클로드와 하루종일 일합니다. 회의록, 이메일 초안, CRM 데이터 정리, 기술 리서치 등 거의 모든 업무에 AI가 들어와 있습니다. 그러다 보니 자연스럽게 한 가지 질문에 계속 부딪힙니다.
AI가 틀렸을 때, 내가 그 분야를 모르면 틀린 줄도 모르는 거 아닌가?
내가 아는 분야에서 AI가 틀리면 바로 잡습니다. 세일즈 팔로업 이메일의 톤이 이상하면 한 눈에 보이고, CRM 데이터 구조가 잘못 정리되면 즉시 감지합니다. 문제는 내가 모르는 분야입니다. OAuth 인증 방식의 차이, 클라우드 아키텍처 선택, API 제약 사항 — 이런 영역에서 AI가 자신 있게 설명하면, 그게 맞는 건지 틀린 건지 판단할 근거가 없습니다.
B2B 세일즈에 비유하면, 경험 많은 세일즈 매니저는 AE가 "미팅 잘 됐습니다"라고 보고할 때 그 말의 결을 읽습니다. 고객이 진짜 긍정적이었는지, 예의상 그랬는지. 그런데 그 산업을 처음 보는 매니저라면 AE의 보고를 그대로 믿을 수밖에 없습니다. AI와의 관계가 정확히 이겁니다.
수백 번의 AI 협업을 돌아보면서 한 가지를 깨달았습니다. AI 오류를 잡는 스킬은 두 종류였습니다.
하나는 내용 검증 — 그 분야를 알기 때문에 틀린 걸 바로 알아채는 것.
다른 하나는 구조 검증 — AI가 어떤 과정으로 그 답에 도달했는지, 논리적으로 일관되는지, 이전에 합의한 것과 모순되는지를 보는 것.
내용 검증은 도메인 지식이 필요하지만, 구조 검증은 분야를 몰라도 작동합니다.
대부분의 사람은 내용 검증만 씁니다. 그래서 아는 분야에서는 AI를 잘 다루지만, 모르는 분야에서는 AI한테 끌려갑니다. 이 글에서 정리하는 11가지 패턴은 전부 구조 검증입니다. 실전에서 반복된 것들이고, 도메인 지식 없이 적용 가능합니다.
AI가 답을 내놓기 전에, 뭘 보고 답했는지부터 확인하는 패턴 세 가지입니다.
1. AI가 원본을 확인하지 않고 답할 때 잡는 법
AI에게 어떤 서비스에 대해 리서치를 시킨 적이 있습니다. AI가 분석을 잘 해줬고, 그 결과를 기반으로 MCP 서버 연결 구조를 정리해줬습니다. 그런데 정리 과정에서 5개 항목을 하나의 그룹으로 묶으면서, 그중 하나를 "제거하면 안 되는 것" 목록에 잘못 넣었습니다.
클로드: "이 5개는 현재 사용하지 않는 커넥터이므로 정리 대상입니다."
나: "잠깐, 아까 같이 본 공식 앱 목록에 이거 분명히 있었잖아. 직접 확인하고 말한 거야?"
방금 전에 같이 본 공식 앱 목록에 해당 항목이 분명히 있었거든요. AI의 현재 발언과 5분 전 사실이 충돌한다는 걸 알아차린 겁니다.
여기서 잡아낸 방식은 MCP 서버 연결 구조를 알아서가 아닙니다. "AI가 실제로 원본을 확인했는지"를 메타 수준에서 체크한 겁니다. AI가 뭔가를 단정적으로 말할 때, "그 근거를 네가 직접 봤느냐?"를 물어보면 됩니다. 이건 어떤 분야에서든 작동합니다.
같은 패턴이 이메일 작성에서도 나타납니다. AI가 기존 이메일 스레드에 답장 초안을 쓰면서, 이전 이메일에서 사용한 호칭과 다른 호칭을 넣은 적이 있습니다. 이전 스레드를 실제로 읽었으면 나올 수 없는 실수였습니다. "이메일 제대로 안 읽었구나" — 한 마디면 교정이 됩니다.
2. 발화자가 빠진 AI 요약이 딜 해석을 뒤집는다
AI에게 미팅 요약을 시키면, 내용은 정확한데 발화자 귀속(attribution)이 누락되는 경우가 많습니다. 고객사와의 미팅 요약에서 이런 한 줄이 나왔습니다.
AI 요약: "직접 세팅 가능성 언급. 외부 도움 없이 내부에서 진행할 수 있다는 의견."
고객이 말한 건지 내가 말한 건지가 빠져 있습니다. 발화자가 누구인지에 따라 딜의 해석이 완전히 달라집니다. 고객이 "직접 해볼게요"라고 했으면 이탈 신호이고, 내가 "직접 하셔도 됩니다"라고 열어준 거면 관계 관리의 일환입니다. 같은 문장인데 방향이 정반대예요.
이건 세일즈 감각이 있어서 잡은 것이기도 합니다. 하지만 세일즈를 몰라도 구조적으로 잡을 수 있습니다. AI 요약을 받을 때 "뭘 말했는지"뿐 아니라 "누가 말했는지"가 명시돼 있는지를 체크하면 됩니다. 발화자 귀속은 분야를 불문하고 요약의 기본 품질 기준입니다.
3. AI가 만들어낸 거짓 문맥을 한 줄로 걸러내는 법
이메일 팔로업 초안을 부탁했을 때, AI가 이런 도입부를 넣었습니다.
클로드: "봄이 되니 역삼 쪽으로 나올 일이 더 많아지고 있습니다. 지난번 미팅 때 나눈 이야기가 계속 생각나서 연락드립니다."
자연스러운 훅처럼 보이지만, 사실이 아닙니다. 이미 첫 미팅에서 사무실 위치를 상대방에게 말했거든요. "역삼 쪽으로 나올 일이 많아지고 있다"는 건 AI가 만들어낸 거짓 문맥입니다.
이건 내가 상황을 알기 때문에 잡은 겁니다 — 내용 검증이었습니다. 하지만 내 상황을 모르는 사람도 쓸 수 있는 구조 검증 방법이 있습니다. "여기 쓰인 것 중 내가 실제로 한 적 없는 말이 있나?" 이 한 가지 체크리스트만 적용하면, AI가 자연스러움을 위해 꾸며낸 거짓 문맥은 대부분 걸립니다. 문장의 자연스러움은 AI가 잘 판단하지만, "이게 사실인가"는 본인만 압니다.
답의 내용은 봤으니, 이제 AI가 지시를 제대로 실행하는 과정에서 생기는 문제입니다.
4. AI에게 실행시키기 전 5초: "무슨 말인지 이해되니?"
클로드에게 복잡한 지시를 내릴 때 습관적으로 하는 말이 있습니다. 지시를 마친 뒤, 실행시키기 전에 "무슨 말인지 이해되니?"를 묻는 겁니다.
나: "이 CRM 비교 문서에서 프레이밍을 바꿔야 해. 지금은 '기능 비교'로 돼 있는데, '설계 철학 비교'로 전환해줘. 기능 항목은 그대로 두되, 각 항목이 왜 그런 구조인지를 설명하는 방향으로. 무슨 말인지 이해되니?"
클로드: "기능 체크리스트는 유지하되, 각 기능의 존재 이유를 설계 철학 관점에서 재해석하라는 말씀이시죠?"
나: "맞아, 진행해."
이걸 안 물어보면 어떻게 되는지도 여러 번 봤습니다. "프레이밍을 바꿔줘"라고만 하면, AI가 내용을 통째로 다시 쓰거나, 기존 구조를 해체하거나, 의도와 전혀 다른 방향으로 갑니다. 실행한 뒤에 "이거 아닌데" 하고 되돌리는 것보다, 실행 전에 5초 들여서 이해도를 확인하는 게 훨씬 빠릅니다.
AI의 오류 중 상당수는 AI가 "틀린 답"을 낸 게 아닙니다. "다른 질문"에 답한 겁니다. 내 지시가 충분히 명확했는지, AI가 같은 그림을 보고 있는지 — 실행 버튼을 누르기 전에 확인하는 이 한 마디가, 사후 교정보다 훨씬 효율적입니다.
5. AI가 "완료됐습니다" 뒤에 빠뜨리는 것들
AI에게 문서를 개선해달라고 하면, 구조를 다듬는 과정에서 기존 내용을 누락시키는 경우가 있습니다. 900줄짜리 CRM 비교 문서의 프레이밍을 개선해달라고 했더니:
클로드: "프레이밍을 개선하고 구조를 재정리했습니다. 핵심 논점이 더 명확하게 전달됩니다."
나: "225줄이 빠졌어. API 코드 예시, 핵심 비유, 시나리오 계산이 통째로 날아갔는데?"
AI는 "개선됐습니다"라고 자신 있게 말했지만, v2에서 225줄이 빠져 있었습니다.
수정 요청에서도 같은 패턴이 반복됩니다. 블로그 글을 에디터에 붙여넣었더니 빈 블록이 생겨서 AI에게 수정을 맡겼습니다. 빈 줄을 전부 제거하고 "고쳤습니다"라고 했는데, 실제로 보니 문단이 전부 하나로 합쳐져서 가독성이 엉망이었습니다. 명함 디자인에서도 마찬가지 — 글꼴 크기를 맞추고 "완료됐습니다" 했는데, 간격 불일치와 라벨 정렬 문제가 남아 있었습니다.
AI는 지시받은 것을 고치는 데 집중하고, 지시받지 않은 연쇄 문제는 놓칩니다. "고치고 나니까 다른 문제는 없어?"를 묻는 겁니다. 원본과 수정본을 나란히 놓고 빠진 게 있는지 확인하는 것 — 이건 문서가 뭘 다루는지 몰라도 할 수 있습니다.
6. AI가 보고하는 숫자가 직관과 3배 차이날 때
이건 정말 자주 나옵니다. 이 글을 쓰는 과정에서도 실제로 일어났습니다.
클로드: "초안 완성했습니다. 137줄, 약 15,000자입니다."
나: "15,000자? 내가 블로그 수십 편 써봤는데, 이건 많아야 5,000자 수준인데. 다시 세어봐."
다시 세게 했더니 공백 포함 6,514자, 공백 제외 4,918자였습니다. 거의 3배 뻥튀기. AI가 사용한 도구가 UTF-8 바이트 수를 셌는데, 한글은 한 글자당 3바이트라 실제 글자 수의 3배가 나온 겁니다. AI는 도구의 출력값을 검증 없이 그대로 전달했고, "약 15,000자"라고 자신 있게 말했습니다.
여기서 잡아낸 방법은 UTF-8 바이트 계산 지식이 아닙니다.
"이 숫자가 직관적으로 말이 되는가?"를 체감으로 판단한 겁니다.
AI가 숫자를 보고할 때 — 글자 수, 비용 추정, 소요 시간 — 내가 경험적으로 아는 범위와 비교해서 "이거 좀 이상한데?"라는 감이 오면 다시 확인시키면 됩니다. 정확한 숫자를 몰라도, "이건 확실히 범위 밖이다"라는 판단은 가능합니다.
AI의 답이 논리적으로 맞는데 현실에서 작동하지 않는 경우입니다.
7. AI 팔로업이 논리적으로 맞는데 역효과인 이유
고객에게 팔로업 이메일을 보내야 하는 상황에서, AI가 회의록을 분석한 뒤 이렇게 제안했습니다.
클로드: "회의록을 보니 고객이 내부 데이터 통합에 어려움을 겪고 있습니다. 이 문제에 대한 인사이트를 이메일 도입부에 넣으면 관심을 끌 수 있을 것 같습니다."
나: "미팅 1번 한 사이에서, 상대 회사 내부 문제를 마치 다 파악한 것처럼 이메일 보내면 어떻게 읽히겠어?"
회의록에 해당 문제가 실제로 언급돼 있었으니, 논리적으로는 맞는 말이었습니다. 하지만 수신자 입장에서 생각하면 완전히 다릅니다. "이 사람이 우리 회사 사정을 다 아는 것처럼 구는데" — 오히려 역효과입니다.
이건 세일즈 경험에서 나온 감각이기도 합니다. 하지만 세일즈를 몰라도 적용할 수 있는 원리가 있습니다. AI가 정보를 활용하는 제안을 할 때, "이 메시지를 받는 사람이 어떤 감정으로 읽을까?"를 한 번만 시뮬레이션하면 됩니다. AI는 정보를 최대한 활용하는 쪽으로 기울고, 수신자의 감정 반응은 잘 예측하지 못합니다. 이 간극을 메우는 건 대인 감각의 영역입니다.
8. AI가 리서치를 잘할수록 빠지는 설득 모드 함정
AI는 정보가 많아질수록 그걸 써먹으려 드는 경향이 있습니다. 리서치를 열심히 해서 상대 회사의 조직 구조, 내부 기술력, 팀 구성까지 다 파악하면 — AI는 이런 식으로 갑니다.
클로드: "리서치 결과를 종합하면, 이 회사는 현재 내부 개발팀이 3명이고 CRM 연동 경험이 없습니다. 이 점을 활용해서 '직접 구축의 리스크'를 강조하는 이메일을 보내면 효과적일 것 같습니다."
나: "그건 말로 한다고 되는 게 아니야. 우리가 아직 확인 못 한 게 뭔지부터 정리하자."
논리적으로 자연스러운 흐름이지만, 팩트 확인이 먼저인 상황에서는 완전히 잘못된 순서입니다.
이건 4개의 서로 다른 팔로업 상황에서 전부 나타났습니다. AI가 매번 비슷한 패턴으로 — 훌륭한 리서치를 마친 뒤 설득 모드로 전환하려 했고, 매번 같은 원칙으로 차단해야 했습니다. AI가 제안하는 다음 액션이 있을 때 "지금 이 순서가 맞는가?"를 묻는 겁니다. 정보를 모으는 단계와 정보를 활용하는 단계를 AI가 섞고 있다면, 순서를 되돌려야 합니다.
같은 오류가 반복되지 않게 개별 교정을 시스템으로 올리는 패턴입니다.
9. AI 오류를 잡은 뒤: "왜 틀렸어?" 다음에 "어떻게 방지해?"까지
AI의 오류를 잡았을 때, 대부분은 "틀렸어, 고쳐"에서 끝납니다. 하지만 같은 유형의 실수가 다른 맥락에서 또 나올 수 있습니다. 그래서 한 단계 더 들어갑니다.
MCP 서버 분류를 잘못한 사례에서, 오류를 교정한 뒤 세 가지 질문을 연속으로 던졌습니다.
1단계: "이건 틀렸어." - 사실 교정.
2단계: "왜 그런 얘기를 했는지 자세히 설명해줘." - 오류의 메커니즘 분석.
3단계: "이 유형의 오류가 구조적으로 재발하지 않게 방지책을 만들자."
3단계까지 가는 이유가 있습니다. AI를 다른 사람에게도 쓰게 해야 하는 위치에 있으면, "나는 잡을 수 있지만 내 클라이언트는 못 잡는다"는 인식이 생깁니다. 개별 오류를 넘어서 오류의 클래스를 다루려는 겁니다. 3단계에서 나온 원칙을 프로젝트 지침에 반영하면, 그 유형의 오류는 구조적으로 줄어듭니다.
10. AI가 대화 맥락을 놓치고 있다는 신호 감지법
긴 대화에서 AI는 초반 합의를 잊어버리는 경우가 있습니다. 이메일 초안을 여러 번 주고받으면서, 중간에 방향이 바뀌었는데 AI가 이전 방향을 계속 고집한 적이 있습니다.
이걸 감지한 건, 결과물에서 이전 합의와의 불일치가 보였기 때문입니다. 대화 전체의 맥락을 AI가 놓치고 있다는 메타 상태를 진단한 겁니다. "우리 채팅 처음부터 다시 읽어봐. 너 지금 헷갈려하고 있어." 이 한 마디로 AI가 맥락을 재정렬합니다.
이건 도메인 지식이 전혀 필요 없는 패턴입니다. "5분 전에 합의한 것과 지금 결과물이 다르다"는 걸 알아차리기만 하면 됩니다. 맥락 유실 신호 세 가지:
AI가 갑자기 이전에 쓰지 않던 용어를 쓴다
이미 결정된 방향을 다시 열어서 논의하려 한다
같은 질문에 이전과 다른 답을 한다
11. AI에게 학습 강제하기: "내가 왜 고쳤는지 맞춰봐"
AI가 쓴 이메일 초안을 살짝 수정해서 보낸 뒤, AI에게 그 이유를 분석하게 한 겁니다.
나: "이메일 보냈는데, 네가 쓴 거에서 두 군데를 바꿨어. 어디를 바꿨고 왜 그랬을지 생각해봐."
클로드: "호칭을 '대표님'에서 '[이름]님'으로 바꾸신 것 같습니다. 첫 미팅에서 상대방이 직함 대신 이름으로 불러달라고 했을 가능성이 있습니다. 두 번째는..."
나: "맞아. 이런 부분들은 꼭 기억해야 해."
AI가 틀린 걸 잡는 것은 방어적 검증이고, "정답을 보여주고 왜 그게 정답인지 맞춰봐"는 공격적 학습입니다. AI가 분석한 이유가 맞으면 클로드 프로젝트 지침에 반영합니다. 개별 대화에서 발견한 원칙을 시스템 수준으로 올리는 작업입니다.
사람과 일할 때도 같은 방법을 씁니다. 다만 사람에게 "내가 왜 고쳤는지 맞춰봐"를 반복하면 관계가 소모됩니다. AI에게는 감정 소모 없이 이걸 반복할 수 있다는 점이, 사람과의 협업에서는 불가능했던 속도를 만들어줍니다.
방어와 공격
11가지 패턴을 돌아보면 두 가지 모드가 보입니다.
방어 모드는 AI가 틀렸을 때 잡는 것입니다. 원본을 확인했는지, 사실이 아닌 문맥을 꾸며내지 않았는지, 이전 합의와 모순되지 않는지, 빠뜨린 게 없는지. AI의 하한선을 관리하는 일입니다.
공격 모드는 잡은 오류를 시스템으로 올리는 것입니다. 왜 틀렸는지 메커니즘을 분석하고, 방지책을 만들고, AI에게 학습을 강제하는 것. AI와 함께 상한선을 올리는 일입니다.
방어만 하면 AI를 "조심해서 쓰는 도구"로 남겨두게 됩니다. 공격까지 하면 AI가 "같이 일하는 팀원"이 됩니다.
서두에서 세일즈 매니저 이야기를 했습니다. 그 산업을 처음 보는 매니저라면 AE의 보고를 그대로 믿을 수밖에 없다고요. 하지만 경험 많은 매니저가 읽는 건 보고의 "결"입니다. 어떤 과정으로 이 결론에 도달했는지, 빠진 건 없는지, 이전에 합의한 것과 충돌하지 않는지.
이 글에서 다룬 11가지 패턴을 돌아보면, 전부 사람과 일할 때 이미 쓰던 스킬입니다.
보고를 받으면 근거를 물어보고,
수정본이 오면 빠진 게 없는지 확인하고,
상대방 입장을 시뮬레이션하고,
같은 실수가 반복되면 구조적 원인을 찾는 것.
함께 일하는 상대가 바뀌었을 뿐, 스킬은 그대로입니다. 다음에 AI가 자신 있게 답할 때, 내용 말고 과정을 한번 물어보세요. 이미 일할 때 사용하던 스킬입니다.