Ornith-1.0, 오픈 코딩 모델의 자기개선 경쟁

공개 코딩 모델이 에이전트 런타임을 겨냥한다

Ornith-1.0 저장소는 "agentic coding"을 위한 자기개선 오픈소스 모델을 내세운다. 모델 크기는 9B Dense, 35B MoE, 397B MoE로 제시되어 있고, Gemma 4와 Qwen 3.5 기반 후학습 모델이라고 설명한다. MIT 라이선스, Hugging Face 배포, OpenAI 호환 serving 예제까지 포함한 점도 중요하다.

핵심은 단순한 코드 생성 모델이 아니라는 주장이다. Ornith는 RL로 해결 roll-out뿐 아니라 그 roll-out을 이끄는 scaffold까지 최적화한다고 설명한다. 코딩 에이전트에서 scaffold는 계획, 파일 탐색, 테스트 실행, 수정 순서 같은 작업 궤적이다. 모델이 한 번에 정답을 쓰는 시대에서 여러 단계를 어떻게 진행할지 배우는 시대로 이동하는 신호다.

숫자는 강하지만 읽는 법이 더 중요하다

README 기준 Ornith-1.0-397B는 SWE-bench Verified 82.4, SWE-bench Pro 62.2, Terminal-Bench 2.1의 Claude Code 설정 78.2를 보고한다. 35B 모델도 SWE-bench Verified 75.6, Terminal-Bench 2.1 64.2로 제시된다. SWE-bench와 Terminal-Bench 계열은 코딩 에이전트 평가에서 자주 인용되지만, 실제 팀의 코드베이스와 완전히 같지는 않다.

Hugging Face의 Ornith 모델 페이지와 vLLM 문서, SGLang 문서를 함께 보면 이 모델은 논문 발표보다 배포 가능성을 강조한다. 256K 컨텍스트, tool call parser, reasoning parser 같은 설정은 에이전트 런타임과 바로 연결된다.

자기개선의 진짜 의미는 데이터 루프다

자기개선이라는 말은 쉽게 과장된다. 그러나 코딩 영역에서는 비교적 구체적 의미가 있다. 모델이 문제를 풀고, 실패 로그를 남기고, 테스트 결과로 보상을 받고, 더 나은 탐색 전략을 학습한다. 이는 단일 프롬프트 튜닝보다 훨씬 운영적인 문제다.

Codex 에이전트 업무 경제성에서 보았듯 코딩 에이전트의 가치는 모델 가격보다 실패율, 재시도 횟수, 테스트 비용에 좌우된다. Ornith가 scaffold 학습을 강조하는 이유도 여기에 있다. 좋은 에이전트는 코드를 잘 쓰는 모델이 아니라 망설일 때 테스트를 돌리고, 변경 범위를 줄이고, 실패를 되돌릴 줄 아는 시스템이다.

오픈 웨이트 LLM 격차 5개월의 관점에서 보면 공개 모델은 폐쇄형 모델을 단순 추격하는 것이 아니라 배포와 커스터마이징에서 다른 강점을 찾고 있다. 사내 코드, 규제 산업, 온프레미스 개발 환경에서는 공개 모델의 제어 가능성이 큰 의미를 갖는다.

한국 개발조직의 도입 체크리스트

한국 기업이 Ornith를 바로 생산 코드 수정에 붙이는 것은 성급하다. 먼저 사내 리포지토리 20~50개에서 실패 유형을 기록해야 한다. 문서 탐색 실패인지, 테스트 환경 실패인지, 한국어 이슈와 코드 주석 이해 문제인지, 긴 컨텍스트 비용인지 구분해야 한다.

Workweave Router, 모델 선택을 인프라로 만든다에서 다룬 라우팅 전략도 필요하다. 쉬운 리팩터링은 작은 모델, 위험한 변경은 폐쇄형 강한 모델, 보안 민감 코드는 온프레미스 공개 모델처럼 분리해야 한다. Ornith 같은 모델은 "모든 것을 대체"하기보다 선택지 하나를 더하는 방식으로 들어오는 것이 현실적이다.

라이선스가 MIT라는 점은 긍정적이지만, 기반 모델과 데이터, 벤치마크 재현성은 별도로 검토해야 한다. 특히 고객 코드가 외부 모델 서버로 나가는지, reasoning trace를 저장하는지, tool call 로그에 개인정보가 남는지 확인해야 한다.

자주 묻는 질문

Q1: Ornith-1.0은 완전히 오픈소스인가요?

A: 저장소는 MIT 라이선스를 내세우고 여러 체크포인트를 공개한다. 다만 실제 사용 전 각 모델 카드와 기반 모델 조건을 확인해야 한다.

Q2: 9B 모델이면 노트북에서도 쓸 수 있나요?

A: GGUF 경로가 있어 로컬 실험 가능성은 있다. 하지만 긴 컨텍스트와 에이전트 작업은 메모리와 속도 제약을 크게 받는다.

Q3: 벤치마크 점수만 보고 도입해도 되나요?

A: 아니다. 사내 코드베이스, 테스트 환경, 보안 정책에서 별도 평가해야 한다.

Q4: 폐쇄형 모델과 경쟁할 수 있나요?

A: 일부 벤치마크에서는 강한 수치를 보인다. 그러나 제품 도입에서는 안정성, latency, 운영비, 지원 생태계까지 봐야 한다.

Q5: 한국어 코딩 업무에도 유리한가요?

A: 코드 자체는 영어 중심이지만 요구사항, 이슈, 문서가 한국어인 경우가 많다. 한국어 프롬프트 평가셋을 따로 만들어야 한다.