공용 인프라를 위한 cross-team kickoff 문서 만들기(Build a cross-team kickoff doc for shared infrastructure)

Shared infrastructure에는 위키 페이지가 아니라 계약이 필요하다

Contract 없이 출시된 shared infrastructure는 support sink가 됩니다. 모든 consumer가 같은 질문을 반복하고, 팀마다 조금씩 다른 답을 받게 됩니다. Stripe의 engineering 글과 GitHub의 developer research는 모두 contract-first 패턴을 말합니다. Input, output, SLA, versioning policy, deprecation notice period를 첫 consumer onboard 전에 문서화해야 한다는 것입니다. The Pragmatic Engineer의 platform 관련 글은 explicit non-goal을 계약의 가장 레버리지 높은 섹션으로 봅니다. 플랫폼이 하지 않을 일을 명시해야 소비 팀이 엣지 케이스를 당연한 범위로 착각하지 않습니다.

이 프롬프트의 작동 방식

이 프롬프트는 kickoff를 여섯 개 섹션으로 나눠, contract, SLA, onboarding step, change management policy, explicit non-goal, non-negotiable까지 포함하게 합니다. 마지막의 "소비 팀이 가장 어길 가능성이 높은 가정 3개"는 pre-mortem 역할을 합니다. 오해가 ticket이 되기 전에 먼저 드러내는 것입니다.

언제 사용할까

• Shared service가 여러 팀을 곧 onboard할 때
• Platform consumer가 늘며 support load가 치솟을 때
• Rewrite가 breaking change를 만들고 있어 notice가 필요할 때
• 새 platform PM이 ownership hygiene를 세우고 있을 때
• Consumer 질문이 서로 충돌하며 contract가 모호하다는 신호를 줄 때

흔한 함정

• Non-goal이 없는 것. 명시적으로 거절하지 않으면 consumer는 당신이 자기 edge case까지 해결해 줄 거라 가정합니다.
• 모호한 SLA. "고가용성"은 SLA가 아닙니다. 숫자를 적어야 합니다.
• Versioning policy가 없는 것. Breaking change를 예측할 수 없으면 consumer는 통합을 계속 미루게 됩니다.

참고 자료

• Stripe Blog — Stripe
• GitHub Developer Research — GitHub
• The Pragmatic Engineer Newsletter — Gergely Orosz
• The Product Engineer Role — PostHog