애플리케이션 플랫폼: 플랫폼 엔지니어링 문화

애플리케이션 플랫폼

마이크로서비스는,

• 애플리케이션이 여러 컴포넌트로 분리
• 각기 다른 팀이 독립적으로 개발 및 배포
• 소프트웨어 개발 속도가 빨라지고 대규모 릴리스 일정을 수립하고 조율할 필요성 감소
• 각 서비스를 담당하는 팀은 독립적이며 자신의 고객(내/외부)에게 필요한 비즈니스 요건에 대응 가능
• 각기 다른 클라우드 리소스에 수평적으로 조절된 규모로 다중 배포되어 네트워크상의 다양한 프로토콜을 이용해 서로 통신
• 데이터 전송과 통신량으로 추가 비용과 레이턴시 발생 -> 사용자 경험을 저하시킬 수 있음
• 서로 독립적으로 릴리즈되지만 의도치 않게 서로 영향을 미칠 수 있음

이런 특징을 가집니다.

이렇게 분산된 시스템 관리를 위해 새로운 관행(convention), 도구, 엔지니어링 문화가 필요합니다.

플랫폼 엔지니어링 문화

1. 표준화의 필요성과 역할 분담

• 조직 내 통신 규약 및 프레임워크는 통일되고 표준화되어야 함
• 각 팀이 독자적으로 개발 스택을 관리하는 방식은 비효율적이며 중복된 노력을 유발함
• 플랫폼 팀은 표준화를 책임지고,
  프로덕션 팀은 비즈니스 요구사항 개발에 집중할 수 있도록 지원

“우리가 제공하는 것은 관문이 아니라 가드레일이다.”
— 다이앤 마시, 넷플릭스 엔지니어링 도구 디렉터

2. '관문'이 아닌 '가드레일'로서의 플랫폼 팀

• 팀마다 다양한 방식을 실험하고 적용할 수 있도록 유연성 보장
• 플랫폼 팀은 개별 팀의 방식을 배우고 관찰한 뒤, 이를 조직 전체에 일반화

“시스템의 구조는 필연적으로 그 시스템을 설계하는 조직의 커뮤니케이션 구조를 닮는다.”
— 콘웨이의 법칙

• 플랫폼 엔지니어링을 잘하면 각 팀에 전문가가 따로 없어도 고품질 시스템 운영 가능

3. 전사적 도구 도입 예시: 모니터링

• 플랫폼 팀이 공통 라이브러리 형태로 모니터링 기능 제공
• 모든 서비스에 기본적인 가용성 척도가 자동 반영
• 프로덕션 팀은 자신의 영역에 특화된 지표만 추가하면 됨 (약간의 시간 소요)

4. 개발자 경험에 집중하는 플랫폼 팀의 태도

• 플랫폼 팀은 프로덕션 팀의 개발자 경험(Developer Experience)에 깊이 몰입해야 함
• 복잡한 요구사항을 제거하여 진입 장벽을 낮추는 데 많은 공감과 노력 필요
• 다양한 팀의 반복적 문제에서 패턴을 추출하고, 도구나 가드레일로 대응
• 예시) 반복되는 스크립트 실행, 바이너리 종속성 충돌, 플러그인 버전 문제, 릴리스 파이프라인 결함 등
• 도구는 기존 기능을 해치지 않아야 하며, 경고 메시지 제공만으로는 충분하지 않음
• "성공만 하면 되니까 경고는 무시하자"는 인식이 생기기 쉬움
• 플랫폼 팀은 프로덕션 팀의 시각에서 문제를 바라보고, 그들에게 익숙한 방식으로 지식을 전달하려는 노력이 필요함

5. 수정 권고 수용률과 롱테일 단계

• 시간이 지나면서 문제 패턴의 영향력은 감소하고 대부분의 팀이 권장안을 수용하게 됨
• 결국 비협조적인 일부 팀만 남는 롱테일 단계에 도달
  • 이때는 해당 팀들을 직접 찾아가 1:1 협업 필요
  • 적극적인 소통을 통한 신뢰 구축으로, 향후 권장안 수용률도 높일 수 있음

6. 권장안의 가시성과 플랫폼 팀의 자세

• 권장안은 쉽게 찾고 이해할 수 있어야 하며,
  지속적으로 가시성을 높이기 위한 노력이 필요
• 유능한 플랫폼 팀일수록 개발자 경험에 집중하며,
  그들이 혜택을 체감할 수 있도록 설계해야 함