리플렉션 Beam 공개, 점수는 밀리고 효율로 승부

effidev·2026년 10월 6일

코딩 에이전트에 붙일 오픈 모델을 고르는 중이라면, 새 모델이 나왔을 때 제일 먼저 할 일은 발표문의 성적표를 직접 세어 보는 것이다. 미국 스타트업 리플렉션(Reflection AI)이 2026년 10월 5일 첫 오픈웨이트 모델 Beam을 공개했다. 그런데 리플렉션이 직접 올린 비교표에서 GLM-5.3, Kimi K3, Qwen3.8-Max 세 모델과 점수가 나란히 적힌 칸은 39개고, 그중 Beam이 앞선 칸은 1개다.

그렇다고 쓸모없는 모델이라는 뜻은 아니다. Beam이 내세우는 건 점수가 아니라 효율이다. 총 5,010억 개의 파라미터 중 토큰 하나를 만들 때 실제로 일하는 건 230억 개뿐이고, 리플렉션은 GLM-5.2와 비슷한 추론 점수를 추론 연산 3~4분의 1로 낸다고 말한다. 이 글은 그 말이 어디까지 근거가 있는지, 표에서 무엇이 보이는지를 정리한다.

이 글은 세 부류를 위해 쓴다. 로컬이나 자체 서버에서 오픈 모델을 돌릴 계획이 있는 개발자, 오픈 모델 비용이 API보다 나은지 따져 보는 사람, 그리고 “오픈웨이트 모델”이라는 말을 처음 들어 보는 사람이다. 용어는 처음 나올 때 풀어 쓴다.

근거는 리플렉션 공식 블로그의 발표문 전문, 그 안에 실린 벤치마크 표, 이 사이트가 앞서 허깅페이스 메타데이터로 확인해 둔 GLM·Qwen 모델 크기, 그리고 Hacker News 반응이다. Beam 점수는 독립 검증을 거치지 않은 리플렉션 발표문의 값이고, 모델 가중치(학습된 숫자 파일)는 아직 공개되지 않아서 파일을 열어 확인한 내용은 없다. 그 점은 글 내내 짚는다.

리플렉션이 낸 첫 오픈웨이트 모델

오픈웨이트는 모델의 가중치 파일을 누구나 내려받아 자기 서버에서 돌릴 수 있게 푼다는 뜻이다. 소스 코드까지 다 여는 오픈소스와는 다르지만, 내 컴퓨터에서 돌려 보고 미세조정(내 업무에 맞게 추가 학습)까지 할 수 있다는 점이 핵심이다.

리플렉션은 2025년 10월에 20억 달러를 투자받으며 “미국의 오픈 프런티어 AI 연구소”를 표방한 회사다. 당시 TechCrunch는 기업가치를 80억 달러로 전했고, 공동 창업자 둘은 구글 딥마인드 출신이다. 당시 CEO는 TechCrunch에 이듬해 프런티어급 언어 모델을 내놓겠다고 말했고, 약 1년 만에 나온 이번 발표문은 Beam을 회사의 첫 오픈웨이트 모델이라고 소개한다.

발표문이 밝힌 Beam의 기본 사양은 이렇다.

발표 시점에는 선별된 사용자에게 먼저 열었고, 대기 명단(waitlist)에 등록하면 초기 접근 권한을 받을 수 있다. 가중치, 기술 보고서, 모델 카드, 개발자용 자료는 “이달 안에” 공개하겠다고 했다. 라이선스는 발표문 끝부분에 Apache 2.0이라고 적혀 있다.

5,010억 개 중 230억 개만 일한다는 말의 뜻

MoE(전문가 혼합)는 모델 안에 전문가 역할을 하는 작은 덩어리를 아주 많이 두고, 토큰 하나를 처리할 때마다 그중 일부만 불러 쓰는 구조다. 회사에 전문가 수백 명이 있어도 한 안건에는 몇 명만 회의에 들어오는 것과 같다. 모델 전체 크기(총 파라미터)와 한 토큰당 계산에 참여하는 크기(활성 파라미터)가 따로 있는 이유다.

두 숫자가 각각 다른 비용을 정한다.

• 총 파라미터 5,010억은 메모리를 정한다. 전문가를 다 올려 놓아야 어느 전문가가 불려도 대답할 수 있기 때문이다.
• 활성 파라미터 230억은 속도와 연산량을 정한다. 토큰마다 계산에 참여하는 건 230억 개뿐이다.

메모리 쪽을 단순 계산으로 환산해 보면 이렇다. 아래는 이 사이트의 계산이고 리플렉션이 낸 숫자가 아니다. 가중치 파일의 크기만 센 값이라, 실제로 돌리려면 맥락 저장 공간 같은 여유 메모리가 더 든다.

그러니 4비트로 줄여도 일반 PC 한 대의 메모리로는 안 되고, 서버급 장비가 필요하다. 이 점에서는 앞서 다룬 Qwen3.8 2.4T 오픈웨이트와 같은 계열의 이야기다. 그 글에서 확인한 Qwen3.8-Max는 총 2.4조 파라미터, 활성 95B였다. 총 크기로는 Beam의 약 4.9배, 토큰당 활성 크기로는 약 4.1배다. 토큰 하나당 연산만 보면 Beam이 Qwen3.8-Max의 4분의 1 수준이라는 얘기다.

GLM-5.2는 GLM-5.3 공개 글에서 허깅페이스 메타데이터로 확인했듯 총 파라미터가 7,533억 개다. Beam의 총 크기는 그것의 약 3분의 2다. 다만 GLM-5.2의 활성 파라미터는 이 사이트가 확인한 값이 없어서 같은 방식의 비교는 하지 않는다.

자사 표에서 Beam이 이긴 칸과 진 칸을 세어 봤다

발표문의 벤치마크 표에는 Beam 외에 Inkling, Nemotron 3 Ultra, GLM 5.2, GLM 5.3, Kimi K3, Qwen 3.8 Max, DeepSeek V4.1 Flash의 점수가 같이 실려 있다. 모든 칸이 채워진 건 아니고, 점수를 보고하지 않은 칸은 NR(not reported)로 비어 있다. 같은 평가에서 Beam과 상대 모두 점수가 있는 칸만 골라 앞섰는지 졌는지 셌다. 이 집계는 이 사이트가 표를 읽고 직접 센 값이다.

두 줄로 읽힌다. Inkling·Nemotron 3 Ultra·GLM 5.2에는 대체로 앞선다. 반대로 GLM 5.3, Kimi K3, Qwen 3.8 Max에는 거의 전부 졌다. 세 모델을 합치면 12+14+13으로 39칸이고 Beam이 앞선 건 1칸이다. 그 1칸은 tau3 banking 평가에서 Kimi K3를 38.0 대 37.1로 근소하게 앞선 것이다. 글머리의 “39번 중 1번”이 이 값이다.

직접 비교하기 쉽게 몇 가지 평가만 뽑았다. 숫자는 발표문 표 그대로고, “-“는 NR이다.

각 평가가 무엇을 재는지 한 줄씩 풀면 이렇다. Terminal Bench는 터미널에서 명령을 직접 쳐서 작업을 끝내는 에이전트 평가다. SWE Bench Pro는 실제 소프트웨어 이슈를 고치는 코딩 평가다. HLE는 전문가 수준의 어려운 문제 모음이고, GPQA Diamond는 대학원 수준의 과학 문제다. MCP Atlas는 외부 도구를 불러 쓰는 능력을 본다.

여기서 눈여겨볼 곳이 둘이다. 하나는 GLM 5.2와의 격차다. Terminal Bench에서 80.1 대 81.0, GPQA에서 90.5 대 91.2로 1점 안팎이고, HLE에서만 36.2 대 40.5로 크게 벌어진다. 리플렉션이 “GLM 5.2와 경쟁 가능하다”고 쓴 문장은 이 표와 대체로 맞는다. 다른 하나는 비교 대상이 GLM 5.2에서 멈추지 않는다는 점이다. 표에는 더 최근 모델인 GLM 5.3, Kimi K3, DeepSeek V4.1 Flash도 같이 들어 있고, 거기서는 Beam이 확연히 밀린다. 발표문도 “Kimi K3 같은 프런티어 오픈 모델은 원초적 능력에서 여전히 앞선다”고 인정한다.

Hacker News(241점, 댓글 66개)에서도 같은 지적이 나왔다. 어떤 댓글은 “더 크면서 중국 오픈 모델보다 못하다”고 했고, 다른 댓글은 DeepSeek V4.1 Flash보다 크고 모든 지표에서 못하다고 썼다. 후자는 과장이다. 위 집계처럼 9칸 중 2칸(CriPT AA 16.3 대 14.3, AA Omniscience 13.0 대 6.6)은 Beam이 앞선다. 다만 7칸에서 진 것도 사실이다.

그래도 Beam이 내세우는 한 가지: 효율

점수로 이기지 못하니 리플렉션은 다른 축을 내민다. 발표문의 문장은 이렇다. 고급 추론 평가에서 GLM-5.2와 비슷한 점수를 내면서 추론 연산을 3~4배 적게 쓴다. 2조 파라미터급 모델인 Qwen 3.8-Max와 비교하면 효율 차이가 더 두드러진다.

이 숫자가 어떻게 나왔는지가 중요하다. 발표문은 연산량을 “2 × 활성 파라미터 수 × 시도당 평균 생성 토큰 수”로 어림했다고 밝힌다. 생각(추론) 토큰과 최종 답변 토큰을 모두 센다. 반대로 프롬프트 읽기(prefill), 맥락에 따라 커지는 어텐션 연산, 서빙 오버헤드는 뺐다. 리플렉션도 이걸 “측정한 추론 비용이 아니라 근사적 연산 비교”라고 적었다. 다른 모델의 토큰 수는 Artificial Analysis와 DataCurve 자료를 썼다.

독자 단위로 옮기면 이렇다. 같은 문제를 풀 때 모델이 쓰는 토큰 수와 토큰당 계산량을 곱한 값이 작다는 얘기고, 그러면 같은 GPU에서 더 많은 요청을 처리하거나 같은 요청을 더 싸게 처리할 여지가 생긴다. 하지만 이 값이 곧 청구서는 아니다. 서빙 효율, 메모리 비용, 호스팅 업체의 가격 정책이 따로 있다. 발표문에는 가격도, API 제공처도 나오지 않는다.

효율을 만든 방법으로 발표문이 내세우는 건 두 가지다. 하나는 학습할 때 불필요한 토큰을 쓰면 감점하는 “길이 페널티”를 걸어 모델이 짧게 풀도록 길들였다는 것이다. 초반에는 답 길이가 줄면서도 점수가 올랐고, 에이전트 능력이 커진 뒤에는 길이가 다시 늘었지만 그 토큰이 점수 향상으로 이어졌다고 설명한다. 다른 하나는 사용자가 추론 강도(reasoning effort) 값을 조절할 수 있게 한 것이다. 낮추면 짧게 답하고, 높이면 더 오래 생각해서 어려운 작업의 성능을 올린다.

앞서 클라우드플레어 Clef 글에서도 같은 질문이 나왔다. 속도와 가격이라는 한 축을 제조사가 직접 재서 내놓을 때, 점수가 밀리는 칸까지 같이 봐야 한다는 것이다. Beam도 같다. 효율 주장은 그럴듯하지만 독립 측정이 아직 없다.

학습 규모를 보여 주는 숫자들

발표문에서 분량이 가장 큰 부분은 어떻게 학습했는지다. 이 모델을 직접 돌릴 일은 없어도, 왜 5,010억짜리가 이 점수에서 멈췄는지 짐작하는 데 도움이 된다. 용어를 먼저 풀면, 강화학습(RL)은 모델이 문제를 풀어 보고 맞으면 보상을 받으며 배우는 방식이다. 롤아웃(rollout)은 모델이 문제 하나를 처음부터 끝까지 풀어 보는 한 번의 시도를 뜻한다.

몇 개는 규모를 가늠할 만한 숫자다. 발표문은 학습 중 평균 11만 개의 롤아웃이 동시에 돌았고, 샌드박스는 최대 17만 개가 동시에 떴다고 밝힌다. 새 샌드박스의 90%는 10초 안에 준비됐다. 새로 학습된 가중치가 추론 서버 전체에 퍼지는 데 중간값으로 약 12초가 걸렸다. 리플렉션은 이를 “오픈 연구소 중 가장 큰 규모의 강화학습 중 하나로 믿는다”고 적었다. 이건 회사의 자기 평가라 확인할 방법이 없다.

데이터 이야기도 있다. 인터넷에서 긁은 원본 토큰의 약 95%는 파싱·중복 제거·품질 선별에서 걸러진다. 대신 일반적인 필터를 썼다면 놓쳤을 약 1.8조 개의 양질 토큰을 자체 분류기로 건졌다고 하고, 그중에는 웹에서 모은 코드 토큰의 87%가 들어 있다고 한다. 사전 학습에서 쓴 23.8조 토큰은 웹, 공개 자료, 라이선스를 받은 독점 데이터를 섞은 것이다.

안전·정렬 쪽은 모델 하나를 따로 키워서 두 “선생님”(대규모 강화학습 선생과 안전 전담 선생)의 능력을 합치는 방식이다. 원칙은 세 층이다. 어기면 안 되는 규칙, 늘 지켜야 할 품질(맥락 활용, 정확한 주장, 불확실성 인정), 기본 말투(직접적이고 꼼꼼하고 선제적)다. 안전 평가 결과는 기술 보고서에 싣고, 내부에서 쓴 안전 평가 도구도 공개하겠다고 한다. 지금은 숫자가 없다.

데모에 나온 숫자 두 개는 이렇게 읽는다

발표문은 Beam이 만든 결과물 데모를 몇 개 보여 준다. 우주비행사 낙하 게임, 뉴욕 지하철 실시간 지도, 소형 모델 Gemma-4용 미세조정 노트북이다. 그중 숫자가 있는 두 가지를 짚는다.

지도 퍼즐 95.5%. 경도 -179°~179°, 위도 -89°~89°의 격자(180×90, 점 16,200개)를 만들게 하고 각 점이 육지인지 바다인지를 맞히게 한 퍼즐이다. Beam은 95.5%를 맞혔고, 발표문은 이를 Opus 5(92.5%)와 Fable 5(97.8%) 사이라고 소개한다. 새로운 과제에서도 일반화된다는 근거로 든 것인데, 이 퍼즐 하나를 한 번 돌린 결과라서 벤치마크와 같은 무게로 읽을 수는 없다. 한 HN 댓글은 이 데모의 설명 문구를 보고 의아했다고 적었다.

Gemma 미세조정 66.5%. Beam을 OpenCode(코딩 에이전트 도구)에 연결해 Unsloth 문서를 읽고 Gemma-4용 Text2SQL 미세조정 노트북을 만들게 했더니, 미세조정한 Gemma의 보류 시험 정확도가 66.5% 올랐다고 한다. 이 66.5%가 퍼센트 포인트인지 상대 증가율인지 발표문에 적혀 있지 않다. 원래 점수를 모르면 크기를 판단할 수 없는 숫자다.

두 데모 모두 모델이 도구를 써서 일을 끝까지 해냈다는 인상을 주기엔 좋다. 하지만 이 사이트에서 재현해 본 건 없고, 데모는 고른 예시라는 점을 감안해야 한다.

발표문에서 빠진 것: 가격, 접속 방법, 독립 측정

이 발표만으로는 알 수 없는 것들이 있다.

• 가격과 API. 가격표도, 어느 클라우드나 추론 업체에서 쓸 수 있는지도 없다. “배포 파트너 생태계와 함께 출시하겠다”는 계획만 있다.
• 가중치. 아직 없다. 허깅페이스에 올라오면 총 파라미터 수와 파일 크기를 직접 대조할 수 있다(GLM-5.3 글에서 한 방식 그대로).
• 독립 측정. Artificial Analysis 종합 지수나 Arena 같은 제3자 순위에 Beam이 들어 있지 않다. 표에서 AA Omniscience 항목에만 “(our results)”(자체 측정)라고 적혀 있고, 다른 모델 점수는 Artificial Analysis와 DataCurve에서 가져왔다고만 한다.
• 하드웨어 요구. 발표문은 서빙 효율을 자랑하지만, 어떤 장비에서 초당 몇 토큰이 나오는지는 없다. HN에서도 “어떤 하드웨어에서 돌릴 수 있고 성능 특성은 어떤지”를 묻는 댓글이 있었다.
• 텍스트 전용. Beam은 이미지를 입력으로 받지 않는다. 발표문도 “다른 형태의 정보는 텍스트로 표현하면 다룰 수 있다”는 정도로만 말한다.

가중치가 풀리면 열어 볼 것 네 가지

이달 안에 가중치가 풀린다고 했으니, 풀리는 날 곧바로 확인할 목록을 미리 적어 둔다.

1. 허깅페이스 리포의 총 파라미터 수. 메타데이터가 501B 근처로 잡히는지, 파일 크기가 위 단순 계산(4비트 약 250GB, 8비트 약 501GB, 16비트 약 1,002GB)과 맞는지 본다.
2. LICENSE 파일. 발표문은 Apache 2.0이라고 했다. 리포의 실제 라이선스 파일이 같은지 확인한다. GLM-5.3은 MIT에서 조항이 바뀐 전례가 있었다.
3. 모델 카드와 기술 보고서. 약속한 안전 평가 결과가 들어 있는지, 활성 파라미터가 23B로 표기되는지, 추론 강도 파라미터의 이름과 허용값이 무엇인지 본다.
4. 내 서빙 엔진에서의 지원. vLLM이나 llama.cpp 같은 엔진이 이 구조를 지원하는지, 지원한다면 어떤 양자화가 되는지 본다.

그 사이에 해 둘 만한 준비가 하나 있다. 지금 쓰는 모델로 가장 비싼 에이전트 작업 하나를 골라 토큰 사용량과 걸린 시간을 기록해 두는 것이다. Beam의 효율 주장을 검증하려면 내 업무에서 지금 쓰는 모델이 몇 토큰을 쓰는지 기준선이 있어야 한다. 가중치가 풀린 뒤 같은 작업을 낮은 추론 강도와 높은 추론 강도로 각각 돌려 비교하면, 3~4배라는 숫자가 내 일에서도 나오는지 알 수 있다.

정리: 누구에게 Beam이 맞나

Beam은 점수 경쟁에서 한 발 늦게 나온 모델이고, 리플렉션도 그걸 숨기지 않았다. 숨기지 않았다는 점이 이 발표문의 신뢰할 만한 부분이다. 대신 효율이라는 새 축은 독립 측정이 붙기 전까지 회사의 주장으로 남는다. 이달 중 가중치가 풀리면, 이 글의 숫자를 기준으로 다시 확인해 보자.