안 쓰는 개념 하나 지우는 일인 줄 알았습니다 — DB 컬럼 DROP까지 갔습니다

이제 안 쓴다는 한마디로 시작했습니다

프랜차이즈 ERP를 운영하고 있습니다. 품목 마스터에는 물류 매입 기준으로 쓰이던 플래그가 하나 있었습니다. 며칠 전 역할이 비슷한 개념을 새로 도입했고, 담당자가 회의에서 짧게 정리했습니다. 옛 개념은 이제 안 쓴다는 결정이었습니다.

처음엔 지우는 커밋 하나로 끝날 일로 봤습니다. 실제로 손을 대보니 화면·엑셀·쿼리·DB까지 손댈 지점이 열 갈래로 갈라졌습니다. 그리고 그 개념 위에 얹혀 있던 지표 하나가 함께 사라진다는 사실이 작업 중간에 드러났습니다.

사용자가 먼저 겪는 불편은 이게 뭐냐는 질문입니다

반쯤 남은 개념의 비용은 사용자 쪽에서 먼저 나타납니다. 화면에 토글이 하나 남아 있고 아무도 켜지 않습니다. 엑셀을 내리면 늘 빈 열이 몇 개 붙어 옵니다. 새로 온 담당자는 그 열을 보고 무엇을 채워야 하는지 묻고, 그때마다 예전 개념인데 지금은 안 쓴다는 설명을 반복하게 됩니다.

운영 쪽 비용은 그 다음입니다. 컬럼이 남아 있으면 쿼리가 남고, 쿼리가 남으면 분기 코드와 동기화 목록이 남습니다. 다음 사람은 살아 있는 코드를 근거로 그 개념이 살아 있다고 읽습니다. 없는 개념보다 반쯤 있는 개념이 더 비쌉니다.

안 쓴다는 말을 먼저 숫자로 확인했습니다

폐기 결정을 들었을 때 먼저 한 일은 코드 검색이 아니라 건수 조회였습니다. 옛 개념으로 지정된 데이터는 16건이었고, 한동안 손대지 않은 방치 상태였습니다. 역할을 이어받은 새 개념은 295건이 실제로 관리되고 있었습니다.

이 두 숫자가 판단을 한 번에 정리했습니다. 16건은 안 쓴다는 말이 사실이라는 근거이고, 295건은 개념을 지워도 업무가 비지 않는다는 근거입니다. 승계가 실측으로 확인되지 않으면 그건 폐기가 아니라 기능 삭제입니다. 옛 경로를 끊기 전에 신·구 결과가 같은지 맞춰보는 절차와 성격이 같습니다.

폐기에도 설계가 필요하다

폐기에도 설계가 필요하다. 기능을 추가할 때는 설계 문서를 쓰고 리뷰를 받는데, 없앨 때는 그냥 지웁니다. 파급 범위만 보면 없애는 쪽이 오히려 넓습니다. 추가는 새 경로를 하나 여는 일이고, 폐기는 이미 여러 계층에 뿌리내린 것을 전부 끊어내는 일입니다.

건물에 방 하나를 붙이는 일과 기둥 하나를 빼는 일의 차이에 가깝습니다. 방을 붙이면 영향은 그 방 주변에서 끝납니다. 기둥을 빼면 위층 하중과 배관 경로, 도면까지 다시 봐야 합니다. 개념도 같습니다. 그 위에 얹힌 필터·엑셀 열·리포트·지표가 전부 같은 기둥에 매달려 있습니다.

그래서 지우기 전에 세 가지 옵션을 놓고 비용을 비교했습니다.

세 번째를 골랐습니다. 앞의 두 옵션은 지금 작업을 줄이고 다음 사람의 시간을 늘리는 선택입니다.

화면에서 컬럼까지, 한 번에 끊었습니다

제거 범위를 먼저 목록으로 만들고 순서대로 내려갔습니다. 실제로 손댄 계층은 이렇습니다.

품목관리 화면의 컬럼·토글·필터

물류매입 화면의 관련 컬럼 2개, 드릴 팝업, 지정 다이얼로그

전기비교 화면의 매입 기준 토글

엑셀 내려받기 7개 열

백엔드 전용 쿼리 6개와 분기 코드, 동기화 목록

DB 컬럼 DROP

순서가 중요합니다. 화면부터 지우고 마지막에 컬럼을 떨어뜨려야, 중간에 멈춰도 사용자에게 깨진 화면이 남지 않습니다. 반대로 컬럼을 먼저 지우면 아직 남아 있는 쿼리가 전부 에러로 바뀝니다. 컬럼을 건드리기 전에 참조 지점 전수조사를 먼저 하는 이유도 같습니다.

정리하면서 알게 된 것이 하나 있습니다. 선택지가 하나 남은 토글은 토글이 아닙니다. 전기비교 화면에는 매입 기준을 고르는 토글이 있었는데, 옛 기준이 빠지면서 선택지가 하나만 남았습니다. 그대로 두면 사용자는 아직 고를 수 있다고 읽습니다. 토글을 없애고 기준을 고정 표기로 바꿨습니다.

백업 없이 컬럼을 지운 판단, 그리고 남긴 것

컬럼은 백업 없이 DROP했습니다. 방치된 16건은 복구 가치가 없다고 판단했습니다. 혹시 몰라 남겨두는 쪽이 아니라, 근거를 대고 버리는 쪽을 택했습니다. 대신 그 판단을 기록으로 남겼습니다. 몇 건이었는지, 왜 복구 가치가 없다고 봤는지, 누가 그 결정을 승인했는지까지.

백업 없는 삭제에서 정말로 남겨야 하는 것은 데이터가 아니라 판단 근거입니다. 데이터는 다시 못 만들어도 판단은 다시 검증할 수 있습니다.

다만 이 판단이 통한 이유는 대상이 내부 운영 플래그였기 때문입니다. 규제·감사 대상 데이터라면 같은 결론이 나오지 않습니다. 외부 API 사용처나 엑셀 수신자가 있는 개념이면 전면 제거 전에 소비처 공지와 유예 기간이 먼저입니다.

함께 사라지는 지표를 문서에 박았습니다

이 개념 위에 지표 하나가 얹혀 있었습니다. 자기 브랜드의 해당 품목 발주가 0이면 본사를 거치지 않은 사입으로 의심하는 적발 지표였습니다. 개념이 사라지면 그 지표도 같이 사라집니다.

개념이 죽으면 그 위의 지표도 죽습니다. 이걸 말하지 않으면 폐기가 아니라 은폐입니다. 그래서 폐기 문서에 사라지는 파생물을 목록으로 적고 이해관계자에게 명시했습니다. 새 개념 기준의 미주문 표시가 다른 화면에 남아 있다는 사실도 같이 적었습니다. 승계 개념이 역할을 정말 대체하는지의 확인이 폐기의 보험이었습니다.

되돌릴 수 있게 만든 장치는 백업이 아니라 재도입 가이드였습니다. 문서에 이렇게 적었습니다.

이 지표가 다시 필요해지면 새 개념 기준으로 재설계할 것. 옛 기준을 되살리지 말 것 — 방치된 데이터라 숫자를 신뢰할 수 없다.

폐기 직후에 역시 필요했다는 말이 나오는 것은 흔한 일이고, 그때 첫 반응은 옛것을 복원하는 것입니다. 방치됐던 데이터를 기준으로 복원하면 신뢰할 수 없는 숫자가 되살아나 그 위에 판단이 다시 쌓입니다. 무엇을 기준으로 다시 만들지를 지금 적어두는 것이 유일한 복원 장치였습니다.

문서 쪽도 같이 정리했습니다. 도메인 요구사항 문서에 「폐기」 절을 새로 만들고, 관련 설계 문서와 프로젝트 규칙을 갱신했습니다. 폐기는 삭제 이력이 아니라 결정 이력이므로 도메인 이력에 남습니다.

개념을 지우기 전 점검 항목

안 쓴다는 말을 건수로 확인했는가 — 폐기 대상의 방치 건수와 승계 개념의 활성 건수를 같이 재본다

제거 범위를 화면·엑셀·API·쿼리·분기 코드·DB 컬럼까지 목록으로 만들었는가

함께 사라지는 지표·알람·리포트를 목록화해 이해관계자에게 알렸는가

백업 없이 지운다면 그 판단 근거를 문서로 남겼는가

재도입이 필요해질 때 무엇을 기준으로 다시 만들지 적었는가

외부 소비처가 있다면 공지와 유예 기간을 먼저 잡았는가

지운 이유와 복원 조건까지가 작업 범위입니다

이번 작업이 끝난 뒤 코드와 DB, 문서에서 그 개념은 일관되게 사라졌습니다. 남은 것은 왜 없앴고 되살릴 때는 무엇을 기준으로 하라는 기록뿐입니다. 매입 기준은 승계 개념 하나로 정리됐고, 화면에서 고를 것이 없어진 토글도 함께 없어졌습니다.

삭제 커밋을 올린 시점이 아니라 지운 이유와 복원 조건을 문서에 남긴 시점이 폐기 작업의 끝입니다. 개념 하나를 없애는 결정을 받았다면 작업 범위에 문서 한 절을 미리 넣어두는 편이 낫습니다. 그 절이 없으면 반년 뒤에 같은 개념이 옛 기준 그대로 되살아납니다.