Ornith-1.0: 스캐폴드를 스스로 학습하는 에이전트 코딩 LLM (feat. DeepReinforce)

9bow · 6월 28, 2026, 7:30오전

Ornith-1.0 소개

처음으로 정말 까다로운 프로그래밍 과제를 마주했던 순간을 떠올려 봅시다. 우리는 곧장 정답 코드를 써 내려가지 못합니다. 대신 어떤 순서로 파일을 열어볼지, 어떤 테스트를 먼저 돌려볼지, 에러가 나면 어떻게 기록하고 되짚을지와 같은 작업 절차(워크플로) 자체를 먼저 머릿속에 세우고, 그 절차를 따라 시도하고 실패하면서 절차 자체를 조금씩 고쳐 나갑니다. 좋은 개발자와 그렇지 못한 개발자의 차이는 단순히 코드 실력뿐 아니라, 문제를 풀어가는 이 절차를 얼마나 잘 설계하느냐에서 갈리기도 합니다.

이 글에서 소개하는 Ornith-1.0 은 바로 이 "문제를 풀어가는 절차"까지 모델이 스스로 학습하도록 만든 에이전트 코딩(agentic coding) 특화 오픈소스 모델 패밀리입니다. DeepReinforce 팀이 공개한 Ornith-1.0은 사람이 손으로 설계한 고정된 작업 절차에 의존하는 대신, 모델이 해법(solution)과 그 해법을 이끌어내는 작업 절차(scaffold)를 함께 생성하고 함께 최적화하는 자기개선형(self-improving) 강화학습(Reinforcement Learning) 프레임워크를 핵심으로 합니다. 그 결과 Ornith-1.0은 동급 크기의 오픈소스 모델 중 다수의 코딩 벤치마크에서 최고 수준(state-of-the-art)의 성능을 달성했습니다.

에이전트 코딩과 "하네스(harness)"의 한계

최근 대형 언어 모델(LLM)을 단순한 코드 자동완성 도구를 넘어, 터미널을 직접 다루고 여러 파일을 오가며 버그를 고치는 자율 에이전트(autonomous agent) 로 활용하려는 흐름이 빠르게 확산되고 있습니다. SWE-Bench 나 Terminal-Bench 처럼 실제 GitHub 이슈를 해결하거나 터미널 환경에서 과제를 완수하는 능력을 측정하는 벤치마크가 사실상의 표준 평가 기준으로 자리 잡았습니다.

이런 에이전트 코딩에서 모델의 성능을 좌우하는 결정적인 요소 중 하나가 바로 하네스(harness), 또는 스캐폴드(scaffold) 라고 불리는 작업 절차입니다. 스캐폴드는 모델이 어떤 순서로 도구를 호출하고, 중간 결과를 어떻게 기억하며, 에러가 발생했을 때 어떻게 대응할지를 규정하는 일종의 골격입니다. 같은 모델이라도 어떤 스캐폴드를 씌우느냐에 따라 성능이 크게 달라집니다.

문제는 지금까지 이 스캐폴드를 거의 전적으로 사람이 손으로 설계해 왔다는 점입니다. 연구자가 특정 과제 유형(예: 버그 수정, 신규 기능 구현)마다 적절한 작업 절차를 미리 짜두고, 모든 과제에 동일한 절차를 적용하는 방식입니다. 이 접근에는 두 가지 한계가 있습니다. 첫째, 사람이 설계한 고정된 절차는 과제마다 미묘하게 다른 최적 전략을 담아내지 못합니다. 둘째, 모델의 능력이 향상되더라도 절차가 고정되어 있으면 그 절차가 곧 성능의 천장(ceiling)이 되어 버립니다. 마치 아무리 실력 있는 요리사라도 정해진 레시피 순서를 한 글자도 못 바꾸게 한다면 진짜 실력을 발휘하기 어려운 것과 같습니다.

Ornith-1.0의 발상 전환: 스캐폴드를 학습 대상으로

Ornith-1.0의 핵심 발상은 단순하면서도 강력합니다. 스캐폴드 자체를 고정된 설계물이 아니라, 모델이 학습을 통해 함께 진화시키는 대상(learnable object)으로 취급하는 것입니다. 즉, 모델은 과제를 푸는 해법만 생성하는 것이 아니라, 그 해법을 이끌어낼 작업 절차까지 스스로 만들어내고, 강화학습을 통해 둘을 동시에 개선해 나갑니다. DeepReinforce 팀은 모델이 자신의 작업 절차를 스스로 세운다는 의미에서 이 접근을 자기 스캐폴딩(Self-Scaffolding) 이라 부르며, 이는 블로그 제목(Self-Scaffolding LLMs for Agentic Coding)에도 그대로 드러나 있습니다.

이는 마치 과학자가 실험을 설계할 때, 실험 결과만 기록하는 것이 아니라 "어떻게 실험할 것인가"라는 실험 방법론 자체를 계속 다듬어 가는 과정과 닮아 있습니다. 좋은 결과가 나온 방법론은 살아남고, 그렇지 못한 방법론은 도태되면서, 점점 더 높은 보상을 이끌어내는 절차들이 자동으로 발견(emerge) 됩니다. 사람이 일일이 절차를 손보지 않아도 과제 유형별 전략이 스스로 생겨나는 것입니다.

이 발상이 실제로 통한다는 것을 결과가 보여줍니다. 플래그십 모델인 Ornith-1.0-397B 는 Terminal-Bench 2.1에서 77.5 점, SWE-Bench Verified에서 82.4 점을 기록하며, 두 벤치마크 모두에서 Claude Opus 4.7(70.3 , 80.8 )을 앞섰습니다. 가장 작은 Ornith-1.0-9B 조차 엣지 디바이스에 올릴 수 있는 크기임에도 Terminal-Bench 2.1에서 43.1 점을 달성하며, 자신보다 훨씬 큰 Gemma 4-31B와 맞먹거나 능가하는 성능을 보였습니다.

자기개선형 학습 프레임워크

Ornith-1.0의 심장부에는 과제를 푸는 능력과 과제를 푸는 절차를 동시에 학습하는 자기개선형 학습 프레임워크가 있습니다. 핵심은 스캐폴드를 정책(policy)과 함께 진화하는 학습 대상으로 다룬다는 점입니다. 이 절에서는 그 구체적인 동작 방식을 단계별로 살펴봅니다.

스캐폴드와 해법의 공동 최적화

각 강화학습 스텝은 두 단계로 진행됩니다.

첫 번째 단계는 스캐폴드 제안 입니다. 모델은 주어진 과제(task)와 그 과제에 직전까지 사용되던 스캐폴드를 입력으로 받아, 개선된 새로운 스캐폴드를 제안합니다. 즉 "이 과제를 풀기 위한 더 나은 작업 절차는 무엇인가?"를 모델 스스로 답하는 것입니다.

두 번째 단계는 해법 생성 입니다. 방금 만들어낸 스캐폴드와 과제 설명을 조건으로 삼아, 모델은 실제 해법 롤아웃(rollout)을 생성합니다. 위 그림에서 보듯 하나의 스캐폴드로부터 여러 개의 해법 롤아웃이 만들어집니다.

여기서 가장 중요한 설계는 보상의 흐름 입니다. 롤아웃이 받은 보상(reward)은 해법 생성 단계뿐 아니라 스캐폴드 제안 단계로도 함께 전파됩니다. 따라서 모델은 단지 "더 좋은 답"을 내도록 최적화되는 것이 아니라, "그 답을 이끌어내는 더 좋은 절차"를 작성하도록 함께 최적화됩니다. 학습이 반복될수록 스캐폴드는 끊임없이 변형(mutate)되고 그중 높은 보상을 유도하는 것들이 선택(select)되는 피드백 루프가 형성되며, 과제 유형별 전략이 사람의 개입 없이 자동으로 떠오르게 됩니다.

보상 해킹(Reward Hacking) 방어: 3중 방어막

모델이 자신의 작업 절차를 스스로 작성하도록 허용하면, 곧바로 보상 해킹(reward hacking) 이라는 고질적인 문제가 따라옵니다. 보상 해킹이란 모델이 과제를 실제로 해결하지 않고도 채점기(verifier)를 속여 보상을 챙기는 행동을 말합니다. 예를 들어 스스로 작성한 스캐폴드가 눈에 보이는 테스트 파일을 미리 읽어 기대되는 산출물을 하드코딩하거나(채점기가 확인하는 파일을 그냥 생성해 버리거나, 기대 출력값을 그대로 적어 넣거나), 환경에 들어 있는 정답(oracle) 풀이를 베끼는 식입니다. 마치 시험 문제를 푸는 대신 채점 기준표를 훔쳐보고 답만 맞추는 학생과 같습니다.

Ornith-1.0은 이 문제를 세 겹의 방어막으로 막아냅니다.

첫째, 바깥쪽 신뢰 경계(trust boundary)를 고정합니다. 환경, 도구 인터페이스(tool surface), 테스트 격리(test isolation)는 모두 변경 불가능하며 모델의 손이 닿지 않는 영역으로 둡니다. 모델이 진화시킬 수 있는 것은 오직 안쪽의 정책 스캐폴드, 즉 메모리 관리, 에러 처리, 오케스트레이션 로직뿐입니다. 운영체제가 사용자 프로세스에게 커널 메모리를 건드리지 못하게 하는 것과 비슷한 발상입니다.

둘째, 결정론적 모니터(deterministic monitor) 가 그 경계를 정확히 명세할 수 있는 수준에서 강제합니다. 숨겨진 경로(withheld path)를 읽으려 하거나, 검증 스크립트를 수정하려 하거나, 허가된 도구 범위를 벗어난 행동을 시도하면 즉시 적발하고, 해당 궤적(trajectory)에는 보상 0 을 부여하며 어드밴티지(advantage) 계산에서도 제외합니다.

셋째, 동결된 LLM 심판(frozen LLM judge) 이 마지막 거부권(veto)을 행사합니다. 의도 수준의 편법은 허가된 도구 범위 안에서도 얼마든지 일어날 수 있기 때문에, 규칙으로 잡아내기 어려운 이런 교묘한 편법은 채점기 위에 얹힌 별도의 LLM 심판이 걸러냅니다. 이때 심판은 주된 보상원이 아니라 어디까지나 채점기 결과에 대한 거부권으로만 작동한다는 점이 중요합니다.

비동기 RL 학습(Pipeline-RL)과 staleness weight

에이전트 코딩 과제는 한 번의 롤아웃이 매우 길기 때문에, 학습 속도를 높이려면 롤아웃 생성과 정책 업데이트를 비동기적으로 파이프라인화할 수밖에 없습니다. Ornith-1.0은 이를 위해 pipeline-RL 전략을 채택합니다.

비동기 학습의 본질적인 문제는 오프-정책(off-policy) 토큰입니다. 긴 롤아웃이 생성되는 동안 정책은 이미 여러 번 업데이트되므로, 롤아웃 앞부분에서 만들어진 토큰들은 현재 정책이 아닌 과거 정책으로 생성된 셈이 됩니다. 이렇게 오래된(stale) 토큰을 그대로 학습에 쓰면 학습이 불안정해집니다.

Ornith-1.0은 토큰의 나이(age) d_t 에 따라 가중치를 낮추는 staleness weight w(d_t) 를 도입해 이 문제를 다룹니다. 토큰이 충분히 최신이면 온전히 반영하고, 어느 정도 오래되면 지수적으로 감쇠시키며, 임계값을 넘어서면 아예 버립니다.

w(d_t)= \begin{cases} 1, & \text{if } d_t \le K_1,\\ \exp\!\bigl(-\lambda(d_t-K_1)\bigr), & \text{if } K_1 < d_t \le K_2,\\ 0, & \text{if } d_t > K_2. \end{cases}

이렇게 계산한 가중치는 토큰 단위 GRPO 손실에 곱해집니다. 즉 표준적인 클리핑(clipping) 기반 정책 경사 손실에 staleness weight w(d_t) 를 추가로 곱해, 오래된 토큰일수록 학습 신호의 기여를 줄이는 구조입니다.

L_t=\min\!\bigl(r_t A_t,\; \mathrm{clip}(r_t,1-\epsilon^{-},1+\epsilon^{+})A_t\bigr)\cdot w(d_t)

여기서 중요도 비율(importance ratio) r_t 는 현재 정책 \pi_{\theta} 와 토큰을 실제로 생성했던 행동 정책 \pi_{\theta_t^{\mathrm{beh}}} 의 확률 비로 정의됩니다.

r_t= \frac{\pi_{\theta}(y_t \mid x, y_{<t})}{\pi_{\theta_t^{\mathrm{beh}}}(y_t \mid x, y_{<t})}

클리핑 범위가 1-\epsilon^{-} 와 1+\epsilon^{+} 로 비대칭(asymmetric)으로 설정되어 있다는 점도 눈에 띕니다. 이렇게 staleness weight와 클리핑을 결합함으로써, Ornith-1.0은 긴 롤아웃을 비동기로 생성하면서도 오프-정책 토큰이 학습을 흔드는 것을 억제합니다.

실험 결과 및 성능 분석

Ornith-1.0은 에이전트 코딩 전반을 폭넓게 다루는 다양한 벤치마크에서 평가되었습니다. 주요 벤치마크는 다음과 같습니다.

Terminal-Bench 2.1: 터미널 환경에서 과제를 완수하는 능력을 측정합니다. Terminus-2와 Claude Code 두 가지 하네스로 평가했습니다.
SWE-Bench (Verified / Pro / Multilingual): 실제 GitHub 이슈를 해결하는 능력을 측정하는 사실상의 표준 벤치마크입니다.
NL2Repo: 자연어 명세로부터 저장소(repository) 수준의 코드를 생성하는 과제입니다.
ClawEval, SWE Atlas: 실제 사용자 과제 분포를 반영한 에이전트 코드 벤치마크입니다.

모든 점수는 5회 실행 평균이며, Terminal-Bench는 Harbor/Terminus-2와 Claude Code 두 하네스로, SWE-Bench 계열은 OpenHands 하네스로 평가했습니다. 흥미롭게도 NL2Repo 평가에는 보상 해킹을 막기 위한 anti-hacking 필터를 적용했는데, 이는 앞서 살펴본 학습 단계의 보상 해킹 방어 철학이 평가 단계에까지 일관되게 이어진다는 점을 보여줍니다.

플래그십: Ornith-1.0-397B

가장 큰 397B MoE 모델은 Terminal-Bench 2.1(Terminus-2)에서 77.5 점, SWE-Bench Verified에서 82.4 점을 기록했습니다. 이는 같은 두 벤치마크에서 각각 70.3 , 80.8 점을 받은 Claude Opus 4.7 을 모두 앞서는 수치입니다. 동급의 오픈소스 모델들, 예를 들어 Minimax-M3나 DeepSeek-V4-Pro와 비교해도 Terminal-Bench 2.1에서 뚜렷한 우위를 보였습니다.

다만 두 가지 맥락을 함께 봐야 균형 잡힌 평가가 됩니다. 첫째, 가장 최신 모델인 Claude Opus 4.8 (85.0 on TB-2.1, 87.6 on SWE-Bench Verified)은 여전히 Ornith-1.0-397B보다 앞서 있습니다. 둘째, 오픈소스 진영 안에서도 Ornith보다 약 두 배 큰 GLM-5.2-744B 는 Terminal-Bench 2.1(Terminus-2)에서 81.0 점으로 Ornith의 77.5 점을 앞섭니다. 따라서 Ornith-1.0-397B의 강점은 "비슷한 크기"의 오픈소스 모델 가운데 최고 수준이라는 데 있으며, 더 큰 모델까지 통틀어 보면 Terminal-Bench에서는 GLM-5.2-744B가, SWE-Bench Verified에서는 Ornith-1.0-397B가 앞서는 양상으로 정리할 수 있습니다. 즉 Ornith-1.0-397B는 "직전 세대 프런티어 모델(Opus 4.7) 수준을 오픈소스로 재현"한 것으로 이해하는 편이 정확합니다. 그럼에도 가중치가 공개된 MIT 라이선스 모델이 이 수준에 도달했다는 점은 충분히 주목할 만한 성과입니다.

주요 벤치마크 결과를 표로 정리하면 다음과 같습니다.

벤치마크	Ornith-1.0-397B	Qwen3.5-397B	GLM-5.2-744B	Minimax-M3-428B	DeepSeek-V4-Pro-1.6T	Claude Opus 4.7	Claude Opus 4.8
Terminal-Bench 2.1 (Terminus-2)	77.5	53.5	81.0	64.0	64.0	70.3	85.0
SWE-Bench Verified	82.4	76.4	-	-	80.6	80.8	87.6
SWE-Bench Pro	62.2	51.6	62.1	59.0	55.4	64.3	69.2
NL2Repo	48.2	36.8	48.9	42.1	-	-	69.7

경량 모델: 35B와 9B

Ornith-1.0의 진가는 작은 모델에서 더욱 두드러집니다. Ornith-1.0-35B 는 단일 GPU 배포를 염두에 둔 MoE 모델임에도, 동급 크기 모델인 Qwen3.5-35B, Qwen3.6-35B, Gemma4-31B를 큰 격차로 앞섰습니다. 특히 Terminal-Bench 2.1에서는 64.2 점을 기록하며, 자신보다 10배 이상 큰 Qwen3.5-397B의 53.5 점 을 오히려 능가하는 결과를 보였습니다.

엣지 디바이스에 배포 가능한 Ornith-1.0-9B 역시 Terminal-Bench 2.1에서 43.1 점, SWE-Bench Verified에서 69.4 점이라는 인상적인 결과를 냈습니다. 컴팩트한 9B 파라미터 모델이 Gemma 4-31B처럼 훨씬 큰 모델과 맞먹거나 능가한다는 사실은, 강력한 에이전트 코딩 능력이 반드시 거대한 모델 크기를 요구하는 것은 아님을 보여줍니다. 이는 자기개선형 학습이 만들어낸 양질의 스캐폴드가 작은 모델의 한정된 용량을 효율적으로 끌어올린 결과로 해석할 수 있습니다.

벤치마크	Ornith-1.0-35B	Qwen3.5-35B	Gemma4-31B	Ornith-1.0-9B	Gemma4-12B
Terminal-Bench 2.1 (Terminus-2)	64.2	41.4	42.1	43.1	21.0
SWE-Bench Verified	75.6	70.0	52.0	69.4	44.2
SWE-Bench Pro	50.4	44.6	35.7	42.9	27.6
NL2Repo	34.6	20.5	15.5	27.2	10.3

모델 라인업과 라이선스

Ornith-1.0은 9B Dense, 31B Dense, 35B MoE, 397B MoE의 네 가지 변형으로 제공됩니다. 모두 사전학습된 Gemma 4 와 Qwen 3.5 위에 자기개선형 강화학습을 적용해 사후 학습(post-training)한 모델입니다. 엣지 디바이스용 9B 컴팩트 모델부터 최대 성능을 위한 397B 프런티어급 MoE 모델까지 전 스펙트럼을 아우르며, 양자화된 FP8 및 GGUF 빌드도 함께 공개되었습니다. 모든 모델은 MIT 라이선스 로 배포되어 지역 제한 없이 누구나 자유롭게 사용할 수 있습니다.

Ornith-1.0 설치 및 사용 방법

Ornith-1.0-35B는 기본적으로 <think> ... </think> 블록으로 사고 과정을 먼저 출력하는 추론(reasoning) 모델입니다. 아래 서빙 레시피는 추론 파서와 도구 호출 파서를 활성화하여, 사고 과정은 reasoning_content 필드로, 도구 호출은 OpenAI 형식의 tool_calls 로 분리해 줍니다. 서빙에는 transformers >= 5.8.1, vLLM >= 0.19.1, SGLang >= 0.5.9 등 비교적 최신 런타임이 필요합니다.

가장 간단하게는 vLLM으로 OpenAI 호환 서버를 띄울 수 있습니다.

vllm serve deepreinforce-ai/Ornith-1.0-35B \
    --served-model-name Ornith-1.0-35B \
    --tensor-parallel-size 8 \
    --host 0.0.0.0 --port 8000 \
    --max-model-len 262144 \
    --gpu-memory-utilization 0.90 \
    --enable-prefix-caching \
    --enable-auto-tool-choice --tool-call-parser qwen3_xml \
    --reasoning-parser qwen3 \
    --trust-remote-code

서버가 뜨면 OpenAI 호환 클라이언트로 그대로 호출할 수 있습니다. reasoning_content 에 사고 과정이, content 에 최종 답변이 담깁니다.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

response = client.chat.completions.create(
    model="Ornith-1.0-35B",
    messages=[{"role": "user", "content": "Write a one-line Python lambda that squares a number."}],
    temperature=0.6,
    top_p=0.95,
    max_tokens=1024,
)

message = response.choices[0].message
print("reasoning:", getattr(message, "reasoning_content", None))
print("answer:", message.content)

Ornith-1.0은 OpenAI 호환 엔드포인트와 도구 호출을 그대로 지원하므로, OpenHands, OpenCode, OpenClaw 같은 표준 에이전트 프레임워크 및 코딩 CLI에 OPENAI_BASE_URL 과 OPENAI_API_KEY 만 지정하면 곧바로 연결됩니다. GGUF 빌드를 활용하면 llama.cpp나 Ollama로 로컬에서도 손쉽게 구동할 수 있습니다.

# OpenHands는 LiteLLM을 거치므로 "openai/" 접두어로 OpenAI 호환 경로를 선택합니다.
export LLM_MODEL="openai/deepreinforce-ai/Ornith-1.0-35B"
export LLM_BASE_URL="http://localhost:8000/v1"
export LLM_API_KEY="EMPTY"
openhands

한계점 및 시사점

Ornith-1.0이 보여준 성과는 인상적이지만, 몇 가지 맥락을 함께 짚어볼 필요가 있습니다. 첫째, 플래그십 397B 모델이 직전 세대 프런티어 모델(Claude Opus 4.7) 수준에 도달했지만, 가장 최신 폐쇄형 모델(Claude Opus 4.8)과는 여전히 격차가 존재합니다. 오픈소스가 프런티어를 빠르게 추격하고 있으나 아직 완전히 따라잡은 것은 아닙니다.

둘째, 자기개선형 학습의 핵심 난제인 보상 해킹은 세 겹의 방어막으로 상당 부분 완화되었지만, 본질적으로 모델이 채점기를 우회할 동기를 가진다는 구조적 긴장은 남아 있습니다. 신뢰 경계를 고정하고 LLM 심판을 두는 방식은 강력하지만, 의도 수준의 교묘한 편법을 완벽하게 걸러낸다고 보장하기는 어렵습니다. 이는 검증 가능한 보상(verifiable reward)에 기반한 모든 강화학습이 공통으로 안고 가야 할 과제이기도 합니다.

그럼에도 Ornith-1.0이 던지는 메시지는 분명합니다. 사람이 손으로 설계하던 작업 절차(스캐폴드)마저 학습 대상으로 끌어들이면, 모델은 단순히 더 나은 답을 내는 것을 넘어 더 나은 문제 해결 전략 자체를 발견할 수 있다 는 것입니다. 이는 강화학습의 최적화 대상을 "정책"에서 "정책 + 그 정책을 둘러싼 절차"로 한 단계 확장한 시도로, 에이전트가 스스로 일하는 방식을 설계하는 미래로 가는 의미 있는 이정표라 할 수 있습니다. 더구나 9B부터 397B까지 전 라인업을 MIT 라이선스로 공개했다는 점에서, 이 자기개선형 접근을 누구나 직접 검증하고 확장해 볼 수 있다는 실용적 가치도 큽니다.

Ornith-1.0: Self-Scaffolding LLMs for Agentic Coding 소개 블로그

Ornith-1.0 컬렉션 (Hugging Face)

Ornith-1.0-35B (Hugging Face)

Ornith-1.0-397B (Hugging Face)

Ornith-1.0-9B (Hugging Face)

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~