검색 화면 하나를 지우면서 파일 36개를 건드렸다

이 시스템에는 검색 화면이 둘 있었습니다. 통합검색(/std-data/search/)과 표준데이터 목록(/std-data/dataset/).

통합검색은 탭 넷(전체·표준데이터·메타데이터·OID)으로 나뉜 화면이었고, 표준데이터 목록은 분류 칩과 필터가 붙으면서 점점 검색 화면 노릇을 하게 됐습니다. 기능 목록의 검색 관련 메뉴 셋(단어·필터·계층)이 어느 화면에 해당하는지 물었더니 결국 셋 다 표준데이터 목록 한 화면이었어요.

두 화면이 같은 일을 하는 상태에서 하나를 유지하는 비용은 계속 나갑니다. 인스턴스 기반으로 모델을 바꿀 때도 통합검색을 거기 맞추는 작업이 따로 있었고요.

걷어냈습니다. 36개 파일, 105줄 추가 2102줄 삭제.

어떻게 걷을 것인가

방법	장점	포기하는 것	판단
① URL만 막고 코드는 남김	되살리기 쉬움	죽은 코드가 계속 빌드·테스트·`grep`에 잡힘. "언젠가"의 근거가 없음	기각
② 메뉴에서 숨기고 주소로는 접근 가능	변경 최소	링크가 남고 문서가 계속 그 화면을 설명함	기각
③ 뷰·URL·템플릿·JS·테스트·매니저 메서드·문서 진입점까지 한 커밋에 삭제	남은 게 없음. 다음 사람이 헷갈릴 자리가 없음	커밋이 커서 회귀 시 범위가 넓음	채택
④ ③ + 검색어 로그의 경로 접두사까지 정리	정말 흔적 0	이미 쌓인 집계가 사라짐 — 워드클라우드 숫자가 줄어듦	기각

②가 제일 흔한 선택인데, 이 블로그에 화면이 없어진 기능을 설명하고 있었다를 3주 전에 썼습니다. 서비스 소개가 이미 삭제된 필터를 설명하고 있던 이야기예요. 같은 실수를 또 하지 않으려고 이번엔 안내 문구와 진입 경로를 같은 커밋에서 지웠습니다.

호출자가 테스트만 남은 매니저 메서드

지우면서 매니저 메서드도 같이 걷었습니다.

매니저	삭제한 메서드
`ConceptManager`	`search()`
`MetaClassPropertyManager`	`search()`
`ObjectIdentifierManager`	`search()`
`DatasetManager`	`search()` · `search_detail()` · `search_metadata()`

통합검색이 유일한 소비자라서, 화면을 지우고 나니 호출자가 테스트만 남았습니다.

이게 죽은 코드를 판별하는 꽤 확실한 신호더군요. 프로덕션 호출자가 0이고 테스트만 그 함수를 부르고 있으면, 그 테스트는 기능을 지키는 게 아니라 함수의 존재를 지키고 있는 겁니다. 커버리지는 초록인데 아무도 안 씁니다.

DatasetManager에서만 78줄이 빠졌고, search.py 뷰가 429줄, 템플릿이 1073줄이었습니다.

3줄짜리 껍데기를 지우면서 알맹이는 남겼다

여기서 한 번 멈췄습니다.

⚠️ `ObjectIdentifierManager._apply_search_filter()` 는 남겨야 합니다. 지운 `search()` 는
이걸 감싼 3줄짜리 껍데기였고, 알맹이인 `_apply_search_filter()` 는 OID 검색 화면
(`/std-data/oid/main/`)이 `get_list_queryset()`·`find_first_match()` 를 통해 지금도 씁니다.

search()를 지우려고 열어 보니 안에 실제 로직이 있는 게 아니라 _apply_search_filter()를 감싸고 있었습니다. 그 알맹이는 다른 화면이 다른 경로로 지금도 씁니다.

이름이 비슷하다고 같이 지웠으면 OID 검색이 조용히 죽었을 겁니다. search()를 지운다고 _apply_search_filter()도 지울 이유가 없는데, 두 함수가 이름과 파일을 공유하고 있어서 한 덩어리로 보였어요.

테스트도 남겼습니다.

점 표기·URN 매칭 테스트(`test_oid_search.py`)도 지우지 않고 `get_list_queryset()` 으로
호출부만 옮겼습니다 — 통합 검색과 무관한 살아 있는 로직의 유일한 검증이라서입니다.

앞 절에서 "테스트만 부르는 함수는 죽은 코드"라고 했는데, 여기는 반대입니다. 함수는 살아 있고 테스트가 그 함수를 옛 이름으로 부르고 있었을 뿐이에요. 두 경우를 가르는 건 "프로덕션 호출자가 있느냐"지 "테스트가 부르느냐"가 아닙니다.

지워진 화면이 남긴 기록은 세야 한다

④를 기각한 이유입니다.

이 시스템의 워드클라우드는 검색어 방문 기록으로 그립니다. 어떤 경로가 검색 화면인지를 접두사 목록으로 판별하는데, 거기에 /std-data/search/가 들어 있었어요.

STD_DATA_PATH_PREFIXES = (
    "/std-data/catalog/",
    "/std-data/scheme/",
    "/std-data/concept/",
    # 폐지된 통합검색. 새로 쌓이지는 않지만 이미 남은 기록을 집계에서 떨어뜨리지 않으려고 둔다.
    "/std-data/search/",
)

지우면 깔끔한데, 지우는 순간 그 화면에서 검색한 과거 기록이 집계에서 빠집니다. 워드클라우드 숫자가 이유 없이 줄어들고, 왜 줄었는지는 아무도 모릅니다.

화면은 없어져도 그 화면이 남긴 데이터는 남습니다. 코드를 지우는 범위와 데이터를 지우는 범위는 다릅니다 — 용어 치환 때 코드 경계에서 멈춘 것과 같은 이야기인데, 그때는 데이터를 못 바꿔서 남긴 거고 이번엔 남기려고 남겼어요.

같은 이유로 워드클라우드 샘플 적재 명령의 링크 목적지만 새 검색 화면으로 바꿨습니다. 단어를 눌렀을 때 404로 가면 안 되니까요.

문서와 라우팅을 잇는 다리

기능 목록 문서에는 여전히 /std-data/search/가 적혀 있습니다. 발주 문서라 임의로 못 고쳐요.

그 문서를 읽어 화면을 도는 메뉴 QA 스윕이 있는데, 거기에 매핑 한 줄을 뒀습니다 — URL_FIXES가 /std-data/search/를 /std-data/dataset/로 넘깁니다.

문서와 구현이 갈릴 때 어느 쪽도 못 고치면 그 사이를 잇는 표를 만드는 수밖에 없습니다. 다만 이건 부채라 표에 줄이 쌓이는 만큼 문서와 구현의 거리가 멀어집니다.

검증

/std-data/search/가 404인 것 확인. 302도 200도 아닌 404여야 지웠다는 뜻이 됩니다.
서비스 소개·이용안내·OID 안내에서 통합검색 진입 경로가 사라진 것 확인. 문구만 지우고 링크를 남기는 실수를 3주 전에 했습니다.
메뉴 QA 스윕이 URL_FIXES를 타고 표준데이터 목록으로 넘어가는 것 확인.
OID 검색 화면(/std-data/oid/main/)에서 점 표기·URN 매칭이 그대로 되는 것 확인 — _apply_search_filter()를 같이 지웠다면 여기가 죽습니다.
워드클라우드 집계에서 과거 통합검색 기록이 여전히 세어지는 것 확인.
남은 테스트 전량 통과. 삭제한 143줄짜리 뷰 테스트와 e2e 2건은 지킬 대상이 없어져 같이 지웠습니다.

남은 것 · 한계

한 커밋에 36개 파일이라 회귀가 나면 이분 탐색이 안 됩니다. 전부 지우는 쪽을 골랐으니 감수한 대가인데, Tailwind 전환에서도 같은 선택을 했습니다. 이 프로젝트는 "원천을 둘로 두지 않는다"를 "커밋을 크게 만든다"로 계속 갚고 있어요.
_batch_counts 배치 COUNT 최적화도 같이 사라졌습니다. 탭마다 건수를 세는 걸 한 번에 묶던 코드인데, 통합검색 전용이라 함께 지웠습니다. 비슷한 게 필요해지면 다시 짜야 하고, 지웠다는 사실은 문서의 "같이 없어진 것" 목록에만 있습니다.
검색어 로그의 /std-data/search/ 접두사는 영원히 남는 코드입니다. 언제 지울지 조건을 안 정했어요. 과거 기록이 의미 없어지는 시점이 있을 텐데 그걸 판단할 기준이 없습니다.
URL_FIXES 표가 부채입니다. 문서와 구현이 갈릴 때마다 줄이 하나씩 늘고, 그 표를 읽어야 실제 라우팅을 알 수 있게 됩니다. 지금은 한 줄이라 괜찮은데 늘어나는 걸 막을 장치가 없습니다.
되살릴 근거는 git 이력뿐입니다. 문서에 "왜 지웠나"와 "같이 없어진 것"은 남겼지만, 그 화면이 어떻게 생겼는지는 안 남았어요. 되살릴 일이 없다고 보고 안 남긴 건데, 그 판단이 틀리면 2102줄을 이력에서 파내야 합니다.