이해가 새 병목이다 — Understanding is the new bottleneck

도발적 한 줄: 나는 에이전트가 짜준 코드를 사람이 여전히 이해해야 한다고 본다.

이 강연에서 왜 그런지 설명하고, 코드를 효율적으로 이해하기 위한 아이디어 몇 가지를 보여줄 것이다. 그럼 시작하자.

에이전트가 우리를 대신해 코드를 점점 더 많이 짜주고, 다들 알다시피 따라잡기가 갈수록 어렵다.

다행인 건 코드를 이해하는 길은 여러 개라는 사실이다. 디프를 한 줄씩 읽는 것만이 방법은 아니다.

이 강연의 대부분은 내 에이전트가 만들어낸 시스템을 이해하는 데 유용했던 기법들을 다룬다:

• 코드 설명 문서(code explainer docs)
• 내 이해도를 점검하는 퀴즈
• 내가 놀아볼 수 있는 마이크로월드(micro-worlds)

하지만 그 전에 더 근본적인 질문부터…

왜? 왜 이해해야 하지?

지금은 우리 스스로를 루프에서 빼내고 에이전트끼리 루프를 돌게 만들자는 시대가 아닌가? 에이전트가 더 똑똑해질수록 사람이 세부에 있을 필요는 오히려 줄어드는 것 아닌가?

이 질문에 이해가 중요하다 쪽에 서 있는 사람들조차 살짝 틀린 답을 갖고 있다고 나는 본다.

가능한 답 하나: 검증하기 위해 이해한다. 에이전트가 한 일이 맞는지 확인한다.

‘맞다’의 의미는 여럿이다 — 스펙과 부합하는가, 잘 설계됐는가… 하지만 근본적으로는 엄지 척 / 엄지 반박의 판정 문제다.

여기서 핵심: 에이전트는 자기가 한 일을 스스로 검증하는 데 점점 능숙해지고 있다. 이건 좋은 일이다. 내 에이전트가 실수를 안 하는 게 나는 좋다.

그런데 흠. 그럼 우리 인간은 어디에 남는가?

여기서 또 다른 답이 등장한다: 참여하기 위해 이해할 수 있다.

에이전트가 뭘 하고 있는지 배우면 나는 창작 과정의 능동적 참여자가 될 수 있다. 왜 이게 중요한지…

루프가 한 번으로 끝나는 프로젝트는 없다. 프로젝트는 에이전트와 여러 번, 여러 번 반복되는 루프다.

그리고 내가 지금 시스템에 대해 가진 이해는 그 시스템을 다음으로 진화시킬 아이디어를 낼 수 있는 능력의 일부다.

어떤 것을 앞으로 밀기 위해 창의적으로, 유창하게 생각하려면 머릿속에 풍부한 개념 집합이 필요하다. 그 유창성이 없으면 프로젝트에 참여할 수 있는 폭이 유의미하게 좁아진다.

덧붙여, 이 이야기는 인지 부채(cognitive debt) 개념과 밀접히 닿는다 — Margaret Storey가 정식화하고 Simon Willison이 대중화한 개념이다.

기술 부채와 비슷하다. 단기적으로는 무슨 일이 벌어지는지 이해하지 않고도 굴러갈 수 있지만, 결국은 물어뜯긴다.

좋다, 이해가 중요하다는 데는 동의하자.

그러면 다음 질문: 어떻게? AI와 함께 빠르게 움직이는 상황에서 이 인간 이해는 어떻게 쌓아야 하는가?

다행히 이해를 어떻게 전달할지 고민한 게 우리가 처음은 아니다. 나는 우리가 교육에서 영감을 얻을 수 있다고 본다. 교육이 만들어낸 최고의 아이디어들을 훔쳐 이 문제에 적용할 수 있을까?

오늘 이 시도를 어떻게 할 수 있는지 세 가지 기법을 공유하고 싶다.

첫째: 설명. 좋은 설명이란 무엇인가?

에이전트가 어떤 작업을 마칠 때마다, 그것은 설명을 위한 기회이자 하나의 산출물(artifact)이다.

가장 소박한 방식: 코드 디프를 읽는다. 바뀐 원자재 그 자체.

이렇게 물어보자:

가능한 최고의 설명은 어떤 모습일까? 인간이든 AI든, 나에게 잘 설명하기 위해 정말 세부까지 공들이는 팀이 있다면 그 결과물은 어떤 느낌일까?

내가 만든 답 하나. /explain-diff라는 스킬이다. 나는 매일 쓴다. 동료들 중에도 유용하다고 하는 사람이 많다.

이 스킬은 세심하게 구조화된 코드 설명 문서를 HTML · 마크다운 · Notion 문서로 출력한다. 팀에서 협업하며 이 설명 문서를 논의하기에 Notion이 좋다. (고지: 나는 Notion에서 일하니 편향이 있다.)

비디오 게임의 시점을 편집하는 예로, 이 설명 문서 안에 뭐가 들어 있는지 보자.

첫 번째 원칙: 배경 지식을 가르쳐줘라!

무엇이 바뀌었는지 다루기 전에, 이미 무엇이 있었는지부터 이해시켜라. 이 사례에서는 그 게임 엔진에 대해 나에게 알려준다.

두 번째 원칙: 세부보다 직관을 먼저.

코드가 나오기 전에, 이 변경의 목적을 명시한다 — “2D 드로잉 트릭으로 정원이 입체적으로 느껴지게 만든다” — 그리고 아이소메트릭 투영(isometric projection)이 무엇인지 관련 개념을 설명한다.

이 모든 것이 변경의 본질에 대한 내 직관을 만든다. 인간인 나를 따라잡게 해서 이해에서 동등한 참여자로 만든다.

인터랙티브 그림으로도 직관을 쌓을 수 있다.

여기서 나는 정원에 놓인 돌을 이리저리 끌면서 좌표가 어떻게 움직이는지 지켜보는 것으로 아이소메트릭 시점을 이해한다.

(이건 Notion이 최근 출시한 신기능을 쓴 것이다: 이제 페이지 안에 인터랙티브 HTML을 임베드할 수 있다.)

드디어 코드가 나온다. 하지만 일반적인 디프는 파일들이 알파벳 순으로 편집돼 나열된 더미이며 설명이 없다.

내가 “literate diff”라 부르는 것은 산문으로 구조화된다 — 합리적인 순서로 변경을 걸어가며 주변 설명과 임베드된 코드 스니펫이 함께 온다. 원시 디프보다 검토가 빠르다.

이 모든 것의 결과는 아름다운 설명 패킷 하나다. 나는 여전히 코드 디프를 읽지만, 이 문서를 항상 먼저 읽는다.

가끔은 이걸 프린트해 카페에 들고 간다 — 방해가 덜하니까.

아름답게도 아이러니하다: AI가 인터랙티브 활동을 내가 깊이 집중할 수 있는 정적인 종이 리포트로 바꿔놓다니 :)

딱 하나의 문제: 읽기는 힘든 일이다 😅

Andy Matuschak가 말했듯 “책은 작동하지 않는다”! 실제로는 붙잡거나 이해하지도 못했으면서 “읽었다”고 스스로 속기가 너무 쉽다.

이걸 어떻게 고칠까? 나는 Andy와 Michael Nielsen이 에세이 안에 간격 반복(spaced repetition) 퀴즈를 임베드한 작업에서 영감을 얻었다.

지금 나는 내 코드 설명 문서에도 비슷한 걸 한다. 문서 하단에 인터랙티브 퀴즈 — 그 변경에 관한 다섯 문항 — 이 있고, 나는 답을 시도한다.

내 원칙: 퀴즈를 통과할 수 있을 때까지는 코드를 다른 사람에게 보내지 않는다. 남의 코드를 리뷰할 때도 같은 원칙을 적용한다.

퀴즈는 속도 조절기다. AI와 일할 때 루프가 인간 이해의 속도보다 빠르게 굴러가기 쉽다.

퀴즈는 이걸 상쇄하는 힘이다: 나는 기계적으로 “내가 정말 이해했는가?”를 물어서 창작 참여자로 온전히 남는다.

자, explain-diff는 여기까지. 원한다면 스킬은 여기에 있다: HTML을 출력하는 변형과 Notion 페이지를 출력하는 변형 두 개.

다음 아이디어: 마이크로월드. 비저너리 교육자 Seymour Papert에서 영감을 받은 것이다.

Papert에게는 이런 아름다운 아이디어가 있었다 — 그가 Mathland에 살기(living in Mathland)라 부른 것. 수학을 배우고 싶으면 Mathland에 살아라 — 프랑스어를 배우려면 프랑스에 살듯. 아이들이 호기심의 결과로 수학을 자연스럽게 배우는 환경을 만들 수 있을까?

그럼 이걸 코드에 어떻게 적용할까? 내가 살면서 시스템이 어떻게 작동하고 어떻게 변하는지 자연스럽게 감으로 잡을 수 있는 세계를 만들 수 있을까?

작년에 나는 Prolog 인터프리터를 짜면서 내부에서 무슨 일이 벌어지는지 감을 잡느라 애먹었다.

에이전트와 함께 이 디버거를 만들었다. 내 논리 언어의 실행을 단계별로 걸어가며 — 시간축을 스크럽하고, 스택에 뭐가 있고 각 단계에서 어떤 규칙이 평가되는지 볼 수 있게 한다. 나 자신을 위해 코멘트도 남길 수 있었다 (“굿, 저 규칙이 잘 적용됐어”).

내가 디버깅하기 위한 도구를 만드는 것과, 에이전트에게 디버깅을 시키는 것 사이에는 큰 차이가 있다. 내가 직접 하는 쪽에서 나는 그 과정에 이해를 쌓는다.

또 다른 사례. 나는 개인 웹사이트를 한 프레임워크에서 다른 프레임워크로 이식하고 있었고 Claude가 그걸 하는 스크립트를 짰다. 그런데 리뷰하기가 너무 힘들었다: 새 프레임워크에 익숙하지 않아서 내가 할 수 있는 말은 “대충 맞게 보이는 것 같다” 정도였다.

그래서 Claude에게 비디오 게임을 만들어달라고 했다 — 내가 이식을 내 손으로 단계별로 해나가는 커맨드 센터, 눈에 보이는 효과와 파일 트리 변화가 함께 진행되는. 결과는 버튼을 눌러 이식을 한 걸음씩 진행하고, 옛 사이트와 새 사이트를 나란히 띄운 UI였다.

이 커맨드 센터에서 나는 새 사이트가 조금씩 살아나는 걸 지켜봤다. 그 경험은 내가 손으로 이식했을 때와 비슷한 이해를 남겼다 — 그러나 훨씬 빠르게, 전체 경험이 나를 위해 배치되어 있었기 때문에.

여기서 요점: 에이전트가 사람에게 다른 코드를 이해시키기 위한 코드 조각을 짤 수 있다.

이건 큰 일이다!

좋다, 마지막 기법: 공유 공간. 지금까지는 혼자 이해하는 이야기였다… 하지만 팀으로 일할 때는 함께 이해해야 한다.

당신과 다른 사람이 같은 멘탈 모델을 갖고 있을 때 대화는 효율적이다. 같은 이미지를 소환하는 공용 어휘가 있으면 즉시 잼(jam)하고 리프(riff)하고 창의적인 대화를 이어갈 수 있다. 그 공유된 구조가 없다면 이런 대화들은 훨씬 힘들다.

팀이 그 이해를 함께 쌓는 공용 환경을 만드는 것에 나는 정말 흥분한다. Notion이 결국 하려는 것과도 상당히 닿아 있다.

최근 Notion에서는 사람과 에이전트가 함께 일하도록 하는 기능을 아주 많이 출시하고 있다. 그래서 팀 전체가 사일로 안에서 각자 일하는 대신 공유된 이해를 쌓게 된다.

작은 예 하나: 이제 Notion 안에서 Claude와 Cursor 에이전트를 굴릴 수 있다. 나는 요즘 코딩의 상당 부분을 그렇게 한다.

그리고 그 에이전트가 Notion 안에서 기술 계획을 세울 때, 기본으로 협업 페이지가 되어 팀과 그 자리에서 코멘트를 달고 논의할 수 있다. 혼자가 아니라 함께 사고하기!

정리해보자. 오늘 우리는 코드를 이해하기 위한 기법들을 다뤘다… 하지만 사실 이건 훨씬 큰 문제라고 나는 본다.

사람이 사물이 어떻게 작동하는지 이해하는 것은 일반적으로도 여전히 중요하다! 검증만을 위해서가 아니라, 참여를 위해서.

놀랍게도, 새 아이디어가 아니다. 우리 컴퓨팅 분야의 기원까지 거슬러 올라간다…

50년 전 Alan Kay는 컴퓨터가 새로운 매체 — 책보다 나은 매체 — 가 될 수 있으며, 사람들에게 (특히 아이들에게) 세계를 어떻게 생각할지 가르칠 수 있다고 그렸다.

이 그림에서 아이들이 아이패드로 유튜브를 보는 것처럼 보일 수도 있지만 그게 아니다. 아이들은 인터랙티브 게임을 하면서 그 게임의 코드를 편집해 물리를 더 잘 이해하고 있다. 50년 전이다!!

이제 아마 이 밈이 이해될 것이다.

요점은 언제나 증강(augment)이었다. 단순 자동화가 아니라.

AI가 시뮬레이션 만들기를 이렇게 쉽게 만들어준 지금은 아름답다… AI에게 우리를 가르치게 하는 것은 컴퓨팅이 열어준 가장 큰 가능성 중 하나다.

이 사실은 미래에 대한 나의 낙관을 키운다!

도구를 제대로 짓기만 하면, 우리는 이전에 가능했던 것보다 세상을 훨씬 더 잘 이해할 수 있다. 스스로를 루프에서 빼기만 할 필요는 없다. 우리는 루프 안으로 더 깊이 들어갈 수도 있다. 선택은 우리에게 달렸다.

FIN