One-link learning document · 2026-07-16
AI가 코드를 더 빨리 쓰는 시대, 인간은 왜 여전히 이해해야 하는가. Geoffrey Litt의 발표를 학습 순서, 전수 요약, 12개 주장군 팩트체크, 구조 보존 한국어 완역으로 재구성했다.
AI 에이전트가 코드를 인간보다 빠르게 만들고 스스로 검증하는 시대에도, 인간은 왜 시스템을 이해해야 하며 그 이해 속도를 어떻게 높일 수 있을까?
코드 생성 속도 ↑ → 인간의 이해가 병목 → 교육 기법으로 이해 대역폭 ↑.
이해는 마지막에 합격·불합격을 내리는 검수만이 아니라, 다음 아이디어를 만들고 여러 번의 에이전트 루프에 창의적으로 참여하게 하는 작업 기억이자 공동 언어다.
사람이 목표를 주고 AI가 계획·구현·검증한 뒤, 그 결과를 바탕으로 사람이 다음 방향을 정하는 반복 과정. 이 글의 핵심은 프로젝트가 이런 루프 하나가 아니라 수많은 루프로 이루어진다는 데 있다.
diff는 바뀐 줄의 원재료이고, 멘탈 모델은 시스템이 왜 그렇게 움직이는지 설명하는 개념 구조다. 둘의 차이를 알아야 “변경을 읽었다”와 “변경을 이해했다”를 구분할 수 있다.
Geoffrey Litt의 중심 주장은 단순하다. 에이전트가 만드는 코드를 인간이 이해해야 하는 가장 깊은 이유는 오류를 잡기 위해서만이 아니라, 시스템의 다음 모습을 상상하고 만드는 과정에 계속 참여하기 위해서다. 따라서 새 병목은 코드 생산이 아니라 인간이 개념을 흡수하는 속도이며, 해결책은 교육의 오래된 발명들을 개발 워크플로에 이식하는 것이다.
이해는 에이전트 작업의 마지막 승인 단계가 아니다. 다음 아이디어를 낳는 입력이며, 여러 번 이어지는 인간–에이전트 루프를 연결하는 상태다.
에이전트가 작업을 끝낼 때마다 그 변경을 가장 잘 가르치는 설명 문서를 만들 기회가 생긴다. 저자의 /explain-diff 스킬은 HTML·Markdown·Notion 문서로 구조화된 코드 설명서를 만든다. 저자는 이를 매일 사용하고 여러 동료도 유용하게 여겼다고 보고하며, 비디오 게임의 시점을 바꾸는 사례에서 다음 순서를 보여 준다.
저자는 퀴즈를 통과하기 전에는 코드를 다른 사람에게 보내지 않고, 타인의 코드를 리뷰할 때도 같은 규칙을 적용한다. 설명서를 먼저 읽되 원시 코드 diff도 끝내 읽는다.
퀴즈는 AI 루프가 인간 이해보다 빨라지는 것을 막는 속도 조절기다. “실제로 이해했는가”를 기계적으로 확인해 속도를 늦추는 대신 다음 루프의 참여 능력을 보존한다.
설명서는 Notion에서 팀과 논의하거나 HTML·Markdown으로 볼 수 있고, 저자는 집중을 위해 출력해 카페에서 읽기도 한다. 대화형 AI가 만든 결과를 정적인 종이 보고서로 깊게 읽는 역설을 의도적으로 활용한다.
마이크로월드는 Seymour Papert의 “Mathland에서 살기”에서 온 발상이다. 프랑스어를 프랑스에서 자연스럽게 익히듯, 호기심에 따라 시스템을 움직이다 보면 작동 원리와 변화를 직관적으로 배우는 작은 환경을 만든다.
내부 실행을 직관화하기 어려웠던 저자는 에이전트와 함께 디버거를 만들었다. 시간을 앞뒤로 훑고, 스택의 내용과 매 단계에서 평가되는 규칙을 보며, “이 규칙을 올바르게 적용했다”는 자기 메모까지 남겼다.
Claude가 만든 일괄 이전 스크립트는 새 프레임워크를 모르는 저자에게 “대충 맞아 보인다”는 검토밖에 허용하지 않았다. 그래서 옛 사이트와 새 사이트를 나란히 띄우고, 버튼을 눌러 단계별 이전을 실행하며 화면 효과와 파일 트리 변화를 보는 “커맨드 센터”형 게임을 만들게 했다.
기법 명명에 관한 주의: 도입부의 실용 목록은 “코드 설명서·퀴즈·마이크로월드”라고 쓰지만, 본문의 공식 세 장은 “설명·마이크로월드·공유 공간”이다. 퀴즈는 설명을 능동 학습으로 바꾸는 하위 기법으로 다뤄진다.
논지는 코드 이해를 넘어선다. 약 50년 전 Alan Kay는 컴퓨터를 책보다 나은 새 학습 매체로 보고, 아이들이 물리 시뮬레이션을 놀면서 코드를 고쳐 세계를 이해하는 미래를 상상했다. 발표 말미의 우주비행사 밈은 “컴퓨터의 본래 요점이 복잡한 개념을 이해시키는 동적 시뮬레이션이었다”는 이 역사적 회귀를 농담으로 압축한다. 저자에게 AI가 시뮬레이션과 맞춤형 학습 도구의 제작 비용을 낮춘 일은 그 비전을 현실화할 기회다.
최종 선택지는 “루프에서 빠질 것인가” 하나가 아니다. 반복 업무를 자동화하면서도 설명서·퀴즈·마이크로월드·공유 공간을 잘 설계하면 인간은 오히려 더 깊이 루프 안으로 들어갈 수 있다. 올바른 도구를 만들 경우 AI가 인간을 세계로부터 멀어지게 하는 대신, 이전보다 더 잘 이해하게 가르칠 수 있다는 것이 저자의 낙관이다.
글 끝의 관련 읽을거리는 같은 결론을 세 방향으로 확장한다. AI HUDs는 인간 정신을 직접 확장하는 비-코파일럿 인터페이스를, AI 생성 디버거 글은 직접 코딩을 더 즐겁고 이해 가능하게 만드는 도구를, Code like a surgeon은 부차 작업을 위임하되 핵심 판단과 개입은 사람이 유지하는 방식을 다룬다.
Claim-by-claim fact-check
발표 이력, 공개 도구, Notion 기능, Papert·Alan Kay의 교육사적 선례는 1차 자료와 일치한다. 퀴즈·공유 멘탈 모델·도메인 이해의 효용도 연구가 방향을 지지한다. 다만 “이해가 새 병목”이라는 핵심은 아직 직접 검증된 일반 법칙이 아니라, 검증된 사실과 저자의 경험을 연결한 설득력 있는 논증이다.
정합성 한줄평: 확인 가능한 고유명사·제품 기능·역사적 인용에는 큰 오류가 없지만, AI 코딩 전반에 대한 인과적 결론은 근거보다 한 단계 앞선다.
사실
공식 AI Engineer World’s Fair 일정에 Geoffrey Litt(당시 Notion Design Engineer)의 Understanding is the new bottleneck 세션이 올라 있다. Simon Willison도 7월 1일 현장에서 이 발표를 봤다고 7월 2일 기록했고, 이후 발표 영상과 스레드를 연결했다.
레퍼런스: AI Engineer World’s Fair 2026 공식 일정 · Simon Willison, “Understand to participate”
부분사실
생산량 증가의 방향은 강하게 뒷받침된다. OpenAI는 2026년 5월 표본 이용자의 70.2%가 사람 기준 1시간 초과로 추정되는 Codex 작업을 적어도 하나 요청했고, 99백분위 내부 이용자는 하루 60시간이 넘는 병렬 에이전트 턴을 만들었다고 보고했다. Anthropic은 약 40만 Claude Code 세션에서 작업 가치와 종단 간 사용이 늘었다고 보고했다. 그러나 두 자료 모두 공급사 관측 자료이며, “인간이 따라가기 어렵다”를 직접 측정한 독립 연구는 아니다.
레퍼런스: OpenAI, “How agents are transforming work” · Anthropic, “Agentic coding and persistent returns to expertise”
부분사실
최신 모델의 코딩·테스트·검증 성능이 이전 버전보다 개선됐다는 개발사 평가와, 에이전트가 테스트·패치·실패 추적을 검사하는 데 실제 쓰인 사례는 있다. 동시에 OpenAI의 2026년 7월 감사는 SWE-Bench Pro 과제 약 30%가 깨졌다고 추정해, 기존 점수만으로 “자기 검증”의 일반적 향상을 단정하기 어렵다는 점도 보여준다. 방향은 맞지만 측정은 아직 불안정하다.
레퍼런스: OpenAI, “Introducing GPT-5.5” · OpenAI, “Separating signal from noise in coding evaluations”
부분사실
약 40만 Claude Code 세션 분석에서 과업 도메인 전문성이 높을수록 검증 가능한 성공률이 높고, 문제 발생 시 회복과 에이전트 조향도 더 좋았다. 이는 “이해가 참여 능력을 증폭한다”는 논지를 지지한다. 다만 관찰 연구이고 전문성 분류에도 모델 판정이 들어가므로, 코드 이해 자체가 창의성을 일으킨다는 인과를 입증한 것은 아니다.
부분사실
Storey는 2026년 2월 이 개념을 기술 부채와 명시적으로 대비했고, Simon Willison은 같은 글을 소개한 뒤 별도 태그와 여러 글로 확산했다. 개념 내용은 정확하다. 다만 용어가 더 이전에도 쓰였음을 Storey 자신이 밝히므로, 두 사람이 ‘유일한 창안자’라는 뜻으로 읽으면 안 된다. 본문의 “popularized”는 합리적이지만 정량적으로 입증하기는 어렵다.
레퍼런스: Margaret-Anne Storey, “How Generative and Agentic AI Shift Concern…” · Simon Willison의 cognitive-debt 태그 아카이브 · Peter Naur, “Programming as Theory Building”
부분사실
/explain-diff 스킬은 배경지식, 직관, 구조화된 ‘literate diff’, 상호작용 도해와 확인 퀴즈를 포함한 HTML 또는 Notion 설명서를 만든다.공개 Gist의 두 변형은 실제로 해당 섹션과 출력 형식을 요구한다. 따라서 도구의 존재와 설계 설명은 확인된다. 반면 “매일 쓴다”, “많은 동료가 가치 있다고 했다”, “원시 diff보다 더 빠르다”는 저자의 경험 보고로, 외부 사용성 평가나 시간 비교 실험은 제시되지 않았다.
부분사실
Roediger와 Karpicke의 두 실험에서는 짧은 5분 지연에는 재학습이 유리했지만, 2일·1주 뒤에는 회상 테스트가 재학습보다 장기 보존을 크게 높였다. Quantum Country도 에세이 속 회상 질문과 간격 반복을 결합한 실제 매체다. 다만 이 결과를 코드 리뷰 정확도·설계 참여·다섯 문항이라는 구체 규칙에 그대로 일반화한 연구는 없으므로 적용 결론은 부분사실이다.
레퍼런스: Roediger & Karpicke (2006), “Test-Enhanced Learning” · Matuschak & Nielsen, Quantum Country · Andy Matuschak, “Why books don’t work”
사실
Mindstorms 도입부가 컴퓨터와의 소통을 “프랑스에 살며 프랑스어를 배우는 것”에 비유하고, 수학 학습의 맥락을 명시적으로 “Mathland”라고 부른다. 본문의 요약은 원전과 정확히 부합한다.
부분사실
실험 연구에서 효과적인 계획이 공유 멘탈 모델을 높였고, 고부하 조건에서 더 효율적인 소통 전략과 향상된 협응 성과로 이어졌다. 다른 연구도 과업·팀 멘탈 모델의 유사성이 팀 과정과 성과에 양의 관련을 보였다. 그러나 주로 시뮬레이션·제한된 과업의 결과여서, Notion 안의 에이전트 협업 전체에 같은 효과가 난다고 단정할 수는 없다.
레퍼런스: Stout et al. (1999), “Planning, Shared Mental Models, and Coordinated Performance” · Mathieu et al. (2000), “The influence of shared mental models…”
사실
Notion의 2026년 7월 1일 공식 릴리스는 Claude와 Cursor를 첫 External Agents로 명시하며, 공유 보드에서 할당·멘션·실행 관찰이 가능하다고 설명한다. 같은 릴리스는 에이전트가 상호작용형 HTML 블록과 퀴즈를 만들 수 있다고 발표했다. 구체 기능 주장은 확인된다.
사실
Kay의 1972년 논문은 잔디밭의 두 아이가 연결된 Dynabook으로 우주 게임을 하다가, 중력을 구현하려고 자기 프로그램을 수정하고 좌표계를 탐색하는 장면을 구체적으로 묘사한다. 1977년 Kay·Goldberg의 Personal Dynamic Media도 시뮬레이션을 Dynabook의 중심 개념으로 두었다. 2026년 기준 각각 54년·49년 전이므로 “50년 전”은 정당한 반올림이다.
레퍼런스: Alan Kay (1972), “A Personal Computer for Children of All Ages” 전사본 · Kay & Goldberg (1977), Personal Dynamic Media
불확실
AI로 맞춤 디버거를 만든 저자의 2024년 사례는 공개돼 있고, 생성 비용이 낮아졌다는 방향도 개연성이 높다. 그러나 “이전 어느 때보다 더 잘 이해”는 측정 가능한 현재 사실보다 미래 전망에 가깝다. 학습 효과, 오개념, 신뢰성, 접근성까지 비교한 증거가 없어 참·거짓 판정은 유보한다.
레퍼런스: Geoffrey Litt, “AI-generated tools can make programming more fun”
도발적인 주장 하나: 저는 우리 에이전트가 작성하는 코드를 이해하는 일이 여전히 중요하다고 생각합니다!
이 발표에서는 왜 그런지 설명하고, 코드를 효율적으로 이해하는 몇 가지 아이디어를 보여드리겠습니다. 자, 시작해 보죠.
에이전트는 우리를 대신해 점점 더 많은 코드를 작성하고 있고, 그 속도를 따라잡기가 갈수록 어려워진다는 사실을 우리 모두 압니다.
하지만 좋은 소식도 있습니다. 코드를 이해하는 방법은 아주 많습니다! diff를 한 줄씩 읽는 것만이 유일한 방법은 아닙니다.
이 발표의 대부분에서는 에이전트가 구축 중인 시스템을 이해할 때 제가 유용하다고 느낀 기법들을 다룹니다.
하지만 먼저 더 근본적인 질문을 던져야 합니다…
왜죠? 왜 이해해야 할까요?
이제 우리는 스스로를 루프 밖으로 빼고 에이전트끼리 루프를 돌게 해야 하는 것 아닌가요? 에이전트가 더 똑똑해질수록 우리가 세부 사항에 관여하는 일은 덜 중요해지는 것 아닌가요?
저는 많은 사람이—이해에 찬성하는 사람들조차도—이 질문에 조금 잘못된 답을 갖고 있다고 생각합니다!
가능한 답 하나는 이렇습니다. 우리는 검증하기 위해 이해합니다. 에이전트의 작업을 확인하고, 그것이 올바른지 살펴봅니다.
‘올바르다’는 말은 여러 뜻일 수 있습니다. 명세와 일치하는가, 아키텍처가 잘 설계됐는가… 하지만 근본적으로는 엄지 올리기 / 엄지 내리기로 답하는 질문입니다.
그런데 말이죠. 에이전트는 자기 작업을 스스로 검증하는 능력이 점점 좋아지고 있습니다. 그리고 이건 좋은 일입니다! 저는 제 에이전트가 실수하지 않을 때가 좋습니다.
하지만, 음. 그렇다면 우리 인간은 어디에 남게 될까요?
바로 여기서 또 다른 답이 나옵니다. 우리는 참여하기 위해 이해할 수 있습니다.
에이전트가 무엇을 하는지 배움으로써 창작 과정의 능동적인 참여자로 남을 수 있습니다. 이것이 중요한 이유는 다음과 같습니다…
루프는 절대 하나로 끝나지 않습니다! 프로젝트는 에이전트와 함께 도는 아주, 아주 많은 루프로 이루어집니다.
그리고 시스템에 대한 여러분의 이해는 그 시스템을 발전시킬 다음 아이디어를 떠올리는 능력의 일부입니다.
무언가를 어떻게 앞으로 나아가게 할지 창의적이고 유창하게 생각하려면 머릿속에 풍부한 개념들이 있어야 합니다. 그 유창함이 부족하면 프로젝트에 참여하는 능력이 실질적으로 제한됩니다.
그런데 이것은 인지 부채라는 개념과도 밀접하게 연결됩니다. 이 개념은 Margaret Storey와 Simon Willison이 널리 알렸습니다.
기술 부채와 비슷합니다. 단기적으로는 무슨 일이 벌어지는지 이해하지 않고도 넘어갈 수 있지만, 결국에는 그 대가를 치르게 됩니다.
좋습니다. 그렇다면 이해가 중요하다는 건 알겠습니다.
하지만 다음 질문이 생깁니다. 어떻게 할까요? AI와 함께 빠르게 일하면서 어떻게 인간의 이해를 쌓을 수 있을까요?
알고 보니 이해를 전달하는 방법을 고민한 사람이 우리가 처음은 아닙니다. 저는 교육에서 영감을 얻을 수 있다고 생각합니다. 교육을 위해 지금까지 발명된 최고의 아이디어들을 가져와 이 문제에 적용할 수 있을까요?
오늘은 우리가 이것을 시도할 방법을 보여주는 세 가지 기법을 공유하려 합니다.
첫 번째는 설명입니다. 좋은 설명은 무엇이 다를까요?
에이전트가 어떤 작업을 마칠 때마다 그것은 설명, 즉 하나의 산출물을 만들 기회입니다.
가장 단순하게는 코드 diff, 곧 변경된 원재료를 읽을 수 있습니다.
하지만 이렇게 물어보면 어떨까요?
최고의 설명이라면 어떤 모습일까요? 인간이든 AI든, 여러분에게 무언가를 제대로 설명하기 위해 세부 사항 하나하나에 정말 공을 들이는 팀이 있다면 어떤 느낌일까요?
여기에 한 가지 답이 있습니다. 저는 /explain-diff라는 스킬을 만들었습니다. 저는 이것을 매일 사용하고, 많은 동료도 유용하다고 느꼈습니다.
이 스킬은 세심하게 구조화된 코드 설명서를 HTML, 마크다운 또는 Notion 문서로 출력합니다. Notion은 팀이 이런 설명서를 함께 다듬고 토론하기 좋은 곳입니다. (고지: 저는 Notion에서 일하므로 편향돼 있습니다.)
비디오 게임의 시점을 수정하는 사례를 통해 이 설명서 안에 무엇이 들어 있는지 살펴봅시다.
첫 번째 원칙: 배경 정보를 가르쳐 달라!
무엇이 바뀌었는지 살펴보기도 전에, 원래 무엇이 있었는지 이해하도록 도와주세요. 이 사례에서는 게임 엔진을 가르쳐 주세요.
두 번째 원칙: 세부 사항보다 직관이 먼저다.
코드가 나오기 전에 “2D 드로잉 기법으로 정원이 3차원처럼 느껴지게 만들기”라는 목표를 밝히고, 아이소메트릭 투영이 무엇인지 같은 관련 개념을 설명합니다.
이 모든 것이 변경의 본질에 대한 제 직관을 길러줍니다. 인간인 제가 이해에서 동등한 참여자가 될 수 있도록 빠진 맥락을 따라잡게 해주는 것입니다.
대화형 도형으로도 직관을 기를 수 있습니다.
여기서는 정원 곳곳으로 바위를 끌어 옮기고 좌표가 움직이는 모습을 보면서 아이소메트릭 시점을 이해하고 있습니다.
(여기에는 Notion이 막 출시한 새 기능을 사용했습니다. 이제 페이지 안에 대화형 HTML을 임베드할 수 있습니다.)
마침내 코드에 도달합니다. 하지만 일반적인 diff는 아무 설명도 없이 알파벳순으로 편집된 파일을 쌓아 놓은 더미입니다.
제가 ‘서술형 diff’라고 부르는 것은 산문처럼 구성됩니다. 합리적인 순서로 변경 사항을 따라가며, 주변 설명과 코드 조각을 함께 삽입합니다. 가공하지 않은 diff보다 더 빨리 검토할 수 있습니다.
이 모든 과정을 거치면 훌륭한 설명서 묶음이 완성됩니다. 저는 여전히 코드 diff도 읽지만, 언제나 이것을 먼저 읽습니다.
가끔은 이것을 인쇄해서 카페로 가져가기도 합니다. 주의를 덜 빼앗기거든요.
아름다울 만큼 역설적입니다. AI가 대화형 활동을 제가 깊이 집중할 수 있는 정적인 종이 보고서로 바꿔줍니다 :)
문제는 딱 하나뿐입니다. 읽기는 힘든 일입니다 😅
Andy Matuschak의 말처럼 “책은 효과가 없습니다”! 실제로 기억하거나 이해하지 못했으면서도 다 읽었다고 스스로를 속이기가 너무 쉽습니다.
이 문제를 어떻게 해결할까요? 저는 Andy와 Michael Nielsen이 연구한 에세이 안에 간격 반복 퀴즈를 삽입하는 방법에서 영감을 얻었습니다.
이제 제 코드 설명서에서도 비슷한 일을 합니다. 설명서 맨 아래에는 변경 사항에 관한 다섯 문제짜리 대화형 퀴즈가 있고, 저는 그 문제에 답하려고 노력합니다.
제 규칙은 이렇습니다. 퀴즈를 통과하기 전에는 다른 사람에게 코드를 보내지 않으며, 다른 사람의 코드를 검토할 때도 똑같이 합니다.
퀴즈는 속도 조절 장치입니다. AI와 함께 일하다 보면 루프가 인간의 이해 속도보다 더 빨리 돌기 쉽습니다.
퀴즈는 그에 맞서는 균형추입니다. 저는 “내가 실제로 이해하고 있는가?”라고 기계적으로 물음으로써 온전한 창의적 참여자로 남을 수 있습니다.
좋습니다. explain-diff 이야기는 여기까지입니다. 원한다면 여기서 스킬을 받을 수 있습니다. HTML 또는 Notion 페이지를 출력하는 두 가지 버전이 있습니다.
다음 아이디어는 마이크로월드입니다. 이 아이디어는 선구적인 교육자 Seymour Papert에게서 영감을 받았습니다.
Papert에게는 수학나라(Mathland)에서 살기라고 부른 아름다운 아이디어가 있었습니다. 수학을 배우고 싶다면 수학나라에서 살아보라는 것입니다. 프랑스어를 배우고 싶을 때 프랑스에 가서 사는 것처럼요. 아이들이 호기심을 따라가다 자연스럽게 수학을 배우는 환경을 만들 수 있을까요?
그렇다면 이것을 코드에는 어떻게 적용할까요? 사람이 그 안에 머물면서 시스템이 어떻게 작동하고 어떻게 변하는지 자연스럽게 직감하게 되는 세계를 만들 수 있을까요?
작년에 저는 Prolog 인터프리터를 코딩하고 있었는데, 그 내부에서 무슨 일이 벌어지는지 직관적으로 파악하기가 어려웠습니다.
에이전트와 함께 이 디버거를 만들었습니다. 이 도구를 이용하면 제 논리 언어의 실행을 한 단계씩 따라가고, 시간을 앞뒤로 훑으며, 스택에 무엇이 있는지와 각 단계에서 어떤 규칙이 평가되는지를 볼 수 있었습니다. 심지어 저 자신을 위해 코멘트도 남길 수 있었습니다(“좋아, 그 규칙을 제대로 적용했어”).
제가 디버깅할 수 있는 도구를 만드는 것과 에이전트에게 디버깅을 맡기는 것 사이에는 큰 차이가 있습니다. 제가 직접 해보는 과정에서 이해가 자라기 때문입니다.
또 다른 사례가 있습니다. 저는 개인 웹사이트를 한 프레임워크에서 다른 프레임워크로 이전하고 있었고, Claude가 그 일을 수행하는 스크립트를 작성했습니다. 하지만 검토하기가 아주 어려웠습니다. 새 프레임워크에 익숙하지 않았기 때문에 제가 할 수 있는 말이라고는 “아마 대충 맞는 것 같네”뿐이었습니다.
그래서 Claude에게 비디오 게임을 만들어 달라고 했습니다. 눈에 보이는 효과와 파일 트리가 변해가는 모습을 지켜보며 제가 직접 한 단계씩 포팅하는 지휘 센터였습니다. Claude는 버튼을 눌러 포팅을 한 단계씩 실행할 수 있고, 기존 사이트와 새 사이트가 나란히 돌아가는 UI를 만들어냈습니다.
이 지휘 센터에서 저는 새 사이트가 점진적으로 살아나는 모습을 지켜봤습니다. 덕분에 직접 손으로 작업했을 때와 비슷한 수준으로 이해하게 됐습니다. 단, 전체 경험이 저를 위해 잘 펼쳐져 있었기 때문에 훨씬 더 빨랐습니다.
여기서 핵심은 에이전트가 우리 인간이 다른 코드를 이해하도록 돕는 작은 코드들을 작성할 수 있다는 것입니다.
이것은 정말 중요한 변화입니다!
자, 마지막 기법은 공유 공간입니다. 지금까지는 모두 혼자 이해하는 이야기였습니다… 하지만 팀으로 일할 때는 함께 이해해야 합니다.
여러분과 다른 사람이 같은 멘탈 모델을 갖고 있으면 효율적으로 소통할 수 있습니다. 같은 이미지를 떠올리게 하는 공유 어휘가 생기므로 함께 즉흥적으로 아이디어를 주고받으며 창의적인 대화를 나눌 수 있습니다. 그런 공유 구조가 없으면 대화는 훨씬 어려워집니다.
팀이 함께 그런 이해를 쌓는 공유 환경을 만드는 일에 저는 정말 큰 기대를 걸고 있습니다. 이것은 어떻게 보면 Notion이 추구하는 일이기도 합니다.
최근 Notion에서는 인간과 에이전트가 함께 일하도록 돕는 새 기능을 아주 많이 출시하고 있습니다. 팀원 각자가 고립된 사일로에서 일하는 대신 팀 전체가 공유된 이해를 키우게 하려는 것입니다.
아주 작은 사례 하나를 들면, 이제 Notion에서 Claude와 Cursor 에이전트를 실행할 수 있습니다. 저도 요즘은 코딩의 상당 부분을 그런 방식으로 합니다.
그 에이전트들이 Notion에서 기술 계획을 만들면 기본적으로 협업 페이지에 놓이기 때문에, 저는 곧바로 팀원들과 코멘트를 달고 토론할 수 있습니다. 혼자가 아니라 함께 생각하는 것입니다!
자, 이제 마무리해 봅시다. 오늘은 코드를 이해하기 위한 몇 가지 기법을 살펴봤습니다… 하지만 사실 저는 이것이 훨씬 더 큰 문제라고 생각합니다.
인간이 사물의 작동 방식을 전반적으로 이해하는 일은 여전히 중요합니다! 검증하기 위해서만이 아니라 참여하기 위해서입니다.
그리고 놀랍지도 않게, 이것은 새로운 아이디어가 아닙니다. 컴퓨팅이라는 우리 분야의 아주 초기 기원으로 거슬러 올라갑니다…
50년 전 Alan Kay는 컴퓨터가 책보다 더 나은 새로운 매체가 되어 사람들, 특히 아이들에게 세상을 생각하는 방법을 가르칠 수 있으리라고 상상했습니다.
이 사진만 보면 아이들이 iPad로 YouTube를 보고 있는 것처럼 보일지도 모르지만, 그렇지 않습니다. 아이들은 대화형 게임을 플레이하면서 동시에 코드를 편집해 물리학을 더 잘 이해하고 있습니다. 이것이 50년 전의 일입니다!!
이제 바라건대 여러분도 이 밈을 이해하실 겁니다.
핵심은 언제나 단순한 자동화가 아니라 증강이었습니다.
이제 AI 덕분에 시뮬레이션을 만드는 일이 이렇게 쉬워졌다는 것은 아름다운 일입니다… AI가 우리를 가르치게 하는 것은 컴퓨팅이 지금껏 열어젖힌 가장 위대한 가능성 중 하나입니다.
그래서 저는 미래를 매우 낙관적으로 봅니다!
올바른 도구를 만든다면 이제 우리는 이전 어느 때보다 세상을 더 잘 이해할 수 있습니다. 단지 스스로를 루프 밖으로 빼기만 할 필요는 없습니다. 우리도 루프 안으로 더 깊이 들어갈 수 있습니다. 선택은 우리에게 달렸습니다.
끝
이 발표가 마음에 드셨다면, 인간과 AI의 협업을 다룬 제가 쓴 다음 글들도 좋아하실 겁니다.
Source links & citations
아래는 원문에 나타난 순서를 그대로 따른 보조 색인이다. 같은 Gist가 두 번 등장하는 것도 서로 다른 원문 발생 위치로 남겼다. 모든 링크는 완역 본문의 해당 문장에도 그대로 보존되어 있다.
원문: Geoffrey Litt, “Understanding is the new bottleneck” (2026-07-02)
Notes & terms
코드 자체의 복잡성보다, 시스템이 왜 그렇게 생겼고 어떻게 바꿀 수 있는지에 대한 사람·팀의 이론이 사라져 생기는 부채.
파일명 순서의 원시 diff가 아니라, 배경·의도·의존성을 따라 산문과 코드 조각을 의미 있는 순서로 엮은 변경 설명.
학습자가 직접 조작하고 결과를 관찰하며 규칙을 체득하는 작고 응답성 높은 환경. Papert의 구성주의적 교육관에서 온 표현.
팀원이 과업·도구·역할·상태를 비슷하게 그릴 수 있게 해 주는 공통 개념 구조와 어휘.