웰컴 제거 진행 상황 실소스 기준으로 정정
목차
며칠 전 이커머스 PG 플랫폼의 웰컴 기능 제거 작업을 진행하면서, 그동안 작성해둔 진행 문서들을 다시 읽어 보니 현재 상황과 맞지 않는 부분들이 있었다. 실제 코드베이스를 기준으로 다시 확인하고 문서를 정정했다. 함께 그 과정에서 느낀 것들을 공유한다.
문서와 현실의 간극
팀에서 큰 피처를 제거하거나 주요 변경을 진행할 때, 보통 진행 상황을 문서로 남긴다. jeju-progress-handoff.md와 jeju-welcome-removal-checklist.md 같은 파일들이 그건데, 이런 문서들은 초기에 계획할 때 작성된 후 실제 작업 진행 상황과 동기화되지 않은 채 남아있기 쉽다. 내 경우도 마찬가지였다.
처음 웰컴 제거 작업을 구상할 때는 "이 파트에서 이렇게 제거하고, 저 파트에서는 저렇게 처리할 거야" 정도로 계획했다. 그런데 실제로 코드를 건드려보니 생각보다 의존성이 복잡했다. 어떤 곳은 이미 제거되어 있었고, 어떤 곳은 아직 코드가 남아있었다. 결국 점진적으로 진행하면서 계획서는 손대지 않은 채 두었던 것 같다.
실소스를 기준으로 재점검
이번에 다시 코드베이스를 돌면서 "아, 이건 이미 비활성화되어 있네" "이건 아직 남아있고" 하는 식으로 실제 상태를 파악했다. 그리고 진행 상황 문서(progress-handoff)와 체크리스트(removal-checklist)를 그 실제 상태에 맞춰 업데이트했다.
데이터를 보며 이렇게 느꼈다. 문서는 "의도"를 담아두는 것도 중요하지만, 최종적으로는 현재의 "실제 상태"를 정확히 반영해야 한다는 점이다. 특히 다른 팀에 인수인계할 때, 또는 운영팀이 다음 스텝을 정하려고 할 때, 문서의 부정확함은 혼란을 일으킨다. "어, 이미 완료된 거 아닌가?" "아니지, 이건 아직 대기 중이네" 이런 식으로.
운영 반영 대기 상태의 명시
이번 변경에서 중요한 포인트는 또 하나 있다. 이커머스 PG 플랫폼의 웰컴 기능을 끄는 일이 개발팀에서는 준비가 되었는데, 실제 운영 환경에 반영하려면 운영 팀의 조치가 필요하다는 것이다. 예를 들면 "이 설정 값을 OFF로 바꿔야 한다" 또는 "이 날짜에 기능을 끄는 배포를 진행해야 한다" 같은 것들이다.
그래서 체크리스트 문서에 명시적으로 "현재 운영팀의 반영을 대기 중"이라고 메모해뒀다. 이렇게 하면 누가 이 문서를 봐도 "아, 이건 개발은 끝났지만 배포는 아직" 이라는 걸 명확히 알 수 있다. 특히 팀 리딩 관점에서 여러 파트의 진행 상황을 한눈에 보려고 할 때, 이런 명시적인 상태 표기가 얼마나 도움이 되는지 다시 한 번 깨달았다.
배운 점
크게 두 가지다.
첫째, 큰 작업일수록 실제 진행 상황을 정기적으로 문서에 동기화해야 한다. 계획과 실제는 항상 다르다. 계획만 남고 현실이 문서에 반영되지 않으면, 그 문서는 오히려 노이즈가 된다. 어느 정도의 주기(일주일? 두 주?)로 "지금 현재 상태가 이거고, 다음은 이거다"를 정리하는 습관이 필요하다.
둘째, 상태 전이(state transition)를 명확하게 표기하는 것이 팀 커뮤니케이션의 기초다. "대기 중", "진행 중", "완료", "블로킹됨" 같은 상태들이 문서에 명시되면, 각 팀 멤버들이 다음 액션을 판단하기 훨씬 쉬워진다. 운영팀은 "아, 개발팀이 완료 신호를 줬으니까 우리가 해야 할 일이 있겠네" 하고 움직일 수 있는 것이다.
문서는 코드만큼 중요한 자산이다. 특히 여러 팀이 협력하는 환경에서 더더욱 그렇다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.