AI 하나로는 부족하다: '자기 채점' 문제의 구조적 한계
스포티파이 CTO 구스타프 쇠데르스트룀은 최근 실적 발표에서 "가장 경력 많은 최고의 개발자들이 12월 이후 단 한 줄의 코드도 직접 작성하지 않았다"고 밝혔습니다. 그들은 코드를 '생성하고 감독하는 일'만 하고 있다는 겁니다. AI가 코드를 쓰는 시대는 이미 왔습니다. 문제는 그 코드를 누가 검증하느냐입니다.
2년간 AI 코딩 어시스턴트를 실전 투입해온 개발자 yw1975는 dev.to에 공유한 글에서 이 문제를 정확히 짚습니다. Claude Code는 컨텍스트가 길어지면 에러 핸들링을 빼먹고, Codex는 과도한 추상화에 빠지며, Cursor는 멀티파일 작업에서 맥락을 잃습니다. 모델마다 실수 패턴이 다르지만 공통점은 하나 — 단일 에이전트는 자기 실수를 스스로 잡지 못한다는 것입니다. "자기 시험지를 자기가 채점하는 격"이라는 그의 표현이 핵심을 찌릅니다.
듀얼 에이전트 워크플로우: 켄트 벡의 페어 프로그래밍을 AI로 재현하다
해법은 의외로 오래된 원칙에서 왔습니다. 켄트 벡이 1990년대 XP(익스트림 프로그래밍)에서 정립한 페어 프로그래밍 — 한 명이 코드를 쓰고, 한 명이 실시간으로 검증하는 구조를 AI 에이전트 두 개로 재현한 겁니다. Claude Code가 코드를 작성하면 Codex가 리뷰하고, 양쪽이 합의할 때까지 턴을 반복합니다. 개발자는 중간에서 테크 리드로서 아키텍처 결정과 스코프 조정만 담당합니다.
이 워크플로우의 실전 검증 결과가 인상적입니다. 15,000 스타를 받은 오픈소스 Electron 프로젝트에 듀얼 에이전트가 작성한 PR이 메인테이너의 3차례 피드백을 거쳐 머지됐습니다. race condition 가드, 에러 로깅, 구현 불일치까지 — 메인테이너가 지적한 3가지 이슈를 두 에이전트가 자체적으로 수정하고 테스트(133/133 통과)를 완료했습니다. 기고자 본인은 TypeScript를 모른다고 합니다. 코드를 한 줄도 직접 쓰지 않았습니다.
스포티파이의 'Honk'과 현장의 교훈: 속도만큼 중요한 것은 리뷰 규율
스포티파이는 Claude Code 기반 내부 시스템 'Honk'을 통해 Slack에서 버그 수정을 요청하면 출근 전에 프로덕션 배포까지 끝나는 루프를 만들었습니다. 2025년 한 해 동안 50개 이상의 기능을 추가한 결과물은 확실히 인상적입니다. 하지만 AI 타임즈 보도에서도 언급되듯, "바이브 코딩으로 업무가 줄어드는 것이 아니라 더 많은 인지 노동 부담이 따른다"는 지적은 무시할 수 없습니다.
듀얼 에이전트 방식이 이 문제에 구조적 답을 줍니다. 리뷰를 '의지력'이 아닌 '시스템'에 맡기는 겁니다. 새벽 2시에 "이 정도면 괜찮겠지" 하고 리뷰를 건너뛰는 바로 그 순간이 사고로 이어진다는 건, 코드 리뷰 문화가 있는 팀이라면 누구나 공감할 겁니다. 자동화된 교차 검증 루프는 개발자의 피로와 무관하게 일정한 품질 기준선을 유지해줍니다.
실무 팁: Cursor 규칙 관리의 함정
AI-First 워크플로우를 운영하려면 도구의 동작 방식도 정확히 알아야 합니다. dev.to의 한 개발자가 실험으로 밝혀낸 사실이 주목할 만합니다. Cursor Agent 모드에서 .cursorrules 파일은 아예 로드되지 않습니다. 9회 테스트 중 규칙 준수율 0%. 반면 .cursor/rules/*.mdc 파일에 alwaysApply: true를 설정하면 9회 중 9회 100% 준수. 팀에서 Cursor를 쓰고 있다면 지금 당장 규칙 파일 형식을 점검해야 합니다.
개발자는 사라지지 않는다. 역할이 바뀔 뿐이다.
"AI가 1,000줄을 쓰고, 내가 3줄에서 버그를 찾았다" — 또 다른 dev.to 기고자의 경험담은 AI 시대 개발자의 핵심 역량을 압축합니다. 부동소수점 계산 오류 3줄이 결제 시스템에서 $50K 손실을 일으킨 사례처럼, AI는 해피 패스를 빠르게 구현하지만 비즈니스 맥락, 엣지 케이스, 보안 취약점은 여전히 인간의 판단 영역입니다.
듀얼 에이전트 워크플로우의 기고자도 한계를 솔직히 인정합니다. 두 AI가 잘못된 설계에 합의하는 '상호 고무도장' 문제, 수정이 새 이슈를 만드는 핑퐁 루프, 컨텍스트 윈도우 손실. 인간 중재자는 옵션이 아니라 필수라는 그의 결론은 AI-First가 AI-Only를 의미하지 않는다는 점을 명확히 합니다.
전망: AI-First 팀이 재설계해야 할 것
업계의 AI 코딩 논의는 지금까지 '생성 속도'에 집중해왔습니다. 하지만 진짜 질문은 다릅니다. "누가 검증하는가?" 스포티파이처럼 Slack에서 배포까지 자동화한 팀이든, 듀얼 에이전트로 오픈소스에 기여하는 개인 개발자든, 공통적으로 도달하는 결론은 같습니다 — AI 생성 코드에도 구조화된 리뷰 규율이 필요하고, 그 규율을 시스템으로 만들어야 한다는 것입니다.
저는 팀원들에게 이렇게 말합니다. "AI는 우리 팀에서 가장 빠른 주니어 개발자야. 놀라울 만큼 빠르고, 때로는 똑똑하지만, 절대 혼자 프로덕션에 코드를 넣게 두면 안 돼." 듀얼 에이전트 워크플로우는 이 철학을 시스템으로 구현한 첫 번째 실용적 패턴입니다. 지금 여러분의 팀에서 AI가 생성한 코드가 어떤 검증 과정을 거치는지 — 그것이 AI-First 팀 리빌딩의 출발점입니다.