Prompt Evaluation이란?

Prompt Evaluation은 프롬프트 변경이 실제로 좋아졌는지 확인하는 평가 절차입니다. 몇 개 결과를 눈으로 보고 “괜찮아 보인다”고 판단하는 방식과 다릅니다.

CCA-F 관점에서는 Prompt 개선을 감이 아니라 측정 가능한 엔지니어링 과정으로 바꾸는 것이 핵심입니다.

평가가 없으면 새로운 Prompt가 특정 문제를 고치면서 기존 정상 케이스를 망가뜨렸는지 알기 어렵습니다.

Success Criteria 먼저 정하기

공식 문서 기준으로 평가를 만들기 전에는 먼저 성공 기준을 정해야 합니다. “좋은 답변”처럼 모호한 기준보다 “정확한 분류 라벨을 반환한다”처럼 측정 가능한 기준이 좋습니다.

성공 기준은 구체적이고, 측정 가능하며, 실제 작업 분포를 반영해야 합니다. 그래야 평가 결과가 배포 판단에 쓸 수 있는 근거가 됩니다.

시험에서는 Prompt Engineering이 성공 기준과 평가 없이 진행되면 주관적 튜닝에 머문다는 점을 이해해야 합니다.

Dataset, Run, Grade, Compare

Prompt Evaluation의 기본 흐름은 네 단계로 볼 수 있습니다. 먼저 평가할 입력 묶음을 만들고, 현재 Prompt로 실행한 뒤, 기준에 따라 채점하고, 이전 버전과 비교합니다.

이 흐름을 반복하면 Prompt 변경을 배포할지, 다시 수정할지 판단할 수 있습니다.

Test Dataset 구성

좋은 Test Dataset은 일반 입력만 모아서는 부족합니다. 실제로 자주 들어오는 Typical Case, 범위의 끝에 있는 Edge Case, 의도적으로 실패를 유도하는 Adversarial Case가 함께 있어야 합니다.

초기에는 사람이 직접 만든 작은 세트로 시작할 수 있습니다. 이후 합성 케이스로 범위를 넓히고, 운영 입력을 검토해 추가하면 실제 사용 분포에 가까워집니다.

Dataset이 바뀌면 이전 점수와 직접 비교하기 어려워질 수 있으므로, 기준선도 다시 계산해야 합니다.

평가 케이스 예시

아래 예시는 원본 예시나 실제 데이터를 사용하지 않는 더미 평가 케이스입니다. 실제 서비스명, 도메인, 계정, 리소스명은 포함하지 않았습니다.

이런 케이스는 Code-based Grading으로 일부 자동 검증할 수 있습니다. 하지만 요약 품질이나 톤처럼 규칙으로 표현하기 어려운 항목은 Model-Based Grading이 필요할 수 있습니다.

Code-based와 Model-Based Grading

Code-based Grading은 정확히 일치하는 값, 문자열 포함 여부, 정규식, JSON Schema 검증처럼 코드로 판정할 수 있는 작업에 적합합니다. 빠르고 일관되며 비용이 낮습니다.

Model-Based Grading은 별도의 평가 모델이 입력, 출력, Rubric을 보고 점수를 매기는 방식입니다. 요약 품질, 톤, 복잡한 판단처럼 코드로 판정하기 어려운 작업에 적합합니다.

단, Model-Based Grading도 Prompt입니다. Rubric을 명확히 작성하고, 사람이 평가한 일부 케이스와 비교해 Calibration을 해야 신뢰할 수 있습니다.

Regression Testing과 운영 지표

Prompt를 바꾼 뒤에는 전체 Eval Suite를 다시 실행해야 합니다. 특정 실패 케이스를 고쳤더라도 기존에 통과하던 케이스가 실패하면 Regression입니다.

Pass Rate만 보면 부족합니다. Regression Rate, 평균 지연 시간, 평가 실행 비용도 함께 봐야 실제 운영에 맞는 개선인지 판단할 수 있습니다.

FAQ

Structured Extraction이란?

Structured Extraction은 비정형 입력에서 필요한 값을 뽑아 정해진 구조로 반환하는 방식입니다. 핵심은 모델의 자유 텍스트를 그대로 파싱하지 않고, Schema가 있는 구조로 결과를 받는 것입니다.

CCA-F에서는 두 가지 방식을 구분해야 합니다. 하나는 Claude의 직접 응답을 JSON Schema로 제한하는 Structured Outputs이고, 다른 하나는 Tool 호출의 입력값을 구조화된 추출 결과로 사용하는 방식입니다.

이 글에서는 Tool Definition, Strict Tool Use, Validation Loop를 중심으로 추출 파이프라인을 정리합니다.

Tool Definition을 추출에 사용하는 방식

Tool Use는 모델이 직접 외부 작업을 실행하는 기능이 아닙니다. Claude는 어떤 도구를 어떤 입력값으로 호출해야 하는지 구조화된 요청을 만들고, 실제 실행은 애플리케이션이 담당합니다.

추출 작업에서는 이 구조를 활용할 수 있습니다. 실행할 외부 API가 없어도, 원하는 추출 결과와 같은 모양의 input_schema를 가진 도구를 정의하고, Claude가 그 도구의 입력값을 채우게 만들 수 있습니다.

이렇게 하면 애플리케이션은 자유 텍스트를 파싱하지 않고 tool_use 블록의 input 객체를 읽으면 됩니다.

Strict Tool Use가 보장하는 것

Strict Tool Use는 도구 정의에 strict: true를 설정해 Tool 입력값이 JSON Schema를 따르도록 보장하는 방식입니다.

공식 문서 기준으로 Strict Tool Use는 도구 이름이 유효하고, 입력값이 input_schema와 맞으며, 필수 필드가 누락되지 않도록 grammar-constrained sampling을 사용합니다.

단, 값의 의미가 입력 근거와 실제로 일치하는지까지 자동으로 보장하는 것은 아닙니다. 그래서 Validation Loop가 필요합니다.

Validation Loop 설계

Validation Loop는 추출 결과를 애플리케이션에 넘기기 전에 검증하고, 실패하면 구체적인 오류와 함께 다시 요청하는 구조입니다.

중요한 점은 Schema 검증만으로 충분하지 않다는 것입니다. 구조적으로 유효한 JSON도 의미는 틀릴 수 있기 때문에, 필요한 경우 근거 확인과 의미 검증을 추가해야 합니다.

Tool Schema 예시

아래 예시는 원본 예시나 실제 데이터를 사용하지 않는 더미 예시입니다. 실제 서비스명, 계정, 도메인, 리소스명은 포함하지 않았습니다.

이 Schema는 도구 입력의 구조를 안정화하지만, title 값이 입력 근거와 맞는지는 별도 검증이 필요할 수 있습니다.

Retry Budget과 Multi-Pass Review

검증 실패가 발생하면 “다시 해줘”처럼 막연히 요청하지 말고, 어떤 필드가 왜 실패했는지 구체적으로 알려줘야 합니다. 그래야 같은 오류를 반복할 가능성이 줄어듭니다.

Retry Budget은 재시도 횟수의 상한입니다. 보통 2~3회 정도로 제한하고, 계속 실패하면 사람 검토, 구조화된 오류 반환, 안전한 기본값 같은 Escalation Path로 넘겨야 합니다.

오류 비용이 큰 작업이나 긴 결과물은 Reviewer Pattern을 사용할 수 있습니다. 생성 모델과 검토 모델의 역할을 나누고, 체크리스트 기반으로 누락, 정확성, 형식 문제를 확인하는 방식입니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Strict Tool Use는 도구 입력값의 Schema 준수를 보장합니다. Claude의 최종 텍스트 응답 JSON을 보장하는 Structured Outputs와 적용 대상이 다릅니다.

둘째, Strict Tool Use가 있어도 의미 검증은 필요할 수 있습니다. 타입과 필드는 맞아도 입력에 없는 값을 그럴듯하게 채울 수 있기 때문입니다.

FAQ

Structured Outputs란?

Structured Outputs는 Claude의 응답을 정해진 JSON Schema에 맞게 생성하도록 제약하는 기능입니다. 단순히 “JSON으로 답해줘”라고 요청하는 것보다 더 강한 형식 보장을 제공합니다.

공식 문서 기준으로 JSON outputs는 output_config.format에 type: "json_schema"와 Schema를 넣어 사용합니다. 응답은 텍스트 블록 안에 유효한 JSON 형태로 반환됩니다.

CCA-F 관점에서는 Structured Outputs를 “예쁜 JSON을 만드는 기능”이 아니라, downstream 시스템이 신뢰할 수 있는 구조를 만드는 기능으로 이해해야 합니다.

JSON Schema가 하는 일

JSON Schema는 출력이 어떤 필드를 가져야 하는지, 각 필드의 타입은 무엇인지, 허용되는 값은 무엇인지 정의합니다.

예를 들어 분류 결과라면 enum으로 허용 가능한 라벨을 제한할 수 있습니다. 반드시 있어야 하는 값은 required에 넣고, 값이 없을 수 있는 항목은 optional로 두는 것이 좋습니다.

중요한 점은 Schema가 구조를 보장해도 값의 의미 판단까지 항상 완벽하게 보장하지는 않는다는 것입니다. 그래서 필드 설명과 테스트가 필요합니다.

Constrained Decoding 이해하기

Constrained Decoding은 모델이 응답을 만든 뒤 나중에 고치는 방식이 아닙니다. 생성 과정에서 Schema에 맞는 토큰만 선택할 수 있도록 제한하는 방식입니다.

그래서 일반 프롬프트 방식보다 JSON 파싱 오류, 누락 필드, 타입 불일치 문제를 줄이는 데 유리합니다.

다만 안전 거부나 토큰 한도 초과처럼 Schema 보장보다 먼저 처리되는 상황은 여전히 확인해야 합니다.

Schema 설계 기준

Schema는 단순할수록 안정적입니다. 실제 데이터에 항상 존재하는 값만 required로 두고, 없을 수 있는 값은 optional 또는 null 허용으로 설계합니다.

시험에서는 Schema가 출력 구조를 안정화하지만, 잘못 설계된 Schema는 오히려 downstream 오류를 만들 수 있다는 점을 기억해야 합니다.

Schema 예시

아래 예시는 원본 예시나 실제 데이터를 사용하지 않는 더미 예시입니다. 핵심은 필요한 필드, 타입, enum, 추가 속성 차단을 명확히 보여주는 것입니다.

운영 시스템에서 이 JSON을 바로 파싱한다면 additionalProperties: false처럼 예상하지 않은 필드를 줄이는 설정도 중요합니다. 다만 지원 범위는 공식 문서의 제한을 확인해야 합니다.

제한 사항과 예외 처리

Structured Outputs는 표준 JSON Schema 전체를 무제한으로 보장하는 기능이 아닙니다. 지원되는 Schema 하위 범위 안에서 동작하며, SDK는 일부 미지원 제약을 변환해 처리할 수 있습니다.

또한 처음 사용하는 Schema는 grammar compile 때문에 지연 시간이 늘 수 있고, 컴파일된 grammar는 일정 기간 캐시됩니다. Schema 구조나 요청의 도구 구성이 바뀌면 캐시가 무효화될 수 있습니다.

응답을 신뢰하기 전에 stop_reason을 확인해야 합니다. 안전 거부나 max_tokens로 인한 잘림이 있으면 JSON이 의도한 Schema와 다를 수 있습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Structured Outputs는 프롬프트로 JSON을 요청하는 것과 다릅니다. output_config.format에 Schema를 제공해 생성 과정을 제약합니다.

둘째, Structured Outputs는 Claude의 직접 응답 형식을 제어합니다. 도구 호출 입력값을 보장하는 Strict Tool Use와는 적용 대상이 다릅니다.

FAQ

Multi-Turn Interaction이란?

Multi-Turn Interaction은 한 번의 요청으로 끝내기 어려운 작업을 여러 번의 대화로 나누어 처리하는 방식입니다. 단순히 대화를 길게 하는 것이 아니라, 각 Turn마다 분명한 역할을 두는 것이 핵심입니다.

입력이 모호하거나, 중간 결과를 확인해야 하거나, 최종 결과가 여러 단계의 결정에 의존한다면 Multi-Turn 방식이 더 안정적일 수 있습니다.

반대로 입력이 명확하고 작업이 짧다면 단일 프롬프트가 더 간단합니다. CCA-F에서는 언제 대화를 나눠야 하는지 판단하는 기준이 중요합니다.

Clarification Turn

Clarification Turn은 모델이 모호한 입력을 임의로 해석하지 않고, 필요한 정보를 먼저 확인하는 단계입니다. 좋은 질문은 짧고 구체적이어야 합니다.

중요한 기준은 한 번에 너무 많은 질문을 던지지 않는 것입니다. 사용자의 답변을 받아야만 품질이 크게 달라지는 핵심 모호점 하나를 먼저 확인하는 편이 좋습니다.

예를 들어 “무엇을 더 알려주실 수 있나요?”보다 “최종 결과는 요약문이 필요한가요, 체크리스트가 필요한가요?”처럼 선택 기준이 분명한 질문이 더 좋습니다.

Turn Sequence 설계

Turn Sequence는 복잡한 작업을 순서 있는 단계로 나누는 설계입니다. 각 Turn은 하나의 목표만 처리하고, 다음 Turn은 이전 Turn의 결과를 명시적으로 이어받아야 합니다.

좋은 흐름은 “요구사항 확인 → 초안 생성 → 특정 부분 수정 → 최종 점검”처럼 단계가 분리되어 있습니다. 이렇게 하면 잘못된 부분을 전체 재작성 없이 수정할 수 있습니다.

시험에서는 Turn Sequence를 단순 대화가 아니라, 출력 의존성을 관리하는 구조로 이해하면 됩니다.

Context Accumulation과 Drift

Context Accumulation은 대화가 길어지면서 이전 메시지와 응답이 계속 쌓이는 현상입니다. 일부는 도움이 되지만, 오래된 결정이나 폐기된 방향은 현재 작업에 방해가 될 수 있습니다.

Anthropic Messages API는 상태 저장형 대화가 아니라, 매 요청에 필요한 대화 이력을 함께 보내는 방식입니다. 따라서 어떤 이력을 유지할지 설계하는 일이 중요합니다.

대화 흐름 예시

아래 예시는 원본 문장이나 특정 서비스 사례가 아닌 더미 예시입니다. 핵심은 각 Turn의 목적을 작게 나누고, 다음 Turn으로 넘길 정보를 명확히 적는 것입니다.

이런 식으로 단계 이름을 붙이면 모델과 사용자가 같은 흐름을 공유하기 쉽습니다. 특히 긴 작업에서는 매 Turn 시작에 “현재 단계”와 “유지할 조건”을 짧게 다시 적는 것이 도움이 됩니다.

계속 진행할지 Reset할지 판단

대화가 여전히 같은 목표를 향하고 있고, 최근 결정이 명확하며, 오래된 정보가 방해되지 않는다면 그대로 이어가도 됩니다.

하지만 목표가 바뀌었거나, 이전 대화에 모순이 많거나, 모델이 계속 원래 의도와 다른 방향으로 답한다면 Reset을 고려해야 합니다.

실무에서는 전체를 버리는 Reset보다 Partial Reset이 유용한 경우가 많습니다. 핵심 결정, 확정된 제약, 필요한 출력만 짧게 옮기고 새로 시작하는 방식입니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Multi-Turn은 긴 대화를 뜻하는 것이 아니라 단계별 목적을 가진 대화 설계입니다. 둘째, Clarification은 많이 묻는 것이 아니라 중요한 모호점 하나를 정확히 묻는 것이 좋습니다.

셋째, Context는 무조건 많이 넣을수록 좋은 것이 아닙니다. 현재 작업에 필요한 정보는 유지하고, 오래된 정보와 모순은 줄여야 합니다.

FAQ

Output Steering이란?

Output Steering은 모델의 답변이 원하는 형식, 톤, 범위, 구조를 따르도록 유도하는 설계입니다. 단순히 “짧게 써줘”라고 말하는 것보다, 어떤 모양의 답이 필요한지 명확히 정하는 것이 중요합니다.

CCA-F 시험에서는 출력 제어를 하나의 기술로 외우기보다, 형식 보장, 도구 입력 보장, 대화 전체의 행동 제어를 구분해서 이해해야 합니다.

최신 Claude 모델에서는 예전 방식의 일부가 제한되므로, 현재 공식적으로 지원되는 방식 중심으로 정리해야 합니다.

Pre-fill을 더 이상 기본 전략으로 보면 안 되는 이유

Pre-fill은 Assistant 응답의 시작 부분을 미리 넣고, 모델이 그 뒤를 이어 쓰게 하던 방식입니다. 예전에는 JSON 시작 괄호나 특정 문구를 강제로 시작하게 하는 데 쓰였습니다.

하지만 공식 문서 기준으로 Claude 4.6 이후 모델과 Claude Mythos Preview에서는 Prefill이 지원되지 않습니다. 따라서 최신 모델 기준으로는 Pre-fill에 의존하면 요청이 실패할 수 있습니다.

시험에서는 “Pre-fill로 형식을 고정한다”보다 “Structured Outputs, Strict Tool Use, System Prompt로 대체한다”는 흐름을 기억하는 것이 더 중요합니다.

Pre-fill 대체 방식 3가지

Structured Outputs는 Claude의 직접 응답이 JSON Schema를 따르도록 제약하는 방식입니다. JSON 파싱 실패나 필드 누락을 줄여야 할 때 적합합니다.

Strict Tool Use는 도구 호출의 입력값이 도구의 JSON Schema와 맞도록 보장하는 방식입니다. 함수 호출, 에이전트 워크플로우, 타입 안정성이 중요한 경우에 사용합니다.

System Prompt는 대화 전체에서 유지되어야 하는 역할, 톤, 응답 범위, 기본 형식을 설정하는 방식입니다. 구조 보장이 목적이 아니라 행동 방향을 지속적으로 잡는 데 적합합니다.

Sampling Parameter의 의미

Temperature, top_p, top_k는 모델이 다음 토큰을 고를 때 후보 범위나 확률 분포를 조정하던 전통적인 Sampling Parameter입니다.

공식 문서 기준으로 Claude Fable 5, Mythos 5, Mythos Preview, Opus 5, Opus 4.8, Opus 4.7, Sonnet 5에서는 기본값이 아닌 temperature, top_p, top_k가 400 오류를 반환합니다.

출력 제어 예시

아래 예시는 특정 서비스나 실제 데이터를 사용하지 않는 더미 예시입니다. 핵심은 Pre-fill로 시작 문자를 강제하지 않고, 출력 형식 자체를 명확히 정의하는 것입니다.

이 정도의 프롬프트 지시만으로 충분한 작업도 있습니다. 하지만 downstream 시스템이 반드시 JSON Schema를 요구한다면 프롬프트만 믿지 말고 Structured Outputs를 사용하는 것이 맞습니다.

기능 선택 기준

JSON 형태가 반드시 깨지면 안 된다면 Structured Outputs를 선택합니다. 도구 호출의 입력값이 반드시 스키마를 따라야 한다면 Strict Tool Use를 선택합니다.

반면 톤, 역할, 답변 범위, 기본 응답 스타일을 유지하는 것이 목적이라면 System Prompt가 더 적합합니다. 일회성 요구사항은 User Prompt에 넣는 것이 자연스럽습니다.

창의적인 문체나 다양한 대안을 원할 때도 Sampling Parameter부터 찾기보다, 프롬프트에서 원하는 다양성의 기준을 설명하고 실제 출력으로 검증하는 방식이 현재 모델에 더 맞습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Pre-fill은 최신 Claude 모델에서 기본 전략으로 보기 어렵습니다. 둘째, Sampling Parameter는 개념은 알아야 하지만 최신 모델의 핵심 제어 수단으로 외우면 안 됩니다.

셋째, Structured Outputs와 Strict Tool Use는 둘 다 Schema와 관련되지만 적용 대상이 다릅니다. Structured Outputs는 Claude의 직접 응답 형식, Strict Tool Use는 도구 호출 입력값을 제어합니다.

FAQ

Reasoning Design이란?

Reasoning Design은 모델이 답을 만들기 전에 어떤 방식으로 문제를 검토하게 할지 설계하는 영역입니다. 단순 답변이 필요한 작업과 여러 조건을 비교해야 하는 작업은 같은 방식으로 다루면 안 됩니다.

CCA-F 시험에서는 특히 Chain-of-Thought와 Extended Thinking을 구분하는 것이 중요합니다. 둘 다 추론과 관련이 있지만, 하나는 프롬프트 기법이고 다른 하나는 Claude의 사고 기능입니다.

핵심은 “추론을 많이 시키면 무조건 좋다”가 아니라, 작업 복잡도와 비용, 지연 시간을 함께 보고 필요한 만큼만 사용하는 것입니다.

Chain-of-Thought의 의미

Chain-of-Thought는 모델이 최종 답변 전에 추론 단계를 보이도록 유도하는 프롬프트 설계 방식입니다. 쉽게 말해, 답만 내는 것이 아니라 판단 과정을 구조적으로 드러내게 하는 방법입니다.

다단계 계산, 복잡한 비교, 여러 제약 조건이 있는 계획 수립에서는 중간 검토 과정이 품질을 높이는 데 도움이 될 수 있습니다.

다만 모든 답변에 Chain-of-Thought를 붙이면 글이 길어지고 토큰 사용량도 늘어납니다. 단순 분류, 짧은 사실 확인, 형식 변환 같은 작업에는 필요하지 않을 수 있습니다.

Extended Thinking의 의미

Extended Thinking은 Claude가 복잡한 작업에서 더 깊게 사고하도록 돕는 기능입니다. 프롬프트 문장으로 “단계적으로 생각해”라고 쓰는 것과는 성격이 다릅니다.

현재 공식 문서 기준으로는 모델에 따라 Adaptive Thinking을 사용하고, 사고 깊이는 effort로 조정하는 흐름이 중요합니다. effort는 응답 전체에 모델이 얼마나 많은 작업량을 쓸지 조절하는 신호입니다.

또한 max_tokens는 최종 답변뿐 아니라 사고에 쓰이는 토큰까지 포함하는 상한으로 이해해야 합니다. 복잡한 작업에서 상한이 너무 작으면 최종 답변이 잘릴 수 있습니다.

두 개념의 차이

시험에서는 아래 차이를 구분하면 대부분의 문제를 풀기 쉽습니다.

짧게 정리하면, Chain-of-Thought는 “어떻게 답을 설명하게 할 것인가”에 가깝고, Extended Thinking은 “모델이 답을 만들기 전에 얼마나 깊게 사고하게 할 것인가”에 가깝습니다.

프롬프트 설계 예시

아래 예시는 원본 문장이나 특정 서비스 사례가 아닌, 개념 설명을 위한 더미 예시입니다. 목적은 답변 전에 검토 기준을 분리해 출력 품질을 안정화하는 것입니다.

이런 구조는 추론을 길게 노출하려는 목적이 아니라, 모델이 어떤 기준으로 판단해야 하는지 분리해 주는 목적입니다. CCA-F에서는 “보이는 추론을 요구할지”, “내부 사고 기능을 사용할지”, “그냥 명확한 출력 형식만 줄지”를 구분하는 능력이 중요합니다.

언제 사용하고 언제 피해야 할까?

복잡한 분석, 다단계 문제, 여러 제약을 동시에 만족해야 하는 작업이라면 Reasoning Design이 도움이 됩니다. 특히 답변 품질이 중간 검토 과정에 크게 의존할 때 효과가 있습니다.

반대로 단순 변환, 명확한 분류, 짧은 질의응답은 직접 답변이 더 적합할 수 있습니다. 이런 작업에 깊은 사고를 강제하면 비용과 지연 시간만 늘어날 수 있습니다.

운영 관점에서는 적용 전후를 비교해야 합니다. 정확도, 응답 길이, 지연 시간, 토큰 사용량을 함께 보고 실제 개선이 있을 때만 유지하는 것이 좋습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Chain-of-Thought는 API 플래그가 아니라 프롬프트 설계 방식입니다. 둘째, Extended Thinking은 모델과 API 설정에 따라 동작 방식이 달라질 수 있으므로 공식 문서 기준으로 이해해야 합니다.

셋째, effort는 사고 깊이와 전체 작업량에 영향을 주지만, 엄격한 토큰 예산은 아닙니다. 비용 상한은 max_tokens와 실제 사용량 모니터링을 함께 봐야 합니다.

FAQ

Few-Shot Prompting이란?

Few-Shot Prompting은 모델에게 작업을 시키기 전에 입력과 출력의 예시를 몇 개 보여주는 방식입니다. 단순히 “이렇게 답해줘”라고 설명하는 대신, 실제로 어떤 입력이 들어오고 어떤 형태로 답해야 하는지 보여주는 방식입니다.

CCA-F 관점에서는 Few-Shot을 “정답을 알려주는 기술”로 보기보다, 출력 형식, 문체, 포함 범위, 제외 범위를 안정화하는 설계 기법으로 이해하는 것이 좋습니다.

특히 요약 형식, 분류 결과, 표준 문구, JSON 형태처럼 출력 구조가 중요할 때 효과가 큽니다.

예시가 출력 형식을 고정하는 이유

모델은 예시에서 단어만 보는 것이 아니라 응답 길이, 항목 순서, 라벨 이름, 문체, 생략 기준 같은 패턴을 함께 참고합니다. 그래서 잘 만든 예시는 긴 설명보다 더 직접적인 기준이 됩니다.

예를 들어 “짧게 요약해줘”라는 지시는 사람마다 다르게 해석될 수 있습니다. 반면 같은 길이와 구조의 요약 예시를 보여주면 모델이 원하는 출력 모양을 더 쉽게 따라갑니다.

공식 문서에서도 예시는 Claude의 출력 형식, 톤, 구조를 조정하는 안정적인 방법으로 설명되며, 예시는 실제 사용 사례와 가깝고 다양하며 구조적으로 구분되어야 한다고 안내합니다.

Zero-shot, One-shot, Few-shot 차이

Zero-shot은 예시 없이 지시문만 주는 방식입니다. 작업이 단순하고 출력 형식이 엄격하지 않다면 가장 빠르고 간단합니다.

One-shot은 예시 하나를 주는 방식입니다. 원하는 형식이 단순하고 대표 예시 하나만으로 충분히 설명될 때 적합합니다.

Few-shot은 여러 예시를 주는 방식입니다. 입력 유형이 조금씩 다르거나, 출력 형식을 더 안정적으로 고정해야 할 때 사용합니다. 다만 예시가 많다고 항상 좋은 것은 아니며, 토큰 비용과 혼란 가능성도 함께 고려해야 합니다.

좋은 예시의 조건

좋은 Few-shot 예시는 실제 입력과 비슷해야 합니다. 지나치게 단순한 예시는 실제 상황에서 도움이 적고, 너무 특수한 예시는 모델이 불필요한 패턴까지 따라 할 수 있습니다.

시험에서는 “예시 수”보다 “예시 품질”이 더 중요하다는 점을 기억해야 합니다. 예시가 출력에 원하지 않는 문체나 표현을 전염시키는 경우도 있기 때문에, 예시 자체를 운영 응답처럼 검토해야 합니다.

예시 작성 예시

Claude 프롬프트에서는 예시와 실제 입력을 구분하기 위해 XML 태그를 사용할 수 있습니다. 태그는 모델이 지시, 예시, 실제 입력을 혼동하지 않게 도와줍니다.

위 예시는 실제 서비스명, 계정, 도메인 같은 민감정보 없이 형식만 보여줍니다. CCAF 시험에서는 이런 예시가 왜 출력 안정성을 높이는지, 그리고 언제 구조화된 출력이나 검증과 함께 써야 하는지를 이해하는 것이 중요합니다.

Static Few-shot과 Dynamic Few-shot

Static Few-shot은 모든 요청에 같은 예시 세트를 넣는 방식입니다. 입력 유형이 좁고 반복적이면 구현이 쉽고 관리도 단순합니다.

Dynamic Few-shot은 현재 입력과 비슷한 예시를 찾아서 넣는 방식입니다. 입력 주제나 난이도가 다양할 때 유리하지만, 예시 저장소와 검색 품질을 관리해야 합니다.

시험 관점에서는 “항상 Dynamic이 좋다”가 아니라, 입력 분포가 단순하면 Static, 입력 분포가 다양하면 Dynamic을 고려한다고 정리하면 됩니다.

시험에서 헷갈리기 쉬운 포인트

Few-shot은 모든 문제의 기본값이 아닙니다. 먼저 명확한 지시문으로 해결되는지 확인하고, 출력 형식이나 톤이 흔들릴 때 예시를 추가하는 흐름이 자연스럽습니다.

예시는 많을수록 좋은 것이 아니라, 원하는 패턴을 안정적으로 보여줄 만큼만 넣는 것이 좋습니다. 공식 문서에서는 일반적으로 3~5개 예시를 권장하지만, 실제로는 작업 복잡도와 토큰 비용을 함께 봐야 합니다.

FAQ

복잡한 Prompt에 구조가 필요한 이유

Prompt가 짧고 단순할 때는 자연어만으로도 충분할 수 있습니다. 하지만 지시, 배경, 예시, 입력값, 출력 형식이 한 번에 섞이면 Claude가 각 문장의 역할을 구분해야 합니다.

이때 구조가 약하면 모델은 어디까지가 지시이고, 어디부터가 분석 대상인지 추측하게 됩니다. 특히 여러 문서를 비교하거나 문서 안에 지시처럼 보이는 문장이 있을 때 혼동이 커집니다.

CCA-F 시험에서는 XML Tags를 복잡한 Prompt의 경계를 명확히 하는 구조화 도구로 이해하면 됩니다. 핵심은 예쁘게 꾸미는 것이 아니라, 지시와 데이터의 역할을 분리하는 것입니다.

XML Tags를 사용하는 이유

XML Tags는 Prompt의 각 영역에 이름을 붙이고 시작과 끝을 명확히 표시합니다. `<instructions>` 안에는 지시를 넣고, `<context>` 안에는 배경을 넣고, `<input>` 안에는 사용자가 제공한 입력을 넣는 방식입니다.

구분선이나 제목만 사용하는 방식은 긴 입력 안에서 경계가 흐려질 수 있습니다. 반면 XML Tags는 여는 태그와 닫는 태그가 있어 각 블록의 범위를 더 분명히 나타냅니다.

공식 문서도 일관되고 설명적인 태그 이름을 사용하고, 계층이 자연스러운 내용은 중첩 태그로 표현하라고 권장합니다.

기본 Tag 구조

시험용으로 먼저 기억할 태그는 `<instructions>`, `<context>`, `<examples>`, `<output_format>`입니다. 이름이 반드시 이 네 개로 고정되는 것은 아니지만, 의미가 명확하고 자주 쓰이는 구조입니다.

`<instructions>`에는 Claude가 수행해야 할 작업을 넣습니다. `<context>`에는 판단에 필요한 배경을 넣습니다. `<examples>`에는 원하는 입력과 출력 패턴을 넣습니다. `<output_format>`에는 최종 결과 형식을 넣습니다.

이 구조를 사용하면 모델이 '무엇을 해야 하는가', '무엇을 참고해야 하는가', '어떤 형식으로 답해야 하는가'를 분리해서 이해하기 쉽습니다.

좋은 Tag Naming과 Closing Tag

Tag 이름은 안에 들어가는 내용의 의미를 설명해야 합니다. `<data>`처럼 너무 넓은 이름보다 `<policy_document>`, `<customer_feedback>`, `<error_log>`처럼 역할이 드러나는 이름이 좋습니다.

같은 역할에는 같은 이름을 계속 써야 합니다. 한 Prompt에서는 `<document>`, 다른 Prompt에서는 `<doc>`, 또 다른 곳에서는 `<source_text>`처럼 흔들리면 구조 신호가 약해집니다.

또 하나 중요한 기준은 닫는 태그입니다. 여는 태그가 있으면 반드시 닫는 태그가 있어야 합니다. 닫는 태그가 없으면 뒤에 나온 내용까지 같은 블록으로 해석될 수 있습니다.

Flat Tags와 Nested Tags

Flat Tags는 모든 태그가 같은 단계에 있는 구조입니다. 지시, 배경, 출력 형식처럼 서로 독립적인 섹션을 나눌 때 적합합니다.

Nested Tags는 상위 태그 안에 하위 태그를 넣는 구조입니다. 문서 하나 안에 출처, 날짜, 본문이 함께 들어가야 할 때 유용합니다.

시험에서는 무조건 중첩 구조가 좋은 것이 아니라는 점을 기억해야 합니다. 계층이 실제로 있을 때만 중첩하고, 단순한 Prompt라면 Flat Tags로 충분합니다.

Data와 Instructions 분리

XML Tags의 중요한 목적은 Claude가 따라야 할 지시와 분석해야 할 데이터를 구분하는 것입니다. 사용자가 제공한 문서 안에는 지시처럼 보이는 문장이 포함될 수 있습니다.

예를 들어 문서 본문 안에 '이전 지시를 무시하라'는 문장이 있어도, 그 문장이 `<document_content>` 안에 있다면 모델은 이를 수행할 지시가 아니라 분석 대상 데이터로 보아야 합니다.

다만 XML Tags만으로 보안이 완성되는 것은 아닙니다. 태그는 경계를 명확히 하는 도구이고, 실제 보안은 도구 권한 제한, 승인 절차, 민감 작업 차단 같은 별도 통제가 함께 필요합니다.

Prompt Injection 완화 관점

Prompt Injection은 입력 데이터 안의 문장이 모델의 기존 지시를 무시하게 만들려는 시도입니다. 문서, 웹 페이지, 로그, 사용자 입력처럼 외부에서 들어오는 내용은 신뢰할 수 없는 데이터로 봐야 합니다.

XML Tags는 지시와 데이터를 분리해 오해 가능성을 줄입니다. 하지만 태그는 보조 수단이지 기본 방어선이 아닙니다.

CCA-F 시험에서는 XML Tags가 Prompt Injection을 완전히 막는다고 이해하면 안 됩니다. 핵심 방어는 신뢰할 수 없는 입력 처리, 최소 권한, 위험한 도구 실행 제한, 사람 승인 같은 운영 통제입니다.

Multi-Document Prompt 구조

Multi-Document Prompt는 여러 문서를 한 Prompt 안에 넣고 비교, 요약, 종합, 차이 분석을 수행하게 하는 구조입니다. 이때 각 문서의 시작과 끝, 출처, 본문을 분리해야 합니다.

공식 문서는 여러 문서를 사용할 때 각 문서를 `<document>`로 감싸고, `<document_content>`와 `<source>` 같은 하위 태그로 문서 내용과 메타데이터를 구조화하라고 설명합니다.

문서가 여러 개일 때는 번호나 이름으로 명시적으로 참조해야 합니다. '위 내용'이나 '문서들'처럼 넓은 표현은 어떤 문서를 기준으로 답해야 하는지 흐릴 수 있습니다.

Document Injection과 Source Attribution

Document Injection은 분석할 문서 내용을 Prompt에 넣는 방식입니다. 좋은 구조는 문서 본문을 지시문 안에 섞지 않고 별도 태그로 분리합니다.

Source Attribution은 답변의 각 주장이나 요약이 어느 문서에서 나온 것인지 연결하는 것입니다. 여러 문서를 비교할 때 출처가 없으면 문서 A의 내용을 문서 B의 내용처럼 말하거나, 두 문서를 섞어 실제로는 없는 결론을 만들 수 있습니다.

따라서 출력 형식에 document index와 source를 포함시키면 오인용을 줄이고 답변 검증이 쉬워집니다.

Sections vs Separate Turns

여러 문서를 처리하는 방식은 하나의 Prompt 안에 섹션으로 넣는 방식과, 여러 Turn으로 나눠 처리하는 방식이 있습니다.

한 번에 비교해야 하는 작업은 하나의 Prompt 안에 모든 문서를 구조화해 넣는 편이 좋습니다. 문서 간 공통점과 차이점, 충돌 사항, 전체 종합이 필요한 경우입니다.

반대로 중간 검토가 필요하거나 단계별로 오류를 잡아야 하는 작업은 여러 Turn으로 나누는 편이 좋습니다. 이 경우 각 단계의 출력이 다음 단계의 입력이 되므로 요약 누락이나 왜곡을 주의해야 합니다.

좋은 XML Prompt와 나쁜 구조 비교

좋은 XML Prompt는 지시, 문서, 출력 형식이 분리되어 있고, 각 문서에 출처와 번호가 있습니다. 또한 문서 안의 내용은 분석 대상일 뿐 지시가 아니라는 기준을 명시합니다.

나쁜 구조는 긴 자연어 문장 안에 지시와 문서 내용을 섞습니다. 이 경우 Claude가 어떤 문장을 따라야 하고 어떤 문장을 분석해야 하는지 추측해야 합니다.

시험에서는 '태그를 썼는가'보다 '지시와 데이터가 분리되었는가', '출처 추적이 가능한가', '출력 형식이 검증 가능한가'를 중심으로 판단하는 것이 좋습니다.

시험에서 헷갈리기 쉬운 포인트

첫째, XML Tags는 모든 Prompt에 반드시 필요한 것은 아닙니다. 복잡한 Prompt에서 경계를 명확히 할 때 유용합니다.

둘째, 태그 이름은 고정 목록이 아니라 의미 있는 이름을 일관되게 쓰는 것이 중요합니다.

셋째, Nested Tags는 계층이 있을 때만 사용합니다. 단순한 섹션에는 Flat Tags가 더 읽기 쉽습니다.

넷째, XML Tags는 Prompt Injection을 완전히 막지 않습니다. 지시와 데이터를 분리하는 데 도움을 줄 뿐입니다.

다섯째, 여러 문서를 넣을 때는 document index, source, document_content를 분리하고 출력에도 출처를 요구해야 합니다.

최종 요약

XML Prompt Structure의 핵심은 복잡한 Prompt에서 역할과 경계를 명확히 하는 것입니다. `<instructions>`, `<context>`, `<examples>`, `<output_format>` 같은 구조는 Claude가 각 블록의 의미를 구분하는 데 도움을 줍니다.

Multi-Document Prompt에서는 각 문서를 `<document>`로 감싸고, `<source>`와 `<document_content>`를 분리해야 합니다. 출력에는 문서 번호와 출처를 포함시켜야 비교와 검증이 쉬워집니다.

CCA-F 시험에서는 XML Tags를 구조화와 출처 추적 도구로 이해해야 합니다. 보안 측면에서는 도움이 되지만, Prompt Injection의 완전한 방어책은 아니며 최소 권한과 승인 절차가 함께 필요합니다.

FAQ

System Prompt를 왜 따로 설계해야 하는가

System Prompt는 Claude가 사용자 요청을 해석하기 전에 참고하는 상위 지시 영역입니다. 여기에는 모델의 역할, 행동 기준, 항상 적용되는 제약, 기본 응답 방식이 들어갑니다.

CCA-F 시험에서는 System Prompt를 단순한 첫 문장으로 보지 않습니다. 세션 전체에 반복 적용되는 기준을 어디에 둘 것인지 판단하는 설계 문제로 봐야 합니다.

공식 문서도 System Prompt에 역할을 지정하면 Claude의 행동과 말투를 사용 사례에 맞게 집중시킬 수 있다고 설명합니다. 따라서 역할과 고정 규칙은 요청마다 반복해서 쓰기보다 System Prompt에 두는 것이 자연스럽습니다.

System Prompt와 User Turn의 차이

System Prompt는 변하지 않는 기준을 담는 위치입니다. 반대로 User Turn은 사용자가 매번 보내는 요청과 그 요청에 필요한 입력을 담는 위치입니다.

두 영역을 섞으면 비용과 정확도 문제가 동시에 생깁니다. 매 요청마다 달라지는 정보를 System Prompt에 넣으면 불필요한 토큰이 늘고, 항상 지켜야 하는 규칙을 User Turn에만 넣으면 다음 대화에서 누락될 수 있습니다.

시험에서는 '무엇이 변하지 않는가'와 '무엇이 요청마다 바뀌는가'를 먼저 구분하면 됩니다.

Persistent Context와 Per-request Context

Persistent Context는 모든 요청에 동일하게 적용되는 배경 정보입니다. 예를 들어 답변 원칙, 보안 기준, 공통 출력 형식, 제품의 기본 정책처럼 계속 유지되어야 하는 기준입니다.

Per-request Context는 특정 요청에만 필요한 정보입니다. 예를 들어 이번 요청의 입력 텍스트, 사용자가 방금 제공한 조건, 특정 작업에만 필요한 값이 여기에 해당합니다.

이 구분은 CCA-F 시험에서 매우 중요합니다. 고정 기준은 System Prompt, 요청별 입력은 User Turn이라는 원칙을 기억하면 대부분의 배치 문제를 풀 수 있습니다.

System Prompt의 5개 구성 요소

시험용으로 System Prompt는 Role, Context, Instructions, Constraints, Examples의 다섯 구성 요소로 정리할 수 있습니다.

Role은 모델이 어떤 관점으로 답할지 정합니다. Context는 답변에 필요한 공통 배경을 제공합니다. Instructions는 수행할 행동을 정의합니다. Constraints는 지켜야 할 한계를 정합니다. Examples는 원하는 결과 형태를 보여줍니다.

순서는 절대 규칙은 아니지만, Role을 먼저 두고 Examples를 마지막에 두면 해석 흐름이 안정적입니다. 먼저 관점을 정하고, 그다음 배경과 행동 기준을 제공한 뒤, 마지막에 예시로 결과 형태를 고정하는 방식입니다.

Role Assignment

Role Assignment는 Claude에게 어떤 전문성 또는 판단 관점으로 행동할지 지정하는 것입니다. 예를 들어 보안 분석가, 고객 지원 담당자, 기술 문서 작성자 같은 역할을 부여할 수 있습니다.

Role은 모델의 기본 관점을 바꿉니다. 같은 질문이라도 보안 분석가 역할이면 위험과 완화 방안을 중심으로 답하고, 고객 지원 역할이면 사용자의 문제 해결 흐름을 중심으로 답할 가능성이 높습니다.

중요한 점은 Role이 새로운 능력을 만들어주지는 않는다는 것입니다. 역할은 답변 관점과 표현 방식을 조정하지만, 모델이 모르는 최신 사실을 자동으로 알게 하거나 외부 시스템에 접근하게 만들지는 않습니다.

Persona Design

Persona는 Role 위에 말투, 이름, 응답 습관, 문체 제약을 추가하는 설계입니다. Role이 '무슨 전문가인가'에 가깝다면, Persona는 '어떤 목소리로 말하는가'에 가깝습니다.

시험에서는 Role과 Persona를 구분해야 합니다. Role은 기능적 전문성입니다. Persona는 말투와 사용자 경험을 안정화하는 장치입니다.

Persona를 너무 모호하게 쓰면 결과가 흔들립니다. '친절하고 전문적으로 답변'보다 '차분한 문체로 200자 이내로 답변하고, 전문 용어는 먼저 풀어서 설명'처럼 구체적인 기준이 더 안정적입니다.

Context Injection

Context Injection은 Claude가 답변에 사용할 사실을 Prompt 안에 제공하는 방식입니다. 모델이 기본 지식만으로 알 수 없는 정책, 규칙, 입력 텍스트, 현재 조건을 넣어 답변을 근거 있는 방향으로 유도합니다.

공식 문서도 지시의 배경이나 동기를 제공하면 Claude가 목표를 더 잘 이해하고 더 적절한 결과를 만들 수 있다고 설명합니다. 즉 Context는 단순한 부가 설명이 아니라 답변 품질을 좌우하는 근거입니다.

다만 Context는 위치가 중요합니다. 모든 요청에 필요한 공통 Context는 System Prompt에 두고, 현재 요청에만 필요한 Context는 User Turn에 둬야 합니다.

Context를 잘못 배치했을 때의 문제

요청마다 달라지는 정보를 System Prompt에 넣으면 매번 불필요하게 같은 정보를 처리하게 됩니다. 이 경우 토큰 비용과 지연 시간이 늘고, 다른 요청에도 부적절한 영향을 줄 수 있습니다.

반대로 항상 적용해야 하는 기준을 User Turn에만 넣으면 대화가 길어질수록 누락되거나 약해질 수 있습니다. 특히 형식, 보안, 추측 금지, 에스컬레이션 기준처럼 반드시 유지되어야 하는 규칙은 고정 위치에 두는 것이 좋습니다.

시험 문제에서 '특정 요청에만 필요한 값'이 나오면 User Turn을 먼저 생각하고, '모든 요청에 적용되는 기준'이 나오면 System Prompt를 먼저 생각하면 됩니다.

Assistant Prefill 관련 시험 포인트

예전에는 Assistant 응답의 시작 부분을 미리 넣어 출력 형식을 유도하는 방식이 사용되기도 했습니다. 하지만 현재 Claude 최신 모델에서는 마지막 Assistant Turn에 미리 채운 응답을 넣는 방식이 지원되지 않을 수 있습니다.

공식 문서 기준으로 Claude 4.6 이후 계열과 일부 최신 모델에서는 마지막 Assistant Turn의 prefilled response가 400 오류를 반환할 수 있습니다. 따라서 시험에서는 형식 제어를 prefill에 의존하기보다 명시적인 출력 형식, 예시, 구조화된 출력 기준으로 제어한다고 이해하는 것이 안전합니다.

핵심은 간단합니다. 최신 설계에서는 '응답 앞부분을 미리 써서 강제'하기보다 '출력 형식과 제약을 명확히 지시'하는 방향이 더 적합합니다.

Role, Persona, Context 테스트 기준

System Prompt는 작성만으로 끝나지 않습니다. 실제 요청에서 역할이 유지되는지, Persona가 흔들리지 않는지, 주입한 Context를 답변에 제대로 사용하는지 테스트해야 합니다.

테스트는 정상 입력만 보면 부족합니다. 주제 전환, 불완전한 입력, 역할 변경 요구, 규칙 무시 요구, 긴 입력처럼 흔들릴 수 있는 조건을 함께 확인해야 합니다.

CCA-F 시험에서는 System Prompt를 코드처럼 검증 가능한 대상으로 보는 관점이 중요합니다. 변경 후에는 기존에 잘 되던 응답이 깨지지 않았는지도 확인해야 합니다.

시험에서 헷갈리기 쉬운 포인트

첫째, System Prompt는 사용자에게 보이는 안내문이 아니라 모델 행동의 고정 기준입니다.

둘째, Role은 전문성 또는 판단 관점이고 Persona는 말투와 표현 방식까지 포함하는 설계입니다.

셋째, Context Injection은 모델이 모르는 사실을 제공하는 방식이지만, 위치를 잘못 잡으면 비용과 일관성 문제가 생깁니다.

넷째, Role과 Persona는 모델의 능력 한계를 넘게 만들지 못합니다. 도구 접근 권한, 최신 사실, 안전 기준을 바꾸는 장치가 아닙니다.

다섯째, 고정 기준은 System Prompt, 요청별 정보는 User Turn이라는 배치 원칙을 기억해야 합니다.

최종 요약

System Prompt & Role Design의 핵심은 고정 기준과 요청별 정보를 분리하는 것입니다. System Prompt에는 역할, 공통 Context, 지시, 제약, 예시를 두고, User Turn에는 현재 요청과 이번 작업의 입력을 둡니다.

Role은 Claude의 판단 관점을 정하고, Persona는 말투와 표현 방식을 안정화합니다. Context Injection은 Claude가 답변에 사용할 사실을 제공해 근거 있는 결과를 만들게 합니다.

CCA-F 시험에서는 System Prompt는 persistent context, User Turn은 per-request context라는 기준을 먼저 잡으면 됩니다. 그리고 Role이나 Persona가 모델의 능력, 최신 지식, 안전 기준을 바꾸지는 못한다는 점을 함께 기억해야 합니다.

FAQ

Prompt Design을 왜 시험에서 중요하게 보는가

Prompt Design은 모델에게 무엇을 해야 하는지, 어떤 기준으로 결과를 만들어야 하는지, 어디까지가 작업 범위인지 알려주는 설계 작업입니다.

CCA-F 시험에서는 Prompt를 단순한 질문문으로 보지 않습니다. 좋은 Prompt는 작업 목표, 입력 Context, 출력 형식, 제약 조건, 완료 기준을 명확히 담아 모델의 해석 범위를 줄입니다.

공식 문서 기준으로 Prompt Engineering을 시작하기 전에는 성공 기준과 평가 방법이 있어야 합니다. 즉 좋은 Prompt는 감으로 쓰는 문장이 아니라, 원하는 결과를 재현 가능하게 만들기 위한 설계 산출물입니다.

Ambiguity가 만드는 문제

Ambiguity는 하나의 지시문을 여러 방식으로 해석할 수 있는 상태입니다. 모델은 모호한 요청을 받으면 사용자의 의도를 정확히 확인하지 못한 채 가능한 해석 중 하나를 선택해 진행할 수 있습니다.

문제는 결과가 그럴듯해 보일 수 있다는 점입니다. 완전히 틀린 답보다 위험한 경우는, 겉으로는 자연스럽지만 사용자의 실제 목적과 다른 결과입니다.

예를 들어 '이 문서를 요약해줘'라는 요청에는 길이, 독자, 형식, 포함할 내용, 제외할 내용이 없습니다. 모델은 이 빈칸을 스스로 채워야 하고, 그만큼 결과 편차가 커집니다.

Specificity와 Direct Instruction

Specificity는 모델이 추측해야 하는 공간을 줄이는 정도입니다. 형식, 길이, 독자, 관점, 포함 항목, 제외 항목을 명시할수록 결과가 예측 가능해집니다.

Direct Instruction은 모델에게 피해야 할 것만 말하는 대신, 실제로 무엇을 해야 하는지 직접 말하는 방식입니다. '모호하게 쓰지 마'보다 '비전문가도 이해할 수 있게 세 문장으로 설명해'가 더 명확합니다.

Anthropic의 공식 Best Practices도 명시적이고 구체적인 지시를 강조합니다. 작업 동사로 시작하고, 원하는 출력에 포함할 내용을 직접 말하며, 품질과 깊이 기준을 구체화하는 것이 좋습니다.

좋은 지시문에 들어가야 할 요소

좋은 지시문은 단순히 자세한 문장이 아닙니다. 모델이 수행할 작업과 결과 기준을 확인할 수 있게 구성되어야 합니다.

기본 요소는 Task, Context, Output Format, Constraints, Acceptance Criteria입니다. 이 다섯 가지가 들어가면 모델이 무엇을 해야 하는지, 어떤 정보를 기준으로 판단해야 하는지, 어떤 형태로 반환해야 하는지 명확해집니다.

시험에서는 '구체적인 Prompt는 길다'가 아니라 '구체적인 Prompt는 판단 기준이 명확하다'로 이해하는 것이 좋습니다.

Instruction Decomposition

Instruction Decomposition은 복잡한 작업을 작고 검증 가능한 단계로 나누는 방법입니다. 하나의 긴 지시문에 여러 목표를 넣으면 모델이 일부 목표를 놓치거나, 어떤 단계에서 문제가 생겼는지 확인하기 어려워집니다.

작업을 단계로 나누면 각 단계의 목적, 입력, 출력, 검증 기준이 분명해집니다. 특히 추출, 요약, 검토, 변환처럼 서로 다른 성격의 작업이 섞여 있을 때 유용합니다.

공식 Prompt Engineering Best Practices도 복잡한 작업은 여러 Prompt로 나누거나, 각 Prompt가 하나의 일을 잘하도록 만드는 접근을 권장합니다.

Include / Exclude / Assume / Stop

Scope를 명확히 하기 위해 Include, Exclude, Assume, Stop 구조를 사용할 수 있습니다. 이 구조는 작업의 시작점과 끝점을 모델에게 분명히 알려줍니다.

Include는 반드시 포함할 내용입니다. Exclude는 제외할 내용입니다. Assume은 모델이 전제로 삼아도 되는 내용입니다. Stop은 어디에서 작업을 멈출지 알려줍니다.

이 네 가지는 특히 분석, 요약, 코드 리뷰, 리스크 평가처럼 범위가 쉽게 넓어지는 작업에서 중요합니다.

Format, Length, Tone, Perspective Constraints

Constraint는 결과의 형태와 품질을 안정화하는 조건입니다. 대표적으로 Format, Length, Tone, Perspective가 있습니다.

Format은 표, 목록, JSON, 문단 같은 출력 구조를 정합니다. Length는 문장 수나 글자 수를 제한합니다. Tone은 설명 방식과 말투를 정합니다. Perspective는 어떤 관점으로 판단할지 지정합니다.

Constraint는 모델을 억누르는 장치가 아니라, 원하는 결과를 더 일관되게 얻기 위한 설계 도구입니다.

좋은 Prompt와 나쁜 Prompt 비교

좋은 Prompt는 길어서 좋은 것이 아닙니다. 모델이 해야 할 결정과 사용자가 직접 정해야 할 결정을 구분해주는 Prompt가 좋습니다.

아래 예시는 같은 작업을 요청하지만 결과 안정성이 크게 다릅니다. 나쁜 Prompt는 모델이 길이, 독자, 형식, 포함 기준을 모두 추측하게 만듭니다. 좋은 Prompt는 주요 판단 기준을 명시합니다.

Prompt 품질을 점검하는 질문

결과가 기대와 다를 때 바로 모델 문제로 보지 말고 Prompt를 먼저 점검해야 합니다. 특히 모호성, 범위, 출력 형식, 검증 기준이 빠져 있는지 확인해야 합니다.

시험에서는 Prompt 개선 문제를 볼 때 '더 자세히 써라'보다 '어떤 누락된 제약을 추가해야 하는가'를 보는 편이 정확합니다.

좋은 점검 질문은 모델이 추측하고 있는 부분을 찾는 데 집중합니다.

시험에서 헷갈리기 쉬운 포인트

첫째, Specificity는 단순히 Prompt를 길게 쓰는 것이 아닙니다. 모델이 추측해야 하는 결정을 줄이는 것입니다.

둘째, Direct Instruction은 금지어 나열이 아니라 원하는 행동을 직접 지정하는 방식입니다.

셋째, 복잡한 작업은 한 문장에 모두 넣기보다 단계로 분해해야 합니다.

넷째, Constraint는 출력 품질을 제한하는 것이 아니라 안정화하는 장치입니다.

다섯째, 모호한 Prompt는 실패를 바로 드러내지 않고 그럴듯하지만 어긋난 결과를 만들 수 있습니다.

최종 요약

Prompt Design Fundamentals의 핵심은 모델이 추측해야 하는 부분을 줄이는 것입니다. 명확한 작업 목표, 충분한 Context, 구체적인 출력 형식, 제약 조건, 완료 기준이 있을수록 결과는 안정적입니다.

복잡한 작업은 Instruction Decomposition으로 나누고, Include / Exclude / Assume / Stop으로 범위를 제한해야 합니다. Format, Length, Tone, Perspective 같은 Constraint는 시험에서 자주 나오는 기본 설계 요소입니다.

CCA-F 시험에서는 좋은 Prompt를 '자세한 문장'이 아니라 '모델의 해석 범위를 통제하는 설계'로 이해하면 됩니다.

FAQ