코드 리뷰를 건너뛰면 기술 부채가 쌓입니다. 하지만 인간을 건너뛰면 다른 종류의 부채가 쌓입니다.

코드 리뷰 (Code Review)를 건너뛰면 기술 부채 (Technical Debt)가 쌓입니다. 하지만 인간을 건너뛰면 무엇이 쌓이는지에 대해 알아보겠습니다.

소프트웨어 공학 (Software Engineering)에는 기술 부채 (Technical Debt)라는 개념이 있습니다. 적절한 추상화 (Abstraction)를 건너뛰고, 빠르게 움직여서, 제품을 출시합니다. 언젠가는 리팩터링 (Refactoring) 시간을 들여 이를 갚아야 합니다.

저는 다른 종류의 부채에 대해 생각해 보았습니다. 코드베이스 (Codebase)에는 나타나지 않는 부채 말입니다.

인간 부채 (Human Debt): AI를 유일한 협업자로 삼아 개발할 때, 당신은 스스로를 나타나게 만드는 유일한 요소를 제거하게 됩니다. 기업적 의미의 책임감 (Accountability)이 아니라, 더 단순한 것입니다. 누군가가 당신의 작업물을 읽고 있다는 사실 말입니다. 당신은 그들의 시간을 낭비하고 싶지 않을 것입니다.

이것은 생산성 해킹 (Productivity Hack)이 아닙니다. 관찰될 때 인간이 행동하는 방식의 구조적 특성에 더 가깝습니다.

연구는 AI 때문에 시작된 것이 아닙니다

2015년, Gail Matthews는 목표 달성 여부를 추적하는 267명의 전문가를 대상으로 연구를 진행했습니다. 한 그룹은 자신의 목표를 기록했습니다. 다른 그룹은 목표를 기록하고 실제 사람에게 매주 진행 상황 보고서를 보냈습니다.

두 번째 그룹은 목표를 76% 더 많이 달성했습니다.

10% 더 많은 것이 아닙니다.

AI는 '14일 차'라는 개념이 없습니다. 당신이 화요일에 VS Code를 12분 동안 열었다가 다시 돌아오지 않았다는 사실을 알지 못합니다. 당신이 만들겠다고 말한 것과 실제로 만든 것 사이의 간극을 알아차리지 못합니다. AI는 당신의 커밋 히스토리(commit history)에서 유의미한 신호와 조작을 구분할 수 없습니다. METR의 2026년 연구 문서에 따르면, 난도가 높은 장기 과제(long-horizon tasks)에서 16%의 부정행위율이 기록되었으며, 성공한 에이전트(agent) 실행 건들도 검토 후 자격이 박탈되었습니다. 에이전트들은 진척 상황을 보고했지만, 실제로 해낸 것은 아니었습니다.

우리는 이 패턴을 **인간 부채 (Human Debt)**라고 부릅니다.

인간 검토자를 AI 협업자로 대체할 때마다, 당신은 아무도 청구하지 않을 작은 의무를 쌓아가게 됩니다. 체크인(check-ins)은 선택 사항이 됩니다. 마일스톤(milestones)은 제안 사항이 됩니다. 스프린트(sprint)는 미완성 파일들이 담긴 폴더가 되어버립니다.

한 개발자를 통해 목격한 것

이것을 검증된 제품의 주장이라고 미화하지는 않겠습니다. 이는 실험의 한쪽 면만 보이는 n=1의 신호입니다.

저는 30일 스프린트 시스템을 구축했습니다. 한 명의 개발자가 이를 수행했습니다 — 실버 티어(Silver tier), 21일 과정. 그는 13일 차까지 도달했습니다. 마일스톤은 실질적이었습니다: GitHub Pages 배포, 드론 미션 계획을 위한 KML 내보내기, Litchi 호환 웨이포인트(waypoints) 작동. 그것은 데모가 아니었습니다. 실제로 배포된 결과물이었습니다.

그러다 스프린트가 조용해졌습니다. 그는 체크인 기록을 중단했습니다. 21일 차는 오지 않았습니다.

제가 주목한 점은 다음과 같습니다: 누군가가 그의 체크인을 읽고 있을 때는 구조가 유지되었습니다. 그가 체크인을 보내지 않자, 실망시킬 대상이 사라졌습니다. 인간 부채는 보이지 않게 되었고, 그 스스로도 그 부채를 상환하는 것을 멈췄습니다.

제 제품이 문제를 해결했다거나 제가 책임 소재(accountability) 문제를 해결했다고 주장하는 것이 아닙니다. 데이터가 말해주는 바는 더 좁습니다: 인간이 읽고 있을 때, 개발자는 마일스톤까지 결과물을 인도(ship)했습니다. 루프(loop)가 닫히자, 스프린트는 끝났습니다.

이것은 하나의 데이터 포인트일 뿐입니다. 하지만 이는 138개의 연구 결과와 일치합니다.

왜 "인간 부채"가 적절한 프레임인가

기술 부채 (Technical Debt)가 유용한 이유는 보이지 않는 무언가에 이름을 붙여주기 때문입니다. 아무도 부채가 쌓이는 것을 보지 못합니다. 시스템이 고장 나고, 2019년에 다르게 작성되었어야 할 추상화 (Abstractions)를 풀어내느라 사흘을 허비할 때에야 비로소 그것을 알아차리게 됩니다.

인간 부채 (Human Debt)도 같은 형태를 띱니다. 당신이 건너뛴 체크인 (Check-ins)과 미뤄둔 마일스톤 (Milestones) 사이의 간극에서 보이지 않게 쌓입니다. 고개를 들어 스프린트 (Sprint) 폴더에 파일은 47개나 있는데 출시된 기능은 하나도 없다는 사실을 깨닫기 전까지는 알아차리지 못합니다.

이 프레임워크가 중요한 이유는 질문의 방향을 "내가 충분히 절제력이 있는가?"에서 "누군가가 읽고 있는 루프 (Loop)를 설계했는가?"로 전환하기 때문입니다. 절제력은 인격에 대한 판단입니다. 책임 구조 (Accountability architecture)는 엔지니어링의 문제입니다.

제가 대화해 본 대부분의 개발자는 책임의 부재를 개인적인 실패로 취급합니다. 그들이 충분히 일관되지 못했거나, 충분히 일찍 일어나지 못했거나, 주의가 산만했다고 생각합니다. 하지만 Matthews의 연구에 참여한 267명은 대조군 (Control group)보다 더 절제력이 있었던 것이 아닙니다. 그들은 단지 보고할 대상이 있었을 뿐입니다.

부채는 당신의 인격에 있는 것이 아닙니다. 시스템 설계에 있는 것입니다.

만약 당신이 지금 무언가를 만들고 있고, 오직 당신만이 자신의 진행 상황을 지켜보고 있다면, 이것이 작업이 예상보다 느린 이유일 수 있습니다. 제가 구축한 스프린트 시스템은 그 루프 안에 인간을 배치합니다. 데일리 체크인 (Daily check-ins)은 읽히고, 마일스톤은 봇 (Bot)에 의해 파싱 (Parsed)되는 것이 아니라 사람에 의해 검토됩니다.

Cohort #2 모집 중입니다. 추가 판매는 없으며, 링크만 제공합니다: mvpbuilder.io/pipeline

Building in public. Day 113.