생산적인 플랫폼 팀 조직하기

Source: Stack Overflow Blog

소개

플랫폼 엔지니어링을 기술적인 분야로 규정하고 싶어지는 유혹이 있습니다. 실제로는 이것이 조직적인 분야이기도 합니다.

플랫폼 팀은 복잡성을 줄이라는 요구를 받으면서도, 그 자체를 둘러싸고 진화해 온 조직 내에 자리 잡고 있습니다. 이들은 제품 팀이 우회하도록 배운 모든 과거 제약, 정치적 경계, 그리고 암묵적인 의존성을 물려받습니다. 그래서 많은 플랫폼이 무겁게 느껴지는 이유는—조직이 원하는 아키텍처가 아니라 조직 자체를 반영하고 있기 때문입니다.

Conway’s Law

1967년, 멜빈 콘웨이는 시스템이 그것을 구축하는 조직의 커뮤니케이션 구조를 반영하는 경향이 있음을 관찰했습니다. 콘웨이 법칙은 저주도 처방도 아니며, 조직 물리학에 대한 중립적인 관찰입니다: 조정 비용이 설계에 영향을 미칩니다. 팀은 깨끗한 기술적 추상화를 최적화하기보다 서로 어떻게 대화하는지를 먼저 최적화합니다.

플랫폼 엔지니어링은 이 현실을 선명하게 부각시킵니다. 플랫폼은 레버리지, 일관성, 속도를 약속하지만, 제품, 마감일, 과거 제약을 중심으로 진화한 조직 내에서 구축됩니다. 조직 구조가 여전히 혼란스럽다면, 플랫폼은 그 혼란을 반드시 반영하게 됩니다.

Challenges for Platform Teams

플랫폼 엔지니어링은 독특한 압력점에 놓여 있습니다. 명확한 사명은 스트림‑정렬 팀의 인지 부하를 줄이는 것이지만, 현실에서는 플랫폼이 조직의 “복잡성 싱크”가 되는 경우가 많습니다. 플랫폼은 자율성을 가능하게 하면서 표준을 강제하고, 장기적인 관점을 유지하면서도 즉각적인 문제에 대응해야 합니다.

마찰은 플랫폼 팀이 복잡한 시스템을 소유하고 있기 때문이 아니라(그것이 그들의 업무입니다), 제품 팀이 손대고 싶어 하지 않는 모든 운영 혼란을 포괄적으로 처리하도록 자주 요구받기 때문입니다. 조직이 콘웨이 법칙에 맞서 싸울 때, 플랫폼 팀은 제품 역량이라기보다 프로세스 단계로 구성됩니다:

• 한 팀은 배포를 실행합니다.
• 다른 팀은 인프라 티켓을 프로비저닝합니다.
• 또 다른 팀은 신뢰성을 모니터링합니다.

그들 중 어느 팀도 아이디어에서 프로덕션까지의 전체 흐름을 소유하지 않으며, 단지 관료주의의 일부분만을 담당합니다. 증상은 바로 인계 자체이며—조정이 작업이 됩니다.

2024 State of DevOps (DORA) Report의 연구는 이 위험을 검증합니다. 제품 마인드셋이 부족한 플랫폼 구현은 처리량이 8 % 감소하고 안정성이 14 % 감소하는 것과 연관되었습니다.

모놀리스를 커뮤니케이션 아티팩트로 보기

조직이 대형 모놀리스를 탈피해 나가면서 긴장은 더욱 뚜렷해집니다. 모놀리스는 단순한 기술 아티팩트가 아니라 조직 역사의 기록입니다. 공유된 모듈 하나하나, 암묵적인 의존성, 숨겨진 결합은 모두 과거의 협업 결정들을 반영합니다. 모놀리스를 순수히 기술적인 문제로만 취급하면 핵심을 놓치는 셈입니다.

모놀리스를 일시적인 불편함이라고 가장하는 대신, 효과적인 플랫폼 조직은 이를 현재의 커뮤니케이션 구조로 인식합니다. 그들은 모놀리스 내부에서 생산성을 지원할 수 있는 팀을 구성하면서, 동시에 미래 아키텍처를 의도적으로 설계해 나갑니다.

Source: …

제품 플랫폼

제품 플랫폼은 기능을 보유하는 것이 아니라 제약 내에서 활성화를 보유하는 것입니다. 이는 오늘날 제품 팀이 대부분의 시간을 소비하는 마찰을 줄이는 데 초점을 맞추면서, 내일 시스템이 변화하도록 준비하는 데 중점을 둡니다. 개선 사항은 빌드 시간, 테스트 가능성, 개발자 워크플로우를 목표로 하며—단독 최적화가 아니라 아키텍처 신호로서 접근합니다.

핵심은, 이러한 유형의 팀은 영원히 존재하도록 설계된 것이 아니라는 점입니다. 팀의 사명은 시스템이 진화함에 따라 변화하며—이는 콘웨이의 법칙을 명시적으로 인정하는 것입니다: 커뮤니케이션 구조가 바뀌면 팀 구조도 바뀌어야 합니다.

효과적인 플랫폼 조직을 위한 패턴

가장 효과적인 플랫폼 조직은 흐름에 맞서 싸우지 않고, 흐름을 활용합니다. “오늘 우리는 어떤 팀이 필요한가?” 라고 묻는 대신, “3년 후에 어떤 시스템을 갖고 싶으며, 어떤 커뮤니케이션 구조가 자연스럽게 그것을 만들어낼 수 있을까?” 라고 묻습니다.

일관된 패턴에는 다음이 포함됩니다:

• 역량에 맞춘 정렬, 작업이 아니라 – 인프라, 데이터, 개발자 경험, 보안은 수동 서비스가 아니라 재사용 가능한 제품으로 취급됩니다.
• 정의된 상호작용 – 제품 중심 팀은 비공식적인 “어깨 두드림”이 아니라 잘 정의된 인터페이스(API, 셀프‑서비스 포털)를 통해 플랫폼과 상호작용합니다.
• 인지 부하를 주요 지표로 – 성공은 플랫폼이 개발자들의 업무를 얼마나 단순화시켜, 지속적인 팀 간 조정 필요성을 얼마나 줄였는지로 측정됩니다.

무엇보다도, 플랫폼 팀은 진화합니다. 레거시 시스템을 안정화하는 팀과 분산 아키텍처를 최적화하는 팀은 동일하지 않습니다. 시스템이 변할 것으로 기대하면서 팀 구조를 정적인 것으로 간주하는 것은 플랫폼 전환에서 흔히 발생하는 실패 요인입니다.

Conclusion

플랫폼 팀이 해결하는 가장 어려운 문제들은 API나 파이프라인에 관한 것이 아니라 경계, 소유권, 인센티브, 그리고 신뢰에 관한 것입니다. 콘웨이의 법칙은 경험 많은 엔지니어들이 이미 느끼고 있는 것을 언어화한 것에 불과합니다.

배포를 가속화하는 플랫폼을 원한다면, 조직도 그 의도를 반영해야 합니다. 독립적으로 진화하는 서비스를 원한다면, 팀도 동일하게 할 수 있어야 합니다. 인지 부하를 줄이려면 먼저 조직 복잡성을 줄여야 합니다.

플랫폼 엔지니어링은 조직이 구축하는 시스템만큼이나 의도적으로 설계될 때 성공합니다. 그것이 진정한 작업입니다.