플랫폼 엔지니어링에서 일을 만드는 11가지 신호

핵심 요약

• 플랫폼 팀은 제품 로드맵이나 수익 목표가 없으므로 엔지니어 스스로 해야 할 일을 발명해야 한다.
• 포스트모템에서 패턴을 찾으면 수정할 대상이나 교체할 시스템이 명확해지지만, 가장 최근의 큰 장애만 편향되기 쉽고 뒤처진 지표이다.
• 클라우드 비용, 팀 계약, 비용 센터를 분석하고 외주 vs 내부 개발을 반복해 검토하는 것이 신호가 된다.
• 팀의 작업 부담(toil)은 무시되기 쉽지만, 사용자 경험을 개선하는 신호를 제공한다.
• 사용자 인터뷰는 문제 공간을 이해하는 데 중심을 두되, 사용자가 기대하는 '더 빠른 말'에만 의존하면 안 된다.
• 의도하지 않은 용도로 플랫폼을 쓰는 사용자의 오버로드된 사용 사례는 사용자가 만든 프로토타입이며, 다른 사용자도 같은 문제를 가졌는지 확인해 기능화를 판단한다.
• 팀과 사용자가 함께 프로토타입을 만드는 파트너-프로토타입 방식도 같은 판단 기준을 적용한다.
• 마이그레이션 후 채택 지연에 빠진 팀들은 현재 솔루션이 불완전한 이유를 보여주는 신호이다.
• 기존 시스템을 설계 문서로 기술하고 업계의 최신 시스템과 비교하면, 더 이상 타당하지 않은 결정들이 드러난다.
• 업계의 트렌드(오픈소스, 블로그, 논문, 컨퍼런스)는 번들링과 언번들링 사이의 진자 운동 패턴을 보인다. 내부 플랫폼도 지연되지만 같은 방향으로 움직인다.
• 11가지 신호는 사전 논거 제공 정도와 선행/후행 지표 여부로 분류되며, 크래시나 스킵 레벨 같은 가장 큰 신호만 따르는 함정에 빠지지 않으려면 우선순위를 명확히 해야 한다.