TL;DR: 단 하나의 최고 모델을 찾아 헤매는 것은 그만두세요. 눈앞에 있는 작업의 형태에 각 모델을 맞추면 됩니다. 아키텍처와 파일 간 리팩터링에는 깊은 추론, 보일러플레이트와 테스트에는 빠르고 저렴한 모델, 저장소 전체에 대한 질문에는 긴 컨텍스트, 여러 단계의 편집에는 안정적인 도구 사용이 필요합니다. 에이전트가 한두 개일 때는 터미널마다 모델을 직접 골라도 됩니다. 하지만 여러 저장소에 걸쳐 여러 작업을 돌리기 시작하면, 그 매핑은 머릿속이 아니라 저장해 둔 Agent에 있어야 합니다. 지금부터 그 지도와 실제 예시, 그리고 오늘 바로 실행해 볼 수 있는 체크리스트를 소개합니다.
터미널을 다섯 개 열어 두고 있습니다. 하나는 까다로운 리팩터링, 하나는 단위 테스트 묶음, 하나는 어렴풋이 기억하는 코드베이스에 대한 질문, 하나는 불안정한 통합 테스트 추적, 하나는 40개 파일에 걸친 심볼 이름 변경을 맡고 있습니다. 각 터미널은 같은 질문을 조용히 던집니다. "이 작업은 어떤 모델로 돌려야 하지?" 이름 변경 작업에 무거운 추론 모델을 투입하면, 빠른 모델이면 깔끔하게 끝낼 작업에 토큰과 시간을 낭비하게 됩니다. 아키텍처 변경에 빠른 모델을 투입하면 세 파일 떨어진 의존성을 놓칩니다. 반복되는 불만은 좀처럼 "모델이 나쁘다"가 아닙니다. "어떤 걸 써야 할지 모르겠다"입니다.
해결책은 리더보드가 아닙니다. 순위는 몇 주마다 바뀌고, 일반 벤치마크의 승자가 여러분의 특정 작업에는 오히려 잘못된 선택인 경우가 많습니다. 오래가는 방법은 모델을 작업의 형태에 맞추는 것입니다. 얼마나 많은 추론이 필요한지, 얼마나 많은 컨텍스트를 담아야 하는지, 도구를 얼마나 안정적으로 따라야 하는지, 실행당 얼마를 쓸 것인지. 이런 속성들은 모델 이름이 바뀌어도 거의 변하지 않습니다.
바로 여기서 작업 계층이 제 역할을 합니다. Sharkly는 올인원 Agent 명령 및 관리 플랫폼입니다. 코딩 에이전트 위에 자리 잡기 때문에 "어떤 작업에 어떤 모델"이라는 결정을 터미널마다 다시 내리지 않아도 됩니다. 역할, 런타임, 규칙을 재사용 가능한 구성인 Agent로 한 번 저장해 두고, 작업 형태에 맞는 Agent에 Task를 할당하면 됩니다. 여러분에게는 이미 코딩 에이전트가 있습니다. Sharkly는 그것들을 팀으로 만들어 줍니다.
리더보드가 아니라 작업의 형태에 모델을 맞추세요
모델 선택은 사실 순서대로 던지는 네 가지 질문입니다.
- 추론 깊이. 이 작업이 파일 전반에 걸친 다단계 계획을 필요로 하는가, 아니면 국소적이고 기계적인 변경인가? 아키텍처, 까다로운 리팩터링, 근본 원인 디버깅은 더 강력한 추론 모델에서 이득을 봅니다. 이름 변경, 포매팅, 스캐폴딩은 그렇지 않습니다.
- 컨텍스트 크기. 모델이 저장소 전체, 긴 명세, 거대한 로그를 한 번에 담아야 하는가? 코드베이스 전체에 대한 질문과 대규모 마이그레이션은 추론 깊이가 조금 덜하더라도 긴 컨텍스트 모델에서 이득을 봅니다.
- 도구 사용 안정성. 여러 단계의 작업(편집, 테스트 실행, 출력 읽기, 다시 편집)은 모델이 정해진 순서를 벗어나지 않고 도구를 얼마나 일관되게 쓰는지에 달려 있습니다. 추론은 훌륭하지만 테스트 실행을 잊는 모델은 이 경우 더 안정적인 모델보다 못합니다.
- 속도와 비용. 대량이면서 중요도가 낮은 작업(테스트, 보일러플레이트, 독스트링)은 기준을 통과하는 가장 빠르고 저렴한 모델에 맡겨야 합니다. 값비싼 추론은 그것이 결정적인 작업을 위해 아껴 두세요.
잘못된 한 단계가 오후 한나절의 디버깅을 잡아먹는다면 무거운 추론 모델을 사용하세요. 작업이 기계적이고 검증하기 쉬우면 빠르고 저렴한 모델을 사용하세요. 대부분의 날에는 서로 다른 작업에 두 가지 모두가 동시에 필요합니다. 그래서 단일 전역 모델 설정이 잘못된 느낌을 주는 것입니다. 서로 다른 답을 원하는 작업들에 하나의 답을 강요하니까요.
작업 유형에서 모델 역할로 이어지는 대략적인 지도
아래의 작업 이름들은 특정 모델 버전보다 오래갑니다. 분류를 특정 이름에 고정하기 전에 벤더의 최신 모델 카드를 확인하고, 분류는 그대로 유지하세요.
| 눈앞의 작업 | 최적화 대상 | 모델 역할 |
|---|---|---|
| 아키텍처, 파일 간 리팩터링, 설계 리뷰 | 추론 깊이 | 무거운 추론 모델 |
| 근본 원인 디버깅, 불안정한 테스트 추적 | 추론 + 안정적인 도구 사용 | 무거운 추론 모델 |
| 저장소 전체 Q&A, 대규모 마이그레이션, 긴 명세 작업 | 컨텍스트 크기 | 긴 컨텍스트 모델 |
| 단위 테스트, 보일러플레이트, 독스트링, 스캐폴딩 | 속도와 비용 | 빠르고 저렴한 모델 |
| 기계적인 이름 변경, 포맷, 대량 편집 | 속도 | 빠르고 저렴한 모델 |
| 다단계 에이전트 루프(편집, 테스트, 반복) | 도구 사용 안정성 | 안정적인 도구 사용자 |
솔직한 두 가지 참고 사항이 있습니다. 첫째, "무거운"이 "항상 더 낫다"는 뜻은 아닙니다. 이름 변경 작업에서 깊은 추론 모델은 빠른 모델보다 느리고 비쌀 뿐 아니라 정확하지도 않습니다. 둘째, Claude Code, Codex, Gemini CLI 같은 런타임은 자체 기본 모델을 가지고 있고, 모델 사용량은 도구에 구성된 구독이나 API 키를 통해 이어지므로, 실제 선택지는 팀이 이미 비용을 지불하고 있는 모델을 이 분류에 맞추는 것입니다. SWE-bench 같은 공개 작업 벤치마크는 모델이 대략 어느 계층에 속하는지 알려줄 뿐, 여러분의 특정 작업에 어떤 모델이 필요한지는 알려주지 않습니다.
터미널마다 모델을 고르는 방식이 확장을 멈추는 지점
에이전트가 한두 개라면 직접 고르는 것도 괜찮습니다. 터미널을 열고 모델을 설정하면, 두 개뿐이니 어디에 무엇이 있는지 기억할 수 있습니다. 오늘 통하는 구성은 사람 한 명과 도구 두어 개입니다.
문제는 양이 늘어날 때 시작됩니다. 세 개 저장소에 걸쳐 여섯 개 작업을 돌리면 모델-작업 매핑이 이제 머릿속에 살게 됩니다. 어느 터미널이 저렴한 모델인지, 지난 화요일에 어느 저장소를 추론 모델로 설정했는지, 마이그레이션이 왜 기어가는지(빠른 모델에 그대로 두었으니까). 동료가 여러분의 작업을 이어받을 때 그 매핑은 작업과 함께 따라가지 않습니다. 여러분의 기억에 남아 있고, 결과는 공유되는 곳으로 돌아가지 않고 개인 터미널에 흩어집니다.
Agent는 어떤 종류의 작업을 어떻게 처리해야 하는지를 저장해 둔 구성입니다. 역할, 런타임과 그 모델, 그리고 그에 따르는 규칙으로 이루어집니다. 터미널마다 모델을 다시 결정하는 대신, Agent를 한 번 만들어 두고("Test Writer"는 빠른 모델로, "Refactorer"는 추론 모델로) 작업 형태에 맞는 Agent에 Task를 할당합니다. 모델 선택이 기억력 싸움이 아니라 재사용 가능한 것이 됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고 결과를 승인합니다. 실행, 장애 요소, 결과가 Task로 돌아오므로 각 모델 선택의 근거가 요청부터 릴리스까지 드러나고, 스크롤백 속에 묻히지 않습니다.
Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 돌리고 있는 모델 주위에 공유 작업, 컨텍스트, 리뷰 계층을 더해 줍니다. 터미널 하나에서 에이전트 하나만 돌린다면 필요하지 않습니다. 여러 에이전트를 병렬로 돌리기 시작하면, 모델 매칭 결정이야말로 저장해 둘 가치가 있는 것입니다.
실제 예시: 세 개의 작업, 세 개의 Agent
한 스프린트에서 세 개의 작업이 큐에 들어왔다고 해 봅시다.
- SH-312: 저장소 전체에서
UserSession을AuthSession으로 이름 변경. 기계적이고 검증하기 쉽습니다. 빠르고 저렴한 모델을 쓰는 "Renamer" Agent로 보내세요. 편집하고, 타입 검사기를 실행하고, 깔끔한 diff를 반환합니다. 여기에 추론 모델 토큰을 쓰는 것은 아무 소득이 없습니다. - SH-318: 결제 흐름이 재시도 시 이중 청구됨. 서비스 전반에 걸친 근본 원인 디버깅입니다. 안정적인 도구 사용을 갖춘 무거운 추론 모델 기반의 "Debugger" Agent로 보내세요. 계획을 세우고, 로그를 읽고, 가설을 세우고, 검증해야 합니다. 여기서 빠른 모델은 추측만 하고 리뷰 주기를 낭비합니다.
- SH-324: "우리 빌링은 Stripe와 어떻게 대사되나요?"라는 질문에 코드베이스에서 답하기. 저장소 전체에 대한 질문입니다. 관련 파일을 한 번에 담을 수 있는 긴 컨텍스트 모델 기반의 "Codebase Analyst" Agent로 보내세요.
각 Agent는 자체 격리된 worktree에서 실행되므로 세 모델이 세 작업을 서로 방해하지 않고 동시에 처리합니다. 각 결과는 변경 요약과 근거를 담아 해당 Task로 돌아옵니다. 기억을 더듬어 재구성해야 하는 터미널 세 개가 아니라, 완료된 산출물 세 개를 리뷰하는 것입니다. 자동화는 여러분의 판단이 필요한 지점에서 멈춥니다. 승인하거나, 변경을 요청하거나, 병합 여부를 결정하는 것은 여러분입니다.
오늘 바로 실행해 볼 수 있는 체크리스트
다음 에이전트 작업 묶음을 시작하기 전에 이걸 실행해 보세요.
- [ ] 각 작업에 대해 먼저 그 형태를 정하세요. 추론 중심, 컨텍스트 중심, 도구 루프 중심, 대량 기계 작업 중 어느 것인가?
- [ ] 그 형태에 대한 기준을 통과하는 가장 저렴한 모델을 배정하세요. 추론 모델은 잘못된 단계가 실제 시간을 잡아먹는 작업을 위해 남겨 두세요.
- [ ] 긴 컨텍스트 작업은 습관적으로 즐겨 쓰는 추론 모델이 아니라 긴 컨텍스트 모델에 맡기세요.
- [ ] 다단계 루프에서는 벤치마크 순위보다 도구 사용 안정성에 더 비중을 두세요.
- [ ] 매핑을 역할별 재사용 가능한 Agent로 한 번 적어 두어, 여러분과 동료가 터미널마다 다시 결정하지 않도록 하세요.
- [ ] 최종 승인은 사람이 맡으세요. 경로는 모델이 고르고, 결과는 여러분이 승인합니다.
모델을 작업에 맞추고, 그 매칭을 Agent로 저장하면, 이 글을 시작하게 한 질문("어떤 걸 써야 하지?")은 터미널마다가 아니라 역할마다 한 번만 답하면 됩니다.
모든 것에 하나의 모델을 쓰기로 정하기보다 여러 코딩 에이전트를 계속 사용하고 싶다면, 그것이 바로 Sharkly가 겨냥해 만들어진 문제입니다. 터미널마다 모델을 직접 고를 수도 있고, 아니면 전체 워크플로를 한곳에서 관리하며 각 결과가 Task로 돌아오게 할 수도 있습니다.
FAQ
가장 순위가 높은 모델을 모든 작업에 쓰면 되지 않나요? 아닙니다. 최상위 범용 모델은 기계적인 작업에서 필요 이상으로 느리고 비쌀 뿐 아니라 정확하지도 않습니다. 순위는 모델이 어느 계층에 있는지 알려줄 뿐이고, 필요한 계층은 작업의 형태가 알려줍니다. 둘을 맞추는 것이 리더보드 1위를 기본값으로 삼는 것보다 낫습니다.
작업의 난이도를 아직 모를 때는 어떻게 모델을 고르나요? 저렴하게 시작하고 올려 가세요. 먼저 빠른 모델에 작업을 맡기세요. 멈추거나, 추측하거나, 리뷰에서 실패하면 그것이 작업이 추론 중심이라는 신호이고, 더 강한 모델로 승격시키면 됩니다. 휴먼 인 더 루프 리뷰 단계에서 배포 전에 불일치를 잡아낼 수 있습니다.
Sharkly가 모델을 대신 골라 주나요? Sharkly는 스스로 모델을 고르지 않습니다. Agent를 만들 때 역할을 런타임과 그 모델에 연결하고, 작업 형태에 맞는 Agent에 Task를 할당하는 것은 여러분입니다. 선택은 여러분의 것이고, Sharkly는 그것을 재사용 가능하게 만들고 모든 실행 결과를 개인 터미널이 아니라 Task에 남깁니다.
