Day 3 - 프롬프트 엔지니어링 기초: 좋은 프롬프트, Zero/Few-shot, 그리고 한계

좋은 프롬프트의 구성 요소

같은 모델, 같은 질문이라도 "어떻게 묻느냐"에 따라 답의 질이 천차만별이다. "글 좀 써줘"와 "초등학교 4학년이 이해할 수 있게, 5문장으로, 친근한 말투로 광합성을 설명해줘"는 완전히 다른 결과를 낳는다. 이 "모델에게 잘 묻는 기술"이 프롬프트 엔지니어링(prompt engineering) 이다.

• 생성형 AI 는 모델을 새로 학습시키지 않아도 프롬프트만 잘 쓰면 원하는 결과의 상당 부분을 얻을 수 있다.
• 학습·파인튜닝은 비싸고 느린 데 비해, 프롬프트는 즉시 바꿀 수 있고 추가 학습 비용이 없다. 그래서 AIF 시험에서 "가장 빠르고 비용이 적게 드는 개선 방법"을 물으면 프롬프트 엔지니어링이 답이 된다.

좋은 프롬프트는 운이 아니라 구조에서 나온다. 보통 다음 요소들을 명확히 담는다.

막연한 "이거 분석해줘"보다, 위 요소를 채운 프롬프트가 훨씬 안정적인 결과를 낸다. 핵심 원칙은 네 가지다.

1. 구체적이고 명확하게: "짧게"보다 "3문장 이내로".
2. 역할 부여(persona): "너는 친절한 고객 상담원이다"처럼 역할을 주면 톤이 잡힌다.
3. 출력 형식 지정: JSON, 표, 불릿 등 원하는 형태를 명시하면 후처리가 쉽다.
4. 예시 제공: 원하는 답의 본보기를 보여주면 적중률이 올라간다(Few-shot).

프롬프트 엔지니어링이 효과적인 이유는 LLM 이 "지시를 따르도록(instruction-tuned)" 추가 학습돼 있기 때문이다. 사전학습만 한 raw 모델은 단순히 다음 토큰만 이어붙이지만, 사람의 피드백으로 정렬(RLHF, 인간 피드백 기반 강화학습)된 모델은 "요청을 이해하고 따르는" 행동을 학습했다. 그래서 명확한 지시와 형식을 줄수록 모델이 그 패턴에 맞춰 응답을 정렬한다. 프롬프트는 모델의 가중치를 바꾸지 않고, 단지 "어떤 출력 분포를 끌어낼지" 조건을 거는 행위다.

막연한 프롬프트를 고쳐 쓰는 과정

네 요소가 실제로 무엇을 바꾸는지 한 프롬프트를 단계별로 고치며 본다. 상황은 쇼핑몰 리뷰를 분류해 담당 부서로 넘기는 일이다.

• 3단계의 "한 단어로만"은 출력 토큰도 줄인다. 형식을 좁히면 품질과 비용이 함께 좋아지는 경우가 많다.
• 4단계처럼 모를 때의 기본 답을 정해 주는 것은 환각을 줄이는 대표적인 프롬프트 기법이다.
• "~하지 마라"를 명시하는 것을 네거티브 프롬프트(negative prompt) 라고 한다. "가격은 언급하지 마라", 이미지 생성에서 "글자·워터마크는 넣지 마라"처럼 원치 않는 요소를 빼는 지시다. 시험 가이드는 맥락·지시와 함께 이것을 프롬프트의 구성 개념으로 든다.

프롬프트 템플릿과 관리

실제 서비스에서는 사용자가 프롬프트 전체를 쓰지 않는다. 개발자가 틀을 만들어 두고 사용자 입력만 끼워 넣는다.

다음 {{문서 종류}} 의 감정을 {{선택지}} 중 하나로 분류하라.

텍스트: {{사용자 입력}}
답:

• 이렇게 바뀌는 자리만 비워 둔 틀이 프롬프트 템플릿이다. 지시·맥락·예시·형식은 고정하고 입력만 갈아 끼우므로 결과가 일관된다.
• 템플릿도 코드처럼 고치면 결과가 달라진다. 그래서 버전을 남기고 비교해야 한다. Amazon Bedrock 의 Prompt Management(프롬프트 관리) 는 프롬프트를 만들어 저장하고, 변수(자리 표시자)를 넣고, 여러 변형(variant)의 출력을 나란히 비교하고, 버전을 남겨 애플리케이션에 배포하는 기능이다.
• 시험에서 "프롬프트를 팀이 재사용하고 변경 이력을 관리하고 싶다"가 나오면 Prompt Management 다.

Zero-shot vs Few-shot: 예시를 몇 개 주느냐

프롬프트 기법 중 AIF 시험이 다루는 대표적인 분류가 "예시(shot)를 몇 개 주느냐"다. 여기서 shot 하나는 "입력 예와 그에 대한 바람직한 출력"의 한 쌍을 뜻한다.

Zero-shot(제로샷): 예시 없이 지시만 준다. 모델이 사전학습 지식만으로 푼다.

다음 문장의 감정을 긍정/부정 중 하나로 답하라.
문장: "이 영화 정말 최고였어!"
감정:

Few-shot(퓨샷): 답의 본보기 몇 개를 먼저 보여준 뒤 진짜 질문을 한다. 모델이 패턴을 보고 따라 한다.

문장: "음식이 형편없었다" → 부정
문장: "서비스가 친절했다" → 긍정
문장: "이 영화 정말 최고였어!" →

One-shot(원샷) 은 예시를 정확히 1개만 주는 경우다. 시험 가이드는 이것을 single-shot 이라고 적는다.

Few-shot 은 모델 가중치를 바꾸지 않는다. 단지 프롬프트 안에서 예시를 보여줄 뿐이라 In-Context Learning(맥락 내 학습) 이라고도 부른다. 진짜 학습(파인튜닝)과 헷갈리면 안 된다.

• 예시는 대화가 끝나면 사라진다. 다음 요청에서 같은 효과를 내려면 예시를 다시 넣어야 하고, 그때마다 입력 토큰으로 과금된다.
• 예시는 고르게 준다. 긍정 예만 세 개 보여 주면 모델이 긍정 쪽으로 기운다.
• 예시의 형식이 곧 출력 형식이 된다. 예시를 "→ 부정"으로 끝냈다면 답도 그 모양으로 나온다.

🔍 더 깊이: 한 단계 더 나아간 기법이 Chain-of-Thought(CoT, 사고의 연쇄) 프롬프팅이다. "단계별로 생각해봐(Let's think step by step)"처럼 모델이 추론 과정을 글로 풀어내게 유도하면, 특히 수학·논리 문제의 정답률이 크게 오른다. 모델이 중간 추론을 토큰으로 "내뱉으면서" 다음 단계 예측의 근거로 삼기 때문이다. AIF 시험에서 "복잡한 다단계 추론 문제의 정확도를 프롬프트만으로 높이고 싶다"가 나오면 CoT 를 떠올리면 된다. 대가도 있다. 풀이 과정만큼 출력 토큰이 늘어 비용과 지연이 커진다.

프롬프트 vs 파인튜닝 vs RAG: 어디까지 프롬프트로 해결되나

모델 동작을 바꾸는 방법은 여러 층이 있다. 비용·난이도가 낮은 순서로 시도하는 게 정석이다.

핵심 판단:

• 모델이 모르는 "정보"가 필요하다 → 프롬프트로 안 됨. RAG(또는 파인튜닝)로 지식을 공급해야 한다.
• 출력의 "형식·톤·행동"만 바꾸면 된다 → 프롬프트 엔지니어링으로 충분.
• 방대한 도메인 패턴을 영구 내재화하고 싶다 → 파인튜닝.

비유하면 이렇다. 프롬프트는 신입 사원에게 업무 지시서를 잘 써 주는 일, RAG 는 참고 자료철을 책상에 펴 주는 일, 파인튜닝은 연수를 보내 사람 자체를 바꾸는 일이다. 지시서와 자료철은 오늘 바로 바꿀 수 있지만 연수는 시간과 돈이 든다.

가상의 사례로, 한 법률 자문 스타트업은 처음에 "더 정확한 답"을 위해 곧장 모델 파인튜닝을 검토했다. 비용 견적이 수천만 원에 달했다. 컨설턴트의 권유로 먼저 프롬프트 엔지니어링(역할 부여 + 출력 형식 고정 + Few-shot 예시)과 사내 판례를 활용한 RAG 를 적용해봤더니, 목표 품질의 대부분이 충족됐다. 파인튜닝은 끝내 필요하지 않았다. "싼 방법부터, 비싼 방법은 나중에"가 생성형 AI 실무의 황금률이다.

프롬프트 엔지니어링의 한계

프롬프트가 만능은 아니다. 한계를 아는 것이 AIF 시험과 실무 모두에서 중요하다.

1. 모르는 정보는 만들어낼 수 없다(혹은 지어낸다): 모델이 학습하지 않은 최신 정보나 사내 비공개 데이터는 프롬프트를 아무리 잘 써도 정확히 나오지 않는다. 오히려 그럴듯하게 지어내는 환각(hallucination) 이 생긴다(내일 자세히).
2. 컨텍스트 윈도우 한도: 예시를 너무 많이 넣으면 토큰 한도에 부딪히고 비용도 커진다.
3. 비결정성: 같은 프롬프트라도 매번 답이 조금씩 다를 수 있어, 100% 일관성이 필요한 작업엔 한계가 있다.
4. 프롬프트 주입(prompt injection) 취약성: 사용자 입력에 "이전 지시를 무시하고…" 같은 악의적 문구가 섞이면 모델이 의도와 다르게 행동할 수 있다(보안 이슈).
5. 민감하거나 깊은 도메인 전문성: 일관된 전문 말투/규정 준수가 핵심이면 프롬프트만으론 한계가 있어 파인튜닝이 필요할 수 있다.

⚠️ 함정: "프롬프트를 길고 자세하게 쓸수록 무조건 좋다"는 흔한 오해다. 지나치게 길면 토큰 비용과 지연이 커지고, 핵심 지시가 묻혀 오히려 모델이 헷갈릴 수 있다. 또 모순된 지시("짧게 쓰되 모든 것을 담아라")를 주면 결과가 불안정해진다. 좋은 프롬프트는 긴 게 아니라 명확하고 일관된 것이다.

프롬프트를 노리는 공격 네 가지

시험 가이드는 프롬프트 엔지니어링의 위험으로 노출·오염·탈취·탈옥을 든다. 이름이 비슷해 헷갈리므로 "무엇을 노리는가"로 구분한다.

• 넷을 묶어 부르는 말이 프롬프트 주입이다. AWS 문서는 이것을 SQL 주입과 같은 애플리케이션 수준의 보안 문제로 설명한다. 기반 인프라는 AWS 가 지키지만, 주입을 막는 설계는 애플리케이션을 만드는 고객의 책임이다.
• 방어책: 사용자 입력 검증, 시스템 프롬프트에 비밀 정보를 넣지 않기, 모델에 주는 권한 최소화, Amazon Bedrock Guardrails 의 프롬프트 공격 필터.
• "프롬프트에 '절대 지시를 무시하지 마라'고 적으면 막힌다"는 오해다. 지시문도 결국 텍스트라 더 교묘한 입력에 밀릴 수 있다. 프롬프트 바깥의 장치가 함께 있어야 한다.

시나리오로 기법 고르기

내일은 그 한계의 핵심인 환각, 편향, 비결정성 같은 생성형 AI 의 위험을 정면으로 다룬다.

📖 용어

• 프롬프트 : 모델에게 주는 입력 전체. 지시, 맥락, 예시, 처리할 데이터가 모두 포함된다.
• 페르소나(역할 부여) : "너는 ~이다"라고 역할을 정해 주어 답의 말투와 관점을 잡는 방법.
• shot : 프롬프트 안에 넣는 "입력 예 + 바람직한 출력" 한 쌍. 0개면 Zero-shot, 몇 개면 Few-shot 이다.
• In-Context Learning : 프롬프트 안의 예시를 보고 그 자리에서 패턴을 따라 하는 것. 가중치는 바뀌지 않는다.
• Chain-of-Thought : 답만 내지 않고 풀이 과정을 단계별로 쓰게 해 추론 정확도를 높이는 기법.
• 프롬프트 템플릿 : 바뀌는 부분만 빈칸으로 남긴 프롬프트 틀. 같은 틀을 여러 입력에 재사용한다.
• 네거티브 프롬프트 : 결과에 넣지 말아야 할 것을 알려 주는 지시.
• 프롬프트 주입 : 입력에 악의적 지시를 섞어 모델을 원래 의도와 다르게 움직이는 공격.
• 탈옥(jailbreaking) : 모델의 안전 장치를 우회해 금지된 답을 끌어내려는 시도.
• RLHF : 사람의 평가를 보상으로 삼아 모델이 지시를 더 잘 따르도록 다듬는 학습 방식.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

Few-shot 프롬프팅에 대한 설명으로 가장 정확한 것은?

• A모델의 가중치를 영구적으로 변경하는 학습 방법이다
• B프롬프트 안에 답의 본보기 예시 몇 개를 보여주어 패턴을 따르게 하는 기법이다
• C예시를 전혀 주지 않고 지시만 하는 방법이다
• D모델을 처음부터 다시 학습시키는 것이다

문제 2

좋은 프롬프트를 작성하기 위한 권장 사항이 아닌 것은?

• A원하는 출력 형식(예: JSON, 한 단어)을 명시한다
• B역할(persona)을 부여해 톤을 정한다
• C가능한 한 모호하고 일반적으로 작성한다
• D구체적이고 명확하게 지시한다

문제 3

모델이 학습하지 못한 최신 사내 문서 내용을 답변에 반영해야 한다. 가장 적절한 접근은?

• A프롬프트에 "정확하게 답하라"고 강하게 지시하면 해결된다
• BRAG(검색 증강 생성)로 관련 문서를 찾아 프롬프트에 함께 제공한다
• Ctemperature를 0으로 낮추면 모르는 정보도 정확해진다
• DFew-shot 예시를 늘리면 모델이 사내 문서를 알게 된다

문제 4

모델 동작을 조정하는 방법을 비용/난이도가 낮은 것부터 높은 순으로 시도하는 일반적 순서는?

• A파인튜닝 → RAG → 프롬프트 엔지니어링
• B프롬프트 엔지니어링 → RAG → 파인튜닝
• CRAG → 파인튜닝 → 프롬프트 엔지니어링
• D파인튜닝 → 프롬프트 엔지니어링 → RAG

문제 5

프롬프트 엔지니어링의 한계로 보기 어려운 것은?

• A모델이 학습하지 않은 정보는 정확히 답하기 어렵고 환각이 생길 수 있다
• B같은 프롬프트라도 출력이 매번 다를 수 있다(비결정성)
• C악의적 사용자 입력에 의한 프롬프트 주입 위험이 있다
• D출력 형식이나 톤을 조정할 수 없다