『플랫폼 엔지니어링』
카미유 푸르니에, 이언 놀런드, 『플랫폼 엔지니어링』, 류광, 307번역랩 역, 한빛미디어, 2025
플랫폼 엔지니어링의 정의와 필요성
이 책에서 사용하는 용어의 정의는 다음과 같다.
- 플랫폼: 셀프서비스 API, 도구, 서비스, 지식 및 지원으로 구성된 하나의 토대. 플랫폼은 조직 내 제품의 형태로 구성된다. 애플리케이션 팀은 플랫폼을 활용해서 팀 간 조정 비용을 줄이면서도 바르게 제품의 기능을 전달할 수 있다.
- 플랫폼 엔지니어링: 플랫폼을 개발하고 운영하는 특정 분야. 이 분야의 목표는 비즈니스에 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것이다.
- 레버리지: 플랫폼 엔지니어링의 핵심 가치는 레버리지에 있다. 레버리지는 소수의 플랫폼 엔지니어들의 작업이 조직 전체의 업무를 줄여주는 것을 의미한다. 플랫폼은 (1) 애플리케이션 엔지니어들이 비즈니스 가치를 창출하는 과정에서 생산성을 높이고, (2) 애플리케이션 엔지니어링 팀 간의 중복 작업을 제거해 효율성을 높임으로써 레버리지를 달성한다.
- 제품: 플랫폼은 하나의 제품이다. 플랫폼을 매력적인 제품으로 개발한다는 것은 플랫폼의 기능을 결정할 때 고객 중심적 접근 방식을 취한다는 의미이다.
지난 25년간 클라우드와 오픈소스 소프트웨어(OSS)라는 두 트렌드가 소프트웨어 업계에 많은 변화를 가져왔다. 조직은 유지보수 비용을 줄이기 위해 클라우드와 OSS를 도입하지만, 이들은 범용적인 솔루션이기 때문에 특정 애플리케이션에 맞게 동작하려면 접착체가 필요하다. 접착제는 시간이 흐를수록 끈적임이 강해지며 미래의 변경을 어렵게 만든다. 그리고 접착제가 점차 확산되면서 '과도한 일반화의 늪’이 만들어진다.
과도한 일반화의 늪에 빠지게 되는 과정에는 소프트웨어 산업이 겪은 변화가 큰 영향을 미쳤다. (1) 인터넷은 소프트웨어에 대한 엄청난 수요를 만들었다. 수요를 감당하기 위해서는 더 많은 하드웨어가 필요했고, 애플리케이션 엔지니어들은 복잡해진 인프라 문제를 쉽게 해결하기 위해 클라우드를 도입했다. 하지만 클라우드 서비스(특히 PaaS가 아닌 IaaS)는 애플리케이션을 이전보다 더 인프라에 종속시켜버렸다. 쿠버네티스의 부상은 클라우드 서비스가 조직의 요구를 충족시키지 못했다는 증거다. (2) 애플리케이션이 폭발적으로 증가하며 운영이 문제가 되었다. 90년대 소프트웨어 산업에는 개발 조직과 운영 조직이 분리되어 있었다. 하지만 한 팀은 빠르게 기능을 개발해 배포하고, 다른 한 팀은 문제가 생겼을 때 최전선에서 해결하는 구조에는 긴장이 발생했다. 이러한 상황은 데브옵스(DevOps)의 도입으로 이어졌다. 데브옵스는 애플리케이션 개발과 운영을 통합하는 모델이다. 업계는 데브옵스를 분리형(운영팀과 개발팀을 분리하되, 운영팀이 코드를 푸시하는 등 일정 개발 업무를 수행하는 방식)이나 통합형("만든 사람이 운영한다"라는 원칙으로 온콜 운영 업무를 공유하는 방식)으로 구현했다. 비슷한 시기 구글은 SRE라는 방식으로 전환했다.
두 변화로 인해 소프트웨어의 릴리즈 주기가 크게 단축되었고, 더 빠른 릴리즈를 위해 애플리케이션 엔지니어는 소프트웨어를 더 자주 수정해야 한다. 변화에 대한 압박은 개별 팀의 의사결정을 접착제와 뒤섞어 늪을 만들어냈다. 그렇다면 플랫폼 엔지니어링은 어떻게 늪을 정화하는가? 개발자들은 자신이 좋아하는 시스템을 사용할 때 더 큰 자율성을 느낀다. 하지만 리더십은 권위에 호소하며 표준을 규정해버리곤 한다. 플랫폼 엔지니어링은 비용 절감이나 효율성에만 초점을 맞추지 않고, '고객으로서의 팀’을 배려해 플랫폼을 제공할 수 있다.
플랫폼 엔지니어링에는 4개의 기둥이 있다.
- 제품: 플랫폼 엔지니어링은 큐레이션된 제품 접근 방식을 따라야 한다. 큐레이션되었다는 것은 플랫폼에 무엇이 포함되고 제외되는지에 대한 나름의 관점(opinion)을 가지고 제공 사항을 엄선한다는 뜻이다. 제품 접근 방식이란, 기술 중심적인 사고에서 벗어나 고객 중심적인 플랫폼을 제공한다는 의미다. 큐레이션없는 제품 접근 방식은 일관된 전략이 없어 단순한 서비스 센터가 된다. 제품 접근 방식없는 큐레이션은 조직의 요구를 충족시키지 못하는 경직된 서비스가 된다. 큐레이션된 제품 접근 방식이 성공하면 두 가지 유형의 플랫폼 제품이 만들어진다: (1) '포장도로’는 여러 서비스를 층층이 쌓아 복잡성을 숨김으로써 사용하기 쉬운 워크플로우를 만드는 유형이다. 포장도로는 강제된 서비스가 아니기 때문에 특수한 요구사항이 있는 팀은 도로에서 벗어나 자신의 길을 갈 수 있다. (2) '철도’는 기존 제품으로 해결되지 않지만 여러 애플리케이션 팀들이 공통적으로 요구하는 문제를 해결하는 유형이다. 철도는 애플리케이션 팀은 기존 플랫폼 대신 철도 플랫폼을 사용할 수 있다.
- 개발: 플랫폼 엔지니어링은 인프라나 개발자 도구 수준을 넘어서는 소프트웨어를 개발해야 한다. 아직 소프트웨어 개발이 필요하지 않다면 플랫폼 엔지니어링이 필요한 단계가 아니다. 플랫폼 엔지니어링은 사내에서 개발한 소프트웨어 로직을 사용해 기반 시스템을 추상화함으로써 레버리지를 만든다. 플랫폼 엔지니어가 만들 수 있는 추상화의 예시로는 외부 서비스를 적당히 캡슐화해 애플리케이션에게 API를 제공하는 플랫폼 서비스, 애플리케이션 안에서 실행되는 리치 클라이언트 및 플랫폼 라이브러리, OSS 플러그인과 커스텀, 메타데이터 레지스트리 통합 등이 있다.
- 범위: 플랫폼은 애플리케이션 개발팀을 폭넓게 지원해야 한다. 이를 위해서는 셀프 서비스, 사용자 관측성(사용자가 자신의 실수인지 플랫폼의 문제인지 구분할 수 있어야), 가드레일, 다중 테넌트(같은 런타임 구성요소 내에서 다른 애플리케이션을 실행할 수 있어야) 등의 역량을 개발해야 한다.
- 운영: 플랫폼은 비즈니스의 토대로서 운영되어야 한다. 애플리케이션 엔지니어가 자신의 비즈니스를 플랫폼에 맡길 수 있어야 하며, 고객이 플랫폼 운영에 신경써야 한다면 플랫폼은 레버리지를 제공하지 못한다. 플랫폼이 토대로 작용하려면 플랫폼 엔지니어링 팀이 전체 플랫폼에 대한 운영 책임을 지고, 플랫폼 지원을 보장하고, 운영 실무에서 규율을 지켜야 한다.
플랫폼 엔지니어링 실무
초기 스타트업에는 별도의 플랫폼 엔지니어링 팀이 필요하지 않을 수 있다. 작은 규모의 조직에서는 애플리케이션 엔지니어들이 플랫폼 엔지니어링 업무를 겸하곤 한다. 공유 코드의 문제점이 증가해 자발적인 기여로 감당하기 어려울 정도가 되면 플랫폼 엔지니어링 팀을 구성할 때다. 최초의 플랫폼 엔지니어링 팀은 다른 엔지니어링 조직과 강한 연결을 유지해야 하며, 과도한 수준의 플랫폼을 구축하지 않도록 주의해야 한다.
플랫폼 엔지니어링 팀은 다양한 기술에 폭넓은 관심을 가져야 한다. 단일 초점 플랫폼 엔지니어링 팀의 종류와 한계는 다음과 같다.
- 지나친 시스템 중심 접근: 이 팀은 인프라, 데브옵스 배경을 가진 팀원들로만 구성된다. 대규모 코드베이스에서 많은 양의 코드를 작성한 경험은 많지 않다. 이 팀은 운영 면에서 매우 뛰어나지만, 운영 문제를 근본적으로 해결하기 위한 소프트웨어 개발은 거의 하지 않는다. 이 팀은 면접에서 매뉴얼이나 전문 서적의 세부사항을 중요시 하기 때문에 실제로 더 나은 추상화를 만들어 운영 부담을 덜어줄 수 있는 소프트웨어 엔지니어를 영입하지 못한다.
- 과도한 개발 중심 접근: 이 팀은 코드 작성을 좋아하며, 실제로 대량의 코드를 생산한다. 이들은 새롭고 더 나은 시스템을 만드는 일이 아니라면 흥미를 느끼지 못한다. 지난 20년간 업계는 더 많은 코드를 배포하는 엔지니어에게 더 많은 보상을 해왔고, 이 팀의 리더도 많은 코드를 작성하며 현재의 위치에 올랐다. 이 팀은 실무 능력이 아무리 뛰어나도 30분안에 알고리즘 문제를 풀지 못하면 채용하지 않기 때문에 운영 역량이 있는 엔지니어를 영입하지 못한다.
운영 역량과 소프트웨어 개발 역량을 모두 갖춘 플랫폼 엔지니어링 팀을 만들기 위해서는 소프트웨어 엔지니어, 시스템 엔지니어, 신뢰성 엔지니어, 시스템 전문가 역할이 모두 필요하다.
플랫폼 엔지니어링 팀은 새로운 것을 구축하는 동시에 안정성, 신뢰성, 사용성을 고려해야 한다. 때문에 플랫폼 엔지니어링 팀의 문화는 제품 엔지니어링 팀보다 다소 보수적인 경향을 보인다. 플랫폼 엔지니어링 팀의 리더는 '우리 대 그들’이라는 문화가 형성되지 않도록 신경써야 한다. 고도로 신뢰할 수 있는 시스템을 운영한다는 자부심이 결함있는 코드를 계속 배포하는 제품 엔지니어링 팀에 대한 경멸로 변질될 정도가 되어서는 안 된다.