코드 생산이 아니라 이해가 병목이다 — AI 코딩 시대 진짜 병목 논쟁 정리

AI가 코드를 대량으로 쏟아내는 시대에, 개발자의 진짜 병목은 타이핑이 아니라 "그 코드를 이해하는 능력"으로 옮겨갔다는 주장이 2026년 7월 해외 개발 담론에서 정면으로 붙었습니다.

이 글은 한국어로는 아직 정리된 적 없는 삼각 논쟁을 한눈에 보여줍니다.

Geoffrey Litt의 "이해가 병목이다", Sean Goedecke의 "부분 이해가 정상이고 필요한 건 리뷰다", 그리고 Addy Osmani로 대표되는 "병목은 리뷰·검증으로 이동했다"는 세 입장을 비교하고, 실무자와 입문자가 무엇을 준비해야 할지까지 짚습니다.

2026년 7월 기준으로 확인된 원문과 데이터를 근거로 삼았습니다.

세 입장은 정면충돌이 아니라 강조점이 다른 삼각 구도입니다.
세 갈래 모두 "타이핑은 더 이상 병목이 아니다"에 동의하고,
병목이 이해냐 리뷰냐 검증이냐에서 갈립니다.
공통 결론은 하나입니다.
코드를 빨리 짜는 능력보다 "무엇이 맞는지 판단하는 눈"의 가치가 커졌다는 것입니다.

 

왜 지금 "병목이 어디로 갔나"가 논쟁이 되었나

예전에는 코드를 짜는 일 자체가 가장 오래 걸리는 단계였습니다.

그런데 에이전트형 코딩 도구가 등장하면서 상황이 달라졌습니다.

에이전트형 코딩 도구는 단순 자동완성이 아니라, 파일을 읽고 수정하고 명령까지 실행하는 도구에 가깝습니다.

코드 생산이 싸지자, 사람들은 "그럼 이제 사람이 가장 오래 붙잡는 일은 무엇인가"를 다시 묻기 시작했습니다.

Sonar가 발표한 2026 State of Code 보고서(개발자 1,100명 이상 설문 기준)를 보면 이 변화가 수치로 드러납니다.

오늘날 커밋되는 코드의 42%가 AI로 생성되거나 보조되며, 이는 2023년의 6%에서 크게 오른 수치입니다.

같은 보고서는 2027년에는 이 비율이 65%에 이를 것으로 전망했습니다.

생산이 이렇게 빨라지면 병목은 자연히 다른 곳으로 옮겨갑니다.

그 "다른 곳"이 어디냐를 두고 세 갈래 주장이 나온 것입니다.

---

세 입장은 무엇이 다른가

먼저 세 입장을 표 하나로 정리했습니다.

각 인물이 실제로 쓴 글과 핵심 주장을 그대로 옮겼습니다.

인물	대표 글	병목은 어디에 있나
Geoffrey Litt (Notion)	이해가 새로운 병목이다 (2026-07-02)	이해. 그것도 검증이 아니라 창의적 참여를 위한 이해
Sean Goedecke (GitHub)	코드베이스를 이해하지 못하는 것을 옹호함 (2026-07-11)	완전한 이해가 아니라 리뷰 능력. 부분 이해는 정상이다
Addy Osmani 외	아우터 루프를 소유하라 (2026-07-09)	리뷰·검증(아우터 루프). "맞다는 것을 증명하는" 단계

Geoffrey Litt는 Notion의 디자인 엔지니어입니다.

그의 주장은 이렇게 요약됩니다.

에이전트가 코드를 점점 더 많이 쓸수록, 가장 위험한 병목은 코드가 맞느냐가 아니라 "사람이 그 코드를 이해하는가"라는 것입니다.

여기서 Litt의 핵심 전환이 나옵니다.

이해는 검증을 위한 게 아니라 참여를 위한 것이라는 주장입니다.

에이전트가 스스로 검증을 잘하게 될수록, 사람이 코드를 이해해야 하는 진짜 이유는 "맞나 확인"이 아니라 "다음 아이디어를 낼 창의적 기여자로 남기 위해서"가 됩니다.

Litt는 이를 기술 부채에 빗대 "인지 부채"라고 불렀습니다.

이해 없이 에이전트에게 계속 맡기면, 사람이 그냥 흐름을 놓쳐버릴 수 있다는 것입니다.

Simon Willison도 같은 날 글을 올려 이 주장에 명시적으로 공감을 표했고, 그 덕에 담론이 빠르게 퍼졌습니다.

 

반대편에서는 "이해 못 해도 괜찮다"고 말한다

Sean Goedecke는 GitHub의 스태프 엔지니어입니다.

그가 7월 11일에 올린 "코드베이스를 이해하지 못하는 것을 옹호함"은 Litt의 담론에 대한 사실상의 암묵적 반론으로 읽힙니다.

다만 이 글이 Litt를 이름으로 직접 지목하지는 않으므로, "Litt를 겨냥해 반박했다"고 단정하기는 조심스럽습니다.

Goedecke의 논지는 이렇습니다.

규모가 크고 이직이 잦은 코드베이스에서는 완전한 이해가 아니라 부분적 이해로 일하는 게 정상이며, 그것은 실패가 아니라는 것입니다.

그는 충분히 큰 코드베이스에서는 모두가 틀린 이론으로 일한다고 표현했습니다.

대신 그가 강조하는 능력은 따로 있습니다.

바로 코드 리뷰 능력입니다.

Goedecke가 2025년 9월에 올린 다른 글은 이 논쟁 언저리에서 가장 큰 반응을 얻었습니다.

해커뉴스에서 192점과 197개 댓글이 달렸는데, 이는 Litt 글이 아니라 Goedecke의 리뷰 글에 붙은 반응이라는 점을 정확히 짚어둘 필요가 있습니다.

그 글의 요지는 "에이전트를 잘 쓰는 능력은 곧 코드 리뷰 능력"이라는 것입니다.

사람이 방향을 잡아주는 체스의 센타우르 비유처럼, 잘못된 방향을 잡아낼 기술이 없으면 에이전트도 금방 막힌다고 봤습니다.

흥미로운 점은 Goedecke가 이해를 무조건 부정하지는 않는다는 것입니다.

그는 다른 글에서 소프트웨어 엔지니어의 진짜 산출물은 프로그램 자체가 아니라 "프로그램이 어떻게 작동하는지에 대한 이론"이라는 Peter Naur의 고전 논의를 끌어옵니다.

그러면서 에이전트는 코드베이스의 이론을 계속 보유하지 못하고 매번 처음부터 새로 만든다고 지적합니다.

이 대목에서는 Litt와 부분적으로 같은 편에 서는 셈입니다.

---

세 번째 축, 병목은 "아우터 루프"로 옮겨갔다

세 번째 입장은 병목을 리뷰와 검증 쪽으로 콕 집어 말합니다.

Addy Osmani가 7월 9일에 올린 "아우터 루프를 소유하라"가 대표적입니다.

그는 작업을 두 층으로 나눕니다.

이너 루프는 에이전트가 조사하고 구현하고 검증하며 스스로 도는 자율 실행 사이클입니다.

아우터 루프는 사람이 반드시 소유해야 하는 생산의 경계입니다.

품질 기준, 내보낼지 막을지의 판정, 결과에 대한 책임, 그리고 취향이 여기에 들어갑니다.

Osmani의 문장 하나가 이 입장을 잘 요약합니다.

"모델이 코드 줄은 쓸 수 있지만, 판정은 나의 몫이다. 에이전트는 당신이 리뷰할 수 있는 것보다 더 많이 배포한다."

이 주장은 앞서 본 Sonar 데이터로도 뒷받침됩니다.

Sonar 2026 State of Code(개발자 1,100명 이상 설문 기준)에 따르면, 개발자의 96%는 AI 코드를 완전히 신뢰하지 않지만, 항상 검증한다고 답한 사람은 48%에 그쳤습니다.

여기에 38%는 "AI 코드를 리뷰하는 게 사람 동료의 코드를 리뷰하는 것보다 더 힘들다"고 답했습니다.

Sonar는 이 현상을 "검증 병목"이라고 이름 붙였습니다.

개인적으로는 이 세 입장이 다른 산을 오르는 게 아니라, 같은 산의 다른 능선을 짚고 있다고 봅니다.

Litt는 "이해해야 다음 아이디어가 나온다", Osmani는 "이해한 만큼만 판정할 수 있다"고 말하는데, 결국 사람이 붙잡아야 할 지점은 겹칩니다.

 

병목이 옮겨갔다는 말도 과장일 수 있다

균형을 위해 반대 목소리도 짚어야 합니다.

"병목이 코딩에서 리뷰로 이동했다"는 서사 자체가 과장이라는 반론이 있습니다.

The New Stack에는 "AI 코드 생성이 병목을 리뷰로 옮긴다"는 글과 "AI는 병목을 코딩에서 리뷰로 옮기지 않았다"는 글이 나란히 존재합니다.

InfoQ가 소개한 한 사례에서는 "코딩은 애초에 병목이 아니었다"는 시각도 등장합니다.

다만 이 반론 글들은 본문 일부를 확인 과정에서 전문으로 회수하지 못했으므로, 인용해 쓰려면 발행 전 원문 재확인이 필요합니다.

핵심은 이 담론이 아직 하나로 합의된 결론이 아니라는 점입니다.

커뮤니티 반응도 회의와 피로 쪽으로 기울어 있습니다.

"동료가 AI로 PR을 만드는 건 공짜지만, 내가 그걸 반박하는 데는 시간이 든다"는 리뷰 비대칭 불만이 대표적입니다.

"AI의 실패 양상은 사람 실수와 달라서 일반적인 코드 리뷰로는 잡기 어렵다"는 지적도 나옵니다.

---

실무자와 입문자는 무엇을 준비해야 하나

세 입장이 강조점은 달라도, 실무에 주는 메시지는 한 방향으로 모입니다.

개발자의 레버리지가 코드 생산량이 아니라 판단과 구조적 리뷰, 그리고 판정 능력으로 옮겨갔다는 것입니다.

실무자라면 이해를 강제하는 장치를 루틴으로 만들어 두는 게 도움이 됩니다.

Litt가 제안한 이해도 퀴즈, 즉 "스스로 흐름을 설명하지 못하면 남에게 코드를 넘기지 않는다"는 규칙이 한 예입니다.

변경 전에 흐름 하나를 처음부터 끝까지 스스로 이해해 보거나, 에이전트에게 방금 만든 코드를 되설명하게 하는 방법도 있습니다.

Osmani가 말한 "판정은 내가 소유한다"는 원칙도 함께 새길 만합니다.

입문자와 비전공자에게는 조금 다른 이야기가 필요합니다.

채용 흐름상 주니어도 에이전트 사용이 기본이 되어가는데, "좋은 코드가 무엇인지" 감이 없으면 리뷰 자체가 불가능합니다.

그래서 AI 시대 학습의 핵심은 코드를 빨리 짜는 법이 아니라 "무엇이 맞는지 판단하는 눈"을 기르는 쪽으로 옮겨가고 있습니다.

단, 이것이 "입문 자체가 불가능해졌다"는 뜻은 아닙니다.

입문이 막힌 게 아니라 학습의 우선순위가 바뀐 것에 가깝습니다.

이 흐름은 앞서 정리한 엔지니어링 진화, 주니어 개발자의 AI 시대, 그리고 AI 시대에 무엇을 공부해야 하는가를 다룬 글들과도 이어집니다.

 

자주 묻는 질문

결국 이해가 병목인가, 리뷰가 병목인가

같은 현상을 두 방향에서 본 것에 가깝습니다.

Litt는 "창의적 참여를 위한 이해"에, 아우터 루프 담론은 "출하 전 검증"에 방점을 둡니다.

두 쪽 모두 "타이핑은 더 이상 병목이 아니다"라는 전제에는 동의합니다.

그럼 코드를 이해하지 못해도 괜찮은가

Goedecke는 큰 시스템에서 부분 이해는 정상이라고 봅니다.

다만 잘못된 방향을 잡아낼 리뷰 능력은 여전히 필수이므로, 이해를 아예 0으로 만들어도 된다는 뜻은 아닙니다.

주니어와 비전공자에게는 어떤 의미인가

코드 생산 능력보다 "무엇이 맞는지 판단하는 눈"의 가치가 커졌습니다.

채용 흐름에 변화는 있지만, 입문 자체가 막혔다고 볼 근거는 아직 없습니다.

정리하면

AI 코딩 시대의 병목 논쟁은 이해냐, 리뷰냐, 검증이냐를 두고 세 갈래로 갈립니다.

세 입장은 정면충돌이 아니라 강조점이 다른 삼각 구도이고, "타이핑은 더 이상 병목이 아니다"라는 지점에서 만납니다.

병목이 옮겨갔다는 서사 자체를 의심하는 목소리도 있으니, 어느 한쪽을 정답으로 못박기보다 세 축을 함께 보는 편이 현실에 가깝습니다.

개인적으로는 도구가 코드를 아무리 빨리 만들어도, 결국 "이게 맞는지 아는 사람"의 가치는 줄지 않는다고 생각합니다.

지금 준비해 둘 것은 타이핑 속도가 아니라 판단하는 눈입니다.