리액트(ReAct) 프레임워크 – LLM이 추론하고 행동하는 방식

생성형 AI가 사람처럼 생각하고 움직이기 위해선 단순한 텍스트 생성 그 이상이 필요하다. 질문에 답하는 것만으로는 부족하고, '무엇을 해야 할지', '어떻게 해결할지'를 스스로 판단하고 행동하는 능력이 핵심이다. 바로 이 지점을 해결해주는 것이 ReAct 프레임워크다. ReAct는 Reasoning + Acting, 즉 추론하고 행동하는 구조로 LLM을 확장시키는 방식이다. 나는 처음 이 구조를 접했을 때, 단순히 문장을 뱉는 모델이 아니라, 일종의 사고 과정을 거쳐 판단하는 ‘디지털 사고 체계’가 가능하다는 사실에 큰 충격을 받았다. 이 글에서는 ReAct의 기본 원리, 내부 작동 방식, 실제 프로젝트 적용에서의 효용성에 대해 체계적으로 설명하고자 한다. 단순 기술 개념이 아니라, ‘AI가 어떤 방식으로 사고하는가’에 대한 구조적 탐구다.

ReAct 프레임워크란? – AI의 사고 흐름을 구조화하는 기술

ReAct는 말 그대로 Reasoning(추론)과 Acting(행동)을 통합한 구조다. 이 구조의 핵심은 ‘대화형 언어모델이 단순히 응답만 하는 것이 아니라, 중간 사고 과정을 서술하고, 필요한 외부 도구를 호출하거나 직접 계산을 수행한다’는 데 있다. 내가 이 개념을 처음 마주했을 때 받은 인상은, LLM이 마치 체스 게임에서 수를 읽듯 문제를 단계별로 해결한다는 점이었다. 예전에는 “서울의 날씨 알려줘” 같은 질문에 단순 응답이 왔다면, ReAct 구조에선 “먼저 도시명을 추출 → 날씨 API 호출 → 결과 요약 → 사용자 친화적 문장으로 출력”까지를 순차적으로 사고한다. 중요한 건 이 과정을 ‘LM이 스스로 판단’한다는 것이다. 기술적으로 ReAct는 일종의 템플릿 시나리오를 활용해 LLM에게 다음의 문장 구조를 따르게 한다: Thought → Action → Observation → Thought → Action → … → Final Answer. 내가 직접 실험해봤던 프로젝트에서는, 수학 문제를 푸는 챗봇에 ReAct를 도입했다. 단순히 정답을 내는 것이 아니라, “먼저 문제를 분석하겠습니다 → 필요한 수식을 확인합니다 → 계산 도구를 호출합니다 → 결과를 정리합니다”와 같은 사고 흐름이 기록되면서 사용자 신뢰도가 훨씬 높아졌다. LLM의 결정 과정을 투명하게 노출하는 구조이기 때문에, 결과가 왜 그렇게 나왔는지 설명 가능한 AI(Explainable AI)의 형태에 가깝다. ReAct는 특히 Tool Use 구조와 궁합이 좋다. 외부 검색, 계산기, 데이터베이스 조회, API 호출 등 도구 사용을 동적으로 판단해서 실행하는 방식이다. 내가 LangChain의 AgentExecutor와 결합해 실험했을 땐, ReAct 기반 프롬프트 구조가 도구를 ‘정해진 순서가 아닌, 상황에 맞게 유연하게 호출’하게 만들었다. 이건 단순히 정답을 빠르게 얻는 게 아니라, AI가 판단력을 갖고 있다는 착각을 유도할 만큼 자연스러운 흐름을 만들어냈다. 결국 ReAct는 LLM을 단순한 언어 생성기에서 ‘의사결정 시스템’으로 확장시키는 브릿지 같은 존재다.

ReAct의 프롬프트 구성과 응용 전략 – 구조화된 사고를 만들다

ReAct의 핵심은 프롬프트 설계다. 단순한 질문-응답 형태로는 작동하지 않으며, 사고 과정의 흐름을 안내하는 틀을 명확히 만들어야 한다. 내가 주로 쓰는 구조는 다음과 같다: **Question:** [사용자 질문] **Thought:** [현재 무엇을 해야 하는지 추론] **Action:** [도구 또는 검색 수행] **Observation:** [행동 결과 기록] **Thought:** [다음 단계로의 추론] … **Final Answer:** [최종 응답]
이 방식은 처음에는 다소 번거롭게 느껴지지만, 실제로 문제 해결 능력을 테스트할 때 매우 유용하다. 특히 복합적인 문제, 예를 들어 “한국 GDP 순위를 알려주고, 그 수치를 미국과 비교해 달러 환산 후 그래프로 표현해줘” 같은 질문에선 ReAct 구조가 빛을 발한다. 일반적인 LLM 호출로는 처리 불가한 작업이다. 하지만 ReAct 방식으로 접근하면 ‘정보 분해 → 검색 → 수치 비교 → 시각화 도구 호출’ 등의 순서를 스스로 판단하게 할 수 있다. 내가 가장 유용하다고 느낀 건, 프롬프트 수준에서 에이전트의 행동을 통제할 수 있다는 점이었다. 예를 들어 “계산은 반드시 툴을 통해서만 하라” 또는 “3번 이상 Action 반복 금지” 같은 조건을 삽입하면, 모델이 판단 범위를 스스로 제한하고 효율적으로 답을 도출해낸다. 이건 마치 인간에게 ‘업무 지침’을 주는 것과 같은 효과다. ReAct는 프롬프트 디자인만 잘하면 실제 프로그램 로직처럼 움직인다. 내가 한 프로젝트에서는 사용자가 질문하면, ReAct가 내부적으로 위키 검색 → 요약 → 키워드 추출 → 재검색을 수행하고, 이 모든 과정을 사용자에게 보여주는 방식으로 신뢰감을 크게 높일 수 있었다. 다만 주의할 점도 있다. ReAct는 프롬프트가 길어질수록 토큰 비용이 커지고, 반복 루프에 빠질 가능성이 있다. 실제로 내가 만든 FAQ 챗봇이 같은 Action을 4번 반복한 적이 있었는데, 프롬프트에 ‘최대 반복 횟수 설정’ 문장을 넣고 해결했다. 또, 일부 LLM은 Thought/Action 패턴을 정확히 따르지 않는 경우가 있다. 그래서 모델에 따라 프롬프트 튜닝이 다르게 필요하다. 나는 이런 점에서 ReAct가 강력한 무기이지만, 여전히 ‘제어 가능한 사고 흐름’을 만들기 위해 많은 실험과 테스트가 필요한 구조라고 본다.

ReAct가 바꾸는 사용자 경험 – 단순 응답에서 협업으로

ReAct가 실질적으로 가져오는 가장 큰 변화는 사용자 경험이다. 내가 체감한 가장 강력한 변화는, AI가 단순히 ‘답을 내놓는 기계’에서 ‘함께 문제를 풀어가는 존재’처럼 느껴진다는 것이다. 예를 들어 사용자 질문에 대해 AI가 “먼저 이 문제를 분석해보겠습니다 → 관련 정보를 찾겠습니다 → 확인했습니다 → 다음 단계로 진행합니다”라고 단계적으로 사고를 공개하는 모습은, 사람의 사고 흐름과 유사하다. 사용자는 그 과정을 읽으며 신뢰를 쌓게 되고, AI가 단순한 자동응답 시스템이 아니라 ‘협업 파트너’처럼 느껴지기 시작한다. 이건 특히 비즈니스 도메인에서 큰 차이를 만든다. 내가 참여했던 B2B 리서치 도구에서는, ReAct 구조를 도입한 이후 고객 이탈률이 줄고, 사용자의 평균 체류 시간이 늘어났다. 이유는 명확했다. 결과만 주는 구조보다 ‘어떻게 도출했는가’를 보여주는 과정이 사용자의 불안감을 줄였기 때문이다. 특히 데이터 기반 의사결정에선 투명한 프로세스가 중요한데, ReAct는 그것을 가능하게 해준다. 이것이 Explainable AI의 실제 구현이고, ReAct는 그 가장 직관적인 구현체라고 생각한다. 나아가 ReAct는 멀티모달 구조와도 잘 연결된다. 이미지 분석, 코드 실행, 음성 처리 등 다양한 도구를 연결해 ReAct가 중심에서 판단하고 실행하도록 구성할 수 있다. 내가 만든 예제 중 하나는, 사용자의 텍스트 입력에 따라 이미지 분석 → 문장 생성 → 오디오 출력까지 자동으로 연결된 워크플로였다. ReAct가 이 흐름의 허브가 되었고, 전체 시스템이 자연스럽게 하나의 ‘AI 워커’처럼 작동했다. 나는 이 구조를 보며, ReAct가 단순한 텍스트 구조가 아니라, AI의 행위 구조를 설계하는 핵심 도구라는 걸 체감했다.

ReAct는 '답하는 AI'에서 '사고하는 AI'로 가는 징검다리다

ReAct 프레임워크는 생성형 AI가 단순한 응답 시스템에서 벗어나, 생각하고 판단하며 실행하는 구조로 진화할 수 있도록 만든 핵심 설계 방식이다. 내가 직접 써보며 느낀 건, 이 구조가 결과보다 ‘과정’에 집중하게 만들고, 사용자가 AI와 협업하고 있다는 감각을 만들어준다는 점이다. ReAct는 기술 그 자체로도 훌륭하지만, 그보다 더 중요한 건 ‘AI가 어떻게 사고하고 행동하는가’를 우리가 설계할 수 있게 해준다는 점이다. 결국 ReAct는 단지 프롬프트 기술이 아니라, AI 설계 철학의 한 축이다. 그리고 이 구조는 앞으로 더 많은 AI 시스템의 기본 사고 프레임으로 자리 잡게 될 것이다.