언제 시작해야 하나

모든 조직에 전담 플랫폼 팀이 필요한 것은 아니다. 하지만 플랫폼 팀이 필요하다는 신호는 분명하게 존재한다.

여러 팀이 같은 인프라 문제를 각자 독립적으로 풀고 있거나, 개발자가 제품 기능보다 도구 관련 작업에 더 많은 시간을 쓰고 있거나, 새 서비스 온보딩에 주 단위의 시간이 걸리고 있다면 플랫폼 팀을 고려해야 할 시점인 것이다. 대체로 프로덕트 팀이 5개 이상이 되면 중복 노력의 비용이 전담 팀을 구성하는 비용을 넘어서게 된다.

팀 구성

플랫폼 팀을 만든다는 것이 기존 인프라 팀의 이름만 바꾸는 것이어서는 안 된다. 플랫폼 팀에는 서로 다른 역량을 가진 사람들이 필요하다.

시스템을 깊이 이해하는 SRE와 인프라 엔지니어가 기반을 담당하고, 셀프서비스 도구와 개발자 경험을 설계하는 소프트웨어 엔지니어가 인터페이스를 만든다. 그리고 프로덕트 매니저가 반드시 포함되어야 한다. 플랫폼도 하나의 제품이기 때문이다. 프로덕트 사고 없이는 개발자가 실제로 필요로 하는 것 대신 팀 내부에서 멋지다고 생각하는 것을 만들게 되는 것이다. 3-4명이면 의미 있는 가치를 전달할 수 있으며, 작게 시작하는 것이 바람직하다.

Team Topologies

Team Topologies 프레임워크에서 플랫폼 팀의 역할은 명확하다. 셀프서비스 역량을 통해 프로덕트 팀의 인지 부하를 줄이는 것이다.

프로덕트 팀들
    | 셀프서비스 역량을 사용
플랫폼 팀
    | 전문 지식을 제공받음
인에이블링 팀 (보안, 데이터 등)

프로덕트 팀은 잘 정의된 인터페이스를 통해 플랫폼의 역량을 소비한다. 일상적인 작업을 위해 티켓을 올리고 기다릴 필요가 없어야 한다. 이 구조가 제대로 동작하려면 플랫폼과 프로덕트 팀 사이의 인터페이스가 명확해야 하고, 플랫폼 팀이 인에이블링 팀으로부터 보안, 데이터 같은 전문 영역의 지식을 지속적으로 받아야 하는 것이다.

씬 바이어블 플랫폼

처음부터 모든 것을 만들려고 하면 안 된다. 최소한의 기능으로 시작하는 것이 핵심이다.

CI/CD 템플릿 하나, 데이터베이스 프로비저닝 방법 하나, 공유 로깅 파이프라인 하나 정도면 버전 1로 충분하다. 이것을 내보내고, 피드백을 받고, 반복하는 것이다. 기능을 추가할 때에는 상상이 아니라 개발자가 실제로 요청하는 것을 기반으로 해야 한다. 사용자가 없는 상태에서 오래 만든 플랫폼은 실제 필요와 동떨어진 결과물이 될 가능성이 높기 때문이다.

도입 전략

도입을 강제하면서 좋은 결과를 기대할 수는 없다. 플랫폼이 진정한 가치를 제공한다면 개발자들이 자발적으로 사용하게 되는 것이다.

가장 효과적인 접근은 인프라 관련 고통을 가장 크게 느끼고 있는 팀 하나를 찾아서 파트너가 되는 것이다. 그 팀의 배포 시간이 2시간에서 5분으로 줄었다는 것을 보여주면, 그 성공은 자연스럽게 다른 팀으로 퍼지게 된다. 과연 억지로 올려야 하는 플랫폼이 좋은 플랫폼인가? 그렇지 않다. 사용을 강제해야 한다면 그것은 플랫폼 자체에 문제가 있다는 신호인 것이다.

흔한 함정들

플랫폼 팀이 빠지기 쉬운 함정들이 있다. 가장 흔한 것은 사용자 없이 만드는 것이다. 개발자와 대화하기 전에 6개월간 플랫폼을 만들면 실제 필요와 동떨어진 결과물이 나올 수밖에 없다. 프로덕트 사고의 부재도 문제이다. 플랫폼을 제품이 아닌 인프라 프로젝트로 취급하면 사용자 경험이 뒷전으로 밀리게 되는 것이다.

조급한 추상화도 경계해야 한다. 구체적인 문제를 충분히 이해하기 전에 범용 솔루션을 만들면 어디에도 맞지 않는 결과물이 나온다. 피드백을 수집하지만 행동하지 않는 것도 마찬가지이다. 그리고 오버 엔지니어링의 유혹이 있다. 서비스 10개를 운영하는 조직에 10,000개용 설계를 적용하면 복잡성만 늘어나는 셈이다.

이 모든 함정을 피하는 방법은 단순하다. 사용자와 일찍 그리고 자주 대화하고, 작게 내보내고, 빠르게 반복하는 것이다.

성공 측정

플랫폼 팀의 성공은 팀 자체의 산출물이 아니라 프로덕트 팀에 미치는 영향으로 측정해야 한다.

변경 리드 타임은 커밋에서 프로덕션까지 걸리는 시간으로, 줄어들어야 한다. 온보딩 시간은 새 서비스의 첫 배포까지 걸리는 시간으로, 역시 줄어들어야 한다. 개발자 만족도는 플랫폼을 실제로 사용하기 좋아하는지를 나타내는 지표이다. "만든 기능 수" 같은 허영 지표는 의미가 없다. 플랫폼 팀이 만든 기능이 아무리 많아도 프로덕트 팀의 생산성이 향상되지 않았다면 목적을 달성하지 못한 것이다.

시리즈를 마치며

11개의 포스트를 통해 플랫폼 엔지니어링이 무엇인지부터 IDP 아키텍처, 개발자 포털, IaC, Kubernetes, 네트워킹, GitOps, CI/CD, 관측 가능성, 보안, 그리고 팀 구성까지 살펴보았다.

이 모든 내용을 관통하는 원칙은 하나이다. 올바른 일을 쉬운 일로 만드는 것이다. 인지 부하를 줄이고, 셀프서비스를 제공하고, 플랫폼을 제품으로 대하는 것이 핵심이다. 작게 시작하고, 빠르게 반복하고, 사용자의 말에 귀 기울이는 것이 플랫폼 팀이 성공하는 방법인 것이다.