ReAct는 Reasoning(생각)과 Acting(행동)을 합친 이름으로, AI 에이전트가 생각 → 행동(도구 호출) → 관찰을 답이 나올 때까지 되풀이하며 문제를 푸는 설계 패턴이다. 검색, 파일 확인, 코드 실행처럼 결과를 보고 다음 판단을 바꿔야 하는 작업에 쓰며, 지금 나와 있는 AI 에이전트 대부분이 이 구조로 돈다.
| 방식 | 하는 일 | 약점 |
|---|---|---|
| 생각만 | 머릿속 추론만으로 답한다 | 모르는 사실을 지어낼 수 있다 |
| 행동만 | 정해 둔 순서대로 도구를 부른다 | 결과를 보고 계획을 고치지 못한다 |
| ReAct | 생각과 도구 호출을 번갈아 한다 | 단계가 늘수록 느려지고 비용이 커진다 |
"이 프로젝트의 테스트 커버리지를 확인해줘"라고 시켰다고 해 보자. 에이전트는 아래 루프를 몇 번 돈 뒤, 더 할 행동이 없으면 최종 답을 낸다.
| 단계 | 예시 |
|---|---|
| Thought | 먼저 테스트 파일이 어디 있는지 봐야겠다 |
| Action | 프로젝트 폴더 구조 탐색 |
| Observation | tests 폴더에 테스트 파일이 있다 |
| Thought → Action | 커버리지 도구를 실행하고 결과를 분석한다 |
초기에는 프롬프트에 Thought/Action/Observation 형식의 예시를 보여 주고, 모델 출력에서 Action 줄을 잘라 내 도구를 실행했다. 그 결과를 Observation으로 붙여 다시 모델에 보내는 방식이었다. 요즘은 모델 API의 도구 호출(function calling) 기능이 Action을 구조화된 형태로 돌려주므로 텍스트를 직접 파싱할 일이 줄었다.
순서는 단순하다. 도구와 설명을 정의하고 모델을 부른다. 도구 호출이 오면 실행한 뒤 결과를 대화에 붙여 다시 부른다. 도구 호출 없이 답만 오면 끝낸다. LangChain 같은 프레임워크도 ReAct 에이전트를 기본으로 제공하지만, 짧은 코드로 직접 짜도 충분하다.
| 상황 | 선택 |
|---|---|
| 다음 단계가 이전 결과에 달린 조사·디버깅 | ReAct |
| 순서가 늘 같은 정형 업무 | 고정된 워크플로 |
| 도구 없이 답할 수 있는 질문 | 모델 한 번 호출 |
같은 도구를 계속 부르며 루프에 갇힐 수 있으니 최대 반복 횟수를 정해 둔다. 관찰 결과가 너무 길면 대화가 금방 불어나 비용이 커지므로 필요한 부분만 잘라 넘긴다. 도구가 실패하면 그 오류도 관찰로 돌려줘야 모델이 다른 방법을 시도할 수 있다.
생각 단계가 기록에 남는다는 점도 장점이다. 에이전트가 이상하게 움직이면 Thought 로그를 따라가며 어디서 판단이 틀렸는지 찾을 수 있다.
사람들이 ReAct를 따로 의식하지 않아도 도구를 쓰는 에이전트의 기본 뼈대로 이미 쓰고 있다. 한 번에 답이 안 나오고, 중간 결과를 보고 다음 행동을 정해야 하는 일이 대표적이다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코딩 에이전트 | 파일 읽기, 코드 수정, 테스트 실행을 번갈아 하며 실패 메시지를 보고 다시 고친다 |
| 웹 검색 답변 | 검색 결과를 읽고 정보가 부족하면 검색어를 바꿔 다시 찾은 뒤 답한다 |
| 사내 문서 검색 | 관련 문서를 찾아 읽고, 답에 필요한 내용이 없으면 다른 문서를 더 찾아본다 |
| 데이터 분석 | 쿼리나 코드를 실행해 결과를 보고 다음에 무엇을 확인할지 정한다 |