Claude Code를 차갑게 실행했을 때, 82,000줄 규모의 저장소(repo)에서 버그 하나를 찾는 데 6.83달러와 207회의 턴(turn)이 소요되었습니다. 저의 파이프라인은 동일한 버그를 로컬라이징(localization)하고 수정하는 데 약 1.70달러를 사용했습니다. 그 격차가 바로 이 프로젝트의 핵심 아이디어이며, 이 포스트는 주로 모든 사람이 제기하는 두 가지 반론에 부딪히지 않고 어떻게 그 결과에 도달했는지에 관한 것입니다. 먼저 짧은 면책 조항을 말씀드리자면, 이것은 제품이 아닌 사이드 프로젝트이며, 아직 제가 발견하지 못한 거친 부분들이 분명히 있을 것입니다. 저는 단순히 멋지다는 말을 듣기보다, 어디서 작동이 깨지는지에 대한 의견을 진심으로 듣고 싶습니다.

이것이 무엇인가
AutoDev Studio를 Git 저장소(repo)로 지정하고, 변경 사항을 평이한 영어로 설명하면, 에이전트 체인(chain of agents)이 요청부터 검토된 풀 리퀘스트(pull request)까지 실제 소프트웨어 생명 주기(software lifecycle)를 실행합니다:

• PM 에이전트가 명확화 루프(clarify loop)를 실행하고 구체적인 티켓(ticket) 초안을 작성합니다.
• 사용자가 승인하면(선택적으로 Jira로 전송), 그 전까지는 코드에 아무것도 건드리지 않습니다.
• Dev 에이전트가 격리된 브랜치(branch)에서 구현을 수행합니다.
• QA가 저장소의 실제 테스트를 실행합니다.
• 다른 모델 패밀리(model family) 출신의 리뷰어가 디프(diff)를 확인하므로, 작성자가 자신의 코드를 스스로 승인하는 일이 발생하지 않습니다.
• QA 또는 리뷰가 실패할 경우, 보수적인 판정을 내리는 제한된 수정 루프(bounded revise loop)를 실행하여, 오류가 있거나 모호한 체크가 통과로 간주되지 않도록 합니다.
• 실제 PR을 생성하며, 사람이 이를 머지(merge)합니다.

모든 단계는 티켓별, 에이전트별로 실제 토큰(token), 비용, 소요 시간을 기록합니다.

기술이나 서브 에이전트(subagents)와 차별화되는 지점이라고 생각하는 부분
이 부분은 제가 가장 피드백을 받고 싶은 부분입니다. 왜냐하면 단순히 몇 가지 기술을 하나의 코딩 에이전트에 연결하고 끝내지 않은 이유가 바로 이것이기 때문입니다. 모든 단계는 각자 자신의 프로바이더(provider)와 모델을 선택합니다. Claude는 계획을 세울 수 있고, Codex는 코드를 작성할 수 있으며, 세 번째 모델은 리뷰를 할 수 있습니다. 그리고 리뷰어가 작성자와 의도적으로 다른 모델 패밀리이기 때문에, 한 모델이 자신의 디프(diff)를 무조건 승인(rubber-stamp)하는 일이 발생하지 않습니다. 이는 동일 모델 LLM 판독기(LLM judges)의 문서화된 약점입니다. 그리고 이를 위해 대부분 API 키가 필요하지 않습니다. 코딩 단계는 각자의 로그인을 통해 헤드리스(headless) 방식으로 구동되는 Claude Code, Codex, Cursor, Aider 또는 Gemini CLI에서 네이티브로 실행될 수 있습니다.

이미 Claude Code나 Codex를 결제하여 사용 중이라면, 특정 단계를 해당 도구로 지정하기만 하면 됩니다. 그러면 토큰당 과금이나 여러 개의 키를 관리할 필요 없이 기존 구독을 그대로 사용하게 됩니다. 제가 생각하는 간단한 차이점은 이렇습니다. 스킬 팩(skill pack) 방식은 특정 벤더의 에이전트 내부에 존재하며 해당 벤더의 모델을 모든 곳에서 실행하는 반면, 이 방식은 여러분이 이미 보유한 로그인 계정을 사용하여 각 단계마다 서로 다른 모델을 사용하여 여러 벤더에 걸쳐 실행됩니다.

결과 (핵심 사항)
핵심 아이디어는 변경 사항이 어디에 적용될지 찾는 비용을 매 작업마다 지불하는 대신, 단 한 번만 지불하는 것입니다. 두 개의 대규모 Python 저장소(35k 및 82k 라인)를 대상으로 한 벤치마크에서, 튜닝된 파이프라인은 잘 로컬라이징된(well-localized) 6개의 작업 모두에서 콜드 싱글 에이전트(cold single-agent) 실행보다 7%에서 75% 사이로 더 저렴하면서도 더 나은 성능을 보였습니다. 제가 승리하지 못하는 부분에 대해서도 솔직하게 말씀드리고자 합니다. 단순히 grep으로 찾을 수 있는 한 줄짜리 수정 작업의 경우, 5단계의 오버헤드 비용이 절감액보다 더 클 수 있으며, 하나의 어려운 교차 기능(cross-cutting) 버그에 대해서는 베이스라인보다 저렴하지만 범위가 더 좁은 수정안을 내놓았습니다. 전체 벤치마크 보고서에는 모든 실패 사례도 기록되어 있으므로, 승리 사례를 신뢰하기 전에 반드시 해당 내용을 읽어보시기 바랍니다.

"몇 번의 커밋만 지나도 인덱스가 오래되어 쓸모없어진다"는 반론에 대하여
이것은 사람들이 상당히 타당하게 제기하는 첫 번째 의문입니다. 따라서 솔직한 메커니즘을 쉬운 용어로 설명하겠습니다. Dev 에이전트를 위해 실제로 파일을 고정(pin)하는 레이어는 벡터 인덱스(vector index)가 아닙니다. 그것은 매 실행 시작 시 최신 커밋으로 다시 동기화되는 결정론적 심볼 맵(deterministic symbol map)이며, 여기에 현재 작업 복사본에 대한 라이브 grep(live grep)과 프롬프트에 입력되는 실제 현재 파일 내용이 추가됩니다. 임베딩(embeddings)은 어떤 영역을 먼저 살펴볼지에만 영향을 미치며, 실행 시 변경된 모듈별로 새로 고침됩니다. 따라서 에이전트가 수정하는 코드는 3번의 커밋 전 스냅샷이 아니라, 바로 지금 디스크에 있는 코드입니다. 로컬라이징을 하기 전에 다시 확인하므로 조용히 정보가 어긋나는(drift) 일이 발생하지 않습니다.

실제 대상 사용자
지식 베이스(knowledge base)는 저장소당 한 번 발생하는 비용이며, 이후의 모든 작업이 이 비용을 분할 상환(amortize)합니다. 따라서 동일한 대규모 코드베이스를 대상으로 변경 사항을 계속해서 배포하는 팀에게 적합합니다. 이러한 환경에서 콜드 에이전트(cold agent)는 매번 탐색 비용을 다시 지불해야 하기 때문입니다.

작고 찾기 쉬운 수정 사항들이 연속되는 스트림의 경우, 콜드 런(cold run)이 여전히 더 저렴하며, 과장하기보다는 그렇게 말하는 편이 맞을 것입니다.

실제로 제가 사용하는 방식
참고 삼아 말씀드리자면, 저는 이제 대부분의 경우 일반적인 claude -p 대신 이 도구를 선택합니다. 이것이 어떤 면에서 더 똑똑하기 때문이 아닙니다. 터미널을 계속 스크롤해서 올라가는 대신, 보드(board)를 훑어보는 것만으로 각 변경 사항이 실제로 어디에 있는지 확인할 수 있고, 서로 다른 계열의 리뷰어(reviewer)가 Claude가 자체적인 디프(diff) 과정에서 조용히 그냥 지나쳐 버린 것들을 잡아내며, 제가 매일 다루는 리포지토리(repo)의 경우 매 실행마다 코드베이스를 다시 학습하는 비용을 지불할 필요가 없기 때문입니다. 이 도구는 제가 기존에 사용하던 Claude Code 및 Codex 로그인 정보를 그대로 사용하므로, 어차피 사용했을 코딩 에이전트(coding agent) 주변에 이러한 구조를 갖추는 데 추가 비용이 들지 않습니다. 이것이 제가 이 도구를 계속 사용하는 진짜 이유입니다.

기타 특징들:

• 별도의 설정 없이 무료 티어에서 바로 실행 가능 (Groq 및 로컬 임베딩 모델(local embedding model) 사용), 따라서 비용 부담 없이 완전 오프라인으로 테스트 가능
• 언어에 구애받지 않는 파이프라인 (Python은 정확하게 파싱되며, 다른 언어들은 미지의 언어에서 차단되는 대신 오류를 허용하는(fail open) 더 가벼운 추출기(extractor)를 통해 처리)
• 에이전트 로그가 스트리밍되는 라이브 보드 및 티켓별 실제 비용 계산 기능
• 독립형 구조, CDN 미사용, 테스트 및 CI 포함, MIT 라이선스 리포지토리

스크린샷과 전체 벤치마크(benchmark)는 README에서 확인하실 수 있습니다: https://github.com/krishagarwal314/autodev-studio

아직 초기 단계이며 곳곳이 거칠기 때문에, 더 많은 분이 살펴봐 주셨으면 합니다. 단계별 모델(per-stage-models) 아이디어나 데이터 신선도 처리(staleness handling)에 대한 의견이 있으시거나, 리포지토리에 적용했을 때 작동이 멈춘다면 이슈(issue)를 남겨주시는 것이 큰 도움이 됩니다. 제안, PR(Pull Request), 그리고 솔직히 팔로우할 가치가 있다고 생각되신다면 스타(star)를 눌러주시는 것만으로도 감사하겠습니다. 읽어주셔서 감사합니다.

submitted by /u/NeighborhoodOwn8510 [link] [comments]