하네스에는 요금이 없습니다 : 값은 하네스가 하는 일에 붙습니다

마구(harness)는 말을 빠르게 만드는 장비가 아닙니다. 가슴걸이와 뱃대끈과 고삐로 이루어진 그 물건이 하는 일은 말이 이미 가진 힘을 수레의 축으로 옮기고, 그 힘이 어느 방향으로 갈지를 정하는 것이지요. 그래서 마구를 채운 사람은 말을 소유하지 않아도 말의 방향을 소유합니다.

소프트웨어에서도 같은 단어를 씁니다. 모델을 감싸서 실제로 일하게 만드는 바깥 껍데기를 하네스라고 부르는데요. 모델에 지침을 넣고, 툴을 쥐여 주고, 돌아온 대답으로 다음 호출을 만들고, 실패하면 다시 시키고, 대화가 길어지면 앞부분을 줄이는 그 루프입니다. 모델을 더 똑똑하게 만들지는 않습니다. 모델이 이미 가진 능력이 어디로 갈지를 정할 뿐이지요.

현지 시각 9월 10일, 오픈AI가 그 하네스를 API로 열었습니다.

Agents API 퍼블릭 베타입니다. 회사 설명은 간단합니다. Codex를 돌리는 것과 같은 하네스와 인프라를 그대로 개방한다는 것이고, 이제 그 하네스를 오픈AI가 호스팅하고 유지합니다. 개발자가 공급하는 것은 지침과 툴과 MCP 서버, 그리고 실행 환경을 무엇으로 할지 고르는 선택입니다. 오픈AI 디벨로퍼스는 이것을 아이디어에서 작동하는 에이전트까지 가는 가장 짧은 경로라고 소개했습니다.

구성은 네 조각입니다. 에이전트(모델·지침·툴·MCP 서버), 환경(파일을 읽고 명령을 실행하는 선택적 샌드박스), 세션(턴을 넘겨도 상태가 유지되는 지속 인스턴스), 그리고 그 사이를 오가는 이벤트와 아이템. 오픈AI가 맡는 쪽은 세션을 살려 두고, 오케스트레이션을 하고, 컨텍스트가 차면 압축하고, 실패하면 복구하는 일입니다. 상정하는 작업 길이는 분 단위나 시간 단위, 심지어 며칠이라고 적혀 있고요.

저 마지막 항목은 조금 더 따져 볼 필요가 있습니다. 며칠씩 도는 세션이 내 프로세스가 죽어도 살아 있으려면, 그 상태는 정의상 내 쪽에 있을 수 없습니다. 지속 세션이라는 말은 편의 기능의 이름이기도 하지만 저장 위치의 이전을 뜻하기도 하지요.

▸ 2년 동안 모두가 같은 루프를 다시 썼습니다

에이전트를 한 번이라도 붙여 본 팀에게는 이 목록이 낯설지 않을 것입니다. 세션 상태를 어디에 저장할지, 툴 호출이 타임아웃 나면 몇 번까지 다시 시킬지, 컨텍스트 윈도가 꽉 차기 전에 무엇을 버릴지, 프로세스가 죽었을 때 어디서부터 이어 붙일지. 지난 2년 동안 에이전트를 만든 팀은 대체로 이 네 가지를 각자 손으로 썼습니다. 그리고 꽤 많은 팀이 그것을 자기 차별화라고 불렀지요. 사내 프레임워크에 이름을 붙이고, 위키에 아키텍처 그림을 올리고요. (저도 그런 그림을 몇 장 봤습니다.)

솔직히 말하면 그건 차별화가 아니었습니다. 회사마다 같은 코드를 다시 쓰는 낭비였고, 그 낭비를 덜어 주는 물건이 나온 것은 진짜 이득입니다. 일을 서브에이전트로 쪼개 동시에 돌리는 것도, 툴 정의를 전부 컨텍스트에 밀어 넣지 않고 필요할 때만 불러오는 tool search 같은 것도 각자 만들기에는 지루하고 까다로운 일이었고요.

그리고 값이 붙어 있지 않습니다. 오픈AI의 공지 문장은 이렇습니다. "There are no additional fees for using the Agents API." 하네스 자체에는 별도 요금이 없다는 뜻이고, 개발자 문서는 청구되는 것을 세 가지로 적어 뒀습니다. 선택한 모델의 API 요율로 계산되는 모델 사용량, 오픈AI가 제공하는 유료 툴, 그리고 오픈AI가 호스팅하는 샌드박스의 컨테이너 사용량입니다.

▸ 공짜인 것은 이름이고, 값은 그 일에 붙습니다

그런데, 저 문장을 다시 읽어 보면 무엇이 공짜인지가 조금 이상합니다. 공짜인 것은 하네스라는 이름이고, 하네스가 하는 일은 공짜가 아닙니다.

압축(compaction)을 보겠습니다. 개발자 문서에 동작이 적혀 있는데요. 전체 컨텍스트 윈도를 보내면 새로 압축된 윈도를 돌려주고, 그 안에는 이전의 상태와 추론을 더 적은 토큰으로 이어 나르는 압축 아이템이 들어 있습니다. 방식은 두 가지입니다. 압축 엔드포인트를 직접 부르거나, 문턱값을 설정해 두고 렌더된 토큰 수가 그 값을 넘으면 서버가 알아서 실행하게 하거나.

중요한 것은 그다음입니다. 압축 호출의 응답에는 사용량 객체가 함께 돌아옵니다. API 레퍼런스가 그것을 압축 패스에 대한 토큰 회계라고 부르고, 입력 토큰과 출력 토큰, 추론 토큰과 캐시 토큰까지 항목을 나눠 적어 뒀습니다. 그리고 Agents API에 별도 요금이 없다는 말은 모델 사용량이 그 모델의 API 요율로 계산된다는 뜻이지요. 두 문장을 이으면 답이 나옵니다. 압축은 공짜로 처리되는 정리 작업이 아니라 토큰을 쓰는 추론 호출이고, 그 토큰은 제 청구서에 올라갑니다.

그러니까 구조가 이렇게 됩니다. 에이전트 비용에서 가장 크게 움직이는 변수는 한 번에 얼마나 긴 컨텍스트를 모델에 밀어 넣는가인데요. 그 컨텍스트에 무엇을 남기고 무엇을 버릴지 정하는 결정이 이제 내 코드 밖으로 나갔습니다. 문턱값 하나만 넘겨 주면 그 뒤는 자동이고요. 문서가 예제에서 쓰는 모델은 이달 초 공개된 GPT-6 Astra이고, 그 API 요율은 100만 토큰당 입력 10달러, 출력 50달러입니다. 자동으로 일어나는 호출이 그 요율로 계산된다는 뜻이지요.

물론 방향이 한쪽만은 아닙니다. 압축의 원래 목적이 바로 비용 절감이고, tool search도 컨텍스트를 줄이는 장치입니다. 잘 돌면 제가 손으로 만든 루프보다 싸게 돌 가능성이 큽니다. 오픈AI가 소개한 사례에는 건당 비용이 60% 줄었다는 고객도, 실패한 에이전트 응답이 86% 줄었다는 다른 고객도 있고요. 다만 고객명과 워크로드가 공개되지 않은 벤더 제시 수치이고 독립 검증도 없습니다.

▸ 그 기억은 제가 읽을 수 없는 형태입니다

값보다 더 오래 남을 문제는 그다음입니다.

압축된 윈도에 들어가는 그 아이템은 암호화되어 있습니다. 문서는 그것이 불투명하며 사람이 해석할 것을 의도하지 않았다고 적어 뒀습니다. 성능과 보안 양쪽에서 합리적인 설계입니다. 요약을 평문으로 남겨 두면 그것 자체가 유출 표면이 되고, 구조화된 내부 표현을 쓰는 편이 토큰도 덜 먹겠지요.

그런데 결과를 생각해 보면요. 며칠씩 도는 세션에서 에이전트가 무엇을 기억하고 있는지가 제가 열어 볼 수 없는 덩어리 안에 들어갑니다. 에이전트가 사흘째에 이상한 판단을 했을 때, 이틀째에 무엇이 버려졌는지를 확인할 방법이 제 쪽에는 없습니다. 사고 조사에서 가장 먼저 찾는 것이 그 시점에 시스템이 무엇을 알고 있었는지인데, 그 자리가 비게 되는 것이지요. 예전에 기록하는 손과 기록되는 손이 같으면 그 기록은 증거가 되지 못한다는 이야기를 다룬 적이 있는데요. 여기서는 손이 아니라 기록의 형식이 문제입니다.

▸ 자체 호스팅이 허용된 한 칸이 아무것도 옮겨 주지 않습니다

국내에서 이 API를 검토하는 팀에게는 더 실무적인 벽이 하나 더 있습니다.

네 조각 가운데 제 인프라에 둘 수 있는 것은 환경, 즉 샌드박스 하나입니다. 오픈AI 호스팅을 쓰지 않고 직접 돌릴 수 있고, Cloudflare·E2B·Modal·Vercel·Oracle을 포함해 제공자 아홉 곳이 이미 붙어 있습니다. 코드가 실행되고 파일이 놓이는 자리를 제 경계 안으로 가져올 수 있다는 뜻이니 규제 산업에서는 반가운 조건이지요.

그런데 문서에 이렇게 적혀 있습니다. 자체 호스팅 샌드박스를 고른다고 해서 Agents API가 ZDR(zero data retention) 대상이 되지는 않습니다. 그리고 퍼블릭 베타 기간에는 데이터 레지던시가 미국으로 한정됩니다.

이것이 왜 걸리는지는 비교해 보면 분명합니다. 오픈AI의 일반 API 플랫폼은 이미 한국에 저장 레지던시를 제공합니다. 유럽·영국·미국·캐나다·일본·싱가포르·인도·호주·UAE와 함께 한국이 그 목록에 들어 있고, ZDR도 적격 조직과 엔드포인트를 대상으로 제공됩니다. 국내 금융권이나 공공 쪽에서 오픈AI API 도입 심사를 통과시킨 팀이 근거로 삼았을 칸이 정확히 저 두 개일 텐데요. Agents API로 옮기려면 그 두 칸을 반납해야 합니다. 샌드박스를 제 데이터센터에 두는 것으로도 되돌려지지 않고요.

공정하게 말하면 오픈AI가 이것을 퍼블릭 베타 한정 제약이라고 명시했으니 풀릴 가능성이 큽니다. 그리고 강제된 이전도 아닙니다. 루프를 직접 소유하고 싶으면 오픈소스인 Agents SDK로 내 애플리케이션 안에서 돌리는 길이 있고, Responses API를 직접 부르면 턴 관리까지 전부 제 손에 남습니다. 다만 지금까지 그 길은 누구나 걷는 길이었고, 이제부터는 굳이 고르는 길이 됐습니다.

그래서 이번 발표가 묻는 것은 하네스를 쓸 것인가가 아닙니다. 쓰는 편이 대체로 낫습니다. 물어야 할 것은 마구를 채울 때 고삐가 어느 쪽 손에 남는지입니다. 컨텍스트에 무엇을 남길지 정하는 결정, 그 결정의 결과를 나중에 읽을 수 있는 권리, 그리고 데이터가 어느 나라에 놓이는지. 지금은 셋 다 넘어가는 조건이고, 그중 데이터가 놓이는 자리만 베타가 끝나면 돌아올 수도 있겠죠. 나머지 둘은 베타와 무관한 설계입니다. 무엇을 위탁하고 무엇을 내 쪽에 남길지 고민이 필요합니다.

---

*커버 이미지: 수레에 연결된 마구를 채운 말 — Unsplash, Alex Gorin*