6개월 운영 후 Tag 시스템을 완전 폐기했습니다 — 데이터가 말한 결정
"한 도메인은 44%, 나머지는 0%였습니다"
운영 중인 PM 도구의 Tag 시스템을 도입한 지 6개월이 됐을 때, 사용률 데이터를 다시 봤습니다. 결과는 명확했어요.
한 도메인 노드 타입: 44% 사용률
나머지 모든 도메인 노드 타입: 0%
처음 도입할 때는 "분류가 있으면 조회·필터·시각화에 좋겠지" 하는 기대가 있었습니다. 그런데 6개월 운영 데이터가 보여준 건 다른 그림이었어요. 거의 안 쓰이고 있었습니다.
이 시점에서 두 가지 길이 있었어요.
"조금 더 운영해보면 자리잡지 않을까" — 보존
"데이터가 명확하니 폐기" — 완전 제거
선택은 완전 제거였습니다. 그리고 그 결정 과정에서 한 가지 일반 원칙이 드러났어요. 운영 데이터가 도구 폐기를 정당화한다는 것입니다.
이번 글은 그 폐기 결정의 5가지 사유, 3가지 옵션 비교, 그리고 재도입 조건을 정책에 박아둔 이유까지 정리한 회고입니다.
5가지 폐기 사유 — 데이터가 모두 같은 방향을 가리켰습니다
폐기 결정에 다섯 가지 사유가 모였습니다. 각 사유가 독립적으로 강한 게 아니라, 다섯 가지가 한 방향을 가리킨 게 결정의 무게를 만들었어요.
1. 실효성 입증 실패
한 도메인 노드 타입에서만 44% 사용, 나머지 모든 타입에서 0%. 6개월간의 자연스러운 사용 패턴이었어요. "사용자가 도입 안 했을 뿐"이라는 변명이 안 되는 상태였습니다. 본인이 사용자였고, 본인이 안 썼습니다.
2. 컨텍스트 부적합
원래 Tag 시스템은 팀 규모가 크고, 분류 거버넌스가 있고, 사용자별 관점이 다양한 환경에서 가치를 만듭니다. 1인 풀스택 운영 + 풍부한 본문 작성 환경에서는 분류 도구의 가치가 약했어요. 도입 시점에는 이 컨텍스트 판단을 못 했고, 6개월 운영해보니 명확해졌습니다.
3. 현대 검색 패러다임
분류 시스템은 검색이 약하던 시대의 해법입니다. 풀텍스트 검색·자연어 검색·시맨틱 검색이 발달한 환경에서는 분류보다 검색이 효율적이에요. "어디 있더라" 하면서 분류 트리 탐색하는 것보다 키워드로 검색하는 게 빠릅니다.
4. 작성-조회 비대칭
분류 시스템의 본질적 문제입니다. 작성할 때마다 "이건 어디에 분류하지?" 부담이 생기는데, 조회할 때 그 분류를 쓰는 빈도는 낮아요. 매번 분류 부담 > 가끔 조회 가치라는 비대칭이 누적되면 사용자가 분류를 포기합니다.
5. 노이즈
UI에 Tag 입력 자리가 남아 있으면 사용자가 "이걸 채워야 하나?"라고 추론합니다. 어설프게 남기면 "쓸 수 있다"는 착각을 유발해서, 실제로는 안 쓰면서도 매번 신경 쓰게 만들어요. 결정을 미루는 상태 자체가 비용이었습니다.
다섯 가지 사유가 다 같은 방향을 가리켰을 때 결정에 망설임이 없었어요.
3가지 옵션의 트레이드오프
폐기 결정 후 "어떻게 폐기할지"가 또 다른 결정이었습니다. 세 가지 옵션이 있었어요.
옵션 | 동작 | 트레이드오프 |
|---|---|---|
A. UI만 숨기기 | 화면에서 안 보이게 처리 | 코드·DB 잔존, 미묘한 noise |
B. 깊이 비활성화 | UI·생성 흐름만 제거, 백엔드·DB 유지 | 잔존 코드 부담, 향후 재활성화 유혹 |
C. 완전 제거 | 정책·코드·DB·UI 전부 삭제 | 작업 범위 큼, 재도입 시 처음부터 |
선택은 옵션 C — 완전 제거였습니다. 이유는 두 가지였어요.
첫째, 어설프게 남기는 비용이 가장 큰 함정이었어요. UI만 숨기면 백엔드 인프라가 잔존해서 6개월 뒤 누군가 "이게 뭐지?" 하고 다시 활성화하려고 시도할 위험이 있습니다. 옛 Tag 데이터도 그대로 남아서 마이그레이션 부담이 누적돼요.
둘째, 1인 운영이라 컴파일·테스트 부담이 작았어요. 팀 규모면 옵션 B가 안전할 수 있지만, 1인이면 완전 제거의 영향 범위가 통제 가능했습니다.
일괄 제거 범위
전 계층 제거를 한 번에 진행했어요.
백엔드: 5개 파일 삭제 + 4개 파일 수정 (DTO·서비스·컨트롤러 의존성 제거)
프론트엔드: 컴포넌트·페이지 삭제 + 4개 파일 정리
DB: Tag 노드 20개 + tagged 관계 일괄 삭제
코드와 데이터를 한 묶음으로 처리하는 게 핵심이었습니다. 코드만 지우고 데이터를 남기면 미래에 또 헷갈리고, 데이터만 지우고 코드를 남기면 죽은 코드가 됩니다.
재도입 조건을 정책에 박아둔 이유
이번 폐기에서 특별했던 부분입니다. 재도입 조건을 정책 문서에 명시했어요.
Tag 시스템 재도입 조건:
1. 메서드랩 50명+ 규모로 확장
2. 분류 거버넌스 정책 수립 완료
3. Tag 활용의 명확한 액션(자동 알림·필터링·시각화) 정의세 조건이 다 충족돼야 재도입을 검토합니다.
왜 이렇게까지 명시했을까요? 미래의 자신으로부터 충동적 재도입을 막는 가드였어요.
6개월 뒤 또는 1년 뒤, 어떤 시점에 "Tag가 있으면 편하지 않을까?" 하는 충동이 다시 올 수 있습니다. 이때 정책에 박힌 조건이 없으면 즉흥적으로 다시 도입하게 돼요. 그러면 또 6개월 후에 같은 폐기 결정을 반복하게 됩니다.
조건이 박혀 있으면 충동을 멈춥니다. "지금 조건 충족하나?" 묻고, 안 되면 도입 보류. 결정의 기록이 미래 결정의 가드 역할을 해요.
이 패턴이 이번 글의 가장 흥미로운 통찰이었습니다. 폐기는 한 번의 결정이 아니라 미래의 충동까지 막는 정책 설계여야 안정적이에요.
분류 vs 검색 — 현대 검색 패러다임
이번 폐기 회고에서 한 가지 더 짚어볼 통찰이 있어요. 분류 시스템 자체에 대한 시야입니다.
분류 시스템은 검색이 약하던 시대의 해법이었어요. 책장에 도서를 듀이 십진분류법으로 정리하는 것, 파일을 폴더 트리로 정리하는 것. 모두 "검색이 안 되니까 분류로 찾는다"는 발상에서 출발했습니다.
그런데 현재는 풀텍스트 검색·자연어 검색·시맨틱 검색이 발달했어요. "어디에 있더라" 대신 "이런 내용 찾아줘"로 패러다임이 바뀌었습니다.
시대 | 패러다임 | 도구 |
|---|---|---|
검색 약함 시대 | 분류로 찾기 | 폴더, Tag, 카테고리 |
검색 발달 시대 | 검색으로 찾기 | 풀텍스트, 자연어, 시맨틱 |
지금 시대에도 분류 시스템이 가치를 만드는 영역은 분명히 있습니다. 큰 팀의 거버넌스, 규제 분류, 자동 라우팅 같은 영역에서는 분류가 필수예요. 하지만 1인 운영 + 풍부한 본문 + 풀텍스트 검색 가능 환경에서는 분류 부담이 검색 효율을 압도합니다.
이 패러다임 변화를 인정하면 "Tag 시스템을 잘 운영하지 못한 게 아니라, 환경에 맞지 않는 도구를 도입했던 것"이라는 평가가 가능해져요. 도입 자체의 판단 실수였지, 운영 실패가 아닙니다.
데이터 기반 폐기 의사결정 체크리스트
도구 폐기·기능 제거·기능 단순화를 검토하실 때 점검할 일반 체크리스트입니다.
1. 운영 데이터를 측정합니다
추측이 아니라 사용률·접근 빈도·완료율 같은 데이터를 확인합니다. "안 쓰일 것 같다"가 아니라 "6개월 데이터에서 X% 사용"이라는 구체 숫자가 의사결정의 근거가 됩니다. 데이터가 없으면 측정부터 시작합니다.
2. 여러 사유가 한 방향을 가리키는지 확인합니다
한 가지 사유로 폐기 결정은 위험합니다. 실효성·컨텍스트·패러다임·비대칭·노이즈 같은 다층 사유가 한 방향을 가리킬 때 결정에 무게가 실립니다. 한 사유만 강하면 다른 시각에서 다시 봅니다.
3. 어설프게 남기는 비용을 인정합니다
UI만 숨기거나 백엔드만 남기는 부분 폐기는 "다음에 정리"의 가면을 쓴 상태로 미래에 더 큰 부담을 만듭니다. 코드·데이터·UI·정책 전 계층을 함께 정리하는 게 안전합니다.
4. 재도입 조건을 정책에 박아둡니다
폐기 후 6개월~1년 뒤 충동적 재도입이 일어날 수 있습니다. 재도입 조건을 미리 명시해두면 미래의 자신(또는 팀)이 충동을 멈출 수 있어요. 결정의 기록이 미래 결정의 가드 역할을 합니다.
비슷한 발상이 다른 운영 결정에서도 흐릅니다. 데이터를 의사결정 근거로 두는 것, 여러 사유가 한 방향을 가리키는지 확인하는 것, 결정의 기록을 미래 결정의 가드로 활용하는 것. 제품 정리의 핵심 기준입니다.
마무리
PM 도구의 Tag 시스템을 6개월 운영 후 완전 폐기했습니다. 한 도메인에서만 44% 사용, 나머지 모든 타입에서 0%라는 데이터가 결정의 근거였어요. 다섯 가지 사유(실효성·컨텍스트·패러다임·비대칭·노이즈)가 같은 방향을 가리켰고, 어설프게 남기는 비용을 피하기 위해 전 계층 제거를 선택했습니다. 그리고 재도입 조건을 정책에 명시해서 미래의 충동적 재도입을 차단했어요.
핵심 교훈은 세 가지입니다.
운영 데이터가 도구 폐기를 정당화한다 — 추측이 아니라 사용률 측정으로 결정
어설프게 남기는 비용이 가장 큰 함정 — 전 계층 제거가 미래 부담을 줄임
재도입 조건을 정책에 박아두면 미래의 충동을 막을 수 있다 — 결정의 기록이 미래 결정의 가드
도구 폐기·기능 제거·기능 단순화를 검토하신다면, 이번 글의 4가지 체크리스트(데이터 측정 / 다층 사유 점검 / 어설프게 남기는 비용 인정 / 재도입 조건 정책화)를 한 번 살펴보시길 추천합니다. 데이터가 명확한 신호를 줄 때 결정에 망설임이 사라지고, 정책에 박힌 조건이 미래의 충동을 막아줍니다.