요약
젯브레인즈 체코 법인은 2025년 매출이 6.3% 늘었지만 3억 1,500만 코루나 순손실을 냈습니다.
기업 재무 자료 사이트 헬기 라이브러리가 체코 상업등기소에 제출된 젯브레인즈 s.r.o.의 재무제표를 정리했습니다. 체코 회계기준에 따른 이 법인 단독 수치이며, 전년 24억 7,900만 코루나 흑자에서 적자로 돌아섰습니다.
왜 중요한가
- 매출은 꾸준히 늘었으므로 적자의 원인은 판매 부진이 아니라 비용과 투자 증가에 있습니다.
- 투자 지출과 차입이 한 해 사이에 크게 불어나 회사가 어딘가에 대규모로 돈을 걸기 시작했다는 신호로 읽힙니다.
핵심 내용
- 매출은 160억 800만 코루나로 늘었지만 EBITDA(상각 전 영업이익)는 22억에서 9억 1,800만 코루나로 줄었습니다.
- 인건비 증가율은 전년 17.8%에서 34.2%로 뛰었고, 매출총이익은 39.7% 줄었습니다.
- 투자 활동 현금 유출은 19억 4,600만 코루나에서 102억 7,300만 코루나로 다섯 배 넘게 늘었습니다.
- 현금성 자산은 69억 7,800만 코루나에서 14억 4,400만 코루나로 줄고, 차입금은 19억 2,400만 코루나로 늘었습니다.
- 배당은 16억 6,500만 코루나로 전년의 네 배를 넘었고, 자기자본이익률(ROE)은 -11.1%입니다.
HN 반응
- 매출 추세가 그대로라 위기론은 과하다는 의견과, 인건비·투자 급증은 뒤늦게 LLM에 돈을 쏟는 것이라는 냉소가 엇갈렸습니다.
- 토론은 코딩에 거대 모델이 꼭 필요한지로 번져, 작은 로컬 모델로 충분하다는 경험담과 폭넓은 언어 지식이 필요하다는 반론이 맞섰습니다.
죽음을 알리는 조종(弔鐘)이라는 댓글이 줄줄이 달렸는데, 매출 줄은 아무도 안 보는 건가요? 매출은 예전 추세 그대로예요. 비용이 폭증한 것도 아닌 듯하고요. 뭔가 큰 걸 향해 투자한 거겠죠. 그건 아마 좋은 일이고, 진화하려면 흔히 필요한 일이기도 하죠.
네, 아래 세부 내역을 보세요. 매출은 6% 늘었습니다(대단하진 않아도 어쨌든 성장입니다). 하지만 인건비는 34.2% 늘었습니다. 그리고 진짜 큰 단서는 "투자활동 현금흐름"이 -8,300만 달러에서 -4억 6,900만 달러로 곤두박질쳤다는 점입니다. 엄청난 규모입니다. 사람을 늘리고 무언가에 투자하고 있다는 뜻입니다.
제 눈엔 실존적 위험 없이 태워도 되겠다 싶은 돈을 어디 "그저 그런" LLM 싱크홀에 아무 목적 없이 태우고 있는 걸로 읽히는데요.
한마디로 다른 데랑 다를 게 없으니 볼 거 없다는 얘기죠.
저는 아직도 코드 생성과 편집에 LLM이 꼭 필요하진 않다는 순진한 생각을 하고 있습니다. JavaScript를 출력하려고 셰익스피어 전집의 지식까지 갖춰야 할 이유가 있을까요?
저보다 똑똑한 분들은 더 잘 아시겠지만, IDE나 에디터에 (완전한 LLM일 필요는 없는) 내장 엔진을 넣어서 외부 도구 호출이나 토큰 비용 없이 쓰는 절충안이 있을 수 있지 않을까요?
조직이 개발자 한 명당 토큰 값으로 연간 2,400달러를 내고 있는데, 연간 1,000달러를 받는 아주 똑똑한 에디터/IDE가 나와서 고정 비용으로 더 많은 결과물을 뽑아 준다면 고민할 것도 없는 선택입니다.
알고 보니 실제로 그럴 필요가 없습니다. 연구자들이 MoE 모델에서 코딩 작업 중 활성화될 확률이 낮은 전문가(Expert)의 절반을 가지치기하는 데 성공했고, 그 결과 더 집중된 모델이 나왔습니다.
https://arxiv.org/abs/2607.16721
가장 큰 이점은 이런 모델을 돌리는 데 필요한 RAM이 크게 줄어든다는 점입니다. 물론 안 쓰는 전문가를 디스크에 캐시해 둘 수도 있겠지만, 핵심은 어떤 전문가가 중요한지 알게 됐다는 것입니다.
그 밖에도 Qwen3.8-27b 같은 최근 모델은 3비트나 심지어 삼진(ternary) 같은 강한 양자화에도 더 잘 버틴다고 합니다. TurboQuant 같은 추가 기법을 쓰면 임대 인프라보다 속도가 4분의 1 수준이라 해도 일반 소비자용 하드웨어에서 충분히 돌릴 수 있습니다.
VS Code에는 Kilo Code나 llama-vscode 같은 확장이 있어서, 클라우드 기반 솔루션처럼 로컬 모델로 작업할 수 있습니다.
생각해 보니, 얼마 전에 제 코딩 수요의 90%를 채워 주는 "작은" 오픈 웨이트 LLM이 나왔으니 저도 동의하는 쪽으로 기웁니다.
Qwen3.8-Flash-Next는 비교적 작아서, 제 집 PC의 6년 된 GPU 6장에서 262k 세션 5개를 동시에 거뜬히 돌리고 RAM에 캐시된 세션도 10개 더 있습니다(집을 담보로 대출받지 않아도 RAM을 사던 시절에 사 둔 겁니다). 장난감이 아닌 로컬 모델은 이게 처음입니다.
그래도 여전히 앤트로픽의 fable을 찾게 되는 부류의 문제가 있긴 합니다...
다만 앤트로픽이 그렇게 좋은 결과를 내는 건 하네스(harness) 꼼수를 잔뜩 쓰기 때문이라는, 확신에 가까운 직감이 있습니다.
예를 들어 opus 4.8은 코딩만 보면 앞서 말한 Qwen 모델보다 크게 낫지 않지만, 사실 지식 쪽(셰익스피어 전집을 안다는 그 부분)에서는 놀라운 결과를 냅니다. 관련 질문이 들어간 요청에 일반 지식 RAG를 붙여서 벤치마크를 전부 이기는 게 얼마나 어렵겠습니까? 별로 어렵지 않습니다.
그래서 하네스, 라우터, 추론 같은 쪽에 큰 혁신의 여지가 있다고 봅니다.
개발자 한 명당 AI에 쓰는 돈으로 말하자면, 제 현재 고객사(포춘 200대 소프트웨어 기업)는 월 500달러를 씁니다. 연 6천 달러죠. 댓글에서 든 예시보다 훨씬 많습니다. 그런데도 할당량을 금방 다 써 버리는 사람이 많습니다.
말씀을 들어볼 마음이 생기던 참이었는데… 컴퓨터에 그래픽카드를 6장 꽂는 얘기를 하면서 그게 사람들이 보통 하는 일인 것처럼 구시니까…
또 하나 함정은, 이 무지막지한 구성을 프런티어 모델과 비교하고 싶어진다는 겁니다. 실제로 비교할 대상은 같은 모델을 OpenRouter에서 돌리는 쪽인데 말이죠.
이 GPU 6장짜리 구성은 전기료만으로도 아마 OpenRouter 쓰는 비용을 넘길 겁니다.
그런데 그것들은 2020년 제품이잖아요. 몇 년 뒤엔 보통 사람들 노트북에도 그 정도 성능이 들어갈 거예요. 전력 아끼려고 클럭을 한참 낮추긴 하겠지만요.
그럼 맥 스튜디오랑 비슷한 수준 아닌가요?
GPU 세대 교체 주기가 한동안 상당히 느려졌다는 점을 염두에 두세요. "2020년 GPU"라면 VRAM 24GB짜리 NVIDIA RTX 3090일 수 있는데, 2026년에 로컬 LLM용으로 살 수 있는 최고의 카드 중 하나입니다. 사실 지금은 중고로 사는 게 아마 최선일 겁니다. 신형 RTX는 말도 안 되게 비싸니까요.
저는 두 장 갖고 있어요. 이 난리가 시작되기 전에 한 장에 1,000달러도 안 주고 샀죠. 돌아가긴 하지만, VRAM 48GB로는 클라우드 모델처럼 로컬 LLM을 쓰기엔 역시 부족해요.
저희 회사도 같은 모델을 씁니다. 개발자들뿐 아니라 여러 업무 수요도 이걸로 돌리고 있어요. GPU(B300) 한 장을 빌려 쓰는데, API 비용의 10분의 1쯤 듭니다.
AWS에서 빌리시나요, 아니면 다른 업체인가요? 그런 고사양 GPU 인스턴스를 온디맨드로 빌릴 때 문제는 없는지 궁금합니다. 용량이 늘 있나요, 아니면 가끔 없을 때도 있나요?
AWS는 안 건드립니다. 유럽 업체에서 빌려요. 서버리스나 스팟 가격제는 수요를 맞추기가 까다로울 수 있습니다. 저희는 상시 가동 서버를 쓰니까 문제없습니다.
비용이든 가용성이든 궁금한 게 있으면, AWS엔 그 문제를 풀어 주는 복잡하기 짝이 없는 뭔가가 있어요. 예약 인스턴스를 한번 보세요.
r/localllama나 r/localllm에서라면 보통일지도요.
Fable이 필요한 부류의 문제가 뭔지 좀 더 말씀해 주실 수 있나요?
질문을 받은 분은 아니지만, 디버깅할 때 여러 번 그랬습니다. 문제를 Opus/Sol/뭐든 다른 모델로 시도해 봤다가 아무 소득이 없어서 Fable한테 던졌더니 한 방에 해결책이 나왔습니다.
힌트를 드리자면, 대규모 복잡한 소프트웨어 아키텍처 설계와 계획입니다.
> "JavaScript를 출력하려고 셰익스피어 전집의 지식까지 갖춰야 할 이유가 있을까요?"
구현 지침서에 "이 핸들러에서 재연결을 시도하는 건 wild goose chase(헛된 추적)가 될 것이다"라고 쓰여 있다면, 모델은 그 표현을 이해할 만큼은 셰익스피어를 알아야 하죠. 적어도 간접적으로라도요...
LLM에 대한 제 이해가 순진한 점은 양해해 주세요. 그런데 언어 전반에 대한 폭넓은 이해 없이, 코드베이스를 의미적으로 이해해서 무엇을 왜 어디에서 바꿔야 하는지 아는 게 어떻게 가능한가요?
여기서 "이해"라는 단어를 느슨하게 쓰고 있긴 한데, 달리 쓸 만한 단어가 생각나지 않았습니다.
무엇을 바꾸고 싶은지에 따라 다릅니다. LSP로도 많은 걸 할 수 있지만 아주 단순한 변경에 한정됩니다.
IntelliJ를 쓰던 시절에는 리팩터링, 코드 일부를 함수로 추출하기, 이름 바꾸기, 빈 클래스/보일러플레이트 생성 같은 훌륭한 기능이 많았지만 딱 거기까지였습니다.
지금 직장에서는 LLM에게 다른 엔드포인트의 데이터 싱크를 가져와서 주어진 URL로 새 싱크를 작성하라고 시킬 수 있습니다. 엔드포인트에서 데이터를 가져와 어떤 내용이 오는지 확인하고, 다른 것과 비교한 다음 새 싱크를 씁니다. 그다음에 다듬는 작업이 필요한데, 데이터를 사방에서 복제하는 식으로 최대한 끔찍하게 만들어 놓기 때문입니다. 그래도 가장 지루하고 영혼을 갉아먹는 부분은 끝나 있습니다.
그래서 제가 https://github.com/spockz/semantic-editor 를 만들고 있습니다. 에이전트에 더 강력한 편집 기능을 주려는 겁니다. 에이전트의 사고 과정(chain of thought)에 붙고, json으로 된 확률적 프레이밍을 처리해서 전부 더 싸고 빠르게 돌아가도록요.
저희 회사 LLM은 Slack 대화 기록, 위키, git 전체 이력, 모든 대면 팀 회의의 (AI가 만든) 노트, JIRA, 모든 코드 리뷰, 모든 프로덕션 로그에 접근할 수 있고, 직접 돌릴 때는 개인 이메일까지 볼 수 있습니다.
어떤 일의 내력을 설명하는 건 보통 어떤 사람보다 빠릅니다.
아주 합당한 질문입니다. 저는 개인적으로 중간 지점이 있지 않을까 생각합니다. 일반 영어가 아니면서 "멍청한" LLM이 파싱할 수 있는 일종의 구조화된 언어 같은 거요. 사람이 쓸 수도 있고, 비용을 더 들여서 "똑똑한" LLM이 쓸 수도 있겠죠.
그 방향으로 갈수록 결국 연산량만 더 많이 먹는 방식으로 프레임워크를 다시 발명하는 셈이 됩니다.
다만 (사일로 바깥에는) 수많은 특정 작업을 위한 프레임워크가 없는 게 현실이고, AI는 그런 패턴을 끌어내기 위한 우회로인 거죠.
Jev가 보여 준 것과 이 분야에서 진행되는 일들을 보면, 앞으로 몇 년간 특정 작업과 워크플로에서 성능을 크게 개선할 여지가 많을 거라는 말씀이 맞다고 생각합니다.
모델이 갑자기 CPU에서 돌아가게 된다면 큰 지각변동이 될 수도 있겠다는 상상도 합니다. Astra급 코딩 에이전트를 노트북에서 로컬로 돌린다고 생각해 보세요. GPU가 그렇게 많이 필요하지 않다면 갑자기 별로 값어치 있어 보이지 않을 겁니다.
아직은 거기까지 시간이 좀 걸리겠지만, 진전은 이뤄지고 있는 것 같습니다.
우리는 언어 모델을 챗봇처럼 대하도록 길들여져 있고, 그런 면에서는 강한 언어 이해력(암묵적으로는 일종의 세계 지식)이 아마 필요할 겁니다.
하지만 프로그래밍 개념과 JavaScript 문법에만 아주 강한, 딱 그 정도의 작은 모델은 분명 만들 수 있을 겁니다. 사용 방식도 다르겠죠. 코드베이스의 특정 접점에서, 예를 들어 PR을 리뷰하거나, 함수 두 개를 합치거나, 이 로그들을 조사하는 식으로요.
아니면 제가 쓴 맛 교훈(bitter lesson)을 제대로 소화하지 못한 걸지도 모르죠. 잘 모르겠네요.
코드를 제대로 다루는 데 필요한 지식의 양은 생각보다 많다고 봅니다. 결국 코드가 존재하는 환경, 코드가 쓰이는 환경을 이해하지 못한 채 코드를 쓰면 문제에 제대로 맞지 않을 가능성이 높기 때문입니다. 셰익스피어 자체는 몰라도 되겠지만, 가상 테이블탑을 만든다면 테이블탑 게임에 대한 지식이 있어야 어떤 구현을 쓸지, 어떤 제약을 고려할지 등을 파악하는 데 도움이 됩니다.
저희 회사는 직원 한 명당 토큰에 연간 5만 달러를 쓰고 있고, 그런 곳이 저희만은 아닙니다.