ChatGPT 앱 생태계, 앱은 이제 호출된다

ChatGPT 앱 생태계, 앱은 이제 호출된다

앱은 더 이상 “찾아 여는 것”만이 아니다

ChatGPT 안의 앱을 이해할 때 가장 먼저 버려야 할 전제는 “또 하나의 앱스토어가 생겼다”는 단순한 해석이다. 물론 사용자는 여전히 특정 서비스를 발견하고, 연결하고, 권한을 승인하고, 결과 화면을 본다. 그러나 본질적 변화는 실행 주체의 이동에 있다. 기존 모바일·웹 앱에서는 사용자가 앱을 고르고, 메뉴를 탐색하고, 폼을 채우고, 버튼을 누른다. ChatGPT 앱에서는 사용자의 의도가 먼저 자연어로 표현되고, 모델이 그 의도를 해석한 뒤 적절한 외부 도구와 UI를 호출한다. 앱은 독립 실행 화면이 아니라 대화의 한 장면, 에이전트 작업 흐름의 한 도구, 그리고 결과 검토용 인터페이스로 들어온다. OpenAI 문서가 Apps SDK를 “ChatGPT를 확장하는 앱”으로 설명하면서도 그 기반을 Model Context Protocol, 즉 MCP에 둔 이유가 여기에 있다. 출처: Apps SDK | OpenAI Developers, MCP – Apps SDK | OpenAI Developers

이 변화는 PM·전략 담당자에게 특히 중요하다. ChatGPT 앱은 기존 앱을 대체하는 별도 클라이언트가 아니라, 사용자의 문제 해결 과정 안에서 호출되는 서비스 표면이다. 예를 들어 “이번 주 경쟁사 언급량과 긍부정 추이를 보고, 다음 캠페인 메시지를 잡아줘”라는 요청이 들어오면 ChatGPT는 소셜 분석 앱의 MCP 도구를 호출하고, 구조화된 데이터를 받아 요약하며, 필요하면 iframe 기반 UI로 차트나 필터를 보여줄 수 있다. 사용자는 “소셜 분석 SaaS에 로그인 → 메뉴 진입 → 키워드 입력 → 기간 설정 → 그래프 해석 → 보고서 작성”을 순서대로 수행하지 않는다. 의도를 말하고, 에이전트가 필요한 서비스를 부른다. 국내에서도 썸트렌드가 ChatGPT Apps 생산성 카테고리에 진입했다는 보도는 이런 데이터 서비스가 생성형 AI 생태계 안의 호출 가능한 기능으로 재배치되는 흐름을 보여준다. 출처: “챗GPT에 ‘요즘 뭐 뜨냐’ 물으면 바로 나온다”…썸트렌드

기존 앱·플러그인·API 연동과 무엇이 다른가

비교의 핵심은 “화면 중심인가, 의도 중심인가”다. 전통적 앱은 사용자가 직접 조작하는 화면 묶음이다. API 연동은 개발자가 사전에 정한 시스템 간 호출이다. 과거 플러그인이나 GPT Actions는 자연어와 외부 API 사이를 연결하는 중요한 전환점이었지만, 대체로 “API 호출을 자연어 뒤에 숨기는” 성격이 강했다. OpenAI의 GPT Actions 문서도 개발자가 API 스키마와 인증을 설정하면 ChatGPT가 자연어 질문과 API 계층 사이의 다리 역할을 한다고 설명한다. 반면 Apps SDK의 핵심은 도구 호출, 구조화된 결과, 그리고 임베디드 UI가 하나의 대화형 작업 흐름 안에 결합된다는 점이다. 출처: GPT Actions, Build your MCP server – Apps SDK

구분 기존 앱 일반 API 연동 GPT Actions/플러그인형 연동 ChatGPT Apps SDK 기반 앱
실행 출발점 사용자의 앱 선택 시스템 로직 자연어 요청 자연어 의도 + 모델의 도구 선택
주요 인터페이스 전체 화면 UI API 응답 텍스트 중심 응답 대화 + 구조화 데이터 + iframe UI
통합 단위 앱/페이지 엔드포인트 액션/API 스키마 MCP 도구, 리소스, UI 컴포넌트
사용자 역할 직접 탐색·입력 보통 없음 요청·승인 요청, 검토, 승인, 후속 지시
사업자 과제 앱 설치·재방문 개발자 채택 GPT 안 API 노출 에이전트가 잘 고르는 도구 설계와 UI 경험

따라서 ChatGPT 앱을 “우리 API를 ChatGPT에 붙이는 일”로만 보면 절반만 본 것이다. API는 여전히 필요하지만, 제품 설계의 기준이 달라진다. 도구 설명은 모델이 이해할 수 있어야 하고, 입력·출력 스키마는 에이전트가 실수 없이 호출할 수 있어야 하며, UI는 사용자가 대화 흐름을 끊지 않고 판단할 수 있어야 한다. Apps SDK 문서는 MCP 서버가 도구 목록을 제공하고, 모델이 도구를 호출하며, 서버가 구조화된 결과와 UI 메타데이터를 반환하는 구조를 설명한다. 이는 API 문서의 사람이 읽는 설명이 아니라, 모델이 실행 계획에 포함할 수 있는 계약으로 API를 재정의하는 일에 가깝다. 출처: MCP – Apps SDK | OpenAI Developers

아키텍처로 보면: 모델, MCP 서버, 앱 UI의 삼각 구조

ChatGPT 앱의 기본 흐름은 단순하지만 함의는 크다. 사용자가 대화창에 요청을 입력하면 ChatGPT 모델은 해당 요청을 해결하기 위해 외부 도구가 필요한지 판단한다. 필요하다고 판단하면 MCP 도구 호출을 만들고, 서비스 사업자가 운영하는 MCP 서버가 실제 API·데이터베이스·업무 시스템을 호출한다. 서버는 결과를 `structuredContent`, `_meta`, `content` 같은 형태로 반환할 수 있고, ChatGPT는 도구 descriptor에 연결된 HTML 템플릿을 로드해 iframe 안에서 UI를 보여준다. 이 UI는 MCP Apps bridge를 통해 도구 입력과 결과를 전달받고, 필요하면 다시 도구를 호출할 수 있다. 출처: Build your MCP server – Apps SDK

사용자 의도
   ↓
ChatGPT 모델
   ↓  도구 선택·인자 생성
MCP tool call
   ↓
서비스 사업자의 MCP 서버
   ↓  내부 API·DB·권한 시스템 호출
Tool response: structuredContent / content / _meta
   ↓
대화 응답 + iframe 앱 UI
   ↓
사용자 검토·승인·후속 지시

이 구조에서 중요한 것은 UI가 모델 응답의 장식물이 아니라는 점이다. OpenAI 문서는 ChatGPT가 도구 descriptor에 연결된 HTML 템플릿을 로드하고, 도구 입력·결과를 iframe에 전달한다고 설명한다. 즉 앱 UI는 “대화 중 삽입되는 작은 웹앱”에 가깝다. 차트, 상품 목록, 일정 후보, 예약 확인, 파일 선택, 결제 확인처럼 텍스트만으로는 판단이 어려운 장면에서 UI가 개입한다. 그러나 전체 사용자 여정은 여전히 대화가 잡고 있다. 이 조합은 특히 SaaS, 커머스, 생산성 도구에 적합하다. 사용자는 자연어로 목표를 말하고, 앱 UI는 확인·비교·선택·승인이라는 고밀도 순간을 담당한다. 출처: MCP Apps compatibility in ChatGPT – Apps SDK, Reference – Apps SDK

MCP는 왜 핵심인가: 앱 생태계의 공용 어댑터

MCP는 ChatGPT 앱을 특정 벤더 전용 플러그인으로만 보지 않게 만드는 핵심 레이어다. OpenAI 문서는 MCP를 대규모 언어 모델 클라이언트가 외부 도구와 리소스에 연결되도록 하는 공개 명세라고 설명한다. MCP 서버는 모델이 대화 중 호출할 수 있는 도구를 노출하고, 지정된 파라미터에 따라 결과를 반환한다. Apps SDK에서 MCP는 서버, 모델, UI를 동기화하는 백본 역할을 한다. 도구의 입력·출력 계약, 인증, 메타데이터, UI 리소스 연결이 이 프로토콜 위에서 정리된다. 출처: MCP – Apps SDK | OpenAI Developers

사업자 입장에서 MCP의 전략적 가치는 “한 AI 플랫폼용 임시 연동”을 넘어선다. 문서상 ChatGPT는 MCP Apps의 iframe-and-bridge 모델을 구현하고, UI는 `ui/*` JSON-RPC over `postMessage` 방식으로 호스트와 통신한다. OpenAI는 표준 키와 브리지를 우선 사용하고, ChatGPT 특화 기능이 필요할 때 `window.openai` 확장을 계층적으로 얹으라고 권장한다. 이는 웹 표준과 브라우저 벤더 확장의 관계와 비슷하다. 기본 기능은 이식성을 확보하고, 특정 플랫폼의 강점은 옵션으로 활용한다. 출처: MCP Apps compatibility in ChatGPT – Apps SDK

실무적으로는 API 게이트웨이 옆에 “AI 호출 게이트웨이”가 하나 더 생긴다고 보는 편이 정확하다. 기존 API 게이트웨이가 인증, 속도 제한, 라우팅, 로깅을 담당했다면 MCP 서버는 모델이 이해할 수 있는 도구 설명, 안전한 호출 범위, 구조화된 결과, UI 리소스 연결까지 담당한다. 따라서 플랫폼/백엔드 팀은 단순히 REST API를 열어두는 것이 아니라, 어떤 기능을 에이전트에게 도구로 공개할지, 어떤 작업은 반드시 사용자 승인을 요구할지, 어떤 결과는 모델에게 보이고 어떤 데이터는 UI에만 둘지 설계해야 한다.

권한·승인 흐름: 에이전트 시대의 신뢰 설계

앱이 대화 안에서 호출될수록 권한 설계는 더 중요해진다. 사용자가 버튼을 직접 누르던 환경에서는 “사용자가 이 행동을 했다”는 증거가 비교적 명확했다. 에이전트 환경에서는 모델이 사용자의 의도를 해석해 도구 호출을 제안하거나 수행한다. 이때 서비스 사업자는 읽기, 쓰기, 결제, 발송, 삭제, 공유 같은 행동을 같은 수준으로 취급해서는 안 된다. 검색·조회는 낮은 위험, 장바구니 구성이나 초안 생성은 중간 위험, 결제·발송·게시·삭제는 높은 위험으로 분류하고 사용자 확인 단계를 명확히 둬야 한다.

Apps SDK 문서의 내비게이션만 보아도 인증, 상태 관리, 보안·개인정보, 앱 제출 가이드라인이 별도 축으로 분리되어 있다. 이는 ChatGPT 앱이 “보여주기용 위젯”이 아니라 실제 서비스 계정과 데이터, 외부 API를 다루는 실행 표면이라는 뜻이다. GPT Actions 문서 역시 제3자 앱 인증을 통해 API 호출이 수행될 수 있음을 설명한다. Apps SDK 기반 앱에서는 여기에 더해 UI와 도구 호출이 결합되므로, 사용자에게 “무엇을 읽는지, 무엇을 바꾸는지, 어떤 계정 권한으로 실행되는지”를 더 명확히 보여줘야 한다. 출처: Apps SDK | OpenAI Developers, GPT Actions

좋은 승인 흐름은 사용자를 귀찮게 하지 않으면서도 책임 경계를 흐리지 않는다. 예를 들어 커머스 앱이라면 “선호 조건에 맞는 상품 추천”은 자동 호출할 수 있지만, 결제 직전에는 상품, 가격, 배송지, 결제수단, 판매자, 환불 조건을 UI로 확인시켜야 한다. 생산성 도구라면 “회의록 초안 작성”은 자동화할 수 있지만, “외부 참석자에게 이메일 발송”은 명시적 승인을 받아야 한다. SaaS 분석 도구라면 “보고서 생성”은 가능하더라도, “대시보드를 전사 공유”하거나 “데이터 소스를 연결”하는 행위는 별도 권한 단계를 요구해야 한다. 에이전트가 똑똑해질수록 승인 UX는 줄어드는 것이 아니라 더 정교해진다.

UI가 대화에 결합된다는 것의 제품적 의미

ChatGPT 앱의 UI는 기존 SaaS 화면을 그대로 iframe에 욱여넣는 공간이 아니다. 대화 흐름 안의 UI는 세 가지 역할을 해야 한다. 첫째, 모델이 수행한 작업의 근거를 사용자가 빠르게 검토하게 해야 한다. 둘째, 선택지가 많을 때 비교·필터·정렬을 제공해야 한다. 셋째, 위험한 실행 전에는 승인을 분명히 받아야 한다. OpenAI 문서는 MCP Apps UI가 iframe 안에서 실행되고 표준 bridge로 호스트와 통신한다고 설명한다. 따라서 UI는 웹앱의 유연성을 가지지만, 사용 맥락은 일반 웹앱보다 훨씬 좁고 집중적이다. 출처: MCP Apps compatibility in ChatGPT – Apps SDK

이 차이를 모르면 실패한다. 예를 들어 기존 CRM의 모든 메뉴를 ChatGPT 앱 UI로 가져오는 것은 좋은 전략이 아니다. 사용자가 “지난 분기 이탈 위험 고객을 보고, 이번 주 연락 우선순위를 잡아줘”라고 말했을 때 필요한 UI는 전체 CRM이 아니라 우선순위 리스트, 판단 근거, 담당자 배정, 메시지 초안, 발송 승인이다. 검색 서비스라면 전체 검색 결과 페이지가 아니라 출처별 묶음, 신뢰도 힌트, 후속 질문 버튼, 비교 표가 중요하다. 커머스라면 카테고리 홈이 아니라 조건에 맞춘 후보, 재고·배송·가격·리뷰 요약, 장바구니 확인이 중요하다.

즉 ChatGPT 앱 UI는 “축소된 앱”이 아니라 “에이전트가 만든 중간 결과를 사람이 판단하기 위한 작업 패널”에 가깝다. PM은 기존 IA를 그대로 옮길 것이 아니라, 자연어 요청 이후 사용자가 어떤 결정을 내려야 하는지부터 역산해야 한다. 사용자가 앱 안에서 탐색하는 시간이 줄어들수록, UI의 가치는 탐색이 아니라 판단 지원으로 이동한다.

Agents SDK와 Apps SDK: 제품 안 에이전트와 ChatGPT 안 앱의 역할 분담

OpenAI의 Agents SDK는 코드로 에이전트를 만들고, 도구 호출, 오케스트레이션, 승인, 상태를 애플리케이션이 소유해야 할 때 쓰는 개발자 도구다. 공식 문서는 에이전트를 계획하고, 도구를 호출하고, 여러 전문 에이전트가 협업하며, 다단계 작업을 완료할 만큼 상태를 유지하는 애플리케이션으로 설명한다. 또한 한 번의 모델 호출과 도구, 애플리케이션 소유 로직으로 충분하면 Responses API를 쓰고, 오케스트레이션·도구 실행·승인·상태를 애플리케이션이 소유해야 한다면 Agents SDK 문서를 보라고 안내한다. 출처: Agents SDK | OpenAI API

Apps SDK와 Agents SDK의 관계는 경쟁이 아니라 배치 위치의 차이다. Apps SDK는 ChatGPT라는 호스트 안에서 외부 서비스가 호출되고 UI를 렌더링하는 방법에 초점을 둔다. Agents SDK는 기업이나 개발자가 자기 제품 안에 에이전트 워크플로를 구현할 때 중요하다. 예를 들어 회계 SaaS가 자체 제품 안에 “월마감 에이전트”를 넣는다면 Agents SDK 성격의 오케스트레이션이 필요하다. 반대로 사용자가 ChatGPT에서 “이번 달 비용 이상치를 찾아 설명해줘”라고 요청했을 때 그 회계 SaaS의 도구와 UI가 호출되게 하려면 Apps SDK와 MCP 노출 전략이 중요하다.

전략적으로는 둘을 함께 봐야 한다. 앞으로 많은 서비스는 “우리 제품 안의 에이전트”와 “외부 AI 플랫폼 안에서 호출되는 우리 서비스”를 동시에 운영하게 된다. 전자는 고객 유지와 깊은 업무 자동화를 담당하고, 후자는 발견·유입·경량 실행·크로스앱 워크플로 참여를 담당한다. 백엔드 입장에서는 같은 핵심 도메인 기능을 내부 에이전트, 외부 ChatGPT 앱, 파트너 API가 공유할 수 있도록 권한·감사·스키마·이벤트 로그를 정리해야 한다.

왜 OpenAI는 ChatGPT를 앱 실행 공간으로 확장하려 하는가

OpenAI의 플랫폼 전략을 한 문장으로 요약하면, ChatGPT를 “답변 인터페이스”에서 “작업 실행 인터페이스”로 확장하는 것이다. 답변만 제공하는 AI는 사용자가 다시 다른 앱으로 이동해야 가치를 완성한다. 반면 앱 호출과 UI 렌더링, 권한 승인, 외부 API 실행이 결합되면 ChatGPT 안에서 검색, 비교, 예약, 구매, 분석, 작성, 발송 같은 업무가 이어질 수 있다. OpenAI 개발자 사이트가 API Platform, Codex, Apps SDK, Agents SDK, tools, ChatKit, commerce 흐름을 함께 배치하는 것도 같은 방향을 보여준다. 출처: Showcase | OpenAI Developers, Apps SDK | OpenAI Developers

이 전략의 핵심은 체류시간 자체보다 “의도 레이어” 장악이다. 사용자가 어떤 서비스를 열지 결정하기 전에, 먼저 AI에게 문제를 설명한다면 AI 플랫폼은 서비스 선택의 관문이 된다. 검색엔진이 웹페이지 발견의 관문이었고, 앱스토어가 모바일 앱 설치의 관문이었다면, 에이전트 플랫폼은 작업 수행 도구 선택의 관문이 될 수 있다. 사용자는 “어떤 앱을 써야 하지?”보다 “이 일을 끝내줘”라고 말한다. 이때 호출되는 앱은 브랜드 인지도, 가격, 데이터 품질, 권한 상태, 응답 속도, 도구 설명의 정확도, 결과 UI의 유용성에 따라 선택될 가능성이 커진다.

다만 “모든 앱이 ChatGPT로 대체된다”는 식의 결론은 과하다. 깊은 설정, 장시간 탐색, 복잡한 관리자 작업, 고유 커뮤니티 경험, 고빈도 전문 워크플로는 여전히 독립 앱의 장점이 크다. 변화의 본질은 대체가 아니라 진입점의 다변화다. 사용자는 어떤 일은 독립 앱에서 하고, 어떤 일은 ChatGPT에서 앱을 호출해 끝낸다. 사업자는 자사 앱의 모든 기능을 옮기려 하기보다, AI 대화 안에서 호출될 때 가장 가치가 큰 “작업 단위”를 선별해야 한다.

SaaS·커머스·검색·생산성 도구는 무엇을 준비해야 하나

SaaS 사업자의 첫 과제는 기능 목록을 “도구 목록”으로 재해석하는 것이다. 예를 들어 프로젝트 관리 도구라면 `프로젝트 검색`, `태스크 생성`, `마감 위험 분석`, `담당자별 병목 요약`, `주간 리포트 생성`이 각각 도구 후보가 된다. 중요한 것은 화면 메뉴명이 아니라 사용자의 의도다. “태스크 생성 API”보다 “회의 내용에서 실행 항목을 뽑아 담당자와 마감일 후보까지 제안”하는 도구가 에이전트 환경에 더 맞다. 도구의 입력은 자연어 의도에서 안정적으로 추출될 수 있어야 하고, 출력은 모델이 요약·비교·후속 작업에 활용할 수 있도록 구조화되어야 한다.

커머스 사업자는 발견과 전환 사이의 경계가 흐려지는 것에 주목해야 한다. 사용자가 “출장용으로 가볍고 배터리 오래가는 노트북 추천해줘”라고 말하면 AI는 검색, 비교, 리뷰 요약, 재고 확인, 장바구니 구성을 하나의 흐름으로 묶을 수 있다. OpenAI Apps SDK 문서에는 conversion apps 영역으로 restaurant reservation spec과 product checkout spec이 분리되어 있으며, ChatGPT 특화 확장 예시로 Instant Checkout 같은 흐름도 언급된다. 다만 Instant Checkout은 restaurant reservation·product checkout spec(개발 규격)과 층위가 다른 소비자 대상 라이브 결제 기능으로, 현재는 미국·일부 승인 파트너(예: Etsy, Shopify 등) 중심의 제한적 베타 단계임에 유의해야 한다. 이는 커머스 앱이 단순 광고 랜딩이나 상품 피드 제공을 넘어, 대화 안 구매 의사결정과 승인 UX를 설계해야 함을 시사한다. 출처: Apps SDK | OpenAI Developers, MCP Apps compatibility in ChatGPT – Apps SDK

검색 서비스와 데이터 플랫폼은 “결과 링크”보다 “근거 있는 답변 재료”가 중요해진다. AI가 검색 결과를 대신 읽고 요약할수록, 서비스의 차별점은 색인 규모만이 아니라 신뢰 가능한 구조화 데이터, 최신성, 출처 투명성, 필터링 가능성, 재현 가능한 쿼리 결과가 된다. 소셜 분석, 시장조사, 특허 검색, 법률·논문 검색 같은 전문 검색 서비스는 ChatGPT 앱 안에서 “AI가 일반 웹으로는 얻기 어려운 고품질 데이터 도구”로 자리 잡을 수 있다. 다만 결과를 모델에게 너무 많이 넘기면 비용·지연·프라이버시 문제가 생긴다. 요약 가능한 구조화 결과와 UI에서만 보여줄 상세 데이터를 분리하는 설계가 필요하다.

생산성 도구는 크로스앱 워크플로에 대비해야 한다. 캘린더, 이메일, 문서, 협업툴, 노트, 파일 저장소는 개별 앱으로도 중요하지만, 사용자가 실제로 원하는 것은 “다음 회의 준비”, “지난 논의 요약”, “고객사 제안서 초안”, “이번 주 우선순위 정리”처럼 여러 앱을 가로지르는 결과다. 이런 환경에서는 단일 앱의 폐쇄성이 약점이 될 수 있다. 반대로 권한과 데이터 경계를 잘 유지하면서도 AI가 안전하게 호출할 수 있는 도구를 제공하는 서비스는 에이전트 워크플로의 필수 부품이 된다.

실무 시나리오 4가지: 어떻게 호출되는가

1. B2B SaaS 분석 리포트

상황: 마케팅 PM이 “지난 2주간 우리 브랜드와 경쟁사 A의 언급량, 감성, 주요 이슈를 비교하고 다음 캠페인 메시지를 제안해줘”라고 요청한다.

실행 흐름: ChatGPT가 소셜 분석 앱의 MCP 도구를 선택한다. 도구는 브랜드, 경쟁사, 기간, 채널 같은 인자를 받아 분석 서버를 호출한다. 서버는 언급량, 감성 분포, 상위 키워드, 대표 게시물 링크, 신뢰도 메타데이터를 구조화해 반환한다. iframe UI는 추이 그래프와 필터를 보여주고, 모델은 핵심 인사이트와 캠페인 메시지 후보를 정리한다.

주의점: 원문 게시물, 개인정보, 내부 캠페인 데이터가 섞일 수 있으므로 모델에 제공할 요약 데이터와 UI에서만 노출할 상세 데이터를 분리해야 한다. 보고서 외부 공유는 승인 단계로 분리한다.

2. 커머스 상품 비교와 구매 (B2C 확장 예시)

상황: 사용자가 “재택근무용 32인치 모니터를 추천해줘. 맥북 연결, USB-C, 눈 피로 적은 제품이면 좋겠어”라고 말한다.

실행 흐름: ChatGPT가 커머스 앱 도구를 호출해 조건에 맞는 상품 후보를 가져온다. 모델은 사용자의 의도에 맞게 후보를 좁히고, UI는 가격, 배송, 재고, 핵심 스펙, 리뷰 요약을 표로 보여준다. 사용자가 하나를 고르면 장바구니 구성 도구가 호출되고, 결제 전 승인 UI가 뜬다. (단, ChatGPT 내 결제 연동은 현재 제한적 베타·승인 파트너 대상이므로, 일반 가용 기능이 아니라 ‘가능한 흐름’으로 이해해야 한다.)

주의점: 추천 근거와 광고·스폰서 노출 여부를 구분해야 한다. 결제, 주소 사용, 쿠폰 적용, 구독 전환은 명시적 확인이 필요하다.

3. 생산성 도구의 회의 준비

상황: 사용자가 “오후 고객 미팅 준비해줘. 지난 메일, 문서, 이슈를 보고 핵심 쟁점과 질문 목록을 뽑아줘”라고 요청한다.

실행 흐름: ChatGPT가 캘린더, 이메일, 문서 관리 도구를 순차적으로 호출한다. 각 도구는 권한 범위 안에서 관련 이벤트, 메일 스레드, 문서 링크, 최근 변경 사항을 반환한다. 모델은 의제를 만들고, UI는 출처별 근거와 미확인 항목을 표시한다.

주의점: 사용자가 접근 권한이 없는 문서를 모델이 우회적으로 추론해서는 안 된다. 참석자에게 자료를 발송하는 단계는 별도 승인으로 분리한다.

4. 개발·운영 도구의 장애 대응

상황: 엔지니어가 “어제 밤 결제 실패율이 오른 원인을 찾아줘”라고 요청한다.

실행 흐름: ChatGPT가 모니터링, 로그, 배포 이력, 이슈 트래커 도구를 호출한다. 에이전트는 시간대별 오류율, 관련 배포, 상위 에러 코드, 영향을 받은 고객군을 조합해 가설을 만든다. UI는 타임라인과 로그 샘플, 롤백 후보를 보여준다.

주의점: 조회와 변경을 분리해야 한다. 롤백, 설정 변경, 고객 공지 발송은 고위험 작업이므로 승인·감사 로그·권한 확인이 필수다. Agents SDK 문서가 애플리케이션이 오케스트레이션, 도구 실행, 승인, 상태를 소유해야 하는 경우를 별도 영역으로 설명하는 이유가 이런 장면과 맞닿아 있다. 출처: Agents SDK | OpenAI API

앱스토어·검색엔진·API 경제에 미칠 영향

첫째, 앱 발견 방식이 바뀐다. 모바일 앱스토어에서는 사용자가 카테고리를 둘러보거나 검색어를 입력해 앱을 설치했다. 검색엔진에서는 키워드와 링크가 중심이었다. 에이전트 플랫폼에서는 “의도에 적합한 도구”가 발견 단위가 된다. 따라서 앱 사업자는 앱 이름 SEO뿐 아니라 도구 설명, 스키마 품질, 결과 신뢰도, 응답 속도, 권한 상태, UI 품질을 최적화해야 한다. 미래의 ASO는 일부 영역에서 “Agent Selection Optimization” 성격을 띨 수 있다. 단, 이는 확정된 공식 용어가 아니라 실무적 해석이다.

둘째, API 경제의 평가 기준이 바뀐다. 기존 API는 개발자가 문서를 읽고 통합했다. 이제는 모델이 도구 설명을 읽고 호출할 수 있어야 한다. 좋은 API가 좋은 MCP 도구가 되는 것은 아니다. 너무 범용적인 엔드포인트, 모호한 파라미터, 비결정적 응답, 과도한 권한 요구, 텍스트 덩어리 출력은 에이전트 환경에서 품질을 떨어뜨린다. 반대로 명확한 작업 단위, 좁은 권한, 구조화 출력, 재시도 안전성, 감사 가능한 실행 로그는 경쟁력이 된다.

셋째, 검색과 커머스의 중간 지대가 커진다. 사용자는 “정보를 찾는 것”과 “거래를 실행하는 것”을 분리하지 않을 수 있다. AI가 후보를 찾고, 비교하고, 질문하고, 장바구니를 만들고, 승인까지 이어주는 흐름에서는 검색 광고, 제휴, 마켓플레이스, 결제, CRM이 한 화면 안에서 만난다. OpenAI 개발자 문서에 Apps SDK와 Commerce, Ads 관련 영역이 함께 배치되어 있다는 점은 이런 방향성을 읽게 한다. 출처: OpenAI for Developers, Apps SDK | OpenAI Developers

넷째, 플랫폼 경쟁은 모델 성능만으로 결정되지 않는다. ChatGPT, Claude, Gemini 같은 AI 플랫폼 경쟁에서 중요한 축은 “얼마나 많은 고품질 도구와 신뢰 가능한 앱이 연결되는가”, “사용자 권한과 조직 거버넌스를 얼마나 잘 처리하는가”, “대화와 UI가 얼마나 자연스럽게 결합되는가”, “사업자가 플랫폼 종속을 얼마나 감당할 수 있는가”다. MCP 같은 표준화 흐름은 사업자에게 이식성을 제공하지만, 각 플랫폼의 확장 기능과 배포·노출 정책은 여전히 차이를 만든다.

사업자가 지금 해야 할 준비

첫 번째는 “AI 호출 가능 기능 목록”을 만드는 것이다. 전체 제품 기능을 나열하지 말고, 사용자가 자연어로 요청할 법한 업무 단위를 기준으로 정리한다. 각 항목마다 조회인지, 생성인지, 변경인지, 외부 발송인지, 결제인지 위험도를 붙인다. 그리고 자동 실행 가능한 작업, 승인 후 실행할 작업, ChatGPT 같은 외부 호스트에는 공개하지 않을 작업을 구분한다.

두 번째는 데이터 반환 구조를 정리하는 것이다. 에이전트가 쓰기 좋은 결과는 긴 HTML이나 PDF가 아니라 구조화된 필드다. 제목, 요약, 점수, 상태, 날짜, 출처, 권한, 다음 행동 후보가 명확해야 한다. 모델에게 보여줄 `structuredContent`는 간결해야 하고, 사용자가 자세히 봐야 하는 표·차트·리스트는 UI에서 다루는 편이 낫다. OpenAI 문서도 모델이 `structuredContent`를 읽어 무슨 일이 일어났는지 서술하므로 간결하고 재시도에 안전하게 유지하라고 설명한다. 출처: Build your MCP server – Apps SDK

세 번째는 권한과 감사 로그를 제품 요구사항으로 올리는 것이다. AI 앱 연동은 “개발자 생태계 확장”만의 문제가 아니라 보안·법무·CS·운영 정책의 문제다. 누가 어떤 대화에서 어떤 도구를 호출했는지, 어떤 데이터가 모델로 전달됐는지, 어떤 변경이 사용자 승인으로 실행됐는지 기록해야 한다. 특히 B2B SaaS는 조직 관리자 정책, 사용자별 권한, 데이터 보존, 외부 공유 제한을 ChatGPT 앱 호출에도 동일하게 적용해야 한다.

네 번째는 UI를 “작업 검토 패널”로 재설계하는 것이다. 기존 웹앱의 홈, 내비게이션, 설정, 상세 메뉴를 모두 넣으려 하지 말고, 사용자가 대화 중 내려야 하는 판단을 중심으로 설계한다. 좋은 ChatGPT 앱 UI는 짧은 시간 안에 “왜 이 결과가 나왔는지”, “무엇을 선택할 수 있는지”, “실행하면 무엇이 바뀌는지”를 보여준다. 특히 모바일 대화 환경에서는 더 압축된 정보 구조가 필요하다.

다섯 번째는 플랫폼 종속성과 표준 이식성의 균형을 잡는 것이다. OpenAI 문서는 MCP Apps 표준 키와 bridge를 기본으로 쓰고, ChatGPT 특화 기능은 필요할 때만 `window.openai` 확장으로 계층화하라고 권장한다. 이는 실무적으로 중요한 원칙이다. 초기에는 ChatGPT의 유통력이 매력적일 수 있지만, 장기적으로는 여러 AI 호스트에서 동일한 도구와 UI를 재사용할 가능성을 열어두는 편이 낫다. 출처: MCP Apps compatibility in ChatGPT – Apps SDK

피해야 할 오해

첫째, “ChatGPT 앱을 만들면 트래픽이 자동으로 온다”는 생각은 위험하다. 에이전트가 선택할 만한 명확한 작업 단위, 신뢰 가능한 데이터, 빠른 응답, 좋은 승인 UX가 없으면 호출될 이유가 약하다. 기존 앱스토어에서도 설치만으로 성공하지 않았듯, 에이전트 플랫폼에서도 연결만으로 성공하지 않는다.

둘째, “우리 API를 전부 열면 된다”는 접근도 위험하다. 모델에게 너무 많은 도구를 제공하면 선택 품질이 떨어지고, 권한 위험이 커지며, 유지보수가 어려워진다. 처음에는 고빈도·저위험·고가치 작업부터 시작하는 편이 낫다. 예를 들어 조회, 요약, 추천, 초안 생성은 좋은 출발점이다. 결제, 발송, 삭제, 권한 변경은 후순위로 두고 승인 흐름을 충분히 검증해야 한다.

셋째, “UI는 필요 없다”는 판단도 절반만 맞다. 텍스트 응답만으로 충분한 작업도 많지만, 비교·선택·검토·승인에는 UI가 필요하다. ChatGPT 앱의 차별점은 모델 응답과 UI가 함께 움직인다는 데 있다. 특히 커머스, 분석, 일정, 문서, 운영 도구는 텍스트만으로 사용자가 신뢰하기 어렵다.

넷째, “독립 앱은 사라진다”는 결론도 성급하다. 독립 앱은 여전히 깊은 탐색, 설정, 반복 업무, 고유 커뮤니티, 전문 시각화에서 강하다. ChatGPT 앱은 새로운 진입점이자 실행 표면이다. 핵심은 어떤 작업을 ChatGPT 안으로 보낼지, 어떤 경험은 자사 앱에 남길지 경계를 설계하는 것이다.

결론: 제품은 화면이 아니라 호출 가능한 능력으로 재정의된다

ChatGPT 앱 생태계의 가장 큰 의미는 앱의 단위가 바뀐다는 데 있다. 과거 앱은 아이콘, 화면, 메뉴, 세션으로 정의됐다. 이제 일부 앱은 “모델이 이해하고 호출할 수 있는 능력”으로 정의된다. Apps SDK는 그 능력을 ChatGPT 안에 UI와 함께 배치하는 프레임워크이고, MCP는 그 능력을 여러 AI 호스트가 이해할 수 있는 프로토콜로 정리하는 표준화 레이어다. Agents SDK는 기업이 자기 제품 안에서 더 복잡한 에이전트 워크플로를 구현할 때 필요한 코드 중심 기반이다. 출처: Apps SDK | OpenAI Developers, MCP – Apps SDK | OpenAI Developers, Agents SDK | OpenAI API

PM과 전략 담당자가 지금 던져야 할 질문은 “우리도 ChatGPT 앱을 만들까?”가 아니다. 더 정확한 질문은 이렇다. 우리 서비스의 어떤 기능이 사용자의 자연어 의도 뒤에서 호출될 때 가장 큰 가치를 만드는가. 어떤 데이터는 모델에게 넘기고, 어떤 데이터는 UI에서만 보여줘야 하는가. 어떤 작업은 자동화하고, 어떤 작업은 반드시 승인받아야 하는가. ChatGPT, Claude, Gemini 같은 플랫폼이 사용자의 작업 출발점이 될 때, 우리 서비스는 선택되는 도구가 될 준비가 되어 있는가.

이 질문에 답할 수 있는 기업은 앱스토어 시대의 “설치된 앱”을 넘어 에이전트 시대의 “호출되는 서비스”가 될 가능성이 높다. 반대로 기존 화면과 API를 그대로 붙이는 데 그친 기업은 대화형 플랫폼 안에서 존재감이 약해질 수 있다. ChatGPT 앱 생태계는 아직 성숙 중이지만 방향은 분명하다. 사용자는 점점 앱을 찾기보다 일을 설명할 것이고, 플랫폼은 그 일을 끝내기 위해 서비스를 호출할 것이다. 제품 전략은 이제 “어디에 노출될 것인가”보다 “어떤 의도에서 호출될 것인가”를 중심으로 다시 쓰여야 한다.

참고 출처