Kwangmin Kim - 프롬프트 테스트 실전 가이드: 7단계 업무 절차와 평가 방법론

1 들어가며

실제로 테스트를 어떤 순서로 진행하고,
어떤 종류의 방법을 사용하는지를 다룬다.

그리고 이 다음 블로그에 사용할 테스트 도구까지 소개한다. 즉, 이론에서 실행으로의 전환점이다.

2 7단계 업무절차

실제 업무에서 프롬프트 테스트를 수행할 때의 흐름을 작성한 것이다.

1단계: 테스트 기준 마련 (주관적 논쟁을 객관적 판단으로 전환)
2단계: 프롬프트 품질 분석
3단계: 테스트 결과 정리 (Type 1 vs Type 2 비교)
4단계: 최종 프롬프트 선별 (성공률 60% vs 80% 데이터 기반 선택과 검증 로직 보완)
5단계: 사용자 피드백 및 이슈 관리 (베타 테스트 20명, 10가지 실제 입력)
6단계: 프롬프트 언어 분석 (영어/한국어 조합 3가지 테스트)
7단계: 지속적인 결과 개선 (3개월 주기 개선 사이클)

각 단계를 설명하기 위해 질문 생성기 프롬프트를 일관된 예시로 사용한다.

질문 생성기란?

사용자가 주제를 입력하면(예: “부산 여행”), 3가지 각도의 질문을 반말로 생성하는 프롬프트다.

Certainty 관점 3가지 질문 유형: - certainty: “확신의 정도”를 나타내며, 질문의 일반성과 개인적 불확실성 정도를 구분하는 개념
- High certainty: 확신 높은 질문 - 일반적이고 누구나 궁금해할 내용 (예: “부산에서 뭐 할까?”)
- Moderate certainty: 중간 확신 질문 - 특정 상황이나 맥락이 필요한 내용 (예: “어디 먼저 갈까?”)
- Low certainty: 낮은 확신 질문 - 불확실하거나 개인차가 큰 내용 (예: “혼자 가도 괜찮아?”)

각 질문은 서로 다른 각도에서 접근하며, 반말 형식(5단어 이내)으로 생성된다.

2.1 테스트 기준 마련

테스트 기준: “좋은 프롬프트”를 어떻게 판단할 것인가?
“기대 결과”를 구체화하는 단계다.
기준이 없으면 테스트 결과를 봐도 “성공인지 실패인지” 판단할 수 없다.

질문 생성기 (프롬프트) 예시:

프롬프트 목적: 사용자가 “부산 여행”을 입력하면, 3가지 각도의 질문을 반말로 생성

구체적 기준 목록:

기준 1: 항상 정확히 3개의 질문 반환 (2개도, 4개도 안 됨)
기준 2: High/Moderate/Low certainty 섹션 명확히 구분
기준 3: 세 질문은 서로 다른 각도 (중복 불가)
기준 4: 반말만 사용 (“합니다” 체 금지)
기준 5: 각 질문은 5단어 이내
기준 6: 질문 외 주석/설명 없음 (“예를 들어…” 같은 부연 금지)

실제 테스트 결과 예시:

입력: “부산 여행”

프롬프트 A 출력:

High certainty: 부산 여행 언제 가?
Moderate certainty: 어떤 코스로 갈까?
Low certainty: 혼자 가도 괜찮을까?

평가: - ✓ 기준 1: 3개 (Pass) - ✓ 기준 2: 섹션 구분 (Pass) - ✓ 기준 3: 서로 다른 각도 (Pass) - ✓ 기준 4: 반말 (Pass) - ✗ 기준 5: “어떤 코스로 갈까?”는 6단어 (Fail) - ✓ 기준 6: 질문만 출력 (Pass)

결과: Fail (기준 5 미달)

왜 이 단계가 중요한가?

기준이 없을 때:

팀원 A: "이 프롬프트 괜찮은데요?"
팀원 B: "아니 질문이 너무 긴 것 같은데..."
팀원 C: "뭐가 길다는 거에요? 저는 이 정도면 적당한 것 같은데?"
→ 3시간 토론, 결론 없음

기준이 있을 때:

팀원 A: "기준 5 위반했어요. 5단어 초과."
팀원 B: "맞네요. 수정 필요."
→ 5분 종료, 즉시 개선 착수

객관적 기준이 주관적 논쟁을 객관적 판단으로 바꿔준다.

2.2 프롬프트 품질 분석

실제로 실행하기 전에, 프롬프트 자체를 먼저 검토한다.
“이 프롬프트가 작동할 가능성이 높은가?”를 미리 판단하는 단계다.
테스트하기 전에 명확한 결함을 먼저 발견하면, 테스트 시간을 절약할 수 있다.

질문 생성기 프롬프트 예시:

버전 A (검토 전):

Generate 3 questions about the user's input.
Use casual Korean tone.

품질 분석 체크리스트:

체크 항목	현재 상태	문제점
역할 정의	✗ 없음	“너는 누구인가?” 불명확
입력 형식	✗ 불명확	“user’s input”이 무엇인지 모호
출력 구조	✗ 없음	3개 질문을 어떻게 구분?
제약 조건	△ 일부	“casual tone”만으로 반말 보장 안 됨
예시	✗ 없음	LLM이 뭘 원하는지 추측해야 함

평가: 실행 전에 이미 문제 발견 → 개선 필요

버전 B (개선 후):

You are a question generator that creates 3 different questions 
based on user's input topic.

Input format: A single topic keyword (e.g., "부산 여행")

Output format:
High certainty: [5 words or less question]
Moderate certainty: [5 words or less question]  
Low certainty: [5 words or less question]

Constraints:
- Use Korean casual speech (반말, ending with "?" not "요?")
- Each question must explore a different angle
- No explanations, just questions

재검토 결과:

체크 항목	개선 후 상태	비고
역할 정의	✓ 명확	“question generator”
입력 형식	✓ 명확	예시까지 제공
출력 구조	✓ 명확	3개 섹션 구분
제약 조건	✓ 구체적	“반말”, “5단어”, “다른 각도” 명시
예시	✓ 있음	괄호 안에 구체적 예시

평가: 실행 전 검토 통과 → 테스트 진행 가능

왜 이 단계가 중요한가? 2단계 없이 바로 3단계로 가면:

Day 1: 버전 A 테스트 시작
       → 10개 입력 테스트
       → 결과: 형식 엉망, 한국어/영어 섞임, 질문 개수 불규칙
       
Day 2: "프롬프트가 너무 모호해요" 깨달음
       → 버전 B로 수정
       → 다시 10개 입력 테스트
       → 시간 낭비: 2일

총 시간: 2일

2단계를 거치면:

Day 1 오전: 버전 A 품질 분석 (30분)
            → 즉시 문제 발견
            → 버전 B로 개선 (30분)
            
Day 1 오후: 버전 B 테스트 시작
            → 10개 입력 테스트
            → 결과: 형식 안정적, 기준 대부분 충족

총 시간: 1일

불필요한 시행착오 방지

2단계는 “종이 위에서 먼저 확인”하는 단계다.
실제 실행은 비용(시간, API 호출)이 드니까, 명백한 문제는 미리 잡는다.

2.3 테스트 결과 정리

실제로 실행한 결과를 체계적으로 기록한다.
“좋았다/나빴다”가 아니라, 어떤 조건에서 어떤 결과가 나왔는지를 정리한다.
나중에 4단계(선별)에서 근거 있는 결정을 하려면, 이 기록이 필수다.

상황 설정:

질문 생성기 프롬프트 2가지 버전을 비교한다: - Type 1: Introduction → Response template → Ending

You are a question generator that creates 3 different questions 
based on user's input topic.

Input format: A single topic keyword (e.g., "부산 여행")

Output format:
High certainty: [5 words or less question]
Moderate certainty: [5 words or less question]
Low certainty: [5 words or less question]

Constraints:
- Use Korean casual speech (반말, ending with "?" not "요?")
- Each question must explore a different angle
- No explanations, just questions

Type 2: Introduction → Ending → Response template (순서 변경)

You are a question generator that creates 3 different questions 
based on user's input topic.

Input format: A single topic keyword (e.g., "부산 여행")

Constraints:
- Use Korean casual speech (반말, ending with "?" not "요?")
- Each question must explore a different angle
- No explanations, just questions

Output format:
High certainty: [5 words or less question]
Moderate certainty: [5 words or less question]
Low certainty: [5 words or less question]

차이점: - Type 1: 출력 형식(Response template)을 먼저 보고, 마지막에 제약조건(Ending) - Type 2: 제약조건(Ending)을 먼저 보고, 마지막에 출력 형식(Response template)

테스트 입력 5개:

1. "부산 여행"
2. "주식 투자"
3. "헬스 다이어트"
4. "강아지 훈련"
5. "영어 공부"

결과 정리 표:

입력	Type 1 결과	Type 2 결과	비교
부산 여행	✓ 3개 질문, 반말, 각도 다름	✓ 3개 질문, 반말, 각도 다름	동일
주식 투자	✓ 3개 질문, 반말, 각도 다름	✗ 2개 질문만 출력	Type 1 우수
헬스 다이어트	✗ “합니다” 체 혼입	✓ 반말 유지	Type 2 우수
강아지 훈련	✓ 3개 질문, 반말, 각도 다름	✓ 3개 질문, 반말, 각도 다름	동일
영어 공부	✗ High/Moderate 중복됨	✓ 각도 명확히 구분	Type 2 우수

통계 요약 및 분석

Type 1: 3/5 완전 성공 (60%)
        - 안정적 출력 개수
        - 반말 형식 불안정
        
Type 2: 4/5 완전 성공 (80%)
        - 가끔 출력 개수 불안정
        - 반말 형식 안정적

Type 1의 약점: - “Ending이 마지막에 와서 형식 지시가 약해짐” - Response template 먼저 보고 생성 시작 → 마지막 Ending 무시

Type 2의 약점: - “Ending을 먼저 보니 형식은 잘 지키지만…” - 가끔 Response template 섹션 구분을 놓침

개관적 분석 가능

정리 없이 그냥 “느낌”만으로:

개발자: "Type 2가 더 나은 것 같아요."
PM: "왜요?"
개발자: "음... 그냥 결과가 더 좋아 보여서요."
PM: "구체적으로 뭐가?"
개발자: "잘... 기억이 안 나네요. 다시 테스트해볼까요?"
→ 같은 테스트 반복

체계적 정리를 했을 때:

개발자: "Type 2가 80% 성공률입니다."
PM: "Type 1은?"
개발자: "60%인데, 특히 반말 형식에서 불안정합니다. (표 공유)"
PM: "이유는?"
개발자: "Ending이 마지막이라 LLM이 놓치는 것 같습니다."
PM: "알겠습니다. Type 2로 가죠. 출력 개수 불안정은 검증 로직으로 보완합시다."
→ 근거 있는 즉시 결정

결과를 표나 구조화된 기록으로 남기면: - 나중에 참고 가능 - 팀원과 공유 쉬움 - 결정 근거 명확

“기억에 의존” → “기록에 의존”으로 바뀐다.

2.4 최종 프롬프트 선별

3단계의 데이터를 바탕으로 하나를 선택한다.
이건 규칙 1(“최소 두 가지 버전”)이 빛을 발하는 순간이다.
비교 대상이 있어야 “선택”이 가능하다.

의사결정 회의 시나리오:

참석자: PM, 개발자, QA

개발자 발표:

3단계 테스트 결과 요약:
- Type 1: 60% 성공률, 반말 불안정
- Type 2: 80% 성공률, 출력 개수 가끔 불안정

PM 질문: “Type 2의 ’출력 개수 불안정’은 어느 정도인가요?”
개발자: “5개 입력 중 1개에서 2개만 출력. 20% 비율입니다.”
QA: “그럼 Type 2 쓰되, 출력 검증 로직 추가하면 되겠네요.”
개발자:

def validate_output(response):
    questions = response.split('\n')
    if len(questions) != 3:
        return False  # 재생성 요청
    return True

PM: “좋습니다. Type 2로 결정. 검증 로직은 내일까지 구현.”

결정 근거 문서:

의사결정 기록 (2026-02-04)
---
문제: Type 1 vs Type 2 선택
결정: Type 2 채택

이유:
1. 성공률 20%p 높음 (60% → 80%)
2. 반말 형식 안정성이 핵심 요구사항
3. 출력 개수 문제는 검증 로직으로 해결 가능

트레이드오프:
- 장점: 형식 안정적, 사용자 경험 일관성
- 단점: 재생성 로직 추가 개발 필요 (1일 소요)

대안 검토:
- Type 1 개선: Ending 강조 시도했으나 효과 미미
- 하이브리드: 복잡도 증가로 기각

근거 없는 선택 방지

"Type 2가 더 나아 보이니까 이걸로 하죠."
→ 3개월 후 문제 발생 시: "왜 Type 2 선택했죠?"
→ 아무도 모름

근거 있는 선택 지향

"Type 2 선택 이유: 반말 안정성 80%, 의사결정 기록 참조"
→ 3개월 후 문제 발생 시: 기록 확인 → 당시 맥락 파악 → 개선 방향 결정

선택의 이유와 과정을 남기는 것이 핵심이다.

2.5 사용자 피드백 및 이슈 관리

핵심: 선별 직후, 실제 사용자로 테스트한다.

주목할 점: 이 단계는 “배포 후”가 아니라 “선별 후 즉시”다.
내부 테스트만으로는 실제 사용 환경의 다양성을 못 잡는다.

베타 테스트 진행 (1주일):

참여자: 사내 직원 20명 (실제 사용자 시뮬레이션)

입력 데이터 (실제 수집):

1. "부산여행" ✓ 정상
2. "주시투자" (오타)
3. "헬스 ㄷ다이어트" (오타 + 자음 분리)
4. "강아지" (너무 짧음)
5. "영어공부 잘하는 법 알려줘" (너무 김)
6. "ㅎㅇ" (의미 없는 입력)
7. "파이썬 배우기"
8. "재택근무" 
9. "!!!" (특수문자만)
10. "주식투자 부동산투자 암호화폐" (여러 주제)

발견된 이슈:

이슈 ID	입력	문제	심각도	비율
ISS-001	“주시투자”	오타 인식 못함, 질문 엉뚱함	높음	15%
ISS-002	“ㅎㅇ”	의미 없는 질문 생성	중간	10%
ISS-003	“강아지”	너무 짧아서 맥락 부족 질문	낮음	5%
ISS-004	“주식… 암호화폐”	첫 주제만 인식	중간	8%

즉시 조치:

# ISS-001 해결: 입력 전처리 추가
def preprocess_input(user_input):
    # 오타 교정 라이브러리 적용
    corrected = spell_checker.correct(user_input)
    return corrected

# ISS-002 해결: 입력 검증
def validate_input(user_input):
    if len(user_input) < 2 or not has_meaningful_chars(user_input):
        return "다시 입력해주세요. 주제를 명확히 적어주세요."
    return None  # 통과

피드백 루프:

Week 1: 베타 테스트 → 4개 이슈 발견
Week 1 말: 전처리/검증 로직 추가 → 재배포
Week 2: 재테스트 → 이슈율 38% → 8% 감소
Week 2 말: 정식 배포 승인

왜 내부 테스트만으로 부족한가?

내부 테스트 입력 (깔끔함):

"부산 여행"
"주식 투자"
"헬스 다이어트"

→ 모두 정상 작동

실제 사용자 입력 (현실):

"부사너행" (오타)
"주식ㅠㅠ" (감정 표현)
"헬스?" (의문형)

→ 프롬프트 혼란

실제 사용자는 완벽하게 입력하지 않는다.
5단계는 그 현실을 마주하는 단계다.

2.6 6단계: 프롬프트 언어 분석

핵심: 프롬프트 언어가 출력 품질에 어떤 영향을 주는가?

이건 단순한 “번역” 문제가 아니다.
같은 내용이라도 언어에 따라 LLM의 반응이 달라진다.

질문 생성기 상황: - 프롬프트: 영어 - 출력: 한국어 반말

3가지 언어 조합 테스트:

버전 A: 프롬프트 영어, 출력 지시 영어

Generate 3 questions in Korean casual speech (반말).

버전 B: 프롬프트 영어, 출력 지시 한국어

Generate 3 questions.
Output format: 한국어 반말로 작성 (예: "뭐 할까?", "어때?")

버전 C: 프롬프트 한국어, 출력 지시 한국어

당신은 질문 생성기입니다.
사용자 입력 주제에 대해 3개 질문을 생성하세요.
출력 형식: 한국어 반말 (예: "뭐 할까?", "어때?")

테스트 결과 (GPT-4 기준):

버전	반말 준수율	영어 혼입	자연스러움	평균 품질
A (영/영)	70%	30%	중간	★★★☆☆
B (영/한)	90%	5%	높음	★★★★☆
C (한/한)	95%	2%	매우 높음	★★★★★

버전 A 실제 출력 예시:

High certainty: What should I do in Busan? (영어 혼입!)
Moderate certainty: 부산 어디 가볼까?
Low certainty: 혼자 가도 괜찮아요? (존댓말 혼입!)

버전 C 실제 출력 예시:

High certainty: 부산 뭐 할까?
Moderate certainty: 어디 가볼까?
Low certainty: 혼자 가도 괜찮아?

→ 일관성 ↑, 자연스러움 ↑

왜 이런 차이가 생기나?

GPT-4 학습 데이터 구성 (추정): - 영어 데이터: 70% - 한국어 데이터: 5% - 기타 언어: 25%

영어 프롬프트 (버전 A):

LLM 내부 처리:
1. 영어 프롬프트 이해 (강점)
2. "Korean casual speech" 해석
3. 영어 → 한국어 전환 (약점)
→ 전환 과정에서 불안정

한국어 프롬프트 (버전 C):

LLM 내부 처리:
1. 한국어 프롬프트 이해 (약점이지만...)
2. 한국어 예시 참조 ("뭐 할까?", "어때?")
3. 같은 패턴으로 생성
→ 예시 덕분에 안정적

핵심 발견:

프롬프트 언어보다 출력 예시가 더 중요하다!
버전 B (영/한)가 버전 A (영/영)보다 좋은 이유: → 한국어 예시 “뭐 할까?”, “어때?”가 LLM에게 명확한 타겟을 제공

실무 적용:

결론: 버전 C 채택

이유:
1. 반말 준수율 95% (최고)
2. 영어 혼입 2% (최저)
3. 자연스러움 최고

단, 프롬프트 수정 시:
- 한국어 프롬프트는 오타/문법 주의 필요
- 영어 프롬프트보다 유지보수 난이도 약간 높음
- 팀 내 한국어 네이티브 리뷰 필수

6단계는 “무슨 언어 쓸까?”를 넘어서, “이 언어 조합이 출력 품질을 어떻게 바꾸나?”를 데이터로 확인하는 단계다.

2.7 지속적인 결과 개선

테스트는 한 번으로 끝나지 않는다.
모델이 변하고, 사용자 패턴이 변하고, 비즈니스 요구사항이 변한다.

질문 생성기의 경우, 오늘 잘 작동했던 프롬프트를 3개월 후 다시 돌리면 형식이 달라질 수 있다.
그때 다시 1단계로 돌아가서 기준을 재확인하고, 새로운 모델 버전에서 다시 테스트한다.
이 루프가 프롬프트의 실제 수명을 결정한다.

2.7.1 예시: 3개월 주기 개선 사이클

질문 생성기의 개선 이력을 시간순으로 정리한 것이다.

시점	모델 버전	발견된 이슈	개선 조치	결과
1월	GPT-4-0613	Low certainty 질문이 너무 추상적	“구체적 예시를 포함하라” 지시 추가	구체성 40% → 75% 향상
2월	GPT-4-0613	사용자 오타에 취약 (“부사너행” 입력 시 질문 생성 실패)	“입력 보정” 단계 추가	오류율 15% → 3% 감소
4월	GPT-4-turbo	모델 업데이트 후 반말 형식 무너짐 (“합니다” 체 출현)	Ending에 “반드시 반말을 사용하라” 강조 추가	반말 준수율 100% 복구
5월	GPT-4-turbo	High certainty와 Moderate certainty 질문 중복 증가	“각 질문은 서로 다른 각도여야 한다” 명시	중복률 20% → 5% 감소
7월	GPT-4o	질문 길이가 불균일 (5단어 제약 무시)	형식 체크 후 재생성 로직 추가	길이 제약 준수율 95% 달성

개선 사이클의 특징: - 모델 업데이트 감지: 4월의 GPT-4-turbo 전환 시점에서 기존 프롬프트가 무너진다. 이건 외부 요인이지만, 정기 테스트가 없었다면 발견이 늦어졌을 것이다. - 사용자 패턴 반영: 2월의 오타 케이스는 내부 테스트에서는 없었던 패턴이다. 실제 사용자 로그를 분석해야 발견된다. - 누적 개선: 1월의 구체성 개선이 7월까지 유지되는지를 확인한다. 새로운 수정이 이전 개선을 망가뜨리지 않는지를 검증한다.

개선 트리거 3가지: 1. 정기 점검: 매 분기 같은 테스트 데이터셋으로 재실행 (모델 변화 감지) 2. 이슈 보고: CS 팀에서 올라온 사용자 불만 (실제 사용 패턴 반영) 3. 비즈니스 요구: “질문이 너무 길어서 UI에 안 들어간다” 같은 새로운 제약

이 세 가지가 7단계를 움직이는 힘이다.
정기 점검이 없으면 모델 변화를 놓친다. 이슈 보고가 없으면 실제 사용자와 괴리된다. 비즈니스 요구가 없으면 제품과 분리된다.
7단계는 단순히 “또 테스트하자”가 아니라, 이 세 가지 신호를 계속 받아들이는 구조이다.

3 7단계의 내부 리듬

준비(1단계) -> 분석(2단계) -> 실행과 정리(3단계) -> 결정(4단계) -> 검증(5단계) -> 세부 확인(6단계) -> 반복(7단계).
이건 제품 개발의 한 사이클과 거의 동일한 구조이다.

4 두 가지 축: 정성적과 정량적

테스트 방법은 두 축으로 나뉜다.
프롬프트 평가에서 답을 얻을 수 있는 질문의 종류 자체가 두 종류이기 때문이다.

같은 질문 생성기 프롬프트에 대해, 두 축이 답하는 질문이 다르다는 건 바로 여기서 보인다.

4.1 정성적 방법이 답하는 질문

“이 프롬프트가 의도대로 작동하는가?”
이 질문은 사람이 출력을 읽고 판단해야 한다.

질문 생성기의 경우, 정성적 방법이 확인하는 건 이런 것이다.
High certainty 섹션에서 나온 질문이 실제로 가장 확신 높은 질문인지.
Low certainty 섹션에서 나온 질문이 실제로 독자의 궁금증을 자극하는지.
세 질문의 각도가 진짜로 서로 다른지.
이건 숫자로 잡을 수 없는 부분이다. 사람이 읽고 판단해야 한다.

4.2 정량적 방법이 답하는 질문

“이 프롬프트가 얼마나 안정적으로 작동하는가?”
같은 프롬프트를 반복 실행했을 때, 결과의 패턴과 일관성을 확인한다.

질문 생성기의 경우, 정량적 방법이 확인하는 건 이런 것이다.
같은 입력을 20번 넣었을 때, 항상 세 질문이 반환되는지.
형식이 무너지는 횟수가 20번 중 몇 번인지.
주제가 겹치는 횟수가 얼마나 되는지.
이건 한 번만 보면 알 수 없는 것이다. 반복 실행 없이는 패턴이 보이지 않는다.

4.3 둘의 관계

정성적 검증이 먼저 통과되어야 정량적 검증이 의미를 가진다.
High certainty 섹션이 실제로 좋은 질문을 내는지가 확인되기 전에, 그 질문이 “얼마나 안정적으로”나오는지를 측정하는 건 순서가 뒤집은 것이다.
먼저 “제대로 작동하는지” -> 그 다음 “그게 안정적인지”.
정성적과 정량적은 단순히 두 가지 방법이 아니라, 순차적으로 적용되는 두 층의 검증이다.

5 Prompt Testbed

The Prompt Testbed
https://the-prompt-playground.vercel.app/

ChatGPT이나 Claude에서도 프롬프트를 실행할 수 있다.
하지만 거기서는 같은 프롬프트를 20번 반복 실행하고, 그 결과 20건을 한 눈에 비교하기 어렵다.
한 번 실행하면 결과가 나오고, 다음에 다시 실행하면 이전 결과가 사라진다.
패턴을 보려면 결과를 모아야 하는데, 일반 대화형 UI는 그 구조가 아니다.

Testbed는 바로 그 부분을 해결하는 환경이다.
동일한 프롬프트를 반복 실행하고, 각 결과를 나열하고, 비교할 수 있는 구조이다.
규칙 7, 즉 “같은 테스트 도구로 최소 열 번 이상 생성”이라는 건, 바로 이런 종류의 도구가 존재한다는 가정 위에 있다.
규칙 7을 실제로 실천하려면, 반복 실행과 결과 비교가 구조적으로 가능한 도구가 있어야 한다.
그 도구가 이것이다.

이후 파트에서 나오는 정성적 실험과 정량적 실험은 모두 이 종류의 환경에서 수행된다.