AI가 2시간 만에 내 UI를 만들었지만, 이를 수정하는 데 3주가 걸렸다

해당 PR (Pull Request)에는 47개의 변경된 파일이 있었습니다. 세 개의 새로운 React 컴포넌트, 두 개의 API 라우트, 하나의 컨텍스트 프로바이더 (context provider), 그리고 전체 폼 검증 (form validation) 라이브러리로 보이는 것이 포함되어 있었습니다. 이 모든 것은 제가 점심을 먹으며 작성한 프롬프트 (prompt)를 따라 AI 에이전트 (AI agent)가 2시간도 채 되지 않아 생성해낸 결과물이었습니다.

"이건 정말 놀랍다"라고 저는 생각했습니다. "이 작업은 일주일은 걸렸을 텐데."

6주가 지난 지금, 저는 여전히 그 PR을 풀어내고 있습니다. 컴포넌트들은 작동합니다 — 대체로 말이죠. 폼 검증도 — 어느 정도는 됩니다. 하지만 팀원 중 누구도 왜 단순한 프롭 (prop)으로 충분한 상황에서 상태 (state)를 컨텍스트 프로바이더 (context provider)로 끌어올려야 (lifting) 하는지 설명하지 못합니다. AI는 우리의 기존 패턴을 알지 못했기에 새로운 패턴을 만들어냈습니다. 그리고 이제 우리는 동일한 작업을 수행하는 두 개의 패턴을 가지게 되었고, 언제 어떤 것을 사용해야 하는지 설명하는 문서 (documentation)는 전무합니다.

이것이 바로 고스트 구현 (Ghost Implementation) 문제입니다 — 뼈대(컴포넌트, 함수, 임포트)는 모두 갖춰져 있지만, 살(왜 그 뼈대들이 그런 방식으로 배치되었는지를 설명하는 정당화된 로직)은 전혀 없는 코드 말입니다.

고스트 구현 문제 (The Ghost Implementation Problem)

고스트 구현은 속도에 집착하는 AI 도구 (AI tooling)의 자연스러운 부산물입니다. 당신이 요청한 결과물을 얻게 됩니다. 코드는 컴파일 (compile)됩니다. 테스트 (test)도 통과합니다. 하지만 왜 그렇게 작성되었는지 아무도 설명할 수 없습니다 — AI도 (컨텍스트가 없으므로), 개발자도 (완전히 이해하지 못한 채 승인했으므로) 말이죠.

이러한 성찰을 불러일으킨 Qiita 포스트는 이와 유사한 상황을 설명했습니다: 한 개발자가 AI 에이전트 (AI agents)를 사용하여 하루 만에 5개의 비즈니스 화면을 구축한 사례입니다. 속도는 실재했습니다. 생산성 향상도 실재했습니다. 하지만 그 포스트는 인도(delivery) 후 몇 주 동안 해당 코드베이스 (codebase)에 어떤 일이 일어났는지에 대해서는 눈에 띄게 침묵했습니다.

제가 컨설팅 업무를 수행하며 지속적으로 관찰하는 내용은 다음과 같습니다:

구현 망각 (Implementation Amnesia): 요구사항은 유창하게 설명할 수 있지만, "실제 함수 시그니처 (function signature)가 어떻게 생겼지?"라는 지점에서 사고가 멈춰버리는 개발자들입니다. 이들은 뇌가 생각을 마치기도 전에 AI에 손을 뻗습니다.
검토자의 맹목 (Reviewer's Blindness): AI의 제안을 읽기도 전에 "수락 (Accept)" 버튼을 더 빨리 클릭하는 엔지니어들입니다. 제품 요구사항이 변경되었을 당시 그 자리에 없었던 모델에 의해 아키텍처 결정 (Architectural decisions)이 내려집니다.
디버깅 반사 신경의 위축 (Debugging Reflex Atrophy): 변수를 격리하기 전에 AI로 달려가는 현상입니다. 예전에는 학습의 기회가 되었을 15분짜리 버그가, AI가 만들어낸 토끼굴 (rabbit holes) 속에서 3시간 동안 이어지는 스레드가 되어버립니다.

이 패턴은 예측 가능합니다. AI 도구들은 _코드를 빠르게 생성하는 것_에 최적화되어 있습니다. 이 목적에 있어서는 눈부시게 성공적입니다. 하지만 그 과정에서 희생되는 것은 개발자의 이해도, 즉 요구사항이 변경될 때 시스템을 유지 관리하고, 디버깅하며, 진화시킬 수 있게 해주는 정신적 모델 (mental model)입니다.

속도의 함정 (The Velocity Trap)

현재 개발자 커뮤니티에서는 다음과 같은 잘못된 등가성을 밀어붙이고 있습니다: "AI가 상용구 코드 (boilerplate)를 처리하고, 나는 아키텍처 (architecture)를 담당한다."

이것이 실제 현장에서 무엇을 의미하는지 깨닫기 전까지는 합리적으로 들립니다. "상용구 코드 (Boilerplate)"는 단순히 반복적인 코드만을 의미하지 않습니다. 그것은 시스템 설계 (system design)를 드러내는 결합 조직 (connective tissue)입니다. AI가 폼 검증 (form validation), API 클라이언트 (API client), 에러 핸들링 (error handling)을 생성할 때, 여러분은 아키텍처에 반영되어야 할 패턴을 인지할 기회를 놓치게 됩니다.

저는 지난 1년 동안 세 팀이 동일한 아키텍처 실수를 두 번이나 반복하는 것을 목격했습니다. 그들은 AI가 하나의 "그럴싸한" 클래스를 점진적으로 생성하고 있었기 때문에, 자신들이 '갓 오브젝트 (god-object)'를 구축하고 있다는 사실을 인지하지 못했습니다. 모든 새로운 기능이 건드려야만 하는 2,000줄짜리 괴물이 되기 전까지는 아무도 전체 그림을 보지 못했습니다.

합의된 의견 (개발자들이 믿는 것)	현실 (데이터가 보여주는 것)
"AI가 상용구 코드를 처리하고, 나는 아키텍처를 담당한다"	"아키텍처 패턴 역시 상용구 코드와 동일한 방식으로 — 검토 없이, 보이지 않게, 점진적으로 생성된다"
...

회의적인 시각 (The Skeptical Take

여기서 저는 제가 스스로에게 처방했던 약에 대해 틀렸음을 인정하겠습니다.

저는 2025년의 대부분을 팀들에게 AI 도구(AI tooling)를 사용할 때 주의하라고 말하며 보냈습니다. 그리고 그들은 대체로 제 말을 무시했습니다. 왜냐하면 속도 향상(velocity gains)이 실제로 나타났기 때문입니다. 예전에는 몇 주가 걸리던 기능을 며칠 만에 출시하는 팀들이 생겨났습니다. 프론트엔드 작업에 막혀 있던 개발자들이 갑자기 완전한 UI를 구축했습니다. 생산성 수치는 가짜가 아니었습니다.

문제는 AI 도구가 작동하지 않는다는 것이 아닙니다. 그것들은 작동합니다. 문제는 성공 지표(success metric)가 불완전하다는 점입니다.

우리는 "첫 번째 작동하는 버전까지의 시간(time to first working version)"은 측정하지만, "유지보수 가능하고 진화 가능한 시스템까지의 시간(time to maintainable, evolvable system)"은 측정하지 않습니다. 이 둘은 서로 다른 것입니다. 그리고 그 사이의 간극이 바로 '유령 구현(Ghost Implementations)'이 존재하는 곳입니다.

공정하게 말하자면, 저도 그 압박감을 이해합니다. 마감 기한은 기술 부채(technical debt) 따위는 신경 쓰지 않습니다. 제품 관리자(Product managers)는 당신의 상태 관리 계층(state management layer)에 대한 멘탈 모델(mental model)에 대해 묻지 않습니다. 출시하려는 유인은 즉각적이지만, 아키텍처 붕괴(architectural decay)의 비용은 뒤로 미뤄집니다. 만약 제 분기별 목표가 출시된 기능 수로 측정되었다면, 저 역시 똑같은 지름길을 택했을 것입니다.

하지만 부채는 실재하며, 복리로 쌓입니다.

퇴화 방지 생존 가이드 (The Anti-Atrophy Survival Guide)

이것은 AI 도구를 거부하자는 것이 아닙니다. AI를 효과적으로 사용할 수 있을 만큼 충분히 강력한(dangerous enough) 기초 역량을 유지하자는 것입니다. 좋은 결과물이 어떤 모습인지 잊어버린다면, AI의 결과물을 평가할 수 없습니다.

주 1회 "두 번 설명하기" 세션: 매일 사용하는 개념에 대한 설명을 글로 적은 뒤, 다시 읽어보세요. 공식 문서(docs)를 참조하지 않고 특정 도구가 왜 그렇게 작동하는지 명확하게 설명할 수 없다면, 그 부분이 바로 당신의 공백입니다.
하나의 "멍청한" 사이드 프로젝트 유지: AI 없이 코딩하는 무언가를 만드세요. 비효율성이 핵심인 프로젝트여야 합니다. 목표는 뇌가 잊어버리는 것을 손이 기억하게 만드는 것입니다.
아키텍처 결정 로그 (Architecture decision log): 사소하지 않은 모든 결정에 대해 세 문장을 작성하세요: 무엇을 선택했는지, 무엇을 거절했는지, 그리고 선택된 것이 왜 승리했는지. AI가 시스템이 왜 이렇게 구축되었는지 설명하지 못할 때, 미래의 당신은 현재의 당신에게 감사하게 될 것입니다.
"AI 의존도 점수 (AI dependency score)" 추적: 각 코딩 세션을 평가하세요: 1=완전 자율, 5=AI가 모든 것을 작성함. 만약 30일 평균이 3.5를 넘어간다면, 당신은 기반을 잃어가고 있는 것입니다.

하루 만에 5개의 화면을 만든 AI 에이전트? 그것은 이야기의 끝이 아닙니다. 그것은 유지보수 주기(maintenance cycle)의 시작입니다. 질문은 당신이 시스템을 이해하는 개발자가 될 것인지, 아니면 그저 AI가 다음에 제안하는 무엇이든 승인하기만 하는 개발자가 될 것인지입니다.

가장 최근에 AI가 생성한 PR(Pull Request)을 살펴보세요. 상태(state)가 왜 그런 방식으로 배치되었는지 소리 내어 설명해 보세요. 만약 할 수 없다면 — 그것이 바로 당신의 "유령 구현 (Ghost Implementation)"입니다.

당신의 의견은 어떠신가요?

여러분의 구체적인 상황에서는 어떻게 전개되는지 듣고 싶습니다. 아래에 댓글을 남겨주세요. 모든 댓글에 답글을 달겠습니다.

여러분의 팀은 개발자들이 AI 없이 독립적인 디버깅(debugging)을 수행하는 능력이 떨어지는 것을 목격했나요? 여러분의 경험은 어떠했나요?

Qiita(miyakiyo)의 "AIエージェントで業務開発はここまで来た｜1日で5画面作った話"를 바탕으로 작성되었습니다 — AI 에이전트를 사용하여 하루 만에 5개의 비즈니스 화면을 구축한 일본 개발자의 생생한 기록입니다.

토론: 여러분의 팀은 개발자들이 AI 없이 독립적인 디버깅(debugging)을 수행하는 능력이 떨어지는 것을 목격했나요? 여러분의 경험은 어떠했나요?