계약 종료 서비스, 여러 팀 영향도 관리하기

계약이 종료된 "웰컴" 서비스를 제거하기 위해 조직 지침 문서를 정리하고, 단계적 제거 계획을 수립했다. 단순히 코드를 지우는 것이 아니라 여러 팀이 참고하는 공식 지침에 이 변화를 반영하고, 제거 작업을 체계적으로 추진하기 위한 구조를 만들었다는 점이 포인트다.

왜 "지침 업데이트 + 제거 계획"인가

처음엔 "계약 종료됐으니 관련 코드 싹 빼면 되지 않을까" 싶을 수 있다. 하지만 실제로는 그렇게 단순하지 않다.

CLAUDE.md는 조직 전체의 참고 문서다. 팀마다 이 지침을 읽고 작업 방향을 정한다. 만약 "웰컴"에 대한 가이드가 지침에 남아 있으면, 신규 팀원이나 다른 파트가 계속 참고하게 되고, 결국 불필요한 통합을 시도하거나 오래된 정책을 따를 수 있다.
여러 곳에 산재되어 있다. 계약 종료 서비스는 한 파일에만 있는 게 아니다. 문서, 코드, 설정, 스크립트 등 여러 곳에 엮여 있을 가능성이 크다. 이를 한 번에 추적하지 않으면 나중에 "어? 이 코드는 왜 여기 있지?"라는 기술 채무가 남는다.

그래서 이번엔 다르게 접근했다.

CLAUDE.md는 단순한 "TODO 목록"이 아니라 조직의 정책 문서다. 여기에 변경사항을 명시하는 건 "이제부터 이렇게 하자"를 공식 선언하는 것과 같다.

변경 전:
웰컴 서비스 통합 관련 문서 및 지침 유지

변경 후:
웰컴 서비스 계약 종료 — 2026년 Q2 이후 더 이상 신규 기능 추가 금지
제거 일정은 별도 계획 문서 참고

이렇게 명시하면:
- 모든 팀이 "아, 이제 이 서비스는 유지보수 모드네"라는 걸 알 수 있다.
- 실수로 여기에 의존하는 새 기능을 짜려던 팀이 미리 알아차리고 다른 방식을 찾을 수 있다.
- 향후 "왜 이건 그대로 있지?" 같은 질문이 줄어든다.

흥미로운 부분은 제거 계획이 두 개의 문서로 나뉜 점이다:

단계	목적	내용
Disable Plan	운영 영향 최소화	기존 사용자에게 미리 공지, 점진적 비활성화
Removal Checklist	완전 제거	코드, 문서, 설정에서 전부 제거 (rollback 고려)

실무에서 이렇게 나누는 이유:

Disable이 먼저 나가야 한다. 기존 사용자가 갑자기 서비스를 못 쓰게 되면 장애처럼 보인다. "1주일 공지 후 비활성화" 정도의 완충 기간이 필요하다.
Removal은 그 다음. 실제 코드 삭제는 disable이 완료되고, 사용자 피드백을 수집한 후에 시작하는 게 안전하다.
롤백을 고려해야 한다. Disable 단계에서 예상 못 한 문제가 터질 수 있다. 롤백 계획이 필요하면 제거 전에 정의해야 한다.

체크리스트 문서가 있으면, 각 팀이 "우리 파트에서 뭘 해야 하나?" 를 명확하게 알 수 있다. 백엔드는 API 제거, 프론트는 UI 빼기, DevOps는 배포 설정 정리 같은 식으로 병렬 진행도 가능해진다.

이런 작업을 하다 보니 느낀 점:

지침은 정적이 아니라 동적이다. 서비스가 나오고, 계약이 종료되고, 팀 구조가 바뀌면 지침도 업데이트되어야 한다. 그런데 많은 조직에서 지침을 "처음 정한 후 방치"하는 경향이 있다.
변화를 문서화하는 시간이 중요하다. 코드 변경과 달리, 지침 업데이트는 "왜 이렇게 바꿨나"를 기록해야 나중에 다른 팀이나 신규 팀원이 이해할 수 있다.
체크리스트는 협업의 도구다. "누가 뭘 끝냈는지" 한눈에 보인다. PR 리뷰 때도 "어? 이건 뭐하려고 지웠어?" 질문이 줄어든다.

이번 작업은 단순한 "서비스 제거"라기보다 "조직의 정책 변화를 어떻게 안전하게 전파하고 실행하는가"에 대한 작은 케이스 스터디였다.

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

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