AI 시대의 진짜 병목은 코드가 아니라 이해다

 

요즘 에이전트한테 코딩을 맡기다 보면 이상한 기분이 들 때가 있습니다. 분명 코드는 어제보다 훨씬 빨리 나오는데, 프로젝트가 그만큼 빨리 굴러가는 느낌은 아니라는 겁니다. 이 찝찝함의 정체를 정확하게 짚어주는 글을 긱뉴스에서 발견했습니다. Notion에서 일하는 Geoffrey Litt의 에세이 "Understanding is the new bottleneck"인데, 제목 그대로 이제 병목은 코드 생성이 아니라 인간의 이해 속도라는 이야기입니다.

코드는 쏟아지는데 이해가 못 따라간다

에이전트가 만들어내는 코드의 양은 계속 늘어나는데, 사람이 그걸 소화하는 속도는 그대로입니다. 글에서는 이걸 코드 더미가 사람 주변에 계속 쌓여가는 이미지로 표현합니다. diff를 한 줄씩 읽는 전통적인 방식으로는 에이전트의 작업 속도를 도저히 따라갈 수 없다는 거죠.

여기서 흔한 반응은 "그래도 검증은 사람이 해야지"입니다. 명세에 맞는지 확인하고, 구조가 괜찮은지 보고, 승인이나 거부를 결정하는 역할이요. 그런데 저자는 이 관점에 한 방을 날립니다. 에이전트는 자기가 만든 결과를 직접 실행하고 검사하고 오류를 찾는 자체 검증 능력도 점점 좋아지고 있다는 겁니다. 검증마저 에이전트가 더 잘하게 되면, 사람은 어디에 남게 될까요?

이해는 검증이 아니라 참여를 위한 것

저자의 답은 이렇습니다. 코드를 이해해야 하는 진짜 이유는 합격/불합격 도장을 찍기 위해서가 아니라, 창작 과정의 능동적인 참여자로 남기 위해서라는 겁니다.

실제 프로젝트는 에이전트에게 한 번 시키고 결과를 받는 단일 루프가 아닙니다. 목표 설정, 구현, 확인, 수정, 확장으로 이어지는 수많은 루프의 연속이고, 각 루프에서 사람이 가진 시스템 이해도가 다음 아이디어의 질을 결정합니다. 이해가 부족하면 에이전트 결과물에 "대략 맞아 보이네요" 정도로 반응할 수는 있어도, 프로젝트가 어디로 가야 하는지 주도할 수는 없습니다.

이해 없이 에이전트의 결과를 계속 받아들이면 단기적으로는 빠르지만, 기술 부채처럼 인지 부채(cognitive debt)가 쌓인다. 코드가 왜 이 구조가 됐는지, 새 요구사항을 어디에 붙여야 할지, 다음 변경이 타당한지를 판단할 수 없게 된다.

"인지 부채"라는 표현이 특히 와닿았습니다. 에이전트 코딩을 몇 달 하다 보면 내 프로젝트인데 남의 코드베이스 같은 순간이 오는데, 그게 바로 인지 부채가 쌓인 상태입니다.

그래서 어떻게 하자는 건가 - 교육의 방법론을 빌려오기

흥미로운 건 해결책의 방향입니다. 저자는 "사람에게 빠르게 이해를 만들어주는 문제"는 교육이 오랫동안 다뤄온 문제라며, 교육학의 도구들을 코드 이해에 가져옵니다.

1. 설명 문서 - diff를 이야기로 바꾸기

저자가 만든 /explain-diff라는 스킬은 에이전트의 변경 사항을 구조화된 설명 문서로 만들어줍니다. 핵심은 순서입니다. 코드를 바로 들이밀지 않고, 기존 시스템의 배경지식 → 변경의 목표 → 필요한 개념 설명 → 그다음에야 실제 코드 순으로 안내합니다. 게임 렌더링을 바꾼 사례라면 등각 투영이 뭔지부터 설명하고 코드로 들어가는 식이죠.

일반적인 diff가 재료를 파일명 순으로 쌓아둔 것이라면, 이런 서술식 diff(literate diff)는 변경 과정을 하나의 이야기로 편집한 것에 가깝습니다. 설명을 먼저 읽고 raw diff를 보면 각 코드 조각이 왜 존재하는지 알고 읽게 되어 리뷰 속도도 빨라진다고 합니다.

2. 퀴즈 - AI 루프의 속도 조절 장치

설명 문서를 읽었다고 이해한 건 아닙니다. 눈으로 따라가기만 해도 이해했다고 착각하기 쉬우니까요. 그래서 저자는 문서 끝에 변경 사항에 관한 퀴즈를 넣고, 퀴즈를 통과해야 코드를 다른 사람에게 보낼 수 있다는 규칙을 씁니다. 무엇이 바뀌었는지, 왜 이 구조인지, 다음 변경에 영향을 주는 제약이 뭔지 설명할 수 없으면 속도를 늦추고 이해를 보충해야 합니다. 퀴즈가 지식 평가가 아니라 속도 조절 장치라는 관점이 신선했습니다.

3. 마이크로월드 - 직접 만져보는 작은 세계

세 번째는 교육자 Seymour Papert의 아이디어에서 온 마이크로월드입니다. 프랑스어를 배우려면 프랑스에서 살아야 하듯, 시스템을 이해하려면 그 시스템이 작동하는 작은 세계에 들어가 직접 조작해봐야 한다는 겁니다.

저자는 Prolog 인터프리터를 만들 때 실행 시간을 앞뒤로 이동하며 스택과 규칙 평가를 들여다보는 전용 디버거를 에이전트와 함께 만들었고, 웹사이트 프레임워크 이전 작업에서는 마이그레이션을 버튼 하나씩 눌러 단계별로 실행하면서 기존 사이트와 새 사이트를 나란히 비교하는 게임 같은 명령 센터를 만들게 했습니다. 전체 변환을 한 번에 돌리는 대신 새 사이트가 단계적으로 살아나는 과정을 직접 경험한 거죠.

여기서 중요한 구분이 나옵니다. "에이전트가 문제를 대신 해결하는 것"과 "에이전트가 사람이 문제를 탐색할 도구를 만들어주는 것"은 완전히 다른 결과를 낳습니다. 전자는 결과만 남고 이해는 늘지 않지만, 후자는 사람이 가설을 세우고 확인하는 탐색 과정을 제공합니다. AI로 코드를 만드는 비용이 낮아진 덕분에, 특정 사람과 특정 작업만을 위한 일회용 학습 도구를 만드는 게 현실적인 선택지가 됐다는 점도 재밌는 포인트입니다.

팀이라면 이해도 공유되어야 한다

개인의 이해만으로는 부족합니다. 각자가 자기 에이전트와 고립되어 작업하면, 결과물은 합쳐져도 이해는 합쳐지지 않습니다. 같은 용어를 다른 의미로 쓰고, 기술적 계획의 전제를 공유하지 못하게 되죠. 그래서 에이전트의 산출물을 개인 터미널에 가두지 말고, 팀원이 댓글 달고 질문하고 수정할 수 있는 공유 문서 위에 남기라는 제안입니다. 팀의 AI 도입이 개인 생산성 문제가 아니라 팀 전체의 공유 멘탈 모델을 만드는 문제라는 지적은 조직에서 AI 도구를 도입 중이라면 곱씹어볼 만합니다.

내 생각 - 검증 게이트보다 이해 게이트

 

이 글이 좋았던 건 "AI 코드를 믿지 말고 다 읽어라" 같은 뻔한 결론이 아니라서입니다. 다 읽는 건 이미 물리적으로 불가능해지고 있고, 그렇다고 안 읽으면 인지 부채가 쌓입니다. 저자의 답은 제3의 길입니다. 이해를 만드는 비용 자체를 AI로 낮추자는 것.

당장 적용해볼 만한 것도 있습니다. 에이전트가 큰 변경을 마쳤을 때 "이 변경을 배경지식부터 시작하는 설명 문서로 만들어줘, 마지막에 퀴즈 5개 넣어서"라고 요청하는 건 오늘부터 할 수 있는 일입니다. 이해가 안 되는 시스템이 있으면 문서를 요청하는 대신 "이걸 직접 조작하며 볼 수 있는 시각화 도구를 만들어줘"라고 해보는 것도요. 코드를 이해하기 위한 코드를 생성한다는 발상의 전환이, 이 글에서 가져갈 가장 실용적인 아이디어라고 생각합니다.

Alan Kay가 50년 전에 그렸던 컴퓨터의 모습이 수동적으로 영상을 보는 기계가 아니라 시뮬레이션을 조작하며 개념을 이해하는 동적 매체였다는 마무리도 좋습니다. AI의 목적을 사람을 루프에서 빼는 것에만 두면 사람은 시스템 바깥으로 밀려나지만, 이해를 돕는 도구를 만드는 데 쓰면 사람이 오히려 더 깊이 루프 안으로 들어갈 수 있습니다.

출처

• 긱뉴스 토론: https://news.hada.io/topic?id=31429
• 원문: Understanding is the new bottleneck - Geoffrey Litt