AI 프롬프트 아키텍처와 평가
LLM의 출력 품질과 안전성을 재현 가능하게 설계하려면? 핵심 이론부터 사례 분석, 단계별 실습, 품질 검수, 종합 문제까지 혼자 학습할 수 있도록 구성한 전공 실습 교재입니다.
오늘의 질문과 학습목표
LLM의 출력 품질과 안전성을 재현 가능하게 설계하려면? 이 질문에 자신의 말로 답할 수 있고, 설계 결과물을 직접 만들고 검수하는 것이 오늘의 완료 기준입니다.
시스템·사용자·도구 지시의 역할을 구분한다.
목표·맥락·제약·출력 형식을 구조화한다.
프롬프트 인젝션과 데이터 경계를 설명한다.
근거 없는 추론을 줄이는 검증 규칙을 작성한다.
평가 데이터와 채점 기준을 만든다.
실패 사례를 이용해 프롬프트를 반복 개선한다.
혼자 공부하는 순서
- 용어를 암기하기 전에 사례에서 문제가 생기는 이유를 설명합니다.
- 좋은 예와 나쁜 예의 차이를 관찰 가능한 기준으로 적습니다.
- 예시를 보지 않고 종합 실습을 먼저 해결합니다.
- 모범답안과 비교한 뒤 빠진 조건을 다른 색으로 보완합니다.
교재 목차
- 학습 안내와 학습목표Page 02
- 제1장. 핵심 이론과 설계 원칙Page 04
- 제2장. 단계별 설계 실습Page 05
- 제3장. 사례 분석과 품질 검수Page 06
- 제4장. 종합 실습과 모범답안Page 07
- 핵심 용어와 최종 점검Page 08
- 자기주도 심화학습과 안내형 실습Pages 09–11
종합 실습 결과물, 자가진단 80점 이상, 핵심 질문 4개에 대한 자신의 답을 남기면 Day 5 학습을 완료한 것입니다.
AI 프롬프트 아키텍처와 평가 핵심 이론
전문 용어는 복잡해 보이지만, 각 용어는 설계에서 반복되는 한 가지 문제를 해결하기 위해 존재합니다. 아래 표에서 “무엇을 뜻하는가”보다 “언제 필요한가”를 중심으로 학습하세요.
| 핵심 개념 | 설명 |
|---|---|
| Instruction Hierarchy | 여러 지시가 충돌할 때 적용되는 우선순위입니다. |
| Context | 모델이 답을 만들 때 참고하는 자료입니다. |
| Constraint | 하지 말아야 할 것과 반드시 지킬 조건입니다. |
| Output Contract | 형식, 필드, 길이, 허용값을 명시한 출력 계약입니다. |
| Prompt Injection | 외부 데이터가 지시처럼 작동해 원래 규칙을 우회하는 공격입니다. |
| Evaluation | 정답 예시와 기준으로 품질을 반복 측정하는 과정입니다. |
좋은 설계와 나쁜 설계의 차이
피해야 할 접근
“아주 완벽하고 전문적으로 분석해줘”처럼 목표와 성공 기준 없이 형용사만 늘린다.
권장 접근
입력 범위, 역할, 금지사항, JSON 스키마, 근거 표기, 불확실할 때의 행동을 명시한다.
[역할] + [목표] + [입력 경계] + [절차] + [제약] + [출력 계약] + [검증 기준]
단계별 설계 절차
문제 정의
사용자가 얻어야 할 관찰 가능한 결과를 정의한다.
구조 추출
신뢰할 수 있는 지시와 신뢰할 수 없는 외부 데이터를 분리한다.
핵심 설계
필요한 맥락만 제공하고 출처를 표시한다.
실패 조건
금지 행동과 불확실할 때의 응답 방식을 적는다.
정책 연결
JSON 또는 Markdown 출력 계약과 예시를 제공한다.
검증과 추적
정상·경계·공격 입력을 포함한 평가 세트로 반복 측정한다.
작동하는 예시
예시를 읽을 때 확인할 것
- 입력과 시작 조건이 명확한가?
- 정상 결과뿐 아니라 실패 결과도 관찰 가능한가?
- 중복·권한·동시성·외부 장애가 필요한 수준으로 다뤄졌는가?
- 요구사항과 구현 결과를 서로 추적할 수 있는가?
사례 분석과 품질 검수
스스로 설명해 보기
- 프롬프트가 길수록 항상 좋은가?
- 예시(few-shot)가 필요한 조건은?
- 외부 문서를 지시와 분리해야 하는 이유는?
- 정확도 외에 평가해야 할 항목은?
각 질문에 2~3문장으로 답하고, 답을 뒷받침하는 사례를 하나씩 적으세요.
품질 자가진단 · 100점
| 영역 | 판단 기준 | 점수 |
|---|---|---|
| 정확성 | 개념과 기술 선택이 요구사항 및 사실에 맞는다. | 25 |
| 완전성 | 정상 흐름, 경계 조건, 실패와 복구를 함께 다룬다. | 25 |
| 일관성 | 용어, ID, 상태, 인터페이스가 산출물 사이에서 일치한다. | 20 |
| 검증 가능성 | 관찰 가능한 결과와 완료 기준을 제시한다. | 20 |
| 설명력 | 선택한 방법과 대안의 차이를 자신의 말로 설명한다. | 10 |
틀린 결과만 고치지 말고, 빠진 질문이 무엇이었는지 기록하세요. 좋은 엔지니어는 정답을 외우기보다 다음 설계에서 같은 누락을 막는 점검 기준을 만듭니다.
종합 실습과 모범답안
고객 문의를 긴급도별로 분류하는 시스템 프롬프트를 작성하고, 정상 2개·모호한 입력 1개·인젝션 입력 1개로 평가하세요.
- 핵심 가정과 미결정 사항을 먼저 적습니다.
- 주요 설계 결과물을 표, 코드 또는 다이어그램으로 작성합니다.
- 정상 흐름과 최소 3개의 실패·경계 조건을 포함합니다.
- 자가진단표로 채점하고 개선 전후를 비교합니다.
모범답안의 핵심 방향 보기
출력 라벨과 판정 기준을 먼저 고정하고 evidence와 confidence를 반환하게 합니다. “이전 지시를 무시하라” 같은 고객 문의 내용은 데이터로만 취급해야 하며, 모호한 경우 human_review 라벨로 보내는 것이 안전합니다.
답안 사용법
모범답안은 유일한 정답이 아닙니다. 자신의 설계가 다른 경우에는 요구사항, 비용, 복잡도, 위험 중 어떤 근거로 다른 선택을 했는지 설명할 수 있어야 합니다.
핵심 용어와 최종 점검
| 용어 | 쉽게 말하면 |
|---|---|
| System Prompt | 모델의 기본 역할과 상위 규칙 |
| Few-shot | 입출력 예시로 패턴을 알려주는 방식 |
| Grounding | 제공된 근거에 답을 연결하는 방법 |
| Hallucination | 근거 없이 사실처럼 생성한 내용 |
| Injection | 외부 입력으로 지시를 우회하려는 공격 |
| Eval | 품질을 반복 측정하는 평가 체계 |
제출 전 8문항
- 오늘의 핵심 질문에 자신의 말로 답할 수 있는가?
- 설계의 입력, 조건, 결과가 명확한가?
- 정상 흐름뿐 아니라 실패와 복구를 포함했는가?
- 동시성, 중복 요청, 권한 문제를 검토했는가?
- 외부 시스템 장애와 타임아웃을 고려했는가?
- 선택한 방법의 단점과 대안을 설명할 수 있는가?
- 산출물 사이의 용어와 상태가 일치하는가?
- 테스트하거나 관찰할 수 있는 완료 기준이 있는가?
LLM의 출력 품질과 안전성을 재현 가능하게 설계하려면? 오늘 만든 결과물을 근거로 이 질문에 답해 보세요.
맥락으로 이해하는 핵심 용어
용어를 정의만 외우지 말고 판단 도구로 익히세요. 각 행을 정의→필요한 이유→예시 또는 주의점 순서로 읽습니다.
| 용어 | 쉬운 정의 | 왜 중요한가 | 예시 또는 주의점 |
|---|---|---|---|
| 시스템 프롬프트 | 모델의 역할·우선순위·금지 사항을 정하는 상위 지침 | 일관된 동작과 안전 경계를 설정 | 사용자 입력과 충돌할 때 우선순위를 명확히 한다. |
| 컨텍스트 | 응답에 필요한 배경 정보와 현재 상태 | 모델이 추측하지 않고 근거를 사용하게 함 | 필요한 정보만 구조화해 제공한다. |
| Few-shot | 입력과 기대 출력의 예시를 몇 개 제공하는 기법 | 형식과 판단 기준을 빠르게 학습시킴 | 예시가 편향되면 같은 편향이 반복된다. |
| 환각 | 근거 없이 사실처럼 생성한 잘못된 내용 | AI 기능의 신뢰성과 직결 | 출처 요구·검색·검증 단계로 줄인다. |
| 평가 루브릭 | 좋은 출력의 기준과 점수를 미리 정의한 표 | 감상이 아닌 반복 가능한 평가를 가능하게 함 | 정확성·완전성·형식 준수를 분리한다. |
| 프롬프트 인젝션 | 외부 입력이 기존 지침을 무시하도록 유도하는 공격 | 도구·데이터 접근 기능에서 특히 위험 | 외부 콘텐츠를 지침이 아닌 데이터로 취급한다. |
고객 문의를 요약하고 답변 초안을 만드는 AI가 개인정보를 노출하지 않으면서 근거 있는 답만 작성해야 한다.
안내형 실습과 문제 해결
실습 상황
고객 문의를 요약하고 답변 초안을 만드는 AI가 개인정보를 노출하지 않으면서 근거 있는 답만 작성해야 한다.
순서대로 수행하기
- 역할·목표·입력·출력 형식·금지 사항을 분리해 적는다.
- 좋은 예와 실패 예를 포함한 테스트 세트를 만든다.
- 정확성·근거성·안전성·형식 점수를 각각 측정한다.
- 실패 원인을 프롬프트·데이터·모델·후처리 중 하나로 분류해 개선한다.
산출물 1개, 핵심 가정 3개, 실패 사례 3개 이상을 저장하세요. 다른 학습자가 추가 질문 없이 판단 과정을 재현할 수 있어야 합니다.
결과가 다를 때 진단하기
| 관찰한 증상 | 가능한 원인 | 다음 조치 |
|---|---|---|
| 없는 정책을 만들어냄 | 근거 사용 규칙 없음 | 근거 없으면 모른다고 답하도록 설정 |
| 출력 형식이 매번 다름 | 스키마·예시 부족 | JSON 스키마와 유효성 검사 |
| 문서 속 지시를 따름 | 신뢰 경계 혼동 | 검색 문서를 데이터로 감싸고 도구 권한 제한 |
스스로 이해도 확인하기
인출 연습 — 펼치기 전에 답하기
좋은 프롬프트가 길기만 하면 되는가?
아닙니다. 필요한 제약이 명확하고 서로 충돌하지 않으며 평가 가능한 것이 중요합니다.
온도는 무엇을 바꾸나?
출력 선택의 다양성을 조절하지만 사실 정확성을 보장하지는 않습니다.
평가 완료 기준은?
대표·경계·공격 사례에서 정한 품질과 안전 기준을 반복해서 충족해야 합니다.
페이지를 보지 않고 오늘의 핵심 판단, 대표 실패 원인, 검증 방법을 연결해 설명하세요. 세 가지가 이어지지 않으면 놓친 용어나 진단 사례로 돌아갑니다.