최근 DeepReinforce가 Ornith-1.0이라는 오픈소스 코딩 모델 패밀리를 공개했습니다.
DeepReinforceOrnith-1.0: Self-Scaffolding LLMs for Agentic CodingIntroducing Ornith-1.0, a self-improving family of open-source models specially for agentic coding tasks.https://deep-reinforce.com/ornith_1_0.html
Ornith-1.0은 에이전틱 코딩 작업을 위한 오픈소스 모델 패밀리입니다. 공식 자료 기준으로 9B Dense, 31B Dense, 35B MoE, 397B MoE 라인업이 소개되어 있고, HuggingFace에는 9B, 35B, 397B 모델과 GGUF, FP8 같은 여러 배포 형식이 올라와 있습니다.
huggingface.coOrnith-1.0 - a deepreinforce-ai CollectionOrnith-1.0 is a family of open-source LLMs specialized for agentic coding.https://huggingface.co/collections/deepreinforce-ai/ornith-10Ornith-1.0 의 핵심 Self-Scaffolding RL
처음에는 Qwen 이나 Gemma 처럼 가성비 좋은 로컬에서 사용이 가능한 또 하나의 코딩 특화 모델이 나온 정도로 생각했습니다. 요즘은 워낙 많은 AI 모델이 나오다 보니, 단순히 “성능이 좋아졌다”, “벤치마크가 높다”는 이야기만으로는 크게 새롭다고 느껴지지 않기도 합니다.
그런데 Ornith-1.0은 조금 다른 지점이 있었습니다.
핵심은 모델이 단순히 코드를 잘 쓰도록 학습된 것이 아니라, 문제를 어떻게 풀지에 해당하는 작업 구조, 즉 스캐폴드까지 함께 학습한다는 점입니다.
DeepReinforce는 이 방식을 Self-Scaffolding RL이라고 부르고 있습니다.
일반적으로 코딩 모델을 학습시킬 때는 사람이 미리 만든 평가 환경이나 작업 흐름이 있습니다. 모델은 그 안에서 코드를 생성하고, 테스트를 통과하면 보상을 받는 식으로 학습합니다. 문제는 이 구조가 특정 작업 유형에만 잘 맞을 수 있다는 점입니다.
예를 들어 어떤 하네스는 버그 수정에는 잘 맞지만, 테스트 생성에는 약할 수 있습니다. 또 어떤 구조는 작은 파일 수정에는 잘 맞지만, 여러 파일을 오가며 맥락을 유지해야 하는 작업에서는 약해질 수 있습니다.
Ornith-1.0이 흥미로운 이유는 이 지점에 있습니다.
DeepReinforce의 설명에 따르면 Ornith는 답을 생성하는 것만 학습하는 것이 아니라, 그 답을 만들기 위한 스캐폴드까지 함께 학습합니다. 쉽게 말하면 모델이 “이 문제를 어떤 순서로 접근할지”, “무엇을 기억해야 할지”, “실패했을 때 어떻게 복구할지”, “어떤 도구를 어떤 순서로 사용할지” 같은 작업 전략까지 같이 최적화한다는 이야기입니다.
기존 방식은 대략 이런 흐름입니다.
사람이 학습 하네스를 설계합니다. -> 모델은 그 안에서 답을 생성합니다. -> 테스트를 통과하면 보상을 받습니다. -> 그 과정을 반복하면서 모델이 좋아집니다.
반면 Ornith가 주장하는 방식은 조금 다릅니다.
모델이 먼저 스캐폴드를 생성합니다. -> 그 스캐폴드를 바탕으로 문제를 풉니다. -> 결과에 대한 보상이 답변뿐 아니라 스캐폴드 쪽에도 반영됩니다. -> 이 과정을 반복하면서 문제를 푸는 방식 자체도 같이 개선됩니다.
이것이 실제로 잘 작동한다면, 코딩 AI에서 꽤 중요한 변화가 될 수 있습니다. 단순히 “코드를 잘 쓰는 모델”을 넘어서, “작업 흐름을 스스로 개선하는 모델”에 가까워지기 때문입니다.
물론 여기서 조심해야 할 부분도 있습니다. 모델이 스캐폴드를 스스로 학습한다고 해서, 모든 개발 과정을 완전히 자율적으로 해결한다는 뜻은 아닙니다. 더 정확히는 사람이 설계한 강화학습 프레임워크 안에서, 태스크별 접근 방식까지 함께 최적화하도록 만든 구조에 가깝습니다.
Ornith-1.0의 공식 벤치마크도 꽤 인상적입니다. 특히 397B 모델은 Terminal-Bench 2.1, SWE-Bench Verified, SWE-Bench Pro 같은 코딩 관련 벤치마크에서 높은 점수를 보고했습니다. 35B MoE 모델도 눈에 띕니다. 일부 벤치마크에서는 훨씬 큰 모델과 비교해도 꽤 좋은 결과를 보여줬기 때문입니다.
자, 그렇다면 이제 새로운 혁신이 일어난건가?
다만 이 수치는 “공식 발표 기준”으로 봐야 합니다. 아직 독립적인 재현 결과가 충분히 쌓인 상태는 아니기 때문에, 이 숫자만 보고 곧바로 “기존 상용 코딩 모델을 완전히 대체한다”고 말하기는 어렵습니다.
특히 35B 모델에 대해서는 표현을 조심할 필요가 있습니다. 일부 자료에서는 35B 모델이 397B급 모델을 이겼다는 식으로 이야기되지만, 실제로는 모든 벤치마크에서 그런 것은 아닙니다. Terminal-Bench 2.1 같은 특정 평가에서는 매우 강한 결과를 보였지만, SWE-Bench Verified나 SWE-Bench Pro에서는 더 큰 모델이 앞서는 경우도 있습니다.
그래서 이 부분은 이렇게 보는 것이 맞습니다.
Ornith-1.0-35B는 모든 면에서 대형 모델을 압도했다기보다, 일부 에이전틱 코딩 환경에서 작은 모델도 충분히 강한 효율을 낼 수 있다는 가능성을 보여준 모델에 가깝습니다.
이 지점은 개인적으로 꽤 중요하게 봅니다. 최근 AI 모델 경쟁은 계속 “더 큰 모델”, “더 많은 파라미터”, “더 강한 프론티어 모델” 중심으로 흘러왔습니다. 그런데 실제 제품을 만들거나 SaaS를 운영하는 입장에서는 항상 가장 큰 모델만 쓸 수 없습니다. 비용, 속도, 배포 환경, 지연 시간, 로컬 실행 가능성까지 같이 봐야 하기 때문입니다.
그런 의미에서 Ornith-1.0의 35B MoE 모델은 꽤 흥미롭습니다. 만약 실제 사용 환경에서도 공식 벤치마크에 가까운 효율이 나온다면, 로컬 또는 프라이빗 환경에서 코딩 에이전트를 구성하려는 팀에게는 실험해볼 만한 선택지가 될 수 있습니다.
또 하나 중요한 부분은 보상 해킹 방어입니다.
코딩 에이전트를 강화학습으로 학습시킬 때 가장 골치 아픈 문제 중 하나는 모델이 실제로 문제를 푸는 대신, 점수만 올리는 방법을 찾아낼 수 있다는 점입니다. 예를 들어 숨겨진 테스트 파일을 읽거나, 검증 스크립트를 조작하거나, 예상 출력을 하드코딩하는 식입니다.
이런 현상은 단순한 상상이 아닙니다. 최근 에이전틱 코딩 모델 평가에서도 모델이 평가 환경의 허점을 이용하는 문제가 실제로 중요한 쟁점으로 다뤄지고 있습니다.
DeepReinforce는 Ornith-1.0에서 이를 막기 위해 세 가지 구조를 설명합니다.
이 부분은 기술적으로 흥미롭지만, 동시에 가장 조심해서 봐야 하는 부분이기도 합니다.
공식 자료에서 이런 방어 구조를 설명하고 있다고 해서, 실제 프로덕션 환경에서도 완전히 안전하다고 볼 수는 없습니다. 평가 환경과 실제 개발 환경은 다릅니다. 실제 프로젝트에는 복잡한 레거시 코드, 불완전한 테스트, 애매한 요구사항, 사내 도구, 사람의 리뷰 과정이 모두 섞여 있습니다.
그래서 Ornith의 보상 해킹 방어는 “문제를 해결했다”라기보다는, “에이전틱 코딩 모델이 앞으로 반드시 다뤄야 할 문제를 꽤 정면으로 다루고 있다” 정도로 보는 것이 맞습니다.
SWE-Bench 같은 벤치마크도 마찬가지입니다.
SWE-Bench Verified는 코딩 모델을 비교할 때 자주 등장하는 지표입니다. 실제 GitHub 이슈와 코드 수정 작업을 기반으로 하기 때문에 단순 알고리즘 문제보다 현실적인 평가로 여겨집니다. 하지만 이 벤치마크도 완벽한 것은 아닙니다. 문제 오염 가능성, 테스트 강도, 의미적으로 올바른 패치인지 여부 등에 대한 지적이 계속 나왔습니다.
따라서 SWE-Bench 점수는 유용한 참고 지표이지만, “이 모델이 실제 회사의 개발 업무를 이 정도 비율로 해결한다”는 식으로 그대로 해석하면 위험합니다.
마치며..
이 글을 쓰면서 가장 흥미로웠던 부분은 결국 하나입니다.
Ornith-1.0은 단순히 오픈소스 모델이 등장했기 보다는 더 효율적인 방법론들이 나오고있는 소식을 보입니다.
예전에는 모델이 코드를 얼마나 잘 생성하는지가 핵심이었습니다. 그다음에는 도구를 얼마나 잘 쓰는지가 중요해졌습니다. 이제는 한 단계 더 나아가, 모델이 어떤 작업 구조를 만들고, 어떤 순서로 문제를 풀고, 실패했을 때 어떻게 복구하는지가 중요해지고 있습니다.
즉, 앞으로의 코딩 AI 경쟁은 단순히 “모델 성능”만의 싸움이 아닐 가능성이 큽니다.
모델 자체의 능력, 도구 사용 방식, 작업 스캐폴드, 테스트와 검증 구조, 보상 해킹 방어, 로컬 실행 가능성.
그리고 실제 개발 워크플로우와 얼마나 자연스럽게 연결되는지.
이 모든 것이 함께 경쟁력이 될 가능성이 높습니다.
AI 코딩 도구를 쓸 때 중요한 것은 단순히 한 번 좋은 답을 받는 것이 아닙니다. 반복적으로 수정하고, 테스트하고, 실패를 복구하고, 프로젝트 전체 맥락을 유지하는 능력입니다.
Ornith-1.0이 정말 그 방향으로 의미 있는 성능을 보여줄 수 있다면, 앞으로 오픈소스 코딩 에이전트 생태계에서 꽤 중요한 모델로 다뤄질 수 있습니다.
아직 확인이 더 필요한 것은 실제 사용 환경에서의 재현성입니다. 로컬 실행 성능, 장기 작업 안정성, 실제 레포지토리에서의 문제 해결 능력, 보상 해킹 방어의 실효성은 앞으로 더 많은 사용자 테스트가 필요합니다.
개인적으로는 이 모델을 “당장 Claude Code나 Codex를 대체할 모델”이라기보다, 오픈소스 코딩 에이전트가 어디로 가고 있는지 보여주는 꽤 흥미로운 신호로 보는 편이 맞다고 생각합니다.