프론티어 모델로 계획을 세우고 대부분의 토큰은 로컬에서 실행하는 에이전트 (나의 dual-3090 시스템을 위해 구축함)

지난 몇 달 동안 저는 개인적인 용도로 사용할 도구를 만들어 왔습니다. 저는 dual RTX 3090 시스템을 보유하고 있어 이를 활용하고 싶었지만, Qwen 3.5/3.6 27B와 Gemma 4 31B는 매우 훌륭함에도 불구하고 프론티어 모델 (frontier model)이 가진 감각이나 능력을 갖추지는 못했습니다. 반면에 프론티어 모델은 비용이 많이 들며, 제가 하는 모든 작업이 그 모델들을 거치는 것을 원하지 않았습니다. 저는 두 세계의 장점을 모두 원했습니다. 즉, 계획을 세울 때는 프론티어 모델의 추론 (reasoning) 능력을 사용하고, 실제 작업의 거의 대부분은 로컬 모델 (local models)이 수행하는 방식입니다. 프론티어 모델을 '호출'하여 작은 모델들이 체급 이상의 성능을 내도록 하는 몇몇 리포지토리 (repos)를 시도해 보았지만, 제가 원한 것은 그것이 아니었습니다. 저는 프론티어 모델로 계획을 세울 수 있기를 원했습니다. 지난 10년 이상의 소프트웨어 엔지니어링 경험을 통해 설계 (design)가 대부분의 프로젝트에서 병목 현상을 일으키고 스파게티 코드 (spaghetti code)나 재작성을 유발한다는 것을 배웠기 때문입니다. 저는 에이전트 (agent)를 만들었고 많은 반복 과정을 거쳤지만, 이제는 완성되었다고 믿으며 개인적인 용도로 사용하고 있습니다. 이 에이전트의 핵심은 다음과 같습니다 (기존의 많은 도구들을 사용하며, 바퀴를 다시 발명하지는 않았습니다). 하지만 모든 것은 커스터마이징이 가능합니다. 설정 파일 (config file)을 통해 모두 교체 가능한 3단계 계층 (3 Tiers) 구조입니다:

• Planner (계획가): Codex (매우 강력함; 다만 결정 JSON을 출력할 수 있는 것이라면 무엇이든 여기서 작동함)
• Local (로컬): Qwen 3.6 27B (에이전트적 사용 및 도구 호출 (tool calling)에 훌륭하며, 코딩에 충분히 좋음)
• Senior (시니어, 선택 사항): opencode-go를 통한 Kimi K2.6 (로컬 모델이 실패하고 재시도 횟수가 소진되었을 때 사용)

3단계 모두를 로컬로 구성하거나, 2단계를 로컬로, 혹은 프론티어 하나와 로컬 하나 등 어떤 조합으로도 구성할 수 있습니다. 이것은 단지 제가 가장 잘 작동한다고 발견한 방식일 뿐입니다. 모든 작업은 Codex로 전달되며, Codex는 이를 N개의 단계 (phases)로 매핑할 수 있습니다. 예를 들어, 큰 코딩 작업은 보통 3단계(연구, 구현, 검토)로 매핑됩니다. 마찬가지로 검토 작업 또한 단계(검토, 결과물)로 나뉩니다. 각 단계는 여러 에포크 (epochs) 동안 반복될 수 있으며, 각 에포크는 로컬 모델이 수행할 작업들을 내놓습니다 (로컬 모델은 이를 매우 잘 수행합니다). 이 모든 것은 Codex에 의해 계획됩니다. 가장 큰 차별점은 결정론적 검증 (deterministic validation)입니다. 작업은 실제 체크가 통과했을 때만 완료된 것으로 간주됩니다. 즉,

명령어가 종료 코드 0을 반환하거나, 생성하기로 했던 파일이 실제로 존재하는 경우입니다. 상태 머신 (state machine)은 모델이 수행했다고 주장하는 내용을 그대로 믿는 대신, 스스로 이러한 체크를 다시 실행합니다. 따라서 수 시간 동안 이어지는 작업 체인이 실제로 이루지 않은 진전을 주장하며 경로를 이탈하는 일을 방지할 수 있습니다. 저는 이 방식이 로컬 모델의 능력을 평소보다 훨씬 더 뛰어나게 만들 수 있다는 것을 발견했습니다. 즉, 수 시간 동안 지속되는 작업을 수행할 수 있게 해줍니다. 프론티어 모델 (frontier model)의 맛과 능력을 갖추면서도, (제 측정 기준) 토큰의 약 85~90%는 로컬 모델을 통해 처리됩니다. 출력 토큰의 경우 약 95%에 달합니다. 컨텍스트 격리 (context isolation)를 통해 컨텍스트 부패 (context rot)를 방지하며, bash 호출로 인해 컨텍스트 윈도우 (context window)가 넘치지 않으므로 프론티어 모델 사용 비용이 훨씬 저렴해집니다. 또한 기본적으로 몇 가지 유용한 기능도 제공합니다. 리포 매퍼 (repomapper)를 사용하여 저장소를 그래프로 매핑하고, 로컬 모델이 무관한 파일들에 파묻히지 않도록 컨텍스트를 상당히 공격적으로 큐레이션 (curate)합니다. 아직 작업 중 (WIP)이지만, 마침내 사용 가능한 단계에 도달했습니다. 그래서 여러분이 이것을 써보고 싶어 하실지 궁금합니다 (저장소 링크는 첫 번째 댓글에 있습니다). 까다로운 점들: 설치: 매우 깔끔하지는 않습니다. pi, opencode 등 기존의 여러 오픈 소스 소프트웨어를 사용합니다. UI 없음: 상태 업데이트를 보여주는 간단한 TUI를 가진 쉘 명령일 뿐입니다. 직접 job.md 파일을 만들거나 (또는 에이전트가 만들게 하거나) 제출해야 합니다. submitted by /u/Poha_Best_Breakfast [link] [comments]