당신이 사용하는 모든 AI 답변은 설정(config), 마이그레이션(migration), 또는 팀원들이 신뢰할 문서 등 어딘가에 반영됩니다. 검증 없이 배포한다는 것은 그 오류 또한 당신의 이름 아래 함께 배포된다는 것을 의미합니다. 이 글은 제가 AI 결과물을 배포하기 전에 검증하기 위해 사용하는 작업 루틴을 소개합니다. AI 정확도를 확인하기 위해 각각 하나의 작업을 수행하며, 오후 내내 걸리는 것이 아니라 단 몇 분 만에 검증을 완료할 수 있도록 구성된 세 가지 복사-붙여넣기용 프롬프트입니다.

처음 두 가지 — 환각 탐색(hallucination sweep)과 AI 사실 확인(fact-checking) 프롬프트 — 는 이 시리즈의 이전 글(아래 링크 참조, 각기 별도의 테스트 실행 결과 포함)에서 가져왔습니다. 세 번째 — 위험도에 맞춘 검증 체크리스트(verification checklist) 구축 — 는 이번에 새로 추가되었으며, 아래에 제시된 함정이 설치된 예시를 통해 테스트되었습니다.

AI 결과물을 검증하려면 실제로 무엇이 필요한가요?

순서대로 세 가지 단계가 있으며, 각 단계는 서로 다른 질문에 답합니다.

1. 탐색 (Sweep) — 어떤 주장들이 포함되어 있으며, 어떤 것들이 조작된 것처럼 보이는가? 답변 전체에 걸쳐 넓고 얕게 수행합니다.
2. 스트레스 테스트 (Stress-test) — 이 핵심적인 주장이 실제로 사실인가? 당신의 결정에 영향을 미칠 주장들에 대해 좁고 깊게 수행합니다.
3. 체크리스트 (Checklist) — 위험도를 고려할 때 이 텍스트가 받아야 할 완전한 검증 세트는 무엇인가? "몇 가지를 확인했다"를 "올바른 것들을 확인했다"로 바꾸는 단계입니다.

대부분의 사람들은 본능적인 1단계 수준에서 멈춥니다. 실제 운영 환경(production)까지 도달하는 실패 사례들은 대개 2단계와 3단계에서 발생합니다.

프롬프트 1: 답변의 환각(hallucinations)을 탐색하기

요약 버전:

아래 텍스트의 환각(hallucinations) 여부를 감사(Audit)하세요.
모든 사실적 주장을 번호가 매겨진 줄로 나열하고, 각 주장에 대해
VERIFIABLE(검증 가능), SUSPECT(의심스러움), 또는 FABRICATION-PATTERN(조작 패턴 - 이름 명시)...

1부의 테스트 실행에서, 이 패턴은 조작된 Stanford 연구를 포함하여 샘플 답변에 심어진 세 가지 오류를 모두 잡아냈습니다. 트레이드오프(trade-off)로는, 이 방식은 판결이 아닌 라벨을 반환하며, 텍스트 길이가 길어질수록 플래그(flag)의 수가 빠르게 증가한다는 점이 있습니다.

프롬프트 2: 당신이 실행하려는 주장을 스트레스 테스트하기

단축 버전:

이 주장을 스트레스 테스트(Stress-test) 하세요. 이것이 사실이라고 가정하지 마십시오.
이 주장이 틀렸음을 증명할 수 있는 증거, 이 주장이 암묵적으로 의존하고 있는 2~3가지 조건, 그리고 가장 가능성 높은 교란 요인(confounder)을 명시하십시오.
...

이 설계는 의도적으로 적대적(adversarial)입니다. 즉, 동의를 구하는 대신 해당 주장에
'반대하는' 논거를 구축합니다. 2부의 테스트 실행에서, 이 팩트 체크(fact-checking) 프롬프트는 "ORM을 사용하면 SQL 인젝션(SQL injection)을 방지할 수 있다"라는 코드 리뷰의 통념을, 이를 깨뜨리는 정확한 탈출구(escape hatches)와 함께 '의심스러움(DOUBTFUL)'이라는 판정으로 바꾸어 놓았습니다.

프롬프트 3: 리스크 수준에 맞춘 검증 체크리스트 구축하기

새로운 프롬프트 전문입니다. 이 단계는 텍스트를
'얼마나 많이' 검증해야 하는지를 결정합니다:

아래의 AI 생성 텍스트에 대한 검증 체크리스트를 구축하십시오.
1. 리스크(stakes) 수준을 명시하십시오: 낮음(LOW) / 중간(MEDIUM) / 높음(HIGH), 그리고 그 이유를 한 줄로 작성하십시오.
2. 리스크가 낮을 경우 3가지 체크 항목을, 중간 또는 높을 경우 6~8가지 항목을 나열하십시오 — 각 항목은
...

핵심은 피해 규모에 따른 순서(Damage-ordering)를 정하는 것입니다. 가장 위험한 주장부터 시작하는 체크리스트를 사용하면, 설령 첫 번째 체크만 수행하더라도 올바른 조치를 취한 것이 됩니다.

체크리스트 프롬프트가 실제로 중요한 문제를 잡아낼 수 있을까?

저는 그럴듯한 AI 스타일의 업그레이드 권장 사항이 담긴 네 문장을 입력했습니다. "pg_upgrade를 사용하여 PostgreSQL 12에서 16으로 인플레이스(in-place) 업그레이드를 수행하십시오. 다운타임은 1분 미만이며, pg_dumpall로 백업하고, 이후 ANALYZE를 실행하십시오. 확장 기능(extensions)은 자동으로 업그레이드되므로 수동 단계가 필요하지 않습니다" — 여기서 마지막 주장은 유창하고 안심을 주지만 틀린 내용으로 심어놓은 함정입니다. Claude Sonnet 모델에 새로운 컨텍스트로 한 번 실행했습니다. 결과는 다음과 같습니다:

• 위험도(Stakes): 높음(HIGH), 적절한 이유와 함께 — 이 내용을 프로덕션 데이터베이스에 적용할 경우 백업 기간이 끝난 후 조용한 데이터 접근 실패를 초래할 위험이 있습니다.
• 심어 놓은 함정은 체크 #1로 평가됨 — '전반적인 주장(blanket claim)'으로 간주되어 허위로 판명되었으며, 가장 빠르게 확인할 수 있는 방법은 (SELECT * FROM pg_extension; 후 확장별 호환성 참고 사항을 확인하는 것)이었습니다.
• 무효화되는 주장의 이름과 동일함 — 실행의 마지막 문장입니다: 이 내용에 의존하면 업그레이드가 성공했다고 믿게 될 수 있지만, 롤백(rollback) 기능이 사라진 후에 깨진 기능을 발견할 수도 있습니다.
• 제가 심지 않았던 커버리지: '1분 미만의 다운타임'이 --link 모드에 조용히 의존한다는 점, 테스트 복원되지 않은 백업은 진정한 백업이 아니라는 점, 12→16 다중 버전 점프 자체를 검증해야 한다는 점, 그리고 텍스트에 아예 롤백 계획이 없다는 점을 지적했습니다 — 총 여덟 가지 체크 사항이며, 피해 순서대로 나열되었습니다.

마지막 항목은 이 체크리스트 단계의 진정한 논거입니다: 단순히 존재하는 문장들만 감사하는 것이 아니라, 해당 텍스트가 언급했어야 했지만 언급하지 않은 체크 사항들을 수면 위로 끌어올립니다.

무료 체크리스트 프롬프트는 어디까지인가?

같은 실행에서 보이는 세 가지 한계점입니다:

• 사실 기반 커버리지(Facts-first coverage). 체크 항목들은 텍스트에 존재하는 주장들을 중심으로 회전합니다. 논리적 오류, 엣지 케이스(edge cases), 그리고 규정 준수 노출 위험은 해당 텍스트가 우연히 암시할 때만 표면화됩니다 — 아무도 '이것 때문에 우리를 고소할 수 있는 사람이 누구인가?'라고 묻지 않았습니다.
• 직감에 따른 위험도(Stakes by gut feel). 한 줄로 LOW/MEDIUM/HIGH를 표시하는 것은 느낌적인 체크일 뿐입니다. 이번에는 맞았지만, 미묘한 입력값에 대해서는 같은 판단을 보장할 수 없습니다.
• 구조적 변동성(Structure drifts). 체크 항목의 개수, 깊이, 그리고 표현 방식은 실행마다 달라집니다 — 일회성 사용에는 괜찮지만, 매일 의존하는 루틴으로는 취약합니다.

루틴(Routine) 버전을 위해 저는 전체 프롬프트를 유료 제품으로 유지하고 있습니다: PromptBase의 AI Verification Checklist Builder. 이 프롬프트는 체크리스트의 규모를 한 줄짜리 추측이 아닌 중요도 루브릭 (Stakes rubric)에 따라 결정하며, 검증 범위를 단순한 사실 확인을 넘어 논리 (Logic), 엣지 케이스 (Edge cases), 그리고 법적 검토 (Legal review)까지 확장합니다. 또한 모든 실행을 동일한 방식으로 마무리합니다 — 즉, 만약 틀렸을 경우 나머지 모든 것을 무효화할 수 있는 핵심적인 주장 (Load-bearing claims)을 확인하며 끝납니다.

세 가지 프롬프트는 어떻게 서로 맞물리나요?

구성 규칙은 간단합니다:

그리고 세 가지 프롬프트 모두에 적용되는 최우선 규칙은 다음과 같습니다: 모델의 감사 (Audit)는 지도일 뿐, 실제 영토가 아닙니다. 모든 판결과 모든 체크리스트 항목은 여전히 사람이 직접 확인하는 과정 — grep 검색, 문서 페이지 확인, 테스트 복구 (Test restore) 등 — 을 거쳐야 합니다. 프롬프트는 검증을 대체하는 것이 아니라, 여러분이 검증에 소비하는 시간이 실제로 피해를 줄 수 있는 핵심 주장들에 집중될 수 있도록 보장합니다.

AI의 도움을 받아 작성되었습니다. 이 기사에서 수행된 체크리스트 테스트 실행은 설명된 대로 — 1회 실행, Claude Sonnet, 새로운 컨텍스트(Fresh context) — 수행되었으며 충실하게 보고되었습니다. 이전 프롬프트들의 테스트 실행 결과는 각각의 개별 기사에 기록되어 있습니다. 이 테스트를 재현하려면: 입력값은 위에 인용되어 있습니다.

전체 체크리스트 버전은 위 섹션에 링크되어 있습니다. 만약 병목 현상이 결과물이 아닌 프롬프트 자체에 있다면, 저는 Optimizer: Diagnose & Rewrite도 운영하고 있습니다. 이 시리즈의 이전 글: AI 환각(Hallucinations) 잡아내기 및 ChatGPT 팩트 체크하기.