9월 29일 OpenAI의 DevDay 요약 발표에서는 이 새로운 기능을 알기 쉽게 설명했습니다. "ChatGPT에게 프로젝트 보드의 새 작업을 모니터링하도록 요청할 수 있습니다. 새 작업이 등록되면, 자리를 비운 사이에도 ChatGPT가 연결된 문서를 읽고 계획 초안을 작성할 수 있습니다." 그 이면에는 모든 플랜에 적용된 제안 단계의 MCP Events 사양 지원이 있으며, 정해진 일정이나 이벤트 기반으로 실행되는 팀 작업(team tasks), 그리고 Slack 및 Teams에서의 @ChatGPT라는 두 가지 팀 기능이 함께 출시되었습니다.
이미 코딩 에이전트를 활용 중인 팀에게, 에이전트가 모니터링하는 보드는 '새 작업'의 의미 자체를 바꿉니다. 이전에는 작업이 사람을 기다렸다면, 이제는 하나 또는 여러 에이전트를 깨울 수 있게 되었습니다. 만약 두 사람이 각자 ChatGPT에 같은 보드를 모니터링하도록 요청하고, 보드 자체에도 새 작업에 할당된 에이전트가 있다면, 작업 하나에 서로 다른 세 곳에서 세 개의 초안 계획이 생성될 수 있습니다. 정작 어떤 계획이 유효한지는 아무도 결정하지 않은 채로 말이죠.
핵심 요약
MCP Events는 ChatGPT가 연동된 앱의 변경 사항을 서명 검증을 거쳐 깔끔하게 수신할 수 있는 방식을 제공하며, ChatGPT 팀 작업(Team tasks)은 Business 및 Enterprise 플랜에 예약형 및 이벤트 기반 업무 처리를 지원합니다. 이벤트를 통해 에이전트를 시작하는 것은 비교적 쉬운 절반의 과제이며, OpenAI는 이를 꼼꼼하게 구현해 냈습니다. 진짜 까다로운 절반은 이벤트가 보드에서 무엇을 만들어내느냐입니다. 결과로 나온 작업의 오너는 누구인지, 계획 초안은 어디에 저장되는지, 어떻게 검토되는지, 그리고 두 에이전트가 동일한 이벤트에 중복 응답하지 않도록 어떻게 방지할 것인지에 대한 문제입니다. 이를 하나의 라우팅 규칙으로 정리해 두어야 합니다. 즉, 하나의 이벤트 유형에는 하나의 오너만 배정하고, 계획은 해당 작업(Task)으로 다시 전달되며, 최종 완료로 인정되기 전에 반드시 사람이 승인하도록 하는 것입니다.
DevDay에서 발표된 기능들
MCP Events는 연동된 앱에서 이벤트가 발생했을 때 MCP 서버가 ChatGPT에 알림을 보내고, 플러그인이 이에 대응하여 자동화를 시작할 수 있도록 하는 Model Context Protocol의 확장 제안 사양입니다. OpenAI의 MCP Events 가이드는 서버 측 구현을 설명합니다. 서버는 이벤트 지원 여부를 알리고 세 가지 메서드인 events/list, events/subscribe, events/unsubscribe를 구현합니다. ChatGPT는 웹훅(Webhook) 전송 방식만 지원하며, HTTPS 검증 챌린지를 거쳐 Standard Webhooks HMAC으로 서명되고, 요청당 최대 256KiB의 이벤트 하나를 처리합니다. 이벤트가 도착하면 가이드의 설명대로 "ChatGPT는 구독된 채팅에서 이벤트를 수신하고 사용자 지침에 따라 응답 방식을 결정"합니다.
세부 사항 역시 중요한 부분마다 세심하게 설계되었습니다. 서버는 재시도 전반에 걸쳐 동일하게 유지되는 고유 ID를 각 이벤트에 부여해야 합니다. 구독은 멱등성(idempotent)을 보장해야 합니다. 구독의 고유 식별자는 주체(principal), 콜백 URL, 이벤트 이름, 인자로부터 파생되므로, 다시 구독하더라도 중복 구독이 생성되지 않고 기존 구독이 업데이트됩니다. 또한 서버는 사설 및 로컬 콜백 주소를 차단해야 하며 리디렉션을 따라가서는 안 됩니다.
| 기능 | 주요 역할 | 지원 플랜 | 응답 정의 방식 |
|---|---|---|---|
| MCP Events | MCP 서버가 이벤트를 푸시하면 ChatGPT가 사용자가 정의한 자동화를 실행 | 모든 플랜 | 채팅에서 이벤트를 구독한 사용자 |
| Team tasks | 정기 일정이나 새 이메일, Slack 메시지 등의 이벤트에 반응하여 주간 프로젝트 업데이트 같은 반복 업무 수행 | Business, Enterprise | 팀원들이 지침을 함께 개선 |
| Slack 및 Teams 내 @ChatGPT | 채널, 스레드, DM에서 멘션하여 관리자가 연결한 도구 또는 사용자 권한이 부여된 자체 도구를 활용 | Business, Enterprise | 대화에 참여한 사람 누구나 개별 ChatGPT 라이선스 없이도 컨텍스트 추가 가능 |
이러한 기능들이 결합되면서 ChatGPT는 대화창 외부에서 업무가 시작될 수 있는 공간으로 진화했습니다. 이는 실질적인 진전이며, 수많은 반복 업무에는 이것만으로도 충분할 것입니다.
트리거 연동은 절반에 불과합니다
DevDay 요약에 나온 예시를 실제 팀 환경에 적용해 보겠습니다. 보드에 새 작업이 도착합니다. ChatGPT가 연결된 문서를 읽고 계획 초안을 작성합니다. 여기서 곧바로 네 가지 질문이 뒤따르며, 이 질문들은 데이터 전송 방식과는 아무런 관련이 없습니다.
결과 작업의 담당자(Owner)는 누구인가? 계획 초안이 곧 작업 할당을 의미하지는 않습니다. 계획이 설명하는 업무를 누군가는 책임져야 하며, 대부분의 팀에서는 보드에 이를 기록합니다. 즉, 작업에 지정된 담당자 이름과 진행 상태의 변경입니다. 아무리 훌륭한 초안이라도 그 자체만으로는 둘 중 어느 것도 바꾸지 못합니다.
계획은 어디에 저장되는가? 이벤트는 구독을 설정한 채팅으로 수신되며, 계획은 해당 사용자의 지침에 따라 전송됩니다. 채팅 창의 답글이 될 수도 있고, 플러그인이 보드 쓰기 기능을 제공하고 지침에 명시되어 있다면 보드로 다시 기록될 수도 있습니다. 팀은 이 결과가 어디로 가는지 알고 있어야 합니다. 그렇지 않으면 다른 사람은 보지도 않는 곳에 훌륭한 계획이 방치된 채 보드에는 계속 "신규(new)"로만 표시될 수 있습니다.
어떻게 검토되는가? 계획은 작업 범위(scope)에 대한 결정입니다. 코드 작성을 시작하기 전에, 작성자가 아닌 다른 사람이 다음 작업자가 쉽게 찾을 수 있는 위치에서 이를 검토해야 합니다.
이벤트에는 누가 응답하는가? 멱등성은 단일 구독이 스스로 중복되는 것을 막아줄 뿐입니다. 두 사람 사이의 조율까지는 해주지 못합니다. 주체(principal)가 구독 식별자의 일부이므로 각 사용자의 구독은 별개로 취급되기 때문입니다. 여기에 보드 자체에 할당된 에이전트까지 더해지면 동일한 작업에 대해 계획이 여러 번 수립될 수 있습니다. 웹훅 계층의 중복 제거가 실제 업무 계층의 오너십까지 결정해 주지는 않습니다.
이는 모두 관리의 문제입니다. 세 사람이 동일한 티켓을 동시에 가져갈 수 있었던 것처럼 에이전트 이전에도 존재했던 문제이지만, 작업을 가져가는 주체가 절대 잠들지 않을 때는 훨씬 더 빈번하게 발생합니다. 부재 중 실행되는 작업의 검토 방식에 대해서는 자리를 비운 사이 작동하는 코딩 에이전트 글을 참고하세요.
라우팅 규칙을 보드에 두어야 하는 이유
에이전트가 담당자(Assignee)로 참여하는 보드에서는 "새 작업 모니터링"이 대부분 "작업 할당"으로 귀결됩니다. Sharkly에서는 에이전트에 할당된 작업이 백로그(Backlog) 상태를 벗어나고 해당 컴퓨터와 런타임이 준비되면 실행이 시작됩니다. 실행 담당자 슬롯에는 정확히 하나의 에이전트 또는 크루(Crew)만 배정되며, Sharkly는 대기 중인 작업을 병합하므로 댓글이 빠르게 연달아 달려도 동일한 에이전트와 작업에 대해 중복 대기 실행이 발생하지 않습니다. 오너십은 암묵적인 규칙이 아니라 명확한 데이터 필드로 관리됩니다.
할당 없이 작업을 시작해야 하는 이벤트의 경우, 보드 측에서는 Sharkly 오토메이션(Sharkly Automations)이 그 역할을 합니다. 오토메이션은 지침, 에이전트 또는 크루, 하나 이상의 트리거, 실행 기록으로 구성된 단일 규칙이며 '활성(Active)' 또는 '일시 중지(Paused)' 상태를 가집니다. 지원되는 트리거로는 일정(타임존이 지정된 cron), 특정 상태로의 작업 이동, 특정 문구가 포함된 댓글, 외부 서비스의 웹훅이 있으며, 테스트를 위한 즉시 실행(Run now)도 제공됩니다. 각 실행은 즉시 시작되어 오토메이션에 기록을 남기므로 지침에 결과가 어디에 기록되는지 명시해야 합니다. 현재 상태 및 댓글 매칭은 조직 전체 범위로 동작하므로, 오토메이션 공식 문서에서는 동작을 수행하기 전에 트리거된 작업을 검증하는 지침을 작성할 것을 권장합니다.
다음은 한 스페이스(Space)의 이벤트-작업 매핑 테이블입니다.
| 이벤트 | 메커니즘 | 실행 주체 | 결과 전달 위치 | 결정권자 |
|---|---|---|---|---|
| Slack에 요청 게시 | Slack 바로가기가 트리아지(Triage) 상태로 작업을 생성 | 아직 없음 | 트리아지 상태의 해당 작업 | 사람이 승인, 거절, 중복 표시 또는 알림 미루기(snooze) 처리 |
| GitHub 이슈 생성 | GitHub 연동: 연결된 리포지토리의 새 이슈가 작업으로 등록됨 | 아직 없음 | 해당 작업 | 해당 스페이스의 트리아지 담당자 |
| 작업이 “Needs plan” 상태로 이동 | 오토메이션, 상태 트리거 | Planner 에이전트 | 해당 작업의 댓글 | 해당 작업의 인간 담당자 |
| 작업에 “/replan” 댓글 작성 | 오토메이션, 댓글 트리거 | Planner 에이전트 | 해당 작업의 새 댓글 | 해당 작업의 인간 담당자 |
| 작업이 코딩 에이전트에 할당되고 백로그를 벗어남 | 작업 실행 | 해당 에이전트(자체 컴퓨터 환경) | 댓글, 실행 내역, 연결된 풀 리퀘스트 | 리뷰어가 검토 후 사람이 최종 승인 |
| CI 실패 웹훅 | 오토메이션, 웹훅 트리거 | Triage 에이전트 | 오토메이션 실행 기록 | 온콜 담당자 |
| 평일 09:00 | 오토메이션, 일정 트리거 | Status 에이전트 | 실행 기록 및 수신자별 수신함(Inbox) 항목 | 팀 리드 |
그리고 팀원들이 함께 검토하고 논의할 수 있도록 정리한 그 이면의 규칙입니다.
Routing rule: new work in the ENG Space
1. One event type, one owner. Each event maps to exactly one
Automation or one Agent Assignee. Personal watchers (a chat
subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
the Backlog category. The "Draft plan" Automation runs the Planner
Agent, which first checks the Task's Space and type and stops if
the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
into a Completed status.
“Needs plan”을 백로그 카테고리에 두는 것은 5단계를 안전하게 만드는 중요한 디테일입니다. 백로그에 할당된 작업은 대기 상태로 머물기 때문에 실행이 시작되기 전에 계획을 먼저 검토할 수 있습니다. Planner의 지침에 계획이 저장될 위치를 명확히 작성하고, 트리거를 전적으로 신뢰하기 전에 '즉시 실행(Run now)'으로 테스트해 보세요. 실행 도중 에이전트에 사람의 결정이 필요해지면 작업은 사람의 응답 대기 중으로 표시되고 담당자의 수신함(Inbox)에 들어가게 되며, 바로 이 지점에서 "자리를 비운 사이"라는 말이 다시 사람의 검토로 연결됩니다. 작업(Task)은 그룹 채팅의 요청이 추적 가능한 작업으로 바뀌는 곳이며, 에이전트에 할당된 GitHub 이슈 역시 마찬가지입니다.
ChatGPT의 감시 기능은 어디에 적합한가
개인이 자신의 채팅창에서 알림을 받고 첫 번째 초안을 확인하고 싶을 때는 MCP Events 구독을 사용하세요. 직접 운영하지는 않지만 팔로우하는 보드, 파트너사의 트래커, 개인적인 금요일 업무 요약 등이 여기에 해당합니다. 반복되는 작업이 ChatGPT 내에서 이뤄지는 팀 업데이트이고 팀이 Business 또는 Enterprise 플랜을 사용 중이라면 팀 작업(Team tasks)을 활용하세요. 팀원들이 제각기 지침을 작성하는 대신 하나의 지침을 함께 다듬어갈 수 있기 때문입니다. 반면 이벤트가 팀 전체가 책임져야 할 업무를 만들어낼 때는 보드 측 규칙을 사용하세요. 누군가 실행해야 할 계획, 누군가 검토해야 할 버그 수정, 월요일 주간 회의 집계에 반영되어야 하는 작업 등이 이에 해당합니다.
이벤트 기반 AI 에이전트의 효과는 어떤 에이전트가 응답할지 정의하는 규칙의 완성도에 달려 있습니다. 이벤트 자체는 배관(인프라)에 불과합니다. 라우팅, 오너십, 검토는 관리의 영역이며, 어떤 벤더의 도구이든 간에 모든 에이전트가 결과를 보고하는 프로젝트 보드에 속해야 합니다. 큐가 가득 찼을 때 에이전트가 다음으로 처리할 작업을 결정하는 방법에 대해서는 AI 백로그 관리 및 트리아지를 참고하세요. OpenAI 발표의 첫 번째 공개 기능이었던 Dots 역시 에이전트 측면에서 동일한 과제를 던져줍니다.
이미 여러 에이전트를 운영 중이라면, Sharkly를 통해 에이전트의 작업과 결과를 한곳에서 관리할 수 있습니다.
추가 참고 자료
- Sharkly Automations: 4가지 트리거 유형, 실행 기록, 그리고 자동화가 멈추는 지점
- 그룹 채팅에서 추적 가능한 코드 작업으로: 메시지를 오너십이 있는 작업으로 전환하기
- AI 백로그 관리 및 트리아지: 에이전트가 다음에 작업할 내용 결정하기
- GitHub 이슈를 AI 에이전트에 할당하기: 이슈에서 검토 가능한 풀 리퀘스트까지
- 자리를 비운 사이 작동하는 코딩 에이전트: 무인 실행과 검토 큐
- OpenAI Dots 살펴보기: 상시 가동되는 개인용 에이전트와 팀에 필요한 보완 장치
