"AI 슬롭 부채(AI slop debt)"는 가속화된 기술 부채입니다. 아무도 준비되지 않았습니다.

여러분이 가졌던 모든 정리 프로세스는 인간의 속도로 발생하는 난장판을 위해 설계되었습니다. AI 에이전트는 그저 "니트로(nitro) 버튼"을 누를 뿐입니다. 최근 pmdata.substack.com의 한 글에서 제가 생각을 멈출 수 없는 용어를 만들어냈습니다: "AI 슬롭 부채 (AI slop debt)". 이는 Claude Code나 Lovable 같은 도구들이 기능적이지만 영혼 없는 코드의 산을 생성할 때 발생하는 현상에 관한 것입니다. 그리고 이는 우리 대부분이 느끼고 있지만 아직 이름을 붙이지 못한 무언가를 정확히 짚어냅니다.

속도 문제는 새로운 것이 아닙니다. 규모가 문제일 뿐입니다. 기술 부채 (Technical debt)는 우리가 소프트웨어를 인도하기 시작한 이래로 항상 존재해 왔습니다. 우리는 항상 지름길을 택했고, 임시방편적인 (hacky) 결과물을 출시했으며, 나중에 수정하겠다고 약속했습니다. 그것은 용인 가능한 수준이었습니다. 인간은 인간이 (이론적으로) 정리할 수 있는 속도로 기술 부채를 생성합니다. 하지만 AI 에이전트는 "나중에"라는 개념에 관심이 없습니다. 이들은 코드를 너무 빠르게 작성하기 때문에, 다음 스프린트 계획 (sprint planning)이 시작되기도 전에 여러분의 백로그 (backlog)가 쓸모없게 되어버립니다.

아무도 이 코드를 소유하지 않습니다. pmdata의 저자는 이를 SoFi에서 소유권이 없는 핵심 코드를 떠맡는 상황에 비유합니다. 여러분도 그런 경험이 있을 것입니다. 어떤 시스템이 핵심적인 역할을 하고 있는데, 문서는 아무도 작성하지 않았고, 원작자는 떠났으며, 이제 그것은 여러분의 문제가 된 상황 말입니다. AI 슬롭 부채는 바로 그 시나리오와 같지만, 그 대상이 모든 파일이라는 점이 다릅니다. "원작자"는 자신이 그것을 작성했다는 사실조차 기억하지 못하는 확률적 모델 (probabilistic model)이었습니다. Slack으로 연락할 사람도 없습니다. 조직적 기억 (institutional memory)도 없습니다. 그저... 출력물만이 존재할 뿐입니다.

상황을 악화시키는 요인들은 다음과 같습니다:

→ 소유권의 부재. 아무도 마감 직전 새벽 2시에 직접 작성한 코드만큼 AI가 생성한 코드에 책임감을 느끼지 않습니다.
→ 취향 (Taste)의 부재. 코드는 작동합니다. 테스트도 통과합니다. 하지만 일관된 설계 철학을 반영하지는 않습니다.
→ 마찰 (Friction)의 부재. 나쁜 결정을 늦추던 요소, 즉 실제로 그것을 타이핑하는 데 드는 노력이 사라졌습니다.

"취향"이 실제 해자 (Moat)입니다. pmdata의 글은 진짜 과제는 이러한 시스템에 엔지니어링적 취향을 인코딩하는 것이라고 주장합니다. 저 또한 이 점이 핵심을 찌르고 있다고 믿습니다. 취향은 왜 시니어 엔지니어의 "단순한" 해결책이 주니어의 "작동하는" 해결책과 다르게 보이는지를 설명해 주는 근거이기 때문입니다.

그것은 다음 기능과 접촉했을 때 살아남는 코드와, 그 기능의 무게 아래 무너져 내리는 코드 사이의 차이입니다. AI 도구는 취향 (taste)을 가지고 있지 않습니다. 그들은 패턴 (patterns)을 가지고 있을 뿐입니다. AI는 합리적으로 보이는 코드를 출력하겠지만, 무언가가 어떻게 개발되어야 하는지에 대한 신념은 없습니다. 🧠 그리고 여기서 불편한 사실이 있습니다. 대부분의 팀은 자신의 취향조차 제대로 설명하지 못한다는 점입니다. 취향은 코드 리뷰 (code review) 코멘트, 복도에서의 대화, 그리고 이전에 실패를 경험해 본 사람들의 직감 속에 존재합니다. 그것을 시스템 프롬프트 (system prompt)에 집어넣으려 한다면 행운을 빌어야 할 것입니다.

당신의 기존 프로세스가 무너질 것입니다

코드 리뷰 (Code review)? 이미 스트레스가 심한 작업입니다. 이제 인간 팀이 검토조차 할 수 없을 정도로 대량으로 쏟아져 들어오는 출력물을 검토하는 상황을 상상해 보십시오. 리팩터링 스프린트 (Refactoring sprints)? 그것들은 하룻밤 사이에 쌓인 것이 아니라, 수 분기 동안 축적된 부채를 물려받은 것입니다. 린팅 (Linting)과 정적 분석 (static analysis)은 구문 수준 (syntax-level)의 문제를 잡아냅니다. 하지만 "이 아키텍처는 6개월 뒤에 악몽이 될 것이다"라는 문제는 잡아내지 못합니다. 그것은 판단의 영역입니다. 그것은 다시 말해 취향의 문제입니다. 이 상황에서 살아남는 팀은 코드를 가장 빠르게 생성하는 팀이 아닙니다. 스스로 만들어낸 결과물에 익사하지 않으면서 어떻게 속도 (velocity)를 유지할지 찾아내는 팀입니다. 🏊

실제로 도움이 되는 것

저는 그 해답이 "AI 도구 사용을 중단하라"는 것이라고 생각하지 않습니다. 그 배는 이미 떠났습니다. 우리에게 더 이상 선택할 수 없는 옵션입니다.

→ AI의 출력물을 신뢰할 수 없는 계약업체가 보낸 풀 리퀘스트 (pull request)처럼 취급하십시오. 당신의 시스템을 모르는 누군가가 작성한 코드를 리뷰하듯 리뷰하십시오.
→ 생성 속도에 투자하기 전에 아키텍처 가드레일 (architectural guardrails)에 투자하십시오. 당신의 시스템이 가진 취향을 글로 설명할 수 없다면, AI는 분명히 그것을 따를 수 없습니다.
→ "빠름"과 "유지보수 가능성"은 서로 긴장 관계에 있음을 받아들이십시오. 모든 팀은 기본 설정 (default)에 의존하는 것이 아니라, 의도적으로 그 경계선을 어디에 그을지 결정해야 합니다.

진짜 질문

AI 기술 부채 (technical debt)는 나중에 닥칠 문제가 아닙니다. 생성된 파일이 면밀한 검토 없이 제출되는 모든 코드베이스에서 지금 이 순간에도 축적되고 있습니다. 이 용어가 만들어진 이유는 그 고통이 이미 존재하기 때문입니다. 💥 우리는 인간의 속도에 맞춘 실수들을 바탕으로 수십 년간의 프로세스를 구축해 왔습니다.

우리는 기계의 속도로 발생하는 실수들에 적응하기 위해 아마도 몇 달 정도의 시간밖에 남지 않았을 것입니다. 그래서 저는 이것이 궁금합니다. 여러분의 팀은 AI가 생성한 코드의 품질을 처리하기 위해 구체적으로 프로세스를 변경했나요? 아니면 여전히 이를 일반적인 기술 부채 (tech debt)처럼 취급하며 그저 잘 되기를 바라고 있나요?