기능 하나 빼는 데 4시간이 들었습니다 — 도메인 제거의 도미노

"이번 프로젝트 범위 아님" 한 줄로 시작된 사건

B2B SaaS 리팩토링 회의에서 짧은 결정이 하나 있었습니다.

"이 집계 기능은 이번 프로젝트 범위 아닙니다."

기획자가 한 줄로 정리한 결정이었습니다. 회의는 1분도 안 걸렸고, 다음 안건으로 넘어갔습니다. 코드 한두 군데 손보면 되는 가벼운 작업으로 다들 생각했습니다.

실제 작업을 시작하자 그림이 달라졌습니다. 그 집계 기능이 또 다른 도메인의 입력값이었던 것입니다. 집계 결과가 다음 단계 계산의 기준이 되는 구조였어요. 입력이 없어지면 계산도 의미를 잃습니다.

결과적으로 작업은 한 군데에 머물지 않았습니다. 4단계 연쇄 작업, 4개 클라이언트 앱, 백엔드, DB, 문서, 배치 스케줄러까지 번졌고 총 230분(3.8시간)이 걸렸습니다.

도메인 제거의 도미노 — 4단계 연쇄

작업을 시간 순으로 정리하면 이렇습니다.

1단계 (90분) — 집계 기능 자체 제거

화면에서 집계 정보를 빼는 일부터 시작했습니다. 그런데 이 화면이 4개 클라이언트(관리자 웹, 협력사 웹, 디자인 목업, 모바일 매니저 앱)에 모두 노출되고 있었습니다. 백엔드 API도 제거 대상, DB 컬럼·테이블도 제거 대상이었습니다. 같은 정보가 여러 표면에 노출되어 있다는 사실이 작업 단계마다 드러났습니다.

2단계 (60분) — 의존 도메인 통째 제거

집계 결과를 기준으로 계산하던 보조 도메인이 의미를 잃었습니다. 입력이 사라지면 계산할 게 없어지니까요. 보조 도메인을 통째로 제거하는 작업이 따라왔습니다. 백엔드 패키지 삭제 + 12개 파일의 wildcard import 정리 + 관련 DDL DROP까지 포함됐습니다.

3단계 (30분) — 문서의 잔존 흔적 정리

요구사항 문서, 화면 설계서, 정책 문서에 흩어져 있던 잔존 흔적을 정리했습니다. 5개 파일 삭제 + 12건 이상 갱신이었습니다. 문서가 코드와 동기화되지 않으면 다음 사람이 혼란스러워집니다.

4단계 (20분) — 배치 스케줄러 재정리

자동 생성 배치 작업도 후보에서 탈락시켰습니다. 21개 후보 중 8개 채택, 나머지는 자연 탈락이었습니다. 이번에 제거된 도메인 관련 배치는 자동으로 후보에서 빠졌습니다.

각 단계는 독립적인 작업처럼 보였지만, 사실 하나의 결정에서 출발한 같은 사건이었습니다. 시간 순으로 일어난 게 아니라, 1단계 작업이 2단계 필요성을 드러내고, 2단계가 3단계를 드러내고, 다시 4단계까지 이어졌습니다.

도미노가 시작된 이유 — 도메인 간 의존이 강했다

이번 사건에서 작업이 도미노처럼 번진 본질적 이유가 있었습니다. 도메인 간 의존이 강했기 때문입니다.

집계 도메인은 단독으로 존재하지 않았습니다. 보조 도메인의 입력값이었어요. 마치 식재료가 빠지면 요리가 의미를 잃듯, 입력이 없어진 도메인은 자동으로 의미를 상실합니다. 이걸 그림으로 그리면 이렇게 됩니다.

[집계 도메인] → [보조 도메인] → [화면·API·배치]
   (입력)        (계산)         (소비)

집계 도메인 하나만 빼려고 했는데, 의존 체인을 따라 보조 도메인과 그 위의 소비 지점들이 줄줄이 영향을 받았습니다. 빼는 작업의 비용은 의존 깊이에 비례합니다.

흥미로운 부분은 같은 시스템 안에서도 의존 강도가 도메인마다 달랐다는 점입니다. 식단 도메인의 "예상 집계량" 필드는 보존했습니다. 이름은 비슷한데 의존 관계가 달랐어요. 식단 도메인은 독립적으로 운영되고 있어서 집계 기능이 빠져도 영향을 받지 않았습니다.

이 차이를 사전에 파악하지 못하면 빼지 말아야 할 것까지 빼는 사고가 발생할 수 있습니다. 그래서 제거 작업 전에 의존 그래프를 그려보는 게 중요합니다.

보존과 정리의 기준 — 시점 스냅샷 vs 현재 정책

이 작업에서 한 가지 결정한 기준이 있었습니다. 모든 것을 다 지우지 않은 것입니다.

지운 것과 남긴 것을 분류하면 이렇습니다.

핵심은 "시점 스냅샷"과 "현재 정책"을 구분한 것입니다.

과거의 계획서나 분석 노트는 그 시점의 의사결정 기록이에요. 지금 시스템에서 빠진 기능이라도, 왜 그 시점에 그 기능을 만들었고 어떤 분석으로 빠지게 됐는지가 미래의 의사결정에 도움이 됩니다. 그래서 보존했어요.

반면 현재 요구사항 문서와 정책 문서는 다릅니다. 이건 "지금 시스템이 어떻게 동작하는가"를 설명하는 문서예요. 이미 빠진 기능에 대한 설명이 남아 있으면 새로 들어온 사람이 혼란스러워집니다. 갱신 또는 삭제 대상이에요.

이 구분이 빠르게 안 되면 "전부 정리" vs "전부 보존" 양극단에 빠집니다. 전부 정리하면 의사결정 히스토리를 잃고, 전부 보존하면 현재 시스템 이해가 어려워져요.

의사결정자가 점검할 4가지 — 범위 결정의 무게

이 사건에서 나온 일반 원칙을 의사결정 관점에서 정리하면 네 가지가 됩니다. 프로젝트 범위 결정·견적 산정·일정 산출 시 활용하시면 됩니다.

1. 추가와 제거는 무게가 다릅니다

"이 기능 추가"와 "이 기능 제거"는 견적 단위가 다릅니다. 추가는 새 코드 라인이 늘어나는 선형 작업이지만, 제거는 의존 관계를 따라 도미노로 번지는 비선형 작업입니다. 견적 산정 시 제거 작업의 비용을 추가 작업과 같은 잣대로 보면 일정이 무너집니다.

2. 도메인 의존 강도를 사전에 파악해야 합니다

"이 기능 빼면 되겠지?"로 시작하면 작업 중간에 새 의존이 계속 발견됩니다. 시작 전에 의존 그래프를 그려보면 영향 범위가 미리 보입니다. ERD, 패키지 의존도, API 호출 관계, 배치 스케줄러를 한 번 둘러보는 게 30분 투자로 4시간 손실을 막을 수 있습니다.

3. 영향 범위를 다축으로 점검해야 합니다

코드만 보면 안 됩니다. 코드 + DDL + API + 문서 + 배치 스케줄러 5개 축을 모두 봐야 합니다. 한 축만 정리하면 다른 축에서 잔존 흔적이 남아 다음 작업자가 혼란을 겪습니다.

4. 보존과 정리의 기준이 명시되어야 합니다

"전부 삭제" 또는 "전부 보존"의 양극단을 피하려면 기준이 필요합니다. 시점 스냅샷(과거 계획·분석)은 보존, 현재 정책 문서는 정리. 이 구분을 팀 내에서 합의해두면 정리 작업이 빨라집니다.

비슷한 발상이 다른 운영 작업에서도 흐릅니다. 변경의 영향이 한 군데에 머무는 게 아니라 다축으로 번진다는 점, 그 다축을 사전에 명시해야 사고를 막을 수 있다는 점. 운영 시스템의 변경을 다루는 시야입니다.

마무리

"이 기능은 이번 프로젝트 범위 아님"이라는 한 줄 결정이 4단계 연쇄 작업, 4개 클라이언트, 백엔드, DB, 문서, 배치 스케줄러까지 번졌습니다. 총 230분이 걸렸고, 이 시간은 의존 관계의 깊이에서 나왔습니다.

핵심 교훈은 세 가지입니다.

추가와 제거의 비용은 비대칭이다 — 추가는 선형, 제거는 의존 깊이에 비례하는 비선형 작업

도메인 의존 그래프를 사전에 파악해야 한다 — 시작 전 30분 투자로 작업 중 발견되는 새 의존을 줄일 수 있음

보존과 정리의 기준이 명시되어야 한다 — 시점 스냅샷은 보존, 현재 정책은 정리. 이 구분이 없으면 양극단에 빠짐

프로젝트 범위 결정·견적 산정·리팩토링 일정 산출을 다루신다면, 이번 글의 4가지 체크리스트(추가/제거 비대칭, 의존 강도 사전 파악, 다축 영향 점검, 보존/정리 기준 명시)를 한 번 확인해보시길 추천합니다. 한 줄 결정의 무게가 다르게 보입니다.