제프리 리트는 자기 에이전트가 짠 코드를 제대로 이해했는지 확인하려고, 에이전트에게 자기를 시험할 퀴즈를 만들게 합니다. 다섯 문제를 통과하지 못하면 동료에게 코드 리뷰를 요청하지 않는 게 그의 규칙이에요. Notion에서 디자인 엔지니어로 일하는 그는 AI Engineer 컨퍼런스 무대에 올라 "사람이 코드가 어떻게 돌아가는지 이해하는 건 여전히 중요하다"는 말을 꺼내면서, 동의하는 사람은 손을 들어보라고 했습니다.
요즘은 에이전트가 5만 줄짜리 PR을 올리고, 그걸 한 줄씩 읽어서 따라가는 건 사실상 불가능해졌죠. 그래서 이게 논쟁거리가 되는 시대이기도 합니다. 리트가 내놓은 답은 코드를 덜 쓰자는 쪽이 아니라, 교육학에서 빌려 온 세 가지 방법으로 AI를 이해의 도구로 쓰자는 쪽이었습니다.
검증이 아니라 참여를 위한 이해
Q. 강연을 "사람이 코드를 이해하는 건 여전히 중요하다"는 말로 여셨습니다. 청중 반응이 어땠나요?
동의하는 분 손 들어보시라고 했더니 꽤 많이 들었어요. 이 자리에 오신 분들이라 표본이 한쪽으로 기울었겠죠. 그래서 반대하는 분도 들어보시라고 했는데, 이쪽도 꽤 많더라고요. 나중에 토론이라도 붙여야 하나 싶었습니다.
중요한 건 이게 지금 진지하게 논쟁이 되는 주제라는 사실이에요. 에이전트가 어마어마한 양의 코드를 대신 써주고 있고, 5만 줄짜리 PR을 그냥 올려버립니다. 따라가기가 점점 더 힘들어지고 있어요. 다들 이걸 체감하고 계실 겁니다.
다행인 건, 이해하는 방법이 예전보다 훨씬 많아졌다는 거예요. 코드를 한 줄씩 읽어 내려가는 것만이 유일한 방법이던 시절은 지났습니다. 저는 에이전트가 쓴 코드를 이해하려고 여러 가지 방법을 쓰고 있어요. 코드가 어떻게 돌아가는지 가르쳐 주는 설명 문서를 만들게 하고, 제가 정말 따라가고 있는지 시험하는 퀴즈를 에이전트에게 출제하게 합니다. 나는 아직 루프 안에 있나, 따라가고는 있나를 확인하는 거죠. 제가 직접 들어가서 살아볼 수 있는 마이크로월드를 만들게 하기도 해요. 글로 읽을 때보다 훨씬 깊이 와닿거든요.
Q. 그런데 왜 이해해야 하느냐고 물으면, 많은 사람들이 결국 "검증하려고"라고 답하는 것 같습니다.
맞아요. 그리고 저는 그 지점에서 사람들이 조금씩 빗나가 있다고 생각해요. 에이전트가 멍청한 짓을 한다는 건 다들 겪어보셨을 거고, 그러니까 사람이 할 일은 에이전트를 선 안에 붙잡아 두는 거라고 보는 거죠. 사고 치지 않게 지켜보는 역할이요. "코드 리뷰가 새로운 병목이다" 같은 말을 할 때 사람들 머릿속에 제일 먼저 떠오르는 것도 이 정확성 확인이에요. 에이전트가 뭔가를 가져오면 내 일은 "이게 맞나?"를 묻는 거라는 구도죠.
물론 정확성이라는 말도 여러 뜻으로 씁니다. 내가 준 스펙 문서와 맞는가, 프로덕션을 망가뜨리지는 않는가, 아키텍처는 잘 잡혀 있는가. 하지만 결국엔 다 통과냐 반려냐를 가르는 판단이에요. 그리고 시간이 지날수록 에이전트도 이 질문들을 스스로 던질 수 있게 되고 있고, 점점 잘하고 있습니다. 검증 루프만 제대로 만들어 주면요. 사람이 정확성 검사에서 차지하는 비중은 줄어들고 있어요.
사실 저는 그게 싫지 않습니다. 제가 하고 싶은 게 분명하고 에이전트가 그걸 정확하게 해냈다면, 틀린 결과물을 들고 오는 것보다 훨씬 좋죠. 저는 그건 환영이에요.
Q. 그럼 에이전트가 계속 똑똑해지면, 사람은 루프에서 나와도 되는 거 아닌가요?
바로 거기서 사람들이 정말 중요한 걸 놓친다고 생각해요. 이해해야 하는 더 깊은 이유가 따로 있거든요. 검증하려고 이해하는 게 아니라, 참여하려고 이해하는 겁니다.
루프가 하나뿐이 아니거든요. 무슨 일이 벌어지고 있는지 들여다보고 루프 안에 들어가면, 빠져나올 때쯤 저는 이미 달라져 있습니다. 뭔가를 이해하게 되고, 그 이해를 다음 루프로 가져가요. 그리고 그다음 루프로, 또 그다음 루프로. 지금 무슨 일이 벌어지는지 알고 있어야, 다음 아이디어도 떠올리고 이 프로젝트에 능동적인 창작자로 남을 수 있습니다.
아마 AI가 나오기 전에도 다들 느껴보셨을 거예요. 무슨 일이 돌아가는지 정말 이해하고 있는 사람이 내놓는 아이디어와, 몇 겹 떨어져 있는 사람이 내놓는 아이디어는 종류가 다릅니다. 머릿속에 개념들이 촘촘하게 자리 잡혀 있으면, 그걸 아주 빠르게 자유자재로 재조합할 수 있어요. 굳이 남한테 이게 어떻게 돌아가느냐고 물어보지 않아도요. 거기서 창의적인 도약이 나옵니다. 그리고 그 도약이야말로 이 일에서 사람의 몫이에요. 다음 아이디어, 또 그다음 아이디어를 떠올리는 일.
그래서 저는 이게 이해가 중요한 진짜 이유라고 생각합니다. 이건 에이전트가 더 좋아진다고 해서 사라지는 문제가 아니에요. 능동적으로 참여하고 싶다면, 이건 계속 해야 하는 일입니다.
Q. 이해하지 못하게 되면 어떤 일이 벌어지나요?
'인지 부채(cognitive debt)'라는 말이 이 상태를 잘 짚어 줍니다. 기술 부채에 빗댄 표현인데, 학자 마거릿앤 스토리(Margaret-Anne Storey)가 널리 알렸고 사이먼 윌리슨(Simon Willison)도 블로그에 소개한 적이 있습니다. 기술 부채가 코드에 쌓인다면, 인지 부채는 개발자와 팀의 머릿속에 쌓여요.
이해해야 한다는 데까지는 다들 동의하실 텐데, 문제는 방법이죠. 우리가 2023년으로 돌아가서 살 수는 없잖아요. 에이전트를 써서 빠르게 움직이고 있고, 따라가기는 점점 더 어려워지고 있습니다.
이 비유가 좋은 이유는 기술 부채와 똑같이 굴러가기 때문입니다. 한동안은 그냥 넘어갈 수 있어요. 그러다 어느 순간 이해가 바닥나 있으면 크게 데입니다. 다들 한 번쯤 겪어보셨을 것 같아요. 저도 겪었고요. 바이브 코딩으로 잘 나가다가 어느 순간 "잠깐, 지금 무슨 일이 벌어지고 있는지 하나도 모르겠는데"라는 순간이 옵니다. 그 시점부터는 참여 자체가 불가능해져요. 인지 부채가 너무 많이 쌓인 거죠.
Q. 그럼 실제로는 어떻게 하고 계신가요?
그래서 저는 먼저 한 걸음 물러나서 더 근본적인 질문을 던져야 한다고 봤어요. "사람은 원래 뭔가를 어떻게 이해하지?"
알고 보면 이 질문을 던진 게 인류 역사상 우리가 처음이 아닙니다. 이걸 다루는 분야가 있어요. 교육학입니다. 교육이라고 하면 강의실에 앉아 있던 안 좋은 기억이 떠오를 수도 있는데, 우리는 그보다 잘할 수 있어요. 교육 분야에서 지금까지 나온 가장 좋은 아이디어를 가져다가, 루프 안에 남아서 이해하는 데 쓰면 됩니다. 제가 쓰는 방법도 거기서 나왔어요. 오늘은 세 가지를 이야기해보려고 합니다. 설명, 마이크로월드, 공유 공간입니다.
첫 번째 : 설명을 다시 설계하기
Q. 첫 번째가 설명이군요. 그런데 에이전트는 지금도 설명을 해주지 않나요?
에이전트가 코드를 짜고 나면, 그건 그 작업을 저한테 설명해 줄 기회이기도 하거든요. 그런데 지금 가장 게으르게 쓰이는 방식은 "여기 코드 디프(diff, 변경 전후 코드 차이) 있습니다"예요. 달라진 부분을 날것 그대로 던져주는 거죠. 저는 이보다 훨씬 잘할 수 있다고 봅니다.
그래서 저는 이런 질문을 던져봤어요. 최고의 설명이란 어떤 모습일까? 만약 팀 하나를 1년 동안 붙여서, 이 코드 변경 하나를 저한테 설명하기 위한 맞춤 커리큘럼을 만들어 오게 한다면 어떤 결과물이 나올까? 이 질문 하나에서 꽤 많은 게 나오더라고요.
Q. 그 질문에서 나온 결과물이 explain-diff군요. 어떻게 작동하나요?
explain-diff는 제가 만든 클로드 스킬입니다. 에이전트가 코드를 바꿔놓으면 그 변경분을 이 스킬에 넣고 돌립니다. 그러면 이 변경이 무엇이고 왜 이렇게 됐는지를 저한테 가르쳐 주는 문서 한 편이 나와요. 저는 매일 쓰고 있고 동료들도 많이 씁니다.
예시로 보여드릴게요. 저는 젠 가든(Zen garden, 일본식 정원)을 그리는 게임을 만들고 있어요. 요즘 같은 때 스트레스를 좀 풀자는 취지죠. 여기서 게임 시점을 위에서 내려다보는 방식(top-down)에서 아이소메트릭(isometric, 비스듬히 내려다보는 입체 시점)으로 바꾸는 코드 변경을 했습니다.
출력은 HTML로 뽑을 수도 있고 마크다운으로 뽑을 수도 있습니다. 저는 Notion에 넣는 걸 좋아하는데, 제가 거기서 일하기도 하지만 그렇게 하면 협업이 되기 때문이에요. 팀원들이 문서에 댓글을 달고 그 자리에서 얘기할 수 있거든요.
Q. explain-diff 스킬로 만든 설명 문서는 어떻게 구성되나요?
첫 번째는 배경 지식부터 시작하는 겁니다. 이번 변경에서 무슨 일이 있었는지로 시작하지 않아요. 그 앞에 있어야 할 것들이 먼저 나옵니다. 이 시스템은 이렇게 돌아갑니다, 우리가 쓰는 게임 엔진은 이겁니다, 좌표계는 이렇게 생겼습니다, 하위 시스템은 이런 것들이 있습니다. 이걸 먼저 가르쳐 줘요.
그러니까 변경 사항을 꺼내기 전에, 제가 그 변경을 이해하기 시작할 수 있는 상태까지 저를 끌어올려 놓는 겁니다. 이미 아는 내용이면 당연히 건너뛰면 되고, 제가 뭘 알고 뭘 모르는지에 맞춰서 조정할 수도 있습니다.
Q. 그다음 원칙은요?
두 번째는 디테일보다 직관이 먼저라는 겁니다. 코드를 들여다보기 전에 이렇게 말해 줘요. "이번 커밋의 목표는 2D 그리기 기법만으로 정원이 입체적으로 느껴지게 만드는 것이다."
잘 쓴 커밋 메시지를 조금 더 깊게 쓴 것이라고 생각하시면 돼요. 코드를 한 무더기 던지기 전에 이 변경의 본질이 어떤 느낌인지부터 잡아 달라. 그렇게 요구하는 거죠. 이게 잘 가르치는 방식이기도 해요. 좋은 수학 선생님들이 하는 게 정확히 이겁니다.
Q. 세 번째 원칙으로 인터랙티브 요소를 꼽으셨습니다.
가능하다면 제가 직접 만져보고 굴려볼 수 있는 요소를 넣어 달라고 합니다
이번 변경은 돌을 그리는 방식을 바꾸는 작업이었어요. 그래서 설명 문서 안의 작은 시뮬레이션에서 제가 돌을 마우스로 끌어볼 수 있게 했습니다. 끌면 좌표가 어떻게 바뀌는지, 그림의 Z 레이어(앞뒤로 겹쳐 그려지는 순서)가 어떻게 달라지는지가 같이 보여요. 참고로 이건 Notion에서 출시한 지 며칠 되지 않은 기능입니다. Notion 페이지 안에 HTML 블록을 넣을 수 있게 됐어요. 이제 에이전트가 Notion 페이지에 인터랙티브 시뮬레이션을 넣어 줄 수 있습니다.
다만 인터랙티브 요소는 조심해서 써야 한다고 생각해요. 오히려 생각을 대신해 주는 편법이 될 수도 있고, 솔직히 말하면 그럴듯해 보이기만 하는 쓰레기가 될 수도 있습니다. 하지만 감각 있게 쓰면, 정지된 그림으로는 닿기 어려운 이해까지 갑니다.
Q. 코드 자체는 마지막에 나오는 건가요?
네, 그제야 코드를 보여줍니다. 그런데 파일 목록을 순서대로 쭉 던지지 않아요. 제가 '리터릿 디프(literate diff, 코드 변경을 산문처럼 읽히게 정리한 것)'라고 부르는 방식을 씁니다. 산문으로 써 주고, 이해하기 좋은 순서대로 설명해 주고, 각 파일 앞에 무슨 일이 벌어지는지를 먼저 말해 줘요. 이런 것들이 쌓이면 날것 그대로의 디프보다 따라가기가 훨씬 쉬워집니다.
사실 저는 이걸 출력해서 카페에 들고 가서 읽기도 해요. 여기서 재미있는 역설이 하나 생깁니다. 예전에는 컴퓨터와 IDE 앞에 붙어 있어야 했는데, AI 덕분에 이제는 카페에 앉아서 이 PR에 관한 교과서를 읽는 셈이 됐거든요. 꽤 근사한 일이에요.
읽었다는 착각을 깨는 장치
Q. 설명 문서를 잘 만들어도, 결국 사람이 제대로 안 읽으면 소용없지 않나요?
정확히 그 문제가 있습니다. 읽는 건 어려운 일이고, 저는 게을러요. 사람은 원래 게으르고요.
한번은 동료에게 PR을 보냈는데, 저는 그걸 다 읽었다고 생각했고 이해했다고 생각했어요. 그런데 그 동료가 가장 기본적인 질문을 하나 던지더라고요. 저는 "어… 모르겠는데요" 소리가 나왔습니다. 분명히 이해하지 못한 상태였어요. 저 자신을 속인 거죠. 그래서 다시는 이런 일이 없게 만드는 시스템을 어떻게 짤 수 있을까 고민했습니다.
Q. 참고한 게 있었나요?
앤디 마투셱(Andy Matuschak)이라는 연구자의 작업을 봤어요. "책은 작동하지 않는다(Books don't work)"라는 유명한 글을 쓴 사람입니다. 무슨 뜻이냐면, 책을 다 읽고도 자기가 이해하지 못했다는 걸 눈치채지 못하는 경우가 굉장히 많다는 거예요.
그래서 그는 마이클 닐슨(Michael Nielsen)과 함께 이런 걸 시도했습니다. 글 안에 간격 반복 퀴즈를 넣어서, 방금 읽은 내용을 정말 기억하고 있는지 그 자리에서 시험하는 거예요. 나중에는 그 퀴즈를 계속 이메일로 보내서 오래 기억하게 만들기도 합니다. 이 방식이 좋은 건, 이해하지 않고서는, 최소한 기억하지 않고서는 그 글을 끝까지 뗄 수가 없다는 점이에요.
Q. 그걸 코드 설명 문서에 그대로 적용하신 거군요.
문서 맨 아래에 퀴즈가 있습니다. 다섯 문제, 난이도는 중간.
제 규칙은 이거예요. 에이전트가 쓴 코드에 대한 퀴즈를 통과하지 못하면 팀원들에게 리뷰를 요청하지 않는다.
좀 유치하게 들릴 수도 있는데, 한번 해보시면 좋겠어요. 이 퀴즈에 걸려서 "아, 나 이거 이해 못 했구나" 싶었던 적이 놀라울 만큼 많습니다.
저는 이걸 속도 조절기라고 생각해요. AI 관련해서는 전부 다 더 빨리, 더 빨리, 더 빨리입니다. 속도를 올리라는 압력이 사방에 있어요. 그런데 우리가 정확성의 속도로만 움직이는 게 아니라 이해의 속도로도 움직이고 있다는 걸 어떻게 확인할까요? 퀴즈가 저에게는 그 조절기입니다.
explain-diff 스킬은 온라인에 공개해 뒀어요. HTML로 뽑는 버전과 Notion 페이지로 뽑는 버전 두 가지가 있습니다. 사실 구조는 아주 단순하니까, 가져가서 각자 자기 것으로 고쳐 쓰시면 됩니다.
※ explain-diff 스킬 링크: https://gist.github.com/geoffreylitt/a29df1b5f9865506e8952488eac3d524
두 번째 : 들어가서 살아보는 마이크로월드
Q. 두 번째 기법이 마이크로월드입니다. 어디서 온 개념인가요?
교육학자 시모어 페퍼트(Seymour Papert)에게서 왔습니다. 시대를 훨씬 앞서간 분인데, '매스랜드에서 살기(living in Mathland)'라는 아이디어를 냈어요. 무슨 뜻이냐면 이렇습니다. 아이들은 프랑스에 살면서 프랑스어를 배우는데, 그럼 수학을 배우려면 어디로 가야 하지? 그냥 거기 있는 것만으로 수학을 직관적으로 익히게 되는 매스랜드 같은 곳이 있을 수 있을까?
그가 만든 것 중에 거북이라는 로봇이 있어요. 아이들이 프로그래밍해서 그림을 그리게 하는 로봇입니다. 그런데 핵심은 로봇을 만드는 게 아니에요. 아이들이 그 프로그래밍을 하면서 실제로 수학을 배운다는 것, 그러니까 로봇이 아니라 아이들이 달라진다는 것이 핵심입니다.
Q. 그걸 코드 이해에 적용하면 어떤 모습이 되나요?
작년에 공부 삼아 프롤로그(Prolog, 데이터베이스 질의 언어와 조금 비슷한 프로그래밍 언어)의 인터프리터(interpreter, 코드를 한 줄씩 읽어서 실행해 주는 프로그램)를 직접 만들어 본 적이 있어요. 그런데 위키백과에서 글로 읽으면 굉장히 복잡해 보이는 대목들이 있는데요. 실제로 안에서 무슨 일이 벌어지는지 감이 잡히면 이렇게 됩니다. "어, 별로 어려운 게 아니었네. 그렇게 읽으니까 어렵게 느껴졌던 거구나." 그럼 어떻게 해야 이게 머릿속에서 더 빨리 맞아떨어질까 고민했습니다.
그래서 클로드에게 마이크로월드를 만들어 달라고 했습니다. 제가 만든 언어가 안에서 어떻게 도는지 눈으로 보려고만 만든, 한 번 쓰고 버릴 디버거였어요. 타임라인을 앞뒤로 훑으면 제 인터프리터가 한 단계씩 무슨 일을 하는지가 나오고, 각 단계의 상태가 전부 시각화됩니다. 뚜껑을 열고 속을 들여다보면서 감을 잡기 시작할 수 있는 거죠.
Q. 그 도구로 실제 버그도 잡으셨나요?
네, 좁은 범위의 버그들을 여기서 고쳤습니다. 타임라인에 제 생각을 메모로 남겨두는 기능도 넣었어요. 화면에서는 잘 안 보이지만, 나중에 제가 그때 무슨 생각을 하고 있었는지 기억하려고 만든 겁니다.
그런데 중요한 건 버그 자체가 아니에요. 버그를 고치는 사이에 이 기계가 어떻게 돌아가는지가 몸에 익고 있었다는 겁니다. 에이전트에게 그냥 "버그 고쳐줘"라고 시키면 곁눈으로 익히는 감각은 안 생겨요. 마이크로월드 안에서 살면 생깁니다.
Q. 다른 사례도 있을까요?
제 개인 웹사이트를 다른 프레임워크로 옮기는 작업이 있었어요. 제일 먼저 한 건 "클로드, 이거 옮기는 스크립트 써줘"였습니다. 스크립트가 나왔고, 작동하는 것처럼 보였어요. 그런데 그 스크립트를 읽고 나서 든 생각은 "음, 모르겠다"였습니다. 뭘 하고 있는 건지 감이 안 왔어요. 파일이 여기저기로 옮겨 갔고, 맞는 것 같긴 한데 그뿐이었죠.
그래서 이렇게 말했습니다. "클로드, 내가 직접 이 이사를 하는 게임을 만들어 줘." 왼쪽에 예전 웹사이트, 오른쪽에 새 웹사이트가 있고, 저는 버튼만 누릅니다. 다음, 다음, 다음. 단계마다 지금 실행하는 명령어를 보여주고, 새 웹사이트가 한 단계씩 살아나는 게 보여요. 아래쪽에는 파일 트리가 있어서 파일들이 움직이는 것도 보입니다.
결과적으로 제가 손으로 직접 옮긴 것과 비슷한 경험을 하게 되는데, 실제로는 버튼만 누른 거예요. 한 단계씩 밟아 나가는 데서 오는 이득은 챙기면서 고통은 피한 셈입니다.
여기서 가져갈 핵심은 이겁니다.
에이전트는 우리가 코드를 이해하도록 돕는 코드를 쓸 수 있다. 목적은 출시할 소프트웨어를 만드는 게 아니에요. 우리를 위한 마이크로월드를 만드는 거죠. 그게 매스랜드입니다. 딱 이 하나를 위한 시뮬레이션이요.
세 번째 : 함께 이해하는 공간
Q. 앞의 두 가지는 결국 혼자 하는 이해인데요.
맞습니다. 여기까지는 전부 저 혼자 이해하는 얘기였어요. 그런데 실제로 일하다 보면 팀으로 움직이는 경우가 많고, 그때 진짜 과제는 팀 전체가 같이 이해하는 겁니다. 그래야 다 같이 붙어서 아이디어를 굴려볼 수 있으니까요.
Notion에서는 이 문제를 정말 많이 고민해요. 저와 상대방이 같은 그림을 공유하고 있어야 소통이 제대로 된다고 보거든요. 시스템의 각 부분을 부르는 이름이든, UI 요소나 개념을 부르는 이름이든요. 그래서 어떻게 하면 여럿이 같이 이해할 수 있게 해주는 도구를 만들지를 많이 고민합니다.
Q. 지금 시도하고 있는 것 중에 소개할 만한 게 있나요?
몇 가지 해보고 있는 게 있어요.
하나는 사람 여럿과 에이전트 여럿이 한 스레드에 같이 있는 겁니다. 예를 들어 제가 팀 PM에게 "이 기능에 대해 유저들이 뭘 요청하고 있어?"라고 물어요. PM이 "나도 잘 모르겠는데, 다른 에이전트한테 물어보자"고 하면 그 에이전트가 대화에 들어와서 같이 얘기합니다.
이미지 출처 : Youtube 'Understanding is the new bottleneck — Geoffrey Litt, Notion', AI Engineer
여기서 벌어지는 일이 중요해요. 저는 제 에이전트랑, PM은 PM대로 자기 에이전트랑 따로 얘기하는 게 아닙니다. 우리가 같은 공간에 있고, 서로가 뭘 주고받는지 다 보여요. 1:1 대화만 하다가 슬랙 채널로 옮겨간 것과 비슷합니다. 남들이 어떻게 움직이는지 더 많이 보이고, 그래서 같이 이해하게 됩니다.
또 하나는 같이 놓고 얘기할 수 있는 문서예요. 클로드가 계획을 하나 써줬다고 해봅시다. 그중 어떤 부분을 팀과 논의하고 싶으면 그냥 거기에 댓글을 달면 됩니다. 이게 제 컴퓨터에만 있는 게 아니라 협업 공간에 있으니까요. "이거 어떻게 생각해?"라고 물으면 팀원이 바로 그 자리에서 답하고, 우리는 그 자리에서 대화합니다.
이미지 출처 : Youtube 'Understanding is the new bottleneck — Geoffrey Litt, Notion', AI Engineer
에이전트와 함께 아이디어를 놓고 토론할 수 있는 이런 공간이, 집단적 이해를 쌓는 데 굉장히 강력하다고 생각해요. 얼마 전 저희가 코딩 에이전트를 Notion 안으로 들여오는 기능을 출시했습니다. 이제 클로드와 커서(Cursor)가 Notion 안에서 돌아가요. 저희 팀은 실제로 코드 상당수를 Notion 안에서 만들고 있는데, 주된 이유가 바로 이 이점 때문입니다. 공유 공간에 있다는 것만으로 얻는 게 그만큼 큽니다.
컴퓨터의 원래 목적
Q. 지금까지 코드 이야기를 하셨는데, 더 큰 이야기로 이어지는 것 같습니다.
처음에 저는 "사람이 코드가 어떻게 돌아가는지 이해하는 건 여전히 중요하다"고 말했어요. 그런데 사실 이건 훨씬 큰 얘기라고 생각합니다. 저는 사람이 모든 것이 어떻게 돌아가는지 이해하는 게 여전히 중요하다고 봐요. 그리고 이건 지금 의심받고 있는 명제이고, 우리가 적극적으로 싸워서 지켜야 하는 것이기도 합니다.
그런데 이건 새로운 싸움이 아니에요. 우리 분야의 기원까지 거슬러 올라갑니다.
Q. 어디까지 거슬러 올라가나요?
개인용 컴퓨터의 개척자 중 한 명인 앨런 케이(Alan Kay)까지 갑니다. 현대적인 GUI를 함께 발명한 사람이기도 하죠. 그가 1972년에 「모든 연령대의 어린이를 위한 개인용 컴퓨터(A Personal Computer for Children of All Ages)」라는 글을 썼어요. 지금 읽어도 놀랄 만큼 앞을 내다본 글입니다.
거기 실린 삽화에는 아이 둘이 아이패드로 유튜브를 보고 있는 것 같은 장면이 있습니다. 반세기 전에 그린 그림이라는 게 좀 놀랍죠. 그런데 그 화면에 떠 있는 건 유튜브가 아닙니다. 케이가 그린 건, 아이들이 게임을 하면서 그 게임의 코드를 직접 고쳐 물리학을 배우는 장면이었어요.
그러니까 핵심은 컴퓨터가 아니라 아이들이었습니다. 컴퓨터의 목적은 사람을 한 단계 끌어올리는 것이었어요. 그런데 어느 시점부터 컴퓨터가 본질적인 비전 - 사람을 한 단계 끌어올리는 것 - 에서 옆길로 샜다는 거죠.
Q. 바로 지금이 그 비전으로 돌아갈 시점이라고 보시는 거군요.
맞아요. 지금 많은 사람들이 이걸 깨닫고 있어요. "코드가 공짜가 됐네. 그럼 한 번 쓰고 버릴 UI도, 개념을 이해하기 위한 동적인 시뮬레이션도 만들 수 있잖아. 디버거도, 놀이터도 만들 수 있잖아." 다들 좋다고 하죠. 그런데 이건 사실 새로운 아이디어가 아닙니다. 애초에 컴퓨터가 하려던 게 바로 이거였어요
그래서 저는 이 대목이 제일 희망적이라고 봅니다. 뭔가가 어떻게 돌아가는지 이해하는 건 여전히 아주 중요하고, 도구와 태도와 창의성만 제대로 갖추면 우리는 그 어느 때보다 더 잘 이해할 수 있어요. 이해가 얕아지는 게 아니라 오히려 깊어지는 겁니다.
AI를 쓰면 우리는 루프 밖으로 밀려나는 게 아니라, 그 어느 때보다 더 깊이 루프 안으로 들어갈 수 있습니다.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 11기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요