혹시 CLAUDE.md / AGENTS.md 파일이 몇 달 지나면 에이전트한테 거짓말을 하게 된다고 느끼는 사람 또 있나요?
Anyone else find their CLAUDE.md / AGENTS.md files end up lying to the agent after a few months?
핵심 요약
에이전트 설정 파일이 시간이 지나며 코드와 불일치해 발생하는 문제와 그 해결책을 논의합니다.
- 설정 파일 부패 — 시간이 지나면서 deprecated 된 패턴이나 라이브러리를 에이전트가 계속 사용하게 됨
- 에이전트 신뢰 문제 — 에이전트가 실제 코드보다 설정 파일을 더 신뢰하여 잘못된 코드를 생성함
- 관리 전략 논의 — 설정 파일을 최소화하거나, 상황별로 문서를 참조하게 하는 등 관리 방식 공유
- 테스트의 중요성 — 에이전트의 환각을 방지하기 위해 TDD나 자동화된 테스트가 필수적이라는 의견
저는 꽤 규모가 있는 레포지토리 몇 개를 관리하고 있는데, 초기부터 "에이전트가 우리 관례를 따르도록 컨텍스트 파일을 작성하자"는 방식을 적극적으로 도입했습니다. 처음에는 아주 잘 작동했죠.
아무도 경고해주지 않았던 문제는 바로 그 파일들이 썩어간다는 겁니다. 우리는 출시 시점에 파일을 작성했습니다. 6개월이 지나니 그 안의 규칙 절반이 틀린 내용이 되었죠. 우리가 더 이상 쓰지 않기로 한 패턴, 버린 라이브러리, 사건 사고 이후 뒤집은 결정들까지요. 파일은 여전히 에이전트에게 자신 있게 옛날 방식을 하라고 지시하고, 에이전트는 왜 안 하겠냐는 듯이 그대로 따릅니다. 에이전트는 코드보다 파일을 더 신뢰하니까요.
그래서 지금 저는 더 이상 존재하지 않는 표준에 맞춰 코드를 생성하는 에이전트를 갖게 되었습니다. 겉보기엔 멀쩡해 보이는데, 이게 명백하게 고장 난 것보다 더 위험합니다.
최근에 1만 개의 공개 레포지토리 중 이런 설정 파일이 있는 건 5%뿐이라는 통계를 봤습니다. 믿어지더군요. 하지만 파일을 가진 사람들은 더 이상한 상황에 처해 있을지도 모릅니다. 낡은 규칙은 규칙이 없는 것보다 더 위험하니까요.
다들 이걸 어떻게 처리하고 계신가요? 그냥 뭔가 바뀔 때마다 파일을 업데이트하도록 스스로를 훈련시키나요(우리는 분명히 안 하고 있습니다)? 아니면 drift(설정값과 실제 코드의 괴리)를 감지하는 CI 체크를 쓰시나요? 아니면 정적 파일 방식을 완전히 버리고 누군가 한 번 써놓은 문서 대신 코드의 상태를 읽는 방식으로 넘어가셨나요?
저보다 규모가 큰 팀들은 어떻게 하고 있는지 궁금합니다.
