> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# ReAct 패턴 & Planning

> 이 문서는 **[GenAI 개념](/blog/guides/genai-concepts/overview)** 섹션의 일부입니다.

[← AI Agent 아키텍처 개요](overview)

***

## ReAct 패턴 (Reasoning + Acting)

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

### ReAct 루프 상세 예시

사용자 질문: **"지난 분기 매출이 가장 높은 제품 3개와 그 이유를 분석해주세요"**

| 단계                | 내용                                                                                                                                                 |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Thought 1**     | 매출 데이터를 DB에서 조회해야 합니다. SQL을 실행하겠습니다.                                                                                                               |
| **Action 1**      | `query_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 2**      | `search_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 비교

| 항목         | ReAct                 | Plan-and-Execute               |
| ---------- | --------------------- | ------------------------------ |
| **접근 방식**  | 한 단계씩 생각하고 행동         | 먼저 전체 계획 수립 후 실행               |
| **적합한 작업** | 단순한 작업, 적은 단계         | 복잡한 작업, 다수의 단계                 |
| **작업 흐름**  | 예측 불가능한 흐름            | 구조화된 출력이 필요한 경우                |
| **장점**     | 유연, 즉각 반응             | 체계적, 진행 상황 추적 가능               |
| **단점**     | 복잡한 작업에서 길을 잃을 수 있음   | 초기 계획 수립에 시간 소요                |
| **대표 구현**  | LangGraph ReAct Agent | LangGraph Plan-and-Execute 템플릿 |

> **참고**
> LangGraph는 [Plan-and-Execute 템플릿](https://langchain-ai.github.io/langgraph/tutorials/plan-and-execute/plan-and-execute/)을 공식 제공합니다. Planner 노드가 계획을 생성하고, Executor 노드가 실행하며, Replanner 노드가 결과를 보고 계획을 수정하는 구조입니다.

***

[다음: Tool Use / Function Calling →](tool-use)