제0부 개관

0.2 전체 스택과 학습 지도 · build vs buy 첫 조망

"ChatGPT 같은 것을 만들겠다"는 문장에는 함정이 하나 숨어 있다. 그 말을 들으면 대부분 거대한 GPU 클러스터에서 몇 달간 모델을 학습시키는 장면을 떠올린다. 그런데 세상에서 파운데이션 모델을 처음부터 학습하는 팀은 손에 꼽을 정도이고, 나머지 수만 개의 팀은 그 층 전체를 사서(buy) 그 위에 자기 몫만 짓는다(build). 대화형 LLM 시스템은 하나의 묶음이 아니라 여섯 층으로 쌓인 스택이고, "만든다"는 그 여섯 층 중 어디를 직접 짓고 어디를 사올지를 정하는 일이다. 어느 층을 사고 어느 층을 짓느냐가 곧 제품 전략이며, 그 선택이 나머지 모든 결정을 제약한다.

이 장은 그 여섯 층의 지도를 그린다. 각 층에서 실제로 어떤 결정이 내려지는지를 예와 함께 다루고, 그 결정들을 관통하는 두 개의 전략 질문을 세운다 — 어디를 build하고 어디를 buy할 것인가(파운데이션 학습·파인튜닝·API·오픈웨이트의 네 갈래), 그리고 비용·지연·품질·안전 중 무엇에 무게를 둘 것인가. 세부 원리·수식·코드는 각 부에서 다룬다. 여기서 얻어 갈 것은 "어디에 무엇이 있고, 무엇을 먼저 정해야 하며, 그 결정이 무엇을 딸려오게 하는가"의 개략이다.

숫자에 대한 경고를 미리 해 둔다. 이 장에 나오는 토큰 단가·GPU 시간당 요금·모델 크기·처리량은 전부 방향을 보여 주려는 예시값이다. 이 분야는 몇 달이면 뒤집힌다. 외울 것은 숫자가 아니라 트레이드오프의 구조다. 손익분기 계산을 여러 번 하지만, 그때마다 중요한 것은 결과 숫자가 아니라 "무엇이 그 숫자를 움직이는가"다.

0.2.1 여섯 층으로 쌓인 시스템

시스템을 만들 때는 밑에서부터 쌓고, 사용자의 요청은 위에서 들어와 아래로 내려갔다 되돌아 나온다. 이 두 방향을 함께 봐야 스택이 이해된다.

빌드 방향(아래→위) 에서 아래층의 선택은 위층의 자유도를 잘라낸다. 파운데이션 가중치가 있어야 정렬을 할 수 있고, 정렬된 모델이 있어야 서빙하며, 서빙되는 모델 위에 응용·제품이 추가된다. 그래서 맨 아래(①)에서 폐쇄형 API를 고르는 순간 ②의 파인튜닝과 ③의 서빙 최적화는 대부분 벤더에게 넘어간다 — 내가 만질 수 있는 층이 위 세 개로 줄어든다. 반대로 ①에서 오픈웨이트를 자체 호스팅하면 ②·③의 자유도를 손에 넣는 대신 그 층을 운영할 책임도 함께 부담한다. 런타임 방향(위→아래→위) 에서는 사용자 요청이 제품 층(⑤)으로 들어와 응용 층(④)에서 프롬프트·검색·도구로 기능이 보강되고, 서빙 층(③)이 토큰을 생성해 정렬된 모델(②)이 파운데이션(①)을 실행해 답을 만든 뒤 역순으로 돌아 나간다.

두 축이 더 있는데, 이들은 "층"이라기보다 스택을 세로로 관통한다. 평가(제4부)는 어느 층을 바꾸든 "좋아졌는가"를 판정하는 계측기다 — 파운데이션 교체든 정렬 실험이든 프롬프트 수정이든 서빙 양자화든, 평가 없이는 개선인지 회귀인지 알 수 없다. 사업·전략·법·윤리(제9부)는 스택을 감싸는 바깥 프레임이다. 기술적으로 가능한 것과 사업적으로·법적으로 해도 되는 것은 다르다. 라이선스가 자체 서빙을 막을 수도, 규제가 데이터를 국경 밖으로 못 내보내게 할 수도 있다.

여섯 층을 다 짓는 팀은 거의 없다는 점을 다시 명시해 두자. 대부분은 ①~③을 사서 ④~⑥만 짓고, 일부는 ②까지 내려가 파인튜닝을 하며, ①을 직접 짓는 것은 극소수다. 이 장의 나머지는 그 "어디까지 내려갈 것인가"를 판단하는 도구다.

0.2.2 층마다 실제로 무엇을 정하는가

지도의 값어치는 "여기서 무엇을 정해야 하는가"를 알려 주는 데 있다. 각 층에서 내려지는 결정은 추상적인 "모델 선택" 수준이 아니라, 구체적인 숫자와 트레이드오프를 가진 실무 판단이다. 하나씩 내려가며 본다.

0.2.2.1 파운데이션 — 무엇을 어디까지 내 것으로 둘지

맨 아래 층의 첫 결정은 build vs buy 그 자체이지만(0.2.5에서 본격적으로 편다), 그 안에도 세부 결정이 여럿이다. 모델을 사기로 했어도 어떤 크기·아키텍처를 고르느냐가 위층 전체의 비용을 결정한다. 조밀(dense) 모델은 파라미터 전부를 매 토큰에 쓰지만, 전문가 혼합(Mixture of Experts, MoE)은 전체 파라미터가 커도 토큰당 일부 전문가만 활성화해 연산을 아낀다 — 대신 어느 전문가가 뽑힐지 몰라 서빙 시 가중치를 사실상 전부 메모리에 적재해야 하므로, "연산은 싸지만 메모리는 비싼" 형태가 된다. 컨텍스트 길이 목표도 여기서 정해진다. 8K로 충분한 제품과 128K·1M을 노리는 제품은 KV 캐시 비용이 자릿수로 다르고(그 산식은 5.1), 이것이 서빙 GPU 예산을 좌우한다.

한국어 서비스라면 놓치기 쉬운 결정이 하나 더 있다. 토크나이저 효율이다. 같은 문장이라도 어떤 모델은 한국어를 잘게 분할해 토큰 수가 영어의 두세 배로 불어난다. 토큰당 과금·토큰당 지연·컨텍스트 소모가 전부 여기에 비례하므로, "한국어를 잘한다"는 품질만이 아니라 "한국어를 몇 토큰에 담느냐"가 곧 비용이다. 예컨대 한국어 법률 문서를 다루는 팀이 영어권 모델을 골랐다가, 같은 계약서를 넣는 데 토큰이 배로 들어 비용과 컨텍스트 여유가 절반으로 줄어드는 일이 흔하다. 마지막으로 오픈웨이트를 쓰기로 했다면 라이선스가 결정에 개입한다 — 어떤 오픈모델은 상업적 사용이나 특정 규모 이상에 제약을 걸고, 어떤 것은 출력물로 다른 모델을 학습하는 것을 금한다(9.2). 이 층의 결정은 몇 달~몇 년을 간다. 바꾸려면 위층을 상당 부분 다시 손봐야 하기 때문이다.

0.2.2.2 적응·정렬 — 기본 모델을 얼마나 우리 것으로 만들지

기본 모델은 범용으로 정렬돼 있다. 우리 제품의 말투·형식·안전 정책·도메인 용어를 입히려면 어디까지 손댈지를 정해야 한다. 가장 간단한 수단은 프롬프트(사실상 ④ 층의 일)이고, 그것으로 부족할 때 이 층으로 내려온다. 지도 미세조정(SFT) 은 원하는 응답의 시연 데이터로 모델을 다시 학습해 형식·말투를 고정한다. 선호 최적화(RLHF·DPO) 는 "A보다 B가 낫다"는 선호쌍으로 더 미묘한 행동을 다듬는다. PEFT(LoRA) 는 전체 가중치 대신 저랭크 어댑터만 학습해 자원을 아끼고, 한 베이스 모델 위에 여러 어댑터를 교체해 서빙할 수도 있다.

여기서 정해야 할 것은 "파인튜닝할까 말까"만이 아니다. 데이터가 몇 건이며 품질이 어떤가(수천 건의 잘 큐레이션된 시연이 수십만 건의 잡음보다 낫다), 평가셋을 갖췄는가(평가 없는 파인튜닝은 개선인지 회귀인지 모르는 도박이다), 그리고 베이스 모델이 갱신되면 이 파이프라인을 다시 실행할 각오가 됐는가까지가 한 묶음이다. 마지막 것이 특히 과소평가된다 — 고객지원 봇의 말투와 거절 정책을 SFT로 고정해 놓았는데 벤더가 API 모델을 조용히 갱신하면, 그 위에 추가한 튜닝이 어긋나 재작업이 필요해진다. 자체 오픈모델을 튜닝했다면 모델을 내가 고정할 수 있어 이 문제는 덜하지만, 대신 학습·평가·배포 파이프라인을 상시 운영해야 한다(8.3). 이 층에 발을 들이는 순간 "모델 하나 쓰기"가 "모델 라이프사이클 운영하기"로 바뀐다는 것을 알고 들어가야 한다.

0.2.2.3 추론·서빙 — 지연·처리량·GPU 단가를 어디에 맞출지

이 층의 결정은 세 가지 축 — 지연, 처리량, GPU 단가 — 위에서 지점을 고르는 일이고, 셋을 동시에 최적화할 수는 없다. 정밀도(양자화) 를 fp16에서 fp8·int8·int4로 낮추면 가중치와 KV 캐시의 메모리·대역폭이 그만큼 줄어 비용과 지연이 내려간다. 손실이 있느냐가 관건인데, 디코드는 대역폭 바운드라(5.1) 메모리를 아끼는 양자화가 품질을 거의 안 저하시키면서 큰 이득을 주는 구간이 실제로 존재한다 — 다만 이것은 통념이 아니라 측정으로 확인할 일이다. 배치 크기는 처리량과 개별 지연을 정면으로 맞바꾼다. 배치를 키우면 같은 가중치 읽기로 여러 토큰을 처리해 시스템 처리량이 오르지만, 개별 요청은 큐에서 더 기다리고 스텝당 연산이 늘어 느려진다. 서빙 엔진(vLLM·TGI·TensorRT-LLM·SGLang)과 연속 배칭·PagedAttention 같은 기법이 이 균형을 자동화하고, 큰 모델은 여러 GPU에 텐서 병렬로 분할하는데 그러면 매 스텝 GPU 간 통신이 지연에 추가된다.

구체적으로 같은 모델이라도 제품이 무엇이냐에 따라 정반대 설정이 나온다. 실시간 챗은 첫 토큰 지연(TTFT)이 생명이라 배치를 낮게 설정해 GPU 활용도를 다소 포기하고 응답성을 산다 — 토큰당 비용은 올라간다. 야간 문서 요약 배치는 개별 지연이 무의미하니 배치를 최대로 키워 GPU를 꽉 채우고 토큰당 비용을 최소화한다. 이 층에 오면 반드시 KV 캐시로 용량을 계획해야 한다. "8B 모델이니 16 GB면 되겠지"는 거의 항상 틀린다 — 컨텍스트를 채우고 배치를 조금만 키워도 KV가 가중치보다 커진다(5.1에서 직접 계산한다).

0.2.2.4 응용 — 무엇을 알려 주고 무엇을 시킬지

여기서부터가 대부분의 팀이 실제로 짓는 층이다. 결정은 "모델에 무엇을 컨텍스트로 넣고, 무엇을 하도록 시킬 것인가"다. 지식을 어떻게 주입할지가 첫 갈림이다 — 시스템 프롬프트에 넣을지, 검색증강생성(RAG)으로 외부 문서를 결합할지, 아니면 아예 파인튜닝(②)으로 모델에 새길지. RAG를 택하면 그 안에서 또 청킹 단위·검색 개수·재순위(rerank) 여부를 정해야 하는데, 검색 문서를 많이 추가할수록 정확도는 오르지만 컨텍스트가 길어져 비용과 지연이 함께 오른다. 무엇을 시킬지는 함수 호출·도구·에이전트로 이어진다. 에이전트 루프는 관찰·행동·반성을 반복하는데, 한 스텝이 곧 한 번의 완전한 생성이므로 스텝 수가 곧 지연·비용의 곱셈 인자다 — 5스텝 길이의 에이전트는 대략 한 번 생성의 다섯 배 시간과 비용이 든다. 도구에 권한을 주는 순간 보안 결정(⑤)이 이 층으로 끌려 들어온다는 것도 알아야 한다.

이 층의 결정이 사소한 것처럼 보이지만 — 프롬프트는 하루에도 몇 번씩 고친다 — 바로 그 경량성이 강점이다. 많은 품질 문제가 여기서 가장 저렴하게 풀린다. 예컨대 사내 문서 Q&A는 파인튜닝보다 RAG+재순위로 며칠 만에 세우는 편이 낫고, 형식이 자꾸 틀리는 문제는 모델을 다시 학습하기 전에 시스템 프롬프트와 몇 개의 예시로 먼저 확립해야 한다.

0.2.2.5 제품 — 무엇을 노출·차단하고 얼마에 팔지

모델이 답을 잘 내는 것과 그것이 안전하고 지속 가능한 유료 서비스가 되는 것은 다른 문제다. 이 층은 무엇을 노출하고 무엇을 막을지(입출력 모더레이션·가드레일), 어떻게 보여 줄지(스트리밍·세션·대화 메모리), 얼마에 팔지(과금 모델·rate limit·SLA)를 정한다. 가드레일 임계값은 그 자체로 트레이드오프다 — 너무 느슨하면 유해·유출 위험이, 너무 엄격하면 정당한 요청까지 막혀 유용성이 떨어진다. 스트리밍은 지연을 "숨기는" 제품 결정이다. 실제 종단 지연은 그대로여도 첫 글자가 빨리 뜨면 사용자는 빠르다고 느낀다.

과금 설계가 특히 이 층에서 날카롭다. 토큰당 원가는 변동비인데 소비자 요금제는 대개 정액(월 구독)이라, 헤비 유저가 원가를 초과 소비하는 위험을 요금제 구조와 rate limit으로 흡수해야 한다. 반대로 API 제품이라면 토큰당 원가에 마진을 더해 통과시키되, 벤더 단가가 오르면 내 마진이 줄어드는 종속 위험을 진다. "무엇을 노출하는가"의 결정은 안전·비용·체감 품질을 동시에 영향을 주므로, 이 층은 순전히 기술이 아니라 제품·사업 판단이 지배한다.

0.2.2.6 운영 — 잘 실행되는지·나아지는지 아는 법

마지막 층은 "지금 잘 돌고 있고 점점 나아지고 있는가"를 아는 장치다. 관측성은 요청 단위로 프롬프트·출력·토큰·지연·비용을 추적하고(프롬프트·출력을 로깅할 때 프라이버시가 즉시 결정에 개입한다), 품질 모니터링은 무언가를 바꿨을 때 회귀를 검출한다. 이것이 왜 별도의 층이냐면, LLM 시스템은 내가 아무것도 안 해도 품질이 변동하기 때문이다 — 벤더가 API 모델을 조용히 갱신하면 어제까지 잘 되던 출력이 미묘하게 달라진다. 회귀 평가 없이는 이것을 사용자 불만으로만 알게 된다. 실험·A/B는 프롬프트·모델·정책의 변경을 안전하게 배포·롤백하고, 데이터 플라이휠은 사용 로그와 피드백(좋아요·싫어요, 수정 이력)을 모아 평가셋과 학습 데이터로 환류시켜 아래층(적응·검색·프롬프트)을 개선한다.

이 층의 결정은 "언제 재학습하고, 무엇을 성공 지표로 삼고, 어떻게 롤백하나" 같은 것이다. 규모가 작을 때는 소홀히 해도 운영되지만, 사용자가 늘면 여기가 곧 제품의 개선 속도를 정하는 병목이 된다. 플라이휠이 잘 작동하면 경쟁자가 따라오기 어려운 데이터 해자가 쌓이고(8.1), 작동하지 않으면 남의 모델 위에 추가한 얇은 껍데기로 남는다.

이상을 한 장에 요약하면 이렇다. 층이 위로 갈수록 결정은 자주 바뀌고 되돌리기 쉬우며, 아래로 갈수록 부하가 크고 오래간다.

0.2.3 문제를 어느 층에서 풀 것인가

층을 이렇게 나눠 놓으면, 이 지도의 가장 실전적인 용도가 드러난다. 같은 증상도 어느 층에서 고치느냐에 따라 비용이 자릿수로 다르다. "답이 자꾸 틀린다"는 하나의 증상이지만 원인과 정착지는 제각각이다. 최신 사실을 몰라서 틀리면 RAG로 지식을 결합하는 ④의 문제이고, 말투나 출력 형식이 어긋나면 프롬프트(④)나 SFT(②)의 문제이며, 근본적인 추론력이 부족하면 더 나은 모델로 갈아타는 ①의 문제이고, 하면 안 되는 답을 하면 가드레일을 세우는 ⑤의 문제다. 문제를 잘못된 층에 배정하면 몇 주를 소모하고도 못 고친다.

여기서 흔한 반사반응 하나를 눕혀 두자. "성능이 부족하면 파인튜닝하면 된다"는 말은 대개 틀린 첫 수다. 파인튜닝(②)은 강력하지만 데이터·평가셋·재학습 파이프라인이라는 부하가 큰 비용을 부르고, 실제로는 많은 품질 문제가 더 나은 프롬프트·검색·예시(④)나 더 나은 모델로의 교체(①의 buy 재선택)로 훨씬 저렴하게 풀린다. 환각을 줄이겠다고 몇 주간 파인튜닝하다가, 결국 RAG 며칠로 더 잘 해결하는 팀을 흔히 본다. 반대 함정도 있다 — 모델이 근본적으로 못 하는 일을 프롬프트로 우겨넣으려다 시간을 버리는 경우다. 프롬프트를 아무리 정교하게 짜도 안 되는 능력은, 층을 내려가 모델을 바꿔야(①) 풀린다.

그래서 실전의 리듬은 위에서 아래로 내려가며 풀기다. 가장 위층(가장 저렴하게, 가장 빨리 바꿀 수 있는 층)에서 먼저 시도하고, 그걸로 안 될 때만 한 층씩 내려간다. 프롬프트로 안 되면 검색·도구(④), 그래도 안 되면 파인튜닝(②), 그마저 근본적으로 부족할 때만 모델 교체·직접 학습(①). 이 방향이 옳은 이유는 비용의 비대칭에 있다. 프롬프트는 몇 분이면 배포하고 롤백하지만, 재학습은 몇 주가 걸리고 되돌리기도 어렵다. 위층에서 풀리는 문제를 아래층으로 끌고 가면 시간과 돈을 모두 잃는다.

0.2.4 스택과 책 구조, 그리고 읽기 경로

이 책의 부(部) 구조는 위 스택의 순서를 거의 그대로 따른다. 지금 읽는 부가 스택의 어디인지를 이 대응으로 늘 확인할 수 있다.

전권을 순서대로 읽으면 아래층부터 자연히 쌓이지만, 모두가 여섯 층을 다 짓지는 않으므로 역할마다 출발 경로가 다르다. 모델을 직접 학습·정렬하는 리서처·ML 엔지니어는 ①·②를 짓는 사람이라 제1부→제2부→제3부→제4부를 먼저 밟고 서빙(제5부)으로 간다. 남의 모델 위에 서비스를 구축하는 앱·플랫폼 엔지니어는 ④·⑤·⑥이 자기 층이라 제6부→제7부→제8부를 먼저 읽고, 필요할 때 서빙(제5부)과 파인튜닝(제3부 일부)을 역참조한다. 도입·전략을 결정하는 창업자·아키텍트·PM은 전 층을 얕게 훑고 구도를 정해야 하므로 제9부(9.1 build vs buy)와 제7부(제품·비용)를 먼저 본다. 어느 경로든 자기완결적으로 읽히도록 썼지만, 세 경로 모두 이 장과 9.1을 공유한다 — 어디를 짓고 어디를 살지가 세 역할의 공통 출발점이기 때문이다.

0.2.5 build vs buy — 네 갈래를 트레이드오프로

스택의 맨 아래에서 갈리는 첫 전략 질문으로 돌아가자. 모델을 어디까지 직접 만들 것인가. 네 갈래가 있다.

이 흐름도는 강요가 아니라 첫 어림이다. 화살표의 조건이 애매하게 느껴지면 그것이 정상이다 — 대부분의 팀은 여러 갈래를 동시에 운용한다(점선). API로 검증하다가 비용이 커진 경로만 오픈웨이트로 이전하고, 이전한 뒤에도 프런티어급이 필요한 소수 요청은 API로 보낸다. ①로 직행하는 팀은 극소수다.

네 갈래를 나란히 놓고 다섯 축으로 따져 보자. 셀 값은 방향 파악용 개략이다.

축을 하나씩 뜯어 보면 왜 이것이 단순한 서열이 아니라 실제 트레이드오프인지 보인다. 비용은 초기 비용과 한계 비용을 갈라 봐야 한다. API는 초기 비용이 0이지만 토큰당 단가가 벤더에 고정돼, 규모가 커지면 그 단가가 그대로 비용이 된다. 자체 서빙은 초기에 GPU와 엔지니어링을 투자하지만 한계 비용이 인프라 상각이라, 활용률이 높으면 토큰당 단가가 API를 이긴다 — 이 손익분기가 다음 절의 주제다. 통제와 데이터 해자는 함께 움직인다. API를 쓰면 모델의 개정·중단·단가를 벤더가 쥐고 내 데이터가 벤더로 나가는 반면, 자체 서빙·파인튜닝은 모델을 내가 고정하고 데이터가 내부에 머물며 학습에 축적돼 해자가 된다. 역량은 거꾸로다 — 지금 이 순간의 최상위 능력에 가장 쉽게 닿는 길은 API이고, 오픈웨이트는 오픈모델의 상한에 묶인다. 속도는 API가 압도한다. 반나절이면 프로토타입이 실행된다.

같은 정보를 비용·역량·통제의 삼각형으로 보면, 왜 넷이 한 점에 모일 수 없는지가 한눈에 보인다. 세 꼭짓점을 동시에 최대화할 수는 없다 — 하나에 다가가면 다른 쪽에서 멀어진다.

③ API는 저비용·빠름과 최상위 역량을 잇는 아래 변에 붙지만 통제 꼭짓점에서 가장 멀다. ① 직접 학습은 통제와 역량의 위 변에 붙지만 저비용·빠름에서 가장 멀다. ④ 오픈웨이트는 통제 쪽으로 기울되 역량이 오픈모델 상한에 걸리고, ② 파인튜닝은 삼각형 안쪽 중간에서 특정 도메인의 통제·역량을 함께 얻는 대가로 데이터·운영 비용을 치른다. 점의 위치는 예시일 뿐, 팀의 데이터·규모·규제에 따라 각 점은 움직인다 — 데이터 해자가 곧 사업의 핵심인 팀은 통제 꼭짓점 쪽으로, 속도가 전부인 초기 스타트업은 아래 변 쪽으로 각자의 좌표가 당겨진다.

0.2.6 API냐 자체 서빙이냐 — 손익분기 개략 계산

"자체 서빙이 싸다"는 말은 조건부다. 그 조건이 무엇인지 개략 계산으로 따져 보자. 수치는 전부 설명용 개략값이고, 모델 품질 차이 같은 것은 일단 무시한 극단적 단순화다.

우선 두 값을 설정한다. API 출력 단가를 $100$만 토큰당 $\$10$, 자체 서빙용 GPU 임대를 시간당 $\$2$(1대, 상시 가동)로 두자. 한 달을 $730$시간으로 설정하면 자체 서빙의 고정비는

$$\text{고정비} = \$2/\text{h} \times 730\,\text{h} \approx \$1{,}460 / \text{월}$$

이고, 이 돈은 트래픽이 얼마든 나간다. 이 고정비로 API를 대신 사면 얼마어치 토큰을 쓸 수 있느냐가 순진한 손익분기다.

$$\text{손익분기 토큰} = \frac{\$1{,}460}{\$10 / 10^6\,\text{토큰}} = 1.46 \times 10^8\ \text{토큰/월}$$

즉 월 출력이 약 1.46억 토큰보다 적으면 API가 저렴하고(게다가 운영 부담이 0이다), 그보다 많고 GPU를 꾸준히 채우면 자체 서빙의 토큰당 단가가 이긴다. 여기서 결정적인 관찰은 자체 서빙의 실효 단가가 활용률의 함수라는 것이다. 자체 서빙의 실효 토큰당 단가는 "고정비 ÷ 실제로 생산한 토큰"이므로, 같은 $\$1{,}460$ 단가의 GPU로 월 1000만 토큰만 생산하면 100만 토큰당 $\$146$ — API의 14배로 비용이 커지고, 월 10억 토큰을 생산하면 100만 토큰당 $\$1.46$ — API의 7분의 1로 저렴해진다. 트래픽이 적거나 불균일하면 고정비를 못 채워 API보다 비용이 커지는 것이다.

용량이 손익분기를 막는지도 확인하자. GPU 한 대가 낼 수 있는 디코드 처리량을 연속 배칭으로 초당 수천 토큰 규모라 가정하면, 한 달 최대 생산량은 대략 $3000\,\text{tok/s} \times 3600 \times 730 \approx 8 \times 10^9$, 즉 수십억 토큰이다. 손익분기인 1.46억 토큰은 이 용량의 2%도 안 된다 — 다시 말해 손익분기를 정하는 것은 GPU의 처리 능력이 아니라 그 GPU를 얼마나 꾸준히 채우느냐다. 트래픽이 그 GPU를 계속 바쁘게 유지하지 못하면, 능력이 남아돌아도 실효 단가는 API 위로 치솟는다.

지금까지의 계산은 낙관치다. 세 가지 숨은 비용을 넣으면 손익분기가 크게 올라간다. 첫째, 엔지니어링 인건비다. 서빙을 세우고 지키는 엔지니어의 완전부담 비용을 월 $\$12{,}000$라 하면, 이 한 사람이 위 GPU 고정비 $\$1{,}460$을 여덟 배 넘게 압도한다. 둘째, 가용성이다. SLA를 지키려면 GPU 한 대로는 안 되고 이중화·피크 대비 오토스케일이 필요해 고정비가 배로 증가한다 — 게다가 피크에 맞춰 기동한 여분 GPU는 평시에 유휴 상태가 되어 활용률을 저하시킨다. 셋째, 품질 격차다. 오픈모델이 프런티어 API보다 약하면 같은 품질을 내려고 더 큰 모델(더 많은 GPU)을 쓰거나, 아니면 사용자를 잃는다 — 이 손실은 계산에 반영되지 않지만 실재한다.

세 가지 트래픽 규모로 이 그림을 구체화해 보자. 월 2000만 토큰이면 API는 $\$200$, 자체 서빙은 GPU 한 대만 해도 $\$1{,}460$으로 7배 비용이 크고 그 위에 인력이 추가된다 — API의 압승이다. 월 5억 토큰이면 API는 $\$5{,}000$, 자체 서빙 인프라는 이중화까지 두 대로 산정해 $\$2{,}920$으로 인프라만 보면 이기지만, 서빙 엔지니어를 절반만 추가해도 $\$6{,}000$이 더해져 다시 API 쪽으로 기운다 — 이미 서빙 역량이 사내에 있지 않은 한. 월 50억 토큰에 이르러야 API가 $\$50{,}000$으로 커져, GPU 여러 대($\$6{,}000$~$\$12{,}000$)에 엔지니어 한 명($\$12{,}000$)을 온전히 붙여도 도합 $\$2$~$\$3$만 선에서 명백히 이기고, 그 차액이 팀을 먹여 살린다.

그래서 인건비까지 정직하게 넣은 실질 손익분기는 순진한 계산의 1.46억 토큰이 아니라 월 수십억 토큰, 또는 월 수만 달러의 API 지출 근처다. 이것이 흔한 경로가 "API로 검증하고, 규모·통제·비용이 그 문턱을 넘을 때 뜨거운 경로만 오픈웨이트·파인튜닝으로 이전"인 이유다. 한 갈래에 결혼하지 말고 이전 비용을 낮게 유지하는 것 — 벤더 호출을 추상화 뒤에 두고, 평가셋을 보존해 언제든 다른 모델로 교체해 품질을 비교할 수 있게 하는 것 — 이 실전의 핵심이다. 정밀한 계약·라이선스·비용 모델링은 7.5과 9.1에서 다룬다.

0.2.7 어느 갈래가 누구에게 맞나

위 계산과 삼각형에서 판단틀은 나오지만, 정답은 팀의 제약에서 나온다. 내 견해를 강한 규칙이 아니라 출발점으로 밝혀 둔다. 반례는 많다.

대부분의 앱과 초기 스타트업은 ③ API로 시작하는 편이 옳다. 최상위 역량에 즉시 닿고, 선투자가 0이며, 가장 빠르게 검증한다. 제품·시장 적합성을 찾기 전에 아래층을 짓는 것은 대개 낭비다 — 아무도 안 쓰는 제품을 위해 서빙 인프라를 완벽하게 튜닝하는 것만큼 허무한 일이 없다. 위험은 벤더 종속·데이터 정책·단가 변동인데, 이것은 추상화와 평가셋 보존으로 이전 비용을 낮게 유지해 관리한다.

데이터를 내보낼 수 없거나(규제·프라이버시) 특정 도메인 특화가 제품의 핵심이면 ④ 오픈웨이트로, 필요하면 ② 파인튜닝으로 내려간다. 온프레미스·프라이빗 요구가 있는 곳, 반복 태스크의 말투·형식·용어를 고정해야 하는 곳에 강하다. 대가는 서빙·평가·재학습 운영을 부담하는 것이다. 파인튜닝은 "모델 하나 쓰기"를 "모델 라이프사이클 운영하기"로 바꾼다는 점을 각오하고 들어가야 한다.

모델 자체가 사업의 해자이고 대규모 자본·데이터·인력·시간을 갖춘 소수만이 ① 파운데이션 직접 학습으로 간다. 프런티어 랩이나 특수 도메인의 대형 사업자에 한한다. 대부분의 팀에게 처음부터 ①은 거의 항상 오답이다 — 비용·시간·리스크가 압도적이고, 그 자원을 위층에 쓰면 훨씬 큰 효용이 난다.

관통하는 지침 하나. 가장 위층(가장 저렴하게 바꿀 수 있는 층)에서 먼저 풀고, 그걸로 안 될 때만 한 층씩 내려가라. build vs buy도 이 리듬을 따른다 — API로 시작해, 프롬프트·RAG로 시도해 보고, 그래도 안 되면 파인튜닝으로, 근본적으로 부족할 때만 모델을 바꾸거나 직접 학습한다. 처음부터 아래층을 짓겠다는 결정은 대개 성급하다.

0.2.8 네 축이 층을 관통한다 — 비용·지연·품질·안전

층은 "무엇을 결정하는가"의 지도이고, 비용·지연·품질·안전은 "그 결정을 무엇으로 평가하는가"의 축이다. 이 넷은 층마다 수단이 다르고, 서로 얽혀 있어 하나를 당기면 반대편이 딸려온다.

각 당김을 구체 사례로 보자. 품질을 높이면 비용·지연이 딸려 온다. 더 큰 모델, 더 많은 검색 문서, 더 긴 사고사슬은 답을 낫게 하지만 토큰과 시간을 소비한다. 코딩 보조 도구가 정확도를 높이려 코드베이스 전체를 RAG로 결합하면 컨텍스트가 길어져 첫 토큰 지연과 토큰당 비용이 함께 오른다. 비용을 낮추면 품질이 위태롭다 — 다만 항상 그런 것은 아니다. 작은 모델·강한 양자화·컨텍스트 축약은 저렴하지만 능력을 저하시킬 수 있는데, 디코드가 대역폭 바운드인 구간에서는 양자화가 품질을 거의 안 잃으면서 비용을 크게 줄이기도 한다. 통념이 아니라 측정으로 확인할 일이다. 안전을 강화하면 지연·체감 품질과 부딪힌다. 입출력 모더레이션·정책 검사는 단계를 늘려 지연을 더하고, 과도하게 보수적인 가드레일은 정당한 요청까지 막아 유용성을 저하시킨다. 지연을 줄이는 수단이 비용을 늘리기도 한다. 여유 GPU를 기동해 대기열을 줄이면 지연은 좋아지지만 활용률이 떨어져 토큰당 비용이 오른다 — 0.2.6에서 본 "놀아도 나가는 GPU"의 그 문제다.

그래서 실무의 목표는 네 축을 다 최대화하는 것이 아니라 제품이 요구하는 지점에 축들을 배치하는 것이다. 두 시나리오를 끝까지 그려 보면 이 배치가 어떻게 갈리는지 보인다. 실시간 코딩 보조는 첫 토큰 지연이 생명이라 더 작고 빠른 모델을 골라 지연을 사는데, 그러면 품질이 저하되므로 코드베이스 RAG와 정교한 프롬프트로 보완한다 — 지연을 위해 비용·품질을 재배치한 것이다. 반대로 의료 분류 봇은 틀리거나 위험한 답이 치명적 문제라 큰 모델·사람 검수·엄격한 가드레일을 받아들이고, 그 대가로 지연과 비용이 오르는 것을 감수한다 — 안전·품질을 위해 지연·비용을 내준 것이다. 같은 시스템도 사용처마다 다른 지점에 놓인다. 실시간 대화형은 지연에, 배치 요약은 비용에, 의료·법률은 안전·품질에 가중치를 둔다. 그래서 "정답 아키텍처"가 없다.

0.2.9 정답 아키텍처는 없다

이 장은 지도를 줬지만, 지도가 경로를 대신 정해 주지는 않는다. 최선의 build vs buy·서빙 스택·RAG 여부는 요구·규모·규제·데이터·팀 역량에 달렸고, 같은 문제라도 트래픽이 100배 다르거나 규제 환경이 다르면 답이 뒤집힌다. 이 책이 특정 벤더·모델·프레임워크의 서열을 골격으로 삼지 않는 이유다. 이 장의 단가·GPU 요금·"프런티어급"의 정의는 전부 몇 달이면 노후화된다 — 결정할 때는 그 시점의 공식 문서와 실측으로 다시 확인하고, 특히 특정 모델의 스펙·가격은 그때의 일차 출처를 따라야 한다. 이 지도에서 가져갈 것은 숫자가 아니라 트레이드오프의 구조다.

몇 가지 통념은 여기서 미리 눕혀 둔다. 파라미터가 크면 무조건 낫다는 말은 스케일링이 조건부라는 사실을 지운다(2.2). RAG가 환각을 없앤다는 말은 줄이는 것과 없애는 것을 혼동한다(6.4). 파인튜닝이 성능 문제의 기본 해법이라는 반사반응은 대개 위층이 더 저렴하다는 것을 잊는다(0.2.3). 자체 서빙이 항상 저렴하다는 믿음은 활용률과 인건비를 빼먹는다(0.2.6). 이것들은 라벨을 붙여 경고할 것이 아니라, 각 장에서 조건을 밝혀 조용히 붕괴시킬 것이다. 그리고 확립된 공학과 조건 의존적인 연구 주장을 섞지 말아야 한다 — 이 지도의 층·순서는 확립된 공학이지만, 특정 정렬 기법이나 양자화 방식의 우열은 평가셋과 조건에 따라 달라지는 연구 주장인 경우가 많다.

요컨대 이 지도는 "무엇을 결정해야 하는지"의 목록이지 "무엇을 결정해야 옳은지"의 정답표가 아니다. 정답은 당신의 제약에서 나온다. 이 책의 나머지는 그 제약을 읽고 각 층에서 판단하는 법을 준다. 그 첫걸음으로, 다음 장은 스택의 맨 아래층이 실제로 무엇을 하는지 — "언어를 확률로 모델링한다"는 말의 의미와 그것이 왜 지능처럼 보이는지 — 부터 근본까지 분석한다. 지도의 기초를 놓는 장이다.