AI 에이전트의 Slop을 없애는 결정론적 상태 머신 구조

원문 제목: [한영자막] AI 에이전트의 엉망진창 결과물(Slop)을 없애려면 '이 구조'를 도입해야 합니다
URL: https://www.youtube.com/watch?v=D7q8fa589FY
영상 ID: D7q8fa589FY
채널: Tech Bridge
발행일: 2026-10-08
처리일: 2026-10-08
발표자: David Khourshid (@DavidKPiano), Stately 창립자·XState 제작자

---

📌 핵심 질문 / 에이전트의 Slop을 줄이는 구조

==AI 에이전트에게 판단·구조·구현·취향을 한꺼번에 위임하는 대신, 비결정론적인 생성 작업과 결정론적인 상태·전이 규칙을 분리해야 에이전트의 행동을 관측하고 스스로 개선할 수 있다.==

• 같은 입력에 예측 가능한 다음 상태를 반환하는 상태 머신이 에이전트 워크플로의 안전한 뼈대가 된다.
• 자연어 메가 프롬프트 안에 숨겨 둔 제어 흐름은 컨텍스트가 길어질수록 희미해지고, 실패 지점을 가리키기 어렵다.
• 상태·이벤트·전이를 구조화하면 단계별 결과, 전체 결과, 전이의 적절성을 각각 평가하고 V1과 V2를 비교할 수 있다.

에이전트의 창의성과 유연성을 없애자는 주장이 아니다. 이메일 문안이나 사용자의 질문처럼 무한히 다양한 생성 영역은 모델에 맡기되, 초안 작성 후 검토, 명시적 승인 후 전송, 수신자 누락 시 전송 금지처럼 반드시 지켜야 하는 규칙은 그래프와 상태 머신에 고정한다. 실행 흔적과 평가 결과를 상태 머신에 되돌려 넣으면 에이전트가 자기 워크플로를 개선하는 루프까지 만들 수 있다.

1. 결정론과 상태 머신의 기초

상태 머신은 현재 상태와 발생한 이벤트가 다음 상태를 결정하는 구조이며, 에이전트의 자유로운 생성 능력과 충돌하지 않고 행동의 경계를 명시하는 데 쓰인다.

1.1. 상태와 이벤트가 만드는 예측 가능한 전이

1. 상태 머신의 최소 관계

   1. 현재 상태와 이벤트: 애플리케이션은 어떤 상태에 있다가 이벤트를 받는다.
   2. 다음 상태: 같은 상태에서 같은 이벤트가 발생하면 예측 가능한 다음 상태에 도달한다.
   3. 결정론: 동일한 입력에 매번 동일하고 예측 가능한 결과를 얻는 성질이 결정론(determinism)이다.

2. 일상적 비유로 본 복잡도 증가

   1. 신생아의 단순 루프: 아기가 울면 먹이고, 먹으면 배부른 상태가 되고, 잠들고, 깨어나면 다시 우는 순환이 반복된다.
   2. 루프에서 그래프로: 생후 약 3개월이 되면 상태가 복잡해지고, 수면 퇴행기에는 명확한 원인을 알 수 없는 불만과 예외가 생겨 전이가 훨씬 많은 그래프처럼 변한다.
   3. 에이전트와의 대응: 에이전트 분야도 단순한 루프에 대한 열광에서 여러 노드와 전이를 가진 그래프에 대한 관심으로 이동했지만, 루프 역시 그래프의 한 형태다.

1.2. 발표의 배경과 적용 범위

1. 발표자의 작업 기반

   1. XState: David Khourshid가 만든 오픈소스 상태 머신 라이브러리다.
   2. Stately: 발표자가 창립한 회사이며, 모든 구현에 Stately나 XState를 써야 한다는 판매 목적의 주장은 아니다.
   3. 이름에 관한 농담: @DavidKPiano라는 핸들은 발표자의 피아노 연주 취향을 반영하며, ‘Piano’는 성이 아니다. 폴란드에서 쇼팽을 아는지 청중에게 묻는 농담으로 소개를 열었다.

2. 문제의식의 연속성

   1. 이전 Agent Conf: 3년 전에는 에이전트 행동을 상태 머신으로 제한하는 방법을 이야기했다.
   2. 이번 접근: 이번에는 상태 머신과 결정론을 이용해 이미 만든 에이전트의 행동을 개선하고 Slop을 제거하는 방법에 초점을 맞춘다.
   3. Agent Conf의 목표: 사용자가 원하지 않는 엉망진창 결과물을 줄이고, 예측 가능한 에이전트를 만드는 것이 목표다.

2. Slop의 근원과 메가 프롬프트의 한계

에이전트의 Slop은 모델이 무조건 무능해서가 아니라 구조화되지 않은 위임(unstructured delegation)에서 주로 생긴다.

2.1. 모든 판단을 한 번에 넘기는 위임

1. 무제한 위임의 구성

   1. 판단의 위임: 사용자가 에이전트에게 무엇을 선택할지까지 맡긴다.
   2. 구조의 위임: 작업 순서와 제약을 별도의 실행 구조로 만들지 않고 에이전트가 알아서 구성하게 한다.
   3. 구현과 취향의 위임: 실제 구현뿐 아니라 결과의 스타일과 품질 기준까지 모델에 맡긴다.

2. 강력해진 모델에도 남는 위험

   1. 능력의 향상: 모델은 예전보다 많은 일을 처리하고, 환각이나 어리석은 실수를 덜 한다.
   2. Slop의 잔존: 작업을 통째로 벽 너머로 던지고 최선을 기대하면, 여전히 예측 불가능한 결과가 나온다.
   3. 실패의 진짜 문제: “대체로 잘 된다”는 상태는 “작동하지 않는 순간”까지 유효할 뿐이며, 실패했을 때 어떤 지점을 고쳐야 하는지 가리킬 구조가 없다.

2.2. 메가 프롬프트에 제어 흐름을 숨길 때 생기는 문제

1. 프롬프트 속 절차의 중복

   1. 자연어 제어 흐름: “먼저 초안을 만들고, 사용자가 수정을 요청하면 고치고, 명시적으로 승인하기 전에는 전송하지 말라”는 순서를 하나의 긴 프롬프트에 적는다.
   2. 도구 설명의 반복: 이메일 전송 도구에도 “사용자 승인 후에만 호출하라”는 같은 규칙을 다시 적는다.
   3. 잘못된 책임 배치: 도구는 기능을 제공해야 하는데, 메가 프롬프트에서는 도구 설명이 제어 흐름까지 떠안는다.

2. 블랙박스와 규칙 감쇠

   1. 분리되지 않은 단계: 모든 작업이 하나의 모델, 하나의 시스템 프롬프트, 하나의 설정에 묶여 각 단계에 맞는 전략을 선택할 수 없다.
   2. 검증 불가능성: 긴 프롬프트가 실제로 작동하는지 증명하기 어렵고, 추론을 켜더라도 에이전트가 어떤 방식으로 작동했는지 확인하기 어렵다.
   3. 컨텍스트에 따른 규칙 약화: 규칙도 다른 문장과 똑같은 텍스트이므로 대화와 실행 컨텍스트가 쌓이면 상대적 중요도가 낮아진다.
   4. 실패 지점의 불투명성: 문단 속 어느 문장에서 흐름이 잘못됐는지 화살표로 표시할 수 없고, 전략별로 다른 모델·설정을 적용하기도 어렵다.

3. 이메일 에이전트로 분리하는 결정론과 생성

이메일 작성은 무한히 다양한 문안을 생성해야 하지만, 전송 과정에는 엄격한 불변 규칙이 있으므로 결정론과 비결정론을 나누기 좋은 예시가 된다.

3.1. 생성 영역과 규칙 영역의 경계

1. 비결정론적인 영역

   1. 이메일 내용: 같은 요청이라도 표현·톤·구성이 달라질 수 있는 문안 생성은 모델의 역할이다.
   2. 명확화 질문: 무엇을 포함할지 불분명하면 에이전트가 사용자에게 추가 질문을 할 수 있다.
   3. 피드백 루프의 초안: 사용자 수정 요청을 반영해 여러 번 만들어지는 초안은 생성적이고 가변적이다.

2. 결정론적인 영역

   1. 초안 선행: 이메일은 반드시 먼저 작성되어야 하며 초안 없이 전송할 수 없다.
   2. 승인 필수: 사용자가 “이 이메일을 보내겠다”고 명시적으로 승인한 이메일만 전송할 수 있다.
   3. 수신자 불변 규칙: 수신자를 지어내서는 안 되며, 수신자가 없으면 전송할 수 없다.

3.2. 상태 머신으로 표현한 이메일 흐름

1. 기본 상태 전이

   1. 초안 작성 상태: 사용자의 요청을 받아 이메일 초안을 생성한다.
   2. 검토 상태: 누락된 정보나 수정 요청을 처리하고, 사용자의 피드백을 반영한다.
   3. 전송 상태: 필요한 수신자와 승인이 확보된 뒤에만 전송한다.

2. 구조가 보장하는 안전성

   1. 누락 정보 처리: 수신자·제목·본문·발신자 이름이 빠지면 검토 상태에서 추가 정보를 요청한다.
   2. 전송 전 조건: 수신자가 없는 초안·검토 상태에는 전송으로 가는 전이가 아예 존재하지 않는다.
   3. 수학적 불가능성: 모델이 실수로 전송 도구를 호출하려 해도 현재 상태에서 전송 전이가 정의되어 있지 않으면 이메일을 보낼 수 없다.

3.3. 첫 번째 이메일 데모의 흐름

1. 불완전한 요청에서 정보 수집까지

   1. 초기 요청: “Jenny에게 발표 후 커피를 마시자고 초대하는 이메일을 써 달라”는 일부러 모호한 요청을 입력한다.
   2. 추가 질문: 에이전트는 Jenny의 이메일 주소와 제목 등 빠진 정보가 있다고 알린다.
   3. 제목 입력: 제목으로 “coffee”를 입력하자 에이전트는 본문에 무엇을 쓸지 다시 묻는다.

2. 검토와 전송의 허점

   1. 시간 절약을 위한 생략: 발표자는 시간이 부족해 “일단 초안을 작성하라”고 입력했고, 에이전트는 계속 검토 단계로 진행했다.
   2. 발신자 이름: 에이전트가 이름을 묻자 “David”라고 입력했다.
   3. 누락된 수신자: 단계별 흐름은 전송까지 갔지만 이메일 주소를 입력하지 않은 사실이 뒤늦게 드러났다.
   4. 시뮬레이션 아웃박스: 최종 이메일은 실제 수신자에게 가지 않고 시뮬레이션된 보낼 편지함에 들어갔다.
   5. 데모의 의도: 상태 머신이 안전한 경계를 제공하더라도 현재 모델링이 사용자 관점에서 가장 빠르고 편한 워크플로라는 뜻은 아니며, 바로 그 개선 여지를 다음 단계에서 다룬다.

4. 명시적 모델링과 관측 가능성

모델링은 절차를 복잡하게 꾸미는 의식이 아니라 사람과 에이전트 모두의 혼란을 대체하는 공통 구조다.

4.1. 언제 모델링이 유용한가

1. 공통 이해의 형성

   1. 사람의 이해: 개발자는 각 단계와 가능한 전이를 보고 어디에서 문제가 생겼는지 파악한다.
   2. 에이전트의 자기 점검: 에이전트도 자신이 어떤 상태에 있고 어떤 전이가 가능한지 내성적으로 살펴볼 수 있다.
   3. 선택적 적용: 모든 에이전트를 형식적인 상태 머신으로 만들 필요는 없으며, 명시적인 흐름과 안전장치가 필요한 곳에 적용한다.

2. 암묵적 구조와의 차이

   1. 문단의 한계: 긴 프롬프트의 문단 안에는 실제 제어 흐름을 화살표로 그리거나 실패 지점을 특정하기 어렵다.
   2. 명시적 구조의 장점: 상태와 전이가 별도 요소로 드러나므로 어느 경로를 조정해야 할지 논의할 수 있다.
   3. 결과의 수렴: 서로 다른 복잡한 실행 경로도 같은 sent 상태에 도달했는지 비교할 수 있다.

4.2. 구조화된 로그

1. 로그의 단위

   1. 상태: 현재 에이전트가 drafting, reviewing, sent 중 어디에 있는지 기록한다.
   2. 이벤트: 사용자 승인, 정보 입력, 수정 요청 등 어떤 이벤트가 발생했는지 기록한다.
   3. 전이와 결과: 이벤트 이후 어느 상태로 이동했고 어떤 이메일을 보냈는지 구조화해 기록한다.

2. 관측 가능성의 효과

   1. 단순·복잡 경로 비교: 짧은 경로와 여러 번의 수정이 포함된 경로가 모두 최종적으로 이메일을 보냈다는 사실을 동일한 상태로 확인한다.
   2. 텍스트 추론과 구별: 단순히 모델이 “생각했다”고 출력한 텍스트가 아니라 실행 가능한 상태와 이벤트 로그를 확보한다.
   3. 문제 해결의 기준: 실패한 상태, 허용되지 않은 전이, 과도하게 반복된 단계를 구체적인 분석 대상으로 삼는다.

5. 상태·전이·전체 워크플로 평가

상태 머신은 실행을 통제하는 그림에 그치지 않고, 단계별 품질과 경로 선택의 품질을 평가하는 내구성 있는 작업 산출물이 된다.

5.1. 평가를 세 층으로 나누기

1. 각 상태의 결과 평가

   1. 초안 상태: 특정 입력에 대해 기대하는 이메일 초안이 생성됐는지 평가한다.
   2. 단계별 기준: 한 단계의 입력·출력 쌍을 검사하므로 전체 과정이 끝난 뒤에만 알 수 있는 오류를 조기에 찾을 수 있다.

2. 전체 결과 평가

   1. 최종 목표: 초기 입력이 전체 절차를 통과한 뒤 기대한 이메일 결과에 도달했는지 본다.
   2. LLM 심판: 전체 산출물은 LLM-as-judge 같은 방식으로 평가할 수도 있다.
   3. 통과의 한계: 최종 이메일이 존재하더라도 불필요하게 여러 단계를 거쳤다면 사용자 경험은 나쁠 수 있다.

3. 전이(edge) 평가

   1. 빠진 평가 대상: 상태와 최종 결과만 평가하면 “작동은 하지만 왜 이렇게 답답한가”라는 경로의 문제를 놓친다.
   2. 전이의 품질: 어떤 이벤트에서 어떤 다음 상태를 택했는지, 불필요한 반복이나 잘못된 질문을 했는지를 별도로 평가한다.
   3. 개선의 단서: 전이 평가가 있어야 상태 머신 자체를 수정할 구체적인 근거가 생긴다.

5.2. 상태 머신을 에이전트에게 넘기는 개선 방법

1. 내구성 있는 입력 묶음

   1. 워크플로 정의: 현재 상태 머신과 모든 상태·전이를 제공한다.
   2. 실행 흔적: 실제 사용자 또는 자체 테스트(dogfooding)의 샘플 워크플로에서 나온 트레이스를 함께 제공한다.
   3. 평가 결과: 각 단계의 평가와 전체 머신의 평가를 함께 넣는다.

2. 개선 제안의 역할 분리

   1. 검토 에이전트: 실행을 담당한 에이전트와 같은 모델일 필요가 없는 별도의 에이전트가 현재 워크플로를 점검한다.
   2. 제안의 질문: “이 상태 머신을 바탕으로 어떤 변경을 하면 에이전트를 개선할 수 있는가?”를 묻는다.
   3. Stately의 경험: Stately의 소프트웨어 팩토리에서 상태 머신 생성·편집 파이프라인에 이 방식을 적용했고, 실제 개선이 잘 작동했다.

5.3. 이메일 워크플로 V1에서 V2로

1. V1의 병목

   1. 불필요한 다중 패스: 작은 문제를 고치기 위해 이메일을 여러 차례 검토·수정하는 흐름이 생겼다.
   2. 최종 성공과 사용자 경험의 분리: 모든 평가를 통과하고 이메일을 보내더라도 사용자는 답답한 과정을 겪을 수 있다.

2. V2의 구조적 개선

   1. 초안 우선: 먼저 이메일 초안을 만들고, 그 뒤 무엇이 부족한지 판단하도록 순서를 바꿨다.
   2. 직행 검토: 초안 작성 후 곧바로 검토 상태로 이동해 필요한 수정만 받는다.
   3. 수정과 전송: “내 이름은 David” 같은 정보를 추가한 뒤 검토를 거쳐 전송한다.
   4. A/B 비교: 같은 시나리오를 V1과 V2에서 실행해 어느 쪽이 더 나은지 체감과 평가 결과를 비교한다.
   5. 최적화 조건: V1이 통과했다는 사실만으로는 충분하지 않으며, 실제 반복 실행과 개선 과정을 거쳐야 최적 결과에 가까워진다.

6. 에이전트 자기 개선을 위한 최소 실행 루프

특별한 프레임워크가 없어도 상태 머신을 만들고 관찰하고 개선안을 비교하는 작은 루프로 에이전트 엔지니어링을 시작할 수 있다.

6.1. 구현에 필요한 최소 구성

1. 상태 기반 실행기

   1. 시작 상태: 초기 상태를 정의하고 “완료”의 조건을 정한다.
   2. 활성 상태 반복: 상태가 활성인 동안 LLM 호출, 도구 호출, 외부 비동기 프로세스를 실행한다.
   3. 다음 상태 결정: 현재 상태와 방금 발생한 이벤트에 따라 다음 상태와 실행할 효과(effect)를 결정한다.

2. 구현 도구의 선택

   1. 상태 머신 라이브러리: XState를 사용할 수 있다.
   2. 간단한 코드: switch 문이나 reducer 함수만으로도 같은 구조를 표현할 수 있다.
   3. 에이전트 프레임워크: LangGraph는 에이전트에 상태 머신을 적용하는 인기 있는 도구 중 하나다.
   4. 코딩 에이전트의 역할: 어떤 방식을 택하든 코딩 에이전트가 상태와 전이 로직을 업데이트하는 데 도움을 줄 수 있다.

6.2. 생성-관찰-제안-비교 루프

1. 모델 생성: 현재 요구사항을 만족하는 상태 머신을 만든다.
2. 실행 관찰: 모든 상태 전이를 추적하고 구조화된 로그와 트레이스를 쌓는다.
3. 개선안 제안: 별도의 에이전트가 상태 머신과 실행 흔적을 보고 현재 워크플로의 개선 아이디어를 제시한다.
4. 버전 비교: 동일하거나 유사한 시나리오를 V1과 V2에서 실행해 실제 개선 여부를 확인한다.
5. 반복: 결과가 좋아졌다는 근거가 있을 때 새 버전을 채택하고 다시 관찰·평가한다.

6.3. 관련 연구와 개념적 계보

1. 선행 사례

   1. Agent Spec: 에이전트 행동과 명세를 다루는 관련 연구로 언급된다.
   2. AIFlow: 흐름과 구조를 명시적으로 다루는 관련 사례로 언급된다.
   3. 프로세스 마이닝: 약 20년 전부터 이벤트 트레이스를 분석해 형식 모델로 추출하고 최적화 지점을 찾던 분야다.

2. 공통 원리

   1. 트레이스의 모델화: 이벤트가 발생한 순서를 모아 상태 머신 같은 형식 모델로 증류한다.
   2. 최적화 지점 발견: 모델과 실제 흔적의 차이를 비교해 불필요한 전이와 개선 가능한 흐름을 찾는다.
   3. 고정된 정답이 아님: 상태 머신을 에이전트가 항상 따라야 하는 유일한 실행 방식으로 강제하는 것이 아니라 자기 개선을 가능하게 하는 발판으로 사용한다.

7. 가드레일에서 자기 개선으로

그래프는 에이전트를 정직하게 만드는 경계였고, 같은 그래프 사고방식은 이제 에이전트가 자신의 행동을 더 나은 방향으로 바꾸는 수단이 된다.

7.1. 2023년의 그래프와 2026년의 그래프

1. 초기 역할

   1. 경계 제공: 상태 머신과 그래프는 에이전트가 할 수 있는 행동의 범위를 제한한다.
   2. 가드레일: 허용되지 않은 상태 전이를 제거해 에이전트가 규칙을 벗어나지 않게 한다.

2. 확장된 역할

   1. 행동의 기록: 동일한 그래프 안에서 실제로 어떤 경로를 택했는지 관찰한다.
   2. 자기 개선: 에이전트가 자신의 상태 머신과 트레이스를 읽고 개선된 V2 구조를 제안한다.
   3. 핵심 전환: 그래프는 단순히 에이전트를 가두는 구조가 아니라, 성능을 검증하고 개선하는 공통 언어가 된다.

7.2. 그래프를 정답으로 오해하지 않기

1. 유연성의 보존

   1. 생성의 자유: 이메일 문안처럼 다양한 표현이 필요한 부분은 계속 비결정론적으로 생성한다.
   2. 규칙의 고정: 안전·승인·순서처럼 위반하면 안 되는 부분만 결정론적으로 통제한다.
   3. 선택적 형식화: 복잡성과 위험이 실제로 발생하는 부분만 명시적으로 모델링한다.

2. 개선의 기준

   1. 단일 실행의 성공 불충분: 한 번 최종 상태에 도달했다고 좋은 워크플로가 확정되는 것은 아니다.
   2. 반복 가능한 실험: 같은 시나리오를 여러 버전에서 실행하고 단계·전이·전체 결과를 평가해야 한다.
   3. 사용자 경험 포함: 기능적 성공뿐 아니라 질문 횟수, 반복 패스, 대기와 같은 과정의 품질도 평가한다.

8. Jev와 가상 에스프레소 머신 데모

새로운 에이전트 프레임워크 Jev와 상태 머신으로 가상 바리스타를 실행해, 결정론적 그래프 안에서 비결정론적 에이전트가 외부 고장까지 복구하는 모습을 보여준다.

8.1. 데모를 만들게 된 계기

1. Jev에 대한 관심

   1. Type Safe의 발표: 발표 며칠 전 Type Safe가 Jev를 공개했고, 발표자는 이를 보고 즉시 호기심이 생겼다.
   2. 즉흥적인 제작: 발표 준비와 생후 6개월 아기의 밤중 각성으로 바쁜 가운데, 새벽 1시쯤 잠들지 못해 직접 데모를 만들기로 했다.

2. 에스프레소 머신의 재등장

   1. 2023년 사례: 이전 Agent Conf에서 상태 머신인 에스프레소 머신에 음료 주문을 전달하면 에이전트가 정확한 조작 순서로 음료를 만드는 사례를 보여줬다.
   2. 이번 확장: 같은 아이디어를 Jev와 결합해, 상태 머신을 알고 가능한 이벤트를 선택하는 가상 바리스타로 확장했다.
   3. 반복되는 농담: Jev 제작자는 상태 머신과 잘 맞을 것이라는 평가에 “절대적으로 맞다”고 답했고, 발표자는 그 조합을 즉석에서 시험했다.

8.2. 상태 머신과 Jev의 결합

1. 가상 머신의 구성

   1. 거대한 내부 상태 머신: 가상 에스프레소 머신은 내부적으로 음료 제조 과정 전체를 나타내는 큰 상태 머신이다.
   2. 가능한 이벤트: Jev는 가상 바리스타가 수행할 수 있는 모든 이벤트와 정확한 상태 머신을 전달받는다.
   3. 다음 행동 선택: 현재 상태와 주문을 바탕으로 분쇄, 추출, 스팀 등 가능한 행동의 가능성을 판단한다.

2. 주문 실행

   1. 카푸치노와 에스프레소: 발표자는 카푸치노와 샷을 주문했고, ‘espresso’를 일부러 ‘expresso’처럼 틀리게 입력했다.
   2. 코르타도 추가: 이어서 코르타도를 주문했고, 발표가 끝나면 직접 마시고 싶다는 농담을 덧붙였다.
   3. 실시간 수행: 미리 녹화하거나 모든 순서를 하드코딩하지 않고 Jev가 각 단계의 상태와 이벤트를 따라 실시간으로 수행했다.

8.3. 고장 주입과 자율 복구

1. 의도적인 혼돈

   1. 부품 고장: 데모에는 일부 머신 부품이 중간에 고장 나는 혼돈(chaos)이 주입돼 있었다.
   2. 확률 표시: 화면에는 현재 어떤 행동을 취할 가능성이 높은지 표시되며, Jev는 스팀 완드를 작동할 시점 등을 판단했다.

2. 그라인더 복구

   1. 고장 유발: 발표자가 그라인더를 일부러 고장 냈다.
   2. 복구 판단: 원두를 갈 수 없으면 에스프레소 음료를 만들 수 없으므로 Jev는 먼저 그라인더를 고쳐야 한다고 판단했다.
   3. 구조의 의미: 상태 머신이 허용하는 이벤트와 현재 조건을 따라가면서도, 어떤 복구 행동을 선택할지는 에이전트의 판단에 맡길 수 있음을 보여준다.
   4. 현장 반응: 데모가 예상보다 잘 작동하자 발표자는 놀라워했고, 청중의 웃음과 박수 속에서 시연을 마쳤다.

주요 발언 모음

“Slop과 작별하고 결정론을 환영하자.”

“동일한 입력이 주어지면 매번 예측 가능한 동일한 출력을 얻는 것이 결정론이다.”

“작동하긴 한다. 하지만 작동하지 않는 순간, 에이전트에게 무엇을 고치라고 가리킬 수 있는가?”

“모델링이 혼란을 실제로 대체한다면 그것은 의식적인 절차가 아니다.”

“문단에는 화살표를 그릴 수 없다.”

“상태 머신은 에이전트가 항상 실행해야 하는 방식이 아니라, 에이전트가 스스로 개선할 수 있는 방식이다.”

“그래프는 에이전트를 정직하게 만드는 가드레일이었고, 이제 에이전트가 자신의 행동을 개선하게 만드는 수단이다.”

핵심 데이터 & 수치

• 영상 길이: 약 20분 29초(1,229초)이며 Agent Conf의 짧은 발표 형식으로 구성된다.
• 상태 머신의 최소 입력: 현재 상태(state)와 이벤트(event)가 다음 상태(next state)를 결정한다.
• 이메일 규칙: 초안 작성 → 검토 → 명시적 승인 → 전송의 순서를 지키며, 수신자 없는 이메일은 전송할 수 없다.
• 상태 평가 범위: 개별 상태의 결과, 전체 워크플로의 결과, 상태 사이 전이(edge)의 품질을 따로 평가한다.
• 워크플로 버전: 기존 이메일 머신 V1을 트레이스와 평가로 분석해 불필요한 다중 패스를 줄인 V2를 만들었다.
• 구현 선택지: XState, switch 문, reducer 함수, LangGraph 등으로 동일한 상태 기반 실행 구조를 만들 수 있다.
• 발표 시점 비교: 2023년에는 그래프를 가드레일로 설명했고, 2026년에는 같은 그래프를 자기 개선 루프로 확장했다.
• 데모 조건: Jev가 가상 바리스타의 전체 상태 머신과 가능한 이벤트를 받아 카푸치노·에스프레소·코르타도를 실시간 처리했다.
• 고장 복구: 그라인더가 고장 나자 음료 제조보다 그라인더 복구를 먼저 선택했다.

20줄 핵심 요약

1. AI 에이전트의 Slop은 모델의 능력 부족보다 구조화되지 않은 위임에서 발생한다.

2. 모든 판단과 구현과 취향을 한 번에 넘기면 성공 경로와 실패 원인을 분리하기 어렵다.

3. 결정론은 같은 입력에 같은 예측 가능한 출력을 내놓는 성질이다.

4. 상태와 이벤트와 다음 상태의 관계는 애플리케이션과 에이전트 워크플로의 기본 골격이 된다.

5. 신생아의 단순한 울음·수유·수면 루프는 복잡한 상태 그래프로 확장될 수 있다.

6. 메가 프롬프트에 제어 흐름을 넣으면 규칙이 일반 텍스트처럼 컨텍스트 속에서 희미해진다.

7. 긴 프롬프트는 하나의 모델과 전략만 사용하게 만들어 단계별 최적화를 어렵게 한다.

8. 이메일 문안과 명확화 질문은 비결정론적 생성 영역으로 남겨야 한다.

9. 초안 작성과 사용자 승인과 수신자 확인은 결정론적 규칙으로 고정해야 한다.

10. 상태 머신에 전송 전이를 정의하지 않으면 수신자 없는 이메일은 수학적으로 전송될 수 없다.

11. 명시적 상태와 이벤트와 전이는 사람과 에이전트가 공유하는 행동 모델이 된다.

12. 구조화된 로그는 단순한 추론 텍스트보다 실행 경로와 실패 지점을 분명하게 보여준다.

13. 평가 대상은 개별 상태의 결과와 전체 결과와 상태 사이 전이로 나눠야 한다.

14. 전이 평가가 있어야 작동하지만 불필요하게 느린 워크플로의 원인을 찾을 수 있다.

15. 상태 머신과 트레이스와 평가 결과를 별도 에이전트에게 주면 개선안이 나온다.

16. 이메일 V2는 먼저 초안을 만들고 그다음 검토하는 방식으로 불필요한 반복을 줄였다.

17. 동일한 시나리오를 V1과 V2에서 실행해야 개선이 실제로 일어났는지 확인할 수 있다.

18. XState나 LangGraph뿐 아니라 switch 문과 reducer 함수만으로도 최소 루프를 구현할 수 있다.

19. 그래프는 에이전트를 가두는 가드레일에서 자기 행동을 개선하는 작업 산출물로 확장된다.

20. Jev 가상 바리스타는 상태 머신과 가능한 이벤트를 사용해 부품 고장 뒤에도 그라인더를 복구하고 주문을 완수했다.

결론 및 시사점

1. 메가 프롬프트를 워크플로의 유일한 제어 장치로 삼지 않는다. 자연어 지시가 담당할 생성 영역과 코드·그래프가 담당할 규칙 영역을 분리한다.
2. 실패 비용이 큰 전이는 명시적으로 닫는다. 승인·권한·수신자·안전 조건처럼 반드시 지켜야 하는 경계는 상태 머신에서 허용 가능한 전이로만 표현한다.
3. 관찰 가능한 실행 흔적을 남긴다. 상태·이벤트·전이·결과를 구조화하면 “왜 실패했는가”와 “왜 느렸는가”를 구체적으로 물을 수 있다.
4. 단계와 전이와 전체 결과를 모두 평가한다. 최종 산출물이 존재하는 것만으로는 충분하지 않으며, 불필요한 질문과 반복을 줄이는 과정 품질도 측정해야 한다.
5. 상태 머신을 버전 관리 가능한 개선 산출물로 취급한다. V1의 실제 트레이스와 평가를 별도 에이전트가 분석해 V2를 제안하게 하고, 같은 시나리오로 두 버전을 비교한다.
6. 가장 단순한 구현부터 시작한다. XState나 LangGraph가 없어도 switch 문, reducer, 기본 반복문으로 현재 상태를 실행하고 다음 상태를 결정하는 루프를 만들 수 있다.
7. 결정론이 창의성을 대체하지 않게 한다. 에이전트의 생성 능력은 유지하되, 통제·관찰·자기 개선이 필요한 경로에만 결정론적 구조를 배치한다.
8. 최종 목표는 통제가 아니라 자기 개선이다. 그래프는 에이전트의 행동을 제한하는 경계를 넘어, 자신의 실행 흔적을 읽고 더 나은 워크플로를 제안·검증하는 기반이 된다.