오래된 감사 문서 아카이빙으로 문서 정리
목차
지난 2월 진행했던 admin-partner 감사 보고서를 .claude/docs/archive 폴더로 이관했다. 간단한 정리 작업이지만, 문서 생명 주기를 어떻게 관리할지에 대한 작은 결정이 담겨 있다.
왜 오래된 감사 문서를 아카이브할까
초기에 문서를 만들 때는 "모두 최상위에 두자"는 생각으로 시작한다. 하지만 4개월, 6개월이 지나다 보면 문서 구조가 지저분해진다. 특히 감사(audit) 같은 일시적 결과물이 쌓이면, 팀원들이 새 문서를 찾을 때 스크롤을 계속해야 하는 상황이 생긴다.
admin-partner 감사(2026-02)는 이미 실행 완료되고, 그 결과 항목들도 대부분 처리된 상태였다. 더 이상 "최신 상태를 확인해야 하는 활성 문서"가 아니었다. 이런 문서를 계속 메인 폴더에 두는 것은:
- 발견성 저하: 팀원들이 "지금 해야 할 감사"를 찾을 때 옛 감사부터 걸린다
- 메인터넌스 부담: docs 구조가 복잡할수록 새 문서 작성/참조 정책을 설명하기 어렵다
- 심리적 노이즈: "이것도 봐야 하나?"라는 불필요한 인지 부하
따라서 "끝난 감사는 archive로"라는 원칙을 정하고, 오래된 것부터 정리하기로 했다.
아카이빙 vs 삭제의 선택
처음에는 "어차피 옛날 것인데 지우면 안 되나?"라고 생각할 수 있다. 하지만 지우지 않은 데는 몇 가지 이유가 있다:
- 히스토리 추적: "작년에 뭘 확인했지?" 할 때 git history 외에도 문서로 남겨두면 도움이 된다
- 패턴 발견: 정기 감사를 반복하다 보면, 예전 보고서와 비교해서 개선 추세를 볼 수 있다
- 온보딩: 새 팀원이 "과거에 뭐가 이슈였는지" 배경을 이해하려면 archive가 필요하다
- 법/정책 근거: 감사는 때로 compliance와 연결되므로, 완료된 것도 증거로 남겨두는 게 좋다
지우는 것과 archive 하는 것의 차이:
| 선택 | 장점 | 단점 |
|---|---|---|
| 삭제 | 폴더가 깔끔, git 용량 절감 | 히스토리 손실, 나중에 필요할 때 복구 어려움 |
| 아카이빙 | 히스토리 보존, 언제든 참조 가능 | 구조 유지 필요, 약간의 클러터 |
우리 팀에서는 아카이빙을 선택했다. git repository는 본래 히스토리를 남기는 게 철학이고, 문서도 마찬가지라고 생각한다.
문서 구조 원칙으로 정리하기
이 작업을 계기로 팀 내 문서 정책을 몇 가지 정립했다:
- 활성 문서:
.claude/docs/루트 → 지금 참조해야 할 정책, 프로세스, 진행 중인 작업 - 완료/과거:
.claude/docs/archive/→ 완료된 감사, 이전 분기 작업 리뷰, 히스토리 성격의 문서 - 명명규칙:
<task>-<date>.md→ archive 문서는 언제 기준의 자료인지 파일명에 포함
이렇게 하면:
- 새로운 감사를 시작할 때 "archive 안 보고 최신 정책만 참조"하면 된다
- 팀원이 폴더 구조만 봐도 "아, 지금 필요한 건 루트, 히스토리는 archive에" 이해한다
- git에서도 여전히 전체 히스토리를 추적할 수 있다 (git log 로 다 뜬다)
작은 결정이 모이는 것
이건 "코드 리뷰가 필요한 변경"이 아니다. 폴더 한 개 이동, 파일 한 개의 이관이다. 하지만 이런 작은 정리들이 모이면:
- 팀원들이 문서를 찾을 때 혼란이 줄어든다
- 새로운 감사를 추가할 때 "어디에 두지?" 고민이 없어진다
- 문서 정책에 대해 말할 때 구체적인 예시가 생긴다
특히 리딩 입장에서는 이런 "조용한 정리"가 중요하다. 팀이 증가하고 업무가 복잡해질수록, 문서 구조는 더 엄격해야 한다. 지금 하나씩 정리하지 않으면, 6개월 뒤엔 docs 폴더가 카오스가 된다.
앞으로도 분기가 끝나면 비슷한 작업들을 archive로 옮길 예정이다. 그리고 팀에서 "언제쯤 이것을 archive로 옮기는 게 좋을지"에 대한 가이드를 문서화할 생각이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.