오르니스 1.5, 11배 작은 모델이 코딩을 다 이겼다

effidev·2026년 8월 20일

11배 큰 모델을, 코딩 9개 전부에서

오르니스 1.5의 가운데 모델은 파라미터가 360억 개다. 비교 대상으로 같은 표에 올라온 큐원 3.5는 3,970억 개다. 11배 차이가 난다.

그런데 코딩 벤치마크 9개에서 작은 쪽이 9개 다 이겼다.

터미널 벤치 67.8 대 53.5. SWE-bench 버파이드 79 대 76.4. 코드 저장소를 통째로 만들게 하는 NL2Repo는 46.2 대 36.8이다.

만든 팀이 직접 공개한 표에 그렇게 적혀 있다.

이 글은 이런 사람에게 필요하다

AI에 코드를 시켜 보고 싶은데 매달 나가는 돈이 부담스러운 사람. 오르니스 1.5는 MIT 라이선스로 풀렸다. 받아서 내 컴퓨터나 내 서버에서 돌리면 사용료가 없다.

“오픈 모델은 아직 멀었다”고 정리해 둔 사람. 그 판단의 근거가 이번 표에서 한 칸 흔들렸다. 다만 전부 흔들린 건 아니고, 흔들린 자리와 안 흔들린 자리가 꽤 뚜렷하게 갈린다.

벤치마크 표를 어디까지 믿어야 할지 모르겠는 사람. 이 글 뒤쪽에서 이 표의 한계를 따로 다룬다.

반대로 이 글이 필요 없는 사람도 있다. 그냥 코드 짜는 AI를 쓰고 싶을 뿐이라면 지금 쓰는 유료 서비스를 계속 쓰는 게 낫다. 오르니스는 아직 공식 API가 없고, 직접 돌리려면 그래픽카드가 있어야 한다.

무엇이 공개됐나

2026년 8월 18일, 오르니스 팀이 허깅페이스에 모델 파일을 올렸다. 허깅페이스는 AI 모델을 올리고 받는 공용 창고 같은 곳이다.

올라온 시각은 협정세계시 기준 06시 20분부터다. 한국 시간으로는 8월 18일 오후 3시 20분쯤이다.

크기가 다른 세 종류가 한꺼번에 나왔다.

세 모델 모두 MIT 라이선스다. 오픈소스 라이선스 중에서도 조건이 가장 헐거운 축에 든다. 고쳐서 배포해도 되고, 그걸로 돈을 벌어도 되고, 고친 내용을 공개할 의무도 없다.

같은 날 양자화 버전도 같이 올라왔다. 양자화는 모델의 숫자들을 더 거친 단위로 반올림해 용량을 줄이는 작업이다. 정확도를 조금 내주고 크기를 크게 줄인다.

GGUF, FP8, NVFP4, 그리고 애플 실리콘용 MLX 4·6·8비트까지 총 18개 저장소가 8월 18~19일 사이에 올라왔다. 맥에서 돌릴 준비가 첫날부터 돼 있었다는 뜻이다.

“36B인데 3B”가 무슨 말인가

표에서 제일 헷갈리는 게 35B-A3B라는 이름이다. 풀면 이렇다.

35B는 모델 전체 크기다. 실제 카드에는 360억 개(36B)라고 적혀 있다.

A3B는 Active 3B, 그러니까 글자 하나를 만들 때 실제로 계산에 참여하는 파라미터가 30억 개라는 뜻이다.

이런 구조를 MoE라고 부른다. 전문가 혼합(Mixture of Experts)의 약자다.

쉽게 말하면 이렇다. 병원에 의사가 100명 있어도 감기 환자 한 명을 볼 때 100명이 다 들어오지는 않는다. 내과 의사 몇 명만 들어온다. 나머지 95명은 자리에 있지만 이번 진료에는 관여하지 않는다.

MoE 모델이 딱 그렇게 동작한다. 모델 안에 작은 전문가 신경망을 여러 개 두고, 입력마다 그중 몇 개만 깨운다.

그래서 메모리에는 360억 개를 다 올려야 하지만, 계산 속도는 30억 개짜리에 가깝다. 무겁게 저장하고 가볍게 돌린다는 뜻이다.

로컬에서 모델을 돌려 본 사람이라면 큐원 3.8 2.4T 오픈웨이트가 450GB의 벽에 막혔던 이야기에서 같은 구조를 본 적이 있을 것이다. 크기와 속도가 따로 논다는 게 MoE의 핵심이다.

코딩 9개 전승 — 표를 그대로 보자

발표문에 실린 35B 비교표에서 코딩 항목만 뽑았다. 오른쪽 열은 파라미터가 11배 많은 큐원 3.5-397B다.

9개 항목, 9개 다 굵은 글씨다.

낯선 이름이 많으니 대표적인 것만 풀어 둔다.

SWE-bench 버파이드는 깃허브에 실제로 올라왔던 버그 리포트를 주고 코드를 고쳐 보라고 시키는 시험이다. 사람이 검수해서 “이건 확실히 풀 수 있는 문제”만 골라 놓은 판이라 이름에 ’버파이드(검증된)’가 붙었다. 79점이면 100문제 중 79개를 고쳤다는 뜻이다.

터미널 벤치는 검은 화면에 명령어를 치는 그 터미널에서 일을 시키는 시험이다. 파일 찾고, 설치하고, 오류 보고 다시 시도하는 과정을 혼자 해내야 한다.

NL2Repo는 “이런 프로그램을 만들어 줘”라는 문장 하나에서 저장소 하나를 통째로 만들어 내게 하는 시험이다. 난이도가 높아 점수 자체가 낮게 나온다.

가장 눈에 띄는 칸은 DeepSWE다

DeepSWE 줄을 다시 보자. 오르니스 1.5-35B가 22점, 큐원 3.5-397B가 1점이다.

그리고 발표문의 원래 표에는 열이 더 있다. 같은 줄에서 직전 버전인 오르니스 1.0-35B가 0점, 비슷한 크기의 큐원 3.6-35B도 0점이다.

세 모델이 0점, 0점, 1점인 시험에서 한 모델만 22점이 나왔다.

이 정도로 갈리면 보통은 그 시험이 요구하는 특정 형식에 맞춰 학습했을 가능성을 먼저 의심해야 한다. 이 부분은 뒤에서 다시 짚는다.

그런데 다 이긴 건 아니다

여기가 이 글에서 제일 중요한 대목이다. 같은 표의 나머지 절반은 그림이 반대다.

8개 중 5개를 큰 모델이 가져갔다.

특히 격차가 큰 자리를 보자. HLE 도구 사용은 33.4 대 48.3으로 15점 가까이 벌어진다. 브라우즈컴프도 11점 차다.

와이드서치와 브라우즈컴프는 둘 다 웹을 돌아다니며 정보를 모아 오는 시험이다. HLE는 사람이 쉽게 못 푸는 어려운 문제를 모아 놓은 시험이다.

그러니까 이 표가 말하는 건 **“작은 모델이 큰 모델을 이겼다”가 아니라 “작은 모델이 코딩만 골라서 크게 늘렸다”**에 가깝다.

여러 문서를 읽어 가며 판단을 조합해야 하는 일에서는 여전히 큰 모델이 앞선다. 오르니스 1.5-35B를 코드 도우미로 쓰는 건 말이 되지만, 리서치 도우미로 그대로 갈아타는 건 아직 이르다.

제일 큰 397B는 어디까지 왔나

397B 모델은 클로드 오퍼스 4.8과 같은 표에 놓였다. 발표문 수치를 그대로 옮긴다.

앞서는 칸도 있고 밀리는 칸도 있다. 승패로 세면 7 대 7이다.

앞서는 자리는 대체로 근소하다. SWE-bench 버파이드는 86 대 85.8, 0.2점 차다. 터미널 벤치도 1.1점 차다.

밀리는 자리는 격차가 크다. NL2Repo는 59.5 대 69.7로 10점, 프론티어 벤치는 13.5 대 21.1로 7.6점 벌어진다. 둘 다 어려운 쪽 시험이다.

정리하면 “붙었다”가 정직한 표현이고, “넘었다”는 과하다. 그리고 이건 오르니스 팀이 자기 모델을 소개하며 직접 만든 표다.

같은 표에 있는 키미 K3(2.8T)는 터미널 벤치 88.3으로 양쪽을 다 앞선다. 오르니스가 이 표에서 1등은 아니다.

397B를 돌리려면 필요한 것

모델 카드에 BF16 기준 약 800GB라고 적혀 있다. BF16은 숫자 하나를 16비트로 저장하는 방식이다.

80GB짜리 데이터센터 GPU로 환산하면 10장이 필요하다. 개인이 집에서 켤 수 있는 물건이 아니다.

“MIT 라이선스라 무료”라는 말과 “돌리는 데 돈이 안 든다”는 말은 다르다. 라이선스료가 없을 뿐, 하드웨어와 전기는 그대로 든다.

GPT-5.6 Sol의 반값 요금이 경로에 따라 2.2배로 갈렸던 사례와 같은 함정이다. 가격표에 적힌 숫자와 실제로 나가는 돈은 자주 다르다.

9B 모델의 현실적인 위치

세 번째 모델인 9B는 덴스 구조다. MoE와 달리 90억 개 파라미터가 매번 전부 계산에 참여한다.

모델 카드에는 BF16 기준 약 19GB, 80GB GPU 한 장에 올라간다고 적혀 있다.

같은 크기끼리 비교하면 결과가 확실하다.

터미널 벤치는 21.3에서 46.2로 두 배 넘게 올랐다.

다만 냉정하게 볼 대목이 있다. 한 단계 위인 큐원 3.6-35B-A3B와 붙이면 SWE-bench 버파이드가 70.6 대 73.4로 진다. MCP-아틀라스도 54.2 대 62.8로 밀린다.

9B는 “같은 체급에서 크게 앞선 모델”이지, “체급을 뛰어넘은 모델”은 아니다.

그래도 의미는 있다. 이 크기대에서 SWE-bench 버파이드 70점대가 나온다는 건, 노트북에서 돌릴 수 있는 코드 도우미의 기준선이 올라갔다는 뜻이다. 애플 실리콘용 MLX 4비트 버전이 첫날부터 올라온 것도 그 용도를 노린 배치로 보인다.

뮤즈 글리머 30B로 24GB 그래픽카드에서 로컬 에이전트를 돌리던 이야기와 같은 흐름 위에 있다.

자기가 문제를 내고 자기가 푼다

발표문 제목이 From Self-Scaffolding to Self-Improvement다. 우리말로 옮기면 “스스로 발판을 놓는 것에서 스스로 나아지는 것으로” 정도다.

이 부분이 오르니스 팀이 내세우는 핵심이다. 학습 과정이 세 단계로 돈다.

1단계, 과제 만들기. 모델이 자기가 이미 푼 문제보다 조금 더 어려운 문제를 스스로 만들어 낸다. 지금까지의 성적 기록을 보고 자기가 약한 자리를 찾는다.

2단계, 발판 만들기. 만든 과제마다 어떻게 접근할지 지침을 짜고, 어떤 도구를 쓸지 고르고, 문제를 어떻게 쪼갤지 정한다. 이 지침 묶음을 스캐폴드(발판)라고 부른다.

3단계, 풀어 보기. 과제와 발판을 놓고 실제로 답을 여러 번 만들어 본다. 그 결과로 나온 점수를 세 단계 전부에 거꾸로 돌려보내 다음 회차를 조정한다. 이 되돌리는 방식으로 GRPO라는 강화학습 기법을 쓴다고 적혀 있다.

발표문의 표현은 이렇다. “더 강해진 모델이 더 어려운 과제를 만들고, 진화한 발판이 능력을 끌어내는 더 나은 방법을 찾고, 더 좋아진 풀이가 더 효과적인 학습 신호를 준다.”

왜 이게 중요한가. 지금까지 모델을 더 똑똑하게 만드는 방법은 대체로 사람이 만든 문제와 사람이 쓴 정답을 더 많이 먹이는 것이었다. 그 방식은 사람이 문제를 만드는 속도에서 막힌다.

이 루프는 그 병목을 모델 안으로 넣으려는 시도다. 잘 되면 사람 손을 덜 타고 계속 올라간다.

그런데 부작용도 여기서 나온다. 모델이 자기가 낼 수 있는 문제만 내면, 잘하는 방향으로만 계속 파고들 수 있다. 코딩 점수가 크게 오르고 웹 검색 점수는 오히려 밀린 이 표의 모양이, 그 가능성과 잘 들어맞는다.

이 벤치표를 어디까지 믿을까

숫자가 좋을수록 조건을 봐야 한다. 확인되는 것과 확인 안 되는 것을 나눠 적는다.

확인되는 것. 모델 카드에 “오르니스 1.5의 모든 결과는 독립적으로 다섯 번 돌린 평균”이라고 적혀 있다. 한 번 잘 나온 걸 올린 게 아니라는 뜻이라 이건 좋은 신호다.

확인되는 것. 가중치가 실제로 공개돼 있다. 표만 내놓고 모델은 안 주는 발표와는 다르다. 누구나 받아서 같은 시험을 다시 돌려 볼 수 있고, 이런 표는 대개 며칠 안에 외부 검증이 붙는다.

확인 안 되는 것. 비교 대상 모델들의 점수를 누가 어떤 설정으로 측정했는지는 발표문에 나와 있지 않다. 자기 모델은 5회 평균인데 상대 모델도 같은 조건이었는지 알 수 없다.

확인 안 되는 것. 앞서 본 DeepSWE의 0점 대 22점처럼 격차가 비정상적으로 큰 칸이 있다. 실력이 늘어서일 수도 있고, 그 시험이 요구하는 출력 형식에 맞춰졌기 때문일 수도 있다. 지금 자료로는 구분이 안 된다.

확인 안 되는 것. 벤치마크 문제가 학습 데이터에 섞여 들어갔는지 여부. 이건 어느 모델 발표에서도 외부에서 검증하기 어려운 항목이다.

큐원 3.8-27B가 공개됐을 때 벤치표를 믿어도 되는지 따졌던 글에서 쓴 기준이 여기에도 그대로 적용된다. 자체 측정 표는 “가능성의 상한선”으로 읽고, 실제 성능은 내 일감으로 직접 재는 게 맞다.

실제로 돌려 보려면

모델 카드에 적힌 실행 환경은 이렇다.

서버에서 돌릴 때. vLLM 0.19.1 이상, SGLang 0.5.9 이상, 트랜스포머스 5.8.1 이상을 지원한다. vLLM과 SGLang은 모델을 API 서버로 띄워 주는 도구다. OpenAI와 호환되는 형식으로 응답하기 때문에 기존 코드에서 주소만 바꿔 붙일 수 있다.

개인 컴퓨터에서 돌릴 때. GGUF 버전이 있어 llama.cpp와 올라마에서 쓸 수 있다. 올라마는 명령어 한 줄로 모델을 받아 띄워 주는 프로그램이다.

맥에서 돌릴 때. MLX 버전이 4·6·8비트로 올라와 있다. MLX는 애플이 만든 자사 칩 전용 실행 도구다.

컨텍스트 길이는 262,144 토큰이다. 토큰은 모델이 글을 쪼개서 세는 단위이고, 한국어는 대략 글자 하나가 토큰 하나에서 두 개쯤 된다. 26만 토큰이면 책 한 권 분량을 한 번에 넣을 수 있는 크기다.

YaRN이라는 기법을 배율 4.0으로 쓰면 약 100만 토큰까지 늘릴 수 있다고 적혀 있다. 다만 이렇게 늘리면 대개 짧은 입력에서의 정확도가 조금 떨어진다.

한 가지 주의할 점. 이 모델들은 추론 모델이다. 기본 설정에서 답을 내기 전에 <think>로 감싼 생각 과정을 먼저 출력한다.

기존 코드에 그대로 붙이면 이 블록이 사용자 화면에 그대로 나갈 수 있다. 앱에 연결하기 전에 이 부분을 걸러내는 처리가 필요하다.

오늘 뭘 하면 되나

당장 할 일이 없는 경우가 대부분이다. 코드 짜는 AI를 유료로 잘 쓰고 있다면 바꿀 이유가 아직 없다. 오르니스는 공식 API 서비스가 없어서, 쓰려면 직접 띄우거나 남이 띄워 둔 걸 찾아야 한다.

노트북이나 데스크톱에서 로컬 모델을 이미 굴리고 있다면, 9B GGUF나 MLX 4비트를 받아 지금 쓰는 모델과 같은 일감을 던져 보는 게 가장 빠른 확인이다. 표가 아니라 내 코드베이스에서 재는 게 유일하게 믿을 만한 숫자다.

GPU 서버를 굴리는 팀이라면 35B-A3B가 볼 만하다. 활성 파라미터가 30억 개라 응답이 빠르고, 모델 카드 기준 80GB GPU 두 장이면 256K 컨텍스트까지 여유가 있다고 적혀 있다.

어떤 경우든 코딩 외의 일감은 따로 재라. 이 표에서 오르니스가 확실히 앞선 건 코딩이다. 웹 검색과 긴 추론은 오히려 밀린 칸이 더 많았다.

그리고 며칠 기다리는 것도 방법이다. 가중치가 공개됐으니 외부 재현 결과가 곧 나온다. 자체 측정 표와 외부 측정이 얼마나 벌어지는지가, 이 모델의 진짜 성적표다.

이 글의 수치는 2026년 8월 20일 기준 오르니스 공식 발표문(ornith.ai)과 허깅페이스 ornith-ai 조직의 모델 카드에서 확인한 값이다. 벤치마크 점수는 모두 오르니스 팀의 자체 측정이며, 외부 독립 검증 결과가 아니다.