출시 준비와 품질 체크리스트

데모에서 제품으로 넘어가는 기준

Apps SDK 앱은 "동작한다"만으로 출시할 수 없습니다. ChatGPT 안에서 실행되는 앱은 사용자의 대화 흐름, 외부 API, 인증, 위젯 UI, 도구 호출이 함께 얽혀 있습니다. 그래서 출시 준비는 코드 배포가 아니라 제품 검수에 가깝습니다.

가장 먼저 확인할 질문은 단순합니다.

• 사용자가 이 앱을 왜 써야 하는가?

• 앱이 실제로 설명한 기능만 수행하는가?

• 필요한 데이터만 요청하는가?

• 실패했을 때 사용자가 다음 행동을 알 수 있는가?

• 운영자가 문제를 발견하고 고칠 수 있는가?

이 질문에 답하지 못하면 리뷰 과정에서도 설명이 흔들립니다. 반대로 이 질문에 답할 수 있으면 제출 양식, 정책 검토, 장애 대응, 출시 후 개선까지 한 흐름으로 정리됩니다.

제출 전에 준비할 패키지

Apps SDK 앱 제출에는 코드 외의 자료가 필요합니다. 제출 양식에는 앱 이름, 로고, 설명, 회사 URL, 개인정보 처리방침 URL, MCP 서버와 도구 정보, 스크린샷, 테스트 프롬프트와 예상 응답, 현지화 정보 등이 포함됩니다. 제출 전에는 필수 항목과 확인 체크박스를 빠짐없이 검토해야 합니다.¹

출시 직전에 다음 항목을 하나의 폴더나 문서로 모아 두면 좋습니다.

여기서 중요한 점은 "마케팅 문구"보다 "검증 가능한 설명"입니다. 리뷰어는 앱 설명과 실제 동작이 일치하는지 확인합니다. 사용자는 앱을 연결하기 전에 어떤 데이터가 오가고 어떤 작업이 실행되는지 이해해야 합니다.

도구 계약 자체 리뷰

Apps SDK 앱은 MCP를 기반으로 도구 로직과 UI 컴포넌트를 함께 제공합니다. MCP 서버는 도구 목록을 알리고, 모델이 선택한 도구를 호출하며, 결과와 함께 위젯에 필요한 메타데이터를 반환하는 구조로 동작합니다.²

따라서 출시 전에는 각 도구를 다음 기준으로 자체 리뷰해야 합니다.

1. 목적이 하나인가
   search_products, create_order, cancel_booking처럼 도구 이름만 봐도 역할이 보여야 합니다. 하나의 도구가 검색, 결제, 알림 전송을 모두 처리하면 모델도 사용자도 동작을 예측하기 어렵습니다.

2. 입력 스키마가 최소한인가
   기능 수행에 필요하지 않은 생년월일, 주소, 전화번호, 위치 정보, 결제 관련 정보는 요청하지 않아야 합니다. "나중에 쓸 수도 있다"는 이유로 필드를 추가하면 개인정보 리스크만 커집니다.

3. 출력 스키마가 UI와 일치하는가
   위젯이 items[].price를 기대하는데 도구가 amount를 반환하면 UI는 깨집니다. 반대로 모델이 읽어야 할 핵심 정보가 _meta에만 들어 있으면 대화 응답 품질이 떨어집니다. 앞 장에서 다룬 원칙처럼, 모델이 이해해야 하는 값은 structuredContent에 두고, UI 내부에서만 필요한 값은 _meta로 분리합니다.

4. 권한 요청 이유가 설명되는가
   캘린더 읽기, 파일 접근, 주문 생성, 외부 사이트 열기 같은 작업은 왜 필요한지 사용자에게 설명되어야 합니다. 권한 요청 문구와 실제 사용 범위가 다르면 신뢰를 잃습니다.

5. 읽기 작업과 쓰기 작업이 구분되는가
   조회 도구는 비교적 안전합니다. 하지만 예약 생성, 메시지 전송, 주문 제출, 파일 수정처럼 외부 상태를 바꾸는 작업은 사용자 확인 단계를 넣어야 합니다. 실행 전 요약 화면을 보여 주고, 사용자가 명확히 승인한 뒤에만 호출되도록 설계합니다.

공개 전 품질 체크리스트

출시 전 품질 점검은 "버그가 없는가"보다 넓게 봐야 합니다. 다음 항목은 최소한의 제품 품질 기준입니다.

보안과 개인정보

• HTTPS가 적용된 운영 MCP 서버를 사용하는가

• 인증 토큰을 브라우저 저장소나 위젯 상태에 평문으로 저장하지 않는가

• 서버 로그에 개인정보나 액세스 토큰이 남지 않는가

• 도구 입력 스키마가 필요한 데이터만 요구하는가

• 사용자가 연결을 해제하거나 권한을 철회했을 때 처리 흐름이 있는가

• 개인정보 처리방침이 실제 데이터 처리 방식과 일치하는가

안정성과 속도

• 주요 도구 호출이 허용 가능한 시간 안에 응답하는가

• 외부 API 지연 시 타임아웃을 설정했는가

• 같은 요청을 반복 호출해도 데이터가 중복 생성되지 않는가

• 서버 재시작 후에도 필요한 상태가 복구되는가

• 위젯 번들이 캐시되어도 최신 서버 응답과 충돌하지 않는가

사용자 경험

• 빈 결과가 나왔을 때 "없음"만 말하지 않고 다음 행동을 안내하는가

• 권한이 없을 때 연결 방법을 알려 주는가

• 오류 메시지가 기술 로그가 아니라 사용자의 언어로 표현되는가

• 모바일·좁은 화면·다크 모드에서 UI가 깨지지 않는가

• 키보드 접근성과 버튼 레이블이 기본 수준을 만족하는가

Apps SDK UI 라이브러리는 ChatGPT 안에서 일관된 경험을 만들기 위한 디자인 토큰과 접근 가능한 React 컴포넌트를 제공합니다.³ 반드시 이 라이브러리를 써야만 좋은 앱이 되는 것은 아니지만, 자체 UI를 만들더라도 색상, 간격, 버튼 상태, 반응형 레이아웃, 접근성 기준은 같은 수준으로 맞춰야 합니다.

실패 시나리오를 테스트 프롬프트로 만들기

리뷰와 운영에서 가장 많이 드러나는 문제는 정상 흐름이 아니라 실패 흐름입니다. 출시 전에는 실패 시나리오를 테스트 프롬프트로 만들어 두어야 합니다.

예를 들어 여행 예약 앱이라면 다음과 같은 프롬프트를 준비합니다.

• "다음 주 금요일 서울에서 부산 가는 가장 저렴한 숙소 찾아줘."

• "로그인하지 않은 상태에서 내 예약 목록을 보여줘."

• "없는 도시 이름으로 호텔을 검색해줘."

• "예약을 만들다가 결제 직전에 취소하고 싶어."

• "권한을 거부한 뒤 다시 검색해줘."

• "외부 API가 실패했을 때 다시 시도해줘."

각 프롬프트에는 예상 결과를 붙입니다.

좋은 오류 처리는 실패를 없애는 것이 아닙니다. 실패했을 때 사용자가 상황을 이해하고 다음 행동을 선택할 수 있게 만드는 것입니다.

리뷰 과정에서 설명 가능한 상태 만들기

앱 리뷰는 방어적으로 준비해야 합니다. 리뷰어가 "왜 이 권한이 필요한가?", "이 도구는 어떤 데이터를 저장하는가?", "사용자가 주문을 확정하기 전에 무엇을 보게 되는가?"라고 물었을 때 바로 답할 수 있어야 합니다.

이를 위해 출시 문서에 다음 네 가지를 포함합니다.

1. 데이터 흐름도
   사용자 입력이 ChatGPT, MCP 서버, 외부 API, 데이터베이스를 어떻게 지나가는지 간단히 그립니다.

2. 권한 매핑표
   권한마다 사용하는 도구, 필요한 이유, 저장 여부, 보관 기간을 정리합니다.

3. 쓰기 작업 확인 정책
   어떤 작업에서 사용자 확인을 요구하는지 명시합니다.

4. 오류 대응표
   API 장애, 인증 실패, 빈 결과, 권한 거부, 위젯 로딩 실패에 대한 사용자 메시지와 서버 로그 기준을 정리합니다.

이 문서는 리뷰만을 위한 자료가 아닙니다. 출시 후 장애가 발생했을 때 운영자가 같은 기준으로 판단하게 해 주는 운영 매뉴얼입니다.

출시 후 봐야 할 운영 지표

리뷰를 통과하면 끝이 아닙니다. 실제 사용자는 테스트 프롬프트보다 훨씬 다양한 방식으로 앱을 호출합니다. 출시 후에는 다음 지표를 꾸준히 봐야 합니다.

• 사용량: 일간·주간 활성 사용자, 대화 내 앱 호출 수

• 도구 호출 성공률: 전체 호출 중 정상 완료 비율

• 평균 응답 시간: MCP 서버 처리 시간과 외부 API 대기 시간

• 오류율: 인증 오류, 권한 오류, 서버 오류, 외부 API 오류

• 위젯 상호작용률: 버튼 클릭, 필터 변경, 상세 보기, 재시도 클릭

• 재방문율: 한 번 사용한 사용자가 다시 호출하는 비율

• 프롬프트별 완료율: 주요 사용 목적별로 원하는 결과까지 도달한 비율

지표를 볼 때는 평균만 보면 안 됩니다. 평균 응답 시간이 1초여도 일부 사용자가 15초를 기다린다면 체감 품질은 나쁩니다. 도구 호출 성공률도 전체 숫자만 보지 말고 도구별, 지역별, 인증 상태별로 나누어 봐야 합니다.

또 하나 중요한 지표는 "사용자가 어디서 멈추는가"입니다. 검색은 성공했지만 위젯에서 아무 행동도 하지 않는다면 결과 카드가 부족한 것일 수 있습니다. 결제 직전 이탈이 많다면 가격, 수수료, 환불 정책 설명이 부족한 것일 수 있습니다.

수익화에 대비한 설계

Apps SDK 앱을 당장 무료로 출시하더라도 수익화 가능성은 미리 고려해야 합니다. 현재 일반적으로 사용할 수 있는 권장 방식은 사용자가 개발자 도메인에서 구매를 완료하는 외부 결제 흐름입니다.⁴ 앞으로 플랫폼 내 결제나 디지털 상품 흐름이 확장되더라도, 데이터 모델을 잘 나누어 두면 전환이 쉽습니다.

수익화 설계에서 가장 중요한 원칙은 상품, 주문, 권한, 환불, 사용 자격을 분리하는 것입니다.

• 상품: 무엇을 파는가

• 주문: 사용자가 무엇을 언제 구매했는가

• 권한: 구매 후 어떤 기능을 사용할 수 있는가

• 환불: 결제 취소나 반환 상태는 무엇인가

• 사용 자격: 현재 시점에 사용자가 실행할 수 있는 기능은 무엇인가

이 다섯 가지를 하나의 isPaidUser 값으로 뭉개면 나중에 문제가 생깁니다. 월 구독, 사용량 기반 과금, 팀 라이선스, 쿠폰, 환불, 체험 기간을 처리하기 어려워집니다.

UI에서도 결제 전후 상태를 명확히 보여 주어야 합니다.

• 결제 전에 무료 기능과 유료 기능의 차이를 설명합니다.

• 결제 버튼을 누르기 전에 가격, 갱신 주기, 환불 조건을 보여 줍니다.

• 결제 후에는 사용 가능한 기능과 남은 한도를 표시합니다.

• 권한이 없어서 실행할 수 없는 도구는 이유와 업그레이드 방법을 안내합니다.

• 환불 또는 구독 해지 후에는 언제까지 접근 가능한지 알려 줍니다.

수익화는 단순히 결제 버튼을 붙이는 일이 아닙니다. 사용자가 돈을 내기 전과 후의 상태를 오해하지 않도록 만드는 신뢰 설계입니다.

최종 출시 체크리스트

마지막으로 제출 직전에 아래 목록을 한 번 더 확인합니다.

• 앱 이름, 로고, 설명이 실제 기능과 일치한다

• 회사 URL과 개인정보 처리방침 URL이 유효하다

• MCP 서버 운영 URL이 안정적으로 접근된다

• 모든 도구의 입력·출력 스키마가 최신 코드와 일치한다

• 읽기 도구와 쓰기 도구가 명확히 구분되어 있다

• 쓰기 작업에는 사용자 확인 단계가 있다

• 인증 실패와 권한 거부 흐름을 테스트했다

• 외부 API 장애와 타임아웃을 테스트했다

• 빈 결과와 UI 로딩 실패에 대한 대체 응답이 있다

• 서버 로그에 민감 정보가 남지 않는다

• 주요 테스트 프롬프트와 예상 응답을 문서화했다

• 스크린샷은 실제 앱 화면을 사용했다

• 현지화 문구와 오류 메시지를 검토했다

• 출시 후 모니터링 지표와 알림 기준을 설정했다

• 수익화 또는 외부 결제 흐름이 있다면 가격·환불·권한 문구를 검토했다

좋은 Apps SDK 앱은 대화 안에서 자연스럽게 발견되고, 필요한 순간에 정확히 작동하며, 실패했을 때도 사용자를 버려두지 않습니다. 출시 준비의 목표는 리뷰 통과가 아니라 지속적으로 신뢰받는 앱을 만드는 것입니다.

참고

¹Submit and maintain your app - Apps SDK | OpenAI Developers

⁴Monetization - Apps SDK | OpenAI Developers