진짜 병목은 "이해"

Understanding is the new bottleneck — Geoffrey Litt, Notion - YouTube

 

2026년 7월 AI Engineer 콘퍼런스에서 Geoffrey Litt가 발표한 Understanding is the new bottleneck 의 내용과 관련 조사를 바탕으로 정리한 글입니다.

발표는 AI가 코드를 빠르게 작성하는 시대에도 인간이 왜 코드를 이해해야 하는지, 그리고 그 이해를 어떻게 따라갈 수 있는지를 다룹니다.

 

 

--------------------------------------------------------------------------------------

 

검증이 아니라, 참여하기 위해 이해한다

인간이 코드를 이해해야 하는 이유로 가장 먼저 떠올리는 것은 검증이다.

AI가 요구사항을 제대로 구현했는지, 이상한 코드를 넣지는 않았는지, 운영 장애를 일으킬 가능성은 없는지 사람이 확인해야 한다는 것이다.

지금도 중요한 역할이지만, 발표자는 이것만으로는 이해의 필요성을 충분히 설명하지 못한다고 말한다.

테스트와 정적 분석, 에이전트의 자체 검토가 발전할수록 단순한 정확성 검사는 더 많이 자동화될 수 있다.

그렇다고 인간의 이해가 필요 없어지는 것은 아니다.

더 중요한 이유는 프로젝트에 계속 참여하기 위해서다.

기능을 만들면 새로운 요구가 생기고, 문제를 해결하면 다음 아이디어가 나온다.

이때 현재 시스템을 얼마나 이해하고 있는지가 다음 아이디어의 범위를 결정한다.

시스템을 잘 이해하는 사람은 기존 구조와 제약을 머릿속에서 조합하며 다음 방향을 생각할 수 있다.

반면 AI가 만든 결과만 받아들이면, 새로운 변경이 필요할 때마다 시스템이 어떻게 되어 있는지 다시 물어봐야 한다.

점차 프로젝트를 함께 만드는 사람보다 AI에 요청하고 결과를 전달받는 사람에 가까워진다.

한 번의 작업에서 얻은 이해가 다음 작업의 아이디어로 이어지며, 이 축적된 이해가 인간을 능동적인 참여자로 남게 한다.

 

예를 들어 AI가 서비스에 캐시를 추가했다고 해보자.

검증만 한다면 테스트가 통과하는지, 캐시가 실제로 적용됐는지 정도를 확인할 수 있다.

하지만 다음 변경에도 참여하려면 왜 캐시가 필요한지, TTL은 왜 이 값인지, 데이터 변경 시 어떻게 무효화되는지, 여러 서버 사이에서 일관성 문제가 생길 수 있는지까지 알아야 한다.

코드를 이해한다는 것은 모든 구현을 외우는 일이 아니다.

다음 결정을 내릴 수 있을 정도로 시스템을 이해하는 일에 가깝다.

검증 역시 완전히 사라지지는 않는다.

다만 코드 한 줄의 옳고 그름보다, 요구사항이 맞는지, 위험을 감수할 수 있는지, 운영에서 어떻게 감지하고 복구할 것인지처럼 더 높은 수준으로 이동할 가능성이 크다.

속도가 이해를 앞서면 인지 부채가 쌓인다

발표에서는 이를 인지 부채(cognitive debt)라는 개념으로 설명한다.

기술 부채는 코드에 쌓인다. 중복이 많고 의존 관계가 복잡해져 앞으로 변경하기 어려워지는 상태다.

인지 부채는 사람과 팀에 쌓인다.

코드는 정상적으로 작동하지만, 팀이 그 코드가 왜 존재하는지, 어디까지 변경해도 되는지, 어떤 조건에서 실패하는지 모르는 상태다.

AI를 이용하면 깔끔한 코드를 빠르게 만들 수 있다.

하지만 변경 속도를 사람이 따라가지 못하면 코드 품질과 별개로 인지 부채는 늘어난다.

처음에는 문제가 없어 보인다. AI에게 기능을 요청하고 테스트가 통과하면 병합한다.

그러나 이런 변경이 반복되면 어느 순간 작은 수정도 어디에 영향을 줄지 확신하기 어려워진다. AI에게 설명을 요청할 수는 있지만, 그 설명이 맞는지 판단할 내부 기준조차 부족해질 수 있다.

바이브 코딩이 잘 진행되다가 어느 순간 “이제 무슨 일이 벌어지는지 모르겠다”고 느끼는 것도 같은 문제다.

기능은 계속 늘어나지만 인간은 프로젝트에 능동적으로 참여하기 어려워진다.

AI가 만든 코드를 이해하는 방법

발표에서는 크게 설명, 마이크로 월드, 공유 공간이라는 세 가지 방법을 제시한다.

설명 과정에 포함된 퀴즈를 따로 떼어보면 실무에서는 다음 네 가지 방식으로 적용할 수 있다.

1. 변경 내용을 설명하는 문서

일반적인 코드 리뷰는 변경된 파일과 diff부터 보여준다.

하지만 익숙하지 않은 시스템의 diff를 바로 읽으면, 각 코드가 왜 바뀌었는지 파악하기 어렵다.

발표자가 만든 ExplainDiff는 먼저 기존 시스템의 배경을 설명한다.

그다음 세부 코드보다 변경의 목적과 핵심 아이디어를 전달하고, 마지막에 실제 코드를 이해하기 좋은 순서로 보여준다.

파일명 순서대로 diff를 나열하는 대신, 실행 흐름에 맞춰 설명과 코드를 함께 배치한다.

발표자는 이를 문학적 코드 diff(literate code diff)라고 부른다.

AI에게 다음과 같이 요청하는 것만으로도 비슷하게 적용할 수 있다.

변경된 파일을 나열하는 데서 끝내지 말고, 기존 구조와 이번 변경의 목적부터 설명해줘. 그다음 실행 흐름에 맞춰 중요한 코드를 보여줘.

2. 이해했는지 확인하는 퀴즈

설명을 읽었다고 반드시 이해한 것은 아니다.

읽을 때는 알 것 같지만, “왜 이 구조를 선택했나요?”라는 질문에는 답하지 못할 수 있다.

발표자는 변경 설명 아래에 다섯 개 정도의 질문을 만들고, 자신이 그 질문에 답할 수 있을 때만 다른 사람에게 리뷰를 요청한다.

퀴즈의 목적은 시험이 아니라 AI의 작업 속도와 인간의 이해 속도가 지나치게 벌어지지 않도록 조절하는 것이다.

발표에서는 이를 속도 조절기라고 표현한다.

다음 정도를 확인하면 된다.

• 이번 변경이 해결하는 문제는 무엇인가
• 주요 실행 흐름은 어떻게 되는가
• 반드시 유지해야 하는 조건은 무엇인가
• 어떤 상황에서 실패할 수 있는가
• 요구사항이 달라지면 어디를 수정해야 하는가

3. 직접 움직여보는 마이크로 월드

동시성, 이벤트 흐름, 트랜잭션, 렌더링처럼 상태가 시간에 따라 변하는 문제는 문서만으로 이해하기 어렵다.

발표자는 이런 경우 AI에게 마이크로 월드(micro-world)를 만들게 한다.

Prolog 인터프리터를 구현할 때는 내부 상태를 단계별로 볼 수 있는 디버거를 만들었고, 웹사이트 프레임워크를 이전할 때는 파일과 명령의 변화를 한 단계씩 확인할 수 있는 작은 도구를 만들었다.

AI에게 문제를 대신 해결하도록 하는 데서 끝내지 않고, 사람이 문제를 이해할 수 있는 환경을 만들어달라고 한 것이다.

백엔드 개발에서도 메시지 재처리, 분산 락 경쟁, 캐시 갱신, 트랜잭션 상태 변화를 보여주는 간단한 시뮬레이터를 만들 수 있다.

제품에 포함할 필요는 없다. 특정 문제를 이해한 뒤 버리는 코드여도 충분하다.

4. 팀이 함께 보는 공유 공간

개인이 AI와 대화하며 시스템을 이해해도, 그 내용이 개인 채팅에만 남으면 팀의 이해는 늘지 않는다.

팀원들이 각자 다른 AI와 대화하면 같은 시스템을 서로 다르게 이해할 수도 있다.

따라서 AI가 만든 계획과 설명, 질문과 결정 이유를 팀이 함께 볼 수 있는 공간에 남길 필요가 있다.

영상에서는 여러 사람과 에이전트가 같은 대화와 문서에 참여하는 방식을 제안한다.

중요한 것은 특정 도구가 아니라, AI와 나눈 대화가 개인의 일회성 기록으로 끝나지 않고 팀의 지식이 되는 것이다.

기존 코드 리뷰 연구에서도 리뷰의 가치는 버그 발견에만 있지 않았다.

지식 전달과 팀의 상황 파악, 대안 발견도 중요한 목적이었다.

AI가 리뷰의 일부를 자동화하더라도 팀이 함께 시스템을 이해하는 기능은 남는다.

모든 코드를 전부 이해할 필요는 없다

이 주장을 AI가 작성한 모든 코드를 한 줄씩 읽어야 한다는 뜻으로 받아들일 필요는 없다.

현대 소프트웨어는 이미 한 사람이 전부 이해할 수 없는 규모다.

운영체제, JVM, 데이터베이스, 네트워크와 프레임워크 내부를 모두 이해한 뒤 서비스를 만들 수는 없다.

중요한 것은 위험에 맞는 수준으로 이해하는 것이다.

일회성 스크립트나 폐기할 프로토타입이라면 입력과 출력, 데이터 손상 가능성, 재실행 가능 여부 정도만 확인해도 충분할 수 있다.

반면 인증, 결제, 개인정보, 재고, 데이터 마이그레이션처럼 실패했을 때 피해가 큰 영역은 더 깊이 이해해야 한다.

• 어떤 불변조건을 지켜야 하는가
• 중복 요청과 동시 실행을 어떻게 처리하는가
• 일부 단계만 성공하면 어떻게 복구하는가
• 장애를 어떻게 감지하는가
• 변경을 어떻게 중단하거나 되돌리는가

목표는 모든 코드를 기억하는 것이 아닌 중요한 결정을 내리고 문제가 생겼을 때 대응할 수 있을 만큼 이해하는 것이다.

 

코드가 자동화돼도 남는 것들

코드 이해 외에도 AI 시대에 쉽게 사라지지 않을 일들이 있다.

문제와 목적을 정하는 일

AI는 주어진 문제를 해결하는 데 강하지만, 무엇을 문제로 볼지는 별개의 문제다.

회원가입 전환율만 높이라고 하면 인증 절차를 약하게 만드는 것도 하나의 해결책이 될 수 있다. 누구의 어떤 문제를 해결할지, 그 과정에서 무엇을 지킬지는 사람이 정해야 한다.

트레이드오프를 판단하는 일

실무에는 하나의 정답이 없는 문제가 많다.

출시 속도와 유지보수성, 일관성과 가용성, 개인화와 개인정보 보호, 비용과 안정성 사이에서 선택해야 한다. AI는 장단점을 정리할 수 있지만, 어떤 손실을 감수할지는 제품과 조직의 상황에 따라 달라진다.

현실의 반응을 확인하는 일

AI가 만든 코드와 기획은 현실에 대한 가설이다.

테스트가 통과해도 사용자는 예상과 다르게 행동할 수 있고, 운영 환경에서는 테스트에 없던 장애가 발생한다. 결국 만들고, 실제로 사용해보고, 관찰한 뒤 다시 수정하는 과정이 필요하다.

책임지고 함께 운영하는 일

AI가 코드를 작성해도 장애가 발생했을 때 복구하는 주체는 조직이다.

누가 변경을 승인했는지, 누가 위험을 인수했는지, 문제가 생기면 누가 중단하고 되돌릴지 명확해야 한다.

앞으로는 누가 직접 코드를 작성했는지보다, 누가 시스템을 이해하고 책임질 수 있는지가 더 중요해질 수 있다.

DORA의 2025년 연구도 AI를 조직의 강점과 약점을 확대하는 증폭기에 가깝다고 설명한다.

테스트와 피드백 구조가 잘 갖춰진 조직은 AI의 속도를 활용할 수 있지만, 기존 과정이 불안정한 조직은 더 많은 변경을 만들면서 문제도 함께 키울 수 있다.

 

AI가 코드를 작성한 뒤 확인할 다섯 가지

복잡한 절차를 만들기보다, 중요한 변경이 끝날 때 다음 다섯 가지를 확인하는 것부터 시작할 수 있다.

1. 왜 바꿨는가
   해결하려는 문제와 이번에 하지 않기로 한 범위는 무엇인가.
2. 어떻게 동작하는가
   주요 데이터 흐름과 제어 흐름은 어떻게 이어지는가.
3. 무엇이 유지돼야 하는가
   깨지면 안 되는 불변조건과 보안·데이터 경계는 무엇인가.
4. 어떻게 실패하고 복구하는가
   중복, 타임아웃, 부분 실패, 재시작 상황에서 어떤 일이 생기는가.
5. 다음 변경을 할 수 있는가
   비슷한 요구사항이 추가됐을 때 어디를 수정해야 할지 설명할 수 있는가.

이 질문에 답할 수 있다면 모든 구현을 직접 작성하지 않았더라도 프로젝트에 계속 참여할 수 있다.

반대로 테스트가 통과했다는 사실만 알고 나머지를 설명할 수 없다면, 기능은 완성됐지만 팀의 이해는 따라오지 못한 상태일 수 있다.

마치며

AI가 코드를 더 많이 작성할수록 사람이 직접 코드를 작성하는 일의 비중은 줄어들 수 있다.

하지만 코드를 작성하는 일과 시스템을 이해하는 일은 같지 않다.

이해는 AI의 실수를 찾기 위해서만 필요한 것이 아니다.

다음 아이디어를 내고, 중요한 선택을 하고, 문제가 생겼을 때 대응하고, 팀과 함께 프로젝트를 이어가기 위해 필요하다.

발표의 마지막도 AI가 인간을 작업에서 빼는 데 그치지 않고, 오히려 더 깊이 이해하고 참여하게 만들 수 있다는 가능성을 강조한다.

결국 중요한 것은 그 변화가 왜 필요했고, 어떻게 작동하며, 다음에는 무엇을 할 수 있는지 사람이 알고 있는가이다.

 

Geoffrey Litt의 gist에 위 내용이 있다. 스킬로 만들어서 작업 후 직접 느껴보자.

explain-diff

explain-diff

 

 

---

출처

1. Geoffrey Litt, “Understanding is the new bottleneck”, AI Engineer 콘퍼런스 발표 및 글, 2026년 7월. (Geoffrey Litt)
   YouTube 발표 영상
2. Margaret-Anne Storey, “How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt”, 2026. (Margaret-Anne Storey)
3. Google Cloud DORA, “State of AI-assisted Software Development 2025”. (Dora)
4. Alberto Bacchelli·Christian Bird, Microsoft Research, “Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013. (Microsoft)