문제는 '어떤 도구가 최고냐'가 아니다
AI 코딩 도구 선택 논쟁이 반복되는 이유가 있다. 비교 기준이 틀렸기 때문이다. GitHub Copilot, Claude Code, Cursor, Windsurf, Aider—이 도구들은 모두 코드에 손을 댄다. 하지만 출발점이 다르고, 실패 방식도 다르다. 같은 카테고리에 놓고 점수를 매기는 순간, 비교는 무의미해진다.
워크플로우 유형별 도구 매핑
실전에서 유용한 질문은 하나다. "내가 지금 해결하려는 작업이 어디서 시작되는가?" dev.to에 올라온 30일 비교 실험과 프론트엔드 에이전트 선택 가이드를 종합하면, 워크플로우 유형별 매핑은 다음과 같이 정리된다.
- 에디터 루프 안에서 일하는 개발자: Cursor 또는 GitHub Copilot. 에디터 에르고노믹스가 생산성을 결정한다. Cursor의 Composer는 멀티파일 변경을 계획하고 실행하는 능력이 현재 가장 앞서 있고, Copilot은 IDE 통합 깊이와 낮은 레이턴시가 강점이다.
- 터미널 네이티브 엔지니어링: Claude Code. 전체 코드베이스를 읽고, 명령을 실행하고, 여러 파일을 동시에 수정하며, 깃 워크플로우까지 처리한다. SSH 환경이나 tmux에서도 동작한다. 단, 사용량에 따른 API 비용이 예상 밖으로 나올 수 있다.
- 빈 화면에서 시작하는 프로토타입: v0 또는 Bolt.new. 인상적인 첫 초안을 빠르게 뽑아낸다. 단, 프로덕션 투입 전 반드시 리뷰가 필요하다.
- 예산 제약이 있는 팀의 CLI 옵션: Aider. MIT 라이선스 오픈소스로, Ollama를 통한 로컬 모델까지 지원한다. API 비용만 부담하면 되고, 월 $5~$20 수준으로 운용 가능하다.
프론트엔드는 별도 기준이 필요하다
프론트엔드 작업은 백엔드 리팩터링과 다르다. 테스트가 통과해도 UI가 '이상해 보일' 수 있다. 기존 프로덕션 앱에서 AI 코딩 에이전트를 쓸 때 실제로 따져야 할 기준은 다음 다섯 가지다.
- 기존 코드 인식: 실제 컴포넌트와 프로젝트 컨벤션을 재사용하는가
- 디자인 시스템 보존: 타이포그래피, 스페이싱, 컬러 토큰을 유지하는가
- 반응형 검증: 현재 뷰포트만이 아니라 모바일/데스크톱을 모두 확인하는가
- 접근성 기본값: 레이블, 포커스, 키보드 사용, 대비를 깨뜨리지 않는가
- 리뷰 가능한 diff: 머지 전에 변경 내용을 개발자가 정확히 확인할 수 있는가
코드 생성 성능이 높아도 리뷰 루프를 숨기는 도구는 프로덕션 프론트엔드에 적합하지 않다. 가장 좋은 프론트엔드 AI 도구는 리뷰 루프를 보존하는 도구다.
도구를 골랐다면: AGENTS.md를 쓰레기통으로 만들지 마라
도구 선택 이후에 팀이 반드시 해야 할 작업이 있다. AI 에이전트의 행동을 규정하는 규칙 파일—AGENTS.md, CLAUDE.md, .cursorrules—을 제대로 설계하는 것이다. 그리고 이 작업을 대부분의 팀이 망친다.
dev.to의 "AGENTS.md is Not a Junk Drawer"는 이 문제를 정확하게 짚는다. 규칙 파일은 시작할 때 한 페이지다가 6개월 뒤 14페이지가 된다. 팀원이 불편할 때마다 규칙을 추가하고, 아무도 삭제하지 않는다. 에이전트는 파일 전체를 컨텍스트에 로드하고, 대부분을 무시한다. 팀은 여전히 유용하다고 착각한다.
규칙 파일의 유일한 목적: 에이전트의 행동을 바꾸는 것
규칙 한 줄이 존재하려면 딱 하나의 조건을 충족해야 한다. 에이전트의 행동을 실제로 바꾸는가. 바꾸지 않는다면 컨텍스트 공간만 낭비한다.
규칙을 추가하기 전에 두 가지를 물어라.
- 이 규칙이 없으면 에이전트가 무엇을 다르게 하는가? 답이 "똑같이 한다"면 삭제하라.
- 에이전트가 취해야 할 구체적인 행동은 무엇인가? 동사 없이 원칙만 있다면 규칙이 아니라 디자인 문서다.
규칙 파일에 넣을 것: 타입 시스템이 표현하지 못하는 레이어링 경계, 새 파일·모듈·테스트의 네이밍 컨벤션, 동일 기능의 라이브러리가 여럿일 때 무엇을 쓸지, 에러 구조화 방식, 테스트를 어느 파일에 어떤 이름으로 추가할지.
규칙 파일에 넣지 말 것: 린터·포매터·타입 체커가 이미 강제하는 것, 모든 코드베이스에 해당하는 일반론(테스트를 작성하라, 시크릿을 커밋하지 마라), 동사 없는 원칙, 아무도 경위를 기억하지 못하는 2년 전 사고에서 비롯된 규칙.
삭제가 규율이다
규칙 추가는 쉽다. 삭제가 기율이다. 주 1회 혹은 최소 월 1회, 누군가가 규칙 파일을 처음부터 끝까지 읽고 각 줄에 질문을 던져야 한다. "이걸 삭제하면 에이전트가 달라지는가?" 정직한 답이 '아니오'라면 그 줄은 지운다. 린터로 이관된 규칙, 더 최신 규칙과 충돌하는 규칙, 아무도 출처를 5초 안에 설명 못 하는 규칙—모두 삭제 대상이다.
건강한 규칙 파일은 작다. 팀의 의견이 줄어서가 아니라, 린터·테스트·타입이 강제할 수 있는 것들이 제자리로 이동했기 때문이다. 수십 줄짜리 규칙 파일이 실제로 에이전트 행동을 바꾸고, 수백 줄짜리 파일은 에이전트가 신호를 찾지 못해 엉뚱한 것에 주의를 기울이는 결과를 낳는다.
팀 도입의 실전 순서
결국 AI 코딩 도구의 팀 도입은 세 단계로 구성된다.
1단계: 워크플로우 유형별 도구 매핑. "무엇이 최고냐"가 아니라 "우리 팀의 작업이 어디서 시작되는가"를 기준으로 도구를 고른다.
2단계: 리뷰 루프 설계. 도구가 무엇이든, 브랜치 생성 → 단일 변경 요청 → diff 검토 → 빌드·타입체크·테스트·린트 → 뷰포트 확인 → 개발자 승인이라는 워크플로우는 협상 불가 항목이다. 이 루프를 숨기는 도구는 아무리 생성 성능이 좋아도 팀에 부채를 쌓는다.
3단계: 규칙 파일 유지보수 체계 구축. 처음부터 완전한 파일을 만들려 하지 마라. 빈 파일 맨 위에 한 줄만 쓰고 시작하라. "이 파일의 규칙은 에이전트의 행동을 바꿔야 한다. 바꾸지 않는다면 디자인 문서나 린터 설정으로 이동하라." 이 한 줄이 이후 모든 추가를 규율한다.
도구 선택보다 규칙 설계가 더 오래간다
Cursor vs Claude Code 논쟁은 내년에도 반복될 것이다. 어떤 도구가 우위를 점하든, 팀이 그 도구를 어떻게 운용하느냐가 실질적 생산성을 결정한다. 규칙 파일이 쓰레기통이 되는 팀과 주기적으로 가지치기하는 팀의 차이는 6개월 뒤 AI 산출물의 일관성과 리뷰 비용에서 드러난다. 도구 선택에 쓰는 에너지의 절반만 규칙 설계와 유지보수에 써도, 팀의 AI-First 워크플로우는 훨씬 오래 버틴다.