LLM 실전 활용 3: 프롬프트 엔지니어링의 착각과 진실 — RAG 시대에 프롬프트는 무엇을 해야 하는가

LLM 실전 활용 3: 프롬프트 엔지니어링의 착각과 진실 — RAG 시대에 프롬프트는 무엇을 해야 하는가

---

한동안 이런 말이 유행했다.

“프롬프트만 잘 쓰면 다 된다.”

실제로 초반엔 그랬다.
모델이 작고, 지식이 부족하던 시절엔
프롬프트가 마법 주문처럼 보였다.

그런데 RAG를 붙이고,
실제 서비스에 넣는 순간 깨닫게 된다.

👉 프롬프트로 해결되는 문제와
절대 해결되지 않는 문제가 분명히 나뉜다.

이번 글은
프롬프트 엔지니어링을 신화에서 실무 도구로 되돌리는 글이다.

---

1. 프롬프트 엔지니어링에 대한 가장 큰 오해

❌ 오해

“프롬프트를 잘 쓰면 모델이 더 똑똑해진다”

✅ 현실

프롬프트는 모델의 ‘지식’을 늘리지 못한다
다만 행동 범위와 출력 형식을 조절할 뿐이다.

즉,

• 없는 지식을 만들어내게 ❌
• 있는 지식을 어떻게 쓰게 할지 ⭕

이걸 이해 못 하면
프롬프트 지옥에 빠진다.

---

2. 프롬프트로 ‘가능한 것’과 ‘불가능한 것’

프롬프트로 가능한 것

• 출력 형식 통제 (JSON, 표, 단계별 설명)
• 말투·톤·역할 지정
• 추론 과정 유도 (step-by-step)
• 요약, 재구성, 변환

프롬프트로 불가능한 것

• 최신 정보 추가 ❌
• 사내 문서 학습 ❌
• 사실 검증 ❌
• 근거 없는 질문의 정답 생성 ❌

👉 이 영역은 RAG, Tool, API의 몫이다.

---

3. RAG 시대에 프롬프트의 역할이 바뀌었다

RAG 이전 프롬프트:

너는 최고의 전문가야.
휴가 규정 알려줘.

RAG 이후 프롬프트의 핵심은 이거다.

“이 문서를 기준으로,
상상하지 말고,
근거 기반으로 답해라.”

즉, 프롬프트는

• 정보를 만드는 역할 ❌
• 정보를 읽고 정리하는 역할 ⭕

---

4. RAG 프롬프트의 3대 원칙

반응형

① Context 우선

• 질문보다 문서가 먼저
• 문서가 답의 상한선

② 금지 조항 명시

• “모르면 모른다고 말해라”
• “문서에 없는 내용은 답하지 마라”

③ 출력 포맷 고정

• 서비스 안정성의 핵심

---

5. 가장 많이 쓰는 RAG 프롬프트 기본 템플릿

실무에서 가장 많이 쓰는 형태다.

너는 내부 문서를 기반으로 답변하는 AI 어시스턴트다.

[규칙]
- 아래 제공된 문서 내용만 사용해서 답변해라.
- 문서에 없는 내용은 "문서에 해당 정보가 없습니다"라고 답해라.
- 추측하거나 일반 상식을 추가하지 마라.

[문서]
{{retrieved_context}}

[질문]
{{user_question}}

[출력 형식]
- 핵심 답변
- 근거 문서 요약

👉 이 프롬프트 하나로
hallucination이 눈에 띄게 줄어든다.

---

6. “Chain-of-Thought를 쓰면 더 똑똑해진다?”의 진실

한때 이런 공식이 유행했다.

“Step by step으로 생각해봐”

사실은 이렇다

• 추론을 잘하는 것처럼 보이게 만들 뿐
• 지식 자체를 늘리지는 않는다

게다가:

• 실무에서는 추론 과정 노출이 위험할 수 있다
• 비용(토큰) 증가

실무 권장 방식

• 내부 추론은 하되
• 결과만 출력

예:

추론 과정을 내부적으로 수행하고,
최종 답변만 출력하라.

---

7. 프롬프트를 복잡하게 만들수록 생기는 문제

많은 팀이 겪는 전형적인 흐름이다.

1. 프롬프트 길어짐
2. 예외 규칙 계속 추가
3. 모델마다 반응 달라짐
4. 디버깅 불가
5. 유지보수 지옥

👉 이건 프롬프트 문제가 아니다.
👉 아키텍처 문제다.

---

8. 프롬프트 vs 시스템 설계, 책임 분리하기

프롬프트가 책임질 것

• 답변 형식
• 역할 정의
• 출력 제약

시스템이 책임질 것

• 정보 제공 (RAG)
• 최신 데이터 (API)
• 계산/검증 (Tool)
• 권한/정책

이 선을 넘기 시작하면
프롬프트는 지옥이 된다.

---

9. 실무에서 검증된 “짧고 강한” 프롬프트 전략

“프롬프트는 짧을수록 좋다.
대신 Context는 강해야 한다.”

좋은 구조는 이렇다.

[System]
- 역할 + 금지 규칙

[Context]
- RAG 결과

[User]
- 질문

프롬프트에 모든 걸 넣지 말고,
정보는 시스템이 공급하자.

---

10. 프롬프트 엔지니어링의 진짜 목적

프롬프트의 목적은
“똑똑하게 만들기”가 아니다.

“예측 가능한 출력을 만들기”

• 항상 같은 형식
• 항상 같은 톤
• 항상 같은 기준

👉 이게 서비스 품질이다.

---

11. 이 글의 핵심 요약

구분결론

프롬프트	행동 제어 도구
지식	RAG/DB/API의 몫
hallucination	프롬프트로 해결 ❌
RAG 시대	프롬프트는 ‘독해 지시서’
좋은 프롬프트	짧고 명확

---

 

LLM,프롬프트엔지니어링,RAG,AI서비스,생성형AI,LLM실무,PromptDesign,Hallucination,AI아키텍처