AI 답변, 어떻게 거르고 쓰시나요? - 제가 매일 쓰는 크로스체크 루틴
AI를 매일 씁니다. Claude Opus, Codex, Gemini 세 개를 동시에 굴립니다. 그러다 보면 자연스럽게 알게 되는 게 하나 있는데, 할루시네이션은 피할 수 없다는 점입니다. 더 좋은 모델을 쓴다고 해서 사라지지 않습니다. 다만 패턴이 있고, 거를 수 있습니다.
이 글은 “AI 맹신하지 마세요”라는 당위 말고, 제가 실제로 어떻게 거르고 쓰는지를 정리해 둔 글입니다.
할루시네이션이 잘 나오는 질문 패턴
먼저 어떤 질문에서 잘 나오는지부터 정리해 두면 좋습니다. 제 경험상 다음 영역이 위험합니다.
| 영역 | 왜 위험한가 |
|---|---|
| 신생 프로젝트의 경제 지표 | 토크노믹스 미공개, 실제 보상 단가 추정 불가능한 상태에서 "월 X만원" 같은 숫자가 나옴 |
| 마이너 라이브러리·SDK 사용법 | 학습 데이터에 적게 들어간 영역이라 시그니처를 그럴듯하게 지어냄 |
| 최신 API 스펙 | 모델 커트오프 이후 변경된 부분을 옛 정보로 답함 |
| 특정 인물의 최근 활동 | 이름이 같은 다른 인물과 섞임 |
| 하드웨어 호환성 | "지원될 것 같다"와 "지원된다"를 구분 안 함 |
공통점이 보이실 겁니다. 검증 가능한 1차 출처가 학습 데이터에 적게 들어간 영역입니다. 모델은 “모르겠다”보다 “있을 법한 답”을 만드는 쪽으로 학습돼 있어서, 출처가 빈약한 영역일수록 그럴듯하게 지어냅니다.
짧은 사례 하나
며칠 전 커뮤니티에서 본 시나리오입니다.
- 어떤 분산 AI 학습 네트워크에 자기 컴퓨터 자원을 제공하면 가상화폐 보상이 나온다.
- 고메모리 미니 PC 한 대 사서 채굴 전용으로 돌리면 한 달에 수십~200만원 정도 벌 수 있다.
- 3개월이면 본전 회수, 그 뒤로는 LLM 구독료가 공짜로 나오는 셈.
수치 출처가 “AI에게 물어봤다”였습니다. 검증해 보니 공식 문서 기준으로 보상은 SOL 고정 지급이 아니라 coordinator point와 Treasurer smart contract를 통한 임의 토큰 보상 구조에 가까웠고, 실제 보상 단가나 월 수익을 계산할 공개 근거는 찾기 어려웠습니다. 게다가 Psyche 공식 FAQ에는 “once rewards are implemented”라는 표현이 그대로 적혀 있어서, 보상 시스템 자체가 아직 라이브가 아닌 상태였습니다. 하드웨어 쪽도 비슷합니다. 공식 FAQ는 Linux + CUDA-compatible GPU를 production 요건으로 명시하고, macOS는 development purpose only라고 설명합니다. 즉 “고메모리 미니 PC나 맥미니를 사서 월 N 토큰을 번다”는 계산은 핵심 전제가 맞지 않았습니다.
여기서 중요한 건 “AI가 틀렸다”가 아니라, AI가 틀릴 수밖에 없는 입력 조건이었다는 점입니다. 보상 토큰, 하드웨어 호환성, 실제 수익률처럼 아직 공식 문서와 지급 이력이 부족한 영역에서는 모델이 과거의 채굴·에어드랍·디핀 사례를 섞어 그럴듯한 숫자를 만들기 쉽습니다. 그래서 이런 주제는 답변의 유창함보다 출처와 메커니즘을 먼저 봐야 합니다.
악의는 전혀 없는 글이었고 본인도 “실제로 굴러갈지는 모르겠다”고 단서를 다셨습니다. 다만 이 케이스가 흥미로운 건, AI가 만든 환각 위에 정량 분석을 쌓아 깔끔한 결론을 내면, 본인도 모르게 모래성이 만들어진다는 점을 보여줘서입니다. AI를 잘 쓰시는 분이라도 이 패턴은 빠지기 쉽습니다.
제가 쓰는 크로스체크 루틴
저는 몇 가지 습관으로 이걸 거릅니다. 정답이라기보다는 1년 가까이 멀티 에이전트를 굴려보면서 만들어진 제 방식입니다.
1. 한 모델의 답을 다른 모델에게 검토시키기
이게 가장 효과 좋습니다. 같은 모델한테 “네 답 다시 검토해 봐”라고 하면 자기 답을 거의 그대로 옹호합니다. 자기검증은 잘 못 해요. 그런데 다른 모델한테 보여주면 다른 관점에서 빈틈을 찾아냅니다.
저는 보통 이렇게 굴립니다.
| 역할 | 모델 | 페르소나 |
|---|---|---|
| 비판자 | Claude (Opus) | 냉정한 검증, 논리 빈틈 지적 |
| 탐색자 | Gemini | 브레인스토밍, 가능성 확장 |
| 구현 검증자 | Codex | 코드 기반 실현 가능성 분석 |
실제로 이렇게 굴려보면 패턴이 보입니다. Gemini는 그럴싸한 말은 잘 만드는데 코드를 안 읽고 답하는 경우가 자주 있고, Codex는 코드베이스를 실제로 읽게 했을 때 라인 번호나 파일 경로를 근거로 반박해 오는 경우가 많았습니다. Claude는 약간 자기 자신을 “리뷰어”로 슬쩍 띄우는 자화자찬 경향이 있어서 그것도 감안해야 합니다. 한 모델만 쓰면 그 모델의 약점이 그대로 결과물에 남는데, 셋을 굴리면 서로 메꿔줍니다.
이게 “단일 모델에 의존하면 그 모델의 약점이 내 결과물에 그대로 들어온다”는 문제를 푸는 방식입니다.
2. Gemini 답변은 한 단계 더 의심
이건 제 사용 범위 안에서의 경험인데, 셋 중에서는 Gemini가 가장 그럴듯하게 말하면서도 세부 검증에서 틀리는 경우가 많았습니다. 한 번은 pytest 결과를 뽑아달라고 했는데 10분 동안 시도하다가 결국 “run_shell_command 도구가 없어서 못 한다”고 답한 적이 있습니다. 다른 에이전트로는 1분이면 되는 작업이었습니다.
그래서 저는 Gemini한테는 “실행”을 잘 안 시키고 “아이디어 확장”만 시킵니다. 답변에 구체적인 숫자가 들어 있으면 거의 무조건 다른 출처로 한 번 더 확인합니다. 위에서 언급한 사례의 “월 9~15 SOL” 같은 수치도 Gemini 답변이었는데, 모델 특성을 알면 “일단 의심부터”가 자동으로 됩니다.
각 모델은 강점과 약점이 다 다릅니다. 본인이 쓰는 모델의 “자주 틀리는 패턴”을 한 번 정리해 두면 거르는 속도가 빨라집니다.
3. 1차 출처로 내려가기
답을 받으면 곧바로 1차 출처를 확인하는 습관을 들이려고 합니다. 모델이 “공식 문서에 따르면”이라고 답했으면 그 공식 문서 URL까지 내려갑니다. “GitHub Issue에서 논의됐다”고 하면 그 이슈 번호까지 찾아갑니다.
신생 프로젝트일수록 이게 중요합니다. 프로젝트 공식 사이트, 공식 문서, GitHub README, FAQ - 이 네 가지에 답이 없으면 “모델이 지어낸 답일 가능성이 높다”고 보는 게 안전합니다.
특히 위험한 표현이 있습니다.
- “일반적으로 알려져 있다”
- “업계에서는 이렇게 본다”
- “보통 이 정도 수준이다”
출처가 없는 일반화 표현입니다. 이런 답이 나오면 “출처가 어디인지 구체적으로 알려줘”라고 되묻습니다. 그러면 모델이 출처를 만들어내거나, “정확한 출처는 없습니다”라고 인정하거나 둘 중 하나입니다. 후자면 그 정보는 일단 보류합니다.
4. 모델에게 “네가 모르는 영역인지” 직접 묻기
이게 의외로 잘 됩니다. 답을 받은 다음에 이렇게 묻습니다.
이 답변에서 네가 학습 데이터로 확실히 알고 있는 부분과, 추정한 부분, 그리고 모르는 부분을 구분해서 알려줘.
좋은 모델일수록 이 요청에 솔직하게 답합니다. “이 부분은 학습 시점 이후 변경됐을 가능성이 있어 확실하지 않습니다” 같은 답이 나오면 그 부분은 따로 검증합니다. 답변 전체를 한 번 더 거르는 효과가 있습니다.
5. 시나리오에 “돈”이 끼어 있으면 의심을 두 단계 올리기
특히 “이걸 이렇게 하면 돈이 된다” 류의 답변은 의심 강도를 두 단계 올립니다. 디핀 채굴, AI 부업, GEO 마케팅, 자동화 수익화 - 이런 영역은 정보 불확실성이 크고 시장 변화가 빨라서 모델이 가장 자주 틀리는 영역이기도 합니다.
이런 답을 받으면 저는 두 가지를 추가로 합니다.
- 비슷한 구조의 다른 사례에서 실제 어떻게 됐는지 찾기 (디핀이면 Render·Akash·Lilypad 차트, GEO면 실제 머천트 매출 귀속 측정 사례 등)
- 보상이나 수익이 발생하는 메커니즘을 한 단계씩 분해해 보기
후자가 특히 중요합니다. “보상은 어디서 오나 → 누가 누구한테 무엇을 위해 지불하나 → 그 돈은 어떻게 결정되나” 식으로 분해하면, 모델이 만들어낸 “있을 법한 시나리오”가 실제 메커니즘과 안 맞는 부분이 빠르게 드러납니다.
정리하면
| 점검 | 질문 |
|---|---|
| 출처 | 1차 출처 URL까지 추적 가능한가 |
| 시점 | 모델 커트오프 이후 변경됐을 영역인가 |
| 모델 특성 | 이 모델이 자주 틀리는 패턴에 해당하는가 |
| 자기검증 | 다른 모델에게 검토시켰는가 |
| 메커니즘 | 답변의 메커니즘을 한 단계씩 분해하면 무너지지 않는가 |
| 돈 | 수익이나 보상이 끼어 있는가 (있으면 의심 두 단계 ↑) |
이 항목들 중 두 개 이상 걸리면 답변을 일단 보류합니다. 이게 별것 아닌 것 같지만, 매일 AI를 쓰는 사람한테는 시간을 꽤 아껴줍니다.
마지막으로
AI를 쓴다는 건 답을 그대로 받아쓰는 일이 아니라, 답을 검증할 줄 아는 능력을 같이 키우는 일이라고 봅니다. 어떤 모델이 좋은지, 어떤 영역에서 잘 틀리는지, 어떻게 크로스체크할 수 있는지 - 이게 AI를 도구로 쓰는 기본기입니다.
그래서 저는 “AI를 맹신하지 마세요”라는 말보다, “AI 답변을 거르는 본인만의 루틴을 하나 만들어 두세요”라는 말이 더 실용적이라고 생각합니다. 위에 적은 건 제 루틴이고, 다들 본인 작업에 맞는 루틴을 만들어 가시면 좋겠습니다.
지난 글 결론에서 적었던 말이 여기에도 그대로 적용됩니다.
AI 시대에 일반인이 돈을 버는 가장 확실한 방법은 “AI가 자동으로 돈을 벌어주는 구조”가 아니라, AI를 도구로 삼아 기존의 문제를 더 잘 해결하는 것입니다.
도구로 삼는다는 말의 절반은 “답을 받는 능력”이고, 나머지 절반은 “답을 거르는 능력”입니다. 둘 다 갖춰야 합니다.