AWS, 검색 에이전트를 다중 턴 강화학습으로 튜닝하는 방법 공개
AI를 활용하여 생성한 이미지입니다.
검색 에이전트는 질문을 한 번 받아 답을 내는 챗봇과 달라요. 검색어를 만들고, 결과를 읽고, 다음 검색을 결정하고, 필요한 자료를 모은 뒤 답을 구성해야 합니다. AWS는 2026년 10월 2일 Amazon SageMaker AI의 다중 턴 강화학습(MTRL)으로 이런 검색 에이전트를 튜닝한 방법과 결과를 공개했어요.[1]
핵심은 마지막 답변 한 줄만 잘 쓰게 만드는 게 아니라, 질문을 해결하는 전체 검색 과정이 좋은 방향으로 이어지게 학습한다는 데 있습니다. AWS가 공개한 내용은 서비스 홍보이면서 동시에 검색·RAG 시스템을 설계하는 개발자가 참고할 수 있는 실험 기록이기도 해요. 다만 AWS가 직접 수행한 사례이므로 모든 모델과 데이터에서 같은 개선이 나온다고 받아들이면 안 됩니다.
단일 응답 학습으로는 부족한 이유
전통적인 지도 학습은 사람이 만든 모범 대화나 정답 궤적을 필요로 해요. 검색 에이전트의 경우에는 질문마다 필요한 검색 순서가 달라지고, 여러 도구 호출이 서로 영향을 주기 때문에 좋은 예시를 충분히 모으기 어렵습니다. 단일 턴 강화학습도 한 번의 응답을 따로 평가하면 앞 단계에서 잘못 가져온 문서가 뒤 단계의 판단을 망친다는 의존성을 제대로 반영하기 힘들어요.[1]
MTRL은 여러 번의 상호작용을 하나의 궤적으로 묶어요. 에이전트가 검색 도구를 어떻게 사용했는지 전체 흐름을 본 뒤, 최종 검색 결과의 품질을 보상으로 주는 방식입니다. 중간 단계마다 정답 문장을 만들도록 강제하지 않아도 되지만, 최종 결과에 기여한 검색 행동은 학습에 반영할 수 있어요.
AWS 실험에서 사용한 구성
| 항목 | AWS가 공개한 내용 | 읽을 때 주의할 점 |
|---|---|---|
| 모델 | Qwen3.6-27B | 특정 지역과 지원 조건을 전제로 한 사례 |
| 보상 | nDCG@10 기반 검색 품질 | 검색 순위 평가 지표이지 답변의 모든 품질을 뜻하지 않음 |
| 데이터 | FRAMES, BRIGHT, Enterprise RAG, Wands | 공개·합성·도메인별 데이터가 섞인 구성 |
| 설정 | 1 epoch, global batch size 128, rollout 동시성 32 | AWS가 설명한 실험 설정이며 일반 권장값은 아님 |
| 관찰 | 검색 품질, 실패율, 턴 효율 개선을 보고 | 벤더가 공개한 자체 실험 결과 |
AWS는 다섯 퍼센트를 검증용으로 남기고, 검색 결과가 정답 문서와 얼마나 잘 맞는지를 nDCG@10으로 평가했다고 설명했어요.[1] 이 구성은 검색 단계의 품질을 측정하기에는 적절하지만, 실제 기업 환경의 권한 오류, 최신성, 개인정보, 비용까지 모두 대변하지는 않습니다.
서버리스 학습이라는 선택
AWS가 강조한 부분은 학습 알고리즘뿐 아니라 운영 방식이에요. 개발자가 GPU 클러스터를 직접 프로비저닝하지 않고 SageMaker AI의 서버리스 실행과 토큰 단위 비용 구조를 이용할 수 있다고 설명했습니다. 롤아웃 생성과 그래디언트 업데이트를 비동기로 처리하고, MLflow에서 에이전트의 단계별 궤적과 보상을 관찰할 수 있다는 점도 소개했어요.[1]
이런 구조는 실험을 빠르게 반복하는 데 유리해 보여요. 반대로 비용이 자동으로 낮아진다는 뜻은 아니에요. 검색 에이전트는 질문 하나에 여러 턴을 소비할 수 있고, 학습 데이터와 평가 작업까지 합치면 토큰 사용량이 커질 수 있습니다. 실제 도입 전에는 질문당 평균 턴 수, 실패 재시도율, 검색 API 비용, 인간 검수 비용을 따로 계산해야 해요.
RAG 개발자에게 주는 메시지
이번 사례에서 가장 실용적인 포인트는 검색 에이전트를 프롬프트만으로 완성하려 하지 않았다는 점이에요. 작은 모델을 특정 도구와 데이터 환경에 맞춰 학습시키면, 범용 대형 모델을 매 요청마다 부르는 비용과 지연을 줄일 여지가 있습니다. 대신 모델이 학습한 검색 습관이 데이터 변경을 따라가지 못하면 성능이 빠르게 낡을 수 있어요.
따라서 MTRL을 검토할 때는 다음 질문부터 정해야 합니다. 최종 답변의 문장 품질을 높이려는 건지, 필요한 문서를 놓치지 않는 검색기를 만들려는 건지, 아니면 도구 호출 횟수와 비용을 줄이려는 건지에 따라 보상 함수가 달라져요. nDCG@10 하나만 최적화하면 검색 순위는 좋아져도 최신성, 출처 다양성, 권한 범위, 답변의 정직한 불확실성 표시는 별도로 관리해야 합니다.
국내 팀이 시작할 때의 순서
- 실제 서비스에서 자주 실패하는 검색 질문을 모아 질문 유형과 오류를 분류해요.
- 검색 결과의 관련성, 최신성, 출처 신뢰도, 답변 완결성을 별도 지표로 정의해요.
- 먼저 프롬프트와 도구 호출 규칙으로 기준선을 만들고, 학습이 정말 필요한 구간을 좁혀요.
- 한 번의 최종 점수만 보지 말고 에이전트의 검색어와 선택 문서를 단계별로 저장해요.
- 운영 전에는 비용 상한, 개인정보 마스킹, 도구 권한, 실패 시 사람에게 넘기는 조건을 정해요.
AWS의 글은 MTRL이 검색 에이전트 학습의 한 경로가 될 수 있다는 사례를 보여줘요. 지금 단계에서 중요한 건 “강화학습을 쓰면 검색이 좋아진다”는 결론보다, 여러 번 이어지는 도구 사용을 하나의 평가 단위로 볼 필요가 있다는 점입니다. 우리 데이터와 실패 유형에 그 방법이 맞는지는 별도의 검증이 필요해요.
MTRL은 SFT와 어떻게 다를까?
지도 미세 조정(SFT)은 사람이 만든 좋은 입력과 출력 예시를 보고 모델이 그 답변을 따라가도록 학습하는 방식이에요. 검색 에이전트에서는 최종 답변뿐 아니라 어떤 검색어를 먼저 넣었는지, 결과가 부족할 때 어떻게 바꿨는지, 언제 검색을 멈췄는지도 중요합니다. 모든 중간 행동에 정답 예시를 붙이려면 데이터 제작 비용이 커져요.
AWS가 설명한 MTRL은 여러 도구 호출을 하나의 궤적으로 보고 마지막 결과에 보상을 주는 접근입니다.[1] 검색어 하나가 완벽했는지보다, 전체 과정이 관련 문서를 찾고 불필요한 반복을 줄였는지를 평가할 수 있어요. 단일 턴 RLVR이 각 답변을 독립적으로 채점하는 것과 비교하면, 앞 단계의 선택이 뒤 단계에 미치는 영향을 다루기 쉽다는 차이가 있습니다.
nDCG@10만 좋아지면 충분할까?
그렇지는 않아요. nDCG@10은 상위 검색 결과가 정답 문서에 얼마나 잘 맞는지 보는 지표입니다. 검색 시스템의 기준선으로는 유용하지만, 실제 사용자가 원하는 모든 조건을 포함하지는 않아요. 문서가 최신인지, 출처가 한 곳에 편중되지 않았는지, 접근 권한이 없는 문서를 끌어오지 않았는지, 답변이 모르는 부분을 인정하는지도 별도 점검이 필요합니다.
예를 들어 내부 문서 검색에서 관련성이 높은 문서를 찾았더라도 그 문서를 볼 권한이 없는 사용자에게 요약해 주면 보안 사고가 됩니다. 고객지원 검색에서는 오래된 정책 문서가 상위에 나오면 검색 점수와 실제 안내 품질이 어긋날 수 있어요. 그래서 MTRL을 도입할 때는 nDCG@10을 유일한 보상으로 두기보다 최신성, 권한, 비용, 답변의 근거 표시를 평가 파이프라인에 따로 넣어야 합니다.
AWS 사례를 그대로 복사하기 어려운 지점
AWS의 실험은 Qwen3.6-27B와 특정 데이터셋, 미국 서부 오리건 리전에서 지원되는 구성에 기반합니다.[1] 모델 이름과 학습 설정만 가져온다고 해서 한국어 고객센터나 사내 위키에서 같은 결과가 나오는 것은 아니에요. 데이터의 문체와 질문 난이도, 검색 인덱스의 품질, 도구가 반환하는 메타데이터가 모두 다릅니다.
특히 Enterprise RAG 데이터처럼 합성 문서가 포함된 평가와 실제 회사 문서는 차이가 있어요. 현실의 문서는 같은 정책이 여러 버전으로 흩어져 있고, 문서 제목은 비슷하지만 권한과 적용 지역이 다른 경우가 많습니다. 자체 검증을 할 때는 실제 장애 티켓과 실패했던 검색 질문을 익명화해 평가셋에 포함하는 것이 좋아요.
운영 비용과 관찰 가능성
여러 턴을 허용하면 검색 품질이 좋아질 가능성이 있지만, 질문 하나에 사용하는 토큰과 검색 API 호출도 늘어날 수 있어요. 따라서 평균 턴 수만 보지 말고 상위 5퍼센트의 긴 궤적, 반복 검색 비율, 실패 후 재시도 횟수를 함께 기록해야 합니다. 사용자가 기다리는 시간이 길어지면 좋은 검색 결과도 서비스 품질로 이어지지 않아요.
AWS는 MLflow를 통해 단계별 궤적과 보상을 관찰할 수 있다고 설명합니다.[1] 이 기록은 모델을 개선하는 데 도움이 되지만 개인정보가 포함될 수 있으므로 원문 질문과 검색 결과를 무기한 저장하면 안 됩니다. 보존 기간, 마스킹, 접근 권한, 삭제 절차를 먼저 정한 뒤 학습 로그를 남겨야 해요.
