Developer Mode vs Store

1. 소개

이전 강의에서 이미 ChatGPT App이 무엇이고 어떤 레이어로 구성되며 예전 플러그인이나 단순 OpenAI API 기반 봇과 무엇이 다른지 이야기했습니다. 이제 두 번째 중요한 주제인 이러한 애플리케이션의 라이프사이클로 넘어가겠습니다.

몇 년이라도 웹 서비스를 개발해 보셨다면 “lifecycle”이라는 단어가 낯설지 않을 겁니다. 어떤 제품이든 기본적인 경로가 있죠: “로컬에서 코드를 작성 → staging에 배포 → production에 배포 → 가끔 깨뜨림 → 고침”. ChatGPT 생태계의 App에서도 거의 동일하지만, 몇 가지 차이가 있습니다. 바로 ChatGPT 내부의 Dev Mode와 별도의 엔터티인 Store가 생긴다는 점입니다.

두 가지 층위를 명확히 구분하는 것이 중요합니다.

1. 여러분의 코드가 물리적으로 어디에 존재하는가: 로컬 Next.js 서버, Vercel, 어떤 Kubernetes 클러스터 등. 이건 여러분의 세계이며, 여러분이 모든 것을 통제합니다.
2. ChatGPT가 여러분의 App을 어떻게 보느냐: 메타데이터, URL, 권한의 집합으로 보며, 이를 Developer Mode에서 연결하거나 Store에서 완성된 제품처럼 꾸밀 수 있습니다. 이건 OpenAI의 세계로, 자체 규칙과 리뷰, 사용자들이 있습니다.

이번 강의는 바로 두 번째 층위에 관한 것입니다. 여러분이 익숙한 환경 모델(dev / staging / prod)을 바탕으로 하되, 이를 ChatGPT의 시각에서 바라볼 것입니다. 우리의 목표는 여러분이 언제든 다음 질문들에 답할 수 있게 하는 것입니다. 지금 내 App은 정확히 어떤 코드를 실행하고 있는가? 누가 그것을 볼 수 있는가? 어떻게 안전하게 실험할 수 있는가? 그리고 Store에서 “App을 업데이트한다”는 건 정확히 무엇을 의미하는가?

2. Developer Mode: ChatGPT 안의 개인 샌드박스

개발자에게 가장 즐거운 것부터 시작해 봅시다. 바로 맘껏 망가뜨려도 거의 아무에게도 피해를 주지 않는 샌드박스입니다.

Developer Mode는 ChatGPT의 특수 모드로, 여러분은 ChatGPT Apps를 URL로 직접 연결할 수 있습니다. 리뷰를 거치지 않고, Store에 App을 게시하지 않으며, 전 세계에 App을 공개하지 않아도 됩니다. 느낌상 브라우저의 localhost:3000과 비슷하지만, 장소가 ChatGPT 세계라는 점만 다릅니다.

개념적으로는 이렇게 보입니다

가장 간단한 그림은 다음과 같습니다.

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Dev 구성(App) (URL + 메타데이터)"]
    AppServer["App 서버 (Next.js + Apps SDK)"]

    User -->|채팅 요청| ChatGPTCore[GPT]
    ChatGPTCore -->|앱이 필요| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/도구| ChatGPTCore
    ChatGPTCore --> User

여러분은 개발자 자격으로 Developer Mode 설정에서 ChatGPT에게 이렇게 말합니다. “여기에 내 App이 있고, 이게 URL이며, 이름과 기능은 이렇다.” 그러면 ChatGPT는 그 URL을 여러분 애플리케이션의 소스로 인식하기 시작합니다. App을 아직 Store에 제출하지 않았다면, 여러분(그리고 개발자로 추가된 팀원들 정도)만 볼 수 있습니다.

연결의 기술적 세부(HTTPS 터널, Vercel 등)는 뒤에서 다룹니다. 여기서 중요한 아이디어는 이겁니다. Dev Mode는 ChatGPT가 호출할 수 있는, 여러분의 dev 서버로 향하는 “동적인 바로가기”입니다.

Developer Mode 활성화 방법

로컬 서버를 ChatGPT 인터페이스에 "연결"할 수 있게 하려면 설정에서 해당 스위치를 활성화해야 합니다.

• 링크 https://chatgpt.com/#settings/Connectors/Advanced로 이동하거나 Settings -> Connected apps -> Advanced로 들어가세요.
• Developer Mode - ON

이 작업을 완료하면 Create App 버튼이 나타납니다.

Dev Mode와 production의 차이

차이는 일반 웹의 dev 환경과 production의 차이와 매우 비슷하지만, 몇 가지 특수한 포인트가 있습니다.

우선, 가시성입니다. Dev Mode의 여러분 App은 일반 ChatGPT 사용자에게 보통 보이지 않습니다. 여러분과, 권한을 가진 조직 구성원 정도만 볼 수 있습니다. 반쯤 고장 난 UX를 우연히 일반 사용자가 보게 될까 걱정하지 않고 실험할 수 있습니다.

둘째, 안정성과 실험입니다. Dev Mode에서는 2분마다 코드를 바꾸든, 로컬 서버를 띄웠다 내렸다 하든, 터널을 재시작하든 상관없습니다. ChatGPT는 지정된 URL로 접근하려고 노력하지만, 가끔 500을 반환하거나 아예 응답하지 않아도 탓하지 않습니다. 그게 dev의 목적이니까요.

셋째, 권한과 정책입니다. Dev Mode에서는 다양한 구성을 더 쉽게 시도할 수 있습니다. 하지만 콘텐츠 정책과 기본 보안은 dev에서도 꺼지지 않는다는 점을 잊지 마세요. ChatGPT는 여러분이 갑자기 “모든 걸 위한 해킹용 App”이 되도록 두지 않습니다. 다만 Store 리뷰의 형식적 요건(완벽한 리스팅, 예쁜 로고 등)은 여기서는 아직 적용되지 않습니다.

마지막으로, Dev Mode에서는 보통 진단이 쉬워집니다. 로직을 빠르게 바꾸고, ChatGPT가 여러분 서버에 어떤 요청을 보내는지 보고, 사용자 마이그레이션을 신경 쓰지 않고도 동작을 조정할 수 있습니다.

우리는 Dev Mode를 애플리케이션을 위한 개인 샌드박스로 살펴봤고, Store 쪽도 살짝 들여다봤습니다. 이제 이것을 App 라이프사이클의 이해하기 쉬운 “상태 기계”로 정리해 보겠습니다.

3. ChatGPT App의 상태: 초안부터 게시 중지까지

이제 여러분의 App을 위한 이해하기 쉬운 “상태 기계”로 정리해 봅시다. 편의상 네 가지 주요 상태로 이야기합니다: Draft / Dev-only, Under review, Published, Paused/Removed.

라이프사이클 상태 기계

다이어그램으로 표현하면 다음과 같습니다.

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / 초안
    Review: Under review (Store)
    Published: Store에 공개, 사용자에게 제공됨
    Paused: Paused / Removed

    Draft --> Review: 검토에 제출
    Review --> Draft: 거절됨 / 수정 요청
    Review --> Published: 승인됨
    Published --> Paused: 일시 중지 / 내리기
    Paused --> Draft: dev 모드에서 작업 재개
    Draft --> Published: 조직 내부 롤아웃(스토어 미사용) (조직 전용)

Draft 상태에서 여러분의 App은 dev 리소스로만 존재합니다. Developer Mode에 연결하고 다양한 기능을 시도할 수 있지만, Store에는 노출하지 않습니다.

사람들에게 App을 보여줄 준비가 되었다고 판단하면 “리뷰에 제출”합니다. 이 상태가 Under review입니다. 이때 OpenAI(또는 조직 내부 리뷰 시스템)가 정책 준수, 안정성, 기본 보안, UX 적정성을 확인합니다.

모든 것이 괜찮다면 App은 Published가 됩니다. Store에 나타나거나(공개 시나리오) 여러분 회사의 사용자에게만 제공될 수도 있습니다(기업 시나리오). 이 시점부터 실제 사용자가 들어오기 시작하며, 코드와 구성을 변경할 때 훨씬 더 신중해야 합니다.

반대로 일시적으로 App을 사용 불가능하게 만들고 싶다면 Paused/Removed 상태로 전환할 수 있습니다. Paused 상태에서는 신규 사용자에게는 숨겨지지만, 이미 시작된 세션에서는 계속 동작하거나 완전히 중지될 수도 있습니다. 세부는 플랫폼 구현과 설정에 따라 달라집니다.

4. Store: 여러분의 App이 제품이 되는 순간

Developer Mode가 개인 작업실이라면, Store는 공식 전시 공간입니다. 여기서는 사용자, 평점, 리스팅 규칙과 리뷰가 중요한 역할을 합니다.

Store로 가면 무엇이 달라지나요

첫째이자 가장 중요한 점: 여러분의 App이 “제품”이 됩니다. 이름, 설명, 아이콘, 카테고리, 때로는 대화 시작 프롬프트까지 포함한 리스팅이 생깁니다. 이 메타데이터를 바탕으로 ChatGPT Store는 사용자가 여러분의 앱을 찾고 추천할 수 있으며, 모델 자체도 어떤 상황에서 앱이 적합한지 이해합니다.

둘째로 중요한 점은 리뷰와 정책입니다. App이 Store에 나타나기 전에 보안, 콘텐츠, UX 요구사항에 부합하는지 검사받습니다. 즉:

• 몰래 과도한 개인정보를 수집할 수 없습니다.
• App이 하지 않는 일을 약속할 수 없습니다.
• 허용된 콘텐츠 카테고리를 벗어날 수 없습니다.

정책과 샌드박스는 다음 강의에서 자세히 다루겠지만, 지금은 Store를 비교적 “예의 바른” 버전의 App만 가져가는 곳으로 인식해 두세요.

셋째는 안정성에 대한 책임입니다. Dev Mode에서의 장애는 여러분의 문제로 끝나지만, Store에서는 적절한 가용성, 합리적인 지연시간, 위젯에서 “빨간 죽음의 화면” 같은 것이 없어야 합니다. 뒷부분 모듈에서는 SLO, 메트릭, Store 리뷰를 이런 관점에서 다룰 것입니다.

버전: dev vs production

흔한 질문: “코드를 업데이트하면 사용자는 무엇을 보나요?” ChatGPT Apps 세계에서는 두 “브랜치”를 동시에 생각하면 좋습니다.

• dev 브랜치: Developer Mode에 연결되어 있으며 IDE 옆의 dev 서버를 가리킬 수 있습니다.
• production 브랜치: Store에 게시된 구성과 연관되어 있고 안정적인 URL을 가리킵니다.

아키텍처 관점에서 프로젝트 안에 작은 TypeScript 타입으로도 표현할 수 있습니다.

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

실제 환경에서는 구성을 여러분의 코드가 아닌 ChatGPT 플랫폼이 보관하지만, 이런 구조는 동일한 App의 서로 다른 두 “이미지”가 있음을 머릿속에 정리하는 데 도움이 됩니다.

ChatGPT App의 릴리스는 웹사이트 업데이트라기보다 Apple App Store 앱 릴리스에 더 가깝습니다. 위젯과 mcp-tools는 매번 앱 릴리스 시점에 캐시됩니다. 리뷰에는 최대 2주가 걸릴 수 있습니다. 그러니 “프로덕션에 올려서 거기서 마저 테스트하자”는 건 통하지 않습니다. 리뷰에 제출하는 시점에는 이미 충분히 테스트되고 안정적인 앱이어야 합니다.

5. 조직적 컨텍스트: 개인 계정 vs 회사

우리는 이미 App을 dev/production 브랜치로 나누어 살펴보고, 이것이 Store에서 어떻게 반영되는지도 보았습니다. 라이프사이클의 또 다른 중요한 축은 “조직적으로 어디에 속하느냐”입니다.

가장 단순한 경우, 여러분은 개인 ChatGPT Plus 계정으로 App을 만듭니다. 그러면 Dev Mode도 전적으로 여러분의 것이고, Store도 여러분 계정을 통해 운영합니다. 비교적 단순하죠. 자신을 위해 만들고, 올리고, 세상과 공유합니다.

하지만 ChatGPT Apps는 기업 환경에서 동작하는 경우가 매우 많습니다. 이때는 몇 가지 추가 역할이 등장합니다. 조직의 관리자는 어떤 앱이 직원에게 허용되는지, 어떤 앱을 차단해야 하는지, 어떤 앱을 파일럿 그룹에만 제공할지 결정합니다. 여러분의 App은 전 세계 공개가 아니라 특정 회사, 심지어 그 안의 특정 부서에만 공개될 수 있습니다.

이런 시나리오에서 라이프사이클은 다음과 같습니다. 먼저 팀 내부에서 dev 프로젝트로만 존재하다가, 이후 “내부 production”이 생겨 예를 들어 영업부 파일럿에만 제공됩니다. 그다음 모든 것이 잘 진행되면 전 세계 사용자용 제품으로 만들기 위해 App을 글로벌 Store에 제출합니다.

아키텍처 관점에서 이는 App이 내부 도구이자 공개 제품으로도 적절히 동작하도록 설계해야 함을 의미합니다. 때로는 피처 플래그, “내부 전용” 모드, 별도의 인증 설정이 필요합니다.

6. 실전 시나리오: GiftGenius의 라이프사이클

앞서의 내용을 추상에 그치지 않도록, 강의 전반에서 우리를 동행할 선물 추천 App인 GiftGenius를 가정해 살펴보겠습니다.

단계 1. 아이디어와 Dev Mode에서의 초안 프로토타입

여러분은 GiftGenius를 만들기로 합니다. 이 App은 사용자에게 선물을 줄 대상, 예산, 수신자의 관심사를 물은 뒤, 여러분의 상품 카탈로그를 사용해 추천을 제안합니다.

첫 단계에서 여러분은 다음을 수행합니다.

1. 최소한의 위젯만 있는 간단한 Next.js 프로젝트를 올립니다.
2. ChatGPT에서 Developer Mode를 켜고 dev 서버의 URL을 추가합니다.
3. 몇 가지 테스트 대화를 진행합니다. 예를 들어 GPT에게 “게이머 친구에게 줄 50달러 이하 선물 추천을 도와줘”라고 요청해 보고, App 호출과 위젯 렌더링, UX가 어떻게 나오는지 확인합니다.

이 단계에서는 Store, 리뷰, 예쁜 아이콘 같은 건 신경 쓰지 않습니다. 목표는 아이디어가 실제로 작동하고 ChatGPT 플랫폼이 필요한 시나리오를 구현할 수 있음을 팀에 증명하는 것입니다.

단계 2. 프로토타입 보강과 내부 “알파”

기본 시나리오가 작동한다고 확신하면 “보강” 단계가 시작됩니다. 여러분은:

• 로직을 어느 정도 이해 가능한 구조로 다듬습니다.
• App에 실제로 필요한 권한과 데이터가 무엇인지 고민합니다.
• 예를 들어 상품 카탈로그가 응답하지 않을 때 등, 오류 시 App의 동작을 점검합니다.

아직은 Dev Mode이지만 혼자만의 작업은 아닙니다. 동료들을 개발자 혹은 테스터로 추가해 그들도 자신의 ChatGPT에 App을 연결할 수 있게 합니다. 이 단계의 라이프사이클은 여전히 Draft 상태를 중심으로 돌며, 코드를 빠르게 갱신하고 다양한 UX 패턴을 실험하고 팀 내부 피드백을 주고받습니다.

단계 3. Store 준비와 리뷰

이제 “GiftGenius는 외부 사용자에게 보여줄 만큼 충분히 괜찮다”고 판단합니다. 초점은 코드에서 제품 포장으로 이동합니다.

• App에 대한 정직하고 명확한 설명을 작성합니다.
• 권한을 설정합니다. App이 어떤 데이터에 접근하고 왜 필요한지 설명합니다.
• UX가 혼란을 주지 않는지, App이 불가능한 걸 약속하지 않는지 확인합니다.

이것이 Draft에서 Under review로 넘어가는 순간입니다. App을 리뷰에 제출하고 일정 기간 이 중간 상태에 머뭅니다. 아마도 피드백을 받을 수 있습니다. 예: 개인정보처리방침 보완, 문구 수정, 권한 축소 등. 다시 Draft로 돌아가 보완 후 재제출합니다.

단계 4. 게시와 “진짜 삶”

승인을 받으면 GiftGenius는 Published 상태가 됩니다. 이제 Store에서 사용자가 찾을 수 있고, ChatGPT가 관련 요청에 제안할 수 있으며, 여러분은 실제 피드백과 사용 데이터를 수집하고 확장을 고민합니다.

이제부터 코드 변경은 단순히 “지금 금방 기능 하나 더 붙이자”가 아닙니다. 작은 릴리스입니다. 하위 호환성, 마이그레이션, 가능하면 먼저 dev 버전을 바꾸고 검증한 뒤 production 구성을 업데이트하는 흐름을 고민해야 합니다.

필요하다면 App을 일시적으로 Paused로 전환할 수 있습니다. 예를 들어 치명적인 취약점을 발견했거나 백엔드가 부하를 감당하지 못할 때입니다. 이상적인 모습은 실험을 위한 dev 환경을 잊지 않으면서 Published 브랜치를 점진적으로 발전시키는 것입니다.

7. 개발자가 환경을 생각하는 법: dev, staging, production + Dev Mode

GiftGenius 사례로 Dev Mode의 아이디어부터 게시된 App까지의 여정을 지나왔습니다. 이제 익숙한 dev/staging/production 환경 도식으로 정리하고, 이것이 Dev Mode 및 Store와 어떻게 맞물리는지 보겠습니다.

머릿속에 다음과 같은 매트릭스를 두면 편리합니다.

Developer Mode는 사실상 여러분의 dev 또는 staging 인프라에 붙어 있습니다. 임시 URL을 게시하고, ChatGPT가 이를 테스트에 사용합니다. 반면 Store 구성은 성숙한 production-URL을 가리킵니다.

앞으로 Vercel 배포와 터널을 다룰 때 이 매트릭스는 꽤 구체적인 단계들의 집합으로 바뀔 것입니다. 하지만 지금부터라도 간단한 원칙을 기억하세요. 현재 ChatGPT의 요청이 여러분의 dev 샌드박스에 들어오고 있는지, 아니면 실제 사용자가 접근하는 프로덕션 환경으로 가고 있는지를 항상 인지하는 것입니다.

8. 라이프사이클에 대한 작은 “코드 한 조각”

이 모든 것을 여러분이 익숙한 TypeScript 접근과 연결해 보겠습니다. 플랫폼 레벨이 아니라 여러분의 도구 레벨에서 App의 라이프사이클을 반영하는 간단한 타입을 작성해 보죠. 저장소에 넣어 두고 서로 다른 상태를 잊지 않도록 할 수 있습니다.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – 선물 추천',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

이런 객체를 ChatGPT에 직접 보낼 일은 없지만, 팀이 같은 컨텍스트를 공유하는 데 도움이 됩니다. 앱들의 상태를 보여 주는 간단한 CLI를 만들어, 어디가 초안이고 어디가 이미 Store에 있는지 헷갈리지 않게 할 수도 있습니다.

다음 모듈에서도 우리는 이 라이프사이클 모델로 계속 돌아올 것입니다. Vercel 터널과 배포를 설정하고, MCP 서버와 에이전트 시나리오를 설계하며, 커머스 플로우와 Store 리뷰 준비를 진행할 때마다요. Dev Mode와 Store를 한 시스템의 양극처럼 생각하세요. 실험을 위한 샌드박스와 성숙한 제품을 위한 진열대입니다.

9. Dev Mode와 Store 작업 시 흔한 실수

오류 №1: “바로 Store로 가서 거기서 해결하자”.
때로는 가능한 빨리 “시장 선점”을 하고 싶어, 반쯤 동작하는 프로토타입 단계에서 App을 Store에 올리고 싶어집니다. 이는 거의 확실하게 부정적 사용자 리뷰, 낮은 사용 통계, 추가 리뷰 질의로 이어집니다. Developer Mode에서 몇 차례 반복을 거치며 동료/친구 피드백을 모으고, 기본 UX를 안정화한 뒤에 Store로 가는 편이 훨씬 건강합니다.

오류 №2: dev와 production 환경을 섞어 쓰기.
전형적인 시나리오: Dev Mode를 production과 같은 URL에 물려 놓고, “간단한 디버그 변경”을 실제 사용자가 보게 되어 놀라는 경우입니다. 일반 웹 서비스와 마찬가지로 dev/prod URL은 엄격히 분리해야 합니다. ChatGPT App 구성에 production-URL이 설정되어 있다면, “퇴근 후 빠른 실험”에 그것을 쓰지 마세요.

오류 №3: 상태에 대한 명확한 인식 부재.
개발자가 App이 어떤 상태(Draft, Under review, Published, Paused)에 있는지 인지하지 못하면, 기묘한 상황이 발생합니다. 누군가는 App이 이미 Store에 있다고 생각하고, 다른 사람은 여전히 로컬 프로토타입이라고 여기는 식입니다. 프로젝트의 README에 지금 App이 어디에 있고 다음 단계로 가려면 무엇을 해야 하는지라도 적어 두세요.

오류 №4: 정책과 리뷰를 막판까지 무시.
일부 팀은 App을 “그냥 웹사이트처럼” 만들다가, Store 요구사항(정책, 권한 등)을 제출 하루 전에야 떠올립니다. 그러다 보면 데이터 수집/보관 방식을 크게 고치고, 설명을 다시 쓰고, 권한을 줄여야 한다는 사실을 뒤늦게 알게 됩니다. 처음부터 정책의 틀을 염두에 두고, Dev Mode에서도 솔직하고 최소한의 권한으로 실험하는 편이 낫습니다.

오류 №5: 내부용과 외부용에 대한 별도 전략 부재.
처음엔 내부 기업용 도구로 만든 App을 나중에 공개 제품으로 바꾸고 싶을 수 있습니다. 이때 대상 사용자를 혼동하기 쉽습니다. 사내에서는 덜 매끄러운 UX와 더 복잡한 시나리오가 용인될 수 있지만, 외부 Store의 사용자는 더 높은 편의성을 기대합니다. 지금 어느 모드에 있는가를 이해하지 못하면, 공개 App이 내부 관리자 툴처럼 보이거나, 내부 파일럿이 글로벌 Store를 너무 일찍 의식하느라 멈춰 설 수 있습니다.

오류 №6: Dev Mode와 가시성(관측성)을 연동하지 않기.
Developer Mode는 디버깅에 매우 적합하며, 이 장점을 적극 활용해야 합니다. dev 환경에서 ChatGPT가 여러분의 App에 어떤 요청을 보내는지 로그를 보고 기록하지 않으면, 나중에 production에서 불쾌한 놀라움이 기다릴 수 있습니다. Dev Mode를 “위젯이 빌드된다”만 확인하는 곳이 아니라, 모델과 사용자의 실제 행동을 학습하는 장으로 활용하세요.