ByteByteGo — 에이전트 루프: AI가 질문에 답하는 것에서 실제로 일을 하는 것으로 (2026-07-09)

챗봇은 질문에 답하고, 에이전트는 작업을 완료한다. 이 차이는 엄청나 보이지만, 실제 그 간격은 생각보다 좁다.

에이전트란 모델 자신이 루프의 종료 시점을 결정하는, LLM을 루프 안에 배치한 시스템이다. 에이전트를 유용하게 만드는 자율성, 비용, 그리고 구축할 때의 설계 과제 — 이 모든 것은 이 전환에서 비롯된다.

기초: 증강된 LLM (Augmented LLM)

순수한 LLM 호출은 상태 없는(stateless) 함수다. 텍스트가 들어가고, 텍스트가 나온다. 날씨를 가져오거나 데이터베이스를 업데이트하려면 그 이상이 필요하다.

모델을 실제 시스템에서 유용하게 만드는 것은 **증강(augmentation)**이다:

• 도구 사용(Tool use): 우리가 정의한 함수를 호출하는 능력
• 검색 레이어(Retrieval layer): 런타임에 관련 문서를 가져올 수 있는 접근
• 메모리(Memory): 호출 간에 정보를 기록하는 방법

Anthropic은 이 조합을 증강된 LLM이라 부르며, 모든 에이전트 시스템의 기본 단위로 취급한다. 파이썬 코드를 실행하는 채팅 어시스턴트, 서비스에 연결된 function-calling API, 문서에서 검색하는 RAG 애플리케이션 — 이것들이 모두 하나의 호출에 기반한 증강된 LLM이다.

워크플로우 (Workflows)

단일 호출로 처리할 수 없는 문제가 있을 때의 자연스러운 대응은 호출들을 연결하는 것이다. 이를 **프롬프트 체이닝(prompt chaining)**이라 한다.

Anthropic이 워크플로우라 부르는 이 패밀리에는:

• 라우팅(Routing): 입력을 분류하고 전문 핸들러로 보냄
• 병렬화(Parallelization): 하위 작업을 동시에 실행
• 오케스트레이터-워커(Orchestrator-worker): 관리자 LLM이 전문가 LLM들에 위임
• 평가자-최적화자(Evaluator-optimizer): 하나가 생성하고 다른 하나가 비판하는 사이클

모든 워크플로우의 공통점: 단계 수와 경로는 개발자가 설계 시점에 결정한다.

루프 (The Loop)

에이전트는 LLM을 루프에 감싸고 모델이 루프 종료를 결정하게 할 때 만들어진다. 루프 자체는 단순한 코드다. 런타임이 LLM을 호출하고, 출력을 읽고, 출력이 명시한 행동을 디스패치하고, 결과를 다시 모델의 시야에 피드백한 후, 모델을 다시 호출한다. 이것이 모델이 최종 답변 신호를 생성할 때까지 반복된다.

루프의 4단계:

1. 인지(Perceive): 현재 상태(원래 작업, 지금까지 일어난 일의 기록, 새로운 입력)를 모델에 전달
2. 추론(Reason): 다음에 무엇을 할지 결정 (질문하기, 도구 호출, 최종 답변으로 마무리)
3. 행동(Act): 런타임이 모델이 요청한 것을 수행
4. 관찰(Observe): 행동의 결과를 캡처하고 상태에 반영

가장 중요한 세부사항: 루프 종료를 누가 결정하는가. 워크플로우에서는 개발자가 설계 시점에 결정한다. 에이전트에서는 모델이 런타임에 결정한다.

결정들 (Decisions)

루프를 통과하는 매 턴마다, 모델의 출력은 4가지 분기 중 하나를 선택한다:

1. 최종 답변(Final answer): 원래 작업에 대한 완전한 응답. 런타임이 이를 루프 종료 신호로 해석한다.
2. 도구 호출(Tool call): 특정 인수로 특정 함수를 호출하도록 런타임에 지시. 도구 실행 후 결과가 대화 상태에 추가되고 모델로 돌아간다.
3. 핸드오프(Handoff): 현재 작업을 다른 에이전트(종종 자체 프롬프트와 도구 세트를 가진 전문가)에게 넘기도록 결정.
4. 지속적 사고(Continued thought): 사고만으로 구성된 추론 턴. ReAct 스타일 구현에서 가장 자주 등장.

ReAct 패턴

ReAct는 **추론(Reasoning) + 행동(Acting)**의 약자다. 이 패턴은 모델에게 같은 응답 안에서 추론 단계와 행동 단계를 교차시키도록 요청한다.

고객 지원 에이전트 예시:

1. 사용자: "최근 주문 상태 알려줘"
2. 모델 사고: 주문 서비스에서 주문을 찾아야 함
3. 모델 행동: get_recent_order(user_id) 호출
4. 관찰: 주문 번호 9152, 5월 14일 접수
5. 모델 사고: 해당 주문의 배송 상태 필요
6. 모델 행동: get_shipping_status(order_id) 호출
7. 관찰: 배송 중, 5월 29일 도착 예정
8. 최종 답변: 사용자에게 상태 요약 전달

가드레일 (Guardrails)

가드레일은 루프가 외부 세계와 교차하는 지점마다 위치한다. OpenAI Agents SDK는 세 가지 가드레일 패밀리를 문서화한다:

• 입력 가드레일(Input guardrails): 첫 번째 턴에서 실행. 프롬프트 인젝션 시도, 정책 위반 요청, 범위 밖 입력을 포착. 빠른 소형 모델을 가드레일로 사용하는 것이 일반적.
• 도구 가드레일(Tool guardrails): 모든 함수 도구 호출을 감싼다. 사전 가드레일은 호출 전 실행하여 차단하거나 모델에게 메시지로 대체. 사후 가드레일은 실행 후 결과를 재작성하거나 차단.
• 출력 가드레일(Output guardrails): 최종 응답에서 실행, 사용자가 보기 전 마지막 정책 시행 레이어.

트레이드오프

루프 제어를 모델에게 넘기는 것은 강력하지만, 세 가지 실질적인 비용이 있다:

1. 복합 오류(Compounding error) 단계별 신뢰도가 95%라면, 10단계에 걸쳐 모든 단계가 맞을 결합 확률은 약 60%. 20단계로 늘리면 약 36%로 떨어진다. 코딩 에이전트가 개방형 작업 에이전트보다 잘 작동하는 이유는 테스트 피드백이 단계별 신뢰도를 높이기 때문이다.

2. 루프 주변의 스캐폴딩(Scaffolding) 루프 주변의 하네스가 루프 내부의 모델만큼 중요하다. Anthropic의 내부 실험: 심지어 frontier 모델도 Claude Agent SDK에서 고수준 프롬프트로 프로덕션 품질 웹앱을 구축하는 데 부족함을 보였다. 수정은 더 좋은 모델이 아닌 스캐폴딩이었다 — 초기화 에이전트, 코딩 에이전트, 세션 간 이동하는 진행 파일, 에이전트가 복구에 사용할 수 있는 git 기록.

3. 잘못된 도구 선택(Wrong tool for the job) 에이전트는 종종 잘못된 선택이다. 워크플로우는 예측 가능성과 일관성을 제공한다. 에이전트는 유연성을 제공하지만, 그 유연성을 지연 시간, 비용, 더 예측할 수 없는 실패 면으로 지불한다.

결론

에이전트 루프는 인식 가능한 진행의 끝에 있다:

단일 LLM 호출 → 증강된 LLM (도구+검색+메모리) → 워크플로우 (체인) → 에이전트 (루프 제어를 모델에게)

루프 내부에서 네 단계가 반복된다: 인지, 추론, 행동, 관찰. 매 턴마다 모델의 출력이 최종 답변, 도구 호출, 핸드오프, 지속적 사고 중 하나를 선택한다. ReAct가 루프를 채우는 가장 일반적인 프롬프트 패턴이다. 가드레일은 루프가 외부 세계와 교차하는 모든 곳에 위치한다.

설계는 세 가지 실질적인 비용을 수반한다: 단계 전반에 걸친 복합 신뢰도, 프로덕션 루프에 필요한 하네스 스캐폴딩, 워크플로우가 문제를 더 저렴하게 해결할 수 있는지에 대한 질문.

---

핵심 요약 (20줄)

1. 에이전트 정의: LLM을 루프에 배치하고 모델 자신이 루프 종료를 결정하는 시스템
2. 증강된 LLM: 도구 사용 + 검색 + 메모리 조합이 모든 에이전트 시스템의 기본 단위 (Anthropic 개념)
3. 진화 단계: 단일 LLM 호출 → 증강된 LLM → 워크플로우 → 에이전트 (루프 제어를 모델에게)
4. 워크플로우 vs 에이전트: 워크플로우는 개발자가 설계 시점에 경로 결정, 에이전트는 모델이 런타임에 결정
5. 4단계 루프: 인지(Perceive) → 추론(Reason) → 행동(Act) → 관찰(Observe) 반복
6. 관찰의 중요성: 모델이 행동 결과를 보고 다음 동작을 결정하는 폐루프 핵심 요소
7. 4가지 분기: 최종 답변 / 도구 호출 / 핸드오프 / 지속적 사고
8. ReAct 패턴: 추론(Reasoning) + 행동(Acting) 교차 — 가장 보편적인 에이전트 프롬프트 패턴
9. 3종 가드레일: 입력(첫 턴 이전) / 도구(함수 호출 전후) / 출력(사용자 전달 전)
10. 비용 #1 복합 오류: 95% 신뢰도 × 10단계 = 60% 성공률, 20단계 = 36%로 급락
11. 코딩 에이전트 우수성 이유: 테스트 피드백이 단계별 신뢰도를 높여 복합 오류 감소
12. 비용 #2 스캐폴딩: Anthropic 실험 — 모델보다 스캐폴딩(초기화 에이전트+진행 파일+git 기록)이 성능 결정
13. 비용 #3 도구 선택: 많은 문제가 에이전트보다 워크플로우로 더 저렴하게 해결 가능
14. 핵심 원칙: 가장 단순한 해결책을 찾고, 필요할 때만 복잡성 추가
15. 프로덕션 현실: 오늘날 LLM 기반 프로덕션 시스템 대부분은 에이전트가 아닌 워크플로우
16. max-turns 역할: 에이전트의 이터레이션 상한선은 안전망, 주 종료 신호는 모델에서
17. 도구 가드레일 중요성: 도구는 실제 시스템에 접촉하는 방법 — 감독 필수
18. 입력 가드레일 패턴: 빠른 소형 모델로 필터링 → 비싼 메인 모델은 통과한 입력만 처리
19. 출력 가드레일 역할: 민감 데이터 유출, 회사 정책 위반 주장 등 최종 방어선
20. 결론: 에이전트의 강력함은 루프 제어 양도에서 오지만, 복합 오류·스캐폴딩·비용 트레이드오프 이해가 선행되어야