30일 동안 코드를 100% AI에게 맡겨봤다 — 무엇이 무너졌나
한 개발자가 30일간 애플리케이션 코드를 직접 타이핑하지 않고 AI에게 전부 맡겨 실제 SaaS를 출시했다. 그 과정에서 기록한 9번의 '실패 지점'이 AI 코딩의 한계선을 보여준다.
I let AI write 100% of my code for 30 days. Here's what broke.
Not "AI-assisted." Not "copilot suggestions I edited." I mean I made a rule: for 30 days, I don't...
개요 #
"AI 보조"도 아니고 "코파일럿 제안을 손봤다"도 아니다. 개발자 Info Inlet은 30일 동안 애플리케이션 코드를 한 줄도 직접 타이핑하지 않기로 했다. 설명하고, 검토하고, 승인하는 것만 자기 몫으로 남겼다.
결과물은 실제 제품이다. 인증, Stripe 결제, 대시보드, 공개 API를 갖춘 소형 SaaS를 이 방식으로 만들어 프로덕션에 올렸다. 동작한다. 그리고 그 과정에서 "이제 AI가 다 짜준다"는 기대가 어디까지 버티고 어디서 조용히 무너지는지를 확인했다.
홍보도 비관론도 아닌 현장 기록에 가깝다.
실험 규칙 #
스스로를 속이지 않기 위해 네 가지 규칙을 정했다.
- 애플리케이션 로직은 손으로 쓰지 않는다. 프롬프트를 넣고 AI가 쓴다.
- 모든 줄을 읽고 거부하고 다시 요청할 수는 있다. 다만 에디터에서 직접 고치는 건 금지.
- 설정, 시크릿, 대시보드에서 버튼 누르는 작업은 사람 몫이다(애초에 AI가 못 한다).
- 한 시간 넘게 막히면 "break"로 기록하고 직접 코드를 쓴다.
30일이 끝났을 때 기록된 break는 9번. 흥미로운 대목은 전부 여기에 있다.
Photo by Lukas Blazek on Pexels
놀랄 만큼 잘 된 것들 #
먼저 기계 쪽 손을 들어줘야 할 부분부터. 본인도 예상 못 했다고 한다.
신규 프로젝트 스캐폴딩은 사실상 해결됐다. "Next.js 앱에 Postgres, Drizzle, 인증 붙여서 세팅해줘" — 한 번에, 정확하게 나왔다. 프로젝트 초반 40%는 지금껏 뭘 만들 때보다 빨랐다.
보일러플레이트는 틀리는 법이 없다. CRUD 엔드포인트, 폼 검증, Zod 스키마, 정렬과 페이지네이션 붙은 테이블 컴포넌트. 쓰기 싫어하는 종류의 코드를 매번 완벽하게 뽑아냈다. 지적할 게 없었다.
러버덕으로는 최고였다. "이 쿼리 왜 느리지?"라고 물었더니 혼자 고민해서 도달했을 답보다 나은 답이 돌아왔다. 빠진 인덱스와 N+1을 한 호흡에 짚었다.
첫 주에는 "개발자는 이제 필요 없다"는 글을 쓰게 되겠구나 싶었다고 한다. 그리고 2주 차가 왔다.
무너진 지점 — 9번의 break #
break 1~3: 시스템 전체를 머릿속에 담지 못한다 #
AI는 눈앞의 파일에는 탁월하고 세 폴더 건너에 있는 파일에는 눈이 멀어 있다. 이미 있는 formatCurrency 헬퍼를 모른 채 두 번째 버전을 태연히 만들었다. 이미 만들어둔 미들웨어를 놔두고 인증 체크를 인라인으로 다시 구현했다. 새 모듈에 미묘하게 다른 User 타입을 도입했다.
이건 버그가 아니다. 전부 컴파일되고 전부 통과한다. **아키텍처 드리프트(architecture drift)**다. 그리고 드리프트는 일주일을 잡아먹는 날이 오기 전까지 보이지 않는다.
AI는 국소적으로 최적화한다. 시스템 전체의 일관성은 여전히 사람의 일이다.
break 4~5: 그럴듯하게, 자신 있게, 틀린 코드를 쓴다 #
가장 무서웠던 실패는 크래시가 아니었다. 멀쩡해 보이고 해피 패스에서는 잘 도는 코드였다.
AI가 짠 결제 웹훅 핸들러는 Stripe 이벤트를 저장하기 전에 먼저 ack을 보냈다. 테스트에서는 완벽하게 돈다. 프로덕션에서 DB가 한 번 튀면? 결제한 고객이 권한도 기록도 없는 상태가 된다. 필자는 예전에 똑같은 걸로 데인 적이 있어서 잡아냈다. AI 출력물을 그대로 복사한 주니어라면 못 잡았을 것이다. 잠을 설치게 만드는 대목이 여기다.
break 6: 자기가 짠 코드를 디버깅하는 건 절망의 루프 #
AI가 보지 못하는 지점에서 문제가 터지면, 고쳐달라고 해봐야 수정이 아니라 변경이 나온다. 함수를 자신 있게 다시 쓰고, 버그가 사라졌다고 장담하고, 두 프롬프트 뒤에 같은 버그를 다시 집어넣는다. 직접 디버거에 들어가서 상태를 이해할 수 없었다면 영원히 돌았을 것이다. 한 달 중 시간을 가장 많이 잡아먹은 구간이다.
Photo by Lucas Andrade on Pexels
break 7~8: 취향, 그리고 "아니, 덜"이라고 말하기 #
설정 페이지를 요청했더니 아무도 원하지 않은 옵션 14개를 얹어줬다. 에러 처리를 요청했더니 전부 try/catch로 감싸고 에러를 삼켜버렸다. AI의 본능은 더하는 쪽이다. 무엇을 빼야 하는지 아는 것 — 엔지니어링에서 제품 설계에 해당하는 그 부분 — 은 아예 없다.
break 9: 마지막 10%가 여전히 90%의 일이다 #
"데모는 됩니다" 상태까지 일주일이 걸렸다. "새벽 2시에 진짜 사용자가 이상한 짓을 해도 버팁니다"까지 나머지 3주가 걸렸다. 엣지 케이스, 레이스 컨디션, 빈 상태, 에러 상태, 더블 클릭했을 때의 상태. AI는 물어봐야 해준다. 무엇을 물어야 하는지 아는 것, 그게 곧 일이다.
불편한 결론 #
30일 뒤 필자가 실제로 믿게 된 것은 이렇다.
AI는 나를 대체하지 않았다. 내가 주니어에게 넘기던 일을 대체했다. 스캐폴딩, 보일러플레이트, 초안. 주니어가 배우는 일이 정확히 그 일이다. 아무도 값을 매기지 않는 진짜 문제가 여기 있다. AI가 엔트리 레벨 작업을 다 해버리면 다음 시니어는 어디서 나오나? 1만 시간은 건너뛸 수 없다. 그 시간을 어디에 쓰느냐를 옮길 수 있을 뿐이다.
매일같이 필요했던 기술은 코드를 쓰는 능력이 아니었다.
- 받은 코드가 미묘하게 틀렸다는 걸 알아채기
- 무엇을 만들지 않을지 판단하기
- 시스템 전체를 머릿속에 들고 있으면서 드리프트를 잡아내기
전부 시니어의 기술이다. AI가 위계를 평평하게 만든 게 아니라, 꼭대기의 가치를 더 키우면서 거기로 올라가는 사다리를 걷어찼다는 뜻이다.
실제로 바꾼 것 #
AI 사용을 줄이지는 않았다. 지금도 타이핑은 100% AI가 한다. 대신 그 주변에 가드레일을 세웠다. 하나하나가 위의 break와 짝을 이룬다.
- 코드를 쓰는 주체와 리뷰하는 주체를 절대 같게 두지 않는다. diff를 반박하도록 지시받은 별도 리뷰어가, 작성자라면 그냥 통과시킬 "그럴듯하지만 틀린" 코드를 잡아낸다.
- 모델이 볼 수 없는 영향 범위를 볼 줄 아는 사람 없이는 머지하지 않는다.
- "컴파일되고 테스트 통과함"은 리뷰의 시작이지 끝이 아니다. 모델은 자기 잘못된 멘탈 모델에 동의하는 테스트를 쓴다.
작성자는 여기, 회의론자는 저기, 머지 버튼은 사람이 — 이 분리 덕분에 타이핑을 기계에 넘기고도 잠을 잘 수 있었다는 설명이다. 필자는 자신이 만드는 제품 xenition도 같은 구조로 개발한다고 밝혔다. 일을 하는 에이전트, 그것을 무너뜨리려 드는 다른 에이전트, 결정을 책임지는 사람.
다시 할 것인가 #
프로토타입이라면? 당장 다시 한다. 스캐폴딩을 손으로 짜는 일로는 돌아가지 않겠다고 했다.
프로덕션이라면? 타이핑은 100% AI에게, 사고는 0%. 타이핑은 애초에 어려운 부분이 아니었다. 그렇게 느껴졌을 뿐이다.
원문은 마지막에 질문 하나를 던진다. AI가 주니어의 일을 가져간다면, 다음 세대 시니어는 어떻게 키울 계획인가. "알아서 되겠지"는 더 이상 답이 아니라는 것이 필자의 입장이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.