개발 slecs

오래된 감사 문서 아카이빙으로 문서 정리

목차

지난 2월 진행했던 admin-partner 감사 보고서를 .claude/docs/archive 폴더로 이관했다. 간단한 정리 작업이지만, 문서 생명 주기를 어떻게 관리할지에 대한 작은 결정이 담겨 있다.

왜 오래된 감사 문서를 아카이브할까

초기에 문서를 만들 때는 "모두 최상위에 두자"는 생각으로 시작한다. 하지만 4개월, 6개월이 지나다 보면 문서 구조가 지저분해진다. 특히 감사(audit) 같은 일시적 결과물이 쌓이면, 팀원들이 새 문서를 찾을 때 스크롤을 계속해야 하는 상황이 생긴다.

admin-partner 감사(2026-02)는 이미 실행 완료되고, 그 결과 항목들도 대부분 처리된 상태였다. 더 이상 "최신 상태를 확인해야 하는 활성 문서"가 아니었다. 이런 문서를 계속 메인 폴더에 두는 것은:

  • 발견성 저하: 팀원들이 "지금 해야 할 감사"를 찾을 때 옛 감사부터 걸린다
  • 메인터넌스 부담: docs 구조가 복잡할수록 새 문서 작성/참조 정책을 설명하기 어렵다
  • 심리적 노이즈: "이것도 봐야 하나?"라는 불필요한 인지 부하

따라서 "끝난 감사는 archive로"라는 원칙을 정하고, 오래된 것부터 정리하기로 했다.

아카이빙 vs 삭제의 선택

처음에는 "어차피 옛날 것인데 지우면 안 되나?"라고 생각할 수 있다. 하지만 지우지 않은 데는 몇 가지 이유가 있다:

  1. 히스토리 추적: "작년에 뭘 확인했지?" 할 때 git history 외에도 문서로 남겨두면 도움이 된다
  2. 패턴 발견: 정기 감사를 반복하다 보면, 예전 보고서와 비교해서 개선 추세를 볼 수 있다
  3. 온보딩: 새 팀원이 "과거에 뭐가 이슈였는지" 배경을 이해하려면 archive가 필요하다
  4. 법/정책 근거: 감사는 때로 compliance와 연결되므로, 완료된 것도 증거로 남겨두는 게 좋다

지우는 것과 archive 하는 것의 차이:

선택 장점 단점
삭제 폴더가 깔끔, git 용량 절감 히스토리 손실, 나중에 필요할 때 복구 어려움
아카이빙 히스토리 보존, 언제든 참조 가능 구조 유지 필요, 약간의 클러터

우리 팀에서는 아카이빙을 선택했다. git repository는 본래 히스토리를 남기는 게 철학이고, 문서도 마찬가지라고 생각한다.

문서 구조 원칙으로 정리하기

이 작업을 계기로 팀 내 문서 정책을 몇 가지 정립했다:

  • 활성 문서: .claude/docs/ 루트 → 지금 참조해야 할 정책, 프로세스, 진행 중인 작업
  • 완료/과거: .claude/docs/archive/ → 완료된 감사, 이전 분기 작업 리뷰, 히스토리 성격의 문서
  • 명명규칙: <task>-<date>.md → archive 문서는 언제 기준의 자료인지 파일명에 포함

이렇게 하면:
- 새로운 감사를 시작할 때 "archive 안 보고 최신 정책만 참조"하면 된다
- 팀원이 폴더 구조만 봐도 "아, 지금 필요한 건 루트, 히스토리는 archive에" 이해한다
- git에서도 여전히 전체 히스토리를 추적할 수 있다 (git log 로 다 뜬다)

작은 결정이 모이는 것

이건 "코드 리뷰가 필요한 변경"이 아니다. 폴더 한 개 이동, 파일 한 개의 이관이다. 하지만 이런 작은 정리들이 모이면:

  • 팀원들이 문서를 찾을 때 혼란이 줄어든다
  • 새로운 감사를 추가할 때 "어디에 두지?" 고민이 없어진다
  • 문서 정책에 대해 말할 때 구체적인 예시가 생긴다

특히 리딩 입장에서는 이런 "조용한 정리"가 중요하다. 팀이 증가하고 업무가 복잡해질수록, 문서 구조는 더 엄격해야 한다. 지금 하나씩 정리하지 않으면, 6개월 뒤엔 docs 폴더가 카오스가 된다.

앞으로도 분기가 끝나면 비슷한 작업들을 archive로 옮길 예정이다. 그리고 팀에서 "언제쯤 이것을 archive로 옮기는 게 좋을지"에 대한 가이드를 문서화할 생각이다.


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

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

댓글 0

첫 댓글 달아줘.