AI가 코드를 짜는 건 이미 됐다. 그 다음이 문제다
2025년 기준으로 AI가 코드를 생성한다는 사실 자체는 더 이상 차별점이 아니다. Claude Code를 쓰든, Copilot을 쓰든, 어떤 팀이든 AI 어시스턴트 하나쯤은 붙어 있다. 그런데 프로덕션 AI 시스템을 2년간 디버깅해온 한 엔지니어의 고백이 현장의 온도를 정확히 짚는다. "가장 아픈 실패는 명백한 실패가 아니다. 모니터링이 전부 '정상'이라고 말하는데, 실제로는 아무 일도 일어나지 않고 있는 상태가 진짜 문제다."
코드 생성 속도는 올라갔다. 그런데 그 코드가 프로덕션에서 실제로 제대로 작동하고 있는지를 확인하는 루프는 여전히 구멍투성이인 팀이 많다. 이 글은 그 루프를 설계하는 데 필요한 세 가지 실천을 묶어서 본다.
1단계: Spec이 먼저다—Claude Code는 '지시받는 속도'가 빠른 것이다
dev.to에 연재 중인 MetaBulkify 빌드 로그는 Claude Code 활용법에 대한 가장 솔직한 현장 보고서 중 하나다. 저자는 솔로 개발자로 Claude Code를 쓰지만, 그 방식이 흥미롭다. 프롬프트로 "앱 만들어줘"를 던지는 게 아니라, 200줄 이상의 스펙 문서를 먼저 작성하고 그걸 Claude Code에 넘긴다.
스펙에는 데이터 모델, 에지 케이스, 에러 핸들링, 보안 고려사항, 실제 UI 컴포넌트 배치까지 들어간다. 그 결과는 인상적이다. 2~3시간의 스펙 작성 + Claude Code의 20분 구현 + 1시간 리뷰 = 총 4시간. 수동으로 코딩했다면 2~3일 걸릴 피처가 4시간 안에 끝난다.
그런데 저자가 강조하는 건 속도가 아니다. 빌링 시스템 하나에서만 리뷰를 세 라운드 돌렸고, 버그 세 개를 잡았다. 쿼터 우회 가능한 집계 기준 불일치, Cloud Tasks 재시도로 인한 중복 카운팅, 실제로 강제되지 않는 소프트 캡. 세 개 모두 코딩 에러가 아니라 스펙이 틀렸거나 불완전해서 생긴 프로덕트 결정의 오류였다.
이게 핵심이다. Claude Code는 시키는 대로 빠르게 만든다. 틀린 걸 시키면 틀린 걸 빠르게 만든다. Spec-driven 개발의 진짜 가치는 AI 속도를 올리는 게 아니라, AI에게 넘기기 전에 팀이 먼저 판단을 강제하는 구조를 만드는 것이다.
2단계: MCP로 테스트를 루프에 통합하라
Spec으로 짜고 리뷰했다면, 다음은 자동화된 검증 루프다. TestSprite MCP는 이 맥락에서 주목할 만한 도구다. Claude Code, Cursor, VSCode 등 주요 IDE에 MCP 서버로 붙어서, 채팅창에 "이 프로젝트 테스트해줘"라고 입력하는 것만으로 테스트 플랜 생성 → 클라우드 실행 → 리포트 생성 → 버그 수정 제안까지의 루프를 자동화한다.
실용적인 포인트는 진입 장벽이 낮다는 것이다. PRD가 완성되지 않아도 된다. 한 문단짜리 앱 설명만 있어도 TestSprite AI가 정규화된 PRD를 만들어 테스트 케이스를 뽑는다. Code Diff 스코프를 쓰면 커밋되지 않은 변경분만 타겟해서 빠른 이터레이션 검증도 가능하다.
설치는 Claude Code 기준으로 프로젝트 디렉토리에서 claude mcp add TestSprite --env API_KEY=your_api_key -- npx @testsprite/testsprite-mcp@latest 한 줄이다. 테스트 결과는 Functional, UI/UX, Security, Performance 카테고리로 분류되고, 실패한 테스트에 대해서는 자동 픽스 제안까지 나온다.
AI-First 워크플로우에서 MCP 기반 테스트 도구가 중요한 이유는 단순히 자동화 때문이 아니다. AI가 생성한 코드를 AI가 검증하는 루프를 IDE 안에 닫아버릴 수 있기 때문이다. Spec → 생성 → 검증이 하나의 컨텍스트 안에서 돌아가면, 사람이 개입해야 하는 지점이 명확해진다.
3단계: Silent Failure 패턴을 루프 설계에 미리 박아라
Spec이 좋고 테스트도 통과했다. 그런데 프로덕션에서 조용히 망가지는 케이스가 있다. 2년간 AI 시스템을 디버깅해온 엔지니어가 dev.to에 정리한 5가지 Silent Failure 패턴은 AI-First 팀이 워크플로우 설계 단계에서 반드시 반영해야 할 체크리스트다.
Exit code zero, 빈 출력. 크론잡이 성공으로 끝났는데 결과물이 없다. if rows is None은 체크하지만 rows = []는 통과시키는 코드가 원인이다. 출력 길이가 히스토리 중앙값의 30% 미만이면 실패로 처리하는 별도 체크가 필요하다.
'이번 한 번만' 훅 비활성화의 영구화. 핫픽스 때 검증 훅을 끄고 재활성화를 잊는 패턴. 6개월 뒤 감사에서 발견된다. 모든 훅 비활성화에 만료일과 담당자를 강제하는 예외 레지스트리가 답이다.
에이전트 액션 버짓 누수. max_actions=20으로 설정했는데 중첩 tool call이 내부에서 카운트를 우회한다. LLM 비용이 5배 뛰고 나서야 발견된다. 버짓 차감은 가장 안쪽 call site에서, 0이 되면 하드 스톱이어야 한다.
Tool argument 의미론적 검증 공백. JSON 스키마는 통과했지만 LLM이 user_id="the user mentioned in the conversation"을 넘기는 경우. 스키마 검증만으로는 부족하다. UUID 패턴 매칭, 데이터베이스 존재 여부 확인 같은 의미론적 검증 레이어가 별도로 필요하다.
이 패턴들의 공통점은 알람이 울리지 않는다는 것이다. 에러 로그에도 없고, 메트릭도 정상이다. 수 주 동안 프로덕션에 머문다.
루프를 닫는 것이 팀의 설계 역량이다
세 소스를 묶어보면 하나의 구조가 보인다. Spec으로 판단을 강제하고 → MCP로 검증을 자동화하고 → Silent Failure 패턴을 루프 설계에 미리 박는다. 이게 AI-First 개발의 실질적인 3단 루프다.
Claude Code의 속도는 실재한다. TestSprite MCP의 자동화는 실재한다. 그런데 그 속도와 자동화가 프로덕션 신뢰성으로 연결되려면, 루프를 설계하는 사람이 있어야 한다. AI가 빠르게 짤수록, 팀이 설계해야 할 검증 구조의 밀도도 함께 올라간다.
스펙을 먼저 쓰고, MCP를 IDE에 붙이고, Silent Failure 체크리스트를 CI에 넣는 것—이 세 가지는 내일 당장 실행할 수 있다. 그리고 그게 AI-First 팀과 AI 도구만 도입한 팀의 차이를 만든다.