AI 보조 개발의 인지 부채

"Agent가 생성한 결과를 검증할 수 있다면, 왜 사람이 여전히 code를 이해해야 하는가?" 이 페이지는 그 질문에 답한다. AI 보조 개발의 인지 부채(cognitive debt)는 agent가 만든 code와 인간이 유지하는 시스템 이해 사이의 격차가 누적되어, 사람이 다음 변경을 설계·검토·협업하기 어려워지는 상태다. 상위 맥락은 AI Agent Interaction Design의 human steering이며, 이 페이지는 agent의 정답률이 아니라 사람이 작업 loop에 계속 참여할 수 있는 이해의 조건을 다룬다.

검증과 참여는 다른 이해다

Geoffrey Litt의 발표는 agent가 작성한 code를 이해하는 이유를 검증(verify)과 참여(participate)로 구분한다.^[1] 전자는 결과에 승인/반려를 내리는 질문이고, 후자는 다음 agent loop를 창의적으로 이끌 수 있게 하는 질문이다. 출처는 다음 아이디어를 내고 반복되는 agent loop를 이끌려면 사람에게 쓸 만한 mental model이 필요하다고 말한다.^[1:1] 이 page는 이를, agent의 결과가 동작하고 자동 검증을 통과해도 사람이 구조·가정·변경 영향의 모델을 만들지 않으면 다음 loop의 목표 설정과 위험 판단이 약해진다는 뜻으로 해석한다. 따라서 이해는 단순한 승인 gate가 아니라 다음 아이디어를 내고 system을 진화시키기 위한 참여 능력이라고 볼 수 있다.

flowchart LR
    A[Agent가 code와 검증 결과 생성] --> B{사람이 시스템 모델을 갱신하는가?}
    B -->|예| C[다음 목표·변경 영향·위험을 논의]
    C --> D[능동적 참여]
    B -->|아니오| E[Code는 증가하지만 이해는 뒤처짐]
    E --> F[인지 부채]
    F --> G[다음 변경의 설계·리뷰·협업 약화]

• 발표는 agent가 자기 검증을 더 잘하는 흐름을 긍정하면서도, 그것이 인간의 맥락 이해를 불필요하게 만들지는 않는다고 주장한다.^[1:2]
• 발표는 사람이 잃은 맥락을 인지 부채와 연결한다. 이해를 나중으로 미루는 일은 단기적으로는 싸 보이지만, 나중에 team이 system을 이끄는 능력을 제한한다.^[1:3]
• 이해를 돕는 수단으로 explainer document, quiz, micro-world, shared space를 제시한다.^[1:4]

Evaluation loop가 통과해도 인지 부채는 남을 수 있다

• Agent Evaluation Loop는 agent 결과의 품질·회귀를 확인하는 feedback loop다. 그러나 evaluation이 통과해도 사람이 다음 요구사항을 안전하게 바꾸거나 이상한 설계를 발견할 수 있다는 보장은 아니다.
• Agent Harness는 context, observability, verification을 제공한다. 이를 인지 부채 관점에서 보면, harness는 agent 실행 도구만이 아니라 사람이 변화와 상태를 학습할 수 있게 하는 설명·관찰 surface도 제공해야 한다는 해석이 가능하다.
• 따라서 "자동 검증을 강화할수록 이해는 덜 필요하다"가 아니라, 자동 검증은 correctness 확인을 돕고 이해 지원은 human steering을 돕는 보완 관계로 두는 것이 안전해 보인다.

Code correctness와는 다른 축이다

인지 부채는 agent가 만든 code가 항상 잘못되었다는 뜻이 아니다. 이 source의 초점은 correctness 자체보다 인간의 참여 역량이다. 이는 기술 부채의 동의어도 아니다 — 기술 부채는 codebase의 설계·유지 비용을, 인지 부채는 사람이 보유한 이해의 격차를 중심으로 본다. 이 source는 explainer·quiz·micro-world 세 기법의 생산성·보안 효과를 정량적으로 검증하지 않는다.^[2] 효과 크기와 team 규모별 적용은 추가 source가 필요하다.

이해를 돕는 세 가지 장치

• Explanations와 quiz: 출처는 세부보다 맥락을 먼저 주는 explainer 문서와 quiz 같은 회상 확인(recall check)을 제시한다.^[1:5] raw diff를 파일 순서대로 요약하는 대신 기존 system·목표·핵심 개념을 먼저 설명하고 변경을 이해 가능한 순서로 제시한다는 대비, quiz가 읽었다는 느낌과 실제 회상을 구분하는 속도 조절 장치라는 설명은 이 page의 해석이다.
• Micro-worlds: 출처는 이해를 돕는 수단으로 interactive micro-world를 제시한다.^[1:6] 이를 임시 simulator, debugger, state viewer처럼 한 동작을 조작하고 결과를 보는 작은 실행 환경으로 보고, 영구 code를 이해하도록 돕기 위해 agent가 임시 code를 만들 수 있다는 발상으로 읽는 것은 이 page의 해석이다.
• Shared spaces: 출처는 collective understanding을 위한 shared space를 제시한다.^[1:7] 개인별 agent 대화에서 생긴 사적 이해를 계획, 용어, 설명, 질문이 보이는 공동 artefact로 옮겨 team이 같은 mental model을 만들게 한다는 설명은 이 page의 해석이다.

이 세 장치는 준비·유지 비용을 요구하므로 모든 사소한 change에 같은 수준의 학습 artefact를 만들 필요는 없다. state, time, concurrency, protocol, failure path처럼 정적 diff만으로 예측하기 어려운 부분은 micro-world의 가치가 크다. shared space는 문서를 더 만드는 일이 아니라, 다음 의사결정에 실제로 참조·수정되는 공유 모델을 만드는 일이어야 한다.

각 장치가 형식만 남는 경우

• agent가 만든 요약만 읽고 실제 system model을 만들지 못하면, 그 요약은 이해의 증거가 아니라 또 하나의 불투명한 layer가 될 수 있다.
• quiz가 암기 확인에만 머물고 변경 영향·실패 경로를 묻지 않으면 참여 능력을 평가하지 못한다.
• micro-world가 핵심 상태 전이나 failure를 드러내지 않는 장식용 demo가 되면 유지 비용만 남는다.
• team member가 각자 다른 private agent context에서만 일하면, 개인 이해가 있어도 공통 용어와 결정 이유가 분산될 수 있다.

Payment retry 정책을 예로 들면

• payment retry 정책을 agent가 변경했다면, explainer는 기존 retry 흐름과 새 stop condition을 먼저 설명하고, quiz는 "어떤 error에서 retry가 중단되는가?"를 묻는다.
• micro-world는 request별 retry timeline, backoff, cancellation, duplicate write 가능성을 조작해 보여줄 수 있다.
• shared space에는 retry 용어, acceptance criteria, open question, trace link를 두어 developer·reviewer·agent가 같은 변경 모델을 논의한다.

관련

• Agent Harness — context와 observability가 agent뿐 아니라 사람의 system 이해를 지원하는 실행 환경이 될 수 있다.
• Agent Evaluation Loop — output evaluation과 human participation은 서로 대체하지 않는 두 feedback loop다.
• AI Agent Interaction Design — human steering이 goal을 갱신하려면 system에 대한 충분한 이해가 필요하다.

출처

테스트 질문

• Agent의 자동 검증이 좋아지는데도 사람이 code를 이해해야 하는 이유는 무엇인가?
• Explain-diff와 일반적인 PR 요약은 어떤 학습 목적에서 다른가?
• Evaluation loop가 통과했는데도 인지 부채가 남을 수 있는 이유는 무엇인가?