김경훈 대표의 환영사. 9월 DevDay의 발표를 한 화면에 모은 슬라이드다.
내가 들은 이번 행사의 메시지는 하네스를 직접 엔지니어링하기보다 OpenAI가 운영하는 하네스 위에서 서비스를 만드는 데 집중하라는 것이었다. 10월 22일 서울 라움 아트센터에서 열린 OpenAI DevDay Exchange에 다녀와서 내린 소감이다. AI를 주제로 한 행사에 직접 가 본 것은 이번이 처음이었다. 내용은 대부분 9월에 이미 공개된 것이었지만, 네 세션을 듣는 동안 하네스를 빌려 쓰는 빌더와 회사의 하네스를 만드는 소프트웨어 엔지니어의 자리가 갈라지고 있다는 생각이 계속 들었다. 그 경계는 결국 하네스를 누가 소유하느냐에서 갈린다.
#처음 가 본 AI 행사
자세한 일정이 미리 공유되지 않아 2시에 시작하는 줄 알고 1시 30분쯤 도착했는데, 입구에는 벌써 줄이 서 있었다. 2시에 입장한 뒤에는 간단한 케이터링을 먹으며 한두 명과 이야기를 나눴고, 메인 프로그램은 3시에야 시작했다.
DevDay Exchange는 9월 샌프란시스코 DevDay의 내용을 여덟 도시에 나눠 전하는 순회 행사였고, 서울에는 600명이 넘게 모였다고 한다. 나는 메인 스테이지에서 오프닝 키노트와 루프, 플러그인 세션을 들었다. 환영사를 빼면 발표는 대부분 영어였다. 키노트와 루프 세션은 그대로 들었지만, 세 번째 발표자의 말이 너무 빨라 플러그인 세션에서는 결국 통역 수신기를 귀에 꽂았다.
여기서 하네스는 모델을 에이전트로 돌리는 실행 틀이다. 도구 호출과 권한, 맥락 관리, 실패했을 때 다시 시도하는 방식까지 모델 바깥에서 에이전트를 움직이는 부분을 말한다. 앨버트 입의 키노트는 Dots와 ChatGPT Space, GPT-6.1 Sol과 함께 Codex의 실행 환경을 관리형 서비스로 여는 Agents API를 소개했다. 보니 채터지의 세션 제목은 ‘루프 엔지니어링 다음에는 무엇이 올까요?‘였다. 모델을 반복해서 부르는 루프 하나로 에이전트를 만들던 데서 여러 에이전트가 협업하는 구조로 옮겨 가는 흐름을 다뤘다. 그 출발점으로 Codex 에이전트를 모델과 하네스 두 상자로 나눠 그렸는데, 모델은 추론하고 무엇을 할지 고르며, 하네스는 지침을 쥐고 도구를 실행해 결과를 돌려준다. 코리 칭의 플러그인 세션은 ChatGPT 플러그인을 만들고 배포하는 과정을 시연하며, 내 서비스를 ChatGPT와 Codex 안에서 사용자가 찾아 쓰게 하는 길을 보여 줬다.
루프 세션의 슬라이드. 목표 하나를 에이전트 팀 넷이 나눠 맡고, 각 팀의 결과가 하나의 해답으로 모인다.
#Harness와 Agents API로 서비스 만들기
4시 45분에는 둘 중 하나를 골라야 했다. 메인 스테이지에서는 Sites 세션이, 브레이크아웃에서는 Harness 세션이 열렸다. 요즘 내 작업용 하네스를 직접 짜고 있어서 망설이지 않고 브레이크아웃으로 옮겼다. 세션 제목은 Harness-as-a-Service였고, 한국어 제목은 ‘Harness와 Agents API로 서비스 만들기’였다. 이재원, 김정원 두 엔지니어가 번갈아 맡은 세션은 메인 스테이지와 달리 한국어로 진행됐다. 이재원 엔지니어는 Responses API로 모델의 추론 기능을 제공하던 데서 출발해 에이전트가 실행되고 관리되는 환경 전체를 서비스로 내놓는 단계까지 왔다고 말한 뒤, Responses API를 써 본 사람과 Chat Completions를 써 본 사람에게 차례로 손을 들게 했다.
브레이크아웃 스테이지의 Harness 세션. 메인 스테이지보다 작은 방이었다.
이어서 김정원 엔지니어는 작년에 Agents SDK를 낼 때까지만 해도 개발자가 하네스를 직접 만들고 구성하고 싶어 한다고 생각했다고 털어놓았다. 그런데 계속 돌아온 피드백은 Codex에 좋은 하네스가 있는데 왜 서비스로 주지 않느냐는 것이었고, 그 답이 Agents API라고 했다. 바닥에 Responses API가 있고, 그것을 엮어 만든 하네스가 Codex다. 그 위에 Agents API가, 맨 위에 개발자의 애플리케이션이 놓인다. Agents API에서 개발자는 맡길 일과 지침, 도구, 환경을 고르고, 거기에 맞는 하네스는 OpenAI가 유지 보수한다. 모델이 나아질 때마다 하네스를 걷어내고 다시 손보는 부담도, 적어도 OpenAI 모델에 한해서는 많이 줄어들 거라는 설명이 붙었다. 하네스를 직접 짜 본 사람이라면 모델이 바뀔 때마다 프롬프트와 도구 구성을 다시 맞추는 일이 얼마나 자주 돌아오는지 안다. 나도 그 대목에서 고개를 끄덕였다.
Harness 세션의 층 구조 슬라이드를 옮겼다. Responses API 위에 Codex가, 그 위에 Agents API와 애플리케이션이 쌓인다.
Codex 하네스를 API로 내놓기까지 넘어야 했던 문제로는 세 가지를 들었다. 첫째는 실행 환경이다. 로컬에서 돌던 Codex와 달리 Agents API는 OpenAI가 호스팅하는 샌드박스나 고객이 지정한 샌드박스에 일을 보내고 결과를 받아 와야 해서, 하네스와 작업이 실행되는 곳을 떼어 냈다. 둘째는 에이전트가 하는 일을 사용자에게 보여 주는 방식이다. 이 대목을 넘겨받은 이재원 엔지니어는 Responses API로 제품을 만들던 내부 팀이 결제 실패의 원인을 찾고 타임아웃을 늘려 다시 시험하는 두 단계를 도구 호출과 그 결과로 묶어 보고 싶어 했고, 그래서 Agents API에 턴이라는 단위를 넣었다고 했다. 셋째는 다시 김정원 엔지니어가 설명한, 며칠씩 도는 작업이다. 컨텍스트 압축을 API 안에서 기본으로 처리하고, 서버가 죽었다 살아나도 진행 중이던 작업과 결과물의 상태를 넘겨받아 이어서 일하게 했다.
세 가지 과제를 개발자 쪽 말로 바꾼 슬라이드를 옮겼다.
OpenAI가 맡는 몫과 개발자가 맡는 몫의 구분은 문서에 더 직접 적혀 있다. 9월 10일 공개 베타로 나온 Agents API의 소개 글은 OpenAI가 하네스를 호스팅하고 유지 관리하니 개발자는 자기 에이전트만의 도구와 지식, 워크플로에 집중하라고 적었다. 에이전트 가이드의 비교표는 더 노골적이다. Agents API는 OpenAI가 관리하는 Codex 하네스에서 돌고 연동 부담이 낮다. 반대쪽 끝의 Responses API는 모델을 직접 부르거나 에이전트를 처음부터 만들 때 쓰고, 연동 부담이 높다.
데모는 인천에서 샌프란시스코로 가는 가상의 항공편이 결항된 상황이었다. 승객 12명, 예약 18건 가운데 내일 오전 출발을 원하는 혼자 여행하는 승객과, 아이가 보호자 옆에 앉아야 하고 근처 공항에 내리면 렌터카를 원하는 4인 가족을 골라 두 사례에 세션을 하나씩 따로 띄웠다. 세션에는 Responses API에서 쓰던 잔여 좌석 조회 도구와 항공편 예약에 필요한 스킬을 넣었고, 좌석 조건과 도착 조건은 하위 에이전트 둘이 나눠 검토했다. 세션을 만드는 코드는 짧았다. 환경을 OpenAI가 호스팅하는 샌드박스로 정하고 네트워크 접근은 끈 채, 결과를 스트리밍으로 받았다. 결과는 대체편 제안을 담은 JSON 파일로 돌아왔고, 마지막 예약 변경은 사람이 승인했다. 중간에 로컬에 띄운 데모 서버가 내려가자 이재원 엔지니어는 여러분의 기도가 부족했던 것 같다며 웃었고, 슬라이드로 설명을 이어 간 뒤 발표 끝에 다시 무대에 올라 데모를 마쳤다.
재예약 데모의 세션 생성 코드. 환경은 OpenAI가 호스팅하는 샌드박스, 네트워크는 막았다.
이 세션에서 가장 오래 남은 것은 데모가 멈춘 사이 이재원 엔지니어가 이어 간 설명이었다. 같은 일을 Responses API로도 충분히 할 수 있지만, 그러면 언제 사람이 개입할지, 에이전트를 어디서 실행할지, 진행 상황을 어떻게 보여 줄지를 하나하나 직접 챙겨야 한다. Agents API를 쓰면 개발자는 예약을 어떤 기준으로 바꾸고 언제 사람이 승인할지에 집중하면 된다고 했다. 앞서 턴을 설명할 때도, 하네스를 서비스로 내놓으면 어디까지 맡기고 개발자가 무엇을 직접 챙길지 그 경계를 하나하나 따져야 한다고 했다.
#하네스를 빌려 쓰는 쪽과 만드는 쪽
나는 이 두 API의 차이가 쓰는 사람의 자리를 가른다고 읽었다. 빌더는 아이디어를 빨리 서비스로 만드는 사람이고, 이들에게는 Codex 하네스를 최대한 그대로 빌려 쓰고 플러그인과 Agents API로 붙이는 길이 효율적이다. 빌더라면 반길 소식이다. 소프트웨어 엔지니어에게는 모호한 지점이 먼저 걸린다. 하네스까지 Codex가 맡는다면 엔지니어에게는 무엇이 남느냐는 질문이다. 그런데 어떤 의미에서는 이번 발표가 그 남는 자리를 더 분명하게 그어 주기도 했다. 발표자가 개발자에게 남긴 몫, 즉 예약을 어떤 기준으로 바꾸고 언제 사람이 승인할지는 Agents API를 써도 회사가 정할 규칙이다. 관리형 API가 주는 기능과 연결만으로 그 규칙을 회사의 방식대로 강제하기 어렵다면, 발표자가 Responses API로 하면 직접 챙겨야 한다고 말한 일들이 엔지니어의 몫으로 돌아온다. 내가 듣지 못한 고객 세션에서도 AWS가 작은 업무에서 시작해 범위를 넓히고, 접근 권한과 사용량, 비용을 기업의 보안 정책과 거버넌스에 맞춰 관리하라고 했다고 한다.
그 자리를 가르는 기준은 하네스를 누가 소유하느냐다. 관리형 하네스를 쓰면 빠르게 만들 수 있지만 비용과 제어를 내 뜻대로 하기 어려울 수 있다. 직접 만들면 그 둘을 쥘 수 있는 대신 그만큼의 개발과 유지 보수를 떠안는다. 그래서 먼저 따질 것은 관리형 API가 주는 도구와 환경 연결만으로 요구를 채울 수 있는지다. 그래도 사내 하네스가 필요한 경우는 남는다. 접근 권한을 사내 권한 체계와 감사 기록에 묶어야 할 때, 사용량과 비용을 팀이나 기능 단위로 통제해야 할 때, 관리형 하네스가 다루지 않는 특화된 도구나 데이터가 업무의 중심일 때다. 이런 몫이 커질수록 관리형 하네스를 감싸거나 Responses API 위에서 짜는 사내 하네스를 플랫폼으로 제공하는 일이 엔지니어에게 온다. 당분간은 관리형 하네스가 더 인기를 끌겠지만, 직접 만든 하네스가 언젠가 다시 이야기될 수도 있다. 그때의 사내 하네스는 다루는 범위를 좁히고, 회사의 권한과 비용 규칙에는 더 깊이 묶인 모습일 것 같다.
다만 이것은 모두에게 해당하는 그림이 아니고, 발표자가 한 말도 아니다. Agents API에도 고객의 샌드박스와 자체 도구를 연결할 수 있어서, 회사에 필요한 통제를 위해 하네스 전체를 만들어야 하는 것은 아니다. 같은 세션 끝에는 김정원 엔지니어가 Codex 하네스와 모델을 AWS Bedrock에서도 퍼블릭 프리뷰로 쓸 수 있을 거라며, 데이터와 컴퓨팅을 AWS 인프라 안에 둘 수 있다고 소개하기도 했다. 관리형과 직접 구축 사이의 선택지는 생각보다 넓다. 하네스를 맡기라는 메시지는 OpenAI에게 유리한 메시지이기도 하다. 다른 참석자의 후기 중에도 발표 전체를 OpenAI에게 다 맡기라는 이야기로 읽은 글이 있었다. 위의 기준도 AI 쪽으로 옮겨 가는 중인 백엔드 엔지니어가 세운 일반론이고, 검증해 본 것은 아니다. 앞으로 팀에서 빌더가 Codex로 만든 것을 사내 하네스로 옮길 일이 생기면, 무엇을 바꿔야 했는지를 권한과 비용, 관측 순서로 적어 볼 생각이다.
지난 1년은 백엔드 엔지니어가 대체된다는 이야기가 더 크게 들렸고, 백엔드 엔지니어로 일해 온 나도 그 이야기에서 자유롭지 않았다. 이번 행사에서는 엔지니어가 회사의 기반 하네스를 구축하고 관리하는 쪽으로 방향을 잡을 수 있겠다는 생각이 들었고, 처음 가 본 AI 행사에서 들고 온 것도 그 생각 하나다. 빌더는 하네스를 빌려 쓰고, 엔지니어는 회사의 하네스를 만든다. 이번 발표가 두 사람의 영역을 전보다 조금 더 갈라 놓은 것은 분명하다.
#본문 밖의 이야기
Harness 세션에서 소개한 고객 사례는 노션과 라쿠텐, 베인이었다. 발표자는 그중 베인앤드컴퍼니의 사례가 조금 더 재미있었다고 했는데, 가상의 고객 페르소나를 만들어 신제품에 대한 설문 응답을 미리 받아 보는 데 Agents API를 쓴다고 한다. 내가 듣지 못한 Sites와 GPT-Live 세션의 데모, Codex 보안 세션의 개요는 디지틀조선의 현장 기사가 옮겨 두었다.
김경훈 오픈AI코리아 대표는 환영사에서 한국이 Dots 주간 활성 이용자 수 세계 3위, ChatGPT Pro 이용자 수 세계 5위권이라고 했다. 국내 개발자 피드백이 반영된 예로는 Codex의 리눅스 지원과 한 프로젝트에서 여러 폴더를 다루는 기능, 모바일 환경 개선을 들었다. 환영사 끝에는 참석자에게 ChatGPT Pro 100 요금제 30일을 행사 기념으로 준다고 했다. 이 한 달 동안 Codex로 이것저것 열심히 실험해 볼 생각이라 벌써 기대된다.
#참고 자료
- 에이전트 API 소개 (OpenAI, 2026.09.10). Codex 하네스와 인프라를 공개 베타 API로 열면서 OpenAI가 하네스를 호스팅하고 유지 관리한다고 밝힌 글.
- Agents (OpenAI API 문서). Agents API와 Agents SDK, Responses API를 실행 위치와 연동 부담으로 비교한 가이드.
- OpenAI ‘DevDay Exchange: Seoul’ 현장 (디지틀조선). 서울 행사의 세션 구성과 Sites, GPT-Live 데모를 자세히 옮긴 현장 기사.
- OpenAI DevDay Exchange 2026. 8개 도시 일정과 행사 형식을 소개하는 공식 페이지.