AI가 코드를 더 빨리 쓸수록, 개발자는 이해에 더 오래 걸려요

AI가 코드를 더 빨리 쓸수록, 개발자는 이해에 더 오래 걸려요

AI 뉴스 썸네일

AI 코딩 도구는 몇 분 만에 기능을 만들고 수정안까지 내놓아요. 문제는 사람이 그 속도로 시스템의 구조와 변경 의도를 받아들이기 어렵다는 데 있어요. Geoffrey Litt는 코드 생성량보다 개발자의 이해 속도가 프로젝트 진행을 제한하기 시작했다고 봐요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
새 병목	AI가 코드를 만드는 속도와 사람이 이해하는 속도의 차이가 벌어져요	다음 변경을 설계할 사람이 시스템의 맥락을 놓칠 수 있어요
코드 설명	원시 코드 차이보다 배경, 목표, 구현 순서를 묶은 설명 문서를 먼저 읽어요	변경된 줄과 설계 의도를 함께 파악할 수 있어요
이해 확인	퀴즈와 조작할 수 있는 실행 환경으로 실제 이해 여부를 확인해요	읽었다는 느낌과 설명할 수 있는 상태를 구분해요
팀 협업	설명과 논의를 같은 공유 공간에 남겨요	개인별 AI 작업이 서로 다른 정신 모형을 만드는 문제를 줄여요

1. 코드 생성보다 이해가 느려진 시대

Geoffrey Litt는 2026년 7월 AI Engineer 행사에서 발표한 내용을 글로 옮겼어요. 출발점은 단순해요. AI 코딩 도구가 많은 코드를 빠르게 만들어도 개발자가 시스템을 이해하지 못하면 다음 아이디어를 구체적으로 제안하기 어려워져요. 구현 결과를 승인하는 데서 작업이 끝나지 않기 때문이에요. 실제 프로젝트는 목표를 바꾸고, 기능을 더하고, 실패 원인을 고치는 여러 번의 반복으로 진행돼요. 2

이해를 미룬 채 결과만 계속 받아들이면 ‘인지 부채’가 쌓여요. 당장은 기능이 빨리 늘지만, 시간이 지나면 왜 이런 구조를 택했는지 설명하기 어려워져요. 새 요구사항을 어디에 연결해야 할지도 판단하기 힘들어요. 기술 부채가 미래의 수정 비용을 키운다면, 인지 부채는 사람이 프로젝트 방향을 정할 수 있는 범위를 좁혀요.

728x90

Litt가 제안한 첫 번째 방법은 코드 설명 문서예요. 파일 순서대로 원시 코드 차이를 읽기 전에 기존 시스템의 배경, 이번 변경의 목표, 핵심 구현을 이해하기 좋은 순서로 묶어 읽어요. 필요한 코드 조각과 상호 작용형 도표도 함께 보여줘요. 이렇게 하면 개발자는 무엇이 바뀌었는지만 보는 대신 각 변경이 왜 필요한지 연결해서 볼 수 있어요.

설명 문서를 읽는 것만으로는 부족할 수 있어요. 글을 끝까지 읽고도 핵심 구조를 말로 풀지 못하는 경우가 있기 때문이에요. 그래서 설명 뒤에 퀴즈를 붙여 무엇이 바뀌었는지, 왜 그 구조를 썼는지, 다음 수정에 영향을 주는 제약이 무엇인지 답하게 해요. 퀴즈를 통과하기 전에는 코드를 다른 사람에게 넘기지 않는 식으로 작업 속도도 조절해요.

두 번째 방법은 시스템을 직접 조작해 보는 작은 실행 환경이에요. Litt는 Prolog 인터프리터의 실행 시간을 앞뒤로 움직이며 스택과 규칙 평가 과정을 보는 디버거를 예로 들었어요. 웹사이트 이전 작업에서는 기존 화면과 새 화면, 파일 트리 변화를 단계별로 볼 수 있는 명령 화면을 만들었어요. AI에게 문제 해결만 맡기지 않고 사람이 내부 동작을 탐색할 도구도 만들게 한 셈이에요.

팀에서는 설명 자료를 함께 볼 수 있어야 해요. 개인마다 별도의 AI 도구와 대화하면 결과물은 합쳐도 시스템을 바라보는 개념과 어휘가 달라질 수 있어요. 기술 계획, 설명 문서, 질문과 답변을 같은 공간에 남기면 팀원이 구현 전제를 확인하고 수정 이유를 공유하기 쉬워져요.

왜 중요한가요

AI 코딩 도구를 평가할 때는 생성한 코드의 양이나 작업 완료 시간만 보기 쉬워요. 하지만 기능을 만든 뒤 개발자가 구조를 설명하지 못한다면 다음 변경부터 검토 비용이 커질 수 있어요. 팀은 코드 리뷰에 ‘무엇을 바꿨나’와 함께 ‘왜 이 순서와 구조를 골랐나’를 남길 필요가 있어요. 2

바로 적용할 수 있는 기준도 분명해요. 큰 변경에는 한 페이지 분량의 배경과 설계 설명을 붙여요. 리뷰어가 핵심 흐름을 자신의 말로 설명할 수 있는지 확인해요. 실행 과정이 복잡하면 일회성 시각화나 단계별 디버거를 만들어요. 이런 도구는 제품에 들어가는 영구 코드가 아니어도 괜찮아요. 사람이 다음 결정을 내리는 데 필요한 이해를 얻으면 역할을 다한 거예요.

이 접근은 AI 사용을 늦추자는 주장과 거리가 있어요. 생성 속도를 그대로 활용하면서 사람이 프로젝트 방향을 놓치지 않도록 정보의 형태를 바꾸자는 제안이에요. 앞으로 개발팀의 생산성은 코드를 얼마나 빨리 받는지와 더불어, 그 코드를 얼마나 빠르게 설명하고 함께 이해할 수 있는지에 달릴 수 있어요.

참고 자료

1. 이해가 새로운 병목이다 — GeekNews
2. Understanding is the new bottleneck — Geoffrey Litt