에이전트 하네스 비교: Claude Code, Aider, Cursor Agent, Codex CLI

1. 서론: 에이전틱 개발자 하네스 (Agentic Developer Harnesses)의 구조

현대 소프트웨어 개발은 인간의 직접적인 개입 없이 코드를 읽고, 수정하고, 실행할 수 있는 언어 모델 에이전트 (Language Model Agents)에 점점 더 의존하고 있습니다. “에이전틱 개발자 하네스 (Agentic developer harness)”는 대규모 언어 모델 (LLM)을 파일 시스템, 터미널, 그리고 외부 API에 연결하여 자연어 프롬프트를 구체적인 행동으로 전환하는 접착제 역할을 합니다. 이 하네스는 모델의 토큰 스트림 (Token stream)을 셸 명령 (Shell commands), 파일 차이점 (File diffs), 또는 API 호출로 변환한 다음, 그 결과를 다시 모델의 컨텍스트 윈도우 (Context window)로 피드백해야 합니다. 이 피드백 루프는 에이전트가 얼마나 빠르게 반복 (Iterate)할 수 있는지, 얼마나 많은 자율성을 누리는지, 그리고 그 출력이 얼마나 예측 가능한지를 결정합니다.

현재 시장은 Claude Code, Aider, Cursor Agent, 그리고 Codex CLI라는 네 가지 도구가 주도하고 있습니다. 각 도구는 파일 탐색 (File discovery), 수정 생성 (Edit generation), 테스트 실행 (Test execution), 버전 관리 (Version control)라는 동일한 핵심 책임을 구현하지만, 개발 환경을 LLM에 노출하는 방식에서 차이가 있습니다. 예를 들어, Claude Code는 git, 테스트 러너 (Test runner), 그리고 검색 인터페이스를 통합된 명령줄 뒤에 래핑 (Wrap)하는 단일 바이너리를 제공합니다. Aider는 모델의 프롬프트에 가상 파일 시스템을 주입하는 Python 중심의 라이브러리를 제공합니다. Cursor Agent는 VS Code 확장 프로그램으로 실행되며, 에디터 이벤트를 모델에 직접 스트리밍합니다. Codex CLI는 OpenAI의 Codex 엔드포인트 (Endpoint)를 둘러싼 경량 래퍼 (Wrapper)로, 단일 턴 (Single-turn) 코드 생성에 집중합니다.

하네스 (Harness)의 설계는 세 가지 실질적인 차원에 영향을 미칩니다. 첫째, 컨텍스트 (Context)의 세밀함 (Granularity)입니다. 전체 저장소 (Repository)를 보는 모델은 더 광범위한 리팩토링 (Refactor)을 계획할 수 있는 반면, 단일 파일로 제한된 모델은 추가적인 컨텍스트를 반복적으로 요청해야 합니다. 둘째, 실행 모델 (Execution model)입니다. 각 명령이 완료될 때까지 기다리는 동기식 (Synchronous) 에이전트는 추론하기 쉽지만, 비동기식 (Asynchronous) 에이전트는 I/O를 중첩하여 지연 시간 (Latency)을 줄일 수 있습니다. 셋째, 비용 프로필 (Cost profile)입니다. 모델로 전송되는 각 토큰 (Token)에는 비용이 발생하므로, 중간 결과물을 캐싱 (Caching)하거나 편집을 배치 (Batch) 처리하는 하네스는 작업당 비용을 낮출 수 있습니다.

SWE-bench 벤치마크에서 Claude Code의 성능은 능력과 비용 사이의 트레이드오프 (Trade-off)를 잘 보여줍니다. 50.5%의 검증된 점수 (Verified score)는 현재 세대 중 중간 수준에 위치하며, 이는 긴밀하게 통합된 커맨드 라인 (Command-line) 하네스가 과도한 토큰 소비 없이도 준수한 정확도를 달성할 수 있음을 보여줍니다.

Claude Code는 SWE-bench에서 50.5%의 검증된 점수를 기록했습니다. 이 수치는 Anthropic의 Claude Code 발표 게시물에서 가져온 것이며, Claude 3.5 Sonnet을 사용한 평가 결과를 반영합니다.

Claude Code의 문서는 에이전트적 특성 (Agentic nature)을 강조합니다. 이 도구는 "코드를 작성하고, 코드베이스를 검색하며, 테스트를 실행하고, git 명령어를 에이전트 방식으로 실행하도록 돕습니다."라는 설명을 담고 있습니다. 이러한 설명은 개발자 하네스의 핵심적인 약속, 즉 수동적인 작업 (Manual plumbing) 없이 고수준의 의도 (High-level intent)를 구체적인 개발 동작으로 전환하는 능력을 포착합니다.

Claude Code의 공식 문서는 이 도구가 "코드를 작성하고, 코드베이스를 검색하며, 테스트를 실행하고, git 명령어를 에이전트 방식으로 실행하도록 돕는다"라고 명시하고 있습니다. Anthropic Claude Code Documentation

이러한 아키텍처 설계(architectural choices)를 이해하는 것은 주어진 워크플로(workflow)에 적합한 하네스(harness)를 선택하기 위한 첫 번째 단계입니다. 이어지는 섹션에서는 각 도구가 개발자 환경을 LLM 컨텍스트 창(context window)에 어떻게 매핑하는지, 파일 수정(file edits)을 어떻게 처리하는지, 그리고 비용 및 동시성 모델(concurrency models)이 어디에서 갈라지는지를 분석합니다. 비교가 끝날 때쯤이면 엔지니어들은 속도 극대화, 토큰 소비 최소화, 또는 버전 히스토리(version history)에 대한 세밀한 제어 유지 등 프로젝트의 제약 조건에 맞춰 하네스를 매칭할 수 있게 될 것입니다.

2. 도구 노출(Tool Exposure): 하네스가 파일 시스템, 터미널 및 API를 LLM 컨텍스트 창에 매핑하는 방식

LLM이 코드를 생성하거나 수정하도록 요청받을 때, 모델은 주변 환경에 대한 관점이 필요합니다. 하네스는 원시 운영체제(파일, 셸, 네트워크 서비스)와 모델의 고정된 크기의 컨텍스트 창(context window) 사이의 간극을 메워줍니다. 이 브릿지는 어떤 데이터를 포함할지, 얼마나 자주 새로고침할지, 그리고 어떤 추상화(abstractions)를 프롬프트(prompts)로 노출할지를 결정합니다. 잘 설계된 노출 레이어(exposure layer)는 모델이 토큰 예산(token budget)을 초과하지 않으면서 파일 경로를 추론하고, 디렉토리 목록을 읽고, 명령어를 호출할 수 있게 합니다.

Claude Code는 터미널을 일급 시민(first-class citizen)으로 취급합니다. 사용자가 실행하는 각 명령어는 캡처되며, 해당 명령어의 표준 출력(stdout)과 표준 에러(stderr)가 프롬프트에 추가되어 모델이 다음 명령어를 제안할 수 있습니다. 컨텍스트 창을 관리 가능한 수준으로 유지하기 위해 Claude Code는 세션당 예산을 부과합니다.

Claude Code는 터미널 세션 비용을 $25.00로 제한합니다. 이 제한은 Anthropic Claude Code 사용 가이드(Usage Guides)에 정의되어 있으며, 긴 디버깅 루프(debugging loops) 동안 토큰 소비가 통제 불능 상태로 치닫는 것을 방지합니다.
이 예산 제약으로 인해 하네스는 오래된 명령어 출력을 정리(prune)하고 가장 최근의 상호작용을 가시권에 유지해야 합니다. 이러한 설계는 대화형 디버깅(interactive debugging)에는 효과적이지만, 다단계 계획(multi-step plan)에서 필요할 수 있는 이전 컨텍스트를 버릴 수도 있습니다.

Aider는 다른 철학을 따릅니다. 이 도구는 로컬 Git 저장소를 모니터링하고, 차이점(diffs)을 드러내며, 파일 스니펫(snippets)을 프롬프트에 직접 주입합니다. 따라서 전체 파일 대신 변경된 허크(hunks)만을 전송함으로써 파일 시스템을 LLM 컨텍스트(context)에 매핑합니다. 이는 수정 사항의 의미론적 관련성(semantic relevance)을 유지하면서 토큰 부하(token load)를 줄여줍니다.

Aider 문서는 이를 “터미널에서 LLM과 함께 코드를 작성할 수 있게 해주며, 로컬 Git 저장소의 파일과 직접 작업하는 커맨드 라인(command-line) 채팅 도구”라고 설명합니다. Aider GitHub Repository Documentation
스테이징된 변경 사항(staged changes)에 대한 노출을 제한함으로써, Aider는 모델이 주의가 필요한 정확한 라인에 집중할 수 있도록 유지할 수 있습니다.

Cursor Agent는 더 풍부한 API 계층을 구축합니다. 모델이 경로 기반 명령으로 쿼리할 수 있는 가상 파일 시스템(virtual file system)을 등록하며, 가공되지 않은 텍스트 대신 구조화된 JSON을 반환하는 터미널 샌드박스(terminal sandbox)를 제공합니다. 이 하네스(harness)는 이러한 JSON 응답을 간결한 프롬프트 파편(prompt fragments)으로 변환하여, 모델이 전체 트리(tree)를 보지 않고도 파일 계층 구조(file hierarchies)에 대해 추론할 수 있도록 합니다.

Codex CLI는 네 가지 중 가장 최소한의 기능을 제공합니다. 간단한 파일 읽기/쓰기 API와 셸(shell)을 감싸는 얇은 래퍼(wrapper)를 노출합니다. 이 CLI는 모델이 요청할 때 파일의 전체 내용을 전송하며, 작업이 완료되면 편집된 파일 전체를 반환합니다. 점진적인 가지치기(incremental pruning)가 없기 때문에, 대규모 프로젝트의 경우 토큰 비용이 빠르게 증가할 수 있습니다.

실제로, 노출 전략(exposure strategy)의 선택은 프로젝트 상태의 어느 정도가 LLM의 컨텍스트 윈도우(context window)에 들어갈지를 결정합니다. Claude Code의 예산화된 터미널 스트림(budgeted terminal stream), Aider의 차이점 중심 Git 뷰(diff-focused Git view), Cursor Agent의 구조화된 API, 그리고 Codex CLI의 원시 파일 덤프(raw file dump)는 각각 토큰 효율성을 위해 완전성(completeness)을 절충(trade-off)합니다. 이러한 절충안을 이해하면 엔지니어가 자신의 워크플로 복잡성과 편집 중인 코드베이스의 크기에 부합하는 하네스를 선택하는 데 도움이 됩니다.

3. 파일 편집 패러다임: 검색 및 교체 블록(Search-and-Replace Blocks) vs. 통합 차이점(Unified Diffs) vs. 전체 파일 재작성(Whole-File Rewrites)

LLM(Large Language Model) 기반 에이전트가 소스 코드를 수정해야 할 때, 하네스(Harness)는 변경 사항이 모델에 어떻게 전달될지, 그리고 모델의 출력이 저장소(Repository)에 어떻게 적용될지를 결정합니다. 여기에는 세 가지 지배적인 패러다임이 존재합니다. 검색 및 교체 블록(Search-and-replace blocks) 방식은 파일을 가변적인 문자열로 취급하여 대상 영역을 찾아 새로운 텍스트로 대체합니다. 통합 디프(Unified diffs)는 편집 내용을 라인 중심의 패치(Patch)로 인코딩하여, 문맥(Context) 라인을 보존하면서 모델이 변경된 부분만 볼 수 있도록 합니다. 전체 파일 재작성(Whole-file rewrites)은 모델에게 파일 전체를 처음부터 생성하도록 요청한 뒤, 기존 버전을 통째로 교체하는 방식입니다.

검색 및 교체(Search-and-replace)는 구현이 가장 간단합니다. 하네스는 함수나 클래스를 둘러싼 스니펫(Snippet)을 추출하여 모델이 해당 스니펫을 다시 작성하도록 프롬프트(Prompt)를 전달하고, 그 결과를 다시 결합(Splice)합니다. 이 방식은 고립된 리팩토링(Refactor)에는 효과적이지만, 모델이 주변 코드를 누락할 경우 의도치 않은 삭제를 유발할 수 있습니다. 통합 디프(Unified diffs)는 모델이 명시적인 + 및 - 라인을 생성하도록 강제함으로써 그러한 위험을 완화합니다. 또한 디프(Diff) 형식은 버전 관리 도구와 깔끔하게 통합되어 자동 충돌 해결 및 감사 추적(Audit trails)을 가능하게 합니다. 그러나 디프 생성은 파싱(Parsing) 단계를 추가하며, 모델이 디프 구문을 이해해야 하므로 토큰(Token) 사용량이 증가할 수 있습니다.

전체 파일 재작성(Whole-file rewrites)은 모델에게 최대의 자유도를 부여합니다. 하네스가 전체 파일 내용을 제공하면, 모델이 완전한 교체본을 반환하고, 하네스가 새 파일을 작성합니다. 이 패러다임은 임포트(Import), 타입 정의(Type definitions), 문서 업데이트가 필요한 새로운 모듈을 추가하는 경우와 같이 파일의 구조가 서로 밀접하게 의존적인 상황에서 빛을 발합니다. 단점은 높은 토큰 비용과 회귀(Regression) 발생 가능성이 높다는 점인데, 이는 모델이 변경되지 않은 섹션까지 완벽하게 재현해야 하기 때문입니다.

실질적인 비교는 Aider 벤치마크에서 나타나는데, 여기서 Claude 3.5 Sonnet은 SWE-bench에서 41.1%의 검증된 점수(Verified score)를 달성했습니다. 이 결과는 편집 패러다임의 선택이 성공률에 어떻게 영향을 미치는지를 반영합니다. Aider가 기본적으로 통합 디프(Unified diffs)를 사용한 것이 상대적으로 높은 점수를 얻는 데 기여했습니다.

Aider Benchmark Leaderboard에 따르면, **Claude 3.5 Sonnet을 사용한 Aider의 검증된 SWE-bench 점수는 41.1%**이며, 이는 디프(diff) 기반 편집이 실제 성능에 미치는 영향을 잘 보여줍니다.

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 패러다임에 관계없이 에이전트가 편집 사항을 설명할 수 있는 공통 언어를 제공합니다. 파일 변경 사항의 표현 방식을 표준화함으로써, MCP는 Claude Code, Cursor Agent, Codex CLI와 같은 도구들이 별도의 커스텀 파서(custom parser) 없이도 편집 사항을 교환할 수 있게 해줍니다.

"모델 컨텍스트 프로토콜 (MCP)은 개발자가 AI 모델과 데이터 소스 간에 안전한 양방향 연결을 구축할 수 있도록 지원하는 개방형 표준입니다"라고 모델 컨텍스트 프로토콜 사양 개요 (Model Context Protocol Specification Overview)는 설명합니다.

실무에서 팀은 빠르고 위험이 낮은 미세 조정에는 검색 및 교체 (search-and-replace) 방식을, 버전 관리(version-control)의 정밀한 검토를 거쳐야 하는 모든 변경 사항에는 통합 디프 (unified diffs) 방식을 채택해야 하며, 편집 내용이 서로 연관된 많은 부분을 건드리는 경우에만 파일 전체 재작성 (whole-file rewrites) 방식을 사용해야 합니다. 적절한 패러다임을 선택하면 토큰 낭비를 줄이고, 안전성을 높이며, 에이전트의 출력을 프로젝트의 워크플로우(workflow)에 일치시킬 수 있습니다.

4. 계획 및 실행 루프: 단일 턴(Single-turn) vs. 다단계 에이전트 궤적(Multi-step Agentic Trajectories)

LLM에 코드 수정을 요청할 때, 하네스(harness)는 모델에게 한 번의 요청으로 완전한 디프(diff)를 생성하도록 요청(단일 턴, single-turn)하거나, 모델이 여러 사이클에 걸쳐 추론하고, 도구 호출(tool calls)을 수행하며, 답변을 개선하도록 할 수 있습니다(다단계, multi-step). 이 차이는 단순히 외관상의 차이가 아닙니다. 이는 모델이 얼마나 많은 컨텍스트(context)를 보는지, 실수를 얼마나 빨리 복구할 수 있는지, 그리고 비용 프로필(cost profile)이 얼마나 예측 가능한지를 결정합니다.

Claude Code 및 Codex CLI에서 볼 수 있는 단일 턴 (Single-turn) 설계는 편집을 순수한 언어 생성 (language generation) 문제로 취급합니다. 하네스 (harness)는 관련 파일들을 수집하여 프롬프트 (prompt)에 주입하고, 모델에게 최종 패치 (patch)를 출력하도록 요청합니다. 이 접근 방식은 구현이 간단하고 지연 시간 (latency)이 낮으며, 변경 사항이 국소적이고 주변 코드가 모델의 컨텍스트 윈도우 (context window) 내에 여유롭게 들어갈 때 잘 작동합니다. 하지만 피드백 없이 모델이 전체 변환을 추측하도록 강제하기 때문에, 예측이 틀릴 경우 완전히 잘못된 디프 (diff)가 생성되어 이를 폐기하고 다시 생성해야 합니다.

Aider와 Cursor Agent가 채택한 다단계 궤적 (Multi-step trajectories) 방식은 문제를 계획 (planning) 단계와 그에 따른 실행 (execution) 단계로 나눕니다. 모델은 먼저 상위 수준의 계획을 제안하고, 이어서 하네스가 파일 시스템 (file-system) 또는 터미널 (terminal) 도구를 호출하여 점진적인 변경 사항을 적용하며, 마지막으로 모델은 관찰된 상태를 바탕으로 계획을 수정합니다. 이 루프 (loop)를 통해 에이전트는 최종 편집을 확정하기 전에 가설을 검증하고, 테스트를 실행하며, 전략을 조정할 수 있습니다. 비용 측면에서는 지연 시간이 길어지고 토큰 소비 (token consumption)가 늘어나지만, 복잡한 리팩터링 (refactor)에서의 성공률은 극적으로 향상됩니다.

Cursor의 Composer 기능은 워크스페이스 (workspace)의 서로 다른 부분에 걸쳐 AI 기반 편집을 조정함으로써 여러 파일을 동시에 편집할 수 있게 해줍니다.

문서에 따르면 “Cursor의 Composer 기능은 워크스페이스의 서로 다른 부분에 걸쳐 AI 기반 편집을 조정함으로써 여러 파일을 동시에 편집할 수 있게 해줍니다.” Cursor 제품 문서
이러한 능력은 하네스가 워크스페이스에 대한 지속적인 뷰 (persistent view)를 유지할 수 있을 때만 가능하며, 이는 일반적으로 단일 턴 에이전트가 결여하고 있는 부분입니다.

다단계 에이전트의 실질적인 한계는 코드베이스 수준의 검색에 사용되는 시스템 전체의 컨텍스트 윈도우 (context window)입니다. Cursor는 인덱싱된 파일 세트를 10,000 토큰으로 제한하며, 이는 추가적인 페이징 (paging) 없이 저장소(repository)의 어느 정도 분량까지 참조할 수 있는지를 결정합니다.