인지적 부채: AI가 만든 코드의 숨은 비용

출처: Dev.to

In early 2026, Anthropic researchers ran an experiment with 52 junior developers. Half used an AI assistant to learn an unfamiliar Python library. The other half worked without one. Both groups finished the task. But when tested on how well they understood the code they had just written, the AI- assisted group scored 50% on a comprehension quiz - versus 67% for the unassisted group.

2026년 초, Anthropic 연구팀은 52명의 주니어 개발자를 대상으로 실험을 진행했습니다. 절반은 unfamiliar한 Python 라이브러리를 배우기 위해 AI 보조 도구를 사용했고, 다른 절반은 그 없이 작업했습니다. 두 그룹 모두 과제를 완료했습니다. 하지만 작성한 코드에 대한 이해도를 시험했을 때, AI 보조 그룹은 퀴즈에서 50% 점수를 받았으며, 비보조 그룹은 67%를 받았습니다.

That 17- percentage-point gap has a name: cognitive debt. It is one of the most important concepts in software engineering right now, and most developers are not paying enough attention to it.

이 17포인트 격차에는 ‘인지 부채’(cognitive debt)라는 이름이 붙습니다. 이는 현재 소프트웨어 공학에서 가장 중요한 개념 중 하나이며, 대부분의 개발자는 이를 충분히 주목하고 있지 않습니다.

Cognitive debt describes the growing gap between the volume of code that exists in a system and the amount that any developer genuinely understands. It is not a new term, but it crystallized across multiple research streams in early 2026.

인지 부채는 시스템 내 존재하는 코드 양과 개발자가 진정으로 이해할 수 있는 양 사이의 증가하는 간격을 설명합니다. 이 용어는 새롭지 않지만, 2026년 초 여러 연구 흐름에서 구체화되었습니다.

Addy Osmani (Google Chrome) described it as “comprehension debt” - the hidden cost that accumulates when code becomes cheap to generate but understanding still requires deliberate effort. Margaret- Anne Storey (University of Victoria) formalized the concept in a March 2026 arXiv paper, framing it as a team-level problem and extending it into a Triple Debt Model: technical debt in the code, cognitive debt in the people, and intent debt - the missing rationale that both humans and AI agents need to safely work with code.

Addy Osmani(Google Chrome)은 이를 “이해 부채”(comprehension debt)라고 설명했는데, 이는 코드가 생성되는 것이 쉬워졌지만 이해는 여전히 의도적인 노력이 필요하다는 숨겨진 비용이 쌓이는 현상을 말합니다. Margaret- Anne Storey(University of Victoria)는 2026년 3월 arXiv 논문에서 이 개념을 팀 수준의 문제로 정립하고, Triple Debt Model을 제시했습니다. 이는 코드 내 기술 부채, 사람들의 인지 부채, 그리고 인간과 AI 에이전트가 안전하게 코드를 다룰 수 있는 missing rationale인 의도 부채를 포함합니다.

These two ideas are easy to conflate, but they are fundamentally different problems.

이 두 개념은 쉽게 혼동될 수 있지만, 근본적으로는 다른 문제입니다.

Technical debt lives in the code - it shows up as slow builds, tangled dependencies, and failing tests. Cognitive debt lives in people - it surfaces as an inability to explain, debug, or extend code that the team themselves wrote.

기술 부채는 코드에 존재합니다 - 이는 느린 빌드, 복잡한 의존성, 실패하는 테스트로 나타납니다. 인지 부채는 사람들에 존재하며, 팀이 스스로 작성한 코드를 설명하거나 디버깅하거나 확장할 수 없는 현상으로 나타납니다.

The critical difference: technical debt announces itself through friction. Cognitive debt breeds false confidence. Your tests are green, velocity looks fine, and nobody realizes the system is fragile until something breaks in production and the team cannot reason through why.

핵심 차이점은 다음과 같습니다: 기술 부채는 마찰을 통해 스스로 알립니다. 인지 부채는 잘못된 자신감( false confidence)을 낳습니다. 테스트가 정상이고 속도가 괜찮아 보이지만, 팀이 생산 환경에서 무언가가 깨질 때까지 시스템의 취약성을 깨닫지 못합니다.

The Anthropic study found more than just a comprehension gap. Developers who delegated fully to AI - asking it to write code - scored below 40% on comprehension. Developers who used AI as a learning tool - asking it to explain concepts - scored above 65%, matching or beating the no-AI group. The tool is not the problem. The usage pattern is.

Anthropic 연구는 단순히 이해 격차 이상의 결과를 찾아냈습니다. AI에게 전체적으로 위임해 코드를 쓰게 한 개발자들은 comprehension에서 40% 미만 점수를 받았으며, AI를 학습 도구로 사용해 개념을 설명하도록 요청한 개발자들은 65% 이상 점수를 받았고, 비AI 그룹과 동등하거나 더 높은 성적을 거두었습니다. 도구가 문제입니다. 사용 패턴이 문제입니다.

A METR study added another dimension: experienced developers working on their own large codebases took 19% longer to complete tasks when using AI-assisted tools versus working without them. Before the study, those same developers expected AI would speed them up by 24%. After the study, they still believed it had sped them up by 20%. The confidence that AI tools produce appears to be partially disconnected from actual performance.

METR 연구는 추가 차원을 제시했습니다: 자체 대규모 코드베이스에서 작업하는 경험 많은 개발자들이 AI 보조 도구를 사용했을 때 비보조 작업에 비해 19% 더 오랜 시간을 소요했습니다. 이 연구 이전에는 해당 개발자들은 AI가 24% 빠르게 할 것이라고 기대했지만, 연구 후에도 여전히 20% 빠른 것으로 믿고 있었습니다. AI 도구가 실제 성능과 연관된 신뢰도는 부분적으로 분리되어 있는 것처럼 보입니다.

A June 2025 MIT Media Lab study used EEG brain scans to compare LLM- assisted writing versus search-assisted writing versus unassisted writing. Brain connectivity - the measure of how actively and broadly neural networks are engaged - scaled down as tool support increased. LLM-assisted work produced the output but not the neural engagement behind it.

2025년 6월 MIT Media Lab 연구는 EEG 뇌파 스캔을 활용해 LLM 보조 작성, 검색 보조 작성, 비보조 작성을 비교했습니다. 뇌 연결성(신경망이 얼마나 활발하고 넓게 참여하는지를 측정)은 도구 지원 수준이 증가함에 따라 감소했습니다. LLM 보조 작업은 출력을 만들었지만 그 뒤에 있는 신경 활동은 전달하지 못했습니다.

Finally, a February 2026 study by Sankaranarayanan introduced an “Explanation Gate” - requiring developers to explain AI-generated code before integrating it. The unrestricted AI group had a 77% failure rate on a maintenance task after a 30-minute AI blackout. The Explanation Gate group had a 39% failure rate. One simple intervention cut the failure rate nearly in half.

마지막으로, 2026년 2월 Sankaranarayanan의 연구는 개발자가 AI 생성 코드를 통합하기 전에 설명하도록 하는 “설명 게이트”(Explanation Gate)를 도입했습니다. 제한되지 않은 AI 그룹은 30분 AI 블랙아웃 후 유지보수 작업에서 77%의 실패율을 보였으며, 설명 게이트 그룹은 39%의 실패율을 보였습니다. 이 간단한 개입으로 실패율이 거의 절반으로 감소했습니다.

There are three core mechanisms.

세 가지 핵심 메커니즘이 있습니다.

AI는 생산적 고 struggle을 없애준다. 학습 과학에 따르면, 공부 중의 어려움(재현 연습, 혼란 극복)은 장기 기억을 촉진합니다. 오류 메시지를 채팅 창에 붙여넣고 해결책을 받는 순간, 버그는 해결되지만 학습 기회는 사라집니다.

AI는 30초 안에 200줄의 작동 코드를 생성할 수 있지만, 그 200줄과 시스템 내 다른 요소와의 상호작용을 이해하는 진정한 정신 모델을 구축하려면 상당히 더 오랜 시간이 걸립니다. 대부분의 개발자는 이 단계를 생략합니다.

자동화 무관심증(automation complacency)은 항공 및 원자력 분야에서 잘 문서화된 실패 모드로, 지속적인 자동화 사용이 오작동에 대한 감지 능력을 약화시킵니다. 2026년 연구에 따르면 개발자는 AI의 잘못된 추론을 73.2%의 경우 받아들입니다.

Here are signals worth watching for:

• You cannot explain a design decision in code review without saying “the AI suggested it.”

• Your productivity drops sharply when AI tools are unavailable due to rate limits or outages.

• There are files in your own codebase you mentally route around because you do not fully follow them.

• You paste error messages into chat without first forming a hypothesis about the cause.

• You can build new features easily but struggle to debug code that is six months old.

• You accept AI solutions without being able to articulate why they work.

• 코드 리뷰에서 설계 결정을 설명하려 하면 ‘AI가 제안했다’고 말할 수밖에 없습니다.

• AI 도구가 제한이나 중단으로 이용 불가능할 때 생산성이 급격히 하락합니다.

• 코드베이스 내 파일이 자신만 몰래 회피하게 되어, 완전히 이해하지 못하고 있습니다.

• 원인 가설을 먼저 형성하지 않고 오류 메시지를 바로 챗에 붙여넣습니다.

• 새로운 기능을 쉽게 만들지만, 6개월 전 코드를 디버깅하는 데 어려움을 겪습니다.

• AI 솔루션을 받아들이면서 그것이 어떻게 작동하는지 설명할 수 없습니다.

The individual-level concern is real, but the structural concern may be larger.

개인 수준의 우려는 실존하지만, 구조적 우려가 더 클 수 있습니다.

Every abstraction layer in history - assembly to C, C to Python, Python to frameworks - was accused of de- skilling developers. Each one expanded the developer population and enabled new categories of software. AI may follow the same pattern.

역사적 각 추상화 계층(어셈블리 → C, C → Python, Python → 프레임워크)은 개발자를 데스킬링(de- skilling)시킨다고 비난받아 왔습니다. 각각은 개발자 인구를 확대하고 새로운 소프트웨어 카테고리를 가능하게 했습니다. AI도 동일한 패턴을 따를 수 있습니다.

The Anthropic study also contains its own counter-argument: developers who used AI for learning scored as well as the no-AI group. The problem is passive delegation, not AI tools themselves. Used as a Socratic tutor, AI may actually accelerate skill development. And Stack Overflow’ s 2026 data shows 64% of developers now use AI specifically to learn - up from 37% in 2024.

Anthropic 연구는 자체 반론을 제시합니다: AI를 학습용으로 사용한 개발자들은 비AI 그룹과 동등한 점수를 받았습니다. 문제점은 수동적 위임에 있는 것이지, AI 도구 자체가 아닙니다. Socratic 튜터로 활용될 경우 AI는 실제로 기술 향상을 가속화할 수 있습니다. Stack Overflow의 2026년 데이터에 따르면 개발자의 64%가 AI를 학습 목적으로 사용하고 있으며, 이는 2024년의 37%보다 상승한 수치입니다.

The research literature and practitioner experience converge on a few high- leverage interventions.

연구 문헌과 실무 경험은 몇 가지 고부가가치 개입에 대해 공통된 인식을 형성하고 있습니다.

• Apply the Explanation Gate. Before integrating any AI-generated code, explain it - why it works this way, and what would break if a specific part changed. Sankaranarayanan’ s study showed this cuts maintenance failure rates dramatically with no measurable impact on initial productivity.

• Attempt problems before consulting AI. Spend 15 to 30 minutes working through a problem independently. The wrong hypotheses and partial approaches during that time are where schema formation happens. When you then consult AI, you arrive with a framework for evaluating its answer.

• Ask “why?” more than “write this.” Prompts like “explain the time complexity of this approach” or “what are the tradeoffs between these two implementations” build understanding. The code AI produces is the output. The understanding you build by interrogating it is the asset.

• Schedule no-AI days. Reserve one day per week for unassisted work. The goal is calibration - measuring your actual skill level and identifying the gaps that have opened since last time.

• Design before you generate. Use AI to reason through architecture and tradeoffs before writing any code. Then generate implementation to fill in a design you already understand, rather than receiving a design embedded in code you do not.

• Run this exercise quarterly. No special tooling required.

• Ask three engineers to independently whiteboard the architecture of a shared system. Where the diagrams diverge is where cognitive debt has accumulated.

• Pick a 50-line function that was AI-generated and committed more than two weeks ago. Ask the author to explain it without looking at it. Track whether they can recover the reasoning.

• Give an engineer a bug report for AI-generated code they have not touched before, with AI access removed, for 20 minutes. Observe whether they form and test hypotheses independently or stall immediately.

• 설명 게이트 적용: AI 생성 코드를 통합하기 전에 그 이유를 설명하세요 — 왜 이렇게 작동하는지, 특정 부분이 변경될 경우 어떤 결과가 발생할지 알려주세요. Sankaranarayanan 연구에서는 이 간단한 조치가 유지보수 실패율을 크게 낮추면서 초기 생산성에 아무런 영향을 주지 않았습니다.

• AI를 참고하기 전에 문제를 먼저 풀어 보세요. 15~30분 동안 독립적으로 작업하고, 그때 형성되는 잘못된 가설과 부분적인 접근이 스키마 형성에 기여합니다. 이후 AI에 문의하면 그 답변을 평가할 프레임워크를 갖추게 됩니다.

• “왜?”에 더 집중하세요. ‘이 접근 방식의 시간 복잡도를 설명해 주세요’ 또는 ‘두 구현 간의 트레이드오프는 무엇인가요’와 같은 질문은 이해를 증진시킵니다. AI가 만든 코드는 결과물일 뿐이며, 그 결과를 질문하면서 쌓은 이해가 가장 큰 자산입니다.

• 주간 AI 없는 날을 일정에 포함하세요. 한 주에 한 번 비보조 작업만 수행하도록 예약합니다. 목표는 교정 — 실제 기술 수준을 측정하고 이전 이후로 생긴 간격을 파악하는 것입니다.

• 생성하기 전에 설계하세요. 코드를 쓰기 전에 AI에게 아키텍처와 트레이드오프를 고려하도록 한 뒤, 이미 이해한 설계에 기반해 구현을 작성하세요. 이미 이해하지 못한 code에 내재된 설계대로 생성하는 대신입니다.

• 분기별로 이 연습을 실행하세요. 특별한 툴이 필요 없습니다.

• 공유 시스템 아키텍처를 세 명의 엔지니어가 독립적으로 화이트보드에 그립니다. 그림이 diverge(차이)하는 부분이 인지 부채가 축적된 위치입니다.

• 두 주 이상 전에 AI로 생성하고 커밋된 50줄짜리 함수를 골라보세요. 저자에게AI 없이 설명하도록 요청하고, 그 reasoning을 되찾을 수 있는지 추적하세요.

• AI 접근이 제거된 상태에서 이전에触碰하지 않은 AI 생성 코드에 대한 버그 보고서를 엔지니어에게 20분간 부여하세요. 그들이 독립적으로 가설을 형성하고 테스트하는지, 아니면 즉시 멈추는지 관찰하세요.

The individual-level concern is real, but the structural concern may be larger.

개인 수준의 우려는 실존하지만, 구조적 우려가 더 클 수 있습니다.