- TypeSafe의 Jev는 텍스트 생성을 아예 포기하고 타입 값만 반환합니다. 최소 70ms, 최대 500ms. 분류 작업 기준 최대 200배 빠르다고 주장합니다.
- Stagehand v4는 SDK를 브라우저 확장 안으로 옮겨 Playwright 대비 2배 빠르고 토큰은 약 80% 덜 씁니다.
- 월 6달러 VPS 한 대로 MMORPG 동접 1,000명에 도전한 개발자는 300명에서 막혔습니다. 원인은 CPU가 아니라 TCP 버퍼였습니다.
70ms, 2배, 300명. 오늘 GeekNews 상위권을 차지한 세 건의 공통점은 전부 ‘숫자로 증명된 제약’이라는 점입니다. 하나는 모델이 텍스트를 버리자 지연이 몇 초에서 밀리초로 떨어졌고, 하나는 자동화 도구를 브라우저 안으로 옮기자 왕복 비용이 절반이 됐으며, 나머지 하나는 1 vCPU·1GB 서버에서 목표치의 30%밖에 못 버텼습니다. 세 사례 모두 “모델을 더 키우자”가 아니라 “구조를 바꾸자”는 쪽에 답이 있었습니다.
텍스트를 버린 모델, Jev
70ms가 바꾸는 것은 속도가 아니라 용도
TypeSafe AI는 2026년 9월 15일 스텔스에서 나오며 시드 4,000만 달러와 함께 첫 모델 Jev를 공개했습니다. ChatGPT 공동 개발자로 알려진 OpenAI 출신 Diogo Almeida가 2년간 준비한 모델로, 회사는 이를 ‘시스템 원(System One) 모델’이라 부릅니다. 카너먼의 빠른 사고·느린 사고에서 따온 이름입니다.
일반 LLM은 토큰을 하나씩 자기회귀적으로 뽑습니다. 구조화 출력을 요청해도 결국 {, "answer", : 같은 토큰을 순차적으로 생성해야 합니다. Jev는 이 과정을 없앴습니다. 입력으로 상태와 선택지를 받고, 단일 포워드 패스에서 타입이 보장된 값만 병렬로 돌려줍니다. 결과적으로 최속 응답은 약 70밀리초, 최악의 경우에도 500밀리초를 넘지 않습니다. 회사는 분류 과제 기준 최대 200배 빠르고 비용은 400배 낮다고 밝혔으며, 입력 토큰 100만 개당 4.2센트, 출력 토큰은 무료로 가격을 책정했습니다.
개발자 Sean Goedecke가 가장 인상적으로 꼽은 데모는 벤치마크가 아니라 둠(DOOM)이었습니다. 게임 상태를 텍스트로 넣고 “지금 발사 버튼을 눌러야 하는가”, “현재 목표가 X일 때 어떤 키를 눌러야 하는가” 같은 선택지를 던지면, 모델이 실시간으로 플레이할 만큼 지연이 낮습니다. 신경망으로 둠을 푸는 건 새롭지 않지만, 범용 모델이 100ms 안에 판단을 내준다는 점이 다릅니다.
Tech Insight — 지금까지 우리가 LLM 위에 올린 제품은 대부분 ‘화려한 챗봇’이었습니다. 자기회귀 생성이라는 원시 연산이 그 형태를 강제했기 때문입니다. 100ms짜리 값싼 판단을 코드 곳곳의 분기점에 꽂을 수 있다면, 라우팅·스코어링·필터링처럼 그동안 규칙 기반으로 하드코딩하던 영역이 통째로 후보가 됩니다. 신제품 기획 단계라면 “어디에 챗봇을 붙일까”가 아니라 “어느 if 문을 모델로 대체할까”로 질문을 바꿔볼 시점입니다.
그런데 이게 진짜 해자일까
Goedecke의 결론은 호의적이되 회의적입니다. 그는 빠른 구조화 출력이 이미 가능하다고 지적합니다. 응답을 "choice": "까지 미리 채워 넣고(prefill) 사용자가 준 선택지로 제한한 토큰 하나만 생성하면, 자기회귀 생성을 거의 건너뛸 수 있다는 것입니다. 입력 토큰은 어차피 병렬로 소화되므로 JSON 블록 전체를 뽑는 것보다 훨씬 빠릅니다. 실제로 그는 Qwen2.5-1.5B-Instruct로 직접 시도해 2~3배 속도 향상을 확인했다고 밝혔습니다. Jev 발표 당일 같은 실험을 시도한 개발자들도 있었습니다.
‘환각이 없다’는 주장에 대해서도 그는 말장난에 가깝다고 봅니다. Jev도 하늘을 빨간색이라고 고를 수 있습니다. 다만 없던 것을 지어내는 대신 주어진 선택지 중 틀린 것을 고르는 것이므로 기술적으로는 ‘실수’라는 겁니다. 이는 구조화 출력을 쓰는 일반 LLM도 마찬가지이며, 실무 신뢰도를 높여주지는 않습니다. 테스트 타임 컴퓨트를 쓸 수 없다는 점에서 지능 상한은 비추론 모델 수준에 머물 가능성이 큽니다.
Stagehand v4, 브라우저 안으로 들어가다
2배 빠르고 토큰은 80% 덜 쓴다
Browserbase가 2026년 8월 10일 공개한 Stagehand v4의 메시지는 한 문장으로 요약됩니다. “Playwright는 테스트를 위해 만들어졌고, Stagehand는 에이전트를 위해 만들었다.” 실제로 v4는 SDK 핵심을 브라우저 확장 프로그램 형태로 옮겼습니다. 로컬에서 쓰던 경험을 원격 브라우저에 그대로 가져오면서, 브라우저 내부에서 동작하는 만큼 왕복 시간(round trip time)이 줄고 CDP 경합 조건이 줄어듭니다.
회사가 공개한 벤치마크 수치는 Playwright 대비 2배 빠른 실행 속도와 약 80% 높은 토큰 효율입니다. 토큰 절감의 핵심은 하이브리드 접근성 트리 트리밍입니다. 페이지 전체 DOM을 통째로 넘기는 대신, 에이전트가 판단에 필요한 만큼의 컨텍스트만 잘라서 전달합니다. 여기에 셀렉터가 깨졌을 때 스스로 복구하는 self-healing 액션과 iframe 지원이 더해졌습니다. Playwright와 비슷한 코드 위에 자연어 명령을 섞어 쓸 수 있는 구조는 그대로 유지됩니다.
Tech Insight — 브라우저 에이전트 비용의 대부분은 모델 호출이 아니라 ‘페이지를 얼마나 설명하느냐’에서 나옵니다. DOM 전체를 매 스텝 넘기면 한 작업에 수십만 토큰이 우습게 나갑니다. 토큰 80% 절감은 성능 튜닝이 아니라 단가 구조를 바꾸는 숫자입니다. 사내 RPA나 데이터 수집 파이프라인을 운영 중이라면, 최적화 항목 목록에서 ‘모델 교체’보다 ‘컨텍스트 전달 방식’을 먼저 확인하는 편이 회수가 빠릅니다.
테스트 도구를 에이전트에 쓰면 생기는 일
Playwright는 결정론적 시나리오를 빠르게 검증하도록 설계된 도구입니다. 셀렉터가 고정되어 있고, 실패하면 테스트가 빨간불로 끝나는 것이 정상 동작입니다. 반면 에이전트는 처음 보는 페이지에서 목표만 알고 경로를 찾아야 합니다. 셀렉터가 바뀌면 멈추는 대신 다른 길을 찾아야 하고, 페이지 구조를 모델에게 설명해야 하며, iframe 안으로 들어가야 할 수도 있습니다. v4가 손본 항목들이 정확히 이 목록과 겹칩니다. 브라우저 자동화를 에이전트 용도로 쓰고 있다면, 지금 쓰는 도구가 테스트용으로 설계된 것인지부터 점검할 필요가 있습니다.
6달러 서버로 MMORPG, 어디서 멈췄나
1,000명 목표, 300명에서 무너졌다
1인 개발자 sigmarion1이 만든 브라우저 MMORPG ‘MODAK Online’이 GeekNews 상위권에 올랐습니다. 최근 CrazyGames 공개 테스트에서 약 3,000명이 4,000판 넘게 플레이했고, 현재는 공식 사이트에서 직접 플레이할 수 있습니다. 클라이언트는 Next.js와 Phaser, 서버는 Go와 WebSocket으로 만들었습니다.
흥미로운 건 게임 자체보다 그 앞에 있던 부하 테스트 기록입니다. 개발자가 세운 전제는 명확했습니다. 사이드 프로젝트의 수명은 인프라 비용이 결정한다는 것. 그래서 프로덕션을 1 vCPU·1GB RAM짜리 월 6달러 VPS 한 대로 고정하고, 여기서 동시접속 1,000명을 버티는 것을 목표로 잡았습니다.
구조는 최대한 단순하게 갔습니다. 초기 Node.js 프로토타입을 Go로 이전해 동일 조건(10개 존, 20Hz 틱)에서 RSS를 약 51.6MB에서 약 26.0MB로 줄였고, 월드를 존당 100명 상한으로 쪼갰으며, 프레임 델타 계산이 오히려 CPU를 더 먹는다는 것을 확인하고 최신 스냅샷만 브로드캐스트하는 방식으로 바꿨습니다. 상태는 메모리에 두고 DB는 로컬 SQLite(WAL)로 비동기 배치 기록해 관리형 DB 비용을 아예 없앴습니다.
그리고 봇 1,000개를 10개 존에 100개씩 붙였습니다. 결과는 실패였습니다. 동시 접속이 약 300개를 넘자 리눅스 커널이 TCP: out of memory를 띄우며 서버가 응답을 놓쳤습니다. 접속 속도를 초당 50개에서 10개로 낮춰도 발생 시점만 늦춰질 뿐 300명 선에서 똑같이 터졌습니다. 병목은 접속 속도가 아니라 소켓 버퍼 용량이었습니다. tcp_mem을 올려 초기 OOM을 피하자, 이번엔 전체 연결의 Send-Q 합계가 약 75MiB까지 치솟아 시스템 RAM을 소진했습니다.
Tech Insight — 실시간 서버를 처음 만들 때 대부분 CPU와 메모리만 봅니다. 그런데 이 테스트에서 먼저 무너진 건 커널의 TCP 메모리와 송신 큐였습니다. 100명짜리 존 스냅샷이 15~20KB이고 이를 1,000명에게 10Hz로 뿌리면 초당 150~200MB의 아웃바운드가 필요합니다. 애플리케이션 프로파일러에는 잡힐지 않는 숫자입니다. 부하 테스트 계획을 세운다면 ss -tmi로 Send-Q를 함께 보는 항목을 지금 추가해 두시기 바랍니다.
진짜 벽은 대역폭이었다
개발자는 패킷을 뜯어보고 스냅샷 상당 부분이 스프라이트 정의나 표시용 메타데이터처럼 매 틱 보낼 필요가 없는 정적 데이터였다는 것을 발견했습니다. 존 입장 시 한 번만 보내고, 이후 스냅샷은 좌표·HP·액션 상태 같은 실시간 필드만 담도록 바꾸는 것이 다음 과제입니다.
다만 TCP 문제를 다 풀어도 남는 벽이 있습니다. 6달러 요금제의 월 3TB 아웃바운드 한도입니다. 정적 데이터를 분리하고 틱을 5Hz로 낮춘 압축 패킷을 가정해도, 3TB 예산 안에서 유지 가능한 평균 동시접속은 약 127명으로 계산됩니다. 평균 100명이면 약 40일, 200명이면 약 16.7일, 1,000명이면 약 33.6시간 만에 한 달 치가 소진됩니다. 현재 15~20KB 패킷을 5Hz로 보내면 3TB는 8~11시간이면 바닥납니다. 결국 이 기록의 결론은 “튜닝으로 어디까지 갈 수 있는가”가 아니라 “요금제를 올려야 하는 지점이 어디인가”를 숫자로 확정한 것입니다.
관련 글
출처
- Sean Goedecke, “Jev means structured output is interesting again” (2026.09.16)
- TypeSafe, “Introducing System One models and Jev” (2026.09.15)
- Browserbase Changelog, “Introducing Stagehand v4: the SDK for browser agents” (2026.08.10)
- sigmarion1, “I Tried Running 1,000 MMORPG Bots on a $6 VPS” (2026.08.24)
- GeekNews 인기 토픽 TOP3 (2026.09.22 기준)
AI Biz Insider · Tech Digest · aibizinsider.com
답글 남기기