코드를 지우는 결정은 왜 항상 미뤄지는가
새 기능을 만드는 절차는 어느 조직에나 있습니다. 설계 문서, 코드 리뷰, 테스트, 배포 파이프라인까지 신입 온보딩 첫 주에 배웁니다. 반대 방향의 절차, 그러니까 기능을 지우는 절차를 가진 조직은 훨씬 드뭅니다. 이 글은 소프트웨어를 오래 운영해 본 엔지니어와 팀 리드를 위한 글입니다. 읽고 나면 왜 우리 팀이 안 쓰는 코드를 못 지우는지, 그리고 그 문제를 감이 아니라 절차로 바꾸려면 무엇부터 손대야 하는지 알게 됩니다.
결론부터 말하면 이렇습니다. 코드를 못 지우는 이유는 기술이 부족해서가 아니라 판정 기준과 실행 순서가 없어서입니다. 판정 기준을 증거 등급으로 고정하고, 실행 순서를 되돌릴 수 없는 것일수록 뒤로 미루는 방식으로 정해 두면, 폐기는 논쟁이 아니라 지루한 절차가 됩니다. 그리고 그 지루함이야말로 목표입니다.
글의 핵심 개념을 형상화했습니다.
살아 있는 코드 한 줄이 매달 청구하는 비용
“이 코드는 그냥 거기 있을 뿐인데 무슨 비용이 드나요”라는 반문을 자주 듣습니다. 디스크는 싸고 서버 자원도 넉넉하니 틀린 말처럼 들립니다. 문제는 청구서가 인프라 요금이 아니라 사람의 시간으로 날아온다는 점입니다.
살아 있는 코드 경로 하나는 다섯 가지 비용을 매달 다시 청구합니다. 근처를 고치려는 사람이 이 코드의 정체를 파악하는 데 쓰는 읽기 비용, 빌드와 검증 파이프라인이 매번 태우는 테스트 시간, 인증이나 외부 호출이 걸린 경로마다 취약점 공지가 나올 때 다시 점검해야 하는 사고 표면, 프레임워크나 데이터베이스를 옮길 때 죽은 기능도 똑같이 이사시켜야 하는 마이그레이션 세금, 그리고 온보딩하는 사람이 “이건 왜 있어요”라고 물어도 아무도 확실히 답하지 못하는 인지 부하입니다.
앞의 네 가지는 측정할 수 있습니다. 파이프라인 시간, 리뷰에 걸린 시간, 취약점 대응 건수는 숫자로 남습니다. 마지막 인지 부하는 측정하기 어렵지만 이직 면담에서 반복해서 등장하는 항목입니다. 여기서 중요한 건 이 비용이 일회성 결제가 아니라 구독료라는 사실입니다. 기능을 만들 때는 한 번 값을 치르지만, 유지하는 동안은 매달 다시 냅니다. 팀이 지우기를 미루는 매 순간, 사실은 이 구독을 자동 갱신하고 있는 셈입니다.
“안 쓴다”는 말은 증거가 아닙니다
폐기 작업이 실패하는 가장 흔한 방식은 잘못 지우는 것이 아니라 영원히 논쟁만 하는 것입니다. “이거 안 쓰는 것 같은데요”와 “혹시 모르니 남겨 두죠”가 회의마다 반복됩니다. 두 진술 모두 증거가 없기 때문에 결론이 나지 않습니다. 감으로 시작한 논쟁은 감으로만 끝날 수 있습니다.
해법은 더 설득력 있는 발언이 아니라 증거의 등급을 미리 정해 두는 것입니다. 어떤 근거가 어느 등급에 해당하는지, 그리고 각 등급에서 무엇까지 할 수 있는지를 사전에 합의해 두면 회의는 “지울까 말까”를 다투는 자리가 아니라 “지금 몇 등급인가”를 확인하는 자리로 바뀝니다. 판정 기준이 바뀌지 않으니 같은 논쟁이 매번 재현되지 않습니다.
등급은 네 단계로 나눌 수 있습니다.
| 등급 | 근거 | 허용 조치 |
|---|---|---|
| E0 | 감과 기억뿐 | 계측 부착만 |
| E1 | 정적 참조 없음 | 격리와 예고 |
| E2 | 런타임 무호출 | 차단 실험 |
| E3 | 호출자 전수 확인 | 제거 |
E0은 아무 증거도 없는 상태입니다. 여기서 허용되는 유일한 행동은 계측을 붙이는 것입니다. 이 규칙 하나만 지켜도 사고의 상당수는 사라집니다. 감으로는 지우지 않겠다는 약속이니까요.
E1은 코드베이스 안에서 정적 분석, 라우팅 테이블, 빌드 산출물을 뒤져도 이 경로를 참조하는 곳이 없다는 확인입니다. 강력하지만 반쪽입니다. 리플렉션으로 호출되거나 문자열로 조립되는 경로, 설정 파일에 클래스 이름만 적혀 있는 경로, 외부에서 URL을 직접 때리는 엔드포인트는 정적 분석의 시야 밖에 있습니다.
E2는 실제 운영 환경에서 일정 기간 호출이 관측되지 않았다는 사실입니다. E1과 E2를 함께 확보하면 내부용 기능은 대부분 다음 단계로 넘어갈 준비가 끝납니다. E3은 남은 호출이 있는 경우에 필요한 등급으로, 호출자를 전부 식별했고 각각에게 대안이나 종료 합의가 있는 상태를 뜻합니다. 외부에 공개한 API를 지울 때는 반드시 여기까지 와야 합니다.
증거는 정적 분석, 런타임 관측, 사람과의 확인이라는 세 층에서 나옵니다. 한 층만 보고 판정하면 반드시 틀립니다. 정적 분석만 믿으면 리플렉션으로 살아 있는 경로를 놓치고, 런타임 로그만 믿으면 드물게만 호출되는 배치 작업이나 연간 결산용 경로를 죽은 코드로 오판합니다.
예를 들어 어떤 사내 리포트 생성 기능이 최근 석 달 동안 호출된 적이 없다고 해 봅시다. 정적 분석과 런타임 로그만 보면 E2 등급으로 보이고, 당장 지워도 될 것 같습니다. 그런데 이 기능이 회계연도 마감 때만 재무팀이 쓰는 경로라면, 석 달치 로그로는 절대 잡히지 않습니다. 사람과의 확인, 그러니까 실제로 이 기능을 만들었거나 담당했던 사람에게 물어보는 절차가 세 번째 층으로 필요한 이유입니다. 이 층을 건너뛰면 로그가 조용하다는 이유만으로 계절성 있는 기능을 지우는 사고가 반복됩니다.
순서를 지키지 않으면 완벽한 판정도 사고가 됩니다
증거가 E3까지 모였다고 바로 지워도 되는 건 아닙니다. 폐기 사고의 대부분은 판정이 틀려서가 아니라 순서가 틀려서 발생합니다. 코드를 먼저 지우고 데이터를 나중에 정리하면 되돌릴 수 없는 상태에 가장 먼저 도달하게 됩니다. 예고 없이 기능을 차단하면 기술적으로는 완벽한 작업이 사용자와의 신뢰 사고로 번집니다.
안전한 철거는 다섯 단계를 순서대로 밟습니다. 관측 단계에서 계측을 붙여 증거 등급 E2에 도달하고, 예고 단계에서 종료일을 통보하고 이의를 처리하며, 마찰 단계에서 경고나 지연을 추가해 잔여 사용이 줄어드는지 확인하고, 차단 단계에서 기능을 끄고 일정 기간 무사고를 확인한 뒤, 마지막 제거 단계에서 코드와 자원을 삭제하고 복구 창이 만료되기를 기다립니다.
각 단계에서 중요한 것은 일정이 아니라 다음 단계로 넘어가는 조건입니다. 조건 없이 날짜만 정해 두면 프로젝트 막바지에 그 날짜가 다가올 때 조건을 건너뛰고 일정에 맞추는 선택을 하게 됩니다. 그리고 되돌리기 계획은 관측 단계에서 미리 써 둬야 합니다. 어떤 커밋을 되돌리면 되는지, 어떤 플래그를 켜면 원상복구가 되는지, 데이터 백업이 어디 있는지를 나중에 급하게 찾으면 이미 늦은 경우가 많습니다.
예고는 절대 생략하지 않습니다. 예고문은 네 가지만 담으면 충분합니다. 무엇이 언제 사라지는지, 대신 무엇을 쓰면 되는지, 문제가 생기면 누구에게 말하면 되는지, 아무 조치도 하지 않으면 어떻게 되는지입니다. 예고 기간은 대상에 따라 달라져야 합니다. 내부 팀만 쓰는 기능이라면 2주에서 한 달, 사내 전체가 쓰는 도구라면 한 분기, 외부 고객이 붙은 API라면 최소 두 분기를 두고 계약 조건이 있다면 그 조건을 우선합니다. 그리고 예고를 문서에만 남기면 아무도 읽지 않는다는 사실도 함께 기억해야 합니다. 실제로 그 기능을 쓰는 채널에, 그 사람들이 보는 형태로 직접 알려야 합니다.
코드는 되돌릴 수 있지만 데이터와 계약은 아닙니다
코드는 되돌릴 수 있습니다. 커밋을 되돌리고 다시 배포하면 5분 안에 원래대로 돌아옵니다. 데이터는 다릅니다. 테이블을 드롭하면 백업이 있어야만 돌아오고, 백업 복원은 5분이 아니라 몇 시간짜리 작업입니다. 외부에 공개한 계약은 더 무겁습니다. 되돌리는 데 필요한 것이 우리 배포 주기가 아니라 상대 회사의 일정이기 때문입니다. 이것이 앞서 말한 철거 순서에서 데이터와 계약을 가장 뒤에 두는 이유입니다.
공개 API, 웹훅, 이벤트 토픽, 공유 뷰는 우리 코드베이스를 아무리 검색해도 판정할 수 없습니다. 호출자를 먼저 식별해야 합니다. 식별 가능한 축은 정확도 순으로 정리됩니다. 인증 정보, 그러니까 토큰이나 키나 클라이언트 식별자별 호출량이 가장 정확합니다. 그다음은 사용자 에이전트 문자열과 클라이언트 버전 헤더로, 정확하진 않지만 어떤 소프트웨어가 호출하는지 힌트를 줍니다. 출발지 주소 대역은 사내 호출인지 특정 파트너인지 구분하는 데 쓰이고, 계약서와 청구 기록에는 기술 지표에 잡히지 않는 사용자가 남아 있기도 합니다.
식별이 안 되는 호출이 남아 있다면 그 자체가 별도로 고쳐야 할 결함입니다. 이번 폐기 작업과 무관하게 인증 없이 열려 있는 경로에는 최소한의 식별을 붙여 두는 편이 다음 폐기 때 훨씬 유리합니다. 호출자 목록이 나오면 이전 완료, 이전 중, 연락 두절 세 칸으로 분류합니다. 마지막 칸이 가장 중요합니다. 연락이 닿지 않는 호출자에게는 앞 단계에서 다룬 마찰, 즉 한도를 낮추고 지연을 넣는 조치가 사실상 유일하게 남은 소통 수단입니다. 실제로 한도를 낮추면 며칠 안에 담당자로부터 연락이 오는 경우가 많습니다.
버전이 있는 API라면 절차는 단순합니다. 새 버전을 내고, 구 버전에 종료일을 붙이고, 그날 끄면 됩니다. 문제는 대부분의 내부 API가 버전 없이 만들어진다는 점입니다. 버전이 없어도 응답에 종료 안내 헤더를 넣고, 로그에서 그 헤더를 받고도 여전히 호출하는 클라이언트를 추적하는 방식으로 사실상의 버전 전환을 흉내 낼 수 있습니다.
폐기를 습관으로 만들면 대청소가 필요 없어집니다
여기까지의 절차를 잘 따르면 기능 하나는 깨끗하게 사라집니다. 그런데 다음 분기에 새 기능 열두 개가 들어오고 그중 몇 개는 다시 아무도 안 쓰게 됩니다. 한 번의 대청소로는 절대 이길 수 없는 게임입니다. 여기서 초점이 개별 폐기에서 폐기율로 옮겨 갑니다. 만드는 속도보다 정리하는 속도가 느리면 부채는 계속 쌓입니다. 목표는 두 속도를 비슷하게 맞추는 것입니다.
가장 효과가 큰 습관은 새로 만드는 것에 처음부터 종료 조건을 붙이는 것입니다. 실험용 기능 플래그에는 만료일을 필수로 넣어, 만료일이 지나면 파이프라인이 경고하거나 실패하게 만듭니다. 임시 우회 코드의 제거 조건은 주석이 아니라 이슈로 남깁니다. 주석은 아무도 검색하지 않지만 이슈는 백로그에 남아 다시 눈에 띄기 때문입니다. 새로 만드는 API에는 처음부터 버전을 붙입니다. 버전 없이 시작한 계약은 나중에 종료할 절차 자체가 없습니다. 파일럿과 시범 서비스에는 종료일과 함께 이 조건을 못 채우면 접는다는 문장을 문서에 명시적으로 적어 둡니다.
핵심은 나중에 판단하겠다는 약속이 아니라, 아무도 손대지 않아도 자동으로 사라지는 구조를 만드는 것입니다. 사람의 의지에 기대는 정리는 언제나 다른 우선순위에 밀립니다. 열려 있는 기능 플래그 수는 특히 잘 드러나는 지표입니다. 그 수가 계속 늘어나고 있다면 실험은 이미 끝났는데 플래그만 남아 코드 안에서 두 갈래 분기를 영원히 유지하는 상태가 조용히 쌓이고 있다는 신호입니다.
폐기 작업을 우선순위 회의에서 새 기능과 경쟁시켜 이기게 만들려고 애쓸 필요는 없습니다. 애초에 경쟁시키지 않는 편이 낫습니다. 스프린트 용량의 일정 비율을 폐기에 고정 배정하거나, 분기마다 폐기 목표를 두세 개 정해 다른 목표와 같은 지위로 관리하는 방식이 실무에서 자주 쓰입니다. 정확한 비율은 팀마다 다르지만, 별도 예산으로 떼어 둔다는 원칙 자체가 새 기능 대비 늘 밀리는 구조를 끊어 냅니다.
이 예산은 성과 지표로도 남겨야 오래갑니다. 이번 분기에 지운 코드 줄 수, 닫은 기능 플래그 수, 종료한 내부 API 수를 새 기능 출시 지표와 나란히 대시보드에 올려 두면, 폐기는 눈에 안 띄는 뒷정리가 아니라 눈에 보이는 성과가 됩니다. 반대로 이 숫자를 아무도 안 보면, 아무리 좋은 절차를 문서로 만들어 둬도 다음 분기 스프린트 계획 회의에서 결국 새 기능에 밀립니다.
지우는 일이 어려운 이유는 결국 판정 기준과 실행 순서가 정해져 있지 않기 때문입니다. 증거 등급을 미리 고정해 두면 논쟁이 짧아지고, 되돌릴 수 없는 것을 뒤로 미루는 순서를 지키면 완벽한 판정이 사고로 번지지 않으며, 종료 조건을 처음부터 붙이는 습관을 들이면 다음 대청소가 필요 없어집니다. 이 절차를 표와 체크리스트로 더 자세히 다듬어 둔 전자책도 함께 준비했습니다.
참고문헌
- 버전 없는 API에 붙이는 종료 안내 헤더는 IETF 표준으로 정의돼 있습니다. RFC 8594, “The Sunset HTTP Header Field”. https://www.rfc-editor.org/rfc/rfc8594
- 기능 플래그에 만료일을 붙이고 열린 플래그 수를 재고처럼 관리하는 관행의 원전입니다. Martin Fowler, “Feature Toggles (aka Feature Flags)”. https://martinfowler.com/articles/feature-toggles.html