이 글은 2026년 7월 AI Engineer 콘퍼런스에서 한 발표를 글로 옮긴 것입니다. 트위터 스레드로도 공유했습니다.
과감한 주장: 에이전트가 쓰는 코드를 우리가 이해하는 일은 여전히 중요합니다!
바로 시작하죠.
에이전트가 우리 대신 점점 더 많은 코드를 씁니다. 따라가기가 점점 힘들어진다는 건 모두 압니다.
그런데 좋은 소식이 있습니다. 코드를 이해하는 방법은 여러 가지입니다! diff를 한 줄씩 읽는 게 유일한 길은 아닙니다.
이 발표는 대부분 제 에이전트가 만드는 시스템을 이해하는 데 도움이 됐던 방법을 다룹니다.
- 코드 설명서
- 이해를 확인하는 퀴즈
- 직접 만져보며 시스템을 파악하는 microworld
하지만 먼저 더 기본적인 질문을 던져야 합니다.
왜 이해해야 하나
왜? 왜 이해해야 할까요?
이제 우리는 루프에서 빠지고 에이전트끼리 알아서 돌게 놔둬야 하는 것 아닌가요? 에이전트가 똑똑해질수록 우리가 세부에 관여하는 일은 덜 중요해지는 것 아닌가요?
많은 사람이, 심지어 이해를 중시하는 사람들조차 이 질문에 조금 틀린 답을 갖고 있다고 봅니다!
한 가지 가능한 답: 우리는 검증하려고 이해합니다. 에이전트의 작업을 확인하고 맞는지 봅니다.
맞다는 건 여러 가지를 뜻합니다. 명세와 일치하는가, 구조가 탄탄한가. 하지만 근본적으로는 통과냐 아니냐를 가르는 질문입니다.
그런데 문제가 있습니다. 에이전트는 자기 작업을 검증하는 실력이 점점 좋아집니다. 이건 좋은 일입니다! 제 에이전트가 실수를 안 하면 저도 좋습니다.
하지만 음, 그러면 우리 인간은 어디에 남을까요?
여기서 또 다른 답이 나옵니다: 우리는 참여하려고 이해할 수 있습니다.
에이전트가 무엇을 하는지 배우면 창작 과정에 능동적으로 참여할 수 있습니다. 이게 왜 중요한지 보겠습니다.
루프는 한 번으로 끝나지 않습니다! 프로젝트는 에이전트와 함께 도는 아주 많은 루프입니다.
그리고 시스템을 잘 이해할수록 이것을 다음 단계로 발전시킬 아이디어를 더 잘 떠올릴 수 있습니다.
무언가를 앞으로 나아가게 할 방법을 창의적이고 막힘없이 생각하려면 머릿속에 풍부한 개념이 있어야 합니다. 그 유창함이 없으면 프로젝트에 참여하는 능력이 눈에 띄게 좁아집니다.
참고로 이건 Margaret Storey와 Simon Willison이 널리 알린 인지 부채(cognitive debt) 개념과 밀접합니다.
기술 부채와 같습니다. 무슨 일이 벌어지는지 몰라도 단기적으로는 넘어갈 수 있지만, 결국 발목을 잡습니다.
좋습니다, 이해가 중요하다는 건 알겠습니다.
그러면 다음 질문이 나옵니다. 어떻게? AI와 함께 빠르게 움직이면서 어떻게 인간의 이해를 쌓을까요?
사실 이해를 어떻게 전달할지 고민한 게 이번이 처음은 아닙니다. 저는 교육에서 영감을 얻을 수 있다고 봅니다. 교육을 위해 나온 최고의 아이디어를 훔쳐 와서 이 문제에 적용할 수 있을까요?
방법 1: 설명
에이전트가 어떤 작업을 끝낼 때마다 설명, 즉 결과물을 만들 기회가 생깁니다.
가장 단순하게는 코드 diff를 읽으면 됩니다. 바뀐 원재료 그 자체죠.
하지만 이렇게 물어보면 어떨까요?
최고의 설명은 어떤 모습일까요? 사람이든 AI든, 무언가를 잘 설명하려고 세부까지 공들이는 팀이 있다면 어떤 느낌일까요?
여기 한 가지 답이 있습니다. 저는 /explain-diff라는 스킬을 만들어 매일 씁니다. 동료도 여럿이 유용하다고 했습니다.
이 스킬은 깔끔하게 정리된 코드 설명서를 HTML, 마크다운, Notion 문서로 뽑아냅니다. Notion은 이런 설명서를 팀이 함께 보고 논의하기 좋은 곳입니다. (밝혀두자면 저는 Notion에서 일하니 편향이 있습니다.)
비디오 게임의 시점을 바꾸는 예로 이 설명서에 뭐가 들었는지 보겠습니다.
첫 번째 원칙: 배경 지식을 가르쳐 주세요!
무엇이 바뀌었는지 다루기 전에, 원래 있던 게 무엇인지부터 이해하게 도와줍니다. 이 경우에는 게임 엔진을 가르쳐 줍니다.
두 번째 원칙: 세부보다 직관이 먼저.
코드에 들어가기 전에 목표부터 말합니다. "2D 그리기 기법으로 정원을 입체감 있게 만들자." 그리고 아이소메트릭 투영이 무엇인지 같은 관련 개념을 설명합니다.
이 모든 게 변경의 핵심에 대한 제 직관을 쌓아줍니다. 인간인 저를 따라잡게 해줘서, 이해에 동등하게 참여할 수 있게 합니다.
상호작용 그림으로도 직관을 쌓을 수 있습니다.
여기서는 정원의 돌을 이리저리 끌어당기며 좌표가 어떻게 움직이는지 보면서 아이소메트릭 시점을 이해하고 있습니다.
(이건 Notion이 막 내놓은 새 기능입니다. 이제 페이지 안에 상호작용 HTML을 넣을 수 있습니다.)
드디어 코드에 다다릅니다. 그런데 흔한 diff는 알파벳 순으로 편집된 파일 더미일 뿐, 아무 설명이 없습니다.
제가 "문학적 diff(literate diff)"라 부르는 건 산문처럼 이어져 있습니다. 변경을 이치에 맞는 순서로 짚어가며 주변 설명과 코드 조각을 함께 담습니다. 원본 diff보다 검토가 빠릅니다.
이 모든 것의 결과물은 멋진 설명서 묶음입니다. 저는 코드 diff도 여전히 읽지만, 항상 이걸 먼저 읽습니다.
가끔은 출력해서 카페에 들고 갑니다. 방해가 덜하거든요.
아름답게 역설적입니다. AI가 상호작용 활동을 제가 깊이 몰입할 수 있는 정적인 종이 보고서로 바꿔줍니다 :)
문제가 하나 있습니다. 읽기는 고된 일입니다 😅
Andy Matuschak가 말하듯 "책은 작동하지 않습니다"! 실제로는 기억하거나 이해하지 못했으면서 다 읽었다고 스스로 착각하기가 너무 쉽습니다.
이걸 어떻게 고칠까요? 저는 Andy와 Michael Nielsen이 에세이에 간격 반복 퀴즈를 넣은 작업에서 영감을 얻었습니다.
이제 제 코드 설명서에도 비슷한 걸 넣습니다. 설명서 맨 아래에 변경에 대한 다섯 문제짜리 상호작용 퀴즈가 있고, 저는 그걸 풀어봅니다.
제 규칙은 이렇습니다. 퀴즈를 통과하기 전까지는 코드를 다른 사람에게 보내지 않습니다. 남의 코드를 검토할 때도 똑같이 합니다.
퀴즈는 속도 조절기입니다. AI와 일하다 보면 루프가 인간의 이해 속도보다 빠르게 돌기 쉽습니다.
퀴즈는 그 균형을 잡아주는 힘입니다. "내가 정말 이해했나?"를 기계적으로 물어서, 온전한 창작 참여자로 남게 해줍니다.
좋습니다, 이게 explain-diff입니다. 원하면 여기 스킬이 있습니다. HTML이나 Notion 페이지로 뽑는 두 가지 판이 있습니다.
방법 2: microworld
다음 아이디어는 microworld입니다. 선구적 교육자 Seymour Papert에게서 영감을 얻었습니다.
Papert에게는 수학나라(Mathland)에 살기라 부른 아름다운 아이디어가 있었습니다. 수학을 배우고 싶으면 수학나라에 살아라, 프랑스어를 배우고 싶으면 프랑스에 가서 사는 것처럼. 아이들이 호기심을 따라 자연스럽게 수학을 배우는 환경을 만들 수 있을까요?
이걸 코드에 어떻게 적용할까요? 직접 들어가 살면서 시스템이 어떻게 돌아가고 어떻게 바뀌는지 자연스럽게 감 잡는 세계를 만들 수 있을까요?
작년에 저는 Prolog 인터프리터를 만들고 있었는데 내부에서 무슨 일이 벌어지는지 감이 안 잡혀 애를 먹었습니다.
그래서 에이전트와 함께 이 디버거를 만들었습니다. 제 논리 언어의 실행을 한 단계씩 밟을 수 있게 해줬죠. 시간을 앞뒤로 훑고, 스택에 뭐가 있는지, 각 단계에서 어떤 규칙이 평가되는지 볼 수 있었습니다. 저 자신에게 메모도 남길 수 있었고요("좋아, 저 규칙을 제대로 적용했군").
나를 위한 디버깅 도구를 만드는 것과 에이전트에게 디버깅을 맡기는 것 사이에는 큰 차이가 있습니다. 직접 하면 그 과정에서 이해가 쌓입니다.
또 다른 예입니다. 저는 개인 웹사이트를 한 프레임워크에서 다른 프레임워크로 옮기고 있었고, Claude가 그 작업을 하는 스크립트를 썼습니다. 그런데 검토하기가 무척 어려웠습니다. 새 프레임워크에 익숙하지 않아서 "그럭저럭 맞아 보이네" 정도밖에 말할 수 없었죠.
그래서 Claude에게 비디오 게임을 만들어 달라고 했습니다. 제가 직접 한 단계씩 이식하는 관제 센터였습니다. 눈에 보이는 효과와 파일 트리가 바뀌는 걸 지켜보면서요. Claude는 버튼을 눌러 이식을 한 단계씩 실행하는 UI를 만들어 줬고, 옛 사이트와 새 사이트가 나란히 돌아갔습니다.
이 관제 센터에서 새 사이트가 조금씩 살아나는 걸 지켜봤습니다. 손으로 직접 한 것과 비슷한 이해가 남았는데, 훨씬 빨랐습니다. 전체 경험이 제 앞에 펼쳐져 있었으니까요.
여기서 핵심은 에이전트가 우리 인간이 다른 코드를 이해하게 돕는 코드를 쓸 수 있다는 점입니다.
이건 큰일입니다!
방법 3: 공유 공간
나와 상대가 같은 심상 모형을 가지면 효율적으로 소통할 수 있습니다. 같은 이미지를 떠올리게 하는 공통 어휘가 있으니 함께 즉흥적으로 아이디어를 주고받으며 창의적인 대화를 할 수 있습니다. 그런 공유 구조가 없으면 그런 대화는 훨씬 어렵습니다.
저는 팀이 함께 이해를 쌓는 공유 환경을 만드는 데 정말 신이 납니다. Notion이 지향하는 바이기도 하고요.
최근 Notion에서는 사람과 에이전트가 함께 일하는 새 기능을 잔뜩 내놓고 있습니다. 각자 따로 일하는 대신 팀 전체가 이해를 공유하도록요.
작은 예 하나: 이제 Notion 안에서 Claude와 Cursor 에이전트를 돌릴 수 있습니다. 요즘 저는 코딩을 상당 부분 이렇게 합니다.
그 에이전트가 Notion에서 기술 계획을 세우면, 기본값으로 협업 페이지에 올라옵니다. 그래서 팀과 바로 댓글로 논의할 수 있습니다. 혼자가 아니라 함께 생각하는 거죠!
애초에 목적은 증강이었다
자, 마무리하겠습니다. 사실 이건 코드를 넘어서는 훨씬 더 큰 문제라고 봅니다.
인간이 사물이 어떻게 돌아가는지 이해하는 일은 일반적으로도 여전히 중요합니다! 검증만이 아니라 참여를 위해서요.
놀랄 것도 없이 이건 새로운 아이디어가 아닙니다. 우리 컴퓨팅 분야의 바로 그 기원까지 거슬러 올라갑니다.
50년 전 Alan Kay는 컴퓨터가 사람들에게, 특히 아이들에게 세상을 생각하는 법을 가르치는, 책보다 나은 새로운 매체가 될 수 있다고 내다봤습니다.
이 사진 속 아이들은 iPad로 YouTube를 보는 것처럼 보이지만 아닙니다. 상호작용 게임을 하면서 그 코드를 직접 고쳐 물리를 더 잘 이해하고 있습니다. 이게 50년 전 일입니다!!
이제 이 밈이 이해되길 바랍니다.
목적은 언제나 증강이었지, 단순 자동화가 아니었습니다.
이제 AI 덕분에 시뮬레이션 만들기가 이토록 쉬워졌다는 건 아름다운 일입니다. AI가 우리를 가르치게 하는 건 컴퓨팅이 열어준 가장 큰 가능성 중 하나입니다.
그래서 저는 미래가 무척 낙관적으로 보입니다!
올바른 도구를 만들면, 우리는 이제 그 어느 때보다 세상을 더 잘 이해할 수 있습니다. 우리는 루프에서 빠질 필요만 있는 게 아니라, 루프 속으로 더 깊이 들어갈 수도 있습니다. 그건 우리에게 달렸습니다.
FIN
함께 읽을 글
이 발표가 좋았다면, 인간과 AI의 협업을 다룬 제 다른 글도 마음에 들 수 있습니다.
- Enough AI copilots! We need AI HUDs: "AI를 위한 설계를 진지하게 고민하는 사람이라면 인간의 마음을 더 직접 확장하는, 코파일럿이 아닌 형태를 고려해야 합니다."
- AI-generated tools can make programming more fun: "대신 저는 AI로 맞춤 디버거 UI를 만들었고, 덕분에 코딩을 직접 하는 게 더 즐거워졌습니다."
- Code like a surgeon: "부차적인 잡일을 가려내 위임하고, 진짜 중요한 본질에 집중하세요."