"AI가 짠 코드를 이해하지 못한 채 그냥 받아들이고 있지는 않나요?”
한국 개발 조직에서 앞으로 6~12개월 안에 반복해서 나올 질문입니다. 그리고 이 질문에 조직이 어떻게 답하느냐에 따라, 2024~2025년 사이에 축적된 AI 생산성이 자산으로 남을지 이연비용으로 돌아올지가 갈리게 됩니다.
오픈 프로젝트 시즌2가 한창 진행 중일 때, HoneyBeePF팀 Discord 채널에서 목격한 2개의 질문이 있습니다.
“왜 굳이 eBPF여야 하는가? 이미 다른 툴이 잘하고 있지 않은가?" “커널에 부담은 안 가나?”
기술적 맥락을 보기보다, 제가 주목했던 것은 이 두 질문이 Cognitive Debt를 예방하는 정확한 질문의 형태라는 점입니다.
목적의 재확인, 그리고 대가의 검증
두 질문을 조금 더 풀어보면, "왜 이 선택인가?"는 구현체 앞에서 추상 레이어를 되살리는 질문입니다. "이미 다른 툴이 있지 않은가?"는 대안 공간을 강제로 열어두는 질문입니다. "커널에 부담은?"은 단순 선택이 감추고 있는 비용을 꺼내는 질문이기도 합니다.
AI가 코드를 뱉는 순간, 사라지는 2~3가지 질문이 정확히 이것입니다. 그냥 코드가 작동하니까, 추상 레이어를 되살릴 필요가 없어 보이고, 대안 공간을 열 이유도 없어 보이고, 대가가 드러나기 전까지는 비용이 없는 것처럼 보이죠.
어제 ThoughtWorks Technology Radar Vol 34가 공개됐습니다. 그 안에 "Codebase cognitive debt"라는 블립이 Techniques 사분면에 새로 올라왔고, 이번 Radar 전체의 4개 테마 중 "Retaining principles, relinquishing patterns"가 이 블립의 상위 서사 역할을 합니다.
많은 초기 요약본이 이를 "AI 코딩의 위험성"으로 읽었습니다. 그 독해는 Vol 34의 주장을 다소 희석하는 방향입니다. 원문이 가리키는 것은 조금 다릅니다. 코드의 생산은 가속되고 있는데, 그 코드에 대한 인간의 이해가 시스템에서 빠져나가고 있다는 것. 작동하는 코드와 이해된 코드는 서로 다른 자산이라는 것. Radar 전체가 이번 분기에 "패턴은 AI에 맡겨도 된다. 그러나 엔지니어링 원칙은 넘기지 말라"로 묶여 있습니다.
이 문장을 받아들이면 Cognitive Debt는 "AI 도구의 부작용"이 아니라, 생산 속도와 이해 속도의 비대칭이 만드는 결과가 됩니다. 도구를 바꾼다고 사라지지 않고, 조직의 질문 습관을 바꾸지 않으면 도구와 무관하게 쌓입니다.
Technical Debt는 "지저분한 코드를 누군가는 이해하고 있는 상태"입니다. 리팩토링이 해결책이 되고, 비용도 추정 가능합니다. 숙련된엔지니어 몇명이 시간을 내어 정리하면 풀립니다.
Cognitive Debt는 **“깨끗해 보이는 코드를 아무도 이해하지 못한 상태”**입니다. 리팩토링으로 풀리지 않습니다. 다시 짜는 쪽이 빠른 경우가 많습니다. (그래서 디버깅 시간이 계속 늘어났죠!) 그리고 문제가 드러나기 전까지 정상으로 보인다는 점에서 Technical Debt보다 위험합니다.
더 치명적인 차이는 회계적으로 드러납니다. Technical Debt는 기록된 부채입니다. PR 라벨, TODO 주석, 이슈 트래커 어딘가에는 흔적이 남습니다. Cognitive Debt는 기록되지 않는 부채입니다. 코드는 커밋되는 순간 "완료"로 분류되고, 부족한 이해도는 장부 어디에도 기재되지 않습니다. 장부에 없는 부채는 복리로 불어나기 시작합니다.
METR이 2025년에 발표한 연구에서, 숙련 오픈소스 개발자 16명이 AI 도구 사용 시 "24% 빨라졌다"고 느꼈으나 실제 측정은 19% 느려진 것으로 나왔습니다. 표본은 작고, 오픈소스 태스크 기반이라 한국 엔터프라이즈에 그대로 일반화할 수는 없습니다. 그러나 "느낀 생산성"과 "실제 생산성"이 반대 방향으로 벌어지는 신호 자체가 드뭅니다. 이 방향성은 무겁게 받아야 한다고 생각합니다.
Google의 Addy Osmani는 이를 "70% Problem"이라 부릅니다. AI가 70%까지 5분에 데려다주는데, 남은 30%에서 5시간이 증발합니다. 우리가 AI가 쓴 코드를 이해하지 못한 채 다음 단계로 넘어갔기 때문입니다.
현재 한국 개발 조직의 AI ROI 계산식은 대부분 네 가지 지표로 요약됩니다. PR 수 증가율, 커밋 수 증가율, Lines of Code/day, 첫 PR까지 걸린 시간. 이 네 지표는 생산의 앞쪽만 측정합니다. 유지보수 구간에서 드러날 비용을 잡지 못합니다. 생산성처럼 보이는 숫자의 상당 부분이 6~12개월 뒤로 미뤄진 유지보수 비용일 가능성이 있고, 이게 사실이라면 AI 도입의 ROI는 지금 계산된 것보다 상당히 낮아집니다.
실무적으로는 세 지표를 AI ROI 계산서에 추가해 보는 것을 추천드리고 싶습니다.
- 코드 이해도 스코어 : AI가 작성하거나 크게 수정한 PR에 한해, 작성자가 "이 코드가 왜 이렇게 작동하는지"를 리뷰어에게 3분 내로 설명할 수 있는지를 랜덤 샘플링으로 측정합니다. (설명 가능 비율이 일정 수준 아래로 떨어지면 경고)
- AI 코드 장애 복구 시간 : 장애가 났을 때 원인 코드가 AI 작성/수정 구간인 경우의 MTTR과, 사람 작성 코드의 MTTR을 비교합니다. 전자가 후자보다 유의미하게 길어지면 Cognitive Debt의 직접 증거입니다.
- 온보딩 시간 추이 : 신규 개발자가 AI 이전에 짠 코드베이스에 적응한 시간과, AI 이후에 짠 코드베이스에 적응한 시간을 비교합니다. 후자가 길어지면 코드의 인간 읽힘성이 저하되고 있다는 신호입니다.
이 세 지표는 전부 사람이 이해하지 못하는 구간을 가시적인 영역으로 끌어올리는 장치입니다. 보이는 부채는 대비할 수 있는 계획을 세울 수가 있습니다.
대부분의 한국 개발 조직은 2024년 하반기~2025년 상반기에 Copilot을 도입했고, 2025년 중후반부터 Cursor와 Claude Code가 본격적으로 깔렸습니다. 상당수 조직이 AI 생성 코드가 프로덕션에 안착한 지 6~12개월 지점에 이미 와 있다는 방증입니다.
Cognitive Debt의 대가는 대개 아래 세 가지 형태로 지금도 다가오고 있습니다.
- 원저자가 퇴사한 뒤 AI가 짠 코드만 남은 모듈에서 장애가 발생합니다. 디버깅 시간이 평소의 2~3배로 늘어납니다.
- 신규 입사자가 코드베이스의 특정 영역에서 계속 막힙니다. 질문하면 "AI가 짜서 잘 모른다"는 답이 돌아옵니다.
- 작은 요구사항 변경인데 영향 범위 분석에 비정상적으로 오래 걸립니다. 코드 이해도가 낮아 안전한 수정 경로가 보이지 않기 때문입니다.
이 세 현상 중 하나라도 조직에서 관찰된다면, Cognitive Debt 측정을 시작할 시점입니다. 아직 관찰되지 않았다면, 관찰되기 전이 예방 지표를 심을 골든타임입니다.
"왜 이 선택인가?"와 "대가는 누가 치르는가?"를 묻는 조직에서 AI는 이해도를 오히려 끌어올립니다. 설명해달라고 요청하면 Claude든 Cursor든 기꺼이 설명해주는 시대입니다. AI를 코드 작성 도구로만 쓰는 조직과, 이해 증폭 도구로도 쓰는 조직 사이의 격차는 앞으로 벌어질 것이라고 봅니다.
문제는 그 질문을 생략하는 조직입니다. 거기서 AI는 Cognitive Debt를 훨씬 더 빠른 속도로 쌓습니다. 그리고 이 격차는 도구의 가격표에는 드러나지 않습니다.
결론, "AI를 쓸 것인가 말 것인가"가 아니라 AI가 뱉은 코드 앞에서 여전히 적확한 질문을 하고 있는지를 검토해야 할 시점이라고 봅니다. 그리고 의심 없이 코드를 적용하는 순간을 포착할 장치가 있는지, 그리고 이해도를 측정 지표로 내려서 가시적인 영역으로 올릴 준비가 되어 있는지가 먼저 점검해야할 때라고 생각합니다.
여러분의 팀은 AI가 짠 코드를 어디까지 이해한 채 프로덕션에 올리고 있나요?
Cognitive Debt의 첫 신호로 어떤 지표를 올려두셨나요?
참고 기사
- ThoughtWorks Technology Radar Vol 34 (2026.04.15) https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2026/04/tr_technology_radar_vol_34_en.pdf