이해가 새로운 병목이다, AI 코딩 시대 개발자의 역할
핵심 요약 2026년 7월 노션의 제프리 리트가 AI Engineer 컨퍼런스에서 편 주장으로, 에이전트가 코드를 짜고 검증까지 맡으면서 개발의 병목이 코드 작성에서 사람의 이해로 옮겨갔다. 이해의 목적 변화와 실천법을 정리한다.
AI 에이전트가 코드를 대신 짜주면서 개발의 병목이 '코드를 얼마나 빨리 쓰느냐'에서 '그 코드를 얼마나 잘 이해하느냐'로 옮겨갔다. 2026년 7월 AI Engineer 컨퍼런스에서 노션(Notion)의 디자인 엔지니어 제프리 리트(Geoffrey Litt)가 발표한 Understanding is the new bottleneck의 핵심 주장이다. 리트는 이해의 목적 자체가 달라진다고 봤다. 예전에는 코드가 맞는지 검증하려고 읽었다면, 이제는 다음에 무엇을 시킬지 판단할 멘탈 모델을 쌓으려고 읽어야 한다는 것이다.
이 글은 코딩 에이전트와 함께 일하는 개발자 관점에서 리트의 주장과 그가 제안한 실천법을 정리한다. 특정 도구의 설치법이나 사용법을 다루지는 않는다.
왜 코드가 아니라 이해가 병목인가
병목이 옮겨간 이유는 두 가지다. 첫째, 에이전트가 쏟아내는 코드의 양이 사람이 따라 읽는 속도를 넘어섰다. 한 번의 요청으로 수십 개 파일이 한꺼번에 바뀌는 변경이 흔해지면서, 결과물을 만드는 일보다 그 결과물을 머릿속에 담는 일이 더 오래 걸린다. 둘째, 리트는 에이전트가 자기 코드를 스스로 검증하는 능력이 빠르게 좋아지고 있다고 말한다. 테스트를 돌리고 오류를 잡는 일이 점점 자동화되니, 정작 사람에게 남는 문제는 '이 코드가 맞나'가 아니라 '이 코드가 어떻게 돌아가는지 내가 아나'가 된다.
리트는 이렇게 개발자의 이해가 실제 코드에서 점점 멀어지는 상태를 '인지 부채(cognitive debt)'라는 말로 설명한다. 기술 부채가 나중에 갚아야 할 코드의 빚이라면, 인지 부채는 개발자 머릿속에 쌓이는 빚이다. 당장은 에이전트가 알아서 굴러가니 아무 문제가 없어 보이지만, 어느 순간 스스로 다음 수를 두지 못하게 된다.
그럼 코드를 왜 이해해야 하나?
검증이 아니라 '참여'하기 위해서다. 리트가 든 가장 중요한 구분이 이것이다. 에이전트가 검증을 점점 잘하게 되면 '맞는지 확인하려고 읽는다'는 이유는 약해진다. 그러나 다음 아이디어를 내고, 방향을 틀고, 설계를 손보는 일은 여전히 사람 몫이다. 그리고 그 일은 코드가 어떻게 짜여 있는지 알아야 할 수 있다. 리트는 매번의 협업이 끝났을 때 더 풍부한 멘탈 모델을 안고 나와야 그다음 창의적 도약이 가능하다고 정리한다.
같은 날 사이먼 윌리슨(Simon Willison)도 참여를 위한 이해(Understand to participate)라는 글에서 이 구분을 짚었다. '이해해서 검증한다'는 낡은 사고방식이 '이해해서 참여한다'로 바뀐다는 것이다. 두 관점의 차이는 아래 표로 정리된다.
| 관점 | 이해하는 이유 | 이해가 부족하면 |
|---|---|---|
| 검증 중심(과거) | 에이전트가 짠 코드가 맞는지 확인 | 버그를 놓친다 |
| 참여 중심(리트의 제안) | 다음 작업을 이끌 멘탈 모델 확보 | 무엇을 시킬지 판단하지 못한다 |
리트가 제안한 세 가지 실천법
리트는 흐트러진 이해를 되찾는 구체적인 방법 세 가지를 소개했다.
- 첫째, 설명 문서와 퀴즈다. 변경 내용을 알파벳순 파일 목록이 아니라 읽는 사람이 이해하기 좋은 순서(리트는 이를 '문학적 diff'라 부른다)로 풀어 쓴 문서를 에이전트가 만들게 한다. 리트는 여기에 5문항짜리 퀴즈를 붙여, 개발자가 변경을 제대로 이해했는지 스스로 확인한 뒤에야 코드를 공유하도록 하는 '속도 조절기(speed regulator)'로 쓴다.
- 둘째, 일회용 마이크로월드다. 시스템이 어떻게 동작하는지 직접 만져 보며 감을 잡도록, 에이전트가 인터랙티브한 시뮬레이터나 디버거를 그때그때 만든다. 리트는 한 단계씩 실행을 따라가는 프롤로그(Prolog) 디버거나, 옛 사이트와 새 사이트를 나란히 놓고 마이그레이션이 진행되는 모습을 실시간으로 보여주는 관제 센터(command center) UI를 예로 들었다. 그는 이 발상을 교육학자 시모어 페퍼트(Seymour Papert)에게서 빌려왔다고 밝혔다.
- 셋째, 공유 협업 공간이다. 이해가 한 사람에게만 고이지 않도록, 팀이 에이전트의 작업을 함께 보고 바로 코멘트를 남기는 공간을 둔다. 리트는 노션에서 에이전트 실행 결과에 팀이 즉시 의견을 다는 기능을 예로 들었다.
지금 당장 팀에서 무엇을 바꿀 수 있나
세 가지 실천법을 그대로 도입하기 어렵더라도, 원칙 몇 개는 오늘부터 적용할 수 있다.
- 설명하지 못하는 코드는 병합하지 않는다. 에이전트가 만든 변경을 동료에게 서너 문장으로 설명할 수 없다면, 아직 리뷰가 끝난 게 아니다.
- 에이전트에게 코드만 시키지 말고 '왜 이렇게 했는지'와 '어디를 먼저 봐야 하는지'까지 설명하게 한다. 결과물뿐 아니라 이해를 돕는 산출물도 함께 요구하라는 게 리트의 제안이다.
- 리뷰를 검사가 아니라 학습으로 다룬다. 변경을 읽고 나서 내 멘탈 모델이 한 뼘 자랐는지를 통과 기준으로 삼는다.
- 일부러 속도를 늦춘다. 리트가 말한 '속도 조절기'의 핵심은, 생성 속도가 이해 속도를 앞질러 갈 때 의식적으로 브레이크를 밟는 것이다.
이 변화는 도구 문제라기보다 습관 문제에 가깝다. 에이전트가 화면을 스스로 읽고 조작하며 점점 더 많은 일을 자율적으로 처리할수록, 개발자가 손을 놓는 지점과 이해가 끊기는 지점이 겹치기 쉽다. 리트의 결론은 하나로 모인다. 자동화가 사람을 대체하는 쪽이 아니라 사람의 역량을 키우는(augment) 쪽으로 에이전트를 써야, 다음 아이디어를 낼 사람이 계속 남는다.