이해가 새로운 병목이다: 에이전트가 코드를 쓰는 시대에 더 중요한 것

에이전트가 코드를 더 많이 대신 써 주는 시대에는, 우리가 코드를 얼마나 빨리 생성하느냐보다 얼마나 잘 이해하느냐가 더 중요해집니다.

겉으로 보기엔 모순처럼 들립니다. 자동화가 발전할수록 인간은 밖으로 빠져나가야 할 것 같은데, 실제로는 반대입니다. 이해가 있어야 다음 실험을 떠올리고, 결과를 해석하고, 프로젝트를 한 단계 더 밀어 올릴 수 있습니다.

먼저 결론부터 말하면, 이 글의 핵심은 “이해는 검증용 체크박스가 아니라 참여의 조건”이라는 점입니다. 에이전트가 일은 빨리 해도, 인간이 이해를 잃으면 창의적으로 개입할 수 없고 결국 프로젝트의 다음 루프를 만들기 어려워집니다.

기준 작성 시점 2026-07-15 · Geoffrey Litt의 원문 스냅숏 기준입니다.

이 글에서 다루는 내용:

배경: 왜 다시 “이해”인가

원문은 아주 단순한 질문에서 출발합니다. 에이전트가 점점 더 많은 코드를 쓰는 상황에서, 우리는 왜 여전히 코드를 이해해야 할까요?

대답은 “정답인지 확인하려고”만은 아닙니다. Geoffrey Litt는 이해의 목적을 verify와 participate로 나눕니다. 검증은 맞고 틀림을 가르는 일이고, 참여는 다음 변화의 방향을 함께 설계하는 일입니다.

이 차이는 작아 보이지만 중요합니다. 에이전트가 자기 검증까지 잘하게 될수록, 인간의 역할은 단순 심사위원이 아니라 맥락을 가진 공동 설계자로 이동합니다.

이 흐름은 OpenAI Codex Record & Replay처럼 작업을 재사용 가능한 형태로 남기는 시도와도 닿아 있고, OpenAI가 작업형 AI로 수렴하는 방식처럼 제품 자체가 작업 흐름을 품어 가는 방향과도 이어집니다.

원문에서 가장 마음에 드는 표현은 이 부분입니다. 프로젝트는 한 번의 루프가 아니라, 수많은 에이전트 루프의 연속이라는 점입니다.

지금 당장 잘 끝나는 것보다 더 중요한 건, 내가 그 결과를 보고 다음 아이디어를 낼 수 있느냐입니다. 이해가 얕으면 “대충 맞는 것 같다”에서 멈추지만, 이해가 충분하면 “이제 이 구조를 이렇게 바꿔보자”로 넘어갈 수 있습니다.

flowchart LR
    A[에이전트가 작업 수행] --> B[결과물 생성]
    B --> C[인간이 이해]
    C --> D[다음 아이디어/개선안]
    D --> A

여기서 이해는 문서 읽기만 뜻하지 않습니다. 모델이 만든 결과를 다시 설명할 수 있는지, 반대로 내가 만든 변경의 이유를 다른 사람에게 전달할 수 있는지가 핵심입니다.

이 관점은 AI 코딩 에이전트의 토큰 비용을 줄이는 로컬 LLM 라우터에서 다룬 “무엇을 모델에 넣을지” 문제와도 맞닿아 있습니다. 입력을 잘 고르는 것만큼, 결과를 사람이 이해 가능한 단위로 재구성하는 것도 중요합니다.

원문은 이해를 돕는 방법으로 세 가지를 제안합니다. 설명문서, 퀴즈, 마이크로월드입니다.

가장 먼저 떠올리기 쉬운 방법입니다. 에이전트가 일을 끝냈다면, 그 결과를 그냥 diff로 넘기지 말고 설명 가능한 산출물로 바꾸는 것입니다.

좋은 설명문서는 단순 요약이 아닙니다. 먼저 배경을 알려주고, 그다음 직관을 세우고, 마지막에 세부 변경을 보여줍니다. 그래야 읽는 사람이 “어디가 바뀌었는지”뿐 아니라 “왜 이렇게 바뀌었는지”를 잡을 수 있습니다.

원문에서 Geoffrey Litt는 이를 literate diff처럼 읽을 수 있는 설명 묶음으로 다룹니다. 핵심은 diff를 대체하는 게 아니라, diff를 이해 가능한 순서로 재배열하는 데 있습니다.

설명문서가 이해를 보여 주는 장치라면, 퀴즈는 이해를 검사하는 장치입니다.

원문은 코드 설명의 마지막에 스스로 풀어 보는 질문을 두고, 통과하지 못하면 아직 사람에게 보낼 단계가 아니라고 봅니다. 이 방식은 간단하지만 강력합니다. AI가 속도를 높여도, 인간의 이해 속도가 따라오지 못하면 결국 병목이 생기기 때문입니다.

마이크로월드는 작은 상호작용 공간입니다. 코드를 그냥 읽는 대신, 직접 움직여 보고 변화가 눈앞에서 보이게 만드는 도구입니다.

예를 들어 실행 흐름을 한 단계씩 넘겨 보는 디버거, 파일 변화를 옆에서 비교해 보는 포트 도구, 상태 전이를 손으로 눌러 보는 시뮬레이터가 여기에 들어갑니다. 이런 도구는 “설명”보다 한 단계 더 강하게, 몸으로 이해하게 만듭니다.

Tip 복잡한 변경일수록 "한 번에 읽히는 diff"보다 "조작 가능한 작은 세계"가 더 잘 먹힙니다. 사람이 손으로 돌려 볼 수 있어야 이해가 빠르게 붙습니다.

이해는 혼자만의 문제가 아닙니다. 팀 프로젝트에서는 서로 같은 mental model을 공유해야 대화가 빨라지고, 설계 논의가 덜 마릅니다.

원문이 흥미로운 지점도 여기입니다. 이제는 에이전트가 혼자 일하는 것이 아니라, 팀의 공유 공간 안에 들어와 함께 작업하는 장면이 더 중요해졌습니다. 문서와 코멘트, 계획과 결과가 한 공간에 붙어 있어야 팀 전체가 같은 맥락을 유지할 수 있습니다.

이 관점은 OpenGenerativeUI 살펴보기처럼 결과를 눈으로 확인하고 조작하는 UI를 붙이는 흐름과도 비슷합니다. 이해는 개인의 머릿속에만 있지 않고, 팀이 함께 만질 수 있는 형태가 될 때 더 강해집니다.

원문이 끝내 말하고 싶은 건 꽤 분명합니다. AI의 목표는 사람을 빼는 것이 아니라, 사람이 더 깊게 참여할 수 있게 만드는 것입니다.

그래서 이해는 사치가 아닙니다. 오히려 자동화가 고도화될수록 더 비싸지는 자원입니다. 우리가 다음 단계로 가려면, 에이전트가 만든 결과를 그냥 소비하는 데서 멈추지 말고 그것을 설명하고, 시험하고, 만져 볼 수 있어야 합니다.

제가 이 글에서 가져가고 싶은 한 문장은 이겁니다. “이해는 검증이 아니라 참여다.”