ReAct: 도구를 쓰는 모델에서 결과를 보고 행동을 바꾸는 모델로

언어 모델에게 답을 구하라고 하면 그럴듯한 설명을 만들 수 있다. 검색 도구를 주면 검색할 수도 있다. 그런데 도구를 여러 번 쓰는 순간 중요한 것은 어떤 호출을 지원하느냐보다, 호출 결과를 보고 다음 행동을 어떻게 바꾸느냐다. ReAct는 이 연결을 단순한 형식으로 보여 준다. 계획을 세우는 텍스트, 실제 행동, 환경의 관찰을 번갈아 이어 가는 방식이다.

행동하고 나면 문제 자체가 달라진다

ReAct는 Reasoning과 Acting을 함께 다룬다. 모델은 문제 해결을 위한 짧은 판단을 생성하고, 과제에 맞는 행동을 선택하며, 환경에서 돌아온 결과를 다시 입력으로 받는다. 이 과정을 반복하면서 계획을 유지하거나 고친다. 검색에서 새 문서를 찾는 일은 정보를 추가하는 동시에 다음에 무엇을 확인해야 하는지도 바꾼다. ReAct 원문

한 번에 완성된 행동 목록을 만드는 방식과 비교하면 차이가 선명하다. 시작할 때 'A를 찾고 B를 확인한 뒤 답한다'고 정할 수 있지만, 실제 검색 결과가 A와 동명이인을 보여 줄 수도 있다. 결과를 받기 전에 모든 행동을 확정하면 예상 밖 상황에 대응하기 어렵다. 관찰을 다음 행동의 입력으로 삼으면 검색어를 바꾸거나 다른 출처로 이동할 수 있다.

직접 만든 예를 들어 보자. 문서 도우미에게 '설정값을 바꾼 뒤 서비스를 다시 시작해야 하는가'를 물었다. 첫 검색에서 일반 설정 안내만 찾았다면, 다음 호출은 재시작 조건을 명시한 문서를 겨냥해야 한다. 새 문서가 특정 버전에서는 재시작이 불필요하다고 말하면, 처음의 가정을 유지하지 않고 버전 조건을 확인해야 한다. 도구를 한 번 사용했다는 사실보다 그 결과가 행동을 바꾸었는지가 중요하다.

이 예는 설명을 위한 상황이다. 원문의 과제는 Wikipedia 기반 질문 답변과 사실 검증, 텍스트 환경 ALFWorld, 웹 쇼핑 환경 WebShop 등이다. 현대의 모든 에이전트 시스템이나 임의의 업무 도구가 이미 같은 성능을 낸다는 의미는 아니다.

프롬프트가 보여 주는 것은 답만이 아니다

원문은 몇 개의 문제 해결 궤적을 예시로 제공한다. 예시에는 모델이 만든 텍스트 판단과 행동, 환경이 반환한 관찰이 포함된다. 즉 정답을 보여 주는 것뿐 아니라 정답에 이르는 상호작용 형식을 보여 준다. 의사결정 환경에서는 매 단계 긴 설명을 넣기보다 필요한 지점에서 판단을 삽입하는 방식도 사용한다. 공식 프로젝트의 프롬프팅 설명

환경의 관찰과 모델의 발화를 구분하는 것도 중요하다. 모델이 '파일이 저장되었다'고 썼다고 파일이 실제로 저장된 것은 아니다. 저장 도구의 결과나 상태 조회가 있어야 한다. 같은 맥락에서 검색 결과를 모델이 지어내면 외부 근거를 이용한 상호작용이 아니라 텍스트 흉내가 된다.

실제 구현에서는 모델이 행동을 요청한 뒤 제어를 환경에 넘기고, 환경이 실행 결과를 반환하는 구조가 필요하다. 행동 문자열을 해석하는 부분, 도구 오류를 정해진 형식으로 돌려주는 부분, 반복을 끝내는 조건도 들어간다. ReAct가 제시하는 형식은 이 연결을 표현하는 방법이지, 실행 환경 자체를 자동으로 제공하는 라이브러리는 아니다.

나는 이 구분이 에이전트를 평가할 때 특히 유용하다고 생각한다. 최종 답만 보면 매끄러운 성공처럼 보여도, 실제 도구 결과와 어긋날 수 있다. 반대로 중간에 한 번 실패했더라도 상태를 확인하고 회복했다면 상호작용 능력을 보여 준 것이다. 중요한 평가 단위가 답 한 개에서 행동과 결과의 연속으로 넓어진다.

검색이 환각을 줄여도 다른 오류는 남는다

원문은 추론만 하는 방식, 행동만 하는 방식, 둘을 결합한 방식 등을 비교한다. 질문 답변에서 외부 지식을 가져오면 근거 없는 사실 생성의 일부를 줄일 수 있다. 행동만 하는 방식은 정보를 얻어도 이를 연결해 답하는 데 어려움을 보일 수 있다. 그래서 판단과 행동의 연결이 도움이 된다.

하지만 ReAct가 모든 조건에서 추론만 하는 방식보다 우수하다고 말하는 것은 과장이다. 원문에서는 과제에 따라 결과가 다르고, ReAct와 추론 중심 방식을 결합한 접근도 평가한다. 오류 분석에는 검색이 필요한 정보를 못 찾는 경우, 잘못된 판단, 같은 행동을 반복해 빠져나오지 못하는 경우가 등장한다. 원문 비교와 실패 분석

이 구분이 흥미롭다. 모델이 내부 지식만 사용하면 잘못된 사실을 매끄럽게 이어갈 수 있다. 도구를 사용하면 그 오류를 관찰로 교정할 기회가 생기지만, 이제는 도구 선택이나 검색 실패도 새 오류 원인이 된다. 오류가 사라진다기보다 위치와 형태가 바뀐다. 실패가 관찰 가능해졌다는 것 역시 별도의 이점이다.

외부 자료도 늘 옳은 것은 아니다. 문서가 낡았거나, 도구 응답이 불완전하거나, 검색 결과가 질문과 비슷하지만 다른 대상을 다룰 수 있다. 따라서 출처가 있다는 이유만으로 최종 답의 정확성이 보장되는 것은 아니다. 가져온 관찰이 실제 질문을 지지하는지 확인하는 문제는 남는다.

로그를 볼 수 있다는 것의 의미

ReAct 형식은 어떤 행동을 요청했고 어떤 응답을 받았는지 살펴보기 편하게 한다. 문제 해결이 어디에서 어긋났는지 찾는 데 도움이 된다. 공식 프로젝트는 사람이 일부 텍스트 판단을 바꾸어 실패 궤적을 수정하는 예도 보여 준다. 프로젝트 사례

다만 생성된 판단 텍스트를 모델 내부 계산의 완전하고 충실한 설명으로 받아들이지는 않겠다. 사람이 읽을 수 있는 로그와 내부 과정에 대한 과학적 해석 가능성은 같은 성질이 아니다. 로그는 적어도 시스템이 어떤 요청을 했는지 확인하는 자료가 될 수 있지만, 그 문장만으로 왜 그런 선택을 했는지 완벽하게 설명하지는 못한다.

실무에서 남길 로그를 고른다면 입력의 중요한 식별자, 도구 이름과 인자, 실행 결과의 상태, 최종 근거를 중심에 놓겠다. 모든 중간 텍스트를 길게 저장하는 것보다 실패를 재현할 수 있는 상태 정보를 확보하는 편이 더 유용할 수 있다. 이는 원문의 프롬프트를 그대로 복사하자는 처방이 아니라 운영을 위한 내 판단이다.

반복에 예산을 주면 선택이 보인다

한 번 검색이 실패했을 때 같은 요청을 열 번 반복하는 시스템은 도구를 사용할 줄 알아도 잘 쓰지는 못한다. 내가 ReAct 형태의 도우미를 만든다면 호출 횟수와 총 시간에 예산을 두고, 같은 행동과 같은 결과가 반복되는지 감지하겠다. 실패한 호출에는 '도구 자체 오류'와 '정상 실행했지만 필요한 정보 없음'을 구분해 반환하고 싶다.

평가는 최종 성공률과 함께 호출 수, 회복 능력, 불필요한 반복을 보겠다. 검색 결과 한 개를 일부러 비워 보거나 환경 상태를 바꾸었을 때 다음 행동을 조정하는지 시험할 수 있다. 이런 실험은 외부 세계와의 연결을 제품 요구로 옮기는 방법이다.

ReAct에서 가장 실용적인 발상은 생각을 오래 쓰는 것 자체보다 관찰이 다음 행동을 바꾸게 하는 구조다. 계획은 실행 전에 완성되는 문서만이 아니라, 실행 결과를 받아 갱신되는 상태가 된다. 언어 모델에게 도구를 붙일 때 이 연결을 설계하는 일이 도구 목록을 늘리는 것만큼 중요하다.

읽은 논문: Shunyu Yao 외, ReAct: Synergizing Reasoning and Acting in Language Models, 사전 공개 2022, ICLR 2023. 논문 · 공식 프로젝트