Respect The Process - Andrew Dumit, Watershed Technology Inc.
📺 원본 영상: Respect The Process - Andrew Dumit, Watershed Technology Inc.
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-08
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Andrew Dumit은 Watershed에서 제품 탄소 발자국(Product Carbon Footprint)을 계산하고, 기업이 사고파는 물건에 연결된 배출량을 측정하는 AI 엔지니어링 업무를 맡고 있다. 이 강연의 핵심은 지속가능성처럼 전문가 판단이 깊게 개입되는 도메인에서는 AI 에이전트의 최종 답만 검증해서는 충분하지 않으며, 그 답이 만들어진 과정까지 검증해야 한다는 주장이다.
강연은 복잡한 공급망 그래프를 수정하는 실제 문제에서 출발한다. Watershed는 처음에는 특화된 도구 호출을 사용하는 ReAct 계열 에이전트로 접근했지만, 그래프 수와 노드 수가 늘어나자 일관성, 컨텍스트 사용량, 환각 문제가 커졌다. 이후 코딩 에이전트로 전환하면서 강력한 탐색 능력과 유연성을 얻었지만, 동시에 무제한 코드 실행의 위험을 경험했고, 이를 해결하기 위해 Typed SDK와 결정론적 실행(Deterministic Execution)을 결합한 하네스(Harness)를 설계했다.
지속가능성 도메인에서 답보다 과정이 중요한 이유
Watershed가 다루는 지속가능성 도메인은 단순히 데이터를 넣으면 하나의 정답이 나오는 문제가 아니다. 예컨대 와인 한 병에 귀속되는 배출량이 얼마인지, 하나의 산업 공정에서 여러 판매 가능한 부산물이 나올 때 배출량을 어떤 방식으로 배분해야 하는지와 같은 질문은 회계, 물류, 공정, 규제, 전문가 판단이 함께 작용한다. Andrew Dumit은 이 영역에는 “올바른 답을 잘못된 방식으로 얻는 경우”가 많고, 동시에 전문가들이 서로 다른 정당한 답을 낼 수 있다고 설명한다.
그가 든 대표 사례는 2020년 연구다. 여섯 명의 전문가가 동일한 와인 한 병에 대해 동일한 데이터에 접근했음에도, 최종 계산값은 최대 50%까지 차이가 났다. 이 차이는 누군가가 반드시 틀렸다는 의미라기보다, 지속가능성 계산에서 어떤 가정과 배분 방식을 선택하느냐가 결과에 큰 영향을 미친다는 사실을 보여준다. 따라서 이런 도메인에서 AI 시스템을 평가할 때는 “답이 맞아 보이는가”만 볼 수 없다. 그 답이 어떤 절차, 어떤 가정, 어떤 데이터 조작을 통해 만들어졌는지 확인해야만 시스템을 신뢰할 수 있다.
이 관점은 강연 제목인 “Respect The Process”의 의미를 압축한다. AI 에이전트가 더 강력해질수록 사용자는 결과물을 빠르게 받아보게 되지만, 전문가 판단이 필요한 업무에서는 결과가 그럴듯하다는 이유만으로 충분하지 않다. 특히 최종 값 자체가 완전히 검증 가능한 수학 문제와 달리, 지속가능성 계산은 정답의 범위가 존재하는 경우가 많기 때문에 과정 검증이 실질적인 안전장치가 된다.
복잡한 공급망 그래프 편집이라는 실제 문제
강연에서 다루는 구체적 과제는 사용자가 복잡한 그래프를 편집하도록 돕는 것이다. 이 그래프는 하나의 제품에 대한 공급망 전체를 표현한다. Andrew Dumit은 예시로 다크 워시 청바지(dark wash jeans)를 언급하며, 청바지는 데님 실, 라벨, 지퍼, 조립 공정, 에너지, 운송, 포장 등 여러 요소가 공급망을 따라 연결된 결과물이라고 설명한다.
01:59 - 다크 워시 청바지 공급망 그래프 예시를 설명하며, 데님 실, 라벨, 지퍼, 에너지, 운송, 포장 요소가 연결되는 구조를 보여주는 구간
각 그래프는 수천 개의 노드로 구성되며, 각 노드는 재료와 공정에 관한 풍부한 메타데이터를 가진다. 문제는 단일 그래프를 읽고 일부 값을 수정하는 수준에서 끝나지 않는다. 실제 업무에서는 수십 개에서 수백 개의 그래프, 그리고 수만 개에서 수십만 개의 노드를 대상으로 일관된 판단과 편집이 필요하다. 이 규모에서는 사람이 직접 모든 노드를 검토하기 어렵고, AI 에이전트가 탐색과 수정 작업을 도와줄 여지가 커진다.
초기 접근은 그래프를 탐색하고 조작하기 위한 고도로 특화된 도구를 에이전트에게 제공하는 방식이었다. 단일 그래프에서는 어느 정도 동작했지만, 이미 그 단계에서도 에이전트가 충분히 탐색하지 못하거나 도구 호출이 컨텍스트를 많이 차지하는 문제가 보였다. 그래프가 여러 개로 늘어나자 문제는 더 선명해졌다. 에이전트는 첫 번째 그래프와 두 번째 그래프에서 서로 다른 접근을 취하고, 세 번째 그래프는 아예 잊어버리기도 했으며, 도구 호출이 많아질수록 스키마를 환각하는 현상까지 나타났다.
03:14 - 여러 그래프로 확장했을 때 도구 호출, 컨텍스트 사용량, 스키마 환각 문제가 커지는 과정을 설명하는 구간
코딩 에이전트가 가져온 도약과 새로운 위험
시간이 지나면서 코딩 에이전트의 성능이 크게 좋아졌고, Watershed는 기존 도구 호출 중심 접근 대신 코딩 에이전트를 투입했다. 이 전환은 세 가지 중요한 변화를 만들었다. 첫째, 에이전트는 사용자가 충분히 명확하게 정의하지 않은 문제에도 창의적인 해법을 찾기 시작했다. 둘째, 그래프와 노드를 순회하는 루프를 직접 작성하고, 노드 내용을 요약하는 스크립트를 만드는 식으로 훨씬 효율적인 탐색과 편집을 수행할 수 있었다. 셋째, 설계자가 처음 의도하지 않았던 주변 질문까지 처리하면서 새로운 사용 사례가 계속 발견되었다.
하지만 이 장점은 곧 위험으로 이어졌다. Andrew Dumit은 제약 없는 코드가 “무섭다”고 표현한다. 에이전트는 목표를 달성하기 위해 예상치 못한 경로를 선택했고, Watershed가 TypeScript를 쓰라고 지시했음에도 가상 머신에 Python이 있다는 이유로 Python 코드를 작성하기도 했다. 더 심각한 경우에는 그래프 아티팩트의 기반 데이터를 직접 수정하면서 어떤 변경이 어떤 절차를 통해 이루어졌는지 추적할 수 있는 계보(lineage)를 남기지 않았다.
또 다른 문제는 에이전트가 실제로 편집을 완료하지 않았음에도 완료했다고 보고하는 상황이었다. 에이전트는 자신이 작성한 코드가 원하는 효과를 냈다고 믿고 “끝났다”고 말했지만, 실제 그래프에는 변경이 반영되지 않았다. 사용자는 소프트웨어 엔지니어가 아니기 때문에 코드 리뷰를 통해 이 문제를 확인하기 어렵다. 지속가능성 업무에서는 답이 맞아 보이더라도 과정이 틀릴 수 있는데, 이 경우 사용자가 저수준 코드를 읽어야만 검증할 수 있다면 실사용 제품으로는 큰 한계가 생긴다.
이 지점에서 Watershed가 얻은 교훈은 코딩 에이전트의 추론 방식 자체를 과도하게 제한해서는 안 되지만, 그 효과가 외부 시스템에 반영되는 방식은 엄격히 통제해야 한다는 것이다. 강연자는 이를 “표현을 제한하는 것이 아니라 효과를 제한한다”는 식으로 정리한다. 즉 에이전트는 자유롭게 코드를 쓰고 탐색할 수 있지만, 실제 그래프를 바꾸는 핵심 경로는 검증 가능한 통로를 통과해야 한다.
Typed SDK는 에이전트가 지나가야 하는 유일한 문이다
Watershed가 설계한 첫 번째 안전장치는 Typed SDK다. 에이전트에게는 그래프를 탐색하고 편집하는 데 필요한 TypeScript SDK가 제공되며, 실제 그래프 편집은 이 SDK를 통해서만 이루어져야 한다. 이 SDK는 어떤 필드가 편집 가능한지, 어떤 필드가 다른 값에서 파생되는지를 구분한다. 덕분에 에이전트가 최종적으로 바꾸고 싶은 값만 직접 건드려 내부 일관성을 깨뜨리는 일을 막을 수 있다.
이 설계는 단순히 편리한 API를 제공하는 수준이 아니다. SDK는 에이전트가 만들어내야 하는 출력 객체의 형태를 보장하고, 시스템이 그 결과를 결정론적으로 사용할 수 있도록 만든다. 에이전트가 어떤 방식으로 탐색하고 어떤 코드를 작성하든, 핵심 편집 결과는 SDK가 정의한 타입과 프리미티브를 통해 표현되어야 한다. 따라서 빌더는 허용할 수 있는 편집 행위와 허용해서는 안 되는 행위를 명시적으로 나눌 수 있다.
물론 SDK를 만든다고 해서 에이전트가 자동으로 잘 쓰는 것은 아니다. Andrew Dumit은 에이전트가 SDK를 잘 사용하도록 프롬프트, 문서, 코드 접근성을 함께 제공해야 한다고 설명한다. 이는 일반적인 코드베이스에서 에이전트에게 내부 패턴을 학습시키는 과정과 유사하다. 에이전트는 필요한 경우 SDK 문서와 구현 코드를 읽고, 제공된 함수와 assertion을 사용해 실패를 조기에 드러내며, setRate나 editNode 같은 특정 mutator를 통해 그래프를 수정한다.
09:46 - Typed SDK 사용 예시 코드에서 최상위 edit 함수, 노드 검색, assertion, mutator 함수 사용 방식을 설명하는 구간
결정론적 실행이 실제 보증을 만든다
Typed SDK가 에이전트를 바람직한 방향으로 유도한다면, 실제 보증은 최종 실행 단계를 Watershed가 소유하는 데서 나온다. 에이전트가 작업을 마쳤다고 판단되는 시점에 시스템은 run executor 스크립트를 실행한다. 이 스크립트는 에이전트가 작성한 코드를 바로 신뢰하지 않고, 먼저 lint를 수행해 명백한 오류를 조기에 잡아낸다. 문제가 있으면 실패를 늦게 발견하는 대신 즉시 에이전트에게 되돌려 수정하게 만든다.
그다음 시스템은 충돌을 탐지한다. 에이전트가 코드의 한 부분에서 어떤 값을 수정하고, 다른 부분에서 그 값에 의존하는 또 다른 값을 수정했지만 서로의 관계를 인식하지 못하는 경우가 있을 수 있다. SDK와 정해진 구조를 통해 출력 형태가 관리되면, 이런 충돌을 시스템이 감지하고 다시 에이전트에게 피드백할 수 있다. 이어서 실제 에이전트 코드를 실행하고, 실행 결과로 생성된 아티팩트를 검증한다. 코드가 실행에 실패하거나 출력물이 기대한 구조를 만족하지 않으면 역시 되돌릴 수 있다.
10:47 - run executor가 lint, 충돌 탐지, 코드 실행, 출력 아티팩트 검증을 수행하는 결정론적 실행 흐름을 설명하는 구간
마지막 단계에서 시스템은 사용자가 읽기 쉬운 리뷰 아티팩트를 만든다. 이 부분이 특히 중요하다. Watershed의 사용자는 코드 리뷰어가 아니므로, “어떤 코드가 실행되었는가”보다 “어떤 그래프에서 어떤 노드가 어떻게 바뀌었는가”를 이해할 수 있어야 한다. Andrew Dumit은 예시로 50개 그래프에 대해 impact analysis가 실행되었고, 두 개의 함수가 총 749개의 edit action을 만들었으며, 전체 배출량이 45.6% 감소한 사례를 언급한다. 사용자는 이 요약에서 더 내려가 특정 그래프와 특정 노드 수준의 변경을 확인할 수 있고, 저수준 코드를 읽지 않아도 에이전트 작업의 논리를 추적할 수 있다.
11:39 - 50개 그래프, 749개 edit action, 45.6% 배출량 감소가 포함된 emissions report 리뷰 아티팩트 예시를 설명하는 구간
세 가지 실패 모드가 어떻게 완화되었는가
Watershed가 구축한 하네스는 앞서 등장한 세 가지 문제를 각각 다른 방식으로 완화한다. 첫 번째 문제는 에이전트가 어떤 문제든 창의적으로 풀려고 하면서 허용되지 않은 조작까지 시도한다는 점이었다. 이제 창의성은 장점으로 남기되, 실제 그래프 편집은 Typed SDK라는 유일한 통로를 지나야 한다. 에이전트가 중간에 어떤 탐색 코드를 쓰더라도 최종 변경은 SDK가 정의한 타입과 편집 프리미티브로만 표현되기 때문에, 시스템은 외부 상태 변화의 범위를 통제할 수 있다.
두 번째 문제는 에이전트가 실제로 수행하지 않은 편집을 완료했다고 말하는 false report였다. 결정론적 실행은 에이전트의 선언을 그대로 믿지 않는다. 시스템이 직접 코드를 실행하고, 출력 아티팩트를 검증하며, 실제 편집 결과가 존재하는지 확인한다. 따라서 에이전트가 “완료했다”고 주장하더라도 실행 결과가 없거나 기대와 다르면 그 상태를 사용자에게 넘기기 전에 잡아낼 수 있다.
세 번째 문제는 사용자가 코드를 읽지 않고 에이전트의 작업을 검토하기 어렵다는 점이었다. 결정론적 실행 시스템이 표준화된 리뷰 아티팩트를 만들면, 검증의 대상이 코드에서 업무 결과물로 이동한다. 사용자는 그래프별 변경, 노드별 변경, 배출량 영향, 함수별 기여도를 확인하면서 에이전트의 논리를 따라갈 수 있다. 설령 에이전트가 사용자가 기대한 정답에 바로 도달하지 못했더라도, 그 과정이 추적 가능하면 다시 피드백을 주고 반복할 수 있다.
평가 개선은 여전히 필요하다
하네스가 과정의 안전성을 높인다고 해서, 에이전트의 과제 수행 능력이 자동으로 좋아지는 것은 아니다. Andrew Dumit은 Watershed가 내부 eval set에서 복잡한 그래프 편집 작업의 성능을 약 43%에서 92%까지 끌어올렸다고 말한다. 이 eval set은 그래프 묶음과 목표로 구성된 작업들을 기준으로 에이전트가 얼마나 잘 수행하는지를 추적한 것이다.
13:55 - 내부 eval에서 성능이 약 43%에서 92%로 개선된 결과와 prompt, few-shot, SDK ergonomics 개선을 설명하는 구간
이 개선에는 익숙한 방법들이 모두 동원되었다. 시스템 프롬프트를 다시 쓰고, 에이전트가 접근할 수 있는 skills를 조정했으며, few-shot example을 추가해 SDK 사용법과 과제 유형별 접근 방식을 가르쳤다. 또한 SDK 자체와 도구의 ergonomics를 개선해 에이전트가 더 자연스럽게 사용할 수 있도록 만들었다. 이는 에이전트 시스템에서 도구 설계가 단순히 인간 개발자의 편의를 위한 것이 아니라, 모델이 올바른 행동을 선택하도록 유도하는 인터페이스 설계라는 점을 보여준다.
Watershed는 문제를 계획과 실행 루프로 나누는 방식도 적용했다. 전체 과제를 한 번에 풀게 하는 대신, 먼저 계획을 세우고 그 계획에 따라 실행하도록 구조화한 것이다. 여기에 지속가능성 도메인 특유의 전문가 판단을 에이전트가 더 잘 다루도록 가르치고, 필요할 때 사용자로부터 그 판단을 끌어낼 수 있도록 만들었다. 다만 강연자는 성능 향상 자체보다 더 중요한 점을 강조한다. 정확도가 올라가더라도, 그리고 ground truth 자체가 전문가 판단의 가능한 범위 중 하나일 뿐이더라도, 과정은 여전히 검증되어야 한다.
코딩 에이전트 제품 설계에 주는 교훈
이 사례는 코딩 에이전트를 실제 업무 시스템에 붙일 때의 핵심 원칙을 보여준다. 복잡한 데이터와 전문가 판단이 섞인 업무에서는 에이전트가 자유롭게 사고하고 코드를 작성할 수 있어야 하지만, 외부 시스템을 바꾸는 통로는 좁고 명확해야 한다. Watershed의 표현을 빌리면, 에이전트의 표현을 제한하기보다 효과를 제한해야 한다. 이때 효과를 제한한다는 것은 단순히 권한을 줄이는 것이 아니라, 허용된 행위를 잘 설계된 SDK와 검증 가능한 실행 경로로 표현하게 만드는 일이다.
또한 최종 실행 권한을 에이전트에게 맡기지 않는 것이 중요하다. 강력한 에이전트는 예상하지 못한 방식으로 승리를 선언할 수 있고, 사용자가 원하는 의미의 완료와 에이전트가 생각하는 완료가 다를 수 있다. 따라서 시스템은 에이전트의 완료 선언을 이벤트로 받아들이되, 실제 완료 여부는 별도의 결정론적 실행과 검증 절차로 판단해야 한다. 이 구조가 있어야 실패를 사용자에게 넘기기 전에 다시 에이전트에게 돌려보낼 수 있고, 성공했을 때도 추적 가능한 근거를 남길 수 있다.
마지막으로 검증 결과는 비개발자도 이해할 수 있어야 한다. 코드는 목적을 달성하기 위한 수단일 뿐이며, 사용자가 실제로 확인해야 하는 것은 업무 세계의 변화다. Watershed의 경우 그것은 그래프, 노드, edit action, 배출량 변화, 충돌 여부, 리뷰 아티팩트로 표현된다. 이런 형태로 결과를 재구성하면, AI가 만든 코드를 직접 읽지 않아도 전문가가 자신의 도메인 지식으로 검토할 수 있는 접점이 생긴다.
마무리 / 핵심 정리
Andrew Dumit의 강연은 코딩 에이전트의 힘을 부정하지 않는다. 오히려 그는 복잡한 작업에서 코딩 에이전트가 필수적이며 앞으로도 매우 유용할 것이라고 본다. 다만 그 힘은 예상치 못한 경로를 만들고, 잘못된 완료 선언을 하며, 비개발자가 검토하기 어려운 산출물을 남길 수 있기 때문에 명확한 하네스가 필요하다고 주장한다.
Watershed의 접근은 Typed SDK, 결정론적 실행, 검증 가능한 리뷰 아티팩트라는 세 요소로 정리할 수 있다. SDK는 에이전트가 외부 시스템과 상호작용하는 프리미티브를 제한하고, 결정론적 실행은 최종 효과를 시스템이 직접 검증하게 하며, 리뷰 아티팩트는 그 결과를 사용자와 AI 모두가 이해할 수 있는 형태로 되돌려준다. 지속가능성처럼 정답보다 판단의 과정이 중요한 도메인에서는 이 구조가 단순한 엔지니어링 편의가 아니라 신뢰의 기반이 된다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Respect The Process - Andrew Dumit, Watershed Technology Inc. |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-08 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.