봇 프롬프트를 계층화해 관리 복잡도 낮추다

mingsblog 사이트에 사이트별 CLAUDE.md 파일을 추가하고 프롬프트 캐스케이드 구조를 정립했다. 작은 변경처럼 보이지만, 멀티 봇·멀티 사이트 환경에서 프롬프트 설정을 체계적으로 관리하기 위한 중요한 구조화 작업이었다.

문제의 배경

여러 봇이 서로 다른 사이트에서 실행되는 상황에서 프롬프트 규칙을 어떻게 관리할지가 핵심이었다.

전역 수준의 CLAUDE.md(예: /home/hedvion/.claude/CLAUDE.md)는 모든 봇이 공유해야 하는 공통 규칙을 담는다. 이메일, 연도 기준, 출력 형식 같은 것들. 하지만 각 봇이 실행되는 사이트마다 특화된 규칙이 필요할 수 있다. mingsblog 봇은 기술 블로그라는 특수한 도메인에서만 동작하니까, 글쓰기 톤, 길이, 구조 같은 사이트 고유 지침이 있어야 한다.

이전에는 이 두 계층을 혼동하거나 어느 한쪽을 우선시해야 하는지 모호했다. 전역 규칙에만 의존하면 사이트별 특수성이 반영되지 않고, 전역을 무시하면 공통 원칙이 깨진다. 특히 토큰 비용이 중요한 상황에서 전역 CLAUDE.md 는 모든 봇 호출마다 로드되므로, 이 파일에 사이트별 디테일까지 들어가면 불필요한 토큰을 낭비하게 된다.

캐스케이드 구조로 정리하다

해결책은 간단했다. 설정을 계층화하기로 했다.

전역 설정 (모든 봇이 로드)
  ↓ 오버라이드/확장
사이트별 설정 (해당 사이트 봇만 로드)

mingsblog 봇이 실행될 때:
1. 먼저 /home/hedvion/.claude/CLAUDE.md 를 로드 (공통 규칙: 출력 형식, 날짜, 이메일 등)
2. 그 다음 /opt/mingsblog/CLAUDE.md 를 로드 (mingsblog 특화 규칙: 글쓰기 톤, 제목 규칙, 카테고리 처리 등)

이렇게 하면:
- 중복 제거: 공통 규칙은 한 곳에만 유지
- 명확한 책임 분리: 어떤 규칙이 어디서 나오는지 알 수 있음
- 확장성: 새로운 봇·사이트를 추가할 때 이 패턴을 그대로 적용 가능
- 토큰 효율: 전역 파일은 짧게, 사이트 파일은 필요한 것만 담음

서버 검증을 통한 확신

문서 변경만으로는 부족했다. 실제 서버 환경에서 이 캐스케이드가 제대로 동작하는지 확인해야 했다.

서버 검증 과정에서 확인한 것들:
- mingsblog 봇이 호출될 때 정말 두 파일이 모두 로드되는가
- 전역 규칙과 사이트 규칙이 예상대로 병합되는가
- 모호한 규칙이 있을 때 우선순위가 명확한가 (일반적으로 사이트가 전역을 오버라이드)

이런 검증 단계를 거쳐야 했던 이유는, 프롬프트 규칙은 "동작하는지 아닌지"가 단순하지 않기 때문이다. 문서상으로는 맞아도, 실제 호출 흐름에서는 로드 순서나 상속 규칙 때문에 다르게 적용될 수 있다. 특히 여러 파일이 관여하는 구조라면 더욱 그렇다.

회고: 작은 구조 변경의 큰 영향

이 작업은 한 줄의 커밋 메시지로는 보이지 않지만, 프롬프트 관리 체계를 정립하는 중요한 단계였다.

팀 관점에서 보면:
- 새로운 봇을 추가할 때 프롬프트 규칙을 어떻게 구성할지 명확해짐
- 다른 개발자도 같은 패턴을 따를 수 있는 기초가 마련됨
- "왜 이 규칙이 먹히지 않지?"라는 혼동을 줄임

개인 차원에서는:
- 멀티레이어 구조에서 우선순위를 설정하는 일의 중요성을 다시 확인했음
- 문서 변경이라도 실제 환경에서 검증하는 버릇을 강화함
- 기술 블로그 봇처럼 특화된 도메인에서 작업할 때, 공통 규칙과 사이트 규칙을 깔끔하게 분리하면 결과 품질이 크게 올라감을 느낌

작은 구조 개선이 여러 봇, 여러 사이트로 확장될 때 진가가 드러난다. 이번 mingsblog 캐스케이드 추가는 그 시작점이다.

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

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