개요

33편은 에이전트를 여럿 붙이는 이야기였다. 이번 편은 그 하나하나를 어떻게 훈련시키느냐로 돌아온다.

31편 끝에서 이렇게 적어뒀었다. “지도 학습을 넘어 에이전트 행동에 강화학습을 적용하는 쪽”이 있다고. 그 다음 이야기가 이번 자료에 있었다.

도구 쓰는 법을 사람이 안 가르치면, 모델은 무엇을 보고 배우는가? 그리고 그렇게 배운 모델은 왜 말이 길어지는가?

두 질문이 이어져 있다. 잘 배운 모델일수록 더 오래 생각하고, 오래 생각할수록 더 비싸진다. 그 균형을 잡는 게 이번 편의 후반부다.

마지막에는 지금까지 본 걸 전부 붙인 물건 하나를 본다. Deep Research다.

교육 자료는 대외비라 슬라이드 이미지나 예제 데이터는 싣지 않는다. 개념만 다시 그려서 쓴다.

1. 딜레마 셋 — 도구를 쓴다는 건 결정을 세 번 하는 것

33편 6절 끝에서 던진 질문을 그대로 받는다. 멀티 에이전트형 RAG에서 리트리버 에이전트들이 제일 중요하다는 데까지 갔는데, 그럼 걔들이 적절한 때에 적절한 도구를 부르게 하려면 뭘 해야 하나.

31편에서 도구를 “언어모델의 손”이라고 했다. 그런데 손이 있다고 잘 쓰는 건 아니다. 자료가 도구 사용을 세 개의 결정으로 쪼개는데, 이 분해가 깔끔했다.

결정 질문 어긋나면
언제 아는 걸로 답할까, 도구를 부를까 계산기 쓸 일에 지어내거나, 상식 질문에 웹 검색을 돌린다
무엇을 계산기·웹 검색·DB 중 뭘 부를까 엉뚱한 도구를 부른다
어떻게 그 도구 API에 인수를 어떻게 넘길까 형식이 틀려서 에러가 난다

여기에 하나가 더 붙는다. 해석 — 돌아온 결과나 오류를 보고 다음 행동을 정하는 것이다.

첫 번째가 제일 어렵다. 그냥 항상 도구를 부르면 되지 않나 싶은데, 자료는 이걸 명확한 트레이드오프로 적어뒀다. 도구를 부르면 정확해지는 대신 비용과 지연 시간이 늘어난다.

“2 더하기 3”에 계산기를 부르는 건 틀리진 않았지만 바보 같은 짓이다.

그리고 이 결정들이 모여서 에이전트의 행동 정책(policy)을 이룬다. 정책이라는 말이 나오면 그다음은 정해져 있다. 강화학습이다.

2. 스스로 배우는 세 가지 방법 — 무엇으로 채점했는가

31편에서 WebGPT(사람 시연 모방), Toolformer(모델이 스스로 데이터 생성), ToolLLM(대규모 API 수집)까지 봤다. 이번 자료는 그 뒤를 잇는 세 편을 소개한다.

셋을 관통하는 질문 하나로 읽으면 편하다. 사람이 정답 절차를 안 적어준다면, 뭘 보고 잘했다고 판정할 것인가?

도구 사용 학습 세 가지 접근

① Gorilla — 문서를 먼저 찾아 읽게 한다

목표는 LLM이 대규모 실제 API 세트를 안정적으로 호출하는 것이다.

접근이 재밌다. API 호출을 생성하기 전에 관련 API 문서를 불러오는 검색 단계를 붙이고, 그 상태로 미세조정을 한다. 검색 증강 미세조정(RAFT)이라 부른다.

효과가 명확하다. 없는 함수를 지어내는 “환각 API 호출”이 줄어든다. 수십만 개의 API를 정확한 서식으로 처리한다.

답을 외우게 하는 대신 설명서를 펴놓고 풀게 했다. 그랬더니 지어내는 게 줄었다.

② ReTool — 실제로 돌려보고 채점한다

목표는 외부 도구(코드 인터프리터)를 쓰는 시점, 도구 선택, 방법을 학습시키는 것이다. 특히 계산이 많이 필요한 작업에서 추론 능력을 올린다.

2단계로 훈련한다.

  1. 콜드 스타트 SFT — 선별된 코드로 증강된 추론 흔적을 먼저 지도 학습으로 먹인다
  2. 강화학습 + 실시간 코드 실행 — PPO로 학습하는데, 그 과정에서 코드를 실제로 실행해서 피드백을 받는다

핵심은 결과 기반 보상이다. 코드가 실제로 돌아서 맞는 답을 냈는지가 채점 기준이다. 이걸로 호출 타이밍, 도구 선택, 코드 개선, 자기 수정까지 배운다.

③ Search-R1 — 검색을 몇 번 할지 스스로 정하게 한다

목표는 에이전트가 자율적으로 다단계 웹 검색을 수행하는 것이다.

에이전트가 배우는 정책이 셋이다. 도구 사용 여부(검색할까 말까), 질의 구성(뭐라고 검색할까), 반복 개선(부족하면 다시 할까).

여기서 쓰는 강화학습 기법이 GRPO(Group Relative Policy Optimization)다. PPO에서 발전한 방법인데, 발상이 단순하다. 같은 질문을 여러 번 굴려보고 서로 비교한다.

한 그룹의 결과 $r_1, \dots, r_G$ 를 얻었다면, 각 결과의 좋고 나쁨을 이렇게 잡는다.

$$ A_i = \frac{r_i - \mathrm{mean}(r)}{\mathrm{std}(r)} $$

절대 점수가 아니라 그룹 안에서의 상대 위치로 채점하는 것이다. “몇 점짜리 답인가”를 매길 필요가 없고, “이번 열 번 중에 몇 번째로 잘했나”만 있으면 된다.

채점 기준을 만드는 대신 줄을 세운다. 별도의 가치 모델을 안 둬도 되니 훈련이 가벼워진다.

셋을 나란히 놓으면

  Gorilla ReTool Search-R1
다루는 도구 대규모 API 코드 인터프리터 웹 검색 엔진
채점 기준 문서와 맞는 호출인가 실행 결과가 맞는가 최종 답이 맞는가
주로 배우는 것 정확한 서식 호출 타이밍과 자기 수정 검색 여부·질의·반복
기법 검색 증강 미세조정(RAFT) SFT + PPO GRPO

31편에서 Toolformer를 보며 “손실이 줄었는지로 자동 채점한다”는 게 핵심이라고 적었었다. 이번 셋도 똑같다. 채점을 자동화할 수 있는 무언가를 찾아내는 게 전부다. 문서, 실행기, 최종 정답 — 셋 다 사람 손을 안 탄다.

3. 생각을 늘리면 똑똑해진다 — Test-Time Scaling

여기서 이야기가 한 번 꺾인다. 지금까지는 훈련할 때 무엇을 하느냐였는데, 이제 답할 때 무엇을 하느냐로 넘어간다.

자료의 주장이 이렇다.

추론 시에 컴퓨팅 자원을 더 많이 투입할수록 성능이 향상된다.

이걸 Test-Time Scaling(TTS)이라고 부른다. 그리고 여기에 붙은 문장이 진짜 중요하다. 난이도가 낮은 작업에서는 모델 매개변수를 늘리는 것보다 더 효과적일 수 있다.

33편에서 봤던 스케일링 법칙 둔화의 또 다른 출구다. 모델을 못 키우면 답하는 시간을 키운다.

  학습 시간 스케일링 추론 시간 스케일링
늘리는 것 파라미터, 데이터, 학습 연산량 생각하는 단계 수
비용을 내는 시점 한 번, 미리 질문할 때마다
바꾸려면 모델을 다시 만든다 그때그때 조절한다

방법은 32편과 이번 자료에서 이미 다 나왔다. CoT로 단계를 밟게 하고, Self-Consistency로 여러 번 굴려 다수결하고, Tree of Thoughts로 갈래를 쳐서 평가한다. 전부 “더 많이 생각하기”의 변주다.

추론 전용 모델의 등장

그러다 아예 추론을 위한 컴퓨팅 자원이 할당된 모델이 나왔다. o1(2024.12)과 DeepSeek-R1(2025.01)이다.

이 모델들을 어떻게 훈련시켰냐가 흥미로웠다. 정확성과 올바른 형식에 대해서만 보상을 준다.

형식이라는 게 이런 것이다.

<think> 여기에 생각하는 과정 </think>
<answer> 여기에 최종 답 </answer>

보상 함수가 하는 일은 딱 둘이다. <think> 블록이 제대로 닫혔는지(형식), 최종 답이 정답과 같은지(정확성). 생각의 내용은 채점하지 않는다.

그런데 이렇게 훈련시켰더니 학습이 진행될수록 응답 길이가 저절로 늘어났다. 아무도 “더 길게 생각해라”라고 안 시켰는데 그렇게 됐다.

잘 답하라고만 했더니 스스로 오래 생각하기 시작했다. 여기가 이번 자료에서 제일 신기했던 대목이다!

4. 그런데 너무 많이 생각한다 — 과도한 사고와 세 처방

좋기만 하면 이 절이 없다. 자료가 바로 다음 장에서 문제를 짚는다.

더 긴 CoT 추론 과정은 실제로 성능을 향상시키지만, 장황하고 중복되는 출력으로 계산 부담이 크게 늘어나는 것은 여전히 문제다.

이걸 과도한 사고(Overthinking)라고 부른다. 쉬운 질문에도 열 문단을 쓴다. 답은 똑같은데 토큰과 시간만 몇 배로 나간다.

과도한 사고에 대한 세 가지 처방

자료는 처방을 세 갈래로 분류한다. 어디를 건드리느냐가 기준이다.

① 모델 기반 접근 — 모델 자체를 고친다

DeGRPO가 사례다. 첫 번째로 생성되는 토큰을 제어 토큰으로 쓴다. <short>가 나오면 짧게, <think>가 나오면 길게 간다.

발상이 좋다고 생각했다. 길이를 밖에서 강제하는 대신 모델이 첫 글자에서 스스로 결정하게 하고, 그 결정까지 학습 대상으로 삼는다.

② 추론 결과 기반 접근 — 중간에 접는다

InftyThink가 사례다. 일부 추론 과정을 만들고, 지금까지의 생각을 요약한 다음, 그 요약을 들고 다음 생각으로 넘어간다. 생각 → 요약 → 생각 → 요약을 반복한다.

효과는 컨텍스트가 무한히 늘지 않는 것이다. 다 쌓아두는 대신 접어서 넘긴다. 32편에서 Reflexion이 실패 궤적을 문장으로 압축했던 것과 성격이 비슷하다.

③ 입력 프롬프트 기반 접근 — 입구에서 나눈다

가장 단순하다. 쉬운 질문에는 연산량을 적게, 복잡한 질문에는 많이 배정한다. 난이도 라우팅이다.

이건 이미 우리가 쓰고 있다. 요즘 상용 모델들의 자동 모드가 사실상 이 방식이다. 질문을 보고 빠른 모드로 갈지 깊은 모드로 갈지 라우터가 정한다.

접근 어디를 건드리나 사례
모델 기반 모델의 출력 방식 DeGRPO — 제어 토큰으로 길이 조절
추론 결과 기반 생각의 누적 방식 InftyThink — 요약해서 넘긴다
입력 프롬프트 기반 들어오는 질문의 분배 난이도 라우팅

세 처방의 결론이 같다. 모든 곳에서 깊이 생각하지 말고, 깊이 생각할 곳을 골라라.

5. 다 합치면 Deep Research

마지막 장은 지금까지 본 걸 전부 붙인 사례다. 자료는 이걸 패러다임 전환의 마지막 칸으로 그린다.

시기 무엇 한계
그전 웹 검색 — 키워드로 크롤·색인·순위 깊은 이해와 종합을 못 한다
2022.11 LLM 챗봇 — 모델 자체가 지식 소스 지식이 낡고 부정확할 수 있다
2023.03 RAG — 외부 지식으로 근거를 댄다 깊고 반복적인 추론·전략적 계획이 없다
2025 에이전트 기반 심층 연구 비싸다

30편에서 RAG를 보며 “기억하지 못하는 검색 엔진”이라는 표현을 봤었다. 한 번 가져오고 끝이라 가져온 게 좋은지 나쁜지 확인하는 과정이 없다. Deep Research는 그 자리를 정면으로 친다.

Deep Research의 네 단계 사이클

네 단계를 돈다

  • 생각(Think) — 세부 목표를 세우고 무엇을 검색할지 정한다
  • 검색(Search) — 검색 API로 상위 k개 결과(제목, 주소, 요약문)를 가져온다
  • 탐색(Explore) — 웹페이지를 실제로 읽고 유용한 정보만 단기 저장소에 모은다. 별로다 싶으면 빠르게 다른 URL로 넘어간다
  • 답변(Answer) — 충분히 모였다고 판단되면 최종 결론을 낸다

기존 RAG와 갈리는 지점이 딱 하나다. RAG는 “검색한 다음 추론”이라는 고정 순서를 따르는데, 여기서는 추론이 언제·무엇을 검색할지 동적으로 결정한다. 그래서 오류가 앞으로 전파되는 게 줄어든다.

시키지 않았는데 나온 행동

자료에서 제일 인상적이었던 부분이다. 강화학습만 시켰는데 가르치지 않은 행동이 나왔다.

  • 계획 능력 — 검색을 시작하기 전에 단계를 먼저 적는다
  • 교차 검증 — 첫 번째 결과에만 의존하지 않고 추가 확인을 한다
  • 성찰적 재검색 — 결과가 불만족스러우면 검색 방향 자체를 튼다
  • 솔직한 회피 — 확실하지 않으면 추측하지 않고 모른다고 답한다

마지막 게 제일 놀라웠다. 환각을 줄이려고 그렇게 애를 쓰는데, “모른다”고 말하는 습관이 보상 설계만으로 나왔다는 것이다.

정답에만 보상을 줬더니 틀린 답을 내느니 모른다고 하는 게 낫다는 걸 스스로 알아냈다!

그리고 계산서

기분 좋게 끝나지 않는다. 자료가 한계를 정직하게 적어뒀다.

비용부터 보자. 표준 질의응답이 쓰는 토큰량을 $C_0$ 라 하면,

$$ C_{\mathrm{single}} \approx 4 C_0, \qquad C_{\mathrm{multi}} \approx 15 C_0 $$

이다. 고부가가치 작업에서만 비용 대비 효율적이라고 못을 박아뒀다.

나머지 한계도 만만치 않다.

한계 내용
범용성 병렬로 쪼갤 수 있는 작업에서만 효과적. 코딩·디버깅처럼 순차적인 단일 컨텍스트 작업에는 안 맞는다
관리 복잡성 에이전트가 너무 많이 생기거나, 무한 루프에 빠지거나, 서로 간섭한다. 명확한 정지 조건이 필요하다
오류 전파 작은 오류가 프로세스 전체의 방향을 왜곡시킨다. 체크포인트와 복구 메커니즘이 필요하다
평가 곤란 실행 경로와 답변이 매번 다르다. 같은 입력에도 매번 다른 흐름이 나오니 공정한 평가가 어렵다

마지막 게 개발자 입장에서 제일 골치 아프다. 재현이 안 되는 시스템은 디버깅이 안 된다. 예전에 멀티플레이 서버에서 타이밍 따라 다르게 터지는 버그 잡느라 고생했던 게 떠올랐는데, 그건 그래도 로그를 붙이면 잡혔다. 여기는 매 실행마다 모델이 다른 길을 고른다. 자료가 대안으로 든 게 LLM 평가 점수(0~1 스케일)와 사람 평가를 같이 쓰는 것인데, 깔끔한 해법은 아직 없어 보인다..

정리

  • 도구 사용은 결정 셋 — 언제(비용/지연 vs 정확성 트레이드오프) / 무엇을(도구 선택) / 어떻게(인수 전달). 여기에 해석(결과·오류를 보고 다음 행동 결정)이 붙는다
    • 이 결정들이 모여 행동 정책(policy)이 되고, 정책은 강화학습으로 학습된다
  • 도구 학습 세 편 — 공통점은 자동으로 채점되는 기준을 찾아낸 것
    • Gorilla — API 문서를 먼저 검색해 읽고 호출(RAFT). 환각 API 호출이 준다
    • ReTool — 콜드 스타트 SFT + PPO, 코드를 실제 실행해 결과로 채점. 호출 타이밍과 자기 수정을 배운다
    • Search-R1 — GRPO로 검색 여부·질의 구성·반복 개선을 학습. 절대 점수 대신 그룹 안 상대 위치로 채점
  • Test-Time Scaling — 추론 시 연산을 늘리면 성능이 오른다. 난이도가 낮은 작업에선 모델을 키우는 것보다 효과적일 수 있다
    • 추론 모델(o1, DeepSeek-R1)은 정확성과 형식에만 보상을 줬는데 응답 길이가 저절로 늘었다
  • 과도한 사고와 세 처방 — 어디를 건드리느냐로 갈린다
    • 모델 기반: DeGRPO(제어 토큰으로 길이 결정) / 결과 기반: InftyThink(요약해서 넘김) / 프롬프트 기반: 난이도 라우팅
  • Deep Research — 웹 검색 → LLM 챗봇 → RAG → 에이전트 기반 심층 연구
    • 생각 → 검색 → 탐색 → 답변을 반복. RAG의 “검색 후 추론” 고정 순서를 깨고 추론이 검색을 지휘한다
    • 창발적 행동 — 계획, 교차 검증, 성찰적 재검색, 솔직한 회피
    • 한계 — 토큰 4배·15배, 병렬화 가능한 작업 한정, 무한 루프, 오류 전파, 매번 경로가 달라 평가 불가
  • 겹치는 글 — 검색과 RAG는 30편, 도구와 Toolformer는 31편, ReAct·Reflexion은 32편, 다중 에이전트는 33편

참고 자료

한줄 평

  • 정답에만 보상을 줬더니 계획하고 교차검증하고 심지어 “모르겠다”고 말하는 습관까지 스스로 생겼다는 게 이번 자료에서 제일 소름 돋았는데, 동시에 그게 15배 비싸다는 계산서를 같이 봐서 정신이 번쩍 들었다!