생성형 AI 서비스를 만들 때 모델 선택에는 시간을 많이 쓰지만, 정작 어떤 추론 환경에서 돌릴지는 나중에 정하는 경우가 많다. 그러면 비용이 예상보다 커지거나, 데모에서는 괜찮았던 응답이 실제 사용자가 몰린 시간에는 답답해진다. 8월 20일 AWS가 SageMaker AI Studio에 추가한 생성형 AI 추론 추천 UI는 이 순서를 바꿔 보게 한다. 모델을 고른 뒤 인스턴스를 감으로 고르는 대신, 서비스가 어떤 요청을 받고 무엇을 우선할지 먼저 정한 뒤 측정값으로 후보를 비교하게 만든다.
이 기능은 인프라를 잘 모르는 팀도 바로 운영 환경을 결정하게 해 주는 마법은 아니다. 다만 추론 배포를 성능 점수 하나로 고르지 않도록, 질문의 형식을 화면에 넣었다는 점은 눈여겨볼 만하다. 작은 사내 챗봇이나 문서 요약 자동화도 같은 방식으로 검토할 수 있다.
이번 변화에서 실제로 달라진 부분
AWS 발표에 따르면 SageMaker AI의 Generative AI Inference Recommendations는 기존 API 기반 기능을 Studio의 시각적 흐름으로 확장했다. Studio에서 Jobs > Inference optimization으로 들어가 사용 사례 프로필, 최적화 목표, 모델과 필요하면 후보 컴퓨팅을 정해 작업을 실행한다. 결과는 배포 가능한 구성의 순위와 측정값으로 돌아온다.
선택지는 단순하지만 중요한 전제를 담고 있다. 사용 사례 프로필은 Interact, Generate, Summarize, Custom으로 나뉜다. Interact는 짧은 입력과 여러 차례의 대화에, Generate는 짧은 입력과 긴 출력에, Summarize는 긴 입력과 짧은 출력에 맞춘다. 실제 요청과 맞지 않으면 Custom에서 JSONL 평가 데이터, 동시 요청 수, 평균 출력 토큰 수를 직접 넣을 수 있다.
그 다음에는 최소 비용, 최소 지연 시간, 최대 처리량 가운데 하나를 목표로 고른다. 세 목표를 한 번에 최대로 만들 수 없다는 사실을 UI가 숨기지 않는 점이 좋다. 상담 화면처럼 사용자가 첫 응답을 기다리는 서비스와, 밤에 문서를 대량 요약하는 작업은 같은 모델을 써도 좋은 배포 구성이 다를 수밖에 없다.
숫자 네 개를 같은 방향으로 읽으면 안 되는 이유
Studio 문서는 결과에서 TTFT, ITL, 처리량, 비용을 함께 보라고 안내한다. TTFT(Time to First Token)는 요청 뒤 첫 토큰이 나오기까지의 시간이다. 스트리밍 응답에서 사용자가 처음으로 반응을 체감하는 지표에 가깝다. ITL(Inter-Token Latency)은 이후 토큰 사이의 간격이다. 첫 글자는 빨리 나왔지만 문장이 천천히 이어지는 문제는 TTFT만으로 잡기 어렵다.
처리량은 일정 시간에 시스템이 처리하는 토큰 또는 요청의 양이다. 비용과 함께 봐야 의미가 생긴다. 동시 요청을 크게 높이면 GPU 사용률과 전체 처리량은 좋아질 수 있지만, 대기열이 늘면서 사용자별 TTFT와 ITL은 나빠질 수 있다. NVIDIA AIPerf 문서의 예시도 동시성 수준에 따라 GPU당 처리량과 사용자당 처리량이 서로 다른 방향으로 움직일 수 있음을 보여 준다. 예시의 수치를 자신의 서비스 목표로 옮겨 쓰면 안 되지만, 하나의 평균값만 보고 배포를 고르는 습관은 경계할 만하다.
따라서 비교표를 볼 때는 먼저 서비스 약속을 문장으로 적는 편이 낫다. 예를 들어 내부 검색 도우미라면 ‘평상시 동시 사용자 수에서 첫 답변을 빠르게 시작하고, 답변 중간이 끊기지 않아야 한다’가 출발점이다. 야간 문서 처리라면 ‘마감 시간 안에 필요한 문서량을 처리하면서 단위 작업 비용을 넘지 않아야 한다’가 더 적절하다. 이후에야 TTFT, ITL, 처리량, 비용의 우선순위를 정할 수 있다.
추천 결과가 곧 운영 검증은 아니다
AWS는 선택한 목표에 맞춰 구성 후보를 벤치마크하고 순위를 매긴다. 지연 시간을 목표로 하면 지원되는 조합에서 커널 튜닝 배포를 쓸 수 있고, 처리량을 목표로 하면 지원되는 조합에서 speculative decoding을 적용할 수 있다. speculative decoding은 작은 초안 모델이 다음 토큰 후보를 먼저 만들고 큰 모델이 이를 검증해, 조건이 맞을 때 생성 속도를 높이는 방식이다. 어떤 최적화가 적용되는지는 모델 구조와 인스턴스 지원 여부에 달려 있다.
그렇다고 추천 1위를 바로 서비스 기본값으로 확정하면 안 된다. Custom 프로필에는 대표 요청을 넣을 수 있지만, 데이터가 실제와 다르면 벤치마크도 실제와 멀어진다. 특히 RAG 서비스는 문서 길이, 검색 결과 개수, 시스템 프롬프트, 대화 이력 때문에 입력 토큰 분포가 크게 달라진다. 코드 생성은 출력 길이와 도구 호출 여부가 영향을 준다. 실제 운영의 급격한 트래픽 증가, 오류율, 재시도, 다운스트림 API 대기 시간도 모델 엔드포인트 벤치마크만으로는 다 보이지 않는다.
비용에도 주의가 필요하다. AWS는 추천 생성 자체에는 추가 요금이 없다고 설명하지만, 최적화 작업과 벤치마킹 동안 프로비저닝되는 엔드포인트에는 표준 컴퓨팅 요금이 적용된다고 명시한다. 작업이 끝나면 이 기능이 만든 엔드포인트는 자동 삭제되지만, 실행 전에 인스턴스 범위와 작업 시간을 확인해야 한다. 예약 용량을 이미 확보한 조직이라면 후보 인스턴스를 제한했을 때 결과가 어떻게 바뀌는지도 따로 살펴볼 일이다.
작은 팀이 가져갈 수 있는 평가 순서
이 기능을 쓰지 않더라도 절차는 가져올 수 있다. 먼저 최근 요청 로그에서 입력 길이, 출력 길이, 동시 요청 수를 대략 세 구간으로 나눈다. 채팅형, 긴 문서 요약형, 대량 생성형을 한 덩어리로 평균 내지 않는 것이 중요하다.
- 대표 요청 묶기: 개인정보와 원문 내용은 제외하고, 토큰 길이와 요청 간격이 비슷한 평가 데이터를 만든다. 실제 로그가 없다면 서비스 화면과 사용 시나리오에서 예상 입력, 출력, 동시성 범위를 먼저 적는다.
- 목표를 하나씩 분리해 비교하기: 같은 모델과 동일한 요청 묶음으로 지연 시간 우선, 비용 우선, 처리량 우선 결과를 각각 본다. 결과가 크게 갈리면 단일 엔드포인트가 아니라 사용 사례별 큐나 배포 구성을 나눌 근거가 된다.
- 배포 뒤 다시 측정하기: 모델을 바꾸거나 미세 조정했을 때, 새 인스턴스가 리전에 추가됐을 때, 서빙 컨테이너나 프레임워크를 올렸을 때는 이전 결과를 재사용하지 않는다. 실제 요청의 TTFT, ITL, 오류율, 비용을 짧은 기간이라도 다시 확인한다.
도구보다 먼저 남겨야 할 기록
AWS의 새 UI는 지금은 특정 리전과 SageMaker 환경에서 제공된다. AWS를 쓰지 않는 팀에는 직접적인 도입 대상이 아닐 수 있다. 그래도 이번 변화가 던지는 실무 질문은 클라우드와 무관하다. ‘이 모델이 가장 좋은가’에서 멈추지 말고, ‘어떤 요청을 어떤 약속 아래 처리하며 무엇을 포기할 수 있는가’까지 적어야 한다.
AI 기능을 붙인 뒤 비용이나 속도 문제가 생기면 모델 교체부터 시도하기 쉽다. 그 전에 대표 트래픽, 동시성, 출력 길이, 허용 지연 시간을 기록해 두면 원인을 더 좁힐 수 있다. 이번 UI의 가치는 버튼 하나로 배포하는 데 있기보다, 그 질문을 배포 전에 강제한다는 데 있다. 운영 환경에서의 답은 여전히 각 서비스의 실제 요청으로 확인해야 한다.