일기 slecs

페이지뷰 통계 레거시 코드를 삭제 대신 아카이브로 보관

목차

이전에 쓰던 페이지뷰 통계 코드들을 archive로 옮기는 작업을 했다. site-pv.py, pv-period.py 같은 함수들이 더 이상 현재 시스템에서 쓰이지 않게 된 것인데, 그냥 지워 버리지 말고 폴더를 따로 만들어서 보관하기로 했다.

통계 시스템도 진화한다

초창기 백엔드는 대부분 "일단 작동하게 하자"는 마음으로 만들어진다. 페이지뷰 집계도 마찬가지였다. 가장 간단한 방식으로 데이터를 모으고, 리포트를 뽑고, 운영자가 확인할 수 있게 했다. 하지만 트래픽이 늘고 요구사항이 복잡해지면서, 처음 설계는 점점 한계에 부딪힌다. 쿼리 성능이 안 나온다든지, 실시간 업데이트가 필요하다든지, 더 정밀한 분석이 필요해진다든지.

그러다 보면 자연스럽게 새로운 통계 시스템이 생겨난다. 더 나은 스택, 더 효율적인 로직으로. 그 과정에서 옛날 코드들은 점차 호출되지 않는다. 하지만 여기서 중요한 결정이 나타난다. 이 코드들을 어떻게 처리할 것인가?

삭제가 아닌 보관을 선택한 이유

완전히 지워 버리는 것처럼 보이는 게 깔끔하지만, 실제로는 위험이 많다.

먼저 당장은 안 쓰지만 언제 필요할지 모른다는 점이다. 과거 특정 기간의 데이터를 재검증해야 할 때가 있다. 그때 옛날 코드가 어떻게 계산했는지 알아야 현재 데이터와 비교할 수 있다. 우리 시스템이 "A 기간의 집계가 정확했다/틀렸다"는 질문이 나왔을 때, 그 당시의 로직을 다시 돌려봐야 할 수도 있다는 뜻이다.

두 번째는 팀원들의 학습 관점이다. 신입이 들어왔을 때 "우리가 어떻게 시작했는가"를 보는 건 좋은 교육이 된다. 왜 이전 방식은 한계가 있었는지, 현재 방식이 어떻게 개선된 건지 이해하는 데 옛 코드만큼 좋은 교재는 없다.

셋째, git history는 영원하지 않다는 생각도 있다. 물론 git에서 이전 커밋을 찾을 수 있지만, 현 시점에 live 코드 폴더에서 "이건 뭐 하는 거지?" 하고 찾는 것보다, 명시적으로 "여기 archive에 있어, 더 이상 안 써"라고 표시하는 게 훨씬 명확하다.

아카이브 구조와 문맥 제공

그래서 archive/stats-legacy/ 폴더를 만들고 그 안에 옛날 코드들을 모았다. 단순히 파일들을 옮긴 게 아니라 README.md도 함께 넣었다. "언제 폐기되었는가", "왜 폐기되었는가", "대신 어떤 시스템을 쓰는가"를 기록해두는 것이 중요하다.

archive/stats-legacy/
├── README.md          # 폐기 이유, 대체 시스템 설명
├── site-pv.py         # 옛 사이트 PV 집계 로직
└── pv-period.py       # 옛 기간별 PV 집계 로직

이렇게 하면:
- 누군가 site-pv.py를 우연히 발견했을 때 폴더 구조로 이미 "이건 legacy"라는 신호가 전달된다
- README를 읽으면 왜 여기 있는지, 언제 쓸 수 있을 것 같은지 판단할 수 있다
- git blame이나 history 검색도 더 쉬워진다

팀 차원에서 다루는 기술 부채

이런 종류의 작업은 작은 것처럼 보이지만, 팀 문화에 꽤 영향을 미친다.

기술 부채 관리에서 중요한 건 "버린다 vs 관리한다"의 구분이다. 우리 팀은 코드를 버리되, 그냥 휴지통에 던지는 식이 아니라 "공식적으로 보관한다"는 입장을 취하기로 했다. 그러려면:

  • 정기적인 아카이브 작업: 더 이상 안 쓰는 모듈이 감지되면, 빠르게 archive로 옮긴다
  • 문맥 기록: 각 폴더마다 왜 폐기되었는지 최소한의 설명을 남긴다
  • 팀 공지: 이런 변경을 하면 PR 설명이나 슬랙에서 "X 모듈이 archive로 이관됐으니 참고"라고 언급한다

이렇게 하면 코드리뷰 때도 "어? 이 함수는 뭐지?"라는 혼동이 줄어든다.

다시 한 번: 왜 이렇게까지 하는가

남은 질문은 "그냥 지우면 되는 거 아닌가?"일 수 있다. 하지만 real-world 시스템을 운영하다 보면, 데이터 일관성이나 감사 추적(audit trail)이 생각보다 중요하다는 걸 느낀다. "이전에는 이렇게 계산했다"는 기록이 남아있으면, 나중에 문제가 생겼을 때 원인을 추적하거나, 마이그레이션 검증을 훨씬 쉽게 할 수 있다.

또 하나는 팀이 성장할 때의 차이다. 작은 팀에선 "아, 그거 옛날에 이렇게 했지"라고 입으로 전달된다. 하지만 팀이 커질수록, 신입이 들어올수록, 명시적인 기록이 필수가 된다. archive 구조는 그 기록의 첫 번째 계층이다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.