분석: 오픈AI가 코덱스 하네스를 열었다 — 하네스란 무엇이고 «오픈»은 어디까지인가

지난 2년간 AI 코딩 도구에서 흥미로운 엔지니어링은 모델 안에 있지 않았다. 모델을 감싼 층에 있었다 — 컨텍스트 창에 무엇을 넣을지 정하고, 언제 도구를 부를지 판단하고, 명령이 매달리면 어떻게 할지 결정하고, 언제 멈춰 사람에게 물을지 아는 그것. 진지한 팀은 모두 이것을 만들었다. 대부분 두 번 만들었다 — 첫 번째는 «오래 도는 작업»에서 살아남지 못했기 때문이다.

8월 20일 오픈AI 가 자기네 버전의 그 층을 Apache-2.0 으로 공개했다. 발표는 이것을 플랫폼 전략으로 규정했다 — 이제 외부 기업이 사용자를 범용 챗봇 창으로 보내는 대신 자사 소프트웨어 안에 에이전트를 심을 수 있다는 것이다. 개발자에게 더 쓸모 있는 질문은 더 좁다. 상자 안에 실제로 무엇이 들었고, 라이선스는 어디까지 덮는가.

하네스가 하는 일

보도에 나온 «모델이 엔진이면 하네스는 차체» 비유는 틀리지 않지만, 구체적인 일을 가린다. 벗겨 보면 하네스는 여섯 가지를 동시에 하고 있고, 그중 무엇도 모델이 스스로 하지 않는다.

• 일을 붙든다. 모델은 요청에 답한다. 하네스는 수십 번의 요청에 걸쳐 «목표»를 살려 두고 언제 그것이 달성됐는지 판단한다.
• 맥락을 관리한다. 긴 작업은 어떤 컨텍스트 창도 넘긴다. 무언가가 요약하고, 버리고, 다시 가져오고, 경계 너머로 추론을 보존해야 한다. 이걸 거칠게 하면 마흔 단계 전에 준 제약을 에이전트가 잊는다.
• 도구를 호출한다. 도구를 정의하고, 인자를 검증하고, 샌드박스 안에서 실행하고, 결과를 모델이 이어받을 형태로 되돌린다.
• 이벤트를 흘려보낸다. 6분 걸리는 작업은 끝났을 때가 아니라 «도는 동안» 읽혀야 한다.
• 중단할 수 있다. 도중에 깨끗이 멈추고 상태를 보존했다가 나중에 잇는 것 — 데모와 «사람이 켜 두고 자리를 뜨는 물건»의 차이가 여기다.
• 승인을 라우팅한다. 어떤 동작이 자동으로 진행되고 어떤 동작이 사람 앞에 멈추는지, 그 판단이 어떻게 기록되는지.

하네스 작업이 벤치마크 숫자를 실제로 움직이는 이유가 이 목록이다. 오픈AI 는 하네스 변경만으로 — 추론 유지와 컨텍스트 압축 — 모델의 ARC-AGI-3 점수가 13.3%에서 38.3%로 올랐고, 하네스 설계로 토큰 소비가 6분의 1이 됐다고 밝혔다. 자사 발표에 실린 자사 수치는 통상의 할인을 적용해 읽어야 하고, 벤치마크 자체도 좁다. 그래도 남길 만한 발견은 방향이다. 같은 가중치가 주변 기계 장치에 따라 실질적으로 다른 결과를 낸다, 그리고 남은 엔지니어링 지렛대가 바로 그 장치에 있다.

여기서 «오픈소스»가 덮는 범위

이번 공개는 진짜로 관대하다. 그런데도 «오픈»이라는 라벨은 계획에 영향을 주는 경계 하나를 가린다.

하네스에 붙은 Apache-2.0 은 포크·수정이 자유롭고, 그 수정을 비공개로 유지한 채 닫힌 상용 제품 — 화이트라벨 제품 포함 — 안에 넣어 출하할 수 있다는 뜻이다. 저작자 표시와 고지 의무는 따르되 카피레프트 방아쇠는 없다. AGPL 실행 층이었다면 네트워크로 서비스하는 순간 공개 의무가 발동하고, 그 한 가지만으로도 대부분의 화이트라벨 로드맵에서 탈락한다 — 이 차이가 실무적 차이다.

라이선스가 덮지 않는 것도 그만큼 분명하다. 가중치는 열리지 않았다 — 하네스는 열렸고 그것이 부르는 지능은 열리지 않았다. Apache-2.0 은 상표권을 주지 않으므로, 「코덱스로 만든 제품」과 「스스로를 코덱스라 부르는 제품」은 다른 문제다. 그리고 클라이언트에 붙은 관대한 라이선스는 그 클라이언트가 접속하는 «서비스»의 약관에 대해 아무 말도 하지 않는다. 오픈 라이선스와 오픈 웨이트의 구분이 구매 심사에서 실제로 일을 한다면, 심사 도중이 아니라 그 전에 라벨이 실제로 뜻하는 바를 읽어 두는 편이 낫다.

대부분의 팀이 가장 먼저 부딪힐 제약

하네스는 한 사업자에 용접돼 있지 않다. 커스텀 프로바이더 항목 하나면 호환 엔드포인트 어디든 — 경쟁사 API, 게이트웨이, 우리 하드웨어에서 도는 모델 — 가리킬 수 있다.

이 제약의 전략적 독법은 단순하다. 이식성은 «있고», 그 통로는 사업자가 통제하며 이미 한 번 바꾼 적 있는 와이어 형식을 지난다. 이것을 종속 방지 보험으로 여기는 쪽은 shim 을 «한 번 드는 비용»이 아니라 «유지보수 대상 구성요소»로 잡아야 한다.

비용

세 층이고, 그중 늘어나는 것은 하나뿐이다.

오픈AI 현행 라인의 공표 단가는 최상위 등급이 100만 입력 토큰당 약 5달러·출력 30달러 수준이고, 캐시 입력은 한 자릿수 배수만큼 싸며 중간·경량 등급은 그보다 한참 아래다. 다만 이 숫자는 계산의 절반이다. 에이전트 실행은 요청 하나가 아니라 수십 개이고, 각 요청이 누적된 맥락을 지고 간다 — 단가는 떨어지는데 청구서는 오르는 바로 그 패턴이다.

배포 예산을 잡는 쪽에는 두 가지 결론이 따른다. 첫째, 안정 프리픽스의 캐시 적중률이 청구서를 지배한다. 턴마다 프롬프트 윗부분을 재배치하는 하네스는 요청 하나 실패시키지 않으면서 비용을 조용히 몇 배로 만든다. 요금표에서 외삽하기 전에 «측정»해야 한다. 둘째, 좌석 경로는 넓어지는 게 아니라 좁아지고 있다 — 코덱스 좌석은 2026년 6월 24일부터 신규 비즈니스 워크스페이스에 추가되지 않는다. 지금 시작하는 팀에게 남은 현실적 통로는 API 키다.

제품에 심기 전에

하네스는 우리의 권한을 그대로 물려받는다. 그래서 점검표는 짧고, 대부분 모델에 관한 것이 아니다.

• 샌드박스 태세. read-only · workspace-write · full-access 는 폭발 반경이 실질적으로 다르다. 그 작업에 «실제로» 필요한 가장 좁은 것을 고른다.
• 승인 정책. 승인을 자동화하는 지점이 에이전트가 검토 가능성을 잃는 지점이다. 절대 자동이 되지 않을 동작 부류를 먼저 정한다.
• 프롬프트 인젝션. 에이전트가 읽는 모든 것에 에이전트를 겨눈 지시가 섞일 수 있다. 방어는 더 좋은 시스템 프롬프트가 아니라 «더 작은 권한 집합»이다.
• 감사 추적. 에이전트가 공유 저장소나 고객 데이터에 쓴다면, 무엇을 했고 어떤 사람이 허락했는지의 기록이 세션보다 오래 남아야 한다.
• 표시 의무. Apache-2.0 은 파생 제품에 고지 파일이 함께 따라가기를 요구한다 — 화이트라벨 제품도 포함이다.

어디에 착지하는가

깃허브·젯브레인스·시스코가 이미 코덱스를 자사 제품에 넣었고, 미국의 한 세무 서비스 기업은 신고 7,000건을 처리하며 준비 시간을 약 3분의 1 줄였다고 밝혔다. 이 사례들의 공통 패턴은 하나다 — 에이전트가 별도 챗봇 창이 아니라 사람들이 이미 쓰는 소프트웨어 안에 나타난다. 그게 실제 플랫폼 논거이고, 코딩에만 갇히지 않는다. 같은 실행 층이 보안 분류·고객지원·영업·마케팅 운영에도 그대로 쓰인다. 향후 1년의 흥미로운 도입이 터미널을 한 번도 열어 본 적 없는 부서에서 나올 가능성이 큰 이유다.

엔지니어링 팀에게 당장의 질문은 더 밋밋하다. 마감에 쫓겨 쓴 이 루프의 자체 버전이 스택 어딘가에 거의 확실히 있을 것이다. 그것이 계속 «우리 것»이어야 하는지, 이제 물어볼 만하다.