OpenAI DevDay Exchange 2026 Seoul 후기
송찬우 17분 분량
2026년 10월 22일 서울에서 열린 OpenAI DevDay Exchange Seoul에 다녀왔습니다. 오프닝 키노트를 맡은 Albert Yip의 이야기 가운데 가장 오래 남은 건 AI와 사람의 관계였어요. 기억하는 요지는, AI가 사람을 거대한 톱니바퀴로 만드는 것이 아니라 한 명 한 명을 더 강하게 만들어 더 가치 있고 중요한 일을 하게 해야 한다는 것이었습니다.
이어진 두 세션, Bonnie Chatterjee의 ‘루프 엔지니어링 다음에는 무엇이 올까요?’와 Corey Ching의 ‘플러그인으로 ChatGPT 플랫폼의 미래를 만들어 보세요’에는 그 방향을 도구로 옮기는 장치가 꽤 구체적으로 나왔어요. 이번 글은 현장에서 찍은 슬라이드를 따라 그 장치가 어떻게 움직이는지 뜯어봅니다.
모델은 고르고, 하네스는 실행합니다.
Bonnie Chatterjee의 발표는 에이전트를 두 칸으로 나누는 그림에서 출발했습니다. 왼쪽 모델은 추론하고 다음에 무엇을 할지 고릅니다. 오른쪽 하네스는 지침을 쥐고, 모델이 요청한 도구(Tool)를 실제로 실행해 결과를 돌려줘요.
하네스는 모델을 감싸서 실제 일을 하게 만드는 실행 환경입니다. 모델은 명령어를 직접 돌리지 않습니다. 이 명령을 실행해 달라는 도구 호출을 내놓을 뿐이고, 셸에서 명령을 돌려 출력을 받아 오는 건 하네스예요. OpenAI는 Codex 에이전트 루프를 풀어 쓴 글에서 이 반복을 설명합니다. 모델이 도구 호출을 요청하면 하네스가 실행하고, 그 출력을 다음 추론의 입력에 덧붙여 다시 모델을 부릅니다. 모델이 도구 호출 없이 답을 내놓을 때까지 이 루프가 돌아요.
그래서 개발자가 설계할 대상도 둘로 나뉩니다. 모델에게는 목표와 지침을 주고, 하네스에는 어떤 도구를 허용할지, 어떤 환경에서 실행할지를 정해 줍니다. 같은 모델이라도 하네스가 열어 준 도구와 돌려주는 결과가 달라지면 다음 선택이 달라집니다.
루프가 돌려면 지금까지의 상태가 남아야 합니다.
다음 화면은 그 루프에 무엇을 실어 보내는지를 보여 줬습니다. 업무 맥락 칸에는 목표, 시도, 학습결과가 있고, 다음 단계 칸에는 명령어와 테스트 결과가 있어요.
여기서 학습결과는 모델을 다시 학습시킨다는 뜻이 아닙니다. 이번 작업에서 해 보고 알아낸 사실, 예를 들어 이 설정을 바꾸니 오류가 사라졌다거나 이 경로는 원인이 아니었다는 관찰이에요. 목표만 반복해서 넣으면 모델은 이미 실패한 시도를 다시 고를 수 있습니다. 시도와 그 결과를 함께 넘기면 다음 명령과 테스트를 고를 근거가 생깁니다.
OpenAI Agents API 문서는 관리형 하네스가 명령 실행, 지침과 스킬, 도구 연결, 긴 맥락의 요약, 하위 작업 위임, 세션 재개를 맡는다고 설명합니다. 다만 화면 속 업무 맥락의 칸 구성은 발표가 보여 준 설계 예시이고, API가 이 칸들을 정해진 형식으로 만들어 준다는 뜻은 아닙니다.
고친 것과 확인한 것은 다른 단계입니다.
이 상태가 어떻게 쓰이는지는 다음 화면의 요청 예시가 보여 줍니다. 입력창에는 /goal Find why search got slower and verify a fix., 검색이 왜 느려졌는지 찾고 수정이 맞는지 검증하라는 목표가 적혀 있었어요. 그 아래로 프로필, 수정 시도, 검증의 세 단계와 CONTINUE가 이어집니다.
이 흐름을 앞의 하네스 그림에 겹쳐 보면, 개발자가 만들 수 있는 루프는 이런 모습이 됩니다. 프로필 단계에서 모델이 프로파일링 명령을 요청하면, 하네스가 그 명령을 실행해 어느 함수나 쿼리에서 시간이 오래 걸리는지 돌려줍니다. 모델이 그 결과를 보고 원인으로 보이는 부분의 수정안을 내면, 그 패치를 실제로 코드에 적용하는 것도 하네스예요. 검증 단계에서는 회귀 테스트와 성능 측정을 다시 돌려 검색 결과가 여전히 맞는지, 느렸던 경로가 실제로 빨라졌는지를 따로 확인하게 할 수 있습니다. 그 결과가 다시 모델의 입력으로 돌아가, 이어서 무엇을 할지 판단하는 재료가 됩니다.
핵심은 수정과 검증을 다른 단계로 둔 점입니다. 코드를 바꿨다고 일이 끝난 게 아니고, 개발자가 성공 기준과 검증 방법을 지침에 넣어 둬야 모델도 언제 멈출지 판단할 수 있습니다. 화면의 /goal은 발표 속 요청 예시라, 모든 클라이언트에서 쓰는 공통 명령이라는 뜻은 아니에요.
검토는 나눠도 병합 책임은 따로 남습니다.
발표는 에이전트 하나에서 여러 에이전트로 넘어갔습니다. 일을 지원 업무, 코어 작업, 조언 역할로 나누는 그림에 이어, 매니저 에이전트에게 주는 요청 예시가 나왔어요.
요청은 책임을 세 갈래로 나눕니다. 리뷰를 기다리는 PR마다 별도 채팅을 만들어 각각 변경 사항을 검토하게 하고, 매니저는 각 채팅의 문제 해결을 관리하면서 모든 PR이 main 브랜치에 안전하게 병합되도록 전체를 조율합니다. 그리고 진행을 가로막는 문제는 사람에게 보고하게 해요.
눈여겨볼 건 뒤의 두 책임입니다. PR 하나하나가 각자 검토를 통과해도, 함께 병합하면 서로 부딪힐 수 있습니다. 그래서 어느 PR을 먼저 넣을지, 한 PR의 수정이 다른 PR에 영향을 주는지는 개별 검토자가 아니라 조정자가 따로 맡습니다. 에이전트끼리 풀 수 없는 문제가 사람에게 올라오는 경로도 처음부터 정해 두고요.
OpenAI의 서브에이전트 문서도 비슷한 구조를 설명합니다. 주 스레드는 요구 사항과 결정, 최종 결과를 쥐고 있고, 독립적인 조사나 테스트는 하위 에이전트에 나눠 맡긴 뒤 요약을 돌려받습니다. 여러 에이전트가 동시에 쓰기 작업을 하면 충돌과 조정 비용이 생길 수 있다는 점도 함께 적혀 있어요.
목표가 바뀌면 기록도 함께 바뀌어야 합니다.
여러 에이전트가 함께 일할 때 더 까다로운 건 요구 사항이 중간에 바뀌는 경우입니다. 발표는 퍼즐 게임을 예로 들었어요. 처음 요청은 혼자 즐길 수 있는 퍼즐 게임이었는데, 협업 게임으로 바뀌고, 오프라인에서도 작동해야 한다는 조건이 붙고, 공유된 턴 방식까지 들어갑니다.
화면 오른쪽의 공유 작업 로그가 이 변화를 받아 냅니다. 목표는 솔로 퍼즐 게임에서 협업 퍼즐 게임으로 바뀌고, 결정 칸에는 오프라인 우선이 적히고, 작업 칸에는 Lay out level 1, Implement shared turns, Test offline co-op이 올라와요. 오프라인 우선이라는 결정이 공유 턴 구현과 오프라인 협업 테스트라는 구체적인 작업으로 이어지는 구조입니다.
각 에이전트가 처음 받은 요청만 쥐고 일하면, 레벨을 만드는 쪽은 여전히 혼자 하는 게임을 만들고 있을 수 있습니다. 모두가 같은 로그에서 현재 목표와 결정을 확인하게 하면 바뀐 요구를 따라갈 근거가 생겨요.
맥락이 압축돼도 다시 읽을 기록을 남깁니다.
이어진 화면에는 이 로그를 어떻게 쓰라는 지침이 그대로 적혀 있었습니다.
요지는 이렇습니다. 목표, 현재 지침, 담당자, 미완료 작업, 결정 사항을 적은 작업 로그를 하나 유지합니다. 새 지침이 오면 진행 중인 작업과 대조해 관련 항목을 고치고, 결정과 그 결과를 적은 뒤 영향을 받는 담당자에게 직접 알립니다. 그리고 압축이나 인수인계 뒤에는 작업 로그부터 읽고 현재 상태를 확인한 다음 진행하라는 거예요. 화면 아래의 agent.md는 이 지침을 파일로 둔 발표 속 예시입니다.
압축(compaction)은 대화가 길어져 모델이 한 번에 볼 수 있는 맥락이 넘칠 때, 앞선 입력을 더 짧은 항목으로 바꿔 넣고 계속 일하는 방식입니다. 앞의 에이전트 루프 글에도 이 동작이 나와요. 맥락 공간은 확보되지만, 줄이는 과정에서 누가 무엇을 맡았는지, 무엇이 아직 안 끝났는지가 정확히 남는다고 단정할 수는 없습니다. 그래서 지침은 압축된 맥락에 기대지 말고, 명시적으로 적어 둔 로그를 다시 읽고 시작하라고 합니다.
다른 에이전트가 PR 검토를 이어받는 경우를 떠올리면 쓰임새가 분명해집니다. 새 검토자는 대화 전체를 다시 읽는 대신 로그에서 현재 목표, 바뀐 조건, 담당 PR, 아직 실패하는 테스트, 이미 정한 방식을 먼저 확인하고 이어서 일할 수 있습니다. 다만 이건 작업 로그를 쓰라는 지침 패턴이지, 모든 것을 자동으로 기억하는 저장소나 벡터 검색 같은 장치가 아니에요. 로그도 누군가 고쳐야 최신으로 남으니, 누가 언제 로그를 고치는지까지 설계에 들어가야 합니다.
플러그인은 묶음이고, 연결은 MCP 서버가 맡습니다.
Corey Ching의 플러그인 세션은 에이전트가 바깥의 도구와 데이터에 닿는 쪽을 다뤘습니다. MCP(Model Context Protocol)는 AI가 외부 도구와 데이터를 정해진 방식으로 부를 수 있게 하는 연결 규약이에요. 가장 구체적인 화면은 설치된 플러그인 폴더와 MCP 서버의 관계를 그린 그림이었습니다.
왼쪽 폴더에는 이름과 버전을 담은 plugin.json, MCP 서버 연결 설정을 담은 mcp.json, 사용 방법을 적은 skills/, 아이콘 같은 assets/가 있고, skills/와 assets/는 선택 사항입니다. 데스크톱 앱이 이 설정 파일을 불러오면, mcp.json에 적힌 연결 대상 URL로 MCP 서버에 붙어요. 화면 속 mcp.json 예시는 type을 streamable-http로 두는데, HTTP 위에서 MCP 메시지를 주고받는 연결 방식입니다. 도구와 HTML 화면, 표시 설정은 서버 쪽에 있고, 앱은 그 도구와 HTML을 대화 안에서 씁니다.
역할을 나눠 보면 이렇습니다. 스킬은 언제 무엇을 어떤 순서로 하라는 사용 절차이고, MCP 서버는 실제로 데이터를 읽고 고치는 기능이고, 플러그인은 이 둘과 아이콘 같은 것을 한 번에 설치하게 묶는 배포 단위예요. 발표에서는 여러 에이전트가 MCP로 함께 읽고 고칠 공유 할 일 목록을 만들어 플러그인으로 묶는 요청 예시도 나왔습니다. 스킬에 작업 전에 할 일 목록을 확인한다고만 적으면 모델은 확인해야 한다는 걸 알 뿐입니다. MCP 서버의 읽기, 갱신 도구가 연결돼야 실제 목록을 가져오고 고칠 수 있어요.
OpenAI 플러그인 문서도 plugin.json에 선택적으로 mcp.json, skills/, assets/를 붙이는 구성을 설명합니다. 다만 현재 문서는 .codex-plugin/plugin.json이나 .mcp.json 같은 호환 형식도 함께 다루고, 모든 플러그인에 MCP 서버나 HTML 화면이 필요한 것도 아닙니다. 화면 속 파일 이름은 발표의 예시로 보는 게 맞습니다.
파일을 열 때와 @로 찾을 때 입구가 다릅니다.
플러그인이 대화에 들어오는 입구도 나눠서 보여 줬습니다. 첫째는 파일 진입점이에요.
화면의 설정은 "openai/ui" 아래 entrypoints에 type이 "file"이고 extensions가 ".pdb", ".cif"인 항목을 둡니다. 둘 다 단백질 같은 분자의 3차원 구조를 담는 파일 형식이라, 분자 구조 뷰어를 예로 든 셈이에요. 사용자가 데스크톱 앱에서 이 확장자 파일을 열면, 등록된 도구가 그 파일을 넘겨받고 대화 옆 패널에 뷰어가 뜹니다.
OpenAI의 MCP 확장 명세에 따르면 도구가 받는 건 파일 이름과 resourceUri입니다. resourceUri는 앱을 거쳐 그 파일에 접근하기 위한 식별자이고, 컴퓨터 안의 파일 경로가 아니에요. 같은 명세의 지원 표에서 파일 진입점은 현재 데스크톱만 지원합니다.
둘째는 입력창의 @멘션입니다.
화면의 도구는 검색어 query 하나를 받아, ResourceLinkSchema 형식의 항목 목록 items를 돌려줍니다. 사용자가 입력창에서 @와 검색어를 치면 서버의 검색 도구가 파일이나 채널 같은 후보를 돌려주고, 사용자가 그중 하나를 골라 대화에 붙이는 흐름이에요. 플러그인을 통째로 부르는 것보다 필요한 자료 하나를 정확히 집어 넣을 수 있습니다. OpenAI 확장 가이드는 이 기능을 ChatGPT 데스크톱 앱에서 쓸 수 있다고 안내합니다.
화면 아래 _meta의 "openai/extensions"에 "mentions/search"를 적는 방식은 현재 명세에서 호환용으로만 남은 예전 방식입니다. 지금 권장하는 방법은 서버 기능(capability)으로 openai/mentions를 알리고 그 searchTool에 검색 도구 이름을 적는 것이고, 이 도구는 읽기 전용 표시(readOnlyHint)를 달아야 해요. 검색해서 항목을 골랐다고 그 대상에 쓰거나 무언가를 실행할 권한이 생기는 것도 아닙니다.
요청을 기다리지 않고 변경을 전달받는 길도 있습니다.
앞에서 본 파일 진입점과 @멘션은 사용자가 파일을 열거나 검색어를 쳐야 도구가 불리는, 요청과 응답의 흐름이었습니다. 발표 후반의 MCP 이벤트는 방향이 반대예요. 구독해 둔 변경이 생기면 서버가 웹훅으로 먼저 알립니다. 화면은 이벤트 목록, 이벤트 구독, 웹훅으로 이어지는 세 단계를 보여 줍니다.
MCP 이벤트 문서를 따라 흐름을 짚어 보면 이렇습니다. 사용자가 ChatGPT에 새 버그 보고가 올라오면 정리해 달라는 식으로 무엇을 지켜보고 어떻게 대응할지를 말합니다. ChatGPT는 events/list로 서버가 어떤 이벤트를 제공하는지 확인하고, events/subscribe로 구독을 만듭니다. 이후 그 이벤트가 생기면 서버가 구독에 등록된 콜백 주소로 서명한 HTTPS 요청, 곧 웹훅을 보내고, 구독한 채팅에서 지시한 대응이 이어져요. 구독을 끊을 때는 events/unsubscribe를 씁니다.
서버가 할 일도 적지 않습니다. 구독을 저장하고 권한과 필터를 지켜야 하며, 콜백 주소는 HTTPS만 받고 사설망이나 로컬 주소는 막아야 합니다. 전달을 시작하기 전에는 확인 값(challenge)을 주고받아 콜백을 검증해야 해요.
지원 범위도 좁습니다. 현재 문서상 ChatGPT 웹의 Work 채팅, Cloud를 고른 데스크톱 앱의 Work 채팅, dots에서 쓸 수 있고, MCP 2.0(프로토콜 버전 2026-07-28)이 필요합니다. 초안 단계인 Events 명세 가운데 웹훅 콜백 방식만 지원하고, 폴링이나 스트리밍은 지원하지 않아요. 모든 MCP 클라이언트에서 실시간으로 이벤트를 받을 수 있다는 뜻은 아닙니다.
자동 검사와 공개 검토는 다른 단계입니다.
마지막은 배포 과정이었습니다. 화면에는 업로드, 자동 피드백, 제출, 검토, 게시의 다섯 단계가 있고, 업로드와 자동 피드백 주변을 점선이 감싸고 있어요.
점선은 반복입니다. 개발자는 플러그인을 올리고 자동 검사 결과를 받아 고치기를 여러 번 되풀이할 수 있어요. 제출 문서에 따르면 자동 검사 진행 상황과 발견 사항은 플러그인 상세 화면에 나오고, 정책 확인을 마치고 제출하면 검토팀이 심사합니다. 승인된 뒤에도 언제 공개할지는 개발자가 고릅니다. 자동 피드백이 검토를 대신하지는 않아요.
이미 게시한 호스팅 MCP 서버는 조금 다릅니다. 조건에 맞는 업데이트는 자동 검사를 통과하면 새 패키지 버전이나 별도 게시 없이 반영될 수 있습니다. 다만 새로 추가한 도구는 승인을 받기 전까지 쓸 수 없어요.
무대 화면은 설계 예시입니다.
이 글에 옮긴 화면은 대부분 요청 예시와 설계 그림입니다. 검색이 실제로 빨라졌는지, PR이 병합됐는지, 협업 게임이 테스트를 통과했는지는 사진으로 확인할 수 없어요. 링크한 문서도 기능마다 지원하는 앱과 조건이 다르고, 가이드와 명세의 설명이 조금씩 다른 부분도 있습니다. 화면 속 설정을 그대로 옮기기보다, 쓰려는 시점의 공식 문서를 다시 확인해야 합니다.
사람에게 남는 일은 기준을 정하는 것입니다.
Albert Yip의 이야기로 돌아가 보면, 이날 슬라이드가 보여 준 구조는 반복을 기계 쪽으로 옮기는 장치였습니다. 하네스는 도구를 실행하고 결과를 되돌리고, 작업 로그는 바뀐 목표와 남은 일을 붙잡고, 플러그인과 MCP는 필요한 자료와 기능을 대화 안으로 가져옵니다.
그런데 그 구조 곳곳에는 사람이 정해야 하는 자리가 남아 있었습니다. 무엇을 성공으로 볼지, 어떤 검증을 통과해야 끝난 것인지, 어떤 도구와 데이터에 어디까지 권한을 열지, 막힌 문제를 누가 받을지예요. 한 명 한 명이 톱니바퀴가 아니라 더 중요한 일을 하는 사람이 될지는, 이 자리를 얼마나 잘 설계하느냐에 달려 있을 것 같습니다.