저는 코딩 에이전트와 실제 소프트웨어 작업을 수행하기 위한 모델에 구애받지 않는 도구를 만드는 데 몇 달을 보냈습니다. 결국, 기능은 예상보다 훨씬 중요하지 않았습니다. 실제로 중요했던 것은 에이전트에게 단순히 프롬프트를 입력하는 대신 에이전트와 함께 구축하는 방법에 대한 제 생각을 바꾼 몇 가지 아이디어였습니다.
이것들이 가장 큰 비중을 차지하는 아이디어들입니다. 처음 세 가지는 제 사고 방식을 진정으로 바꿔 놓았습니다. 나머지는 거의 즉시 사용할 수 있는 실용적인 것들입니다.
1. 에이전트가 작업을 시작하기 전에 수용 기준을 확정하세요
그리고 에이전트가 수정할 수 없는 곳에 두세요.
이것이 아마도 저에게 가장 큰 변화였을 것입니다. 돌이켜보면 당연해 보이지만, 실제로 적용해보기 전까지는 이것이 얼마나 중요한지 제대로 깨닫지 못했습니다.
작업이 완료된 후에 수용 기준이 변경될 수 있다면, 기준은 점차 실제로 생성된 결과물 쪽으로 이동하게 됩니다. 에이전트가 의도적으로 그런 것은 아닙니다. 단지 여전히 움직일 수 있는 목표를 기준으로 작업을 판단하는 것뿐입니다. 골대가 움직일 수 있다면, 결국에는 움직이게 되어 있습니다.
이는 프롬프트의 문제가 아니라 구조적인 문제이므로, 해결책도 구조적이어야 합니다.
수용 기준을 먼저 작성하세요. 편집 가능한 작업 공간 외부에 저장하고, 수정하려는 모든 시도를 자동으로 차단하세요. 이제 에이전트는 재협상할 수 없는 계약을 향해 작업하게 됩니다. 작업이 완료된 것은 에이전트가 그렇게 말해서가 아닙니다. 원래 계약을 충족했기 때문에 완료된 것입니다.
2. 누구도 자신의 작업을 평가해서는 안 됩니다
코드를 작성한 모델이 그 코드가 올바른지 판단하기에 가장 부적합한 심판입니다. 작업이 끝날 때쯤이면, 모델은 이미 스스로 그 해결책이 타당하다고 확신한 상태입니다.
따라서 책임을 분리하세요.
결정적인 스크립트가 모든 기계적인 부분을 검증하도록 하세요. 스크립트는 성공적인 종료 코드를 만들어낼 수 없습니다. 코딩 모델을 리뷰어가 아닌 엔지니어로 대우하세요. 그런 다음 결과물을 새로운 컨텍스트의 리뷰어, 즉 코드가 작성되는 과정을 전혀 보지 않은 리뷰어에게 넘겨 디자인, 의도, 전반적인 품질을 평가하게 하세요.
이 간단한 분리만으로도 예상보다 훨씬 더 많은 문제를 발견할 수 있었고, 놀랍도록 비용이 적게 듭니다.
3. 강제하는 것은 쉽습니다. 조정하는 것이 어려운 부분입니다.
이 깨달음은 제가 전체 시스템에 대해 생각하는 방식을 바꿔 놓았습니다.
대부분의 에이전트 시스템은, 제 초기 버전을 포함하여, 모든 작업을 거의 동일하게 처리합니다. 한 줄짜리 오타 수정도 주요 아키텍처 재설계와 동일한 프로세스를 거칩니다. 이는 시간 낭비이거나 너무 위험합니다.
핵심은 비례적인 노력입니다.
먼저 작업을 분류하세요. 아무것도 의존하지 않는 작은 변경인가요, 아니면 모든 것이 의존하는 핵심 인프라인가요? 비즈니스 로직인가요, 아니면 일반적인 유틸리티 코드인가요?
그런 다음 분류 결과에 따라 얼마나 많은 리뷰를 받을지, 어떤 모델이 처리해야 할지, 얼마나 많은 자율성을 허용할지 결정하세요.
강제 조치를 마련하는 것은 쉽습니다. 노력이 일치하도록 만드는 것이 진정한 가치가 축적되기 시작하는 지점입니다.
실용적인 레이어
이러한 더 큰 아이디어들이 자리 잡은 후, 몇 가지 작은 관행들이 거의 즉시 효과를 보였습니다.
- 규칙은 프롬프트가 아닌 시스템에 넣으세요. "메인 저장소를 편집하지 마세요"라고 말하는 프롬프트는 단지 조언일 뿐입니다. 차단된 도구 호출로 강제된 동일한 규칙은 무시하기 불가능해집니다. 중요한 규칙은 모델이 올바르게 행동하기로 선택하는 것에 의존해서는 안 됩니다.
- 상태를 대화 외부에 유지하고, 모든 작업에 새 작업자를 사용하세요. 작업 기록을 외부에 저장하고, 격리된 작업 트리를 사용하며, 병합 큐를 통해 변경 사항을 처리하세요. 상태가 채팅 외부에 존재하면, 컨텍스트 제한이 더 이상 가장 큰 제약 조건이 아닙니다. 작업은 병렬화, 재개 가능, 그리고 훨씬 더 추론하기 쉬워집니다.
- 교차 제공자 리뷰가 동일 제공자 리뷰보다 낫습니다. 모델은 다른 사람의 작업보다 자신의 작업에 대해 더 관대할 수 있습니다. 다른 제공자의 모델을 사용하는 것은 이러한 편향을 줄이는 간단하고 효과적인 방법입니다.
원칙이 효과를 보는 이유
이 아이디어들 중 어떤 것도 특정 모델에 의존하지 않습니다. 이는 시스템 엔지니어링, 즉 프로토콜, 검증, 리뷰 파이프라인, 책임 분리에 관한 것입니다.
벤치마크 최상위에 있는 모델은 계속해서 바뀔 것입니다.
하지만 원칙은 아마 변하지 않을 것입니다.
지속적인 가치는 모델에 있지도 않고, 기능에 있지도 않습니다. 그 가치는 모델 주변에 구축하는 구조에 있습니다.
