AI로 10배 더 만드는데, 왜 결과를 아무도 안 믿을까 — 이해부채와 이해의 항복

집 서버에 이런저런 AI 에이전트를 붙여 쓰면서, 한동안 기분 좋은 착시에 빠져 있었다. 코드도, 문서도, 분석 리포트도 예전보다 몇 배씩 쏟아져 나왔다. 그런데 어느 순간 이상한 감각이 들었다 — 생산량은 분명히 늘었는데, 정작 내가 내놓은 결과물을 내가 확신하지 못한다. 출력이 맞는지 일일이 다시 들여다볼 시간은 없고, 그렇다고 안 보자니 찜찜하다. 이 글은 그 찜찜함의 정체에 대한 이야기다. 결론부터 말하면, 그건 게으름이 아니라 이해부채(cognitive debt)라는 구조적인 현상이고, 개인이든 조직이든 AI를 본격적으로 도입하면 거의 똑같이 밟는 함정이다.

먼저, 직관에 반하는 숫자 하나

Google이 매년 내는 DORA(소프트웨어 개발·전달 효율성 조사) 2024 리포트에 카운터-인튜이티브한 결과가 있다. 응답자의 75.9%가 업무에 AI를 쓰고, 75%가 "생산성이 올랐다"고 답했다. 여기까지는 예상대로다. 그런데 같은 조사에서, AI 채택이 늘어날수록(채택률 25% 증가를 기준으로) 소프트웨어 전달 처리량은 약 1.5% 줄고, 전달 안정성은 약 7.2% 떨어지는 것으로 추정됐다. 개개인은 더 빨라졌다고 느끼는데, 실제로 "쓸 수 있는 상태로 세상에 내보내는" 속도와 안정성은 오히려 나빠진 것이다.

DORA는 그 원인을 흥미롭게 짚는다. AI가 코드를 쉽게 쏟아내니 한 번에 바뀌는 변경 덩어리(batch size)가 커지고, 큰 변경은 늘 위험을 키운다는 것이다. 즉 문제는 "AI가 나쁜 코드를 만든다"가 아니라, 사람이 소화할 수 있는 속도보다 빨리 만들어진다는 데 있다. 체감 생산성과 실제 전달력 사이의 이 간극이, 내가 느낀 찜찜함의 첫 단서였다.

부채는 코드에만 쌓이지 않는다

우리가 익숙한 빚은 기술부채(technical debt)다 — 출시를 서두른 선택들이 누적돼 나중에 수정·확장을 더디게 만드는, 코드 안에 사는 빚이다. 그런데 Margaret-Anne Storey 등이 제안한 'triple debt' 모델(arXiv 2603.22106)은 AI 시대에 두 종류의 빚이 새로 두드러진다고 말한다. 하나는 이해부채, 다른 하나는 의도부채(intent debt)다. 이 글은 그중 지금 가장 아픈 이해부채 하나에 집중한다.

기술부채는 코드 안에 산다. 이해부채는 사람 머릿속에 산다.

이해부채의 정의는 이렇다 — "빨리 가느라 팀이 공유된 이해를 유지하지 못해 쌓이는 빚." 예전에는 결과물이 사람 손으로 천천히 나왔기 때문에, 만드는 과정 자체가 곧 이해의 과정이었다. 한 줄씩 짜고 한 문단씩 쓰다 보면 "왜 이렇게 했는지"가 자연스레 머리에 남았다. 그런데 작업 주체가 AI로 바뀌면서 결과가 한 덩어리로 와르륵 나온다. 이제 "이게 무엇을 하는지 파악하는 일"은 저절로 되는 게 아니라, 의도적으로 따로 시간을 내야 하는 별도 작업이 됐다. 문제는, 조직은 그 시간을 따로 줘야 한다는 사실을 모른다는 것이다. "왜 이렇게 늦어? 빨리 배포해" 하는 압박은 그대로다.

핵심 — 사람들은 'understanding'마저 항복한다

Andrej Karpathy가 2026년 한 강연에서 던진 문장이 이 지점을 정확히 찌른다.

"You can outsource your thinking, but you can't outsource your understanding."
(사고는 외주를 줄 수 있어도, 이해는 외주를 줄 수 없다.)

그는 이렇게도 말했다 — "전통적 소프트웨어는 우리가 명세할 수 있는 것을 자동화하고, LLM은 우리가 검증할 수 있는 것을 자동화한다." 즉 AI에게 일을 맡기더라도, "무엇을 만들려는지, 왜 그게 옳은지"를 아는 책임은 여전히 사람에게 남고, 사람이 그 병목이 된다는 뜻이다. 그런데 현장에서 실제로 벌어지는 일은 한 걸음 더 나간다. 사람들은 사고(thinking)뿐 아니라 이해(understanding)까지 항복해 버린다.

처음엔 AI 결과물을 눈으로 보려 애쓴다. 그런데 양이 너무 많고 방대하다. 그러면 결론 부분만 훑어 읽고 전체 검토는 포기한다. 그리고 그 결과를 이해했다는 확신 없이 다음 사람에게 넘긴다. 받은 사람도 똑같이 자기 AI에 그대로 넣어 한 번 더 돌려 회신한다. 이걸 이해의 항복이라고 부른다 — 자동 번역기가 뱉은 외국어 계약서를 읽지도 않고 서명한 뒤, 옆 사람에게 "확인해줘" 하고 넘기는 것과 똑같다. 그리고 옆 사람도 그걸 다시 번역기에 넣는다.

다이어그램 설명. 이 그림이 보여주는 건 이해의 항복이 한 사람의 게으름이 아니라 조직을 도는 루프라는 점이다. "AI가 결과물을 한꺼번에 생성"하면 사람은 "결론만 훑고 검토를 포기"하고, "확신 없이 다음 사람에게 전달"한다. 그 다음 사람이 "자기 AI에 넣어 한 번 더 돌리는" 순간 화살표가 처음으로 되돌아간다 — 검증되지 않은 결과물이 또 다른 검증되지 않은 입력이 되어 빙글빙글 돈다. 이 루프가 위험한 이유는, 한 바퀴 돌 때마다 "누가 이걸 실제로 이해했는가"의 답이 점점 비어 가는데도 산출물은 멀쩡해 보인다는 것이다. 그리고 "검토되지 않은 결과가 조직 안에 유통"되는 갈래는 조용히 쌓이다가 "장애나 잘못된 의사결정"으로 터진다.

이게 실제로 사고가 되는 두 장면

추상적으로 들릴 수 있으니 구체적인 두 장면으로 옮겨 보자.

첫째, 조용히 썩는 보고서. 경쟁사 조사를 맡긴 에이전트가 그럴듯한 리포트를 만들어 팀이 함께 쓰는 문서 도구에 자동으로 올려둔다. 정작 그걸 끝까지 읽는 사람은 없다. 몇 달 뒤, 그 안에 섞여 있던 환각(hallucination, AI가 그럴듯하게 지어낸 거짓 사실) 분석을 근거로 제품 전략이 정해진다. 아무도 그 거짓을 잡아내지 못한다. AI의 결과물은 "뻔한 버그"를 잘 만들지 않기 때문에 더 위험하다 — 작은 단위에서는 그럴듯하게 잘 돌아가고, 전체를 연결해 봐야 비로소 어긋남이 드러난다.

둘째, 판단 불능에 빠지는 장애 대응. 이해의 항복이 누적된 시스템에서 장애가 터진다. 보통 장애는 복잡한 상황에서 일어난다. 그때도 우리는 AI에게 묻는다. AI가 해결책 후보 몇 개를 내놓는다. 그런데 그 코드와 시스템을 충분히 이해한 사람이 없으면, 어느 대안이 옳은 방향인지 판단할 수가 없다. 가장 빠른 결정이 필요한 순간에, 결정을 내릴 근거가 머릿속에 없는 것이다. 이해부채는 평소엔 보이지 않다가 꼭 이런 위기에서 대형 사고로 모습을 드러낸다.

왜 이게 중요한가

여기까지가 내가 AI를 본격적으로 들이면서 만난 첫 번째 벽이다. AI 전환(AX)을 "도구를 깔고 계정을 나눠주는 일"로만 생각하면, 생산량 그래프는 우상향하는데 정작 신뢰할 수 있는 결과물은 늘지 않는 이상한 구간에 갇힌다. 체감은 좋은데 결과가 안 빨라지는, 바로 그 구간이다. 핵심은 분명하다 — AI 시대의 진짜 병목은 생산이 아니라 검증이다. 사고는 기꺼이 외주를 주되, 이해는 끝까지 사람이 쥐고 있어야 한다.

그렇다면 모든 출력을 사람이 다시 정독하면 될까? 양을 생각하면 불가능하다. 시니어 몇 명이 눈에 불을 켜고 리뷰해도 따라잡지 못한다. 그래서 필요한 건 "더 열심히 읽기"가 아니라 이해를 항복하지 않고도 결과를 믿을 수 있게 만드는 구조 — 검증을 사람의 정독에서 떼어내 별도의 자동화된 레이어로 옮기는 일이다. 그 구체적인 방법은 다음 글에서 다룬다.

---

참고한 공개 자료: Andrej Karpathy의 2026년 강연(verifiability·understanding 관련 발언), Google DORA 2024 State of DevOps Report, Margaret-Anne Storey 등의 'triple debt' 모델(arXiv:2603.22106), getdx의 cognitive debt 정리.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.