캡스톤 통합: 기술·제품 데모와 “앱 패스포트”

1. “앱 패스포트”란 무엇이며 왜 필요한가

앱 패스포트는 간결하지만 알찬 문서(보통 1–2쪽짜리 Markdown 또는 README의 한 섹션)로, 누구든 여러분의 ChatGPT 앱을 빠르게 이해하게 해 줍니다: 어떻게 구성되어 있는지, 한계는 무엇인지, 어떻게 수익을 내며 프로덕션에서 어떻게 운영하는지 등.

이건 마케팅 브로셔가 아닙니다. 여기에는 “가장 혁신적인 AI 기술” 같은 말이 아니라 아주 현실적인 내용이 담깁니다:

• ChatGPT, 여러분의 위젯, MCP 서버, 에이전트, ACP/Stripe 사이의 경계가 어디인지;
• 어떤 PII를 보관하는지, OAuth/스코프와 시크릿 순환은 어떻게 구성되어 있는지;
• 지연 시간과 가용성에 대한 SLO, 어떤 대시보드와 알럿이 있는지;
• 성공적인 시나리오 1건의 평균 비용은 얼마이며, 과금은 어떻게 하는지;
• 이미 문서화된 대표 인시던트는 무엇이고 런북은 어디에 있는지;
• 앞으로 몇 달 동안 이 앱으로 무엇을 할 계획인지.

패스포트를 링크와 하이레벨 설명의 집합체로 생각해도 좋습니다. 코드보다는 덜 자주, 하지만 “투자자용 공식 발표”보다는 더 자주 업데이트됩니다.

ChatGPT 앱 개발자인 여러분에게 패스포트는 성숙도 체크리스트이기도 합니다. 어떤 섹션이 비어 있다면(“SLO를 아직 정의하지 않았네…”), 이는 문서뿐 아니라 해당 실천 자체가 부족하다는 강한 신호입니다.

2. GiftGenius 앱 패스포트의 기본 구조

GiftGenius에는 다음 구조가 합리적입니다(앱에 맞게 약간 수정해도 되지만 큰 틀은 유지하세요).

누가 무엇을 왜 읽는지 표로 정리하면 다음과 같습니다:

이제 각 블록을 살펴보면서 동시에 GiftGenius용 실제 PASSPORT.md를 함께 작성해 보겠습니다.

3. 아키텍처: 한 장의 그림으로 전체 스택 보여주기

아키텍처 섹션은 패스포트의 핵심입니다. 200개의 사각형이 있는 UML 다이어그램을 그릴 필요는 없습니다. 사용자가 ChatGPT에서 시작해 여러분의 DB와 결제까지 가는 레이어와 흐름을 보여주는 것이 중요합니다. Apps SDK와 MCP를 사용하는 ChatGPT 앱에서 이 경로는 표준적입니다.

편리한 형식은 PASSPORT.md 안에 Mermaid 다이어그램을 직접 넣는 것입니다. 예를 들어 GiftGenius의 경우:

flowchart TD
  U[User in ChatGPT] --> C[ChatGPT + GPT-5]
  C --> W[GiftGenius Widget
Next.js + Apps SDK]
  W --> MCP[MCP Server
giftgenius-mcp]
  MCP --> A[Agent: GiftPlanner]
  A --> DB[(Postgres: products,gifts)]
  A --> ACP[ACP / Stripe]
  ACP --> ORD[(Orders)]

다이어그램 아래 텍스트에서 핵심 시나리오를 설명합니다:

사용자가 채팅에서 선물 받을 사람을 설명합니다. 모델은 MCP 서버의 tool suggest_gifts 호출이 적절하다고 판단합니다. 에이전트는 리소스로 카탈로그를 읽고 여러 tool을 실행할 수 있습니다. 그런 다음 선물을 선택하면 Stripe에서 ACP 세션을 만들고, 체크아웃은 웹후크를 통해 진행되며 결과는 DB에 저장됩니다.

여기서 기술 스택을 함께 언급하면 좋습니다: Next.js 16 + Apps SDK, Node/Python 기반 MCP 서버, PostgreSQL, 캐시용 Redis, 결제는 Stripe.

아키텍처 섹션에 작은 기술 조각을 추가해 다이어그램의 구성 요소가 코드에서 어떻게 드러나는지 보여줄 수 있습니다. 예를 들어, requestId와 userId를 MCP 클라이언트로 전달하는 Next.js 라우트 일부:

// app/api/suggest-gifts/route.ts
import { mcpClient } from "@/lib/mcpClient";

export async function POST(req: Request) {
  const { occasion, budget } = await req.json();
  const requestId = crypto.randomUUID();      // 로그 추적용 트레이스
  const userId = req.headers.get("x-user-id") ?? "anonymous";

  const result = await mcpClient.callTool("suggest_gifts", {
    occasion, budget, requestId, userId,
  });

  return Response.json({ requestId, result });
}

이런 코드 조각은 다이어그램의 “Widget → MCP”라는 추상적 화살표를 실제 코드와 연결해 줍니다.

4. Security & Privacy: 무엇을 정확히 기록해야 하나

패스포트에서의 보안은 “HTTPS를 쓰고 TypeScript 백엔드라 괜찮아요”가 아닙니다. 보안, 컴플라이언스, 법무 관점의 구체적인 질문에 답해야 합니다.

GiftGenius에서는 다음을 간단히 기술합니다:

인증/인가 모델:
커머스 시나리오에는 MCP Auth Server를 통한 PKCE 기반 OAuth 2.1을 사용합니다. 토큰은 user_id와 tenant_id에 연결되며, 체크아웃과 관련된 모든 tool 호출은 commerce.checkout 스코프를 요구합니다.

PII의 범위와 취급 방식.
예: 이메일과 이름은 PII, 선호도 데이터는 가명 처리된 데이터입니다. 이메일은 해시만 로깅하고, 배송지는 저장하지 않으며 Stripe와 웹후크로만 전달합니다.

보존 기간과 삭제 정책:
툴 로그는 30일, 커머스 이벤트는 1년 보관합니다. 사용자 요청 시 주문과 관련 분석 이벤트를 삭제할 수 있습니다.

시크릿 관리:
OpenAI API key, Stripe secret, OAuth client secret을 어디에 보관하는지(예: 관리형 시크릿 스토어), 얼마나 자주 순환(rotating)하는지, 스테이징에서 이를 어떻게 테스트하는지 간단히 설명합니다.

패스포트에 최소 권한 원칙을 보여 주는 기술 중심의 작은 코드 조각을 실을 수 있습니다.

// config/scopes.ts
export const TOOL_SCOPES = {
  suggest_gifts: ["read:products"],
  get_gift_details: ["read:products"],
  create_checkout_session: ["read:products", "write:orders", "stripe:checkout"],
} as const;

이후 도구 설명과 MCP 인증 부분에서 동일한 스코프를 참조합니다. 이제 이는 단순한 “최소 권한” 구호가 아니라 구체적인 계약이 됩니다.

5. Observability와 SLO: 앱의 상태를 ‘보이게’ 하기

다음 블록은 관측 가능성입니다. 앱이 살아 있고 건강한지 어떻게 확인하는가에 대한 부분으로, 구조화된 로그, 메트릭, SLO, 대시보드 링크를 연결합니다.

GiftGenius에서는 다음이 자연스럽습니다:

핵심 SLO.
예: MCP 가용성 ≥ 99.5%, suggest_gifts의 p95 latency < 5초, 체크아웃 성공률 ≥ 99%.

SLO를 어디서 확인하는지.
Grafana/Datadog/…의 대시보드 이름과 URL(패스포트에는 “Dashboard: GiftGenius / SLO”만 적어도 충분).

구조화된 로그 포맷.
앞선 모듈에서 이미 다음 필드를 설계했습니다: request_id, tool_name, user_id/tenant_id, tokens_in/tokens_out, cost_estimate, duration_ms, error_code. 패스포트에는 작은 JSON 예시를 넣어도 좋지만, 우리는 더 나아가 코드에서 사용하는 TypeScript 타입으로 정리합니다.

// lib/logging.ts
export type ToolInvocationLog = {
  level: "info" | "error";
  timestamp: string;
  requestId: string;
  userId?: string;
  toolName: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
};

그리고 헬퍼 함수:

export function logToolInvocation(event: ToolInvocationLog) {
  console.log(JSON.stringify({ type: "tool_invocation", ...event }));
}

이 타입이 코드와 패스포트 사이의 다리가 됩니다. Observability 섹션에서 모든 tool 호출이 ToolInvocationLog 형식으로 로깅된다고 쓰고, 이를 집계하는 대시보드 링크를 함께 제공합니다.

간단한 텍스트 다이어그램을 덧붙일 수도 있습니다:

이벤트 로그 → 로그 저장소 → SLO 대시보드 → 알럿 → 인시던트/런북.

6. Economics & Product Metrics: 비용과 사용자 행동

여기서는 이전 “경제” 모듈(M19)에서 다룬 내용(비용 메트릭, 프라이싱, 제품 분석)을 하나로 연결합니다.

GiftGenius의 패스포트에는 다음을 고정합니다:

핵심 시나리오의 유닛 이코노믹스(가령 “완료된 작업 1건의 경제성”).
예: “평균 cost_per_successful_task(결제까지 성공한 선물 추천 1건) = $0.13(LLM + 인프라). 작업당 평균 매출 = $0.80(파트너 CPA).”

주요 수익화 모델.
간단히: “구매 없이 기본 추천은 무료, 스토어 파트너로의 전환에 대한 CPA로 수익화 + 확장 필터와 선물 히스토리를 제공하는 유료 프리미엄 구독 옵션.”

핵심 제품 지표.
예: activation rate = 최소 한 번 workflow_completed가 발생한 사용자 비율; repeat rate = 한 달 내 최소 한 번 복귀한 사용자 비율; workflow_completed → checkout_success 전환율.

실험.
진행 중인 A/B 목록: “모델 A(비쌈) vs 모델 B(저렴)”, “긴 마스터 vs 빠른 인라인”. 각 실험에 대해 experiment_id, 변형, 타깃 메트릭(전환율, cost_per_task, quality‑score)을 관리합니다.

패스포트가 이론에 그치지 않도록 코드에도 드러내면 좋습니다. 예를 들어 분석 이벤트용 통합 헬퍼:

// lib/analytics.ts
export function trackEvent(
  name: string,
  payload: Record<string, unknown>,
) {
  console.log(JSON.stringify({
    type: "analytics",
    name,
    ts: new Date().toISOString(),
    ...payload,
  }));
}

워크플로 성공 시 호출 예:

trackEvent("workflow_completed", {
  userId,
  requestId,
  experimentId: "model_ab_01",
  variant: "A",
  costUsd: 0.13,
  checkoutSuccess: true,
});

패스포트에서는 어떤 이벤트가 핵심이며 그에 연동된 KPI가 무엇인지 설명합니다. 코드는 “정말 측정하고 있다”는 증거가 됩니다.

다만 메트릭과 경제성은 앱이 프로덕션에서 안정적으로 동작할 때 의미가 있습니다. 다음 섹션에서는 GiftGenius의 운영 측면—인시던트, 온콜, 런북—을 패스포트에 어떻게 고정할지 살펴봅니다.

7. Ops & Incidents: 프로덕션에서 앱과 함께 살아가기

이 섹션은 일이 뜻대로 흘러가지 않을 때 어떻게 대응하는가에 대한 내용입니다.

GiftGenius의 패스포트에는 최소한 다음 두 가지 대표 인시던트를 적습니다:

결제 문제.
예: 체크아웃 성공률이 SLO 아래로 하락, Stripe 웹후크 대량 오류. 패스포트에는 이를 위한 런북 “Checkout Failures”가 있으며, 증상, 확인 위치(오류 대시보드, 웹후크 엔드포인트 로그), 즉각적인 완화 조치(문제 플래그 비활성화, 일부 트래픽을 샌드박스로 전환 또는 임시로 상품권만 추천)와 후속 조치(포스트모템, 신규 알럿 추가)가 정리되어 있다고 씁니다.

MCP/LLM 문제.
예: suggest_gifts의 p95 지연 시간이 9초로 상승하거나 많은 요청에서 “Error talking to app”이 발생. 여기에는 별도의 런북이 있으며, OpenAI 상태, 터널/Vercel, MCP 헬스체크 확인, 카탈로그 없이도 응답을 시도하는 강등(degraded) 모드로 전환(커머스 없이 일반 아이디어만 제시) 등이 포함됩니다.

같은 섹션에 운영 캘린더도 간단히 기록합니다: SLO 재검토 주기, 비용 리뷰 주기, 보안 로그 점검 주기, 시크릿 순환 주기 등.

또한 온콜 담당자(한 명뿐이어도)와 알럿이 도착하는 Slack 채널 또는 이메일도 적어 둡니다.

8. Roadmap & Risks: 현실적인 전망

마지막 블록은 미래에 관한 것입니다. 장편 소설이 필요하지 않습니다. 앱의 현실적인 발전 과제 3–5개와 알려진 제약 몇 가지면 충분합니다.

GiftGenius의 예:

• 추천 품질을 전환율과 연결하기 위한 LLM 평가(LLM‑evals) 도입;
• 추가 로케일 도입 및 도구 설명 로컬라이제이션 실험;
• 일부 트래픽에서 더 저렴한 모델 실험;
• Stripe 장애에 대한 복원력 개선(웹후크와 지연 확인 처리 강화);
• Apps SDK 또는 MCP 새 버전으로의 마이그레이션 대비(툴 계약 버저닝).

제약: API 한도(캡), ChatGPT UI의 제한(예: 결과 카드 수 제한), 현재 아키텍처의 취약점(싱글 리전 DB, MCP 핫 스탠바이 부재 등).

실험 계획: 프라이싱/UX/모델 관련 어떤 가설을 검증할지, 그리고 어떤 메트릭으로 의사결정을 내릴지.

9. 패스포트의 위치와 업데이트 방법

실무에서 가장 편한 형식은 GiftGenius 저장소 루트 또는 docs/ 폴더의 PASSPORT.md이며, 내부 문서 시스템(Confluence, Notion 등)에 복사/링크를 남겨 둡니다.

10–15분 안에 읽을 만큼 가볍되, 다음 질문에 답할 만큼 밀도가 있어야 합니다:

• “이게 대체 어떤 앱이고, 어떻게 구성돼 있나?”
• “X가 다운되면 어떻게 되나?”
• “사용자 1명당 우리에게 얼마나 비용이 드나?”
• “지금 우리가 가장 우려하는 리스크는 무엇인가?”

다음이 바뀌면 패스포트를 업데이트하세요:

• 아키텍처 경계(새 서비스, 새 결제 수단, 다른 스택으로의 마이그레이션);
• 핵심 SLO나 보안 정책(예: 다른 보존 기간);
• 수익화 모델;
• 중요 인시던트와 포스트모템에서의 인사이트.

사소한 코드 변경까지 즉시 반영할 필요는 없습니다. 그렇지 않으면 또 하나의 금방 낡아버리는 문서가 됩니다.

결국 패스포트는 여러분이 앱에 대해 아는 모든 것을 농축한 것입니다. 다음 자연스러운 단계는 이를 바탕으로 기술·비즈니스 모두에게 제품을 이야기하는 법을 익히는 것입니다.

10. 기술·제품 데모: 왜 두 가지 ‘버전의 스토리’가 필요한가

GiftGenius를 보여줄 때 여러분은 거의 항상 두 유형의 청중(때로는 한 자리에 섞여 있음) 앞에 서게 됩니다:

• 기술 청중(CTO, 아키텍트, 시큐리티, 개발 리드);
• 제품/비즈니스 청중(CEO, 투자자, 프로덕트 매니저, 마케팅).

기술적 청중이 중요하게 보는 것:

• 아키텍처가 명확하고, 레이어가 분리되어 있으며, 확장 포인트가 있다는 점;
• 신뢰성과 관측 가능성: 로그, 트레이싱, SLO, 알럿;
• 복원력 스토리: OpenAI, MCP, Stripe가 다운되면 어떻게 되는가;
• 향후 진화 계획(SDK/MCP/모델 마이그레이션).

비즈니스 청중이 더 궁금한 것:

• 사용자의 고통은 무엇인가(예: “선물 찾기에 40분이 걸린다”);
• GiftGenius가 ChatGPT 안에서 몇 분 만에 그 문제를 어떻게 해결하는가;
• 수익화, 유닛 이코노믹스, 성장 지표는 무엇인가;
• CAC를 낮추고 전환/매출을 높일 수 있는가.

따라서 동일한 데모 스토리를 두 “레이어”로 사고하세요. 성숙한 제품의 증거는 둘 모두에게 보여 주되, 강조점은 다르게 가져갑니다.

11. GiftGenius 기술 데모 시나리오(5–7분)

기술 청중 앞에서 GiftGenius를 발표한다고 가정해 봅시다.

먼저 짧은 컨텍스트.
30초 정도: “GiftGenius는 ACP 체크아웃을 갖춘 선물 추천용 ChatGPT 앱입니다. 우리는 ChatGPT 내부에서 Apps SDK, MCP, 단계 계획용 에이전트를 사용합니다.”

이어서 아키텍처 슬라이드/패스포트 조각.
Mermaid로 만든 것과 유사한 다이어그램을 열고, ChatGPT(LLM 부분), 여러분의 위젯, MCP, Stripe가 있는 커머스 레이어의 경계를 설명합니다. 모든 tool이 MCP에 캡슐화되어 있고 위젯은 얇은 UI 레이어임을 보여주면 유익합니다.

로그를 곁들인 라이브 데모.
스플릿 화면을 켭니다. 왼쪽은 GiftGenius가 열려 있는 ChatGPT, 오른쪽은 로그나 MCP Inspector. “게이머를 위한 50달러 이하 선물 추천”처럼 자연스러운 요청을 합니다. 실행 과정에서 다음을 보여줍니다:

• suggest_gifts tool 호출과 request_id;
• tool_invocation 구조화 로그에서 보이는 tokens, cost_estimate, duration_ms;
• ACP 세션을 만들고 주문을 생성하는 보조 tool.

바로 대시보드를 보여줄 수 있다면 최고입니다. “지난 24시간 이 시나리오의 p95 지연 시간, 체크아웃 성공률은 여기입니다.” 이 지점에서 기술 청중은 이것이 애완 프로젝트가 아니라 관측 가능성을 갖춘 시스템임을 이해합니다.

장애 주입(Failure injection, 선택이지만 매우 효과적).
시스템에 자신이 있거나(혹은 사전 시나리오를 준비했다면) 카탈로그(DB) 접근을 잠시 끄고 요청을 반복할 수 있습니다. 다음을 보여줍니다:

• MCP가 오류를 올바르게 로깅하고 알럿이 발동한다;
• 에이전트가 강등 모드로 전환해 카탈로그가 불가용하다고 사용자에게 솔직히 알리고, 일반적인 아이디어만 제시한다;
• 이 모드에서는 체크아웃이 불가하다.

마지막으로 운영과 진화 계획을 짧게.
패스포트의 SLO, 인시던트, 로드맵 슬라이드로 마무리합니다. 목표 지표, 모니터링 방식, 런북이 있는 인시던트, v2 계획(스케일링, 새 모델, 새 시장)을 간단히 보여주세요.

핵심 메시지: 우리는 멋진 UI만 가진 것이 아니라, 프로덕션에서 살아갈 준비가 된 탄탄한 플랫폼을 만들었다는 점입니다.

12. 제품 데모 시나리오(비즈니스 관점)

이제 같은 GiftGenius를 제품 관점에서 이야기해 봅니다.

사용자 이야기로 시작.
예: “Katya라는 사용자가 있습니다. 그녀는 저녁 시간에 동료에게 줄 선물을 골라야 합니다. 보통은 쇼핑몰 웹사이트를 돌아다니며 30–40분을 쓰죠.”

ChatGPT에서 GiftGenius를 보여줍니다.
Katya는 마켓플레이스에서 필터를 누르는 대신 자연어로 씁니다. “보드게임을 좋아하는 동료에게 줄 선물 추천, 예산은 50달러.” ChatGPT는 GiftGenius를 사용할 수 있다고 설명하고 위젯을 엽니다. GiftGenius가 몇 가지를 확인한 뒤 후보 목록을 보여줍니다.

결과와 가치를 강조.
선물 카드, 저장하기 또는 바로 구매로 이동, ACP/Stripe를 통한 체크아웃을 보여줍니다. “사용자가 원래 시간을 보내는 곳—바로 ChatGPT—에서 이 모든 과정이 3–5분 만에 끝난다”는 점이 중요합니다.

그다음 1–2분은 수익화와 지표.
스토어 CPA 또는 수수료로 수익을 내고, 잦은 사용자에게 프리미엄 모드를 제안할 수 있음을 설명합니다. 패스포트의 수치(성공 시나리오 1건의 비용, 구매 전환율, 마진 여유)를 인용합니다.

다음은 성장에 대해 조금.
사용자 유입 계획을 이야기합니다: ChatGPT 스토어 리스팅, 콘텐츠, 파트너 통합 등. 그리고 이를 제품 지표에 연결합니다. “리스팅 변경이 신규 app_opened 수와 activation rate에 어떤 영향을 주는지, 글과 영상이 리텐션과 ‘workflow_completed가 1회 초과’ 사용자 비율에 어떤 영향을 주는지 살펴본다.”

리스크와 계획으로 마무리.
현재 제약(예: OpenAI/Stripe 한도 의존, 로케일 지원 미흡)을 솔직히 말하고, 파이프라인에 있는 실험과 개선 로드맵을 보여줍니다.

준비를 잘하면 비즈니스 청중은 “또 하나의 AI 위젯”이 아니라 경제성과 성장 계획을 갖춘 명확한 제품을 보게 됩니다.

13. 실습: GiftGenius를 중심으로 나만의 패스포트와 데모 만들기

이 강의의 실습으로, 여러분의 GiftGenius 저장소에 바로 PASSPORT.md 파일을 만들고 최소 다섯 블록—아키텍처, 보안, observability/SLO, 경제성과 제품 지표, 인시던트/운영—을 채워 보세요. 새로운 런북을 작성하거나 SLO를 변경할 때마다 패스포트로 돌아와 그 변화를 반영합니다.

동시에 5–7분 데모용 대본도 만들어 두세요. 처음 2–3분은 사용자 시나리오와 가치, 다음 2–3분은 아키텍처와 운영(SLO, 비용, 인시던트). 이런 대본은 비즈니스와 기술의 언어를 동시에 구사하는 연습에 큰 도움이 됩니다. 건조한 코드나 빈약한 마케팅으로 치우치지 않게 해 줍니다.

이 두 아티팩트는 “형식적인 서류”가 아니라 최종 캡스톤 데모의 기반입니다. 바로 이 패스포트와 시나리오를 바탕으로 CTO/CEO 앞에서 앱을 방어하게 될 것입니다.

14. 패스포트/데모 준비 시 흔한 실수

오류 №1: 패스포트를 마케팅 북릿으로 만들어 버림.
가끔 패스포트가 랜딩 페이지처럼 변합니다. “혁신적인 AI” 같은 말은 많고 아키텍처, SLO, 비용, 인시던트는 빈약합니다. 이런 문서는 누구에게도 도움이 되지 않습니다. 기술자는 내부가 어떻게 돌아가는지 모르고, 비즈니스는 리스크를 통제하고 있는지 보지 못합니다. 패스포트에는 사실, 도식, 메트릭, 링크가 있어야 합니다.

오류 №2: 코드를 나열할 뿐, 데이터 흐름과 책임을 설명하지 않음.
개발자에게 흔한 편향은 각종 서비스, 라이브러리, 프레임워크를 줄줄이 나열하면서 “사용자 → ChatGPT → 위젯 → MCP → 에이전트 → ACP/DB”라는 하이레벨 흐름을 잊는 것입니다. 결과적으로 새로 합류한 사람은 책임의 경계가 어디인지 이해하지 못합니다. 아키텍처 섹션에서 더 중요한 것은 npm 패키지 이름이 아니라 데이터 플로우와 레이어입니다.

오류 №3: 패스포트를 observability/비용 계측과 연결하지 않음.
패스포트에 “우리는 SLO가 있다”라고 당당히 적혔지만, 실제로 그것을 어떻게 측정하는지, 로그가 어디에 있고 JSON 이벤트에 어떤 필드가 쓰이는지 보이지 않는 경우가 있습니다. 혹은 “LLM 비용이 통제되고 있다”라고 하지만 cost_per_task 같은 메트릭이 하나도 없습니다. 실 로그/메트릭/대시보드와의 연결이 약할수록 SLO와 비용은 Google Docs 속 문구일 가능성이 큽니다.

오류 №4: 아키텍처와 내고장성을 보여주지 않는 ‘예쁜 UI 쇼’만 함.
“선물 카드가 정말 멋지죠?”라는 쇼로 흐르기 쉽습니다. 하지만 기술 청중은 “Stripe가 다운되면?”, “tool 호출은 어떻게 로깅하나?”, “스케일할 수 있나?”를 생각합니다. 데모에서 최소 한두 가지는 로그, SLO, 인시던트 스토리를 보여주지 않으면 장난감 같은 인상만 남습니다.

오류 №5: 기술에만 치우친 데모—사용자 스토리와 경제성이 없음.
반대의 편향입니다. p95 지연 시간, MCP 핸드셰이크, JSON Schema 얘기를 10분 동안 하지만 정작 어떤 사용자 문제를 해결하는지, 누가 비용을 지불하는지, 시나리오 1건이 얼마나 드는지 한 번도 말하지 않습니다. 비즈니스와 프로덕트에는 “멋진 엔지니어링 작품이지만 비즈니스 케이스가 없다”로 보입니다. 항상 엔지니어와 프로덕트 매니저의 모자를 동시에 쓰고 이야기하세요.

오류 №6: 패스포트와 데모가 따로 논다.
패스포트에는 이렇게 쓰여 있는데 데모에서는 저렇게 보이는 경우가 있습니다. 문서에는 이런 SLO가 약속되어 있지만 대시보드에는 다른 값이 나오거나, 패스포트에는 런북이 있는 3개의 인시던트가 적혀 있는데 라이브 발표에서는 첫 장애에 모두 우왕좌왕합니다. 패스포트를 데모의 시나리오로 사용하세요. 동일한 SLO, 동일한 대시보드, 동일한 런북을 참조하면 청중은 ‘우연히 모인 아티팩트’가 아닌 ‘하나의 응집된 시스템’을 보게 됩니다.

오류 №7: 패스포트를 일회성 과제로 취급.
가장 큰 함정은 모듈 제출용으로 PASSPORT.md를 한 번 쓰고 잊어버리는 것입니다. 현실에서는 이런 문서가 팀을 ‘머릿속에만 있는 지식’의 동물원으로 만듭니다. 패스포트를 코드의 살아 있는 일부로 대하세요. 중요한 아키텍처/운영/비즈니스 결정이 있을 때 함께 변화해야 합니다. 그러면 두어 달 뒤의 여러분이 스스로에게 고마워할 것입니다.