Skip to main content
← AI Agent 아키텍처 개요

​
ReAct 패턴 (Reasoning + Acting)

ReAct는 2022년 Yao et al.이 제안한 패턴으로, LLM이 추론(Reasoning) 과 행동(Acting) 을 번갈아 수행합니다.

​
ReAct 루프 상세 예시

사용자 질문: “지난 분기 매출이 가장 높은 제품 3개와 그 이유를 분석해주세요”
단계내용
Thought 1매출 데이터를 DB에서 조회해야 합니다. SQL을 실행하겠습니다.
Action 1query_sql("SELECT product_name, SUM(revenue) as total FROM sales WHERE quarter='2025Q4' GROUP BY product_name ORDER BY total DESC LIMIT 3")
Observation 1결과: [{“product_name”: “Pro Plan”, “total”: 12억}, {“product_name”: “Enterprise”, “total”: 9.5억}, {“product_name”: “Starter”, “total”: 7.2억}]
Thought 2상위 3개 제품을 확인했습니다. 이유를 분석하려면 마케팅 캠페인 데이터도 확인해야 합니다.
Action 2search_documents("2025 Q4 마케팅 캠페인 결과 보고서")
Observation 2문서 발견: “Pro Plan 할인 프로모션(11월), Enterprise 대기업 계약 3건 체결…”
Thought 3매출 데이터와 마케팅 정보를 종합하여 분석 보고서를 작성할 수 있습니다.
Answer최종 분석 보고서 생성
주의 ReAct 루프가 무한히 반복되지 않도록 최대 반복 횟수(보통 5~15회)와 타임아웃 을 반드시 설정하세요.

​
ReAct의 실패 모드

프로덕션 환경에서 ReAct 패턴을 운영하다 보면 반드시 마주치는 실패 모드가 있습니다. 미리 알고 대비하면 디버깅 시간을 대폭 줄일 수 있습니다.

​
1. 무한 루프 (Infinite Loop)

Agent가 같은 도구를 반복 호출하거나, 같은 추론을 되풀이하는 현상입니다.
원인증상해결법
도구 결과가 Agent의 기대와 다름같은 SQL을 미세하게 바꿔가며 반복 실행System Prompt에 “3회 시도 후 실패 보고” 규칙 추가
종료 조건이 모호함”더 좋은 결과가 있을 수 있다”며 계속 검색명확한 완료 기준을 프롬프트에 명시
도구 에러를 이해하지 못함에러를 무시하고 같은 호출 반복에러 메시지를 LLM이 이해할 수 있는 형태로 포매팅

​
2. 잘못된 도구 선택 (Wrong Tool Selection)

Agent가 주어진 맥락에 맞지 않는 도구를 선택하여 불필요한 비용과 시간이 발생합니다.
원인증상해결법
도구 설명이 서로 유사함”search_documents”와 “query_knowledge_base”를 혼동각 도구의 용도 차이를 설명에 명시
도구 수가 너무 많음 (15개 이상)무관한 도구를 자주 선택카테고리별 라우팅 또는 도구 수 축소
사용자 의도 파악 실패”삭제해줘”를 “조회”로 해석Few-shot 예시를 System Prompt에 추가

​
3. 관찰 결과 오해 (Observation Misinterpretation)

도구가 올바른 결과를 반환했지만, Agent가 그 결과를 잘못 해석하는 경우입니다. 이것이 가장 교활한 실패 모드입니다. 겉보기에는 정상적으로 동작하기 때문입니다.
원인증상해결법
숫자/단위 혼동”1200”을 1,200원으로 해석 (실제는 1,200만원)도구 결과에 단위를 명시적으로 포함
빈 결과 = 없음으로 단정검색 결과 0건을 “데이터가 없다”로 결론”결과 없음 시 다른 검색어 시도” 규칙 추가
부분 결과를 전체로 착각LIMIT 10 결과를 “전체 데이터”로 해석도구 결과에 전체 건수/페이지 정보 포함

​
ReAct vs Plan-and-Execute 의사결정 가이드

실무에서 가장 많이 받는 질문입니다: “우리 사용 사례에는 어떤 패턴이 맞나요?” 아래 의사결정 기준을 참고하세요.
판단 기준ReAct 추천Plan-and-Execute 추천Multi-Agent 분해 추천
예상 단계 수3단계 이하4~9단계10단계 이상
작업 예측 가능성입력에 따라 경로가 달라짐대부분 정해진 단계를 따름병렬 실행 가능한 독립 하위 작업 존재
대표 사례FAQ 응답, 단순 조회보고서 생성, 데이터 파이프라인크로스 도메인 분석, 복합 워크플로우
실패 시 복구즉각 재시도 가능계획 수정 후 재실행실패한 Sub-Agent만 재실행
비용 효율가장 낮음중간 (계획 수립에 추가 토큰)가장 높음 (다수 LLM 호출)
참고 실전 팁: 확신이 없으면 ReAct로 시작 하세요. 그리고 Agent가 자주 길을 잃거나 5단계 이상의 추론이 반복되면, 그때 Plan-and-Execute로 전환합니다. 처음부터 복잡한 패턴을 선택하면 디버깅 비용이 기하급수적으로 증가합니다.

​
실전 ReAct System Prompt 예시

아래는 프로덕션 환경에서 실제 사용 가능한 수준의 System Prompt입니다. 데이터 분석 Agent를 기준으로 작성했으며, 실패 방지 규칙들이 포함되어 있습니다. 
당신은 데이터 분석 Agent입니다. 사용자의 데이터 관련 질문에 도구를 활용하여 정확히 답변합니다.

## 행동 원칙
1. 도구 호출 전에 반드시 "왜 이 도구를 사용하는지" 먼저 생각하세요.
2. 한 번의 질문에 도구 호출은 최대 7회까지만 허용됩니다.
3. 같은 도구를 같은 인자로 2회 이상 호출하지 마세요.

## 도구 사용 규칙
- query_sql: SQL 쿼리 실행. SELECT만 가능. 결과가 1000행 이상이면 LIMIT을 사용하세요.
- search_documents: 사내 문서 검색. 키워드 2~5개로 검색하세요.
- get_customer_info: 고객 ID로 고객 정보 조회. 고객명으로는 검색 불가.

## 실패 시 대응
- 도구 호출이 에러를 반환하면, 에러 메시지를 분석하고 수정된 인자로 1회 재시도하세요.
- 재시도도 실패하면, 사용자에게 실패 사유를 설명하고 대안을 제시하세요.
- 검색 결과가 없으면, 검색어를 바꿔 1회 재시도하세요.

## 응답 형식
- 데이터 기반 답변: 반드시 출처(어떤 테이블, 어떤 문서)를 명시하세요.
- 숫자 포함 시: 단위(원, 건, %)를 반드시 표기하세요.
- 확실하지 않은 내용: "~로 추정됩니다"와 같이 불확실성을 표현하세요.
성공 핵심 포인트: 좋은 System Prompt는 “무엇을 하라”뿐 아니라 “실패했을 때 어떻게 하라” 를 명시합니다. 실패 대응 규칙이 없는 Agent는 프로덕션에서 반드시 문제를 일으킵니다.

​
Agent Planning 패턴

ReAct 패턴은 “한 단계씩 생각하고 행동”하는 방식입니다. 하지만 복잡한 작업에는 사전 계획(Planning) 이 필요합니다.

​
Plan-and-Execute 패턴

먼저 전체 계획(단계 목록)을 수립하고, 각 단계를 순차적으로 실행합니다. 실행 중 문제가 발생하면 계획을 수정할 수 있습니다. 
사용자: "분기 매출 보고서를 만들어줘"

Plan:
1. 매출 데이터 조회 (SQL)
2. 전분기 대비 증감 계산
3. 제품별 매출 비중 분석
4. 차트 생성
5. 보고서 포맷으로 정리

Execute: 각 단계를 순차 실행, 실패 시 Plan 수정

​
ReAct vs Plan-and-Execute 비교

항목ReActPlan-and-Execute
접근 방식한 단계씩 생각하고 행동먼저 전체 계획 수립 후 실행
적합한 작업단순한 작업, 적은 단계복잡한 작업, 다수의 단계
작업 흐름예측 불가능한 흐름구조화된 출력이 필요한 경우
장점유연, 즉각 반응체계적, 진행 상황 추적 가능
단점복잡한 작업에서 길을 잃을 수 있음초기 계획 수립에 시간 소요
대표 구현LangGraph ReAct AgentLangGraph Plan-and-Execute 템플릿
참고 LangGraph는 Plan-and-Execute 템플릿을 공식 제공합니다. Planner 노드가 계획을 생성하고, Executor 노드가 실행하며, Replanner 노드가 결과를 보고 계획을 수정하는 구조입니다.
다음: Tool Use / Function Calling →