에이전틱 코딩의 진짜 함정: 인지 부채 (youtube.com) ↗

• Lars Fay의 에세이 “Agentic Coding is a Trap”을 Theo가 53분짜리 영상으로 한 줄씩 리뷰한 콘텐츠. 원문은 기술 부채가 아니라 인지 부채(cognitive debt, 코드와 의도를 연결하는 머릿속 모델이 흐려지는 것)에 초점
• 핵심 주장은 “사람은 오케스트레이터, AI가 코딩한다”는 흐름이 단기 생산성 대신 장기 역량을 깎아먹는다는 것. Simon Willison(Django 만든 사람), Martin Fowler 같은 30년차 개발자조차 “내가 만든 앱을 내가 잘 모르겠다”고 말하는 중
• Theo가 가장 좋아한 비유: AI 코딩은 슬롯머신. 도큐먼트 읽고 라이브러리 배우는 “느린 고통”보다 한 번 더 돌려보는 게 덜 아프기 때문에, 사람들이 학습을 포기하고 레버만 당기게 됨
• Anthropic 자사 연구 인용: “Claude를 잘 쓰려면 감독이 필요한데, 감독에 필요한 코딩 실력 자체가 Claude를 많이 쓸수록 위축된다”는 모순
• Theo는 풀스택 개발 유튜버이자 t3.gg·T3 Stack 만든 사람. Lars Fay는 잘 알려진 백엔드 엔지니어로 원문 에세이는 “indispensable value in AI era” 등 시리즈의 연장선

인지 부채가 기술 부채와 다른 점은?

• 기술 부채는 코드 안에 쌓이는 빚. AI가 오히려 잘 해결함. Theo는 Twitch에서 TypeScript 8,000개 파일을 구글 시트로 나눠 손으로 마이그레이션한 사례 회상. 지금은 AI가 한 번에 처리
• 인지 부채는 사람 머릿속에 쌓이는 빚. “이 결정이 왜 이렇게 됐고, 의도가 어떻게 코드로 옮겨졌나”의 연결이 흐려지는 것
• 빠르게 움직일 수는 있지만, 6개월 뒤 본인이 만든 시스템을 처음 보는 것처럼 다시 읽어야 함. 자신감이 떨어지고 디버깅이 어려워짐
• 결정적 차이: 기술 부채는 시간을 들여 갚을 수 있지만, 인지 부채는 한 번 잃은 직관을 되찾으려면 처음부터 다시 만들어야 함
• 신입만의 문제가 아님. 영상에서 인용한 Reddit 글 중에 9년차 개발자(31살, 1살 아기 아빠)가 “회사가 모든 개발 작업을 AI로만 하게 강제해서 매일 실력 잃는 느낌이다. 이직하려면 결국 기술 실력으로 평가받는데 머리가 굳는 중”이라고 호소함. 인지 부채는 경력 무관하게 빠짐

왜 AI가 학습 자체를 막는가?

• 사람은 모르는 걸 만질 때 고통을 느낌. 안 풀리는 버그, 안 맞는 문서, 안 따라오는 머리. 이 고통을 견디며 “조각”을 배워야 다음 문제를 풀 수 있음
• AI가 이 고통의 비용을 거의 0으로 만듦. 한 번 더 돌리는 게 책 한 챕터 읽는 것보다 훨씬 덜 아픔
• Theo의 스케이트보드 비유: 대부분의 사람이 ollie 못 배우고 그만두는 이유는 정강이 까지는 게 너무 아파서임. 코딩도 같은 구조였는데, 이제 그 진입 장벽이 사라짐
• 결과: 기본기 없는 사람은 AI에 더 깊이 의존하고, 시스템이 깨질 때 “왜 깨졌는지” 추론할 도구가 없음. 슬롯머신만 계속 당김

어떤 사람이 AI 코딩에서 살아남나?

• 이미 깊이 이해하고 있는 사람. Theo는 4년간 안 만진 자기 코드베이스(Ping)에서 outage가 났을 때, 첫 에러 메시지 보고 거의 직감으로 원인을 맞춤. AI는 보조 도구로만 쓰고 본인은 시스템을 읽는 중이었음
• 일부러 모르는 영역에 들어가서 “바보가 되는 감각”을 다시 찾는 사람. Theo는 Rust로 새 프로젝트, 암호학 챌린지 같은 걸 일부러 들어감
• 오픈소스 메인테이너. 다양한 수준의 기여자가 보내는 코드를 매일 리뷰하면서 자기 위·아래 레이어를 동시에 배우게 됨
• Lars의 워크플로우 요약: AI로 계획·조사·즉석 코드 생성·문서 탐색은 하되, 구현은 본인이 따라가며 진행. 한 번에 리뷰 못 할 양은 절대 생성하지 않음

스펙부터 쓰지 마라: 작게 만들고 배워라

• Theo가 Twitch에서 정착시킨 방식, 회사 안에서 “Theo method”로 굳어진 패턴
• 2주 동안 거대한 스펙 문서를 쓰고 그걸로 구현 들어가면 막상 만들 때 스펙이 다 틀려 있음. 왜? 만들기 전엔 어떤 부분이 어려운지 모르기 때문
• 대안: 2~3일 만에 가장 작은 동작 버전(minimum viable shape)을 만들어봄. 만들면서 진짜 어려운 부분, 진짜 필요한 부분이 보임. 그때서야 좋은 스펙이 나옴
• Lars와 Dax(Open Code)도 같은 얘기. “코드를 짜는 행위 자체가 계획을 세우는 과정”임. 타입 적어보고 폴더 구조 만져보면서 무엇을 만들어야 하는지 알게 되는 것
• 중요한 구분: AI Plan mode(에이전트가 plan 써주는 기능)는 이거랑 다름. 본인이 코드에 들어가서 직접 만져봐야 학습이 됨. AI가 써준 plan은 만져보지 않은 사람이 쓴 spec과 동급
• 한 가지 보너스: 작은 버전을 빨리 버리고 다시 짜는 비용이 AI 덕분에 거의 0이 됨. “잘못 골랐을 때 갈아엎는 두려움” 자체가 사라져서 실험을 더 많이 할 수 있게 됨

모든 코드를 같은 무게로 다루지 말 것

• Theo가 Lars 글에서 한 발 더 나간 부분: 코드를 두 종류로 나누는 게 핵심
• 하루에 수천 번 실행되며 사용자한테 닿는 코드. 여기는 품질이 더 좋아야 하고 AI를 보조로 쓰되 본인이 깊이 이해해야 함
• 1회성 코드(데이터 분석, 일회용 계산기, 마이그레이션 스크립트, NAS 파일 정리). 여기는 10배 더 만들고 버려도 됨. 예전엔 손으로 직접 하던 일을 이제 코드로 해결 가능
• 1인기업 운영자가 흔히 헷갈리는 지점. 본인이 만지는 코드가 어느 쪽인지 분류 안 하면 둘 다 어설프게 됨

구분	1회성 코드	매일 돌아가는 코드
예시	데이터 정리 스크립트, 일회용 계산	결제 로직, 사용자 인증, API 핸들러
AI 활용	거의 다 맡겨도 됨	보조로만, 본인이 라인 단위 이해
품질 기준	작동하면 됨	6개월 뒤에도 본인이 읽을 수 있어야 함
학습 비중	낮음	높음

Claude Code가 다운되면 일이 멈추는 게 vendor lock-in인가?

Theo는 그것보다 “도구 선택의 문제”로 봄. T3 Code 같은 오픈소스 클라이언트로 Claude·Codex·Cursor·GPT-5를 같은 인터페이스에서 전환할 수 있고, 한 모델이 다운돼도 다른 걸로 넘어가면 됨. 진짜 lock-in은 “본인이 코드를 못 짜는 상태”이고, 그건 vendor 문제가 아니라 실력 문제.

AI 디버깅은 권장되나, 금지되나?

권장됨. Theo의 입장은 명확. 버그가 사용자한테 영향을 주고 있다면 해결 확률을 높이는 모든 수단을 써야 함. 다만 시스템을 모르는 상태에서 AI에만 매달리는 건 다른 얘기. 시스템을 알면 AI가 디버깅을 가속시키고, 모르면 AI가 엉뚱한 곳을 파게 만듦.

그럼 주니어 개발자는 AI를 쓰지 말아야 하나?

Lars의 우려는 “다음 시니어가 안 나올 것”임. 30년 마찰을 거쳐 만들어지던 시니어가, 그 마찰을 건너뛴 채 오케스트레이터 역할로 점프하면 시니어의 판단력이 안 생김. Theo는 약간 다르게 봄. 호기심 많은 소수는 AI로 더 빠르게 깊이 들어가고 있고, 그게 안 되는 다수는 더 빨리 도태됨. 둘 다 가속되는 중.

1인기업 관점

결국 인지 부채를 줄이려면 도구 선택보다 시스템 설계가 먼저인 듯. 불변성(immutability, 한 번 만든 데이터를 안 바꾸는 원칙)과 단일 책임(SRP, 하나의 모듈은 하나의 이유로만 바뀌게)을 지켜서 레이어를 잘 나눠두면 수정 빈도 자체가 줄고, 6개월 뒤에 봐도 어디서 뭐가 깨졌는지 추적이 됨. 반대로 한 함수가 너무 많은 일을 하고 상태가 곳곳에서 변하는 코드는 AI한테 맡기든 본인이 짜든 머리에 안 들어옴. 실제로 usedesktop 만들 때 이거 안 지키고 speckit으로 spec-driven만 돌렸다가, 나중에 전체를 다시 리팩토링하느라 시간을 더 썼음. Theo가 말한 “earned the right to ship fast”의 진짜 의미도 결국 이 설계 감각을 갖춘 사람이 빠르게 갈 자격이 있다는 얘기 아닌가 싶음.

---

관련: 같은 Theo 영상 시리즈의 Claude·Copilot 가격 인상이 GPU 부족 신호라는 분석과, 도구가 아니라 기본기·판단력이 먼저라는 관점도 같이 보면 좋습니다.