복잡한 릴리스 계획을 더 명확하게 정의

이번에는 릴리스 계획 문서(RELEASE_PLAN.md)를 손봤다. 웨어러블 기기용 새로운 폼팩터 지원, 특정 릴리스 버전을 막고 있는 블로커들, 그리고 워치페이스 단위의 상태 추적을 추가한 것이다. 문서 한 장인지라 코드 변경은 없지만, 팀이 나아가는 방향과 우선순위를 결정하는 데 꽤 중요한 작업이었다.

멀티플랫폼 시스템에서 계획 문서가 하는 일

우리 팀이 다루는 워치페이스 시스템은 플랫폼이 하나가 아니다. 각 플랫폼마다 폼팩터가 다르고, 각 버전에는 고유한 제약과 지원 범위가 있다. 새로운 폼팩터(이번의 Wear OS 1-bis처럼)가 추가될 때마다 단순히 코드만 짜는 것이 아니라, 이게 전체 로드맵에 어떻게 들어맞는지, 어떤 조건에서 나올 수 있는지를 팀 전체가 이해해야 한다. 그런데 이걸 구두로 설명하면 자꾸 빠지는 부분이 생긴다.

릴리스 계획 문서는 그 이해를 고정시킨다. 누가 어떤 버전을 담당하든, 디자이너와 개발자가 대화할 때, 매니저가 일정을 짤 때 모두가 "같은 지도"를 보고 있게 해준다. 이번 업데이트는 그 지도를 더 촘촘하고 명확하게 그리는 작업이었다.

추가한 항목들과 그 의미

특히 블로커 항목이 중요했다. 기존에는 "triton 버전은 아직 못 낸다"라고만 했는데, 이제는 왜 못 내는지, 무엇이 막히는지가 명시되어 있다. 이게 보이니까:
- PM이 우선순위 재조정을 제안할 때 팀의 동의를 더 쉽게 얻을 수 있다.
- 다른 팀과 협업할 때 "이 부분이 우리의 임계점입니다"라고 명확하게 말할 수 있다.
- 새로 온 팀원이 온보딩될 때 "왜 지금 이걸 하고 있는지"를 설명하기가 훨씬 간단하다.

상태 추적의 세분화

페이스별 상태 추적도 마찬가지다. 기존에는 "대부분의 페이스는 준비됐다"는 식의 대략적 얘기였다면, 이제는 어떤 페이스가 어느 단계인지가 한눈에 보인다. 이렇게 하면:
- 리소스를 어디에 집중할지 객관적으로 판단할 수 있다.
- 한 페이스의 지연이 전체 릴리스를 늦추는 상황을 미리 감지할 수 있다.
- 각 페이스 담당자가 자기 진행 상황을 정확하게 리포팅할 수 있다.

문서화가 의사결정을 바꾼다

이번 작업을 하면서 느낀 것은, 좋은 문서화는 단순한 기록이 아니라 의사결정 도구라는 점이었다. 블로커가 명시되니 "이걸 먼저 풀면 전체 일정이 2주 앞당겨진다"는 식의 구체적인 영향도 계산할 수 있고, 페이스별 상태가 보이니 "저쪽 담당자한테 리소스를 더 줘야 하지 않을까"라는 제안도 데이터 기반으로 할 수 있다.

특히 팀장 입장에서는, 문서가 있으니 팀원들 사이의 의견 충돌을 더 객관적으로 중재할 수 있다. "내 생각엔" 대신 "계획상" 얘기를 할 수 있다는 뜻이다.

앞으로 배운 것

복잡한 멀티플랫폼 시스템을 다룰 때는, 계획을 "살아있는 문서"로 유지하는 게 정말 중요하다. 계획이 실제와 괴리되기 시작하면 팀이 신뢰하지 않게 되고, 그러면 의사결정이 다시 구두 커뮤니케이션으로 돌아간다. 그 이후는 혼란이고 중복 논의고 시간 낭비다.

그래서 이번 업데이트처럼 "작은 개선"이 계속 들어가야 한다. 새로운 폼팩터가 생기면 즉시 추가하고, 블로커가 해결되면 문서에 반영하고, 상태가 바뀌면 업데이트한다. 그것이 "계획이 팀과 함께 숨 쉬게" 한다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.