ChatGPT의 답변은 채팅창 안에만 머물지 않습니다. PR (Pull Request) 설명에 붙여넣어지기도 하고, 디자인 문서(design doc)에 인용되기도 하며, 회의 중에 "듣자하니..."라는 말과 함께 반복되기도 합니다. 그 시점에서 그 오류는 당신의 이름이 붙은 당신의 오류가 됩니다. 답변을 반복하기 전에 팩트 체크(Fact-checking)를 하는 것은 편집증이 아닙니다. 이는 머지(merge)하기 전에 테스트를 실행하는 것과 같은 기본적인 위생 관리입니다.

좋은 소식은, 모든 것을 검증할 필요도 없고 오후 내내 조사를 할 필요도 없다는 것입니다. 당신에게 필요한 것은 분류 규칙(triage rule) 하나와 복사-붙여넣기 가능한 팩트 체크 프롬프트 하나뿐입니다. 이는 ChatGPT, Claude, 또는 Gemini에서도 동일하게 작동합니다. 아래에 두 가지 버전과 실제 테스트 실행 결과, 그리고 짧은 버전이 한계에 부딪히는 지점에 대한 솔직한 설명이 함께 있습니다.

왜 굳이 ChatGPT 답변을 팩트 체크해야 할까요?

모델이 그럴듯하게(plausible) 보이도록 최적화되어 있기 때문입니다. 그럴듯하다는 것이 진실(true)과 같지는 않습니다. 언어 모델(Language models)은 질문의 형태에 가장 잘 맞는 답변을 생성하며, 이는 대개 진실과 겹치기도 하지만 때로는 그렇지 않기도 합니다. 실패 모드(failure mode)는 명백한 헛소리가 아닙니다. 90%는 맞지만 결정적인 세부 사항 하나가 틀린, 자신감 넘치는 문장입니다. 아무리 유창한 문구라도 외부에서는 이 둘을 구분할 수 없습니다. 오직 확인(checking)만이 이를 구분할 수 있습니다.

어떤 주장들을 실제로 확인할 가치가 있을까요?

모든 주장을 확인할 필요는 없습니다. 모든 것을 확인하려다 검증 자체를 포기하게 되는 것이 사람들의 실수입니다. 제가 사용하는 분류 규칙은 다음과 같습니다:

만약 틀렸을 경우 당신의 결정이 바뀔 만한 주장들을 확인하세요. 나머지는 건너뛰세요.

실제로 이는 다음 세 가지 카테고리를 순서대로 확인한다는 것을 의미합니다:

1. 당신이 곧 실행에 옮길 주장 — "이 API는 X에서 속도 제한(rate-limited)이 걸립니다", "이 라이선스는 Y를 허용합니다".
2. 당신이 다른 사람에게 전달할 주장 — 문서, PR, 또는 당신이 정보의 출처가 될 대화로 들어가는 모든 것.
3. 지나치게 깔끔해 보이는 구체적인 정보 — 정확한 백분율, 명명된 연구, 정돈된 버전 히스토리.

그 외의 모든 것 — 배경 정보, 일반적인 맥락, 표현 방식 — 은 검증되지 않은 상태로 두어도 됩니다. 그 부분에서 틀리는 것은 당신에게 아무런 비용을 발생시키지 않기 때문입니다.

복사-붙여넣기용 ChatGPT 팩트 체크 프롬프트

분류(triage) 단계에서 중요한 주장이 전달되면, 이를 스트레스 테스트(stress-test) 하세요. 해당 주장을 생성한 채팅창이 아닌, 모델이 스스로를 방어할 이해관계가 없는 새로운 채팅창에 다음 내용을 복사하여 붙여넣으세요:

아래의 주장을 스트레스 테스트(stress-test) 하세요. 이 주장이 사실이라고 가정하지 마십시오.
1. 주장을 정확하게 재진술하십시오. 모호한 점이 있다면 기록하십시오.
2. 반증 가능성(Falsifiability): 어떤 증거가 이 주장이 틀렸음을 증명할 수 있습니까?
...

이 설계는 의도적으로 적대적(adversarial)입니다. 대부분의 "이게 사실인가요?"라는 프롬프트는 모델이 스스로의 의견에 동의하도록 유도하지만, 이 프롬프트는 모델이 해당 주장에
'반대하는' 논거를 구축하도록 강제합니다. 즉, 무엇이 이를 반증할 수 있는지, 무엇에 암묵적으로 의존하고 있는지, 다른 어떤 것이 이를 설명할 수 있는지를 따지게 합니다. 동의(Agreement)는 최종 판결에 나타나기 위해 반드시 이러한 공격에서 살아남아야 합니다.

실제 주장에서는 어떤 일이 벌어질까요?

코드 리뷰에서 사실처럼 언급되는 것을 아마 들어보셨을 법한 주장 하나를 입력해 보았습니다: "ORM을 사용하면 SQL 인젝션(SQL injection)을 방지할 수 있다." Claude Sonnet을 사용하여 단 한 번의 실행(one pass), 새로운 컨텍스트로 진행했습니다. 프롬프트 자체는 모델에 구애받지 않으며(model-agnostic), ChatGPT에 그대로 붙여넣어도 동일하게 작동합니다. 결과는 다음과 같았습니다:

• 모호성이 가장 먼저 드러남: "방지한다"는 의미가 면역(immunity)을 뜻하는지, 아니면 위험 감소(risk reduction)를 뜻하는지? "ORM을 사용한다"는 것이 모든 ORM에 포함된 로우 SQL(raw-SQL) 탈출구(escape hatches)까지 포함하는 개념인지?

• 구체적인 반증 가능성(Falsifiability): 인젝션이 가능한 ORM 코드베이스의 실제 사례 하나가 이 주장을 반증합니다. 그리고 결과는 그러한 사례가 발생하는 지점을 정확히 짚어냈습니다: 문자열 연결(string concatenation)을 사용하는 raw() / text() / execute() 탈출구, 그리고 ORM이 일반적으로 매개변수화(parameterize)하지 않는 식별자(identifiers, 예: 테이블 이름, 컬럼 이름, 정렬 방향) 위치에 사용된 신뢰할 수 없는 입력값. ORM은 일반적으로 값(values)을 매개변수화하지, 식별자를 매개변수화하지는 않습니다.

• 암묵적 조건들: 개발자가 로우 쿼리(raw-query) API를 절대 건드리지 않음; 신뢰할 수 없는 입력이 식별자 위치에 절대 도달하지 않음; ORM 자체의 매개변수화 기능에 버그가 없음.

• 혼란 변수(The confounder) — 제가 가장 좋아하는 부분: 실제로 인젝션을 방지하는 것은 바로 '매개변수화된 쿼리(parameterized queries)'입니다. ORM은 단지 당신을 그 경로로 기본 설정(default)해 줄 뿐입니다. ORM의 공으로 돌리는 것은 도구(tool)와 메커니즘(mechanism)을 혼동하는 것입니다.

• 판결: 의심스러움 (DOUBTFUL) — 위험이 감소했을 뿐, 제거된 것은 아님 — 제가 실제로 사용하는 가장 빠른 확인 방법: 코드베이스에서 ORM의 raw/execute 탈출구(escape hatches)를 grep으로 검색하고 문자열 연결(string concatenation)이 있는지 확인합니다.

이는 대부분의 사람이 수행하는 것보다 해당 주장에 대해 더 나은 보안 검토(security review)이며, 1분도 채 걸리지 않았습니다. 무엇이 이를 가능하게 했는지 주목하세요: 해당 주장은 하중을 지탱하는(load-bearing) 성격(사람들이 이 때문에 입력값 정제(input sanitization)를 건너뛰기 때문)을 가지고 있었고, 프롬프트는 동의하는 대신 공격했습니다.

단일 주장 프롬프트의 한계는 어디인가?

매일 사용해 본 결과, 짧은 버전에는 네 가지 한계(walls)가 있습니다:

• 한 번에 하나의 주장만 처리하며, 추출은 사용자의 몫입니다. ChatGPT의 전체 답변은 산문 속에 뒤엉킨 수십 개의 주장을 포함하고 있습니다. 이를 뽑아내고 하중을 지탱하는 핵심 주장을 골라내는 것은 여러분의 역할입니다. (그 추출 단계는 별도의 도구입니다 — 이 시리즈의 첫 번째 파트에서 소개한 환각 체크 도구를 참조하세요.)
• 단계별 신뢰도가 없습니다. SUPPORTED(지지됨) / UNCLEAR(불분명함) / DOUBTFUL(의심스러움)은 세 가지 범주일 뿐입니다. 제품을 출시할지 결정할 때는 "정확히 얼마나 의심스러운가?"가 중요합니다.
• 증거 구조가 없습니다. 짧은 프롬프트는 어떤 증거가 주장을 해결할 수 있는지는 명시하지만, 무엇이 지지하고 무엇이 반박하는지를 조직화하지는 않습니다. 즉, 여러분이 직접 책상 위에서 이를 다시 구성해야 합니다.
• 일관성이 흔들립니다. 자유 형식(Freeform)의 출력은 실행할 때마다, 그리고 모델마다 감사(audit)의 깊이가 달라짐을 의미합니다.

저는 주장을 충분히 자주 스트레스 테스트하기 때문에, 전체 버전을 유료 프롬프트로 유지하고 있습니다: Fact Checker: Claim Stress Test on PromptBase. 동일한 적대적(adversarial) 핵심을 유지하면서, 1~5단계의 신뢰도 등급, 구조화된 찬성 증거/반대 증거, 그리고 매 실행 시 동일한 감사 깊이를 제공합니다. 이는 동의하기 위해서가 아니라 반박하기 위해 만들어졌습니다.

환각 체크(Hallucination check)인가, 팩트 체크(fact-check)인가 — 당신에게 필요한 것은 무엇인가?

이 둘은 서로 다른 단계이며, 상호 보완적입니다:

• Hallucination check (환각 체크) (이 시리즈의 첫 번째 파트): _AI 답변 전체_를 훑으며 모든 주장(claim)을 추출하고, 조작 패턴을 표시합니다. 넓고 얕게 수행하며 — 용의자를 찾아냅니다.
• Claim stress test (주장 스트레스 테스트) (본 문서): _중요한 단 하나의 주장_을 가져와 심층적으로 압박 테스트를 수행합니다. 좁고 깊게 수행하며 — 용의자를 심문합니다.

답변 전체가 검증되지 않았다면 먼저 훑기(sweep)를 수행하고, 당신이 실행에 옮기려는 생존한 주장들에 대해 스트레스 테스트를 수행하세요. 회의 중 나온 통계나 리뷰 중 언급된 "모범 사례(best practice)"와 같이 누군가부터 단독으로 전달한 주장에 대해서는, 훑기 과정을 건너뛰고 즉시 스트레스 테스트로 넘어가세요.

빠른 AI 팩트 체크 루틴

판결이 무엇이든, 모델의 답변은 지도일 뿐 실제 영토가 아닙니다. 마무리 루틴은 다음과 같습니다:

1. 의심스러운 (DOUBTFUL) 판결: 감사(audit)에서 명시한 "가장 빠른 확인 방법"을 실행하세요. 대개 grep 검색, 변경 로그(changelog), 또는 공식 문서 페이지 하나를 확인하는 것입니다.
2. 중요한 주장에 대한 지지된 (SUPPORTED) 판결: 모델이 나열한 가장 강력한 조건 하나를 여전히 점검(spot-check)하세요. 모델의 지지는 하나의 논거(argument)일 뿐, 출처(source)가 아닙니다.
3. 이름이 명시된 연구나 정확한 숫자가 포함된 경우: 정확한 출처를 검색하세요. 빠르게 찾을 수 없다면, 조작된 것으로 간주하고 삭제하세요.
4. 당신의 검증이 뒷받침하는 것보다 더 자신 있게 주장을 반복하지 마세요. "문서에 따르면 X라고 한다"와 "모델이 X라고 추론했다"는 서로 다른 문장입니다 — 이 둘을 명확히 구분하여 유지하세요.

AI의 도움을 받아 작성되었습니다; 위의 테스트 실행은 설명된 대로 수행되었으며(1회 통과, Claude Sonnet, 새로운 컨텍스트), 요약되어 충실히 보고되었습니다. 이를 재현해 보세요: ORM 주장을 체커에 붙여넣고 비교해 보십시오.

전체 버전: Fact Checker: Claim Stress Test. 이 시리즈의 이전 글: How to Catch AI Hallucinations.