미사용 서비스 폐기와 디프리케이션: 기술 부채를 줄이는 안전한 워크로드 정리 가이드

새벽 2시, 클라우드 모니터링 대시보드를 살펴보다가 한참 동안 눈을 떼지 못했습니다. 3년 전 마케팅 이벤트용으로 급하게 만들었던 이벤트 응모 서비스가 여전히 전용 데이터베이스와 함께 월 300달러짜리 인프라 자원을 잡아먹고 있었기 때문입니다.

로그를 조회해 보니 지난 한 달간 들어온 요청은 단 4건. 그마저도 해외 검색 엔진의 스크랩봇이 보낸 무의미한 트래픽이었습니다. 더 큰 문제는 매주 진행하는 보안 점검과 의존성 패치 때마다 이 유령 서비스 때문에 팀원 한 명의 하루가 통째로 날아가고 있다는 사실이었습니다.

"이 서비스, 그냥 서버 끄고 코드 삭제하면 안 되나요?" 주니어 개발자의 천진난만한 질문에 시니어들은 쓴웃음을 지었습니다. 사업부 누군가가 갑자기 "어? 우리 옛날 이벤트 데이터 어디 갔어요?"라며 항의할까 봐, 혹은 아무도 모르는 옛날 B2B 파트너 API가 이 서버에 몰래 연결되어 있을까 봐 모두가 선뜻 삭제 버튼을 누르지 못하고 있었습니다.

우리는 흔히 코드를 새로 추가하고 화려한 신규 기능을 개발하는 것에만 열광합니다. 하지만 정작 시스템이 거대해질수록 팀의 발목을 잡는 것은 아무도 책임지지 않는 유령 서비스와 버려진 기능들입니다. 쓰지 않는 기능을 내버려 두는 순간, 코드베이스는 얽히고설킨 덤불이 되고 배포는 공포가 되며 신규 기능의 출시 속도는 반토막이 납니다.

오늘 글을 한 줄로 요약하면 이겁니다. 기술 부채의 진짜 주범인 '유령 서비스'를 안전하게 폐기(Sunset)할 줄 아는 엔지니어가 팀의 생산성을 2배 이상 끌어올립니다.

1. 가지치기 없이 자라는 나무는 결국 스스로의 그늘에 가려 말라죽습니다

과수원의 농부는 열매를 더 크고 단단하게 맺기 위해 겨울마다 과감하게 가지치기를 합니다. 열매를 맺지 못하는 병든 가지를 잘라내지 않으면, 뿌리에서 올라온 영양분이 불필요한 곳으로 dispersion되어 나무 전체가 시들어버리기 때문입니다.

소프트웨어 아키텍처도 과수원 나무와 똑같습니다. 쓰지도 않는 기능과 서비스가 계속 남아있으면 새로운 개발자가 들어왔을 때 온보딩 문맥이 터무니없이 길어지고, CI/CD 파이프라인의 파이프 테스트 시간은 한도 끝도 없이 증가합니다.

제가 이끌던 조직에서 쓰지 않는 서비스 4개를 선정하여 과감하게 폐기(Sunsetting)하는 프로젝트를 단 6주간 진행한 적이 있습니다. 결과는 놀라웠습니다.

• 인프라 운영 비용 35% 절감: 무의미하게 켜져 있던 RDS 데이터베이스와 EC2 인스턴스를 스크랩하여 월 수백만 원의 고정 비용을 즉시 절약했습니다.
• 주간 비상 호출(On-call Alert) 60% 감소: 유령 서비스의 노후된 SSL 인증서 만료나 메모리 누수로 밤마다 울리던 오진동 알림이 완전히 사라졌습니다.
• 배포 리드 타임 45% 단축: 전체 빌드 및 통합 테스트 시간이 25분에서 11분으로 줄어들면서 하루 배포 횟수가 2배 이상 늘어났습니다.

서비스를 잘 만드는 것만큼이나 잘 죽이는 것(Deprecation)은 고도의 엔지니어링 역량입니다. 이를 가능하게 만드는 핵심 시각적 개념들을 정리해 보면 다음과 같습니다.

• 유령 서비스(Zombie Service): 비즈니스 가치는 소멸했으나 단 단 한 명의 사용자나 레거시 로직 때문에 인프라 자원과 관리 리소스를 계속 잡아먹는 시스템.
• 카나리 선셋(Canary Sunsetting): 트래픽을 한 번에 끊지 않고 10%, 50%, 100% 단계적으로 차단하며 비즈니스 영향을 관찰하는 폐기 기법.
• 선셋 SLA(Sunset Service Level Agreement): 서비스 폐기 공지부터 완전 데이터 아카이빙 및 코드 삭제까지 걸리는 공식적인 조직 합의 기간.

2. 마케팅팀의 호통 한 마디에 신규 출시가 한 달 지연되었던 밤

하지만 서비스 폐기가 말처럼 쉬운 것은 결코 아닙니다. 2년 전, 저는 데이터베이스 CPU 사용량이 급증하는 원인을 찾다가 4년 전 외주 업체가 만들고 간 '영수증 이벤트 확인 페이지'를 발견했습니다. Datadog으로 확인한 결과 주간 트래픽은 거의 '0'에 가까웠습니다.

저는 팀원들에게 "트래픽도 없는데 괜히 서버 유지비만 나가니 이번 스프린트에 깔끔하게 정리합시다"라고 말하며, 아무런 사전 공지 없이 해당 API 서버를 중단하고 관련 DB를 테라폼(Terraform) 코드로 삭제해 버렸습니다.

사단은 다음 날 오전에 터졌습니다. B2B 영업 이사님과 마케팅 상무님이 개발팀 자리로 쫓아와 고함을 질렀습니다. 알고 보니 그 유령 서버는 핵심 B2B 고객사의 오래된 결제 상태 조회 시스템이 내부적으로 토큰을 검증할 때 슬그머니 거쳐 가던 숨겨진 프록시 역할을 하고 있었습니다.

"오늘 아침부터 대형 고객사 3곳의 결제 확인이 전면 중단됐습니다! 책임지실 겁니까?"

팀 전체가 비상 상태에 돌입했습니다. 삭제했던 데이터베이스 백업본을 복구하고, 테라폼 코드를 롤백하고, 퍼블릭 IP를 재설정하느라 하루 꼬박 비상 근무를 서야 했습니다. 이 여파로 그달에 예정되어 있던 분기 최대 신규 제품의 출시가 무려 한 달이나 미뤄졌습니다.

단순히 '트래픽이 없다'는 엔지니어의 자만으로 진행한 독단적인 삭제가 조직 전체에 엄청난 신뢰 하락과 비즈니스 손실을 안겨준 것입니다. 그 잔혹한 실패 경험을 통해 저는 깨달았습니다. 서비스 폐기는 '코드 삭제 작업'이 아니라 사업부, C-Level, 고객을 아우르는 '비즈니스 설득 및 리스크 관리 과정'이어야 한다는 사실을요.

3. 안전하고 비난 없는 서비스 폐기를 위한 3단계 선셋 프레임워크

그 사건 이후 우리 팀은 독단적인 삭제를 금지하고, 모든 팀원이 안전하게 유령 서비스를 식별하고 폐기할 수 있는 3단계 프레임워크를 구축했습니다. 이 프레임워크를 도입한 후 단 한 건의 사고도 없이 15개 이상의 레거시 시스템을 성공적으로 선셋시켰습니다.

1단계: 정량적 데이터 기반의 '비용 대비 이용률' 증명

사업부나 PM에게 "이 서비스 안 쓰니까 끌게요"라고 말하면 100% "혹시 모르니까 그냥 두죠"라는 답변이 돌아옵니다. 설득은 감정이 아니라 정량적 숫자로 해야 합니다.

• 트래픽 및 비용 데이터 시각화: 최근 90일간의 MAU(월간 활성 사용자 수)와 호출 건수, 그리고 이 서비스를 유지하는 데 드는 월 인프라 비용 및 패치 공수를 계산합니다.
• 유지비용 대비 가치 산출: "이 기능은 지난 달 12명이 사용했지만 유지비는 150만 원이 듭니다. 사용자 1명당 호출 비용이 12.5만 원입니다"라는 직관적인 리포트를 제시하세요.

2단계: 단계적 의존성 차단과 브라운아웃(Brownout) 테스트

아무리 로그를 뒤져도 숨겨진 호출자가 있을 수 있습니다. 따라서 서비스를 한 번에 끄지 않고 티 안 나게 시그널을 보내야 합니다.

• API Deprecation 헤더 추가: HTTP Response Header에 Sunset: Wed, 11 Nov 2026 00:00:00 GMT 및 Deprecation 경고를 심어 호출하는 측의 개발자 로그에 알림이 뜨게 합니다.
• 브라운아웃(Brownout) 실행: 서비스 폐기 예정일 2주 전, 사용량이 가장 적은 새벽 시간대에 10분~30분간 의도적으로 503 에러를 발생시키거나 응답 지연(Latency)을 주입합니다. 만약 숨은 이용자가 있다면 이때 모니터링 알림이나 문의가 들어옵니다.

3단계: 4단계 스크랩 절차 준수 및 지식 자산화

영향도 검증이 끝나면 체계적인 4단계 스크랩 프로세스에 따라 인프라와 코드를 완전히 정리합니다.

• 1단계 (Data Snapshot): DB 및 S3 데이터를 최종 백업하여 콜드 스토리지(Glacier 등)로 이관.
• 2단계 (Traffic Block): 게이트웨이 및 DNS 단에서 트래픽 완전 차단.
• 3단계 (Infra Destroy): 테라폼/CloudFormation을 활용해 인프라 자원 삭제.
• 4단계 (Code Pure Extraction): 애플리케이션 코드베이스에서 관련 모듈, 테스트 코드, 설정 파일 완전히 제거.

오늘부터 시도할 3가지 지침과 실전 무기 팩

팀에서 서비스 선셋을 시작하고 싶다면 내일 출근해서 다음 3가지를 즉시 실행해 보세요.

1. 유령 서비스 후보 리스트 작성: 최근 6개월간 수정 내역이 없고 트래픽이 저조한 서비스 3개를 찾아 모니터링 링크와 함께 메모해 두세요.
2. 사업부 언어로 번역하기: 인프라 비용 절감액을 신규 기능 개발에 투자할 수 있는 '공수(Man-Month)'로 환산하여 PM에게 공유하세요.
3. 선셋 캘린더 공유: 슬랙이나 노션에 폐기 예정 일정을 최소 30일 전에 공지하는 채널을 만들고 투명하게 소통하세요.

아래 작성된 실전 무기 팩은 여러분이 당장 내일 출근해서 복사하여 팀 노션에 붙여넣고 사용할 수 있는 [서비스 선셋 체크리스트]와 [데이터 분석 AI 프롬프트]입니다. 꼭 활용해 보시길 권합니다.

# 🛠️ [무기 팩 1] 서비스 선셋(Sunsetting) 안전 실행 체크리스트

## 영향도 분석 및 데이터 수집 (D-30)

- [ ] 최근 90일간 APM/Access Log 기반 호출 트래픽 데이터 추출 완료
- [ ] 월간 인프라 유지 비용(AWS/GCP/SaaS) 및 관리 공수 정량화 완료
- [ ] 내부/외부 API 의존성 그래프 작성 (어느 서비스가 이 API를 부르는가?)
- [ ] 사업부(PO/PM/마케팅/영업) 담당자와 폐기 동의 사전 미팅 진행

## 사전 공지 및 브라운아웃 테스트 (D-14)

- [ ] 슬랙 공지 채널 및 외부 개발자 문서에 Deprecation 일정 등록
- [ ] HTTP 응답 헤더에 `Deprecation` 및 `Sunset` 날짜 명시
- [ ] 트래픽 최저 시간에 15분간 브라운아웃(의도적 트래픽 차단) 진행 및 영향 모니터링

## 완전 스크랩 및 코드 정리 (D-Day)

- [ ] 운영 데이터베이스 최종 스냅샷 생성 후 Cold Storage 이관
- [ ] DNS 레코드 및 API Gateway 라우팅 규칙 제거
- [ ] IaC(Terraform 등)를 통한 인프라 자원 삭제 적용
- [ ] 애플리케이션 레포지토리 내 코드, 환경변수, CI/CD 파이프라인 삭제 PR 작성 및 머지
- [ ] 시스템 아키텍처 위키 및 API 명세서 업데이트

---

# 🤖 [무기 팩 2] 유령 서비스 선셋 설득용 AI 프롬프트 템플릿

[역할 정의]
너는 15년 차 시니어 엔지니어링 매니저(EM)이자 시스템 아키텍트야. 
기술을 모르는 비즈니스 이해관계자(PM, 마케터, C-Level)에게 오래된 유령 서비스를 왜 안전하게 폐기해야 하는지 비즈니스 언어로 설득하는 보고서를 작성해야 해.

[요청 사항]
아래 제공된 [서비스 현황 데이터]를 바탕으로, 비즈니스 이해관계자가 한눈에 이해할 수 있는 1페이지 '서비스 선셋 제안서'를 작성해줘.

[서비스 현황 데이터]
- 대상 서비스명: [예: 2023_spring_event_api]
- 최근 30일간 총 호출 수: [예: 14건]
- 월간 인프라 비용: [예: $450 (약 60만 원)]
- 관련 코드 라인 수 및 테스트 코드: [예: 12,000줄 / 테스트 성공률 60%]
- 보안 취약점 이슈: [예: Log4j 레거시 버전 미패치 위험 존재]
- 주요 우려 사항: [예: 마케팅팀에서 과거 응모자 데이터가 사라질까 봐 반대함]

[출력 형식 및 작성 가이드]
1. Executive Summary: 선셋이 필요한 이유 한 줄 요약
2. 비즈니스 리스크 & 비용 손실: 인프라 비용 + 보안 위협 + 개발 생산성 저하를 정량적으로 제시
3. 사업부 우려 완화책: 데이터 백업 및 필요 시 즉시 데이터 추출이 가능함을 강조
4. 타임라인 & 단계별 계획: 사전 공지 - 브라운아웃 - 데이터 아카이빙 - 서버 중단 4단계 일정
5. 톤앤매너: 전문적이면서도 비즈니스 가치(비용 절감 및 신규 개발 속도 향상)를 강조하는 설득조

결국 훌륭한 시스템 아키텍처는 무언가를 계속 더해서 만들어지는 것이 아니라, 더 이상 뺄 것이 없을 때 완성됩니다. 지저분한 레거시와 쓰지 않는 유령 서비스를 과감하게 잘라내어, 여러분의 팀이 진짜 중요한 신규 가치 창출에 집중할 수 있기를 응원합니다.

참고 자료

• Google Cloud: Decommissioning a Legacy System Framework
• Martin Fowler: Deprecation and Migration Lifecycles
• AWS Well-Architected Framework: Cost Optimization & Cleanup

참고 자료 (References)

• Google Cloud Architecture Framework — Operational Excellence & System Decommissioning