ReAct 논문은 지금도 AI 에이전트를 설명할 때 자주 다시 호출됩니다. 이유는 성능 숫자보다 구조에 있습니다. 생각, 행동, 관찰이 어떻게 하나의 루프로 이어지는지를 가장 선명하게 보여줬기 때문입니다. 이 글에서는 ReAct를 논문 요약이 아니라 agent workflow 설명서처럼 풀어보겠습니다.
왜 ReAct가 나왔나
ReAct 이전에도 한쪽에서는 chain-of-thought prompting처럼 중간 추론을 길게 적는 흐름이 있었고, 다른 한쪽에서는 검색·웹 탐색·환경 제어처럼 행동을 고르게 하는 흐름이 있었습니다. 문제는 이 둘이 자주 따로 놀았다는 점입니다.
생각만 길게 하면 외부 세계를 확인하지 못하고, 행동만 많으면 왜 지금 이 행동을 해야 하는지가 흐려집니다. ReAct는 이 둘을 번갈아 묶어서 계획과 상호작용을 하나의 구조 안에 넣었습니다.
ReAct의 핵심
ReAct는 언어 모델이 reasoning trace와 task action을 interleaved manner로 생성하게 하는 방식입니다. 답을 바로 내놓기보다 생각을 정리하고, 행동하고, 결과를 받고, 다시 생각하게 만드는 루프라고 보면 됩니다.
중요한 것은 단계 수가 아니라 순환입니다. thought가 action을 고르고, action이 observation을 만들고, observation이 다시 다음 thought를 바꿉니다. 그래서 모델은 처음 가설을 끝까지 밀어붙이기보다 중간에 확인하고 수정할 수 있습니다.
생각-행동-관찰 세 단계 구조
- Thought: 지금 무엇이 부족한지, 다음 행동이 왜 필요한지 정리하는 단계
- Action: 검색, 도구 호출, 웹 탐색, 코드 실행처럼 바깥으로 실제 손을 뻗는 단계
- Observation: 행동 결과를 받아 보고 다음 판단에 반영하는 단계
Google Research 설명에서도 reasoning traces는 계획을 세우고 유지하고 고치는 데 도움을 주고, actions는 Wikipedia 같은 외부 정보원과 상호작용해 reasoning에 필요한 재료를 가져온다고 설명합니다.
아주 짧은 흐름 예시
아주 단순한 질문이라면 ReAct는 정답을 바로 쓰지 않고, 확인 → 관찰 → 초점 수정 순서로 움직입니다.
- 먼저 핵심 정의가 맞는지 확인해야겠다고 판단한다
- 논문 초록이나 공식 설명을 찾아본다
- reasoning traces와 task-specific actions를 섞어 생성한다는 문장을 확인한다
- 이제 초점을 단순한 추론이 아니라 추론과 행동의 교차 구조로 잡는다
- 다음으로 chain-of-thought와의 차이를 확인한다
- 외부 정보와 상호작용해 grounded reasoning을 돕는다는 설명을 본다
- 최종 답변에서는 ReAct를 외부 세계와 상호작용하며 판단을 갱신하는 구조로 설명하게 된다
이 예시에서 중요한 것은 마지막 답변 문장보다, 단계가 진행될수록 근거가 더해지고 설명의 초점이 바뀐다는 점입니다. 바로 이 지점이 ReAct를 agent-design 관점에서 특별하게 만듭니다.
질문에 답할 때 ReAct는 어떻게 움직이나
질문이 “ReAct는 왜 chain-of-thought보다 에이전트 설계에 더 가깝나요?”라면, ReAct식 접근은 정답을 바로 던지지 않고 정의 확인 → 한계 확인 → 설명 초점 수정 순서로 답을 다듬습니다.
- 먼저 ReAct의 정의를 정확히 잡는다
- 논문 초록이나 프로젝트 설명을 확인한다
- reasoning traces와 action을 섞어 생성한다는 핵심 표현을 확보한다
- 초점이 긴 생각 자체보다 생각과 외부 상호작용의 결합이라는 점을 정리한다
- 이어서 chain-of-thought의 한계를 다시 확인한다
- 외부 근거에 닿지 않으면 hallucination을 줄이기 어렵다는 점을 확인한다
- 최종 설명도 생각을 유지하면서 바깥 정보를 확인하고 계획을 수정하는 구조로 정리된다
여기서 포인트는 검색을 했다는 사실보다, 검색 결과가 설명의 중심을 바꿨다는 점입니다.
쇼핑 추천에서는 어떻게 움직이나
예를 들어 “재택근무용 기계식 키보드를 찾아줘. 너무 시끄럽지 않고, 맥과 잘 맞고, 20만 원 이하였으면 좋겠어”라는 요청에서는 기억 속 브랜드를 말하는 것보다 조건을 확인하며 후보를 좁히는 과정이 더 중요합니다.
- 먼저 중요한 조건이 소음, 맥 호환성, 가격이라는 점을 정리한다
- 해당 조건으로 후보를 넓게 검색한다
- 스위치 정보와 맥 배열 정보가 제품마다 제각각이라는 점을 발견한다
- 바로 추천하지 않고 후보별 스위치와 배열을 따로 확인하는 쪽으로 계획을 바꾼다
- 후보 A는 가격은 맞지만 맥 키캡 기본 제공이 아니라는 점을 확인한다
- 후보 B는 저소음 적축, 맥/윈도우 전환 지원, 18만 원대라는 정보를 확보한다
- 연결 안정성 후기를 추가로 확인한다
- 절전 복귀가 느리다는 관찰 때문에 단일 추천보다 비교 추천이 더 적절하다고 결론을 바꾼다
이 예시에서 중요한 것은 추천 대상만이 아닙니다. observation 이후 추천 방식 자체가 단일 추천에서 비교 추천으로 바뀐다는 점이 중요합니다.
코딩 에이전트에서 ReAct를 보면
“테스트가 깨졌으니 원인을 찾아 고쳐줘”라는 요청은 오늘의 tool-using agent와 ReAct가 실제로 어떻게 이어지는지 가장 잘 보여줍니다.
- 우선 실패한 테스트와 에러 유형을 확인해야 한다고 판단한다
- 테스트를 실행해 실제 실패 로그를 본다
- 여러 테스트가 모두 timezone 관련 AssertionError로 실패했다는 공통점을 발견한다
- 관련 구현 파일을 읽어 공통 원인을 좁힌다
- naive datetime을 로컬 시간으로 가정한 구현을 확인한다
- 테스트 기대값을 다시 읽어 입력이 UTC 기준 ISO 문자열이라는 점을 확인한다
- 파싱 기본값을 UTC aware로 바꾸는 수정에 들어간다
- 수정 뒤 다시 테스트를 실행한다
- 기존 실패가 모두 해결됐는지 확인한 뒤에만 수정 내용을 보고한다
이것은 사실상 현대 코딩 에이전트의 기본 루프입니다. 메모리, 권한 제어, 실패 복구가 더 붙어도 뼈대는 그대로입니다.
Chain-of-thought와 다른 점
chain-of-thought는 주로 내부 추론을 더 잘 전개하는 방식입니다. 반면 ReAct는 내부 추론과 외부 상호작용을 연결합니다. 그래서 지식 집약형 QA, 팩트 검증, 인터랙티브 환경 탐색처럼 바깥 정보가 필요한 문제에서 특히 의미가 컸습니다.
다만 이것을 ReAct가 CoT보다 무조건 낫다는 뜻으로 읽으면 곤란합니다. 행동이 거의 필요 없는 문제도 있고, 행동 비용이 너무 비싸면 괜히 많이 움직이다가 느려질 수 있습니다. 중요한 것은 우열보다 역할 차이입니다.
툴 호출과 무엇이 다른가
ReAct를 단순 tool use와 같다고 보면 절반만 본 셈입니다. 검색 도구를 여러 번 호출해도, 그 앞뒤에 왜 지금 이 도구를 써야 하는지와 결과를 보고 계획을 어떻게 바꿀지가 없다면 그것은 그냥 도구 호출에 더 가깝습니다.
ReAct의 포인트는 도구 사용을 추론 루프 안에 넣었다는 점입니다. 그래서 agent를 볼 때는 도구 개수보다 도구 사용의 판단 구조를 먼저 보는 편이 맞습니다.
논문이 보여준 가능성
논문은 HotpotQA, FEVER, ALFWorld, WebShop에서 ReAct를 평가했습니다. OpenReview와 arXiv 초록 기준으로 ALFWorld와 WebShop에서는 기존 imitation / reinforcement learning baselines 대비 절대 성공률 34%, 10% 개선을 보고했습니다.
이 수치를 오늘 기준의 최고 성능으로 읽을 필요는 없습니다. 더 중요한 메시지는 생각과 행동을 함께 묶는 구조가 성능뿐 아니라 해석 가능성과 신뢰성에도 의미가 있다는 점입니다.
ReAct가 주는 이점
근거를 확인할 수 있다
모델이 기억만으로 답하지 않고, 필요할 때 외부 근거를 확인합니다. hallucination을 완전히 없애지는 못해도, 적어도 근거 없는 자신감을 줄이는 데 도움을 줍니다.
중간에 계획을 바꿀 수 있다
처음 계획이 틀려도 중간에 바꿀 수 있습니다. 관찰 결과를 받은 뒤 탐색 순서, 추천 방식, 문제 정의 자체를 조정할 수 있습니다.
디버깅이 쉬워진다
중간 thought와 action을 보면 에이전트가 왜 그런 판단을 했는지 읽기 쉬워집니다. 실패했을 때 검색어가 문제였는지, 관찰 해석이 틀렸는지, 계획 전환 타이밍이 늦었는지 추적하기가 쉽습니다.
큰 행동 공간에서 낭비를 줄일 수 있다
행동 공간이 큰 환경에서는 무작정 이것저것 시도하는 것보다 짧은 reasoning이 행동 후보를 줄여줄 수 있습니다. 이 점은 웹 탐색이나 멀티스텝 업무 자동화에서 계속 중요합니다.
ReAct만으로 부족한 점
ReAct가 만능은 아닙니다. observation 품질이 낮으면 reasoning도 같이 흔들리고, 모든 단계에 thought를 길게 붙이면 오히려 느리고 비쌉니다. 논문이 action-heavy task에서 sparse reasoning을 쓴 이유도 여기에 있습니다.
또 잘못된 가설에 집착하면 도구를 써도 실패가 계속될 수 있습니다. 그래서 실전에서는 검증 루프, 반례 탐색, critic 역할, 사람 승인 같은 추가 장치가 필요합니다.
권한, 보안, 실패 복구, 시간 제한, 장기 메모리, 비용 관리 같은 운영 문제도 논문 범위를 넘어서는 설계 과제입니다. 따라서 ReAct는 만능 운영체제가 아니라 에이전트 핵심 루프를 설명하는 최소 모델로 보는 편이 정확합니다.
실무에서 자주 흔들리는 지점
과잉 탐색
필요 없는 검색과 도구 호출을 너무 많이 해서 비용만 커지는 경우입니다. 이때는 action budget이나 종료 조건이 필요합니다.
관찰 오독
도구 결과를 읽고도 핵심 제약을 잘못 해석하는 경우입니다. 예를 들어 가격은 맞지만 재고가 없는데, 그 사실을 놓친 채 추천을 계속할 수 있습니다.
목표 이탈
처음 사용자 요청과 다른 방향으로 점점 흘러가는 경우입니다. 이때는 주기적으로 목표를 다시 적어보는 thought가 도움이 됩니다.
실행 불일치
thought에서는 조심스럽게 하자고 했는데, action에서는 과격한 실행이 나가는 경우입니다. 그래서 현대 agent 시스템은 생각 루프만이 아니라 권한 정책까지 함께 둡니다.
오늘의 에이전트와 연결되는 부분
오늘의 tool-using agent는 ReAct보다 훨씬 복잡합니다. 메모리 계층, planner와 executor 분리, 함수 호출 스키마, self-check, evaluator 같은 층이 더 붙습니다. 그래도 ReAct가 계속 살아남는 이유는 복잡한 시스템을 이해하는 가장 작은 단위를 제공하기 때문입니다.
- 메모리: 과거 observation을 오래 보관
- 정책: 어떤 action이 허용되는지 제어
- 검증: 답변 전에 다시 확인
- 평가: 실패 원인을 다음 실행에 반영
- 분업: planner와 executor를 역할 분리
이렇게 보면 ReAct는 낡은 기법이 아니라 현대 agent stack의 가장 아래 골격에 가깝습니다. 코딩 에이전트, 웹 에이전트, 검색 에이전트 모두 도구는 달라도 생각-행동-관찰 루프는 크게 다르지 않습니다.
ReAct를 설계 아이디어로 쓸 때 볼 기준
- thought는 길이보다 의사결정 이유가 중요하다
- action은 정보 가치가 높은 것부터 고른다
- observation은 단순 수집이 아니라 제약 업데이트로 읽는다
- 루프마다 종료 조건을 둬야 과잉탐색을 막을 수 있다
- 중요한 작업에는 검증 단계나 사람 승인을 별도로 둔다
쉽게 말하면 ReAct를 잘 쓰는 방법은 계속 생각하고 계속 행동하게 만들기가 아닙니다. 가장 비싼 불확실성을 줄이는 행동을 먼저 고르고, 그 결과로 계획이 실제로 갱신되게 만드는 쪽에 가깝습니다.
지금 다시 읽을 이유
지금도 ReAct를 다시 읽을 가치가 있는 이유는 최신 유행이라서가 아닙니다. 모델이 언제 기억만 믿으면 안 되는지, 어떤 순간에 외부 도구가 필요한지, 행동 결과를 다음 판단에 정말 반영하고 있는지를 묻는 가장 쉬운 틀을 주기 때문입니다.
관련해서 함께 보면 좋은 글은 MCP란 무엇인가, Toolformer 논문 쉽게 이해하기, Claude Code, Codex, Gemini CLI 비교입니다. 구조, 도구 연결, 실제 workflow가 각각 어떻게 이어지는지 흐름이 더 또렷해집니다.
정리
ReAct를 한 줄로 줄이면 이렇습니다. AI가 생각만 하지 말고, 필요할 때 행동하고, 그 결과를 다시 생각에 반영하게 만들자. 이 한 줄을 이해하면 agent를 보는 눈도 같이 바뀝니다.
공식·원문 출처는 arXiv 논문, Google Research Blog, 프로젝트 사이트, OpenReview입니다.
