에이전트가 올린 5만 5천 줄 PR — Notion 엔지니어가 말한 “진짜 병목은 리뷰가 아니다”

by

에이전트가 코드를 점점 더 정확하게 검증해줄수록, 사람이 코드를 이해할 필요는 줄어드는 것처럼 보입니다. 그런데 이 진단은 절반만 맞습니다. 진짜 이해가 필요한 이유는 검증이 아니라 다음 아이디어를 떠올리는 창의적 참여 때문이며, 그 자리는 에이전트에게 위임할 수 없다는 것이 이 영상의 핵심 주장입니다.

채널 AgentOS가 정리한 이 콘텐츠에서, Notion에서 일하는 발표자는 실제 업무에서 매일 쓰는 이해 도구 두 가지—코드 diff 설명 문서와 마이크로월드—를 구체적인 예시와 함께 보여줍니다.

검증은 위임해도, 참여는 위임할 수 없다

발표자는 먼저 상대 논리를 인정합니다. 에이전트가 점점 더 정확하게 검증 절차를 거치게 되면서 정확성 검증에서 인간의 역할은 점점 줄어들고 있고, 원하는 결과를 정확하게 처리해준다면 오히려 반길 일이라는 것입니다. 문제는 여기서 사람들이 논리를 확장해 “에이전트가 똑똑해질수록 우리는 모든 것을 이해할 필요가 없다”고 결론 내리는 부분입니다.

코드 변경 작업은 한 번의 반복으로 끝나지 않습니다. 현재 상황을 이해하면 그 이해를 바탕으로 다음 단계로 나아가게 되고, 그 이해가 다음 아이디어를 떠올리고 프로젝트에 적극적으로 참여하는 창의적 구성원이 되는 토대가 됩니다. 머릿속에 풍부한 개념 구조가 있는 사람과 몇 단계 떨어져서 이해하는 사람이 만들어내는 아이디어는 분명히 다릅니다. 그래서 이 문제는 더 좋은 도구로 씻어낼 수 있는 문제가 아니라, 적극적인 참여자가 되려면 여전히 직접 해야 하는 일이라고 발표자는 강조합니다.

코드 diff를 4단계로 다시 쓰는 explain diff 스킬

발표자가 직접 만들어 매일 쓰고 동료들과도 공유하는 ‘explain diff’ 스킬은 코드 diff를 곧바로 보여주지 않고, 다음 네 단계로 설명 문서를 구성합니다.

  1. 배경 설명 — 게임 엔진과 좌표계, 하위 시스템이 어떻게 작동하는지부터 안내합니다. 이미 아는 내용이면 건너뛸 수 있습니다.
  2. 세부 사항보다 우선하는 직관 — 코드를 쏟아붓기 전에 이번 커밋의 핵심 목표를 한 문장으로 먼저 전달합니다.
  3. 상호작용형 그림 — 예를 들어 바위를 끌어보면 어떤 좌표가 움직이고 그림의 Z 레이어가 어떻게 변하는지 보여주는 작은 시뮬레이션을 넣습니다.
  4. 문해력 기반 코드 비교 — 파일을 순서대로 나열하는 대신, 각 파일을 보여주기 전에 무슨 내용인지 설명하는 산문을 붙입니다.

발표자는 이렇게 만든 문서를 출력해서 커피숍에 가져가 읽는다고 말하며, AI 덕분에 IDE에 몰두하던 방식에서 교과서를 읽듯 PR을 접하게 된 변화를 아이러니하면서도 아름답다고 표현합니다. Notion을 도구로 선택한 이유로는 협업 댓글 기능으로 팀원들이 문서에 댓글을 달고 토론할 수 있다는 점을 듭니다.

퀴즈를 통과 못 하면 리뷰를 요청하지 않는다

읽는 것만으로는 이해했다는 착각이 생길 수 있습니다. 발표자는 연구자 아니마 아난드의 “책은 효과가 없다”는 말에서 영감을 얻어, 자신이 만드는 코드 설명 문서 맨 아래에도 중간 난이도의 5문항 퀴즈를 넣습니다. 자신이 작성한 코드에 대한 퀴즈를 스스로 통과하지 못하면 동료에게 리뷰를 보내지 않는다는 규칙을 세웠다고 합니다. 이를 “속도 조절 장치”라고 부르며, AI 관련 모든 것이 속도를 높이라고 유도하는 상황에서 정확성의 속도뿐 아니라 이해의 속도까지 확보하기 위한 장치라고 설명합니다.

마이크로월드: 로봇이 아니라 사람이 달라지는 것

세 번째 축은 교육자 시모어 파퍼트에게서 받은 영감입니다. 파퍼트는 아이들이 수학을 직관적으로 배울 수 있는 “수학의 나라”가 있는지 물었고, 아이들이 프로그래밍해서 여러 일을 할 수 있는 거북이 로봇을 만들었습니다. 핵심은 로봇이 아니라 “변한 건 아이들”이라는 점입니다.

발표자는 프롤로그 인터프리터를 직접 구현하면서 내부 구현을 시각화하는 임시 디버거 UI를 만들어 기계에 대한 감을 잡았던 경험, 그리고 개인 웹사이트를 다른 프레임워크로 이전할 때 대본 대신 직접 이식 작업을 진행할 수 있는 비디오 게임을 만들어 달라고 요청했던 경험을 예로 듭니다. 핵심은 에이전트가 소프트웨어를 출시하는 대신, 사람이 이해하도록 돕는 작은 마이크로월드를 만들어준다는 점입니다.

실전 가이드: 오늘부터 적용하는 방법

코드 변경을 리뷰에 보내기 전에 explain diff 방식의 설명 문서부터 만듭니다. 배경 설명 → 핵심 직관 → (가능하다면) 상호작용형 그림 → 산문이 붙은 diff, 이 네 단계 순서를 그대로 따라가면 됩니다. 별도의 준비물 없이 기존 코드 diff와 커밋 메시지만 있으면 되고, 문서 하나를 만드는 데는 짧은 시간이면 충분합니다.

문서 맨 아래에 중간 난이도의 퀴즈 5문항을 붙이고, 리뷰를 요청하기 전에 스스로 풀어봅니다. 여기서 통과하지 못하면 리뷰를 보내지 않는다는 규칙을 지키는 것이 중요합니다. 이 규칙을 지키면 스스로 이해하지 못한 부분을 리뷰 요청 전에 미리 발견할 수 있습니다.

인터프리터 구현이나 시스템 마이그레이션처럼 내부 동작이 복잡한 작업에서는, 텍스트 설명 대신 에이전트에게 상태를 단계별로 볼 수 있는 임시 디버거 UI나 마이그레이션을 한 단계씩 재생해볼 수 있는 작은 시뮬레이션을 만들어달라고 요청합니다. 버그를 고치거나 단계를 넘기면서 실제로 기계나 시스템에 대한 감이 잡혔는지를 성공 지표로 삼고, 이후에는 이 마이크로월드를 팀 동료와 공유해 함께 상태를 짚어보는 방식으로 발전시킬 수 있습니다.

비판적 검토

영상은 추상적인 주장을 발표자가 매일 쓰는 구체적인 도구로 뒷받침하고 있다는 점이 인상적입니다. 새로운 개념을 만들어내는 대신 간격 반복 학습, 파퍼트의 구성주의 교육론처럼 이미 검증된 교육학 방법을 코드 이해에 그대로 적용했다는 설명 방식도 설득력을 더합니다.

다만 발표자 스스로도 상호작용형 요소를 다룰 때는 신중해야 하며, 잘못 쓰면 “그냥 목발”이거나 “허술할 수 있다”고 인정합니다. 어떤 변경에 인터랙티브 그림이 실제로 필요하고 어떤 변경에는 과한 장치인지 판단하는 기준은 영상에서 구체적으로 제시되지 않습니다. 또한 팀이 함께 이해하는 방법에 대한 기법은 시간 관계상 다루지 못했다고 밝히고 있어, 팀 단위 적용은 원본 영상(15:17 지점)을 별도로 확인해야 합니다. 이 영상은 원 발표를 한국어로 편집·정리한 요약 클립이므로, 세부 구현 방식의 뉘앙스는 원본 발표를 함께 참고하는 것이 정확합니다.

핵심 요점

영상을 본 후 기억해야 할 다섯 가지입니다.

  1. 에이전트가 정확성 검증을 잘할수록 사람이 할 일이 줄어드는 것처럼 보이지만, 다음 아이디어를 떠올리는 창의적 참여의 자리는 이해에서만 나오며 위임할 수 없습니다.
  2. 코드를 리뷰에 보내기 전, 배경 설명 → 직관 → 상호작용형 그림 → 주석 붙은 diff 순서의 4단계 설명 문서를 먼저 만들어보면 스스로 이해했는지 점검할 수 있습니다.
  3. 문서 아래에 중간 난이도 퀴즈 5문항을 붙이고, 스스로 통과하지 못하면 리뷰를 요청하지 않는 규칙을 세우면 이해의 속도를 정확성의 속도와 맞출 수 있습니다.
  4. 복잡한 내부 동작은 텍스트 설명보다 직접 만져볼 수 있는 임시 디버거나 단계별 시뮬레이션(마이크로월드)으로 이해하는 편이 효과적이며, 핵심은 도구가 아니라 그 과정에서 달라지는 사람입니다.
  5. 이런 접근은 새로 생긴 요구가 아니라, 앨런 케이가 50년 전 에세이에서 이미 그렸던 목표—컴퓨터가 아니라 사람을 한 단계 발전시키는 것—를 지금의 도구로 되살리는 일입니다.

참고자료

Leave a Comment