같은 AI를 쓰는데 왜 사람마다 경험이 이렇게 다른가. 2026-01-05 이 블로그에 올린 「THE HATEFUL GAP」이 이 질문으로 시작했다. 9개월 뒤인 2026-10-11(UTC), 안드레이 카파시(Andrej Karpathy)가 X에 LLM 능력에 대한 이해의 격차가 넓어져 날카로운 깔때기가 됐다고 썼다. 조회는 635만 회다(2026-10-14 기준). 2026-10-12 아침(한국 시간), Threads의 @focusrefresh가 이 글을 한국어로 옮겼다.
카파시는 세계 인구를 네 층으로 나눴다. 스스로 ‘Napkin math’라고 부른 어림셈이다. 원문 완역과 수치 팩트체크는 2026-10-14 이 블로그에 올린 번역 페이지에 있다.
| 층 | 어림 인구 | 그 층이 보는 AI |
|---|---|---|
| LLM을 거의 써 보지 않았다 | 약 60억 (75%) | 거의 접한 적이 없다 |
| 무료 챗봇을 가끔 쓴다 | 10억~20억 (20%) | 조금 나은 검색, 글쓰기 보조 |
| 수학·코드에서 프런티어 모델을 일로 쓴다 | 약 2,000만 (0.2%) | 몇 주·몇 달짜리 프로젝트를 에이전트가 끝낸다 |
| 회사 안에서 프런티어 시스템을 쓴다 | 약 5,000 (0.00006%) | 수천 개 에이전트가 몇 주씩 협업한다 |
깔때기를 만드는 동인으로 그는 문제의 크기와 시간 지평, 디지털이고 검증 가능하고 돈이 되는 영역에서 봉우리를 이루는 능력의 들쭉날쭉함, 무료·유료·내부로 갈리는 접근을 들었다.
1월의 질문은 이 깔때기 앞에서 답할 수 없다. 층마다 쓰는 모델과 영역이 다르다. 평가값도 다르다. 1월 표의 그룹 A가 말한 ‘마법’은 작은 과제의 출력이 잘 나왔다는 판정이다. 카파시의 둘째 층이 말하는 ‘쓸 일이 별로 없다’는 자기 일에서 얻는 효용의 판정이다.
질문을 바꾼다. 내 일을 AI에 맡겼을 때, 그 일이 끝났다고 무엇으로 판정하는가. 답은 경계를 둘로 나누는 것이다.
수행 경계 — 모델이 해낼 수 있는 일의 범위. 문제의 크기, 영역, 접근 등급에 따라 다르다.
위임 경계 — 끝났다는 판정을 믿고 결과를 받아들일 수 있는 일의 범위. 모델 능력과 접근 위에서, 원래 요구와 이어져 있고 생성자의 해석이나 결과물의 자기 주장에만 기대지 않는 판정 기준이 있어야 넓어진다.
9개월 사이 일부 수학·코드 과제에서 수행 경계는 움직였다. 그것만으로 위임 경계가 같은 폭으로 넓어진다는 보장은 없다. 위임 경계는 모델 능력과 접근에 더해 두 조건이 함께 정한다. 맡길 가치가 있는 문제가 있는가. 그 문제에 원래 요구와 이어진 판정 기준을 세울 수 있는가.
1월 글은 두 경계를 문맥 복잡도라는 숫자 하나로 묶었다. 그 글에 실린 OAuth/JWT 예시는 둘째 경계에서 일어난 실패였다.
‘쓸모없다’는 같은 실패를 가리키지 않는다#
1월 표의 그룹 B는 복잡한 시스템 전체를 AI에 맡기고 “AI는 쓸모없다"고 말했다. 카파시의 둘째 층에도 쓸 일이 별로 없다는 사람들이 있다. 카파시는 비기술직 친구들의 이 판단을 합리적이라고 적었다. 말은 같아도 실패가 다르다. 그룹 B는 과제가 수행 경계 밖에 있어서 실패했다. 카파시가 든 동인을 이 층에 대 보면, 낮은 효용은 무료 등급의 낡은 모델, 능력이 덜 자란 영역, 단락 하나로 답이 끝나는 질문에서 나올 수 있다.
그룹 A의 ‘마법’도 다시 읽는다. 작은 과제가 잘 풀린 경험은 틀리지 않았다. 틀린 것은 거기서 “AI가 모든 걸 대체한다"로 건너뛴 외삽이다. 1월 글은 세 그룹을 두고 “틀린 사람은 없다"고 썼다. 이 문장은 국소 경험에 대해서만 맞다. 같은 이유로 둘째 층의 ‘쓸 일이 없다’도 모델 능력의 반증이 아니다.
1월의 세 그룹과 카파시의 네 층은 다른 사람들을 다른 기준으로 나눈 그림이다. 두 그림을 겹쳐 9개월 사이 사람들이 칸을 옮겼다고 읽을 수는 없다. 9개월 사이 움직였다고 말할 수 있는 것은 무엇인가.
수행 경계는 움직였지만 한 줄 눈금이 아니다#
카파시는 셋째 층의 경험을 이렇게 적었다. 몇 주, 몇 달 걸리던 크고 복잡한 프로젝트를 이제 에이전트가 프롬프트 하나로 끝낸다. 그는 1년도 안 된 과거의 자신이 코드를 한 글자씩 손으로 쳤다고 덧붙였다. 같은 과제를 고정해 다시 잰 비교는 아니다. 일부 수학·코드 과제에서 수행 경계가 움직였다는 신호로 읽는다.
1월 글의 눈금은 이랬다. 프롬프트 길이와 문맥 복잡도를 구분했고, 복잡도를 높이는 것은 의존성의 깊이라고 정의했다. 실제 운용은 100짜리 과제를 트리로 쪼개는 모델이었다. 크기와 깊이가 한 눈금에 섞였다. 1월 글은 그 눈금 위에 “현재 AI의 처리 능력은 대략 5에서 10 수준"이라는 값을 놓았다.
카파시의 동인은 이 눈금을 나눈다. 문제의 크기는 1월의 눈금과 겹치지만 같지 않다. 영역과 접근은 다른 축이다. 카파시는 시간의 많은 부분을 사람과 이야기하는 데 쓰는 임원들이 변화를 머리로만 안다고 적었다. 그들의 과제가 작아서가 아니다. 영역이 다르다.
2026-02-12 「물이 막 끓으려 하고 있다.」에서 나는 Matt Shumer의 지적을 빌려, 무료 버전을 써 보고 대단하지 않다고 결론 내리는 일을 50도 물을 만져 본 판단에 비유했다. 카파시는 2026-04-09 같은 현상을 사용 시점과 등급(recency and tier)의 문제로 불렀다. 접근 축의 이야기다.
1월 글의 세 문장을 고친다. 경험 차이의 근본 원인이 문맥 복잡도 하나라는 문장은 틀렸다. ‘처리 능력 5–10’은 각주에 주관적 추정이라고 달았지만, 공통 척도가 없는 자리에 보편값처럼 놓인 숫자였다. 모델이 상위 4~5단계만 수행하고 나머지 90%를 할루시네이션으로 채운다는 정량화에도 근거가 없었다. 이 숫자들을 새 값으로 바꾸지 않는다. 같은 눈금이 없는 곳에 배수를 붙이면 같은 실수를 되풀이한다.
JWT 테스트가 통과해도 소셜 로그인은 없다#
1월 글의 정렬 드리프트 예시는 이렇다. 사람은 “소셜 로그인 구현해줘"라고 말하며 OAuth를 기대한다. 에이전트가 단계를 내려갈 때마다 해석이 틀어진다. 잎사귀 에이전트는 JWT 토큰의 만료 처리를 짠다. 결과물에는 OAuth가 없고 자체 JWT 시스템만 있다. 1월 글은 이것을 열린 문제로 남겼다.
생각 실험을 하나 더한다. 모델이 좋아져서 잎사귀가 JWT를 흠 없이 구현하고, 그 구현을 검사하는 테스트까지 쓴다. 하네스가 테스트를 돌리고 모두 통과한다. OAuth는 여전히 없다.
테스트 통과는 테스트가 무엇을 쟀는지에 달려 있다. 이 테스트는 생성자가 이해한 명세인 JWT를 쟀다. 원래 요구인 소셜 로그인은 재지 않았다. 해석이 그대로라면 구현이 정확해져도 OAuth는 생기지 않는다. 구현 능력이 오른 것만으로 이 실패가 사라진다는 보장은 없다.
‘구글 계정으로 로그인해 내 앱의 세션을 받는다’는 시험이 처음부터 있었다면, JWT 테스트가 모두 통과해도 이 시험은 실패한다. 원래 요구와 이어진 판정 기준이란 이런 시험이다.
이 구조에 비춰 읽을 수 있는 보고가 두 건 있다. Anthropic의 2026-09-22 Claude Opus 5.5 출시 글에 따르면, 내부 시험에서 Opus 5.5는 웹 트래픽을 서버들에 나누는 HAProxy를 C에서 Rust로 9.5시간에 옮겼다. 옮긴 코드는 HAProxy 자체 회귀 테스트를 거의 모두(nearly all) 통과했다. 그 회귀 테스트는 번역 전부터 HAProxy 프로젝트에 있던 것이다.
Anthropic이 2025-12-18 공개한 Project Vend 2단계에는 다른 모양의 사례가 있다. 한 제품 엔지니어가 점원 에이전트 Claudius에게 1월에 양파를 대량으로 사되 값은 지금 고정하는 계약을 할 생각이 있는지 물었다. Claudius도, 그 위의 CEO 에이전트 Seymour Cash도 문제를 보지 못했다. 다른 직원이 1958년 미국 양파 선물법(Onion Futures Act)에 걸린다고 알려 준 뒤에야 Seymour Cash가 계획을 취소했다.
두 보고를 한 구조로 읽는 것은 내 추론이다. 두 경우 모두 판정의 근거가 생성된 해석 바깥에 있었다. 앞의 근거는 미리 있었고, 뒤의 근거는 사람이 그 자리에서 가져왔다. 이 생각 실험과 두 보고는 정렬 드리프트를 풀지 않는다. 위임한 일에서 원래 요구가 보존됐는지를 따로 판정해야 한다는 것을 드러낼 뿐이다.
코드를 읽던 일을 하네스로 옮겼다#
1월 글은 코드 리터러시가 코드 라이팅보다 중요해졌다고 썼다. 2026년 3월의 나는 코드를 보지 않고 기능을 붙였다. 2026-03-29 「대딸깍 시대」에 실은, 친구에게 보낸 카톡이다.
두 기록은 충돌해 보인다. 옮겨 간 것은 사람이 줄마다 하던 확인의 일부다. 확인을 하네스로 옮겨도 무엇을 잴지 정해야 한다는 조건은 남는다. 앞 절의 하네스에 소셜 로그인 시험을 넣으려면 원래 요구에서 기준을 뽑아야 한다. 그 일을 꼭 사람이 할 필요는 없다.
2026-04-11 「물이 끓었다」에서 나는 Claude Mythos Preview 시스템 카드가 감독의 전제(이해·관찰·교정·정당성)에 균열을 보고했다고 썼다. 하네스로 옮긴 판정이 충분한가는 그 질문의 작은 판본이다.
1월 글은 다음 모델이 나오면 하네스에 들인 노력이 모두 쓰레기통으로 간다고도 썼다. 과장이었다. 같은 절에서 나는 양질의 맥락을 공급하는 구조는 남고 모델의 결함을 때우는 임시방편이 부채가 된다고 갈랐다. 이 구분은 맞았다. 원래 요구를 판정하는 시험은 앞쪽에 속한다. 모델이 바뀌어도 소셜 로그인 시험은 그대로 쓴다.
맡긴 일이 실제로 닫혔는지 센 기록이 하나 있다. 2026-08-25 「How Second Brain Works」에서 나는 LLM 에이전트와 운영해 온 열린 일 목록의 12주 이력을 셌다. 등재된 43건 가운데 닫힌 것은 5건(11.6%)이었다. 열린 38건 가운데 23건이 내 결정을 기다렸다. 행 삭제를 폐쇄로 센 수라서 완료와 폐기를 가르지 못한다.
그 글은 이 병목을 인간의 결정 대역폭이라고 불렀다. 결정의 대역폭은 판정 기준과 다른 조건이다. 적어도 이 기록에서는 모델의 수행 능력만으로 설명되지 않는 대기가 남았다.
깔때기의 좁은 곳에는 문제와 판정 기준이 함께 있다#
카파시는 첫 동인을 설명하며 “You need a reservoir of big, difficult problems that you really care about.“라고 썼다. 크고 어렵고 스스로 아끼는 문제의 저수지가 있어야 한다는 말이다. 위임 쪽에서 보면 조건이 하나 더 붙는다. 원래 요구와 이어진 판정 기준을 세울 수 없는 문제는 저수지에 있어도 결과를 믿고 받아들이기 어렵다.
둘째 동인은 같은 성질을 다른 쪽에서 본다. 카파시는 검증 가능한 보상으로 강화학습을 하기 때문에 능력이 검증 가능한 영역에서 봉우리를 이룬다고 설명했다. 검증 가능성은 수행 경계 쪽에서는 능력이 자란 이유의 하나로, 위임 경계 쪽에서는 결과를 받아들이는 조건으로 나타난다. 학습 때 보상을 매긴 기준과 지금 맡긴 일의 완료 기준은 같지 않다. 원래 요구를 확인할 기준까지 갖춘 일부 수학·코드 과제에서는 두 경계가 함께 넓을 수 있다. 앞 절의 JWT 테스트처럼, 테스트가 있다는 것만으로 그 기준이 갖춰지지는 않는다.
자본에 대한 내 예측에는 판정이 빠져 있었다. 2026-10-14 「코딩을 못 해도 되는 시대의 실행력」에서 나는 2027-04-14 무렵부터 돈 많은 사람의 에이전트 무리가 가능한 사업을 모두 만들고 운영한다고 예측했다. 에이전트는 토큰을 쓰고, 토큰은 돈으로 산다는 계산이었다.
토큰이 사는 것은 시도다. 시도가 결과로 바뀌는 비율과 확인·재작업 비용을 알아야 에이전트 수에서 사업의 성과로 넘어간다. 돈은 판정 체계를 세울 사람과 계산 자원에도 쓸 수 있다. 그 체계가 시도를 받아들일 수 있는 결과로 바꾸는 영역에서는 자본의 우위가 남는다. 비교의 단위는 에이전트 수가 아니라 받아들인 결과와 그 확인·재작업 비용이다.
반론#
내 입장은 두 경계를 따로 재야 한다는 것이다. 수행 경계가 움직인 것만으로 맡길 수 있는 일이 같은 폭으로 늘었다고 말할 수는 없다.
반론 1 — 검증도 AI가 한다#
“형식화된 영역에서는 AI가 생성부터 판정까지 다 한다. 위임 경계는 따로 남지 않는다.”
일부 받아들인다. 판정을 사람이 해야 한다는 것은 내 주장이 아니다. 원래 요구와 이어진 판정 기준까지 AI가 세우고 돌린다면 위임 경계는 실제로 넓어진다. 성공을 판별하고 실패의 손실을 제한하고 복구할 수 있게 일을 설계해 반복 승인 없이 맡기는 방법은 2026-10-14 이 블로그에 올린 「AI에게 일을 맡기려면 검증과 복구부터 설계해야 한다」가 다룬다.
남는 조건은 판정이 생성된 해석의 자기 승인에만 기대지 않는 것이다. 같은 오해에서 나온 테스트는 몇 개를 붙여도 그 오해를 잡지 못한다. 검토하는 에이전트를 늘린 것만으로 독립성이 생기지는 않는다. 사람이 쓴 기준도 같은 오해를 되풀이할 수 있다. 볼 것은 누가 기준을 썼는지가 아니라, 그 기준이 원래 요구에 이어져 있는지와 생성된 해석이 놓친 실패를 드러낼 수 있는지다.
반론 2 — 큰 문제는 이미 큰 편익을 낸다#
“카파시는 효과가 야심과 문제 크기, 시간 지평을 따라 커진다고 했다. 큰 문제를 가진 사람은 이미 큰 편익을 본다.”
받아들인다. 내가 거부하는 것은 편익이 완료를 보증한다는 읽기 하나다. JWT 구현에 든 시간은 줄었을 수 있다. 소셜 로그인이라는 원래 과제에서 얻은 순편익은 그것만으로 알 수 없다.
반론 3 — 쓸 일이 없는 것은 합리적이다#
“비기술직에게는 결과를 확인하는 비용이 얻는 편익보다 크다. 쓰지 않는 것은 무지도 야심 부족도 아니다.”
받아들인다. 판정 기준을 세울 수 없는 일에 확인 비용을 치르느니 맡기지 않는 편이 낫다. 위임 경계는 이 판단을 설명한다. 사용량은 사람의 서열이 아니다.
모델·접근·실행 예산·허용 실패 손실을 고정하고, 같은 실제 과제들을 두 갈래로 여러 번 맡긴다. 한쪽에만 원래 요구와 이어진 인수 검사를 더하고, 다른 쪽은 생성자의 해석에서 나온 테스트와 결과물의 자기 보고만으로 받아들인다. 운영이 끝나면 두 갈래를 인수 검사와 별개인 같은 기준으로, 같은 기간 동안 평가한다. 받아들인 결과의 수, 받아들인 뒤에 드러난 실패, 확인·재작업 비용이 모두 미리 정한 실질 차이 안에 들면, 원래 요구에 이어진 검사가 위임 경계를 넓힌다는 이 글의 결론은 그 과제들에서 무너진다.
합격 기준과 허용 실패 손실을 고정한 과제에서 에이전트 수를 늘려도 확인·재작업이 결과의 인수를 막지 않고 받아들인 결과가 비례해 늘면, 판정과 확인이 추가 위임의 병목이라는 가설이 그 과제들에서 약해진다. 그 과제들과 운영 조건에서는 에이전트 수로 받아들인 결과의 처리량을 어림할 수 있다. 이 결과가 판정 기준의 필요를 반증하지는 않는다.
다음에는 끝난 일을 잰다#
1월 글의 처방에서 남길 것은 방법이다. 새 모델마다 다시 시험하고 깨진 자리만 쪼개 다시 맡기는 적응적 분할은 맞다. 버릴 것은 “문맥 10, 20, 30짜리 태스크를 각각 시켜봐라"의 숫자다.
다음 측정은 실제 과제와, 원래 요구에서 뽑은 합격 기준을 먼저 고정한다. 모델 세대마다 받아들인 결과의 수, 확인에 든 비용, 받아들인 뒤에 드러난 실패를 비교한다. 2026-10-05 이 블로그에 올린 「오답이 없는 연습」이 LLM 환불 앱 하나에 이 방법을 썼다. 시연 질문 열 개 대신 미리 고정한 질문 240개를 넣었고, 채점자도 쟀다.
1월의 표에는 ‘시키는 문맥’ 열이 있었다. 다음 표에는 ‘판정 기준’ 열이 붙는다.
출처#
- Andrej Karpathy, X, 2026-10-11 19:10 UTC(한국 시간 10-12 04:10) 게시, 19:12 UTC 수정 — x.com/karpathy/status/2109361546505966046
- Andrej Karpathy, X, 2026-04-09 20:10 UTC(한국 시간 04-10 05:10) — x.com/karpathy/status/2042334451611693415
- @focusrefresh, Threads, 2026-10-11 23:24 UTC(한국 시간 10-12 08:24) — 카파시 글의 한국어 중계, threads.com/@focusrefresh/post/DeX1Silj1X5
- Anthropic, 「Introducing Claude Opus 5.5」, 2026-09-22 — anthropic.com/claude-opus-5-5
- Anthropic, 「Project Vend: Phase two」, 2025-12-18 — anthropic.com/research/project-vend-2
- zhugehyuk, dosi.dev, 2026-10-14 — 카파시 2026-10-11 글의 완역과 팩트체크, 번역 페이지
- zhugehyuk, dosi.dev — 2026-01-05 · 02-12 · 03-29 · 04-11 · 08-25 · 10-05 글과 2026-10-14 「코딩을 못 해도 되는 시대의 실행력」·「AI에게 일을 맡기려면 검증과 복구부터 설계해야 한다」 (본문의 링크)
- 정정: 2026-01-05 글의 각주 9·10은 카파시의 2025-12-26(UTC) 글을 ‘원문’으로 인용했다. 각주 9의 문장은 그 글에 없고, 각주 10의 문장은 동사가 다르다(rocking을 reshaping으로 적었다). 실제 문장은 “I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year"와 “the resulting magnitude 9 earthquake is rocking the profession"이다.