목차
- 오늘 본 것: Apps SDK와 GPT-5.5 라인의 조합
- 최근 몇 달 사이 움직인 네 지점
- 프론트→백엔드 전환자가 본 아키텍처 긴장
- WeChat 모델이 미국에서 되는가와 오늘의 메모
슈퍼앱은 한 앱 안에 메시징, 결제, 커머스, 예약, 서드파티 미니앱까지 묶어놓은 통합 플랫폼이다. WeChat이 원형이고 Alipay, Grab, Gojek이 비슷한 궤도 위에 있다. 유저는 앱 하나만 깔면 일상의 상당 부분을 그 안에서 해결한다.
오늘 OpenAI API 문서를 뒤적이다가 Apps SDK 페이지가 또 업데이트된 걸 봤다. 2025년 10월 DevDay에서 공개된 이후 몇 차례 확장을 거친 상태다(출처: OpenAI Release Notes, 2026-03 기준). ChatGPT 대화창 안에서 Zillow, Canva, Spotify, Booking 같은 서드파티가 UI 카드로 실행되는 그 기능 이야기다.
예를 들어, 보다가 퍼즐이 맞춰졌다. 최근 몇 달 기사 제목에서 "OpenAI가 슈퍼앱을 노린다"고 반복해 나오던 이야기의 조각이 이거였다. 모델 업그레이드(GPT-5.5 라인) + Apps SDK + Agentic Commerce 이 셋이 한 묶음이다. 이 셋이 합쳐져야 WeChat 스타일의 일상 진입점이라는 그림이 완성된다. 프론트에서 백엔드로 넘어온 지 2년, 양쪽 세계가 동시에 흔들리는 게 눈에 보여서 TIL로 남긴다.
오늘 본 것: Apps SDK와 GPT-5.5 라인의 조합
반면, Apps SDK가 내놓은 것은 외형상 단순하다. ChatGPT 대화창 안에서 서드파티 앱이 일급 시민이 된다. 예를 들어 Zillow 앱을 활성화한 상태에서 "샌프란시스코 미션 지구에서 월세 3000달러 이하 2베드 찾아줘"라고 치면, ChatGPT가 Zillow 백엔드에 질의를 넘기고 응답이 지도·카드·리스트 UI로 대화창에 바로 박힌다. 유저는 Zillow 앱을 따로 깔 필요가 없다.
그런데, 개발자가 Apps SDK에 노출하는 건 세 가지다. 첫째, 툴 정의. 기존 OpenAI Functions와 유사한 스키마로 호출 가능한 기능을 선언한다. 둘째, UI 컴포넌트 힌트. ChatGPT가 호스팅하는 제한된 컴포넌트 셋(카드, 리스트, 지도, 폼) 안에서 어떻게 표현할지 지정한다. 셋째, 딥링크. 필요할 때 원래 서비스로 유저를 이동시키는 경로를 둔다.
그러나, 2023년의 ChatGPT Plugins와 비교해보면 차이가 분명하다. 그때 플러그인은 툴 호출만 가능했고, UI는 순수 텍스트였다. 지금은 호스팅 UI가 합쳐지면서 "대화 안에 앱이 떠 있는" 감각이 생긴다. 유저는 카드를 탭하고 폼을 채우고 결과를 비교한다. 말 그대로 미니앱의 감각이다.
따라서, 외형은 단순한데 파급이 크다. 왜냐하면 이게 GPT-5.5 라인의 모델 특성과 붙으면서 의미가 달라지기 때문이다. 모델이 긴 컨텍스트에서 도구를 일관되게 호출하고, 여러 앱을 순서대로 엮는 에이전트 플로우를 안정적으로 유지해야만 슈퍼앱의 그림이 그려진다. 모델이 3~4턴에서 흔들리면 앱 전환이 엉키고, 유저는 "그냥 각 앱 직접 쓰겠다"로 돌아간다. GPT-5.5가 강조한다고 알려진 지점이 바로 장기 에이전트 플로우의 안정성이다(릴리스 노트 해석 기반, 2026-03 시점).
따라서, (개인적으로 이 순서가 중요하다고 본다. 모델 성능이 먼저 올라가야 SDK가 살아나고, SDK가 살아나야 커머스 레이어가 얹힌다. 거꾸로는 작동하지 않는다.)
최근 몇 달 사이 움직인 네 지점
그러나, 2026년 1분기 기준으로 OpenAI의 움직임을 모아보면 방향이 한 쪽이다. 네 가지만 꼽는다.
첫째, Apps SDK의 확장이다. 초기에는 읽기 전용 컴포넌트(카드, 리스트, 지도) 위주였는데, 2026-02 업데이트에서 결제 프리뷰 카드가 추가되었다. 아직 실제 결제를 SDK 안에서 완결짓지는 않지만, 유저가 상품 선택 → 결제 정보 확인 → 외부 딥링크로 결제 완료라는 흐름이 한 자리에서 일어난다. 의미 있는 중간 단계로 보인다.
예를 들어, 둘째, Agentic Commerce Protocol(ACP) 발표다. ChatGPT 대화에서 검색-추천-결제까지 한 흐름으로 묶는 규약으로, Stripe와 Shopify가 초기 파트너로 언급됐다(출처: OpenAI 공식 블로그, 2026년 초 발표 기준). 쇼핑 플랫폼이 ACP를 채택하면 유저가 ChatGPT에서 "여름용 경량 텐트 추천해줘"라고 했을 때 여러 쇼핑몰의 결과가 한 카드 세트로 올라오고, 그 자리에서 결제로 이어진다. 실제로 얼마나 돌아가고 있는지는 데이터가 더 쌓여야 알 수 있겠지만, 프로토콜을 제안했다는 사실 자체가 방향을 드러낸다.
물론, 셋째, 모델 튜닝의 방향이다. GPT-5.5 라인이 내세운 것은 추론 성능 숫자 하나만이 아니다. 긴 에이전트 플로우에서의 일관성, 도구 호출 실패 복구, 정책 준수율 같은 "에이전트 안정성" 지표들이 강조된 편으로 보인다. 이게 슈퍼앱 환경에서 핵심이다. 여러 앱이 연쇄로 호출될 때 중간에 한 번이라도 실패하면 유저 경험이 붕괴한다.
예를 들어, 넷째, 사용자 베이스 숫자다. 2025년 말 기준으로 ChatGPT 주간 활성 유저가 8억 명대로 발표된 바 있다(출처: DevDay 2025 키노트). 이 규모에 결제 인프라가 얹히면 이커머스 쪽에서 무시할 수 없는 채널이 된다. 반대로 말하면, 저 8억 명이 실제로 결제까지 이어지는 행동을 하느냐가 슈퍼앱 성립의 분기점이다.
또한, 이 넷을 붙여놓으면 "대화창 = 포털"이라는 방정식이 눈에 보인다. 포털이라는 단어가 2000년대 초 Yahoo, Daum 시절 용어 같지만, 기능적으로는 그게 맞다. 유저 발화 → 의도 분해 → 서드파티 앱 선택 → 실행 → 결제. 이 플로우를 대화창 하나에서 끝내겠다는 그림인 거다.
프론트→백엔드 전환자가 본 아키텍처 긴장
실제로, 프론트엔드 2년 반, 백엔드로 넘어와 2년. 양쪽 코드를 다 만져본 입장에서 슈퍼앱 논의가 흥미로운 이유는, 두 세계가 서로 다른 지점에서 깨지는 게 보이기 때문이다.
프론트 관점 – UI 표면이 내 도메인 밖으로 이동한다
게다가, 프론트 입장에서 Apps SDK는 "내 UI가 더 이상 내 앱 안에만 있지 않다"는 선언에 가깝다. 예전에는 내가 만든 컴포넌트가 브라우저 탭이나 네이티브 앱 안에서만 렌더링되었다. 이제는 ChatGPT 대화창이 또 하나의 렌더링 표면이 된다.
그러나, 퍼널의 시작점이 내 앱 밖으로 넘어가는 게 진짜 변화다. 유저가 "이탈리안 레스토랑 찾아줘"라고 말하면 그 발화는 내 Next.js 홈 페이지에 도착하지 않는다. ChatGPT가 받고, 내 서비스는 서버 쪽 인터페이스로만 연결된다. UX 디자이너가 공들여 만든 랜딩 배너, 홈 화면, 네비게이션이 상당 부분 건너뛰어진다. 브랜드를 쌓기 위해 2년 동안 튜닝해온 온보딩 플로우가 ChatGPT 카드 한 장으로 요약되는 셈이다.
즉, 디자인 시스템 쪽에도 구멍이 생긴다. ChatGPT가 호스팅하는 카드는 내 디자인 토큰을 그대로 반영하지 못한다. 색·폰트·간격이 ChatGPT 쪽 기본값으로 돌아가고, 나는 데이터와 레이아웃 힌트만 내려준다. 이게 받아들일 만한 교환인지는 조직마다 다르게 답한다. 진입 장벽을 낮추는 대신 브랜딩을 포기하는 거래다. 이미 브랜드가 강한 서비스(Zillow, Airbnb 같은)는 일부 버리고 들어간다. 새로 시작하는 서비스라면 오히려 장점이 될 수도 있다. 0 → 1 단계에서 ChatGPT가 유저 유입을 대신 만들어주는 셈이니까.
프론트엔드 엔지니어가 추가로 배워야 할 것은 두 가지로 보인다. 하나는 기존 웹/앱 UI 외에 카드 컴포넌트 스키마 작성. 다른 하나는 대화 흐름 위에서의 UX 설계다. 후자는 전통적인 화면 전환 사고와 결이 다르다. 화면이 없다. 응답 하나가 단위이고, 다음 응답까지 컨텍스트를 이어줄 수 있는 구조화된 정보만 남긴다. 이걸 디자인 툴에서 어떻게 스펙으로 잡을지는 아직 도구가 따라오지 못하는 구간이기도 하다.
백엔드 관점 – API가 에이전트 계약서가 된다
백엔드 입장에서는 다른 긴장이 보인다. 2년 전 REST API를 만들 때의 설계 원칙이 그대로 쓰이지 않더라. REST는 사람이 호출하거나 다른 코드가 호출하고, 에이전트용 엔드포인트는 LLM이 호출한다. LLM은 응답 메시지를 자연어로 읽고 다음 행동을 결정한다.
에러 메시지부터 달라진다. HTTP 400에 {"error": "invalid_input"} 정도만 떨어뜨리면 LLM이 무엇을 고쳐서 재시도할지 추론하기 어렵다. 요즘 쓰이는 에러 포맷은 훨씬 풍부한 쪽으로 움직인다.
{
"status": "error",
"code": "missing_required_field",
"message": "체크인 날짜가 비어 있다",
"required_fields": ["check_in", "check_out"],
"suggestion": "YYYY-MM-DD 형식으로 전달하라",
"example": {"check_in": "2026-05-01", "check_out": "2026-05-03"}
}
실제로, LLM은 이 응답을 읽고 바로 다음 호출에 필요한 값을 채운다. 이전에는 "에러는 로그에 잘 남기면 된다"였다. 지금은 "에러 자체가 대화의 일부"다. 에러 메시지가 사람을 향하는 UX 텍스트처럼 설계되기 시작했다. 이게 왜 아무도 안 알려주는지 모르겠는데, 에러 응답 포맷만 바꿔도 툴콜 실패 후 복구율이 눈에 띄게 좋아진다는 걸 체감했다.
레이트 리밋도 다시 짜야 한다. 사람 호출은 초당 몇 건 수준이지만, 에이전트는 1턴 안에 같은 엔드포인트를 재시도하거나 여러 엔드포인트를 병렬 호출하기도 한다. 호출 주체를 사람/에이전트로 구분해서 쿼터를 다르게 주는 설계가 점점 흔해지는 편이다. 에이전트는 실패를 자체적으로 복구하려 하기 때문에, 재시도 친화적인 멱등 설계가 필수에 가까워진다.
반면, 인증도 바뀐다. 유저 개인 토큰, 에이전트 프레임워크 토큰, 앱 개발자 토큰이 셋 다 섞이는 흐름이 된다. 누가 이 호출의 책임 주체인가를 모든 요청에 남기지 않으면 감사 로그가 깨진다. 2년 전에는 고민 안 해도 됐던 지점이다.
두 세계의 간극이 진짜 문제다
프론트가 사라지는 게 아니라 분할된다. 지금 운영 중인 서비스라면 앞으로 세 개의 UI 표면을 동시에 유지해야 할 가능성이 크다.
- Apps SDK의 컴포넌트 스키마 (ChatGPT 호스팅 UI)
- 전통적인 웹/네이티브 UI (직접 방문 경로)
- 에이전트 전용 JSON API (타사 에이전트가 호출)
이처럼, 이 셋이 같은 데이터를 서로 다른 방식으로 표현하는 것 자체는 괜찮다. 문제는 핵심 비즈니스 규칙(가격, 재고, 예약 가능 시간, 프로모션 조건)이 셋 사이에서 어긋날 때다. "ChatGPT에서는 5만 원인데 앱에서는 6만 원이네?" 같은 상황이 생기면 유저 신뢰가 한 번에 깨진다. 데이터 컨트랙트를 하나로 두고, 세 표면은 그 위에 얇게 얹는 패턴이 자리잡는 중이다.
모노리포에 스키마를 공유하고, 표면별로 프레젠테이션 레이어만 분리하는 구성이 기본값이 된다. 2년 전이었으면 "이건 과설계다"라고 봤을 법한 구조인데, 슈퍼앱 시나리오가 현실화되면 이게 생존 조건이 될 수도 있겠더라.
WeChat 모델이 미국에서 되는가와 오늘의 메모
여기서부터는 판단이 갈리는 영역이다. 개인 의견으로는 WeChat 모델 그대로의 재현에는 회의적인 편이다.
WeChat이 슈퍼앱이 될 수 있었던 조건은 2013~2017년 사이 중국 시장의 특수성이 크게 작용했다. 한 줄로 풀면 "결제가 약한 시장에서 QR 간편결제를 먼저 장악한 뒤 미니앱을 얹었다"는 순서다. 홍바오(디지털 세뱃돈)라는 문화적 장치가 QR 결제 채택을 단기간에 폭발시켰고, 그 위에 미니프로그램이 2017년에 올라갔다. 이 순서가 반대였다면 작동하지 않았을 가능성이 높다.
| 조건 | WeChat (중국, 2013~2017) | ChatGPT (미국, 2026년 시점) |
|---|---|---|
| 결제 인프라 | 카드 결제 기반 약함 → QR로 공백 장악 | 카드·Apple Pay·Venmo 이미 포화 |
| 규제·수수료 | 앱스토어 우회 상대적으로 수월 | Apple/Google 수수료 정책 존재 |
| UX 진입점 | 메신저 (일상 체류 시간 1위) | 검색·생산성 (체류는 부분적) |
| 경쟁 구도 | 토종 플랫폼 단일 집중 | Google·Meta·Amazon·Apple 동시 |
| 유저 락인 | 친구·가족 네트워크 전체가 그 안 | 네트워크 효과 아직 약함 |
그래서, 가장 약해 보이는 지점이 결제 진입점이다. Agentic Commerce Protocol이 아무리 잘 설계돼도, 미국 유저가 "ChatGPT에서 결제하는 게 더 편하다"고 느끼는 순간이 얼마나 빨리 올지가 관건이다. 미국에서는 이미 Apple Pay, Venmo, 카드 탭이 마찰이 낮은 결제 경로다. 그걸 대체하려면 결제 자체보다 "결제 전 탐색"의 가치를 압도적으로 끌어올려야 한다. ChatGPT가 거기까지 갈 수 있느냐는 또 다른 질문이다.
예를 들어, 그렇다고 슈퍼앱 그림 전체가 불가능하다는 뜻은 아니다. 소비 슈퍼앱(WeChat 계열)과 업무 슈퍼앱(Teams 계열)은 전략이 다르다. 업무 쪽은 시나리오가 훨씬 현실적이다. 이메일, 캘린더, 문서, 코드, 데이터 분석, 미팅 노트가 하나의 대화창에서 연결되는 구도. 이건 오히려 Microsoft의 Teams+Copilot 전략과 정면으로 부딪히는 자리다. ChatGPT가 먼저 저 자리를 잡으려고 달리고 있는 모양새로 보인다.
그래서 "OpenAI 슈퍼앱"이라는 기사 제목이 약간 흐리게 쓰이는 느낌이 있다. 소비 슈퍼앱인지 업무 슈퍼앱인지가 기사마다 다르다. 용어가 뒤섞이는 동안 실제 전략은 후자(업무 허브) 쪽에 더 가까워 보인다.
이처럼, 당장 내가 손으로 확인해보려는 게 세 가지다.
- Apps SDK로 간단한 카드 컴포넌트 하나를 얹어서, 실제 대화 흐름 안에서 UI가 어떻게 보이는지 찍어보기
- 운영 중인 서비스의 에러 응답을 LLM-친화 포맷으로 재설계한 뒤, 툴콜 성공률이 체감상 얼마나 오르는지 기록
- Agentic Commerce Protocol 초안 문서를 한 번 끝까지 읽고, Stripe 개발자 문서와 교차 확인
특히, 참고 링크는 두 개만 남긴다.
- OpenAI Apps SDK 공식 문서 (2026-03 기준 확인)
- OpenAI 공식 블로그 – Agentic Commerce 관련 발표 (2026년 초 발표 기준)
실제로, 다만 아직 이 모델이 실제 매출과 유지율로 이어지는지, 그리고 Apple/Google 스토어 정책이 에이전트 결제 플로우를 어떻게 해석할지는 더 지켜봐야 한다.
관련 글
- AI 컨퍼런스에서 GPT 대신 Claude 쓰는 개발자가 늘어난 이유 – HumanX 2025에서 발표자 대부분이 Claude를 시연 도구로 선택했다는 보고가 이어졌다. GPT 중심이던 개발자 도구 생태계에 전환…
- ChatGPT가 스토킹범 도왔다며 OpenAI 고소 — AI 책임 문제 정리 – ChatGPT가 스토커의 망상을 부추기고 위험 신호를 무시했다는 이유로 OpenAI가 고소당했다. 소송 핵심 쟁점, 현행 AI 책임 법리,…
- AI 개발자 격차, Stanford 리포트가 숫자로 보여준 현실 – 같은 팀, 같은 스택인데 아웃풋이 2배 차이 나기 시작했다. Stanford AI Index Report가 보여준 AI 개발자 격차의 실체…