Respect The Process - Andrew Dumit, Watershed Technology Inc.

한 줄 핵심

복잡한 판단이 필요한 도메인에서는 코딩 에이전트의 자유도를 높이기보다, 정해진 SDK와 결정적 실행으로 과정 자체를 검증해야 안전하게 성능을 낼 수 있다.

시간별 요약

1. 0:00
   Watershed의 탄소·배출량 산정 업무는 전문가 판단이 많이 개입되는 영역이라, 정답만 맞추는 것보다 그 정답이 나온 과정을 검증하는 것이 더 중요하다. 같은 데이터로도 전문가 답이 크게 달라질 수 있어, 결과만 맞는 시스템은 충분하지 않다.
2. 2:01
   복잡한 공급망 그래프를 편집하는 작업은 노드 수와 메타데이터가 방대해 일반적인 에이전트가 쉽게 무너진다. 도구 호출이 늘수록 컨텍스트가 소모되고 일관성이 깨지며, 여러 그래프를 다룰 때는 환각과 재시도가 급증한다.
3. 4:00
   coding agent를 도입하자 탐색·편집 효율과 유연성은 크게 좋아졌지만, 무제한 코드 실행은 예상 밖의 경로로 문제를 해결하거나 잘못된 편집을 수행하는 위험도 키웠다. 사용자는 코드 자체를 읽어 검토하기 어렵기 때문에, 결과만으로는 작업의 타당성을 보장하기 힘들어졌다.
4. 8:01
   해결책은 표현의 자유를 막는 것이 아니라 효과를 제한하는 것이었다. 에이전트는 자유롭게 코드를 작성하되, 실제 그래프 편집은 typed SDK를 통과해야 하고 최종 실행은 시스템이 통제하여 lint, 충돌 탐지, 검증, 재시도를 수행한다.
5. 11:00
   결정적 실행으로 생성된 산출물은 비개발자도 검토 가능한 형태의 리뷰 아티팩트로 바뀌며, 그래프 단위로 무엇이 어떻게 바뀌었는지 추적할 수 있다. 이 덕분에 에이전트가 틀렸거나 예상과 다르게 동작해도, 사용자와 시스템 모두가 원인을 따라가며 복구할 수 있다.
6. 14:01
   하네스만으로는 부족하고, 프롬프트 개선·few-shot 예시·도구 ergonomics 개선·plan/execute 루프 설계로 태스크 성능도 계속 끌어올려야 한다. 내부 eval 기준 성능이 43%에서 92%로 개선됐지만, 핵심은 정확도 향상과 별개로 과정의 신뢰성을 항상 보장하는 구조를 유지한 점이다.

실무 인사이트

• 정답이 하나로 고정되지 않는 업무일수록 결과 검증보다 과정 검증에 먼저 투자해야 하며, 이를 위해 에이전트의 행동을 SDK와 실행 파이프라인으로 강하게 제한하는 것이 효과적이다.
• 코드를 잘 쓰는 에이전트보다 중요한 것은 그 코드가 실제로 의도한 변화를 만들었는지 확인하는 능력이며, 결정적 실행과 사람이 읽기 쉬운 리뷰 산출물이 그 간극을 줄인다.
• 성능 개선은 하네스 설계와 별개로 프롬프트, 예시, 도구 인터페이스, 루프 구조를 지속적으로 다듬는 방식으로 이루어져야 한다.