생성형 AI를 처음 사용했을 때가 기억이 나는가

질문만 입력하면 알아서 좋은 답을 만들어 줄 것이라고 생각하기 쉽다.

하지만 실제로 사용해 보면 같은 모델이라도 질문을 어떻게 작성했는지, 어떤 정보를 함께 제공했는지에 따라 결과가 크게 달라진다.

이번 주차에서는 단순히 “프롬프트를 잘 작성하는 법”을 넘어 다음 내용을 학습했다.

생성형 AI와 LLM은 어떤 원리로 동작하는가?
왜 생성형 AI는 틀린 내용을 그럴듯하게 말하는가?
좋은 프롬프트는 어떤 구조로 작성해야 하는가?
Prompt Engineering과 Context Engineering의 차이는 무엇인가?
AI Agent를 안정적으로 운영하기 위해 무엇이 필요한가?

이번 글에서는 생성형 AI의 기본 원리부터 Prompt Engineering, Context Engineering, Harness Engineering까지 전체 흐름을 정리해 본다.

1. 소프트웨어 개발 방식의 변화

전통적인 소프트웨어는 사람이 요구사항과 규칙을 직접 정의하고, 이를 함수와 조건문으로 구현하는 방식이었다.

예를 들어 고객 등급을 구분하는 프로그램을 만든다면 다음과 같이 규칙을 직접 작성할 수 있다.

구매금액이 100만 원 이상이면 VIP
구매금액이 50만 원 이상이면 GOLD
그 외에는 NORMAL

이 방식에서는 개발자가 모든 규칙을 명확하게 정의해야 한다.

반면 머신러닝과 딥러닝에서는 사람이 규칙을 직접 작성하기보다 데이터를 제공하고, 모델이 데이터에 포함된 패턴을 학습하도록 한다.

전통적인 개발

규칙 + 데이터
→ 프로그램
→ 결과

머신러닝

데이터 + 결과
→ 학습
→ 규칙을 포함한 모델

LLM 시대에는 여기서 한 단계 더 변화했다.

특정 문제만 해결하도록 모델을 매번 새롭게 학습시키는 대신, 대규모 데이터로 사전학습된 범용 모델에게 자연어로 문제를 설명하고 결과를 요청한다.

즉, 중요한 능력이 다음과 같이 변하고 있다.

문제를 직접 푸는 방법을 프로그래밍하는 능력
→ 모델이 이해할 수 있도록 문제를 설명하는 능력

지도학습 중심의 방식에서 LLM 활용 방식으로 이동하면서, 앞으로는 “문제를 푸는 법”뿐 아니라 “문제를 설명하는 법”이 중요해진다고 정리한다.

2. AI의 발전 방향

AI는 크게 다음과 같은 방향으로 발전하고 있다.

인지 AI
→ 생성형 AI
→ Agentic AI
→ Physical AI

인지 AI

이미지, 음성, 텍스트 등에 포함된 패턴을 인식한다.

이미지 분류
음성 인식
객체 탐지
의료 영상 판독

생성형 AI

학습한 데이터의 패턴을 바탕으로 새로운 결과를 생성한다.

텍스트 생성
이미지 생성
코드 생성
문서 요약
질의응답

Agentic AI

질문에 답하는 것을 넘어 목표를 달성하기 위한 작업을 직접 계획하고 실행한다.

예를 들어 여행 일정을 작성하는 수준을 넘어 항공편을 검색하고, 호텔을 비교하고, 일정표를 작성하는 여러 단계를 수행한다.

Physical AI

AI가 디지털 환경을 넘어 실제 물리 환경에서 판단하고 행동한다.

자율주행 자동차
산업용 로봇
휴머노이드
물류 자동화 시스템

이러한 발전은 AI가 단순히 답변을 생성하는 존재에서 지시를 따르는 존재, 나아가 목표를 달성하는 존재로 변화하고 있음을 의미한다.

3. 생성형 AI가 잘하는 작업

생성형 AI가 잘 수행하는 작업은 크게 네 가지로 정리할 수 있다.

작업	설명	예시
생성	새로운 결과물을 만듦	글, 코드, 이미지, 아이디어 생성
검색	필요한 정보를 찾아옴	정보 탐색, 문서 검색, 근거 수집
요약	긴 정보를 핵심만 남김	문서 요약, 회의록 정리
추론	정보를 연결하여 판단함	비교 분석, 원인 분석, 대안 제시

생성형 AI는 한 가지 작업만 수행하는 것이 아니라 이 작업들을 조합하여 사용할 때 더 큰 가치를 만든다.

예를 들어 기업 분석을 수행한다면 다음과 같은 과정이 가능하다.

관련 자료 검색
→ 자료 요약
→ 경쟁사와 비교
→ 핵심 인사이트 생성
→ 보고서 초안 작성

4. LLM은 어떻게 문장을 생성할까?

LLM은 Large Language Model의 약자로, 대규모 텍스트 데이터를 학습한 언어 모델이다.

언어 모델의 핵심 역할은 다음과 같다.

현재까지 입력된 단어 또는 토큰을 바탕으로 다음에 등장할 가능성이 높은 토큰을 예측한다.

예를 들어 다음 문장이 있다고 하자.

퇴근 후 공항에 택시를 타고 갔는데
탑승 시간에 늦어서 결국 비행기를 ______.

모델은 학습된 데이터에서 얻은 패턴을 바탕으로 빈칸에 들어갈 후보들의 확률을 계산할 수 있다.

놓쳤다: 72%
탔다: 15%
봤다: 8%
기타: 5%

그리고 이 확률분포를 기반으로 다음 토큰을 선택한다.

선택한 토큰을 기존 문장에 다시 추가한 다음, 또 다음 토큰을 예측한다.

입력 토큰
→ 다음 토큰 확률 계산
→ 토큰 선택
→ 선택된 토큰을 입력에 추가
→ 다시 다음 토큰 계산

이 과정이 반복되면서 하나의 문장과 답변이 만들어진다.

5. 토큰이란?

토큰은 LLM이 텍스트를 처리하는 기본 단위다.

토큰 하나가 반드시 단어 하나와 일치하는 것은 아니다.

다음과 같은 요소가 각각 토큰이 될 수 있다.

하나의 단어
단어의 일부
숫자
공백
문장부호
특수문자

영어 단어는 하나 또는 여러 개의 부분 단어로 나뉠 수 있으며, 한국어는 조사와 어미 등의 영향으로 영어보다 더 많은 토큰으로 분리되는 경우가 있다.

토큰이 중요한 이유는 크게 두 가지다.

사용 비용

LLM API는 일반적으로 입력 토큰과 출력 토큰의 수를 기준으로 비용을 계산한다.

Context Window

모델이 한 번에 처리할 수 있는 입력과 출력의 전체 길이에는 제한이 있다.

따라서 필요 이상의 긴 문서와 대화 내용을 모두 입력하면 비용이 증가하고 중요한 정보가 묻힐 수 있다.

6. 생성형 AI가 환각을 일으키는 이유

생성형 AI의 대표적인 한계는 환각, 즉 Hallucination이다.

환각은 모델이 사실이 아니거나 확인되지 않은 정보를 그럴듯하게 생성하는 현상을 말한다.

이 현상이 발생하는 이유는 LLM의 기본 목적이 사실을 검색하는 것이 아니라 다음 토큰을 자연스럽게 예측하는 것이기 때문이다.

모델은 다음 내용을 보장하지 않는다.

학습 데이터가 모두 사실인지
정보가 최신 상태인지
출처가 신뢰할 수 있는지
기업 내부 정보가 포함되어 있는지
특정 전문 분야의 내용이 정확한지

따라서 모델은 답을 모르는 상황에서도 질문과 문맥에 잘 연결되는 문장을 만들어 낼 수 있다.

LLM은 대규모 웹 데이터를 학습하며, 다음 문장을 확률적으로 예측하는 구조이기 때문에 환각 현상에 구조적으로 노출될 수 있다.

7. RAG가 등장한 이유

LLM이 학습하지 못한 정보나 최신 정보를 사용해야 할 때 활용되는 대표적인 방식이 RAG다.

RAG는 Retrieval-Augmented Generation의 약자로, 검색 증강 생성을 의미한다.

사용자 질문
→ 관련 문서 검색
→ 검색 결과를 프롬프트에 포함
→ LLM이 검색된 자료를 기반으로 답변

RAG를 활용하면 다음과 같은 정보를 모델에게 제공할 수 있다.

기업 내부 규정
최신 뉴스
제품 매뉴얼
연구 논문
고객 상담 기록
사내 업무 문서

일반적으로 문서를 임베딩 벡터로 변환하여 벡터 데이터베이스에 저장하고, 질문과 의미적으로 가까운 문서를 검색한다.

RAG의 핵심은 LLM 자체에 새로운 지식을 학습시키는 것이 아니라, 답변하는 시점에 필요한 정보를 찾아 프롬프트에 함께 넣어주는 것이다.

Prompt Engineering 기초

8. Prompt Engineering이란?

프롬프트는 모델에 전달되는 입력이다.

질문 한 문장만 프롬프트가 되는 것은 아니다.

다음 내용들이 모두 프롬프트에 포함될 수 있다.

모델의 역할
수행할 작업
참고해야 할 데이터
출력 형식
지켜야 할 정책
제한 조건
원하는 결과의 예시

Prompt Engineering은 LLM이 사용자의 목적에 맞는 결과를 생성하도록 입력을 설계하고 반복적으로 개선하는 과정이다.

단순히 질문을 길게 작성하는 것이 아니라 다음 요소를 명확하게 만드는 작업에 가깝다.

무엇을 해야 하는가?
왜 해야 하는가?
어떤 정보를 참고해야 하는가?
어떤 기준으로 판단해야 하는가?
어떤 형식으로 답해야 하는가?

Prompt Engineering을 LLM이 연속적인 토큰 예측을 더 잘 수행할 수 있도록 고품질의 입력을 설계하는 과정으로 정의한다.

9. Prompt Engineering의 한계

프롬프트를 잘 작성한다고 해서 항상 완벽한 결과가 나오는 것은 아니다.

프롬프트의 효과는 다음 조건에 따라 달라질 수 있다.

사용하는 모델
모델의 크기와 성능
작업의 난이도
입력 데이터 품질
제공한 예시
출력 파라미터
대화 히스토리

같은 프롬프트라도 모델에 따라 다른 결과가 나올 수 있으며, 프롬프트를 길게 만든다고 성능이 계속해서 향상되는 것도 아니다.

따라서 Prompt Engineering은 한 번에 정답을 만드는 작업이 아니라 다음과 같은 반복 작업이다.

프롬프트 작성
→ 결과 확인
→ 문제점 분석
→ 프롬프트 수정
→ 다시 평가

10. System Prompt와 User Prompt

LLM에 전달되는 프롬프트는 크게 System Prompt와 User Prompt로 구분할 수 있다.

System Prompt

모델의 역할과 기본 행동 규칙을 설정한다.

예를 들면 다음과 같다.

당신은 데이터 분석 교육 전문가입니다.

어려운 통계 개념을 초보자가 이해할 수 있도록
간단한 예시와 함께 설명하세요.

확인되지 않은 내용은 추측하지 마세요.

User Prompt

사용자가 현재 수행하고자 하는 작업을 요청한다.

상관관계와 인과관계의 차이를
온라인 쇼핑몰 사례를 이용하여 설명해 주세요.

System Prompt가 모델의 기본 역할과 행동 범위를 설정한다면, User Prompt는 현재 처리해야 할 구체적인 과제를 전달한다.

LLM 출력 제어

11. Max Tokens

Max Tokens는 모델이 생성할 수 있는 출력 토큰 수를 제한한다.

값을 크게 설정하면 더 긴 답변을 만들 수 있지만 다음 문제가 발생할 수 있다.

응답 시간이 길어진다.
API 사용 비용이 증가한다.
불필요한 설명이 추가될 수 있다.

하지만 Max Tokens를 줄인다고 답변이 자동으로 간결해지는 것은 아니다.

출력 제한에 도달하면 문장이 중간에 종료될 수 있기 때문이다.

따라서 출력 길이를 제어하려면 Max Tokens뿐 아니라 프롬프트에 직접 형식을 지정하는 것이 좋다.

핵심 내용만 5문장 이내로 작성하세요.

각 항목을 100자 이내로 설명하세요.

12. Temperature

Temperature는 모델이 다음 토큰을 선택할 때 무작위성을 얼마나 허용할지를 조절한다.

낮은 Temperature

높은 확률을 가진 토큰이 우선적으로 선택된다.

결과가 비교적 일관됨
사실 중심의 답변에 적합
분류, 추출, 요약 등에 활용

높은 Temperature

낮은 확률의 토큰도 선택될 가능성이 높아진다.

다양한 표현이 생성됨
아이디어 발상에 적합
결과의 일관성이 낮아질 수 있음

낮은 무작위성
→ 사실 확인, 데이터 추출, 정형화된 문서

높은 무작위성
→ 아이디어 생성, 카피라이팅, 시나리오 작성

다만 프롬프트 안에 “Temperature를 0.2로 설정해”라고 작성한다고 해서 실제 API 파라미터가 변경되는 것은 아니다.

API의 Temperature 설정과 프롬프트 내용은 서로 다른 영역이다.

프롬프트만으로 비슷한 효과를 만들고 싶다면 다음과 같이 출력 성격을 설명하는 것이 더 안정적이다.

추측을 최소화하고 확인 가능한 사실만 사용하세요.

가능한 한 다양한 관점과 새로운 아이디어를 제시하세요.

13. Top-k와 Top-p

Top-k와 Top-p는 다음 토큰 후보의 범위를 제한하는 방식이다.

Top-k

확률이 높은 상위 K개의 토큰만 후보로 사용한다.

Top-k = 3

1위 후보
2위 후보
3위 후보
만 선택 가능

값이 작을수록 보수적인 출력이 생성되고, 값이 커질수록 다양한 토큰이 후보가 된다.

Top-p

후보 토큰들의 누적 확률이 설정한 값에 도달할 때까지 토큰을 포함한다.

예를 들어 다음과 같은 확률이 있다고 하자.

토큰확률누적 확률

A	0.50	0.50
B	0.25	0.75
C	0.15	0.90
D	0.10	1.00

Top-p가 0.9라면 A, B, C가 후보가 된다.

Temperature와 Top-p를 동시에 지나치게 조정하면 예상하지 못한 결과가 발생할 수 있으므로 하나의 기준을 중심으로 조정하는 것이 관리하기 쉽다.

14. Reasoning Effort와 Verbosity

일부 추론형 모델에서는 추론 수준과 출력 상세도를 별도로 조절할 수 있다.

Reasoning Effort

문제를 해결하기 위해 내부적으로 얼마나 많은 계산과 검토를 수행할지를 결정한다.

낮은 추론 수준
→ 단순 분류, 정보 추출, 짧은 요약

중간 추론 수준
→ 문서 분석, 일반적인 코딩, 기획

높은 추론 수준
→ 복잡한 전략 분석, 디버깅, 심층 연구

Verbosity

최종 답변을 얼마나 상세하게 작성할지를 조절한다.

Low
→ 핵심 결과만 제시

Medium
→ 결과와 간단한 근거 제시

High
→ 배경, 과정, 예시까지 상세히 설명

Reasoning Effort는 얼마나 깊게 검토할지에 관한 설정이고, Verbosity는 최종 결과를 얼마나 상세하게 표현할지에 관한 설정이다.

모델과 API에 따라 지원 여부와 설정 방식은 다를 수 있다.

RICE Prompt Framework

15. 좋은 프롬프트는 길이가 아니라 구조가 중요하다

질문을 길게 작성한다고 반드시 좋은 프롬프트가 되는 것은 아니다.

중요한 것은 필요한 정보를 구조적으로 구분하는 것이다.

강의자료에서는 프롬프트를 다음 네 가지 요소로 구성하는 RICE Framework를 소개한다.

R: Role
I: Instruction
C: Context
E: Examples

RICE는 모델에게 다음 내용을 알려주는 구조다.

요소	핵심 질문
Role	누구의 관점으로 답할 것인가?
Instruction	무엇을 수행해야 하는가?
Context	어떤 상황과 정보를 참고해야 하는가?
Examples	어떤 기준과 형식을 따라야 하는가?

16. Role: 역할

Role은 모델이 어떤 전문가나 관점으로 답해야 하는지를 지정한다.

당신은 데이터 분석 담당자입니다.
숫자를 기반으로 의미 있는 인사이트를 도출하고,
비전문가도 이해할 수 있도록 설명합니다.

Role을 부여하면 모델은 해당 역할에 적합한 다음 요소를 우선적으로 사용한다.

전문 용어
표현 방식
판단 기준
분석 관점
답변의 깊이

다만 역할만 부여하고 구체적인 작업을 지정하지 않으면 결과는 여전히 모호할 수 있다.

17. Instruction: 지시

Instruction은 모델이 실제로 수행해야 하는 작업을 설명한다.

모호한 지시는 모호한 결과를 만든다.

모호한 지시

이 데이터 좀 분석해 줘.

구체적인 지시

월별 매출 데이터를 분석하여
전월 대비 증가율이 가장 높은 달과 가장 낮은 달을 찾고,
변화의 원인으로 확인해야 할 항목을 3가지 제안하세요.

Instruction에서는 가능한 한 행동을 나타내는 동사를 사용하는 것이 좋다.

요약하라
비교하라
분류하라
추출하라
평가하라
제안하라
변환하라

18. Context: 배경 정보

Context는 모델이 답변을 생성할 때 참고해야 할 배경 정보와 데이터를 의미한다.

Context가 없는 질문

업무 효율을 높일 아이디어를 제안해 주세요.

Context가 포함된 질문

우리 회사는 직원 30명 규모의 중소 IT 기업입니다.

매주 평균 15회의 회의가 열리고 있으며,
회의록 작성과 문서 검색에 많은 시간이 소요됩니다.

추가 인력 채용 없이 업무 효율을 높일 수 있는
아이디어를 5가지 제안해 주세요.

Context는 단순히 정보를 많이 넣는 것이 아니다.

모델이 판단해야 하는 범위와 경계 조건을 설정하는 역할도 한다.

예산은 최대 1,000만 원이다.
외부 SaaS 도입은 가능하다.
고객 개인정보를 외부 서버에 저장해서는 안 된다.
3개월 안에 적용할 수 있어야 한다.

관련 있는 Context는 응답의 정확도와 관련성을 높일 수 있지만, 불필요한 정보가 많아지면 오히려 중요한 내용이 묻힐 수 있다.

19. 어떤 Context가 필요한지 모를 때

사용자가 제공해야 할 정보를 정확히 모르는 경우에는 AI에게 먼저 질문하도록 만들 수 있다.

이를 역할 역전 또는 Socratic Prompting 방식으로 활용할 수 있다.

신규 프로젝트 제안서를 작성하려고 합니다.

바로 제안서를 작성하지 말고,
좋은 제안서를 작성하기 위해 필요한 정보를
한 번에 하나씩 질문해 주세요.

질문이 모두 끝난 후,
제가 제공한 답변을 바탕으로 제안서를 작성하세요.

AI가 인터뷰어 역할을 맡아 필요한 정보를 수집하고, 전체 대화를 Context로 활용하는 방식이다.

20. Examples: 예시

Example은 원하는 출력의 내용과 형식을 보여주는 역할을 한다.

다음 형식으로 기술 제안서를 평가하세요.

[예시]

- 강점:
기존 시스템과 쉽게 연동할 수 있어 초기 도입 부담이 낮다.

- 약점:
구체적인 비용 절감 근거와 성능 평가 기준이 부족하다.

- 개선사항:
현재 업무 비용과 예상 자동화율을 바탕으로
3년간 ROI를 계산해야 한다.

예시는 단순한 참고 결과가 아니다.

모델이 무엇을 좋은 답변이라고 판단해야 하는지를 보여주는 평가 기준에 가깝다.

예시를 제공하는 것은 모델에게 일종의 채점표를 전달하는 것과 같다.

21. RICE 이외에 추가하면 좋은 요소

실무에서는 RICE에 다음 요소를 추가하면 결과의 안정성을 높일 수 있다.

Policy 또는 Rule

확인되지 않은 내용은 추측하지 않는다.
수치를 제시할 때는 근거를 함께 표시한다.
자료에 없는 내용은 ‘확인 불가’라고 작성한다.

Style

경영진 보고서 문체로 작성한다.
짧고 명확한 문장을 사용한다.
전문 용어는 필요한 경우에만 사용한다.

Constraints

전체 분량은 1,000자 이내로 작성한다.
제안 항목은 최대 5개로 제한한다.
각 항목은 3문장 이내로 설명한다.

Format 또는 Structure

핵심 결론
주요 근거
예상 위험
권고 사항

Style이 말투와 표현 방법을 결정한다면, Format은 결과물의 모양과 순서를 지정한다.

22. 실무용 프롬프트 기본 템플릿

다음 템플릿을 복사하여 업무에 맞게 수정하면 된다.

# Role

당신은 [분야]에서 [경력 또는 전문성]을 가진 전문가입니다.
[답변할 때 중요하게 고려할 관점]을 우선합니다.

# Goal

이 작업의 최종 목적은 [목적]입니다.

# Context

- 조직 또는 프로젝트 상황:
- 현재 문제:
- 참고 데이터:
- 대상 독자:
- 예산 및 일정:
- 반드시 고려할 조건:

# Task

다음 순서에 따라 작업하세요.

1. [첫 번째 작업]
2. [두 번째 작업]
3. [세 번째 작업]

# Policy

- 확인되지 않은 내용은 추측하지 마세요.
- 제공된 자료와 일반적인 원칙을 구분하세요.
- 정보가 부족하면 부족한 부분을 명시하세요.

# Style

- 간결하고 논리적으로 작성하세요.
- 비전문가가 이해할 수 있는 표현을 사용하세요.

# Constraints

- 전체 분량은 [분량] 이내로 작성하세요.
- 제안은 최대 [개수]개로 제한하세요.

# Output Format

## 핵심 결론

## 분석 결과

## 위험 요소

## 권고 사항

# Example

[원하는 결과의 예시]

Prompting Techniques

23. Zero-shot, One-shot, Few-shot

Zero-shot Prompting

예시 없이 작업 지시만 제공한다.

다음 문장을 긍정 또는 부정으로 분류하세요.

문장: 이 제품은 기대보다 훨씬 만족스럽다.

간단하고 빠르지만 모델의 기본 능력에 의존한다.

One-shot Prompting

하나의 예시를 제공한다.

예시:
이 영화는 정말 재미있었다. → 긍정

분류:
이 제품은 기대보다 훨씬 만족스럽다. →

Few-shot Prompting

여러 개의 예시를 제공한다.

이 영화는 정말 재미있었다. → 긍정
배송이 너무 늦어서 실망했다. → 부정
가격은 비싸지만 성능은 훌륭하다. → 긍정

새 문장:
고객센터 연결이 전혀 되지 않았다. →

예시가 많을수록 무조건 좋은 것은 아니다.

다음 조건을 고려해야 한다.

예시의 품질
예시의 대표성
출력 형식의 일관성
Context Window 제한
입력 토큰 비용

24. 단계적 문제 분해

복잡한 문제는 하나의 요청으로 처리하기보다 여러 단계로 나누는 것이 좋다.

예를 들어 설비 수율 저하 원인을 분석한다고 하자.

다음 순서에 따라 분석하세요.

관찰된 현상을 정확히 요약하세요.
가능한 원인 후보를 분류하세요.
각 후보와 현재 증거를 비교하세요.
추가로 확인해야 할 데이터를 제안하세요.
즉시 조치와 근본 대책을 구분하세요.

모델의 숨겨진 내부 사고 내용을 그대로 요구하기보다, 사용자가 검토할 수 있는 단계별 결론·근거·검증 항목을 출력하도록 하는 것이 실무적으로 유용하다.

25. Step-back Prompting

Step-back Prompting은 바로 답을 만들기 전에 문제의 더 큰 맥락을 먼저 살펴보게 하는 방식이다.

일반적인 질문

LLM 기반 논문 추천 시스템의 주요 기능과 기대효과를 제안하세요.

Step-back 질문

LLM 기반 논문 추천 시스템을 기획하려고 합니다.

바로 기능을 제안하지 말고 먼저 다음을 분석하세요.

1. 연구자가 논문 탐색 과정에서 겪는 근본적인 문제는 무엇인가?
2. 기존 검색 시스템이 이를 해결하지 못하는 이유는 무엇인가?
3. 이 문제를 해결하기 위해 AI가 맡아야 할 핵심 역할은 무엇인가?

그 결과를 바탕으로 시스템의 기능과 기대효과를 제안하세요.

Step-back Prompting은 잘못 설정된 문제를 그대로 최적화하는 것을 방지할 수 있다.

26. Self-Consistency

LLM의 출력에는 무작위성이 존재하기 때문에 한 번의 결과만으로 판단하기 어려운 경우가 있다.

Self-Consistency는 동일한 질문에 대해 여러 결과를 생성하고, 반복적으로 등장하는 결론을 선택하는 방식이다.

동일한 문제를 서로 독립적인 세 가지 관점에서 분석하세요.

각 분석 결과를 비교하고,
공통적으로 나타난 결론과 서로 다른 결론을 구분하세요.

마지막에는 가장 타당한 최종 결론을 제시하세요.

이 방식은 복잡한 판단이나 분석에서 단일 결과에 지나치게 의존하는 문제를 줄일 수 있다.

다만 여러 번 모델을 호출하므로 비용과 시간이 증가한다.

27. Devil’s Advocate Prompting

Devil’s Advocate Prompting은 의도적으로 강한 반론을 생성하는 방법이다.

단순히 “문제점이 무엇인가?”라고 질문하는 것보다 이미 실패했다고 가정하는 방식이 더 구체적인 위험을 발견하는 데 도움이 될 수 있다.

이 프로젝트가 최종 투자심의에서 부결되었다고 가정하세요.

당신은 재무 리스크를 검토하는 CFO입니다.

프로젝트가 거절된 가장 강력한 이유를 5가지 제시하고,
각 문제를 해결하기 위해 필요한 데이터와 보완 자료를 설명하세요.

이 방식은 다음 상황에 활용할 수 있다.

기획안 검토
투자 심의 준비
연구계획서 검토
기술 설계 리뷰
보안 위험 분석
장애 시나리오 분석

강한 반론을 미리 확인하면 실제 보고나 심의 전에 논리적 빈틈을 보완할 수 있다.

28. Multi-Persona Prompting

Multi-Persona Prompting은 하나의 문제를 여러 이해관계자의 관점에서 검토하는 방식이다.

당신은 지금부터 CFO와 COO 두 명의 임원 역할을 수행합니다.

[CFO]
- 투자 대비 수익과 비용 위험을 중시합니다.
- 투자 회수 기간을 검토합니다.

[COO]
- 현업 적용 가능성과 운영 효율을 중시합니다.
- 조직 변화와 실행 난이도를 검토합니다.

두 역할이 아래 투자안에 대해 각각 의견을 제시하고,
상대방 의견에 반박하도록 하세요.

마지막에는 공동 결론과 승인 조건을 정리하세요.

서로 다른 역할을 충돌시키면 한 관점에서는 발견하기 어려운 문제를 찾을 수 있다.

29. Meta Prompting

Meta Prompting은 AI에게 최종 답을 바로 요청하지 않고, 좋은 답을 얻기 위한 프롬프트 자체를 만들도록 요청하는 방식이다.

당신은 AI 프롬프트 설계 전문가입니다.

기업 분석 보고서를 작성하기 위한
전문가 수준의 프롬프트를 생성하세요.

다음 요소를 포함해야 합니다.

- 기업의 수익구조
- 경쟁사 비교
- 주요 성장 요인
- 위험 요인
- 재무지표
- 최종 투자 관점
- 사실 검증 기준
- 출력 형식

복잡한 업무를 처음 수행하거나 어떤 질문을 해야 할지 모를 때 유용하다.

30. Markdown으로 프롬프트 구조화하기

Markdown은 제목, 목록, 표 등을 간단한 기호로 표현하는 형식이다.

# 제목

## 소제목

- 항목 1
- 항목 2

1. 첫 번째
2. 두 번째

**중요한 내용**

Markdown을 사용하면 프롬프트의 각 영역을 명확하게 구분할 수 있다.

특히 다음과 같은 내용을 나누는 데 유용하다.

역할
목적
Context
작업 순서
정책
출력 형식
예시

# Context

여기에 참고 정보를 입력합니다.

# Task

여기에 수행할 작업을 입력합니다.

# Constraints

여기에 제한 조건을 입력합니다.

프롬프트가 구조화되면 사람도 수정하기 쉽고, 모델도 각 정보의 역할을 구분하기 쉬워진다.

논문에서 얻을 수 있는 Prompt Engineering 교훈

31. 예시의 내용뿐 아니라 형식도 중요하다

강의자료에서 소개된 연구들은 Few-shot Prompting에서 정답 예시가 중요하지만, 입력과 출력의 형식 자체도 모델 성능에 상당한 영향을 줄 수 있다고 설명한다.

예를 들어 다음 두 예시는 정보는 비슷하지만 형식의 일관성이 다르다.

형식이 불명확한 예시

긍정 이 영화는 좋았다.
배송이 늦었다. 부정
가격이 만족스럽다 긍정

형식이 일관된 예시

이 영화는 좋았다. // 긍정
배송이 늦었다. // 부정
가격이 만족스럽다. // 긍정

Example을 제공할 때는 다음을 일관되게 유지해야 한다.

구분 기호
입력과 출력 순서
라벨 위치
문장 구조
출력 길이

강의자료는 Few-shot의 효과가 모델 크기와 예시 품질에 따라 다르며, 예시의 형식을 유지하는 것이 중요하다는 연구 결과를 소개한다.

32. 공손함과 감정은 보조 요소다

공손한 표현이나 감정적 중요성을 담은 문장이 모델의 반응에 영향을 줄 수 있다는 연구도 소개된다.

하지만 다음과 같이 이해하는 것이 적절하다.

공손하거나 감정적인 프롬프트
≠ 항상 정확한 답변

공손함과 감정은 모델의 출력 태도와 집중도에 영향을 줄 수 있지만 다음 요소를 대신하지 못한다.

정확한 Instruction
충분한 Context
명확한 평가 기준
근거 자료
출력 검증

따라서 “이 작업은 정말 중요합니다”라는 문장을 추가하는 것보다 작업 기준과 필요한 정보를 명확하게 제공하는 것이 우선이다.

33. Temperature가 곧 창의성은 아니다

높은 Temperature는 출력의 무작위성과 복잡성을 높일 수 있지만, 의미 있는 창의성이 항상 증가하는 것은 아니다.

오히려 다음 문제가 증가할 수 있다.

출력 간 불일치
원래 예시와의 거리 증가
사실 오류
문맥 이탈
불필요한 복잡성

창의적 결과가 필요하다면 Temperature만 높이기보다 다음과 같은 Instruction을 함께 사용하는 것이 좋다.

서로 다른 산업의 사례를 결합하여 아이디어를 제안하세요.

기존 방식과 완전히 다른 대안을 최소 3가지 포함하세요.

각 아이디어가 기존 접근과 어떤 점에서 다른지 설명하세요.

34. 특정 프롬프팅 기법이 항상 효과적인 것은 아니다

Few-shot과 단계적 문제 분해 등의 기법은 모델과 작업에 따라 효과가 달라질 수 있다.

특히 다음 조건을 확인해야 한다.

모델이 충분한 추론 능력을 가지고 있는가?
예시가 실제 작업을 대표하는가?
작업이 단계적 분석을 필요로 하는가?
불필요하게 프롬프트만 길어지지는 않았는가?
단순한 문제에 과도한 기법을 적용하지 않았는가?

좋은 프롬프트는 가장 복잡한 프롬프트가 아니라, 현재 문제를 해결하는 데 필요한 정보만 포함한 프롬프트다.

Prompt Engineering을 넘어 Context Engineering으로

35. Context Engineering이 등장한 이유

초기의 생성형 AI 활용은 대부분 한 번 질문하고 한 번 답을 받는 Single-turn 방식이었다.

이때는 필요한 정보를 하나의 프롬프트 안에 포함하는 것으로 충분했다.

하지만 AI Agent와 Multi-turn 환경에서는 상황이 달라진다.

Agent는 여러 번의 작업을 수행하면서 다음 정보들을 계속 생성하고 사용한다.

System Prompt
사용자 요청
대화 기록
검색 결과
외부 문서
API 결과
도구 실행 결과
이전 작업 결과
메모리
오류 메시지

이 모든 정보를 단일 프롬프트 작성만으로 관리하기는 어렵다.

Context Engineering은 모델이 추론할 때 사용하는 전체 정보 상태를 설계하고 관리하는 기술이다.

강의자료에서는 Prompt Engineering이 효과적인 문장을 작성하는 데 집중한다면, Context Engineering은 모델의 Context Window에 어떤 정보를 어떤 순서와 형태로 제공할지를 관리하는 전략이라고 설명한다.

36. Prompt Engineering과 Context Engineering의 차이

구분Prompt EngineeringContext Engineering

핵심 질문	무엇이라고 말할 것인가?	무엇을 알려줄 것인가?
주요 대상	질문과 지시 문장	모델에 전달되는 전체 정보
주요 환경	단일 요청	Multi-turn, Agent
관리 요소	역할, 지시, 형식	기억, 문서, 검색, 도구, 기록
목적	원하는 응답 유도	필요한 정보가 적절한 시점에 사용되도록 관리

Prompt Engineering이 문장 작성 중심이라면, Context Engineering은 AI 시스템 설계에 더 가깝다.

37. Context Engineering의 구성 요소

System Prompt 설계

모델의 역할, 목적, 행동 규칙과 금지사항을 정의한다.

Memory와 History

대화 내용을 얼마나 유지하고 어떤 정보를 기억할지 결정한다.

모든 대화를 그대로 저장하기보다 중요한 내용만 요약하여 관리할 수 있다.

Tool과 외부 지식

검색, RAG, 데이터베이스, API 등의 결과를 필요한 시점에 제공한다.

관련성이 낮은 자료는 제외하여 노이즈를 줄여야 한다.

Few-shot과 Format

출력 예시와 구조를 제공하여 결과의 일관성을 높인다.

강의자료는 이를 System Prompt, Memory와 History, Tool과 외부 지식, Few-shot과 Format의 네 영역으로 정리한다.

38. Context Rot

Context가 많을수록 항상 모델 성능이 좋아지는 것은 아니다.

Context가 지나치게 길어지면 다음 문제가 발생할 수 있다.

중요한 정보를 놓친다.
오래된 정보와 최신 정보가 충돌한다.
관련 없는 정보가 추론에 개입한다.
모델이 초기 지시를 잊는다.
처리 비용과 응답 시간이 증가한다.

이를 Context Rot 또는 컨텍스트 부패라고 한다.

정보 부족
→ 모델이 판단할 근거가 부족함

정보 과다
→ 중요한 정보가 노이즈에 묻힘

좋은 Context Engineering은 모든 정보를 넣는 것이 아니라 현재 작업에 가장 관련성이 높은 정보를 선별하는 것이다.

Harness Engineering

39. Harness Engineering이란?

LLM은 강력하지만 결과를 완전히 예측하기 어렵다.

Harness는 말에 채우는 마구를 의미한다.

강한 말이 가진 힘을 원하는 방향으로 전달하고 폭주를 방지하듯이, Harness Engineering은 AI의 능력을 안전하고 반복 가능한 방식으로 사용하도록 시스템을 설계하는 것이다.

Prompt와 Context만으로 해결하기 어려운 문제는 다음과 같다.

도구를 잘못 호출하면 어떻게 할 것인가?
외부 API 호출이 실패하면 어떻게 할 것인가?
같은 오류가 반복되지 않게 하려면 어떻게 할 것인가?
Agent가 실행할 수 있는 권한은 어디까지인가?
결과물의 합격 여부는 누가 판단하는가?
잘못된 결과가 외부 시스템에 반영되지 않게 하려면 어떻게 할 것인가?

40. Harness Engineering의 핵심 원칙

결과를 측정 가능하게 만든다

Agent에게 “코드를 잘 작성했는가?”라고 묻는 것보다 구체적인 통과 기준을 제공해야 한다.

모든 단위 테스트가 통과해야 한다.
응답 시간은 500ms 미만이어야 한다.
보안 취약점 High 등급이 없어야 한다.
JSON Schema 검증을 통과해야 한다.

시스템 구조로 규칙을 강제한다

프롬프트에 “이 구조를 지켜라”라고 적는 것만으로는 부족할 수 있다.

CI/CD, 코드 검사, 권한 관리 등을 이용해 규칙 위반을 시스템에서 차단해야 한다.

필요한 정보만 단계적으로 공개한다

모든 규칙과 문서를 처음부터 전부 제공하면 Context Window가 낭비된다.

처음에는 전체 구조를 알려주는 짧은 안내문만 제공하고, 필요한 세부 문서는 작업 단계에 따라 읽도록 구성할 수 있다.

기록을 남긴다

Agent의 실행을 개선하려면 다음 기록이 필요하다.

검색 기록
사용한 출처
도구 호출 기록
오류 기록
수정 기록
최종 결과 평가

강의자료에서는 Agent가 실수할 때마다 같은 실수를 다시 하지 못하도록 시스템 수준의 해결책을 추가하는 것을 Harness Engineering의 핵심 방향으로 설명한다.

41. Prompt, Context, Harness의 관계

세 개념은 서로 대체하는 관계가 아니라 단계적으로 확장되는 관계다.

Prompt Engineering
무엇을 어떻게 요청할 것인가?

Context Engineering
모델에게 어떤 정보를 제공할 것인가?

Harness Engineering
모델의 실행을 어떻게 통제하고 검증할 것인가?

예를 들어 사내 보고서 작성 Agent를 만든다고 하자.

Prompt Engineering

경영진 보고서 형식으로 핵심 내용을 작성한다.

Context Engineering

사내 매출 데이터
기존 보고서
경영진 관심사항
최근 회의 내용
관련 시장 자료

Harness Engineering

출처가 없는 수치는 출력 금지
민감정보 자동 마스킹
보고서 형식 자동 검사
승인 전 외부 전송 금지
실패 시 재시도 및 로그 기록

세 가지가 모두 갖춰져야 실제 업무에서 신뢰할 수 있는 AI 시스템을 만들 수 있다.

실습 예시

42. 좋지 않은 프롬프트

AI 도입 기획안을 작성해 줘.

이 질문에는 다음 정보가 빠져 있다.

어떤 기업인지
어떤 업무를 개선하는지
예산과 기간은 얼마인지
누구에게 보고하는 문서인지
어떤 기준으로 평가하는지
결과 형식은 무엇인지

43. 개선된 프롬프트

# Role

당신은 대기업 전략기획팀에서
AI 투자안을 검토하는 컨설턴트입니다.

# Goal

고객 상담 AI Agent 도입 여부를
경영진이 판단할 수 있는 기획안을 작성합니다.

# Context

- 현재 상담 인력: 50명
- 월 상담 건수: 40,000건
- 상담원 1인당 월평균 인건비: 400만 원
- 단순 문의 비중: 약 55%
- 예상 구축 기간: 6개월
- 최대 예산: 10억 원
- 개인정보는 외부에 저장할 수 없음

# Task

1. 현재 문제를 정리하세요.
2. AI Agent 적용 범위를 제안하세요.
3. 예상 효과를 정량·정성 효과로 구분하세요.
4. 주요 위험을 재무, 기술, 운영, 보안 관점에서 분석하세요.
5. 단계별 도입 계획과 Go/No-Go 기준을 제안하세요.

# Policy

- 제공되지 않은 수치는 임의로 만들지 마세요.
- 추가 데이터가 필요하면 ‘추가 확인 필요’라고 표시하세요.
- 예상과 사실을 명확하게 구분하세요.

# Output Format

## 1. Executive Summary
## 2. 현재 문제
## 3. 적용 범위
## 4. 기대효과
## 5. 위험 요소
## 6. 단계별 도입 계획
## 7. 최종 권고안

# Constraints

- 전체 분량은 A4 2페이지 수준으로 작성하세요.
- 경영진이 이해하기 쉬운 표현을 사용하세요.

단순히 질문을 길게 만든 것이 아니라 모델이 판단해야 할 역할, 정보, 작업, 규칙과 형식을 분리했다는 점이 핵심이다.

3주차 핵심 정리

이번 주차에서 가장 중요하게 느낀 점은 다음 세 가지다.

1. LLM은 사실 데이터베이스가 아니다

LLM은 입력된 문맥과 학습 데이터의 패턴을 기반으로 다음 토큰을 예측한다.

따라서 자연스러운 답변과 사실이 정확한 답변은 서로 다를 수 있다.

2. 좋은 프롬프트는 길이가 아니라 구조다

좋은 프롬프트에는 다음 요소가 명확하게 구분되어 있다.

역할
목적
지시
Context
규칙
형식
예시

불필요한 설명을 많이 넣기보다 모델이 판단하는 데 필요한 정보를 명확하게 제공해야 한다.

3. 좋은 AI 시스템은 프롬프트만으로 만들 수 없다

단일 질문에서는 Prompt Engineering으로 결과를 개선할 수 있다.

하지만 Agent와 실제 업무 시스템에서는 다음 요소가 함께 필요하다.

Prompt Engineering
+
Context Engineering
+
Harness Engineering

결국 생성형 AI 활용 능력은 단순히 질문을 잘 쓰는 능력에서 다음 단계로 발전하고 있다.

AI가 필요한 정보를 적절한 시점에 사용하고,
잘못된 행동을 시스템이 통제하며,
결과를 자동으로 검증할 수 있도록 설계하는 능력

복습 질문

전통적인 프로그래밍과 LLM 기반 문제 해결 방식의 차이는 무엇인가?
LLM이 환각 현상을 일으키는 근본적인 이유는 무엇인가?
RAG는 모델의 학습과 어떤 점에서 다른가?
System Prompt와 User Prompt는 각각 어떤 역할을 하는가?
Temperature를 높이면 항상 더 창의적인 결과가 생성되는가?
RICE Framework의 네 가지 구성 요소는 무엇인가?
Example이 단순 출력 예시가 아니라 평가 기준이라고 볼 수 있는 이유는 무엇인가?
Step-back Prompting은 어떤 문제를 방지하는가?
Prompt Engineering과 Context Engineering의 차이는 무엇인가?
Harness Engineering이 필요한 이유는 무엇인가?

'개발 > SKALA 4기' 카테고리의 다른 글

[SKALA] 객체지향(OOP)과 Spring Boot 핵심 정리 (0)	2026.07.27
[SKALA] LLM 모델과 Transformer 아키텍처 이해 (0)	2026.07.23
[SKALA] 데이터 전처리와 상관·회귀분석 정리 (0)	2026.07.23
[SKALA] 데이터 분석 개요와 기초통계 정리 (0)	2026.07.23
[SKALA] Web, HTML, CSS, JS 기초 (2)	2026.07.16