• 에이전트가 작성한 코드가 사람 주변에 계속 쌓이는 상황에서 개발 속도를 제한하는 요소는 코드 생성 능력이 아니라 시스템을 따라가며 다음 변화를 구상할 수 있는
  인간의 이해 속도로 이동하고 있음
• 코드를 이해하는 목적은 결과를 승인하거나 거부하는
  검증에 그치지 않으며, 여러 차례 이어지는 에이전트 작업 루프에서 다음 아이디어를 제안하고 창작 과정에 참여하는 데 있음
• 원시 코드 차이 대신 배경지식/변경 목표/상호작용형 도표/서술식 코드 차이를 묶은
  코드 설명 문서를 먼저 읽으면 변경의 구조와 의도를 더 빠르게 파악할 수 있음
• 설명 문서의 퀴즈와 실행 과정을 직접 조작하는
  마이크로월드는 에이전트가 대신 판단하게 하지 않고 사람이 시스템의 상태 변화와 내부 작동을 체험하도록 만듦
• 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가 시뮬레이션 제작 비용을 낮추면서, 특정 개념을 배우기 위한
  맞춤형 환경을 필요할 때마다 생성할 수 있게 됨
• 목표는 사람을 루프에서 빼는 것만이 아니라 사람이 이전보다
  더 깊이 루프 안으로 들어가도록 만드는 것임

관련 글

댓글과 토론