# 이해가 새로운 병목이다

> Clean Markdown view of GeekNews topic #31429. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31429](https://news.hada.io/topic?id=31429)
- GeekNews Markdown: [https://news.hada.io/topic/31429.md](https://news.hada.io/topic/31429.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-14T10:21:02+09:00
- Updated: 2026-07-14T10:21:02+09:00
- Original source: [geoffreylitt.com](https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck.html)
- Points: 11
- Comments: 2

## Topic Body

- 에이전트가 작성한 코드가 사람 주변에 계속 쌓이는 상황에서 개발 속도를 제한하는 요소는 코드 생성 능력이 아니라 시스템을 따라가며 다음 변화를 구상할 수 있는 **인간의 이해 속도**로 이동하고 있음  
- 코드를 이해하는 목적은 결과를 승인하거나 거부하는 **검증**에 그치지 않으며, 여러 차례 이어지는 에이전트 작업 루프에서 다음 아이디어를 제안하고 **창작 과정에 참여**하는 데 있음  
- 원시 코드 차이 대신 배경지식/변경 목표/상호작용형 도표/서술식 코드 차이를 묶은 **코드 설명 문서**를 먼저 읽으면 변경의 구조와 의도를 더 빠르게 파악할 수 있음  
- 설명 문서의 퀴즈와 실행 과정을 직접 조작하는 **마이크로월드**는 에이전트가 대신 판단하게 하지 않고 사람이 시스템의 상태 변화와 내부 작동을 체험하도록 만듦  
- AI를 사람을 루프에서 제거하는 자동화 수단으로만 사용하지 않고 이해를 위한 도구와 시뮬레이션을 만드는 데 활용하면, 사람과 팀이 오히려 **더 깊이 루프에 참여**할 수 있음  
  
---  
  
### 코드 생성 속도를 따라가지 못하는 인간  
  
- 에이전트가 작성한 **코드 더미**가 한 사람 주변에 계속 높아지는 모습처럼, 생성되는 코드의 양은 늘어나지만 사람이 이를 이해하는 속도는 같은 비율로 증가하지 않음  
- 모든 코드 차이를 한 줄씩 읽는 방식만으로는 **에이전트의 작업 속도**를 따라가기 어려움  
- 코드 이해에는 원시 코드 차이 외에도 다음과 같은 다양한 방식이 있음  
  - 시스템과 변경 사항을 가르치는 **코드 설명 문서**  
  - 실제 이해 여부를 확인하는 **퀴즈**  
  - 내부 동작을 직접 조작하며 익히는 **마이크로월드**  
  - 팀 전체가 같은 정신 모형을 형성하는 **공유 공간**  
  
### 이해는 검증이 아니라 참여를 위한 것  
  
- 사람이 코드를 이해해야 한다는 질문에 흔히 나오는 답은 에이전트의 작업을 **검증**하기 위해서라는 것임  
  - **명세**에 맞는지 확인함  
  - **구조**가 적절한지 판단함  
  - 최종적으로 **승인/거부**를 결정함  
- 발표 자료에서는 이를 엄지를 올리거나 내리는 **이분법적 판단**으로 표현함  
  - 검증만을 사람의 역할로 보면 이해는 결과에 대한 **합격 여부**를 판단하는 과정으로 축소됨  
- 하지만 에이전트는 자신이 만든 결과를 직접 실행하고 검사하며 오류를 찾는 **자체 검증 능력**도 계속 개선되고 있음  
- 검증을 에이전트가 더 잘 수행하게 될수록 **인간은 어디에 남는가**라는 문제가 생김  
- 대안은 **이해를 통해 참여하는 것**임  
  - 에이전트가 무엇을 하고 있는지 알아야 사람이 **창의적 과정의 능동적인 구성원**으로 남을 수 있음  
  - 시스템을 이해하면 현재 결과를 평가하는 데서 끝나지 않고 **다음 단계에서 무엇을 바꿀지** 생각할 수 있음  
  
### 프로젝트는 하나의 루프가 아니라 수많은 루프임  
  
- 실제 프로젝트는 에이전트에게 한 번 지시하고 결과를 받는 **단일 루프**가 아님  
- 목표 설정/구현/확인/수정/확장으로 이어지는 **수많은 반복 루프**가 서로 연결됨  
- 각 반복에서 사람이 가진 **시스템 이해도**가 다음 아이디어의 질과 범위를 결정함  
- 머릿속에 충분한 개념과 구조가 있어야 다음과 같은 질문을 유창하게 다룰 수 있음  
  - 무엇을 **추가하거나 제거**해야 하는가  
  - 어느 **구조를 변경**해야 하는가  
  - 현재 구현에서 어떤 **새로운 가능성**이 생겼는가  
- 이해가 부족하면 에이전트가 만들어준 결과에 “대략 맞아 보인다”고 반응할 수는 있지만, 프로젝트가 어디로 가야 하는지 **주도하기 어려움**  
  
### 이해를 미루며 쌓이는 인지 부채  
  
- 시스템을 이해하지 않은 채 에이전트의 결과를 계속 받아들이면 **단기적으로는 빠르게 진행**할 수 있음  
- 그러나 기술 부채가 나중의 변경 비용을 높이듯, 이해를 생략한 작업은 **인지 부채(cognitive debt)** 를 남김  
- 인지 부채가 쌓이면 프로젝트에 참여한 사람이 **전체 흐름을 놓치게 됨**  
  - 코드가 왜 현재 구조가 됐는지 **파악하기 어려움**  
  - 새로운 요구사항을 어디에 연결해야 할지 **판단하기 어려움**  
  - 에이전트가 제안한 다음 변경의 타당성을 **논의하기 어려움**  
- AI 시대의 문제는 코드가 생성되지 않는 것이 아니라, 생성된 시스템에 관해 사람이 **충분한 개념을 갖지 못하는 것**임  
  
### 교육 방법을 코드 이해에 적용하기  
  
- 빠르게 변하는 AI 작업 환경에서 인간의 이해를 구축하는 문제는 **교육이 오랫동안 다뤄온 문제**와 닮아 있음  
- 새로운 사실을 단순히 전달하는 것보다 **배경지식/직관/연습/피드백**을 함께 제공해야 실제 이해가 형성됨  
- 코드 이해에도 교육에서 발전한 방법을 적용할 수 있음  
  - 세부 구현 전에 **배경과 직관**을 제공함  
  - 내용을 읽은 뒤 **회상하고 답하게 함**  
  - 추상적인 규칙을 직접 조작할 수 있는 **환경**을 제공함  
  - 다른 사람과 같은 **개념과 어휘**를 공유하게 함  
  
### 변경 사항을 가르치는 `/explain-diff`  
  
- [/explain-diff](https://gist.github.com/geoffreylitt/a29df1b5f9865506e8952488eac3d524)는 에이전트가 수행한 변경을 **구조화된 설명 문서**로 만드는 스킬임  
- HTML/Markdown/Notion 페이지 형태로 출력할 수 있으며, Notion 문서는 팀원이 댓글을 달고 함께 논의하는 **협업 산출물**로 사용할 수 있음  
- 단순한 코드 변경 목록이 아니라 사람이 변경 사항을 학습하도록 설계된 **설명 자료**를 생성함  
- 게임 화면의 원근감을 변경하는 사례에서는 코드를 바로 보여주지 않고 다음 순서로 접근함  
  - 기존 **게임 엔진의 렌더링 방식**을 먼저 설명함  
  - “2D 그리기 기법으로 정원을 입체적으로 보이게 만들기”라는 **변경 목표**를 제시함  
  - **등각 투영**이 무엇인지 설명해 변경의 시각적 원리를 이해하게 함  
  - 이후에 실제 **구현 코드**로 이동함  
  
### 배경지식부터 가르치기  
  
- 좋은 설명은 “무엇이 바뀌었는가”보다 **“바뀌기 전에는 무엇이 있었는가”** 에서 시작함  
- 기존 게임 엔진의 좌표 체계와 렌더링 구조를 모르면 새 원근법 코드만 읽어도 **변경의 이유**를 이해하기 어려움  
- 설명 문서는 에이전트와 동일한 배경을 갖지 못한 사람이 대화에 참여할 수 있도록 **기존 시스템의 구조**를 먼저 보충함  
- 이는 단순한 요약이 아니라 사람을 **현재 프로젝트 문맥**으로 다시 데려오는 과정임  
  
### 세부 구현보다 직관을 먼저 만들기  
  
- 코드에 앞서 변경의 본질을 한 문장으로 설명하면 세부 구현이 어떤 **목표를 향하는지** 알 수 있음  
- 정원을 입체적으로 보이게 만드는 사례에서는 등각 투영의 수식부터 설명하지 않고, 평면의 그림을 3차원처럼 보이게 한다는 **시각적 목표**를 먼저 전달함  
- 배경과 목표를 이해한 뒤 코드 조각을 보면 각 계산과 변환이 전체 결과에서 맡는 **역할을 연결**하기 쉬움  
- 사람을 세부 코드의 수동적인 독자가 아니라 **변경 의도를 이해하는 동등한 참여자**로 만드는 것이 목적임  
  
### 상호작용형 도표로 좌표 변화를 체험하기  
  
- 정적인 그림만 보여주는 대신 정원 위의 바위를 직접 끌어 움직이는 **상호작용형 도표**를 사용함  
- 바위를 이동하면 화면상의 위치와 내부 좌표가 함께 변해 **등각 투영의 좌표 변환**을 확인할 수 있음  
- 수식이나 코드만 읽을 때보다 입력과 출력의 관계를 직접 조작하며 **직관을 형성**할 수 있음  
- Notion 페이지 안에 상호작용형 HTML을 삽입해 코드 설명 문서 자체를 **작은 실행 환경**으로 만들 수 있음  
- AI는 설명문을 쓰는 데서 그치지 않고 이해에 필요한 **시각화와 조작 도구**까지 생성할 수 있음  
  
### 원시 코드 차이를 서술식 코드 차이로 바꾸기  
  
- 일반적인 코드 차이는 변경된 파일을 **파일명 순서**로 나열함  
  - 파일 간 **관계**를 설명하지 않음  
  - 변경 **목적**을 알려주지 않음  
  - 어떤 순서로 읽어야 하는지 **안내하지 않음**  
- **서술식 코드 차이(literate diff)** 는 변경 사항을 글의 흐름처럼 재구성함  
  - 변경의 **목적**을 먼저 제시함  
  - 이해하기 적절한 순서로 **파일과 함수**를 설명함  
  - 설명 사이에 필요한 **코드 조각**만 삽입함  
  - 주변 맥락과 구현 선택의 **관계**를 함께 보여줌  
- 원시 코드 차이가 재료를 그대로 쌓아둔 것이라면, 서술식 코드 차이는 변경 과정을 **하나의 이야기로 편집**한 것에 가까움  
- 설명을 먼저 읽은 뒤 원시 코드 차이를 검토하면 각 코드 조각이 왜 존재하는지 알고 읽을 수 있어 **검토 속도가 빨라짐**  
  
### AI가 만든 설명서를 종이로 읽기  
  
- 완성된 설명 문서는 하나의 **코드 설명 패킷**처럼 사용할 수 있음  
- 원시 코드 차이도 계속 읽지만 항상 **설명 문서를 먼저 읽음**  
- 집중이 필요할 때는 문서를 인쇄해 카페에서 **종이로 읽기도 함**  
- AI와의 프로그래밍이라는 상호작용적인 활동이 오히려 깊게 집중할 수 있는 **정적인 종이 보고서**로 바뀌는 역설이 생김  
- 핵심은 가장 최신의 인터페이스를 사용하는 것이 아니라 사람이 실제로 **이해하기 좋은 형태로 정보를 변환**하는 것임  
  
### 읽었다는 느낌과 실제 이해의 차이  
  
- 설명 문서를 잘 구성해도 **읽는 행위 자체가 이해를 보장**하지는 않음  
- 사람은 문장을 눈으로 따라간 것만으로 내용을 기억하거나 이해했다고 **착각하기 쉬움**  
- Andy Matuschak의 “[books don't work](https://andymatuschak.org/books/)”와 Andy Matuschak/Michael Nielsen의 [Quantum Country](https://quantum.country/)에서 아이디어를 가져옴  
- Quantum Country는 글 안에 **간격 반복 퀴즈**를 삽입해 독자가 내용을 직접 회상하게 함  
- 같은 방식을 코드 설명 문서에 적용해 마지막에 변경 사항에 관한 **다섯 개의 대화형 질문**을 배치함  
  
### 퀴즈는 AI 루프의 속도 조절 장치임  
  
- 코드를 다른 사람에게 보내기 전에 설명 문서의 **퀴즈를 통과해야 한다는 규칙**을 사용함  
- 다른 사람이 작성한 코드를 검토할 때도 **같은 기준**을 적용함  
- 퀴즈는 지식을 평가하기 위한 부가 기능이 아니라 **속도 조절 장치**임  
- AI와 작업하면 구현/수정/재생성 루프가 **인간의 이해보다 빠르게 진행**되기 쉬움  
- 퀴즈는 각 루프에서 기계적으로 다음 질문을 던지게 함  
  - 실제로 **무엇이 바뀌었는지** 설명할 수 있는가  
  - 왜 이런 **구조를 사용했는지** 이해하는가  
  - 다음 변경에 영향을 주는 **제약**을 알고 있는가  
- 통과하지 못하면 작업 속도를 늦추고 이해를 보충해야 하므로, 사람이 **창의적 참여자**로 남을 수 있음  
  
### Seymour Papert의 Mathland에서 가져온 마이크로월드  
  
- 두 번째 방법인 **마이크로월드**는 교육자 Seymour Papert의 아이디어에서 출발함  
- Papert는 프랑스어를 배우기 위해 프랑스에서 생활하듯, 수학을 배우려면 수학이 자연스럽게 작동하는 **Mathland**에서 살아야 한다고 봄  
- 아이가 설명을 수동적으로 듣는 대신 호기심에 따라 환경을 탐색하며 **수학적 개념을 자연스럽게 익히는 방식**임  
- 이를 코드에 적용하면 시스템을 설명하는 문서만 제공하는 것이 아니라, 사람이 그 안에 들어가 **작동 방식을 직접 경험하는 환경**을 만들 수 있음  
- 마이크로월드는 실제 프로덕션 시스템 전체를 그대로 노출하기보다 특정 원리와 상태 변화를 관찰하기 좋게 구성한 **작은 세계**임  
  
### Prolog 인터프리터를 시간축으로 탐색하기  
  
- Prolog 인터프리터를 개발할 때 내부에서 어떤 일이 일어나는지 **직관적으로 파악하기 어려웠음**  
- 에이전트와 함께 실행 과정을 단계별로 탐색하는 **전용 디버거**를 제작함  
- 이 디버거에서는 다음을 직접 확인할 수 있음  
  - 실행 시간을 **앞뒤로 이동**함  
  - 현재 스택에 어떤 값이 있는지 **살펴봄**  
  - 각 단계에서 어떤 규칙이 평가되는지 **확인함**  
  - 특정 규칙이 올바르게 적용된 순간에 **메모를 남김**  
- 완성된 결과만 보는 대신 논리 언어의 실행이 시간에 따라 어떻게 전개되는지 **직접 따라갈 수 있음**  
- 에이전트에게 디버깅을 맡기면 문제는 해결될 수 있지만, 사람이 디버거를 직접 조작해야 **실행 구조에 관한 이해**가 생김  
  
### 에이전트가 대신 디버깅하는 것과 이해 도구를 만드는 것의 차이  
  
- “에이전트가 문제를 찾아 수정함”과 “에이전트가 사람이 문제를 탐색할 도구를 만듦”은 **서로 다른 결과**를 만듦  
- 전자는 작업 결과를 빠르게 얻지만 내부 과정에 대한 **인간의 이해는 거의 늘지 않을 수 있음**  
- 후자는 사람이 실행 상태를 살펴보고 가설을 세우고 결과를 확인하는 **탐색 과정**을 제공함  
- 코드 작성의 일부를 에이전트에게 맡기면서도 핵심적인 **사고와 탐색은 사람이 직접 수행**할 수 있음  
- 에이전트의 역할을 정답 제공자에서 **이해 환경 제작자**로 확장하는 접근임  
  
### 웹사이트 마이그레이션을 게임처럼 수행하기  
  
- 개인 웹사이트를 한 프레임워크에서 다른 프레임워크로 이전할 때 Claude가 **자동화 스크립트**를 작성함  
- 새 프레임워크에 익숙하지 않아 스크립트를 읽어도 **“대략 맞아 보인다” 이상으로 평가하기 어려웠음**  
- 이를 해결하기 위해 Claude에게 이전 작업을 직접 수행하는 **비디오게임 형태의 명령 센터**를 만들도록 요청함  
- 명령 센터에서는 다음 과정을 시각적으로 확인할 수 있음  
  - 버튼을 눌러 **마이그레이션 단계를 하나씩 실행**함  
  - 기존 사이트와 새 사이트를 화면 양쪽에 **나란히 표시**함  
  - 각 단계에서 새 사이트의 모습이 어떻게 달라지는지 **확인함**  
  - 파일 트리가 어떤 순서로 변하는지 **관찰함**  
- 전체 변환을 한 번에 실행하는 대신 새 사이트가 단계적으로 살아나는 과정을 **직접 경험**함  
- 손으로 모든 파일을 옮겼을 때와 비슷한 이해를 얻으면서도 필요한 작업과 관찰 환경이 미리 준비돼 있어 **훨씬 빠르게 진행**할 수 있음  
  
### 코드를 이해하기 위한 코드를 생성하기  
  
- 에이전트가 작성할 수 있는 코드는 제품 기능이나 자동화 스크립트에 **한정되지 않음**  
- 사람이 다른 코드를 이해할 수 있도록 다음과 같은 **임시 도구**도 만들 수 있음  
  - **실행 시각화 도구**  
  - **단계별 디버거**  
  - **좌우 비교 화면**  
  - **파일 트리 변화 표시기**  
  - **상호작용형 개념 설명**  
  - 작업을 작은 단계로 나눈 **명령 센터**  
- 이런 도구는 장기적으로 유지되는 제품 코드가 아니어도 **충분한 가치**가 있음  
- AI로 코드를 만드는 비용이 낮아지면서 특정 사람과 특정 작업을 위한 **일회성 학습 환경**도 현실적으로 만들 수 있음  
  
### 팀에서는 함께 이해해야 함  
  
- 개인이 시스템을 이해하는 것만으로는 **팀 작업에 충분하지 않음**  
- 팀원들이 같은 **정신 모형**을 가지고 있어야 짧은 표현으로도 같은 구조와 동작을 떠올릴 수 있음  
- 공유된 어휘와 이미지가 있으면 아이디어를 즉흥적으로 주고받고 **새로운 방향을 함께 발전**시키기 쉬움  
- 반대로 각자가 별도의 에이전트와 고립된 상태로 작업하면 다음 문제가 생김  
  - 같은 용어를 **서로 다른 의미**로 사용함  
  - 기술적 계획의 **전제를 공유하지 못함**  
  - 결과물은 합쳐도 **이해는 합쳐지지 않음**  
- 팀의 AI 활용은 각 개인의 생산성을 높이는 문제뿐 아니라 팀 전체의 **공유 이해를 구축하는 문제**임  
  
### 에이전트와 사람의 작업을 같은 공유 공간에 남기기  
  
- Notion에서는 Claude와 Cursor 에이전트를 **페이지 안에서 실행**할 수 있음  
- 에이전트가 작성한 기술 계획은 기본적으로 **협업 가능한 페이지**에 만들어짐  
- 팀원은 에이전트가 만든 계획을 별도의 채널로 복사하지 않고 같은 자리에서 바로 검토할 수 있음  
  - 특정 문장에 **댓글을 남김**  
  - 구현 선택을 **질문함**  
  - 계획을 함께 **수정함**  
  - 팀의 논의와 에이전트의 결과를 **한 문맥에 남김**  
- 에이전트가 개인별 사일로 안에서 작업하는 대신, 사람과 에이전트가 **공동 문서를 중심으로 사고**하게 됨  
- 공유 공간은 결과를 저장하는 문서함이 아니라 팀이 함께 **정신 모형을 만드는 장소**임  
  
### 컴퓨터의 목적은 처음부터 증강이었음  
  
- 코드 이해를 위한 설명/퀴즈/마이크로월드의 문제는 **프로그래밍에만 한정되지 않음**  
- 사람은 결과를 검증하기 위해서만이 아니라 세상이 어떻게 작동하는지 이해하고 변화에 참여하기 위해 **지식을 필요로 함**  
- Alan Kay는 약 50년 전 컴퓨터를 책보다 나은 **새로운 교육 매체**로 구상함  
- 당시의 그림에는 아이들이 태블릿 같은 장치를 바라보는 모습이 나오지만, 영상을 수동적으로 시청하는 것이 아님  
  - **상호작용형 물리 시뮬레이션**을 조작함  
  - 게임을 플레이하면서 **코드를 직접 수정**함  
  - 수정한 코드가 물리적 움직임을 어떻게 바꾸는지 **확인함**  
- 컴퓨터는 정적인 정보를 전달하는 기계가 아니라 복잡한 개념을 움직이고 바꾸며 이해하게 하는 **동적 매체**가 될 수 있음  
  
### 자동화만이 아니라 더 깊은 참여로  
  
- 우주인이 지구를 바라보며 “컴퓨터의 목적은 복잡한 개념을 이해하기 위한 동적 시뮬레이션을 만드는 것이었나”라고 묻고, 뒤의 우주인이 “항상 그랬다”고 답하는 **밈**으로 핵심을 표현함  
- 컴퓨터와 AI의 목적을 사람의 작업 제거에만 두면 사람은 **시스템의 바깥으로 밀려날 수 있음**  
- 반대로 AI를 설명/시뮬레이션/마이크로월드/공유 공간을 만드는 데 사용하면 사람이 **더 많은 개념을 더 깊게 이해**할 수 있음  
- AI가 시뮬레이션 제작 비용을 낮추면서, 특정 개념을 배우기 위한 **맞춤형 환경**을 필요할 때마다 생성할 수 있게 됨  
- 목표는 사람을 루프에서 빼는 것만이 아니라 사람이 이전보다 **더 깊이 루프 안으로 들어가도록 만드는 것**임  
  
### 관련 글  
  
- [Enough AI copilots! We need AI HUDs](https://www.geoffreylitt.com/2025/07/27/enough-ai-copilots-we-need-ai-huds) - 코파일럿을 넘어 인간의 정신을 더 직접적으로 확장하는 **AI 인터페이스**  
- [AI-generated tools can make programming more fun](https://www.geoffreylitt.com/2024/12/22/making-programming-more-fun-with-an-ai-generated-debugger) - AI로 맞춤형 디버거 UI를 만들어 사람이 직접 프로그래밍하는 **과정을 개선한 사례**  
- [Code like a surgeon](https://www.geoffreylitt.com/2025/10/24/code-like-a-surgeon) - 부수적인 반복 작업은 위임하고 사람이 **핵심 작업에 집중하는 방식**

## Comments



### Comment 61771

- Author: coremaker
- Created: 2026-07-14T10:54:05+09:00
- Points: 2

병목을 완전히 제거하려면  
  
- AI 를 이용한 결과물에 대한 신뢰도가 지금보다 더 높아져야하고, 이를 사람(사장, 관리자)이 체감해야합니다.  
- 일정 이상의 리스크를 감당할 수 있다면, 상당수의 병목이 제거될 것이라 판단합니다. 그래서 리스크가 통제되는 상황에서는 적극적으로 사람 개입없이 적용해보면 어떨까 싶기도 합니다.  
- 만약 Human In The Loop 를 할 수 밖에 없는 상황이라면, 한 사람에게 완전히 의존하는 프로세스를 만들면 안됩니다. 어떤 사람이 와도 수행할 수 있게 해야하고, 상황에 따라서는 N 명이 투입될 수 있는 상황을 만들어야합니다.  
- 병목을 발견하는 능력을 실무자 뿐아니라 관리자와 사장이 갈고 닦아야 합니다. 대부분의 병목은 의사결정을 통해 제거되거나 착아질 수 있습니다.  
- 이런 논의를 실무자가 아니라 관리자와 사장이 해야합니다.

### Comment 61770

- Author: shakespeares
- Created: 2026-07-14T10:43:51+09:00
- Points: 1

사람의 인지 및 기억 구조가 단기 기억, 장기 기억으로 나눠져 있기 때문에 아무리 이렇게 해서 AI의 코딩 속도를 올리려고 한들 사람이 중간중간에 확인하면서 단기 기억을 쌓는 것이 인지 부채에 가장 효율적이다라고 말하고 싶네요.