에이전트를 처음 만들면 많은 사람이 이렇게 기대한다. 입력을 넣으면 모델이 알아서 계획하고, 도구를 쓰고, 결과를 검토한 뒤, 완성된 답을 내놓을 것이라고 말이다. 데모에서는 가끔 그렇게 보인다. 하지만 실제 업무에서는 한 번의 호출로 끝나는 일보다, 중간에 확인하고 수정하고 다시 시도해야 하는 일이 훨씬 많다.
그래서 에이전트는 단발성 응답보다 통제된 반복 안에서 더 잘 작동한다. 좋은 하네스는 모델에게 단지 "똑똑하게 대답하라"라고 요구하지 않는다. 대신 "무엇을 먼저 보고, 무엇을 결정하고, 어떤 행동을 하고, 그 결과를 어떻게 되짚을지"를 순서로 만들어 준다. 이 순서가 바로 워크플로이고, 그 순서가 반복되는 방식이 루프다.
이 장에서는 에이전트가 제멋대로 돌아다니지 않게 만드는 흐름 제어의 핵심을 살펴본다. 핵심은 단순하다. 에이전트는 자유로울수록 유능해지는 것이 아니라, 잘 설계된 루프 안에 있을 때 비로소 쓸모 있어진다.
왜 에이전트에는 루프가 필요한가
사람이 일을 할 때를 떠올려 보자. 먼저 상황을 살펴보고, 다음 할 일을 정하고, 실제로 행동한 뒤, 결과가 맞는지 확인한다. 잘 안 되면 계획을 바꾸고 다시 시도한다. 에이전트도 마찬가지다.
문제는 언어 모델이 기본적으로는 한 번의 요청에 대해 한 번의 응답을 생성하는 구조라는 점이다. 즉, 모델 자체는 긴 작업을 안정적으로 운영하는 관리자라기보다, 매 순간 주어진 문맥을 바탕으로 다음 출력을 예측하는 엔진에 가깝다. 긴 작업을 완수하게 만들려면, 모델 바깥에서 반복 구조를 제공해야 한다.
루프가 없으면 흔히 다음과 같은 문제가 생긴다.
첫 번째 생각이 틀렸는데도 그대로 밀어붙인다.
도구 실행 결과를 충분히 읽지 않고 다음 행동으로 넘어간다.
실패했는데 실패를 실패로 인식하지 못한다.
이미 해본 시도를 또 반복한다.
목표를 달성했는데도 멈추지 못한다.
결국 루프 설계는 "에이전트가 몇 번 더 생각하게 하자"는 이야기가 아니다. 그것은 작업을 진행하고, 점검하고, 멈추게 하는 제어 구조를 만든다는 뜻이다.
Observe → Plan → Act → Reflect 구조
에이전트 워크플로를 설계할 때 가장 유용한 기본 틀 중 하나가 Observe → Plan → Act → Reflect 구조다. 이름은 단순하지만, 실제로는 에이전트의 산만함을 줄이고 실패를 다루기 쉽게 만드는 강력한 프레임이다.
Observe: 지금 무슨 일이 벌어지고 있는가
Observe는 관찰 단계다. 여기서 에이전트는 일을 시작하기 전에 현재 상태를 읽는다. 사용자 요청, 시스템 제약, 도구 결과, 이전 실행 기록, 현재 파일 상태, 남은 예산 같은 정보가 여기에 포함된다.
관찰 단계가 약하면 에이전트는 언제나 성급해진다. 아직 확인하지 않은 파일을 안다고 가정하고 수정하거나, 이미 실패한 API를 다시 호출하거나, 오래된 컨텍스트를 최신 사실처럼 받아들인다. 많은 실패가 실행 단계가 아니라 관찰 단계의 부실함에서 시작된다.
좋은 Observe는 단순히 정보를 많이 넣는 것이 아니다. 지금 행동을 결정하는 데 필요한 정보만 명확하게 읽게 하는 것이다. 예를 들어 코딩 에이전트라면 "현재 브랜치, 수정된 파일 목록, 테스트 실패 로그, 작업 목표"가 핵심일 수 있다. 업무 자동화 에이전트라면 "이 작업이 승인 대상인지, 이미 처리된 요청인지, 대상 사용자가 누구인지"가 먼저 보여야 한다.
즉, Observe는 에이전트에게 세상을 다 보여주는 단계가 아니라, 지금 판단해야 할 현실을 읽게 하는 단계다.
Plan: 다음 한 걸음을 정한다
Plan은 전체 인생 계획을 세우는 단계가 아니다. 좋은 Plan은 대개 아주 소박하다. "다음에 무엇을 할까?"를 결정하는 것이다.
여기서 중요한 점은 계획을 너무 크게 잡지 않는 것이다. 언어 모델은 장대한 계획을 그럴듯하게 말하는 데는 능하지만, 긴 계획을 끝까지 일관되게 실행하는 데는 종종 약하다. 그래서 하네스는 거대한 마스터플랜보다 검증 가능한 다음 단계를 뽑아내게 해야 한다.
예를 들어 "버그를 고쳐라"는 목표는 너무 크다. 하지만 "실패한 테스트를 재현하고, 원인으로 의심되는 함수 하나를 확인하고, 수정 후 해당 테스트만 다시 실행하라"는 계획은 훨씬 다루기 쉽다. 이렇게 작게 쪼개진 계획은 실패했을 때도 원인을 찾기 쉽고, 성공했을 때도 진척을 판단하기 쉽다.
좋은 Plan은 보통 세 가지를 포함한다.
다음 행동의 목적
사용할 도구 또는 작업 방식
성공 여부를 확인할 기준
계획이 이 세 가지 없이 "일단 해보자" 수준으로 흘러가면, 루프는 곧 방황으로 바뀐다.
Act: 행동은 작고 명확하게
Act는 실제로 도구를 호출하고, 파일을 읽고, 코드를 수정하고, 메시지를 보내는 단계다. 많은 팀이 에이전트 성능을 논할 때 이 단계만 본다. 하지만 실행 그 자체보다 더 중요한 것은 실행의 경계다.
좋은 Act는 한 번에 너무 많은 것을 하지 않는다. 한 번의 행동이 커질수록 실패 원인을 추적하기 어려워지고, 되돌리기도 어려워진다. 예를 들어 코드 수정, 테스트 실행, 배포, 알림 전송을 한 번에 묶어버리면 어디서 문제가 생겼는지 분간하기 어렵다.
반대로 잘 설계된 Act는 가능한 한 원자적이다. 파일 한 개를 읽고, 특정 테스트를 실행하고, 메일 초안을 만들고, 승인 전 단계에서 멈춘다. 이렇게 행동 단위를 작게 만들면 루프는 훨씬 안정적이 된다.
여기서 기억할 점은, 에이전트에게 자유를 줄수록 똑똑해 보일 수는 있지만 운영은 어려워진다는 것이다. 제품 환경에서는 "무엇이든 할 수 있는 에이전트"보다 "정해진 범위 안에서 차근차근 움직이는 에이전트"가 더 가치 있다.
Reflect: 결과를 되짚지 않으면 반복은 학습이 아니라 배회가 된다
Reflect는 많은 구현에서 빠지기 쉬운 단계다. 실행만 하고 곧바로 다음 행동으로 넘어가면, 에이전트는 분주해 보이지만 실제로는 같은 실수를 반복한다.
Reflect의 목적은 단순하다. 방금 한 행동이 목표에 도움이 되었는지 판단하는 것이다. 성공했는가? 실패했는가? 부분 성공인가? 예상과 다른 결과가 나왔는가? 계획을 유지해야 하는가, 바꿔야 하는가? 여기서 중요한 것은 자기반성의 화려한 문장이 아니라, 다음 루프의 방향을 바꾸는 판단이다.
좋은 Reflect는 보통 네 가지 결론 중 하나로 끝난다.
목표를 달성했으니 종료한다.
다음 단계로 진행한다.
계획을 수정한 뒤 다시 시도한다.
위험하거나 불확실하므로 사람에게 넘긴다.
이 네 갈래가 분명해야 루프가 흐려지지 않는다. Reflect가 없으면 에이전트는 결과를 소화하지 못하고, Reflect가 약하면 에이전트는 실패를 읽고도 행동을 바꾸지 못한다.
루프는 많이 도는 것이 아니라, 잘 도는 것이다
에이전트 설계에서 흔한 오해가 하나 있다. 반복 횟수가 많을수록 더 깊이 생각하고 더 좋은 결과를 낼 것이라는 믿음이다. 물론 한 번 더 점검하는 것이 도움이 될 때도 있다. 하지만 루프의 수가 많다고 해서 품질이 자동으로 올라가지는 않는다.
오히려 나쁜 루프는 빠르게 비용만 키운다. 같은 파일을 계속 읽고, 비슷한 검색을 반복하고, 실패한 도구를 계속 호출하고, 이미 틀린 가설을 더 길게 밀어붙인다. 이것은 사고의 깊이가 아니라 통제되지 않은 반복이다.
좋은 루프는 반복 자체보다 반복 사이의 변화를 만든다. 새 정보를 얻었는가, 가설이 수정되었는가, 행동 범위가 줄었는가, 종료 가능성이 높아졌는가가 중요하다. 루프를 한 번 돌 때마다 상태가 의미 있게 갱신되어야 한다.
그래서 하네스는 "몇 번 반복할까?"보다 먼저 "반복할 때 무엇이 달라져야 하는가?"를 정의해야 한다.
단일 루프와 다중 루프
모든 에이전트가 같은 깊이의 워크플로를 가질 필요는 없다. 간단한 작업은 단일 루프로 충분하고, 복잡한 작업은 여러 층의 루프가 필요하다.
단일 루프는 가장 기본적인 형태다. 관찰하고, 계획하고, 실행하고, 되짚는 과정이 한 줄로 이어진다. 예를 들어 문서 요약, 간단한 데이터 조회, 테스트 실패 원인 파악 같은 작업은 이 구조만으로도 잘 돌아간다. 구현이 단순하고 디버깅이 쉽다는 장점이 있다.
다중 루프는 바깥 루프와 안쪽 루프가 역할을 나누는 구조다. 예를 들어 바깥 루프는 전체 목표의 진척을 관리하고, 안쪽 루프는 세부 작업 하나를 해결한다. 코딩 에이전트를 예로 들면, 바깥 루프는 "기능 구현 완료"를 향해 움직이고, 안쪽 루프는 "테스트 실패 하나를 해결"하는 데 집중할 수 있다.
다중 루프는 강력하지만 위험도 함께 커진다. 루프가 겹칠수록 상태 관리가 어려워지고, 어느 레벨에서 멈춰야 하는지 불분명해지기 쉽다. 그래서 초기에 에이전트를 만들 때는 가능한 한 단일 루프로 시작하고, 정말 필요한 경우에만 안쪽 루프를 추가하는 편이 낫다.
핵심은 구조의 화려함이 아니라 책임의 명확함이다. 바깥 루프는 목표 진척을 관리하고, 안쪽 루프는 특정 문제를 해결한다. 두 루프가 같은 판단을 두 번 하면 오히려 혼란만 커진다.
계획자, 실행자, 검토자를 나누는 이유
복잡한 작업에서는 하나의 에이전트가 모든 역할을 맡는 것보다, 역할을 분리하는 편이 더 안정적일 때가 많다. 흔히 사용하는 구조가 계획자, 실행자, 검토자 구분이다.
계획자는 무엇을 해야 하는지 정리한다. 실행자는 실제 도구를 사용해 일을 진행한다. 검토자는 결과가 기준에 맞는지 확인한다. 이 셋을 꼭 서로 다른 모델이나 프로세스로 나눌 필요는 없지만, 하네스 수준에서 역할을 분리해 사고하게 만드는 것만으로도 품질이 달라진다.
이 구조가 유용한 이유는 각 역할이 잘하는 일이 다르기 때문이다. 계획자는 큰 그림과 우선순위를 잡는 데 강하고, 실행자는 세부 작업을 차근차근 밀어붙이는 데 강하며, 검토자는 틀린 점과 누락된 점을 잡아내는 데 강하다. 한 주체가 이 세 가지를 동시에 하면, 자신의 계획을 스스로 정당화하며 검토를 느슨하게 하는 일이 자주 생긴다.
예를 들어 리서치 에이전트라면 계획자는 조사 질문을 분해하고, 실행자는 자료를 읽고 정리하며, 검토자는 출처 누락이나 논리 비약을 점검할 수 있다. 업무 자동화 에이전트라면 계획자는 처리 순서를 정하고, 실행자는 실제 시스템을 조작하며, 검토자는 승인 필요 여부와 정책 위반 가능성을 확인한다.
다만 역할 분리는 만능이 아니다. 간단한 작업까지 억지로 여러 역할로 나누면 느리고 비싸기만 하다. 역할 분리는 복잡도와 위험이 올라갈 때 도입해야 한다. 특히 쓰기 권한이 있는 작업, 실패 비용이 큰 작업, 검증이 핵심인 작업에서 효과가 크다.
서브에이전트는 기능 분리가 아니라 책임 분리다
서브에이전트를 설계할 때 흔히 "여러 에이전트를 쓰면 더 똑똑해지겠지"라고 생각한다. 하지만 실제로는 역할을 늘릴수록 조율 비용이 커진다. 따라서 서브에이전트는 기능을 멋지게 나누기 위해서가 아니라, 책임과 권한을 분리하기 위해 도입해야 한다.
좋은 분리 기준은 다음과 같다.
보는 정보가 다른가
사용할 도구가 다른가
실패했을 때 책임 경계가 다른가
승인 수준이 다른가
예를 들어 고객 데이터에 접근하는 에이전트와 초안만 작성하는 에이전트는 분리할 이유가 충분하다. 전자는 민감 정보와 권한 통제가 중요하고, 후자는 표현 품질과 요약 능력이 더 중요하기 때문이다. 반면 같은 도구, 같은 정보, 같은 목표를 공유하면서 이름만 다른 에이전트를 여러 개 두는 것은 대개 복잡도만 늘린다.
서브에이전트는 분업 그 자체보다도, 실수의 범위를 좁히는 장치로 이해하는 편이 좋다.
반복 실행의 장점과 위험
루프 기반 워크플로는 분명한 장점이 있다. 한 번에 완벽한 답을 기대하지 않고, 중간 결과를 바탕으로 점진적으로 개선할 수 있다. 실패를 더 이른 시점에 발견할 수 있고, 사람의 개입 지점을 넣기도 쉽다. 무엇보다 긴 작업을 작은 단위로 다루게 해 준다.
하지만 반복 실행은 그 자체로 새로운 위험을 만든다. 가장 흔한 것은 루프 중독이다. 뭔가 잘 안 되면 다시 시도하면 될 것 같아서, 종료와 에스컬레이션 없이 계속 돌리는 것이다. 이런 시스템은 처음에는 끈질겨 보이지만, 나중에는 비용과 지연을 키우는 기계가 된다.
반복 실행이 위험해지는 순간은 대개 세 가지다.
첫째, 새 정보 없이 같은 행동을 반복할 때다. 이 경우 루프는 개선이 아니라 맴돌기다.
둘째, 중간 상태가 오염될 때다. 잘못된 가정이 메모리나 작업 상태에 남으면, 다음 반복은 더 나쁜 출발점에서 시작한다.
셋째, 성공 기준이 모호할 때다. 무엇을 달성하면 끝인지 정의되지 않으면, 에이전트는 일을 끝냈는지 판단할 수 없다.
따라서 루프를 설계할 때는 "다시 시도하자"보다 먼저 "언제 다시 시도할 가치가 있는가"를 정해야 한다.
종료 조건은 에이전트의 브레이크다
루프 설계에서 종료 조건은 선택 사항이 아니다. 종료 조건이 없는 에이전트는 열심히 일하는 것처럼 보여도, 실제로는 브레이크 없는 기계와 비슷하다.
좋은 종료 조건은 한 가지가 아니라 여러 층으로 설계하는 편이 안전하다. 가장 기본적인 종료 조건은 작업 성공이다. 목표가 달성되었고 검증도 통과했다면 멈춰야 한다. 하지만 현실에서는 이것만으로 부족하다. 성공하지 못한 경우에도 멈춰야 할 이유가 많기 때문이다.
실무에서 자주 쓰는 종료 조건은 다음과 같다.
최대 반복 횟수 도달
시간 예산 초과
비용 또는 토큰 예산 초과
같은 실패의 반복 횟수 초과
일정 횟수 이상 진척 없음
승인 필요 단계 도달
위험 점수 임계치 초과
여기서 특히 중요한 것은 무진전 종료 조건이다. 루프를 여러 번 돌았는데 상태가 나아지지 않았다면, 그 시점에서 멈추고 다른 전략을 택해야 한다. 예를 들어 세 번 연속으로 같은 테스트가 같은 이유로 실패했다면, 네 번째 반복은 개선이 아니라 낭비일 가능성이 높다.
종료 조건은 에이전트의 능력을 제한하는 것이 아니라, 오히려 시스템 전체의 신뢰를 높이는 장치다. 멈출 줄 아는 에이전트가 오래 살아남는다.
실패했을 때 멈추는 법
에이전트는 실패할 수 있다. 더 정확히 말하면, 반드시 실패한다. 문제는 실패 자체가 아니라 실패했을 때 어떤 모드로 들어가느냐다.
좋지 않은 시스템은 실패 직후에도 같은 전략을 자동 반복한다. 반면 좋은 시스템은 실패를 종류별로 다르게 다룬다. 일시적 실패인지, 권한 문제인지, 도구 스키마 문제인지, 목표 해석 문제인지에 따라 다음 행동이 달라져야 한다.
예를 들어 네트워크 오류처럼 일시적인 문제는 제한된 횟수의 재시도가 합리적이다. 하지만 권한 부족 오류는 재시도보다 승인 요청으로 보내는 편이 맞다. 입력 자체가 모호해서 실패했다면, 도구를 다시 호출하기보다 사용자에게 질문을 돌려야 한다. 실행 결과가 위험 신호를 보이면 즉시 중단하고 사람 검토로 전환해야 한다.
즉, 실패 처리의 핵심은 "계속할까, 말까"가 아니다. 어떤 종류의 실패이므로 어떤 제어 경로로 보낼 것인가다.
이때 하네스는 실패를 최소한 다음 네 갈래로 나눌 수 있어야 한다.
재시도하면 해결될 수 있는 실패
계획 수정이 필요한 실패
사람 승인이 필요한 실패
즉시 중단해야 하는 실패
이 구분이 없으면 루프는 실패를 모두 같은 방식으로 처리하고, 결국 너무 쉽게 멈추거나 너무 오래 버틴다.
워크플로는 길이보다 상태 전이가 중요하다
에이전트 흐름을 설명할 때 우리는 종종 단계 수에 집착한다. 몇 단계 워크플로인지, 몇 개의 서브에이전트가 있는지, 계획이 얼마나 정교한지 같은 것들이다. 하지만 운영 관점에서 더 중요한 것은 단계 수가 아니라 상태 전이다.
지금 에이전트는 어떤 상태인가? 준비 중인가, 실행 중인가, 검토 중인가, 승인 대기인가, 실패 복구 중인가, 종료되었는가? 이 상태가 명확해야 로그도 읽기 쉽고, 모니터링도 가능하고, 사람 개입 지점도 설계할 수 있다.
예를 들어 같은 "실행 중"이라도 실제로는 다를 수 있다. 자료를 모으는 중인지, 도구 결과를 기다리는 중인지, 재시도 중인지에 따라 관리 방식이 달라진다. 상태를 나누지 않으면 모든 일이 하나의 검은 상자 안에서 일어나고, 문제가 생겼을 때 무엇이 꼬였는지 알기 어려워진다.
좋은 워크플로는 에이전트의 사고 과정을 장황하게 설명하지 않아도, 지금 어디까지 왔는지가 드러난다.
실전에서 유용한 루프 설계 원칙
복잡한 이론보다 현장에서 바로 도움이 되는 원칙을 정리해 보자.
첫째, 한 루프에서 한 가지 핵심 진전만 기대하라. 한 번의 반복이 목표 전체를 끝내길 바라지 말고, 상태를 더 좋은 쪽으로 한 칸 움직이게 하라.
둘째, 실행보다 판정 기준을 먼저 설계하라. 무엇을 하면 성공인지 모르는데 행동부터 정하면, 루프는 오래 돌수록 더 불안정해진다.
셋째, 재시도와 재계획을 구분하라. 같은 행동을 다시 하는 것과, 전략 자체를 바꾸는 것은 전혀 다른 일이다.
넷째, 읽기와 쓰기를 섞지 말라. 가능하면 먼저 충분히 관찰하고, 그다음 제한된 쓰기 행동으로 넘어가야 한다.
다섯째, 큰 목표보다 다음 행동의 품질을 높여라. 에이전트는 거대한 비전보다 다음 한 걸음을 정확히 디딜 때 더 안정적으로 일한다.
여섯째, 멈춤을 실패로 보지 말라. 잘 멈추는 것은 무능함이 아니라 제어력이다.
코딩 에이전트를 예로 보는 루프 설계
코딩 에이전트는 워크플로와 루프 설계의 중요성이 가장 잘 드러나는 분야다. 단순한 모델 호출로는 "코드를 잘 쓰는 것처럼 보이는 답변"은 만들 수 있어도, 실제 리포지터리에서 안전하게 수정하고 검증하는 일은 어렵다.
예를 들어 버그 수정 작업을 맡긴다고 해 보자. 좋은 루프는 대개 이런 흐름을 따른다. 먼저 에러 로그와 실패 테스트를 읽는다. 그다음 원인 후보를 세운다. 가장 가능성 높은 지점을 한 군데 수정한다. 관련 테스트를 실행한다. 결과를 보고 수정이 유효한지 판단한다. 통과하면 더 넓은 테스트로 확장하고, 실패하면 원인 가설을 바꾼다. 여러 번 실패하면 사람에게 넘긴다.
이 구조에서 중요한 것은 모델의 코딩 능력만이 아니다. 어느 시점에 테스트를 돌릴지, 얼마나 넓게 수정할지, 몇 번까지 재시도할지, 언제 멈출지를 하네스가 정해 준다는 점이다. 바로 이 차이 때문에 같은 모델이라도 어떤 하네스 위에 올리느냐에 따라 결과가 크게 달라진다.
업무 자동화 에이전트에서의 루프 설계
업무 자동화에서는 루프의 역할이 조금 다르다. 여기서는 정확성만큼이나 승인과 예외 처리가 중요하다. 예를 들어 일정 조정, 이메일 발송, CRM 업데이트 같은 작업은 한 번 잘못 실행하면 되돌리기 어렵거나 사람 관계에 영향을 줄 수 있다.
이 경우 Observe 단계에서는 요청자의 신원, 대상 데이터, 기존 처리 이력, 정책 위반 여부를 먼저 확인해야 한다. Plan 단계에서는 초안 작성인지 실제 전송인지 구분해야 한다. Act 단계에서는 가능한 한 비파괴적 행동부터 시작해야 한다. Reflect 단계에서는 정책 준수, 승인 필요 여부, 후속 작업 필요성을 점검해야 한다.
즉, 업무 자동화 루프는 단순히 작업을 빨리 끝내는 구조가 아니라, 사고를 내지 않고 처리하는 구조여야 한다. 그래서 종종 "실행"보다 "대기"와 "승인 요청"이 더 중요한 상태가 된다.
좋은 워크플로는 사용자 경험이기도 하다
루프와 워크플로는 내부 기술 설계처럼 보이지만, 실제로는 사용자 경험을 크게 좌우한다. 사용자는 에이전트의 내부 프롬프트를 보지 못해도, 이 시스템이 지금 무엇을 하고 있는지는 체감한다.
갑자기 오래 멈춰 있거나, 같은 질문을 반복하거나, 이미 끝난 일을 다시 수행하거나, 위험한 작업을 조용히 실행하는 시스템은 불안하다. 반대로 지금 관찰 중인지, 계획을 세우는 중인지, 검증 때문에 잠시 멈춘 것인지가 드러나는 시스템은 훨씬 신뢰를 준다.
좋은 하네스는 에이전트의 사고를 전부 공개하지 않더라도, 최소한 작업의 진행 상태와 중요한 분기점을 사용자에게 이해 가능한 형태로 보여준다. 이것이 운영 가능성뿐 아니라 제품 경험에도 중요하다.
워크플로는 에이전트를 일하게 만드는 운영체제다
프롬프트가 명령이라면, 워크플로는 그 명령이 현실 속 행동으로 바뀌는 순서다. 컨텍스트가 재료라면, 루프는 그 재료를 꺼내 보고, 써 보고, 다시 정리하는 리듬이다. 그리고 하네스는 그 모든 것이 안전하고 반복 가능하게 돌아가도록 만드는 작업장이다.
에이전트는 한 번의 멋진 응답으로 제품이 되지 않는다. 실제 제품이 되려면 관찰하고, 계획하고, 행동하고, 되짚는 흐름이 있어야 한다. 더 나아가 언제 반복하고, 언제 멈추고, 언제 사람에게 넘길지까지 정해져 있어야 한다.
결국 워크플로와 루프 설계의 목적은 모델을 더 영리하게 보이게 만드는 것이 아니다. 에이전트를 더 다루기 쉬운 시스템으로 바꾸는 것이다. 제어할 수 없는 똑똑함보다, 제어 가능한 반복이 훨씬 더 큰 제품 가치를 만든다.
다음 장에서는 이런 루프 기반 에이전트를 더 믿을 수 있게 만들기 위해, 큰 목표를 어떻게 검증 가능한 작은 작업으로 나눌지 살펴본다. 에이전트가 잘 돌기만 해서는 충분하지 않다. 각 단계가 정말 제대로 끝났는지를 확인할 수 있어야 하기 때문이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.