(1/5) Claude Code·Codex 를 온프렘으로 — 왜, 그리고 무엇을 갖춰야 하나
- 왜, 그리고 무엇을 갖춰야 하나 — 3층 구조와 손익분기 ← 지금 글
- 모델 고르기 — 어떤 오픈웨이트가 코딩 에이전트급인가
- 하드웨어와 서빙 — GPU·VRAM·양자화·vLLM 로 띄우기
- 하네스 연결 — 로컬 모델을 에이전트 CLI 에 물리기
- "완벽히 동일"의 조건 — 검증·남는 갭·하이브리드 운영
Summary
요즘 코딩 에이전트(Claude Code, Codex 같은 CLI 도구) 없이 개발하는 게 상상이 안 될 만큼 편해졌는데, 딱 하나 걸리는 게 요금이에요. 사람 여럿이 하루 종일 돌리면 API 청구서가 월 단위로 훅 올라가고, 그게 계속 누적되니까 어느 순간 “차라리 GPU 를 사서 사내에 깔면 되지 않나?” 하는 생각이 들죠.
그래서 이 시리즈에서는 코딩 에이전트를 통째로 온프렘(사내 GPU)으로 내리는 이야기를 처음부터 끝까지 해볼게요. 이번 1편은 그 전체 지도예요. 무엇을 대체해야 하는지, 그리고 어떤 조건이 다 갖춰졌을 때 클라우드와 “완벽히 동일한 방향”으로 쓸 수 있는지를 먼저 잡습니다.
💡 이 글에서 다루는 것
- 왜 코딩 에이전트는 유독 토큰(=돈)을 많이 먹는가
- Claude Code·Codex 를 3층으로 분해하기 — 모델 / 서빙 / 하네스
- 온프렘에서 “완벽히 동일”이 되려면 갖춰야 할 조건 체크리스트
- GPU 를 사는 게 언제 이득인가 — 손익분기 감각
- 5부작 로드맵
1. 왜 이렇게 비싼가 — 에이전트는 토큰을 폭식한다
먼저 왜 돈이 많이 나가는지부터 짚어야 대체 전략이 나와요. 상용 코딩 에이전트는 대부분 입력 토큰 + 출력 토큰으로 과금하는데, 에이전트 방식은 그 토큰을 유독 많이 씁니다.
- 매 턴마다 컨텍스트를 다시 실어요. 파일 내용, 도구 실행 결과, 대화 이력이 턴이 쌓일수록 커지고, 그게 매 요청마다 입력 토큰으로 다시 들어갑니다.
- 한 작업에 여러 번 왕복해요. “파일 읽고 → 수정하고 → 테스트 돌리고 → 실패 보고 다시 고치고”가 전부 별도 요청이에요. 사람이 질문 한 번 던지는 것과는 토큰 소모의 자릿수가 달라요.
- 리즌잉/사고 과정도 출력 토큰이에요. 요즘 모델은 답하기 전에 길게 생각하는데, 그 사고 토큰도 과금 대상인 경우가 많죠.
그래서 채팅으로 몇 마디 주고받는 것과 달리, 코딩 에이전트는 한 명이 하루만 굴려도 수백만~수천만 토큰이 우습게 나갑니다. 사람 수가 늘면 선형으로 늘고요. 이게 “감당이 안 되는” 청구서의 정체예요.
⚠️ 오해 하나 짚고 갈게요. 온프렘으로 옮긴다고 토큰을 덜 쓰는 게 아니에요. 토큰 소모량은 그대로거나 오히려 늘 수도 있어요. 달라지는 건 “토큰당 한계비용이 0 에 수렴한다”는 점이에요. 하드웨어를 한 번 사두면, 그 위에서 몇 토큰을 굽든 추가 청구서가 안 날아옵니다. 대신 고정비(장비·전력·운영)를 우리가 짊어지죠.
2. Claude Code·Codex 를 3층으로 분해하기
“온프렘으로 옮긴다”를 막연하게 두면 막막해요. 그런데 이 도구들을 뜯어보면 사실 세 개의 층이 겹쳐 있는 구조예요. 층을 나눠 놓으면 “어디를 우리 걸로 갈아끼워야 하는가”가 선명해집니다.
| 층 | 하는 일 | 상용 예시 | 온프렘 대체 |
|---|---|---|---|
| 모델 | 코드를 이해·생성하는 실제 지능 |
Claude, GPT 계열 |
오픈웨이트 모델 |
| 서빙 | 가중치를 GPU 에 올려 API 로 노출 |
클라우드가 대행 |
vLLM· SGLang 등 |
| 하네스 | 툴 실행·파일 편집· 에이전트 루프 |
Claude Code / Codex CLI |
오픈 CLI + 호환 API |
- 모델(가중치) — 진짜 “머리”예요. 이걸 우리 걸로 바꾸는 게 핵심이자 가장 어려운 부분입니다. 상용은 가중치를 안 주니까, 우리는 오픈웨이트(공개 가중치) 모델 중에서 코딩 에이전트급을 골라야 해요. (2편 주제)
- 서빙(추론 엔진) — 가중치 파일을 GPU 메모리에 올리고, 토큰을 생성해 OpenAI 호환 API 로 뱉어주는 계층이에요. 클라우드에선 이걸 알아서 해주지만, 온프렘에선 우리가
vLLM같은 엔진으로 직접 세웁니다. (3편 주제) - 하네스(에이전트 CLI) — 모델에게 “파일 읽어라 / bash 실행해라 / 검색해라” 같은 도구를 쥐여주고, 그 결과를 다시 모델에 먹여 다음 행동을 뽑는 에이전트 루프예요. Claude Code·Codex CLI 가 바로 이 계층이고, 여기엔 오픈소스 대안이 꽤 많아요. (4편 주제)
이렇게 보면 대체 작업은 결국 “모델을 오픈웨이트로, 서빙을 vLLM 으로, 하네스를 오픈 CLI 로” 세 칸을 채우는 일이에요. 그리고 이 세 칸을 잇는 접착제가 하나 있는데, 바로 OpenAI 호환 API 규격이에요. 하네스 대부분이 “OpenAI 형식으로 말하는 엔드포인트”만 있으면 붙기 때문에, 우리가 세운 서빙이 그 규격만 맞추면 퍼즐이 맞아떨어집니다.
3. “완벽히 동일한 방향”이 되려면 — 조건 체크리스트
사용자분들이 가장 궁금해하는 게 이거예요. “뭐가 다 갖춰지면 지금이랑 똑같이 쓸 수 있냐.” 저는 이걸 6개 조건으로 정리해요. 이 여섯이 다 초록불이면, 체감상 거의 같은 방향으로 굴러갑니다.
| 조건 | 무엇을 봐야 하나 | 다루는 편 |
|---|---|---|
| 모델 지능 | 코딩 에이전트 벤치 티어가 붙나 | 2편 |
| 툴 콜 | 함수·도구 호출을 안정적으로 하나 | 2편·4편 |
| 긴 컨텍스트 | 큰 코드베이스를 담을 토큰 창 | 2편·3편 |
| API 호환 | OpenAI 규격을 그대로 흉내 내나 | 3편·4편 |
| 하네스 패리티 | 편집·검색·MCP 기능이 되나 | 4편 |
| 처리량·지연 | 사람 수만큼 동시에 빠르게 | 3편 |
하나씩 짧게 감만 잡아둘게요.
- 모델 지능 — 제일 중요해요. 아무리 인프라를 잘 깔아도 모델이 코딩 에이전트급이 아니면 방향이 달라져요. “채팅은 되는데 에이전트로는 헤매는” 모델이 꽤 많거든요.
- 툴 콜(함수 호출) — 에이전트는 모델이 “이 도구를 이런 인자로 불러줘”를 구조화된 형식으로 정확히 뱉어야 굴러가요. 이게 흔들리면 파일을 엉뚱하게 고치거나 루프가 깨집니다.
- 긴 컨텍스트 — 큰 저장소를 다루려면 수만~수십만 토큰 창이 필요해요. 창이 좁으면 파일 몇 개만 봐도 앞 내용을 까먹어요.
- API 호환 — 하네스가 붙으려면 서빙이 OpenAI 규격(특히 스트리밍·툴 콜 필드)을 충실히 흉내 내야 해요.
- 하네스 패리티 — 지금 쓰던 편집 diff, 코드 검색, MCP 연동 같은 편의 기능이 대체 CLI 에도 있어야 “똑같이” 쓰는 느낌이 나요.
- 처리량·지연 — 나 혼자 쓰면 GPU 한두 장으로 충분하지만, 팀이 동시에 붙으면 동시 요청을 감당하는 처리량과 첫 토큰까지의 지연이 사용 경험을 좌우해요.
✅ 이 여섯을 시리즈 내내 하나씩 초록불로 바꿔갈 거예요. 마지막 5편에서 이 체크리스트를 실제로 검증하는 방법과, 그래도 남는 갭을 솔직하게 정리합니다.
4. 손익분기 — GPU 를 사는 게 언제 이득인가
돈 때문에 시작한 이야기니까, 숫자 감각을 대충이라도 잡아야죠. 정확한 견적은 3편에서 하드웨어를 고르며 다시 하고, 여기선 의사결정용 어림셈만 볼게요.
핵심은 이 비교예요.
온프렘 = 장비 감가상각 + 전력 + 운영인건비 (고정비, 사용량과 무관)
클라우드 = 토큰 사용량 × 단가 (변동비, 쓰는 만큼)
- 클라우드는 변동비예요. 안 쓰면 0 이지만, 많이 쓰면 끝없이 올라가요. 팀이 코딩 에이전트에 완전히 물들수록 이 곡선이 가팔라집니다.
- 온프렘은 고정비예요. 장비를 한 번 사면 그 위에서 얼마를 굽든 청구서가 안 늘어요. 대신 안 써도 감가상각·전력은 나갑니다.
그래서 판단 기준은 딱 하나예요.
💡 월 API 지출이, GPU 장비를 갚아나가는 월 고정비를 넘어서기 시작하면 온프렘이 이깁니다. 팀 규모가 크고 사용량이 꾸준할수록 그 교차점이 빨리 와요. 반대로 “가끔 쓰는 1~2명”이면 클라우드가 거의 항상 더 쌉니다.
여기에 돈으로 환산 안 되는 두 축이 더 붙어요.
- 데이터 통제 — 소스코드가 사내 밖으로 안 나가야 하는 조직(금융·공공·보안)이라면, 손익분기와 무관하게 온프렘이 정답에 가까워요.
- 운영 부담 — GPU 서버는 사면 끝이 아니라 누군가 계속 돌봐야 해요. 이 인건비를 빼먹으면 손익분기 계산이 장밋빛으로 왜곡돼요. 3편에서 이 항목을 꼭 넣어서 계산합니다.
5. 5부작 로드맵
이 시리즈가 어디로 가는지 한 장으로 정리하면 이래요.
- 1편(지금) — 왜 옮기나, 3층 구조, 동일성 조건, 손익분기 감각.
- 2편 — 모델 — 어떤 오픈웨이트가 코딩 에이전트급인가. 크기·MoE·컨텍스트·툴 콜 능력으로 후보를 거르는 법.
- 3편 — 하드웨어·서빙 — GPU/VRAM 을 어떻게 계산하고, 양자화로 얼마나 줄이며, vLLM 으로 어떻게 띄우는가. 손익분기 재계산.
- 4편 — 하네스 — 로컬 모델을 오픈 CLI 에 물려 실제로 파일을 고치게 만들기. OpenAI 호환 엔드포인트, 툴 정의, MCP.
- 5편 — 동일성 검증 — 여섯 조건을 실제로 검증하는 법, 그래도 남는 갭, 그리고 로컬+클라우드 하이브리드로 현실적으로 타는 법.
정리하면 온프렘 코딩 에이전트는 “모델·서빙·하네스 세 칸을 오픈 조각으로 채우고, OpenAI 호환 API 로 잇는 일”이에요. 나머지 편들은 각 칸을 하나씩 깊게 파는 거고요.
일단 오늘은 여기까지…..
다음 글에서는 그 세 칸 중 가장 중요한 모델부터 골라볼게요. 어떤 오픈웨이트가 코딩 에이전트로 쓸 만한지 기준을 세워봅니다.
