Multi-Turn Reinforcement Learning on Amazon SageMaker AI: A hands-on guide

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker AI의 Multi-Turn Reinforcement Learning(MTRL)은 에이전트의 다단계 작업 결과를 보상으로 학습하며, Wordle 예제에서 GPT-OSS-20B의 미사용 단어 풀이 성공률을 기본 추론 노력 기준 61%에서 84%로 높였다.

📌 핵심 요약

• SageMaker AI는 정책 모델과 학습 작업을 관리하고, Amazon Bedrock AgentCore 등에 배포한 에이전트가 여러 차례 행동한 뒤 에피소드 종료 시 보상 하나를 반환한다. Wordle 예제에서는 GRPO로 동일 단어에 대한 여러 실행의 보상을 비교해 LoRA 어댑터를 갱신하며, 정답 해결 여부가 보상을 지배하도록 설계했다.
• GPT-OSS-20B는 학습에 사용하지 않은 단어에서 기본 추론 노력의 성공률이 61%에서 84%로, 학습 당시 사용한 낮은 추론 노력에서는 15%에서 69%로 개선됐다. 평가 작업에서 낮은 추론 노력은 중간 추론 노력보다 게임당 생성 토큰을 63~83% 적게 사용했다.
• 100단계 학습은 12시간 40분 동안 105,486회 실행됐으며, 입력 처리·생성·학습 토큰 요금은 당시 us-east-1 정가 기준 총 $338.50이었다. 별도 청구되는 AgentCore 실행 비용은 약 $79였고, 전체 토큰 요금에서는 학습 차원이 가장 큰 비중을 차지했다.
• 작성 시점의 지원 모델은 Amazon Nova 2 Lite, GPT-OSS-20B, Gemma 4 31B 지시 조정 모델, Qwen 3.6 27B이며 모델별 지원 리전이 다르다. 학습 작업·에이전트·Amazon S3 버킷은 같은 리전에 있어야 하며, 데이터셋·에이전트·학습된 모델은 사용자 AWS 계정에 남고 기반 모델 학습에 사용되지 않는다.
• 구현에는 두 IAM 역할과 올바른 HTTP 진입점 구성이 필요하다. 학습 역할은 job.sagemaker.amazonaws.com을 신뢰해야 하며, 런타임 검증에서는 가짜 작업 ARN에 대한 400 'Could not find job', 다른 계정 ARN에 대한 403, HTTP 서버 미시작에 따른 30초 시간 초과를 구분한다. 제공된 본문은 데이터셋 준비 단계 도입부에서 끊겨 이후 학습·모니터링·평가 절차는 확인할 수 없다.

🧩 주요 포인트

1. 최종 결과 보상과 GRPO → 정답 행동 경로를 미리 지정하지 않고, 여러 단계에 걸친 에이전트 전략을 LoRA로 개선하는 접근이다.
2. 낮은 추론 노력의 성공률 개선과 생성 토큰 감소 → 작업 성능과 토큰 비용을 함께 평가할 필요가 있으며, 별도 AgentCore 비용도 총비용 판단에 포함된다.
3. 동일 리전·IAM 신뢰 주체·HTTP 진입점 제약 → 학습 실행 전 통합 검증이 중요하며, 오류 유형을 구분해야 구성 문제를 정확히 진단할 수 있다.

🧠 상세 정리

1. 단일 응답 학습으로 다루기 어려운 에이전트 작업

일반적인 미세 조정은 하나의 프롬프트에 더 나은 답을 생성하도록 가르치지만, 경비 보고서 작성이나 지원 티켓 분류 같은 에이전트 작업은 이전 단계에 의존하는 일련의 행동으로 이루어진다. 원문은 이런 작업에 모방할 유일한 정답 경로가 드물고 전체 과정의 성공 여부가 가장 신뢰할 만한 피드백이므로, 지도 미세 조정과 단일 턴 강화학습만으로는 충분히 다루기 어렵다고 설명한다. MTRL은 올바른 경로를 지정하는 대신 최종 결과의 채점 방법을 정의하고, 작업에 필요한 여러 턴을 거친 뒤 반환된 보상을 학습 신호로 사용한다. 예제로 선택한 Wordle은 다섯 글자 단어를 여섯 번 안에 맞히는 게임으로, 각 추측의 글자가 위치까지 맞으면 초록색, 단어에는 있지만 위치가 다르면 노란색, 단어에 없으면 회색으로 표시된다. 규칙이 적고 이전 피드백이 다음 행동에 영향을 주며 결과를 객관적으로 채점할 수 있어 교육용 예제로 적합하지만, 원문은 최첨단 모델이 이미 잘하는 게임이라는 한계도 밝힌다. 실제 활용 대상으로는 공개 모델이 학습하지 않은 기업 내부의 다단계 작업에 작고 저렴한 모델을 특화하는 경우를 제시한다.

2. SageMaker AI와 AgentCore의 역할 및 보상 설계

시스템은 학습 작업과 정책 모델을 소유하는 SageMaker AI, 에이전트·Wordle 환경·보상 함수를 호스팅하는 AgentCore의 두 부분으로 구성된다. 일반적으로는 AWS Lambda 전달자를 통해 AgentCore나 Amazon EKS, Amazon EC2, AWS Fargate 같은 자체 인프라의 에이전트에 프롬프트를 보내며, 이 예제는 AgentCore를 사용한다. 각 실행에서 비밀 단어를 담은 학습 행 하나가 런타임에 전달되면 Strands 에이전트가 SageMaker Job Runtime의 OpenAI 호환 엔드포인트로 정책 모델을 호출하고, guess_word 도구로 최대 여섯 번 추측한다. 환경은 매번 글자별 피드백과 현재까지 알려진 정보를 반환하고, 게임 종료 후 반환된 보상을 바탕으로 GRPO가 동일 단어에 대한 여러 실행의 보상 차이를 이용해 LoRA 어댑터를 갱신한다. 환경·도구·채점 함수는 하나의 Python 파일에 모이며, 데이터셋은 비밀 단어만 담고 에이전트에 포함된 SCOWL 기반 단어 목록은 채점에만 쓰인다. 보상은 해결 속도에 따라 성공 시 1.05~1.55, 실패 시 -0.5, 유효한 추측을 한 번도 하지 못하면 -1.5를 부여하고, 각 결과 등급 안에서 좋은 전략을 장려하는 작은 보상 항을 더하는 구조다.

3. 지원 모델과 Wordle 실험의 성능 변화

MTRL은 사용자가 기반 모델을 선택하면 서비스가 학습과 샘플링 인프라를 마련하는 서버리스 방식이며, 작성 시점의 지원 모델은 모두 LoRA 어댑터로 학습된다. Amazon Nova 2 Lite와 GPT-OSS-20B는 미국 동부 버지니아 북부 us-east-1과 미국 서부 오리건 us-west-2에서, Gemma 4 31B 지시 조정 모델과 Qwen 3.6 27B는 us-west-2에서 지원된다. 저자들은 네 모델 중 토큰당 가격이 가장 낮고 요청마다 추론 노력을 제어할 수 있다는 이유로 GPT-OSS-20B를 선택했으며, 최신 지원 목록은 MTRL 문서에서 확인하도록 안내한다. 실험에서는 학습에 사용하지 않은 단어에 대한 성공률이 기본 추론 노력에서 61%에서 84%로, 학습에 사용한 낮은 추론 노력에서는 15%에서 69%로 상승했다. 이 결과는 서로 다른 추론 설정에서의 개선을 보여주지만, Wordle에서 얻은 성과이므로 원문에 없는 다른 업무의 개선 폭까지 제시하지는 않는다. 데이터셋과 에이전트, 학습된 모델은 사용자 AWS 계정 안에 유지되며 기반 모델 학습에는 사용되지 않는다고 명시한다.

4. 토큰 과금 구조와 별도 런타임 비용

사용자는 인스턴스나 클러스터 크기를 선택하지 않고, 기반 모델별로 정해진 입력 처리 Prefill, 생성 Sample, 역전파 학습 Train의 세 차원에서 백만 토큰당 비용을 지불한다. 다중 턴 작업은 매 턴 대화 이력을 다시 읽으므로 입력 처리 토큰이 누적되며, 생성 토큰에는 추론 토큰도 포함되고 학습 토큰은 LoRA 어댑터를 갱신하는 역전파에서 처리된다. 100단계 실험은 12시간 40분 동안 105,486회 실행됐고, 입력 처리 491,616,806개, 생성 159,737,098개, 학습 643,308,554개로 총 1,294,662,458개의 토큰을 사용했다. 당시 us-east-1의 GPT-OSS-20B 정가인 백만 토큰당 $0.12, $0.30, $0.36을 각각 적용하면 비용은 $58.99, $47.92, $231.59이며 합계는 $338.50이다. 가장 큰 비용인 학습 차원은 행동 경로 길이에 따라 증가하므로, 원문은 더 짧은 게임과 덜 장황한 추론이 비용을 줄인다고 설명한다. AgentCore의 vCPU와 메모리 사용료는 별도이며 이 실험에서는 CloudWatch 사용량과 당시 정가를 기준으로 약 $79였고, 토큰 사용량은 DescribeJob의 BillableTokenUsage에서 확인할 수 있다.

5. 실행 전제조건과 두 IAM 역할의 차이

실습에는 Python 3.10 이상, uv, Node 20 이상, AgentCore CLI와 함께 작업을 시작하는 머신의 botocore 1.43.37 이상이 필요하며, 이 botocore 버전부터 AgentRFT CreateJob 연산이 포함된다. Amazon S3 버킷은 에이전트와 같은 리전에 있어야 하고 학습 작업도 해당 리전에서 실행해야 하는데, CreateJob이 다른 리전의 런타임 ARN을 거부하기 때문이다. IAM 역할은 에이전트 런타임 역할과 학습 작업 역할로 나뉘며, agentcore deploy가 생성하는 런타임 역할은 bedrock-agentcore.amazonaws.com을 신뢰하고 정책 모델 호출과 보상 보고를 위한 AmazonSageMakerJobRuntimeAccess 정책이 필요하다. 샘플 저장소의 CDK 스택은 이 관리형 정책을 자동으로 연결한다. 사용자가 생성하는 학습 작업 역할은 job.sagemaker.amazonaws.com을 신뢰하고 sts:AssumeRole과 sts:TagSession을 모두 허용해야 하며, AmazonSageMakerJobFullAccess 관리형 정책이 필요하다. 일반적인 sagemaker.amazonaws.com을 신뢰 주체로 사용하면 CreateJob이 'Could not assume role' 오류로 실패하고, 올바른 주체는 재시도 후 오류 메시지에 나타난다는 점이 주요 주의사항이다.

6. AgentCore 배포와 낮은 추론 노력 설정

배포는 aws-samples의 sample-multi-turn-rl-wordle 저장소를 복제하고 Wordle/agentcore/aws-targets.json에 계정과 리전을 설정한 뒤, Wordle 디렉터리에서 agentcore validate와 agentcore deploy를 실행하는 흐름이다. CLI는 런타임의 Linux ARM64 플랫폼에 맞게 의존성을 빌드하고, AmazonSageMakerJobRuntimeAccess가 연결된 실행 역할을 생성하며, AWS CloudFormation을 통해 에이전트를 배포한다. 원문은 콘솔에서 코드 패키지를 직접 올릴 때 약 700MB의 컴파일된 의존성이나 정책 연결을 잘못 처리하기 쉽다는 이유로 CLI 사용을 권장하며, 출력된 런타임 ARN은 학습 작업에 사용하도록 안내한다. 런타임은 agentcore.json의 REASONING_EFFORT=low를 읽어 정책 모델의 모든 요청에 reasoning_effort를 설정한다. REASONING_PROMPT_HINT=true는 gpt-oss의 Harmony 채팅 형식에서 설정을 읽을 수 있도록 시스템 프롬프트에 'Reasoning: low'도 추가하며, 두 변수 모두 비밀 단어에 관한 힌트를 제공하지 않는다. 평가 작업에서 낮은 추론 노력은 중간 추론 노력보다 게임당 생성 토큰을 63~83% 줄였지만, 이 수치는 전체 청구액 감소율로 제시된 것은 아니다.

7. 에이전트 진입점과 HTTP 서버 구성의 함정

에이전트 구현은 main.py 하나에 들어 있으며, 진입점은 전달받은 프롬프트에서 작업과 정답을 파싱하고 해당 정답으로 WordleGame 환경을 생성한다. 내부의 guess_word 도구는 다섯 글자 추측을 게임 환경에 전달해 피드백을 돌려주고, 에이전트는 정책 모델·시스템 프롬프트·이 도구를 사용해 작업을 수행한 다음 최종 보상을 반환한다. 다른 업무로 바꿀 때 수정할 부분은 작업 파싱, 도구, 보상이라는 것이 원문의 설명이다. 여기서 sagemaker_rft_handler 데코레이터는 반환된 보상을 SageMaker AI에 보고하지만, 그 자체로 HTTP 서버를 시작하지는 않는다. 따라서 BedrockAgentCoreApp을 사용하고 @app.entrypoint를 가장 바깥쪽 데코레이터로 배치해 AgentCore가 호출할 서버를 시작해야 한다. 이 구성이 없으면 모든 호출이 30초 후 시간 초과되므로, 보상 반환 로직뿐 아니라 서비스가 호출할 진입점까지 함께 구성해야 한다.

8. 가짜 작업 ARN을 이용한 검증과 제공 본문의 범위

학습 자원을 사용하기 전에 샘플의 payload.json으로 실제 학습 서비스와 같은 형태의 요청을 보내며, 이 요청에는 문자열로 직렬화한 작업 프롬프트와 정답, 식별자 및 jobArn·rolloutId 메타데이터가 들어 있다. 가짜 작업 ARN은 의도적으로 실패하게 만들되 자신의 계정 ID를 넣어야 하는데, 다른 계정의 ARN은 작업 존재 여부를 확인하기 전에 403을 반환해 IAM 문제처럼 보일 수 있기 때문이다. 정상적인 검증 경로에서는 CloudWatch 로그에 프롬프트 파싱과 Job Runtime 인증이 나타난 뒤 400 'Could not find job' 오류가 발생하며, 이는 파싱·인증·오류 보고가 작동한다는 근거가 된다. 정책 모델까지 도달하지 못했으므로 명령의 반환 보상은 -1.5이고, 403 'not authorized to access this resource'는 다른 계정 ARN을, 30초 시간 초과는 HTTP 서버 미시작을 우선 확인할 신호로 설명된다. 이어지는 데이터셋 준비 단계는 목표 응답·대화 기록·라벨이 없고 각 행이 하나의 작업이라는 설명을 시작하지만, 제공된 본문은 해당 문장 중간에서 끝난다. 도입부는 학습·MLflow 모니터링·서빙 설정 평가와 실패 사례까지 다룬다고 예고하지만 실제 절차는 제공 범위에 없으므로, 보조 개요에만 있는 후속 내용으로 이를 보완할 수는 없다.

🧾 핵심 주장 / 시사점

• MTRL의 핵심은 정답 행동 순서를 수집하는 대신 최종 결과를 채점하는 데 있다. 따라서 예제의 적용 가능성을 판단할 때는 해당 다단계 업무의 성공을 보상으로 표현할 수 있는지가 중요하다.
• 낮은 추론 노력에서 성공률 개선과 생성 토큰 감소가 함께 관찰됐지만, 토큰 요금의 최대 항목은 학습이었다. 생성 토큰 절감 수치만으로 전체 비용 절감 폭을 판단하기는 어렵다.
• 런타임 검증은 성공 응답만을 기준으로 삼지 않는다. 의도한 400 오류는 연결 경로가 작동한다는 증거가 될 수 있으며, 403과 30초 시간 초과는 서로 다른 구성 문제를 가리킨다.

✅ 액션 아이템

• GPT-OSS-20B의 기본 추론 노력과 낮은 추론 노력에서 성공률·생성 토큰을 함께 비교해 적용 설정 판단.
• 토큰 요금 $338.50과 별도 AgentCore 비용 약 $79를 함께 반영해 실험 총비용 검토.
• 학습 전 동일 리전·IAM 신뢰 주체·HTTP 진입점을 검증하고, 400 'Could not find job'·403·30초 시간 초과를 구분해 구성 문제 진단.

❓ 열린 질문

• GPT-OSS-20B의 Wordle 성공률 개선이 실제 적용하려는 다단계 작업에서도 재현되는가?
• 낮은 추론 노력의 생성 토큰 63~83% 감소를 고려할 때, 작업 성능과 전체 비용을 함께 만족하는 추론 설정은 무엇인가?
• 동일 리전·IAM 신뢰 주체·HTTP 진입점 제약을 충족한 환경에서 400 'Could not find job'을 통한 통합 검증이 확인됐는가?