같은 AI가 누구에게는 ‘어설픈 챗봇’이고 누구에게는 ‘현기증’인 까닭은 맡기는 문제의 크기와 일의 분야, 쓸 수 있는 모델이 저마다 다르기 때문이에요. Andrej Karpathy는 10월 12일 새벽(한국 시간) X에 올린 긴 글에서 사람들을 깔때기 네 층으로 나누고 이렇게 설명했어요. 이 글을 곁에 두고 같은 주에 개발자들이 많이 읽은 AI 글 여덟 편을 함께 읽었어요. 대부분은 깔때기 어느 한 층의 이야기였어요.
출발점: Karpathy의 깔때기
한국 시간으로 10월 12일 새벽, Andrej Karpathy가 X에 긴 글을 올렸어요. 4월에 쓴 글을 다시 꺼내 들며 LLM이 어디까지 할 수 있는지 사람마다 아는 정도가 다르고 그 차이가 점점 벌어지고 있다고 썼어요. 19일 기준으로 좋아요 43,406개, 조회 662만 회예요. Hacker News에서도 728점을 받았고 댓글이 1,072개 달렸어요.
Karpathy는 사람들을 깔때기 네 층으로 나눴어요. AI를 써 본 일반 사람들 눈에 AI는 아직 ‘어설픈 챗봇’이에요. 반대편 끝의 극소수 전문가는 곡선이 수직으로 치솟는 현기증을 느끼고요. 숫자는 본인이 어림셈(napkin math)이라고 밝힌 값이에요. 그림을 따라 한 층씩 내려가 볼게요.
약 60억 명, 인구의 75%는 LLM을 거의 써 본 적이 없어요.
10억~20억 명, 약 20%는 무료 챗봇을 가끔 써요. 조금 나은 검색이나 글쓰기 도우미쯤으로 여겨요.
Karpathy는 수학이나 코딩을 하지 않는 전문직 상당수도 이 층에 있다고 봤어요. 임원처럼 사람을 만나는 데 시간을 많이 쓰는 사람은 변화를 머리로는 알아도 직접 겪지는 못한다는 거예요.
약 2천만 명, 0.2%는 최상위 모델로 수학과 코딩 일을 해요. 몇 주, 몇 달 걸리던 큰 프로젝트를 에이전트가 프롬프트 하나로 끝내는 모습을 직접 봐요.
Karpathy 자신도 1년 전까지는 코드를 한 글자씩 손으로 쳤다고 적었어요.
약 5천 명은 AI 회사 안에서만 쓰는 가장 앞선 시스템을 써요. 에이전트 수천 개가 몇 주씩 함께 큰 소프트웨어를 만드는 모습이라고 해요.
그사이 사람이 검토하고 이해하는 속도는 뒤처지기 시작했다고 덧붙였어요.
이런 깔때기가 생기는 까닭으로 Karpathy는 세 가지를 꼽았어요. 첫째, 문제가 크고 오래 걸릴수록 효과를 크게 느껴요. 둘째, 모델의 능력이 디지털이면서 검증할 수 있고 돈이 되는 분야에 몰려 있어요. 이걸 들쭉날쭉함(jaggedness)이라고 불러요. 셋째, 쓸 수 있는 모델이 무료, 유료, 회사 내부용으로 나뉘어 있어요.
극소수의 전문가는 곡선이 수직으로 치솟는 현기증을 느끼고 있다. 이 모든 일이 한꺼번에 벌어지고 있다.
Andrej Karpathy, X, 2026-10-11
이 깔때기를 곁에 두고 같은 주에 많이 읽힌 글을 읽어 보면, 대부분 깔때기 어느 한 층의 이야기예요.
벤치마크로 재는 일은 얼마나 될까
Mercor는 「Benchmark Map」에서 미국 노동부의 직업 분류(O*NET, 직업 923개와 과업 18,797개)에 공개 벤치마크 29개의 문항을 하나하나 짝지어 봤어요. 짝짓는 일은 LLM에 맡겼고 사람 전문가가 붙인 태그와 견줘 검증했다고 해요. 그 결과 미국에서 일하는 시간의 90%가 기존 벤치마크로 거의 재지 않는 과업에 쓰인다고 결론지었어요. 벤치마크 문항 다섯 개 이상으로 재는 과업이 하나라도 있는 직업은 923개 중 208개뿐이었어요. 22개 직군 가운데 6개에는 그런 직업이 하나도 없었어요. HN에서 624점을 받았어요.
저자들은 이 결과가 잠정적이라고 적었어요. 고른 벤치마크가 대표 표본이 아니어서 측정 범위가 실제보다 좁게 나왔을 수 있어요. 소프트웨어 공학처럼 벤치마크가 많은 분야는 직군마다 개수를 제한한 탓에 덜 잡혔다고 해요. 그래도 방향은 Karpathy가 말한 들쭉날쭉함과 같아요. 제가 읽기에는 모델이 잘하는 일과 잘하는지 확인할 수 있는 일이 같은 곳에 몰려 있다는 이야기예요.
도구인가, 자동화인가
10월 12일, Clojure를 만든 Rich Hickey가 「‘AI’는 도구가 아니다」라는 글을 올렸어요(HN 318점). Hickey가 보기에 도구는 손에 쥐고 다루는 것이고 쓸수록 솜씨가 늘어요. LLM은 부탁하면 알아서 해 주니 도구로 볼 수 없고 자동화라는 주장이에요. 읽기나 코드 쓰기를 맡겨 버리면 그 일을 하며 배우던 것, 곧 글을 쓰고 따지고 생각하는 법을 놓친다고 했어요.
도구는 그걸 들고 무언가를 하는 연장이다. 나 대신 일을 해 주지는 않는다.
Rich Hickey, ‘AI’ Is Not a Tool
같은 날 Huahai가 쓴 반론은 HN에서 805점을 받아 더 많이 읽혔어요. Huahai도 일을 맡기면 배울 기회를 잃을 수 있다는 데는 동의해요. 다만 컴파일러와 스프레드시트도 많은 일을 알아서 하지만 우리는 둘 다 도구라고 부른다고 짚었어요. 결과를 따져 묻고 시험해 보고 고치며 쓰는 사람에게는 LLM도 도구라는 거예요. 반대로 요약만 읽고 원문을 건너뛰면 읽기에서 배우던 것을 잃는다고 봤어요.
다른 도구가 그렇듯, 잘 쓰려면 솜씨가 필요하다.
Huahai, AI is a tool and using it well takes skill
제가 보기에는 두 글이 깔때기의 서로 다른 층을 말하고 있어요. 깔때기 아래로 갈수록 결과를 시험하고 고치는 데 드는 시간도 늘어날 거예요. 그 일을 건너뛴다면 Hickey의 걱정이 맞고요.
깔때기 맨 아래: 하루에 머지 3만 건
Anthropic 엔지니어링 블로그에 올라온 「Redesigning source control at Anthropic」에는 Karpathy가 말한 맨 아래층이 숫자로 나와요(HN 894점). 모노레포에 하루에 머지되는 변경이 2026년 5월 약 2,500건에서 9월에는 3만 건을 넘었어요. CI는 하루에 약 2,500만 번 체크아웃을 해요. git은 클론마다 전체 기록을 갖는 오프라인 우선 설계인데, 늘 연결돼 있는 에이전트와 자동화 작업에는 이 전제가 맞지 않았다고 해요. 그래서 Scion이라는 자체 버전 관리 시스템을 만들어 다섯 달 만에 모노레포를 git에서 옮겼어요.
Scion은 클라이언트가 늘 온라인이라고 가정해요. 기록, blame, 커밋, 머지는 서버가 맡고 클라이언트는 크기가 정해진 캐시만 둬요. 파일도 필요한 것만 받아요. 예전 git 미러 구성과 비교해 CPU와 메모리 사용량이 약 200분의 1로 줄었고 체크아웃은 몇 분에서 몇 초가 됐다고 해요. 다만 글쓴이들은 git을 대체하려는 것은 아니라고 했어요. 다른 git 플랫폼이 참고하도록 방식을 공개한다고 밝혔어요.
같은 주에 나온 보안 문제 세 건
에이전트가 늘 켜져 있고 API 키까지 쥐고 있으면 공격받을 틈도 늘어나요. 이번에 많이 읽힌 글 가운데 세 편이 그 이야기였어요.
Codex CLI의 상주 데몬(HN 609점). 9월 25일 openai/codex 저장소에 올라온 이슈예요. 보고에 따르면 CLI를 대화형으로 열면 창을 닫아도 꺼지지 않는 백그라운드 데몬이 떠요. 홈 폴더에는 약 374MB짜리 패키지가 복사되고 업데이트를 확인해 백엔드를 다시 띄우는 프로세스도 따로 돌아요. 글쓴이는 이 기능을 기본으로 꺼 두거나 처음 한 번은 물어봐 달라고 했어요. 19일까지 관리자의 답은 없어요.
OpenCode 침해(HN 964점). 10월 17일 OpenCode가 X에 공지를 올렸어요. 대규모 증류(distillation) 공격과 관련된 보안 침해로 OpenCode Console 사용자의 1.4%가 영향을 받았고 해당 사용자 모두에게 메일로 알렸다는 내용이에요. HN 토론에는 받은 안내 메일이라며 ‘워크스페이스에 저장한 OpenAI, Anthropic 같은 외부 서비스의 API 키가 노출됐을 수 있으니 폐기하고 새로 발급하라’는 문장이 올라왔어요.
격리와 모니터링의 실패(HN 950점). 7월 이후 여러 AI 회사가 ‘모델이 허가 없이 외부 시스템에 접근했다’고 밝혔어요. CSO Online은 이 사례들을 모아 다뤘어요. 기사에 나온 보안 전문가들은 에이전트가 똑똑해서가 아니라 샌드박스나 외부 통신 제한 같은 오래된 보안 관행을 지키지 않아서 생긴 일이라고 봤어요.
데몬 이슈 본문에 적힌 끄는 방법은 아래와 같아요. 글쓴이에 따르면 데몬을 멈춰도 업데이트 프로세스는 남아 있어서 따로 끝내야 했대요.
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop' # not stopped by `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon세 이야기는 결국 에이전트에게 권한을 얼마나 주느냐로 이어져요. 에이전트에게 쥐여 주는 API 키를 꼭 필요한 범위로만 만들어 두면 새어 나가도 그 키로 할 수 있는 일이 많지 않아요. 뒤에서 도는 프로세스는 언제 무엇을 하는지 드러나야 하고요. 격리와 모니터링 같은 오래된 보안 기본기가 에이전트에도 그대로 통해요.
에이전트에게 남기는 것
Kevin Liao는 「Agents don’t need memory, they need documentation」에서 대화 기록을 벡터 DB에 쌓아 두는 ‘기억’ 대신 문서를 남기라고 해요(HN 392점). 유사도 검색으로는 무엇이 맞고 무엇이 최신인지 가릴 수 없다는 거예요. 문서에는 코드에 드러나지 않는 요구 사항, 결정, 제약만 적으라고 해요. 내용이 낡으면 뒤에 덧붙이지 말고 고쳐 쓰라고 권해요.
이 블로그 저장소도 비슷하게 꾸려 왔어요. 저장소 맨 위의 CLAUDE.md와 docs/DESIGN.md에는 바꾸면 안 되는 규칙과 그 근거를 적어 두었어요. 규칙 상당수에는 어기면 실패하는 테스트도 붙어 있어요. 문서를 믿기만 하지 않고 테스트로 확인하는 거예요. Karpathy의 말을 빌리면 일을 검증할 수 있는 쪽으로 옮겨 두는 셈이에요.
깔때기 어디에 서 있든 해 볼 일은 비슷해 보여요. 맡긴 일의 결과를 확인할 방법을 먼저 만들어요. 에이전트에게 주는 권한은 좁게 잡아요. 그리고 알아낸 것은 문서로 남겨요.
참고한 글 (숫자는 2026년 10월 19일 기준)
Andrej Karpathy, X 게시물 · 좋아요 43,406 · 조회 662만 · HN 728점
Mercor, Benchmark Map · HN 624점
Rich Hickey, ‘AI’ Is Not a Tool · HN 318점
Huahai, AI is a tool and using it well takes skill · HN 805점
Anthropic, Redesigning source control at Anthropic · HN 894점
openai/codex 이슈 #48195 · HN 609점
CSO Online, 격리와 모니터링 실패를 다룬 기사 · HN 950점
Kevin Liao, Agents don’t need memory, they need documentation · HN 392점