Automata V.30 | 🤨 누가 만들었는지 감도 안 잡히는 정체불명 AI 'Ox Alpha'

🕵️ 익명의 AI 모델 'Ox Alpha', Claude Fable 5를 앞선다는 주장으로 화제… 정체는 미스터리 

출처: https://oxalpha.com/

혜성같이 나타난 모델

2026년 8월 20일, 'stealth/ox-alpha'라는 ID를 달고 OpenRouter와 OpenCode에 정체불명의 AI 모델이 등장했어요. 개발사는 'stealth'(익명 제공자)로만 표기됐고, 회사명도 보도자료도 없었죠. AI 업계에서는 이런 방식을 '스텔스(stealth) 릴리스'라고 불러요. 실제 트래픽으로 성능을 검증하면서 사용자 반응을 모으고, 공식 출시 전 인지도를 올리는 전략이에요.

사양만 보면 눈길을 끌어요. 컨텍스트 윈도우(한 번에 처리할 수 있는 텍스트 분량)가 약 100만 토큰(1,048,576)에 달하고, 텍스트·이미지·비디오 입력을 모두 지원해요. 스텔스 모델 중 비디오 입력을 지원한 건 처음이에요. 미리보기 기간에는 무료로 사용할 수 있었고, 하루 100조 토큰 처리 용량을 주장했어요. Stripe CEO 패트릭 콜리슨이 X에 "매우 인상적"이라고 언급했고, 출시 48시간 만에 OpenRouter 글로벌 리더보드 9위까지 올랐어요.

놀라운 벤치마크 숫자, 액면 그대로 믿으면 안 돼요

커뮤니티에서 가장 빠르게 퍼진 건 벤치마크 수치였어요. 개발자 Ben Davis의 비공식 테스트에서 Ox Alpha가 DeepSWE 코딩 벤치마크 10개 과제 중 80%를 맞혀, Claude Fable 5(65%)와 GPT-5.6 Sol(52%)을 앞섰다는 주장이었죠.

그런데 이 수치에는 중요한 맥락이 있어요. DeepSWE 벤치마크는 원래 91개 오픈소스 저장소에서 뽑은 113개 과제로 구성돼요. 고작 10개 과제만으로는 어떤 모델이든 우연히 높은 점수를 받을 수 있거든요. 이후 커뮤니티가 전체 과제를 직접 돌린 결과, Ox Alpha는 약 62.8%를 기록했어요 (2개 과제는 시간 초과). 공식 리더보드엔 아직 등재되지 않았지만, 등재된 모델들과 비교하면 Claude Opus 5(74%), GPT-5.6 Sol(73%), Claude Fable 5(70%)보다 낮은 수준이에요.

같은 모델이라도 평가 과제 수가 10개에서 113개로 늘어나자 Ox Alpha의 순위가 1위에서 하위권으로 급락했어요.

실제 사용자 반응도 엇갈려요. 코딩 에이전트들이 출시 직후 180억 토큰 이상을 처리하며 활발하게 쓰였지만, "다른 모델이 이미 해결한 문제를 Ox Alpha는 풀지 못했다", "몇 분 동안 추론만 하고 아무것도 하지 않는다" 같은 불만도 나왔어요.

너 정체가 뭐야? 커뮤니티의 탐정 놀이

OpenRouter 역사상 6개월 내 다섯 번째 익명 스텔스 모델이에요. 앞선 네 개(GLM-5, MiMo-V2-Pro, Ling-2.6-flash, LongCat-2.0)는 모두 중국 AI 연구소 출신으로 밝혀졌어요.

이번에도 커뮤니티는 코드명을 분석했어요. 주목받는 단서는 다음과 같아요.

이를 종합하면, Zhipu AI(Z.ai)의 GLM-5.3 다중모달 변형 모델일 가능성이 가장 높다는 게 커뮤니티의 결론이에요. 단, 공개된 GLM-5.3은 텍스트 전용인데 Ox Alpha는 이미지·비디오를 지원하니, 미공개 변형 버전이라는 가정이 필요해요. 공식으로 확인된 사실은 아직 없어요.

스텔스 릴리스, 왜 계속 나올까요?

익명 출시는 AI 연구소 입장에서 꽤 합리적인 전략이에요. 브랜드 이미지 없이 순수하게 성능만으로 평가받을 수 있고, 실제 사용자 트래픽으로 인프라를 테스트할 수 있어요. 무엇보다 "정체 불명의 모델이 상위권을 위협한다"는 스토리는 광고비 없이도 엄청난 관심을 끌어요.

다만 구독자님이 무료 기간에 써보려 한다면 주의할 점이 있어요. OpenRouter 정책상 익명 제공자가 입력 내용을 저장할 수 있어요. 회사 이름조차 밝히지 않은 곳에 민감한 코드나 개인정보를 붙여넣는 건 피하는 게 좋아요.

🛡️ 코딩 에이전트를 지켜보는 눈: Uber의 ADR 시스템

요즘 많은 회사에서 개발자들이 Claude Code, Cursor, Codex CLI 같은 AI 코딩 에이전트를 업무에 쓰고 있어요. 그런데 이 에이전트들이 회사 노트북에서 돌아가기 시작하면 보안팀은 골치가 아파집니다. 기존 보안 도구(EDR, 엔드포인트 탐지 및 대응 시스템)는 "어떤 파일이 만들어졌고 어떤 프로그램이 실행됐는지"는 알려주지만, "에이전트가 왜 그 파일을 썼는지", "어떤 명령을 받아서 움직였는지"는 전혀 기록하지 않거든요.

이게 왜 문제냐고요? 예를 들어 프롬프트 인젝션(Prompt Injection) 공격을 생각해 보세요. 악성 텍스트가 에이전트에게 "이 파일을 외부로 보내라"고 몰래 지시하는 공격인데, 결과만 보면 정상 작업과 구분이 안 돼요. 파일 한 줄 쓴 것과 회사 비밀번호를 유출한 것이 로그 상으로 똑같이 생겼거든요.

기록부터 남기자: ADR Sensor

Uber는 이 간극을 메우기 위해 ADR(Agentic AI Detection and Response) 시스템을 개발하고 MLSys 2026에 논문으로 발표했어요. ADR의 첫 번째 핵심은 ADR Sensor입니다. 에이전트마다 로그를 저장하는 방식이 다 달라요. Claude Code는 JSONL 파일, Cursor는 SQLite 데이터베이스, Cline은 JSON 파일 형식으로 로그를 남기죠. ADR Sensor는 이 제각각인 로그를 읽어 AgentEvent라는 공통 형식으로 통일해줍니다. Claude Code, Cursor, Cline, Claude Desktop, Codex CLI, Warp, opencode — 현재 실무에서 많이 쓰이는 에이전트 7종을 지원해요.

설치도 간단합니다:

pip install adr-sensor

의심 세션만 추려내는 2단 탐지

로그를 모으는 것만으론 부족하죠. 하루 1만 건 넘는 에이전트 세션을 전부 AI에게 분석시키면 비용이 감당이 안 돼요. ADR Detector는 이 문제를 2단계 구조로 풉니다.

ADR 파이프라인은 7종 로그를 수집·정규화한 뒤, 1단계(gpt-4o)로 의심 세션을 빠르게 걸러내고 2단계(claude-sonnet)에서 정책·코드·위협 인텔을 참조해 최종 경보를 발령해요.

ADR 파이프라인은 7종 로그를 수집·정규화한 뒤, 1단계(gpt-4o)로 의심 세션을 빠르게 걸러내고 2단계(claude-sonnet)에서 정책·코드·위협 인텔을 참조해 최종 경보를 발령해요.

마치 공항 보안처럼요. 1차 검색대(X선 스캐너)에서 빠르게 훑고, 수상한 것만 2차 정밀 검색을 하는 방식이에요.

이 구조는 실제 보안 관제 센터(SOC)에서 사람들이 일하는 방식 그대로예요. 먼저 넓게 훑고 수상한 것만 깊게 들여다보는 거죠.

10개월 프로덕션, 실제로 뭘 잡았나

ADR은 Uber 사내에서 이미 10개월 넘게 실제로 운영되고 있어요. 7,200대 이상의 업무용 맥북에 배포돼 하루 1만 건 이상의 에이전트 세션을 처리했는데, 가장 많이 발견된 문제는 자격 증명(비밀번호·API 키 등) 노출이었습니다 — 26개 분류에 걸쳐 수백 건이 회사 밖으로 무심코 공유된 상태였어요. 이 결과를 바탕으로 Uber는 실행 전 차단 기능도 추가했고, 수십만 건 세션에서 유니크 자격 증명 206개를 정밀도 97.2%로 잡아냈어요.

벤치마크 성능도 주목할 만해요. ADR-Bench 302개 과제 기준으로 ADR은 오탐(정상인데 악성으로 판단하는 것) 0건을 기록하면서 공격 탐지율 67%를 달성했어요. 비교 대상 세 도구(ALRPHFS, GuardAgent, LlamaFirewall)가 30~40건씩 오탐을 낸 것과 대조적이죠. 기업 환경에서는 오탐 한 건마다 사고 대응 비용이 따라붙기 때문에, 정밀도를 먼저 챙기는 이 설계 선택이 실무적으로 중요합니다.

지금 바로 쓸 수 있을까?

ADR 코드는 Apache-2.0 오픈소스로 공개되어 있어요. 단, 알아둘 점이 있어요.

사내에 코딩 에이전트가 여러 종류 퍼져 있고 "누가 무엇을 시켰는지"부터 기록하고 싶다면, ADR Sensor 하나만으로도 충분히 가치 있는 출발점이에요. 에이전트 보안이 더 이상 먼 미래 이야기가 아니라는 것을, Uber의 10개월 운영 결과가 말해주고 있습니다.

🤖 Sol Advisor: "이 작업, 혼자 할까 나눌까?" 먼저 선언하는 Codex 오케스트레이션 플러그인

코딩 에이전트에 서브에이전트(보조 에이전트)를 붙이는 방식이 점점 일반화되면서, 작업이 들어오면 일단 여러 조각으로 나눠 분배하는 구성이 기본값처럼 자리 잡았어요. 그런데 나누는 것 자체에도 비용이 붙습니다. 명세를 써서 넘기고, 결과를 받아 읽고, 그게 맞는지 다시 확인하는 왕복이 생기거든요. 처음부터 한 세션 안에서 끝낼 수 있는 작업이었다면 그 왕복은 순수한 낭비예요. 반대로, 위험한 변경이었다면 나눠 준 것만으로는 부족하고 독립적인 검토가 따로 필요하죠.

Sol Advisor는 이 문제를 정면으로 다루는 OpenAI Codex 전용 플러그인이에요. 작업 도구를 처음 호출하기 전에, 반드시 "어떤 경로로 진행할지"와 "그 이유"를 먼저 선언하게 만들어요. 판단을 사람의 감에 맡기는 대신, 매 작업마다 기록으로 남기는 거예요.

기본값은 "혼자"

Sol Advisor의 기본 경로는 solo, 즉 혼자 처리입니다. 보조 에이전트는 어디까지나 예외예요. 이 점이 기존 방식과 다른 핵심이에요. Awesome Codex Subagents처럼 역할별 서브에이전트를 잔뜩 갖춰두고 필요할 때 고르는 방식, 또는 Claude Code 동적 워크플로우처럼 작업마다 병렬 구성을 새로 짜는 방식과는 방향이 반대입니다. Sol Advisor는 선택지를 늘리는 대신, 위임 자체를 예외로 두고 기본값을 뒤집었어요.

작업 도구 첫 호출 전에 아래 형태의 선언이 한 줄 출력됩니다:

SELECTIVE ROUTE
mode: solo | delegate | audit | full
risk: <이 작업에 한정된 판단 근거>

이 선언보다 앞선 도구 호출은 허용되지 않아요. 나중에 어떤 경로로 진행했고 이유가 무엇이었는지를 기록에서 되짚을 수 있게 하려는 설계예요.

네 가지 경로, 상황에 따라 선택

Sol Advisor는 작업 위험도가 높아질수록 solo → delegate → audit → full 순서로 감독 단계를 추가하며, 단계 하향은 허용되지 않아요.

Sol Advisor는 작업 위험도가 높아질수록 solo → delegate → audit → full 순서로 감독 단계를 추가하며, 단계 하향은 허용되지 않아요.

각 경로는 다음과 같이 정리돼 있어요:

여기서 Sol, Terra, Luna는 OpenAI가 GPT-5.6과 함께 공개한 모델 이름이에요. Sol Advisor는 이 셋에 역할을 고정해 뒀습니다. Luna(gpt-5.6-luna)는 최대 추론 강도로 범위가 정해진 구현을, Terra(gpt-5.6-terra)는 높은 추론 강도로 판단이 무거운 작업을, Sol 검토 레인(gpt-5.6-sol)은 읽기 전용으로 파일을 건드리지 않고 검토만 담당해요.

경로 변경에도 규칙이 있어요. 진행 중에 새로운 위험을 발견하면 더 무거운 경로로 올릴 수 있지만, 조용히 낮추는 건 금지되고 올릴 때는 반드시 근거를 기록해야 합니다.

설계와 판정은 항상 주 에이전트 몫

보조 에이전트를 쓰더라도, 아키텍처 결정·경로 선택·명세 작성·변경분 검증·최종 수용은 모두 주 세션(Sol)에 남습니다. 보조 에이전트가 보내온 결과는 "주장"으로 취급하고, 주 에이전트가 변경된 파일 전체를 직접 확인하고 검사를 재실행해요. 검토 결과도 ship(출시), fix-first(먼저 수정), rethink(재검토) 세 가지 중 하나로만 돌아오고, 수정이 일어나면 이전 검토는 무효가 돼 새 검토자를 다시 세워야 합니다.

Codex에 직접 붙이는 방법

Sol Advisor는 npm이나 pip이 아니라 Codex CLI 자체의 plugin 서브커맨드로 설치합니다. 먼저 사전 조건을 확인하세요: 플러그인이 활성화된 최신 Codex CLI(또는 ChatGPT 데스크톱 앱), 주 세션을 GPT-5.6 Sol / High 추론강도로 돌릴 수 있는 환경, 네이티브 커스텀 에이전트 지원, 그리고 jq가 필요해요. Luna나 Terra 접근 권한은 위임 경로(delegate·full)를 실제로 쓸 때만 필요합니다.

설치는 세 단계예요.

# 1. 플러그인 마켓플레이스에 등록
codex plugin marketplace add DannyMac180/sol-advisor --ref main

# 2. 플러그인 추가
codex plugin add sol-advisor@sol-advisor

# 3. 역할(agent) 파일 설치 — 저장소가 제공하는 설치 스크립트 실행
plugin_dir="$(codex plugin list --json | jq -r '.installed[] | select(.pluginId == "sol-advisor@sol-advisor") | .source.path')" \
  && test -n "$plugin_dir" && test "$plugin_dir" != null && test -d "$plugin_dir" \
  && test -f "$plugin_dir/scripts/install-agents.sh" \
  && sh "$plugin_dir/scripts/install-agents.sh"

이 설치 스크립트는 Sol·Luna·Terra 세 역할 파일을 설치한 뒤 정확히 일치하는지 검증해요. 수정됐거나 안전하지 않거나 심링크된 파일은 건드리지 않는 fail-closed 방식이고, Codex 설정 파일(config.toml 등)은 전혀 편집하지 않습니다. 설치 후에는 네이티브 역할이 인식되도록 반드시 새 Codex task를 새로 시작해야 해요.

적용은 새 task에서 원하는 작업을 sol-advisor과 함께 호출하며 시작하면 됩니다.

$sol-advisor:orchestration을 사용하여 [원하는 기능]을 구축하고 검증하세요. 태스크 도구를 사용하기 전에 선택적 경로(selective route)를 먼저 선언하세요.

업데이트할 때는 codex plugin marketplace upgrade sol-advisor 실행 후 codex plugin add sol-advisor@sol-advisor와 설치 스크립트를 다시 돌리면 돼요. 로컬에서 포크해 테스트하고 싶다면 저장소 경로로 이동해 codex plugin marketplace add /absolute/path/to/sol-advisor로 로컬 경로를 그대로 등록할 수도 있습니다.

이런 분께 맞아요

Codex를 쓰면서 서브에이전트를 언제 붙일지 매번 감으로 결정해왔다면, Sol Advisor는 그 결정을 명시적인 기록으로 바꿔줘요. 특히 위험한 변경에 자동으로 독립 검토(audit 경로)를 붙일 수 있다는 점은 실무에서 체감 차이가 큽니다. 사람이 기억해서 요청하지 않아도 되니까요.

다만, Codex와 주 세션 모델이 Sol(gpt-5.6-sol) 고강도 추론으로 고정돼 있어야 동작합니다. Codex를 쓰지 않거나 해당 환경을 갖추기 어렵다면 이 플러그인은 적용되지 않아요. 또한 경로가 네 가지로 고정돼 있어서, 작업마다 직접 오케스트레이션 구조를 설계하고 싶은 분들에게는 제약으로 느껴질 수 있습니다. Sol Advisor는 MIT 라이선스로 공개돼 있어요.