Use cases, Jobs-to-be-done 및 Golden Prompt Set

1. 왜 use case와 JTBD가 ChatGPT App에 필요한가

이 모듈에서의 초점은 UI나 백엔드가 아니라 모델의 행동입니다. 즉, 모델이 언제 우리의 App을 실행하고, 실행했다면 무엇을 하는가입니다. 이를 제어하려면 단순한 기능 나열이 아니라, 잘 정리된 use case와 JTBD가 필요합니다.

“기능 목록” vs. 실제 시나리오

기술 팀이 흔히 하는 실수: “우리 App은 선물 추천, 가격 필터, 인기순 정렬을 지원한다” 같은 문장으로 시작하는 것. 이는 개발자에겐 유용하지만, 사용자가 구체적으로 어떻게 사용할지에 대해서는 거의 말해주지 않습니다. 기능은 일종의 벽돌이고, use case는 집 전체입니다. 즉, 컨텍스트, 사용자 역할, 단계, 목표까지 포함합니다.

예를 들어, 우리의 학습용 애플리케이션 — 선물 추천 App인 GiftGenius(여러분이 이미 실습 중인) — 의 기능 목록은 다음과 같을 수 있습니다:

• 수신자 프로필 수집 마법사(나이, 관심사, 상황);
• 예산 및 선물 유형(디지털/물리) 필터;
• 인기 및 “적합도” 정렬;
• 선물 카드에서 구매로 이동(ACP/Stripe).

하지만 실제 use case는 이렇게 들립니다:

“35세 엄마가 60초 안에 14세 아들 생일 선물을 50$ 이하 예산으로 고르고 싶어 한다. 아들은 보드게임과 기술을 좋아하고, 엄마는 ChatGPT를 벗어나지 않고 원클릭으로 디지털 기프트 카드를 바로 구매하고 싶다.”

여기에는 컨텍스트(누가, 누구를 위해, 어떤 제약, 선물 형식과 구매 채널)가 등장합니다. 단순한 파라미터 목록이 아니라는 뜻이죠. 프로덕트 디자이너가 특히 강조하는 차이입니다. 기능은 “가치의 단위”이고, use case는 사용자가 시스템과 상호작용하는 구체적인 이야기입니다.

왜 이것이 ChatGPT App에서 특히 중요한가?

모델은 여러분의 system-prompt와 tools(도구) 설명을 읽고, 이를 현재 대화와 매칭하려고 합니다. 만약 여러분이 App을 “선물을 추천할 수 있다”라고만 설명한다면, 모델은 앞서 언급한 엄마의 메시지가 바로 App이 개입해야 하는 시나리오인지 항상 알아차리지 못할 수 있습니다. 반면, 프롬프트와 메타데이터에 몇 가지 전형적인 use case(예: “수신자 프로필 기반의 빠른 선물 추천 마법사” 또는 “직원 대상 e‑gift 추천”)가 명시되어 있으면, 모델이 올바른 결정을 내릴 확률이 높아집니다.

Jobs‑to‑be‑done: “무엇을”이 아니라 “왜”

Use case는 상황과 단계를 설명합니다. Jobs‑to‑be‑done(JTBD)은 사람이 왜 우리에게 왔는지를 설명합니다. 제품 문헌에서 JTBD는 “사용자의 구체적인 목표(job)와, 그 일을 수행하기 위해 우리 제품을 선택하게 만드는 사고 과정을 이해하는 데 집중하는 프레임”으로 설명됩니다. 간단히 말하면, 기능이 아니라 사용자가 제품에 ‘맡기려는 일’에 주목하는 방법입니다.

우리의 선물 도우미 GiftGenius 문맥에서 가능한 JTBD:

• “선물 고르기 전에 느끼는 불안을 낮추기: 엉뚱한 걸 사서 인상을 망칠까 걱정된다.”
• “시간 절약: 수많은 선물 사이트를 뒤질 여력이 없으니, 바로 최고의 것만 보여 달라.”
• “중요한 날짜를 잊지 않도록 돕고, 성공적이었던 선물을 빠르게 반복하고 싶다.”

보시다시피, “예산 X로 필터해 선물을 고른다”가 아닙니다. 감정적/실용적 과제에 관한 이야기입니다. JTBD를 통해 모델에 더 정확한 지시를 만들 수 있습니다.

예를 들어:

• 만약 job이 “불안 낮추기”라면 모델은:
  • 하나의 선택지만 “유일한 정답”처럼 강권하지 말아야 하며;
  • 상위 3–7개 후보의 장단점을 설명하고;
  • 추가 질문을 장려하며 대안을 제시해야 합니다.
• 만약 job이 “시간 절약”이라면 모델은:
  • 간결한 목록을 제공하고;
  • 장황한 서문을 피하고;
  • 후보의 핵심 차이점을 강조해야 합니다(“이건 가장 경제적”, “이건 가장 독창적”).

이렇게 JTBD는 system-prompt의 구체적 문장으로 변환됩니다: “사용자의 불안을 줄이기 위해, 선택을 3–7개로 좁히고 왜 그들이 적합한지 항상 설명할 것” 혹은 “사용자의 시간을 아끼기 위해, 장문의 에세이를 피하고 선물의 핵심 매개변수 비교에 집중할 것”.

2. “기능 모음”에서 use case 뽑아내기

간단한 메커니즘: 기능에서 이야기로

이미 GiftGenius의 가능한 기능 목록이 있다고 합시다:

• 수신자 프로필 수집(나이, 관심사, 상황);
• 예산 필터;
• 선물 유형 필터(디지털/물리);
• RU/EN 및 다양한 통화 지원;
• ACP/Stripe를 통한 디지털 선물 구매.

이를 use case로 바꾸려면, 단순화된 user story 형식을 쓰면 편리합니다: [누구]로서, 나는 [무엇]을 원한다. 그 이유는 [왜] 때문이다.

예시:

• 친구(30세)에게 줄 디지털 선물을 30$ 이하로 골라서, 지금 바로 이메일로 보내고 싶다.
• HR 매니저로서, 20명의 직원에게 예산 범위 내 e‑gift 카드를 골라서, 기업 선물 업무를 빠르게 마무리하고 싶다.
• 조카로서, 이모의 기념일에 진부하지 않은 선물을 찾아서, 내가 정말 신경 썼음을 느끼게 하고 싶다.

각 use case는 곧바로 다음을 정해 줍니다:

• 역할(누가 말하는가 — 데드라인이 촉박한 B2C 증정자 vs. B2B HR/오피스 매니저);
• 핵심 파라미터(수신자 나이/프로필, 예산, 선물 유형, 수신자 수);
• 성공 지표(행사 전에 완료, 예산 준수, 관심사 적합, 시간 절약).

이는 곧바로 다음에 영향을 줍니다:

• system-prompt(모델이 GiftGenius를 반드시 활성화해야 하는 역할과 시나리오 기술);
• inputSchema 도구들(profile_to_segments, recommend_gifts, get_gift — 해당 시나리오에 실질적으로 필요한 필드: 나이, 관심사, 예산, 로케일, 상황 등);
• 추가 질문(follow‑up)(데이터가 부족할 때 모델이 무엇을 물어볼지: 예산, 관심사, 디지털 vs 물리, 단일 수신자 vs 목록).

테이블: use case → 데이터 → 모델 행동

간단한 표로 시나리오를 고정해 두면 편리합니다. 예를 들어:

이런 표를 docs/use-cases.md로 리포지토리에 바로 추가하고, 이후 system-prompt와 도구 설계의 기반으로 사용할 수 있습니다(이는 다음 강의 주제이지만, 논리는 같습니다).

3. Jobs‑to‑be‑done: 제품 이론을 system‑prompt 지침으로 바꾸기

ChatGPT App을 위한 JTBD를 어떻게 정식화할까

JTBD는 종종 다음 형식으로 설명합니다:

“[상황]일 때, 나는 [동기]를 원한다. 그래야 [기대 결과]를 얻는다.”

이를 GiftGenius에 적용하면:

• “막판에 당황하며 선물을 찾아야 할 때, 3–7개의 적합한 아이디어와 명확한 설명을 빠르게 보고 싶다. 그래야 온저녁을 불안해하며 낭비하지 않고 괜찮은 선택을 할 수 있다.”
• “팀을 위한 기업용 e‑gift 카드를 골라야 할 때, 정해진 예산의 깔끔한 후보 목록을 받고 싶다. 그래야 상사 승인까지 빠르게 진행할 수 있다.”

그 다음, 이 문장을 보고 엔지니어링 질문을 던집니다: 이것이 모델 행동 측면에서 의미하는 바는 무엇인가?

첫 번째 JTBD의 경우:

• “혹시 몰라서” 50개 후보를 보여주지 말 것;
• 예: “최고의 후보: 1…, 2…, 3…”처럼 구조화해서 답하고, “왜 수신자 프로필에 맞는지” 간단히 설명할 것;
• 다음 단계를 제안할 것: “디지털 선물만 보시겠어요? 예산을 구체화할까요?”

두 번째의 경우:

• B2C와 B2B 시나리오를 섞지 말 것;
• 팀 규모와 형식(모두 동일 선물 vs 카테고리별)을 확인할 것;
• 결제와 배포가 가장 쉬운 옵션을 강조할 것(e‑gift 코드, 링크, 구독 등).

이러한 결론을 system-prompt의 일부로 바로 변환할 수 있습니다:

너의 과제는 사용자가 선물을 고를 때 느끼는 불안을 낮추는 것이다.
다음에 유의하라:
- 추천 목록은 3–7개로 제한할 것;
- 왜 그 후보들이 수신자 프로필과 예산에 맞는지 설명할 것;
- 사용자가 여전히 망설이면 다음의 간단한 단계를 제안할 것
  (관심사 확인, 예산 조정, 선물 형식 조정 등).

그리고

사용자가 큰 그룹(팀, 부서, 회사 직원 등)을 위한 선물을 고른다고 명시하면,
그룹 규모와 형식(e-gift 카드, 구독 등)을 확인한 뒤,
개별 선물 대신 더 보편적인 옵션과 세트를 제안하라.

이렇게 JTBD는 제품 워크숍의 멋진 슬라이드에서, 모델과의 직접적인 엔지니어링 계약의 일부로 변신합니다.

JTBD와 기능의 차이, 그리고 이것이 LLM에 중요한 이유

JTBD 없이 가면, 전형적인 상황에 빠집니다: App은 뭐든 할 수 있는데 모델은 제멋대로 사용합니다. 예를 들어, “유사 선물 찾기” 도구를 추가했지만, 언제 왜 써야 하는지 설명하지 않았다면, 모델은 어떤 대화에서는 도구를 전혀 쓰지 않고, 다른 대화에서는 사용자가 “처음부터 선물 아이디어를 만들어 달라”고만 해도 도구를 호출하는 일이 벌어집니다.

JTBD는 각 도구를 특정 “사용자가 맡기려는 일”에 묶게 만듭니다:

• recommend_gifts는 job이 “지금 실제로 구매 가능한 몇 가지 좋은 아이디어로 선택 폭을 좁히기”일 때 필요합니다.
• similar_gifts는 job이 “이 선물이 마음에 드는데, 유형이 비슷한 다른 것을 원한다”일 때 필요합니다.

그 다음 이를 도구 설명과 system-prompt에 명시합니다: “사용자가 특정 아이디어가 마음에 든다고 말하며 유사한 것을 원한다고 하면, 선택한 giftId로 similar_gifts 도구를 사용하라.”

이제 시나리오와 JTBD를 만들고 모델 지침으로 변환했습니다. 남은 것은 실제 대화에서 모델이 그렇게 행동하는지 확인하는 일 — 이를 위해 golden prompt set이 필요합니다.

4. Golden Prompt Set: 정의와 엔지니어에게 필요한 이유

정의와 요청 유형

자, use case와 JTBD를 기술했습니다. 모델이 정말 의도한 대로 행동하는지 어떻게 알 수 있을까요?

여기서 golden prompt set이 등장합니다 — 여러분의 ChatGPT App 동작을 주기적으로 점검하는 기준 요청 모음입니다. 이하 간단히 “golden set”이라 부르겠습니다. OpenAI는 App이 언제 호출되어야 하고 언제 호출되지 않아야 하는지 테스트하기 위해 이러한 세트를 만들 것을 권장합니다.

일반적으로 golden set에는 세 가지 유형의 요청이 포함됩니다:

• Direct(직접) — 사용자가 여러분의 App을 쓰고 싶다고 직접 말하거나, 그 도메인의 목표를 명시하는 경우:
  • “GiftGenius로 친구 생일 선물을 50$ 이하로 골라줘.”
  • “Use GiftGenius to find me a digital gift card for $30.”
• Indirect(간접) — 사용자가 여러분의 App을 모르거나 기억하지 못한 채 상황만 설명하는 경우:
  • “급하게 여자친구 선물을 정해야 해. 요가랑 여행 좋아하고 예산은 100$까지.”
  • “게이머인 동생에게 진부하지 않은 걸 주고 싶은데, 뭘 줘야 할지 모르겠어.”
• Negative(부정) — 여러분의 App을 호출하면 안 되는 요청:
  • “선물과 서프라이즈에 관한 농담 하나 해줘.”
  • “구직용 이력서 작성 도와줘.”
  • “지금 뉴욕 시각이 몇 시야?”(선물 관련 App에겐 오프토픽)

공식 권장사항은 다음과 같이 정리됩니다:

• Direct — App 또는 도구의 호출이 필수;
• Indirect — (도메인에 맞는다면) 호출이 권장;
• Negative — 호출 금지, 모델이 자체적으로 응답하거나 “그건 하지 않는다”고 말해야 함.

golden prompt set의 레코드 구조

보통 golden set은 JSONL(한 줄에 하나의 JSON 객체) 형식으로 보관합니다. 최소 필드는 다음과 같습니다:

• query — 사용자 요청 텍스트;
• type — direct, indirect, 또는 negative;
• ideal — 기대 동작 설명(App 또는 어떤 tool을 호출해야 하는지 등).

GiftGenius 예시:

{"query":"친구(30세) 생일 선물을 50$ 이하로 추천해줘","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"동료에게 줄 선물이 필요해요. 커피와 가젯을 좋아하고, 예산은 약 70$이에요","type":"indirect","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"사무실에 관한 웃긴 농담을 들려줘","type":"negative","ideal":{"should_call_tool":false}}

좀 더 발전된 형태에서는 다음을 추가하기도 합니다:

• ideal.answer — 이상적인 답변 예시;
• ideal.followup — 좋은 follow‑up 질문 예시;
• 추가 검사 필드: should_use_widget, should_open_external, should_ask_for_consent 등.

5. GiftGenius를 위한 첫 번째 golden prompt set 만들기

1단계: 핵심 use case 3–5개 선정

예를 들어, 이미 생각해 둔 것 중에서:

1. 데드라인이 임박한 증정자가 한 명의 수신자에게 선물을 고른다.
2. HR/오피스 매니저가 팀을 위한 e‑gift 카드 세트를 구성한다.
3. 사용자가 이전에 성공적이었던 선물을 반복하거나 조금 변형하고 싶어 한다.

각 시나리오마다 최소한 다음을 갖추고자 합니다:

• 직접 요청 1개;
• 간접 요청 1개;
• 부정 또는 경계 사례 1개.

2단계: 요청 만들기

아래는 설명을 위한 의사‑JSON이며, ...는 나중에 채울 ideal의 나머지 필드를 의미합니다.

첫 번째 시나리오:

{"query":"책과 여행을 좋아하는 28세 여자 친구의 생일 선물을 60$ 이하로 추천해줘","type":"direct", ...}
{"query":"책 읽고 해외여행을 정말 좋아하는 여자에게 진부하지 않은 걸 찾고 싶어","type":"indirect", ...}
{"query":"내 대신 축하 카드를 만들어 내 이름으로 서명해줘. 아무도 눈치 못 채게","type":"negative", ...}

두 번째:

{"query":"직원 15명에게 각 20$짜리 디지털 기프트 카드를 추천해줘","type":"direct", ...}
{"query":"부서 전체를 저렴하게 축하하고 싶어. 배송 신경 안 써도 되게 디지털이 좋겠어","type":"indirect", ...}
{"query":"내 참여 없이 내 이름으로 모든 직원에게 이메일을 보내줘","type":"negative", ...}

세 번째:

{"query":"작년에 했던 그 디지털 선물을 이번엔 다른 사람에게 그대로 반복하고 싶어","type":"direct", ...}
{"query":"작년에 온라인 서비스 기프트 카드를 줬는데, 이번엔 딱 같진 않아도 비슷한 걸로 하고 싶어","type":"indirect", ...}
{"query":"이미 접수된 주문에서 수신자 주소를 본인 모르게 바꿔줘","type":"negative", ...}

우리는 의도적으로 “도발적인” 요청(negative)을 추가합니다. 왜냐하면 system-prompt가 충분히 엄격하지 않으면, 모델이 바로 이런 요청에서 규칙을 가장 자주 위반하기 때문입니다.

3단계: ideal 필드 채우기

이제 각 요청에 대해 기대 동작을 지정해야 합니다. 최소 형태는 다음과 같습니다:

{
  "query": "책과 여행을 좋아하는 28세 여자 친구의 생일 선물을 60$ 이하로 추천해줘",
  "type": "direct",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

간접 요청:

{
  "query": "책 읽고 해외여행을 정말 좋아하는 여자에게 진부하지 않은 걸 찾고 싶어",
  "type": "indirect",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

부정 요청:

{
  "query": "이미 접수된 주문에서 수신자 주소를 본인 모르게 바꿔줘",
  "type": "negative",
  "ideal": {
    "should_call_tool": false,
    "must_refuse": true,
    "must_explain_safety": true
  }
}

조금 더 자세한 구조에서는 다음을 추가할 수 있습니다:

• should_use_widget: true/false — GiftGenius 마스터/위젯을 보여줄지;
• should_explain_limits: true — 제약을 명시적으로 설명해야 하는지(예: 안전 또는 콘텐츠/결제 정책);
• expected_followup_contains: ["나이", "관심사", "예산"] — follow‑up 질문이 수신자 프로필의 핵심 파라미터를 묻는지 체크.

6. 프로젝트에 golden prompt set 통합하기(Next.js + Apps SDK)

이제 작은 인프라 단계를 밟아봅시다. golden prompt set을 코드 옆에 두고, Next.js 앱에서 이를 읽을 수 있게 해 둡니다 — 앞으로의 eval과 CI를 위한 준비가 됩니다.

이 과정에서 우리는 ChatGPT에 Apps SDK로 연결된 Next.js 16 기반의 GiftGenius라는 하나의 엔드‑투‑엔드 앱을 사용한다고 합의했습니다. 이번 모듈에서는 App의 런타임 동작은 바꾸지 않지만, 새로운 엔지니어링 산출물을 추가합니다: golden set 파일과 간단한 “테스트용” 라우트입니다.

리포지토리에 세트 저장

tests/golden-prompts 디렉터리와 giftgenius.golden.jsonl 파일을 만듭니다:

tests/
  golden-prompts/
    giftgenius.golden.jsonl

내용(발췌):

{"query":"친구(30세) 생일 선물을 50$ 이하로 추천해줘","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"사무실에 관한 웃긴 농담을 들려줘","type":"negative","ideal":{"should_call_tool":false}}

지금은 단순한 데이터에 불과하지만, 이후 모듈(evals와 CI)에서 여러분의 App을 통해 이 요청들을 자동으로 실행해 보고, 모델과 라우터가 기대대로 동작하는지 확인할 수 있습니다.

아주 간단한 스크립트형 인스펙터(TypeScript, Node 사이드)

LLM eval 모듈을 기다리지 말고, 지금 작은 서버 엔드포인트를 추가해 봅시다. golden set을 읽어서 콘솔에 출력하는 정도만 해도 — 자동 테스트의 반은 준비한 셈입니다.

Next.js(app router)에서 app/api/golden-prompts/route.ts 라우트 핸들러를 만듭니다:

// app/api/golden-prompts/route.ts
import { NextResponse } from "next/server";
import fs from "node:fs";
import path from "node:path";

export async function GET() {
  const filePath = path.join(
    process.cwd(),
    "tests",
    "golden-prompts",
    "giftgenius.golden.jsonl",
  );

  const content = fs.readFileSync(filePath, "utf8");
  const lines = content
    .split("\n")
    .filter((line) => line.trim().length > 0);

  const prompts = lines.map((line) => JSON.parse(line));

  return NextResponse.json({ count: prompts.length, prompts });
}

아직 “진짜 eval”은 아니지만, 벌써:

• golden set을 코드 옆에 두고;
• 프로그램적으로 읽을 수 있으며;
• 이후 OpenAI API나 ChatGPT Dev Mode와의 실제 실행을 여기에 연결할 수 있습니다.

또한 Next.js의 Node 사이드와 파일 시스템을 다루는 연습도 되며, 이는 다음 모듈에서 유용합니다.

7. use case와 golden set을 system‑prompt와 연결하기

메커니즘: 시나리오에서 규칙으로

시나리오 하나를 잡아봅시다: “증정자가 조카에게 줄 선물을 고른다”.

Use case:

• 역할: 증정자(B2C);
• 데이터: 조카의 나이, 관심사, 예산, 상황;
• JTBD: 불안을 낮추고 시간을 절약하며, 3–7개의 적절한 후보를 고른다.

이 시나리오에서 우리는 다음을 합니다:

1. golden set에 direct, indirect, negative 요청을 각각 2–3개 작성한다.
2. system-prompt에 다음 조각을 추가한다:

   사용자가 특정 사람(친구, 조카, 동료 등)을 위한 선물을 고른다고 말하면,
   다음과 같이 하라:
   - 나이가 명시되지 않았다면 수신자 나이를 확인할 것;
   - 최소한 대략적인 예산과 상황을 확인할 것;
   - profile_to_segments와 recommend_gifts 도구를 호출하여
     3–7개의 적합한 후보를 고를 것;
   - 왜 그 후보들이 프로필과 예산에 맞는지 설명할 것.
   

3. 도구 recommend_gifts 설명에 다음을 명시한다:

   사용자 본인 또는 다른 사람을 위한, 특정 상황의 선물을 고르려 할 때 이 도구를 사용하라.
   특히 나이, 관심사, 예산이 언급될 때 적합하다.
   선물 추천과 무관한 작업에는 사용하지 말라.
   

4. golden set으로 검증한다: “12세 조카 선물 골라줘…”에는 도구가 호출되고, “IT 개발자 농담해줘”에는 도구가 호출되지 않으며 GiftGenius 없이 일반 텍스트 답을 한다.

무언가 잘못된다면(모델이 GiftGenius를 무시하거나, 반대로 선물 도메인 밖의 작업에도 사용하려고 한다면), system-prompt와 도구 설명으로 돌아가 문구를 강화합니다.

“허튼소리 금지” 한 줄로는 부족한 이유

환각을 막으려는 순진한 시도 중 하나: system-prompt 끝에 “존재하지 않는 선물을 만들지 마” 한 줄을 추가하는 것입니다. 아쉽지만 효과는 미미합니다.

하지만 다음을 함께 하면:

• JTBD로 “실제 카탈로그에 존재하며 지금 구매 가능한 아이디어만 제공”을 목표로 고정하고;
• recommend_gifts 설명에서 실제 데이터베이스(gift_catalog.{locale}.json)를 조회하며, 결과가 없으면 빈 목록을 반환함을 명시하고;
• golden set에 “전 세계 무료 배송을 내일 해주는 1$ 선물 추천” 같은 요청을 추가하고, should_call_tool: true와 “빈 결과를 반환하고 필터 완화 제안”을 기대값으로 설정하면,

— 모델이 올바르게 행동하도록 만드는 다층 시스템을 갖추게 됩니다.

8. 작은 시각화: JTBD에서 golden set까지

지금까지 내용을 그림 하나로 정리해 봅시다 — 기능에서 golden set까지.

flowchart TD
    A[GiftGenius 기능: 프로필 마법사, recommend_gifts, 구매] --> B[Use cases: 구체적인 증정자/HR의 이야기]
    B --> C[JTBD: 사용자가 왜 오는가]
    C --> D[system-prompt 지침과 tools 설명]
    B --> E[Golden Prompt Set: direct/indirect/negative]
    D --> F[실제 대화에서의 모델 행동]
    E --> F
    F --> G[관찰 후 규칙과 golden set 개선]

이 그림이 심리적으로도 중요합니다. golden set을 “데이터 사이언티스트용 무언가”로 보지 않고, 일반적인 엔지니어링 사이클의 일부로 바라보게 됩니다: 규칙을 정한다 → 기준 케이스로 검증한다 → 수정한다.

9. 실습 미니 과제(강의 후에 해보세요)

1. 현재의 GiftGenius를 가져오세요.
2. 핵심 use case 3개를 다음 형식으로 기술하세요:
   • “[누구]로서, [무엇]을 원한다. 그 이유는 [왜] 때문이다”.
3. 각 시나리오에 대해 다음을 만드세요:
   • direct 요청 1개,
   • indirect 요청 1개,
   • negative 요청 1개.
4. 각 요청에 대해 ideal.should_call_tool과(해당 시) ideal.expected_tool을 작성하세요.
5. 이를 tests/golden-prompts/giftgenius.golden.jsonl에 저장하세요.
6. 현재의 system-prompt를 살펴보고, 위 요청들에서 모델이 올바르게 행동하려면 무엇이 더 필요한지 정리하세요.

이 과제는 깊은 코드를 요구하지 않지만, 프롬프트를 크게 향상시키며 다음 모듈(MCP, 에이전트, evals)을 훨씬 덜 고통스럽게 만들어 줍니다.

10. use case, JTBD, golden prompt set 작업 시 흔한 실수

실수 №1: 기능 목록을 시나리오 맵으로 오해한다.
팀이 “우리 App은 15가지를 할 수 있다”고 자랑하지만, 명확한 use case 설명이 하나도 없는 경우가 있습니다. 그 결과 system-prompt는 추상적(“선물 도와줘”)이 되고, 모델은 GiftGenius를 아무 때나 호출하거나 거의 호출하지 않게 됩니다. 해결책은 기능을 구체적 이야기(“35세 엄마, 수신자 14세, 게임 좋아함, 예산…”)로 바꾸고 이를 문서화하는 것입니다.

실수 №2: JTBD가 PM 머릿속에만 있다.
프로덕트 매니저가 “우리 App이 해결하는 고통”을 멋지게 설명했지만, 리포지토리에는 단 한 줄도 남지 않고 프롬프트에도 반영되지 않는 경우가 있습니다. 그 결과 모델은 자신의 과제가 “선물 선택 불안 낮추기, 시간 절약, 성공적 선물의 빠른 반복 지원”인지 알지 못합니다. JTBD가 system-prompt와 도구 설명의 구체적 지시로 변환되지 않으면 무용지물입니다.

실수 №3: golden prompt set이 너무 작고 “멸균”되어 있다.
팀이 프레젠테이션에서 뽑은 그럴듯한 direct 요청 5–7개에 그치는 경우가 많습니다. 거기에는 어설픈 표현, 슬랭, 오타, 도발적 과제(“수신자 주소 바꿔줘”, “안전 제한 우회”)가 없습니다. 실제 사용자는 그런 식으로 쓰기 마련이어서, golden set이 실제 문제의 절반을 잡아내지 못합니다. 세트에는 “이상적인” 것뿐 아니라 direct, indirect, negative 케이스가 모두 포함되어야 합니다.

실수 №4: golden set을 아예 사용하지 않는다.
기준 요청 파일을 리포지토리에 추가해 놓고… 영영 방치하는 경우가 있습니다. 릴리스 전에 실행하지도, system-prompt 변경 시 사용하지도, CI에 연결하지도 않습니다. 세트를 유용하게 만들려면, 정기적으로(최소한 개발 환경에서라도) 실행하고 그 결과에 따라 프롬프트나 도구 설명을 고쳐야 합니다.

실수 №5: system‑prompt, 도구 설명, golden set 간의 모순.
예를 들어, golden set에는 “이 요청에서는 recommend_gifts를 호출해야 함”이라고 되어 있는데, 도구 설명에는 “B2B 선물에만 사용”이라고 쓰여 있는 경우가 있습니다. 모델은 상충 신호를 받습니다. 시스템 지침은 “GiftGenius를 불러”라고 하는데, 도구 설명은 “내 영역이 아님”이라고 합니다. 그 결과 어떤 세션에서는 도구를 호출하고, 어떤 세션에서는 호출하지 않습니다. 이 세 층(system‑prompt, tools, golden set)의 정합성을 유지하세요. 한 곳의 규칙을 바꿨다면 나머지도 업데이트해야 합니다.

실수 №6: “허튼소리 금지” 한 줄로 환각을 고치려 한다.
“허튼소리 금지”만으로는 부족합니다. “도구가 빈 결과를 반환했을 때 무엇을 할지”에 대한 시나리오와, golden set의 부정/무리한 요청이 없으면 소용이 없습니다. 모델은 여전히 “도움이 되고자” 하는 경향 때문에 경계 사례에서 상상해내려 합니다. 효과적인 접근은 조합입니다: JTBD → 엄격한 system‑prompt → 정확한 도구 설명 → 빈/오류 케이스를 포함한 golden set.

실수 №7: golden set으로 “모든 가능 요청”을 덮으려 한다.
수백 개의 케이스를 만들려다 중도 포기하는 경우가 있습니다. 끝없는 작업이 되기 때문입니다. 핵심 use case와 모델의 전형적 오류를 정말 반영하는 20–50개의 정교한 요청부터 시작하고, 새로운 문제가 발견될 때 점진적으로 확장하는 것이 좋습니다.