Dirac: 비용 64% 절감하면서 8/8 완벽 정확도를 달성한 오픈소스 AI 코딩 에이전트 (id.news.hada.io)

한줄 요약

오픈소스 AI 코딩 에이전트 Dirac, 평균 $0.18로 8/8 완벽 정확도·64.8% 비용 절감 동시 달성.

무엇이 달라지나?

AI 코딩 에이전트 시장에서 성능과 비용은 대개 트레이드오프 관계로 여겨진다. Dirac은 이 전제를 정면으로 반박하는 오픈소스 프로젝트다.

Dirac은 Gemini-2.5-flash-preview 모델 기반으로 Terminal-Bench-2에서 65.2%를 기록했고, GitHub 공개 저장소 8개 복잡한 리팩토링 태스크에서 8/8 성공률을 달성했다. 같은 벤치마크에서 8/8을 달성한 도구는 Dirac과 Opencode 두 가지뿐이다. 그런데 비용 면에서는 차이가 뚜렷하다. Dirac의 평균 처리 비용은 $0.18로, Cline $0.49, Kilo $0.73, Opencode $0.44 등 경쟁 도구 대비 64.8% 저렴하다. README 기준으로 약 2.8배의 비용 절감 효과다.

태스크별로 보면, HuggingFace의 transformers 저장소 DynamicCache 태스크에서 $0.13, Django의 datadict 태스크에서 $0.08, VSCode의 sendRequest 태스크에서 $0.25를 기록했다. 경쟁 도구 일부가 Incomplete 또는 Failure로 표시된 태스크에서도 Dirac은 전부 Success였다.

이 성과의 배경에는 세 가지 핵심 설계 원칙이 있다.

Hash-Anchored Edits: 기존 코드 편집 방식은 줄 번호 기반으로 동작하기 때문에 컨텍스트가 길어질수록 위치가 어긋나는 문제가 생긴다. Dirac은 안정적인 라인 해시를 기준으로 수정 위치를 특정해 이 문제를 원천 차단한다.

Multi-File Batching: 여러 파일을 단일 LLM 왕복(round-trip)으로 처리해 API 호출 횟수와 레이턴시를 동시에 줄인다. 리팩토링처럼 다수의 파일을 건드려야 하는 작업에서 효과가 두드러진다.

High-Bandwidth Context: 가장 관련성 높은 정보만 컨텍스트에 유지하는 방식으로 토큰 낭비를 억제한다. 긴 컨텍스트에서 추론 성능이 흔들리는 LLM의 고질적 문제를 완화하는 접근이다.

여기에 TypeScript, Python, C++ 문법 구조를 이해하는 AST-Native Precision이 결합되어, 함수 추출이나 클래스 리팩토링 같은 구조적 조작을 언어 문법을 인식한 채로 수행한다.

실무에서 어떤 의미인가?

Dirac은 Cline을 포크해 개발된 오픈소스 프로젝트로, Apache License 2.0을 따른다. 즉 상업적 활용도 가능한 구조다.

CLI 사용 방식은 간결하다. dirac auth로 인증 후 dirac "프롬프트"로 바로 작업을 시작할 수 있다. Plan Mode(-p 플래그)로 전략을 먼저 검토하거나, Yolo Mode(-y 플래그)로 모든 액션을 자동 승인하는 방식도 지원한다. git diff | dirac "Review these changes" 같은 파이프 입력도 가능해 기존 개발 워크플로와 자연스럽게 통합된다. 이전 작업 이력은 dirac history로 불러와 이어서 진행할 수 있다.

VS Code 익스텐션도 Marketplace에서 설치 가능하다. Anthropic, OpenAI, OpenRouter 등 여러 AI 제공자를 선택해 연결할 수 있고, 프로젝트별 AGENTS.md 파일로 동작을 커스터마이징하는 것도 된다. .ai, .claude, .agents 디렉터리는 자동으로 읽혀 Claude skills도 활용 가능하다.

AWS Bedrock 연동도 지원한다. 관련 환경 변수를 설정하면 자동으로 Bedrock 프로바이더로 전환된다. 단, Sonnet 4.6 이상 최신 Claude 모델은 us., eu., ap. 같은 cross-region inference profile prefix가 필요하다.

한 가지 주목할 제약은 MCP(Model Context Protocol)를 지원하지 않는다는 점이다. 지원 모델도 native tool calling이 가능한 경우로 한정된다. 신뢰성과 성능을 위한 의도적 선택으로 보이지만, 기존에 MCP 기반 워크플로를 구축한 팀이라면 사전에 확인이 필요하다.

도입 전 체크포인트

Dirac은 분명히 매력적인 수치를 보여준다. 그러나 몇 가지 맥락을 함께 살펴볼 필요가 있다.

첫째, 벤치마크는 8개 태스크 기준이다. 표본 크기가 크지 않으므로 다양한 실무 환경에서의 일반화 가능성은 직접 검증이 필요하다. 둘째, 비용 비교는 동일 모델 기준이 아닐 수 있다. 도구마다 기본으로 사용하는 모델이 다르기 때문에 단순 수치 비교만으로 효율성을 단정하기는 어렵다. 셋째, MCP 미지원은 특정 팀에게 실질적 제약이 될 수 있다. 넷째, Cline 포크 프로젝트인 만큼 커뮤니티 규모나 장기 유지보수 지속성은 시간을 두고 지켜볼 필요가 있다.

반면, 오픈소스로 직접 코드를 확인할 수 있고, AWS Bedrock을 포함한 다양한 프로바이더를 지원한다는 점은 엔터프라이즈 환경에서도 검토해볼 여지를 만든다.