📘 1부: 프롬프트는 질문, 엔지니어링은 설계입니다

 

부제: 더 좋은 응답을 쉽게 얻는 법


LLM을 쓰다 보면 누구나 한 번쯤 이런 경험을 합니다.

  • “어제는 잘하더니 오늘은 왜 이렇게 엉뚱하게 답하지?”
  • “GPT가 작업 중간에 뭔가 잃어버린 것 같은데?”
  • “이렇게 스펙을 정리했는데 왜 다른 걸 이해하지…?”

이 차이를 만드는 핵심 원인은 프롬프트를 어떻게 입력 혹은 설계했느냐입니다.
같은 모델에게 요청해도 결과가 다르게 나오는 이유죠.

이 글에서는 ‘프롬프트 vs 프롬프트 엔지니어링’의 차이
가장 쉽고 실용적인 관점에서 정리해보겠습니다.


🧩 1. 프롬프트란 무엇일까요?

프롬프트는 AI에게 주는 요청(Instruction)입니다.
즉, “이걸 해달라”고 전달하는 단순 명령입니다.

예를 들면:

  • “이 문서를 요약해 주세요.”
  • “서비스 기획서를 작성해 주세요.”
  • “아이온2 전투 시스템을 설명해 주세요.”

이렇게 단순하게 입력해도 모델은 꽤 많은 일을 해냅니다.
하지만 문제는 결과가 일정하지 않다는 점입니다.
바로 이 지점에서 엔지니어링이 필요해집니다.


🏗️ 2. 프롬프트 엔지니어링이란?

프롬프트 엔지니어링은
AI가 더 좋은 결과를 안정적으로 내도록 입력을 설계하는 기술입니다.

단순히 길게 쓰거나 어렵게 쓰는 게 아니라,

  • 목적
  • 구조
  • 맥락
  • 데이터
  • 출력 형식

등을 명확하게 설계해 모델이 헤매지 않도록 안내하는 작업입니다.

그리고 중요한 사실이 있습니다.

프롬프트 엔지니어링은 개발자 기술이 아닙니다.
언어로 ‘설계’를 하는 모든 사람에게 필요한 스킬입니다.

PM·마케터·기획자·에디터·컨설턴트…
LLM을 쓰는 누구나 매일 부딪히는 실용 기술입니다.


🎯 3. 왜 굳이 프롬프트 엔지니어링을 해야 할까요?

저도 초기에는 이렇게 생각했습니다.

“GPT가 똑똑한데 굳이 복잡하게 설계할 필요가 있나?”

하지만 실제 업무에서 깊게 활용해보니 명확한 이유가 있습니다.

✔ 결과 품질이 매번 다르다

작은 표현·순서 차이만으로도 큰 품질 차이가 납니다.

✔ 모델은 부정문·복잡한 문장·중간부 누락에 취약

Lost in the Middle(중간 내용 삭제)은 LLM의 고질적 문제입니다.

✔ 엔지니어링을 하면

  • 더 정확하고
  • 더 빠르고
  • 더 저렴하고
  • 재사용 가능한 자동화 도구가 됩니다.

결국 목적은 하나입니다.

더 좋은 결과를 얻기 위해서.
더 쉽게, 더 안정적으로.


🧱 4. 프롬프트 엔지니어링의 핵심 4요소

이 4요소는 Anthropic Claude Prompt Engineering Guide,
OpenAI Prompting Overview,
Google Cloud Prompt Engineering Guide
에서 공통적으로 사용하는 구조입니다.

각 요소의 의미를 1줄로 정리하면 다음과 같습니다.


① Instructions (지시)

모델에게 “무슨 작업을 해야 하는지” 명확히 전달하는 부분.

예)

  • “아래 문서를 3줄로 요약해 주세요.”

② Input Data (데이터)

모델이 실제로 처리해야 하는 텍스트·표·코드 등 입력 데이터.

예)

  • 분석할 문서 본문
  • 사용자 로그
  • 텍스트 조각

③ Context (맥락)

작업이 수행되는 배경·조건·관점을 설명하는 부분.

예)

  • “PM 관점에서 설명해 주세요.”
  • “전문가 톤을 유지해주세요.”

④ Output Indicator (출력 지시문)

모델이 어떤 형태로 결과를 내야 하는지 구조·형식을 명시.

예)

  • “표 형식으로 작성해 주세요.”
  • “JSON으로 출력해 주세요.”
  • “한 줄당 20자 이하로 써 주세요.”

이 네 가지를 포함해 프롬프트를 작성하면 품질과 재현성이 크게 향상됩니다.


✏️ 5. 엔지니어링 팁 — 이것만 기억해도 반은 성공합니다

(각 항목에 좋은 예시(O) / 나쁜 예시(X) 포함)


✅ 1) 부정문 최소화

LLM은 부정문을 자주 오해합니다.

(X) 나쁜 예시

“문체는 절대 변형하지 말고 요약해 주세요.”
‘변형하지 말고’를 무시하거나 반대로 이해할 위험↑

(O) 좋은 예시

“문체는 그대로 유지하고, 핵심 내용만 요약해 주세요.”
긍정문 기반 → 오해 없음


✅ 2) 구조화된 프롬프트 사용

모델은 구조를 좋아합니다.

(X) 나쁜 예시

“전투, 경제, 보상을 포함해서 게임 시스템을 자세히 설명해 주세요.”
누락 or 순서 혼란 가능

(O) 좋은 예시

출력 구조:

  1. 전투 시스템(3줄)
  2. 경제 구조(표)
  3. 보상 구조(장점/리스크 2줄씩)
    → 모델이 “틀”대로 작성 → 안정적 출력

✅ 3) 출력 형식을 먼저 정하기

(X) 나쁜 예시

“이 글의 핵심 내용을 알려주세요.”
→ 모델이 임의 판단 → 길이·형식·순서 불안정

(O) 좋은 예시

“아래 문서를

  • 3줄 요약
  • 불렛 포인트
  • 한 문장 20자 이하
    형식으로 정리해 주세요.”
    → 품질·일관성 급상승

✅ 4) 짧고 명확하게

긴 설명은 사람도 AI도 이해하기 어렵습니다.

(X) 나쁜 예시

“배경이 이런데, 그래서 제가 원하는 건 이런 거고… 아무튼 잘 정리해 주세요.”

(O) 좋은 예시

“아래 기사를 PM 관점에서 3줄로 요약해 주세요.”
→ 명확·간결·정확


🔮 6. 앞으로는 GPT에게 ‘설계’까지 맡기는 시대

프롬프트 엔지니어링의 최신 방향은
“프롬프트를 사람이 직접 설계하는 시대가 끝나가고 있다”입니다.

이제는 이렇게 요청하는 것이 더 효율적입니다.

“GPT, 이 작업을 위한 최적의 프롬프트를 먼저 설계해 주세요.”

사람은 요구사항만 제시하고,
프롬프트의 구조·형식·샘플·맥락은 모델이 설계하는 시대입니다.


🧭 7. 마무리

프롬프트 엔지니어링은 어렵지 않습니다.
본질은 “좋은 질문을 구조적으로 만드는 기술”이며,
이를 통해 더 좋은 응답을 쉽게 얻을 수 있습니다.

이번 1부에서는 개념을 정리했습니다.
2부에서는 실전 Before/After 비교를 공개하겠습니다.


📘 다음 글 예고

2부: 프롬프트 엔지니어링은 GPT에게 맡기세요 — 실전 Before/After 3선

내용 구성:

  • AI/RAG 평가 기준 자동 생성
  • 데이터 정제 + 시각화 레포트 생성
  • 서비스 기획 문서 자동 생성
    세 가지 실무 예제를 통해 프롬프트 엔지니어링의 효과를 보여드립니다.

 

AI 챗봇, RAG 파이프라인 속 기획자의 역할

1. 서문

앞선 글에서는 Safety 정책과 폴백·쿠션멘트 설계를 다뤘습니다.
이번에는 이 요소들이 RAG 파이프라인 속에서 어떻게 연결되는지를 이야기하려 합니다.

먼저 간단히 복습하자면:

  • LLM (Large Language Model): 대규모 언어 모델. 질문을 이해하고 답변을 생성하는 엔진
  • RAG (Retrieval-Augmented Generation): LLM이 답변을 생성하기 전, 검색으로 근거 자료를 찾아 활용하는 최신화 프레임워크
    → 즉, 검색 기반 + 생성형”을 결합해 답변의 신뢰도를 높이는 방식입니다.

파이프라인 자체는 개발팀이 주도적으로 설계·구현했지만,
제가 맡은 역할은 그 흐름이 사용자 경험 차원에서 안정적으로 작동할 수 있도록 기준과 필요사항을 정의하는 것이었습니다.


2. RAG 파이프라인 개요

RAG는 보통 다음 단계를 거칩니다:

  1. Input 처리 – 사용자 발화 전처리
  2. Retriever – 검색 및 문서 매칭
  3. Augment – 검색 결과 정제 및 후보 선택
  4. Generator – LLM 응답 생성
  5. Output Post-processing – 응답 후처리 및 검증

이 중 기획자의 역할은 각 단계에서 “어떤 경우를 어떻게 처리할지” 기준을 제공하는 것입니다.


3. 단계별 기획자의 터치포인트

각 단계는 개발팀이 주도적으로 구현했지만,
기획자는 사용자 경험 관점에서 기준을 정의하는 역할을 했습니다.

단순 요약이 아니라, 실제로 어떤 일이 일어나는지를 예시와 함께 풀어보겠습니다.

① Input (전처리 & Safety 1)

  • 개발팀: 언어 탐지, 금칙어/개인정보(PII) 검출, 입력 포맷 정규화
  • 기획:
    • 미지원 언어 → “현재 한국어만 지원합니다. 다시 입력해 주세요.”
    • 특수문자/형식 오류 → “입력하신 문구를 확인해 주세요.”
    • 금칙어/불법 발화/개인정보 → “안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.”
    • 계정/결제 등 사람 개입 필요 → 상담사 이관

👉 핵심은 차단/재시도/이관 플로우를 정의하는 것입니다. 이렇게 해야 사용자 경험을 보호하고 시스템 자원도 절약할 수 있습니다.

② Retriever (검색/매칭)

  • 개발팀: 쿼리 빌드, 인덱스 검색, 스코어링, Top-K 후보 산출
  • 기획:
    • IDK (도메인 안인데 답 없음) vs OOD (도메인 밖 질문) 구분
    • 검색 신뢰도 임계치(Threshold) → 기준 이상 = 답변 생성, 기준 이하 = 추천 리스트 제공
    • 소스 우선순위 = 공식 문서 > 공지 > 커뮤니티

👉 임계치는 초기엔 개발팀이 임의로 정했지만, 실제 운영에서는 “언제 답변을 막고 언제 추천으로 돌릴지”가 사용자 경험에 직결됩니다.

📦 Top-K & Score Threshold란?

  • Top-K Retrieval: 검색 결과 중 상위 K개만 가져오는 방식.
    예: 200개 검색 → 상위 5개만 선택 = Top-5. (보통 K=3~10)
  • Score Threshold(임계치): 검색 결과의 유사도 점수(score)가 기준 T 이상일 때만 “신뢰 가능”으로 간주.
    예: 0.85 ≥ 0.8 → 답변 생성
    예: 0.55 < 0.8 → “정확한 답변을 찾지 못했습니다. 대신 [추천 리스트]를 확인해 주세요.”
  • 왜 기획자가 알아야 할까? 이 값들은 사용자 경험에 직접 영향을 주는 값이기 때문입니다.
    예: T가 너무 높으면 → 답변이 자주 막힘
    예: T가 너무 낮으면 → 엉뚱한 답변까지 노출

③ Augment (컨텍스트 구성)

  • 개발팀: Top-K 결과 중 프롬프트에 넣을 자료 정제
  • 기획:
    • 최신 자료/공식 자료 우선 순위 설정 (이번 달 공지 > 작년 글, 공식 FAQ > 커뮤니티)
    • 중복 제거 (비슷한 문서 여러 개일 경우 1개만 남김)
    • 신뢰도 낮음 → 다운그레이드 응답 (“정확한 답변은 제공되지 않습니다. 대신 [공식 문서]를 참고하세요.”)

👉 즉, 어떤 자료를 남기고/빼고, 불충분할 때 어떻게 보여줄지를 정하는 단계입니다.

④ Generator (LLM 생성)

  • 개발팀: 프롬프트 구성 및 LLM 호출
  • 기획:
    • 브랜드 톤·쿠션멘트 정의
      • 게임 = 친근/재밌게 (“이 부분은 아직 준비되지 않았어요 😅”)
      • 금융 = 단정/공식 (“현재 해당 정보는 제공되지 않습니다.”)
    • 신뢰도 낮음 → 정중 거절 + 대체 링크 안내
    • 프롬프트 가드레일
      • 범위 벗어난 질문은 거절
      • 모르면 IDK
      • 출처 없이 단정 금지

👉 답변 자체는 모델이 생성하지만, 어떤 톤과 규칙 안에서 말하게 할지”는 기획이 정합니다.

⑤ Output (후처리 & Safety 2)

  • 개발팀: 최종 응답 필터링, 금칙어/민감정보 제거, 마스킹 처리
  • 기획:
    • 차단 발생 시 대체 문구 정의
      • “안전한 서비스 제공을 위해 일부 내용은 표시되지 않습니다.”
    • 필요 시 공식 링크/상담 버튼 제공
    • 책임 문구/출처 표기 여부 결정

👉 Output은 마지막 안전망입니다. Input에서 걸러지지 않은 리스크가 여기서 최종적으로 검수됩니다.


5. 경험담 & 마무리

처음엔 “개발팀이 기술적으로 잘 만들겠지”라고 생각했습니다.
하지만 막상 업무를 진행하다 보니, 사용자 안내 기준이 빠진 채로는 파이프라인이 온전히 작동하지 않는다는 걸 알게 되었습니다.

결국 기획자의 역할은 직접 파이프라인을 설계하는 것이 아니라,
각 단계가 사용자 경험 차원에서 일관되게 동작하도록 기준과 필요사항을 정의하고 정리하는 것이었습니다.

겉으로 보면 RAG 파이프라인은 기술 중심 프로세스처럼 보입니다.
그러나 실제로는 Safety 정책, 폴백, 쿠션멘트 같은 사용자 경험 설계가 파이프라인 속에 녹아 있어야 비로소 서비스가 제대로 굴러갑니다.

결국 기획자는 기술의 빈 공간을 채우는 사람이 아니라,
서비스 전체가 일관된 경험을 주도록 연결해주는 역할을 맡습니다.


P.S. 🙂

RAG 2.0이 아직 일반화되지도 않았는데, 벌써 RAG 3.0이 논의될 정도로
AI는 지금도 하루가 다르게 발전하고 있습니다.

따라서 지금의 RAG 파이프라인 구축은 어디까지나 하나의 프레임워크이자 레퍼런스일 뿐입니다.
앞으로 새로운 기술 트렌드에 맞춰 계속 진화할 것이고,
기획자는 급변하는 흐름 속에서 유연하게 기준과 해결책을 설계하는 태도를 가져야 할 것입니다.

 

AI 챗봇 기획, 폴백·쿠션멘트 제대로 설계하는 법

1. 서문

챗봇 기획에서 폴백(Fallback)쿠션멘트(Cushion Message) 는 단순한 보조 장치가 아닙니다.
서비스가 복잡해질수록 이 두 장치는 사용자 경험을 지키는 안전망이 됩니다.
저는 CS 챗봇 시절부터 AI 챗봇까지 이어지는 과정에서 이 두 요소를 어떻게 설계·운영했는지를 경험했고, 그 과정에서 얻은 시행착오와 교훈을 공유하고자 합니다.


2. 타임라인: Rule 기반 → AI 기반

CS 챗봇 (Rule-Based)

  • 매칭 실패 → 폴백 동작 or 무조건 상담사 연결
  • 폴백과 쿠션멘트의 구분이 명확했음

AI 챗봇 (LLM + RAG 도입)

  • 단순 실패가 아니라, 다양한 케이스가 발생
    • 검색은 됐는데 결과 신뢰도가 낮음
    • 답변 후보가 너무 많음
    • 외부 도메인 질문이 들어옴 등
  • 결국 “각 케이스별로 사용자에게 어떻게 안내할 것인가?”라는 복잡도가 급격히 늘어남

👉 여기서 중요한 개념이 I.D.K vs. O.O.D

  • IDK (I Don’t Know): 챗봇이 “내가 모른다”를 스스로 인지하는 상황 (답변 범위 안인데 답을 못 찾음)
  • OOD (Out of Domain): 아예 서비스 영역 밖의 질문이 들어온 상황 (예: 게임 가이드 챗봇인데 ‘날씨 어때?’ 물어봄)
  • 이 둘을 구분하지 않으면, 같은 폴백으로 처리되어 사용자 경험이 무너집니다.

3. 매칭 구분표 작성

AI 챗봇에서 가장 어려웠던 부분은, 이 다양한 케이스를 기술·운영·기획이 이해할 수 있는 “매칭 구분표”를 정의하는 일이었습니다.

  • 실제 구분표(단순화 예시)
구분케이스처리 기준사용자 노출
IDKFAQ 범위 내, 매칭 실패유사 질문 추천쿠션멘트 + 추천 리스트
OODFAQ 범위 밖 질문폴백 → 종료/이관쿠션멘트 + 상담 안내
RAG Low Score검색결과 신뢰도 낮음답변 차단쿠션멘트 + 공식 링크
  • 효과
    • 혼선 제거 → 기획/개발/운영이 같은 기준을 공유
    • 개발 속도 향상 → 케이스별 기준이 명확해 구현 지연 최소화

4. 최종 구조도 & 사용자 안내 예시

챗봇 질문이 들어오면, 아래 흐름처럼 6가지 케이스로 분류 후 처리됩니다.
(단순화 된 예시입니다.)

구분케이스처리 기준사용자 안내(쿠션/블럭 예시)
SAFETY 차단비윤리 발화/금칙어/현금거래 등즉시 차단(선차단) + 로그“안전한 서비스 제공을 위해 해당 내용은 안내드릴 수 없습니다.”
필요 시: “정확한 내용은 {official_link}에서 확인해 주세요.”
입력 부적합‧미지원 언어미지원 언어, 특수기호/형식 오류언어 탐지/형식 검증 → 안내 후 재시도미지원 언어: “죄송합니다. 해당 언어는 현재 지원하지 않습니다.”
형식 오류: “지원하지 않는 문자입니다. 다시 입력해 주세요.”
OOD (Out of Domain)도메인 밖 질문·일상대화·의미 없는 발화LLM 기반 폴백(종료 또는 재질문 유도)“안녕하세요! 저는 {ip_name} {bot_scope} 정보를 안내하는 AI입니다. {bot_scope} 관련 질문을 해 주세요.”
도메인 내이지만 챗봇 처리 불가계정/결제/신고 등 사람 개입 필요초동수사/상담 이관“이 요청은 챗봇이 처리하기 어려워 상담사에게 연결해 드릴게요.” (상담사 바로 연결 or 버튼 제공)
IDK (검색 실패/저신뢰)자료 없음·오래됨·커뮤니티 글 등응답 차단 + 쿠션멘트 + 추천/링크 안내“질문 범위는 맞지만 적합한 답변을 찾지 못했습니다. 대신 도움이 될 수 있는 항목을 안내드릴게요: {추천_리스트}”
“정확한 정보는 {official_link}에서 확인해 주세요.”
정상 응답검색·생성 정상정상 RAG 응답 생성일반 답변 제공
(RAG 환각을 감안하여, 부정확할 수 있음을 쿠션멘트로 안내)
출력 체크(2차 SAFETY)생성 응답에 금칙어/민감 정보 포함후처리 차단/마스킹“안전한 서비스 제공을 위해 일부 내용은 비공개 처리되었습니다.”

5. 협업 포인트 (R&R)

  • 프로젝트 리딩 = PM
  • 서비스 리딩 = 기획
  • 사용자 접점 최종 결정 = 운영실
    → 즉, 기획자가 초안을 설계하되 최종 컨펌은 운영실이 맡았습니다.
  • 구조/플로우: 기획자가 주도
  • 사용자 톤·멘트: 운영실이 최종 결정
    → 실제로도 약 80% 이상은 운영실이 최종 톤을 확정했고, 기획자는 시스템적 일관성을 맞추는 역할에 집중했습니다.

6. Tip & 시행착오

제가 직접 겪으면서 깨달은 몇 가지 포인트입니다.

  • 기획자의 핵심 역할
    복잡한 내용을 단순화하여, 가시성을 제공하고 팀이 속도를 낼 수 있도록 돕는 것.
    기획은 결국 ‘지도’와 같은 역할이라는 점을 다시 한 번 확인했습니다.

  • RAG 파이프라인 도입 시 복잡도 폭발
    설계 초기부터 기술팀과 협의하며, 폴백 & 쿠션멘트 정의를 동시에 진행했어야 했습니다.
    초반엔 따로 움직이다 보니 기준이 꼬였고, 나중에 통합 정리하는 데 시간을 더 썼습니다.

폴백과 쿠션멘트는 사용자 경험의 시작이자 마지막 방어선입니다.
특히 Rule 기반 → AI 기반으로 넘어가면서 복잡도가 커질수록, 기획자가 기준을 정리하고 협업 구조를 잡아주는 역할이 필수적이었죠.
결국 기획자가 길을 정리해주고, 개발팀이 빠르게 구현하고, 운영실이 최종 목소리를 결정하는 구조가 가장 효율적이었습니다.


P.S. 🙂

요즘 AI가 하루가 다르게 빠르게 발전하고 있습니다.
모든 내용은 단순한 경험과 프레임워크의 참고서일 뿐이며, 실제 진행 방식은 언제든지 바뀔 수도 있고 더 효율적인 방식으로 진화되어야 합니다.