1편을 쓰고 며칠 지나서 회사 GPU 워크스테이션 한 대에 같은 Qwen3.5 122B를 깔아봤습니다.
M4 노트북에서 속도가 한 자릿수로 떨어지는 걸 보고 나니 회사 쪽은 어떨까 하는 생각이 자연스럽게 들었습니다. 노트북에서는 외롭다고 하고 끝냈는데, GPU가 들어간 워크스테이션에서는 어떻게 보일지 궁금했습니다. 마침 사내에 시범으로 띄워볼 수 있는 RTX Pro 6000 Blackwell 96GB가 한 대 있어서 같은 모델을 올려봤습니다.
속도는 5배에서 7배쯤 빨라졌습니다. M4에서 초당 6~8토큰이던 게 35~50토큰이 나왔습니다. 답이 한 글자씩 깜빡이며 떨어지던 게 문장째로 흘러나오는 느낌으로 바뀌었습니다. 1편에서 말한 한 자릿수 두 개 중에 속도 쪽은 풀린 겁니다.
그러고 나서 팀 다섯 명을 거기 붙였습니다. 얼마 안 가 평균 응답이 다시 한 자릿수로 돌아왔습니다.
같은 말이 이번엔 다른 데서 나왔습니다. 1편에서는 노트북 한 대의 속도가 한 자릿수였고, 이번에는 GPU 한 대를 다섯이 같이 쓰는 큐가 한 자릿수를 만들었습니다. 요청이 쌓이면서 초당 토큰이 다시 내려갔습니다. 여기서 끝났으면 GPU를 더 사자고 하면 됐을 텐데, 그 주에 회계팀에 보고서를 들고 갔다가 또 다른 숫자를 봤습니다. 시트당 단가를 나눠 보니 우리가 쓰던 클라우드 ZDR보다 비싸게 나왔습니다. 보안팀에서는 누가 어떤 코드를 어떤 모델에 넣었는지 로그가 있느냐고 물었는데, Ollama에는 그런 로그가 기본으로 붙어 있지 않았습니다.
회사에 들이는 문제는 답이 하나로 떨어지지 않는 것 같았습니다. 노트북에서는 저 혼자 기다리면 그만이었는데, 회사에서는 기다리는 사람이 여럿이고, 돈을 보는 사람이 따로 있고, 위험을 보는 사람이 또 따로 있습니다. 같은 모델을 올렸는데 질문이 세 군데서 따로 들어오는 겁니다.
재밌는 건 세 질문 중에 모델이 얼마나 똑똑하냐를 묻는 질문은 하나도 없었다는 겁니다. 저는 노트북에서도 워크스테이션에서도 모델 답이 쓸 만한지부터 봤는데, 회사 안에서 들어온 질문은 기다리는 시간, 돈, 기록이었습니다. 모델 성능은 이미 됐다고 치고 그 바깥을 묻는 셈입니다. 처음엔 좀 김이 샜는데 생각해보면 당연한 것 같기도 합니다. 성능은 제가 혼자 봐도 되는 문제고, 나머지 셋은 저 혼자서는 답할 수 없는 문제니까요. 노트북에서 1편을 쓸 때는 질문하는 사람도 답하는 사람도 저 하나였습니다. 회사에서는 질문하는 사람이 늘어난 만큼 제가 답할 수 있는 몫이 줄어들었고, 그게 생각보다 낯설었습니다.
노트북의 외로움이 회사로 가면
1편에서 로컬 LLM이 벤치는 따라잡았는데 노트북 위에서는 외롭다고 썼습니다. 속도가 한 자릿수고, OS 통합도, NPU도, 에이전트로 쓰는 것도, 배터리와 발열도 제대로 풀리는 게 없다고요.
회사 GPU로 오면 그중 몇 개는 풀립니다. 속도가 풀리고, 데스크톱급이라 배터리와 발열은 애초에 문제가 아닙니다. 데이터센터급 GPU에서는 Tensor Core를 다 쓰니까 노트북 NPU가 놀던 것과도 사정이 다릅니다.
대신 회사에서만 생기는 문제가 있었습니다. 하나는 동시 사용자 큐입니다. 다섯 명이 한 대를 같이 쓰면 그 빠르던 속도가 다시 한 자릿수가 됩니다. 또 하나는 거버넌스 로그입니다. 누가 무슨 코드를 어떤 모델에 넣었는지 회사가 따라갈 수 있어야 하는데, 로컬 추론 서버는 그걸 알아서 남겨주지 않습니다. 마지막이 회계입니다. 개인한테는 API 호출 0이라는 숫자 하나면 충분했는데, 회사 회계로 가면 시트당 단가, 안정성, 자율성, 모델 지원 종료가 다 따로 들어갑니다. 이걸 다 합쳐야 진짜 비용이 보입니다.
그래서 저는 이걸 보안과 규제, 비용, 직군별 일하는 방식, 이렇게 세 가지를 같이 놓고 봐야 한다고 생각하게 됐습니다. 이 셋이 맞아떨어지는 데서만 로컬 LLM이 남는 장사가 되고, 그 조합은 회사마다 다릅니다. 하나만 보고 정하면 나머지 둘에서 꼭 탈이 나는 것 같습니다. 전부 로컬로 깔자는 것도, 전부 클라우드로 가자는 것도 아닌 것 같습니다.
어떤 코드는 클라우드로 안 보냅니다
제일 먼저 봐야 하는 게 보안인 것 같습니다. 여기서 답이 정해지면 나머지 둘은 대체로 따라옵니다.
회사 보안팀이 무서워하는 건 생각보다 모델 학습 데이터 유출이 아닙니다. 클라우드 LLM에 우리 코드를 넣었더니 그게 학습에 들어가서 다른 회사 사용자한테 보이는 그림은 ZDR 옵션으로 거의 막혔습니다. 진짜 무서운 건 추론할 때 넘어가는 컨텍스트 자체입니다. 회사 핵심 코드 파일 하나가 클라우드로 한 번 넘어가면, 학습에 안 쓰이더라도 누군가의 서버 메모리를 지나갔다는 사실은 남습니다. 정책 위반 의심으로 분류되면 최대 2년까지 보관되기도 하는데, Anthropic ZDR 문서에도 법적 의무나 정책 위반 대응이 필요하면 예외라고 적혀 있습니다. 평소에는 안 남지만 예외로 남는 길이 있다는 뜻입니다.
개인으로 쓸 때는 이 예외가 별로 신경 쓰이지 않았습니다. 제 코드가 어딘가 서버 메모리를 잠깐 지나간다고 해서 크게 잃을 게 없으니까요. 회사는 다릅니다. 무슨 일이 생겼을 때 그 코드가 우리 손을 떠난 적이 있는지 없는지를 설명해야 하는 쪽이 회사이고, 한 번이라도 떠났다면 그다음부터는 우리가 통제할 수 없는 얘기가 됩니다. 보안팀이 로그부터 물어본 것도 그래서였던 것 같습니다.
만약 그때 로그가 다 남아 있었다면 보안팀 질문은 거기서 끝났을까 생각해보면 그것도 아닐 것 같습니다. 로그가 있으면 다음에는 그 로그를 누가 보느냐, 얼마나 들고 있느냐를 물었을 겁니다. 로그 자체가 또 하나의 민감한 자료가 되니까요. 누가 어떤 코드를 넣었는지 적힌 기록이면 그 코드 일부가 같이 남을 수도 있습니다. 결국 로컬로 가져와도 무엇을 남기고 무엇을 안 남길지를 회사가 직접 정해야 한다는 얘기라, 클라우드에서 계약서가 대신 해주던 일을 회사가 떠안는 것에 가까워 보입니다.
그 예외 때문에 금융, 의료, 법무, 게임사 핵심 코드 같은 1등급 자산은 ZDR로도 마음이 안 놓입니다. 미국 OCC나 한국 금감원의 클라우드 이용 가이드도 데이터 관리가 바깥 사업자 정책에 묶이는 구조를 따로 검토하라고 합니다. ZDR 계약을 맺어도 그 계약이 바깥 사업자 정책에 기대고 있다는 것 자체가 하나의 위험인 셈입니다.
EU AI Act도 이 부담을 키웁니다. 8월부터 고위험 AI 시스템에 데이터 거버넌스, 기술 문서, 사람의 감독, 수명 주기 모니터링 같은 의무가 붙습니다. 다만 일주일 전에 EU 쪽에서 생체 인식, 핵심 인프라, 교육, 고용, 이민과 국경 관리 같은 영역의 일부 조항을 2027년 말로 미루기로 했습니다. 8월이 통째로 풀린 것도 아니고 모든 고위험 영역이 8월에 묶이는 것도 아니라서, 회사 법무팀이 자기 회사가 어디에 들어가는지부터 봐야 클라우드 ZDR로 갈지 로컬로 가져올지를 정할 수 있을 것 같습니다. 개발팀이 먼저 모델을 깔아 보고 나중에 법무팀에 물어보는 순서로 가면, 다 만들어 놓은 걸 다시 뜯어야 할 수도 있습니다. 저도 워크스테이션에 먼저 올려 놓고 나서야 이런 질문들을 받았으니, 순서가 거꾸로였던 셈입니다.
그런데 여기서 흔히 빠지는 함정이 있는 것 같습니다. 1등급 자산이 무서워서 회사 전체를 로컬로 옮기려는 겁니다. 회사 안에서 LLM이 닿는 일 대부분은 1등급이 아닙니다. 사내 문서 요약, 회의록 정리, 메일 초안, 간단한 리팩토링, README 손보기 같은 것들이요. 이런 것까지 로컬 GPU에 묶어 두면 비용이나 일하는 방식 쪽에서 무리가 옵니다. 클라우드 ZDR이 더 맞는 일을 굳이 로컬로 끌어오는 셈이니까요. 저는 1등급 자산은 로컬로, 3등급 아래는 클라우드 ZDR로 나눠 두는 게 맞다고 보고 있습니다. 이걸 못 나누면 회사 전체가 한쪽으로 쏠려서 비효율이 쌓입니다.
API 호출 0이 회계로 가면
개인과 회사가 제일 크게 다른 게 비용입니다.
개인이 보는 비용은 한 줄입니다. 월말에 카드로 나가는 API 청구서요. 로컬에 깔면 그 줄이 0이 되니 계산이 간단합니다. 회사 회계로 가면 그 한 줄이 네 줄이 됩니다.
먼저 하드웨어 감가상각입니다. RTX Pro 6000은 지금 시장가가 9천 달러 안팎이고, CPU나 메모리, SSD, 케이스, 전원까지 합친 워크스테이션 한 대는 1만 2천5백 달러 정도입니다. 36개월로 나누면 한 달에 350달러쯤 됩니다.
여기에 생각 못 한 변수가 하나 있었습니다. 원하는 하드웨어를 살 수 있느냐는 겁니다. 메모리 512GB짜리 Mac Studio M3 Ultra는 3월에 단종됐습니다. 전 세계적으로 DRAM이 모자라서 Apple이 512GB 옵션을 빼버렸습니다. NVIDIA DGX Spark도 2월에 같은 이유로 값이 18% 올랐습니다. 회사에서 GPU 인프라를 직접 갖추겠다는 계획이 공급망 사정에 그대로 걸려 있는 겁니다. 클라우드를 쓰면 이런 건 신경 쓸 일이 없습니다. 로컬로 가겠다고 정하는 순간, 계산서에 없던 걱정이 하나 더 생기는 셈입니다. 견적을 받아 놓고 결재가 나는 사이에 값이 오르거나 물건이 사라질 수도 있으니, 예산을 짜는 쪽에서는 꽤 곤란할 것 같습니다.
다음은 전기료입니다. 600W짜리를 평균 35% 정도 돌린다고 치면 미국 산업용 전기료로 한 달에 20달러 남짓입니다. 한국은 더 싸고 EU는 더 비싸겠지만 어느 쪽이든 다른 항목에 비하면 작습니다.
세 번째가 운영 인건비인데, 저는 여기가 함정이라고 봅니다. MLOps나 DevOps 엔지니어가 워크스테이션 한 대를 관리한다고 해 봅시다. 한 달 인건비를 1만 2천 달러로 잡고 근무 시간의 10%를 GPU 운영에 쓴다고 하면 한 달 1,200달러입니다. 5%면 절반, 20%면 두 배입니다. 회계가 인건비를 어떻게 잡느냐에 따라 시트당 단가가 몇 배씩 달라집니다.
개인으로 로컬 LLM을 돌릴 때는 이 항목이 아예 안 보입니다. 모델을 깔고, 버전을 올리고, 뭔가 안 되면 붙잡고 고치는 데 드는 제 시간을 비용으로 치지 않으니까요. 회사에서는 그 시간이 누군가의 월급에서 나갑니다. 노트북에서 API 호출 0이 공짜처럼 느껴졌던 건 제 시간을 공짜로 쳤기 때문이었던 것 같습니다.
그렇다고 개인이 자기 시간을 비용으로 쳐야 한다는 생각은 잘 안 듭니다. 노트북에서 모델을 만지는 시간은 저한테는 반쯤 놀이였으니까요. 그런데 회사로 오면 같은 시간이 놀이가 아니라 업무가 되고, 업무가 되면 누군가는 그 시간을 다른 일에 썼으면 얼마를 벌었을지를 계산합니다. 같은 손이 같은 일을 하는데 어디서 하느냐에 따라 값이 붙고 안 붙고가 정해진다는 게 좀 묘합니다. 로컬 LLM을 좋아하는 사람이 회사에서 이걸 밀어붙이기 어려운 이유도 아마 여기 있는 것 같습니다. 본인한테는 즐거운 시간이 표에는 제일 큰 줄로 올라가니까요.
네 번째는 모델 업데이트와 검증입니다. 분기마다 새 모델이 나오면 사내 코드로 평가를 다시 돌려야 하고, 그게 한 달로 치면 670달러쯤 듭니다. 이걸 빼면 단가는 내려가지만 회사 정책상 검증을 건너뛸 수는 없습니다.
다섯 명 팀이 워크스테이션 한 대를 같이 쓴다고 보고 네 가지를 합쳐서 시트당으로 나누면 이렇게 나옵니다.
| 항목 |
월 비용 |
시트당 (5명 공유) |
| 하드웨어 감가상각 (워크스테이션 풀세트 $12,500 / 36개월) |
$347 |
$69 |
| 전기료 (600W × 35% 가동률) |
$23 |
$5 |
| 운영 인건비 (0.1 FTE × $12,000) |
$1,200 |
$240 |
| 모델 업데이트·검증 |
$667 |
$133 |
| 합계 |
$2,237 |
$447 |
인건비를 5%로 잡으면 시트당 3백 달러대, 20%로 잡으면 7백 달러 가까이 됩니다.
클라우드 묶음 가격은 시트당 한 달 40달러에서 80달러 선입니다. Cursor Business가 40달러이고, GitHub Copilot Enterprise는 GitHub Enterprise Cloud까지 합치면 60달러쯤 됩니다. API를 직접 쓰면 개발자 한 명당 한 달 15달러 정도로도 되지만, 그러면 SSO, 감사 로그, 시트 관리, 온보딩 자동화를 따로 만들어야 하니 실제로는 더 듭니다. 단가만 놓고 보면 클라우드가 다섯 배에서 열 배 쌉니다.
그런데도 로컬을 고민하게 되는 건 단가 말고 들어가는 게 두 가지 더 있어서입니다.
하나는 안정성입니다. 4월 20일에 OpenAI가 90분 넘게 멈췄습니다. ChatGPT, Codex, API가 한꺼번에요. 회사 코딩 업무가 클라우드 API 하나에 묶여 있으면 그 90분 동안 다 같이 멈춥니다. 다섯 명 팀이 90분을 손 놓고 있으면 그 한 번으로 한 달치 단가 차이가 꽤 줄어듭니다. 90분이면 짧아 보이지만, 그게 마감 전날 오후였다면 얘기가 완전히 달라질 겁니다. 장애는 늘 제일 곤란한 때를 골라서 오는 것처럼 느껴지고, 그때 우리 손에 다른 선택지가 하나라도 있느냐가 크게 다가올 것 같습니다.
다른 하나는 자율성입니다. 회사가 1년 동안 Claude Sonnet 4.5 위에서 일하는 방식을 다듬어 놨는데, Sonnet 5가 나오면서 4.5 API를 차례로 내린다고 하면 그 일부를 다시 만들어야 합니다. 저는 이게 회사 입장에서 제일 부담스러운 부분이라고 생각합니다. 로컬 모델은 가중치를 회사가 들고 있는 한 사라지지 않습니다. 그 돈을 내고 자율성을 사는 셈입니다. 이건 표에 한 줄로 안 들어가서 회계팀을 설득하기가 제일 어려운 항목일 것 같습니다. 일어날지 안 일어날지 모르는 일에 미리 돈을 쓰자는 얘기니까요. 그래도 한 번 겪어 본 회사라면 이 줄의 무게를 다르게 볼 것 같습니다.
보험 같은 거라고 생각하면 조금 이해가 쉬울 것 같기도 합니다. 보험료는 사고가 안 나면 아까운 돈이고 사고가 나면 제일 잘 쓴 돈이 됩니다. 다만 보험은 얼마를 내면 얼마를 받는지가 적혀 있는데, 이건 그런 게 없습니다. 모델이 언제 내려갈지, 내려가면 얼마나 다시 만들어야 할지를 미리 알 수 없으니까요. 회계팀이 이 줄을 어려워하는 것도 그래서일 것 같습니다. 값을 매길 수 없는 걸 표에 넣으라고 하면 저라도 곤란할 것 같습니다.
그러니 단가만 보면 클라우드가 맞고, 안정성과 자율성까지 넣으면 섞어 쓰는 쪽으로 기우는 것 같습니다.
누가 어떻게 쓰느냐
같은 회사 안에서도 직군마다 답이 다르게 나오는 것 같습니다. 처음엔 회사 단위로 로컬이냐 클라우드냐를 정하면 될 줄 알았는데, 들여다볼수록 그 질문을 부서 단위로, 어떤 때는 일 하나 단위로 쪼개서 물어야 하는 것처럼 보였습니다.
코딩 쪽은 오래 혼자 일할 수 있는 모델이어야 의미가 있습니다. 1편에서 Anthropic이 Claude Code를 7시간 동안 혼자 돌린 Rakuten 사례를 얘기했는데, 사람 손 없이 모델이 도구를 수백 번 부르면서 일을 끌고 가는 모습이었습니다. 로컬 Qwen3.5 122B로 그게 될까 하면, 5분짜리 일은 되는데 한 시간짜리는 중간에 길을 잃습니다. 1편에서 꼽은 한계 중 에이전트로 쓰는 문제가 코딩에서 제일 크게 걸립니다. 컨텍스트가 길어지면 클로즈드 모델보다 빨리 상합니다. 그래서 코딩은 사실상 클라우드를 못 놓을 것 같고, 1등급 코드가 아니면 로컬을 고집할 이유가 별로 없어 보입니다. 개발자들이 제일 먼저 로컬 LLM에 관심을 보이는데, 정작 개발자의 일이 로컬과 제일 안 맞는다는 게 좀 아이러니하게 느껴졌습니다.
개발자가 먼저 관심을 보이는 건 아마 직접 깔아볼 수 있어서일 겁니다. 회의록을 정리하는 쪽 사람들은 워크스테이션에 모델을 올리는 일 자체를 할 이유가 없으니 로컬이라는 선택지가 있다는 것도 모를 수 있습니다. 그러면 로컬이 제일 잘 맞는 사람들은 그걸 모르고, 제일 안 맞는 사람들이 그걸 만지고 있는 상황이 됩니다. 제가 워크스테이션에 처음 붙인 것도 회의록 쪽이 아니라 팀 다섯 명이었던 걸 생각하면 저도 그 순서대로 간 셈입니다.
로컬이 제일 잘 맞는 건 글쓰기와 리서치 쪽입니다. 회의록 정리, 문서 요약, 메일 초안, 보도자료 다듬기 같은 일은 한 번 부를 때 짧고, 컨텍스트도 길지 않고, 결과를 사람이 바로 봅니다. 모델이 한 시간씩 혼자 돌 필요가 없습니다. 게다가 회의록에는 회사 내부 얘기가 많이 섞여 있습니다. 전략 회의, 인사 회의, 법무 검토 회의 같은 걸 클라우드로 보내는 것 자체가 보안 정책에 걸립니다. 워크스테이션 한 대로 이쪽 직군을 다 받을 수 있다면 제일 남는 장사가 될 것 같습니다. 속도가 조금 느려도 이쪽 사람들은 크게 불편해하지 않을 것 같습니다. 회의록 요약을 30초 더 기다리는 것과 회의 내용이 밖으로 나가는 것 중에 고르라면 답은 꽤 분명하니까요.
그리고 이쪽 일은 큐가 쌓여도 덜 아플 것 같습니다. 회의록은 회의가 끝나고 나서 한 번 부르면 되는 일이라, 다섯 명이 동시에 붙어서 계속 주고받는 코딩하고는 쓰는 모양이 다릅니다. 제가 다섯 명을 붙였다가 한 자릿수로 떨어진 걸 봤을 때 그 다섯이 회의록 쪽 사람들이었다면 아마 느리다는 말이 그렇게 빨리 나오지 않았을 겁니다. 같은 워크스테이션이라도 누구를 붙이느냐에 따라 평가가 꽤 다르게 나왔을 것 같습니다.
데이터와 분석 쪽은 한 번에 얼마나 많이 넣어야 하느냐가 답을 정합니다. Llama 4 Scout가 10M 컨텍스트를 오픈 웨이트로 풀었는데, 이게 진짜 쓸모 있는 데가 여기인 것 같습니다. 분기 데이터, 1년치 로그, 코드베이스 전체 인덱스 같은 걸 한 번에 넣고 보는 일은 클라우드 1M 컨텍스트로는 안 됩니다. 그리고 이런 자료는 아예 밖으로 못 나가는 경우가 많습니다. 분기 영업 데이터는 사내망 밖으로 안 나간다고 정해둔 회사라면 로컬 말고는 선택지가 없습니다. 일하는 방식과 보안이 같이 답을 내는 경우입니다. 다만 Llama 4는 라이선스를 법무팀이 먼저 봐야 합니다. 사용자 수가 일정 규모 아래면 무료인데, 그 위로는 따로 협상해야 하고, 한국 IT 대기업은 대부분 무료 쪽에 들어가겠지만 해석이 달라질 여지는 있습니다.
디자인과 기획 쪽은 멀티모달이 답을 정합니다. 디자인 리뷰, 와이어프레임 검토, 기획 자료 비주얼 다듬기 같은 일이요. Gemini 3.2 Flash처럼 vision까지 묶인 모델이 제일 빨리 좋아지는 영역이고, PNG 한 장 던지고 이 화면 위계 좀 봐달라고 하면 클라우드 모델이 답을 해줍니다. 로컬 멀티모달은 아직 외롭습니다. Qwen3.5 VL이 있긴 한데 다른 도구랑 잘 안 붙고, 디자인 도구에 플러그인으로 들어가 있는 모델은 거의 다 클라우드입니다. 이쪽도 클라우드를 못 놓을 것 같습니다.
코딩과 디자인은 클라우드, 글쓰기와 리서치와 분석은 로컬이 맞는다고 보면, 한 회사 안에서도 부서마다 답이 다르게 나옵니다.
이게 말로는 깔끔한데 실제로 하면 좀 번거로울 것 같습니다. 같은 회사 사람들이 부서마다 다른 도구를 쓰고, 다른 창을 열고, 어떤 자료는 이쪽에 넣으면 되고 어떤 자료는 저쪽에만 넣어야 한다는 걸 다 알고 있어야 하니까요. 결국 기준을 잘 정해 두고 그걸 사람들이 혼동하지 않게 알려주는 게, 모델을 고르는 것만큼 일이 될 것 같습니다.
회사가 그릴 수 있는 그림 네 가지
세 가지를 같이 놓고 보면 회사가 실제로 고를 수 있는 그림은 몇 가지로 모이는 것 같습니다. 저는 네 가지 정도로 보고 있습니다. 회사 규모, 보안 등급, 직군이 어떻게 섞여 있느냐에 따라 어디에 들어갈지가 달라집니다.
첫 번째는 전부 클라우드로 가는 그림입니다. 50명이 안 되는 스타트업이나 1등급 자산이 별로 없는 회사, SaaS 스타트업, 마케팅 에이전시, 초기 핀테크 같은 곳이요. Cursor Business에 Claude Code를 쓰거나 GitHub Copilot Enterprise를 쓰고, API는 가끔 쓰는 보조 작업에만 붙입니다. 시트당 한 달 80~100달러 정도입니다. 이게 제일 단순하고, 회사가 인프라를 직접 들고 갈 이유가 없습니다. ZDR을 쓰다가 1등급 자산이 생기면 그때 다음 그림으로 넘어가면 됩니다.
두 번째는 클라우드를 메인으로 두고 로컬을 보조로 쓰는 그림입니다. 50명에서 500명 사이 중견 IT 회사인데 1등급 자산이 조금 있고 코딩과 디자인이 일의 중심인 곳이요. 코딩과 디자인은 클라우드 ZDR로 하고, 사내 문서나 회의록이나 분기 리포트 정리는 사내 워크스테이션 한두 대로 처리합니다. 둘을 합치면 시트당 100~250달러 안팎입니다. 한국 중견 IT 회사 대부분은 여기 들어갈 것 같습니다. 제가 워크스테이션 한 대로 해본 것도 사실 이 그림의 로컬 쪽 절반에 가까웠습니다. 다섯 명이 붙자마자 느려진 걸 생각하면, 이 그림에서 로컬은 회사 전체가 아니라 몇몇 부서의 짧은 일만 받는 정도로 두는 게 맞을 것 같습니다.
세 번째는 반대로 로컬을 메인으로, 클라우드를 보조로 쓰는 그림입니다. 금융, 의료, 게임사처럼 1등급 자산이 매출에서 큰 비중을 차지하는 회사요. 1등급 코드와 분석은 GPU 몇 대를 묶은 클러스터로 하고, 일반 작업은 클라우드 ZDR로 보냅니다. 사내 MLOps 인력이 반 명에서 한 명은 붙어야 하고, 시트당 200~400달러 정도인데 그 인건비가 제일 큰 변수입니다. 이건 한두 달 검토로 끝나는 결정이 아닌 것 같습니다. 법무, 보안, 회계, 기술이 다 같이 들어가야 하고, 단기간에 돈이 남지는 않아서 1~2년을 놓고 봐야 할 것 같습니다.
네 번째는 전부 로컬로, 사내망 안에서만 돌리는 그림입니다. 정부, 국방, 일부 의료기관처럼 거의 모든 자산이 1등급인 조직이요. GPU 클러스터를 크게 꾸리고, 사내 IT 팀이 전담하고, 바깥 API는 막습니다. 시트당 한 달 500달러가 넘습니다. 회사가 200명은 넘어야 그나마 계산이 맞고, 그보다 작으면 MLOps 인건비를 시트로 나눴을 때 단가가 너무 커집니다. 그래서 이건 계산이 맞아서 고르는 그림이라기보다 규제 때문에 어쩔 수 없이 가는 그림에 가깝습니다. 이런 조직은 단가를 따지기 전에 이미 답이 정해져 있으니, 이 글에서 하는 계산이 별로 쓸모가 없을 수도 있습니다.
이렇게 늘어놓고 보면 회사마다 들어가는 칸이 다르고, 한 회사 안에서도 직군별로 다른 그림을 같이 쓸 수 있습니다. 코딩 쪽은 두 번째 그림의 클라우드를, 회의록 쪽은 두 번째 그림의 로컬을 같이 쓰는 식으로요. 로컬이냐 클라우드냐를 처음부터 둘 중 하나로 정하려고 하면 잘 안 풀리는 것 같습니다.
그리고 한 번 칸을 정했다고 거기 계속 있는 것도 아닐 것 같습니다. 스타트업이 커지면서 1등급 자산이 생기면 첫 번째 그림에서 두 번째로 넘어가야 하고, 클라우드 단가가 더 내려가면 두 번째 그림에서 로컬 비중을 줄이고 싶어질 수도 있습니다. 저는 어느 칸에 들어가느냐보다 칸을 옮길 때 얼마나 덜 아프게 옮길 수 있느냐가 나중에 더 중요해질 것 같다고 생각합니다.
만약 처음부터 그걸 염두에 둔다면, 도구를 고를 때 모델보다 그 앞단을 먼저 보게 될 것 같습니다. 사람들이 쓰는 창은 하나로 두고, 뒤에서 어떤 요청은 클라우드로, 어떤 요청은 사내 워크스테이션으로 보내는 식이요. 그러면 칸을 바꿀 때 사람들 손에 익은 건 그대로 두고 뒤쪽만 바꾸면 됩니다. 말로는 쉬운데 그 앞단을 누가 만들고 누가 관리하느냐를 생각하면 다시 운영 인건비 줄로 돌아옵니다. 어느 길로 가도 그 줄을 피해 가기는 어려운 것 같습니다.
회사 입장에서 따져볼 건 대충 이런 것들일 것 같습니다. 보안 1등급 자산이 있는지, 있으면 세 번째나 네 번째 쪽이고 없으면 첫 번째나 두 번째 쪽입니다. GPU를 운영할 사람을 근무 시간의 10%라도 뗄 수 있는지, 못 떼면 첫 번째 말고는 답이 없습니다. 직군이 어떻게 섞여 있는지, 코딩과 디자인이 많으면 클라우드 비중을 높이고 글쓰기와 리서치와 분석이 많으면 로컬 비중을 늘리는 게 맞을 것 같습니다. 그리고 회사 규모입니다. 이걸 보고 나면 어느 칸에 들어갈지 윤곽은 나오는데, 정확한 시트당 단가는 그 안에서 회계팀이 인건비를 어떻게 잡느냐에 따라 또 달라집니다.
I/O 사흘 뒤에
이 글이 나가는 5월 21일은 Google I/O 키노트가 끝나고 사흘째 되는 날입니다. 1편에서 예상한 것 중 맞은 것도 있고 빗나간 것도 있는데, 회사 도입 계산에 들어오는 건 몇 개 안 됩니다.
Gemini 3.2 Pro 가격이 공식으로 나온 게 하나입니다. 1편을 쓸 때 Gemini 3.2 Flash 가격이 미리 보였었고, I/O에서 Pro 쪽 가격이 정해졌습니다. 값이 더 내려가면 첫 번째와 두 번째 그림의 클라우드 단가가 한 번 더 내려갈 거고, 같은 시트 값으로 토큰을 더 많이 쓸 수 있게 됩니다.
Android OS 통합 발표는 회사 도입에는 아직 직접 닿는 게 없어 보입니다. 1편에서 말했듯이 Android는 일반 사용자 기기 쪽 얘기라, 워크스테이션과 서버 중심인 회사 LLM 운영과는 다른 얘기입니다. 다만 직원들이 노트북뿐 아니라 폰에서도 Gemini를 쓰는 게 당연해지면, 회사 SSO나 MDM에 붙는 OEM 모델이 두 번째 그림에 보조 도구로 들어올 수는 있을 것 같습니다.
I/O가 회사 도입 그림 자체를 바꿔 놓지는 않았고, 클라우드 단가를 조금 더 내려가게 만든 정도로 보고 있습니다. 그보다는 6월 WWDC와 하반기 OpenAI Sweetpea 쪽이 더 큰 변수일 것 같습니다. 회사 도입은 키노트 하나로 하루아침에 바뀌는 일이 아니라서, 발표가 나와도 계산서에 들어오기까지는 시간이 좀 걸리는 것 같습니다.
워크스테이션 한 대에서 본 한 자릿수는 노트북에서 본 한 자릿수와는 좀 다른 종류였습니다. 노트북에서는 점수는 따라왔는데 쓰기엔 외롭다는 얘기였다면, 회사에서는 외로운 쪽과 맞는 쪽이 회사마다, 부서마다 다르게 나온다는 얘기였습니다. 한 자릿수라는 숫자가 이렇게 자꾸 다른 얼굴로 돌아오는 게 좀 재밌습니다. 처음엔 속도였고, 그다음엔 큐였고, 회계팀 앞에서는 단가였습니다. I/O 키노트가 1편 예상을 어디까지 맞혔는지, 6월부터 9월까지는 어떻게 보이는지는 다음 편에서 다시 볼 생각입니다.
댓글
댓글 쓰기