개념
프롬프트가 잘 안 먹히는 이유는 대개 구조에 있다
레슨 1에서 프롬프트로 테스트 케이스를 만들어봤다. 좋은 프롬프트가 좋은 결과를 만든다는 것도 확인했다. 그런데 실무에서 조금 더 쓰다 보면 이런 일들이 생긴다.
- 긴 요구사항 문서를 붙여 넣었더니 뒷부분을 아예 안 본 것 같은 답 이 온다
- 같은 프롬프트인데 어제와 오늘 결과가 다르다
- 형식을 지켜달라고 했는데 매번 다른 형식으로 나온다
- 예시를 보여주면 잘하는데, 말로 설명하면 못 한다
이건 프롬프트를 "더 정성껏" 써서 해결되는 문제가 아니다. 모델이 입력을 어떻게 다루는지, 그리고 프롬프트에 어떤 구성요소가 필요한지 를 알아야 풀린다.
이 레슨은 그 기초를 다진다. 국제 자격증 체계도 같은 판단을 하고 있다 — ISTQB의 생성형 AI 테스팅 자격증(CT-GenAI) 은 전체 5개 챕터 중 프롬프트 엔지니어링에 가장 많은 시간(365분)을 배정한다. 전체 학습 시간의 절반 가까이다.
먼저 토큰 — 모델은 글자를 보지 않는다
모델은 우리가 쓴 글을 토큰(token) 이라는 조각으로 잘라서 처리한다. 영어는 대략 단어 하나가 1~2토큰, 한국어는 글자 하나가 1토큰을 넘는 경우가 흔하다.
QA가 이걸 알아야 하는 이유는 셋이다.
1) 컨텍스트 윈도우 — 한 번에 넣을 수 있는 양에 상한이 있다.
모델마다 처리 가능한 토큰 수에 한계가 있다. 이 한계를 넘으면 입력이 잘리거나 거부되는데, 문제는 잘렸다는 사실이 답변에 드러나지 않는다 는 것이다. 모델은 남은 부분만 보고 자신 있게 답한다.
요구사항 명세 80페이지를 통째로 붙여 넣고 "테스트 케이스를 만들어줘" 라고 했는데, 뒤쪽 30페이지 기능이 결과에 하나도 없다. 누락이라고 생각하지만 실제로는 모델이 그 부분을 본 적이 없다.
이 실패는 조용해서 위험하다. 대응은 단순하다 — 긴 입력은 나눠서 넣고, 결과에 앞부분만 반영되지 않았는지 확인한다. 뒤에 나올 프롬프트 체이닝이 이 문제의 정석 해법이다.
2) 비용 — 토큰이 곧 돈이다.
API 과금은 대체로 입력·출력 토큰 수를 기준으로 한다. 매 커밋마다 큰 컨텍스트를 밀어 넣는 파이프라인을 만들면 비용이 선형으로 는다. 모듈 18a(레슨 10)에서 CUA의 실행 비용을 따진 것과 같은 계산이다.
3) 한국어는 토큰 효율이 나쁘다.
같은 내용이라도 한국어가 영어보다 토큰을 더 쓰는 경우가 많다. 컨텍스트 한계에 더 빨리 닿고 비용도 더 든다는 뜻이다. 긴 코드나 로그를 넣을 때 특히 체감된다.
실무 감각: 토큰 수를 정확히 셀 필요는 없다. 다만 "지금 내가 넣는 입력이 한계에 가까운가"를 의식하는 것만으로 조용한 실패의 상당수를 피할 수 있다.
모델의 종류를 구분하면 도구 선택이 쉬워진다
같은 LLM이라도 성격이 다르다. 테스트 업무에 어떤 것을 쓸지 고를 때 알아둘 구분이다.
| 유형 | 성격 | 테스트 업무에서 |
|---|---|---|
| 파운데이션 모델 | 대규모 사전학습만 된 상태 | 그대로 쓰기엔 지시 따르기가 약하다 |
| 인스트럭션 튜닝 모델 | 지시를 따르도록 추가 학습됨 | 대부분의 테스트 작업의 기본 선택 |
| 추론(reasoning) 모델 | 답하기 전에 단계적으로 생각 | 복잡한 조합·경계 분석, 근거가 필요한 판단 |
| 멀티모달·비전 언어 모델 | 이미지·화면을 함께 이해 | 와이어프레임에서 인수기준 뽑기, UI 이상 판정 |
멀티모달이 QA에게 특히 값을 한다. 기획 산출물이 텍스트만이 아니기 때문이다. 화면 설계서 이미지와 유저 스토리를 함께 주면 텍스트만 줬을 때보다 훨씬 구체적인 결과가 나온다. 다음 레슨에서 이걸 실습한다.
온도(temperature) — 같은 질문에 다른 답이 나오는 이유
온도 는 출력의 무작위성을 조절하는 값이다. 낮으면 안정적이고 반복 가능한 답이, 높으면 다양하지만 예측하기 어려운 답이 나온다.
| 작업 | 권장 방향 |
|---|---|
| 테스트 케이스를 정해진 형식으로 생성 | 낮게 — 재현성이 중요 |
| 아이디어 발산, 놓친 시나리오 찾기 | 높게 — 다양성이 목적 |
| 판정·평가(LLM-as-judge) | 낮게 — 일관성이 생명 |
온도를 0에 가깝게 해도 완전히 결정적이지는 않다. 이 사실이 모듈 18b(레슨 5)에서 다룬 통계적 검증의 출발점이다 — 반복 실행과 통과율로 다뤄야 하는 이유 가 여기 있다.
6요소 프롬프트 구조
여기가 이 레슨의 핵심이다. 테스트 업무용 프롬프트는 여섯 가지 구성요소 로 짜는 것이 표준적인 접근이다.
| 요소 | 무엇을 담나 | 예 |
|---|---|---|
| 역할(Role) | 어떤 관점에서 답할 것인가 | "너는 결제 도메인 경험이 있는 QA 엔지니어다" |
| 맥락(Context) | 배경 정보 | "이 서비스는 B2C 커머스이고, 이번 릴리즈는 쿠폰 중복 적용을 허용한다" |
| 지시(Instruction) | 수행할 작업 | "아래 유저 스토리에서 테스트 조건을 도출하라" |
| 입력 데이터(Input data) | 작업 대상 | 유저 스토리, 인수기준, 화면 캡처, 코드, 기존 케이스 |
| 제약(Constraints) | 지켜야 할 조건 | "경계값 분석과 동등분할만 사용", "최대 15개", "결제 취소는 범위 제외" |
| 출력 형식(Output format) | 결과의 모양 | "표로. 열은 ID·조건·입력·기대결과·우선순위" |
나쁜 프롬프트와 좋은 프롬프트의 차이는 대개 빠진 요소의 개수다.
[ 빠진 것이 많은 프롬프트 ]
"로그인 테스트 케이스 만들어줘"
→ 역할·맥락·입력데이터·제약·출력형식이 전부 없다
→ 일반론적인 케이스 10개가 나온다. 우리 제품과 무관하다
[ 여섯 요소를 채운 프롬프트 ]
역할: 인증 도메인 QA 엔지니어
맥락: 소셜 로그인 3종과 이메일 로그인을 지원. 5회 실패 시 10분 잠금
지시: 아래 인수기준에서 테스트 조건을 도출하라
입력: (인수기준 원문)
제약: 동등분할·경계값·상태전이만 사용. 소셜 로그인은 이번 범위 제외
출력: 표. 열은 ID / 기법 / 조건 / 입력 / 기대결과 / 우선순위(1~3)제약과 출력 형식을 빠뜨리는 사람이 가장 많다. 그런데 이 둘이 결과의 재사용성을 결정한다. 출력 형식을 지정하면 그대로 테스트 관리 도구에 붙여 넣을 수 있고(모듈 22), 지정하지 않으면 매번 손으로 정리해야 한다.
시스템 프롬프트와 사용자 프롬프트
도구에 따라 프롬프트가 두 층으로 나뉜다.
- 시스템 프롬프트 — 대화 전체에 적용되는 설정. 역할·제약·출력 규칙처럼 매번 반복되는 것 을 여기에 둔다.
- 사용자 프롬프트 — 그때그때의 지시와 입력 데이터.
실무에서 이 구분이 주는 이득은 크다. 팀의 테스트 케이스 작성 규칙, 우선순위 기준, 출력 형식을 시스템 프롬프트에 한 번 넣어두면 팀원 누가 쓰든 같은 형식의 결과 가 나온다. 모듈 18a(레슨 8)에서 Claude Skills로 업무를 표준화한 것과 같은 발상이다.
핵심 기법 셋
구조를 갖췄으면 다음은 기법이다. 테스트 업무에서 실제로 쓰이는 것은 세 가지다.
1) 프롬프트 체이닝(Prompt Chaining)
한 번에 다 시키지 않고 여러 단계로 쪼개서, 각 단계의 결과를 확인· 보정한 뒤 다음 단계로 넘긴다.
[한 번에] "이 유저 스토리로 테스트 케이스 만들어줘"
→ 모호한 요구사항 위에 그럴듯한 케이스가 쌓인다
[체이닝]
① "이 유저 스토리에서 모호한 부분을 찾아라" → 사람이 확인·보정
② "①의 결과를 반영해 인수기준의 테스트 가능성을 평가하라" → 확인
③ "②를 반영해 인수기준의 완전성을 평가하라" → 확인
④ "확정된 인수기준에서 테스트 조건을 도출하라"각 단계에서 사람이 개입할 지점이 생기는 것 이 체이닝의 진짜 값이다. 긴 입력을 나눠 넣는 방법이기도 해서, 앞에서 본 컨텍스트 한계 문제도 함께 해결된다.
2) 퓨샷 프롬프팅(Few-shot Prompting)
예시를 프롬프트에 넣어주는 기법이다. 예시 개수로 이름이 갈린다.
| 이름 | 예시 개수 | 언제 |
|---|---|---|
| 제로샷(zero-shot) | 0개 | 일반적인 작업, 모델이 이미 잘 아는 것 |
| 원샷(one-shot) | 1개 | 형식만 맞추면 되는 경우 |
| 퓨샷(few-shot) | 여러 개 | 우리 팀 스타일을 따르게 하고 싶을 때 |
설명보다 예시가 강하다. "우리 팀 테스트 케이스 형식은 이러이러하고 저러저러하다"고 세 문단을 쓰는 것보다, 잘 쓴 케이스 3개를 붙여 넣는 것이 훨씬 정확하게 전달된다. 팀의 우수 사례를 모아두면 그대로 퓨샷 예시 자산이 된다.
3) 메타 프롬프팅(Meta Prompting)
프롬프트 자체를 AI에게 만들게 하는 기법이다.
"결제 실패 시나리오의 테스트 조건을 도출하려고 한다. 이 작업에 적합한 프롬프트를 6요소 구조로 작성해줘. 내가 놓칠 만한 제약도 함께 제안해줘."
받은 프롬프트를 사람이 검토·수정해서 쓴다. 프롬프트를 어떻게 써야 할지 막막할 때 특히 유용하고, AI와 함께 프롬프트를 만드는 협업 형태에 가깝다. 다만 나온 프롬프트를 그대로 믿으면 안 된다 — 이 커리큘럼의 원칙(모듈 18c)이 여기에도 적용된다.
기법을 고르는 기준
셋은 배타적이지 않고 조합해서 쓴다. 상황별 선택은 대략 이렇다.
| 상황 | 기법 |
|---|---|
| 작업이 복잡하고 중간 확인이 필요하다 | 체이닝 |
| 입력이 길어 한 번에 안 들어간다 | 체이닝 |
| 결과 형식·스타일을 우리 팀에 맞춰야 한다 | 퓨샷 |
| 판정 기준이 미묘해서 말로 설명하기 어렵다 | 퓨샷(좋은 예 + 나쁜 예) |
| 어떻게 물어야 할지 모르겠다 | 메타 프롬프팅 |
| 같은 작업을 팀에서 반복한다 | 시스템 프롬프트 + 퓨샷을 템플릿으로 고정 |
마지막 줄이 실무에서 가장 큰 차이를 만든다. 좋은 프롬프트는 한 번 쓰고 버리는 것이 아니라 팀 자산으로 관리한다.
이 커리큘럼과 CT-GenAI 실라버스의 대응
생성형 AI 테스팅을 자격증으로 준비한다면, 이 커리큘럼의 어느 레슨이 어디에 해당하는지 알아두면 좋다. ISTQB CT-GenAI는 5개 챕터로 구성된다.
| 실라버스 챕터 | 이 커리큘럼 |
|---|---|
| 1. 생성형 AI 소개·핵심 개념 | 이 레슨(전반부) |
| 2. 프롬프트 엔지니어링 | 이 레슨(후반부) + 레슨 12 + 레슨 1 |
| 3. 리스크 관리 — 환각·추론오류·편향 | 모듈 18b 레슨 2·4·5 |
| 3. 리스크 관리 — 프라이버시·보안·환경 | 모듈 18b 레슨 9 |
| 3. 리스크 관리 — 규제·표준 | 모듈 18b 레슨 6 |
| 4. LLM 기반 테스트 인프라 | 모듈 18b 레슨 10 + 모듈 18a 레슨 4·5 |
| 5. 조직 배포·도입 | 모듈 18b 레슨 10(후반부) |
여기에 이 커리큘럼만의 것이 더해진다 — 모듈 18c의 교차검증과 하네스 다. 실라버스가 "AI를 잘 쓰는 법"에 무게를 둔다면, 이 커리큘럼은 "AI가 만든 것을 검증하는 법" 을 한 단계 더 파고든다.
실무에서 왜 필요한가
프롬프트를 감으로 쓰는 사람과 구조로 쓰는 사람의 차이는 재현성 에서 갈린다. 감으로 쓰면 오늘 좋은 결과가 나와도 내일 같은 결과를 못 만들고, 동료에게 전수할 수도 없다. 6요소 구조로 쓰면 프롬프트가 문서화 가능한 자산 이 된다.
토큰과 컨텍스트 윈도우를 아는 것도 실질적이다. "AI가 이걸 놓쳤다"는 불평의 상당수가 실제로는 모델이 그 부분을 보지 못한 것 이다. 원인을 구분할 수 있으면 대응이 달라진다 — 프롬프트를 고칠 일이 아니라 입력을 나눌 일이다.
그리고 이 지식은 팀에 기여하는 통로가 된다. 팀의 시스템 프롬프트와 퓨샷 예시 세트를 만들어두는 일은 QA가 하기 좋고, 만들어두면 팀원 전체의 결과 품질이 올라간다. 모듈 18a 레슨 8의 표준화와 같은 효과다.