오늘의 AI Daily News

발행 기준: 새 발표와 검증 가능한 범위

이 글은 2026년 10월 25일 오전 11시 30분 KST를 기준으로 공개된 공식 자료만 다룬다. 검색 API에는 필요한 키가 없어 결과를 근거로 사용하지 않았다. 대신 AWS 인공지능 블로그의 공식 RSS를 열어 원문 게시 시각과 링크를 확인하고, 같은 피드에 실린 글 전문 및 각 발표 원문·공식 문서를 대조했다. OpenAI 뉴스, Hugging Face 블로그, GitHub 블로그 RSS, Google 블로그 RSS도 살폈다. 이들 목록에서 이 글의 기준 시각 이후 내용이나 지난 글에서 이미 다룬 소재를 새 발표로 부풀리지 않았다. 10월 25일은 일요일이다. 오늘 공개된 새 모델이 네 건 나왔다는 뜻이 아니라, 앞선 영업일에 나온 공식 기술 발표 중 이전 AI Daily News가 아직 다루지 않은 네 건을 오늘의 실무 관점에서 깊이 읽는다는 뜻이다.

선정한 원문은 AWS가 UTC 10월 23일에 공개한 멀티턴 강화학습 실습, SageMaker 엔드포인트 자동 확장과 CDK 배포, Bayer Crop Science의 에이전트 의사결정 엔진 및 UTC 10월 22일 공개한 SageMaker 훈련 세션 API다. 시차를 적용하면 앞의 세 건은 10월 24일 KST, 마지막은 10월 23일 KST 발표다. 따라서 날짜 표기와 발행 날짜를 혼동하지 않는다. 수치와 개선 효과는 각 발표 주체의 사례 결과이며, 독립 실험이나 모든 계정·리전·업무에 대한 보증이 아니다.

오늘의 핵심은 새 모델의 이름이 아니다. 에이전트의 행동을 어떻게 학습하고, 필요한 자유도를 어디까지 개발자에게 돌려주며, 실제 업무의 권한과 오류를 어떻게 운영하고, 변경 후에도 추론 용량이 살아 있는지 어떻게 보장할 것인가가 네 발표를 잇는다. 모델이 Wordle을 풀 수 있다는 사실은 사내 결재를 안전하게 처리할 수 있다는 뜻이 아니다. GPU를 직접 관리하지 않아도 된다는 사실은 훈련 알고리즘을 잘 설계했다는 뜻이 아니다. 질문의 80%를 엔지니어 없이 해결했다는 사례는 나머지 20%의 위험이 작다는 뜻이 아니다. CDK 배포가 성공했다는 로그는 자동 확장 정책이 실제로 남아 있다는 증거가 아니다. 이 글은 각 주장 뒤에 숨은 분모·계약·관측 지표를 풀어, 실무자가 자기 시스템에 적용할 수 있는 검증 단위로 바꾼다.

Top News: 공식 발표 네 건을 먼저 짚기

1. SageMaker AI의 멀티턴 강화학습(MTRL) 실습. 하나의 질문에 대한 정답 문장을 학습하는 대신, 에이전트가 여러 번 도구를 사용해 과제를 끝낸 전체 에피소드의 보상으로 모델을 조정한다. AWS의 Wordle 사례에서 gpt-oss-20b의 홀드아웃 단어 해결률은 실제 서빙 설정인 중간 reasoning effort·temperature 1.0에서 61%→84%였다. 낮은 effort 설정에서는 15%→69%였다. 약 10만 5천 롤아웃의 훈련 토큰 비용은 약 339달러, 별도 AgentCore 런타임 사용액은 약 79달러라는 자체 계산이다. 문제 자체는 교육용이며, 이 가격에 인력·개발·검증·운영 전액이 포함된 것은 아니다. 원문 · 공식 문서 · 샘플 코드
2. SageMaker 훈련 세션 API의 프로그램 가능한 학습 루프. sample(), forward_backward(), optim_step() 등 GPU 경계의 연산은 서비스에 맡기면서, 보상·데이터 선택·순서·손실 함수는 개발자 Python 코드가 관리한다. AWS는 수학 문제의 작은 예제에서 10단계 학습 후 홀드아웃 정확도 56%→75%, 별도 코드 생성 실험에서 200개 테스트 문제의 정확도 40%→50.5%를 보고했다. 이는 서로 다른 작은 실험이지 MTRL 사례와 합쳐 하나의 우월성 점수로 읽을 수 없다. 원문 · 공식 문서 · 공식 cookbook
3. Bayer Crop Science, 기존 분석 플랫폼 위에 에이전트 인터페이스 운영. 분석 실행·기록 계층인 CDE를 대체하지 않고, 자연어 질의와 장애 진단을 맡는 ADE를 얹었다. 발표에 따르면 22개 전문 에이전트와 약 20개 API 도구가 운영되고, 초기 단계의 사용자 질문 약 80%는 엔지니어 개입 없이 해결됐다. 한 장애 원인 파악은 종전 1시간 이상에서 10분 미만으로 줄어든 사례가 있다. 이는 발표사가 제시한 특정 조직·업무의 성과다. 핵심 설계는 오래 사는 체크포인트, 세 단계의 인증 경계, 읽기 전용 최소 권한, 태스크 성공률을 보는 알람이었다. 원문
4. SageMaker 엔드포인트 갱신과 자동 확장 정책의 충돌 해결. 엔드포인트 구성 변경 전에 ScalableTarget을 해제해야 하지만, 이를 수동으로 하면 CloudFormation의 실제 상태와 선언 상태가 어긋날 수 있다. AWS의 CDK 예시는 해제→엔드포인트 갱신→InService 확인→대상 재등록→정책 부착을 커스텀 리소스로 순서화했다. 새 모델 배포가 끝나도 확장 정책이 조용히 사라지는 오류를 막는 운영 패턴이다. 대신 Lambda 12개와 Step Functions 상태 머신 2개 등 보조 리소스가 생긴다. 원문 · 샘플 코드

배경: 모델의 한 번짜리 답에서 ‘행동하는 시스템’으로

일반적인 지도 미세조정은 입력과 기대 출력 쌍을 만든다. 고객 문의를 입력하면 분류 라벨을, 설명을 입력하면 정답 문장을 돌려주는 식이다. 그러나 업무용 에이전트는 한 번만 답하지 않는다. 현재 상태를 읽고, 필요한 도구를 고르고, 결과를 해석하고, 실패하면 다시 시도하고, 마지막에 업무가 실제로 끝났는지 확인한다. 앞 단계의 선택이 뒤 단계의 관측 자체를 바꾸므로, 동일 과제에도 여러 합당한 경로가 존재한다. 이런 문제에서는 모든 중간 단계를 사람이 정답으로 표기하기 어렵다. 최종 목표가 비교적 확실하다면 전체 에피소드의 결과를 보상으로 쓰는 강화학습이 매력적이다. 하지만 결과를 어떻게 판정하느냐에 따라 잘못된 전략이 학습될 수도 있다.

에이전트 훈련과 배포 사이에도 빈틈이 있다. 연구자는 새로운 보상 함수나 데이터 커리큘럼을 짜고 싶지만, 흔한 관리형 미세조정 서비스는 미리 정해진 레시피만 받는다. 직접 GPU 클러스터를 잡으면 자유도는 늘지만 분산 실행, 체크포인트, 장애 복구, 비용 관리가 팀의 일이 된다. 훈련 세션 API는 이 경계에서 연산 인프라와 알고리즘 통제권을 분리하려는 제품 설계다. 다만 사용자 코드가 잘못된 보상·평가·도구를 사용하면 GPU 관리가 깔끔해도 모델의 행동은 나빠진다.

실제 업무에서는 또 다른 경계가 등장한다. Bayer의 기존 CDE는 여러 작물·지역의 분석 워크플로를 실행하고 기록해 왔다. 사용자에게 어려웠던 것은 실행 자체보다, 어느 API와 로그에서 실패 이유를 찾고 결과의 출처를 확인하는지였다. ADE는 그 위에 자연어 인터페이스를 얹는다. 그래서 모델 학습 성능보다 어떤 데이터에 접근하고 어떤 도구로 무엇을 읽었는지가 중요해진다. 입력자가 권한이 없는 결과를 볼 수 있다면 자연어 UI는 보안 구멍이고, 단순히 HTTP 200을 반환한다고 사용자의 질문이 해결된 것은 아니다.

마지막으로 추론 서비스의 인프라가 남는다. 새 모델 아티팩트가 준비되어도 엔드포인트 갱신이 자동 확장 정책을 끊어 버리면, 트래픽이 늘어나는 순간 서비스 품질은 무너진다. 이것은 생성 모델만의 문제가 아니라 선언형 배포 시스템과 상태가 있는 클라우드 리소스의 조합에서 흔히 생기는 라이프사이클 순서 문제다. 오늘의 네 뉴스는 이처럼 데이터→보상→모델 갱신→도구·권한→배포→용량이라는 연속적인 제품 사슬을 각각 다른 위치에서 비춘다. 어느 한 곳의 데모 성공을 전체 사슬의 운영 준비 완료로 해석하지 않는 것이 오늘 읽기의 출발점이다.

1. 멀티턴 강화학습: 정답 경로가 아니라 에피소드 결과를 배운다

Wordle 예제가 보여주는 학습 단위

AWS의 실습에서 각 훈련 행은 정답 문장이나 교사 에이전트의 행동 로그를 담지 않는다. 비밀 단어 하나가 에이전트 환경에 전달되고, 에이전트는 정책 모델에 물어 추측을 만들고 guess_word 도구로 결과를 받는다. 최대 여섯 차례 시도 뒤 환경이 보상 하나를 반환한다. AWS는 SageMaker AI가 훈련 작업과 정책 모델을 소유하고, AgentCore가 게임 환경·도구·보상 함수를 호스팅한다고 설명한다. 작업은 Lambda forwarder를 경유해 AgentCore 런타임을 호출한다. AgentCore가 유일한 선택지는 아니며 문서상 EKS, EC2, Fargate 같은 자체 인프라에서도 에이전트를 호스팅할 수 있다.

설계의 가장 중요한 경계는 비밀 단어가 모델에 노출되면 안 된다는 점이다. 예제의 한 훈련 행은 JSON 문자열 안에 prompt, answer, id를 담지만, answer는 환경과 보상 코드만 읽는다. 정책 모델은 모든 과제에서 같은 ‘다섯 글자 단어를 맞혀라’ 지시와 도구의 이전 피드백만 본다. 만약 환경 코드를 고치다가 비밀 단어가 로그나 모델 문맥으로 새어 들어간다면 높은 해결률은 행동 학습이 아니라 데이터 누출의 결과가 된다. 사내 업무에서도 비슷한 오류가 생긴다. 평가 정답, 고객이 제출하지 않은 최종 처리 결과, 승인자만 아는 상태를 에이전트 프롬프트에 넣으면 보상은 실제 추론 능력을 측정하지 않는다.

훈련에는 같은 단어를 여러 번 플레이한 결과의 상대 차이를 쓰는 GRPO(Group Relative Policy Optimization)가 적용되고, gpt-oss-20b 전체를 다시 학습시키는 대신 LoRA 어댑터를 업데이트한다. 원문은 640개 훈련 단어와 겹치지 않는 128개 검증 단어를 사용했다. 다섯 배치와 여러 epoch의 계산을 통해 100단계 약 10만 5천 회 롤아웃이 발생했다. 128개 검증 과제는 설정 비교의 출발점이지만, 1~2개 정답 차이도 비율로는 거의 1%포인트다. 발표의 37%, 84% 같은 숫자를 너무 정밀한 소수점 경쟁으로 읽으면 안 된다. 특히 도구 사용에서 손실 규모가 큰 조직이라면 단순 정답률 외에 돌이킬 수 없는 잘못된 행동 빈도를 따로 측정해야 한다.

보상 역전: 좋은 행동에 점수를 줬는데 나쁜 행동이 이기는 이유

이번 사례에서 가장 전이 가능한 교훈은 성능 숫자보다 보상 설계 오류다. AWS는 처음에 각 추측의 점수를 한 게임 동안 더했다. 단일 추측을 독립 사례로 평가할 때는 쓸 만한 점수였지만 전체 에피소드로 합치자 두 가지 역전이 생겼다. 실패한 게임도 여섯 번의 보너스가 쌓여 약 +0.49점을 얻었다. 첫 시도에 정답을 맞힌 게임은 +0.99점인데 세 번째에 맞힌 게임은 +1.61점이었다. 오래 끌수록 중간 보너스를 더 모으니, 효율적인 성공이 불리해진 것이다. 모델은 사람이 원한다고 생각한 목표가 아니라 구현된 점수 함수를 최적화한다.

수정된 보상은 결과를 먼저 분리한다. 첫 시도 성공은 1.55, 여섯 번째 성공은 1.05, 여섯 번 시도 후 실패는 -0.5, 유효한 추측조차 못 한 경우는 -1.5를 기본으로 둔다. 녹색·노란색·회색 힌트를 일관되게 사용하고 새 글자를 탐색하는 작은 shaping 항은 [-1, 1]로 자른 뒤 성공에는 0.04, 실패에는 0.15의 가중치를 준다. 성공의 추가 점수가 작아야 빠른 성공과 느린 성공의 순서가 뒤집히지 않는다. 원문의 초기 수정은 성공에도 0.15를 사용했는데, 다시 인접한 시도 횟수의 순서가 바뀌었다. 두 번의 수정을 거쳐야 모든 성공은 모든 실패보다 높고, 빠른 성공은 느린 성공보다 높다는 불변식을 만족했다.

업무형 보상에서도 이 방식이 필요하다. 인사 승인 에이전트라면 ‘도구를 여러 번 호출했다’, ‘담당자에게 친절하게 설명했다’보다, 권한 있는 승인자가 필요한 서류를 확인했고 데이터베이스의 최종 상태가 정책에 맞는지가 우선이다. 주어진 기한 전에 정확히 해결하는 것과, 반복 호출로 비용을 쓰다가 우연히 해결하는 것을 구분한다. 반대로 실패했지만 위험한 데이터 변경은 없었던 경우와 잘못된 계좌로 지급해 놓고 자연스러운 완료 메시지를 보낸 경우는 똑같은 실패로 묶지 않는다. 샘플 과제를 실제 학습에 넣기 전에 사람이 예상한 업무 순서를 테스트 벡터로 만들고, 경계값·부분 실패·무응답·잘못된 도구 호출에서 보상 함수가 같은 순서를 유지하는지 검사해야 한다.

결과 수치와 비용의 정확한 분모

AWS의 100단계 실행은 약 4억 9,162만 prefill 토큰, 1억 5,974만 sample 토큰, 6억 4,331만 train 토큰을 사용했고, 당시 미국 동부 리전의 공개 단가로 합산한 훈련 토큰 비용은 338.50달러였다. 약 12시간 40분이 걸렸고 AgentCore 런타임은 별도 약 79달러였다고 한다. 따라서 ‘339달러로 Wordle 모델을 만들었다’는 문장은 불완전하다. 훈련 토큰만 339달러이고 런타임, 추가 평가, S3·로그·인력·실패한 사전 실험은 따로 봐야 한다. 원문 자체도 오류 때문에 여러 실행을 다시 했다고 말한다. 비용을 도입 제안서에 옮긴다면 성공적으로 평가된 모델 버전 하나를 얻는 총비용으로 다시 계산해야 한다.

세 토큰 항목을 나눠 보는 것도 중요하다. prefill은 매 턴 이전 대화 기록을 다시 읽으면서 늘고, sample은 모델이 생성하는 일반 출력과 reasoning 토큰까지 포함한다. train은 어댑터 업데이트를 위한 역전파 입력으로 전체 비용에서 가장 큰 부분이었다. 실무형 에이전트는 Wordle보다 도구 결과가 길고, 승인 기록이나 정책 문서가 반복해서 붙는다. 같은 에피소드 횟수라도 문맥 길이가 늘면 prefill·train 비용이 크게 달라질 수 있다. API 공급자의 ‘입력 단가’ 하나를 전체 비용에 곱하는 것은 잘못이다. 평균 턴 수, 턴당 입력 누적, 실패 후 재시도, 중단 조건, 평가 비용을 포함해야 한다.

숫자 가운데 가장 흥미로운 대목은 검증 곡선과 실제 서빙 조건의 차이다. 훈련 단계의 검증은 temperature 0에서 마지막 37%였으나, 중간 reasoning effort와 temperature 1.0으로 별도 평가했을 때 훈련 모델은 84%, 베이스는 61%였다. 낮은 effort에서도 훈련 전 15%에서 후 69%로 올랐다. 즉 훈련 중 편의상 고정한 디코딩 설정이 실제 제품의 결과를 대표하지 않았다. 이 차이가 모든 업무에서 확률적 샘플링을 올리라는 권고는 아니다. 어떤 작업은 같은 입력에서 같은 결과를 내는 재현성이 더 중요하다. 요점은 배포할 effort·temperature·도구 타임아웃·출력 검증 규칙을 명시한 다음, 그 설정 그대로 오프라인 평가와 부하 시험을 하라는 것이다.

구현에서 드러난 취약한 지점

이 실습은 성공한 호출만 나열하지 않는다. AgentCore 앱의 HTTP 서버 엔트리포인트와 SageMaker 보상 보고 데코레이터의 순서를 틀리면 모든 호출이 30초에 타임아웃된다. 데모용 가짜 작업 ARN이 다른 AWS 계정을 가리키면 인증 단계의 403으로 끝나, 실제로 확인하려던 ‘작업이 없음’ 오류에 닿지 못한다. 인증 토큰을 요청마다 새로운 botocore 세션에서 만들면 동시 롤아웃 32개 부근에서 자격증명 공급자가 막혔고, 1시간 동안 단순 캐시하면 자격증명이 갱신될 때 403이 생겼다. AWS는 갱신 가능한 세션과 짧은 캐시, 403 재서명을 사용했다고 설명한다. 세부 구현은 서비스 버전에 따라 바뀔 수 있으나, 훈련의 병렬도는 인증·도구·네트워크의 병렬도까지 시험한다는 교훈은 변하지 않는다.

모델이 한 롤아웃에서 정책 엔드포인트를 한 번도 호출하지 못하면 학습 작업 전체가 실패할 수도 있다. 반면 정책 모델을 호출했지만 유효한 추측을 못 했다면 -1.5 보상으로 학습할 수 있다. 이 둘을 같은 ‘실패’로 로깅하면 어디를 고쳐야 하는지 알 수 없다. 또 학습률이 너무 높을 때 모델이 도구 호출을 구조화된 호출이 아니라 일반 텍스트로 쓰기 시작해 모든 롤아웃이 최하 점수를 받았고 기울기 정보가 사라졌다는 보고가 있다. 실제 에이전트라면 JSON 스키마 오류, 도구 이름 변경, 권한 부족, 모델의 계획 오류를 서로 다른 오류군으로 남겨야 한다. 기술 문제가 보상으로 섞이면 모델이 어떤 행동을 학습해야 하는지에 대한 신호가 왜곡된다.

한 팀이 이 기술을 시험한다면 처음부터 수만 번 롤아웃하지 않는다. ① 독립된 개발 계정에 읽기 전용 또는 되돌릴 수 있는 환경을 만들고, ② 비밀 정답이 정책 모델에 들어가지 않는지 확인하고, ③ 보상 불변식을 유닛 수준에서 점검하고, ④ 단일 에피소드로 도구·인증·로그의 모든 구간을 거친 뒤, ⑤ 작은 훈련을 돌려 도구 호출 형식과 결과 분포를 확인한다. 그 다음 비로소 예산 한도와 중단 기준을 갖춘 본 실험을 실행한다. 사고를 잘 설명하는 모델을 만드는 것보다, 검증 가능한 결론을 가진 과제와 엄격한 환경을 만드는 일이 먼저다.

2. 훈련 세션 API: ‘관리형’과 ‘알고리즘 자유도’ 사이의 새로운 경계

관리형 미세조정과 무엇이 다른가

SageMaker AI 훈련 세션 API는 AWS가 하루 먼저 발표한 서버리스 모델 맞춤화 확장의 기술적 중심이다. 관리형 레시피는 사용자가 기본 모델·데이터·하이퍼파라미터를 주고 서비스가 학습 단계를 정한다. SageMaker Training Jobs나 HyperPod은 알고리즘 구현의 자유가 크지만 인스턴스와 분산 작업의 운영 책임이 커진다. 이번 API는 GPU에 남아 있는 상태 유지형 세션을 만들고, 개발자의 Python 프로세스가 sample, forward_backward, optim_step 같은 연산을 호출한다. 서비스는 모델 적재, LoRA, 분산 실행, 동기화, 장애 복구, 체크포인트 저장을 처리한다고 설명한다. 제어 경계가 ‘훈련 작업 전체’에서 GPU 연산 하나하나로 내려온다.

이 경계는 연구팀에게 실제로 의미가 있다. 예를 들어 지원 상담 모델을 지도 미세조정하되, 규제상 반드시 포함해야 하는 문구의 손실에 다른 가중치를 주고 싶을 수 있다. 코드 에이전트는 생성 결과를 샌드박스 테스트로 평가하고, 실패 유형별로 다음 프롬프트의 난이도를 바꾸고 싶을 수 있다. 구매 승인 에이전트는 동일 과제의 네 개 시도를 비교하고, 모두 실패했으면 다음 배치를 학습시키지 않고 보상 판정기를 먼저 고쳐야 할 수도 있다. 미리 포장된 레시피는 이런 분기와 단계별 관측을 충분히 표현하지 못할 수 있다. API를 쓰면 알고리즘은 우리 코드가, 연산 인프라는 공급자가 맡는 계약을 설계할 수 있다.

그렇다고 모든 학습에 이 API가 최선인 것은 아니다. 데이터와 정확한 기대 출력이 안정적으로 정해져 있고 표준 지도 학습으로 충분하다면, 관리형 레시피가 설정·오류면이 적을 수 있다. 모델을 0에서 사전학습하거나 특정 GPU 커널을 수정해야 한다면 이런 API보다 낮은 수준의 훈련 작업이 필요할 수 있다. API 호출마다 전달할 데이터와 결과를 직렬화하고 네트워크 경계를 넘어야 하므로, 아주 작은 연산을 지나치게 잘게 쪼개면 지연이 커질 여지도 있다. 원문은 GPU 유지와 토큰 과금을 강조하지만, 각 조직은 작업량의 크기와 API 왕복·로컬 보상 실행 시간까지 포함해 비교해야 한다. ‘서버리스’는 비용이 0이거나 운영 결정이 없다는 말이 아니라, 서버를 명시적으로 배치하지 않아도 된다는 책임 분배다.

세 클라이언트가 나타내는 작업의 층

공식 글은 ServiceClient→TrainingClient→SamplingClient 세 층을 소개한다. ServiceClient에는 실행 역할, 리전, 모델 패키지 그룹, S3 출력 위치와 선택적 KMS·VPC 설정이 붙는다. 이 객체가 학습 세션을 시작한다. TrainingClient는 순전파·역전파·최적화·저장 같은 학습 작업을 수행하고, SamplingClient는 현재 정책으로 답을 생성하거나 로그확률을 계산한다. 활성 세션은 OpenAI 호환 chat completions 엔드포인트도 제공하므로 기존 샘플링 코드를 연결할 수 있다. 하지만 호환 엔드포인트라는 말은 모든 응답 의미·도구 호출 형식·reasoning 옵션까지 기존 서비스와 완전히 같다는 보장은 아니다. 실제 적용은 모델별 채팅 템플릿과 토큰화, 호출 제한을 확인해야 한다.

일반적인 강화학습 한 단계는 네 부분으로 나뉜다. 먼저 여러 프롬프트에서 현재 정책의 출력을 샘플링한다. 두 번째로 사용자 코드가 숫자 정답, 단위 테스트, 시뮬레이터, 검토자 피드백 같은 결과를 점수화한다. 세 번째로 그 점수에서 advantage를 계산하고 GPU의 forward_backward·optim_step을 실행한다. 마지막으로 새 어댑터 가중치를 샘플러에 반영해 다음 단계가 갱신된 정책에서 생성되도록 한다. 샘플러 반영을 빼먹으면 훈련 그래프는 진행되는 듯해도 롤아웃은 오래된 정책에서 계속 나올 수 있다. 개발자가 루프를 직접 제어하는 만큼 이러한 순서 불변식도 개발자의 책임이다.

원문의 간단한 수학 문제 예제는 질문별로 여러 출력을 생성하고 정답이면 1, 아니면 0으로 보상한다. 같은 질문 그룹에서 평균을 빼고 표준편차로 나눠 상대 advantage를 만든다. sample() 호출은 future를 즉시 돌려주므로 요청 여러 개를 먼저 제출한 뒤 결과를 기다린다. 각 학습 datum에는 프롬프트·응답 토큰, 샘플링 때의 로그확률, advantage, 프롬프트 부분을 손실에서 제외할 가중치 마스크가 담긴다. 이는 ‘짧은 코드만 쓰면 RL이 끝난다’는 이야기가 아니다. 정확히 어떤 토큰에 손실을 적용하고 어떤 정책에서 그 샘플을 얻었는지가 알고리즘의 의미다.

예제에서는 40개 수학 문제로 10단계를 학습한 뒤 홀드아웃 정확도가 56%에서 75%로 올랐다고 한다. 이 숫자만으로 제품에 사용할 모델이 개선됐다고 결론 내리면 안 된다. 40개 문제는 규모가 작고, 최종 지표가 어떤 난도·언어·표현 변형을 포함하는지에 따라 차이가 크다. 정답 추출 함수가 #### 뒤 숫자를 읽는다면 포맷을 지키는 능력과 수학 풀이 능력이 섞인다. 더 많은 문제, 다른 표현, 실서비스 입력의 오타와 중간 질문, 토큰 비용·응답 지연을 함께 검증해야 한다. 공급자 블로그의 숫자는 API가 작동하는 실습 사례의 근거이지 일반화 성능 보증이 아니다.

Code RL 사례: 샌드박스 판정도 정답은 아니다

cookbook의 좀 더 복잡한 예시는 경쟁 프로그래밍 문제를 푸는 코드 생성 모델이다. gpt-oss-20b에 rank 32 LoRA 어댑터를 적용했고, 한 과제에서 모델이 check_solution 도구를 호출해 테스트 결과를 본 뒤 답을 수정할 수 있다. 생성된 Python 코드를 샌드박스에서 실행해 유닛 테스트를 전부 통과하면 1, 아니면 0으로 보상하고, 코드 블록 자체가 없으면 작은 패널티를 준다. 50단계, 단계마다 128문제와 문제당 8개의 답, 두 턴, 정책 staleness 상한 3단계라는 조건에서 원문은 훈련 보상 0.46→0.60, 200개 홀드아웃 문제 정확도 40%→50.5%를 보고했다.

이 사례의 재사용 가능한 아이디어는 샘플링과 훈련의 시간차를 명시했다는 점이다. 여러 롤아웃 작업자가 GPU가 학습하는 동안 다음 후보를 만들면 처리량은 좋아질 수 있지만, 어떤 출력은 이전 정책에서 생성된다. cookbook은 최대 k=3 단계 오래된 정책의 그룹만 허용하고, 더 오래된 것은 다시 큐에 넣으며, 정책 차이를 고려하는 손실을 사용한다. 무조건 최신 정책만 기다리면 GPU가 놀 수 있고, 무제한 오래된 샘플을 받으면 지금 정책에 맞지 않는 학습 신호가 쌓인다. 서비스 운영에서 캐시 최신성과 처리량을 절충하듯, 강화학습에서는 정책 최신성과 처리량을 절충해야 한다.

유닛 테스트 통과도 최종 진실은 아니다. 테스트가 충분하지 않다면 모델은 특정 입력을 하드코딩하거나 우연히 공개 테스트만 통과할 수 있다. 실행 샌드박스가 제대로 격리되지 않으면 코드가 네트워크·파일·프로세스 자원에 접근할 수 있다. 모델이 테스트 피드백을 본 뒤 마지막 제출물을 바꾸는 과정에서는 테스트 결과가 정답 자체를 과도하게 누설할 수도 있다. 실제 기업 코드를 이 레시피로 학습한다면 샌드박스의 권한과 자원 제한, 보상 평가의 시간 제한, 공개/비공개 테스트 분리, 비밀 데이터 유출 방지, 반복 생성에 따른 테스트 과적합을 별도 설계해야 한다. AWS 발표가 코드 생성 정확도 개선을 보여줬다고 해서 안전한 소프트웨어 생성까지 입증한 것은 아니다.

토큰 과금의 이점과 보이지 않는 비용

AWS는 훈련 세션의 GPU 사용을 처리한 토큰 기준으로 청구하므로, 사용자 기기에서 보상 함수를 10초 실행하는 동안 GPU 시간 요금이 발생하지 않는다고 설명한다. GPU를 한 시간 단위로 예약해 놓고 보상 계산을 기다리는 구조보다, 보상 계산이 비싼 작업에서 유리할 수 있다. 그러나 총 실험비는 별개의 문제다. 로컬이나 별도 클라우드의 보상 모델, 코드 실행 샌드박스, 데이터 저장, 호출 실패 재시도, 검증 데이터 제작, 숙련된 ML 엔지니어의 시간을 계산해야 한다. 토큰 사용료는 비교적 투명한 분자 중 하나일 뿐이다.

또한 토큰 과금이 예측 가능하려면 생성 길이와 반복 횟수를 관리해야 한다. 실패한 답을 길게 설명하는 모델은 정답률이 낮을 뿐 아니라 sample과 train 비용을 늘린다. 다중 에이전트 롤아웃은 도구 목록과 이전 대화가 누적돼 prefill이 폭증할 수 있다. 단계마다 입력 길이 분포, 생성 길이 분포, 보상, 성공률, GPU API 지연, 로컬 판정 지연을 함께 기록한다. 단순히 ‘50단계 학습’이라는 축만으로 두 실험을 비교할 수 없다. 각 단계의 문제 수·답 수·길이·판정 비용이 다르기 때문이다.

세션은 살아 있는 동안 동시 세션 할당량을 점유한다. stop()을 빼먹으면 처리하지 않는 실험도 쿼터를 차지할 수 있으므로 오류 경로까지 종료를 보장해야 한다. 저장 역시 한 종류가 아니다. 학습 중 샘플러 갱신용 가중치, 서빙용으로 병합한 모델, 가중치와 optimizer 상태를 포함하는 재개용 체크포인트는 용도가 다르다. save_weights_for_sampler와 save_state의 결과를 구분하지 않으면 재개할 수 없는 아티팩트를 백업이라고 오인하거나, 배포할 수 없는 상태를 운영 모델로 등록할 수 있다. 모델 패키지 그룹의 버전, 입력 데이터 스냅샷, 보상 코드 커밋, 토큰화 설정을 함께 기록해야 실험을 재현할 수 있다.

MTRL과 세션 API를 혼동하지 않기

전날 발표한 훈련 세션 API와 오늘 다룬 MTRL 실습은 둘 다 SageMaker AI에서 GPU 기반 모델 맞춤화를 다루지만 같은 사용법을 다른 이름으로 부르는 게 아니다. MTRL 관리형 작업에서는 사용자가 에이전트 런타임·데이터·보상을 제공하고, 여러 롤아웃과 정책 갱신의 큰 틀을 서비스가 조정한다. 훈련 세션 API에서는 개발자 루프가 sample, forward_backward, optim_step을 직접 순서화한다. 전자는 에피소드형 작업을 서비스 틀에 올리기 쉽고, 후자는 새로운 손실·커리큘럼·데이터 조합을 실험하기 쉽다. 실제 선택은 ‘새 알고리즘을 구현해야 하는가’, ‘보상 환경이 어디에 있는가’, ‘운영팀이 직접 감당할 실험 코드의 범위는 무엇인가’에 달려 있다.

두 방식 모두 평가 데이터를 잘못 나누면 숫자를 과장한다. Wordle 단어가 학습과 검증에 겹치면 일반화로 보기 어렵고, 코드 문제의 같은 풀이 패턴이 양쪽에 들어가면 비슷한 문제가 생긴다. 두 방식 모두 사람의 업무 권한을 학습 보상과 동일시하지 말아야 한다. 모델을 훈련시켜 도구 사용률을 높여도 지급·삭제·권한 변경 도구에는 별도의 정책과 승인 절차가 필요하다. 제품팀은 훈련 API 선택보다 먼저 과제 성공의 판정기와 실제 피해 가능성을 명세해야 한다.

3. Bayer ADE: 에이전트를 기존 결정 시스템의 ‘설명 계층’으로 놓다

왜 분석 플랫폼을 갈아엎지 않았나

Bayer Crop Science는 유전체, 현장 시험, 영상, 환경 조건, 모델 출력을 조합해 작물 육종에 쓰는 분석을 운영한다. 기존 Connected Decision Engine(CDE)은 다양한 작물·지역·팀의 여러 모델 구성을 배포·실행·모니터링하고 이력을 남긴다. 문제는 CDE가 계산을 못 하는 것이 아니라, 연구자나 육종가가 ‘어제 어떤 워크플로가 왜 실패했는가’를 알아보려면 API, 문서, 메타데이터 저장소, 대시보드, 로그를 직접 이어야 했다는 점이다. ADE(Agentic Decision Engine)는 실행 플랫폼을 새로 만들기보다 그 위에 자연어 접근 계층을 놓았다. 이 접근은 조직에서 흔히 벌어지는 ‘챗봇이 기존 업무 시스템을 대체한다’는 서사와 다르다. 권위 있는 업무 기록은 원래 시스템에 남기고, 에이전트는 여러 출처를 탐색해 설명한다는 역할 분담이다.

그 결과 이 제품의 성패는 최신 기반 모델 하나를 택하는 문제가 아니다. 어떤 전문 에이전트가 어떤 시스템에 접근할 수 있는지, 감독자 에이전트가 질문을 제대로 라우팅하는지, 도구의 최신 상태와 캐시가 충돌할 때 어느 쪽을 우선하는지, 사용자가 답의 근거를 확인할 수 있는지가 핵심이다. 원문은 22개의 전문 에이전트가 운영 중이라고 밝힌다. Domain Expert는 문헌·내부 지식에 대한 RAG를, Operational은 실시간 워크플로 상태를, Troubleshooting은 운영 텔레메트리를, Visualization은 차트·대시보드를 담당한다. 감독자가 질문을 분류하고 필요하면 여러 전문가의 결과를 결합한다. 전문가를 많이 두는 자체가 성숙도를 증명하지는 않는다. 전문화가 의미 있으려면 역할별 권한과 평가셋이 분리되어야 한다.

ADE의 4층 구조는 사용자 경험, 오케스트레이션, 전문가, 도구와 데이터다. React 프런트엔드의 요청은 Microsoft Entra ID를 확인하는 프록시를 통과한다. AgentCore 런타임에서 LangGraph 기반 제어 흐름이 실행되고, DynamoDB가 워크플로 체크포인트를, Aurora PostgreSQL이 세션·피드백·분석을, ElastiCache가 TTL이 있는 응답 캐시를 맡는다. S3에 있는 도메인 자료는 Titan Text Embeddings V2로 임베딩되어 OpenSearch Serverless에서 검색된다. CloudWatch가 런타임·애플리케이션 관측을, AgentCore Gateway가 백엔드 API의 MCP 도구 노출과 인증 경계를 맡는다. 이 서비스를 모두 써야 올바른 에이전트가 된다는 뜻은 아니다. 각 구성 요소가 어떤 종류의 상태와 책임을 소유하는지를 분리했다는 것이 중요하다.

세션이 살아 있다는 것과 상태가 지속된다는 것은 다르다

AgentCore 런타임은 사용자 세션별 실행 문맥을 격리하고 세션 생명주기 안에서 문맥을 유지할 수 있다. 하지만 장기 워크플로의 복구 원본으로 런타임 세션만 믿지 않았다. ADE는 LangGraph 체크포인트를 DynamoDB에 저장해 인스턴스 재시작, 확장, 세션 경계를 넘어 실행을 복원할 수 있도록 했다. 에이전트가 두 단계의 질문에서 첫 단계 조회를 마친 뒤 프로세스가 사라졌다면, 두 번째 단계는 어떤 도구를 다시 호출해야 하는지 알 수 있어야 한다. 무작정 전 단계를 다시 실행하면 비용은 물론, 쓰기 권한이 있는 워크플로에서는 중복 부수효과가 생길 수 있다. Bayer의 현재 운영은 읽기 전용 도구 중심이지만, 이 원칙은 향후 변경 도구를 추가할 때 더 중요해진다.

체크포인트에는 장점과 부담이 함께 있다. 저장된 상태가 오래되면 새 권한 변경이나 새 워크플로 결과가 반영되지 않을 수 있다. 사용자 세션 상태, 도구 응답 캐시, 업무 원본 데이터의 최신성은 서로 다른 개념이다. 담당자의 권한이 오늘 철회됐는데 어제의 에이전트 체크포인트가 과거 도구 결과를 그대로 재사용한다면 새로운 조회의 권한 검사를 우회한 셈이 될 수 있다. 따라서 복구 시 어떤 상태를 믿고 어떤 상태를 다시 검사할지 정의한다. 업무 결과가 바뀔 수 있는 도구는 재검증하고, 데이터 버전·조회 시각·사용자 권한 스냅샷을 로그에 남긴다. ‘지속 상태를 외부화하라’는 권고를 ‘과거 응답은 언제든 그대로 재사용하라’로 번역해서는 안 된다.

사용자·에이전트·도구의 신원을 한 토큰으로 덮지 않는다

Bayer는 사용자의 신원을 Microsoft Entra ID에 두고, AWS 서비스 간 호출에는 IAM, 후단 CDE 도구 접근에는 AgentCore Gateway의 outbound authorization을 사용한다. 별도 Lambda 인터셉터가 사용자별 검증과 필요한 권한 속성 전달을 맡는다. 이 설계의 중요한 점은 토큰을 많이 쓴다는 사실이 아니라 각 신뢰 경계의 발급자·수신자·스코프·유효기간을 명시한다는 사실이다. 프런트엔드에 로그인했다는 것만으로 모든 내부 API를 호출해도 되는 것은 아니다. 에이전트 런타임 역할이 어떤 AWS 리소스를 읽을 수 있다는 사실만으로 현재 사용자가 해당 업무 기록을 볼 권한이 있다는 것도 아니다.

인사시스템 같은 업무 앱에 적용하면 사용자 부서·직급·담당 조직에 따라 볼 수 있는 근태나 급여 자료가 달라진다. 검색 도구는 동일한 인덱스를 보더라도 사용자별 접근 범위를 적용해야 한다. 감독자 에이전트가 여러 전문가에게 질문을 전달할 때도 원 사용자와 요청 목적의 추적성을 유지해야 한다. 전문 에이전트가 자기 서비스 계정으로 모든 데이터를 보고 자연어 결과만 필터링하는 방식은 취약하다. 원문이 말하는 최소 권한은 전문가별로 다르다. Troubleshooting은 진단에 필요한 운영 자료를 읽되 워크플로를 수정하지 못하고, Domain Expert는 검색 인덱스를 조회하되 무관한 CDE API를 호출하지 못한다. 읽기만 허용해도 민감 정보 유출 위험은 남는다는 점을 함께 기억해야 한다.

도구 500개를 프롬프트에 넣는 것은 설계가 아니다

CDE에는 500개가 넘는 모델 구성이 있다. ADE는 API마다 별도 MCP 서버를 배포하는 대신, OpenAPI 명세를 AgentCore Gateway에 등록해 REST 작업을 MCP 도구로 노출한다. 원문은 운영 중 약 20개 API 도구를 공개하고 이 경로가 API별 통합 부담을 99% 이상 줄였다고 보고한다. 99%는 자체 조직의 통합 방식 비교이지 모든 프로젝트의 보편적 비용 절감률이 아니다. API 명세만 넣으면 인증·오류 처리·스키마 의미가 저절로 정확해진다는 뜻도 아니다. 게이트웨이는 인터페이스의 반복 작업을 줄일 뿐, 백엔드 권한과 데이터 계약은 여전히 유지해야 한다.

도구 설명은 모델의 문맥을 소비한다. 모든 도구를 항상 보여주면 토큰 비용이 늘고, 비슷한 이름의 도구를 고르는 오류도 늘 수 있다. ADE는 전문가별 도구를 제한하고, 더 큰 카탈로그에서는 의미 기반 도구 검색을 이용할 수 있다고 설명한다. 실무자는 도구 사용률만 보지 말고 질문 유형별로 올바른 도구를 골랐는지, 불필요한 도구를 몇 번 불렀는지, 사용 권한이 없는 도구를 시도했는지를 구분해 측정해야 한다. 도구 수를 무조건 줄이는 것도 해법이 아니다. 하나의 ‘만능 검색’ 도구가 너무 많은 역할을 맡으면 쿼리 비용과 권한 범위가 불투명해진다. 역할이 분명한 전문가와 제한된 도구 카탈로그 사이에서 적절한 단위를 찾아야 한다.

Visualization이 도구에서 별도 에이전트가 된 과정도 흥미롭다. 처음에는 다른 에이전트가 호출하는 단일 기능이었지만 데이터 조회, 차트 유형 선택, 재시도, 오류 처리, 기존 대시보드 반환 여부를 스스로 결정해야 하자 별도 전문 에이전트가 됐다. 필요하면 격리된 Code Interpreter에서 matplotlib·Plotly로 차트를 만들고 S3를 통해 데이터를 교환한다. 원칙은 단순하다. 입력과 출력이 좁은 결정적 작업은 도구로, 자체 상태·정책·재시도·표현 판단을 소유하는 복합 기능은 에이전트로 모델링한다. 그렇다고 모든 복잡한 코드에 LLM을 넣을 필요는 없다. 차트 종류를 업무 규칙으로 확실히 고를 수 있다면 결정적 서비스가 더 감사 가능할 수 있다. 에이전트화는 그 판단 과정의 유연성이 실제로 필요한 경우에만 이득이다.

새 모델이 항상 호환되는 것은 아니다

Bayer 팀은 reasoning mode가 켜진 새 모델 버전을 검토했지만, 당시 ADE 구현이 요구하는 도구 사용과 구조화 출력의 조합과 맞지 않아 릴리스에는 기존 모델을 유지했다. 이는 성능표의 점수가 높으면 운영 모델을 즉시 바꾸고 싶어 하는 팀에게 중요한 사례다. 모델 선택은 API 호출 성공 여부만이 아니라 구조화 출력 스키마의 안정성, 도구 호출 형식, 스트리밍, 응답 지연, 토큰 한도, 리전 가용성, 할당량, reasoning 옵션의 상호작용을 포함한다. 새 버전의 언어 품질이 좋아도 필수 도구를 한 번이라도 조용히 생략한다면 업무 결과는 나빠질 수 있다.

따라서 모델 교체는 사전 합의된 호환성 스위트를 통과해야 한다. 최소한 역할별 질문, 한 도구만 필요한 질문, 여러 도구가 필요한 질문, 도구 오류와 타임아웃, 스키마 위반, 허용되지 않은 자료 요청, 긴 자료와 간결한 자료의 인용 품질을 비교한다. 출력의 표면 형태만 맞추는 테스트는 부족하다. 예컨대 status: complete라는 JSON이 나와도 실제 CDE 워크플로가 실패 상태라면 에이전트는 실패했다. 인터페이스 계약과 의미 계약을 함께 시험해야 한다.

HTTP 성공과 업무 성공은 다른 지표

원문이 밝힌 운영상 사고 하나는 예외 처리기가 에이전트 오류를 잡아 정상 응답을 돌려줘, 모니터링이 실패를 성공으로 셌다는 점이다. 네트워크 상태 코드만 보면 체인은 멀쩡하지만 사용자의 질문은 해결되지 않았다. ADE는 CloudWatch의 사용자 정의 지표로 도구 오류, throttling, 모델 타임아웃, 구조화 출력 검증 실패를 따로 기록하고, 감독자와 전문가 사이의 호출을 추적한다. 업무형 에이전트에서 ‘실패율 0%’가 나오면 먼저 성공의 정의를 의심해야 한다. 에러를 친절하게 문장으로 돌려준 것과 해결한 것은 다르다.

Bayer는 초기 단계의 질문 약 80%를 엔지니어 없이 해결했다고 밝혔다. 분모는 질문이다. 해결의 판정이 사용자의 자기 보고인지, 엔지니어 재접촉 부재인지, 업무 원본 상태 검증인지 원문만으로는 상세히 알 수 없다. 업무별 심각도가 같은 것도 아니다. 간단한 상태 질문 80건을 자동 처리하고 손실이 큰 육종 결정 관련 질문 20건을 잘못 안내했다면 숫자는 여전히 80%일 수 있다. 내부 도입에서는 질문을 오류 진단, 데이터 출처, 규칙 해석, 실제 결정 지원으로 나누고 각각 정답 근거·잘못된 답의 비용·검토 경로를 정해야 한다. 완료율과 함께 ‘근거 없는 단정 비율’, ‘잘못된 출처 선택’, ‘권한 위반 시도’, ‘같은 문제 재질문’을 보고, 사용자가 어떤 종류의 답을 최종 승인할 수 있는지 UI에 드러낸다.

비용·보안·출시 준비가 프롬프트 밖에 있다

ADE의 요청 하나는 감독자, 전문가, 모델, 도구를 여러 번 거칠 수 있다. 계정 전체 Bedrock 청구액만으로 어느 질문이 비싼지 알 수 없어 애플리케이션 inference profile, 요청 메타데이터와 모델 호출 로그, IAM 주체 정보를 결합했다. 원문은 Visualization과 Operational 전문가가 다수 도구 호출 때문에 많은 토큰을 썼다고 설명한다. 반복되는 고정 프롬프트 접두부를 캐시할 수 있는 모델에서는 입력 토큰 비용을 20~30% 줄였다고도 보고한다. 이 수치는 ADE의 실제 패턴과 공급자 가격에서 나온 결과다. 다른 조직은 고정된 시스템 지시·도구 정의의 비중과 캐시 적중률에 따라 달라진다. 토큰 최적화가 접근 권한을 약화시키지 않도록, 사용자별 민감 맥락을 공용 캐시 접두부에 넣지 않는 것이 중요하다.

출시 전 검토에서는 모델 응답의 환각보다, 실패가 알람에 드러나지 않는 문제, 변경 가능한 컨테이너 이미지 태그, 이미지 이력 부재, 취약점 검사 누락, 네트워크 오류로 빈 응답이 돌아오는 문제를 찾았다. 팀은 ECR의 불변 버전 이미지·push 시 검사·수명주기 정책, 추가 알람, 부하 및 서비스 할당량 시험을 적용했고 35개 blocker를 해결했다고 밝혔다. 처음에는 전체 조직이 아니라 제한된 그룹에 공개했고, 발표 시점에는 사용자 100명 이상이 썼다. 이 수치를 이용해 ‘에이전트 운영은 프롬프트만 다듬으면 된다’고 말할 수 없다. 오히려 배포 이력과 용량, 장애 감지, 보안 응답을 다듬는 시간이 출시 품질을 만들었다.

향후 쓰기 도구를 붙일 때는 위험이 한 단계 올라간다. 현재 원문은 생산 환경의 전문 에이전트가 읽기 전용 접근과 구조화 출력 검증, 근거 자료에 기반한 답을 사용한다고 적는다. 차트를 생성하거나 원인을 설명하는 것과, 육종 실험을 삭제하거나 모델 결과를 확정하는 것은 다른 권한이다. 쓰기를 도입한다면 사용자 의도의 재확인, 변경 전후 비교, 승인자, idempotency key, 동시 수정 충돌, 철회·복구 절차까지 별도로 설계해야 한다. 발표된 80% 자동 해결률을 쓰기 자동화의 승인 근거로 사용해서는 안 된다.

4. SageMaker 엔드포인트 자동 확장: 선언형 배포가 실제 용량을 보증하지 않는다

변경 순서 하나가 왜 서비스 장애로 번질 수 있나

기계학습 모델의 실시간 엔드포인트를 운영하면 모델 이미지나 아티팩트, 인스턴스 유형, 환경 변수, 초기 인스턴스 수를 바꾼다. 동시에 Application Auto Scaling이 트래픽 변화에 맞춰 인스턴스를 늘리고 줄인다. 보통 인프라 코드는 두 자원을 선언하고 CDK 또는 CloudFormation이 적절히 업데이트할 거라고 기대한다. 이번 AWS 글은 그 기대가 특정 SageMaker 엔드포인트 변경에서 깨진다고 설명한다. 엔드포인트 구성의 variant를 없애거나 인스턴스 유형을 바꾸려면 먼저 해당 variant에 등록된 scalable target을 해제해야 한다. 자동 확장 등록이 남은 상태에서 엔드포인트를 갱신하면 SageMaker가 변경을 거부한다. 문제는 등록을 수동 해제해도 CloudFormation의 선언 상태가 자동으로 따라오지 않는다는 점이다.

원문은 세 실패 방식을 구분한다. 첫째, 확장 대상을 그대로 둔 채 엔드포인트를 갱신하면 업데이트 자체가 거부된다. 둘째, CLI로 대상을 수동 해제한 뒤 엔드포인트 구성만 바꾸면 갱신은 성공하지만 CloudFormation 템플릿의 자동 확장 설정은 바뀌지 않았으므로 재등록을 실행하지 않는다. 이 경우 성공으로 보이는 배포 뒤에 자동 확장이 없는 엔드포인트가 남는다. 셋째, 수동 해제 후 자동 확장 매개변수까지 바꿔 배포하면 CloudFormation은 사라진 ScalableTarget 리소스를 업데이트하려다 못 찾는다. 롤백까지 실패해 스택이 UPDATE_ROLLBACK_FAILED 상태가 될 수 있다. 막힌 배포와 조용히 손상된 배포 중 후자가 더 늦게 발견될 수 있다는 점이 중요하다.

서비스 관점에서 이 문제는 고객의 정상 요청이 몰리는 시간에 드러난다. 배포 직후엔 트래픽이 적어 고정 인스턴스 하나로 버틸 수 있다. 야간에 엔드포인트를 교체하고 테스트 한 번이 성공했다고 출시해도, 다음 날 사용자 증가에 대응할 정책이 사라졌다면 p95 지연과 5xx가 갑자기 증가한다. 모델의 추론 품질은 전혀 변하지 않았는데 사용자는 서비스를 못 쓴다. 따라서 릴리스 검증의 완료 조건은 HTTP 응답 하나와 CloudFormation UPDATE_COMPLETE만이 아니다. 실제 scalable target과 scaling policy가 기대하는 리소스 ID, 최소·최대 용량, 대상 지표, cooldown을 갖고 존재하는지를 조회해야 한다.

커스텀 리소스로 순서를 명시하다

AWS 샘플 CDK construct는 CloudFormation의 기본 ScalableTarget 및 ScalingPolicy 선언 대신 세 개의 커스텀 리소스를 사용한다. 먼저 Deregister가 기존 확장 대상을 제거한다. 처음 배포라 대상이 없으면 ‘없음’을 정상 경로로 취급한다. 다음으로 CDK가 엔드포인트 구성을 갱신한다. 그 후 Register Scalable Target이 엔드포인트가 InService가 될 때까지 기다린 뒤 대상을 다시 등록한다. 마지막 Attach Scaling Policy는 대상이 조회 가능해질 때까지 기다린 다음 정책을 붙인다. 코드의 node.add_dependency로 실행 순서를 강제하고, 엔드포인트와 자동 확장 매개변수를 함께 넣은 ConfigHash가 변경 때 커스텀 리소스를 다시 호출하도록 한다.

엔드포인트 API가 갱신 요청을 받았다고 즉시 새 인스턴스가 InService인 것은 아니다. 이 시간차 때문에 단일 Lambda 호출 안에서 무작정 기다리면 실행 제한과 재시도 문제가 생긴다. 샘플은 CDK provider의 비동기 완료 패턴을 사용한다. on_event는 시작만 하고, is_complete가 약 30초 간격으로 상태를 확인한다. 확장 대상 재등록 단계는 총 1시간, 정책 부착 단계는 총 15분의 대기 한도를 둔다. 이것은 코드의 작은 구현 세부라기보다 클라우드 제어 평면의 결국 일관적 상태를 배포 그래프에 반영한 것이다. 어떤 자원은 ‘생성 API가 성공’과 ‘이후 API에서 조회 가능’ 사이에 시차가 있다. 배포가 그 시차를 무시하면 작은 테스트 계정에서는 우연히 통과하고 규모가 큰 환경에서 자주 실패할 수 있다.

보조 리소스의 수는 눈여겨봐야 한다. 논리적으로는 세 개의 커스텀 리소스지만, 원문에 따르면 배포된 스택에는 Lambda 12개와 Step Functions 상태 머신 2개가 들어간다. 다섯 개는 샘플의 직접 작성한 핸들러이고 나머지는 provider 프레임워크가 만든다. 하나의 배포 문제를 풀기 위해 운영 구성 요소가 늘어난 셈이다. 이것이 곧 샘플이 나쁘다는 뜻은 아니다. 실패를 드러내고 복구 가능한 순서로 만드는 대가다. 다만 보안팀은 새 역할과 Lambda 권한을, 운영팀은 Step Functions 실패 및 비용을, 배포팀은 커스텀 리소스 삭제·롤백 동작을 검토해야 한다. 인프라 코드 몇 줄이 실제 클라우드 자원 몇 개인지 배포 결과로 확인한다.

ConfigHash와 멱등성: 배포를 반복했을 때 같은 상태인가

샘플은 엔드포인트 구성과 확장 설정을 하나의 ConfigHash에 담는다. 이 값이 바뀌면 해제·갱신·재등록 순서를 다시 실행한다. 모델 이미지가 바뀌는데 hash에서 이미지 태그를 빠뜨리면 필요한 갱신이 트리거되지 않을 수 있고, 반대로 의미 없는 값을 hash에 넣으면 불필요한 확장 중단이 반복될 수 있다. 프로덕션에서는 이미지 태그 자체보다 불변 digest나 버전을 포함해야 배포한 모델의 정확한 상태를 알 수 있다. Bayer 사례에서도 변경 가능한 이미지 태그가 출시 위험으로 발견됐다. 두 발표는 다른 제품을 다루지만, 선언형 배포가 신뢰할 수 있으려면 변경의 정체성을 불변값으로 기록해야 한다는 공통점이 있다.

자동화된 배포는 실패 후 재실행된다. 따라서 해제 작업은 대상이 이미 없을 때 정상 종료해야 하고, 재등록 작업은 같은 요청을 두 번 받더라도 기대한 최종 상태로 수렴해야 한다. 정책 부착은 대상이 보이기 전과 후에 다른 결과를 내는 것이 정상이다. 커스텀 리소스의 Create·Update·Delete 경로를 각각 시험하고, 중간에 실패했을 때 현재 엔드포인트가 구형·신형 중 어느 버전인지, 확장 대상이 있는지, 정책이 붙었는지 조회할 수 있어야 한다. 멱등성은 함수가 같은 입력에서 항상 같은 로그를 찍는다는 뜻이 아니라, 재시도해도 업무상 최종 상태가 중복·누락 없이 수렴한다는 뜻이다.

특히 Deregister와 Register 사이에는 의도적으로 자동 확장이 없는 창이 생긴다. 그 기간에 트래픽이 급증한다면 기존 인스턴스의 여유가 필요하다. 중요한 엔드포인트는 배포 시간, 이전 엔드포인트의 유지, 새 인스턴스의 warm-up, 트래픽 전환 전략을 함께 설계한다. 샘플이 순서를 안전하게 자동화한다고 해서 무중단·무용량 위험까지 보장하지는 않는다. 실제 지표가 target_value: 100인 예시를 복사해도 모델의 동시성, GPU 메모리, 배치 처리 방식, cold start에 맞지 않을 수 있다. 확장 정책의 지표와 cooldown은 실서비스의 트래픽 패턴으로 정해야 한다.

배포 후 검증을 별도 게이트로 만들기

원문 샘플은 describe-scalable-targets와 describe-scaling-policies로 대상과 정책을 확인한다. 이를 수동 체크리스트 한 줄로만 남기면 어느 날 빠진다. 배포 파이프라인에 기계적으로 넣는 것이 낫다. 첫째, 변경 전후의 모델 이미지 digest와 endpoint config 이름을 기록한다. 둘째, 배포 후 엔드포인트가 InService가 될 때까지 제한 시간을 둔다. 셋째, 실제 scalable target의 리소스 ID와 최소·최대 용량을 선언값과 비교한다. 넷째, scaling policy의 대상 지표와 cooldown이 기대값인지 확인한다. 다섯째, 테스트 트래픽에서 최소한의 요청 품질과 지연을 확인한다. 여섯째, 이 중 하나라도 실패하면 새 모델의 트래픽 확대를 중단하고 복구 절차를 실행한다. 외부 API가 성공했다고 고객 영향이 없다는 결론을 내리지 않는다.

실제 확장 동작을 확인하는 부하 시험은 가벼운 smoke test와 다르다. 목표 지표를 넘어서는 부하를 일정 시간 발생시켜 새 인스턴스가 등록되는지 봐야 한다. 그러나 프로덕션에 무제한 테스트 트래픽을 넣으면 기존 고객에게 영향을 준다. 사전 환경에서 확장 정책의 동작을 시험하고, 프로덕션에서는 리소스 존재·알람·용량 상한을 우선 검증하는 계층적 전략이 합리적이다. 강제 확장 시험이 필요한 경우 사전에 팀과 시간대를 맞추고 비용·사용자 영향 한도를 정한다. 오늘의 발표는 배포 자동화 예시이지 특정 조직의 재해 복구 계약까지 정의하지 않는다.

이 사례가 일반 웹앱에도 적용되는 이유

SageMaker가 아닌 Kubernetes HPA, 서버리스 concurrency 설정, DB 읽기 복제본, CDN 캐시, 메시지 큐 소비자 수에서도 구성 갱신과 확장 정책의 생명주기가 어긋날 수 있다. 공통 패턴은 서로 다른 제어 평면이 같은 리소스의 현재 상태를 각자 관리한다는 점이다. 선언형 도구는 자신이 아는 상태만 조정한다. 운영자가 콘솔·CLI로 수동 변경하면 선언과 실제 상태가 갈라진다. 그 차이는 다음 배포에서 오류로 터질 수도 있고, 조용히 유지될 수도 있다. 따라서 중요한 배포는 템플릿 검사만으로 끝내지 말고 API를 통해 실제 상태를 읽어 원하는 상태와 비교해야 한다.

인사시스템을 예로 들면 급여 마감일에 AI 상담 엔드포인트를 교체했는데 확장 설정이 풀리는 순간, 직원의 단순 문의가 지연될 뿐 아니라 운영자의 장애 대응이 급여 처리 업무와 충돌한다. 기능 개발자는 모델 응답 품질에만 관심을 두고 인프라 담당자는 CDK 성공 여부만 보면 이 실패는 소유자가 없다. 릴리스 문서에 ‘성공한 사용자 여정’과 ‘성공한 인프라 조건’을 동시에 적고, 누가 그 증거를 확인하는지 지정해야 한다. 좋은 배포는 명령이 끝난 배포가 아니라 실제 서비스 계약이 계속 지켜지는 배포다.

네 발표를 하나의 시스템으로 읽는 여섯 가지 질문

1) 무엇이 정답인가: 평가의 종료 조건을 먼저 정한다

Wordle은 6회 안에 단어를 맞히면 끝난다. 코드 문제는 단위 테스트를 통과하면 끝난다. Bayer의 질문은 원인과 근거를 사용자에게 전달했을 때 끝난다고 주장할 수 있지만, 그 답이 실제 워크플로 상태와 맞는지 확인해야 한다. 엔드포인트 배포는 CDK 작업이 완료됐을 때가 아니라 실제 요청과 자동 확장이 정상일 때 끝난다. 이 네 개의 ‘완료’는 서로 다른 단위다. 제품팀은 모델 응답 완성, 도구 호출 성공, 데이터베이스 최종 상태, 사용자의 업무 완료 중 어느 것을 최종 정답으로 삼는지 명시해야 한다. 여러 단계 업무는 중간 단계별 성공이 모두 참이어도 전체 결과가 실패할 수 있다.

특히 평가 기준은 모델에게 보여줄 수 있는 정보와 분리해야 한다. 평가의 정답이 프롬프트에 들어가면 숫자는 높아지지만 시스템은 아무것도 배운 것이 없다. 데이터베이스 값을 변경하는 작업이면 성공을 에이전트의 자기 보고가 아니라 변경 후 상태로 판정한다. 권한이 없는 자료가 답에 나타나면 유창한 설명이어도 실패다. 특정 사용자 질문을 잘 답했더라도 해당 답을 도출한 도구의 감사 기록이 누락되면 규제 업무에서는 불완전하다. 이 종료 조건을 수치화하지 못한다면 강화학습보다 업무 흐름 분석이 먼저다.

2) 누가 무엇을 소유하는가: 추상화 아래의 책임을 적는다

MTRL 서비스는 정책 학습을 조정하지만 고객은 에이전트 환경과 보상을 만든다. 훈련 세션 API는 GPU 연산을 실행하지만 루프의 의미를 결정하지 않는다. AgentCore는 런타임 격리와 도구 접근을 돕지만 Bayer는 도구별 권한, 세션 지속 상태, 태스크 실패를 설계했다. CDK는 CloudFormation 자원을 만들지만 SageMaker 엔드포인트와 Application Auto Scaling의 업데이트 순서를 사용자 construct가 다뤄야 했다. 어떤 서비스가 ‘관리형’이라고 불리더라도 업무 정답, 접근 권한, 롤백 조건, 고객 영향은 사라지지 않는다.

이를 책임 매트릭스로 표현하면 도움이 된다. 데이터팀은 훈련·평가 분할과 자료 출처를, ML팀은 보상·학습률·정책 최신성을, 앱팀은 도구 의미와 응답 검증을, 보안팀은 사용자·서비스·도구 경계를, 플랫폼팀은 배포·확장 상태를, 제품 책임자는 실제 업무 성공의 기준을 맡는다. 한 사람이나 팀이 여러 칸을 소유할 수 있으나 빈 칸을 두면 안 된다. 공급자 문서가 어떤 기능을 제공한다는 사실과 우리 조직에서 그 기능의 운영 책임자가 있다는 사실은 다르다.

3) 무엇을 로그로 남길 것인가: 재현 가능한 사건 단위를 만든다

멀티턴 학습에서는 한 에피소드의 과제 ID, 모델·어댑터 버전, sampling 설정, 도구 호출, 보상 세부 항목이 필요하다. 훈련 세션에서는 각 단계의 데이터 스냅샷, policy 버전, advantage, 토큰 사용, checkpoint가 필요하다. ADE에서는 사용자와 권한 문맥, 감독자의 라우팅, 전문가의 조회 출처, 도구 오류, 캐시 적중, 최종 답의 근거가 필요하다. 배포에서는 엔드포인트 구성과 실제 확장 정책의 전후 상태가 필요하다. 공통 요구는 나중에 왜 이 결과가 나왔는지 복원 가능한 식별자와 버전이다.

그러나 로그에 민감한 원문을 모두 쌓으면 다른 문제가 생긴다. 사용자 질문, 내부 문서, 비밀 토큰, 모델의 숨은 생각이나 정책 정보가 장기간 보관될 수 있다. 관측과 기밀성 사이에서 목적별 보존 기간과 마스킹을 정한다. 과제 ID와 해시, 주요 단계의 상태 코드, 데이터셋 버전만으로 진단 가능한 경우는 원문 대신 그 값을 남긴다. 디버깅 목적으로 원문 샘플을 수집할 때는 접근자와 만료 시각을 제한한다. ‘모든 것을 로그로 남긴다’와 ‘사건을 재현할 수 있다’는 같은 말이 아니다.

4) 비용을 무엇으로 나눌 것인가: 단가보다 완료 과제당 총비용

MTRL의 339달러는 훈련 토큰만의 가격이다. 훈련 세션 API의 토큰 요금은 GPU 처리 부분을 설명한다. ADE의 요청당 비용은 감독자·전문가·도구·검색·캐시를 합쳐야 하고, 엔드포인트는 평균 요청당 비용 외에 피크 인스턴스와 최소 용량 유지비가 있다. 이 수치를 각각 별도 그래프에 두면 의사결정이 쉽지 않다. 조직의 최종 분모를 정확히 완료된 업무 한 건으로 정해 합산해야 한다. 실패 후 재시도, 사람이 검토한 시간, 잘못된 답을 정정한 시간, 장애 복구비까지 포함한다.

예를 들어 모델을 더 훈련시켜 추론 호출 수를 줄였어도 학습 준비가 오래 걸리고 모델 갱신이 잦다면 총비용은 늘 수 있다. 에이전트 전문가를 늘려 정확도를 높였어도 라우팅과 도구 호출이 길어져 응답 시간이 업무 한도를 넘으면 가치가 줄어든다. 자동 확장을 쓰며 최저 용량을 너무 높게 잡으면 피크에는 안전해도 평상시 비용이 늘고, 너무 낮게 잡으면 cold start가 사용자 경험을 해친다. 비용 표에는 베이스라인, 개선 후, 오류율·지연·운영 인력·피크 비용을 같은 기간으로 맞춰 넣는다.

5) 무엇을 되돌릴 것인가: 모델·상태·정책을 별도로 복구한다

모델 품질이 떨어지면 이전 어댑터나 모델 패키지로 돌아갈 수 있어야 한다. 그러나 보상 코드가 잘못돼 학습 데이터를 오염시켰다면 모델 롤백만으로 평가 체계가 고쳐지지 않는다. 에이전트가 잘못된 근거를 캐시에 넣었다면 프롬프트를 고쳐도 오래된 응답이 남을 수 있다. IAM 정책이 바뀐 뒤 체크포인트를 복구한다면 과거 권한 문맥을 다시 검증해야 한다. 엔드포인트의 이미지가 이전 것으로 돌아가더라도 확장 정책이 사라졌다면 롤백은 불완전하다. 복구 대상이 모델, 데이터, 세션, 캐시, 도구 권한, 인프라 중 무엇인지 사건별로 분리한다.

롤백은 배포 실패 후에 처음 써보면 늦다. 사전 환경에서 중간 단계 실패를 주입한다. 예를 들어 엔드포인트가 Failed가 되면 scalable target이 어떤 상태로 남는지, ADE의 전문가가 타임아웃되면 감독자가 어떤 답을 보내는지, MTRL의 보상 서비스가 한 롤아웃에서 실패하면 전체 작업을 중단하는지, 학습 세션 도중 프로세스가 죽으면 어떤 checkpoint에서 재개하는지 시험한다. 사용자에게 보이는 응답에는 ‘원인을 확인하지 못했다’와 ‘정상적으로 분석을 마쳤다’를 분명히 구분한다. 실패를 숨기는 정중한 문장은 운영상 성공이 아니다.

6) 어디에서 사람의 권한을 유지하는가: 자동화 수준을 명시한다

Wordle의 보상은 자동으로 확정할 수 있지만 고객에게 지급하거나 직원 기록을 수정하는 작업은 그렇지 않다. Bayer ADE는 현재 주로 읽기 전용 설명에 집중해 업무 원본의 변경권을 CDE와 조직 절차에 남겼다. 자동 확장 정책은 인프라의 인스턴스 수를 자동으로 바꾸지만 비용 상한과 배포 승인은 사람·정책이 정한다. 개발자는 ‘에이전트가 할 수 있음’과 ‘에이전트가 해도 됨’을 두 칸으로 나눠 적어야 한다. 첫 칸은 기술 역량이고 둘째 칸은 업무 권한이다.

가능한 단계는 조회만 하는 보조, 변경안을 제시하지만 사람이 승인하는 반자동, 미리 한도가 정해진 저위험 변경의 자동 실행, 모든 변경의 자동 실행으로 나뉜다. 단계가 올라갈수록 평가셋뿐 아니라 idempotency, 감사, 취소, 비정상 탐지, 비상 정지, 최종 책임자를 더 엄격히 설계해야 한다. 공개 데모에서 기술적으로 잘 된다는 이유만으로 마지막 단계로 뛰면 안 된다. 기술의 성숙도와 조직의 통제 준비는 별도의 축이다.

개발자에게 의미: 네 발표를 실제 설계 선택으로 옮기는 방법

먼저 문제가 ‘학습’ 문제인지 구분한다

에이전트의 답이 좋지 않을 때 팀은 곧바로 미세조정을 떠올리기 쉽다. 그러나 실패를 적어 보면 모델 지식 부족이 아니라 도구 호출 타임아웃, 검색 인덱스의 오래된 문서, 인증 스코프 누락, 사용자 질문의 모호성, 후단 API의 불안정, 잘못된 성공 판정이 원인일 수 있다. 이런 문제에는 MTRL이나 세션 API를 도입해도 근본 해결이 되지 않는다. 학습을 검토하기 전에 실제 실패 과제를 모으고 원인을 최소 다섯 범주로 나눈다. 입력 정보 부족, 도구 선택·호출 오류, 모델 추론 오류, 실행 환경·권한 오류, 평가 판정 오류다. 범주마다 해결책이 다르다.

입력 정보가 부족하다면 검색 품질과 데이터 갱신 주기를 고친다. 도구 선택이 흔들리면 도구 이름·설명과 전문가별 카탈로그 범위를 정리한다. 모델이 피드백을 읽고도 반복해서 같은 실패 행동을 한다면 학습 데이터나 RL이 가치 있을 수 있다. 실행 환경이 불안정하면 타임아웃·재시도·인증을 고친다. 평가 판정이 틀리면 어떤 훈련도 신뢰할 수 없다. Wordle 사례에서도 보상 역전이 있었고, Bayer 사례에서도 HTTP 성공이 업무 실패를 가렸다. 둘 다 모델의 본질적 역량 문제가 아니라 측정 계약의 결함이었다.

새 기능 도입 전에 팀이 만들 첫 문서는 수십 페이지의 AI 전략이 아니라 실패 사례 표다. 각 행에는 과제 ID, 실제 입력, 기대한 최종 상태, 당시 관측된 상태, 사용한 데이터와 도구, 잘못됐을 때의 피해, 복구 방법을 적는다. 30~50개만 모아도 어떤 오류가 반복되는지 보인다. 이후 규칙·검색·프롬프트·도구 수정을 먼저 비교하고, 그로도 남는 재현 가능한 행동 오류에 모델 맞춤화를 적용한다. 학습이 필요한 이유를 ‘다른 방법으로 해결할 수 없는 반복 실패’로 좁히면 실험의 성공 기준과 예산도 선명해진다.

모델 맞춤화의 선택 나무

첫 번째 질문은 정답 출력이 있는가다. 입력과 기대 출력이 신뢰할 수 있게 모인다면 지도 미세조정이나 선택 기반 선호 최적화로 시작할 수 있다. 정답 경로는 여러 개지만 최종 상태를 기계적으로 확인할 수 있다면 에피소드 기반 RL이 후보가 된다. 예를 들어 고객 문의를 어느 팀으로 라우팅해야 하는지 이미 라벨이 있다면 먼저 분류 평가를 만들 수 있다. 반면 에이전트가 여러 부서 시스템을 돌아 최종적으로 한 건의 실물 문제를 해결하는 업무에서는 중간 행동의 완전한 정답 경로가 없을 수 있다.

두 번째 질문은 학습 알고리즘을 직접 제어해야 하는가다. 데이터와 보상만 주면 되는 수준이면 MTRL 관리형 작업을 검토할 수 있다. 보상 방정식뿐 아니라 단계마다 데이터 난도를 바꾸거나, 모델 출력 여러 개에 자체 advantage 계산을 적용하거나, 새 손실 함수를 시험해야 한다면 훈련 세션 API가 맞다. 이미 특정 GPU 런타임·분산 학습 라이브러리·커널에 의존한다면 Training Jobs 또는 HyperPod 같은 다른 경로가 필요할 수 있다. 세 선택지의 이름만 비교하지 말고 필요한 제어 수준, 개발팀이 소유할 장애면, 현재 지원 모델·리전을 표로 비교한다.

세 번째 질문은 결과를 어떻게 검증할 수 있는가다. Wordle은 별도 비밀 단어를 뽑을 수 있지만, 기업의 실제 업무는 계절 변화·정책 개정·고객군 이동을 겪는다. 오늘의 홀드아웃 데이터가 다음 달 업무를 대표하지 않을 수 있다. 같은 고객의 유사한 티켓을 훈련과 평가에 나눠 담으면 독립 과제로 보기 어렵다. 평가 분할은 날짜·고객·업무 유형 또는 조직 단위로 해, 미래에 처음 보는 사례에 가까워지게 한다. 모델 한 번의 성공 외에 반복 실행 안정성과 치명적 부수효과를 측정한다.

네 번째 질문은 결과가 상태를 바꾸는가다. 읽기 전용 진단 에이전트는 잘못된 설명을 할 수 있지만, 적어도 도구를 통한 직접 데이터 변경은 막을 수 있다. 지급, 삭제, 권한 부여, 근무 기록 수정처럼 되돌리기 어렵거나 감사가 필요한 작업은 모델의 출력이 정책 엔진과 사람의 승인 앞에 제안으로 머물도록 설계한다. 학습으로 도구 호출이 더 정확해져도 운영 권한을 자동으로 늘리지 않는다. 모델 맞춤화는 실행 정책을 대체하지 않는다.

도구를 설계할 때: 호출의 의미를 작고 검증 가능하게

Bayer 사례의 전문가별 도구 제한은 다양한 조직에서 적용할 수 있다. 도구가 너무 광범위하면 모델이 잘못된 입력을 줬을 때 피해가 커진다. 반대로 지나치게 작게 쪼개면 한 질문에 호출 수가 늘어 비용·지연·상태 불일치 가능성이 높아진다. 적절한 도구는 업무상 의미 있는 한 동작과 명확한 입력·출력·오류 코드를 가진다. 예컨대 get_workflow_status(workflow_id)는 대상과 결과가 비교적 뚜렷하다. execute_any_sql(query)는 권한과 비용의 경계가 너무 넓다. search_everything(query)는 결과의 출처·최신성·접근 권한이 불투명해지기 쉽다.

도구 스키마에는 필수 값, 허용 범위, 사용자 권한이 필요한 위치, idempotency 규칙, 시간 제한, 반환값의 출처·시각을 명시한다. 입력 검증은 모델 프롬프트가 아니라 백엔드에서 한다. 모델이 user_id를 만들어 넣더라도 서버는 그 ID가 현재 사용자의 범위에 있는지 재검증해야 한다. 도구가 특정 오류를 반환하면 에이전트는 정상 경로로 꾸미지 말고 사용자에게 현재 확인하지 못했다는 사실을 전달해야 한다. 접근 거부, 존재하지 않는 항목, 일시적인 타임아웃은 서로 다른 후속 조치가 필요하다.

도구 응답을 모델에 그대로 던지는 것도 위험할 수 있다. 수천 행의 로그, 긴 HTML 오류 페이지, 문서 전체를 넣으면 비용과 문맥 압박이 증가한다. 오류 원인 파악에 필요한 구조화 필드만 추리고, 원본을 참조할 수 있는 감사 ID를 함께 둔다. 검색 결과라면 문서 제목뿐 아니라 버전·게시 시각·권한·관련 구절을 보낸다. 에이전트가 답의 근거를 제시할 수 있도록 도구 출력 자체가 인용 가능한 형태여야 한다. 모델이 마지막 문장에서 출처를 만든 뒤 붙이게 하면 존재하지 않는 문서나 잘못된 판본이 나타날 수 있다.

학습 데이터와 실행 데이터의 경계를 세운다

MTRL 예제의 answer는 에이전트 환경의 정답으로만 사용한다. 코드 RL의 유닛 테스트도 평가기의 일부다. 이 구조를 기업 업무로 옮기면 승인 후의 실제 정산 결과, 내부 수동 교정 내용, 사용자가 볼 권한이 없는 정책 예외 등 매우 민감한 정답 자료가 생긴다. 보상 서비스와 정책 모델 사이에 역할과 네트워크 경계를 두고, 학습 로그가 두 자료를 함께 덤프하지 않는지 확인해야 한다. 데이터세트 파일 하나에 정답과 프롬프트가 함께 들어 있더라도 실행 시 모델에게 건네는 필드가 무엇인지 코드 수준에서 검증한다.

검증 데이터는 학습 과정의 반복 의사결정에도 쉽게 새어 들어간다. 매 실험마다 같은 128문제를 보고 보상 함수·프롬프트·하이퍼파라미터를 조정하면 모델 가중치가 직접 그 데이터를 보지 않아도 팀이 검증 세트에 과적합한다. 따라서 개발용 검증 세트와 릴리스용 봉인 세트를 구분한다. 릴리스 평가에는 정해진 횟수만 접근하고, 결과를 본 뒤 조정했다면 다음 봉인 세트를 만든다. 고비용 실무에서는 샘플 수가 작아도 평가와 학습 의사결정의 시간 순서를 기록하는 것이 중요하다.

프롬프트와 보상 사이의 충돌을 살핀다

보상은 결과의 숫자지만 프롬프트는 모델의 행동 범위를 설명한다. 둘이 다르면 모델은 보상에 맞춰 지시를 우회할 수 있다. ‘모든 고위험 문의는 사람에게 넘겨라’는 시스템 지시를 주고, 사람에게 넘기면 해결률이 낮다고 보상에서 벌점을 준다면 모델은 위험 문의도 억지로 답하도록 압박받는다. ‘사용자에게 확인 질문을 하라’고 지시하면서 대화 턴 수가 적을수록 무조건 보상이 높으면 확인을 건너뛸 유인이 생긴다. 보상 설계 회의에는 모델 연구자뿐 아니라 제품 책임자와 보안·업무 담당자가 참여해야 한다. 지시·정책·보상이 같은 순서를 선호하는지 예시 과제로 확인한다.

Wordle의 shaping 항은 사용 가능한 힌트를 존중하는 전략을 돕지만, 결과보다 작도록 제한되어 있다. 기업 업무에서는 비슷하게 ‘근거를 제시했다’, ‘도구 오류를 사용자에게 설명했다’ 같은 품질 항을 추가할 수 있다. 그러나 근거가 틀렸는데 형식만 채우면 높은 점수를 받는 보상은 위험하다. 출처가 실제 도구 결과의 ID와 연결되는지 기계적으로 검증할 수 있어야 한다. 사람이 읽고 ‘그럴듯하다’고 느끼는 평가는 보조 지표로 쓸 수 있으나, 외부 기록과 모순되는 최종 상태를 뒤집는 근거가 될 수 없다.

운영 포인트: 단계별 게이트와 반드시 보아야 할 신호

게이트 A — 과제 정의와 데이터 무결성

첫 단계의 산출물은 평가 과제 명세다. 과제마다 시작 상태, 허용된 도구, 성공 최종 상태, 실패 시 허용 가능한 상태, 절대로 바뀌면 안 되는 데이터, 사용자 권한을 적는다. 여러 턴을 허용하는 이유도 적는다. 한 번의 검색으로 끝나는 질문에 굳이 멀티턴 RL을 붙이면 도구와 비용이 늘어날 뿐이다. 성공률을 비교할 베이스라인에는 현재 사람이 수행하는 절차, 기존 규칙, 기존 RAG 또는 기존 모델을 포함한다. 특정 공급자의 새 API만 평가하고 대조군을 없애면 개선이 실제로 얼마인지 알 수 없다.

데이터 누출 검사는 파일 단위와 런타임 단위 모두 필요하다. 파일에 정답이 있다면 환경 코드만 읽는지, 로깅이 프롬프트를 통째로 찍으면서 정답을 섞지 않는지, 에이전트의 도구 목록에 정답 데이터베이스가 우연히 노출되지 않는지 확인한다. 사용자별 비공개 자료는 학습·평가에 쓰기 전에 이용 권한과 보존 기간을 정한다. 제품 로그에서 자동으로 모은 사용자 문장은 테스트 과정에서 재생산되거나 모델 아티팩트에 영향을 줄 수 있으므로 무심코 학습 데이터로 옮기지 않는다.

게이트 B — 보상과 오류 계약

보상 함수를 실제 훈련 전에 독립적으로 실행해 결과 표를 만든다. 성공·부분 성공·검증 실패·시간 초과·권한 거부·무응답·중복 변경·금지된 도구 호출을 모두 넣는다. 중요도 순서가 점수의 대소와 일치해야 한다. Wordle 실습의 역전처럼 ‘빠른 성공보다 느린 성공이 높다’는 오류는 모델이 열심히 학습할수록 더 나빠진다. 각 항목의 상한·하한을 공개하고, shaping 항이 결과 항의 경계를 넘지 못하게 한다. 보상 계산이 실패했을 때 0점을 반환할지 작업을 중지할지도 명시한다. 실패한 판정기를 조용히 0점으로 처리하면 대량의 잘못된 학습 신호가 생길 수 있다.

기술적 실패와 업무 실패를 따로 분류한다. 모델이 잘못된 판단을 한 것은 학습의 신호가 될 수 있지만, 정책 엔드포인트가 인증 오류로 한 번도 호출되지 않았다면 모델의 학습 품질을 평가할 수 없다. 부하 때문에 도구 호출이 타임아웃된 경우도 사업 로직의 실패처럼 보상을 주기보다 환경의 신뢰성을 먼저 고쳐야 한다. 반대로 실제 운영에서 타임아웃 대응이 에이전트의 업무 능력이라면, 그 상황을 별도 과제와 보상으로 설계할 수 있다. 핵심은 의도한 학습 목표와 인프라 사고를 섞지 않는 것이다.

게이트 C — 모델·도구 인터페이스의 호환성

새 모델·어댑터를 적용하기 전에 도구 호출 스키마와 구조화 출력을 검증한다. 필수 필드가 빠졌을 때 거부하는지, enum 밖의 값을 만드는지, tool call을 일반 텍스트로 출력하는지, 잘못된 순서로 두 도구를 호출하는지, 긴 응답 뒤에도 최종 JSON이 유효한지 본다. Bayer가 reasoning mode가 있는 새 모델을 바로 적용하지 않은 이유가 여기에 있다. 모델의 벤치마크 성능이 올라도, 실제 에이전트가 의존하는 조합이 깨지면 릴리스할 수 없다. 인터페이스 시험은 모델 버전뿐 아니라 SDK 버전, 도구 명세 버전, decoding 설정을 묶어 기록한다.

특히 훈련 전후 비교에는 서빙 설정을 고정해야 한다. MTRL 사례의 훈련 중 검증과 최종 실서비스 설정이 크게 달랐다. 낮은 effort와 중간 effort, temperature 0과 1.0은 서로 다른 제품 동작이다. 두 모델을 비교하면서 한쪽만 더 긴 토큰 한도나 다른 도구 시간 제한을 주면 성능 차이를 해석할 수 없다. 평가 표에는 베이스 모델·훈련 모델 × 설정 × 과제 유형을 별도로 적는다. 전체 평균 하나로 합치지 않는다. 성공이 높아져도 실패한 과제의 심각도가 커지면 배포 보류 사유가 된다.

게이트 D — 세션·권한·출처

에이전트가 여러 턴을 쓰면 한 사용자 세션의 자료가 다른 세션에 섞이지 않아야 한다. 사용자별 권한이 바뀐 뒤 저장된 체크포인트를 복구할 때는 최신 권한을 다시 확인한다. Gateway가 서비스 간 인증을 처리해도 도구의 비즈니스 권한은 별도로 검증한다. 전문가별 역할은 작게 주고, 읽기 도구도 민감도를 분류한다. 문서 검색 결과가 허용된 자료인지, 인용이 실제 검색 결과와 일치하는지, 출처 문서가 최신인지 관측한다. 답이 틀렸는데 도구 호출은 모두 성공했다면 태스크 성공률이 떨어져야 한다.

캐시는 지연과 비용을 줄이지만 권한·최신성의 경계를 바꾼다. Bayer는 ElastiCache에 TTL을 둔다. 업무 앱에서 캐시 키가 질문 문자열만이라면 다른 사용자의 답이 섞일 수 있다. 사용자 역할, 테넌트, 데이터 버전, 정책 판본이 응답의 의미에 영향을 준다면 키 또는 캐시 계층에 반영해야 한다. 모든 값을 키에 넣으면 적중률이 떨어질 수 있으므로 데이터 종류별로 공유 가능한 결과와 사용자별 결과를 분리한다. 권한이나 데이터가 바뀌었을 때 즉시 무효화할 것인지, 일정 TTL의 지연을 업무상 허용할 것인지 명세한다.

게이트 E — 배포·확장·관측

추론 엔드포인트 배포의 완료 조건은 컨테이너가 뜬 것만이 아니다. 실제 모델 버전, 인스턴스 유형, 최소·최대 용량, 확장 정책, 주요 CloudWatch 알람, 도구 후단 접근성을 비교한다. CloudFormation 또는 CDK와 콘솔의 수동 변경을 혼합했다면 drift를 확인한다. 자동 확장 대상이 없는 성공 배포는 가능한 실제 실패 유형이므로 API 조회를 게이트에 넣는다. 신규 모델의 응답이 더 느리면 같은 요청률에서도 필요한 인스턴스가 늘어난다. 모델 품질 평가와 별개로 부하 시험을 반복해야 한다.

관측 지표는 최소 네 층으로 나누는 편이 좋다. 인프라에는 CPU/GPU·메모리·동시성·확장 이벤트·오류율, 모델에는 토큰·지연·형식 위반·모델 버전, 에이전트에는 도구 선택·재시도·라쳇된 상태·세션 복구, 업무에는 실제 해결·사람 이관·오답 정정·사용자 재질문이 들어간다. 상위 층이 실패했는데 하위 층이 정상일 수 있다. ADE의 HTTP 성공 오인 사례가 대표적이다. 알람은 무엇을 감지하는지와 누가 조치할지를 함께 써야 한다. 숫자만 많고 소유자가 없는 대시보드는 사고 대응을 개선하지 않는다.

게이트 F — 비용·안전·릴리스 판단

파일럿에서 비용을 줄였는지는 요청당 토큰이 아니라 정확히 해결된 업무 1건당 총비용으로 본다. 추론 호출, 도구 API, 검색, 저장, 캐시, 훈련, 평가, 인프라, 사람 검토, 오류 정정의 합을 같은 기간과 같은 업무군에서 비교한다. 주말과 월말, 신입 직원과 숙련 직원, 단순 질문과 고위험 질문의 분포가 다르면 세그먼트별 표가 필요하다. 공급자 발표의 Wordle 84%, Bayer 80%, Code RL 50.5%는 서로 분모가 달라 한 그래프에 찍을 수 없다. 각 수치는 원문 사례의 상황 안에서만 읽는다.

최종 릴리스 결정에는 수치 외의 절대 조건을 둔다. 금지된 자료 노출 0건, 승인 없는 쓰기 0건, 되돌릴 수 없는 중복 변경 0건 같은 조건은 평균 성공률이 높아도 양보하기 어렵다. 반면 일부 저위험 답변의 말투 차이는 출시를 막기보다 관찰하며 개선할 수 있다. 조직의 위험도를 나누고, 어느 오류가 차단 기준인지 미리 정한다. 사람에게 넘기는 경로는 실패로만 세지 않는다. 고위험 과제에서 확신 없는 모델이 정확하게 이관했다면 그것도 설계된 성공일 수 있다. 성공과 자동화율을 동일시하지 않는 것이 중요하다.

적용 사례: 내부 인사 질의 에이전트를 만든다면 어디에 이 뉴스를 쓸까

다음은 네 발표의 원칙을 한 업무에 옮긴 설계 예시다. Bayer가 인사시스템을 만들었다는 뜻도, AWS 사례의 수치가 여기서 재현된다는 뜻도 아니다. 회사의 직원이 “지난달 초과근무 6시간이 왜 급여에 반영되지 않았나요?”라고 묻는 상황을 가정한다. 정답을 내려면 근태 승인, 급여 마감 시각, 수당 정책의 적용 버전, 직원의 소속과 고용 형태, 실제 급여 항목을 확인해야 할 수 있다. 직원은 자기 자료만 볼 수 있고, 어떤 정보는 담당 인사 관리자만 볼 수 있다. 에이전트가 친절한 답을 만드는 것보다 정확한 출처와 권한 범위 안에서 원인을 설명하고 필요한 경우 사람에게 이관하는 것이 목표다.

첫째, 권위 있는 시스템을 정한다. 근태 승인 원본은 근태 서비스, 급여 계산 원본은 급여 시스템, 정책의 적용 판본은 정책 저장소다. 모델의 기억이나 검색 인덱스 캐시를 원본으로 삼지 않는다. 사용자의 요청에 대해 get_overtime_approval, get_payroll_cutoff, get_policy_version, get_payslip_item 같은 제한된 도구를 만든다. 각 도구는 서버에서 본인·담당자 권한을 확인하고, 감사 ID와 조회 시각을 돌려준다. 에이전트는 이 값을 근거로 “승인은 급여 마감 다음 날 완료되어 이번 달 항목에 미반영, 다음 달 반영 예정”이라고 설명할 수 있다. 반면 도구가 세 군데에서 서로 다른 날짜를 반환하면 자신 있게 결론을 내리는 대신 불일치를 명시하고 담당자에게 넘긴다.

둘째, 업무 성공을 나눈다. 저위험 성공은 자료를 정확히 조회해 근거를 보여준 경우다. 조건부 성공은 자료가 부족하거나 모순돼 사람에게 정확한 사유와 함께 이관한 경우다. 실패는 틀린 사유를 단정하거나 다른 직원의 급여를 노출하거나, 승인되지 않은 지급 변경을 실행한 경우다. 단순한 ‘정답률’ 하나로 이 세 결과를 묶지 않는다. 모델을 학습하려면 각 사례의 실제 마감·승인·지급 상태를 판정기로 만들고, 마지막 응답 문장의 내용이 원본과 맞는지 따로 확인한다. 원문에서 Wordle의 비밀 단어를 모델에게 숨긴 것처럼, 평가의 정답 속성을 모델 입력에 넣지 않는다.

셋째, 처음 버전은 읽기 전용으로 출시한다. 질문을 분류하는 감독자와 근태·급여·정책 전문가를 분리할 수도 있지만, 실제 필요와 호출 비용을 보고 정한다. Bayer의 22개 에이전트를 규모에 상관없이 복제할 이유는 없다. 질문 유형이 다섯 개이고 도구가 여덟 개뿐이라면 하나의 제한된 에이전트와 명시적 라우팅 규칙이 더 나을 수도 있다. 전문화 여부는 도구별 권한, 평가셋, 운영 책임이 달라지는 시점에 결정한다. 감독자가 많아질수록 라우팅 오류와 토큰 비용이 늘어날 수 있다는 점을 비용 표에 반영한다.

넷째, 실제 사용자 질문을 수집해 실패 원인을 분류한다. ‘정책 판본을 착각한다’면 검색과 날짜 필터를 고친다. ‘해당 직원의 권한 밖 자료를 조회하려 한다’면 도구 권한과 모델의 선택 정책을 고친다. ‘마감 직후와 직전의 사례에서 계속 잘못 판단한다’면 그 경계 사례를 평가셋에 넣고, 충분한 사례가 모였을 때 학습을 검토한다. 이런 단계 없이 MTRL에 보상만 주면 모델이 잘못된 판정기나 불완전한 도구에 적응할 수 있다. 시스템의 책임 경계가 틀린 상황을 모델 가중치로 덮으려 하지 않는다.

다섯째, 모델 맞춤화가 필요하다는 근거가 생기면 초기 실험은 회계·급여의 실제 쓰기 권한 없이 구성한다. 과거 익명화 사례나 별도 테스트 DB에서 여러 턴을 진행하고, 정확한 사유를 찾으면 보상, 근거가 없는데 단정하면 큰 패널티, 권한 없는 조회나 변경을 시도하면 절대 실패를 준다. 사람에게 넘겨야 할 사례를 올바르게 넘긴 것도 높은 점수로 인정한다. 불필요하게 여러 도구를 돌며 같은 결과를 반복 조회하는 것은 작게 감점하되, 중요한 원본 확인보다 효율성 점수가 앞서지 않게 한다. Wordle의 보상 역전 검사를 업무 버전으로 수행한다.

여섯째, 배포할 때는 모델뿐 아니라 도구의 API 스키마와 권한 정책도 버전으로 묶는다. 새 모델이 정확한 답을 더 자주 만들더라도 get_payslip_item의 구조화 호출을 누락한다면 출시하지 않는다. 엔드포인트 자동 확장 대상과 정책이 남아 있는지 실제 API로 확인하고, 급여일 피크에 가까운 부하를 사전 환경에서 시험한다. 사용자 경험의 p95 응답 시간, 사람 이관 비율, 잘못된 권한 시도, 지원팀의 재문의 건수를 본다. 모델 성능이 좋아도 급여 마감일에 엔드포인트가 확장되지 않으면 제품은 실패한다. 이 시나리오가 네 발표를 한 흐름으로 읽어야 하는 이유다.

이 시나리오의 최소 데이터 계약

도구 응답은 사람이 읽는 자유 서술보다 구조화된 필드를 우선한다. 예컨대 근태 승인 응답에는 employee_id, period, hours, approval_status, approved_at, source_version, audit_id를 둔다. 급여 마감 응답에는 해당 기간의 cutoff_at, 적용한 정책 판본, 재계산 예정 시각을 둔다. 각 시각의 시간대를 명확히 하고, 근태 기간의 월과 지급월을 혼동하지 않도록 한다. 아시아/서울 기준 월말 23:59에 접수된 승인과 UTC 기준 이벤트 시각을 그대로 비교하면 하루가 어긋날 수 있다. 에이전트의 자연어 답이 정확해지려면 먼저 도구의 날짜 의미가 정확해야 한다.

정책 문서는 단순한 최신 문서 검색으로 충분하지 않다. 지난달 발생한 근무에는 그 당시 발효된 판본을 적용해야 할 수 있다. 검색 결과는 유효 시작·종료 시각과 적용 조직을 반환해야 한다. 새 정책이 발표됐지만 다음 달부터 적용된다면, 사용자의 사건 시점에 현재의 최신 문서를 인용하는 답은 틀리다. 이는 모델이 문서를 잘 읽는가보다 검색 도구가 시간 유효성을 지키는가의 문제다. 지식베이스에 정책 원문만 적재하고 적용 기간을 버리면 모델의 품질 개선으로 해결하기 어렵다.

민감 정보는 답을 만들 때도 최소화한다. 사용자가 자신의 급여 문의를 했다고 해서 다른 직원의 승인 패턴이나 비슷한 급여 기록이 예시로 노출되면 안 된다. 로그에는 전체 급여액보다 감사 ID와 오류 유형을 남길 수 있다. 학습 데이터로 전환할 경우 실제 직원 식별자를 제거하고, 훈련 과정의 샘플링·평가 로그에 역식별 가능 자료가 남지 않는지 검토한다. 테스트 환경의 ‘가짜’ 직원 자료도 운영 비밀과 섞이지 않게 분리한다. 정확한 업무형 AI의 출발점은 풍부한 프롬프트가 아니라 안정된 데이터 계약과 권한 경계다.

사고 대응 연습: 각 발표가 알려준 실패를 재현해 보기

연습 1 — 보상 점수는 높아지는데 사용자 경험은 나빠진다

훈련 그래프에서 평균 보상이 오르고 있어도 몇 개 롤아웃을 직접 읽는다. 성공 과제에서 불필요한 도구 호출이 늘었는지, 실패 과제가 중간 보너스를 많이 받아 높은 점수를 받는지 확인한다. 점수 항목별 합을 출력해 업무상 최악의 행동이 어떤 점수인지 표로 만든다. Wordle 원문의 첫 보상은 실패 게임이 양수, 느린 성공이 빠른 성공보다 높은 역전을 보였다. 실제 업무라면 비슷한 현상을 ‘필요 없는 확인 질문이 많아져 해결 시간이 늘어남’이나 ‘실패했지만 출처 링크를 많이 달아 고득점’ 형태로 발견할 수 있다. 즉시 학습을 멈추고 보상 순서를 수정한 후, 이전 데이터와 모델이 새 기준에서 어떤 점수를 얻는지 다시 평가한다.

여기서 중요한 것은 학습률을 먼저 바꾸지 않는 것이다. 모델이 목표를 충실히 최적화하고 있는데 목표가 잘못됐다면 하이퍼파라미터를 조정해도 근본 원인은 그대로다. 보상 판정기를 버전으로 관리하고, 어느 버전에서 만든 모델인지 명확히 기록한다. 이전 모델과 새 모델을 비교할 때는 동일한 새 판정기에서 재평가한다. 서로 다른 보상 버전의 점수 두 개를 나란히 놓고 개선률을 계산할 수 없다. 사람이 확인한 실제 업무 최종 상태를 상위 기준으로 유지한다.

연습 2 — 모델은 좋아졌는데 도구 호출이 텍스트로 나온다

MTRL 사례에서 과도한 학습률 후 모델이 도구 호출을 일반 문장으로 썼다는 보고는 에이전트의 실용성을 단번에 없애는 실패다. 테스트 환경에서 구조화된 호출이 없는 응답을 명시적으로 실패로 잡는다. 모델이 “지금 get_workflow_status를 호출하겠습니다”라고 서술만 했을 때, 런타임에서 실제 호출이 일어났는지 확인한다. 스키마 검증기는 텍스트 속의 함수 이름을 업무 결과로 취급하지 않는다. 공급자 예제의 텍스트 복구 로직은 Wordle이라는 제한된 게임에서 학습이 계속되게 하는 장치다. 민감한 업무에서는 그 문장을 파싱해 임의로 도구를 실행하는 폴백이 위험할 수 있다. 무엇을 복구할 수 있고 무엇을 거부해야 하는지 업무별로 정한다.

모델 교체나 SDK 업그레이드 때도 같은 검사를 반복한다. reasoning effort, temperature, 시스템 지시, 도구 설명 순서가 변하면 구조화 호출률이 달라질 수 있다. 인터페이스 스위트에는 정상 호출, 필수 인자 누락, 비허용 인자, 도구 오류 뒤 재시도, 사람이 검토해야 하는 상황을 포함한다. 단순히 JSON 파서가 통과했다는 사실만 보지 말고 결과가 실제 후단 시스템을 조회했는지 감사 ID로 연결한다.

연습 3 — 모든 요청이 200인데 업무 성공률이 떨어진다

Bayer가 발견한 것처럼 예외 처리기가 친절한 문장으로 오류를 감싸면 HTTP 관점의 성공률은 높다. 테스트 환경에서 전문가 하나를 강제로 타임아웃시키고 감독자와 최종 응답이 어떻게 달라지는지 본다. 사용자에게 ‘현재 해당 자료를 확인할 수 없습니다’라고 명시하고 재시도·이관 경로를 제시하면 설계된 실패다. 반면 ‘자료를 확인했고 문제없습니다’라고 답하면 치명적인 허위 성공이다. 로그에는 어떤 전문가·도구에서 실패했는지 구조화된 코드가 남아야 한다. 알람은 HTTP 5xx만이 아니라 태스크 완료율과 구조화 출력 검증 실패를 포함한다.

성공 판정기의 기준도 시험한다. 사용자가 답을 읽은 뒤 같은 질문을 반복하거나 지원팀에 재문의한 비율을 볼 수 있다. 그러나 재문의가 없다는 사실만으로 답이 맞았다고 확정해서도 안 된다. 일부 사용자는 잘못된 안내를 믿고 행동하거나 질문을 포기할 수 있다. 샘플 사례를 사람이 원본 자료와 대조하고, 고위험 질문은 별도의 품질 검토를 한다. 기술 지표와 사용자 행동 지표가 불일치할 때 둘 중 편한 하나만 선택하지 않는다.

연습 4 — 배포는 성공했는데 다음날 추론 지연이 폭증한다

CDK 배포 후 실제 scalable target과 policy를 조회하는 자동 게이트를 제거한 상태를 사전 환경에서 재현한다. 수동 해제 후 모델 구성을 바꾸면 CloudFormation 성공에도 확장 정책이 재등록되지 않을 수 있다는 AWS 사례를 확인한다. 테스트는 실제 자원을 생성·변경하므로 비용과 격리 환경을 고려해 수행한다. 이후 수정된 construct의 순서가 다시 대상과 정책을 만들고, 대상이 InService 전에는 등록을 시도하지 않는지 본다. 부하를 올렸을 때 확장 이벤트가 발생하는지 검증하고, 실패했을 때 원래 endpoint config와 정책으로 돌아가는 절차를 문서화한다.

프로덕션에선 이 사건이 모델 지연 문제처럼 보일 수 있다. 토큰 생성이 느린가, GPU가 과열됐나, 프롬프트가 길어졌나 조사하기 전에 요청 대비 인스턴스 수와 확장 이벤트가 정상인지 확인한다. 모델 품질팀과 인프라팀의 관측 대시보드가 연결돼 있어야 오진을 줄인다. 인프라 원인인데 모델을 롤백하면 사용자 지연은 남고 또 다른 위험만 생길 수 있다.

원문 수치의 분모와 해석 주의

• 61%→84%는 Wordle 홀드아웃 단어에서 중간 reasoning effort, temperature 1.0 조건으로 베이스와 훈련 모델을 비교한 해결률이다. AWS 원문은 훈련 중 temperature 0 검증이 최종 37%였다고 별도로 설명한다. 다른 디코딩 설정의 숫자를 한 실험의 전후로 섞지 않는다.
• 약 339달러는 MTRL 작업의 prefill·sample·train 토큰을 당시 특정 리전 공개 단가로 계산한 값이다. AgentCore 런타임 약 79달러는 별도다. 실패한 개발 실행·인력·보관·운영은 포함된 것으로 가정하지 않는다.
• 56%→75%는 훈련 세션 API의 작은 GSM8K 실습에서 10단계·40문제 학습 후 보고된 홀드아웃 정확도다. 모델 전체의 수학 능력이나 다른 언어·난이도에 대한 성능 보증이 아니다.
• 40%→50.5%는 cookbook의 코드 RL 사례에서 200개 별도 시험 문제로 보고된 정확도다. 코드 보안, 유지보수성, 테스트의 완전성까지 측정한 수치가 아니다.
• 질문 약 80%는 Bayer ADE의 초기 단계에서 엔지니어 개입 없이 해결됐다는 공급자·고객 공동 사례의 비율이다. 질문 유형별 분모와 장기 추적 결과는 원문만으로 확정할 수 없다.
• 입력 토큰 비용 20~30% 감소는 ADE의 반복 접두부를 캐싱했을 때 보고된 사례 효과다. 전체 요청 비용이나 모든 모델의 동일 절감률이 아니다.
• API별 통합 부담 99% 이상 감소는 Bayer가 개별 서버 대신 Gateway의 OpenAPI 기반 도구 노출을 쓴 내부 비교다. 다른 조직의 인력 절감이나 서비스 비용을 바로 뜻하지 않는다.
• Lambda 12개·Step Functions 2개는 AWS의 특정 CDK provider 샘플이 실제로 배포하는 보조 자원 수다. 모든 자동 확장 구성의 필수 개수가 아니다. 라이브러리 구현이나 샘플 개정에 따라 바뀔 수 있다.

숫자를 서로 연결해 ‘AWS에서 에이전트를 훈련하면 84%의 질문을 339달러에 자동 해결한다’ 같은 문장을 만드는 것은 오류다. Wordle 게임, 수학 벤치마크, 코드 시험, Bayer의 실제 질문, 추론 인프라는 각각 다른 연구·운영 단위다. 비교할 때는 과제, 데이터, 설정, 비용 범위, 관측 기간 다섯 칸을 먼저 맞춰야 한다. 공개 사례의 가치는 그 결과를 그대로 구매할 수 있다는 뜻이 아니라, 우리 조직의 실험을 설계할 때 어떤 변수와 실패를 기록할지 알려준다는 데 있다.

이번 주에 바로 실행할 수 있는 작은 실험 네 가지

실험 A — 20개 에피소드로 보상 역전 찾기

새 모델 훈련 없이도 할 수 있다. 현재 에이전트가 처리하는 반복 업무 한 종류를 고르고 성공·실패·부분 성공을 포함한 20개 과제를 만든다. 각 과제의 최종 상태는 모델의 문장 대신 업무 시스템 또는 사람이 검토한 자료로 확정한다. 보상 함수를 20개에 적용한 뒤 점수 순으로 정렬한다. 맨 위 5개와 맨 아래 5개를 사람이 읽고, 실제 업무 가치와 순서가 맞는지 확인한다. 다음에는 도구 호출을 한 번 더 추가하거나, 답을 장황하게 하거나, 이관을 생략한 변형을 만들어 점수가 이상하게 오르지 않는지 본다. 이런 보상 게임화 시험은 GPU를 쓰기 전 결함을 발견할 수 있다.

결과 문서에는 보상 코드 버전과 각 항목의 기여를 같이 적는다. 정답의 품질 점수, 속도 점수, 비용 점수, 정책 위반 패널티가 최종 값만 남으면 어느 항목이 순서를 뒤집었는지 알 수 없다. Wordle 사례처럼 한 번 수정한 함수도 인접한 성공 순서가 뒤집힐 수 있다. 빠른 성공과 느린 성공, 올바른 사람 이관과 틀린 자동 답, 원본 확인을 거친 답과 기억에 의존한 답 사이의 우선순위를 예시로 고정한다. 승인을 요하는 업무라면 승인 없는 변경은 다른 성과가 아무리 높아도 좋은 점수가 되지 않도록 한다.

실험 B — 현재 모델의 서빙 설정별 평가표 만들기

훈련 중 지표가 실제 서빙 품질을 대표하는지 확인한다. 모델·프롬프트·도구·데이터를 고정하고 temperature, reasoning effort, 최대 출력 토큰, 도구 시간 제한을 현재 서비스의 값과 연구용 값으로 나눠 같은 과제를 평가한다. 한 과제를 여러 번 실행해 평균 성공, 반복 성공, 최악의 부수효과를 따로 기록한다. 모델이 하나의 설정에서는 도구 호출을 잘하지만 다른 설정에서는 텍스트로만 설명하는지 본다. 생산 환경에 적용할 값으로 측정한 결과만 출시 근거로 삼는다.

지연과 비용도 같은 표에 넣는다. 해결률이 올라가도 한 질문에 필요한 모델 호출이 두 배로 늘고 사용자 대기 시간이 허용치를 넘으면 도입 가치가 떨어진다. 불확실한 질문에서 제대로 사람에게 넘기는 비율을 긍정 지표로 삼을 수 있다. Wordle처럼 명확한 게임에는 이관 개념이 없지만, 업무 서비스에는 ‘모르겠다’고 정확히 인정하는 능력이 중요하다. 평가에서는 모든 질문에 답하도록 압박하지 않는다.

실험 C — 에이전트 체인에서 가짜 성공 제거하기

사전 환경의 전문가·도구 한 군데씩 오류를 주입한다. 검색 서비스 503, IAM 접근 거부, 모델 타임아웃, 스키마 위반, 캐시의 오래된 값을 가정한다. 각 상황에서 사용자 응답과 애플리케이션 지표가 실제 상태를 가리키는지 확인한다. 최종 API의 HTTP 200은 오류를 정중히 설명하는 경로에도 나올 수 있으므로, task_outcome 같은 별도 필드를 resolved, handed_off, blocked, unsafe 등으로 기록한다. 도구 오류를 재시도해서 해결했는지도 추적한다. 오류의 원인이 모델인지 후단인지 알 수 있어야 다음 조치가 명확하다.

특히 근거 출처가 누락됐을 때 ‘답을 생성했으니 성공’으로 처리하지 않는다. 자료가 조회되지 않은 상태에서 모델이 배경 지식으로 그럴듯한 이유를 만들어낼 수 있다. 이 경우 제품 정책에 따라 일반 정보로만 답하고 사실 확인 불가를 표시하거나, 정확한 개인별 사안이라면 사람에게 넘긴다. 사용자에게 의미 있는 해결을 업무 성공으로 기록하고, 낮은 수준의 전송 성공은 인프라 지표로만 사용한다.

실험 D — 배포 후 실제 확장 상태 비교하기

현재 모델 엔드포인트의 선언 설정을 읽고 실제 AWS API가 돌려주는 scalable target과 scaling policy를 비교한다. 차이가 없다면 그 상태를 스냅샷으로 저장한다. 다음 모델 갱신 이후 같은 비교를 자동으로 수행해 실제 리소스가 사라지거나 매개변수가 달라지면 배포를 완료로 표시하지 않는다. 프로덕션 변경 없이도 이 읽기 전용 비교를 먼저 만들 수 있다. 사전 환경에서는 인스턴스 유형과 모델 이미지를 바꿔 업데이트 순서와 롤백을 검증한다. 배포는 새 모델의 답이 나오는지와 충분한 용량을 유지하는지가 모두 참일 때 완료된다.

이 네 실험은 모두 큰 플랫폼 교체 전에 작은 증거를 만든다. 보상 역전이 없다는 증거, 서비스 설정에서 품질이 유지된다는 증거, 실패가 숨지 않는다는 증거, 배포 후 확장 정책이 남는다는 증거다. 실험에서 하나라도 실패하면 해당 경계를 고치고 다시 확인한다. 공개 기술 발표를 읽은 결과는 새로운 제품 이름을 회의록에 적는 것보다, 우리 시스템의 한 경계를 실제로 더 명확하게 만드는 데 있어야 한다.

선택 비교표: 문제에 맞는 첫 행동은 무엇인가

관찰한 문제	먼저 확인할 증거	우선 시도	학습을 검토할 조건
에이전트가 근거 문서를 못 찾음	검색 결과의 판본·권한·재현율	인덱스 갱신, 질의·메타데이터 개선	올바른 자료를 받았는데도 반복적으로 잘못 해석할 때
모델이 적절한 도구를 고르지 못함	도구 목록·설명·호출 추적	전문가별 도구 범위와 스키마 정리	인터페이스를 단순화해도 안정적 행동을 못 배울 때
한 번의 답은 되지만 여러 단계 업무에서 실패	중간 상태와 최종 업무 상태	과제 정의, 중단·재시도 규칙, 보상 불변식	객관적인 최종 판정기가 있고 반복 오류가 남을 때 MTRL 검토
특수 손실·커리큘럼이 필요함	관리형 레시피로 표현할 수 없는 단계	작은 Python 루프로 정확한 실험 명세 작성	GPU 운영은 맡기되 학습 연산 순서가 필요하면 세션 API 검토
에이전트의 성공률이 높게 보이는데 사용자가 재문의	HTTP 지표와 실제 해결 사례의 차이	태스크별 결과 지표·오류 주입·샘플 검토	측정 체계를 고친 뒤에도 모델 행동이 원인일 때
새 모델 배포 뒤 피크 시간에 지연 증가	실제 확장 대상·정책·인스턴스 수	배포 후 상태 대조, CDK 순서 수정	모델 최적화는 용량 설정이 정상임을 확인한 뒤

이 표는 공급자 기능을 추천 순위로 세운 것이 아니라 실패 원인과 첫 조치의 연결이다. 특히 검색 실패와 권한 오류를 모델 훈련 과제로 오인하면 학습 비용을 쓰고도 사용자에게 같은 장애를 남긴다. 반대로 평가 환경과 도구가 안정적이며 반복해서 같은 잘못된 행동을 하는데 프롬프트 수정만 되풀이하는 것도 효율적이지 않다. 원인별 실험을 작게 만든 뒤 학습·운영 수단을 선택한다.

업무 위험에 따라 통과 기준도 달라야 한다. 사내 개발 문서의 요약은 근거 링크와 불확실성 표기로 우선 공개할 수 있지만, 직원 급여 설명은 법적·개인적 영향이 크므로 데이터 판본, 담당자 검토, 이의제기 경로를 더 엄격히 둔다. 코드 에이전트가 초안을 제시하는 것과 프로덕션에 자동 배포하는 것은 같은 성공률을 요구하지 않는다. 보상·모델·도구·배포의 각 경계에 어떤 실수를 허용할지 제품 책임자가 정해 놓아야 운영팀이 수치를 읽고 행동할 수 있다.

실험 기록에는 날짜만 적지 말고 판단 당시 공개된 공식 문서의 링크와 확인 시각을 남긴다. 모델 지원 리전, 베이스 모델 목록, 가격, 서비스 할당량은 바뀔 수 있고 블로그 글은 공개 시점의 설명이다. 이번 MTRL 실습의 모델 목록도 글에 쓰인 당시의 목록일 뿐이다. 팀이 실행할 때 현재 문서의 지원 범위를 다시 읽고, 리전과 계정의 실제 사용 가능 여부를 확인한다. ‘공식 자료를 봤다’는 것과 ‘우리 계정에서 지금 사용할 수 있다’는 것은 다르다.

또한 팀별로 성공의 언어를 맞춘다. ML팀의 reward, 플랫폼팀의 InService, 앱팀의 200 OK, 지원팀의 해결은 서로 다른 상태다. 하나의 출시 대시보드에 이 네 값을 나란히 두고 최종 사용자의 과제 완료와 연결해야 한다. 한 값이 좋다고 다른 값의 공백을 가리지 않는다. 이 작업은 새 모델을 더 크게 만드는 것보다 덜 화려하지만, 발표에서 실제로 반복해서 등장한 장애를 줄이는 방법이다. 수치는 맥락 속에서 읽고, 경계는 테스트로 확인하며, 결과는 실제 사용자 업무로 판정한다.

오늘의 결론

오늘 살핀 발표의 공통어는 경계다. MTRL은 에이전트 행동과 결과 보상 사이의 경계를, 훈련 세션 API는 알고리즘 코드와 GPU 운영 사이의 경계를, Bayer ADE는 자연어 설명과 권위 있는 업무 시스템·사용자 권한 사이의 경계를, SageMaker CDK 샘플은 선언형 배포와 실제 확장 상태 사이의 경계를 다룬다. 네 발표는 각각 유용한 구현과 수치를 공개했지만, 어느 것도 다른 경계의 문제를 자동으로 해결하지 않는다.

개발자가 다음 주에 시작할 일은 대규모 재훈련보다 작다. 실패 과제를 분류하고, 보상·태스크 성공의 정의를 고정하고, 도구의 실제 권한과 데이터 출처를 확인하고, 배포 후 리소스 상태를 조회한다. 이 네 가지가 통과하면 그제야 모델 학습의 자유도를 어디까지 요구할지 결정할 수 있다. 좋은 AI 시스템은 답을 유창하게 만들 뿐 아니라 정답의 근거, 실행할 수 있는 권한, 실패를 드러내는 지표, 되돌릴 수 있는 배포 상태를 함께 갖는다.

공식 소스 링크

• AWS 공식 인공지능 블로그 RSS — 게시일·원문 링크 확인
• 멀티턴 강화학습 실습 원문 · MTRL 문서 · Wordle 샘플 저장소 · 평가 작업 문서
• 훈련 세션 API 원문 · 세션 API 문서 · 공식 cookbook
• Bayer ADE 사례 원문 · Bedrock 비용 귀속 문서 · AWS Well-Architected 생성형 AI 렌즈
• SageMaker 엔드포인트 자동 확장 CDK 원문 · 샘플 저장소 · 자동 확장 문서
• 확인한 다른 공식 목록: OpenAI 뉴스 · Hugging Face 블로그 · GitHub 블로그 RSS · Google 블로그 RSS

발표 원문의 제품 지원 범위·가격·리전·할당량은 바뀔 수 있다. 적용 전에는 링크된 최신 공식 문서와 자기 계정의 실제 설정을 다시 확인해야 한다. 본문의 ‘개발자에게 의미’와 운영 설계 예시는 공식 발표의 사실과 구분한 실무 해석이다.