이득:
- 가장 간단한 솔루션부터 점점 더 복잡해지는 솔루션을 에이전트에 적용
- 체인화, 라우팅 및 병렬 워크플로우 패턴 구별
- 다단계 작업을 계획-실행-검증 주기로 나누기
우리는 이전 유닛에서 단일 차량 단순 사이클을 설정했습니다. 실제 작업에는 여러 단계, 여러 도구, 때로는 분기 결정이 필요한 경우가 많습니다. "이달 말에 발생한 주문을 찾고, 고객에게 사과 이메일 초안을 작성하고, 관리자에게 요약합니다." 이 단원에서는 실제 에이전트가 필요할 때 다단계 작업을 구성하는 패턴과 계획-실행-검증 주기를 다룹니다. 주요 원칙: 필요한만큼 복잡합니다.
가장 간단한 솔루션에서 에이전트로 확장
모든 작업에 가장 복잡한 솔루션이 필요한 것은 아닙니다. 복잡성 규모를 단계적으로 높이고 가장 간단하고 적절한 솔루션에서 중지합니다.
- 단일 호출: 단일 모델 호출(요약, 분류)로 작업이 해결되면 여기서 중지합니다.
- RAG를 사용한 단일 호출: 정보가 필요한 경우 검색을 추가하고 다시 단일 호출을 추가합니다.
- 고정된 작업 흐름: 단계가 미리 알려진 경우 수동으로 순서를 지정합니다(코드 흐름). 모델은 각 단계에서 하위 작업을 수행하지만 순서는 사용자가 결정합니다.
- 모델 기반 에이전트: 단계를 미리 알 수 없는 경우 모델은 어떤 에이전트를 언제 호출할지 결정합니다. 가장 강력하지만 가장 비싸고 위험한 옵션입니다.
Workflow와 에이전트의 차이점은 매우 중요합니다. Workflow에서는 제어 흐름(예측 가능, 테스트 가능, 저렴함)을 작성합니다. 모델에 의제 제어권을 부여합니다(유연하지만 예측 불가능). 대부분의 기업 업무는 실제로 워크플로입니다. 실제 에이전트는 상대적으로 적습니다.
팁: "이 작업에 대한 단계를 미리 작성할 수 있나요?" 묻다. 작성할 수 있다면 더 저렴하고 안전하며 테스트하기 쉬운 워크플로를 구축하세요. 그러나 입력에 따라 단계가 달라지고 예측할 수 없는 경우에는 에이전트가 필요합니다.
세 가지 기본 워크플로 패턴
프롬프트 체인: 한 단계의 출력이 다음 단계의 입력이 됩니다. “초안 작성 → 편집 → 서식.” 모든 단계는 간단하고 집중되어 있습니다. 디버깅하기 쉽습니다.
라우팅: 먼저 들어오는 요청을 분류하여 적절한 전문가에게 보냅니다. “이 질문은 기술적인 문제인가요, 청구인가요, 아니면 환불인가요?” → 올바른 하위 스트림으로 리디렉션됩니다. 각 경로는 자체 프롬프트와 도구로 최적화됩니다.
병렬화: 독립적인 작업을 동시에 실행하고 결과를 결합합니다. "문서 5개를 따로 요약한 뒤 합쳐보세요." 속도가 빠를 뿐만 아니라 모든 부분에 주의가 집중됩니다.
패턴
언제
예
사슬로 묶인
단계는 순차적이고 종속적입니다.
초안 → 편집 → 형식
리디렉션
입력 유형에 따라 다른 처리
지원 요청 분류
평행
독립적인 하위 작품
여러 문서를 개별적으로 요약
에이전트(루프)
단계를 미리 예측할 수 없습니다.
개방형 연구/수리
# 라우팅 패턴 (개념적)type = Pattern.classify(request) # "return" | "기술" | "송장"if 투어 == "반환": 답변 = return_flow(요청)elif tur == "기술": 답변 = 기술_흐름(요청)else: 답변 = 송장_흐름(요청)
계획-실행-검증 주기
실제 에이전트의 강력한 패턴: 모델 계획을 수립하고 실행한 다음 확인합니다. 모델은 복잡한 작업을 하위 단계로 나누고 도구를 사용하여 각 단계를 수행한 다음 마지막으로 "목표를 달성했나요?"라고 묻습니다. 그는 확인합니다. 검증 단계에서는 별도의 새로운 모습으로 오류를 포착합니다(“이 출력이 작업을 충족합니까?”).
# 계획-실행-검증(개념적)plan = model.uret("이 작업을 여러 단계로 나누기: " + task)for 계획의 단계: result = agent_loop(step) # 실행 toolscheck = model.uret("이 출력이 작업을 충족합니까? 누락된 것이 있으면 알려주세요: " + task + results)if check.missing: # 수정 라운드 ...
긴 작업에 대한 두 가지 좋은 방법: 중지 조건(최대 단계 수 - 무한 루프 방지)을 적용하고 진행 상황을 추적합니다(에이전트가 주의가 산만해지지 않도록 수행 중인 작업을 기록하도록 함). 단계 제한이 없는 에이전트는 막히면 영원히 회전할 수 있고 비용은 폭발할 것입니다.
약한/강한 디자인
약함(하나의 거대 에이전트에 모든 것을 맡기는 것):
"복잡한 작업을 완료하세요"라고 말하고 무제한 도구를 사용하여 출시하세요.# 결과: 예측할 수 없는 동작, 무한 루프의 위험, 높은 비용,# 디버그가 불가능합니다.
강력함(흐름 우선, 필요한 경우에만 에이전트, 제한적):
먼저 작업을 고정된 단계(라우팅 + 체인)로 나눕니다. 단계를 알 수 없는 하위 작업에만 에이전트를 사용하세요. 단계 제한, 진행 상황 추적 및 검증 라운드를 추가합니다.
미니 케이스 3개
사례 1 — 상담원 대신 워크플로. 한 팀은 FA와 함께 "지원 요청 처리" 작업을 설정했습니다. 때로는 요원이 15계단을 돌아서 잘못된 길로 내려가는 경우도 있었습니다. 단계는 본질적으로 수정되었습니다(분류 → 관련 정보 가져오기 → 초안 작성 → 승인을 위해 제출). 라우팅 + 체이닝 워크플로우로 전환했을 때 일관성은 58%에서 96%로 증가했고 비용은 절반으로 줄었습니다.
사례 2 - 병렬 이득. 법무팀은 20개의 계약을 하나씩 요약하고 있었습니다. 총 4분 정도 소요되었습니다. 병렬 패턴(모두 동시에, 그런 다음 결합)으로 전환했을 때 각 요약이 완전한 관심을 받음에 따라 시간이 25초로 단축되었고 품질이 향상되었습니다.
사례 3 - 정지 조건이 없었습니다. 수사요원은 똑같은 두 도구를 끝없이 호출하며 찾을 수 없는 정보를 찾았다. 밤새 상당한 비용이 축적되었습니다. 최대 8단계 제한과 '3번 안에 못 찾으면 모른다' 규칙을 추가하자 비용은 억제됐고, 솔직한 '못 찾았다'는 답변이 나왔다.
일반적인 실수
- 모든 것을 에이전트에 위임: 단계를 알고 있으면 워크플로가 더 저렴하고 안전하며 테스트 가능합니다.
- 상담원과 워크플로 혼합: 귀하 또는 모델이 제어권을 갖나요? 이것을 명확하게 하지 않고 디자인하지 마세요.
- 중지 조건을 설정하지 않음: 에이전트가 무한 루프에 들어가 비용이 누적됩니다.
- 진행 상황 추적 없음: 긴 임무 중에 에이전트는 주의가 산만해져서 동일한 작업을 다시 수행합니다.
- 검증 라운드 건너뛰기: 부정확하지만 그럴듯해 보이는 출력이 확인되지 않은 상태로 전달됩니다.
주의: 에이전트가 자유로워질수록 폭발 반경이 커집니다. 유연성은 무료가 아닙니다. 자유가 추가될 때마다 예측 불가능성과 위험이 추가됩니다. 가장 좁은 적절한 솔루션을 선택하십시오.
요약하면
- 복잡성에서는 "필요에 따라" 원칙이 적용됩니다. 즉, 단일 호출 → RAG → 워크플로 → 실제로 필요한 경우에만 에이전트입니다.
- 워크플로에서는 제어 흐름(예측 가능)을 작성합니다. 의제를 모델에 맡깁니다(유연하지만 위험함).
- 세 가지 기본 패턴: 체인화(순차적 종속), 라우팅(유형별 배포), 병렬(독립적 작업).
- 실제 에이전트는 계획-실행-검증 주기, 중지 조건 및 진행 상황 추적을 사용합니다.
- 유연성이 증가하면 예측 불가능성과 비용도 증가합니다. 가장 좁은 적절한 솔루션을 선택하십시오.
응용과제
귀하의 사업에서 다단계 작업을 선택하십시오(예: "월별 보고서 준비 및 배포"). (1) 이 작업의 단계를 미리 작성할 수 있나요? 작성할 수 있다면 워크플로(어떤 패턴: 연결/라우팅/병렬?)로 설계하세요. 글을 쓸 수 없다면 대리인이 필요한 이유를 설명하세요. (2) 상자 화살표 다이어그램을 사용하여 선택한 디자인을 그립니다. (3) 기관인 경우: 중지 조건, 진행 상황 추적 및 검증 라운드를 어떻게 설정할지 작성합니다. (4) "단일 개발자"로 동일한 작업을 수행할 때 발생할 수 있는 위험 3가지를 나열하십시오.
체크리스트
- [ ] "필요에 따라 복잡성" 척도에서 적절한 수준을 선택할 수 있습니다.
- [ ] Workflow와 상담원 간의 제어 차이를 구분할 수 있습니다.
- [ ] 체인화, 라우팅 및 병렬 패턴을 적절한 작업에 매핑할 수 있습니다.
- [ ] 에이전트에서 계획-실행-검증 주기, 중지 조건 및 진행 상황 추적을 설정할 수 있습니다.
- [ ] 유연성이 너무 많으면 예측 불가능성과 비용이 발생한다는 점을 명심합니다.