일기 slecs

Claude 지침 계층 구조로 설정 관리 일관성 확보

목차

여러 프로젝트와 환경에서 Claude Code를 쓰다 보니, 각 곳의 CLAUDE.md 지침이 서로 다르거나 중복되는 문제를 마주쳤다. 어떤 프로젝트는 최신 규칙을 따르고, 어떤 곳은 낡은 버전을 유지하고 있었고, 이번에 그 혼란을 정리하기 위해 "캐스케이드" 구조를 문서로 명시했다.

문제: 분산된 설정, 동기화 실패

처음엔 각 프로젝트마다 CLAUDE.md를 독립적으로 관리했다. 하지만 팀 공통 규칙(예: 금지 사항, 출력 포맷, 날짜 기준)이 있음에도, 모든 프로젝트에 같은 내용을 복사-붙여넣기하는 건 유지보수 악몽이었다. 팀 지침이 바뀌면 매번 수십 개 파일을 일일이 수정해야 하고, 실수로 누락되는 프로젝트가 생겨난다.

더 근본적인 문제는 토큰 비용이었다. CLAUDE.md는 모든 Claude 호출마다 프롬프트 토큰으로 계산된다. 중복된 내용을 각 환경에서 다시 로드한다는 것은, 봇 호출이 증가할수록 낭비가 커진다는 뜻이다. 그렇다고 모든 지침을 글로벌 하나에 넣으면, 개별 프로젝트의 특수한 요구사항을 반영하기 어렵다.

해결: 단일 진실 원칙(Single Source of Truth) + 계층 구조

이번 변경에서 문서화한 구조는 다음과 같다:

계층 역할 위치 유지보수
중앙(Global) 모든 봇이 따를 공통 규칙 hedvionCorp/ops 리포 · docs/server-global-CLAUDE.md Git 커밋 → 모든 환경 자동 반영
서버(Server) 서버 환경 전용 지침 /home/hedvion/.claude/CLAUDE.md Symlink로 central 파일을 가리킴
프로젝트(Project) 각 프로젝트/봇 특수 규칙 /opt/<repo>/CLAUDE.md 프로젝트별로 중앙 규칙을 상속·확장

핵심은 symlink + git 기반 워크플로우다. 서버의 CLAUDE.md는 실제 파일이 아니라 ops 리포의 중앙 문서를 가리킨다. 누군가 로컬 macOS에서 ops 리포를 수정해 커밋·푸시하면, 서버는 git pull로 자동 동기화된다. "서버검증"이라는 메모는, 이 구조가 실제로 서버 환경에서 제대로 작동하는지 테스트했다는 뜻이다.

이렇게 하면:
- 중복 제거: 공통 규칙은 한 곳에만 존재
- 일관성 보장: 모든 환경이 최신 지침 준수
- 토큰 절감: 중앙 파일을 symlink로 참조하면 불필요한 복사 방지
- 유연성 유지: 각 프로젝트는 자신의 CLAUDE.md에서 전역 규칙을 상속한 뒤 로컬 오버라이드 가능

다시 생각해보니: 설정 관리의 근본

이런 종류의 작업(문서화, 구조 정립)은 코드 변경처럼 눈에 띄지 않는다. 커밋 한 줄로 끝나 보이지만, 뒤에는 "어떤 진실을 중앙에서 관리할 것인가", "팀이 언제 동기화되어야 하는가", "변경이 언제 모든 환경에 반영될 것인가"에 대한 의사결정이 있다.

내 경험상, 설정 관리가 제대로 안 되면 팀은 서서히 "어느 파일을 믿어야 하나" 하는 혼란에 빠진다. 누군가 로컬 환경에서 테스트하고, 다른 누군가 스테이징에서 다른 규칙을 따르고, 운영 환경은 또 따로다. 이 상태에서는 일관된 의사결정도, 팀 차원의 베스트 프랙티스 확산도 어렵다.

따라서 문서 한 장을 작성하더라도, "이게 어떻게 관리되는지", "누가 수정할 수 있고 언제 반영되는지"를 명확히 해두는 게 중요하다. 그래야 팀 누구나 새로운 규칙이 필요할 때 그 구조를 따라 변경할 수 있고, 코드 리뷰도 "왜 이 규칙인지" 배경을 이해한 상태에서 진행된다.


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

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

댓글 0

첫 댓글 달아줘.