프런티어 모델로 계획하고 로컬에서 토큰 대부분을 처리하는 에이전트 (듀얼 3090 환경용으로 직접 제작)

지난 몇 달 동안 개인적으로 쓸 툴을 하나 만들었어. RTX 3090 두 개 박은 시스템이 있는데, 이걸 좀 써먹고 싶었거든. 근데 qwen 3.5/3.6 27B나 Gemma 4 31B 같은 모델들이 성능은 괜찮아도 프론티어 모델 특유의 감각이나 능력은 좀 부족하더라고.

반면에 프론티어 모델은 비싸기도 하고, 내가 하는 모든 작업을 거기다 다 돌리고 싶진 않았어. 그래서 두 마리 토끼를 다 잡고 싶었지. 계획 짜는 건 프론티어 모델한테 맡기고, 실제 작업은 로컬 모델이 다 처리하게 만드는 식으로 말이야.

작은 모델들이 프론티어 모델을 '호출'해서 체급 이상의 성능을 내게 해주는 레포들도 몇 개 써봤는데, 내가 원하던 건 그게 아니었어. 지난 10년 넘게 소프트웨어 엔지니어링을 하면서 느낀 건데, 결국 프로젝트의 병목은 설계에서 오거든. 설계가 제대로 안 되면 나중에 스파게티 코드 되고 다 뜯어고쳐야 하니까, 프론티어 모델로 설계를 확실하게 하고 싶었어.

그래서 에이전트를 하나 만들었는데, 시행착오를 엄청 겪은 끝에 지금은 개인적으로 아주 잘 쓰고 있어.

이 에이전트의 핵심은 이거야 (이미 있는 툴들을 많이 활용해서 바퀴를 다시 발명하진 않았어). 근데 전부 커스텀이 가능해.

3단계 계층 구조로 되어 있고, 설정 파일로 다 바꿀 수 있어:

• Planner: Codex (존나 강력함; 결정 내리는 JSON만 뱉어주면 뭐든 상관없음)
• Local: Qwen 3.6 27B (에이전트 용도나 툴 호출에 최적이고, 코딩도 충분히 잘함)
• Senior (선택 사항): Kimi K2.6 via opencode-go (로컬 모델이 실패하고 재시도 횟수 다 썼을 때 투입)

3단계 전부 로컬로 돌려도 되고, 2단계만 로컬로 하거나, 프론티어 하나에 로컬 하나 섞는 식으로 조합은 마음대로야. 난 이게 제일 잘 돌아가더라고.

모든 작업은 Codex로 넘어가고, 거기서 N개의 단계로 쪼개져. 예를 들어 큰 코딩 작업이면 보통 3단계(조사, 구현, 검토)로 나뉘는 식이지.

리뷰 작업도 마찬가지로 단계별(리뷰, 아티팩트 생성)로 진행돼.

각 단계는 여러 에포크를 돌 수 있는데, 각 에포크마다 로컬 모델이 처리할 작업들이 나오고, 이 모든 계획은 Codex가 짜는 거야.

가장 큰 차별점은 결정론적 검증(deterministic validation)이야. 작업이 끝났다고 치는 건 오직 체크를 통과했을 때뿐이야. 즉, 명령어가 0을 반환하거나, 만들어야 할 파일이 실제로 존재해야만 완료로 간주해. 모델이 지가 다 했다고 구라치는 걸 믿는 게 아니라, 상태 머신이 직접 검증을 다시 돌려버려. 그래서 몇 시간씩 걸리는 작업 체인이 진행 상황을 날려 먹는 일이 없지.

이 방식으로 로컬 모델 성능을 훨씬 더 끌어올릴 수 있었어:

1. 몇 시간씩 걸리는 작업도 가능해짐.
2. 프론티어 모델의 감각과 능력을 가져가면서도, 내 측정 기준 토큰의 85~90%는 로컬 모델이 처리함. 출력 토큰은 95% 정도가 로컬임.
3. 컨텍스트 격리가 돼서 컨텍스트 오염을 막아줌. bash 호출 때문에 컨텍스트 윈도우가 터질 일이 없으니 프론티어 모델 비용도 훨씬 아껴짐.
4. 기본적으로 유용한 기능도 몇 개 있음: repomapper를 써서 레포를 그래프로 매핑하고, 로컬 모델이 쓸데없는 파일에 파묻히지 않게 컨텍스트를 꽤 빡세게 관리함.

아직 만드는 중이긴 한데, 이제는 쓸만한 단계까지는 왔어. 혹시 써보고 싶은 사람 있어? (레포는 첫 번째 댓글에 달아둘게)

좀 지저분한 점들:

설치: 깔끔하지 않음. pi나 opencode 같은 기존 오픈소스 소프트웨어를 이것저것 섞어 써서 그래.

UI 없음: 그냥 상태 업데이트 보여주는 간단한 TUI가 달린 셸 명령어일 뿐이야. 직접 job.md 파일을 만들거나, 에이전트가 만들게 시켜야 해.