요약
앤트로픽 IPO를 앞두고 투자자들이 기업가치를 1조 1000억 달러까지 낮춰 보고 있습니다.
블룸버그가 사정을 아는 사람들을 인용해 전한 소식입니다. 선거 뒤 AI 관련 주식이 크게 팔려 나가자, 앤트로픽 상장에 참여하려던 투자자들이 기대 기업가치를 다시 따져 보고 있습니다.
왜 중요한가
- 선거 뒤 AI 주식 매도세가 상장을 준비하는 AI 연구소의 몸값 평가로까지 번졌습니다.
- 정식 상장 마케팅을 코앞에 두고 투자자 쪽 기대치가 내려가, 공모 가격 논의가 더 낮은 선에서 시작됩니다.
핵심 내용
- 잠재 투자자들은 1조 2000억~1조 3000억 달러를 기업가치 범위로 논의하고 있습니다.
- 소식통 한 명에 따르면 일부는 1조 1000억 달러까지 낮춰 보고 있습니다.
- 앤트로픽은 다음 주부터 투자자를 상대로 정식 IPO 마케팅에 나설 예정입니다.
- 투자자들이 기대치를 다시 따지게 된 계기는 선거 뒤 이어진 혹독한 매도세입니다.
HN 반응
- 로컬 모델이 '충분히 좋은' 수준에 이르러 AI 대기업 가치가 부풀었다는 의견과, 코딩은 아직 Opus 5.5를 못 따라온다는 반론이 맞섰습니다.
- 구독 요금으로는 원가를 감당할 수 없다는 의견에, 일부 이용자는 S-1(상장 신고서)의 매출총이익률 85%를 근거로 반박했습니다.
유료 구독 기사라서 원문의 앞부분만 보고 정리했습니다.
물론 작은 일화에 불과한 데이터 포인트이긴 한데, Strix Halo 박스에서 Qwen3.8-Flash-Next를 잘 돌리게 된 뒤로 Claude Pro 구독 사용량이 뚝 떨어졌어요. 이번 주 할당량을 18%밖에 안 썼어요. 오늘이 금요일이니까 예전 같으면 적어도 80%는 썼을 거예요. 로컬에서, 그것도 제 PC에서 꽤 잘 돌아가는데 정말 놀라울 만큼 좋은 모델이에요. 몇 달 뒤 갱신 시기가 와도 Claude Pro 구독은 갱신할 생각이 없어요.
미래가 로컬 모델이면 좋겠어요. 모든 회사가 사업을 굴리거나 제품을 만들려고 소수의 빅테크 기업에서 토큰을 사 와야 한다는 발상이 끔찍하다고 생각하거든요.
저는 이 사이트에서 이런 예측을 했다가 욕을 먹은 적이 있습니다. 최전선(즉 가장 어려운 문제)은 앞으로도 가용 컴퓨팅 파워의 한계를 계속 밀어붙이겠지만, 보통 사람들이 AI로 하는 일이 늘 최전선에 있지는 않을 것이고, 최전선에 나타나는 것이 반드시 돈이 되는 것도 아닙니다. 예전에는 체스, 아타리, 바둑이 최전선이었습니다. 도전적인 과제였고 AI를 크게 발전시켰지만 큰돈이 되지는 않았습니다. 지금은 휴대폰으로도 이걸 다 할 수 있습니다.
당신이 바로 그 과정의 사례입니다. 예전에는 데이터센터에서 돌아가는 최전선 모델이 필요했습니다. 알고리즘이 좋아졌고 아마 하드웨어도 좋아졌겠지만, 당신의 요구 사항은 높아지지 않았습니다. 이제는 필요한 일을 로컬 하드웨어로 해냅니다. 흥미로운 새 최전선 활용처를 찾지 않는 한, 앞으로 앤트로픽에 돈을 보내지 않아도 될 AI 사용자 한 명인 셈입니다.
그래서 저는 AI 대기업의 기업 가치를 조금 비관적으로 봅니다. 지금 최전선에는 분명 돈이 되는 일이 몇 가지 있지만, 앞으로는 사람들이 지금 하는 일의 상당수를 로컬 하드웨어로 옮겨 갈 수 있고, 최전선에 새로 생기는 일은 수조 달러의 빚을 갚을 만큼의 이익을 내지 못할 수도 있습니다. AI 기업들은 자신들이 새로운 활용처를 끊임없이, 영원히 찾아낼 수 있고, 게다가 그 활용처가 돈이 된다는 데 크게 걸었습니다.
2025~2026년의 추세가 오픈 웨이트 모델과 로컬 추론에서 2027~2028년까지 이어진다면, 1,200억 파라미터급 오픈 모델이 오늘날 사용 사례의 80%에는 충분하고도 남을 것이라는 데 동의합니다. 그렇다면 오픈AI와 앤트로픽, 그리고 AI 인프라 구축을 어떻게 정당화할 수 있습니까?
저는 모델이 좋아질수록 점점 더 야심 찬 프로젝트를 만들고 있습니다. 개인적으로도, 직장에서도요.
제가 말을 잘못했네요. 요구 사항이 로컬 모델의 성능 향상 속도보다 빠르게 늘지는 않았다고 말했어야 했습니다. 코딩에 관해서는 로컬 모델과 하드웨어의 성능이 대부분 사람의 필요보다 더 빠르게 올라갈 것으로 봅니다. 샘 올트먼이 당신의 RAM을 불순한 의도로 노리는 것도 아마 그 때문일 겁니다.
오픈 웨이트/로컬 모델이 중요하긴 하지만 Fable/Astra 같은 최전선 모델과는 경쟁이 안 됩니다. 근처에도 못 갑니다.
적어도 탄탄한 하이브리드 모델이 미래가 되지 않으리라고는 믿기 어렵습니다. 시장 지배력이 약한 고객에게 상대적으로 높은 마진으로 하드웨어를 팔아서 벌 수 있는 돈이 너무 많아서, 하드웨어 업체를 소비자와 소규모 사업자 시장에서 무기한 밀어낼 수는 없을 겁니다.
충분히 쓸 만한 로컬 모델, 훌륭한 클라우드 모델, 그리고 모든 소형 기기에서 실리콘에 내장되어 돌아가는 더 단순하고 특화된 모델이 공존하게 될 것 같습니다.
흥미롭네요. 저도 3.8-flash-next(4비트 양자화, 추론은 llama, 하네스는 pi, 128GB Strix Halo 머신)를 Claude Code의 opus 5.5와 비교해 보고 있는데, qwen이 좋고 빠른 모델이긴 해도 코딩에서는 근처에도 못 미칩니다. haiku 5.5가 오히려 더 낫게 느껴질 정도입니다.
쉬운 작업용 일종의 “서브 haiku”로 쓰면서 더 큰 Claude 모델에 쓸 토큰을 아끼는 건 상상이 가지만, 당장 Claude 구독을 해지할 일은 없을 겁니다.
opus 5.5에는 확실히 한참 못 미치지만, opus 4.5가 넘었던 것과 같은 문턱, 즉 “충분히 쓸 만하다”는 선을 넘었어요. 내일 모든 서비스형 모델 회사가 문을 닫는다 해도, 제 Strix Halo에서 돌아가는 qwen 3.8 flash next q4만 있으면 만족할 거예요.
여기서 문제는 우리가 말하는 게… 음… 햄버거 얘기가 아니라는 거예요. 제가 맥도날드를 버거킹보다 좋아한다고 해도, 배고픈데 근처에 맥도날드가 없으면 버거킹 버거를 사 먹는 걸 막지는 못하죠. 한쪽이 조금 더 맛있을 수는 있어도 서로 충분히 대체할 수 있잖아요.
코딩 AI는 햄버거가 아니에요. 로컬 LLM이 Opus 4.5만큼 좋다 해도(수천 달러를 하드웨어에 쏟아부었을 때 얘기고, 저는 그래도 의심스럽지만요) 모델 사이의 실제 차이는 엄청나게 커요.
제가 월 200달러짜리 Claude를 쓴다고 해 볼게요(안 쓰고 더 싼 요금제를 쓰지만, 일단 그렇다고 치고요). Opus 4.5급 로컬 LLM으로 바꿨는데 5.5였다면 내지 않았을 프로덕션 장애를 단 한 번이라도 내면, 그 실수는 수천 달러가 들어요.
그 “더 싼” 모델은 사실 더 싸지 않아요.
Opus가 항상 더 낫다고 가정하시는데, 클라우드 AI 제공업체는 품질이 들쭉날쭉할 수 있어요. 몇 달 동안은 아주 쓸 만하다가도 어떤 시기에는 품질이 뚝 떨어지기도 하죠. 온라인에서는 제공업체가 새 모델을 학습시키거나 서비스에 사용자가 너무 몰릴 때 품질을 낮춘다는 추측이 돌아요. 로컬 모델에는 그런 문제가 없어요.
서비스 품질이 이 정도로 오락가락하는 것만으로도, 더 일관적이라는 이유로 로컬에서 돌리는 모델을 선호하는 기업이 많을 수 있어요.
맞아요, 가끔은 qwen이 더 낫기도 해요(q3인데도요). 어제 둘한테 로그의 한 줄이 무슨 뜻인지 물어봤는데, opus는 “아, 그냥 DNS 서버가 eodns에서 udp로 폴백한 거예요, 걱정 마세요”라고 했고, qwen은 그 IP 주소가 도커 서브넷이라는 걸 제대로 알아보고 거기로 DNS를 보내지 말라고, 아마 뭔가 잘못된 거라고 했어요.
Opus 4.5보다 훨씬 나아요. 이 스레드 다른 곳에 올린 스트레스 테스트(OCaml로 작성한, 최적화가 들어간 C -> 마이크로코드 컴파일러로, 마이크로코드와 Verilog 출력을 생성해요)를 보세요. 올해 초에 이 컴파일러의 원래 C 버전을 짜려고 Opus 4.6/4.8을 쓸 때보다 더 잘하고 있어요. 그때 Claude가 떠올리지 못한 최적화도 내놨고요.
원래 컴파일러를 만들 때 opus에게 오라클이 있었나요? 없었다면 qwen이 더 잘하는 게 당연하죠.
알려진 대로 LLM은 검증 비용이 낮을 때는 놀랍고, 비쌀 때는 훨씬 덜 쓸모 있어요.
실제로 있었어요. yacc 기반의 예전 구현이 있었는데 아키텍처상 한계가 많았어요. 더 나은 아키텍처로 처음부터 다시 만드는 게 낫다고 판단했지만, 생성된 마이크로코드를 처음에 비교해 볼 수 있도록 그 예전 구현을 그대로 갖고 있었어요.
여기에 몇 가지 짚고 싶은 점이 있습니다.
첫째, 최전선은 들쭉날쭉합니다. Qwen3.8 Flash Next가 내는 오류 중에 Opus 5.5는 내지 않는 것이 있고, 반대로 Opus 5.5가 내는 오류 중에 Qwen3.8 Flash Next는 내지 않는 것도 있습니다. 후자가 대체로 더 적겠지만 0은 아닙니다. 능력 차이가 정말 크지 않은 한 모델 사이에는 전순서가 없고 부분 순서만 있습니다.
그리고 덧붙이자면, 오류를 최소화하려고 Opus 5.5를 항상 최대 추론 설정으로 돌리시나요? 대부분은 그렇게 하지 않을 겁니다. 다들 이 정도면 충분하다는 감과 비용을 저울질하는 나름의 직관이 있으니까요.
둘째, Opus 5.5의 강점은 자율 작업입니다. 대화형, 사람이 개입하는(HITL) 작업에는 썩 좋은 선택이 아닙니다. 툴 사용보다 복잡한 Bash 명령과 알아보기 힘든 Python 스크립트를 선호하고, 자기가 무엇을 하는지 설명조차 하지 않는 경우가 많다는 점이 그렇습니다. 가상의 페어 프로그래머로 쓰기에는 좋지 않습니다. 하는 일을 따라가며 머릿속 모델을 유지하기가 다른 모델보다 어렵기 때문입니다(다만 자율 작업을 우선하는 벤치마크 때문인지, 이런 문제와 관련 문제가 다른 모델에도 번졌습니다). CLAUDE.md 지침으로 어느 정도 해결할 수는 있지만 그래도 완벽하지는 않습니다.
마지막으로, 정확성을 보장하려고 모델이 실수하지 않기를 기대한다면 소프트웨어 개발 프로세스가 근본적으로 잘못된 겁니다. 어떤 모델이든 최소한 어느 정도는 오류를 낸다고 가정하고, 그것을 감안한 개발 프로세스가 필요합니다. 여기서 문제는 어떤 모델이 오류를 덜 내느냐가 꼭 아니라, 어떤 모델이 오류를 발견하기 쉬운 코드를 만드느냐입니다. 아이러니하게도 더 강력한 모델은 더 복잡한 코드를 만들어서 발견을 더 어렵게 만들 수 있습니다.
FrontierBench 2.0 [1]의 추론 노력 수준에서도 이와 비슷한 효과를 볼 수 있습니다.
“FrontierCode는 (올바른) 코드를 더 많이 작성한다고 해서 모델 점수가 반드시 오르지는 않는 몇 안 되는 코딩 벤치마크입니다. 그래서 흥미로운 현상이 생깁니다. 추론 노력을 높일수록 모델 점수가 낮아질 수 있다는 것입니다. 이런 비단조성은 사용자 체감과 자주 일치하지만 다른 평가에서는 보기 어렵기 때문에, 우리는 이를 이 벤치마크의 유용한 특징으로 봅니다.”
예를 하나 들면 이렇습니다.
“이 과제는 앱이 분석 이벤트를 기록하는 데 쓰는 PostHog의 오픈 소스 Android SDK에서 가져왔습니다. 기기가 오프라인이면 SDK는 이벤트를 디스크에 쓰고 앱이 다음에 시작될 때 전송합니다. 과제는 두 모듈이 동시에 데이터를 보내는 시작 시 버그를 고치는 것입니다. 라이브 큐는 새 이벤트를 보내고, 레거시 통합인 PostHogSendCachedEventsIntegration.kt는 캐시된 이벤트를 보냅니다. 둘이 경합을 벌여 이벤트가 서버에 순서가 뒤바뀐 채 도착합니다.
“낮은 노력 수준에서 GPT-6 Astra는 캐시 로딩을 PostHogQueue.kt로 옮기고, 레거시 통합에서 전송 로직을 제거하며, SDK의 공개 API는 건드리지 않아 통과하는 해법을 내놓습니다.
“최대 노력 수준에서는 모델이 PostHogSendCachedEventsIntegration.kt를 아예 삭제하고 그 책임을 다른 레거시 파일들에 흩뿌리는 경우가 많습니다. 이렇게 해도 경합은 해결되고 숨겨진 동작 테스트 대부분도 통과합니다. 하지만 삭제된 클래스는 SDK의 공개 posthog.api 표면의 일부여서, 이를 참조하는 모든 앱에 불필요한 호환성 파괴 변경을 일으킵니다. 모델이 특정 파일을 수정하지 않았는지 결정적으로 검사하는 범위 차단기(scope blocker)가 이 변경을 잡아내고, 에이전트는 과제에서 실패합니다.”
[1] https://cognition.com/blog/frontier-code-2.0
그 부분은 동의해요. 지금까지 본 바로는 저도 opus 4.5 언저리 어딘가라고 봐요.
“충분히 쓸 만하다”는 개인 프로젝트에는 충분할 수 있지만, 경쟁이 치열한 환경에서 “그럭저럭 쓸 만한” 모델을 쓰는데 경쟁자들은 Opus 5.5 같은 최전선 모델을 쓴다면 상당히 불리해질 거예요.
꼭 그렇지는 않아요. “모든 모델은 실수한다”를 전제로 프로세스를 짠다면 모델이 얼마나 자율적으로 움직일 수 있는지를 제한하게 될 테고, 그러면 그 문턱을 넘은 모델들 사이에 체감되는 차이는 별로 없어요.
경쟁 환경에서는 비용과, 특정 업체에 종속되지 않는 것도 따져 볼 요소예요.
일종의 스트레스 테스트로 지난 이틀 동안 시켜 본 작업이 있어요. C로 작성된 C -> 마이크로코드 컴파일러가 있어요(대부분 Opus 4.6/4.8 시절에 “그때” 해 둔 작업이에요). 그 컴파일러 문서를 주고 OCaml로 구현해 달라고 했어요(흔한 언어는 아니지만 컴파일러를 짜기에는 좋은 구현 언어거든요). 비교 기준(golden)으로 첫 번째 컴파일러를 쓸 수 있고요. 구조는 대략 C 언어 파서 -> AST -> IR -> [최적화 패스] -> 마이크로코드(+ Verilog 코드 일부)예요. 지금은 원래 컴파일러가 있던 수준까지 거의 따라잡았어요. 마이크로코드를 생성할 뿐 아니라, 그 마이크로코드를 로드해 실행하는 Verilog 코드도 생성해야 하고, 기능을 확인하려고 Verilator에서 시뮬레이션도 돌려야 해요. 원래 컴파일러에 없는 새 최적화를 제안해 보라고 했더니 몇 가지를 내놨는데, 경우에 따라 마이크로코드 줄 수를 최대 30%까지 줄여 줘요(이 머신에서는 마이크로코드가 적을수록 성능이 좋아요). 원래 컴파일러를 작업하던 4.6/4.8 시절에 Claude가 떠올리지 못한 아이디어들이에요(다른 최적화가 없는지 여러 번 물어봤던 기억이 나요).
그래서 종합하면 최소한 Opus 4.8 수준이고, 어떤 면에서는 4.8을 넘어서고 있다고 봐요.
비행기 안에서 이것저것 실험해 보려고 MBP에서 Ollama로 Qwen 3.8 27b를 써 봤는데, 꽤 복잡한 PDF 처리 작업 하나에서 놀랄 만큼 잘하더라고요.
감으로 보기엔 Opus 5.5만큼 좋았어요. 조금 더 느리고, 원하는 결과를 얻으려면 프롬프트를 조금 더 손봐야 했지만요(앱 파이프라인용으로는 그 정도면 괜찮죠).
느린 것도 하드웨어 때문일 뿐이고요.
저는 월 32달러(AUD)짜리 구독을 쓰고 있었는데, 어제 5시간 한도에 걸린 뒤 작업을 끝내려고 결국 추가 크레딧에 손을 댔어요.
세상에, 15달러어치 추가 크레딧으로 Claude Code를 30분밖에 못 썼어요. 그러고 바닥났어요.
구독 가격이 재정적으로 지속 가능할 리가 없어요. 실제 운영 비용에 조금이라도 근접할 방법이 없다고요.
다르게 보면, API 요금을 내는 고객들이 트래픽 처리 비용보다 훨씬 많은 돈을 앤트로픽에 내고 있다는 뜻이에요. S-1에 매출총이익률 85%라고 보고했으니, 분명히 그런 것 같아요.
좋아요, 그런데 마진이 85%라고 해도 30분 사용의 실제 원가는 2.25달러예요. 그 원가면 34달러로는 7.5시간밖에 못 써요. 평균 사용자는 그보다 더 쓰지 않을까요?
아마 틀리게 짐작하셨을 거예요.
중간 사용자는 기껏해야 AI를 검색 엔진, 밈 제작기, 그리고/또는 챗봇으로 쓰는 정도예요…
토큰/API 대신 구독을 쓰는 프로그래머 일부가 만들어 내는 추가 비용은 마케팅 비용으로 쉽게 분류할 수 있어요.
기껏해야요? 그 주장의 근거가 되는 데이터가 있나요, 아니면 본인을 투영해서 추측하는 건가요? AI 맥시멀리스트들은 사람들이 이걸 상담사로 쓰고, 어떤 연인보다도 친밀한 대화를 나눈다고 믿게 하려 들죠. AI 미니멀리스트들은 총구를 들이대지 않으면 아무도 이걸 안 쓰고, 그래도 안 쓴다고 믿게 하려 들고요. “날 믿어, 친구” 말고 우리가 당신 말을 믿을 만한 이유를 대지 않는 한, 당신이 그리는 중간 사용자상도 다른 어떤 주장만큼이나 의심스러워요.