이해가 새로운 병목이다
(geoffreylitt.com)- 에이전트가 작성한 코드가 사람 주변에 계속 쌓이는 상황에서 개발 속도를 제한하는 요소는 코드 생성 능력이 아니라 시스템을 따라가며 다음 변화를 구상할 수 있는 인간의 이해 속도로 이동하고 있음
- 코드를 이해하는 목적은 결과를 승인하거나 거부하는 검증에 그치지 않으며, 여러 차례 이어지는 에이전트 작업 루프에서 다음 아이디어를 제안하고 창작 과정에 참여하는 데 있음
- 원시 코드 차이 대신 배경지식/변경 목표/상호작용형 도표/서술식 코드 차이를 묶은 코드 설명 문서를 먼저 읽으면 변경의 구조와 의도를 더 빠르게 파악할 수 있음
- 설명 문서의 퀴즈와 실행 과정을 직접 조작하는 마이크로월드는 에이전트가 대신 판단하게 하지 않고 사람이 시스템의 상태 변화와 내부 작동을 체험하도록 만듦
- AI를 사람을 루프에서 제거하는 자동화 수단으로만 사용하지 않고 이해를 위한 도구와 시뮬레이션을 만드는 데 활용하면, 사람과 팀이 오히려 더 깊이 루프에 참여할 수 있음
코드 생성 속도를 따라가지 못하는 인간
- 에이전트가 작성한 코드 더미가 한 사람 주변에 계속 높아지는 모습처럼, 생성되는 코드의 양은 늘어나지만 사람이 이를 이해하는 속도는 같은 비율로 증가하지 않음
- 모든 코드 차이를 한 줄씩 읽는 방식만으로는 에이전트의 작업 속도를 따라가기 어려움
- 코드 이해에는 원시 코드 차이 외에도 다음과 같은 다양한 방식이 있음
- 시스템과 변경 사항을 가르치는 코드 설명 문서
- 실제 이해 여부를 확인하는 퀴즈
- 내부 동작을 직접 조작하며 익히는 마이크로월드
- 팀 전체가 같은 정신 모형을 형성하는 공유 공간
이해는 검증이 아니라 참여를 위한 것
- 사람이 코드를 이해해야 한다는 질문에 흔히 나오는 답은 에이전트의 작업을 검증하기 위해서라는 것임
- 명세에 맞는지 확인함
- 구조가 적절한지 판단함
- 최종적으로 승인/거부를 결정함
- 발표 자료에서는 이를 엄지를 올리거나 내리는 이분법적 판단으로 표현함
- 검증만을 사람의 역할로 보면 이해는 결과에 대한 합격 여부를 판단하는 과정으로 축소됨
- 하지만 에이전트는 자신이 만든 결과를 직접 실행하고 검사하며 오류를 찾는 자체 검증 능력도 계속 개선되고 있음
- 검증을 에이전트가 더 잘 수행하게 될수록 인간은 어디에 남는가라는 문제가 생김
- 대안은 이해를 통해 참여하는 것임
- 에이전트가 무엇을 하고 있는지 알아야 사람이 창의적 과정의 능동적인 구성원으로 남을 수 있음
- 시스템을 이해하면 현재 결과를 평가하는 데서 끝나지 않고 다음 단계에서 무엇을 바꿀지 생각할 수 있음
프로젝트는 하나의 루프가 아니라 수많은 루프임
- 실제 프로젝트는 에이전트에게 한 번 지시하고 결과를 받는 단일 루프가 아님
- 목표 설정/구현/확인/수정/확장으로 이어지는 수많은 반복 루프가 서로 연결됨
- 각 반복에서 사람이 가진 시스템 이해도가 다음 아이디어의 질과 범위를 결정함
- 머릿속에 충분한 개념과 구조가 있어야 다음과 같은 질문을 유창하게 다룰 수 있음
- 무엇을 추가하거나 제거해야 하는가
- 어느 구조를 변경해야 하는가
- 현재 구현에서 어떤 새로운 가능성이 생겼는가
- 이해가 부족하면 에이전트가 만들어준 결과에 “대략 맞아 보인다”고 반응할 수는 있지만, 프로젝트가 어디로 가야 하는지 주도하기 어려움
이해를 미루며 쌓이는 인지 부채
- 시스템을 이해하지 않은 채 에이전트의 결과를 계속 받아들이면 단기적으로는 빠르게 진행할 수 있음
- 그러나 기술 부채가 나중의 변경 비용을 높이듯, 이해를 생략한 작업은 인지 부채(cognitive debt) 를 남김
- 인지 부채가 쌓이면 프로젝트에 참여한 사람이 전체 흐름을 놓치게 됨
- 코드가 왜 현재 구조가 됐는지 파악하기 어려움
- 새로운 요구사항을 어디에 연결해야 할지 판단하기 어려움
- 에이전트가 제안한 다음 변경의 타당성을 논의하기 어려움
- AI 시대의 문제는 코드가 생성되지 않는 것이 아니라, 생성된 시스템에 관해 사람이 충분한 개념을 갖지 못하는 것임
교육 방법을 코드 이해에 적용하기
- 빠르게 변하는 AI 작업 환경에서 인간의 이해를 구축하는 문제는 교육이 오랫동안 다뤄온 문제와 닮아 있음
- 새로운 사실을 단순히 전달하는 것보다 배경지식/직관/연습/피드백을 함께 제공해야 실제 이해가 형성됨
- 코드 이해에도 교육에서 발전한 방법을 적용할 수 있음
- 세부 구현 전에 배경과 직관을 제공함
- 내용을 읽은 뒤 회상하고 답하게 함
- 추상적인 규칙을 직접 조작할 수 있는 환경을 제공함
- 다른 사람과 같은 개념과 어휘를 공유하게 함
변경 사항을 가르치는 /explain-diff
- /explain-diff는 에이전트가 수행한 변경을 구조화된 설명 문서로 만드는 스킬임
- HTML/Markdown/Notion 페이지 형태로 출력할 수 있으며, Notion 문서는 팀원이 댓글을 달고 함께 논의하는 협업 산출물로 사용할 수 있음
- 단순한 코드 변경 목록이 아니라 사람이 변경 사항을 학습하도록 설계된 설명 자료를 생성함
- 게임 화면의 원근감을 변경하는 사례에서는 코드를 바로 보여주지 않고 다음 순서로 접근함
- 기존 게임 엔진의 렌더링 방식을 먼저 설명함
- “2D 그리기 기법으로 정원을 입체적으로 보이게 만들기”라는 변경 목표를 제시함
- 등각 투영이 무엇인지 설명해 변경의 시각적 원리를 이해하게 함
- 이후에 실제 구현 코드로 이동함
배경지식부터 가르치기
- 좋은 설명은 “무엇이 바뀌었는가”보다 “바뀌기 전에는 무엇이 있었는가” 에서 시작함
- 기존 게임 엔진의 좌표 체계와 렌더링 구조를 모르면 새 원근법 코드만 읽어도 변경의 이유를 이해하기 어려움
- 설명 문서는 에이전트와 동일한 배경을 갖지 못한 사람이 대화에 참여할 수 있도록 기존 시스템의 구조를 먼저 보충함
- 이는 단순한 요약이 아니라 사람을 현재 프로젝트 문맥으로 다시 데려오는 과정임
세부 구현보다 직관을 먼저 만들기
- 코드에 앞서 변경의 본질을 한 문장으로 설명하면 세부 구현이 어떤 목표를 향하는지 알 수 있음
- 정원을 입체적으로 보이게 만드는 사례에서는 등각 투영의 수식부터 설명하지 않고, 평면의 그림을 3차원처럼 보이게 한다는 시각적 목표를 먼저 전달함
- 배경과 목표를 이해한 뒤 코드 조각을 보면 각 계산과 변환이 전체 결과에서 맡는 역할을 연결하기 쉬움
- 사람을 세부 코드의 수동적인 독자가 아니라 변경 의도를 이해하는 동등한 참여자로 만드는 것이 목적임
상호작용형 도표로 좌표 변화를 체험하기
- 정적인 그림만 보여주는 대신 정원 위의 바위를 직접 끌어 움직이는 상호작용형 도표를 사용함
- 바위를 이동하면 화면상의 위치와 내부 좌표가 함께 변해 등각 투영의 좌표 변환을 확인할 수 있음
- 수식이나 코드만 읽을 때보다 입력과 출력의 관계를 직접 조작하며 직관을 형성할 수 있음
- Notion 페이지 안에 상호작용형 HTML을 삽입해 코드 설명 문서 자체를 작은 실행 환경으로 만들 수 있음
- AI는 설명문을 쓰는 데서 그치지 않고 이해에 필요한 시각화와 조작 도구까지 생성할 수 있음
원시 코드 차이를 서술식 코드 차이로 바꾸기
- 일반적인 코드 차이는 변경된 파일을 파일명 순서로 나열함
- 파일 간 관계를 설명하지 않음
- 변경 목적을 알려주지 않음
- 어떤 순서로 읽어야 하는지 안내하지 않음
- 서술식 코드 차이(literate diff) 는 변경 사항을 글의 흐름처럼 재구성함
- 변경의 목적을 먼저 제시함
- 이해하기 적절한 순서로 파일과 함수를 설명함
- 설명 사이에 필요한 코드 조각만 삽입함
- 주변 맥락과 구현 선택의 관계를 함께 보여줌
- 원시 코드 차이가 재료를 그대로 쌓아둔 것이라면, 서술식 코드 차이는 변경 과정을 하나의 이야기로 편집한 것에 가까움
- 설명을 먼저 읽은 뒤 원시 코드 차이를 검토하면 각 코드 조각이 왜 존재하는지 알고 읽을 수 있어 검토 속도가 빨라짐
AI가 만든 설명서를 종이로 읽기
- 완성된 설명 문서는 하나의 코드 설명 패킷처럼 사용할 수 있음
- 원시 코드 차이도 계속 읽지만 항상 설명 문서를 먼저 읽음
- 집중이 필요할 때는 문서를 인쇄해 카페에서 종이로 읽기도 함
- AI와의 프로그래밍이라는 상호작용적인 활동이 오히려 깊게 집중할 수 있는 정적인 종이 보고서로 바뀌는 역설이 생김
- 핵심은 가장 최신의 인터페이스를 사용하는 것이 아니라 사람이 실제로 이해하기 좋은 형태로 정보를 변환하는 것임
읽었다는 느낌과 실제 이해의 차이
- 설명 문서를 잘 구성해도 읽는 행위 자체가 이해를 보장하지는 않음
- 사람은 문장을 눈으로 따라간 것만으로 내용을 기억하거나 이해했다고 착각하기 쉬움
- Andy Matuschak의 “books don't work”와 Andy Matuschak/Michael Nielsen의 Quantum Country에서 아이디어를 가져옴
- Quantum Country는 글 안에 간격 반복 퀴즈를 삽입해 독자가 내용을 직접 회상하게 함
- 같은 방식을 코드 설명 문서에 적용해 마지막에 변경 사항에 관한 다섯 개의 대화형 질문을 배치함
퀴즈는 AI 루프의 속도 조절 장치임
- 코드를 다른 사람에게 보내기 전에 설명 문서의 퀴즈를 통과해야 한다는 규칙을 사용함
- 다른 사람이 작성한 코드를 검토할 때도 같은 기준을 적용함
- 퀴즈는 지식을 평가하기 위한 부가 기능이 아니라 속도 조절 장치임
- AI와 작업하면 구현/수정/재생성 루프가 인간의 이해보다 빠르게 진행되기 쉬움
- 퀴즈는 각 루프에서 기계적으로 다음 질문을 던지게 함
- 실제로 무엇이 바뀌었는지 설명할 수 있는가
- 왜 이런 구조를 사용했는지 이해하는가
- 다음 변경에 영향을 주는 제약을 알고 있는가
- 통과하지 못하면 작업 속도를 늦추고 이해를 보충해야 하므로, 사람이 창의적 참여자로 남을 수 있음
Seymour Papert의 Mathland에서 가져온 마이크로월드
- 두 번째 방법인 마이크로월드는 교육자 Seymour Papert의 아이디어에서 출발함
- Papert는 프랑스어를 배우기 위해 프랑스에서 생활하듯, 수학을 배우려면 수학이 자연스럽게 작동하는 Mathland에서 살아야 한다고 봄
- 아이가 설명을 수동적으로 듣는 대신 호기심에 따라 환경을 탐색하며 수학적 개념을 자연스럽게 익히는 방식임
- 이를 코드에 적용하면 시스템을 설명하는 문서만 제공하는 것이 아니라, 사람이 그 안에 들어가 작동 방식을 직접 경험하는 환경을 만들 수 있음
- 마이크로월드는 실제 프로덕션 시스템 전체를 그대로 노출하기보다 특정 원리와 상태 변화를 관찰하기 좋게 구성한 작은 세계임
Prolog 인터프리터를 시간축으로 탐색하기
- Prolog 인터프리터를 개발할 때 내부에서 어떤 일이 일어나는지 직관적으로 파악하기 어려웠음
- 에이전트와 함께 실행 과정을 단계별로 탐색하는 전용 디버거를 제작함
- 이 디버거에서는 다음을 직접 확인할 수 있음
- 실행 시간을 앞뒤로 이동함
- 현재 스택에 어떤 값이 있는지 살펴봄
- 각 단계에서 어떤 규칙이 평가되는지 확인함
- 특정 규칙이 올바르게 적용된 순간에 메모를 남김
- 완성된 결과만 보는 대신 논리 언어의 실행이 시간에 따라 어떻게 전개되는지 직접 따라갈 수 있음
- 에이전트에게 디버깅을 맡기면 문제는 해결될 수 있지만, 사람이 디버거를 직접 조작해야 실행 구조에 관한 이해가 생김
에이전트가 대신 디버깅하는 것과 이해 도구를 만드는 것의 차이
- “에이전트가 문제를 찾아 수정함”과 “에이전트가 사람이 문제를 탐색할 도구를 만듦”은 서로 다른 결과를 만듦
- 전자는 작업 결과를 빠르게 얻지만 내부 과정에 대한 인간의 이해는 거의 늘지 않을 수 있음
- 후자는 사람이 실행 상태를 살펴보고 가설을 세우고 결과를 확인하는 탐색 과정을 제공함
- 코드 작성의 일부를 에이전트에게 맡기면서도 핵심적인 사고와 탐색은 사람이 직접 수행할 수 있음
- 에이전트의 역할을 정답 제공자에서 이해 환경 제작자로 확장하는 접근임
웹사이트 마이그레이션을 게임처럼 수행하기
- 개인 웹사이트를 한 프레임워크에서 다른 프레임워크로 이전할 때 Claude가 자동화 스크립트를 작성함
- 새 프레임워크에 익숙하지 않아 스크립트를 읽어도 “대략 맞아 보인다” 이상으로 평가하기 어려웠음
- 이를 해결하기 위해 Claude에게 이전 작업을 직접 수행하는 비디오게임 형태의 명령 센터를 만들도록 요청함
- 명령 센터에서는 다음 과정을 시각적으로 확인할 수 있음
- 버튼을 눌러 마이그레이션 단계를 하나씩 실행함
- 기존 사이트와 새 사이트를 화면 양쪽에 나란히 표시함
- 각 단계에서 새 사이트의 모습이 어떻게 달라지는지 확인함
- 파일 트리가 어떤 순서로 변하는지 관찰함
- 전체 변환을 한 번에 실행하는 대신 새 사이트가 단계적으로 살아나는 과정을 직접 경험함
- 손으로 모든 파일을 옮겼을 때와 비슷한 이해를 얻으면서도 필요한 작업과 관찰 환경이 미리 준비돼 있어 훨씬 빠르게 진행할 수 있음
코드를 이해하기 위한 코드를 생성하기
- 에이전트가 작성할 수 있는 코드는 제품 기능이나 자동화 스크립트에 한정되지 않음
- 사람이 다른 코드를 이해할 수 있도록 다음과 같은 임시 도구도 만들 수 있음
- 실행 시각화 도구
- 단계별 디버거
- 좌우 비교 화면
- 파일 트리 변화 표시기
- 상호작용형 개념 설명
- 작업을 작은 단계로 나눈 명령 센터
- 이런 도구는 장기적으로 유지되는 제품 코드가 아니어도 충분한 가치가 있음
- AI로 코드를 만드는 비용이 낮아지면서 특정 사람과 특정 작업을 위한 일회성 학습 환경도 현실적으로 만들 수 있음
팀에서는 함께 이해해야 함
- 개인이 시스템을 이해하는 것만으로는 팀 작업에 충분하지 않음
- 팀원들이 같은 정신 모형을 가지고 있어야 짧은 표현으로도 같은 구조와 동작을 떠올릴 수 있음
- 공유된 어휘와 이미지가 있으면 아이디어를 즉흥적으로 주고받고 새로운 방향을 함께 발전시키기 쉬움
- 반대로 각자가 별도의 에이전트와 고립된 상태로 작업하면 다음 문제가 생김
- 같은 용어를 서로 다른 의미로 사용함
- 기술적 계획의 전제를 공유하지 못함
- 결과물은 합쳐도 이해는 합쳐지지 않음
- 팀의 AI 활용은 각 개인의 생산성을 높이는 문제뿐 아니라 팀 전체의 공유 이해를 구축하는 문제임
에이전트와 사람의 작업을 같은 공유 공간에 남기기
- Notion에서는 Claude와 Cursor 에이전트를 페이지 안에서 실행할 수 있음
- 에이전트가 작성한 기술 계획은 기본적으로 협업 가능한 페이지에 만들어짐
- 팀원은 에이전트가 만든 계획을 별도의 채널로 복사하지 않고 같은 자리에서 바로 검토할 수 있음
- 특정 문장에 댓글을 남김
- 구현 선택을 질문함
- 계획을 함께 수정함
- 팀의 논의와 에이전트의 결과를 한 문맥에 남김
- 에이전트가 개인별 사일로 안에서 작업하는 대신, 사람과 에이전트가 공동 문서를 중심으로 사고하게 됨
- 공유 공간은 결과를 저장하는 문서함이 아니라 팀이 함께 정신 모형을 만드는 장소임
컴퓨터의 목적은 처음부터 증강이었음
- 코드 이해를 위한 설명/퀴즈/마이크로월드의 문제는 프로그래밍에만 한정되지 않음
- 사람은 결과를 검증하기 위해서만이 아니라 세상이 어떻게 작동하는지 이해하고 변화에 참여하기 위해 지식을 필요로 함
- Alan Kay는 약 50년 전 컴퓨터를 책보다 나은 새로운 교육 매체로 구상함
- 당시의 그림에는 아이들이 태블릿 같은 장치를 바라보는 모습이 나오지만, 영상을 수동적으로 시청하는 것이 아님
- 상호작용형 물리 시뮬레이션을 조작함
- 게임을 플레이하면서 코드를 직접 수정함
- 수정한 코드가 물리적 움직임을 어떻게 바꾸는지 확인함
- 컴퓨터는 정적인 정보를 전달하는 기계가 아니라 복잡한 개념을 움직이고 바꾸며 이해하게 하는 동적 매체가 될 수 있음
자동화만이 아니라 더 깊은 참여로
- 우주인이 지구를 바라보며 “컴퓨터의 목적은 복잡한 개념을 이해하기 위한 동적 시뮬레이션을 만드는 것이었나”라고 묻고, 뒤의 우주인이 “항상 그랬다”고 답하는 밈으로 핵심을 표현함
- 컴퓨터와 AI의 목적을 사람의 작업 제거에만 두면 사람은 시스템의 바깥으로 밀려날 수 있음
- 반대로 AI를 설명/시뮬레이션/마이크로월드/공유 공간을 만드는 데 사용하면 사람이 더 많은 개념을 더 깊게 이해할 수 있음
- AI가 시뮬레이션 제작 비용을 낮추면서, 특정 개념을 배우기 위한 맞춤형 환경을 필요할 때마다 생성할 수 있게 됨
- 목표는 사람을 루프에서 빼는 것만이 아니라 사람이 이전보다 더 깊이 루프 안으로 들어가도록 만드는 것임
관련 글
- Enough AI copilots! We need AI HUDs - 코파일럿을 넘어 인간의 정신을 더 직접적으로 확장하는 AI 인터페이스
- AI-generated tools can make programming more fun - AI로 맞춤형 디버거 UI를 만들어 사람이 직접 프로그래밍하는 과정을 개선한 사례
- Code like a surgeon - 부수적인 반복 작업은 위임하고 사람이 핵심 작업에 집중하는 방식
댓글과 토론
병목을 완전히 제거하려면
- AI 를 이용한 결과물에 대한 신뢰도가 지금보다 더 높아져야하고, 이를 사람(사장, 관리자)이 체감해야합니다.
- 일정 이상의 리스크를 감당할 수 있다면, 상당수의 병목이 제거될 것이라 판단합니다. 그래서 리스크가 통제되는 상황에서는 적극적으로 사람 개입없이 적용해보면 어떨까 싶기도 합니다.
- 만약 Human In The Loop 를 할 수 밖에 없는 상황이라면, 한 사람에게 완전히 의존하는 프로세스를 만들면 안됩니다. 어떤 사람이 와도 수행할 수 있게 해야하고, 상황에 따라서는 N 명이 투입될 수 있는 상황을 만들어야합니다.
- 병목을 발견하는 능력을 실무자 뿐아니라 관리자와 사장이 갈고 닦아야 합니다. 대부분의 병목은 의사결정을 통해 제거되거나 착아질 수 있습니다.
- 이런 논의를 실무자가 아니라 관리자와 사장이 해야합니다.
사람의 인지 및 기억 구조가 단기 기억, 장기 기억으로 나눠져 있기 때문에 아무리 이렇게 해서 AI의 코딩 속도를 올리려고 한들 사람이 중간중간에 확인하면서 단기 기억을 쌓는 것이 인지 부채에 가장 효율적이다라고 말하고 싶네요.