하나의 SDLC 파이프라인에서 로컬 LLM, Claude Code, Codex, Gemini 등을 혼합하여 사용하기 (오픈 소스)
요약
단일 모델 대신 SDLC의 각 단계(계획, 구현, 검토 등)에 최적화된 다양한 LLM을 혼합하여 사용하는 오픈 소스 파이프라인을 소개합니다. 로컬 모델과 호스팅 모델을 결합하여 성능을 높이고 비용을 최대 75%까지 절감할 수 있음을 벤치마크로 증명했습니다.
핵심 포인트
- SDLC 단계별로 특화된 모델(DeepSeek-R1, Claude Code, Qwen-Coder 등)을 독립적으로 사용 가능
- 작성자와 검토자를 다른 모델로 설정하여 자기 승인 오류 방지
- Claude Code 단독 사용 대비 대규모 저장소 작업에서 더 높은 성능 기록
- 반복적인 저장소 탐색을 줄여 비용을 7%에서 75%까지 절감
- OpenAI 호환 엔드포인트 및 Ollama를 통한 로컬 모델 지원
많은 AI 코딩 도구들은 하나의 모델이 모든 것을 수행해야 한다고 가정합니다: 작업을 이해하고, 코드를 작성하고, 이를 검토하며, 그것이 올바른지 결정하는 것까지 말이죠. 저는 그 반대의 아이디어를 바탕으로 무언가를 구축하게 되었습니다. 하나의 모델이 소프트웨어 개발 생명주기 (SDLC) 전체를 수행하는 대신, 각 단계마다 완전히 다른 모델을 사용할 수 있습니다. 이는 로컬 LLM (Local LLMs)과 호스팅된 모델 (Hosted models)을 원하는 대로 혼합할 수 있음을 의미합니다. 예를 들어:
- 계획 (Planning)을 위해 로컬에서 실행되는 DeepSeek-R1
- 구현 (Implementation)을 위한 Claude Code
- 검토자 (Reviewer)로서 Ollama에서 실행되는 Qwen-Coder
- 다른 프로젝트를 위한 Gemini CLI
- 오직 코딩 단계만을 위한 Codex
- 또는 당신이 선호하는 어떤 조합이든 가능합니다.
각 단계는 독립적이므로, 특정 제공업체나 특정 모델 제품군에 종속되지 않습니다. 만약 이미 Claude Code, Codex, Cursor, Aider 또는 Gemini CLI와 같은 도구를 사용하고 있다면, 코딩 단계에서는 API 키조차 필요하지 않습니다. AutoDev Studio는 기존 로그인을 통해 이 도구들을 헤드리스 (Headlessly) 방식으로 구동할 뿐입니다. 한편, 다른 단계들은 Ollama 또는 모든 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 통해 완전히 로컬 모델에서 실행될 수 있습니다. 검토자 (Reviewer)는 의도적으로 작성자 (Author)와 다른 모델 제품군으로 설정되어, 동일한 모델이 자신이 작성한 코드를 스스로 승인하는 일이 발생하지 않도록 했습니다. 이것은 처음부터 설계 목표 중 하나였습니다.
파이프라인 자체는 다음과 같습니다:
- PM 에이전트가 명확화 루프 (Clarification loop)를 실행하고 구현 티켓 (Implementation tickets)을 생성합니다
- 선택 사항으로 Jira 동기화 수행
- Dev 에이전트가 격리된 브랜치에서 구현을 진행합니다
- QA가 저장소의 실제 테스트를 실행합니다
- 검토자가 차이점 (Diff)을 검증합니다
- QA 또는 검토가 실패할 경우 제한된 수정 루프 (Bounded revise loop)를 실행합니다
- 사람이 병합할 수 있도록 실제 풀 리퀘스트 (Pull request)를 생성합니다
모든 단계는 자체적인 토큰 (Tokens), 실행 시간 (Runtime) 및 비용 (Cost)을 기록합니다. 제가 이것을 처음 만든 이유는 하나의 모델에게 모든 것을 요구하는 대신, 실제로 의미가 있는 곳에 특화된 모델 (Specialised models)을 사용하는 실험을 하고 싶었기 때문입니다.
제가 사용해 온 몇 가지 예시는 다음과 같습니다:
- 로컬 추론 모델 (local reasoning model) → 계획 (planning)
- Claude Code → 구현 (implementation)
- 로컬 Qwen-Coder → 리뷰 (review)
- 로컬 임베딩 모델 (local embedding model) → 저장소 인덱싱 (repository indexing)
결과적으로 저를 놀라게 했던 벤치마크 결과는, 두 개의 대규모 Python 저장소(35k 및 82k LOC)에서 튜닝된 파이프라인이 잘 위치된(well-localised) 6가지 작업 모두에서 Claude Code를 단독으로 실행했을 때보다 성능이 뛰어났으며, 반복적인 저장소 탐색을 피함으로써 비용을 7%에서 75%까지 절감했다는 점입니다. 물론 항상 승리하는 것은 아닙니다. 아주 작은 한 줄짜리 수정은 단일 에이전트를 사용하는 것이 더 저렴한 경우가 많으며, 저는 이러한 실패 사례들도 벤치마크에 포함했습니다.
기타 몇 가지 특징:
- 로컬 모델과 호스팅된 모델 모두와 작동
- OpenAI 호환 엔드포인트 (OpenAI-compatible endpoints) 지원
- 완전히 오프라인 워크플로우를 원하는 경우 무료 로컬 모델로 실행 가능
- 언어에 구애받지 않는 파이프라인 (language-agnostic pipeline)
- 스트리밍되는 에이전트 로그가 포함된 라이브 대시보드
- 단계별 비용 및 실행 시간 추적
- MIT 라이선스
리포지토리 (Repo): https://github.com/krishagarwal314/autodev-studio
이 프로젝트는 아직 초기 단계의 사이드 프로젝트이므로, 진심으로 피드백을 받고 싶습니다. 특히 로컬 모델을 실험하고 계신 분들의 의견을 기다립니다. 더 나은 모델 조합에 대한 아이디어가 있거나, 개별 단계에 다른 로컬 LLM을 사용해보고 싶거나, 파이프라인이 제대로 작동하지 않는 부분을 발견하신다면 이슈(issue)나 토론(discussion)을 통해 알려주시면 정말 감사하겠습니다. 그리고 이 프로젝트가 흥미롭다고 생각하신다면, 스타(star)를 눌러주시는 것도 큰 힘이 됩니다.
/u/Neighborhood8510이 r/MachineLearning에 제출함 [link] [comments]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/OpenAI Codex (search)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기