AI Writes Code Faster Than You Can Understand It | Crack Any Codebase with AI

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI가 코드를 만드는 속도가 개발자가 코드를 이해하는 속도보다 빨라질 때, 개발자는 무엇을 지켜야 하는가?==

• AI는 코드 생성 속도를 세네 배 또는 그 이상 끌어올릴 수 있지만, 개발자의 이해 속도는 자동으로 빨라지지 않는다.
• 깨끗하고 테스트된 코드에도 지식이 사라지거나 설계의 이유가 잊히면 ‘이해 부채(comprehension debt)’가 생긴다.
• AI를 한 줄 수정이나 대규모 코드 생성에만 쓰면 판단이 개발자의 머리 밖에서 일어난다.
• AI를 소크라테스식 분석가로 사용해 가설·가정·데이터 흐름·트레이드오프를 질문하면, 코드베이스의 멘탈 모델을 만드는 학습 도구가 될 수 있다.

이 영상은 Zachary Huang의 책 Crack Any Codebase with AI 제1장을 소개하는 짧은 강연이다. 핵심은 AI를 쓰지 말라는 주장이 아니다. AI가 만든 코드를 무조건 받아들이거나 더 빨리 읽으려 하지 말고, 기존 시스템이 왜 존재하는지부터 데이터·인터페이스·컴포넌트·백엔드·프론트엔드·파이프라인·인프라의 연결을 조사하라는 주장이다. 개발자는 AI의 패턴 지식과 생성 속도를 활용하되, 사업 규칙과 설계 이유를 확인하고 테스트·영향 범위 분석·검증된 변경으로 마무리해야 한다.

---

1. 코드가 싸지고 이해가 희소해지는 시대

AI 코딩의 가장 큰 위험은 코드 자체의 품질만이 아니라, 팀이 그 코드가 왜 존재하고 어떻게 움직이는지 모르게 되는 데 있다.

1.1. AI는 코드 작성을 쉽게 하지만 이해를 어렵게 한다

1. 생성 속도와 이해 속도의 불균형

   1. 코드 생성의 가속: 원하는 것을 설명하면 모델이 코드를 만들고, 모든 줄을 읽지 않은 채 배포하는 일이 가능해졌다.
   2. 이해의 정체: AI가 코드를 세네 배 빠르게 만들어도 개발자가 시스템을 이해하는 속도는 그대로일 수 있다.

2. 낯선 코드베이스에서 드러나는 역효과

   1. 레거시 서비스: 기존 레거시 서비스를 맡으면 개발자는 코드보다 먼저 그 서비스가 왜 존재하는지와 어디에서 무엇을 하는지를 알아야 한다.
   2. 새 팀과 장애 조사: 새로운 팀에 합류해 첫날 수십만 줄을 보거나, 익숙하지 않은 운영 장애를 조사할 때 코드를 더 많이 생성하는 능력만으로는 속도가 나지 않는다.

1.2. 이해 부채의 정의

1. 기술 부채와 다른 부채

   1. 기술 부채(technical debt): 마감일을 맞추기 위해 지저분한 코드를 받아들이는 것처럼, 이미 알려진 타협이다.
   2. 이해 부채(comprehension debt): 소프트웨어가 작동하고 테스트도 통과하지만, 아무도 왜 작동하는지 설명하지 못하는 상태다.

2. 이해 부채가 생기는 순간

   1. 지식의 이탈: 시스템을 잘 알던 개발자가 떠나면 코드가 남아도 그 안에 있던 배경 지식과 설계 의도가 사라진다.
   2. 정신 모델의 초과: 시스템이 한 사람의 머릿속 모델보다 커지면, 각 구성요소는 깨끗해 보여도 전체 연결을 이해할 수 없게 된다.
   3. 설명할 수 없는 AI 변경: AI가 아무도 설명하지 못하는 변경을 대량으로 생성하면 이해 부채가 빠르게 커진다.

3. ‘유령이 나오는 코드베이스’라는 비유

   1. 작동하지만 낯선 시스템: 코드베이스는 정상적으로 실행되는데, 설계 이유를 아는 사람이 없어 유령이 나오는 집처럼 느껴진다.
   2. 유령의 정체: 그 유령은 숨은 버그만이 아니라 사라진 이해 그 자체다.

---

2. 코드베이스를 읽는 두 가지 방식

너무 많은 코드를 만났을 때 답은 더 빨리 읽는 것이 아니라, 필요한 코드를 더 적게 읽고 시스템의 연결을 먼저 파악하는 것이다.

2.1. 코더 모드와 엔지니어 모드

1. 코더가 읽는 것

   1. 문법과 로직: 코더는 한 파일 안의 문법과 로직이 무엇을 하는지 읽는다.
   2. 국소적 이해: 함수와 조건문을 파악하는 데는 유효하지만, 그 코드가 시스템 전체에서 어떤 역할을 하는지는 충분히 드러나지 않을 수 있다.

2. 엔지니어가 읽는 것

   1. 연결과 데이터 흐름: 엔지니어는 사용자의 클릭에서 데이터베이스까지 데이터가 어떻게 이동하는지 본다.
   2. 설계의 이유: 왜 하나의 설계를 선택했는지, 어떤 트레이드오프가 시스템을 지탱하는지 확인한다.

3. 아키텍처적 사고

   1. 넓은 시야: 파일 하나의 문법을 넘어 컴포넌트와 인터페이스의 관계를 보는 시야다.
   2. 판단의 축적: 이 시야는 완벽한 선택만으로 만들어지지 않는다. 다양한 패턴과 불완전한 선택을 경험하며 판단이 쌓인다.

2.2. 수동 코딩이 길러 주던 판단

1. 버그 추적

   1. 데이터 흐름 학습: 버그를 직접 따라가면 데이터가 어디에서 들어와 어느 분기와 저장소를 거치는지 자연스럽게 배운다.
   2. 연결 이해: 단순히 에러 줄을 고치는 것이 아니라, 한 변경이 다른 컴포넌트에 어떤 영향을 주는지 보게 된다.

2. 문서와 설계 원칙

   1. 문서와 씨름하기: 불완전하거나 어려운 문서를 직접 읽는 과정도 시스템의 설계 원칙을 파악하는 훈련이다.
   2. 마찰의 교육 효과: 수동 코딩의 번거로움은 개발자를 느리게 하는 마찰이면서, 동시에 판단을 훈련하는 반복 횟수(reps)였다.

3. AI가 없앤 마찰

   1. 한 줄 수정: AI에게 한 줄짜리 수정만 맡겨도 어떤 결정을 내렸는지 개발자의 머리 밖에서 처리될 수 있다.
   2. 500줄 생성: 500줄의 코드를 한 번에 받아들일 때는 더 많은 판단과 설계가 개발자의 정신 모델을 거치지 않고 시스템 안으로 들어온다.

---

3. 이해를 의도적인 훈련으로 바꾸기

AI는 과거의 연습을 없애는 도구가 될 수도 있고, 이해를 훈련하는 새로운 체육관이 될 수도 있다.

3.1. 사라진 반복 횟수를 다시 설계한다

1. 근육이 약해지는 원리

   1. 반복을 건너뛰는 경우: 직접 코딩하고 버그를 쫓는 반복을 모두 건너뛰면 시스템을 이해하는 능력이 위축된다.
   2. 의도적인 반복: 반대로 AI를 사용하더라도 설명·질문·검증의 반복을 일부러 수행하면 이해 능력을 다시 강화할 수 있다.

2. 도구에서 새로운 체육관으로

   1. 옛날 운동을 없앤 도구: AI는 예전의 코딩 연습과 문서 읽기의 마찰을 없애 준다.
   2. 새로운 훈련 장비: 같은 AI를 코드를 대신 쓰게 하는 대신, 코드베이스를 조사하고 멘탈 모델을 시험하는 장비로 사용할 수 있다.

3. 0에 곱해도 0이라는 경고

   1. 기초가 없는 생성: 멘탈 모델이 0인 상태에서 AI에게 “X를 만들어 달라”고 하면 코드가 나와도 이해는 늘지 않는다.
   2. 이해 없는 배포: 결과가 작동하는 것과 결과를 이해하는 것은 다르며, 후자가 0이면 AI의 생성량을 아무리 늘려도 이해는 0에 머문다.

3.2. 자판기 대신 소크라테스식 분석가

1. 두 가지 사용 모드

   1. 자판기(vending machine): “X를 만들어 줘”라고 요청하고 결과를 받는 방식이다.
   2. 소크라테스식 분석가(Socratic analyst): “X를 설명해 줘”라고 요청한 뒤 답을 다시 질문하고 검증하는 방식이다.

2. 모든 답을 가설로 다루기

   1. 가설의 지위: AI의 답은 확정된 사실이 아니라 확인해야 하는 가설로 취급한다.
   2. 근거 확인: 코드, 테스트, 실행 결과와 대조해 답이 실제 시스템에 맞는지 확인한다.

3. 구체적인 반문 예시

   1. try/catch와 널 포인터: AI가 널 포인터 문제를 try/catch로 덮었다면 예외를 숨기지 말고 근본 원인이 무엇인지 묻는다.
   2. 캐시와 인덱스: AI가 캐시를 만들었다면 정말 캐시가 필요한지, 데이터베이스 쿼리에 인덱스만 추가하면 되는지 비교하게 한다.
   3. 가정과 단순성: 어떤 가정을 했는지 이름 붙이게 하고, 가장 단순한 해결책을 제시하도록 요구한다.

---

4. AI의 강점과 엔지니어의 책임

AI는 패턴과 문법을 많이 알고 있지만, 시스템의 지역적 맥락과 사업적 이유를 자동으로 알지는 못한다.

4.1. AI가 모르는 것

1. 패턴과 문법

   1. AI의 강점: AI는 반복되는 코드 패턴과 문법을 빠르게 조합한다.
   2. 생성의 한계: 문법적으로 맞고 그럴듯한 코드가 시스템의 의도까지 맞춘다는 보장은 없다.

2. 맥락과 선택의 이유

   1. 사업 규칙: AI는 지난 분기의 사업 규칙이나 조직 내부의 예외를 저절로 알지 못한다.
   2. 느린 알고리즘의 이유: 현재는 느려 보여도 다른 제약 때문에 선택한 알고리즘이 있을 수 있으며, AI는 그 역사와 이유를 자동으로 알 수 없다.

4.2. 회의론에 대한 답

1. 회의론자가 지적하는 문제

   1. 존재하지 않는 API: AI는 실제로 없는 API를 만들어 낼 수 있다.
   2. 미묘한 버그: 표면적인 테스트를 통과하지만 특정 조건에서 드러나는 버그를 만들 수 있다.
   3. 잘못된 전제: 출발점이 틀렸는데도 자신 있게 잘못된 전제 위에 시스템을 쌓을 수 있다.

2. 그래도 AI를 버리지 않는 이유

   1. 검증은 엔지니어의 일: AI가 말이 안 되는 내용을 걸러내고, 주장을 검증하며, 실제로 작동하는지 묻는 것은 엔지니어의 책임이다.
   2. AI는 반복 횟수를 늘린다: AI를 무비판적으로 믿는 대신 더 많은 조사·질문·검증을 빠르게 반복하는 데 사용하면 가치가 있다.

4.3. 숨을 곳이 없는 출력 형식

1. 검증 가능한 답을 강제하기

   1. 한 문장 요구: 마케팅 언어로 길게 설명하게 두지 말고, 핵심 주장을 한 문장으로 말하게 한다.
   2. 구체적인 산출물: 모호한 설명 대신 데이터 흐름, 호출 관계, 실패 조건처럼 확인 가능한 결과를 요구한다.

2. 다이어그램과 대안

   1. Mermaid 순서도: 긴 글 대신 Mermaid sequence diagram을 요청해 각 단계의 핸드오프를 드러낸다.
   2. 대안과 트레이드오프: “가장 좋은 설계” 하나를 받아들이지 말고 다른 선택지와 각각의 트레이드오프를 함께 요구한다.

3. 구체성의 효과

   1. 검증 지점 증가: 한 문장, 다이어그램, 대안 비교는 AI가 모호한 표현 뒤에 숨을 수 있는 공간을 줄인다.
   2. 개발자 판단 회복: 출력 형식이 구체적일수록 개발자는 시스템의 연결과 선택을 실제로 검토하게 된다.

---

5. AI를 위험하지만 유능한 팀원처럼 관리하기

AI는 가치 있지만 감독 없이 변경을 밀어 넣게 해서는 안 되는, 뛰어나지만 무모한 팀원에 가깝다.

5.1. 신뢰와 감독의 균형

1. 유능함 인정하기

   1. 가치 있는 협업자: AI는 패턴을 찾고 초안을 만들며 반복 작업을 처리하는 데 유용하다.
   2. 무모함 인정하기: 그 유능함이 잘못된 전제와 결합하면 자신 있게 위험한 변경을 만들 수 있다.

2. 감독 없이 배포하지 않기

   1. 모든 주장 검증: AI가 한 설명과 생성한 코드를 실제 코드베이스·테스트·실행 결과와 대조한다.
   2. 사람의 맥락과 판단: AI가 polished answer를 내놓더라도, 조직의 맥락과 설계의 의도는 사람이 제공해야 한다.

5.2. 이해를 만드는 단계적 접근

1. 존재 이유에서 시작하기

   1. 왜 존재하는가: 먼저 시스템과 서비스가 어떤 문제를 해결하기 위해 존재하는지 묻는다.
   2. 사업·제품 맥락: 구현 세부보다 먼저 목적과 제약을 파악해 기술 선택을 해석할 기준을 만든다.

2. 구성요소와 연결 파악하기

   1. 데이터와 인터페이스: 데이터가 어디서 들어와 어디로 나가며, 어떤 인터페이스를 통해 컴포넌트가 연결되는지 확인한다.
   2. 전체 구성: 백엔드·프론트엔드·파이프라인·인프라가 어떤 순서와 경계로 작동하는지 지도처럼 정리한다.

3. 행동 전 검증하기

   1. 테스트: 변경이 의도한 동작을 유지하는지 테스트한다.
   2. 영향 범위 분석: 바뀐 코드가 어디까지 영향을 미칠지 blast radius를 분석한다.
   3. 확신 있는 변경: 멘탈 모델과 검증 결과가 맞아떨어질 때만 자신 있게 변경을 적용한다.

---

6. 실전에서 바로 적용할 AI 코드베이스 조사법

영상의 마지막은 AI를 실제 저장소에 연결해 멘탈 모델을 만들고, 이해 부채를 늘리지 않는 변경으로 이어 가라는 실행 순서다.

6.1. 질문을 계층화한다

1. 목적 질문

   1. 존재 이유: 이 시스템은 왜 만들어졌고 어떤 사용자·사업 문제를 해결하는가.
   2. 제약 조건: 느린 알고리즘이나 복잡한 구조를 선택하게 한 요구사항과 제약은 무엇인가.

2. 구조 질문

   1. 데이터 흐름: 클릭부터 데이터베이스까지 어떤 경로를 거치는가.
   2. 인터페이스: 컴포넌트·서비스·파이프라인 사이의 계약은 무엇이며 어디에서 데이터 형식이 바뀌는가.

3. 변경 질문

   1. 실패 조건: 특정 입력·장애·널 값에서 무엇이 깨질 수 있는가.
   2. 영향 범위: 이 변경이 다른 서비스·사용자 흐름·운영 인프라에 미칠 수 있는 범위는 어디까지인가.

6.2. AI에게 요청할 구체적인 결과

1. 지도 만들기

   1. 첫 아키텍처 지도: 실제 저장소를 가리키고 주요 컴포넌트와 연결을 찾아 첫 번째 아키텍처 지도를 만든다.
   2. Mermaid 변환: 설명을 Mermaid 순서도나 시퀀스 다이어그램으로 바꾸게 해 핸드오프와 경계를 확인한다.

2. 검증 가능한 분석

   1. 가정 목록: AI가 분석에서 사용한 가정을 명시하게 한다.
   2. 대안 표: 하나의 설계를 정답처럼 말하지 않도록 대안과 트레이드오프를 비교하게 한다.
   3. 근거 링크: 설명한 코드 위치·테스트·인터페이스를 제시하게 해 실제 저장소와 대조한다.

6.3. 이해 부채를 늘리지 않는 완료 조건

1. 멘탈 모델 확보

   1. 설명 가능성: 변경된 코드를 다른 개발자에게 왜 필요한지, 데이터가 어떻게 흐르는지 설명할 수 있어야 한다.
   2. 복구 가능성: 문제가 생겼을 때 어느 계층과 컴포넌트를 먼저 확인할지 알고 있어야 한다.

2. 실행과 검증

   1. 실제 시스템 연습: 연습용 예제보다 실제 저장소·레거시 서비스·운영 장애를 대상으로 멘탈 모델을 만들어야 한다.
   2. 검증 후 행동: 테스트와 영향 범위 분석을 거친 뒤 확신 있는 변경을 적용한다.

---

주요 발언 모음

“AI는 코드를 10배 쉽게 만들었지만, 코드를 이해하는 것은 10배 어렵게 만들었다.”

“코드는 싸다. 이해는 희소하다.”

“너무 많은 코드에 대한 답은 더 빨리 읽는 것이 아니라, 더 적게 읽는 것이다.”

“AI가 없앤 예전의 운동은 새로운 체육관 장비가 될 수 있다.”

“모든 답을 가설로 다뤄라.”

“AI를 뛰어나지만 무모한 팀원처럼 관리하라.”

“목표는 행동할 수 있을 만큼 신뢰할 수 있는 멘탈 모델을 만드는 것이며, 이해 부채를 더 깊게 만들지 않는 것이다.”

핵심 데이터 & 수치

• 4분 47초: Manning Publications가 Zachary Huang의 책 제1장을 소개하는 영상 길이다.
• 3~4배: AI가 코드를 개발자가 이해하는 속도보다 세네 배 빠르게 생성할 수 있다는 설명이다.
• 10배: 영상 도입부의 압축된 표현으로, AI가 코드 작성을 10배 쉽게 만들면서 이해를 10배 어렵게 만들었다고 말한다. 엄밀한 측정치라기보다 변화의 방향을 강조하는 수사다.
• 100,000줄: 새로운 직장에서 첫날 마주할 수 있는 대규모 코드베이스의 예시다.
• 1줄 / 500줄: AI가 한 줄 수정부터 500줄 생성까지 개발자의 머리 밖에서 결정을 수행할 수 있다는 예시다.
• 0 × 무엇이든 = 0: 멘탈 모델이 없는 상태에서 코드 생성량만 늘려도 이해가 생기지 않는다는 비유다.

결론 및 시사점

1. AI가 생성한 코드의 양보다 팀이 그 코드의 목적·연결·트레이드오프를 이해하는지가 중요하다.
2. 기술 부채는 지저분한 코드에만 생기지 않으며, 깨끗하고 테스트된 코드에도 이해 부채가 숨을 수 있다.
3. AI에게 “만들어 줘”라고만 하지 말고, “설명해 줘”라고 요청한 뒤 가정과 근거를 계속 질문해야 한다.
4. 널 포인터를 try/catch로 덮거나 불필요한 캐시를 추가하는 식의 표면적 해결을 근본 원인과 비교해야 한다.
5. AI의 답은 가설로 간주하고 실제 코드·테스트·실행 결과와 검증해야 한다.
6. 한 문장, Mermaid 다이어그램, 대안과 트레이드오프를 요청하면 모호한 설명을 줄일 수 있다.
7. 코더는 파일 안의 문법과 로직을 읽고, 엔지니어는 데이터 흐름과 컴포넌트 연결·설계 이유를 읽는다.
8. 기존의 수동 코딩과 버그 추적이 길러 주던 이해의 반복을 AI 시대에는 의도적으로 다시 설계해야 한다.
9. 실제 코드베이스를 AI에 연결해 시스템의 존재 이유, 데이터, 인터페이스, 컴포넌트, 인프라를 단계적으로 파악해야 한다.
10. 최종 변경은 테스트와 blast radius 분석을 거쳐야 하며, AI는 감독 없이 배포하는 팀원이 되어서는 안 된다.

핵심 요약 (40줄)

1. AI는 코드를 빠르게 만들지만 개발자가 그 코드의 의미를 이해하는 속도까지 자동으로 높이지는 않는다.
2. 원하는 것을 설명하고 AI가 만든 코드를 읽지 않은 채 배포하면 낯선 코드베이스에서 오히려 느려질 수 있다.
3. 개발자는 레거시 서비스와 운영 장애와 새 직장의 대규모 저장소를 이해하는 데 많은 시간을 쓴다.
4. 소프트웨어가 작동하지만 아무도 왜 작동하는지 설명하지 못하면 이해 부채가 생긴다.
5. 기술 부채가 마감 때문에 받아들인 지저분한 코드라면 이해 부채는 사라진 지식과 정신 모델의 공백이다.
6. 개발자가 떠나거나 시스템이 한 사람의 모델보다 커지거나 AI 변경을 설명하지 못하면 이해 부채가 커진다.
7. 이해가 사라진 코드베이스는 작동하지만 유령이 나오는 집처럼 느껴질 수 있다.
8. AI는 코드를 세네 배 빠르게 만들 수 있어 코드와 팀의 이해 사이의 간격을 넓힌다.
9. 개념적 실패는 오타처럼 검색할 수 없고 숨은 가정이나 잘못된 전제의 형태로 나타난다.
10. 너무 많은 코드에 대한 답은 더 빨리 읽는 것이 아니라 필요한 코드를 더 적게 읽는 것이다.
11. 코더는 한 파일의 문법과 로직을 읽고 엔지니어는 데이터 흐름과 설계의 연결을 읽는다.
12. 아키텍처적 사고는 패턴과 불완전한 선택을 겪으며 쌓이는 판단이다.
13. 수동 코딩과 버그 추적은 데이터 흐름과 설계 원칙을 간접적으로 가르치는 반복이었다.
14. AI에게 한 줄 수정이나 500줄 생성을 맡기면 중요한 결정이 개발자의 머리 밖에서 일어난다.
15. 예전의 코딩 연습을 건너뛰면 이해 근육이 위축되므로 의도적인 반복이 필요하다.
16. AI는 과거의 운동을 없애는 도구이면서 새로운 이해 훈련을 위한 체육관 장비가 될 수 있다.
17. 멘탈 모델이 0인 상태에서는 AI에게 코드를 아무리 많이 받아도 이해가 늘지 않는다.
18. “X를 만들어 줘”라는 요청은 AI를 자판기처럼 쓰는 방식이다.
19. “X를 설명해 줘”라고 요청하고 답을 추궁하면 AI를 소크라테스식 분석가로 사용할 수 있다.
20. AI의 모든 답은 확정된 사실이 아니라 코드와 테스트로 확인해야 하는 가설이다.
21. 널 포인터를 try/catch로 덮었다면 예외 처리가 아니라 근본 원인을 요구해야 한다.
22. AI가 캐시를 만들었다면 실제로 캐시가 필요한지 쿼리 인덱스로 충분한지 물어야 한다.
23. AI가 사용한 가정을 밝히게 하고 가장 단순한 해결책을 함께 요구해야 한다.
24. AI는 패턴과 문법은 잘 알지만 지난 분기의 사업 규칙이나 느린 알고리즘의 선택 이유는 모를 수 있다.
25. 존재하지 않는 API와 미묘한 버그와 잘못된 전제는 AI 사용을 포기할 이유가 아니라 검증할 이유다.
26. 말이 안 되는 내용을 잡고 주장을 검증하고 작동 여부를 묻는 것은 엔지니어의 책임이다.
27. 한 문장 설명과 Mermaid 시퀀스 다이어그램은 모호한 마케팅 언어를 검증 가능한 출력으로 바꾼다.
28. 하나의 최선 설계 대신 대안과 트레이드오프를 요구하면 AI가 숨을 공간이 줄어든다.
29. AI는 뛰어나지만 무모한 팀원이므로 가치 있게 활용하되 감독 없이 변경을 배포하게 해서는 안 된다.
30. AI의 매끄러운 답변이 제공하지 못하는 조직의 맥락과 판단은 사람이 보충해야 한다.
31. 코드베이스를 조사할 때는 시스템이 왜 존재하는지부터 질문해야 한다.
32. 그다음 데이터·인터페이스·컴포넌트와 백엔드·프론트엔드·파이프라인·인프라의 연결을 파악한다.
33. 실제 저장소에 AI를 연결하고 첫 번째 아키텍처 지도를 만드는 것부터 훈련을 시작할 수 있다.
34. 변경 전에는 테스트와 blast radius 분석으로 영향 범위를 확인해야 한다.
35. 이해의 목표는 모든 코드를 암기하는 것이 아니라 행동을 가능하게 하는 신뢰할 수 있는 멘탈 모델이다.
36. 실제 시스템에서 복잡성을 다이어그램으로 바꾸고 높은 레버리지 질문을 던지는 연습이 필요하다.
37. AI를 코드 생성에만 쓰면 이해 부채가 깊어질 수 있고 코드베이스 조사에 쓰면 이해를 확장할 수 있다.
38. 코드 생성 속도와 이해 속도의 간격은 AI 시대 개발자의 새로운 전문적 위험이다.
39. AI가 만든 결과를 소유하려면 개발자가 그 결과의 가정·데이터 흐름·설계 이유를 설명할 수 있어야 한다.
40. 코드는 싸지만 이해는 희소하므로 AI의 가장 가치 있는 사용처는 코드를 더하는 일보다 기존 시스템을 이해하는 일일 수 있다.