프롤로그: 초당 200줄, 그리고 멈춰버린 사람
2026년의 어느 평범한 오후. 당신은 터미널에 한 문장을 친다.
"결제 실패 시 3회까지 지수 백오프로 재시도하고, 실패하면 데드레터 큐로 보내줘."
30초 뒤, AI 에이전트는 새 파일 4개, 수정 12군데, 테스트 9개를 만들어 냈다. 테스트는 전부 초록불이다. 에이전트는 스스로 만든 코드를 실행해 보고, 엣지 케이스를 찾아 고치고, 다시 돌려 확인까지 했다. 완벽해 보인다.
당신은 "Merge" 버튼 위에 커서를 올린다. 그리고 문득 손이 멈춘다.
…이 재시도 로직, 지금 어디서 트랜잭션을 잡고 있지? 백오프 간격은 누가 정했더라? 데드레터 큐가 꽉 차면 어떻게 되는 거였지?
모른다. 방금 만들어졌는데, 당신은 그것을 모른다.

이 장면이 바로 소프트웨어 개발자 제프리 리트(Geoffrey Litt) 가 2026년 7월 2일 발표한 에세이 「Understanding is the new bottleneck」(이해가 새로운 병목이다)의 출발점이다. 리트는 MIT 미디어랩 출신으로, "AI는 사람을 대체하는 자동화가 아니라 사람을 증강하는 도구여야 한다"는 주장을 오래 해 온 연구자다. 이 짧은 글은 발표되자마자 개발자 커뮤니티를 크게 흔들었다.
그가 던진 질문은 단순하지만 아프다.
AI가 코드를 아무리 빨리, 아무리 정확히 짜도 — 그것을 만든 사람이 더 이상 이해하지 못한다면, 우리는 무엇을 잃는가?
이 글은 그 질문을 처음부터 끝까지 따라간다. 용어가 낯설어도 괜찮다. 그림과 사례로, 하나씩 천천히.
1장: 병목은 어디로 갔나 — 생성 → 검증 → 이해
↓
2장: 왜 이해하는가 — '검증'과 '참여'는 다르다
↓
3장: 갚지 않은 빚 — 인지 부채(cognitive debt)
↓
4장: 50년 된 꿈 — 케이, 페퍼트, 그리고 매쓰랜드
↓
5장: 세 가지 무기 — 설명서·마이크로월드·공유 공간
↓
6장: 2026 현장 — 바이브코딩의 청구서
↓
7장: 루프 밖이 아니라, 더 깊이 루프 안으로
1장: 병목은 어디로 갔나
병목(bottleneck)이라는 말
먼저 단어부터. 병목은 병(bottle)의 목(neck)이다. 병을 아무리 크게 만들어도, 물이 나오는 속도는 결국 가장 좁은 목이 정한다. 시스템 전체의 속도는 가장 느린 한 지점이 결정한다 — 이걸 엔지니어들은 병목이라 부른다.
소프트웨어를 만드는 과정을 아주 거칠게 셋으로 나눠 보자.
① 생성
아이디어를 실제 코드로 옮긴다. 타이핑, 문법, 보일러플레이트.
② 검증
이 코드가 맞는지 확인한다. 테스트, 리뷰, 디버깅.
③ 이해
이게 무엇을, 왜, 어떻게 하는지 머릿속에 담는다.
수십 년 동안 병목은 압도적으로 ①생성이었다. 아이디어는 많은데 손이 느렸다. 그래서 우리는 더 좋은 언어, 프레임워크, IDE, 자동완성, 스택오버플로를 만들어 생성 속도를 끌어올렸다.
그리고 2024~2026년, 생성 병목은 사실상 사라졌다. AI 에이전트는 사람보다 수십 배 빠르게, 지치지 않고 코드를 쏟아 낸다. 병목이 뚫리면, 물은 그다음으로 좁은 목으로 몰린다.

그럼 다음 병목은 '검증'일까?
자연스러운 예상은 ②검증이다. 코드가 이렇게 많이 쏟아지면, 사람이 일일이 검토하다 지쳐 나가떨어질 테니까. 실제로 많은 사람이 "이제 개발자는 AI가 짠 코드를 리뷰하는 사람이 된다"고 말한다.
그런데 리트의 관찰은 여기서 방향을 튼다. 그는 이렇게 쓴다.
"에이전트는 자기 작업을 스스로 검증하는 일에 점점 더 능숙해지고 있다."
에이전트는 테스트를 짜서 돌리고, 실패를 보고 고치고, 타입 체크와 린트를 통과시키고, 심지어 스스로 만든 코드를 실행해 결과를 눈으로 확인한다. 즉 검증조차 점점 자동화되고 있다. 그러니 검증도 영원한 병목은 아니다.
병목은 한 칸 더 밀려 ③이해에 도착한다. 그리고 이해는 — 지금으로선 — 자동화할 수 없다. 왜냐하면 이해는 에이전트가 아니라 당신의 머릿속에서 일어나야 하는 일이기 때문이다.
생성은 공짜가 됐다. 검증은 자동화되는 중이다. 그런데 사람의 이해는 여전히 사람의 속도로만 자란다 — 그래서 이해가 새로운 병목이다.
여기서 많은 사람이 자연스럽게 반문한다. "그래서 뭐? 이해까지 굳이 사람이 해야 하나? 어차피 AI가 다 하는데." 리트의 진짜 통찰은 바로 이 반문에 대한 답에 있다. 2장으로 가자.
2장: 왜 이해하는가 — '검증'과 '참여'는 다르다
리트가 이 에세이에서 던지는 가장 핵심적인 구분은 이것이다. 우리가 코드를 이해하려는 이유에는 두 가지가 있는데, 사람들이 이 둘을 자꾸 섞는다는 것이다.
| 이해하는 이유 ① | 이해하는 이유 ② |
|---|
| 검증(verify)하기 위해 | 참여(participate)하기 위해 |
| 이 코드가 맞나? 버그는 없나? 내보내도 되나? | 다음 아이디어는 뭐지? 여기서 뭘 더 할 수 있지? |
| 문지기(gatekeeper)의 시선 — 통과/반려 | 창작자(participant)의 시선 — 다음 수(手) |
| AI가 점점 대신해 줌 | AI가 대신해 줄 수 없음 |

문지기 vs 창작자
검증만 생각하면, 이해는 점점 불필요해 보인다. AI가 스스로 검증을 잘하게 될수록, 사람이 코드를 붙잡고 이해할 이유가 줄어드니까. 이 논리를 끝까지 밀면 결론은 하나다 — "사람은 루프에서 빠져라(take the human out of the loop)."
하지만 리트는 말한다. 프로젝트는 한 번의 명령으로 끝나지 않는다.
"하나의 프로젝트는 에이전트와 함께 도는 수많은, 아주 많은 루프다."
그리고 결정적인 문장.
"당신이 시스템에 대해 가진 이해는, 다음 아이디어를 떠올리는 당신의 능력의 일부다."
이 말을 곱씹어 보자. 오늘 만든 재시도 로직을 당신이 이해하고 있다면, 내일 당신은 "아, 여기 백오프에 지터(jitter)를 넣으면 천둥 무리(thundering herd)를 막겠는데?" 하고 다음 아이디어를 떠올릴 수 있다. 하지만 그 코드가 당신에게 블랙박스라면, 당신은 다음 수를 둘 수 없다. 그냥 또 "알아서 잘 고쳐줘"라고 빌 수밖에 없다.
✋
문제 — 이해를 '검증'으로만 보면
AI가 검증을 잘할수록 사람은 이해할 이유를 잃는다. 결국 사람은 루프 밖으로 밀려나고, 시스템은 아무도 이해하지 못하는 블랙박스가 된다.
💡
전환 — 이해를 '참여'로 보면
이해는 검증용 도구가 아니라, 다음 창작을 위한 연료다. 시스템을 이해하는 만큼 다음 아이디어를 낼 수 있다.
🚀
결과 — 목표가 바뀐다
사람을 루프에서 빼는 게 목표가 아니다. 사람을 더 깊이 루프 안에 두는 게 목표다. "핵심은 언제나 자동화가 아니라 증강이었다."
이 구분이 왜 중요한지, 코어닷투데이는 이미 다른 각도에서 다룬 적이 있다. 「버그를 찾겠다는 착각: 코드 리뷰의 진짜 목적」에서 우리는 코드 리뷰의 본질이 버그 사냥이 아니라 '이해할 수 있는 코드인가'를 확인하는 것이라고 봤다. 리트의 이번 글은 그 이야기의 미래편이다. 리뷰의 시대엔 "사람이 이해할 수 있게 코드를 짜자"였다면, 에이전트의 시대엔 "사람이 이해하도록 도구를 짜자"로 무대가 옮겨간다.
3장: 갚지 않은 빚 — 인지 부채(cognitive debt)
이해를 잃으면 정확히 무슨 일이 벌어질까? 이걸 가장 날카롭게 개념화한 사람이 마거릿앤 스토리(Margaret-Anne Storey) — 캐나다 빅토리아 대학의 소프트웨어 공학 교수다. 그는 개발자 생산성과 "사람 요인"을 30년간 연구해 왔다.
당신은 아마 기술 부채(technical debt) 라는 말을 들어봤을 것이다. 지금 급하니까 대충 짜 두고 "나중에 고치자" 하고 넘긴 코드 — 그 미뤄둔 정리 비용이 이자처럼 불어나 결국 발목을 잡는다는 비유다.
스토리는 2026년, AI 시대에 맞춰 이 비유를 확장한다. 그의 「Triple Debt Model(삼중 부채 모델)」은 소프트웨어의 건강을 세 종류의 빚으로 본다.
| 기술 부채 | 인지 부채 | 의도 부채 |
|---|
| technical debt | cognitive debt | intent debt |
| 어디에 쌓이나: 코드 안에 | 어디에 쌓이나: 사람 안에 | 어디에 쌓이나: 문서·기록 안에 |
| 지저분하고 얽힌 코드 | 팀이 시스템을 이해하지 못함 | "왜 이렇게 만들었는지" 기록이 없음 |
스토리의 핵심 경고는 이렇다. AI가 코드를 잘 짜줄수록, 가장 큰 위험은 기술 부채에서 인지 부채로 옮겨간다. 코드는 깔끔한데, 그걸 이해하는 사람이 팀에 아무도 없는 상태. 겉보기엔 멀쩡한데 아무도 운전대를 잡을 줄 모르는 자동차다.
스토리의 결론: AI 시대에 잘 살아남는 팀은 "이해(understanding)와 의도(intent)를, 코드 품질만큼이나 의식적으로 관리하는 팀" 이 될 것이다.
이 개념은 개발자 사회에 빠르게 퍼졌다. 개발자이자 유명 블로거인 사이먼 윌리슨(Simon Willison)도 이 주제를 정면으로 다뤘고, 여러 엔지니어링 조직이 "인지 부채"를 실제 관리 지표로 논의하기 시작했다.
· 6개월 전 AI로 짠 모듈을 아무도 설명하지 못한다.
· 버그가 나면 "고쳐줘"라고 다시 AI에게 비는 것 외엔 방법이 없다.
· 신규 입사자가 코드를 읽어도 "왜 이렇게 됐는지"를 물을 사람이 없다.
· 온보딩·핸드오버가 무너진다 — 인수인계할 이해 자체가 없으니까.
코어닷투데이가 앞서 다룬 「그 코드를 아는 마지막 사람들」이나 「자기진화 에이전트와 역량의 침식」이 바로 이 부채가 쌓였을 때의 풍경이다. 그렇다면 이 빚을 어떻게 갚을까? 리트의 답은 놀랍게도 50년 전의 꿈에서 시작한다.
4장: 50년 된 꿈 — 케이, 페퍼트, 그리고 매쓰랜드
리트가 제안하는 해법의 뿌리는 최신 AI가 아니라 1970년대에 있다. 그는 두 명의 거인을 소환한다.
앨런 케이 — "컴퓨터는 계산기가 아니라 매체다"
앨런 케이(Alan Kay) 는 개인용 컴퓨터와 그래픽 인터페이스의 아버지 중 한 명이다. 그는 50년 전, 대부분이 컴퓨터를 "빠른 계산기"로 볼 때 전혀 다른 미래를 그렸다. 컴퓨터는 생각을 담고 나누는 매체(medium) 이며, 무엇보다 배움을 위한 매체라는 것이다.
케이가 즐겨 든 예가 있다. 아이가 물리학 교과서에서 중력 공식을 외우는 대신, 화면 속 시뮬레이션에서 행성을 직접 던져 보고, 중력 상수를 손으로 바꿔 궤도가 어떻게 달라지는지 가지고 놀며 배우는 것. 공식을 읽는 게 아니라, 공식이 사는 세계에 들어가 사는 것.
시모어 페퍼트 — "매쓰랜드에서 살기"
이 아이디어를 교육으로 밀어붙인 사람이 시모어 페퍼트(Seymour Papert) 다. 그는 유명한 비유를 남겼다. 프랑스어를 배우는 가장 좋은 방법은 문법책을 외우는 게 아니라 프랑스에 가서 사는 것이다. 그렇다면 수학을 배우는 가장 좋은 방법은?
"수학의 나라, 매쓰랜드(Mathland)에서 사는 것."
수학이 자연스럽게 쓰이는 세계에 몸을 담그면, 수학은 외울 대상이 아니라 그냥 그 세계의 말이 된다. 페퍼트는 아이들이 거북이(turtle)에게 명령해 그림을 그리는 Logo 언어를 만들어 이 철학을 실현했다.

그런데 왜 지금, 이 50년 된 꿈인가?
여기가 리트의 반전이다. 케이와 페퍼트의 꿈은 아름다웠지만, 한 가지 문제가 있었다. 그런 인터랙티브 학습 세계를 하나 만드는 데 엄청난 노력이 들었다. 시뮬레이션 하나, 인터랙티브 도표 하나를 손으로 코딩하려면 며칠이 걸린다. 그래서 이 꿈은 소수의 명작(예: 물리 시뮬레이션 교육 사이트)에만 머물렀다.
그런데 2026년, 판이 바뀌었다. 리트는 짜릿한 한 문장으로 이를 표현한다.
"에이전트는 우리 인간이 다른 코드를 이해하도록 돕는 코드를 짜 줄 수 있다."
즉, AI가 이제 그 '이해를 돕는 세계'를 즉석에서 값싸게 만들어 준다. 케이의 꿈을 가로막던 "제작 비용"이라는 벽이 무너진 것이다. 이 깨달음 위에서 리트는 세 가지 구체적 무기를 제시한다. 5장의 본론이다.
5장: 세 가지 무기 — 설명서·마이크로월드·공유 공간
무기 ①: 코드 설명서와 '퀴즈 속도조절기'
리트는 /explain-diff라는 자신만의 도구(스킬)를 만들었다. 에이전트가 코드를 바꾸면, 이 도구가 그 변경을 가르치듯 설명하는 문서를 자동 생성한다. 평범한 diff와는 완전히 다르다.
| 평범한 diff | /explain-diff의 설명서 |
|---|
| 파일 이름 알파벳순으로 나열 | 이야기 순서(내러티브)로 재배열 |
| +빨강 −초록 줄만 보여줌 | 바꾸기 전에 필요한 배경 지식부터 깔아줌 |
| "무엇을 바꿨나" | "왜, 어떤 직관으로 바꿨나" + 인터랙티브 도해 |
| 읽고 나면 남는 게 없음 | 끝에 퀴즈가 있어 이해를 확인 |
여기서 가장 흥미로운 건 퀴즈다. 리트는 이 아이디어를 앤디 마투셰크(Andy Matuschak) 와 마이클 닐슨(Michael Nielsen) 의 작업에서 가져왔다. 두 사람은 Quantum Country라는 프로젝트에서, 양자컴퓨팅을 설명하는 글 본문 사이사이에 복습 퀴즈를 심는 실험을 했다. 이 퀴즈는 간격 반복(spaced repetition) — 잊어버릴 때쯤 다시 물어봐서 기억을 장기 기억으로 굳히는 학습법 — 을 따른다.
리트는 이 교육 기법을 코드 이해에 그대로 가져왔다. 그리고 여기서 그의 가장 유명한 표현이 나온다.
"나는 퀴즈를 통과하기 전까지는 그 코드를 남에게 보내지 않는다."
"퀴즈는 속도 조절기(speed regulator)다."
이 문장이 왜 천재적인가? AI 루프는 사람보다 훨씬 빠르게 돈다. 그냥 두면 AI는 당신의 이해를 저만치 앞질러 달아나 버린다 — 인지 부채가 순식간에 쌓이는 것이다. 그런데 "퀴즈를 통과해야 코드를 내보낼 수 있다"는 규칙을 걸면, AI의 속도가 사람의 이해 속도에 묶인다. 퀴즈가 브레이크가 아니라 속도조절기인 이유다 — 멈추는 게 아니라, 따라올 수 있는 속도로 맞춰 주는 것.

백문이 불여일견. 아래에서 당신이 직접 이해 게이트를 통과해 보자. AI 에이전트가 방금 만든 변경을 읽고, 퀴즈 3문제를 맞혀야 "코드 내보내기"가 열린다. 마지막 문제는 검증이 아니라 참여를 묻는다 — 이해했다면, 다음 수를 둘 수 있어야 하니까.
어떤가? 세 번째 문제에서 잠깐 멈칫했다면, 그게 바로 리트가 말한 "참여를 위한 이해" 다. 단순히 "이 코드 맞아?"를 넘어, "그래서 다음엔 뭘 하지?"에 답할 수 있을 때 비로소 당신은 루프 안에 있는 것이다.
무기 ②: 마이크로월드(micro-world)
두 번째 무기는 페퍼트의 "매쓰랜드"를 코드에 적용한 것이다. 시스템의 동작을 읽는 대신, 그 동작을 체험하는 작은 인터랙티브 세계를 만드는 것.
리트가 든 실제 사례 둘.
프롤로그 디버거
Prolog 인터프리터의 실행을 한 스텝씩 눈으로 따라가며 밟아 보는 도구. 논리가 어떻게 풀려나가는지 '읽지' 않고 '본다'.
마이그레이션 관제탑
프레임워크를 갈아엎는 작업에서, 옛 사이트와 새 사이트를 나란히 띄워 놓고 변경이 반영될 때마다 실시간으로 비교하는 '커맨드 센터'.

리트가 남긴 인상적인 고백이 하나 있다. 그는 어떤 작업에서 AI에게 코드를 통째로 맡기는 대신, AI로 커스텀 디버거 UI를 만들었다. 그랬더니 "코딩을 직접 하는 게 더 재미있어졌다"는 것이다.
🤖
흔한 길
AI가 코드를 다 짜고, 사람은 구경만 한다 → 재미없고, 이해도 안 남는다.
🔬
리트의 길
AI에게 이해를 돕는 도구(디버거·마이크로월드)를 짜게 하고, 코딩은 내가 한다.
🎮
결과
이해가 남고, 다음 아이디어가 떠오르고, 무엇보다 일이 다시 재미있어진다.
무기 ③: 공유 공간(shared spaces)
이해는 개인만의 문제가 아니다. 3장의 인지 부채가 팀의 부채였음을 떠올리자. 리트의 세 번째 무기는 사람과 에이전트가 투명하게 함께 일하는 공유 공간(그는 Notion 같은 협업 도구를 예로 든다)이다.
에이전트가 무엇을 왜 했는지가 팀 모두가 보는 공간에 남으면, 팀은 공유된 정신 모형(shared mental model) 을 갖게 된다. 같은 그림을 머릿속에 공유하면 소통이 빨라진다 — "그거 있잖아, 그거" 한마디로 통하는 팀처럼. 이것은 스토리가 말한 "의도 부채(intent debt)"를 갚는 방법이기도 하다. 왜 그렇게 만들었는지가 공유 공간에 살아 있으니까.
① 설명서 + 퀴즈
개인의 이해를 지킨다
→
② 마이크로월드
체험으로 직관을 준다
→
③ 공유 공간
팀의 이해를 잇는다
6장: 2026 현장 — 바이브코딩의 청구서
이 논의는 상아탑의 이야기가 아니다. 2026년 현재, 인지 부채의 청구서는 이미 날아오고 있다.
바이브코딩의 그림자
"느낌대로 프롬프트만 던져 앱을 만든다"는 바이브코딩(vibe coding) 이 폭발하면서, 이해 없는 코드가 대량 생산됐다. 코어닷투데이가 다룬 「바이브코딩 호러 스토리」의 풍경이 그것이다 — 잘 돌아가던 앱이 어느 날 무너지는데, 만든 사람조차 어디서부터 봐야 할지 모른다. 코드는 있지만 이해는 처음부터 없었던 것이다.
리뷰 자동화라는 흐름
동시에 검증 쪽은 빠르게 자동화되는 중이다. GitHub의 코드 리뷰 봇, Cursor의 Bugbot, Vercel Agent, CodeRabbit 같은 도구들이 PR마다 버그를 자동으로 짚어 준다. 리트의 "검증은 에이전트가 점점 잘한다"는 관찰이 현실로 나타나는 지점이다. 이는 역설적으로 리트의 논지를 강화한다 — 검증이 자동화될수록, 사람에게 남는 유일하게 대체 불가능한 일은 '이해(참여)'가 된다.
측정과 관리의 대상이 되다
가장 흥미로운 변화는, "이해"가 이제 관리 지표로 논의되기 시작했다는 것이다. 개발자 생산성 분석 회사들이 인지 부채를 실제 조직 건강 지표로 다루고, 리트의 "퀴즈 = 속도조절기" 같은 장치가 워크플로에 들어온다. 코어닷투데이가 정리한 「AI 코딩을 잘못 재는 열두 가지 방법」의 문제의식과도 맞닿는다 — 짠 코드의 양이 아니라, 팀이 그것을 얼마나 이해하고 통제하는지가 진짜 지표라는 것.
※ 세 활동의 '자동화·해결 정도'를 개념적으로 표현한 그림. 정밀 수치가 아니라 병목의 이동을 보여주기 위한 도식이다.
7장: 루프 밖이 아니라, 더 깊이 루프 안으로
이 글을 관통하는 두 개의 세계관이 있다. 하나는 이렇게 말한다.
"AI가 다 하니까, 사람은 루프에서 빠져라."
리트는 정반대를 말한다.
"우리는 그저 우리 자신을 루프에서 빼낼 필요가 없다. 우리는 오히려 더 깊이 루프 안으로 들어갈 수 있다."
이 차이는 도구를 어떻게 쓰느냐의 문제다. 같은 AI라도, 이해를 뺏는 방식으로 쓰면 사람을 밀어내고, 이해를 돕는 방식으로 쓰면 사람을 더 깊이 끌어들인다. 리트의 마지막 문장은 희망적이다.
"올바른 도구를 만든다면, 우리는 지금 그 어느 때보다 세계를 더 잘 이해할 수 있다."

그래서, 무엇을 할 것인가
거창한 결론 대신 내일 당장 해볼 수 있는 것들로 마무리하자.
읽지 말고 물어라
AI가 코드를 짜면 "설명해줘"에서 멈추지 말고, "내가 이걸 이해했는지 퀴즈 내줘"라고 해보라. 리트의 속도조절기를 공짜로 얻는다.
도구를 짜게 하라
"이 시스템 고쳐줘"만 시키지 말고, "이 시스템을 내가 이해하게 도와주는 작은 시각화/디버거를 만들어줘"를 시켜보라. 마이크로월드는 생각보다 싸다.
이해를 팀에 남겨라
에이전트가 무엇을 왜 했는지 공유 공간에 남겨, 인지 부채·의도 부채를 갚아라. 이해는 개인이 아니라 팀의 자산이다.
생성이 공짜가 된 시대의 역설은 이것이다. 코드가 흔해질수록, 이해는 귀해진다. 그리고 이해는 자동화되지 않는다 — 그것은 당신의 머릿속에서, 당신의 속도로만 자란다. 리트가 우리에게 남긴 건 위기감이 아니라 초대장이다.
사람을 루프에서 빼는 게 아니라, 사람을 더 깊이 루프 안으로.
그것이, AI가 코드를 다 짜는 시대에 인간에게 남은 — 그리고 인간만이 할 수 있는 — 진짜 일이다.
더 읽을거리 (코어닷투데이)
- 버그를 찾겠다는 착각: 코드 리뷰의 진짜 목적, 1976에서 2026까지 — 이 글의 '과거편'. 리뷰의 본질은 버그가 아니라 이해다.
- 그 코드를 아는 마지막 사람들 — 이해가 사라진 시스템의 풍경.
- 자기진화 에이전트와 역량의 침식 — 사람이 루프 밖으로 밀려날 때.
- 바이브코딩 호러 스토리 — 이해 없이 만든 코드의 청구서.
- AI 코딩을 잘못 재는 열두 가지 방법 — 양이 아니라 이해가 지표다.
원문 및 출처