에이전트와 도구 사용: 말하는 모델이 일하는 모델이 되기까지

왜 필요했나: 말은 잘하는데 계산은 틀리는 모델

LLM(대규모 언어 모델)은 다음에 올 토큰(글자 조각)을 예측하는 방식으로 글을 만든다. 이 방식으로 번역·요약·대화는 잘하지만, Toolformer 논문이 짚었듯 산수나 사실 조회처럼 훨씬 작고 단순한 프로그램도 잘하는 일에서 오히려 실수한다. 최신 사건을 모르고, 그럴듯한 거짓을 지어내는 환각(Hallucination)도 생긴다.

한편 단계별로 생각을 적게 하는 방식(chain-of-thought, 생각의 사슬)은 추론력을 높였지만, ReAct 논문은 이를 '닫힌 블랙박스'라고 표현했다. 모델이 자기 머릿속 지식만으로 생각하므로 바깥 세상과 맞춰 보지 못하고, 중간에 틀린 사실이 끼면 그 오류가 끝까지 이어진다.

반대로 모델에게 행동 계획만 짜게 하는 연구도 있었지만, 이쪽은 높은 수준의 목표를 따져 보거나 진행 상황을 기억하는 '생각'이 빠져 있었다. 생각과 행동이 따로 연구되던 이 간극이 에이전트와 도구 사용 연구의 출발점이다.

핵심 아이디어: 수첩을 든 신입 사원

AI 에이전트(AI Agent)는 목표를 받으면 스스로 단계를 나눠 외부 도구를 쓰며 일을 끝내는 LLM 시스템이다. 여기서 도구란 계산기, 검색 엔진, 위키백과 API, 코드 실행기, 웹 브라우저처럼 모델 바깥에서 정확한 결과를 돌려주는 프로그램을 말한다.

신입 사원을 떠올리면 쉽다. 일을 받으면 수첩에 '먼저 지난 분기 매출을 확인해야겠다'고 적고(생각), 사내 시스템을 조회하고(행동), 나온 숫자를 보고(관찰), '예상보다 낮네, 원인을 더 찾아보자'고 다시 적는다. 머리로만 답을 지어내지 않고, 모르는 것은 찾아보고, 찾아본 결과로 계획을 고친다.

ReAct는 이 수첩 쓰기를 LLM에 그대로 옮겼다. ReAct 논문은 이를 '행동하기 위해 생각하고(reason to act), 생각하기 위해 행동한다(act to reason)'고 표현했다. 생각은 계획을 세우고 예외를 처리하게 돕고, 행동은 바깥 정보를 끌어와 생각을 사실에 붙잡아 둔다.

어떻게 작동하나: 생각–행동–관찰의 반복

1단계, 질문을 받는다. 에이전트는 프롬프트(Prompt)에 담긴 지시와 몇 개의 예시를 보고 무엇을 해야 할지 파악한다. ReAct는 예시를 한두 개만 주는 방식으로도 작동했다.

2단계, '생각'을 글로 적는다. 지금 무엇을 알고 무엇이 모자라는지, 다음에 무엇을 할지 쓴다. 3단계, '행동'을 낸다. 정해진 형식으로 도구를 부르는 것이다. 예를 들어 '위키백과에서 X를 검색'처럼 쓴다. Toolformer는 이런 호출을 특수한 표시로 감싸 글 속에 끼워 넣고, 도구가 돌려준 결과도 그 자리에 이어 붙였다.

4단계, 시스템이 실제로 도구를 실행하고 결과를 '관찰'로 돌려준다. 에이전트는 이 관찰을 읽고 다시 2단계로 돌아가 생각을 이어 간다. 충분한 근거가 모였다고 판단하면 최종 답을 낸다.

여기에 덧붙는 장치가 있다. Reflexion은 한 번 시도가 실패하면, 그 피드백을 보고 '무엇이 잘못됐는지'를 글로 반성해 기억(에피소드 메모리)에 저장하고, 다음 시도 때 그 반성문을 함께 읽게 했다. 모델의 파라미터(Parameter)를 고치지 않고 글만으로 배우게 한 것이다.

발전 흐름: 출발점 연구들이 각각 새로 한 것

ReAct(2022)는 생각과 행동을 한 흐름 안에서 번갈아 내게 했다. 질의응답(HotpotQA)과 사실 검증(Fever)에서 단순한 위키백과 API만 써도 생각의 사슬 방식의 환각과 오류 전파 문제를 줄였고, 텍스트 게임(ALFWorld)과 쇼핑 웹사이트 탐색(WebShop)에서는 예시 한두 개만으로 모방 학습·강화학습 방식보다 성공률을 각각 절대치로 34%, 10% 높였다. 사람이 생각 기록을 읽고 판단 근거를 확인할 수 있다는 점도 장점으로 꼽았다. 다만 논문은 내부 지식을 쓰는 생각의 사슬과 ReAct를 섞은 방식이 전체적으로 가장 좋았다고 보고했다.

Toolformer(2023)는 '언제, 어떤 도구를, 어떤 입력으로 부를지'를 모델이 스스로 배우게 했다. 도구마다 사람이 쓴 예시 몇 개만 주고, 모델이 대량의 글에 도구 호출 후보를 끼워 넣게 한 뒤, 실제로 실행해 보고 다음 토큰 예측을 돕는 호출만 남겨 그 데이터로 파인튜닝(Fine-tuning)했다. 계산기·질의응답·검색·번역·달력을 다뤘고, 67억 파라미터의 GPT-J 기반 모델이 훨씬 큰 GPT-3보다 여러 과제에서 좋은 결과를 냈다.

Reflexion(2023)은 시행착오에서 배우는 방법을 바꿨다. 기존 강화학습처럼 많은 샘플과 비싼 파인튜닝을 쓰는 대신, 실패를 언어로 반성하게 했다. 코딩 평가 HumanEval에서 pass@1 91%를 기록해, 당시 GPT-4의 80%를 넘었다고 보고했다.

CodeAct(2024)는 행동의 형식을 바꿨다. 보통 에이전트는 JSON이나 정해진 텍스트 형식으로 도구를 부르는데, 이러면 미리 정한 도구 범위를 벗어나기 어렵고 여러 도구를 조합하기도 힘들다. CodeAct는 행동을 실행 가능한 파이썬 코드로 통일해, 코드 한 덩어리로 여러 도구를 엮고 실행 결과를 보며 고치게 했다. 17개 LLM을 분석해 기존 방식보다 성공률이 최대 20% 높았고, 7천 건의 다중 턴 상호작용 데이터(CodeActInstruct)도 공개했다. 이런 흐름을 정리한 LLM 기반 자율 에이전트 서베이(2023)는 에이전트 구성 방식을 하나의 통합 틀로 묶고, 응용과 평가 방법을 함께 정리했다.

실전 평가: 생각보다 훨씬 어렵다

도구를 쓰는 에이전트가 단순한 과제에서 잘한다고 실제 업무도 잘하는 것은 아니다. WebArena(2023)는 전자상거래, 커뮤니티 게시판, 협업 개발, 콘텐츠 관리라는 네 분야의 실제로 작동하는 웹사이트를 재현 가능한 환경으로 만들었다. 사람이 인터넷에서 흔히 하는 길고 복잡한 과제를 주었더니, 가장 좋은 GPT-4 기반 에이전트의 성공률은 14.41%로 사람(78.24%)에 크게 못 미쳤다.

SWE-bench(2023)는 12개 인기 파이썬 저장소의 실제 GitHub 이슈와 그 해결 커밋에서 2,294개 문제를 모았다. 모델은 코드베이스 전체를 보고 여러 함수·클래스·파일을 함께 고쳐야 하며, 실행 환경과 상호작용하고 아주 긴 맥락을 다뤄야 한다. 당시 가장 좋았던 Claude 2도 1.96%만 해결했다.

두 평가가 보여 준 것은 같다. 도구 호출 형식을 맞추는 것과, 긴 과정을 끝까지 정확히 해내는 것은 전혀 다른 문제다. 이후 연구 관심이 '얼마나 믿을 만하게 일하는가'로 옮겨 가는 배경이다.

요즘 어디로 가고 있나: 도구를 '잘 의심하는' 에이전트

첫째, 도구가 틀린 답을 줄 때다. 2026년 10월 발표된 'When Tools Lie' 연구는 수학 문제를 푸는 에이전트의 도구 결과를 몰래 그럴듯한 오답으로 바꿔치기했다. 31개 문제에서 검증 장치가 없으면 정확도가 100%에서 72.4%로 떨어졌고, 같은 맥락에서 반드시 되짚어 보게 하는 '강제 반성'을 넣으면 100%로 회복됐다. 검증 도구를 선택 사항으로만 주면 모델이 실제로 그것을 부를 때만 효과가 있었다. 검증 수단이 있는 것과, 검증을 하게 만드는 규칙은 별개라는 결론이다.

둘째, 근거 없이 행동할 때다. 'From Evidence to Action' 연구는 656개 사례로 이루어진 SafeActBench를 만들어, 에이전트가 무엇을 확인한 뒤 행동했는지 추적했다. 실패는 실행 단계보다 그 전에 자주 시작됐다. 조사를 덜 끝낸 채 멈추거나, 필요한 근거가 확보되기 전에 행동했다. 근거를 확보한 뒤의 단일 행동은 대체로 믿을 만했지만, 여러 행동이 이어지는 작업에서는 선행 조건을 놓치거나 중간에 끝내는 문제가 더 드러났다.

셋째, 멈출 때를 모를 때다. 'Judged Useless, Queried Anyway' 연구에서 일곱 에이전트는 고장 난 검색 소스의 결과를 97~100% '쓸모없다'고 정확히 판단했지만, 대부분 그 판단에 따라 멈추지 않았다. 프롬프트로 규칙을 알려 줘도 일부만 따랐다. 쓸모없는 결과가 다섯 번 연속 나오면 답하도록 실행 틀(harness)이 강제하자, 모든 모델의 성공률이 올랐다. 세 연구 모두 모델의 판단력만 믿기보다 바깥 구조로 검증과 멈춤을 강제하는 쪽이 효과적이라고 말한다.

한계와 쟁점

먼저 신뢰의 문제다. 에이전트는 도구 결과를 '정답'으로 받아들이기 쉽다. 도구가 조용히 틀리면 그 오류가 이후 추론 전체로 퍼진다. ReAct가 줄이려던 오류 전파가, 이번에는 도구 쪽에서 들어오는 셈이다.

다음은 평가의 문제다. 짧은 과제의 성공률은 높아도 WebArena·SWE-bench 같은 긴 실전 과제에서는 크게 떨어졌다. 또 최근 연구가 보여 주듯 정적인 상황에서 '이 행동이 옳은가'를 잘 판단하는 것과, 실제로 상호작용하며 옳게 실행하는 것은 다르다. 결과만 맞았다고 과정이 근거에 기반했다는 보장도 없다.

마지막으로 설계 선택의 문제가 남는다. 도구 호출을 정해진 형식으로 제한할지, CodeAct처럼 코드로 자유롭게 열어 줄지는 유연성과 통제 사이의 균형이다. 반성이나 검증을 모델 재량에 맡길지, 규칙으로 강제할지도 아직 정답이 없다. 강제하면 안정적이지만 불필요한 확인이 늘 수 있다.

더 공부하려면

처음이라면 ReAct(2210.03629)부터 읽기를 권한다. 생각–행동–관찰 고리라는 오늘날 에이전트의 기본 형태가 여기서 나왔고, 논문의 그림 1이 일반 프롬프트·생각의 사슬·행동만·ReAct 네 방식을 나란히 비교해 이해하기 쉽다.

그다음 Toolformer(2302.04761)로 '모델이 도구 사용을 스스로 배우는 법'을, Reflexion(2303.11366)으로 '실패에서 글로 배우는 법'을, CodeAct(2402.01030)로 '행동을 코드로 표현하는 법'을 읽으면 출발점의 세 갈래가 정리된다. 전체 지형은 LLM 기반 자율 에이전트 서베이(2308.11432)로 잡는다.

평가가 궁금하면 WebArena(2307.13854)와 SWE-bench(2310.06770)를 본다. 최근 동향은 'When Tools Lie'(2610.08097), 'From Evidence to Action'(2610.07753), 'Judged Useless, Queried Anyway'(2610.06191) 순으로 읽으면 '도구를 믿을 만하게 쓰는 법'이라는 요즘 질문이 잘 보인다.