47개 파일이 바뀐 PR이 있다. React 컴포넌트 3개, API 라우트 2개, 컨텍스트 프로바이더 1개, 그리고 누가 요청한 것도 아닌 폼 검증 라이브러리 하나. 점심을 먹으면서 쓴 프롬프트 하나로 AI 에이전트가 2시간 만에 만들어낸 결과물이다. dev.to에 올라온 이 사례의 저자는 "일주일 걸릴 작업"이라고 감탄했다. 그리고 6주 뒤, 아직도 그 PR을 풀고 있다.
문제는 코드가 동작하지 않는다는 게 아니다. 컴포넌트는 '대체로' 작동하고, 폼은 '어느 정도' 검증한다. 진짜 문제는 팀원 중 누구도 왜 상태가 그 구조로 설계됐는지 설명하지 못한다는 것이다. AI는 기존 코드베이스의 패턴을 몰랐고, 그래서 새 패턴을 발명했다. 결과적으로 같은 역할을 하는 패턴이 두 개가 됐고, 어느 것을 언제 써야 하는지 문서는 없다. 이것이 'Ghost Implementation'이다—뼈대(컴포넌트, 함수, 임포트)는 있지만 살(그 구조를 선택한 근거)은 없는 코드.
이 문제가 지금 더 중요하게 느껴지는 이유가 있다. AI 타임즈 보도에 따르면, SpaceX가 AI 코딩 플랫폼 Cursor 개발사 Anysphere를 600억 달러(약 90조 원) 규모에 인수하기로 했다. IPO 나흘 만의 결정이다. Cursor는 이미 연간 10만 달러 이상을 지불하는 기업 고객 3000곳 이상을 확보했고, ARR은 최대 30억 달러에 달한다. SpaceX의 컴퓨팅 인프라와 xAI의 모델이 Cursor에 결합되면, AI 코딩 도구의 성능과 접근성은 지금보다 훨씬 빠르게 높아질 것이다. 즉, Ghost Implementation을 만들어낼 도구의 속도와 규모가 커진다는 뜻이다.
기존에 우리가 다뤄온 주제—리뷰 전략, 보안 설계, 품질 게이트—는 모두 AI가 생성한 결과물을 외부에서 걸러내는 구조였다. 하지만 Ghost Implementation은 그 전 단계에서 발생한다. 코드가 게이트를 통과한 뒤의 문제가 아니라, 개발자가 게이트 앞에서 이미 이해를 포기한 상태가 문제다. 리뷰어가 AI 제안을 읽는 속도보다 빠르게 'Accept'를 누르고, 아키텍처 결정이 요구사항 회의에 없었던 모델에 의해 이루어지고, 버그를 만나면 직접 디버깅하기 전에 AI에 먼저 묻는다. 저자가 명명한 세 가지 증상—Implementation Amnesia, Reviewer's Blindness, Debugging Reflex Atrophy—은 도구의 결함이 아니라 개발자 역량의 점진적 공동화다.
'AI는 보일러플레이트를 처리하고, 나는 아키텍처를 담당한다'는 말이 개발자 커뮤니티에서 일종의 합의처럼 통용된다. 나도 팀에 비슷한 말을 해왔다. 그런데 이 말이 실제로 어떻게 작동하는지를 들여다보면 균열이 보인다. 보일러플레이트와 아키텍처 결정은 명확히 분리되지 않는다. AI가 폼 검증, API 클라이언트, 에러 핸들링을 생성할 때, 그 안에는 시스템 설계에 영향을 미치는 선택들이 조용히 포함된다. 저자가 목격한 세 팀은 AI가 '합리적인' 클래스를 하나씩 추가하는 동안 2000줄짜리 God Object가 만들어지는 걸 눈치채지 못했다. 전체 그림을 아무도 보지 않았기 때문이다.
테크 리드로서 나는 이 문제를 두 가지 레이어로 구분해서 본다. 첫 번째는 개인 레이어다. AI 의존도를 스스로 측정해야 한다. 저자가 제안한 'AI 의존도 점수(1=완전 자율, 5=AI가 전부 작성)'를 30일 평균으로 추적하고, 3.5를 넘으면 경고 신호로 읽어야 한다. AI 없이 코딩하는 사이드 프로젝트를 유지하는 것도 효과적이다—비효율이 목적인 공간이 역설적으로 독립적 사고를 훈련한다. 두 번째는 팀 레이어다. PR 머지 기준에 '설명 가능성'을 포함시켜야 한다. 코드가 동작하는지가 아니라, 작성자가 왜 이 구조를 선택했는지를 설명할 수 있는지가 머지의 조건이 되어야 한다.
실용적으로 정리하면 세 가지다. 첫째, 아키텍처 결정 로그를 의무화한다. AI가 생성한 비자명한 구조에 대해 '무엇을 선택했는지, 무엇을 버렸는지, 왜 그 선택이 이겼는지' 세 문장을 반드시 남긴다. 미래의 팀원이 AI에게 물어봐도 알 수 없는 맥락을 사람이 기록해야 한다. 둘째, 리뷰 프로세스에 '구두 설명' 단계를 넣는다. 특히 AI 에이전트가 생성한 코드를 포함한 PR은, 작성자가 핵심 구조를 팀에 직접 설명하는 짧은 세션을 의무화한다. 설명할 수 없으면 머지하지 않는다. 셋째, 속도 지표를 재정의한다. 'Time to First Working Version'만 측정하면 Ghost Implementation은 계속 쌓인다. 'Time to Maintainable System'을 함께 추적해야 두 수치 사이의 갭이 보이고, 그 갭이 기술 부채의 실제 크기다.
SpaceX의 Cursor 인수는 AI 코딩 도구가 인프라 수준의 전략 자산으로 자리 잡았음을 의미한다. 도구는 더 빨라지고, 더 강력해지고, 더 저렴해질 것이다. 그 흐름을 막을 이유도 없고, 막을 수도 없다. 하지만 도구의 속도가 올라갈수록, 그 출력물을 이해하는 개발자의 밀도는 반대 방향으로 움직이는 경향이 있다. AI가 5개 화면을 하루에 만들어내는 것은 이야기의 시작이지 끝이 아니다. 그 코드를 6개월 뒤에 고칠 수 있는 사람이 팀에 남아 있느냐가 진짜 질문이다. Ghost Implementation은 코드베이스의 문제가 아니라, 팀이 자신의 시스템을 이해하는 능력을 잃어가고 있다는 신호다.