당신은 Claude Code에게 특정 인터페이스를 수정하지 말라고 지시합니다.
Claude는 그 지침을 인지하고, 코드를 수정합니다.
몇 번의 세션이 지난 후, 그것은 똑같은 실수를 또 저지릅니다.
당신은 CLAUDE.md에 규칙을 추가합니다. 에이전트는 이를 읽습니다. 모든 것이 좋아 보입니다.
하지만 다시 그 일이 발생합니다.
어느 순간부터 당신은 지침 파일 자체가 더 길거나, 더 구체적이거나, 아니면 완전히 재작성되어야 하는지 의문을 품기 시작합니다.
하지만 만약 문제가 지침 자체에 있는 것이 아니라면 어떨까요?
에이전트에게 무엇을 해야 할지 알려주는 것의 문제점
CLAUDE.md나 AGENTS.md 같은 파일들은 유용합니다. 이 파일들은 코딩 에이전트에게 리포지토리, 그 관례(convention), 그리고 개발자들이 작업을 처리하기를 원하는 방식에 대한 지속적인 맥락을 제공합니다.
하지만 여기에는 한계가 있습니다: 에이전트에게 규칙을 알려주는 것이, 중요한 순간에 그 규칙을 따르게 하는 것과는 같지 않다는 것입니다.
몇 가지 예를 들어보겠습니다:
- 당신은 에이전트가 불필요한 추상화(abstraction)를 추가한 것에 대해 수정합니다. 그러자 나중에 수행하는 작업에서 또 다른 추상화를 추가합니다.
- 당신은 리포지토리가 테스트를 처리하는 방식을 설명해 줍니다. 그런데 에이전트는 미래 세션에서 그 관례를 무시합니다.
- 성공을 보고하기 전에 주장을 검증하도록 요청합니다. 하지만 확인 절차 없이 자신감 있게 결과를 요약합니다.
당신은 이 모든 것에 대한 지침을 추가할 수 있습니다.
하지만 새로운 규칙이 추가될 때마다, 에이전트가 탐색해야 할 정보량이 더 늘어납니다. 그리고 관련 정보가 이용 가능하더라도, 에이전트는 여전히 잘못된 결정을 내릴 수 있습니다.
당연한 대응은 계속해서 규칙을 추가하는 것입니다.
저는 이것이 확장성이 있다고 확신하지 못합니다.
수정 이후에 무엇이 일어나야 하는가?
다른 워크플로우를 상상해 보세요.
당신이 에이전트의 아키텍처적 결정(architectural decision)을 수정했다고 가정합시다. 시스템은 그 수정을 단순히 현재 작업에만 중요한 것으로 취급하는 대신, 잠재적으로 재사용 가능한 교훈으로 식별합니다.
나중에 에이전트가 비슷한 상황에 직면합니다.
시스템은 이전에 했던 수정이 관련성이 있을 수 있음을 인식하고, 해당 시점에 그 지침을 제시합니다.
개발자는 마크다운 파일을 업데이트해야 한다는 것을 기억할 필요가 없고, 에이전트는 같은 교훈을 처음부터 다시 발견할 필요도 없습니다.
그것이 아이디어입니다.
물론, 해당 설명 내부에는 해결하기 어려운 문제들이 숨어 있습니다.
1. 모든 수정 사항이 규칙이 될 필요는 없다
때로는 개발자가 일회성 변경을 원할 수 있습니다.
때로는 수정 사항이 몇 달 동안 중요하게 작용할 저장소의 관례(repository convention)를 반영할 수도 있습니다.
때로는 그 수정 사항이 특정 아키텍처나 작업에만 적용될 수도 있습니다.
유용한 시스템은 이러한 상황들을 구별해야 합니다. 그렇지 않으면 모든 수정을 영구적인 부담으로 만들 위험을 안게 됩니다.
2. 올바른 교훈은 적절한 시점에 나타나야 한다
“저장소의 관례를 따르라”와 같은 일반적인 지침은 작성하기는 쉽지만 항상 유용하지는 않습니다.
구체적인 안내가 훨씬 더 실행 가능할 수 있습니다.
예를 들어:
“성공했다고 보고하기 전에 주장을 검증하라.”
보다 구체적인 지침은 다음과 같을 수 있습니다:
“테스트가 통과했다고 보고하기 전에, 실제로 실행한 테스트 명령어의 결과를 확인하라.”
도전 과제는 교훈이 언제 적용되는지 인식하고, 에이전트가 관련 결정을 내릴 때 그것을 전달하는 것입니다.
3. 더 많은 안내는 더 많은 노이즈를 만들 수 있다
시스템이 관련 없는 지침을 끊임없이 주입하면, 개발자들은 그것들을 무시하기 시작할 것입니다.
수정 사항으로부터 학습하는 것은 결과적인 안내가 에이전트를 압도하지 않으면서 행동을 개선시킬 때만 유용합니다.
이는 단순히 안내가 표면화되는지 여부뿐만 아니라, 그것이 도움이 되는지를 측정한다는 것을 의미합니다.
우리가 탐구하고 있는 것들
우리는 오픈 소스 솔루션을 구축하고 있으며, 세션 전반에 걸쳐 코딩 에이전트를 더욱 신뢰할 수 있게 만드는 방법을 탐구하고 있습니다.
CLAUDE.md나 AGENTS.md 같은 지침 파일은 유용하지만, 항상 동일한 실수가 반복되는 것을 막지는 못합니다. 우리는 코딩 에이전트가 개발자가 이미 가르쳐 준 내용을 적용하는 방식에 여전히 개선할 여지가 있다고 생각합니다.
또한 실수에는 여러 종류가 있습니다. 일부는 결정론적 검사(deterministic checks)로 포착될 수 있습니다. 다른 것들은 판단을 포함하며, 이 경우 에이전트는 올바른 정보를 가지고 있어도 잘못된 결정을 내릴 수 있습니다.
이러한 차이를 이해하는 것이 문제의 중요한 부분입니다.
코딩 에이전트를 사용하는 개발자를 위한 질문
만약 당신이 Claude Code, Codex, Cursor 또는 유사한 도구를 정기적으로 사용한다면, 당신의 경험을 듣고 싶습니다.
코딩 에이전트(coding agent)를 수정했을 때, 그 수정 사항이 미래 세션에서도 실제로 얼마나 자주 유지되나요?
지침 파일(instruction files)을 관리하나요? 후크(hooks)를 사용하나요? 자체 메모리 시스템을 구축했나요? 아니면 단순히 특정 실수가 계속 발생한다는 것을 받아들였나요?
저는 특히 에이전트가 이미 올바른 지침을 가지고 있었음에도 불구하고 여전히 잘못 수행하는 경우에 관심이 있습니다.
저희는 AutoSteer를 통해 이 부분을 탐구하고 있으며, 개발자들이 무엇을 필요로 하는지에 대한 가정을 하기 전에 실제로 무엇이 효과가 있는지 이해하고 싶습니다.