Verification Loop Prompt: 당신의 어시스턴트가 당신보다 먼저 자신의 작업을 테스트하도록 하세요

Source: Dev.to

만약 코딩이나 글쓰기를 위해 어시스턴트를 사용한다면, 아마도 다음과 같은 패턴을 보았을 것입니다:

1. 구체적인 요청을 합니다.
2. 겉보기에 맞는 결과를 받습니다.
3. 다음 20분 동안 숨겨진 함정을 발견하는 데 시간을 보냅니다.

해결책은 “더 좋은 모델을 사용한다”거나 “좀 더 구체적으로 요청한다”(두 방법 모두 도움이 됨)가 아닙니다. 해결책은 요청의 형태를 바꾸는 것입니다.

제가 이것을 Verification Loop Prompt라고 부릅니다: 어시스턴트가 여러분에게 전달하기 전에 자신의 출력물을 테스트하고 검증하도록 강제하는 두 단계 프롬프트입니다.

이것은 완벽함을 추구하는 것이 아니라, 실패 모드의 상위 80 %를 — 빠르고 저렴하게, 그리고 반복적으로 — 잡아내는 것입니다.

아이디어

대부분의 프롬프트는 답변을 요구합니다.

검증 루프는 답변 + 증거를 요구합니다.

당신은 단순히 “X를 수행해라”라고 요청하는 것이 아니라, 다음을 요청하는 것입니다:

마지막 단계가 중요합니다: 좋은 검증 루프는 확실성을 가장하지 않고, 그것을 드러냅니다.

기본 프롬프트 (복사/붙여넣기)

이를 기본값으로 사용하고, 작업에 따라 검증 섹션을 조정하십시오.

You are helping me with: 

Constraints:
- 
- 
- 

Deliverable:
- 

Verification loop (do this *after* you draft the deliverable):
1. List assumptions you made (bullet list).
2. Check the deliverable against each constraint (pass/fail + fix if fail).
3. Provide 5 edge cases / failure modes relevant to this task.
4. Propose a minimal test plan (steps I can actually run).
5. If anything is uncertain, flag it explicitly and ask up to 3 clarifying questions.

Only then output the final deliverable.

다른 작업을 하지 않을 경우, 경계 사례와 최소 테스트 계획을 요청하십시오.

Example 1: AI‑assisted coding (a tiny refactor with guardrails)

사용자가 입력을 파싱하는 함수를 리팩터링한다고 가정해 보세요.

Without verification

동작을 은밀히 바꾸는 깔끔해 보이는 리팩터링을 자주 보게 됩니다.

With verification

보조 도구에게 행동 계약을 이해했음을 증명하도록 강제합니다.

Prompt

You are helping me with: refactoring a TypeScript function that parses a date input.

Constraints:
- Must preserve current behavior for valid ISO strings (YYYY‑MM‑DD).
- Must reject ambiguous formats (e.g., 03/04/05) instead of guessing.
- Must keep the same public function signature.
- Must include unit tests for at least 6 cases.

Deliverable:
- Updated function + Jest test cases.

Verification loop:
1. List assumptions about existing behavior.
2. Compare old vs. new behavior for the 6 test cases (table).
3. Identify 5 tricky inputs that could break parsing.
4. Provide a minimal test plan: commands to run + expected output.

받게 되는 결과는 크게 달라집니다: 단순히 코드가 아니라 미니 사양이 제공됩니다.
핵심은 단계 2입니다. 기존‑신규 동작을 명시적으로 비교하도록 강제함으로써, 보조 도구가 “꾸미기”를 멈추고 “보존”에 집중하게 됩니다.

실용적인 변형: “컴파일 + 실행” 검사

도우미가 도구에 접근할 수 없더라도 유용한 시뮬레이션을 수행할 수 있습니다:

• “이것은 … 때문에 타입 검사를 통과해야 합니다”
• “이 테스트는 X를 주장하며, 이는 제약 Y에 해당합니다”

실제로 테스트를 실행하는 것과는 다르지만, (누락된 import, 잘못된 API 사용, 타입 불일치 등) 놀라울 정도로 많은 실수를 잡아냅니다.

예시 2: 데이터베이스 변경 (실수가 큰 피해를 주는 경우)

스키마 변경은 검증 루프에 이상적인 장소입니다. 실패 유형이 잘 알려져 있기 때문입니다:

• 데이터 손실
• 장시간 잠금
• 롤백 누락
• 성능 퇴보

Prompt

You are helping me with: writing a PostgreSQL migration to split a full_name column into first_name and last_name.

Constraints:
- No data loss.
- Must be reversible (down migration required).
- Must be safe for large tables (avoid long table locks).
- Must include a backfill strategy.

Deliverable:
- up.sql + down.sql + short rollout notes.

Verification loop:
1. List assumptions about existing data (nulls, formatting, edge cases).
2. Identify the riskiest operation in the migration.
3. Provide a rollback plan and what data cannot be perfectly recovered.
4. Give a minimal test plan using a temp table with sample rows.

이는 어시스턴트가 현실에 직면하도록 강제합니다: 모든 변환이 완벽히 되돌릴 수 있는 것은 아닙니다.
손실이 발생하는 부분을 명시하지 못한다면, 충분히 고민하지 않은 것일 가능성이 높습니다.

검증을 위한 “변경 예산”(스파이럴 방지)

일반적인 실패 유형은 과도한 고민이다: 어시스턴트가 결과물을 만든 뒤 40가지 비판을 작성하고 다시 모두 다시 쓴다.

작은 예산으로 해결하라:

• 5가지 경계 사례로 제한한다.
• 한 번의 수정 패스로 제한한다.
• 3가지의 명확화 질문으로 제한한다.

프롬프트에 다음 줄을 추가한다:

Verification budget: one pass only. If you find issues, fix them once and move on.

검증은 안전벨트 역할을 해야지, 우회로가 되어서는 안 된다.

일상 작업을 위한 가벼운 버전

작은 요청(이메일, 문서, 요약)에는 이 빠른 루프를 사용하세요:

Before you finalize:
- What did you assume?
- What’s the most likely mistake here?
- What would you check if you had 2 minutes?

짧지만, 다음을 확실히 잡아냅니다:

• 누락된 컨텍스트
• 어울리지 않는 톤
• 빠진 요구사항

왜 작동하는가 (기계적으로)

어시스턴트는 그럴듯한 완성을 만들어내는 데 뛰어납니다. 검증 루프는 목표를 바꿉니다:

그 두 번째 단계는 비교, 제약 조건 확인, 그리고 반례 생성이라는 다른 모드를 작동시킵니다.

인간적인 말로 하면: 당신은 어시스턴트에게 팀원처럼 자신의 작업을 검토하도록 만드는 것입니다.

# A small checklist to keep

When you’re not sure how to structure the verification loop, pick **3** from this menu:

- **Assumptions** – what did you infer?
- **Constraint check** – pass/fail
- **Edge cases** – counterexamples
- **Test plan** – minimal, runnable
- **Rollback plan** – for risky changes
- **Confidence + uncertainty** – what might be wrong?

If you build the habit, you’ll notice something subtle: you spend less time “prompting harder” and more time shipping.

That’s the whole point.