2026년 5월 기준으로, Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Google Antigravity, Kiro, 그리고 Windsurf까지 논쟁을 벌일 만큼 진지한 수준의 코딩 도구 7개가 등장했습니다. 새로운 점은 거의 모든 도구가 이제 백그라운드 모드 (background mode)를 출시했다는 것입니다. 단순히 "에디터 안의 AI"가 아니라, "클라우드에서, 자체 머신에서 실행되며, 당신이 말 그대로 다른 무엇인가를 하는 동안 Pull Request (PR)를 생성하는 AI"입니다.

저는 지난 몇 달 동안 주요 경쟁 도구들을 통해 실제 업무를 수행해 왔습니다. 장난감 같은 작업이 아니라, 실제 저장소 (repos)에서의 실제 프로덕션 작업입니다. 마케팅 페이지에서는 모두 동일하게 들리지만 실제로는 그렇지 않기에, 제가 시작하기 전에 이런 비교 자료가 있었으면 좋았을 것이라고 생각합니다.

이런 종류의 도구를 언제 사용해야 하는지에 대한 개념적인 버전이 궁금하시다면, 백그라운드 AI 코딩 에이전트와 위임 시점에 관한 글에 별도로 작성해 두었습니다. 이 기사는 그 나머지 절반입니다. 즉, 위임하기로 결정했다면 실제로 어떤 도구를 선택할 것인가에 대한 내용입니다.

이 도구들에서 "백그라운드 에이전트"가 의미하는 것

먼저, 모든 곳에서 진정으로 동일한 형태를 띠고 있는 공통 모델에 대해 설명하겠습니다.

당신은 작업을 설명합니다. 도구는 새롭고 격리된 가상 머신 (Virtual Machine, VM)을 프로비저닝 (provision) 합니다. 해당 VM은 브랜치의 현재 HEAD에서 당신의 저장소를 클론 (clone) 하고, 작동 가능한 환경을 갖추기 위해 설정 명령어를 실행한 다음, 에이전트가 작업을 수행하고, 체크 (checks)를 실행하며, 요약이 포함된 초안 Pull Request (PR)를 생성합니다. 당신은 시간이 될 때 언제든 PR을 검토하면 됩니다. 작업이 진행되는 동안 당신은 지켜보고 있지 않았습니다.

차이점은 중요한 세부 사항에 있습니다. 어디에서 실행을 트리거 (trigger) 하는지, 격리된 환경이 얼마나 우수한지, 설정을 어떻게 처리하는지, 어떻게 결과를 보고하는지, 비용이 얼마나 드는지, 그리고 기반이 되는 모델 (underlying model)이 얼마나 강력한지 등이 그것입니다. 그 세부 사항들이 비교의 핵심입니다.

먼저 언급해 둘 가치가 있는 점이 하나 있습니다. 이 도구들 중 그 어떤 것도 스스로 코드를 병합(merge)해서는 안 됩니다. 모든 도구는 여러분의 기존 품질 게이트(quality gates)가 통제권을 유지할 수 있도록 특별히 초안 PR(draft PR)을 생성합니다. 백그라운드 에이전트(background agent)는 기여자(contributor)이지, 커미터(committer)가 아닙니다. 어떤 도구를 선택하든 브랜치 보호(branch protection)와 필수 리뷰(required review) 설정을 유지하십시오.

OpenAI Codex Cloud Tasks

Codex는 클라우드 네이티브(cloud-native) 모델에 가장 강력하게 집중합니다. 제품 전체가 '사용자가 작업을 설명하면, 그것이 다른 어딘가에서 실행되고, 검토 가능한 diff를 반환하며, 사용자가 어떻게 할지 결정한다'는 아이디어를 중심으로 구축되었습니다.

강점. 깔끔한 diff를 반환하는 독립적이고 경계가 명확한 작업입니다. Codex는 "여기에 설명된 변경 사항이 있으니, 깨끗한 환경에서 이를 수행하고 결과를 보여달라"는 루프를 수행하는 데 진정으로 뛰어납니다. 격리(isolation)가 확실하고, 환경 설정(environment setup)이 간단하며, diff가 검토하기 쉬운 형태로 돌아옵니다. 범위가 좁게 지정된 작업(tightly scoped tasks)의 백로그를 처리하는 데 있어 가장 강력한 옵션 중 하나입니다.

약점. 사용자의 로컬 상태(local state)가 필요한 모든 작업입니다. 매우 클라우드 우선(cloud-first) 방식이기 때문에, 실제 사용자의 머신, 로컬 서비스, 브라우저 상태, 커밋되지 않은 변경 사항(uncommitted changes)에 의존하는 것들은 Codex가 도와줄 수 없는 바로 그 요소들입니다. 이것은 결함이 아니라 설계의 결과이지만, 잘못된 작업에 사용하려고 하면 그 한계를 느끼게 됩니다.

가격 구조. Codex는 고정된 시트(seat) 단위가 아닌 사용량 기반(usage-based) 모델로 운영됩니다. 이는 양날의 검입니다. 산발적으로 위임한다면 사용한 만큼만 지불하면 되므로 저렴합니다. 하지만 에이전트 군단을 24시간 내내 가동한다면 사용량 기반 과금이 빠르게 상승할 수 있으므로 사용량을 주시해야 합니다.

Codex에 적합한 사고 모델(mental model): 이것은 레포지토리 범위의 작업(repo-scoped tasks)을 던져 넣는 큐(queue)입니다. 코드를 작성하는 빌드 서버(build server)처럼 취급하십시오.

Cursor Cloud Agents

Cursor는 IDE 측면에서 출발했으며, 그 배경 이야기가 이를 반영합니다. 에디터에서 대화형으로 작업을 시작한 다음 이를 격리된 VM에서 실행되는 클라우드 에이전트로 넘기거나, 클라우드 에이전트를 직접 시작할 수 있습니다.

강점. 포그라운드 (foreground)와 백그라운드 (background) 사이의 핸드오프 (handoff)가 비교 대상 중 가장 매끄럽습니다. 대화형으로 작업하다가 특정 부분을 위임할 수 있다고 판단되면, 작업 흐름을 끊지 않고 바로 클라우드로 보낼 수 있습니다. 각 클라우드 작업은 고유한 파일 시스템, 터미널, 네트워크 및 패키지 환경을 갖춘 새로운 VM을 할당받으며, 저장소(repo)를 HEAD 상태로 복제하고 설정을 실행한 뒤 작업을 시작합니다. 이미 Cursor를 사용 중인 개발자들에게 이러한 연속성은 강력한 셀링 포인트 (selling point)입니다.

약점. 팀 티어 (team tier) 기준으로 IDE 기반 옵션 중 가장 비용이 많이 들며, 클라우드 에이전트 경험이 훌륭하긴 하지만 근본적으로 에디터를 중심으로 설계된 제품 위에 계층적으로 쌓여 있는 형태입니다. 만약 Cursor를 별도로 사용하고 있지 않다면, 오직 백그라운드 에이전트만을 위해 Cursor를 도입하는 것은 해당 기능을 위해 감수해야 할 표면적 (surface area)이 너무 넓습니다.

가격 구조. 비즈니스 티어 (Business tier)의 팀 시트 (team seats) 비용은 높은 편이며, 보고된 바에 따르면 개발자 10명 기준 연간 약 4,800달러 수준으로 Windsurf와 비슷한 범위에 있습니다. 이 모든 도구의 가격은 끊임없이 변동되므로 모든 수치는 스냅샷 (snapshot)으로 취급해야 하지만, Cursor는 가격대가 높은 편에 속합니다.

이미 Cursor에서 작업하고 있다면 클라우드 에이전트는 고민할 필요 없는 선택입니다. 하지만 그렇지 않다면 가치 제안 (value proposition)의 범위는 좁아집니다.

GitHub Copilot 코딩 에이전트

Copilot의 배경 스토리는 작업이 이미 이루어지고 있는 곳, 즉 GitHub 자체와 가장 밀접하게 엮여 있습니다. 이슈 (issue)를 코딩 에이전트에 할당하거나 언급하면, 에이전트가 백그라운드에서 작업하고, 초안 PR (draft PR)을 생성하며, 검토를 요청합니다. 또한 CLI 및 에디터 내부에서도 위임 흐름 (delegate flow)을 사용할 수 있습니다.

강점. 만약 팀이 GitHub 이슈(issue)와 PR(Pull Request)을 기반으로 운영된다면, 그 통합 능력은 타의 추종을 불허합니다. 에이전트가 이슈 설명과 댓글을 컨텍스트(context)로 읽고, 브랜치 보호 규칙(branch protection rules)에 따라 초안 PR(draft PR)을 생성하며, 이 모든 과정이 이미 사용 중인 워크플로우(workflow) 내에서 이루어집니다. 브랜치 보호를 우회하는 사람 없이 이슈의 수락 기준(acceptance criteria)을 직접 초안 PR로 전환하는 것은 진정으로 깔끔한 루프(loop)입니다. Copilot은 실제로 에이전트를 로컬(local), 백그라운드(background), 클라우드(cloud), 서브 에이전트(sub-agent)라는 별도의 유형으로 나누었는데, 처음에는 혼란스러울 수 있지만 어떤 것을 호출하는지 알게 되면 매우 유용합니다.

약점. 모델의 한계치(model ceiling)는 역사적으로 프런티어(frontier) 모델들에 비해 뒤처져 왔으며, 어렵고 모호한 추론(reasoning) 작업에서는 그 한계가 드러날 수 있습니다. 잘 정의된 이슈-to-PR 작업에는 탁월하지만, 깊은 판단력이 필요한 작업에서는 인상적이지 않습니다.

가격 구조. Copilot은 가장 저렴한 팀 옵션 중 하나로, Business 티어 기준 개발자 10명당 연간 약 2,280달러 범위인 것으로 알려져 있어, 이미 GitHub 비용을 지불하고 있는 팀에게는 쉬운 기본 선택지가 됩니다.

여기서의 적합성은 조직적 측면입니다. 만약 팀의 신뢰할 수 있는 단일 출처(source of truth)가 GitHub 이슈라면, Copilot의 코딩 에이전트는 새로운 프로세스 도입 없이 거의 그대로 녹아듭니다.

Claude Code 비동기 (Async)

Claude Code는 터미널 우선(terminal-first) 에이전트이며, 그 비동기(async) 기능은 이를 확장합니다. 백그라운드에서 실행하여 다른 일을 하는 동안 작업을 수행하도록 할 수 있으며, 기반이 되는 Opus 모델 덕분에 그룹 내에서 가장 높은 추론(reasoning) 한계치를 유지합니다.

강점. 어려운 작업들입니다. 작업에 실제 추론(reasoning), 다단계 계획(multi-step planning), 또는 까다로운 코드베이스(codebase)를 다루는 능력이 필요할 때 모델의 품질이 드러납니다. 최신 Claude Opus 출시는 긴 에이전트 세션(agentic sessions)의 신뢰성을 눈에 띄게 끌어올렸으며, 이는 에이전트가 20분 동안 관리자 없이 실행될 때 정확히 필요로 하는 부분입니다. 또한 2026년 설문조사에서 개발자들 사이에서 압도적인 차이로 가장 사랑받는 도구로 선정되었는데, 이는 결코 가볍게 볼 수 없는 결과입니다.

약점. 주로 비용입니다. 팀 티어(team tier)는 다른 도구들보다 훨씬 더 비싸며, 보고에 따르면 10인 기준 Copilot보다 한 자릿수(order of magnitude) 더 높습니다. 개인이나 소규모 팀에게는 사용당 비용이 매우 합리적일 수 있지만, 규모를 확장할 경우 구매할 수 있는 추론(reasoning) 도구 중 가장 비쌉니다. 또한 터미널 우선(terminal-first) 방식이기 때문에, 백그라운드 경험이 Cursor나 Copilot의 GitHub 네이티브 흐름(flow)만큼 GUI가 세련되지는 않았습니다.

가격 구조. 개인 사용은 합리적입니다. 팀 티어는 이 그룹 내에서 큰 차이로 가장 비싸기 때문에, 이는 기본 설정으로 선택하는 것이 아니라 추론(reasoning)의 한계치를 원하기 때문에 의도적으로 지출하는 비용입니다.

Claude Code 생태계는 핵심 에이전트를 넘어 깊이 있게 확장됩니다. 만약 팀이 이 도구를 사용하는 방식을 표준화하고 있다면, 플러그인 마켓플레이스 및 스킬(plugin marketplace and skills)을 통해 여러분의 작업 패턴을 공유 가능한 설치형 구성 요소로 바꿀 수 있으며, 이는 여러 사람이 동일한 관례(conventions)에 따라 작업을 위임할 때 더욱 중요해집니다.

내가 실제로 이들 사이에서 선택하는 방법

기능 비교표는 잊으세요. 상황별로 제가 실제로 내리는 결정은 다음과 같습니다.

팀이 GitHub 이슈(issues)와 PR(Pull Requests)을 중심으로 움직인다면. Copilot 코딩 에이전트입니다. 통합 비용(integration tax)이 거의 제로에 가깝고 가격이 가장 저렴합니다. 새로운 도구를 도입하는 것이 아니라, 이미 비용을 지불하고 있는 도구의 기능을 활성화하는 것뿐입니다.

당신은 이미 하루 종일 Cursor에서 작업하고 있습니다. Cursor cloud agents. 포그라운드에서 백그라운드로의 핸드오프 (foreground-to-background handoff)는 당신이 경험할 수 있는 가장 매끄러운 수준이며, 새로운 작업 영역 (surface area)을 추가할 필요도 없습니다. 만약 당신이 아직 Cursor를 사용하고 있지 않다면, 이것은 Cursor를 시작해야 할 약한 이유가 됩니다.

백로그 (backlog) 작업을 위한 순수한 위임 큐 (delegation queue)를 원합니다. Codex cloud tasks. 사용량 기반 가격 책정 (usage-based pricing)은 간헐적인 위임에 적합하며, 클라우드 우선 (cloud-first) 설계는 정확히 "설명하고, 다른 곳에서 실행하고, 차이점 (diff)을 검토한다"는 방식에 맞춰 구축되었습니다. 규모를 키울 때는 사용량 측정기 (meter)를 주의하십시오.

작업이 진정으로 어렵고 품질을 위해 비용을 지불할 용의가 있습니다. Claude Code async. 작업에 가용한 가장 강력한 추론 (reasoning) 능력이 필요하고, 처음부터 제대로 해내는 것이 실제 돈만큼의 가치가 있을 때, 이것이 바로 한계치 (ceiling)입니다. 개인에게는 비용이 적절합니다. 대규모 팀에게는 의도적이고 값비싼 선택입니다.

대부분의 진지한 사용자들은 하나만 선택하지 않습니다. 범위가 잘 정해진 대다수의 작업에는 저렴하고 통합된 옵션을 사용하고, 진정으로 어려운 작업에는 비싸고 높은 추론 능력을 가진 옵션을 사용합니다. 이는 제가 단일 에이전트 대 멀티 에이전트 (single-agent versus multi-agent) 트레이드오프 (tradeoff)에서 설명한 것과 동일한 분할 방식입니다. 도구를 작업의 난이도에 맞추십시오. 상용구 (boilerplate) 작업에 프런티어 (frontier) 급의 가격을 지불하지 마십시오.

아무도 좋아하지 않는 가격 책정의 현실

비용에 대해 짧고 솔직한 부연 설명을 덧붙이자면, 수치는 매 분기 변하며 프레임워크 (framing)가 특정 수치보다 더 중요하기 때문입니다.

두 가지 가격 모델이 지배적입니다. 인당 고정 요금제 (Flat per-seat: Copilot, Cursor, Windsurf, Kiro, Antigravity)와 사용량 기반 요금제 (usage-based: Codex, 그리고 API 레벨의 Claude Code)입니다. 연간 10명의 개발자를 기준으로 할 때, 2026년에 보고된 고정 요금제의 격차는 Copilot의 경우 수천 달러 초반부터 Cursor와 Windsurf의 경우 그 몇 배에 달했으며, Claude Code의 팀 티어 (team tier)는 나머지를 훨씬 상회했습니다. 사용량 기반 옵션은 가끔 위임할 때는 저렴하지만, 에이전트를 지속적으로 실행할 때는 가장 비싸질 수 있습니다.

함정은 좌석당 가격 (seat price)을 최적화하려다 사용 패턴 (usage pattern)을 무시하는 것입니다. 거의 사용하지 않는 고정 좌석제는 돈 낭비입니다. 반대로 24시간 내내 몰아치는 사용량 기반 (usage-based) 도구는 차라리 고정 요금제를 구매하는 것이 더 나았을 상황을 초과할 수도 있습니다. 가격표가 가장 낮아 보이는 것에 맞추지 말고, 실제 작업 방식에 맞춰 과금 모델을 선택하세요.

그리고 이 글에 포함된 수치를 포함하여, 여러분이 보는 모든 숫자를 하나의 스냅샷 (snapshot)으로 취급하십시오. 이 카테고리는 끊임없이 가격을 재조정합니다. 팀을 어떤 도구에 투입하기 전에 반드시 현재 가격을 확인하세요.

모든 도구를 나쁘게 만드는 실수들

도구 자체보다 어떻게 사용하는지가 더 중요하며, 동일한 실수들이 모든 도구의 성능을 떨어뜨립니다.

모호한 작업 (Vague tasks). "코드베이스를 개선해줘"라는 명령은 네 가지 도구 모두에서 쓰레기 같은 결과물을 만들어냅니다. 완료 정의 (definition of done)가 명확하고 범위가 잘 지정된(well-scoped) 작업만이 병합 가능한 PR (Pull Request)을 생성합니다. 좋은 프롬프트와 나쁜 프롬프트 사이의 병합률 (merge rate) 격차는 도구 간의 품질 격차보다 훨씬 큽니다.

지침 파일 (instructions file)의 부재. 백그라운드 에이전트 (background agent)는 사용자의 컨텍스트 (context)가 전혀 없는 깨끗한 VM (Virtual Machine)에서 시작합니다. 설정, 테스트 명령, 컨벤션 (conventions)을 다루는 AGENTS.md 또는 그에 상응하는 파일을 리포지토리 루트 (repo root)에 두는 것이 여러분이 할 수 있는 가장 레버리지가 높은 (highest-leverage) 작업입니다. 이를 생략하면 모든 에이전트가 실제보다 더 멍청해 보일 것입니다.

디프 (diff)를 무비판적으로 승인하기 (Rubber-stamping). AI가 생성한 코드는 측정 가능한 수준으로 더 높은 버그 밀도 (bug density)를 가집니다. 설득력 있는 PR 요약이 실제 변경 사항을 읽는 것을 대신할 수는 없습니다. 저는 어떤 도구가 생성했는지와 상관없이 에이전트가 만든 PR을 동일한 AI 생성 코드 테스트 프로세스 (testing process for AI-generated code)를 통해 검증합니다. 리뷰 규율 (review discipline)은 도구와 무관해야 합니다.

부채를 무시하기. 에이전트 코드를 빠르게 많이 배포하면, 단일 PR 리뷰로는 잡아낼 수 없는 복잡성과 중복이 쌓이게 됩니다. 이러한 새로운 형태의 기술 부채 (new shape of technical debt)는 이 모든 도구에서 실제로 나타나는데, 이는 특정 벤더 (vendor)의 문제가 아니라 빠르게 작성된 기계 생성 코드 (machine-authored code) 자체의 특성이기 때문입니다.