Harness-as-a-Service: Building with the Agents API

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Agents API는 Codex 하네스를 관리형 서비스로 제공해 개발자가 에이전트 운영 인프라보다 도구·업무 규칙·제품 구현에 집중하도록 한다.

📌 핵심 요점

1. 모델이 수시간에서 수일 동안 작업하게 되면서, 모델 호출뿐 아니라 실행 환경 연결·진행 상황 표시·상태 복구를 담당하는 하네스가 중요해졌다.
2. Agents API는 Codex 하네스를 기반으로 한다. 개발자는 도구·데이터·지침·실행 환경을 정하고, OpenAI가 하네스와 주변 서비스를 운영한다.
3. 하네스와 실행 환경을 분리해 자체 샌드박스와 OpenAI 제공 샌드박스를 선택할 수 있다. 발표에서는 OpenAI 호스팅 환경의 GUI를 사용하는 computer use도 소개했다.
4. 장기 실행을 지원하려면 턴 단위 활동 정보, 컨텍스트 압축, 세션 라우팅, 장애 이후 상태 복구가 필요하다. 특히 실행 결과를 받지 못했다고 명령을 무조건 재실행해서는 안 된다.
5. 항공편 재예약 데모는 병렬 세션, 스킬, 도구, 두 하위 에이전트의 검사, JSON·Python 산출물, 사람의 최종 승인을 결합해 업무 자동화의 구체적인 형태를 보여준다.

🧩 배경과 문제 정의

발표는 에이전트가 장애 조사, 지원 티켓 처리, 재무 대사처럼 여러 단계가 필요한 업무를 수행하기 시작했다는 관찰에서 출발한다. 모델의 작업 능력이 커질수록 주변 소프트웨어도 단순한 추론 요청 처리에서 장시간 실행을 관리하는 구조로 바뀌어야 한다는 문제의식이다.

개발자들은 사용할 도구와 데이터, 필요한 업무 흐름을 알고 있어도 샌드박스 연결, 비밀정보 관리, 활동 표시, 상태 보존까지 직접 운영하고 싶어 하지는 않았다. 이에 대한 해법으로 제시된 Agents API는 Codex 하네스를 관리형 서비스로 제공하면서 실행 환경과 업무 설정은 개발자가 선택하게 한다.

발표가 다루는 핵심 과제는 세 가지다. 클라우드 하네스를 별도의 실행 환경과 안전하게 연결하는 것, 미리 경로를 알 수 없는 에이전트의 활동을 제품 화면에 드러내는 것, 장시간 작업을 배포와 장애 이후에도 이어가는 것이다. 항공편 취소 이후 재예약 데모는 이 기능들을 하나의 업무 흐름으로 묶어 보여준다.

🕒 시간순 섹션별 상세정리

1. 모델의 발전이 하네스의 역할을 바꾸다

• 개발자 경험 팀의 Charlie와 API 팀의 Steve는 에이전트가 장애 조사·고객 지원·재무 업무를 수행하고, OpenAI 내부에서도 여러 부서가 이를 활용한다고 보여준다. [00:55]
• Astra와 GPT 6.1 Sol이 더 큰 작업을 처음부터 끝까지 수행할 수 있게 되면서, 주변 소프트웨어도 추론 엔드포인트에서 서비스형 하네스로 확장됐다고 보여준다. [01:25]
• 이번 발표의 목표는 하네스 구축 과정에서 얻은 교훈과 Agents API를 통해 만들 수 있는 제품을 보여주는 것이다. [01:37]

2. 기존 API와 Agents API의 계층 관계

• 이전의 호스팅 워크플로와 달리, 발전한 모델은 수십 개 도구를 수시간 또는 수일 동안 활용할 수 있어 더 유연한 기반이 필요해졌다고 보여준다. [02:11]
• 2025년 출시한 Responses API는 텍스트·이미지·추론 등 다양한 콘텐츠를 주고받는 기반으로 소개되며, Codex와 ChatGPT work 같은 제품을 지원했다고 드러낸다. [02:40]
• Responses API가 기반 인터페이스라면 Codex는 작업 수행 능력을 제공하고, Agents API는 하네스를 대규모로 직접 운영하는 부담을 줄이는 계층으로 드러난다. [03:18]

3. 개발자가 원한 것은 설정의 통제와 운영의 위임

• 2025년의 Agents SDK는 개발자가 직접 제어하는 로컬 하네스 구축을 도왔지만, 실제 상담에서는 도구 선택·샌드박스 배치·비밀정보 관리에 관한 질문이 반복됐다. [04:02]
• 도구·데이터·실행 환경에 대한 선호가 있어도 하네스 전체를 운영하고 싶은 것은 아니라는 점이 관리형 서비스의 출발점이다. [04:32]
• 개발자가 도구·데이터·지침·환경을 정의하면 OpenAI가 Codex 기반 하네스와 주변 서비스를 운영하고, 하네스 개선도 제공한다는 역할 분담을 보여준다. [04:59]

4. 클라우드 하네스가 해결해야 할 세 가지 문제

• 로컬 컴퓨터를 전제로 만든 하네스를 다른 실행 환경과 연결하고, 활동을 관찰할 수 있게 하며, 배포나 서버 장애에도 장시간 상태를 유지해야 한다. [05:55]
• 이를 위해 하네스와 실제 명령이 실행되는 환경을 분리하고, 클라우드에서 임의의 환경과 통신할 수 있어야 한다고 보여준다. [06:29]
• 파일 목록 조회 같은 명령도 올바른 세션의 컴퓨터로 전달하고 결과를 회수해야 하며, 여러 세션의 명령과 결과를 분리해야 한다. [06:57]

5. 샌드박스 선택과 computer use 확장

• 개발자는 자체 샌드박스를 연결하거나 OpenAI가 제공하는 샌드박스를 사용할 수 있으며, 두 방식 모두 터미널을 활용한 작업을 지원한다고 보여준다. [07:10]
• 새 기능으로 API를 통한 computer use를 발표하며, Astra가 OpenAI 호스팅 환경의 GUI를 사용할 수 있다고 보여준다. [07:24]

6. 원시 로그를 넘어 턴 단위 작업을 보여주기

• 에이전트는 입력과 도구 결과에 따라 파일을 열거나 접근법을 바꾸고 다른 에이전트에 일을 맡길 수 있어, 실행 경로를 미리 예측하기 어렵다. 사용자는 현재 작업과 개입 필요성을 알아야 한다. [08:03]
• 내부 팀은 여러 차례의 사용자 요청과 에이전트 응답을 턴별로 시각화하려 했지만, 원래 API는 그 관계를 쉽게 제공하지 않았다. [08:45]
• API에 턴 정보를 추가해 개발자가 대화 관계를 처음부터 복원하지 않고도 작업을 표시할 수 있게 했다. 이런 설계가 실제로 위임할 수 있는 운영 범위를 결정한다고 보여준다. [09:13]

7. 컨텍스트 한계와 장애를 넘는 장기 실행

• 작업 이력이 컨텍스트 창을 넘으면 compaction으로 유용한 정보를 이어가도록 한다. 이는 장기 실행 개발자가 직접 처리해야 했던 이력 관리 부담을 줄이는 기능이다. [09:43]
• 장시간 세션에는 사용자 지시와 외부 도구 결과를 올바르게 라우팅해야 한다. 모델 추론·저장소·도구 서비스 등 의존 시스템의 신뢰성도 함께 고려해야 한다고 보여준다. [10:35]
• 장애 이후에는 이미 수행한 작업을 반복하지 않도록 상태를 정밀하게 복원해야 한다. 파일 수정 요청 뒤 연결이 끊겼다면 결과 미수신만으로 실행 여부를 알 수 없으므로, 실행 환경의 상태와 하네스 기록을 함께 고려해야 한다. [11:35]

8. 항공편 취소 이후 재예약 데모 시작

• 샌프란시스코에서 시카고로 향하는 AL204편 취소를 가정한다. 특정 공항에 도착해야 하는 승객과 네 명이 함께 이동해야 하는 가족처럼 까다로운 사례를 처리 대상으로 삼는다. [12:24]
• 두 건의 재예약을 별도 Agents API 세션으로 시작하고 활동 화면에서 진행을 확인한다. 세션은 API의 기본 구성 단위이며 JavaScript 생성 예제를 보여준다. [12:53]
• 데모는 OpenAI 호스팅 샌드박스를 선택하고 네트워크 접근을 폭넓게 제한한다. 이벤트를 스트리밍해 화면을 실시간으로 갱신하도록 설정한다. [13:13]

9. 스킬·도구·하위 에이전트로 업무 규칙 구성

• 재예약 절차를 담은 로컬 스킬을 작업 공간에 넣고 capability directories로 공유한다. 같은 설정에서 플러그인과 MCP 서버 경로도 지정할 수 있다고 보여준다. [13:44]
• 항공편 재고 검색 도구로 좌석을 조회하고 임시 확보할 수 있지만, 결과는 참고용이며 최종 재예약 확정에는 사람이 관여하도록 한다. [14:06]
• 좌석과 도착 조건 검사를 두 하위 에이전트에 맡기고 둘의 결과를 기다린 뒤 제안하도록 설정한다. 동시 실행 수를 늘리면 토큰 사용량도 증가할 수 있다고 덧붙인다. [14:38]

10. 산출물과 제약조건을 확인한 뒤 사람이 승인

• 최종 제안 JSON, 비교한 대안 JSON, 제약조건을 결정론적으로 검사할 Python 스크립트를 요청한다. 첫 사례에서는 O'Hare 도착 조건에 맞춘 추천과 근거를 확인하고, 임시 확보 상태의 예약을 사람이 승인한다. [15:42]
• 네 명의 가족 사례에서는 좌석이 한 개뿐인 AL314와 네 좌석은 있지만 함께 앉는 것을 보장하지 못하는 AL744를 제외했다. 제안·비교 JSON과 검증용 Python 파일도 확인한다. [16:42]
• 두 번째 예약도 사람이 승인한다. 발표는 취소편에서 발생한 다수 사례를 병렬 처리하면서 추천 이유를 확인하고 최종 결정권을 유지할 수 있다는 점을 강조한다. [17:02]

11. 제품 개발의 초점과 고객 활용 사례

• 비슷한 제품을 Responses API로도 구현할 수 있지만, Agents API를 사용하면 운영 인프라보다 애플리케이션·재예약 규칙·승인 시점에 집중하고 작성·테스트·유지할 코드를 줄일 수 있다고 보여준다. [17:35]
• Notion의 비동기 업무 위임, Rakuten의 장기 실행과 후속 지시, Bain의 고객 연구 기반 가상 포커스 그룹을 보여준다. Bain 사례에서도 사람이 결과를 점검한다고 덧붙인다. [18:20]
• AWS 생태계를 선호하는 개발자를 위해 Agents API의 핵심을 AWS에 통합한 OpenAI 기반 Bedrock managed agents 경로도 보여준다. [18:38]

12. 병렬화 가능한 업무의 범위를 넓히자는 제안

• 발표자는 수백에서 수만 개 에이전트를 활용할 수 있다면 어떤 일을 할지 질문하며, 마이크로서비스 보안 조사·대규모 소프트웨어 프로젝트·여러 연구 접근의 동시 탐색을 예로 든다. [19:13]
• Codex 하네스를 API로 제공하는 의미를 병렬화 가능한 업무의 범위를 크게 넓히는 데서 찾으며 발표를 마무리한다. [19:29]

🧾 결론

• 발표의 핵심은 모델 접근을 제공하는 API에서 에이전트 실행과 운영을 맡는 서비스로 제공 범위를 넓히는 데 있다.
• 실행 환경과 업무 규칙을 직접 선택하는 것과 하네스 전체를 직접 운영하는 것은 별개의 요구다. Agents API는 이 둘을 분리한다.
• 업무 자동화의 완성도는 추천 결과뿐 아니라 진행 상황의 가시성, 제약조건 검사, 장애 복구, 승인 절차에 달려 있다.
• 관리형 하네스가 제공하는 운영 기능을 활용하면 개발자는 애플리케이션과 업무별 판단 기준에 더 많은 시간을 배분할 수 있다는 것이 발표의 주장이다.

📈 투자·시사 포인트

• 플랫폼 관점에서는 모델 추론에 더해 하네스 운영까지 서비스 범위가 확장된다. 평가할 대상도 모델 성능과 함께 실행 안정성·관측 가능성·환경 연결 능력으로 넓어진다.
• 기업 도입 관점에서는 인프라 구축 부담을 줄이는 대신 업무 규칙과 승인 경계를 명확하게 설계하는 역량이 중요해진다. 항공편 데모는 이 역할 분담을 보여준다.
• 병렬 에이전트는 처리 범위를 확대할 수 있지만, 발표는 하위 에이전트 동시 실행 수가 늘면 토큰 사용량도 증가할 수 있다고 설명한다. 처리 속도와 사용량을 함께 평가해야 한다.
• Notion·Rakuten·Bain 및 AWS 연계 사례는 활용 범위의 단서다. 다만 매출·수익성·도입 효과를 판단할 정량 자료는 제시되지 않아 투자 성과로 연결해 해석하기에는 근거가 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 가격, 사용량 제한, 동시 세션 한도, 지역별 제공 범위, 정식 서비스 조건은 이 영상에서 설명하지 않는다.
• 발표에 등장하는 99.9% 신뢰성 논의는 분산 시스템 설계의 요구사항을 설명하는 맥락이다. 실제 측정 결과나 계약상 SLA를 제시한 것으로 해석해서는 안 된다.
• 연결이 끊긴 뒤 실행 여부를 확인하고 중복 동작을 피해야 한다는 문제는 설명하지만, 이를 처리하는 구체적인 프로토콜과 보장 범위는 공개하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자동화할 업무 하나를 골라 입력 데이터, 허용 도구, 필수 제약조건, 완료 기준을 명시한다.
• 자체 샌드박스와 제공 샌드박스 중 필요한 환경을 정하고, 네트워크 접근과 비밀정보 관리 요구사항을 확인한다.
• 턴과 이벤트 스트림을 활용해 사용자가 작업 진행과 개입 필요성을 파악할 수 있는 화면을 설계한다.
• 예약 확정처럼 외부 상태를 바꾸는 동작에는 승인 단계를 두고, 연결 단절 시 실제 실행 여부를 확인하는 절차를 점검한다.

❓ 열린 질문

• 관리형 하네스에 맡길 수 있는 운영 책임과 개발자가 직접 처리해야 하는 책임의 경계는 어디까지인가?
• 컨텍스트 압축 이후에도 업무상 중요한 제약조건과 판단 근거가 유지되는지 어떻게 검증할 것인가?
• 실행 환경의 실제 상태와 하네스 기록이 어긋났을 때 어떤 복구 절차와 중복 실행 방지 보장이 제공되는가?