새로운 모델이 나올 때마다 「지금의 프롬프트를 그대로 적용하면 품질이 어떻게 될까?」라는 궁금증이 생기지만, 수동으로 내용을 수정하고 나열하여 비교하는 작업은 꽤나 무거워서 뒤로 미뤄지기 일쑤입니다. Bedrock에는 이전부터 OptimizePrompt라는 동기 API(Synchronous API) 방식의 프롬프트 최적화 기능이 있었지만, 이는 1개 모델·1개 프롬프트를 수정하는 것뿐인 심플한 기능이라는 인상이었습니다.

2026년 5월 14일, 이를 확장한 Advanced Prompt Optimization and Migration Tool이 Bedrock에 추가되었습니다. 1개 작업(Job)으로 최대 5개 모델 × 최대 10개 템플릿을 나란히 최적화 및 평가할 수 있는 비동기 작업(Asynchronous Job)형 도구로, 모델 이관(Migration)을 위한 베이스라인 측정에도 사용할 수 있는 내용으로 보입니다.

• Bedrock에 비동기 작업형 프롬프트 최적화 기능이 추가 - 1개 작업으로 최대 5개 모델을 동시에 비교 가능
• 입력은 템플릿(최대 10개) + 평가 샘플(템플릿당 최대 100개) 형태의 JSONL - 이미지, PDF 등의 멀티모달(Multimodal) 입력에도 대응
• 평가 방법은 「자연어 스티어링 기준(Steering criteria)」, 「LLM-as-a-judge (기본값은 Claude Sonnet 4.6)」, 「Lambda 커스텀 평가」 중에서 선택 가능
• 추가 요금은 없으며, 내부에서 발생하는 모델 호출 토큰 요금 + (사용할 경우) Lambda 요금만이 과금 대상

대략 말하자면, 「복수의 모델 × 복수의 프롬프트 템플릿을 조합하여 최적화하고, 스코어·비용·레이턴시(Latency)를 한꺼번에 산출해 주는 비동기 작업」입니다.

기존의 동기 API(bedrock-agent-runtime의 OptimizePrompt)와 나란히, 새로운 Advanced 버전이 bedrock 서비스 측의 작업(Job) API로서 제공되는 형태인 것으로 보입니다.

「간단하게 1개만 다시 쓰고 싶다」면 기존의 동기 API로 충분하고, 「모델 이관이나 실서비스 투입 전에 제대로 비교하고 싶다」면 Advanced 쪽을 사용하는 식으로 구분될 것 같습니다.

작업(Job)을 생성하면 Bedrock 측에서 대상 모델에 대한 호출과 평가가 실행되며, 결과가 S3에 기록됩니다.

CLI에서 실행할 경우의 흐름은 대체로 다음과 같습니다.

문서상으로는 도쿄(ap-northeast-1)도 대응 리전에 포함되어 있지만, 본 기사 작성 시점에서는 도쿄 콘솔 왼쪽 내비게이션에 아직 Advanced Prompt Optimization 항목이 나타나지 않았기 때문에, 이번에는 버지니아 북부(us-east-1)에서 테스트합니다.

템플릿은 1행 1객체 형태의 JSONL로 작성합니다. 가독성을 위해 정렬된 형태로 예시를 들지만, 실제 prompts.jsonl에는 1개 템플릿을 1행으로 압축하여 저장해야 한다는 점에 주의하십시오 (복수의 템플릿을 비교하고 싶다면 2행 이후에 별도의 객체를 나열합니다).

{
"version": "bedrock-2026-05-14",
"templateId": "summarize-ja",
...

inputVariables는 **객체 1개가 아니라 객체의 배열(Array of Objects)**로 작성해야 합니다. {"minutes": "..."}와 같이 단일 객체로 작성하면, Cannot deserialize value of type ArrayList<Map<String,String>> from Object value 에러가 발생하며 거부되므로 주의가 필요합니다. referenceResponse는 선택 사항이지만, LLM-as-a-judge나 Lambda 평가에서 「기대 출력과의 일치도」를 확인하고 싶다면 넣어두는 것이 판정의 질을 안정시키는 데 도움이 되는 것 같습니다.

# 정렬된 버전 prompts.json → 1템플릿 1행의 prompts.jsonl
jq -c . prompts.json > prompts.jsonl
wc -l prompts.jsonl # 1행으로 되어 있는지 확인
...

마침 "Nova 1 Lite로 작동 중인 기존 프롬프트를 Nova 2 Lite로 교체하고 싶다"라는, 바로 이 도구가 상정하는 유스케이스로 실행해 보겠습니다. 비교 대상은 Nova 1 Lite (us.amazon.nova-lite-v1:0)와 Nova 2 Lite (global.amazon.nova-2-lite-v1:0) 두 모델입니다.

aws bedrock create-advanced-prompt-optimization-job \
--region us-east-1 \
--job-name minutes-summarizer-2026-05-16 \
...

반환값으로 jobArn (예: arn:aws:bedrock:us-east-1:123456789012:advanced-prompt-optimization-job/4a38ef56fdd9)이 돌아오므로 따로 기록해 둡니다.

비동기 방식이므로, get-advanced-prompt-optimization-job으로 상태를 확인합니다. 작은 규모의 작업은 15~20분, 큰 규모는 몇 시간이 걸릴 수도 있다고 합니다.

JOB_ARN=arn:aws:bedrock:us-east-1:123456789012:advanced-prompt-optimization-job/4a38ef56fdd9
aws bedrock get-advanced-prompt-optimization-job \
--region us-east-1 \
...

InProgress → Completed가 되면 완료입니다.

이번 작업은 약 20분 만에 Completed 되었습니다. 출력 위치는 고정되어 있으며 {OUTPUT_URI}/{job-id}/advanced_prompt_optimization_results.jsonl 경로입니다. job-id는 jobArn의 마지막 세그먼트(이번 경우에는 4a38ef56fdd9)입니다.

aws s3 ls "$OUTPUT_URI" --recursive
# outputs/4a38ef56fdd9/advanced_prompt_optimization_results.jsonl ← 이것이 본체
aws s3 cp "${OUTPUT_URI}4a38ef56fdd9/advanced_prompt_optimization_results.jsonl" /tmp/apo_result.jsonl

내용물은 템플릿 1개당 1행인 JSONL 형식이며, 최상위 레벨에 promptTemplateId / promptTemplate / steeringCriteria / customEvaluationMetricLabel / promptOptimizationResults (모델별 배열)가 나열됩니다. promptOptimizationResults[].dataset[]에는 각 샘플별 원본 모델 응답(originalPromptModelResponse / optimizedPromptModelResponse)과 판정 모델의 판정 이유까지 전부 들어있어서, 나중에 스프레드시트로 옮겨 수동 리뷰(Human Review)를 하고 싶은 용도로도 사용할 수 있을 것 같습니다.

주의할 점으로, 문서에는 "비용 추정"도 결과에 포함되는 것처럼 적혀 있지만, 실제 JSONL에는 토큰 수(inputTokens / outputTokens)와 TTFT (ttftInSec)만 들어있을 뿐, 달러($) 환산값 자체는 나오지 않습니다. 요금 견적은 "평균 토큰 수 × Bedrock의 현재 단가"로 직접 계산해야 합니다.

평균 메트릭(Metrics)은 originalPromptMetrics / optimizedPromptMetrics에서 추출할 수 있습니다. 이번 작업의 결과는 다음과 같았습니다.

스코어는 0~1로 정규화된 수치이며, 두 모델 모두 최적화 후에는 만점에 도달했습니다. 원본 프롬프트에서도 Nova 2 Lite가 베이스가 0.93으로 높게 나타나, 베이스 모델 시점의 품질 차이가 그대로 보이는 형태이므로 이관 판단을 위한 기초 자료로서 솔직한 출력이라고 할 수 있습니다.

입력 토큰이 3~4배로 증가한 것은 최적화기 (Optimizer)가 '금칙 규칙', '변환 예시', 'Few-shot 예시' 등을 프롬프트에 추가하여 품질을 보장하기 때문입니다. 예를 들어 Nova 1 Lite에 대해서는 Few-shot 예시까지 임베딩되어 다음과 같은 형태로 다시 작성되었습니다.

다음 의사록을 반드시 독립된 3행(3문장)으로 요약해 주세요.
【출력 규칙】
- 각 행은 그 자체로 의미가 완결되는 독립된 1문장(주어 또는 주제 + 술어가 명확할 것)으로 구성할 것.
...

반면 Nova 2 Lite에는 Few-shot이 붙지 않고, 규칙 리스트 + 말투 변환 예시만으로 구성되어 있어 모델마다 최적화 방침이 달라진다는 것을 알 수 있습니다. 출력 토큰 수가 작아진 것 또한 이러한 규칙들이 '冗長한 서론을 줄여라'라는 방향으로 기여했기 때문으로 보입니다.

콘솔에서 확인하는 것이 가장 편하며, Bedrock 콘솔의 왼쪽 네비게이션에 Advanced Prompt Optimization이 추가되어 있으므로, 거기서 작업을 선택하면 모델별 스코어 표와 최적화 후 프롬프트가 나란히 표시됩니다. 참고로, 출력된 S3 오브젝트를 나중에 이동시키면 콘솔의 결과 페이지가 추적할 수 없게 된다고 하므로, 결과가 필요 없어질 때까지는 출력 위치를 건드리지 않는 것이 무난해 보입니다.

툴 자체에는 별도의 전용 요금이 없으며, **내부적으로 수행되는 모델 호출의 온디맨드 토큰 요금 (On-demand token charge)**만이 과금 대상이라고 합니다. LLM-as-a-judge를 사용하는 경우의 judge 모델 호출 비용도, Lambda 커스텀 평가를 사용하는 경우의 Lambda 실행 비용도 각각 평소와 같이 발생한다고 이해하면 됩니다.

샘플 수 × 모델 수 × (베이스라인 + 후보 프롬프트)만큼 추론이 발생하므로, 검증 중에는 저렴한 모델로 적은 샘플 수부터 시도하여 감을 잡는 것이 현실적일 것 같습니다.

평가 메서드를 직접 customLLMJConfig로 지정하지 않는 한, 판관 역할은 기본적으로 Claude Sonnet 4.6이 수행되는 것으로 보입니다. 이번 사례처럼 steering criteria를 전달한 경우에도, 기본 3가지 관점(Answer Accuracy / Answer Completeness / Expression Quality)에 'Output Language and Content Requirements'와 같은 독자적인 관점이 동적으로 1개 추가되어, 가중치가 포함된 합계 스코어가 산출되는 동작을 보였습니다.

• 단발적인 재작성이라면 기존의 OptimizePrompt를, 모델 이관 평가까지 포함하여 돌리고 싶다면 Advanced를 사용하는 식으로 구분하는 것이 좋아 보입니다. 이번과 같은 작은 검증(템플릿 1개 × 샘플 2개 × 모델 2개)이라면 20분 내외, $0.5 이하로 수렴하므로, 사내 프롬프트 정리를 위해 한 번 돌려보는 정도라면 가볍게 시도해 볼 만한 인상을 받았습니다.