한 주 동안 Claude Code에 기능 하나를 통째로 맡긴 개발자가 있다. 아키텍처, 스키마, API, UI, 테스트까지—단 한 줄도 직접 타이핑하지 않고 오직 리뷰, 실행, 프롬프트만 했다. dev.to에 공개된 이 실험 기록은 흔한 'AI 생산성 자랑'이나 'AI 위험 경고'와 결이 다르다. 실제로 무엇이 작동했고, 무엇이 조용히 무너졌는지를 날짜별로 추적한다.
첫 이틀: 진짜로 빠르다
Next.js + Postgres 기반의 알림 시스템(notification system)을 구축하는 실험이었다. 200단어 남짓한 설명을 건넸더니 한 시간 안에 스키마, 마이그레이션 파일, 이벤트 큐 워커, 기본 API, 테스트까지 작동하는 상태로 나왔다. 혼자 했다면 이틀은 걸렸을 작업이다. 이 부분은 부정할 이유가 없다. AI 코딩 에이전트의 '첫 60%'는 실제로 빠르다.
3일차: 조용한 버그가 반나절을 삼켰다
문제는 3일차에 나타났다. 일부 알림이 4초씩 지연되는 현상이 스테이징 환경에서만 재현됐다. Claude Code에 원인 분석을 맡겼지만 해결되지 않았다. 결국 직접 코드를 읽고, 로그를 찍고, 트레이스를 분석하는 데 4시간이 걸렸다. 범인은 단 하나—sendNotification(result)에서 빠진 await 하나였다.
이 버그가 중요한 이유는 버그 자체 때문이 아니다. '리뷰 모드'와 '작성 모드'는 다른 인지 상태라는 사실을 증명했기 때문이다. 직접 코드를 쓸 때는 비동기 호출 여부를 생각하면서 타이핑한다. 리뷰할 때는 그 생각이 없다. AI가 생성한 코드를 리뷰하는 행위는, 본인이 작성할 때와 다른 종류의 주의력을 요구한다.
4일차: 맥락 망각과 리라이트 루프
이미 승인된 워커 코드 위에 사용자별 알림 설정 기능을 추가하려 했더니, Claude Code는 새 기능을 얹는 대신 기존 워커의 일부를 조용히 다시 썼다. 변수명이 바뀌고, 에러 핸들링 전략이 달라졌다. '일관성 개선'이라는 설명이 돌아왔지만, 이미 테스트를 통과한 코드가 다시 검증 대상이 되는 순간이었다.
이 패턴은 계속 반복됐다. 새 요청마다 관련 없는 영역까지 변경됐다. 시간의 상당 부분이 '왜 바꿨느냐, 원래대로 되돌려라'는 대화에 쓰였다. Anthropic 엔지니어링 블로그(Claude 블로그 #104)가 지적한 것처럼, AI 에이전트의 harness는 '모델이 무엇을 못 한다'는 가정을 인코딩한다—그 가정이 계속 재확인될수록 개발자의 판단 비용이 쌓인다.
5일차: 자신감 있는 환각
가장 불안한 순간은 금요일이었다. rate limiting 기능을 요청하자 Claude Code는 Redis 기반 슬라이딩 윈도우를 깔끔하게 작성해왔다. 문제는 이 프로젝트에 Redis가 없었다는 점이다. 언급한 적도, 설치된 적도 없는 의존성이 '당연히 있는 것처럼' 등장했다. 코드 자체는 훌륭했다. 하지만 그 아래 깔린 가정은 완전히 만들어진 것이었다.
덜 꼼꼼한 리뷰어였다면 npm install redis를 실행하고 Redis 인스턴스를 인프라에 추가했을 것이다. 환각의 무서움은 틀린 답이 아니라, 틀린 전제가 맞는 답처럼 포장된다는 데 있다.
AI 없이 코딩한 경험이 던지는 질문
흥미롭게도 비슷한 시기, AI 구독 rate limit에 막혀 두 시간 동안 혼자 코딩한 개발자의 경험이 dev.to에 올라왔다. Kotlin 문법이 바로 떠오르지 않았고, 로직을 스스로 구조화하는 데 시간이 걸렸다. 하지만 결국 그 과정에서 '결정을 느끼는' 감각, '왜'를 직접 이해하는 깊이가 되살아났다고 했다.
이 두 경험은 같은 질문의 양면이다. AI에게 맡기면 빠르지만 맥락을 잃는다. 직접 짜면 느리지만 판단이 체화된다. 어느 쪽이 옳은가의 문제가 아니라, 언제 어느 쪽을 선택할 것인가의 설계 문제다.
실용 판단 프레임: 무엇을 맡기고 무엇을 직접 짜는가
일주일의 실험이 만들어낸 작동 기준은 이렇다.
맡겨도 되는 것: - 초기 스캐폴딩—스키마, 파일 구조, 보일러플레이트. 아직 잃을 맥락이 없는 '첫 60%' - 기계적이지만 반복적인 작업—테스트 케이스 작성, 타입 생성, 마이그레이션 파일, README - 낯선 서비스 탐색—처음 쓰는 외부 SDK의 첫 시도. 빈 문서를 보며 막히는 것보다 수정하는 편이 빠르다
직접 짜야 하는 것:
- 비동기 정확성이 중요한 코드—await 누락, 트랜잭션 탈출 같은 버그는 테스트에서 안 잡히고 실부하에서 터진다
- 인증·결제·세션처럼 틀리면 비용이 큰 영역—느리고 편집증적으로, 직접
- 기능이 길어질수록 쌓이는 맥락—무엇을 쓰고 무엇을 쓰지 않는지, 어떤 결정이 이미 내려졌는지를 AI는 잊는다
Anthropic이 설계 원칙을 바꾸는 이유
AnthropicClaude 엔지니어링 블로그(#104)는 이 맥락에서 중요한 통찰을 제공한다. AI는 '만들어지는 것(built)'이 아니라 '자라는 것(grown)'이다. harness에 인코딩된 '모델이 못 하는 것'에 대한 가정은, 모델이 진화할수록 stale해진다. Sonnet 4.5에서 'context anxiety'로 조기 종료하던 행동이 Opus 4.5에서 사라진 것처럼—매 모델 업그레이드마다 기존 가정을 재검증해야 한다.
이것은 개인 워크플로우에도 그대로 적용된다. 세 달 전에 AI에게 맡기지 않았던 영역이 지금은 맡길 수 있게 됐을 수 있다. 반대로 여전히 직접 짜야 하는 영역은 더 명확해졌을 것이다. AI 워크플로우는 한 번 설계하고 끝나는 게 아니라, 모델이 바뀔 때마다 재평가해야 하는 살아있는 구조다.
앞으로의 전망
실험자는 Claude Code를 그만두지 않았다. 오히려 더 많이 쓰되, 방식을 바꿨다. 기능 전체가 아닌 머릿속에 한 번에 담을 수 있는 크기의 조각으로 나눠 맡긴다. 모든 커밋 라인을 읽는다—훑지 않고. 아키텍처 결정, 네이밍 컨벤션, 사용하는 것과 사용하지 않는 것을 단일 문서에 정리해 매 프롬프트에 참조한다.
Claude Code가 없었다면 일주일 안에 완성되지 않았을 기능이 실제로 배포됐다. 그건 사실이다. 하지만 그 과정에서 드러난 것은 AI 에이전트의 가치가 '속도'보다 '범위'에 있다는 점이다. 빠르게 첫 형태를 만들고, 개발자는 판단이 필요한 곳에 집중력을 아끼는 구조—그 설계 자체가 지금 프론트엔드 개발자에게 요구되는 진짜 역량이다.