도구를 고를 때 우리가 던지는 질문은 오랫동안 비슷했다. 팀이 이미 아는 기술인가, 문서가 충분한가, 5년 뒤에도 유지보수될 것인가. 그런데 최근 두 가지 실험이 이 질문 목록에 새로운 항목 하나를 조용히 추가하고 있다. "AI 에이전트가 이 도구로 코드를 짤 때 얼마나 덜 망가지는가."
같은 태스크, 세 도구, 다른 결과
dev.to에 올라온 한 실험은 꽤 흥미롭다. 저자는 Flask 기반 URL 단축 서비스(REST API + Redis 캐싱 + Docker 배포)라는 동일한 태스크를 Claude Code, Cursor, Codex CLI에 동시에 던졌다. 같은 저장소, 같은 제약 조건, 같은 평가 기준. 결과는 이렇다.
Claude Code는 코드 품질에서 앞섰다. 타입 힌팅이 잘 붙어 있고, Docker Compose 파일이 별다른 수정 없이 작동했다. 프롬프트가 모호하면 되묻는 습관 덕분에 첫 구현에 필요한 수동 수정이 2건에 그쳤다. 대신 가장 느렸고, 비용도 태스크당 약 $0.15로 가장 비쌌다.
Cursor는 28분 만에 첫 커밋을 만들어냈다. 가장 빨랐다. 하지만 Redis 연결 풀 설정을 조용히 잘못 생성했고, 로그를 직접 보지 않았다면 잡지 못했을 버그였다. 인라인 리뷰 모델 덕분에 변경 사항을 라인 단위로 검토할 수 있어서 '통제감'은 셋 중 가장 높았다.
Codex CLI는 태스크당 약 $0.03으로 가장 저렴했다. 그러나 수동 수정이 5건으로 가장 많았고, Dockerfile이 arm64에서 깨지는 아키텍처 불일치 문제도 있었다.
이 숫자들보다 중요한 건 저자의 결론이다. "이 도구들은 누구도 나를 대체하지 않았다. 아키텍처 결정과 '이게 프로덕션에서 실제로 동작하는가'라는 판단은 여전히 내 몫이었다." 에이전트를 '시니어 주니어'처럼 대하라는 조언도 여기서 나온다. 빠르고 대체로 유능하지만, 리뷰 없이 풀어두면 조용히 무언가를 망친다.
8개 도구를 한 달 쓴 개발자가 실제로 지갑을 연 것
비슷한 시기에, 또 다른 실험도 진행됐다. React 대시보드 구축과 레거시 Python 서비스 유지보수라는 두 가지 실제 업무를 GitHub Copilot, Cursor, Codeium, Tabnine, Replit AI, v0, Bolt, Lovable 여덟 도구에 동시에 맡긴 것이다. 구독료만 약 $190이 들었다.
한 달 뒤 저자의 선택은 이렇다. Cursor Pro는 남겼다. 에이전트 모드에서 파일을 지정하고 변경 사항을 diff로 검토하는 방식이 "주니어 개발자 PR을 리뷰하는 느낌"을 줬기 때문이다. Copilot은 회사가 비용을 대기 때문에 유지했고, Codeium은 사이드 프로젝트용 무료 대안으로 남겼다. Bolt, Lovable, v0, Replit은 해지했다. "내가 이미 코드를 짤 수 있기 때문"이다.
흥미로운 대목은 v0에 대한 평가다. 저자는 Bolt나 Lovable과 달리 v0를 "기존 React 앱에 붙여 넣을 수 있는 UI 컴포넌트를 생성하는 데 가장 실용적인 도구"로 구분했다. 이 구분은 중요하다. 같은 'AI 코딩 도구'라도 누구의 문제를 푸는 도구인가에 따라 가치 평가가 완전히 달라진다는 걸 보여주기 때문이다.
세 번째 질문이 등장했다 — '에이전트가 이 라이브러리로 덜 틀리는가'
도구 비교 실험이 '어떤 에이전트를 쓸 것인가'를 다뤘다면, 라이브러리 선택 문제는 한 단계 더 깊이 들어간다. dev.to의 또 다른 글은 Effect와 StyleX라는 두 라이브러리를 중심으로 이 질문을 던진다. "에이전트가 더 잘 쓰는 라이브러리를 선택 기준으로 삼아야 하는가?"
Effect는 TypeScript에서 비동기 함수의 실패 경로를 타입 채널로 분리한다. 평범한 async 함수가 성공 타입만 노출하고 실패를 주석이나 예외로 처리하는 것과 달리, Effect는 NotFoundError, RateLimitError 같은 태그드 에러를 타입 시스템에 직접 녹인다. 에이전트가 새로운 에러 케이스를 추가하면서 UI 분기를 빠뜨리면, assertNever 호출이 즉시 타입 에러를 낸다. 컴파일러가 에이전트의 실수를 먼저 잡는 구조다.
StyleX는 같은 아이디어를 스타일링에 적용한다. 전역 셀렉터나 임의의 클래스명 대신 stylex.create로 정의된 타입 검사 가능한 API를 통해서만 스타일을 조합한다. 에이전트가 셀렉터를 오타 내거나 존재하지 않는 클래스를 참조하는 실수가 구조적으로 줄어든다.
이 두 라이브러리가 공통적으로 하는 것은 하나다. 에이전트가 실수할 수 있는 경로를 타입 시스템으로 차단한다. 그리고 이 접근은 에이전트가 코드의 상당 부분을 담당하기 시작하면서 의미가 완전히 달라졌다.
하지만 여기서 멈춰야 한다
저자가 솔직하게 인정하는 지점이 있다. Effect와 StyleX 모두 학습 곡선이 가파르다. 새로운 프로그래밍 모델, 새로운 어휘, 더 많은 추상화. 에이전트는 이 스택을 나보다 더 잘 이해할 수 있지만, 이 코드를 장기적으로 유지보수해야 하는 건 나다. 에이전트 친화성을 위해 팀의 학습 비용을 전부 지불하는 게 항상 옳지는 않다는 것이다.
이 지점에서 shadcn/ui가 흥미로운 대안으로 등장한다. 에이전트가 패턴을 잘 따르는 만큼 생성 품질도 높지만, 컴포넌트 소스가 프로젝트 안에 있어서 개발자가 파일을 열면 무슨 일이 벌어지는지 이해할 수 있다. 에이전트에게 구조를 주되, 사람이 리뷰할 수 있게 남겨두는 균형이다.
선택 기준을 업데이트할 시간
세 편의 실험을 겹쳐 읽으면 하나의 방향이 보인다. AI 에이전트가 실무 워크플로우에 깊이 들어온 지금, 도구와 라이브러리 선택 기준에는 새로운 축이 추가됐다.
기존 기준은 여전히 유효하다. 팀 친숙도, 문서 품질, 장기 유지보수 가능성, 프로덕션 디버깅 용이성. 그런데 이제 여기에 하나가 더 붙는다. 이 도구 혹은 라이브러리는 에이전트가 생성한 코드의 오류를 구조적으로 줄여주는가, 아니면 오히려 조용한 버그가 끼어들 틈을 넓히는가.
Cursor가 Redis 버그를 조용히 심었듯, Codex CLI가 arm64 Dockerfile을 깨뜨렸듯, 에이전트의 실수는 주로 확인하지 않으면 보이지 않는 곳에서 일어난다. Effect의 타입 채널이 그 자리를 메우는 방식은, 어쩌면 다음 세대 라이브러리 설계의 기본값이 될지 모른다.
하지만 어느 도구를 선택하든 변하지 않는 것도 있다. 아키텍처 방향, 프로덕션 동작 검증, 그리고 팀이 리뷰할 수 없는 코드는 배포하지 않겠다는 판단 — 이건 아직 우리 몫이다.