AI 코딩 도구로 프로토타입을 빠르게 뽑아내는 건 이제 그렇게 어렵지 않다. 문제는 그다음이다. 사용자가 늘고, 트래픽이 쌓이고, 클라우드 청구서가 올라오기 시작할 때—그제서야 AI가 만든 코드의 민낯이 드러난다. '동작하는 코드'와 '프로덕션을 버티는 코드' 사이의 간극을 메우는 건 결국 개발자의 몫이다.
조용히 새고 있던 비용과 성능
dev.to에 공개된 한 개발자의 사례는 이 간극을 적나라하게 보여준다. AI로 빌드한 브라우저 게임 포털이 사용자를 모으기 시작하자, Firebase 청구서가 눈에 띄게 올라갔다. 하루 50,000건이었던 Firestore 무료 한도를 하루 1,000,000건으로 초과하는 상황이 됐다. 체감 성능도 점점 나빠졌다. 처음엔 그냥 넘어갔지만, 유저가 늘수록 문제는 복리처럼 불어났다.
흥미로운 건 이 개발자가 원인을 '추측'으로 찾지 않았다는 점이다. Google Cloud Billing Reports로 비용 발생 지점을 추적하고, Firestore Query Insights로 읽기가 집중된 컬렉션을 파악하고, API 레이턴시 메트릭으로 느린 엔드포인트를 특정했다. 관찰성(Observability) 도구를 먼저 세팅하고, 데이터로 범위를 좁힌 다음, 그 결과를 AI 코딩 어시스턴트에게 다시 던져 원인을 함께 분석했다. 이 순서가 핵심이다.
AI가 만들어낸 세 가지 패턴의 실패
드러난 문제는 세 가지였다. 첫째는 야간 클린업 잡의 N+1 쿼리 패턴이었다. AI가 작성한 코드는 모든 프로필을 순회하며 각각 서브쿼리를 날리는 구조였다. 프로필이 500개면 쿼리도 501번. 실제로 정리할 데이터가 30건뿐이어도 마찬가지였다. 해결책은 collectionGroup 쿼리로 조건에 맞는 문서만 직접 타기팅하는 것—읽기 횟수가 501회에서 30회로 줄었다.
둘째는 '한 엔드포인트가 너무 많은 일을 하는' 문제였다. 프로필 API 하나가 불필요한 서브컬렉션 데이터를 항상 함께 로딩하고, 매 요청마다 유지보수 태스크를 실행하고, 중복 요청을 걸러내지 못했다. 여러 React 컴포넌트가 거의 동시에 같은 프로필 데이터를 요청해도 각각 독립적으로 백엔드를 때렸다. 인증 토큰도 매번 새로 발급했다. 이런 비효율들이 쌓여 하나의 느리고 비싼 엔드포인트가 됐다. 레이지 로딩으로 필요한 데이터만 요청하고, ETag 기반 캐싱으로 중복 응답을 막고, 유지보수 작업을 lastMaintenanceAt 타임스탬프로 하루 한 번으로 제한하면서 상황이 크게 개선됐다.
셋째는 씨앗 생성기(Random Seed Generator)였다. 겉으로는 단순해 보이는 기능이지만, 매 요청마다 Firestore에서 여러 문서를 읽어 가중치를 계산하는 구조였다. 하루 200명의 사용자가 씨앗을 요청하면 그것만으로 하루 50,000건의 읽기가 발생했다. 무료 한도를 통째로 잡아먹는 숨겨진 구멍이었다.
AI로 빠르게 만들수록, 검증 루프가 더 중요해진다
이 사례가 보여주는 건 단순히 'AI 코드는 느리다'가 아니다. AI는 '동작하는 최초의 구현'을 빠르게 만드는 데 탁월하다. 하지만 그 구현이 실제 트래픽 아래에서 어떻게 동작하는지는 별개의 문제다. N+1 쿼리, 과도한 데이터 로딩, 캐싱 부재—이런 패턴들은 작은 스케일에서는 보이지 않다가 사용자가 늘면 갑자기 폭발한다.
여기서 AI 워크플로우를 다시 설계할 필요가 생긴다. Claude로 6주 만에 계약서 분석 앱을 프로덕션까지 올린 사례(dev.to, fynPrint)를 보면, 프롬프트 설계와 API 응답 구조화에 많은 반복이 필요했음을 솔직하게 밝힌다. 특히 Claude에게 JSON 출력을 안정적으로 뽑아내기 위해 필드명·타입·예시를 명시하고, 불필요한 토큰을 줄이는 지침을 추가하는 등 세밀한 조율 과정이 있었다. 빠른 프로토타이핑은 AI가 했지만, 신뢰할 수 있는 프로덕션 품질은 사람이 검증하고 다듬는 과정에서 나왔다.
멀티 AI 도구를 오케스트레이션하는 오픈소스 CLI인 tasuki(dev.to, 0xkohe)의 접근도 비슷한 맥락을 건드린다. Claude Code, Codex CLI, GitHub Copilot CLI를 rate limit 상황에 따라 자동으로 전환하며 사용하는 이 도구는, 단일 AI 도구에 의존하는 대신 각 도구의 강점을 전략적으로 조합한다. 중요한 건 도구가 바뀌어도 컨텍스트가 .tasuki/handoff.md로 이어진다는 점—워크플로우의 연속성을 의도적으로 설계한 결과다.
프론트엔드 개발자가 가져야 할 검증 루프
세 사례를 합치면 하나의 실용적인 흐름이 보인다. AI로 빠르게 초안을 만들고 → 관찰성 도구로 실제 동작을 측정하고 → 병목을 데이터로 특정한 다음 → AI 어시스턴트와 함께 개선하는 루프다. 이 루프에서 개발자가 담당하는 부분은 '측정하고 질문을 설계하는 것'이다. 어떤 메트릭을 볼 것인지, 어떤 데이터를 AI에게 넘길 것인지, 어떤 트레이드오프를 선택할 것인지—이 판단들은 AI가 대신할 수 없다.
프로덕션 이전에 잡아야 할 체크리스트
AI가 생성한 코드를 프로덕션에 올리기 전, 최소한 이 세 가지는 확인해야 한다. 데이터베이스 쿼리 패턴: N+1 문제가 숨어 있지 않은지, 항상 필요 이상의 데이터를 가져오지 않는지. 캐싱 레이어: 동일한 데이터를 반복 요청하는 경로가 있는지, 클라이언트·서버 양쪽에 적절한 캐싱이 설계되어 있는지. 백그라운드 잡의 스케일링: 사용자 수에 비례해서 쿼리가 늘어나는 구조가 아닌지. 이 세 가지는 AI가 가장 자주 놓치는 패턴이기도 하다.
결국 남는 것은 '질문하는 능력'
AI 도구가 빨라질수록, 개발자의 역할은 '코드를 직접 쓰는 것'에서 '올바른 질문을 설계하고, 결과를 검증하고, 실패를 구조적으로 잡는 것'으로 이동하고 있다. 프로덕션에서 터지기 전에 문제를 잡는 능력—그건 AI가 아직 스스로 갖추지 못한, 개발자의 고유한 영역이다.