Prompt Management

왜 프롬프트 관리인가

하드코딩의 한계 · 자산화 · 수명주기

PART 1 · 왜 프롬프트 관리인가

왜 프롬프트 관리인가

코드에 박힌 문자열에서 버전 있는 자산으로

프롬프트도 코드처럼

기법으로 잘 만든 프롬프트도 하드코딩된 채로는 관리할 수 없습니다 — Bedrock Prompt Management가 수명주기를 맡습니다.

하드코딩 — 수정마다 코드 배포
자산화 — ARN 있는 Bedrock 리소스
수명주기 — 작성 → 버전 → 평가 → 배포
거버넌스 — 작성·검토·배포 역할 분리

takeaway

프롬프트가 자산이 되는 순간 버전 관리·테스트·배포가 필요해집니다 — 코드에 프롬프트를 하드코딩하지 않습니다.

PART 1 · 왜 프롬프트 관리인가

하드코딩이 부딪히는 벽

프롬프트가 수십 개가 되는 순간 문자열 상수로는 감당 불가

코드 속 문자열 Bedrock 프롬프트 리소스

문구 하나 고치려면 코드 수정 → 리뷰 → 배포 콘솔에서 수정 → Version 발행 — 코드는 그대로

누가 언제 무엇을 바꿨는지 이력 없음 불변 버전 스냅샷 — 이력 조회와 즉시 롤백

도메인 전문가는 코드를 못 고쳐 개발자에게 요청 IAM으로 작성·검토·배포 권한을 역할별 분리

어느 문구가 더 나은지 감으로 판단 Variant 비교와 평가 잡으로 숫자로 판단

takeaway

기법(prompt-engineering)이 품질을 만들고, 관리(Prompt Management)가 그 품질을 유지·개선 가능하게 만듭니다.

PART 1 · 왜 프롬프트 관리인가

Prompt Management 워크플로우

작성 → 버전 → 평가 → 배포 — 프롬프트를 코드처럼 다루는 수명주기

1
작성
• Bedrock 콘솔 Prompt Builder에서 프롬프트 작성
• 변수 템플릿 {{variable}}으로 재사용 가능한 구조
• 모델 선택 + inferenceConfig 설정
2
버전
• Save draft → Create version으로 버전 발행
• 각 버전은 불변 스냅샷 — 롤백 가능
• ARN으로 코드에서 직접 참조
3
평가
• Compare variants로 최대 3개 변형 비교
• Advanced Prompt Optimization으로 자동 평가
• Steering criteria 또는 LLM-as-judge 루브릭
4
배포
• Converse API에 prompt ARN 전달
• promptVariables로 런타임 변수 주입
• 코드 변경 없이 프롬프트만 업데이트

takeaway

각 버전은 불변이고 ARN으로 참조됩니다 — 코드 배포 없이 프롬프트만 교체할 수 있습니다.

프롬프트 자산 관리

Prompt Builder · 변수 템플릿 · 불변 버전 · ARN 배포

PART 2 · 프롬프트 자산 관리

프롬프트 자산 관리

작성 · 버전 · 호출 — 자산 관리의 실제 도구들

만들고, 발행하고, ARN으로 부른다

create_prompt로 템플릿을 만들고, 버전으로 확정하고, Converse에서 ARN으로 호출합니다.

작성 — Prompt Builder + {{variable}} 템플릿
버전 — 불변 버전 · ARN 참조
비교 — Variant 최대 3개 나란히
배포 — 코드 변경 없이 업데이트

takeaway

템플릿 · 버전 · 비교 · ARN 호출 — 네 도구가 수명주기 전체를 덮습니다.

PART 2 · 프롬프트 자산 관리

프롬프트 생성과 버전 발행

create_prompt로 템플릿 등록, create_prompt_version으로 불변 스냅샷 확정

python

import boto3

client = boto3.client("bedrock-agent", region_name="us-east-1")

# ① 프롬프트 생성 — {{variable}}로 재사용 가능한 템플릿
response = client.create_prompt(
    name="customer-service",
    variants=[{
        "name": "default",
        "modelId": "us.anthropic.claude-sonnet-4-6",
        "templateType": "TEXT",
        "templateConfiguration": {"text": {
            "text": "당신은 {{company_name}} 상담사입니다.\n고객명: {{customer_name}}",
            "inputVariables": [{"name": "company_name"}, {"name": "customer_name"}],
        }},
        "inferenceConfiguration": {"text": {"temperature": 0.2, "maxTokens": 1024}},
    }],
)

# ② 버전 발행 — Draft를 배포 가능한 불변 스냅샷으로 확정 (1, 2, 3… 자동 증가)
version = client.create_prompt_version(promptIdentifier=response["id"])

① create_prompt — 클라이언트는 bedrock-agent. 템플릿·모델·inferenceConfiguration이 variant 하나에 묶임
② create_prompt_version — 버전은 불변 스냅샷, 번호는 정수 자동 증가 — 롤백은 번호를 되돌리는 것

takeaway

Draft는 계속 고치고, 배포는 버전으로만 합니다 — 버전이 불변이어야 롤백이 성립합니다.

PART 2 · 프롬프트 자산 관리

변수화 vs Variant — 재사용의 두 축

변수화는 "누구에게 쓸지", Variant는 "어떻게 생성할지"

변수화 — {{variable}}

하나의 템플릿을 여러 상황에

고정 부분(역할·규칙·톤)과 동적 부분(고객명·이력) 분리
값은 호출 시점에 promptVariables로 주입
템플릿 1개 = 고객 · 상품 · 상황 전부 커버

재사용을 위한 축입니다. 같은 프롬프트를 다른 입력에 쓰는 문제를 풉니다.

Variant — 변형

같은 목적을 다른 설정으로

모델을 다르게 — Sonnet vs Haiku 품질·비용 비교
파라미터를 다르게 — temperature 0.1 vs 0.5
메시지를 다르게 — 간결형 vs 상세형 문구

실험을 위한 축입니다. 어느 설정이 더 나은지 비교하는 문제를 풉니다.

takeaway

두 축은 함께 씁니다 — 변수로 재사용하고, Variant로 실험해서 이긴 쪽을 버전으로 발행합니다.

PART 2 · 프롬프트 자산 관리

변수 배치와 캐싱

고정 부분은 앞으로, 가변 부분은 뒤로 — 배치가 캐시 히트율을 결정

고정 — 캐시 대상

당신은 {{company_name}} 고객센터 상담사입니다.
정중하게 응대하고, 모르는 것은 모른다고 답합니다.
출력 형식: 인사 → 답변 → 다음 안내 순서의 3문단.

가변 — 매번 바뀜

고객명: {{customer_name}}
이전 문의 요약: {{history_summary}}

앞부분 고정 — 프롬프트 캐싱이 재사용하는 prefix
가변은 끝으로 — 중간에 끼우면 그 뒤 캐시가 전부 무효

takeaway

역할·규칙·형식 같은 고정 블록을 앞에 몰아 두면 캐시된 prefix가 커져 비용이 줄어듭니다 — 매번 바뀌는 변수는 템플릿 끝에 둡니다.

PART 2 · 프롬프트 자산 관리

ARN으로 호출 — 코드에서 프롬프트 분리

프롬프트 버전 ARN을 modelId 자리에 — 변수는 런타임에 주입

python

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    # ① 프롬프트 버전 ARN을 modelId 자리에 — 모델·메시지·파라미터가 버전에 내장
    modelId="arn:aws:bedrock:us-east-1:111122223333:prompt/PROMPT12345:2",
    # ② 템플릿 변수 {{genre}}, {{number}}를 런타임에 주입
    promptVariables={
        "genre":  {"text": "pop"},
        "number": {"text": "3"},
    },
)

print(response["output"]["message"]["content"][0]["text"])

prompt ARN = modelId — 버전 스냅샷에 모델·메시지·inferenceConfig가 모두 내장
promptVariables — {{variable}} 자리에 런타임 값 주입, 호출마다 다르게
bedrock:RenderPrompt 권한 필요 — 프롬프트 리소스를 렌더링하는 별도 IAM 액션
제약 — ARN 호출 시 inferenceConfig·system·toolConfig를 함께 전달할 수 없음(버전에 내장된 설정 사용)

takeaway

프롬프트 개선이 코드 배포와 분리됩니다 — ARN의 버전 번호만 올리면 애플리케이션은 그대로 새 프롬프트를 씁니다.

PART 2 · 프롬프트 자산 관리

Compare Variants — 나란히 비교

배포 전에 변형을 나란히 실행 — 최대 3개까지, 변형마다 모델도 다르게

무엇을 바꿔 볼 수 있나

메시지 — 지시 문구·예시·형식을 변형별로 다르게
모델 — 같은 프롬프트를 다른 모델로 (Sonnet vs Haiku)
파라미터 — temperature·topP를 변형별로 조정

한도와 사용법

최대 3개 — 변형을 나란히(side-by-side) 실행·비교
같은 입력 — 동일 변수 값으로 세 변형을 동시 테스트
승자 채택 — 이긴 변형을 새 버전으로 발행

takeaway

감으로 고르지 않습니다 — 같은 입력에 세 변형을 나란히 돌려 보고 이긴 쪽을 버전으로 발행합니다.

운영 워크플로우

롤백 · 역할 분리 · 단계적 도입

PART 3 · 운영 워크플로우

운영 워크플로우

만든 자산을 팀이 안전하게 굴리는 방법

버전이 있으면 운영이 열립니다

롤백은 번호를 바꾸는 일이 되고, 권한은 역할별로 나뉘고, 도입은 단계적으로 진행됩니다.

롤백 — Version 번호만 되돌리기
역할 분리 — 작성·검토·배포를 IAM으로
단계적 도입 — Git → 등록 → CI/CD
Git이 소스 · Bedrock이 런타임

takeaway

운영의 핵심은 전부 버전에서 나옵니다 — 불변 버전이 없으면 롤백도 승인 게이트도 성립하지 않습니다.

PART 3 · 운영 워크플로우

롤백 3패턴

어느 패턴이든 코드 변경 없음 — ARN의 Version 번호가 스위치

수동 롤백

이상 감지 시 사람이 되돌리기

고객 불만 급증 · 오답 제보 감지
운영팀이 참조 버전을 이전 번호로 변경
즉시 적용 — 배포 파이프라인 불필요

자동 롤백

평가 점수가 게이트

새 버전 배포 후 평가 잡으로 품질 측정
점수가 임계값(예: 0.8) 미만이면 이전 버전으로 복원
평가 데이터셋이 있어야 성립하는 패턴

블루/그린

두 버전을 앱 레벨에서 병행

구 버전·새 버전 ARN을 동시에 운영
앱이 호출 비중을 조절 — 새 버전이 안정되면 구 버전 비중을 0으로
문제 시 구 버전으로 즉시 복귀

takeaway

롤백이 번호 하나 바꾸는 일이 되는 것 — 이것이 버전 관리가 주는 가장 큰 운영 이득입니다.

PART 3 · 운영 워크플로우

팀 역할 분리

작성 · 검토 · 배포를 서로 다른 사람이 — IAM이 게이트를 강제

1
개발자 — 작성
• Draft 작성·수정 권한
• 템플릿 구조와 변수 설계
• Variant로 후보 변형 준비
2
도메인 전문가 — 검토
• 문구·정책·톤 검토
• 콘솔에서 직접 수정 가능 — 코드 지식 불필요
• Compare variants로 후보 비교
3
운영팀 — 배포 승인
• 버전 발행·참조 전환 권한
• 평가 결과 확인 후 승인
• 이상 시 롤백 결정

takeaway

역할별로 IAM 권한을 분리하면 검토 없이 프로덕션 프롬프트가 바뀌는 사고를 구조적으로 막습니다.

PART 3 · 운영 워크플로우

단계적 도입

처음부터 완벽한 워크플로우 대신 — 2~4주 간격의 세 단계

1
Git + PR 리뷰
프롬프트 텍스트를 저장소에 두고 코드 리뷰로 변경을 통제합니다 — 도구 추가 없이 시작.
2
Prompt Management 등록
Bedrock에 등록해 Version 관리와 ARN 호출로 전환합니다 — 코드와 프롬프트가 분리됩니다.
3
CI/CD + 자동 평가
버전 발행 시 평가 잡을 자동 실행하고, 점수 게이트를 통과해야 배포되게 합니다.

takeaway

끝 그림은 Git이 소스, Bedrock이 런타임입니다 — 각 단계를 2~4주 간격으로 도입하면 팀 저항 없이 정착됩니다.