최근 ChatGPT의 MCP가 플러그인 체계로 통합되면서 재미있는 이야기를 봤다. 이제 ChatGPT의 오른쪽에도 플러그인 화면을 띄워놓고 대화하면서 조작할 수 있다는 것이다. 이전에는 MCP를 연결해도 주로 ChatGPT가 도구를 호출하고 텍스트로 결과를 받는 방식이었다. 그런데 플러그인 자체의 앱 화면이 대화 옆에 나타난다면 사용 경험이 꽤 달라진다.
정말 가능한 기능인지, 일반 사용자는 어떻게 실행하는지, 기존 커스텀 MCP도 바로 오른쪽에 띄울 수 있는지 궁금해서 공식 문서와 개발자 사례를 찾아봤다. 결론부터 말하면 기능은 실제로 존재한다. 하지만 플러그인이라고 해서 모두 오른쪽 패널을 지원하는 것은 아니다. 특히 일반 Chat 모드와 Work 모드를 구분해야 한다.
조사 기준: 2026년 10월 9일. 아래 내용은 공식 문서와 공개된 개발자 보고를 정리한 것으로, 모든 계정에서 직접 작동을 확인한 사용 후기는 아니다.
1. 언제 생긴 기능인가?
핵심 발표는 2026년 9월 29일 OpenAI DevDay 2026이었다. OpenAI는 개발자가 ChatGPT 안에 자신만의 앱 화면을 넣을 수 있게 하는 Plugin Extensions를 발표했다.
OpenAI DevDay 2026 공식 발표에는 플러그인 전용 공간을 사이드바에 추가하거나, 대화와 나란히 놓는 인터랙티브 패널을 만들거나, 특정 파일을 여는 전용 뷰어를 제공할 수 있다는 내용이 등장한다.
이전에 MCP가 ’ChatGPT가 외부 기능을 호출하는 통로’에 가까웠다면, 이제는 MCP 서버가 제공하는 UI까지 ChatGPT 안에서 직접 보여줄 수 있는 구조로 확장된 셈이다. 다만 MCP 자체가 무조건 화면을 만들어주는 기술로 바뀐 것은 아니다.

2. 오른쪽 패널과 왼쪽 사이드바 앱은 다른 기능이다
처음에는 두 기능이 혼동되기 쉬웠다. 공식 Plugin Extensions 개발 문서와 MCP Extensions 규격을 보면 각각 별도의 진입점으로 정의되어 있다.
| 기능 | 개발 규격에서의 이름 | 실제 동작 |
|---|---|---|
| 사이드바 앱 | Global entrypoint | 왼쪽의 앱 진입점에서 열어 전체 화면에 가깝게 작업 |
| 대화 옆 패널 | Thread entrypoint | 현재 대화 스레드의 콘텐츠 탭으로 앱을 열어 대화와 함께 사용 |
| 메시지 내부 UI | Inline MCP App | ChatGPT의 특정 답변 안에 카드·표·위젯 등을 표시 |
| 파일 뷰어·편집기 | File entrypoint | 지원하는 파일을 열 때 플러그인의 전용 뷰어 제공 |
그러니까 ’플러그인 UI가 있다’는 말만으로는 원하는 화면이 어디에 나타나는지 알 수 없다. 내가 궁금했던 대화 오른쪽에 같이 열리는 화면은 Thread entrypoint, 즉 Conversation panel에 해당한다.
예를 들어 문서를 읽으며 대화로 수정 지시를 하고, 옆 패널에서 결과를 확인하는 식의 활용이 가능하다. 이미지 목록을 보며 하나를 선택하거나, 프로젝트 항목을 검토하는 작업에도 적합하다. 이런 활용 예시는 기능의 가능성을 설명한 것이지 모든 플러그인이 이미 지원한다는 뜻은 아니다.

3. 일반 사용자라면 실제로 어떻게 열까?
직접 시험해 볼 방법도 있다. OpenAI는 확장 기능의 예시로 Bits & Bolts Remote라는 데모 플러그인을 안내한다. CAD 부품 라이브러리를 다루는 예제지만, 플러그인 UI가 ChatGPT에 들어가는 방식을 확인하기에 알맞다.
일단 다음 순서로 시도하면 된다.
- 공식 Plugin Extensions 문서의 Try it out에서 Install Bits & Bolts Remote를 선택한다.
- ChatGPT 플러그인 설치를 마치고, 웹에서는 일반 Chat 대신 Work 모드로 새 대화를 연다.
- 왼쪽 사이드바에서 Bits & Bolts Remote를 찾으면 Parts Library 같은 전용 앱 화면을 열어본다.
- 해당 플러그인을 사용하는 대화에서 Parts Tray처럼 대화 스레드의 콘텐츠 탭으로 제공되는 진입점이 있는지도 확인한다.
- 화면이 열린다면 대화와 앱을 함께 사용하면서 부품 선택·조회 등의 동작을 시험한다.
여기서 주의할 점이 있다. 3번의 Parts Library는 사이드바의 Global entrypoint, 4번의 Parts Tray는 Thread entrypoint 예시다. 사이드바 앱이 열렸다고 해서 대화 옆 패널까지 반드시 나타난다고 볼 수는 없다. Parts Tray라는 이름은 공식 규격의 예시로 등장하지만, 실제 버튼 위치나 표시 여부는 지원 환경과 앱 버전에 따라 달라질 수 있다.
데모를 설치하지 않더라도 자신이 쓰는 플러그인이 해당 UI를 제공한다면 같은 원리로 사용할 수 있다. 반대로 도구 목록만 있는 MCP는 아무리 호출해도 오른쪽에 별도 관리 화면이 자동으로 생기지는 않는다.
4. 왜 내 ChatGPT에는 오른쪽 패널이 안 보일까?
가장 중요한 부분이다. 기능이 발표됐다는 것과 내 환경에서 바로 쓸 수 있다는 것은 다른 문제다.
OpenAI MCP Extensions 규격의 플랫폼 지원 표는 웹 지원 환경을 Work 브라우저라고 설명하면서 기존 ChatGPT Chat은 제외한다고 명시한다. 따라서 웹 Chat 모드에서 평소처럼 MCP를 실행해도 오른쪽 패널이 나타나지 않을 수 있다.
| 사용 환경 | 확인할 점 |
|---|---|
| ChatGPT 웹 Work | 공식 규격상 대화 패널을 지원하는 웹 환경 |
| ChatGPT 웹 일반 Chat | 해당 웹 지원 범위에서 제외되는 것으로 명시됨 |
| ChatGPT 데스크톱 앱 | Global·Thread 진입점 지원. 파일용 진입점도 지원 |
| iOS·Android | 규격에 Thread 진입점 지원으로 표기. 모바일 화면 배치는 데스크톱과 다를 수 있음 |
| 웹 Free·Go | 개발 문서에서 확장 기능 제공 예정으로 안내 |
공식 발표의 ’모든 플랜에서 이용 가능’이라는 큰 설명과, 개발 문서의 웹 Free·Go 관련 안내가 얼핏 달라 보일 수 있다. 여기서는 기본 플러그인 기능과 특정 UI 확장 기능의 제공 시점을 구분하는 편이 정확하다. 계정, 워크스페이스 정책, 클라이언트와 배포 시점에 따라서도 화면은 달라질 수 있다.
패널이 보이지 않는다면 ’기능이 가짜인가?’부터 의심할 것이 아니라 Work 모드인지, 플러그인이 UI 진입점을 구현했는지, 현재 플랫폼에서 지원하는지를 먼저 확인해야 한다.
5. 커스텀 MCP라면 어떻게 구현할까?
직접 MCP 서버를 운영하는 사람에게는 이쪽이 더 중요하다. 이미 연결한 서버가 있다면 이름이나 플러그인 아이콘만 바꾸는 것으로는 부족하다. 서버가 열어줄 UI 리소스와 진입점 정보를 별도로 등록해야 한다.
OpenAI의 구현은 기본적으로 MCP Apps의 UI 리소스 방식을 바탕으로 한다. 서버가 도구를 노출하고, 도구의 메타데이터에 HTML UI를 나타내는 resourceUri를 연결한다. 플러그인 확장 기능에서는 그 도구에 thread나 global 진입점을 추가할 수 있다.
대화 옆 패널용 메타데이터를 단순화하면 다음과 같은 모습이다.
{
"name": "example.open_panel",
"title": "Example Panel",
"inputSchema": {
"type": "object",
"properties": {}
},
"_meta": {
"ui": {
"resourceUri": "ui://example/panel"
},
"openai/ui": {
"entrypoints": [
{ "type": "thread" }
]
}
}
}
이 JSON 하나만 붙여 넣는다고 곧바로 패널이 나타나는 것은 아니다. 서버에 ui://example/panel 리소스가 실제로 존재해야 하고, 그 리소스가 실행할 UI 내용도 제공해야 한다. 화면이 서버 기능을 다시 호출해야 한다면 MCP Apps 통신 부분 역시 필요하다. 위 예시는 메타데이터의 형태를 보여주는 최소 예제다.
대신 앱을 왼쪽 사이드바에서 실행하고 싶다면 entrypoints의 유형으로 global을 사용한다. 하나의 플러그인에서 역할이 다른 도구들로 두 진입점을 모두 제공할 수도 있다. 공식 규격은 이러한 진입점이 각각 어떤 방식으로 열리는지 정의해 놓았다.

이미 돌아가는 MCP를 ChatGPT에 연결하는 절차
OpenAI의 연결·테스트 안내에서 제시하는 기본 흐름은 다음과 같다.
- MCP 서버를 공개 HTTPS 엔드포인트 또는 Secure MCP Tunnel로 연결 가능한 상태로 만든다.
- ChatGPT의 Plugins에서 를 눌러 Add custom MCP server를 선택한다.
- 서버 이름·설명을 입력하고 HTTPS 주소 또는 터널을 선택한다. 필요한 인증과 보안 안내를 처리한다.
- Create as a plugin으로 생성한 뒤 설치한다.
- 새 대화에서
@로 플러그인을 선택하고 도구·UI 호출을 시험한다. - 서버의 도구나 UI 메타데이터를 변경했다면 서버를 재배포하거나 재시작한 후, ChatGPT 플러그인 연결 화면에서 Refresh를 실행한다.
- 변경된 진입점이 반영됐는지 새 대화에서 다시 확인한다.
메뉴 명칭은 계정이나 UI 업데이트에 따라 다를 수 있다. 특히 Secure MCP Tunnel은 개인 개발과 테스트에 사용할 수 있지만, 공개 디렉터리에 제출할 플러그인에는 안정적인 공개 HTTPS 엔드포인트가 따로 요구된다는 점도 알아둘 만하다.
공식 SDK도 제공된다. TypeScript는 @openai/mcp-extensions을, Python은 openai-mcp-extensions을 참고하면 된다. 코드를 수정하기 전에는 현재 사용하는 MCP SDK와 앱 프로토콜 버전의 호환성을 확인하는 것이 좋겠다.
6. 실제로 보고된 문제도 있다
이 기능은 발표된 지 얼마 되지 않았고, 개발자들이 직접 부딪힌 문제도 공개적으로 올라왔다.
대화 옆 앱에서 링크를 열 때 다른 탭으로 이동하는 문제. 2026년 10월 초 OpenAI MCP Extensions GitHub 이슈 #37에는 Work 웹의 앱 화면에서 만든 링크가 기존 패널을 재활용하기보다 별도 브라우저 탭을 여는 사례가 기록됐다. 제보자는 별도의 수동 Thread 진입점 제어까지 검증한 것은 아니라고 선을 그었다.
데스크톱 앱의 특정 대화에서 도구 호출이 실패하는 문제. Codex GitHub 이슈 #50152에는 2026년 10월 2일 macOS 환경에서 일부 오래된 대화의 MCP 앱 패널이 thread not found 오류를 내며 열리지 않는 사례가 올라왔다. 다른 대화에서는 정상 동작하기 때문에 모든 사용자에게 발생하는 문제라고 일반화할 수는 없다.
UI 리소스를 정상 읽었는데도 빈 화면이 나타나는 문제. Codex GitHub 이슈 #47512에서는 Windows 데스크톱에서 HTML UI 리소스를 새 버전으로 교체하고 다시 열 때 간헐적으로 패널이 비어 보였다는 보고도 찾을 수 있다.
이 사례들은 ’기능이 동작하지 않는다’는 결론을 내리기 위한 것이 아니라, 플러그인 도구 호출의 성공과 패널 UI 렌더링의 성공은 서로 다른 문제일 수 있다는 점을 보여준다. 실제 앱을 만들 때는 도구뿐 아니라 패널의 열기·닫기, 새 대화 전환, 링크 이동, 재연결 동작도 함께 시험해야 한다.
7. 무엇이 달라진 걸까?
내가 이번 변화를 흥미롭게 본 이유는 단순히 화면이 하나 더 생겼기 때문이 아니다.
예전에는 AI에게 문서를 찾아달라고 하면 결과를 채팅창에서 받아보고, 그다음 앱이나 웹사이트를 별도로 열어야 했다. 이제는 기능을 지원하는 플러그인이라면 채팅에서는 설명과 요청을 주고받고, 옆 화면에서는 실제 항목을 선택하고 확인하는 흐름을 만들 수 있다.
그렇다고 모든 MCP가 웹앱처럼 변하는 것은 아니다. API만 호출하는 도구는 여전히 API 도구로 잘 동작하고, UI가 필요하지 않은 작업에는 그편이 더 간단할 수 있다. 또한 패널이 있다고 해서 사용자 승인이나 서버의 접근 권한 검사를 우회하는 것은 아니다.
정리하면 세 가지다.
- 오른쪽 플러그인 패널은 실제로 존재하는 Conversation panels / Thread entrypoint 기능이다.
- 웹에서는 Work 모드와 플러그인의 UI 지원 여부가 핵심 조건이다. 일반 Chat 모드나 모든 커스텀 MCP에 자동으로 붙는 기능은 아니다.
- 사용자는 Bits & Bolts Remote로 시험해 볼 수 있고, 개발자는 MCP Apps UI 리소스와
thread진입점을 구현해야 한다.
기능이 마음에 든다면 바로 커스텀 서버를 대대적으로 바꾸기보다 공식 데모부터 열어보는 편이 낫겠다. 실제 화면 구성이 원하는 작업 방식에 맞는지 확인하고 나서 구현 범위를 결정해도 늦지 않다.