[한영자막] AI 에이전트의 엉망진창 결과물(Slop)을 없애려면 ''이 구조''를 도입해야 합니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 에이전트의 엉망진창 결과물(Slop)을 줄이려면 상태 머신으로 실행 규칙과 전이를 명시하고, 실행 기록과 평가를 바탕으로 그 구조를 개선해야 한다.

📌 핵심 요점

1. 발표자는 Slop의 원인을 비구조적 위임에서 찾는다. 판단·구조·구현을 모두 에이전트에게 맡기면, 실패했을 때 무엇을 고쳐야 하는지 특정하기 어렵다.
2. 결정론을 적용할 대상은 생성되는 문장 전체가 아니라 실행 규칙이다. 이메일 내용과 확인 질문은 유연하게 생성하되, 초안 작성·사용자 승인·수신자 확인 같은 조건은 구조로 관리한다.
3. 거대한 프롬프트에 제어 흐름을 넣으면 규칙 준수를 보장하기 어렵고, 맥락이 쌓일수록 규칙의 영향이 약해질 수 있다. 단계를 분리하면 단계별 모델·프롬프트·설정도 달리 구성할 수 있다.
4. 상태 머신은 상태와 이벤트를 구조화된 기록으로 남겨 실패 지점을 살펴볼 수 있게 한다. 단계별 결과와 최종 결과뿐 아니라, 상태 사이의 전이가 사용자에게 불필요한 부담을 주는지도 평가해야 한다.
5. 핵심은 구조를 고정하는 데서 끝나지 않는다. 별도의 개선 에이전트에 상태 머신·실행 기록·평가를 제공하고, 수정 전후에 같은 시나리오를 실행해 행동과 사용 경험의 개선을 비교한다.

🧩 배경과 문제 정의

발표자 David Khourshid는 상태 머신 라이브러리 XState를 만든 개발자이자 stately.ai의 창업자다. 발표의 출발점은 에이전트를 더 예측 가능하게 만들고, 사용자가 원하지 않는 Slop을 줄이는 것이다.

상태 머신은 현재 상태와 발생한 이벤트를 바탕으로 다음 상태를 정하는 구조다. 발표자는 이 결정론적 관계를 에이전트의 실행 규칙에 적용하되, 이메일 문구나 확인 질문처럼 다양한 답이 가능한 영역은 모델에 맡기는 방식을 설명한다.

문제는 모든 판단과 실행 구조를 에이전트에 넘기면 실패 원인을 특정하기 어렵다는 데 있다. 제안하는 해법은 실행 구조를 명시하고 관찰한 뒤, 그 구조 자체를 에이전트가 개선하도록 만드는 것이다. 이메일 작성과 가상 에스프레소 머신이 이를 설명하는 시연으로 등장한다.

🕒 시간순 섹션별 상세정리

1. Slop을 줄이고 예측 가능한 에이전트 만들기

• 발표자는 Slop과 작별하고 결정론을 도입하자는 메시지로 시작한다. 목표는 사용자가 원하지 않는 결과물을 줄이고 에이전트를 예측 가능하게 만드는 것이다. [00:18]
• 자신을 David Khourshid로 소개하고, XState 제작자이자 stately.ai 창업자라고 보여준다. XState는 오픈소스이며 제안하는 접근은 다른 도구로도 구현할 수 있다고 드러낸다. [00:49]

2. 상태·이벤트·다음 상태와 루프의 관계

• 상태 머신의 핵심을 현재 상태와 이벤트가 주어지면 예측 가능한 다음 상태에 도달하는 관계로 보여준다. 이를 결정론이라고 부른다. [01:36]
• 아기의 울음·수유·수면 반복이 성장하면서 복잡해지는 사례로 단순 루프와 복잡한 상태 구조를 보여준다. [02:34]
• 에이전트 논의가 루프에서 그래프로 이동했지만 루프도 그래프라고 강조하며, 에이전트 엔지니어링에 그래프를 활용하는 주제로 연결한다. [03:01]

3. 비구조적 위임이 만드는 실패 진단의 어려움

• 이전 발표가 상태 머신으로 에이전트 행동을 제한하는 데 초점을 맞췄다면, 이번에는 상태 머신과 결정론으로 행동을 개선하고 Slop을 줄이는 데 초점을 둔다. [03:27]
• 판단·구조·구현을 모두 에이전트에게 넘기는 비구조적 위임을 Slop의 원인으로 지목한다. 잘 작동하다가 실패했을 때 수정 대상을 특정하기 어렵다는 문제가 있다. [04:27]
• 결정론을 같은 입력에 대해 같은 예측 가능한 출력을 얻는 것으로 정의하고, 이것이 에이전트 행동 개선에 도움이 된다고 보여준다. [04:51]

4. 이메일에서 규칙과 생성 내용을 구분하기

• 복잡한 문제를 단순화한 이메일 작성 에이전트를 예시로 선택한다. 사용자의 요청을 받아 이메일 초안을 만드는 업무다. [05:21]
• 먼저 초안을 만들고, 승인받은 이메일만 보내며, 수신자를 지어내지 않는 것은 결정론적으로 관리할 규칙이다. [05:44]
• 이메일 내용, 확인 질문, 피드백을 반영한 수정 초안은 다양한 결과가 가능한 영역으로 남겨둔다. [06:03]

5. 거대한 프롬프트에 제어 흐름을 넣을 때의 한계

• 초안 작성·수정·승인 후 발송 순서를 프롬프트에 적고 도구 설명에도 승인 조건을 반복하는 방식은 제어 흐름을 텍스트에 맡긴다. [06:50]
• 단계를 분리하지 않으면 하나의 모델·시스템 프롬프트·설정에 묶여, 단계마다 다른 전략을 적용하기 어렵다. [07:05]
• 발표자는 프롬프트만으로 매번 규칙이 지켜진다고 보장하기 어렵고, 맥락이 쌓이면 규칙의 중요성이 약해질 수 있다고 지적한다. [07:47]

6. 상태와 전이 조건으로 발송 경로 제한하기

• 요청에서 초안 작성과 검토로 이어지는 상태 머신을 제시한다. 검토 중에는 추가 확인이나 수정이 가능하다. [08:09]
• 수신자 없이 보내지 않는 보호 조건을 두고, 발송 단계에 도달해야 이메일을 보낼 수 있도록 구성한다. [08:24]
• 초안 작성과 검토 상태에는 발송 전이가 없기 때문에, 제시된 구조에서는 그 상태에서 발송할 수 없다고 보여준다. [08:38]

7. 첫 이메일 시연과 구조화된 관찰

• Jenny에게 커피를 제안하는 모호한 요청을 입력하자 에이전트가 주소와 제목 등 추가 정보를 묻고, 초안과 이름 수정 단계를 진행한다. [09:38]
• 시연 중 수신자 주소를 빠뜨렸다고 언급한 뒤 모의 발송함으로 전송됐다고 보여준다. 이 흐름이 최선의 사용자 경험은 아니라는 점을 다음 논의로 연결한다. [10:09]
• 모델링은 사람과 에이전트의 혼란을 줄이는 데 유용하며, 상태와 이벤트를 구조화해 기록할 수 있다고 보여준다. 모든 에이전트를 상태 머신으로 만들 필요는 없다는 단서도 붙인다. [11:13]

8. 결과 평가를 넘어 전이 경로 평가하기

• 명시적 구조는 실패하거나 조정해야 할 지점을 살펴볼 수 있게 한다. 단계별 출력과 전체 워크플로 결과를 평가하는 방식도 보여준다. [12:27]
• 최종적으로 이메일을 얻더라도 과정이 번거로울 수 있으므로, 놓치고 있는 평가 대상으로 상태 사이의 엣지를 제시한다. [12:42]
• 상태 머신, 실제 또는 모의 사용자의 실행 기록, 단계별·전체 평가를 에이전트에게 제공해 구조 수정안을 요청한다. Stately의 상태 머신 생성·편집 파이프라인에서 활용했다고 드러낸다. [13:34]

9. 수정된 흐름으로 반복 질문 줄이기

• 개선안은 작은 문제를 해결하려고 여러 번 왕복하던 흐름을 바꿔, 먼저 초안을 만든 뒤 필요한 정보를 확인하도록 구성한다. [14:11]
• 새 흐름에서는 초안을 검토하고 이름 등을 수정한 뒤 발송하는 과정을 보여주며, 이전보다 빠르고 나아진 사용 경험이라고 보여준다. [14:35]
• 기존 평가가 모두 통과하더라도 직접 사용하고 반복 개선하지 않으면 더 나은 흐름을 놓칠 수 있다고 강조한다. [14:56]

10. 특정 라이브러리 없이 구현하는 실행 루프

• 특별한 도구 없이 초기 상태에서 시작해, 작업이 끝나지 않은 동안 LLM 호출·도구 호출·외부 비동기 작업을 실행하는 루프로 구현할 수 있다고 보여준다. [15:25]
• 현재 상태와 발생한 이벤트에 따라 다음 상태와 실행할 효과를 결정한다. 구현 예로 XState, switch 문, reducer 함수, LangGraph를 언급한다. [15:54]

11. 모델링·관찰·제안·비교의 개선 순환

• 상태 머신을 만들고 전이를 관찰한 다음, 별도의 에이전트가 워크플로와 실행 기록을 보고 개선안을 제안하게 한다. [16:34]
• 두 버전에 같은 시나리오를 실행해 개선 여부를 비교한다. Agent Spec, AIFlow, 프로세스 마이닝도 관련 선행 접근으로 보여준다. [17:10]
• 상태 머신을 영구히 고정된 실행 방식으로 삼기보다 에이전트가 스스로 개선할 수 있는 구조로 활용하자고 정리한다. 그래프의 역할이 경계 설정에서 행동 개선으로 확장된다는 메시지다. [17:44]

12. Jev와 가상 에스프레소 머신 시연

• Jev에 에스프레소 머신의 상태 구조와 가능한 이벤트를 제공한다. 자연어 음료 주문을 받아 가상 바리스타가 필요한 단계를 수행하는 모습을 보여준다. [19:28]
• 머신 일부가 고장 나는 상황을 넣고 그라인더를 고장 낸다. 발표자는 Jev가 음료 제조에 필요한 그라인더 수리를 선택하는 과정을 보여준다. [20:17]
• 시연이 작동하는 모습을 확인하고 놀라움을 표현한 뒤, 청중에게 감사하며 발표를 마친다. [20:27]

🧾 결론

• 상태 머신은 에이전트가 지켜야 할 경계와 실행 순서를 명시하는 수단이며, 생성 내용의 다양성을 모두 제거할 필요는 없다.
• 평가를 통과해 원하는 결과에 도달하더라도, 질문과 수정이 반복되는 불편한 경로는 남을 수 있다. 결과와 함께 과정도 살펴봐야 한다.
• 명시적 구조는 사람과 에이전트가 함께 검토하고 수정할 수 있는 개선 대상이 된다.
• 모든 에이전트를 정형화할 필요는 없으며, XState 같은 특정 라이브러리도 필수 조건은 아니다.

📈 투자·시사 포인트

• 에이전트 제품을 평가할 때 최종 출력의 품질과 함께 승인 조건, 실행 권한, 실패 지점의 추적 가능성을 확인필요가 있다.
• 워크플로 도구의 실무적 가치는 그래프를 보여주는 기능뿐 아니라, 실행 기록과 평가를 구조 수정으로 연결하는 능력에서도 찾을 수 있다.
• 단계별 모델·프롬프트·설정을 선택할 수 있는 구조는 업무별 전략을 달리 적용할 여지를 제공한다.
• 발표는 특정 기업의 투자 수익이나 시장 전망을 제시하지 않는다. 소개된 도구는 에이전트 구현과 개선 방식을 비교하는 사례로 읽는 것이 적절하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 비구조적 위임이 Slop의 원인이라는 설명은 발표자의 견해다. 원인별 기여도나 상태 머신 도입 전후의 오류 감소율은 제시되지 않는다.
• 발송이 특정 상태에서 수학적으로 불가능하다는 설명은 해당 전이 구조를 전제로 한다. 실제 시스템의 도구 호출 경로와 구현까지 같은 제약을 지키는지는 별도 확인이 필요하다.
• 첫 이메일 시연에서는 수신자 주소를 빠뜨렸다는 언급 뒤에 모의 발송함으로 전송됐다고 설명한다. 대본만으로는 수신자 검증이 어떻게 처리됐는지 확인할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 에이전트 업무에서 반드시 지켜야 할 실행 규칙과 유연하게 생성해도 되는 내용을 구분한다.
• 이메일 사례처럼 초안·검토·승인·발송 상태와 전이 조건을 명시하고, 승인 또는 수신자 정보가 없을 때 발송 경로가 차단되는지 확인한다.
• 상태·이벤트·전이를 구조화해 기록하고, 실제 사용자 또는 모의 사용자 시나리오를 수집한다.
• 단계별 결과와 최종 결과를 평가하면서, 반복 질문과 불필요한 수정 전이도 함께 검토한다.

❓ 열린 질문

• 어떤 업무에서는 상태 머신이 혼란을 줄이고, 어떤 업무에서는 모델링 부담이 더 커지는가?
• 결과 평가가 모두 통과한 상황에서 전이 경로의 불편함과 개선 효과를 어떤 기준으로 측정할 것인가?
• 개선 에이전트가 구조를 바꿀 때 기존 승인 조건과 실행 경계를 계속 유지하는지 어떻게 확인할 것인가?