오늘 아침 热门 AI 2025(인기 AI 2025)에 대한 Juejin 검색 결과를 읽다가 깊이 빠져들게 되었는데, 마침내 한 가지 사실이 깨달아졌습니다. 인기 있는 AI 코딩 도구 포스트에서 가장 유용한 부분은 승자가 누구인지가 아닙니다. 그것은 각 도구가 남기는 인계물(handoff)입니다.

계속해서 나타나는 요약글들은 Cursor, Claude Code, Codex, v0, Lovable, Replit, 그리고 Windsurf를 하나의 S/A/B/D 스타일 비교군으로 묶습니다. 또 다른 인기 포스트는 전체적인 능력 면에서는 Cursor를 1위로, 생태계 통합(ecosystem integration) 면에서는 GitHub Copilot을 1위로, 가성비 면에서는 Codeium을 1위로, 그리고 프론트엔드 UI 면에서는 v0를 1위로 꼽습니다. 별도의 긴 경험담 형식의 글에서는 업무용으로는 Cursor를, 학습용으로는 Trae와 Codex를 사용하며, 백업용으로는 GitHub Copilot이 포함된 VS Code를 사용한다고 합니다. 질문은 모두 광범위하지만, 결과표는 매우 다릅니다.

저는 예전만큼 Cursor가 Claude Code를 이기는지에 대해 논쟁하는 데 관심이 없습니다. 몇 년간 소프트웨어를 출시해 온 결과, 제가 실제로 답을 얻어야 하는 질문은 이것입니다: AI 세션이 끝났을 때, 내가 다음 사람이나 미래의 나 자신에게 무엇을 넘겨줄 수 있는가?

Cursor의 공식 Plan Mode(계획 모드)가 좋은 예입니다. 이 모드는 저장소(repository)를 조사하고, 관련 파일을 찾고, 명확한 질문을 던지며, 코드를 작성하기 전에 파일 경로와 코드 참조가 포함된 계획을 작성합니다. 이는 지속 가능한 인계물(durable handoff)이 Markdown 계획서와 검토 가능한 diff(차이점)가 될 수 있음을 의미합니다. Claude Code는 다른 방향에서 접근합니다. 해당 문서에 따르면 프로젝트를 탐색하고, 여러 파일을 수정하며, 테스트를 실행하고, Git과 함께 작업하는 터미널 워크플로우(terminal workflow)를 설명합니다. 이들의 인계물은 대개 diff, 명령 출력(command output), 그리고 커밋 후보(commit candidate)입니다. v0는 또 다릅니다. Vercel의 문서에는 고충실도(high-fidelity) UI 생성, 백엔드 연결, 진단(diagnostics) 및 배포가 설명되어 있으므로, 이들의 자연스러운 인계물은 컴포넌트(component)나 실행 중인 웹 프로토타입(web prototype)입니다.

이것들은 동일한 답변의 사소한 변형이 아닙니다. 이것들은 서로 다른 수명과 서로 다른 검증 방식을 가진 서로 다른 엔지니어링 산출물(engineering artifacts)입니다.

채팅 기록(chat transcript)은 읽기는 쉽지만 유지보수하기는 어렵습니다. 스크린샷(screenshot)은 보여주기는 쉽지만 병합(merge)하기는 어렵습니다. 생성된 컴포넌트(component)는 유용할 수 있지만, 누군가가 데이터 로딩(data loading), 접근성(accessibility), 그리고 기존 앱과의 경계(boundary)를 확인한 후에야 비로소 유용합니다. Git diff는 검토(review), 테스트(test), 되돌리기(revert)가 가능하며 커밋(commit)에 할당될 수 있습니다. 계획(plan)은 코드가 변경되기 전에 에이전트(agent)가 잘못된 서비스에 손을 대는 것을 방지할 수 있습니다.

그렇기 때문에 저는 이제 도구를 선택하기 전에 작은 산출물 테이블(artifact table)을 작성합니다:

정확한 도구 이름은 바뀔 수 있습니다. 하지만 산출물에 관한 질문들은 더 천천히 변합니다.

저는 이를 아주 번거로운 방식으로 배웠습니다. 한때 에이전트에게 인증 모듈을 "정리(clean up)"

저는 이러한 요약(roundups)에 나타난 수치들을 여전히 주의해서 보고 있습니다. 어떤 게시물은 9.6, 8.2, 7.8과 같은 소수점 점수를 제공하고, 다른 게시물은 등급(tier) 문자를 사용하며, 근간이 되는 테스트 코퍼스(test corpus)는 대개 공개되지 않습니다. 저는 그러한 점수들을 액면 그대로 믿지 않을 것입니다. 제품의 경계 또한 빠르게 움직입니다. Cursor는 이제 플랜(plans)과 장기 실행 에이전트(long-running agents)에 대해 이야기하고 있으며, Claude Code는 단순한 터미널 경험을 넘어 확장되었고, v0는 이제 스스로를 목업(mockup) 이상의 것을 할 수 있는 도구로 설명합니다. 이번 달에는 한 열(column)에 속했던 기능이 다음 릴리스(release)에는 다른 열에 속할 수도 있습니다.

이러한 불확실성이 비교 자체를 무용하게 만드는 것은 아닙니다. 단지 제가 그것들을 읽는 방식을 바꿀 뿐입니다. 저는 스코어카드(scorecard)를 후보군을 찾는 용도로 사용하고, 그 다음에는 인계물(handoff)을 판단합니다. 내가 그것을 검토(review)할 수 있는가? 다시 실행(rerun)할 수 있는가? 소스(source)를 추적할 수 있는가? 잘 다듬어진 문단을 엔지니어링 작업으로 번역하는 과정 없이 바로 병합(merge)할 수 있는가? 만약 대답이 '아니오'라면, 모델 점수가 아무리 높더라도 워크플로(workflow)를 구원하지는 못할 것입니다.

현재 저의 스택(stack)은 편집기 중심의 빠른 변경을 위한 Cursor, 저장소 탐색 및 까다로운 다중 파일 작업을 위한 Claude Code, 가벼운 인라인(inline) 보조를 위한 GitHub Copilot, 그리고 UI 방향을 빠르게 탐색해야 할 때를 위한 v0입니다. 작업이 편집의 연속보다는 에이전트(agent)를 위한 목표로서 더 잘 표현될 때는 Codex를 추가 옵션으로 사용합니다. 다음 릴리스 주기 이후에 이 조합을 바꿀 수도 있겠지만, 인계물(artifact)에 관한 기준은 그대로 유지될 것입니다.

비교에서 승리하는 AI 도구가 반드시 팀의 제품 출시(ship)를 돕는 도구는 아닙니다. 명확하고, 테스트 가능하며, 검토 가능한 인계물(handoff)을 남기는 도구가 대개 더 나은 기회를 가집니다.