120조 원 컴퓨트 딜이 우리 제품 결정을 흔드는 방식

$450억짜리 컴퓨트 딜이 두 번. 합치면 약 120조 원이 Anthropic 한 곳으로 향한다.

TechCrunch 보도에 따르면 유럽 기반 GPU 클라우드인 Nscale과 Anthropic이 8월에 이미 $450억 규모의 컴퓨트 공급 계약을 맺었고, 지금 같은 규모의 2차 딜을 또 협상 중이다. AI 인프라 역사상 단일 공급사가 이 물량을 소화한 전례는 없다. 당연히 헤드라인을 장식한다.

그런데 이 뉴스를 "Anthropic 돈 많네"로 읽으면 아무것도 가져갈 게 없다. 컴퓨트 딜의 진짜 파장은 클라우드 서버실 깊숙한 곳이 아니라, 우리가 매일 날리는 API 호출 한 줄에 담겨 있다.

단, 이 이야기에는 불편한 반전이 있다. 컴퓨트가 늘어나면 모델이 더 자주, 더 빠르게 바뀐다. 그게 지금 잘 돌아가는 제품을 가장 조용하게 망가뜨리는 원인이 된다.

$90B 컴퓨트가 모델 출시 속도를 어떻게 바꾸나

AI 모델 훈련은 결국 GPU 시간 싸움이다. GPT-4급 모델 하나를 훈련하는 비용이 대략 $50M~$100M으로 추정된다. 이 기준으로 보면 $90B은 이론상 900회 이상의 대규모 훈련 run을 돌릴 수 있는 금액이다. 물론 전기비·운영비가 섞이니 그대로 나누는 건 무리지만, 방향은 분명하다.

더 크고 더 나은 모델이 더 자주 나온다.

Claude 3 시리즈가 나온 게 2024년 초였고, 이미 버전 넘버가 붙은 Haiku·Sonnet·Sonnet 3.7·Sonnet 4가 1년 반 안에 연이어 등장했다. 컴퓨트 공급이 2배로 늘면 이 주기는 더 짧아질 것이다. 제품팀이 "이번 달에 신모델 평가할 여유가 없다"고 넘기다가, 어느 날 현재 버전이 deprecated 대기열에 올라 있는 걸 발견하게 된다.

두 가지 얼굴 — 싸지는 API 비용과 불안정해지는 출력

좋은 소식부터. 컴퓨트 여유가 생기면 추론 비용이 내려간다. Anthropic은 이미 Haiku 급 모델을 사실상 원가 근처로 운영하고 있고, 공급이 늘면 이 추세는 계속될 가능성이 높다. 우리 팀은 블로그 자동 생성, 앱 리뷰 분류, 발행 콘텐츠 검수에 하루 수백~수천 건씩 claude_cli를 호출한다. 이 단가가 떨어지면 새 기능을 붙일 때마다 "비용이 얼마나 늘지"를 먼저 계산하는 습관이 좀 느슨해진다.

불편한 진실은 모델 교체 속도가 프롬프트 안정성을 건드린다는 점이다.

악플 감지 AI 서비스를 만든 허성범 개발자의 케이스가 여기서 딱 겹친다. 댓글 수십만 건을 실시간으로 분류하는 제품을 소수 팀이 운영할 때, 모델 한 세대 교체가 "독성 판단 기준" 자체를 조용히 이동시킨다. 예전엔 그냥 넘기던 표현이 새 모델에선 독성으로 잡히거나, 반대로 명백한 악플이 통과된다. 코드는 아무것도 안 바꿨는데 사용자가 "갑자기 이상해졌다"고 느끼는 게 이 경우다.

이건 사용자 신뢰 문제다. 기술 이슈가 아니라.

우리 팀이 실제로 겪는 시나리오

HEDVION은 지금 10개가 넘는 봇에서 Claude를 호출한다. 모델 버전은 코드에 명시적으로 박혀 있다 — claude-haiku-4-5-20251001 식으로. 직접 겪어봤는데, 이 방식이 안전하긴 해도 딜레마가 있다. 새 모델이 나왔을 때 "지금 버전보다 좋다"는 걸 알면서도 교체 작업의 부담 때문에 미루다가, deprecated 공지를 늦게 확인해서 하루아침에 봇 호출이 다 실패한 적이 있다. 버전 이름 하나 고치면 5분이지만, 그 이후 프롬프트 동작이 미묘하게 달라졌는지 확인하는 QA가 진짜 문제다.

Anthropic의 컴퓨트 규모가 2배가 되면, 1년 안에 지금보다 성능이 한 단계 뛰어오른 Haiku 급 신모델이 나올 게 거의 확실하다. 그때 선택지는 두 가지다.

버전 고정 + 주기적 마이그레이션 테스트 전략은 지금처럼 버전을 명시하되, 신모델 출시 때마다 스테이징에서 기존 프롬프트를 돌려 출력 품질을 비교하는 파이프라인을 미리 만들어두는 것이다. 귀찮지만 가장 안전하다.

최신 버전 alias 자동 따라가기 전략은 claude-haiku-latest 같은 alias를 쓰는 것. 최신 성능을 자동으로 누리지만, 모델 교체 시점에 프롬프트 동작이 조용히 바뀌어도 알아채기 어렵다. 우리처럼 콘텐츠 검수 게이트, 발행 품질 판정 같은 사용자 노출 로직이 있는 봇을 운영한다면 이건 너무 위험하다. 모르는 사이에 검수 기준이 틀어진 채 한 달치 콘텐츠가 나가는 시나리오가 충분히 가능하다.

벤더 집중 리스크, 지금 설계 안 하면 나중에 더 비싸진다

$90B이 Anthropic 한 곳에 집중된다는 건, 역설적으로 Anthropic을 쓰는 제품팀의 벤더 의존도가 더 깊어진다는 신호다. 인프라가 탄탄해질수록 "다른 모델로 갈아탈 이유"가 줄어들고, 프롬프트·파이프라인·평가 기준이 전부 Anthropic 모델 특성에 맞춰 최적화된다.

처음엔 "API 하나 바꾸면 되지 않나" 싶었는데, 실제로 해보면 모델 교체는 단순 코드 수정이 아니다. 프롬프트 재튜닝, 출력 형식 검증, 엣지케이스 재테스트 — 이 과정이 소수 팀에서는 며칠 작업이고, 봇이 10개면 곱하기 10이다. OpenAI도 GPT-3.5-turbo 때 같은 패턴이었다. 대부분의 스타트업이 거기 다 묶였다가, deprecated 스케줄 발표마다 마이그레이션 공황이 생겼다. Anthropic도 같은 패턴을 밟을 것이다 — 더 빠른 속도로.

지금은 "그냥 써도 괜찮은" 국면이지만, 설계는 지금 하는 게 낫다.

지금 당장 써먹을 수 있는 판단 기준 세 가지

모델 버전 교체 정책을 한 줄이라도 문서화해라. "신버전 나오면 스테이징에서 2주 테스트 후 교체"처럼. 없으면 사람마다 판단이 달라지고, 급할 때 "일단 올려보자"가 나온다. 조용한 품질 저하는 그때 시작된다.

지금 잘 나오는 출력 50개를 golden set으로 저장해둬라. 모델이 바뀔 때 "이전이랑 같은가"를 판단하려면 비교 기준이 있어야 한다. 50개면 충분하다. 없으면 "느낌상 비슷한 것 같다"로 교체 결정을 내리다가, 사용자가 이상하다고 리포트할 때 처음 알게 된다.

API 호출 로그에 사용 모델명을 반드시 남겨라. deprecated 전환이 예고 없이 동작 변화를 만들 때, 로그에 모델 버전이 있으면 "모델이 바뀐 거 아닌가"를 30초 안에 확인할 수 있다. 없으면 디버깅 시간이 두세 배 늘어난다.

Anthropic이 120조짜리 인프라를 깔아두는 동안, 제품팀이 할 일은 그 위에서 사용자가 일관된 경험을 받도록 완충재를 만드는 것이다. 모델이 빨라지고 좋아지는 건 알아서 따라간다. 흔들리지 않게 잡아두는 건 우리 몫이다.

원문: AI News & Artificial Intelligence | TechCrunch