AI × HUMAN UNDERSTANDING
AI 시대,
이해가 새로운 병목이다
코드를 만드는 속도보다
시스템을 따라잡는 속도가 중요해졌다.
안녕하세요. SCV입니다.
AI 코딩 에이전트에게 일을 맡기면 구현은 놀랄 만큼 빨라집니다. 요구사항을 설명하고 잠시 기다리면 여러 파일이 바뀌고 테스트까지 추가됩니다. 그런데 결과가 쌓일수록 이상한 역전이 일어납니다. 코드를 만드는 시간은 줄었는데, 무엇이 왜 바뀌었는지 따라잡는 시간은 오히려 부족해집니다. 이제 생산성을 제한하는 것은 타이핑 속도나 코드 생성 능력이 아니라 사람이 시스템을 이해하는 속도일 수 있습니다.
Geoffrey Litt는 2026년 7월 AI Engineer 발표를 정리한 글 「Understanding is the new bottleneck」에서 이 문제를 정면으로 다룹니다. 그의 주장은 단순히 “AI가 만든 코드를 꼼꼼히 검토하자”가 아닙니다. 사람이 이해해야 하는 더 중요한 이유는 결과를 승인하거나 거부하기 위해서가 아니라, 다음 변화를 상상하고 프로젝트의 창작 과정에 계속 참여하기 위해서라는 것입니다. 이 관점은 AI 시대의 개발 방법뿐 아니라 기획, 디자인, 데이터 분석, 조직의 의사결정 방식까지 다시 보게 만듭니다.
UNDERSTANDING LAYER
생성 속도는 빨라졌지만 이해 대역폭은 그대로다
예전에는 개발자가 코드를 작성하는 과정 자체가 이해를 만드는 시간이었습니다. 함수 이름을 고민하고 오류를 추적하고 구조를 고치는 동안 시스템의 제약과 가능성이 머릿속에 축적됐습니다. 코드 작성은 결과를 생산하는 행위인 동시에 정신 모형을 구축하는 학습 과정이었습니다.
에이전트는 이 둘을 분리합니다. 결과는 빠르게 생산하지만, 그 결과에 도달하는 동안 사람이 겪던 시행착오와 관찰은 생략됩니다. 한 번의 작업에서 바뀐 코드가 정확하고 테스트가 통과하더라도, 담당자는 어떤 선택지가 버려졌는지, 어느 가정에 기대고 있는지, 다음 요구사항이 들어오면 어디가 흔들릴지 모를 수 있습니다. 출력의 품질과 인간의 이해 수준은 같은 속도로 증가하지 않습니다.
이때 흔한 대응은 모든 코드 차이를 한 줄씩 읽는 것입니다. 원시 diff는 필요한 자료지만 언제나 좋은 학습 순서는 아닙니다. 파일명 순서로 나열된 변경 조각은 변경의 목적, 파일 사이의 관계, 먼저 알아야 할 배경을 알려주지 않습니다. 재료는 모두 있지만 조리법과 식사의 순서가 없는 셈입니다. AI가 한 번에 수천 줄을 바꿀 수 있는 환경에서는 읽는 양을 늘리는 것만으로 생성 속도를 따라잡기 어렵습니다.
핵심은 이해를 포기하는 것이 아니라 이해의 인터페이스를 바꾸는 것입니다. 코드를 더 많이 읽는 대신 어떤 배경을 먼저 알아야 하는지, 이번 변경의 본질이 무엇인지, 상태가 어떤 순서로 움직이는지, 판단을 좌우하는 제약이 무엇인지 압축해서 보여줘야 합니다. 같은 시스템이라도 설명의 순서와 표현 방식이 달라지면 이해에 필요한 시간은 크게 줄어듭니다.
UNDERSTANDING LAYER
이해는 검증보다 참여를 위한 능력이다
사람이 AI 결과를 이해해야 하는 이유를 물으면 가장 먼저 나오는 답은 검증입니다. 요구사항에 맞는지, 보안상 문제가 없는지, 구조가 적절한지 확인하고 마지막에 승인 또는 거절을 내리는 역할입니다. 물론 고위험 시스템에서 인간의 검증은 여전히 중요합니다. 그러나 사람의 역할을 최종 심사자로만 정의하면 이해는 합격 여부를 판단하기 위한 비용으로 축소됩니다.
에이전트의 자체 검증 능력도 계속 향상되고 있습니다. 테스트를 만들고 실행하며 실패를 분석하고 브라우저 화면을 확인하는 루프를 스스로 돌립니다. 검증 능력이 좋아질수록 “사람은 마지막 버튼만 누르면 된다”는 결론으로 흐르기 쉽습니다. 하지만 실제 프로젝트는 한 번의 지시와 한 번의 결과로 끝나지 않습니다. 목표를 정하고 구현하고 확인하고 수정하고 확장하는 수많은 루프가 이어집니다.
각 루프에서 다음 질문을 만드는 주체는 시스템에 대한 이해를 필요로 합니다. 지금 무엇을 추가할 것인가, 어떤 복잡성을 제거할 것인가, 예상하지 못한 가능성을 제품으로 발전시킬 것인가, 어느 제약을 받아들이고 어느 제약을 바꿀 것인가를 결정해야 합니다. 머릿속에 풍부한 개념과 관계가 있어야 새로운 방향을 유창하게 상상할 수 있습니다.
그래서 이해는 브레이크가 아니라 조향 장치에 가깝습니다. 검증만 하는 사람은 이미 만들어진 결과에 반응하지만, 이해하는 사람은 다음 결과의 방향을 만듭니다. “대략 맞아 보인다”에서 멈추는 팀과 “이 구조라면 이런 기능도 가능하겠다”고 이어가는 팀의 차이는 프롬프트 기술보다 정신 모형의 깊이에서 생깁니다.
UNDERSTANDING LAYER
이해를 미루면 인지 부채가 쌓인다
기술 부채는 빠른 선택의 대가가 코드에 남아 미래의 변경 비용을 높이는 현상을 가리킵니다. 인지 부채는 비슷한 비용이 사람과 팀의 머릿속에 쌓이는 현상입니다. Margaret-Anne Storey는 생성형 AI와 에이전트가 널리 쓰이는 환경에서 기술 부채보다 인지 부채가 더 큰 위협이 될 수 있다고 지적합니다. 코드가 비교적 깔끔해도 사람이 시스템의 이야기를 잃어버리면 무엇을 어떻게 바꿔야 하는지 판단할 수 없기 때문입니다.
인지 부채는 빌드 실패처럼 즉시 드러나지 않습니다. 간단한 변경도 예상치 못한 곳을 망가뜨릴까 두려워지고, 특정 사람의 구두 지식에 의존하며, 시스템이 점점 블랙박스처럼 느껴지는 형태로 나타납니다. 팀은 계속 기능을 출시하므로 겉보기 속도는 유지될 수 있지만 다음 의사결정의 품질과 자신감은 서서히 떨어집니다.
특히 개인마다 별도의 에이전트와 대화하는 조직에서는 결과물은 합쳐져도 이해는 합쳐지지 않을 수 있습니다. 한 사람은 인증 구조를 에이전트와 바꾸고, 다른 사람은 데이터 모델을 수정하고, 또 다른 사람은 화면 흐름을 추가합니다. 각자 자신의 대화 안에서는 맥락이 있지만 팀 전체가 공유하는 언어와 그림이 남지 않으면 통합 이후의 시스템을 누구도 온전히 설명하지 못합니다.
인지 부채를 줄이는 방법은 모든 자동화를 멈추는 것이 아닙니다. 빠른 생성과 느린 이해 사이에 의도적인 동기화 지점을 두는 것입니다. 중요한 변경마다 최소 한 명이 이유와 제약을 설명할 수 있게 하고, 무엇이 바뀌었는지만이 아니라 왜 그렇게 바뀌었는지 기록하며, 정기적으로 팀의 정신 모형을 다시 맞추는 시간이 필요합니다.
UNDERSTANDING LAYER
방법 1: 원시 diff보다 설명 문서를 먼저 읽는다
Litt가 매일 사용한다는 /explain-diff는 에이전트가 수행한 변경을 학습용 설명 문서로 바꾸는 방식입니다. 좋은 설명은 “무엇이 바뀌었는가”에서 바로 시작하지 않습니다. 먼저 기존 시스템이 어떻게 작동했는지 알려주고, 이번 변경의 목표와 직관을 제시한 다음, 이해하기 좋은 순서로 코드 조각을 배치합니다.
예를 들어 2D 게임의 정원을 입체적으로 보이게 만드는 변경이라면 수식이나 파일 목록부터 보여주지 않습니다. 기존 렌더링 방식과 좌표 체계를 설명하고, “2D 그리기 기법으로 정원을 3차원처럼 보이게 한다”는 목표를 제시한 뒤 등각 투영의 직관을 알려줍니다. 이 배경을 가진 상태에서 좌표 변환 코드를 보면 각 계산이 전체 효과에서 맡은 역할을 연결하기 쉬워집니다.
이런 형식을 서술식 코드 차이, 즉 literate diff라고 부를 수 있습니다. 원시 diff가 변경 재료를 파일 순서대로 쌓아둔 것이라면 서술식 diff는 목적과 인과관계에 맞춰 편집한 이야기입니다. 배경, 직관, 실행 흐름, 중요한 선택, 필요한 코드 조각 순으로 읽고 마지막에 원시 diff를 확인하면 검토 속도와 이해의 질을 함께 높일 수 있습니다.
설명 문서는 원시 코드를 대체하지 않습니다. 원시 코드를 읽기 위한 지도에 가깝습니다. 지도 없이 모든 골목을 걷는 것과 목적지와 주요 지형을 확인한 뒤 걷는 것은 같은 거리를 이동해도 인지 부담이 다릅니다. 팀에서는 설명서를 개인 메시지에 가두지 말고 댓글과 질문이 남는 공유 문서에 두는 편이 좋습니다.
실무에서 설명 문서에 꼭 들어갈 항목은 5가지입니다. 첫째, 변경 전 시스템의 최소 배경입니다. 둘째, 이번 변경이 해결하는 문제와 성공 기준입니다. 셋째, 요청부터 출력까지의 실행 흐름입니다. 넷째, 선택한 구조와 버린 대안입니다. 다섯째, 다음 변경에 영향을 줄 제약과 실패 지점입니다. 이 정도만 있어도 파일 목록식 요약보다 훨씬 유용한 검토 출발점이 됩니다.
UNDERSTANDING LAYER
방법 2: 퀴즈를 AI 루프의 속도 조절 장치로 쓴다
잘 쓴 설명을 읽었다고 해서 실제로 이해한 것은 아닙니다. 문장을 눈으로 따라가는 동안 익숙하다는 느낌이 생기지만, 책을 덮고 핵심을 설명하려 하면 기억나지 않는 경우가 많습니다. Andy Matuschak와 Michael Nielsen의 Quantum Country는 글 안에 회상 질문을 넣어 읽기와 기억 사이의 간극을 줄이는 “기억 매체”를 실험했습니다.
Litt는 이 아이디어를 코드 설명에 적용합니다. 설명 문서 마지막에 변경 내용에 관한 5개의 질문을 두고, 자신이 답할 수 있을 때만 다른 사람에게 코드를 보냅니다. 다른 사람의 변경을 검토할 때도 같은 기준을 씁니다. 여기서 퀴즈는 점수를 매기는 시험이 아니라 AI 루프의 속도를 인간의 이해 속도에 맞추는 조절 장치입니다.
좋은 질문은 문서의 문장을 그대로 찾는 문제가 아닙니다. “요청이 실패할 때 어느 계층에서 복구되는가”, “이 캐시를 제거하면 어떤 불변 조건이 깨지는가”, “새 요구사항이 들어오면 어느 경계를 확장해야 하는가”처럼 인과관계와 제약을 회상하게 해야 합니다. 정답 위치나 문장 길이만 보고 맞힐 수 없도록 선택지도 비슷한 밀도로 구성해야 합니다.
팀에서 더 간단히 적용하려면 코드 리뷰 설명란에 3개의 질문만 추가해도 됩니다. 리뷰어가 답하지 못했다면 곧바로 반려하기보다 설명이 부족한 지점을 찾습니다. 작성자도 답하지 못한다면 생성 속도를 잠시 늦추고 시스템을 다시 탐색해야 한다는 신호입니다. 질문은 개인을 평가하는 도구가 아니라 공유 이해의 빈틈을 탐지하는 센서여야 합니다.
UNDERSTANDING LAYER
방법 3: 마이크로월드로 시스템 안에 들어간다
문서와 퀴즈로도 이해하기 어려운 시스템이 있습니다. 동시성, 상태 머신, 렌더링 좌표, 네트워크 재시도처럼 시간에 따라 상태가 변하는 영역은 정적인 설명만으로 직관을 만들기 어렵습니다. 이때 유용한 것이 마이크로월드입니다. 마이크로월드는 복잡한 프로덕션 시스템 전체가 아니라 특정 원리와 상태 변화를 안전하게 관찰하고 조작하도록 만든 작은 실행 환경입니다.
Litt는 Prolog 인터프리터의 내부 동작을 이해하기 위해 에이전트와 함께 전용 디버거를 만들었습니다. 사용자는 실행 시간을 앞뒤로 이동하고, 현재 스택의 값을 보고, 어떤 규칙이 평가되는지 단계별로 확인합니다. 에이전트에게 오류 수정을 맡기면 결과는 빨리 얻을 수 있지만, 사람이 디버거를 조작하면 실행 구조에 대한 이해가 남습니다.
웹사이트 프레임워크 이전 사례도 인상적입니다. Claude가 자동화 스크립트를 만들었지만 새 프레임워크에 익숙하지 않은 사람은 그 스크립트를 보고 “대략 맞는 것 같다”는 판단밖에 하기 어려웠습니다. 그래서 전체 이전을 한 번에 수행하는 대신 단계별 버튼, 이전·이후 화면, 파일 트리 변화를 보여주는 게임 같은 명령 센터를 만들었습니다. 손으로 모든 파일을 옮기지 않아도 변화가 축적되는 과정을 직접 경험할 수 있었습니다.
중요한 전환은 “AI가 문제를 대신 해결한다”에서 “AI가 사람이 문제를 탐색할 환경을 만든다”로 역할을 넓히는 것입니다. 에이전트는 제품 코드뿐 아니라 상태 시각화기, 단계별 디버거, 전후 비교 화면, 데이터 흐름 재생기처럼 이해를 위한 일회성 코드도 저렴하게 만들 수 있습니다. 오래 유지할 도구가 아니어도 한 번의 중요한 판단을 개선한다면 충분한 가치가 있습니다.
마이크로월드를 요청할 때는 관찰 대상과 조작 범위를 분명히 해야 합니다. 어떤 상태를 보고 싶은지, 사용자가 어떤 입력을 바꿀 수 있는지, 변화가 어떤 출력으로 드러나는지, 실제 시스템과 무엇이 다른지 적어야 합니다. 그렇지 않으면 예쁜 데모는 만들어져도 잘못된 정신 모형을 학습할 수 있습니다.
UNDERSTANDING LAYER
방법 4: 개인의 이해를 팀의 공유 공간으로 옮긴다
개인이 시스템을 잘 이해해도 팀의 언어가 다르면 협업 비용은 줄지 않습니다. 함께 일하려면 같은 단어를 들었을 때 비슷한 구조와 동작을 떠올리는 공유 정신 모형이 필요합니다. 공유된 모형이 있으면 짧은 대화로도 아이디어를 발전시킬 수 있지만, 각자가 별도의 AI 대화에 갇히면 전제와 선택 이유가 사라집니다.
에이전트가 만든 계획, 설명, 실험 결과를 팀원이 이미 일하는 공유 공간에 남기는 것이 중요합니다. 문서의 특정 문장에 댓글을 달고, 구현 선택을 질문하고, 계획을 함께 수정하며, 결정의 근거가 같은 맥락에 축적되어야 합니다. 공유 공간은 결과물 보관함이 아니라 사람과 에이전트가 공동으로 정신 모형을 만드는 작업대입니다.
여기서 문서화의 목표도 달라집니다. 모든 내용을 완벽하게 기록하는 것이 아니라 다음 대화를 가능하게 하는 공통 언어를 만드는 것입니다. 핵심 상태, 경계, 불변 조건, 실패 방식, 결정 이유가 유지되면 세부 구현은 필요할 때 코드에서 확인할 수 있습니다. 반대로 자동 생성된 장문의 요약만 쌓이면 정보량은 늘어도 누구도 읽지 않아 또 다른 부채가 됩니다.
UNDERSTANDING LAYER
실무 적용: 이해 예산을 작업 정의에 포함한다
이 관점을 실무에 적용하려면 “코드 완료”와 “작업 완료”를 구분해야 합니다. 테스트가 통과하고 배포 가능해진 시점은 코드 완료입니다. 담당자가 변경의 목적과 실행 흐름, 주요 제약, 다음 확장 지점을 설명할 수 있고 팀의 공유 자료가 갱신된 시점이 작업 완료입니다. 모든 작은 수정에 무거운 절차를 붙일 필요는 없지만 위험도와 변화량에 따라 이해 예산을 배정해야 합니다.
낮은 위험의 단순 변경은 짧은 요약과 자동 테스트로 충분할 수 있습니다. 여러 경계를 건드리는 중간 위험 변경은 배경·목표·흐름을 담은 설명과 3개의 회상 질문이 적절합니다. 인증, 결제, 데이터 이전처럼 되돌리기 어렵거나 영향 범위가 큰 변경은 실행 가능한 마이크로월드, 롤백 경로, 팀 리뷰까지 필요합니다. 이해 비용을 일률적으로 적용하지 않고 리스크에 비례시키는 것이 핵심입니다.
에이전트에게 작업을 요청할 때도 산출물을 코드만으로 한정하지 마세요. “구현 후 변경 전 배경, 실행 흐름, 선택 이유, 실패 지점을 설명하라”, “내가 이해했는지 확인할 질문 5개를 만들라”, “상태 변화를 단계별로 조작할 수 있는 작은 관찰 도구를 만들라”고 함께 요청할 수 있습니다. 생성 능력을 더 많은 제품 코드에만 쓰지 않고 인간의 이해 대역폭을 늘리는 데 투자하는 것입니다.
회의에서는 진행률보다 설명 가능성을 확인할 수 있습니다. 담당자가 현재 구조를 3분 안에 설명할 수 있는지, 새 요구사항을 어느 경계에 연결할지 말할 수 있는지, 한 명이 빠져도 팀이 결정의 이유를 재구성할 수 있는지 묻습니다. 답이 흐릿하면 더 빨리 생성하는 것보다 공유 이해를 복구하는 편이 장기적으로 빠릅니다.
UNDERSTANDING LAYER
자동화와 인간 참여는 양자택일이 아니다
“결국 AI의 신뢰도가 충분히 높아지면 사람이 이해할 필요도 사라지는 것 아닌가”라는 반론이 가능합니다. 리스크가 낮고 결과를 쉽게 되돌릴 수 있으며 성공 기준이 자동으로 측정되는 작업에서는 사람을 루프에서 빼는 편이 합리적입니다. 모든 로그 정리나 의존성 업데이트를 사람이 깊이 공부할 필요는 없습니다.
하지만 목표가 계속 진화하고 좋고 나쁨의 기준이 열려 있는 창작 작업에서는 이야기가 다릅니다. 제품의 다음 방향, 사용자 경험의 미묘한 질, 조직이 감수할 위험, 장기적인 구조 선택은 현재 결과를 넘어선 판단을 요구합니다. 이 판단에 참여하려면 시스템에 대한 개념과 직관이 필요합니다. 자동화할 영역과 이해를 보존할 영역을 구분하는 것이 성숙한 AI 활용입니다.
또한 사람을 루프에 둔다고 해서 한 명의 영웅에게 모든 맥락을 의존해서는 안 됩니다. 설명 문서와 마이크로월드, 공유된 결정 기록은 이해를 여러 사람에게 복제할 수 있게 합니다. 목표는 병목이 된 개인을 더 압박하는 것이 아니라 팀의 이해 대역폭을 넓히는 것입니다.
UNDERSTANDING LAYER
컴퓨터의 목적은 자동화만이 아니라 증강이었다
이 논의의 뿌리는 AI보다 오래됐습니다. Seymour Papert는 수학을 설명으로만 배우는 대신 수학적 개념이 자연스럽게 작동하는 작은 세계에서 탐색하도록 해야 한다고 보았습니다. Alan Kay는 약 50년 전 컴퓨터를 책보다 역동적인 학습 매체로 상상했습니다. 아이가 시뮬레이션을 조작하고 코드를 바꾸며 물리적 움직임의 변화를 확인하는 도구였습니다.
오늘날 AI는 이런 맞춤형 설명과 시뮬레이션을 만드는 비용을 크게 낮춥니다. 특정 코드 변경을 위한 설명서, 한 번만 쓸 상태 탐색기, 팀의 논의를 위한 전후 비교 화면을 필요할 때 만들 수 있습니다. 이는 사람을 시스템 바깥으로 밀어내는 자동화와 다른 가능성입니다. 사람이 이전보다 더 깊게 시스템 안으로 들어가도록 돕는 증강입니다.
AI 시대의 경쟁력은 누가 더 많은 코드를 생성하느냐로만 결정되지 않을 것입니다. 생성된 시스템을 누가 더 빠르고 정확하게 이해하고, 그 이해를 팀과 공유하며, 다음 질문으로 연결하느냐가 중요해집니다. 코드가 싸질수록 맥락과 판단은 비싸집니다. 출력이 넘쳐날수록 무엇을 만들고 왜 바꿔야 하는지 설명할 수 있는 능력이 희소해집니다.
결론은 AI를 덜 쓰자는 것이 아닙니다. AI가 만든 결과만 받지 말고, AI에게 이해의 도구도 만들게 하자는 것입니다. 설명을 먼저 읽고, 질문으로 회상하고, 작은 세계를 직접 조작하고, 팀의 공유 공간에서 정신 모형을 맞춰야 합니다. 사람을 루프에서 제거하는 것만이 진보는 아닙니다. 올바른 도구를 만든다면 우리는 더 깊이 루프 안으로 들어갈 수 있습니다.
UNDERSTANDING LAYER
게시 전 체크리스트
- 이번 변경의 목적을 코드 없이 2문장으로 설명할 수 있는가?
- 요청부터 출력까지 주요 상태 변화를 순서대로 말할 수 있는가?
- 선택한 구조의 이유와 버린 대안을 알고 있는가?
- 실패 가능성이 큰 경계와 복구 방법을 알고 있는가?
- 다음 요구사항이 들어오면 어디를 확장해야 하는지 짐작할 수 있는가?
- 이 이해가 개인 채팅이 아니라 팀의 공유 공간에 남아 있는가?
- 정적 설명으로 부족하다면 직접 조작할 작은 관찰 도구가 있는가?
UNDERSTANDING LAYER
팀에 도입하는 4단계 운영안
첫 단계는 현재 흐름을 측정하는 것입니다. 지난 2주 동안 AI가 만든 변경 가운데 담당자가 이유를 설명하기 어려웠던 사례, 리뷰가 “테스트가 통과하니 승인”으로 끝난 사례, 후속 변경에서 다시 구조를 조사해야 했던 사례를 모읍니다. 코드 줄 수나 프롬프트 횟수보다 재탐색 시간, 질문이 특정인에게 집중된 정도, 예상하지 못한 부작용으로 되돌린 횟수가 인지 부채를 더 잘 보여줍니다. 목표는 사람을 감시하는 것이 아니라 이해가 끊기는 지점을 찾는 것입니다.
두 번째 단계는 변경을 3개 등급으로 나누는 것입니다. 1등급은 문구 수정, 독립된 스타일 조정, 쉽게 되돌릴 수 있는 자동 정리처럼 영향이 제한된 작업입니다. 자동 테스트와 2문장 요약이면 충분합니다. 2등급은 여러 모듈을 통과하거나 데이터 계약을 바꾸는 작업입니다. 변경 전 배경, 실행 흐름, 선택 이유, 회상 질문이 필요합니다. 3등급은 인증·권한·결제·마이그레이션·개인정보처럼 실패 비용이 큰 작업입니다. 서술식 diff, 상태 시각화 또는 리허설 환경, 복구 계획, 2명 이상의 공유 검토를 요구합니다.
세 번째 단계는 에이전트의 완료 조건을 바꾸는 것입니다. 기존 완료 조건이 “코드 작성, 테스트 통과, 린트 통과”였다면 여기에 “설명 패킷 생성, 근거 링크 연결, 불확실한 가정 표시”를 추가합니다. 설명이 코드를 꾸미는 사후 보고서가 되지 않게 하려면 에이전트가 탐색 중 발견한 경계와 대안을 함께 남기도록 해야 합니다. 구현이 끝난 뒤 기억을 재구성하는 것보다 결정이 일어날 때 근거를 포착하는 편이 정확합니다.
네 번째 단계는 짧은 이해 체크를 실제 리뷰에 넣는 것입니다. 발표식 회의를 새로 만들 필요는 없습니다. 리뷰어가 설명 문서의 흐름을 따라가며 “이 입력이 들어오면 상태가 어디서 바뀌는가”, “이 실패는 사용자에게 어떻게 보이는가”, “다음 확장은 어느 계약을 건드리는가”를 묻습니다. 답이 곧바로 나오지 않으면 담당자의 능력 부족으로 보지 말고 문서나 관찰 도구가 보완되어야 할 지점으로 기록합니다. 2~3회 반복하면 팀이 자주 놓치는 설명 요소가 템플릿으로 정착합니다.
UNDERSTANDING LAYER
이해 패킷에 넣을 최소 구성
이해 패킷은 장문의 설계 문서가 아닙니다. 변화의 위험도에 맞게 5분에서 20분 안에 읽을 수 있는 안내서가 이상적입니다. 첫 화면에는 변경 목적, 사용자에게 보이는 결과, 영향받는 시스템 경계를 놓습니다. 그다음에는 변경 전과 변경 후의 흐름을 나란히 보여주고, 데이터나 상태가 이동하는 순서를 표시합니다. 이후에 구조 선택의 이유와 대안을 설명하고, 마지막에는 실패 방식과 확인 질문을 둡니다.
좋은 패킷은 사실과 해석을 구분합니다. “테스트 18개가 통과했다”, “이 함수가 모든 쓰기 요청의 진입점이다”는 확인 가능한 사실입니다. “향후 확장이 쉬울 것이다”, “이 구조가 가장 단순하다”는 판단이므로 근거와 조건을 적어야 합니다. AI 설명은 매끄러운 문장 때문에 확정된 사실처럼 보이기 쉬우므로 관찰한 내용, 추론한 내용, 아직 확인하지 못한 내용을 시각적으로 분리하면 과신을 줄일 수 있습니다.
또한 패킷은 변경된 파일을 모두 요약할 필요가 없습니다. 독자가 머릿속에 실행 모델을 만들 수 있게 핵심 경로만 고릅니다. 파일 중심이 아니라 사용자의 동작이나 시스템 이벤트에서 출발해 입력, 판단, 상태 변경, 출력, 실패 처리 순으로 설명합니다. 세부 코드는 이 흐름을 입증하는 데 필요한 부분만 넣고 전체 diff로 연결합니다.
UNDERSTANDING LAYER
에이전트에게 바로 쓸 수 있는 요청 템플릿
다음 템플릿은 구현 요청의 마지막에 붙일 수 있습니다.
“작업을 마친 뒤 코드를 나열하지 말고 내가 변경을 이해할 수 있는 패킷을 작성해 주세요. 먼저 변경 전 시스템의 관련 배경을 설명하고, 이번 목표를 1문장으로 요약하세요. 사용자 입력부터 최종 출력까지 실행 흐름을 단계별로 보여주세요. 선택한 구조의 이유와 검토했지만 채택하지 않은 대안을 구분하세요. 확인된 사실, 합리적 추론, 아직 검증하지 않은 가정을 표시하세요. 가장 위험한 실패 지점과 되돌리는 방법을 적고, 실제 이해 여부를 확인할 수 있는 질문 5개를 만드세요. 상태 변화가 정적인 글로 이해하기 어렵다면 프로덕션 데이터 없이 실행되는 작은 관찰 도구를 제안하세요.”
이 요청의 장점은 더 긴 설명을 강요하는 데 있지 않습니다. 배경, 인과관계, 불확실성, 실패라는 서로 다른 이해 요소를 빠뜨리지 않게 하는 데 있습니다. 에이전트의 답이 길지만 실행 흐름을 말하지 않거나, 확신에 찬 표현만 있고 근거가 없다면 패킷은 아직 완료되지 않은 것입니다.
UNDERSTANDING LAYER
인지 부채를 감지하는 8가지 신호
첫째, 작은 변경을 시작할 때마다 같은 파일과 로그를 처음부터 다시 조사합니다. 둘째, 리뷰 의견이 구조나 인과관계보다 형식과 테스트 통과 여부에만 몰립니다. 셋째, “왜 이렇게 만들었는가”라는 질문에 당시 에이전트 대화를 찾아야만 답할 수 있습니다. 넷째, 담당자가 휴가를 가면 특정 영역의 변경이 사실상 멈춥니다. 다섯째, 비슷한 기능이 기존 경계를 모르고 별도 경로로 반복 구현됩니다. 여섯째, 새 요구사항을 어디에 연결해야 할지 합의하는 시간이 구현 시간보다 길어집니다. 일곱째, 장애가 나면 증상을 고치지만 어떤 상태 전이가 원인이었는지 설명하지 못합니다. 여덟째, 문서는 많지만 현재 시스템을 5분 안에 설명해 주는 자료는 없습니다.
이 신호 가운데 3개 이상이 반복된다면 더 많은 코드를 생성하기 전에 공유 이해를 복구할 필요가 있습니다. 최근의 중요한 변경 1개를 골라 실행 흐름을 다시 그리고, 결정 이유를 재구성하고, 담당자가 아닌 팀원이 설명해 보게 하는 것으로 시작할 수 있습니다. 이해 복구의 효과는 문서 개수보다 후속 변경의 탐색 시간, 리뷰 질문의 질, 장애 원인 파악 속도에서 확인해야 합니다.
UNDERSTANDING LAYER
역할별로 무엇을 이해해야 하는가
개발자는 주요 실행 경로와 데이터 계약, 실패 처리, 되돌리기 방법을 설명할 수 있어야 합니다. 모든 구현 세부를 암기할 필요는 없지만 어느 경계가 어떤 책임을 갖는지 알아야 후속 변경을 설계할 수 있습니다. 리뷰어는 코드 스타일보다 변경의 가정과 영향 범위를 확인하고, 설명과 실제 코드가 어긋나는 지점을 찾아야 합니다.
기획자와 제품 책임자는 성공 기준, 사용자에게 보이는 상태, 자동화가 내리는 결정의 범위를 이해해야 합니다. 시스템 내부의 모든 함수를 알 필요는 없지만 어떤 예외에서 사람이 개입해야 하는지, 무엇이 자동으로 되돌릴 수 없는지 판단해야 합니다. 디자이너는 정상 화면뿐 아니라 대기, 실패, 부분 완료, 권한 부족처럼 시스템 상태가 사용자 경험으로 번역되는 방식을 알아야 합니다.
관리자는 생성량을 생산성으로 착각하지 않도록 팀의 이해 건강도를 살펴야 합니다. 한 사람에게 맥락이 집중되지 않았는지, 중요한 결정이 공유 공간에 남는지, 속도 목표가 설명과 검토를 밀어내는지 확인해야 합니다. 관리자의 역할은 모든 코드를 이해하는 것이 아니라 팀이 이해를 만들고 전달할 시간을 작업 범위에 포함시키는 것입니다.
UNDERSTANDING LAYER
무엇을 측정할 것인가
AI 도입의 성과를 생성된 코드 줄 수나 완료 티켓 수로만 보면 이해 활동은 비용처럼 보입니다. 더 유용한 지표는 후속 변경을 시작하기까지의 탐색 시간, 새 팀원이 핵심 흐름을 설명하기까지 걸린 시간, 리뷰에서 발견된 잘못된 가정의 수, 장애 후 원인을 재구성하는 시간, 특정 개인 없이 변경 가능한 영역의 비율입니다.
회상 질문의 정답률 자체를 성과 평가에 쓰면 사람들은 시험에 맞춘 문서를 만들게 됩니다. 질문은 이해의 품질을 진단하기 위한 도구로만 사용해야 합니다. 마찬가지로 설명 문서의 길이도 좋은 지표가 아닙니다. 짧아도 실행 흐름과 제약을 정확히 보여주는 문서가 자동 생성된 장문보다 낫습니다.
한 달 단위로는 “이번 달 가장 큰 인지 부채는 어디에서 생겼는가”, “어떤 설명 형식이 후속 변경 시간을 줄였는가”, “어떤 작업은 사람의 깊은 이해 없이 자동화해도 안전했는가”를 회고할 수 있습니다. 이해를 무조건 많이 요구하는 것이 아니라 가장 가치 있는 곳에 배분하는 법을 학습하는 과정입니다.
SOURCES
참고 자료
- Geoffrey Litt, Understanding is the new bottleneck — 2026년 7월 발표 원문과 슬라이드
- GeekNews, 이해가 새로운 병목이다 — 한국어 요약과 토론
- Margaret-Anne Storey, Cognitive Debt — AI 시대 인지 부채의 정의와 팀 신호
- Geoffrey Litt, explain-diff — 배경·직관·코드·퀴즈로 변경을 가르치는 스킬
- Andy Matuschak & Michael Nielsen, Quantum Country — 회상 질문을 글에 결합한 기억 매체
FAQ
자주 묻는 질문
Q1. AI가 만든 코드를 전부 읽어야 하나요?+
아닙니다. 위험도와 변경 범위에 따라 이해 수준을 다르게 정해야 합니다. 핵심은 모든 줄을 똑같이 읽는 것이 아니라 배경, 목적, 실행 흐름, 제약을 먼저 파악한 뒤 필요한 원시 코드를 확인하는 것입니다.
Q2. 설명 문서도 AI가 쓰면 잘못될 수 있지 않나요?+
맞습니다. 설명은 진실의 원천이 아니라 코드와 실행을 탐색하기 위한 지도입니다. 테스트 결과, 실제 코드, 로그와 교차 확인하고 설명이 어떤 근거에서 나온 것인지 연결해야 합니다.
Q3. 퀴즈가 개발 속도를 늦추지 않나요?+
짧은 지연은 생기지만 잘못된 이해로 다음 변경을 쌓는 비용을 예방합니다. 모든 작업에 같은 퀴즈를 요구하지 말고 영향이 큰 변경에 3~5개의 회상 질문을 적용하는 방식이 현실적입니다.
Q4. 비개발 직군에도 적용할 수 있나요?+
가능합니다. 데이터 분석의 지표 정의, 마케팅 자동화의 의사결정 규칙, 디자인 시스템의 상태 변화처럼 결과 뒤의 구조를 이해해야 다음 판단을 할 수 있는 업무에 동일하게 적용됩니다.
Q5. 가장 작게 시작하는 방법은 무엇인가요?+
다음 AI 작업부터 코드와 함께 변경 전 배경, 핵심 흐름, 실패 지점, 회상 질문 3개를 요청해 보세요. 팀 리뷰에서 질문에 답하지 못한 부분만 보충하면 무거운 절차 없이도 인지 부채를 줄일 수 있습니다.
'AI' 카테고리의 다른 글
| Qwen 3.8 Max 프리뷰 공개, 정식판 이후 오픈웨이트 예고: Qwen 3.7과 달라질 점 (0) | 2026.07.20 |
|---|---|
| Kimi 3.0 출시? 공식명 Kimi K3 핵심 기능과 사용법 (1) | 2026.07.17 |
| 젠스파크(Genspark)란? 2026년 요금과 10,000 크레딧, 예전에 쓰고 지금은 안 쓰는 이유 (2) | 2026.07.16 |
| 조코딩 AX 인재전쟁 신청 후기 및 결과: 5,300명 중 메디테라피 본선 예비 후보가 되기까지 (0) | 2026.07.16 |
| NotebookLM으로 영상 만들기: 실제 품질 후기와 간단한 사용법 (1) | 2026.07.15 |
