AI 답변, 끝까지 읽어보시나요?

들어가며 — 스크롤을 내리는 손

AI에게 뭔가 물으면, 요즘은 답이 깁니다. 한 화면을 넘기고, 또 넘기죠. 그러면 대부분의 사람은 비슷하게 움직입니다 — 위 몇 줄을 읽다가, 휠을 굴려 맨 아래 결론까지 내려가, 거기만 복사해 붙입니다. 답이 매끄럽고 정연할수록 더 그렇습니다. “이만큼 길고 빼곡하게 썼으면 맞겠지.”

저는 그 지점에서 손을 멈춥니다. AI의 답은 받는 즉시 끝까지 읽고, 미심쩍은 줄은 따로 떼어 확인하는 게 십수 년 일하며 굳은 습관입니다. 그리고 그렇게 끝까지 읽을 때마다, 매끄러운 문장들 사이에 조용히 틀린 한 줄이 섞여 있는 걸 자주 봅니다. 바로 그 한 줄에서, AI로 일하는 사람이 갈립니다 — 결론만 보고 넘기는 사람과, 답을 끝까지 검증하는 사람으로.

1. AI가 길게 답할수록, 사람은 덜 읽는다

안드레이 카르파시(OpenAI 창립 멤버이자 테슬라 AI를 이끌었던 사람)가 이 변화를 한 문장으로 짚었습니다 — “AI는 사람이 검증할 수 있는 것보다 빨리 생성한다.”

예전에는 무언가를 만드는 일이 병목이었습니다. 보고서 한 장, 표 하나를 만드는 데 시간이 걸렸죠. 그런데 AI가 그 만드는 수고를 거의 0으로 만들면서, 병목은 검토로 옮겨갔습니다. 이제 어려운 건 만드는 게 아니라, 만들어진 걸 제대로 확인하는 일입니다.

문제는, 현실에서 사람들이 바로 그 검토를 건너뛴다는 데 있습니다. 만드는 수고가 사라지니까, 확인하는 수고도 함께 사라진 것처럼 굴어요. AI가 1분 만에 두 페이지를 뽑아주면, 그 두 페이지를 1분 동안 검증할 마음은 좀처럼 들지 않습니다. 그래서 결론만 긁어 다음으로 넘깁니다. 병목은 분명 검토로 옮겨왔는데, 정작 그 자리를 비워둔 채로요.

2. 안 읽은 구간에 오류가 숨는다

AI의 답은 대부분 맞습니다. 그래서 오히려 더 위험합니다. 열 줄 중 아홉 줄이 정확하면, 사람은 나머지 한 줄도 맞다고 믿어버리니까요. 그리고 그 틀린 한 줄은 빨간 글씨로 오지 않습니다 — 나머지 아홉 줄과 똑같이 매끄러운 문장으로 섞여 들어옵니다.

얼마 전 한 교육 자료에 넣을 업계 사례를 AI로 정리하던 때입니다. AI는 사례를 깔끔하게 써 내려가다, 중간에 “생산성 ○○% 향상” 같은 구체적인 성과 숫자를 자연스럽게 적어 넣었습니다. 문장만 보면 흠잡을 데가 없었죠. 그런데 그 숫자의 출처를 짚어보니, 어디에도 그런 수치는 없었습니다 — AI가 사례의 모양새를 맞추려고 그럴듯하게 지어낸 숫자였어요. 결론만 보고 넘겼다면, 출처 없는 숫자가 그대로 교육장 스크린에 올라갔을 겁니다.

여기서 가장 위험한 건 그 가짜 숫자 자체가 아닙니다. “AI가 썼으니 맞겠지”라는 한 문장입니다. 똑같은 숫자를 사람이 적어 왔다면 “이거 출처가 어디예요?”라고 한 번은 물었을 텐데, AI가 적었다는 이유로 오히려 더 쉽게 통과시킵니다. 그래서 사람이 했으면 걸렸을 오류가, AI를 거치면 검증 없이 더 멀리 나갑니다.

3. 그래서 ‘읽기’를 넘어 — 눈에 보이게 바꾼다

길수록 안 읽는 게 사람의 본성이라면, 답을 안 읽어도 오류가 튀어나오는 형태로 바꾸면 됩니다. 카르파시의 처방이 정확히 이것입니다 — 검증을 사람의 인지 강점에 맞추라는 것. 그는 검증을 빠르게 해주는 장치로 미리보기, 시각 출력, 스크린샷 같은 것들을 듭니다. 빽빽한 텍스트를 한 줄씩 곱씹는 것보다, 표나 그림으로 보면 어긋난 데가 훨씬 빨리 눈에 띄기 때문입니다.

실천은 단순합니다. AI에게 답을 받으면, 한 번 더 시킵니다 — “이걸 표로 정리해줘”, “비교를 HTML 표로 보여줘”, “이 데이터를 간단한 차트로 그려줘.” 그러면 텍스트 문단 속에 묻혀 보이지 않던 것들이 대번에 드러납니다. 빈칸, 앞뒤가 안 맞는 값, 혼자 튀는 숫자 — 줄글로 읽을 땐 스르륵 넘어가던 것들이, 칸과 그림으로 나란히 놓이는 순간 눈을 찌릅니다. 앞의 가짜 숫자도, 사례들을 표로 세워 “출처” 칸을 만드는 순간 그 칸만 비어 있어 단번에 보였을 겁니다.

카르파시가 이 이야기를 한 건 주로 코드를 다루는 맥락이었습니다. 하지만 코드를 못 읽는 사람에게는 오히려 더 맞는 처방입니다. 코드는 어차피 못 읽으니 시각 출력에 기댈 수밖에 없고, 표와 그림은 누구의 눈에나 똑같이 보이니까요. 비개발자가 가진 가장 강한 검증 도구는, 결국 눈입니다.

같은 답이라도 검증하는 방식이 결과를 가릅니다. 읽고 넘기면 오류가 흘러가고, 보이는 형태로 바꾸면 눈에 걸립니다.

4. 결국 같은 원리입니다 — 검증은 눈으로

전에 AI가 ‘됐다’고 해도 일이 끝난 게 아니라며, 결과물을 그림으로 끝까지 보라고 쓴 적이 있습니다. 그건 슬라이드 같은 산출물을 눈으로 확인하는 이야기였죠. 오늘 글은 그보다 한 칸 앞 — AI가 내놓은 답변 텍스트 자체입니다. 대상은 다르지만 원리는 똑같습니다. 검증은 글자를 노려보는 게 아니라, 눈에 보이는 형태로 바꿔서 보는 것입니다.

그리고 이건 좋은 답은 ‘다시’ 버튼이 아니라 평가의 눈에서 나온다는 이야기의 가장 첫 단계이기도 합니다. 평가하려면, 일단 봐야 하니까요. 끝까지 읽지 않은 답은 애초에 평가할 수도 없습니다. ‘평가의 눈’이라는 게 거창한 안목 같지만, 그 출발점은 이렇게 소박합니다 — 답을 끝까지 본다. 그리고 잘 안 보이면, 보이는 형태로 바꿔서 본다.

5. 검증할 수 있는 만큼만, 맡길 수 있다

카르파시의 또 다른 문장이 이 모든 걸 하나로 묶습니다 — “전통적인 컴퓨터는 코드로 명세할 수 있는 것을 자동화하고, AI는 사람이 검증할 수 있는 것을 자동화한다.”

이 말을 뒤집으면 이렇게 됩니다 — 내가 검증하지 못하는 일은, AI에게 제대로 맡길 수도 없다. 검증력이 곧 위임의 한계선입니다. 검증 못 하는 영역을 맡기는 건 맡기는 게 아니라 그냥 눈 감고 받는 것이고, 그 순간 결과의 책임만 고스란히 사람에게 남습니다.

그래서 AI를 잘 쓰는 사람은 답을 빨리 받는 사람이 아니라, 그 답을 빨리·정확히 검증하는 사람입니다. 조직에서 조용히 갈리는 것도 누가 더 많은 기능을 아느냐가 아니라, 누가 “AI가 줬으니 됐다”는 말 앞에서 한 번 더 멈춰 서느냐입니다. AI는 일을 빠르게 합니다. 하지만 그 답이 맞는지 판단하는 마지막 자리는, 여전히 사람의 것입니다.

그래서 저는 도구를 빨리 익히라고 말하지 않습니다. 답을 끝까지 보고, 보이지 않으면 보이게 바꿔서 검증하라고 말합니다. 그게 도구가 아니라, 일하는 방식을 바꾸는 일이니까요.

출처

Andrej Karpathy — “Software Is Changing Again” (YC AI Startup School 강연, 2025) 정리 — 생성-검증 루프, “AI는 사람이 검증할 수 있는 것보다 빨리 생성한다”, 검증 인터페이스(미리보기·시각 출력·스크린샷)
Andrej Karpathy’s Verifiability Thesis (Sequoia AI event 정리) — “AI는 사람이 검증할 수 있는 것을 자동화한다”

카르파시 발언의 사실관계는 위 출처를 따릅니다. 업계 사례의 가짜 숫자 일화는 실제 작업 경험을 익명화한 것이며, 해석과 현장 관점은 박상훈의 견해입니다.