수일의 수동 반복을 제거하는 다중 모델 프롬프트 최적화

생성형 AI 애플리케이션 개발자는 새 모델로 마이그레이션할 때 프롬프트를 다시 쓰고, 테스트 케이스를 실행하고, 결과를 비교해 수정하는 수동 반복 작업을 수일에서 수주 동안 수행한다. 이러한 병목은 배포된 애플리케이션의 프롬프트가 이미 튜닝되어 있더라도, 더 빠르고 저렴한 새 모델이 출시되면 다시 검증 과정을 거쳐야 하는 구조적 문제에서 발생한다. Amazon Bedrock은 이 과정을 자동화하기 위해 단일 작업으로 최대 5개 모델의 프롬프트를 동시에 최적화하고 성능을 비교하는 Advanced Prompt Optimization 기능을 도입했다.

이 도구는 특정 모델의 특성에 종속되지 않는 Model-agnostic 설계를 채택하여 Amazon Bedrock에서 제공하는 다양한 모델을 대상으로 작동한다. 사용자는 원본 프롬프트와 최적화된 프롬프트의 성능 차이를 직접 비교함으로써, 경험적인 휴리스틱 수정 방식에서 벗어나 데이터 기반의 워크플로우로 전환한다. 시스템은 사용자가 설정한 평가 지표를 기반으로 최적의 결과물을 도출하는 프롬프트를 자동으로 생성하며, 이를 통해 엔지니어가 모델별 프롬프트 특성을 일일이 학습해야 했던 공수를 제거한다.

실제 구현은 Amazon Bedrock 콘솔의 전용 인터페이스를 통해 이루어진다. 사용자는 왼쪽 탐색 창에서 Advanced Prompt Optimization 메뉴를 선택하고 `Create prompt optimization` 버튼을 눌러 작업을 생성한다. 이 과정에서 기준 모델 1개와 비교 후보 모델을 최대 4개까지 지정하여 총 5개 모델의 성능을 단일 작업 내에서 동시에 검증한다. 결과적으로 수동 루프가 사라지고 설정한 지표에 따라 최적의 조합을 찾는 가이드 기반 프로세스가 적용된다.

가중치 변경 없는 강화학습 루프와 TTFT 기반 지연 시간 측정

Advanced Prompt Optimization은 모델의 내부 가중치를 수정하지 않고 평가 지표를 통해 프롬프트를 개선하는 강화학습 스타일의 피드백 루프를 실행한다. 시스템은 파인튜닝처럼 모델 파라미터를 변경하는 대신, 사용자가 설정한 품질 점수를 보상 값으로 삼아 점수가 높아지는 방향으로 입력 프롬프트의 구조와 내용을 반복 수정한다. 이는 모델의 지식 체계를 바꾸는 것이 아니라 모델이 보유한 능력을 최대치로 끌어낼 수 있는 최적의 지시서를 찾아내는 과정이다. 가중치를 고정한 상태에서 프롬프트만 변경하므로 막대한 컴퓨팅 자원 소모 없이 성능을 향상시킨다.

응답의 체감 속도를 정밀하게 관리하기 위해 TTFT(Time-to-First-Token)를 핵심 지표로 측정한다. TTFT는 클라이언트가 요청을 보낸 시점부터 모델이 첫 번째 토큰을 생성하여 반환할 때까지의 시간을 의미하며, 챗봇이 타이핑을 시작하는 시점과 동일한 사용자 경험 지표가 된다. 전체 지연 시간은 이 TTFT에 이후 생성되는 전체 토큰의 출력 속도를 더해 계산하며, 이를 통해 모델별 응답 특성을 수치로 파악한다. 특히 프롬프트가 복잡해질수록 TTFT가 증가하는 경향이 있으므로 품질과 속도의 상관관계를 추적하는 지표로 활용한다.

최적화 프로세스는 품질 점수, TTFT, 추론 비용이라는 세 가지 축을 동시에 분석한다. 추론 비용은 온디맨드 가격 정책을 기반으로 한 추정치로 제공되며, 결과 페이지에는 최적화 전후의 모델별 평가 점수 변화와 즉시 복사 가능한 최적화 프롬프트가 나열된다. 사용자는 샘플별 TTFT와 예상 비용을 함께 검토하여 품질 향상이 지연 시간 증가나 비용 상승으로 이어지지 않았는지 검증한다. 이를 통해 품질 점수가 높으면서도 TTFT가 낮고 비용이 합리적인 최적의 프롬프트를 선택한다.

4가지 평가 방법론과 멀티모달 데이터 처리 기준

사용자는 검증 목적에 따라 4가지 평가 방식 중 하나를 선택하여 프롬프트 성능을 측정한다. 첫째, 모든 평가 필드를 생략하면 시스템이 정확도, 답변 완결성, 작성 스타일 점수를 결합해 산출하는 기본값(Default) 방식이 작동한다. 둘째, 답변의 방향성을 세밀하게 제어하고 싶을 때는 Steering criteria를 설정하여 모델의 출력 성향을 가이드한다. 셋째, 정성적 평가가 필요할 때는 LLM-as-a-Judge 방식을 사용하며, 사용자가 정의한 루브릭을 기반으로 모델이 다른 모델의 결과물을 채점한다. 이때 `{{prompt}}`, `{{response}}`, `{{referenceResponse}}` 플레이스홀더를 사용하여 입력값, 응답, 정답지를 상호 대조한다. 넷째, 정량적 수치 산출이 필수적인 경우 AWS Lambda를 연동해 사용자 정의 메트릭을 계산하며, 이때 최종 출력값은 반드시 단일 숫자로 제공해야 한다.

최적화 작업의 입력 데이터는 한 줄에 하나의 JSON 객체를 담는 JSONL 형식을 따른다. 각 행은 최적화할 프롬프트 템플릿과 평가 방법을 명시하며, 아래와 같은 스키마 구조를 가진다.

{

"promptTemplate": "[최적화할 프롬프트 내용]",

"evaluationMethod": {

"llmJudge": { "customLLMJPrompt": "[루브릭 내용]" },

"lambdaMetric": { "functionArn": "[람다함수ARN]" },

"steeringCriteria": { "criteria": "[가이드라인]" }

}

}

텍스트 외의 시각적 데이터가 포함된 작업은 멀티모달 입력을 통해 처리한다. PNG, JPG, JPEG, GIF, WebP 이미지 파일과 PDF 문서 형식을 지원하며, 모든 파일은 Amazon S3 URI 참조 방식으로 입력한다. 이 기능을 통해 개발자는 문서 분석, 이미지 분류, 시각적 질의응답(VQA)과 같이 텍스트와 시각 정보가 결합된 복잡한 작업의 프롬프트를 정밀하게 최적화할 수 있다.

콘솔 워크플로우와 boto3를 활용한 최적화 자동화

콘솔 기반의 워크플로우는 기준 모델 1개와 최대 4개의 후보 모델을 선택하는 단계로 시작한다. 사용자는 프롬프트 템플릿 소스 섹션에서 로컬 머신의 JSONL 파일을 직접 업로드하거나 Amazon S3 URI를 입력하여 데이터를 가져온다. 결과값이 저장될 S3 출력 경로를 지정한 후 최적화 생성 버튼을 누르면 작업이 제출된다. 결과 페이지에서는 최적화 전후의 평가 점수, 최적화된 프롬프트, 샘플별 TTFT, 온디맨드 기반 비용 추정치라는 4가지 핵심 데이터를 제공한다.

전체 파이프라인은 boto3(AWS 파이썬 SDK)를 통해 코드로 제어하여 자동화할 수 있다. 최적화 작업은 실행 시간이 길기 때문에 비동기 방식으로 작업을 생성하고, 작업 ID를 통해 상태를 주기적으로 확인하는 폴링 구조를 구현한다.

import boto3

client = boto3.client('bedrock')
response = client.create_prompt_optimization_job(
 jobName='optimization-job-01',
 baseModelIdentifier='amazon.nova-lite-v1',
 candidateModelIdentifiers=['amazon.nova-pro-v1', 'anthropic.claude-3-sonnet'],
 inputDataConfig={'s3Uri': 's3://bucket/input.jsonl'},
 outputDataConfig={'s3Uri': 's3://bucket/output/'}
)

이러한 API 기반 접근 방식은 수동 콘솔 조작 없이 여러 모델의 최적화 작업을 동시에 예약하고 관리할 수 있게 한다. 특히 대규모 프롬프트 템플릿을 관리하는 엔지니어링 환경에서 효율적이며, 콘솔과 동일한 요약 뷰 및 상세 결과 뷰를 통해 최적화 성과를 확인할 수 있다.

실무 데이터셋 기반의 성능 개선 수치와 모델 선택 기준

Amazon Nova 2 Lite 모델을 사용한 NESTFUL 함수 호출 작업에서 정확도가 0.267에서 0.647로 상승했다. 이는 tutorial GitHub repo의 데이터셋과 5개의 평가 샘플을 기준으로 측정한 결과이며, 모델이 API 호출에 필요한 인자 값을 정확한 형식으로 생성하는 능력이 개선되었음을 보여준다. 최적화 이전에는 4건 중 1건 정도만 정답을 맞혔으나, 최적화 이후에는 3건 중 2건 가까이 정답을 도출하는 수준으로 성능이 올라갔다.

요약 작업인 XSum 사례에서는 Claude Haiku 4.5 모델을 사용하여 품질 점수를 0.550에서 0.743으로 높였다. 이 과정에서 출력 토큰 수는 51개에서 28개로 감소하여, 모델이 불필요한 수사를 제거하고 핵심 정보 위주로 답변하도록 최적화되었다. 출력 토큰의 감소는 곧바로 API 호출 비용 절감과 생성 시간 단축으로 이어져 사용자 경험을 개선한다. 다만 이러한 개선 폭은 데이터셋 구성, 프롬프트 복잡도, 모델 기본 역량에 따라 달라지므로 실제 배포 전에는 더 큰 규모의 데이터셋으로 검증해야 한다.

최종적으로 최적의 모델을 선택하는 판단 기준은 품질 점수의 상승 폭, 토큰 수 감소량, 그리고 TTFT를 종합적으로 비교하여 비용과 성능의 최적 절충점을 데이터로 선택하는 것이다. 개발자는 품질 향상이 지연 시간 증가나 비용 상승으로 이어지지 않았는지 확인하고, 서비스의 요구사항에 맞는 최적의 모델과 프롬프트 조합을 결정해야 한다.