팀 공유 지침 문서 헤더 체계화로 가독성 개선
목차
저희 팀은 모든 개발자가 접근할 수 있는 CLAUDE.md 파일들을 관리하고 있다. 이 파일들엔 프로젝트별 개발 규칙, AI 에이전트를 위한 컨텍스트, 코드 리뷰 가이드라인 같은 것들이 담겨 있다. 이번 작업은 이 문서들의 헤더 구조를 체계화해서 찾기 쉽고 이해하기 좋게 만든 것이다.
CLAUDE.md 가 팀 전체에 미치는 영향
CLAUDE.md 는 단순한 문서가 아니다. 서버에서 돌아가는 봇들, 로컬에서 개발하는 팀원들, 그리고 AI 에이전트들이 모두 이 파일들을 읽고 작업한다. 특히 AI 컨텍스트 로드 측면에서 중요한데, 매번 보트나 에이전트가 호출될 때마다 이 파일의 내용이 읽혀진다. 토큰 비용 관점에서 보면, 구조가 명확하지 않은 문서는 필요 없는 부분까지 길게 로드되거나, 반대로 핵심 정보를 찾기 위해 전체를 다시 읽어야 하는 낭비가 생긴다.
"캐스케이드 헤더"라는 건 사실 헤더의 계층적 구조를 말한다. Markdown 에서:
# 최상위 섹션 (Level 1)
## 주요 서브섹션 (Level 2)
### 세부 항목 (Level 3)
#### 더 깊은 정보 (Level 4)
이렇게 계층을 명확히 하면 문서 생성 도구들이 자동으로 목차를 만들 수 있고, 파일 크기가 크더라도 필요한 부분만 빠르게 스캔할 수 있다.
왜 이 작업이 필요했나?
팀이 성장하면서 CLAUDE.md 파일들도 계속 커져왔다. 특히 공통 지침(서버-글로벌 CLAUDE.md)은 여러 봇/프로젝트에서 참고하는 "단일 진실의 원천"이 되어 있다. 이런 문서가 헤더 구조 없이 단순 텍스트 뭉치가 되면:
- AI 에이전트 컨텍스트 로딩: 필요한 한두 섹션만 참고하려 해도 전체 문서를 읽어야 해서 토큰 낭비
- 팀원 온보딩: "어디에 뭐가 있는지" 검색이 어려워서 같은 질문을 반복하게 됨
- 유지보수 비용: 문서 업데이트 시 어느 섹션에 어떤 내용을 넣을지 불명확함
- 자동화 도구 활용 불가: 목차 생성, 문서 네비게이션 같은 보조 기능 사용 불가
특히 이번엔 서버에서도 이 문서를 검증했다는 게 포인트다. 실제로 우리 인프라의 봇들이 이 지침을 읽고 동작하는지, 혹은 구조가 명확해진 걸로 뭔가 개선될 게 있는지 확인하는 과정이 있었던 것 같다.
계층화의 실제 효과
이렇게 헤더를 체계화하면:
| 관점 | 개선 전 | 개선 후 |
|---|---|---|
| 토큰 비용 | 전체 파일 로드 필수 | 필요한 섹션만 선택 로드 가능 |
| 검색성 | "어디에 있지?" 문제 | 목차 + 섹션 이름으로 즉각 이동 |
| 협업 | 문서 수정 시 맥락 파악 어려움 | 섹션별 책임자 명확, 깎음 편함 |
| 자동화 | 문서 도구 미활용 | 마크다운 네비게이터, 스크린 리더 등 활용 가능 |
한 가지 흥미로운 건 docs 카테고리 작업도 사이드 업무(side)로 분류된다는 거다. "메인 기능 개발"이 아니니까 더 후순위로 밀릴 수 있는데, 실제로는 팀 전체의 개발 생산성에 영향을 미친다. 지침 문서가 명확하면 코드 리뷰도 빨라지고, 온보딩도 빨라지고, AI 에이전트도 올바른 컨텍스트에서 작업한다.
배운 점
이번 작업을 하면서 느낀 건, 큰 변화가 아닌 작은 구조 개선이 누적되면 꽤 큰 영향을 미친다는 거다. 특히 팀 전체가 참고하는 "공유 자산" 같은 문서에선 더욱 그렇다. 헤더를 한두 개 추가하는 건 몇 줄의 변경이지만, 나중에 수십 번의 문서 조회 시 효율을 올린다. 이걸 토큰 비용과 시간으로 환산하면 "문서화가 개발이다"라는 말이 실감된다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.