원본 글 : https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck
원본 Youtube : https://www.youtube.com/watch?v=WkBPX-oDMnA
Notion의 디자인 엔지니어 Geoffrey Litt가 2026년 7월 AI Engineer 컨퍼런스(AI Engineer World’s Fair)에서 발표한 “Understanding is the new bottleneck”입니다. 무척 좋은 내용이라서 요약해서 공유드립니다.
AI 코딩의 병목은 이제 ‘정확성’이 아니라 ‘인간의 이해’다.
- 왜 이해해야 하는가 — 검증(verify)에서 참여(participate)로
에이전트가 쏟아내는 코드를 사람이 따라잡기 어려워진 상황에서, 흔한 답은 “인간의 역할은 검증”이라는 것입니다. 그런데 Litt는 이 답이 틀렸다고 봅니다. 에이전트는 스스로의 작업을 검증하는 능력이 점점 좋아지고 있어서, 검증만을 이유로 삼으면 인간이 설 자리가 사라지기 때문입니다.
진짜 이유는 참여입니다. 프로젝트는 한 번의 루프가 아니라 에이전트와의 수많은 반복 루프이고, 시스템에 대한 이해가 곧 “다음 아이디어”를 떠올리는 능력의 일부입니다. 머릿속에 풍부한 개념 구조가 있어야 창의적으로 다음 방향을 제시할 수 있고, 그게 없으면 참여 능력 자체가 제한됩니다.
이해 없이 넘어가는 것의 대가가 인지 부채(cognitive debt)입니다. Margaret Storey가 제시하고 Simon Willison이 확산시킨 개념으로, 기술 부채처럼 단기적으로는 괜찮아 보여도 결국 발목을 잡습니다. Litt 본인도 장시간 바이브 코딩 중 “지금 무슨 일이 벌어지는지 전혀 모르겠다”는 순간을 겪으며 이 문제를 절감했다고 합니다.
그렇다면 어떻게 이해를 만들 것인가? Litt의 답은 “이해를 전달하는 문제를 가장 오래 고민해온 분야인 교육에서 아이디어를 훔쳐오자”입니다. - 기법 1 – 설명 문서 (explain-diff)
에이전트가 작업을 마칠 때마다 “최고의 설명이라면 어떤 모습일까”를 묻고, 이를 자동화한 것이 그가 매일 쓰는 /explain-diff 스킬입니다(GitHub gist로 공개, HTML, Notion 페이지 출력 2종). 원칙은 다음과 같습니다.
– 배경 지식 먼저: 무엇이 바뀌었는지에 앞서서, 원래 시스템(예: 게임 엔진)이 어떻게 동작하는지부터 가르친다.
– 직관 우선: 코드 보다 먼저 목표를 먼저 제시(“2D 드로잉 트릭으로 정원을 3D처럼 보이게”)하고 아이소메트릭 투영 같은 관련 개념을 설명한다.
– 인터랙티브 그림: Notion이 최근 출시한 HTML 임베드 기능으로, 바위를 직접 드래그하며 좌표가 어떻게 변하는지 체험하는 시뮬레이션을 문서에 넣는다.
– 문해적 diff(literate diff): 알파벳 순 파일 나열이 아니라, 산문처럼 합리적 순서로 변경사항을 걸어가며 설명하는 방식이 원시 diff보다 리뷰가 빠르다.
그는 이 설명 문서를 프린트해서 카페에 가져가 읽기도 하는데, “AI가 인터랙티브한 활동을 깊이 집중할 수 있는 종이 리포트로 바꿔준다”는 아이러니를 언급합니다. - 기법 2 – 퀴즈 : 이해의 속도 조절기
읽었다고 이해한 건 아니라는 문제가 남습니다. Andy Matuschak의 “books don’t work” 논의와, 에세이에 간격 반복 퀴즈를 심은 Quantum Country 작업에서 영감을 받아, 설명 문서 하단에 변경사항에 대한 5문항 퀴즈를 붙입니다. 그의 규칙은 “퀴즈를 통과하기 전엔 남에게 코드를 보내지 않는다”이며, 남의 코드를 리뷰할 때도 동일하게 적용합니다.
퀴즈의 본질은 속도 조절기(speed regulator)입니다. AI 루프는 인간의 이해 속도보다 빨리 돌기 쉬운데, 퀴즈가 “내가 정말 이해했나?”를 기계적으로 묻는 견제 장치가 되어 창의적 참여자로 남게 해준다는 것입니다. - 기법 3 – 마이크로월드 : Papert의 ‘Mathland’
교육자 Seymour Papert의 “수학을 배우려면 수학 나라에 살아라(프랑스어를 배우려면 프랑스에 살듯)”라는 아이디어를 코드에 적용해, 시스템 안에 ‘거주하며’ 자연스럽게 직관을 얻는 환경을 만듭니다. 두 가지 실제 사례:
– Prolog 인터프리터 디버거: 실행을 타임라인으로 스크럽하며 각 단계의 스택과 평가되는 규칙을 시각화하는 디버거를 에이전트와 함께 제작. 핵심은 “에이전트가 대신 디버깅하게 두는 것”과 “내가 쓸 도구를 만들어 직접 디버깅하는 것”의 차이 — 후자가 이해를 만든다는 점입니다.
– 웹사이트 마이그레이션 커맨드 센터: Claude가 짜준 마이그레이션 스크립트는 새 프레임워크를 몰라 리뷰가 불가능했기에, 버튼을 눌러 단계별로 포팅을 직접 실행하면서 구/신 사이트를 나란히 보고 파일 트리 변화를 관찰하는 ‘비디오 게임’ 형태의 UI를 만들게 함. 손으로 직접 한 것과 비슷한 이해를 훨씬 빠르게 얻었다고 합니다.
결론: “에이전트는 인간이 다른 코드를 이해하도록 돕는 코드를 쓸 수 있다” — 출시용 소프트웨어가 아니라 나를 위한 일회용 이해 도구를 만드는 것이 핵심입니다. - 기법 4 – 공유 공간 : 팀의 집단적 이해
팀원들이 같은 멘탈 모델을 공유하면 같은 이미지를 떠올리게 하는 공유 어휘로 효율적으로 소통하고 창의적으로 발전시킬 수 있습니다. 최근 Notion에서 Claude와 Cursor 에이전트를 직접 실행할 수 있게 됐고, 에이전트가 세운 기술 계획이 기본적으로 협업 페이지에 생성되므로 팀이 즉시 코멘트하고 토론하며 “혼자가 아니라 함께 생각”하게 된다는 것입니다. - 결론 – 원래 목적은 ‘증강’이었다
50년 전 Alan Kay는 컴퓨터가 책보다 나은, 사람들(특히 아이들)에게 세상을 사고하는 법을 가르치는 새로운 매체가 될 것이라 봤습니다. 그의 유명한 그림 속 아이들은 아이패드로 유튜브를 보는 게 아니라, 인터랙티브 게임을 플레이하면서 그 코드를 직접 수정하며 물리를 배우고 있습니다.
컴퓨터의 목적은 언제나 자동화가 아닌 증강(augment)이었고, AI가 시뮬레이션 제작을 누구에게나 가능하게 만든 지금이야말로 그 비전을 실현할 때라는 것. 올바른 도구를 만들면 우리는 그 어느 때보다 세상을 잘 이해할 수 있으며, 루프에서 빠져나오는 게 아니라 더 깊이 들어갈 수도 있다는 낙관으로 마무리합니다.