제9부 사업·전략·법·윤리

9.1 build vs buy 전략

회의실에서 벌어지는 build 대 buy 논쟁은 거의 항상 잘못된 질문에서 시작한다. "우리 모델을 만들 것인가, 남의 것을 살 것인가" — 이 문장은 세상에 선택지가 둘뿐인 것처럼 말하지만, 실제로 손에 쥐는 것은 스위치가 아니라 조정 변수다. 한쪽 끝은 남이 학습한 모델을 그대로 호출하는 것, 반대쪽 끝은 데이터·아키텍처·가중치를 전부 자기가 만드는 것이고, 그 사이에 스택을 조금씩 더 자기 것으로 가져오는 여러 단이 놓인다. 조정 변수를 어디에 맞출지가 곧 제품 전략이며, 대부분의 실패는 "만들까 살까"를 이분법으로 놓고 필요 이상으로 오른쪽 끝까지 조정해 버리는 데서 온다.

0.2에서 이 갈림을 네 갈래(API·오픈웨이트·파인튜닝·직접 학습)로 처음 훑고 개략 계산으로 손익분기의 개략을 파악했다. 이 장은 그 조망을 결정 구조로 근본까지 분석한다. 목표는 정답을 파는 것이 아니라, 당신의 제약 — 비용·데이터·규제·인재·시간 — 을 입력하면 스스로 답이 나오는 판단틀을 손에 쥐어 주는 것이다. 그러려면 스펙트럼의 각 단이 무엇을 사고 무엇을 포기하는지, 어떤 인자가 그 선택을 당기는지, 그리고 가장 자주 오해되는 축인 비용의 손익분기가 실제로 어디에 걸리는지를 숫자로 따라가야 한다. 여기 나오는 토큰 단가·GPU 요금·학습 비용은 전부 방향 파악용 개략값이고 몇 달이면 노후화된다 — 외울 것은 숫자가 아니라 손익분기의 구조와 인자들의 당김이다. 특정 벤더의 정확한 스펙, 특히 Anthropic·Claude의 모델 ID·가격은 그 시점의 공식 문서(claude-api)로 재확인해야 한다.

9.1.1 스위치가 아니라 조정 변수 — 여섯 단의 스펙트럼

투자를 적은 것부터 큰 것 순으로 세우면, 모델을 "우리 것"으로 만드는 등반 순서가 정확히 여섯 단으로 정렬된다. 남의 모델을 그대로 호출하고(① API), 입력을 다듬고(② 프롬프트), 외부 지식을 붙이고(③ RAG), 가중치를 손대고(④ 파인튜닝), 대규모 코퍼스로 이어 학습하고(⑤ 지속 사전학습), 끝내 데이터부터 전부 자기가 짓는다(⑥ 파운데이션 처음부터). 위 단으로 갈수록 얻는 것 — 통제·차별화·소유 — 이 커지지만, 함께 치르는 대가 — 초기 투자·인재 요구·출시 지연 — 도 정확히 같은 방향으로 커진다.

이 그림을 오해 없이 읽으려면 두 가지를 분명히 해야 한다. 첫째, ②·③은 ①·④~⑥과 같은 종류의 축이 아니다. 프롬프트 엔지니어링(6.1)과 RAG(6.3)는 가중치를 전혀 바꾸지 않는 응용 층 수단이라서, 폐쇄 API 모델 위에도 추가하고 자체 호스팅한 오픈모델 위에도 추가한다. 엄밀히 말하면 이들은 "얼마나 build할 것인가"의 세로축이 아니라 그 축을 가로지르는 직교 수단이다. 그런데도 하나의 스펙트럼에 눕혀 놓는 이유는, 실무의 등반 순서가 정확히 이 모양이기 때문이다 — 먼저 프롬프트로 밀어 보고, 지식이 부족하면 RAG를 붙이고, 그래도 행동이 안 바뀔 때만 가중치를 손댄다. 직교 축을 하나의 "투자 사다리"로 눕혀 본 것이라 이해하면 된다.

둘째, 한 단에 정착할 필요가 없다. 성숙한 시스템은 거의 항상 여러 단을 동시에 쓴다. 주력 경로는 프런티어 API(①)에 정교한 시스템 프롬프트(②)와 RAG(③)를 추가해 실행하면서, 대량·반복·비용 민감한 워크로드만 파인튜닝한 오픈모델(④)로 라우팅한다(5.6). build 대 buy는 한 번 고르면 끝인 결혼이 아니라 워크로드마다 다르게 배치하는 포트폴리오다. 이 장의 나머지가 반복해 돌아올 결론이 이것이다 — 어느 단 하나를 고르는 문제가 아니라, 어떤 워크로드를 어느 단에 놓을지를 정하는 문제다.

9.1.2 각 단이 무엇을 사고 무엇을 포기하나

스펙트럼의 값어치는 "이 단으로 한 칸 올라가면 정확히 무엇을 얻고 무엇을 내주는가"를 아는 데 있다. 여섯 단을 하나씩 뜯어 본다. 여기서 "바꾸는 것"은 그 단에서 커스터마이즈하는 대상, "사는 것"은 그 대가로 얻는 이득, "포기·대가"는 치르는 값이다.

표만으로는 놓치는 세 가지 결이 있다. 하나는 바뀌는 빈도다. 위로 갈수록 "무배포로 바꿀 수 있는 것"에서 "재학습해야 바뀌는 것"으로 옮겨 간다. 프롬프트(②)는 코드 배포로 하루에도 몇 번 바꾸지만, 파운데이션(⑥)은 몇 달 단위의 결정이다. 그래서 자주 바뀔 것은 위층에, 드물게 바뀔 것은 아래층에 둔다. 고객지원 봇의 거절 정책처럼 정책팀이 매주 손대는 규칙을 파인튜닝으로 가중치에 내재화하면, 규칙이 바뀔 때마다 재학습·재평가·재배포를 실행해야 한다 — 프롬프트 한 줄이면 될 일을 몇 주가 걸리는 파이프라인으로 만든 셈이다.

둘째, ④부터는 오픈웨이트가 사실상 전제다. 폐쇄 API 모델의 가중치는 손댈 수 없다. 벤더가 제공하는 매니지드 파인튜닝이 예외이긴 하나 제약이 크다(9.1.10). 그래서 스펙트럼에서 ④로 올라가는 결정은 곧 오픈 대 폐쇄 웨이트 결정과 얽힌다(9.2). "우리 도메인에 맞게 파인튜닝하자"는 결정은 조용히 "폐쇄 벤더를 떠나 오픈모델을 자체 서빙하자"는 결정을 딸려 오는데, 이 딸림을 보지 못하면 파인튜닝 계획을 세워 놓고 정작 만질 가중치가 없다는 것을 뒤늦게 안다.

셋째, ⑤ 지속 사전학습은 대부분의 팀에게 과잉이다. 파인튜닝(④)에 RAG(③)를 더하면 도메인 적응의 대부분이 해결된다. ⑤가 값을 하는 경우는 "모델이 그 도메인의 언어·기호 체계 자체를 모른다"는 드문 상황 — 특수 법률·의료 코퍼스, 저자원 언어, 수억 줄 규모의 사내 코드베이스 — 에 국한된다. 논문들은 지속 사전학습이 도메인 성능을 높인다고 보고하지만, 그 이득은 태스크·데이터·평가셋에 따라 갈리고 컴퓨트는 크다. 이 조건 의존적인 이김이 당신의 이김을 보장하지 않으므로, ⑤를 고려한다면 반드시 자기 데이터와 자기 평가셋으로 iso-quality 비교를 거쳐야 한다(4.1의 평가셋 오염 주의).

9.1.3 여덟 인자로 옵션을 나란히 놓기

무엇을 기준으로 조정 변수를 설정할 것인가. 실무에서 반복해 등장하는 여덟 인자로 옵션들을 나란히 세우면, 이 결정이 단순한 서열이 아니라 실제 트레이드오프임이 드러난다. 셀 값은 방향 파악용 개략이고, 팀의 데이터·규모·규제에 따라 움직인다.

이 표에서 가장 먼저 읽어야 할 것은 인자들이 서로 독립이 아니라는 점이다. 오른쪽으로 갈수록 통제·해자·차별화가 함께 오르고, 속도·초기비용·인재 접근성이 함께 나빠진다. 0.2에서 본 비용·역량·통제의 삼각형이 여기서도 지배한다 — 세 꼭짓점을 동시에 최대화할 수 없듯, 여덟 인자에 전부 최고점을 주는 옵션은 없다. 그래서 이 표의 올바른 사용법은 "어느 열이 가장 좋은가"를 세는 것이 아니라, "우리에게 어느 행이 압도적으로 중요한가"를 먼저 정하고 그 행이 미는 방향을 따르는 것이다.

특히 한 인자가 나머지 전부를 압도하는 경우가 있다. 데이터를 국경이나 조직 밖으로 절대 낼 수 없는 요구 — 공공·금융·의료·국방 — 라면, 비용과 속도가 아무리 API에 유리해도 규제·주권 행이 다른 모든 행을 이긴다. 이때 build 대 buy는 최적화 문제가 아니라 제약 만족 문제가 된다. "가장 좋은 지점을 고르는" 게 아니라 "허용되는 지점 중에서 고르는" 것이고, 허용 집합이 ④ 이상(자체 가중치·온프레미스, 8.4)으로 좁혀지면 그 안에서만 비용·속도를 다툰다. 규제가 걸린 팀이 API의 손익분기 계산에 몇 주를 쓰는 것은, 애초에 선택지에 없는 열을 두고 다투는 헛수고다.

또 하나 표가 숨기는 것은 시간축이다. 표의 "역량" 행은 지금 이 순간의 상한을 기록한 스냅숏일 뿐이다. 오늘 참인 "우리가 파인튜닝한 소형모델이 이 태스크에서 범용 API보다 낫다"는, 다음 프런티어 릴리스가 그 격차를 지워 버리면 내일 거짓이 된다. 데이터 해자와 역량 우위는 표의 정지 화면에서는 강점처럼 보이지만, 둘 다 시간에 따라 침식되거나 뒤집힌다. 이 두 인자는 따로 떼어 깊게 볼 값어치가 있어 다음 두 절에서 각각 다룬다.

9.1.4 데이터 해자는 파인튜닝에서 오지 않는다

여덟 인자 중 가장 오해가 심한 것이 데이터 해자다. 흔한 오해는 "파인튜닝하면 우리 데이터가 가중치에 녹아 해자가 된다"인데, 이것은 인과를 거꾸로 해석한 것이다. 해자는 파인튜닝이라는 기법에서 나오지 않는다. 해자는 독점적 데이터와 그 데이터를 제품 개선으로 실행되는 플라이휠에서 나온다(8.1). 파인튜닝은 그 데이터를 가중치에 녹이는 여러 수단 중 하나일 뿐이고, 데이터 자체가 독점적이지 않으면 아무리 파인튜닝해도 해자가 아니다. 공개된 데이터로 파인튜닝한 모델은 경쟁자도 똑같이 만들 수 있다 — 오픈웨이트 위에서라면 며칠이면 재현된다.

뒤집으면, API를 쓰면서도 강한 해자를 쌓는 제품이 많다는 뜻이 된다. 사용자의 상호작용 로그, 그들이 고친 답, 눌러 준 좋아요·싫어요, 사내에만 있는 문서 인덱스 — 이것들은 벤더의 모델이 아무리 좋아져도 벤더가 가질 수 없는 자산이다. 이 자산을 평가셋과 검색 인덱스와 프롬프트 개선으로 환류시키면, 남의 모델 위에 추가됐더라도 경쟁자가 따라오기 어려운 격차가 쌓인다. 실제로 API 위에서 독점 지식 인덱스와 사용 로그 플라이휠로 해자를 만든 제품이, 범용 오픈모델을 파인튜닝만 해 놓은 제품보다 훨씬 방어적인 경우가 흔하다.

그렇다면 파인튜닝이 해자에 기여하는 지점은 어디인가. 파인튜닝은 독점 데이터가 이미 있을 때, 그 데이터의 가치를 프롬프트·RAG로 다 뽑아내지 못하는 경우에 마지막 한 겹을 더한다 — 예컨대 수만 건의 사내 대화에서 배어 나오는 말투·판단 기준을, 매 요청 프롬프트에 다 실을 수는 없으니 가중치에 내재화하는 식이다. 하지만 그 밑바탕에 독점 데이터와 플라이휠이 없으면 파인튜닝은 해자가 아니라 단순히 비용이다. 그래서 build 대 buy를 데이터 해자 관점에서 물을 때 던져야 할 질문은 "파인튜닝할까"가 아니라 "우리에게 남들이 못 가진 데이터가 있는가, 그리고 그 데이터가 제품을 쓸수록 더 쌓이는 구조인가"다. 이 질문에 그렇다고 답할 수 없다면, 스펙트럼을 오른쪽으로 미는 것으로 해자가 생길 거라는 기대는 착각이다.

9.1.5 역량 우위는 시한부다

두 번째로 오해가 심한 인자가 역량이다. 자체 모델의 역량 우위는 사진 한 장에서는 강점으로 보이지만, 동영상으로 실행해 보면 시한부인 경우가 많다. 논리는 이렇다. 파인튜닝한 소형모델이 특정 태스크에서 오늘의 범용 API를 이긴다고 하자. 그 우위는 두 가지 흐름에 끊임없이 침식된다. 하나는 프런티어의 전진이다 — 다음 세대 범용 모델이 그 태스크까지 잘하게 되면, 당신이 애써 좁힌 격차가 추가 비용 없이 지워진다. 다른 하나는 오픈웨이트의 전진이다 — 당신이 베이스로 삼은 오픈모델보다 나은 오픈모델이 나오면, 당신의 파인튜닝 자산은 더 나은 베이스 위에서 다시 만들어야 할 부채가 된다.

이 침식은 통념 하나를 정면으로 반박한다. "우리가 직접 만든 게 항상 낫다"는 NIH(Not Invented Here) 편향은, 자체 파인튜닝한 모델이 특정 시점·특정 태스크에서 범용 모델을 이길 수 있다는 사실을 우위의 영속성으로 착각한다. 실제로는 (ㄱ) 그 우위는 다음 릴리스에 지워질 수 있고, (ㄴ) 우위를 유지하려면 새 베이스로 갈아타고 재학습하는 지속 투자가 필요하며, (ㄷ) 종종 더 나은 베이스 모델에 좋은 프롬프트·RAG를 추가하는 편이 파인튜닝보다 저렴하고 낫다. "직접 만들었다"는 심리적 만족이 유닛 이코노믹스와 품질 판단을 이기게 두면, 지워질 우위를 지키느라 계속 돈을 붓는 함정에 빠진다.

그렇다고 자체 모델의 역량이 늘 시한부라는 것은 아니다. 프런티어가 근본적으로 못 하거나 하지 않는 것 — 극도로 좁고 독점적인 도메인, 프런티어가 학습 데이터로 본 적 없는 사내 지식, 규제상 그들이 다룰 수 없는 데이터 — 위에서라면 자체 모델의 우위가 지속된다. 판별의 기준은 이것이다. 우리의 우위는 "프런티어가 아직 못 따라온 것"인가, 아니면 "프런티어가 원래 안 하는 것"인가. 앞이면 시한부라 유지 투자를 각오해야 하고, 뒤라면 지속 가능한 해자에 가깝다. build를 정당화하는 것은 후자이지, "지금 우리가 조금 더 낫다"는 스냅숏이 아니다.

9.1.6 TCO와 손익분기의 산식

여덟 인자 중 가장 자주 오해되는 축은 비용이다. "규모가 커지면 자체 서빙이 싸다"는 직관은 조건부로만 참인데, 그 조건을 드러내려면 개략 계산(0.2)를 총소유비용(Total Cost of Ownership, TCO)으로 정식화해야 한다. 정밀한 유닛 이코노믹스는 7.5이, 용량 계획의 물리는 5.5가 담당하고, 여기서는 손익분기의 구조만 세운다.

API 옵션의 월 비용은 사용량에 거의 선형이다. 입력·출력 단가가 다르므로 분리한다.

$$C_{\text{API}} = \frac{V_{\text{in}}}{10^6}\, p_{\text{in}} + \frac{V_{\text{out}}}{10^6}\, p_{\text{out}}$$

$V_{\text{in}}, V_{\text{out}}$ 은 월 입력·출력 토큰 수, $p_{\text{in}}, p_{\text{out}}$ 은 100만 토큰당 단가다. 프리픽스 캐시·배치 할인이 있으면 실효 단가가 내려간다(5.6·7.5). 이 옵션의 본질은 선투자와 운영 인건비가 거의 0이라는 것이다.

자체 서빙 옵션의 월 비용은 사용량과 거의 무관한 고정비가 지배한다.

$$C_{\text{self}} = \underbrace{g \cdot H \cdot N}_{\text{GPU 임대·감가}} + \underbrace{E}_{\text{엔지니어링(상각)}} + \underbrace{O}_{\text{운영·관측·대기}}$$

$g$ 는 GPU 시간당 비용, $H$ 는 월 가동시간(상시면 약 730), $N$ 은 GPU 대수, $E$ 는 서빙을 구축·유지하는 엔지니어링 인건비의 월 상각분, $O$ 는 기타 운영비다. 핵심은 이 비용이 토큰을 하나 쓰든 100억 개 쓰든 거의 같다는 것이다 — GPU는 유휴 상태여도 요금이 나간다. 그래서 자체 서빙의 실효 토큰당 단가는 사용량에 반비례한다.

$$\text{자체 실효 단가} = \frac{C_{\text{self}}}{V_{\text{in}} + V_{\text{out}}}$$

이 클러스터가 물리적으로 감당하는 월 용량 상한은 처리량으로 정해진다(5.5).

$$V_{\max} = T \cdot 3600 \cdot H \cdot N \cdot u$$

$T$ 는 GPU당 지속 처리량(토큰/초), $u$ 는 평균 활용률(0~1)이다. 트래픽이 이 상한을 넘으면 GPU를 더 사야 하므로 $C_{\text{self}}$ 가 계단식으로 증가한다.

단순화를 위해 입출력을 합쳐 블렌디드 단가 $p$(100만 토큰당)와 총량 $V = V_{\text{in}} + V_{\text{out}}$ 로 보면, 두 옵션이 같아지는 손익분기 사용량 $V_{\text{be}}$ 는

$$C_{\text{API}} = C_{\text{self}} \;\Longrightarrow\; \frac{V_{\text{be}}}{10^6}\,p = gHN + E + O \;\Longrightarrow\; \boxed{\,V_{\text{be}} = \frac{10^6\,(gHN + E + O)}{p}\,}$$

이 식에서 곧바로 읽히는 것이 있다. 분자에 GPU 임대료 $gHN$ 뿐 아니라 인건비 $E$ 와 운영비 $O$ 가 들어 있다. 엔지니어링 비용이 손익분기를 크게 높인다. GPU 임대료만 보고 "저렴하다"고 판단하면 거의 항상 틀리는 이유가 이 두 항이다 — 자체 서빙의 실제 비용은 실리콘이 아니라 사람과 신뢰성(SLA)이다. 그리고 이 손익분기에는 품질이 아예 빠져 있다. 자체 오픈모델이 프런티어 API보다 품질이 낮으면 "같은 비용"이어도 같은 제품이 아니다. 이 함정은 9.1.8에서 따로 다룬다.

9.1.7 수계산 — 손익분기와 활용률 민감도

산식을 숫자로 느껴 보자. 모든 값은 설명용 개략이며, 실제 단가·처리량·품질 차이를 무시한 단순화다. 방향성만 가져가라.

가정 (전부 개략):
  · API 블렌디드 단가  p   = $5 / 100만 토큰
  · GPU 시간당          g   = $2.5 / 시간   (온디맨드 가속기 1대)
  · 월 가동시간          H   = 730 시간      (상시 켜둠)
  · GPU 대수            N   = 1
  · GPU당 지속 처리량    T   = 2,000 토큰/초 (좋은 배칭 가정, 5.3·5.5)
  · 평균 활용률          u   = 0.4           (현실적 — 트래픽 변동·헤드룸)
  · 엔지니어링 상각      E   = $8,000 / 월    (서빙 구축·유지, 약 0.5 FTE)
  · 기타 운영           O   = $1,000 / 월    (관측·로깅·대기 인프라)

먼저 자체 서빙의 월 고정비다.

$$C_{\text{self}} = gHN + E + O = (2.5)(730)(1) + 8{,}000 + 1{,}000 = 1{,}825 + 9{,}000 = \$10{,}825\,/\text{월}$$

GPU 임대료는 \$1,825뿐인데 사람·운영이 \$9,000이다. 자체 서빙 비용의 대부분이 실리콘이 아니라 사람이라는 것이 첫 교훈이다. 이제 손익분기 사용량을 구한다.

$$V_{\text{be}} = \frac{10^6 \times 10{,}825}{5} = 2{,}165{,}000{,}000 \approx 21.7\text{억 토큰/월}$$

월 약 22억 토큰을 넘겨 써야 자체 서빙이 API보다 저렴해진다. 엔지니어링·운영을 빼고 GPU 임대료(\$1,825)만 봤다면 손익분기가 $\frac{10^6 \times 1{,}825}{5} = 3.65$억 토큰으로 여섯 배 낮게 산정됐을 것이다 — 이 여섯 배가 바로 "사람 비용을 빼먹은 낙관"의 크기다.

그런데 그 사용량을 이 GPU가 감당하는지가 다음 관문이다. 용량 상한은

$$V_{\max} = T \cdot 3600 \cdot H \cdot N \cdot u = 2{,}000 \times 3600 \times 730 \times 1 \times 0.4 \approx 21.0\text{억 토큰/월}$$

용량 상한(21.0억)이 손익분기(21.7억)와 거의 같다. 이 단일 GPU 구성은 GPU를 거의 꽉 채워야 겨우 API와 본전이라는 뜻이다. 여기서 활용률이 결정적이라는 것이 드러난다. 실효 단가를 활용률별로 계산하면 손익분기가 얼마나 아슬아슬하게 활용률에 매달려 있는지 보인다.

읽어야 할 것은 자체 서빙이 이기려면 두 조건이 동시에 성립해야 한다는 점이다. 트래픽이 손익분기를 넘길 만큼 크고(그래야 $V$ 가 크고), 그 트래픽이 GPU를 꾸준히 높게 채울 만큼 안정적이어야 한다(그래야 $u$ 가 높다). 활용률 0.4에서는 GPU를 꽉 채워도 겨우 본전이고, 트래픽이 야간에 놀거나 불균일해 활용률이 0.2로 떨어지면 실효 단가가 API의 두 배로 증가한다. 반대로 활용률 0.7~0.9를 꾸준히 유지할 만큼 트래픽이 크고 안정적이면 API의 절반 값에 서빙하고, 그 절감액이 엔지니어링 팀을 정당화한다. "규모가 커지면 자체 서빙이 무조건 싸다"는 절반만 참인 것이다 — 저렴해지는 것은 사용량이 분기점을 넘고, 활용률을 높게 유지하며, 품질 등가를 맞출 때뿐이고, 세 조건 중 하나라도 붕괴하면 자체 서빙이 더 비용이 크다.

9.1.8 품질을 뺀 비용 비교는 거짓말

앞 절의 손익분기에는 결정적인 것이 빠져 있었다 — 품질이다. 자체 서빙하는 오픈모델과 프런티어 API가 같은 태스크에서 같은 품질을 낸다는 암묵의 가정 위에서만 그 비교가 성립한다. 이 가정이 깨지면, "같은 비용"이라는 말은 "같은 값에 더 나쁜 물건"을 뜻하게 된다. 품질이 낮은 쪽으로 옮겨 손익분기를 넘겼다고 좋아하는 사이, 그 품질 저하가 전환율·재방문·이탈로 매출을 잠식한다 — 그리고 이 손실은 서빙 비용 장부에 반영되지 않아 보이지 않는다.

그래서 비용 비교는 반드시 iso-quality, 즉 품질을 맞춘 뒤에 해야 의미가 있다. 실무에서 이를 지키는 방법은 두 갈래다. 하나는 자체 모델의 품질을 API 수준까지 높이는 데 드는 추가 비용을 손익분기에 넣는 것이다 — 더 큰 오픈모델을 쓰거나(GPU 더), 파인튜닝 데이터를 더 큐레이션하거나(사람 더), 실패를 보정하는 후처리를 붙이는(지연·토큰 더) 비용 말이다. 이것을 넣으면 자체 서빙의 실효 단가가 올라가 손익분기가 오른쪽으로 밀린다. 다른 하나는 반대로, 품질 차이를 매출 손실로 환산해 API 쪽에 "품질 프리미엄"을 인정하는 것이다 — 자체 서빙이 토큰당 20% 싸도 품질 저하로 전환율이 5% 빠지면, 그 5%가 20% 절감보다 크면 API가 이긴다.

여기서 평가셋이 왜 이 장 전체에서 가장 중요한 자산인지가 드러난다. iso-quality 비교를 하려면 "같은 품질"을 잴 자가 있어야 하는데, 그것이 바로 당신의 태스크·당신의 데이터로 만든 평가셋이다(4.1·7.6). 벤더가 광고하는 벤치마크 점수는 당신의 태스크가 아니고, 오염되었을 수도 있다. 자기 평가셋 없이 "이 오픈모델이 프런티어급이라더라"에 기대 이전을 결정하는 것은, 재 보지 않고 옮기는 것이다. 뒤에서 보겠지만 이 평가셋은 벤더 락인을 깨는 데도 똑같이 결정적이다 — 어느 벤더로도 옮겨 같은 잣대로 재는 "우리 기준"이기 때문이다.

9.1.9 벤더 락인과 이식성

buy 쪽, 특히 ① API의 가장 큰 리스크는 벤더 락인이다. 단가 인상·모델 폐기(deprecation)·정책 변경·rate limit·리전 제약이 전부 벤더 손에 있다(7.2). 그렇다고 build로 도망치는 것이 답은 아니다 — 락인을 줄이면서 buy의 이점을 누리는 설계가 실무의 표준이다. 그러려면 락인이 실제로 어디서 오는지부터 정확히 지적해야 한다. 락인은 "API를 쓴다"는 사실에서 오는 것이 아니라, 벤더 고유의 것에 코드와 자산이 얽히는 데서 온다.

완화의 핵심은 모델 접근을 얇은 추상화 뒤에 두는 것이다. 애플리케이션이 벤더 SDK를 직접 부르는 대신 내부 인터페이스(게이트웨이)를 부르고, 그 뒤에서 벤더별 어댑터가 번역한다.

이 계층이 주는 것은 넷이다. 이식성 — 벤더 교체가 어댑터 하나 추가로 끝나고 애플리케이션 코드는 안 바뀐다. 멀티 벤더 라우팅 — 태스크·비용·지연·가용성에 따라 모델을 고르고(5.6), 쉬운 요청은 저렴한 모델로 어려운 요청만 프런티어로 보내며, 한 벤더 장애 시 자동 페일오버한다. 평가셋 보존 — 게이트웨이에 모델 독립 평가 훅을 걸어 두면 새 모델을 같은 평가셋으로 즉시 비교할 수 있다. 그리고 점진 이전 — 0.2가 말한 흔한 경로("API로 검증하고 뜨거운 경로만 자체 서빙으로 이전")를 코드 변경 없이 트래픽 비율로 실행한다.

무비용은 아니다. 추상화는 최소공통분모 문제를 낳는다. 공통 인터페이스만 쓰면 벤더 고유의 강력한 기능 — 특수 캐시, 내장 툴, 강한 구조화 출력 — 을 못 쓴다. 그래서 실무의 절충은 "공통 경로는 게이트웨이로, 고유 기능은 명시적 escape hatch로" 열어 두는 것이고, 이식성과 기능성의 균형점은 팀이 정한다. 내 견해로는 초기부터 부하가 큰 게이트웨이를 짓는 것은 YAGNI 위반이다. 얇은 어댑터 인터페이스와 평가셋 보존만으로 락인의 대부분은 방어되고, 멀티 벤더 라우팅·페일오버는 규모가 그것을 정당화할 때 붙이면 된다. 반대로 이것을 나중으로 미루면 코드가 벤더 스키마에 얽힌 뒤라 이식이 곧 재작성이 되므로, 얇은 방어만은 처음부터 넣는 것이 저렴하다.

9.1.10 오픈이냐 폐쇄냐와 얽힌다

스펙트럼에서 ④ 이상으로 올라가는 결정은 오픈 대 폐쇄 웨이트 선택과 분리되지 않는다. 상세한 라이선스·생태계는 9.2가 다루므로, 여기서는 build 대 buy 결정과의 얽힘만 다룬다. 폐쇄 웨이트는 가중치가 벤더 서버 안에 있고 API로만 접근하는 형태로, 스펙트럼 ①~③에 자연히 대응하며 가중치를 직접 파인튜닝(④)할 수 없고 온프레미스 배포(8.4)가 원칙적으로 불가하다. 오픈 웨이트는 가중치를 받아 자기 인프라에서 실행하는 형태로, 스펙트럼 ④~⑥의 전제이며 파인튜닝·양자화·자체 서빙·온프레미스가 전부 가능하다.

단 "오픈 웨이트 ≠ 오픈소스 ≠ 자유로운 상업 이용"이다. 라이선스가 상업·재배포·규모를 제약할 수 있고, 라이선스를 안 읽고 파인튜닝했다가 배포를 못 하는 사고가 흔하다(9.2). 그리고 중간 지대에 함정이 하나 있다. 일부 폐쇄 벤더는 "당신 데이터로 우리 모델을 파인튜닝해 주는" 매니지드 서비스를 제공한다. ④의 이점 일부(도메인 특화)를 buy의 편의로 얻지만, 결과 가중치를 반출할 수 없는 경우가 많아 락인이 오히려 깊어진다. "파인튜닝했으니 우리 것"이라는 착각을 조심해야 한다 — 벤더 플랫폼을 떠나는 순간 그 투자는 사라질 수 있다.

요컨대 "얼마나 build할 것인가(스펙트럼)"와 "오픈이냐 폐쇄냐"는 같은 결정의 두 측면이다. ④ 이상을 원하면 오픈 웨이트(또는 반출 불가를 감수한 매니지드)로 좁혀지고, 규제가 데이터 반출을 막으면 오픈 웨이트에 온프레미스가 사실상 강제된다. 그래서 파인튜닝을 논의할 때 라이선스와 반출 가능성을 함께 논의에 포함하지 않으면, 스펙트럼 결정과 오픈·폐쇄 결정이 어긋나 뒤늦게 값을 치른다.

9.1.11 위에서 아래로 내려가며 풀기

지금까지의 인자·비용·얽힘을 하나의 결정 흐름으로 합치면, 그것은 강요가 아니라 리듬이다 — 가장 저렴하게 바꿀 수 있는 단에서 먼저 풀고, 안 될 때만 한 단씩 내려간다. 비용의 비대칭이 이 방향을 정당화한다. 프롬프트는 몇 분이면 배포하고 롤백하지만 재학습은 몇 주가 걸리고 되돌리기도 어렵다. 위층에서 풀릴 문제를 아래층으로 끌고 가면 시간과 돈을 함께 잃는다.

세 가지가 이 흐름의 핵심이다. PMF 이전에는 거의 항상 ①이다 — 아직 팔릴지도 모르는 제품을 위해 아래층을 짓는 것은 대개 낭비이고, 파운데이션을 짓는 동안 시장이 사라진다. 각 분기는 "더 싼 단에서 안 풀리는가?"를 묻는다 — 위 단에서 풀리면 거기서 멈추고, 파인튜닝·지속학습·직접학습은 위 단이 근본적으로 부족할 때만 정당하다. 그리고 점선은 되돌아옴이다 — 자체 서빙으로 갔다가 수요 폭증이나 품질 격차로 다시 API로 오는 것도 정상이며, 9.1.9의 이식성이 이 왕복을 저렴하게 만든다. build 대 buy는 일방통행이 아니다.

9.1.12 누구에게 언제 맞나

아래는 강한 규칙이 아니라 출발점으로서의 내 견해다. 반례가 많고, 팀의 데이터·규제·자본이 답을 뒤집는다.

초기·PMF를 탐색하는 스타트업은 ① API에 ②·③(프롬프트·RAG)을 추가한 데 머무는 편이 옳다. 최상위 역량에 즉시 닿고 선투자 0으로 최대한 빨리 검증하며, 차별화는 모델이 아니라 제품·데이터 인덱스·UX·워크플로우에서 만든다. PMF 전에 파인튜닝·자체 서빙에 내려가는 것은 손익분기(9.1.7)에 한참 못 미쳐 비용이 크고, 아직 무엇을 특화할지도 모르는 상태다. 초기부터 얇은 게이트웨이와 평가셋 보존만 해 두어 이전 옵션을 살려 두고, 마진을 벤더 단가에 지나치게 의존하지 않도록 유닛 이코노믹스를 주시한다(7.5).

규모가 커진 엔터프라이즈는 한 단을 고르는 대신 포트폴리오로 배치한다. 대부분의 워크로드는 ①~③에 두고, 대량·반복·비용 민감한 워크로드만 ④(오픈웨이트 파인튜닝 + 자체 서빙)로 이전해 손익분기를 넘긴 곳에서 단가를 회수하며, 멀티 벤더 라우팅으로 협상력과 가용성을 확보한다. 여기서 실제 자산은 사내 지식·로그 플라이휠(8.1)이지 파인튜닝 자체가 아니다. 가장 흔한 실패는 "우리도 자체 모델"이라는 정치적 압력에 손익분기 계산 없이 GPU를 사들이고, 엔지니어링·운영 인건비($E$, $O$)를 과소평가하는 것이다.

규제 산업 — 금융·의료·공공·국방 — 은 데이터 주권이 다른 인자를 압도하면 ④ 이상에 온프레미스(8.4)가 사실상 강제된다. 오픈 웨이트를 프라이빗으로 서빙하고 필요 시 파인튜닝하며, 이때는 최적화가 아니라 제약 만족이라 비용·속도가 불리해도 감수한다. 다만 리전 격리·전용 배포·데이터 미학습 계약을 제공하는 폐쇄 벤더 옵션이 규제를 만족시키면 ①도 가능하니, 법무·컴플라이언스와 함께 판단해야 한다(9.3). 오픈 웨이트 라이선스와 데이터 출처(저작권)를 확인하지 않으면 규제 회피가 새 규제 위반을 낳는다.

연구소·프런티어 랩은 ⑤·⑥이 정당화되는 거의 유일한 자리다. 모델 자체가 연구·사업의 목적이고 대규모 컴퓨트·데이터·리서치 인재를 보유한다. 그럼에도 모든 것을 처음부터 하지는 않는다 — 오픈 웨이트에서 출발한 지속 사전학습·정렬 연구가 훨씬 흔하다. 여기서의 함정은 학술적 새로움을 제품 가치로 착각하는 것이다. 파운데이션을 훈련할 역량이 있다는 것과 그것이 최선의 자원 배분이라는 것은 별개다.

9.1.13 대부분은 파운데이션을 처음부터 학습하면 안 된다

이 장에서 가장 중요한 한 문장은 이것이다. 거의 모든 팀에게 ⑥(파운데이션 처음부터)은 오답이다. 마케팅과 자존심이 이 결정을 흐리므로, 근거를 숫자로 확정해 둘 값어치가 있다. 프런티어급까지는 아니어도 그럴듯한 중형 모델 하나를 처음부터 학습한다고 하고, 컴퓨트 비용의 하한을 스케일링 법칙(2.2)으로 추정해 보자.

학습 FLOP은 대략 $6ND$ 로 추정한다($N$ 은 파라미터 수, $D$ 는 학습 토큰 수). 70B 파라미터 모델을 컴퓨트 최적에 가깝게 1.4조 토큰으로 학습한다면

$$\text{FLOPs} \approx 6ND = 6 \times 70\times10^9 \times 1.4\times10^{12} \approx 5.9\times10^{23}$$

가속기 한 대의 지속 처리량을 실효 400 TFLOP/s(피크 약 1000 TFLOP/s에 실제 활용률 40% 가정)로 두면, 필요한 GPU-시간은

$$\frac{5.9\times10^{23}}{4\times10^{14}\ \text{FLOP/s}} \approx 1.5\times10^{9}\ \text{GPU-초} = \frac{1.5\times10^{9}}{3600} \approx 41\text{만 GPU-시간}$$

이다. GPU 시간당 \$2.5로 환산하면 한 번의 깨끗한 학습 런에 약 $\$1.0$M — 컴퓨트만이다. 그런데 한 번에 성공하지 않는다. 발산·버그로 재시작이 흔하고(2.6), 하이퍼파라미터 스윕·아블레이션까지 더하면 실효 컴퓨트가 쉽게 2~5배로 증가한다. 게다가 요즘은 추론 효율을 위해 컴퓨트 최적보다 훨씬 많은 토큰(예: 10조)으로 과학습하는 경우가 많은데, 그러면 FLOP이 7배로 늘어 단일 런만 \$7M 안팎, 재시작까지 넣으면 컴퓨트만 수천만 달러 규모가 된다. 여기에 데이터 파이프라인(2.1), 분산학습 인프라(2.4·2.5), 그리고 6~18개월간 붙는 리서치 팀 인건비가 추가된다. 요컨대 "그럴듯한, 그러나 이미 한 발 뒤진" 모델 하나에 최소 수백만~수천만 달러이고, 실제 프런티어를 노리면 자릿수가 또 올라간다.

이것이 오답인 이유를 넷으로 정리하면 이렇다. 비용 — 방금 본 하한에 실패한 런과 인프라가 더해져, "한 번 훈련비"가 아니라 "여러 번 훈련비"로 산정해야 한다. 인재 — 대규모에서 안정적으로 사전학습을 수행할 수 있는 팀은 세계적으로 소수이고, 극도로 희소·고가라 돈이 있어도 팀을 못 꾸리는 경우가 대부분이다. 데이터 — 수조 토큰 규모의 고품질·중복제거·법적으로 깨끗한 데이터가 필요한데(2.1), 웹을 긁는 것으로는 부족하고 필터링·혼합·저작권(9.3)이 겹쳐 대부분의 팀은 프런티어 랩만큼의 데이터에 닿지 못한다. 시간과 진부화 — 몇 달~몇 년이 걸리는 사이 다음 프런티어 오픈 웨이트가 당신의 결과물을 추월하고, 당신의 from-scratch 모델은 완성되는 순간 이미 노후화됐을 수 있으며, 따라잡으려면 다시 처음부터 돈을 낸다. 감가상각 부담이 크다.

그리고 대안이 가치의 대부분을 훨씬 저렴하게 확보한다. 오픈 웨이트에서 출발한 파인튜닝(④)·지속 사전학습(⑤)은 처음부터 짓는 비용의 극히 일부로 도메인 특화의 대부분을 얻고, 프런티어 능력이 필요하면 API(①)가 즉시 준다. ⑥이 정당한 경우는 모델 자체가 대체 불가능한 해자이고, 자본·팀·데이터·시간을 전부 갖췄으며, 기존 어떤 모델로도 근본적으로 부족한 — 이 세 조건의 교집합뿐이고, 그것을 만족하는 팀은 극소수다.

결국 이 장 전체가 한 문장으로 수렴한다. build는 목적이 아니라 수단이다. 스펙트럼을 오른쪽으로 미는 것 자체는 미덕이 아니며, 그것이 통제·해자·비용에서 측정 가능한 우위를 줄 때만 정당하다. 그 우위를 재는 자가 평가셋이고, 그 우위가 시한부인지 지속적인지를 가르는 것이 9.1.5의 질문이며, 그 우위를 오픈이냐 폐쇄냐와 맞물려 좁히는 것이 다음 장의 주제다. 파인튜닝 이상으로 내려가기로 했다면 이제 오픈 웨이트의 실제 의미를 알아야 한다 — Llama·Mistral·Qwen·DeepSeek 같은 오픈 웨이트가 무엇을 허용하고 무엇을 막는지, "오픈 웨이트 ≠ 오픈소스 ≠ 자유로운 상업 이용"의 라이선스 지형이 build 대 buy 결정을 어떻게 다시 좁히는지를 9.2에서 다룬다.