Organizing productive platform teams

Context

플랫폼 팀은 조직 내 복잡성을 축소하라는 명령을 받지만, 기존 제품 개발 중심의 조직 구조와 역사적 제약을 그대로 상속받는다. 결과적으로 조직의 커뮤니케이션 구조가 플랫폼 설계에 반영되어 기술적으로는 최적이 아닌 '무거운' 플랫폼이 된다.

Technical Solution

• 조직 구조를 능력(Capability) 기반으로 정렬: 인프라, 데이터, 개발자 경험, 보안을 재사용 가능한 제품으로 취급하고 작업(Task) 단위 팀 구조에서 벗어남
• 모놀리식 시스템의 조직적 성질 인정: 레거시 시스템 안에서 생산성을 지원하면서 동시에 향후 아키텍처를 의도적으로 형성하는 팀 설계
• 제품 마인드셋의 플랫폼 구축: 특정 기능 소유가 아닌 제약 조건 내에서의 활성화(Enablement) 소유로 전환하여 빌드 시간, 테스트성, 개발자 워크플로우 개선
• 명확한 인터페이스 정의: 비공식적 '어깨 탭(Shoulder Taps)' 대신 API와 셀프서비스 포털을 통한 플랫폼 팀과 제품 팀 간 상호작용
• 팀 구조의 동적 진화: 3년 후 원하는 시스템 상태와 그것을 자연스럽게 생성할 커뮤니케이션 구조를 먼저 정의한 후 팀 구성

Impact

플랫폼 엔지니어링에 제품 마인드셋이 없는 경우 처리량 8% 감소, 안정성 14% 감소 발생 (2024 State of DevOps DORA 리포트)

Key Takeaway

Conway의 법칙을 인정하고 현재의 커뮤니케이션 구조를 기술 문제로 보지 않으며, 향후 원하는 아키텍처를 만들 조직 구조를 먼저 설계하는 것이 플랫폼 엔지니어링의 핵심이다.