이해는 새로운 병목이다

요즘 회사에서 버전 차이가 6개월 정도 나는 두 스키마의 데이터를 마이그레이션하는 작업을 좀 하고 있는데… 문제는 내 서비스를 만든다고 프리 선언한 뒤로, 백단 실무를 신경을 안쓰고 있던 터라 진짜 마이그레이션 지옥이 펼쳐져 있다는 것이다.

물론 요즘은 대 에이전트님이 알아서 “딸깍” 마이그레이션 스크립트를 짜줄 수 있지만, 문제는 내가 이걸 이해할 수가 없다는 것이다.

아 대충 그냥 맞게 했겠거니…

LGTM 하고 넘어가는건데.. 사실 많이 찝찝하다.

요즘 이런 게 한 두번이 아니다.

불과 1~2년 전까지만 해도 AI가 짜주는 건 코드 조각이거나, 기능 수정 하나 정도여서 작업이 끝나면 그 diff를 직접 확인하고 “음… 개 이상한 짓거리를 해놨네?” 라고 혼쭐을 내거나 할 수 있었다.

근데 요즘은 기능 단위가 아니라 프로젝트 단위, 패치 단위를 그냥 에이전트가 전자레인지에 만두 데우듯이 “띵동~!” 하고 작성해버리니까

그 몇 만줄, 수십 개의 파일 diff가 있는 PR을 하나하나 확인하고 머지한다는게 거의 불가능에 가깝다.

그래서 앞에서 언급했듯, 그냥 “아 잘했겠지” 하고 구현 결과만 좀 QA 해보다가 머지하는 빈도수가 더 많아졌다. (예전에는 마크다운이라도 만들어서 변경 사항이나 개선점 보고서라도 받았었는데, 이것도 사실 받아보고 훑어보고 삭제하고 끝이라서 그만 뒀다. 2000줄짜리 보고서는…ㅋㅋ 어케 읽어요.)

근데, 보니까 그런 고민들은 요즘 나만 하는게 아닌 거 같았다.

대 AI시대로 넘어오면서, 거의 대부분의 개발자가 이해하는 것 자체를 생산성과 엿 바꿔먹었으니까… ㅋㅋㅋㅋㅋ

요즘 해커톤 준비한다고 잘 알지도 못하는 게임을 만들다 보니까, 더 이런게 좀 부각되는 거 같다.

그래서 인터넷을 좀 뒤져보다가 그 중에서 꽤나 도움이 될 만한 발표를 하신 분이 있길래 기록겸 정리겸 가져와봤다.

이해는 새로운 병목이다.

발표 제목은 “Understanding is the new bottleneck”.

원본은 Litt 본인 블로그 서면 버전에 발표 스크립트 그대로 올라와 있다. 발표에서 공개한 스킬 원본도 gist에 공개돼 있어서 두 개 다 보고 정리했다.

시작하는 얘기가 나랑 너무 똑같다. 뭐, 모두가 그러겠지만…

자기가 마라톤 바이브 코딩을 몇 시간째 돌리다가 어느 순간 완전히 맥락을 놓쳤다는 것. 에러에 빠진 게 아니라 무지에 빠졌다고 표현한다.

뭐가 어떻게 돌아가는지 전혀 모르겠다.

이 상태가 되면 에이전트를 이끌 수도, 다음에 뭘 만들지 결정할 수도 없어진다.

근데 이해가 왜 중요한 건데

“이해가 중요하다” 는 소리는 다들 한다. 근데 그 이유를 잘못 짚고 있단다.

흔한 대답이 검증하려고 이해한다는 거다. 에이전트가 짠 게 맞는지 확인하려고. 근데 문제는 요즘 에이전트가 자기 작업 검증하는 능력도 점점 늘고 있다는 거.

검증이 이유라면, 에이전트가 발전할수록 인간의 이해는 필요 없어진다. (실제로 AI inspector가 더 일을 잘한다. 나보다…)

Litt가 주장하는 진짜 이유는 참여하려고다.

프로젝트는 에이전트랑 한 번만 도는 게 아니라 수십 번, 수백 번 루프를 돈다.

그리고 시스템을 이해하고 있어야 다음에 뭘 만들지 창의적으로 떠올릴 수 있다는 거.

머릿속에 개념이 풍부해야 사고가 유창해지고, 그 유창함 없이는 프로젝트에 참여하는 능력 자체가 잘려나간다.

이해는 품질 검사 도구가 아니라 창의성의 원재료라는 거다.

이 프레임 전환이 진짜 핵심이다.

“에이전트가 똑똑해질수록 나는 놀아도 되겠지” 라고 생각하기 쉬운데, 오히려 반대라는 것.

에이전트가 검증까지 다 해주고 나면, 인간한테 남는 유일한 역할이 “다음 아이디어” 다.

근데 모르면? 다음 아이디어를 낼 수가 없다.

인지 부채

인지 부채가 기술 부채랑 구조적으로 똑같다.

애초에 기술 부채라는 것도 “일단 넘어가자” 에서 파생되니까.

단기적으로는 이해 안 하고 넘어갈 수 있는데, 결국 발목 잡힌다는 것.

“관여한 인간들이 그냥 줄거리를 놓쳐버린 상태” 가 된다고. 영화 보다가 딴 짓 하고 다시 보면 갑자기 이상한 놈이 튀어나와서 전개가 바뀌어버릴 수도 있으니까..

웃을수만은 없다. 몇 번 그랬으니까..ㅋㅋ

그럼 뭘 해야 하는데

재밌게 접근한다.

이해를 전달하는 방법 고민한 건 우리가 처음이 아니라는 것.

교육학이 수백 년 동안 갈고닦은 최고의 아이디어들을 훔쳐다 이 문제에 적용하자는 게 발표 나머지 세 파트다.

처방은 총 세 개다.

1. 설명 문서 + 퀴즈

에이전트가 작업을 끝낼 때마다 그게 나한테 설명해줄 기회다.

가장 나이브한 방법이 그냥 raw diff 읽는 건데 — 이건 알파벳 순서로 편집된 파일 뭉치라서 설명이 아니다. 그냥 파편이다.

Litt는 대신 /explain-diff 라는 자기 Claude 스킬을 만들어서 매일 쓴다. 이 스킬이 diff를 받으면 문서를 뽑아주는데, 네 섹션이 고정이다.

Background — 이 변경 관련해서 원래 시스템이 어떻게 생겼는지. 초심자용 깊은 배경 + 이 변경에 직접 관련된 좁은 배경 둘 다.
Intuition — 변경의 핵심 직관. 디테일 말고 본질. 토이 예시랑 다이어그램 많이 넣어서.
Code — 실제 코드 변경 워크스루. 이해 가능한 순서로 그룹핑.
Quiz — 5문항. PR을 진짜 이해했어야 풀 수 있는 중간 난이도. 함정 문제는 아니고.

발표에서 강조하는 설명의 두 원칙.

첫째, 배경부터 가르쳐라. 뭐가 바뀌었는지 보기 전에 원래 뭐가 있었는지부터 알아야 한다.

둘째, 디테일 전에 직관. 코드 보여주기 전에 이 변경이 뭘 하고 싶은지, 관련된 개념이 뭔지부터 말해줘야 한다. Litt가 든 예시가 이렇다 — “2D 드로잉 트릭으로 정원을 입체적으로 느끼게 만들기” 같은 한 줄 목표를 먼저 던지고, 등거리 투영이 뭔지 인터랙티브 도식으로 먼저 익히게 한다.

이걸 literate diff 라고 부른다.

산문으로 구조화된 diff. 합리적인 순서로 변경을 따라가면서 설명이랑 코드 스니펫이 섞여 있는 모양. raw diff 보다 리뷰가 빠르다는 게 Litt 주장.

여기서 진짜 아름다운 디테일이 하나 나온다.

Litt는 이 설명 패킷을 가끔 인쇄해서 카페에 들고 간다. 종이라서 덜 산만하니까.

AI 가 인터랙티브한 활동을 정적인 종이 리포트로 바꿔주는 거.

나는 이 대목이 진짜 좋았다.

나도 보고서를 뽑아보고 정리 문서를 안만들어 본게 아닌데, 이게 도통 눈에 들어오질 않았다. 근데 그게, 내 집중력 문제가 아닐 수도..? 있다는 이야기 같아서…ㅋㅋ

유퀴즈

여기서 퀴즈가 나온다.

우리는 실제로는 이해도 기억도 못 하면서 “읽었다” 라고 자기 자신을 속이기 너무 쉽다.

그래서 /explain-diff 문서 하단에 5문항 퀴즈를 넣고 직접 푼다. 규칙도 세워놨다.

퀴즈를 통과하기 전엔 코드를 남에게 보내지 않는다. 남의 코드 리뷰할 때도 똑같이 한다.

여기서 발표 통틀어서 제일 인상적인 개념어가 나오는데 — 퀴즈는 속도 조절기다.

AI 랑 일하면 루프가 인간 이해 속도보다 훨씬 빨리 돈다. 퀴즈는 “내가 진짜 이해했나?” 를 기계적으로 묻는 반작용의 힘.

이게 있어야 온전한 창의적 참여자로 남는다.

두 번째 처방: 마이크로월드

여기가 좀 몽글몽글하게 좋았다.

프랑스어 배우려고 프랑스 가는 것처럼. 그 속에 살아야 자연스럽게 직관적으로 이해할 수 있게 되는 원리도 적용이 된다.

이걸 코드에 적용하면 — 그 안에 살면서 시스템이 어떻게 굴러가는지 자연스럽게 직관되는 세계를 만들 수 있냐는 질문이 된다.

두 사례를 든다.

첫 번째, 프롤로그 디버거

프롤로그 인터프리터를 만들다가 내부 동작 직관이 안 잡혀서, 에이전트랑 같이 디버거를 만들었다. 로직 언어 실행을 스텝별로 밟고, 시간을 스크럽하고, 각 단계에서 스택에 뭐가 있는지 보고, 심지어 자기 자신한테 “좋아, 이 규칙 잘 적용됐네” 코멘트까지 남길 수 있는 도구.

중요한 건 이거다. 에이전트더러 디버깅시키는 것과 내가 디버깅할 도구를 만드는 것은 다르다.

직접 하는 게 이해를 쌓는다.

두 번째, 웹사이트 마이그레이션 커맨드 센터

개인 웹사이트를 프레임워크 갈아탈 때 Claude 가 스크립트를 써줬는데, 리뷰가 도저히 안 됐다.

새 프레임워크를 몰라서 “대충 맞는 것 같은데?” 밖에 못 하는 상태.

그래서 Claude 한테 비디오 게임을 만들어달라고 했다. 버튼 클릭해서 포팅을 단계별로 실행하고, 구 사이트랑 신 사이트를 나란히 띄워놓고 파일 트리 변화를 지켜보는 커맨드 센터.

새 사이트가 점진적으로 살아나는 걸 눈으로 지켜봤고, 손으로 직접 한 것만큼의 이해를 훨씬 빠르게 얻었다고 한다.

발표에서 제일 많이 인용되는 문장이 여기 나온다.

에이전트는 코드를 이해하는 것을 돕는 코드를 써줄 수 있다. 이건 큰 일이다.

내 입장에서는

이 발표가 나한테 왜 다르게 꽂혔냐면 — 팀이 없어서다.

팀 있는 개발자는 인지 부채가 쌓이면 누군가 지적해준다. PR 리뷰에서 “이거 왜 이렇게 됐어?” 하고 물어보는 동료가 있다.

근데 나는 없다. 내가 놓친 걸 놓쳤다고 말해줄 사람이 없다.

그러니까 발표에 나온 속도 조절기 개념이, 오히려 팀 없는 개발자한테 더 필수적인 장치일 수 있겠다는 생각이 들었다. 팀 있는 사람은 인간 리뷰어가 자연스럽게 조절기 역할을 해주는데, 나는 기계적인 규칙 없으면 그냥 폭주한다.

당장 다음주부터 본격적으로 해커톤 사전 과제 개발에 들어갈건데, 바로 한 번 적용을 해봐야겠다.

마치며

어차피 검증은 AI가 더 잘하니까, 계속 참여자로 남기 위해서 이해하자.

이게 사실 핵심 같다.

이 프레임을 받아들이면 “에이전트가 똑똑해질수록 인간 이해는 덜 중요해진다” 라는 말은 할 수 없게 된다.

에이전트가 검증을 다 해줄수록, 인간한테 남는 유일한 역할이 다음 아이디어를 내는 거고 그건 이해 없이는 불가능하니까.

내가 그동안 “아 잘했겠지” 하고 넘긴 순간마다, 잃은 건 사실 시간이 아니라 다음 아이디어를 낼 능력이었을 수도 있다.

마침.