Your coding agent doesn't always follow your rules — Talha Sheikh, Checkout.com

한 줄 핵심

코딩 에이전트의 성능보다 중요한 것은 작업 완료를 자동으로 검증하는 하네스와 피드백 루프이며, 이를 잘 설계해야 더 작은 모델도 신뢰할 수 있게 쓸 수 있다.

시간별 요약

1. 0:07
   Claude code 같은 코딩 에이전트는 작업을 빠르게 분해해 수행해도, 실제 실행 단계에서는 작은 누락과 실패가 자주 남는다. 결국 사용자가 계속 수정 지시를 내려야 하므로, 에이전트가 끝났다고 말하는 순간에 실제 완료 여부를 판정하는 검증 장치가 필요하다.
2. 2:00
   이를 위해 Vector V1을 만들어 Claude hooks로 세션 종료 시 자동 검증을 걸고, 테스트 케이스가 실패하면 다시 시도하도록 구성했다. 핵심은 에이전트가 일을 했는지가 아니라, 원하는 기준대로 끝났는지를 결정적으로 확인하는 것이다.
3. 3:00
   모델이 더 강력해져도 그것이 곧 신뢰성으로 이어지는 것은 아니며, 좋은 spec이나 MCP 서버, sub-agents만으로는 검증을 대체할 수 없다. 오히려 가드레일이 강할수록 더 작은 모델이나 오픈소스 모델도 충분히 쓸 수 있어 비용을 크게 줄일 수 있다.
4. 5:01
   각 조직이 자기 방식의 enforcement를 따로 만들기 때문에, 개인용 도구가 아니라 공통 패턴으로 일반화되어야 한다. 이 검증은 대화 종료, 커밋 전, multi-agent workflow, async operation, LLM-as-a-judge 같은 여러 단계에 걸쳐 언어와 코드에 독립적으로 적용될 수 있다.
5. 7:01
   Anthropic의 executed advisor pattern, OpenAI의 harness engineering, 코드 리뷰 도구들, WorkOS의 'enforce don't instruct'는 모두 같은 방향을 가리킨다. 이제 가치의 중심은 코드를 많이 쓰는 능력이 아니라, 결과를 검증하는 시스템을 얼마나 잘 설계하느냐에 있다.

실무 인사이트

• 코딩 에이전트 도입 시에는 프롬프트 개선보다 먼저 자동 검증 기준과 실패 시 재시도 루프를 설계해야 실제 생산성이 올라간다.
• 비용 최적화는 더 큰 모델을 쓰는 방향보다, 하네스와 검증을 강화해 작은 모델도 신뢰 가능하게 만드는 방향에서 더 크게 발생한다.
• 팀 단위로는 각자 다른 규칙을 수동으로 적용하기보다, 커밋 전·작업 종료·비동기 처리 단계에 공통 검증 계약을 두는 것이 재현성과 확장성에 유리하다.