인지부채 - 바이브 코딩 시대의 새로운 부채 관리법

“첫 출시 코드를 내보내는 것은 빚을 지는 것과 같다. 약간의 빚은 개발을 가속한다. 제때 갚기만 한다면.” — Ward Cunningham, OOPSLA ‘92¹

바이브 코딩으로 일하다 보면 이상한 순간이 온다. 분명히 내 프로젝트인데, 코드를 열어보면 남의 집 같다. 에이전트가 설계하고, 에이전트가 구현하고, 나는 승인 버튼을 눌렀다. 일은 빨리 끝났다. 그런데 장애가 나면 이렇게 말하게 된다. “이 문제가 왜 생긴 거죠? AI가 만든 거라 잘 모르겠어요.”

이것이 인지부채(cognitive debt)다. 코드는 쌓이는데 이해는 쌓이지 않는다. 그 격차가 빚이다.

용어가 과장이 아니다. 2025년 MIT Media Lab 연구팀은 에세이를 쓰는 사람들의 뇌를 EEG로 측정했다. LLM을 쓴 그룹은 뇌 연결성이 가장 약했고, 자기가 쓴 글을 제대로 인용하지 못했으며, 자기 글이라는 소유감도 가장 낮았다. 이 패턴은 AI 사용을 중단한 뒤에도 이어졌다. 연구팀은 이 현상에 “인지부채"라는 이름을 붙였다.² 코드 쪽 데이터도 방향이 같다. GitClear가 2억 라인 이상의 커밋을 분석해 보니, AI 어시스턴트가 퍼진 기간 동안 복사-붙여넣기 코드는 늘고 리팩터링은 절반 이하로 줄었다.³ 산출물은 빨라졌다. 이해와 정리는 뒤로 밀렸다.

사람을 끼워 넣으면 해결되는가

이 문제 앞에서 흔히 나오는 처방이 human-in-the-loop이다. 모든 산출물을 사람이 검토하게 하자는 것이다. 듣기에는 그럴듯하다. 현실에서는 작동하지 않는다.

이유는 단순하다. 에이전트는 사람보다 훨씬 빨리 만든다. 사람이 매번 관여하면 사람이 병목이 된다. 병목이 된 사람은 시간에 쫓긴다. 쫓기다 보면 내용은 안 보고 승인 버튼만 누르게 된다. 검토는 형식이 되고, 형식이 된 검토는 착각을 만든다. “사람이 봤으니 괜찮다"는 착각이다. 아무도 안 본 것보다 나쁠 수 있다.

이것은 새로운 발견이 아니다. 자동화 연구는 40년 전에 이미 결론을 냈다. Bainbridge는 1983년 논문에서 자동화의 아이러니를 지적했다. 자동화될수록 사람은 기술을 연습할 기회를 잃는다. 남는 일은 지루한 감시다. 그런데 정작 사람이 개입해야 하는 순간은 가장 어려운 순간이다.⁴ 후속 연구들은 자동화 안주(automation complacency)가 초심자만의 문제가 아니라는 것도 확인했다. 전문가도 똑같이 안주하고, 훈련이나 지시로는 잘 고쳐지지 않는다.⁵

체감도 믿을 것이 못 된다. METR이 2025년에 숙련 오픈소스 개발자들을 대상으로 무작위 대조 실험을 했다. AI 도구를 쓴 개발자들은 실제로는 19% 느려졌는데, 본인들은 20% 빨라졌다고 느꼈다.⁶ 내가 이해하고 있다는 느낌과 실제 이해 사이의 격차. 인지부채는 정확히 그 격차에서 자란다.

부채는 없애는 것이 아니라 관리하는 것이다

그러면 어떻게 해야 하는가. 나는 인지부채를 기술부채(technical debt)와 같은 방식으로 다루자고 주장하고 싶다.

기술부채라는 말을 처음 만든 Ward Cunningham은 부채를 악으로 규정하지 않았다. 오히려 반대다. 약간의 빚은 개발을 가속한다. 문제는 빚 자체가 아니라 갚지 않고 방치할 때 붙는 이자다.¹ 인지부채도 마찬가지다. AI가 생성한 모든 코드를 사람이 완전히 이해하고 설명할 수 있어야 한다는 요구는 비현실적이다. 그 요구를 진지하게 받아들이는 순간 AI를 쓰는 의미가 사라진다. 부채를 0으로 만들려는 시도는 실패한다. 목표는 0이 아니라 적정 수준이다.

적정 수준이란 무엇인가. 언제든 요구받으면 일정 깊이까지는 설명할 수 있는 상태다. 모든 함수를 외우고 있을 필요는 없다. 그러나 시스템이 왜 이렇게 생겼는지, 어디가 위험한지, 무엇이 관찰되면 설계가 실패한 것인지는 말할 수 있어야 한다. 그 선 아래로 이해가 내려가면 빚을 갚아야 한다.

문제는 방법이다. 나는 세 가지를 쓰거나 제안한다.

첫째, 쪽지시험

설계나 구현이 끝났는데 내가 지금 뭘 만든 건지 잘 모르겠다는 느낌이 들 때가 있다. 그 순간이 빚을 갚을 순간이다. 나는 이럴 때 에이전트에게 쪽지시험을 요구한다. 아이디어 수준의 이야기가 아니다. 실제로 스킬로 만들어 쓰고 있다.

핵심 원칙은 하나다. 답은 항상 내 입에서 나와야 한다. 에이전트가 설명해 주면 편하다. 그리고 소용없다. 설명을 들으면 이해했다고 착각하기 때문이다. 착각한 채로 부채는 그대로 남는다. 그래서 이 시험은 채점이 아니라 인터뷰다. 에이전트는 개방형 질문을 하나 던진다. “왜 대안 X가 아니라 이 방식인가?” “이 부분이 없으면 무엇이 잘못되는가?” 내 답을 듣고, 갭이 드러난 지점을 골라 꼬리 질문을 던진다. 다음 질문은 미리 정해져 있지 않다. 내 직전 답이 결정한다. 같은 갭이 두 번의 후속 질문에도 안 풀리면 그때야 해설이 나온다.

빠뜨린 것을 즉시 알려주지도 않는다. “단계가 더 있는데, 뭐가 빠졌을까?“라고 회상을 요구한다. 불편하다. 불편한 것이 정상이다. 빚을 갚는 일이 편했던 적은 없다.

둘째, 리터릿 코드 디프

Knuth는 1984년에 리터릿 프로그래밍(literate programming)을 제안하며 이렇게 말했다. 프로그램 작성의 주 임무를 컴퓨터에게 지시하는 것이 아니라, 컴퓨터가 무엇을 하길 원하는지 인간에게 설명하는 것으로 바꾸자.⁷ 이 관점을 디프(diff)에 적용한 것이 리터릿 코드 디프다.

일반적인 코드 리뷰 화면은 변경된 파일의 나열이다. 파일 순서는 알파벳순이고, 변경의 논리적 순서와 무관하다. 리뷰어는 조각난 변경들을 머릿속에서 재조립해야 한다. 에이전트가 만든 큰 변경 앞에서 이 재조립은 자주 포기된다. 그리고 승인 버튼이 눌린다.

리터릿 코드 디프는 순서를 뒤집는다. 변경을 개념의 순서대로 배열하고, 각 단계에 설명을 붙인다. “먼저 저장소 인터페이스를 바꿨다. 왜냐하면. 그 다음 호출부를 고쳤다. 왜냐하면.” 읽는 사람은 변경을 하나의 이야기로 따라간다. 나는 이 문서를 릴리즈 노트처럼 유지보수하는 것도 좋다고 본다. PR마다 리터릿 디프 문서를 하나씩 만들고, README에 인덱스를 두어 접근성을 유지하는 식이다. 코드베이스의 역사가 “누가 언제 무엇을 바꿨다"가 아니라 “왜 이렇게 되었다"로 남는다.

셋째, 서술형 문서

AI가 뽑아내는 문서는 대부분 열거식이다. 불릿 포인트가 정렬된 문서는 한눈에 들어온다. 그것이 장점이자 함정이다. 한눈에 들어오기 때문에 읽었다고 착각하기 쉽고, 논리가 빠진 자리도 눈에 띄지 않는다. 그리고 빨리 잊힌다.

아마존은 이것을 회사 차원에서 실험했다. 베조스는 2004년 임원 회의에서 파워포인트를 금지하고 서술형 메모를 도입했다. 이유가 정확하다. 좋은 서술형 메모가 어려운 것은, 서술 구조가 무엇이 더 중요하고 어떻게 연결되는지에 대한 더 나은 사고를 강제하기 때문이다.⁸ 읽는 쪽도 마찬가지다. 서술형은 열거식보다 읽는 데 시간이 걸린다. 대신 이야기로 읽기 때문에 논리가 끊긴 자리가 드러나고, 읽은 내용이 오래 남는다.

ADR(Architecture Decision Record)로 비교해 보자. 열거식 ADR은 이렇게 생겼다.

## 결정: 세션 저장소를 Redis로 이전
- 현황: DB 세션 테이블 병목
- 대안: Memcached, DynamoDB, Redis
- 선택: Redis
- 근거: TTL 지원, 운영 경험 보유

깔끔하다. 그리고 아무것도 검증할 수 없다. 병목이 얼마나 심했는지, Memcached는 왜 탈락했는지, “운영 경험 보유"가 결정을 정당화할 만큼 중요한 조건이었는지 이 문서는 말하지 않는다. 같은 결정을 서술형으로 쓰면 이렇게 된다.

지난 분기 트래픽이 두 배로 늘면서 세션 테이블의 락 경합이 응답 지연의 주범이 되었다. 피크 시간대 p99 지연의 60%가 세션 조회에서 나왔다. 캐시 계층 도입이 필요했는데, Memcached는 재시작 시 세션이 전부 날아가 로그인 폭주를 일으킬 수 있어 제외했다. DynamoDB는 지연 요건은 맞췄지만 TTL 정밀도가 분 단위라 세션 만료 정책과 맞지 않았다. Redis는 두 요건을 모두 만족했고, 팀에 운영 경험이 있어 장애 대응 리스크도 낮다. 다만 단일 노드 구성이므로 Redis 장애 시 전체 로그인이 불가능해진다. 이것이 이 설계의 실패 조건이다.

읽는 데 세 배쯤 걸린다. 대신 이 글을 읽은 사람은 질문할 수 있다. “p99의 60%라는 수치는 어디서 나왔나?” “Memcached에 영속화 옵션이 있지 않나?” 열거식 문서 앞에서는 나오지 않던 질문들이다. 논리가 문장으로 이어져 있어야 논리의 구멍도 보인다. 인지부채를 갚는 문서는 빨리 읽히는 문서가 아니라 따져 읽을 수 있는 문서다.

결론

인지부채는 바이브 코딩의 버그가 아니라 비용이다. 속도를 샀으면 값을 치러야 한다. 값을 안 치르는 방법은 없다. human-in-the-loop처럼 치르는 시늉만 하는 방법이 있을 뿐이고, 시늉은 대체로 안 치르는 것보다 나쁘다.

기술부채를 다루듯 다루면 된다. 전부 갚으려 하지 마라. 갚을 수 없다. 대신 이자가 감당 가능한 수준인지 계속 확인하라. 내가 지금 뭘 승인했는지 설명할 수 없다면 이자가 한도를 넘은 것이다. 그때 쪽지시험을 보고, 디프를 이야기로 다시 읽고, 문서를 서술형으로 다시 써라.

이해는 자동으로 쌓이지 않는다. 코드만 자동으로 쌓인다.