에이전트가 내 규칙을 '제안' 정도로만 여기고 자기들 마음대로 규칙을 만듭니다.

우리도 비슷한 아키텍처를 구축했는데, 코드 검사를 루프 안에 넣었어. 그래서 에이전트가 정의된 라이브러리 대신 다른 JS 라이브러리를 쓰려고 하면 에러가 발생해서 작업을 다시 해야 함. 정의된 작업은 100개뿐이고, 그 외의 것은 아무것도 못 하게 막아놨어.

🪝

궁극적인 해결책은 없지만, "이것들은 강제 규칙이며, 여기서 벗어나는 것은 용납할 수 없는 실패로 간주한다"라고 명시하면 그나마 좀 더 말을 잘 듣게 됨.

훅이 필요함. 제대로 설정하면 미묘한 행동까지도 기대 이상으로 잘 작동함, 100%는 아니지만.

Claude Code 같은 걸 쓸 때, 그 안에는 여러 층의 자체 시스템 프롬프트가 포함되어 있음. 어떤 면에서 프롬프트는 조언일 뿐이라 에이전트가 따르기로 '선택'하는 거임. 항상 따를 거라는 보장이 없는 불안정한 녀석들이지. 대부분은 잘 따르지만.

그렇긴 해도 추가 프롬프트를 통해 자신만의 규칙을 도입할 수 있음. 성공할 때도 있고 대놓고 무시당할 때도 있을 거야. 정상임. 하지만 네 프롬프트가 약할 수도 있음. 시행착오의 영역이지. 조정하고, 정제하고, 뭐가 되고 뭐가 안 되는지 테스트해 봐. 개선된 프롬프트는 더 나은 결과와 일관성을 주겠지만, 보장된 건 아님. 몇 달간 잘 작동하던 프롬프트도 모델 업데이트 한 번에 망가질 수 있음. 그럼 다시 조정하는 거지. 반복해.

이제 이걸 막으려면 훅이 확실한 답임. 에이전트를 멈추게 하는 메커니즘, 게이트, 프롬프트 인젝션 같은 거. 훅은 원하는 경로를 그려줄 수 있고 에이전트는 그 길을 따라갈 거야. 한 경로를 막으면 가이드와 올바른 경로에 대한 인식을 심어주면서 다른 문을 열어줘. 그러면 일관된 결과를 보기 시작할 거임.

솔직히 이건 일종의 예술임. 많이 할수록 조종하는 실력이 늘어날 거야.

Claude.md 파일을 # 프로젝트 규칙
##규칙 이렇게 시작하고 불렛포인트를 적어봐, 보통은 잘 따라오더라고.

그냥 .md 파일에 네 아이디어를 주입하려고 하면 무시당할 거야. 에이전트와 대화하면서 네가 원하는 걸 말하고, 그들이 직접 파일을 관리하게 해.

프로젝트 수준의 Claude.md + 스킬 + 메모리를 조합하는 다층 접근 방식으로 효과를 봤음.

근데 내 규칙들은 어떻게 작동해야 하는지보다는 최종 결과물이 어떠해야 하는지에 더 집중되어 있음.

시스템 프롬프트나 Md 파일에 "강제 제약(hard constraints)" 같은 단어를 쓰는 게 효과가 있었음. 하지만 다른 댓글들이 말하는 훅이 더 나은 방법인 것 같고 병행해서 써야 할 듯. 이 논문에서 본 내용임 https://arxiv.org/abs/2604.21744