또 새로운 버즈워드?

인프라 쪽에서 오래 일하다보면 직무를 칭하는 용어가 계속 변경되는 것을 경험한다. 시스템 관리자, DevOps, SRE, 이제는 플랫폼 엔지니어링이라는 용어가 생겼다.

이러한 용어는 과연 단순 리브랜딩일까?

그렇지 않다. 환경이 변화되며, 역할이 확대 및 축소되고, 변화된 환경에 맞는 이름이 부여되는 것이다. 기존 DevOps가 풀지 못했던 문제를 플랫폼 엔지니어가 풀려고 시도하는 것도 하나의 예시이다.

DevOps의 한계

DevOps는 "네가 만들면, 네가 운영한다"라는 철학을 가진다. 개발자가 코드 작성에 그치지 않고 운영까지 책임지겠다는 것이다. 이론적으로는 훌륭한 접근이다.

하지만 현실에서는 문제가 드러난다. 모든 팀이 각자의 Terraform을 작성하고, 각자의 CI/CD 파이프라인을 구축하고, 각자의 Kubernetes 클러스터를 관리한다. 결과적으로 10개 팀이 동일한 문제를 10가지 방식으로 해결하게 되는 것이다. 개발자들은 비즈니스 로직을 작성하는 대신 YAML 파일을 디버깅하는 데 시간을 쓰게 된다.

이를 인지 부하(Cognitive Load)라고 부른다. 코드를 프로덕션 환경에 배포하기 위해 개발자가 알아야 하는 지식의 총량이 지나치게 커진 것이다. DevOps의 철학 자체는 올바르지만, 그 실행 과정에서 개발자에게 과도한 부담을 전가하게 된 셈이다.

그래서 플랫폼 엔지니어링이란?

플랫폼 엔지니어링은 내부 개발자 플랫폼(Internal Developer Platform, IDP)을 구축하는 분야이다. 개발자와 인프라 사이에 셀프서비스 레이어를 두어, 개발자가 인프라의 복잡성을 직접 다루지 않아도 되게 하는 것이 핵심이다.

예를 들어, 데이터베이스가 필요할 때 티켓을 올리고 기다릴 필요가 없어야 한다. 애플리케이션을 배포하기 위해 Kubernetes의 내부 동작을 이해할 필요도 없어야 한다. 플랫폼이 이러한 복잡성을 추상화하여 개발자에게 간단한 인터페이스만 제공하는 것이다.

개발자 ──→ 플랫폼 (셀프서비스) ──→ 인프라
                │
                ├── "DB 필요해"     → 완료
                ├── "앱 배포해줘"   → 완료
                └── "로그 보여줘"   → 여기

DevOps, SRE, 플랫폼 엔지니어링의 관계

이 세 가지는 경쟁 관계가 아니라 서로 다른 관점에서 같은 문제를 바라보는 것이다.

초점누가
DevOps개발과 운영의 공유 오너십모두
SRE엔지니어링으로 신뢰성 확보SRE 팀
플랫폼 엔지니어링셀프서비스로 인지 부하 감소플랫폼 팀

정리하자면, DevOps는 문화이고, SRE는 실천이며, 플랫폼 엔지니어링은 제품이다. 플랫폼 팀은 하나의 제품을 만드는 것이며, 그 제품의 고객은 같은 조직 내의 개발자들이다. 이러한 관점의 차이가 플랫폼 엔지니어링을 기존 접근법들과 구분 짓는 핵심이다.

골든 패스

플랫폼 엔지니어링에서 자주 등장하는 개념 중 하나가 골든 패스(Golden Path)이다. 이는 특정 작업을 수행하는 데 있어 플랫폼이 권장하는 표준 경로를 의미한다.

웹 서비스 배포를 예로 들면, 제공된 템플릿을 사용하고 브랜치에 푸시하면 CI가 자동으로 실행되고, 스테이징 환경에 배포된 후 원클릭으로 프로덕션에 반영되는 흐름이다. 이 경로를 반드시 따라야 하는 것은 아니다. 필요하다면 벗어날 수도 있다. 다만, 기본 경로가 충분히 편리하기 때문에 대부분의 개발자가 굳이 벗어나지 않게 되는 것이 골든 패스의 목표이다.

플랫폼 팀이 하는 일

플랫폼 팀의 업무는 다양하지만, 공통된 목적이 있다. 개발자 포털을 구축하여 서비스, 문서, 도구를 한곳에서 접근할 수 있게 한다. 셀프서비스 인프라를 제공하여 데이터베이스, 메시지 큐, 스토리지 등을 개발자가 직접 프로비저닝할 수 있게 한다. CI/CD 템플릿을 만들어 파이프라인을 처음부터 작성하지 않아도 되게 한다. 관측 가능성(Observability) 도구를 통합하여 로깅, 메트릭, 트레이싱을 일관된 방식으로 제공한다.

이 모든 활동의 공통점은 하나이다. "코드를 작성했다"에서 "프로덕션에서 실행되고 있다"까지의 거리를 줄이는 것이다.

일정 규모를 넘어선 조직은 결국 같은 벽에 부딪히게 된다. 개발자가 비즈니스 로직보다 인프라 관리에 더 많은 시간을 소비하는 상황이다. 플랫폼 엔지니어링은 이 문제에 대한 체계적인 답이다.

다음 포스트에서는 IDP의 내부 구성 요소를 살펴본다.