챗봇에서 편집기까지

툴에 넘기는 값은 모델이 한 글자씩 만들어내는 출력이다. 사진을 글자로 바꿔(base64) 넣으려면 모델이 그 긴 문자열을 오타 없이 전부 뱉어야 한다.

• 126KB 이미지 → 약 12만 토큰. 가장 큰 모델의 한 번 출력 한도(12.8만)의 94%
• 500KB 사진 → 약 49만 토큰. 한도의 4배
• 공식 Python SDK는 4MiB 넘는 요청 본문을 파싱 전에 413으로 거절

최적화로 해결되는 문제가 아니라 구조적으로 불가능하다. Canva도 같은 이유로 upload-asset-from-url(URL로만 받기) 하나만 남겨뒀다.

판정: 문서화되지 않음. 원본이라고도 축소본이라고도 확정할 수 없다.

공식 문서는 침묵한다

Apps SDK 레퍼런스와 변경 이력을 전수 확인했다. getFileDownloadUrl 설명은 “파일의 임시 다운로드 URL을 가져온다”가 전부다. 원본 여부, 리사이즈, 재인코딩, EXIF, 만료 시간 — 어느 것도 언급이 없다.

증거가 양쪽으로 갈린다

2024년 자료는 오래됐고, 측정 대상도 download_url이 아니라 다른 경로의 사본이었다. 결정적 실측은 아직 아무도 하지 않았다.

화질 이전에 막는 것들

• 모바일은 아예 안 된다 — 파일 대신 껍데기 참조만 오는 버그가 열려 있다
• 이미지 20MB 상한 — 인쇄 원고는 넘기기 쉽다
• HEIC 불안정 — 아이폰 기본 포맷인데도
• URL 만료 시간이 문서화돼 있지 않다
• ICC 프로파일·EXIF 보존이 보장되지 않는다 — 색이 틀어져도 알 방법이 없다

확인하려면

6000×4000 PNG에 고유 EXIF와 AdobeRGB ICC를 심고 해시를 기록한 뒤, 더미 툴로 받아서 해시·크기·ICC를 찍어보면 10분이면 끝난다. 2048px로 돌아오면 인쇄 불가 확정. 다만 ChatGPT 앱을 하나 만들어야 해서 4단계에서나 가능하다. 절차는 scratchpad-research/chatgpt-file-fidelity.md에 있다.

Canva가 쓰는 재료 세 가지

• 이미 Canva에 있는 에셋 — 사용자가 예전에 올려둔 것을 get-assets로 꺼낸다
• 템플릿과 스톡 소재 — Canva가 보유한 디자인 요소와 사진
• 텍스트에서 생성 — generate-design(prompt)로 프롬프트만 가지고

셋 다 “사용자가 방금 채팅에 붙인 사진”이 아니다.

결정적 차이 — 상품의 본질

Canva 상품의 본질은 디자인이다. 인스타 포스트, 프레젠테이션 — 사용자 사진이 없어도 텍스트·레이아웃·스톡 소재만으로 완성품이 나온다. 우리 상품의 본질은 사용자의 사진 그 자체다. 사진 없는 포토북은 상품이 아니다.

같은 벽 앞에서 할 수 있는 일이 다르다. Canva는 이 제약을 우아하게 피해 갈 수 있고 우리는 피할 수 없다. 이것이 “Canva는 되는데 왜 우리는 안 되나”의 답이다.

그래도 가져올 조각

get-assets는 우리 search_my_photos와 같은 발상이다. 스냅스에 사진을 올려둔 재구매 고객에게는 그대로 통한다 — “작년 제주도 사진으로 포토북”이면 바로 꺼낼 수 있다. 신규 고객만 새 업로드가 필요하다.

우리가 더 나은 지점

Figma는 또 다른 선택을 했다 — 미인증 상태로 만든 결과물을 추측 불가능한 URL에 두고 나중에 소유권을 주장(claim)하게 한다. 이커머스 전환에는 이쪽이 유리하고, 우리 익명 진입 구조와 같은 발상이다.

업계 전체가 같은 벽에 있다

Canva·Figma·Adobe 모두 URL이 아니면 받지 못하고, Mixbook은 아예 20장 업로드를 앱에서 받는다. 사진을 챗봇으로 못 받는 것은 우리 설계의 약점이 아니라 업계 공통 제약이다. 차이는 그 다음에 무엇을 하느냐에서 갈린다.

• 채팅에 이미 붙인 사진은 가져오지 못한다. 위젯에서 다시 골라야 한다 — 사용자 입장에서 한 번 더 고르는 마찰이 생긴다
• 아직 검증되지 않았다. 위젯은 샌드박스 iframe인데, <input type="file"> 자체는 샌드박스 토큰을 요구하지 않으므로 동작할 것으로 판단하지만 실제로 돌려봐야 확실하다. 3단계에서 확인할 항목이다
• _meta.ui.domain으로 고유 오리진을 받아야 하고(플러그인마다 하나), 우리 CORS 허용목록에 등록해야 한다
• ChatGPT에는 window.openai.uploadFile()도 있지만 그건 ChatGPT 저장소로 올리는 것이라 원본 문제가 그대로 남는다. 우리가 쓸 것은 connectDomains 경유 직접 업로드다

비용 관점에서는 거의 공짜다. 목업 미리보기 때문에 위젯은 어차피 만들기로 했고, 여기에 업로드 UI를 얹는 것뿐이다.

확인 환경

stg1-kr-mobile-api.snaps.com · 채널 MWEB · 필름 책갈피(00803300010001 / 045021049239) · 2026-09-01

API 순서

POST /v1/project?appType=web60  {productCode}     → prjCode
POST /v1/project/{prjCode}/file  (사진)          → 업로드 응답이 곧 이미지 분석 결과
                                                    (얼굴 위치·화질·특징까지 함께 옴)
POST /v1/project/{prjCode}  multipart           saveFile + 약 40개 필드

디자인 파일 구조

{"scene": [...], "info": {...}} — info는 진단용 메타데이터일 뿐이고 실제 내용은 scene에 있다. 템플릿 조회(GET /v1/template/{code}/json)와 프로젝트 조회(GET /v1/project/{prjCode}/json)가 같은 형식을 돌려주고, 편집기는 둘을 같은 함수에 넣는다.

이것 때문에 계속 실패했다

• finishStatus는 참/거짓이 아니라 "N" / "Y"
• projectSaveType은 "SAVE" 또는 "SAVE_TO_CART"
• 스냅스 백엔드는 필드가 틀려도 500 A500000만 뱉고 무엇이 문제인지 알려주지 않는다. 대조군을 두고 하나씩 갈라야 원인이 나온다

추천 서버를 그대로 쓸 수 있다

기존 ai-rcmd의 multiform.data가 이미 합성된 씬 데이터이고 multiform.order가 슬롯에 넣을 이미지 순서다. 변환 규칙은 “n번째 이미지 자리에 order[n]을 꽂는다” 한 줄이고, 그 변환기가 iOS에 약 50줄로 이미 구현돼 있다. Python 포팅은 작은 작업이다.

프로그래매틱 조립 시 주의

같은 사진을 여러 자리에 쓰면 1장으로 접힌다. 원인은 thumbnailBlob이 사진 단위 키를 쓰기 때문이다. 서버가 만들 때 이미지 키를 사진당이 아니라 자리당 발급하면 우회되고, 추천 서버의 중복 필터는 꺼야 한다.

전부 이미지 1장짜리다(우드블럭 달력만 예외). 차이는 “옵션을 몇 개 정해야 하는가”뿐이다.

옵션 없이 바로 — 10종

크기만 정하면 됨 — 12종

크기 + 방향 — 11종

기타 — 4종

전체 매핑 원본(분기 조건과 소스 줄 번호까지)은 scratchpad-research/product-entry-matrix.md §4에 있다. 근거 파일은 전부 snaps-m/src/components/StoreNavigationActions/index.tsx다.

신 웹 편집기가 지원하는 건 28개 묶음뿐이고, 목록에 없으면 오류로 끝난다. 아래 상품은 네이티브 앱 편집기에서만 열린다.

• 졸업앨범 · 팬북
• 액자 (일반 · 캔버스)
• 카드 · 폴라로이드 팩
• 씰스티커 A5 · 메모패드 · 홈데코

이 상품들은 앱 딥링크라는 별도 트랙이 필요하다. 미설치 사용자를 어떻게 처리할지도 함께 정해야 해서, 이번 일정에는 넣지 않았다.

또 포토북 웹 편집기에는 캔버스가 없다. 5단계 요청 폼(선택→요청→확인→업로드→완료)이고, “직접 만들기”는 프로젝트만 만든 뒤 네이티브로 넘긴다. 포토북 핸드오프의 목적지는 캔버스가 아니라 업로드 단계다.

OpenAI가 챗 안에서 결제하는 기능(Instant Checkout)을 만들었다가 6개월 만인 2026-03-04에 폐기했다. 근거는 실측이다.

• 월마트 기준, 챗 내부 결제가 walmart.com으로 보내는 것보다 전환율이 3분의 1
• ChatGPT 앱을 낸 100개사 중 인앱 결제를 켠 곳은 Instacart 하나뿐

현재 OpenAI 문서는 자사 사이트 결제를 “권장되는 일반적 방식”이라고 명시한다. Shopify도 ChatGPT에서는 판매자 자체 스토어로 넘겨 결제한다. 정책과 시장이 같은 방향이고, 그게 우리가 하려던 방식이다.

“내 그림이 이 키링에 올라간 모습”을 채팅에 보여주는 것은 하기로 정했다. 이미지 1장짜리 상품은 그 그림이 구매 결정의 거의 전부이기 때문이다.

다만 두 가지가 확인됐다.

• MCP가 이미지를 돌려줘도 Claude에서는 접힌 블록 안에 갇혀 안 보인다. 그래서 위젯(MCP Apps) 규격이 필수다
• 그 위젯에 넣을 그림을 그려줄 도구가 회사에 없다. 상품 이미지를 만들어주는 서버가 있지만 액자 전용이라 굿즈에는 거절당했고(직접 호출해 확인), 굿즈에 그림을 얹는 기능은 편집기 안에만 있다

필요한 재료(상품별 위치·크기 정보)는 상품 API가 이미 주고 있어서 아주 어려운 일은 아니다. 편집기의 합성 기능을 서버로 옮기는 작업에 가깝고 3~4주로 잡았다.

저장용 미리보기와 혼동하지 말 것. 저장에 필요한 이미지는 임시 한 장으로 충분하다(실측). 목업은 전환율을 위한 추가 투자이고, 없어도 핸드오프 자체는 완성된다.

위젯은 목업만 담당하지 않는다. 같은 위젯에 파일 선택을 넣으면 사용자가 우리 서버로 직접 원본을 올릴 수 있다(1절 참조). 목업 때문에 어차피 만드는 물건이라, 업로드까지 얹는 추가 비용은 거의 없다. 이미지 1장 상품에서는 “올리고 → 목업 보고 → 편집기로”가 한 위젯 안에서 이어진다.

보안에서 놓치기 쉬운 것

• SSRF — 사용자가 준 URL을 서버가 받아오므로 내부망 주소 차단이 실제로 필요하다. 특히 169.254.169.254가 뚫리면 서버 자격증명이 샌다
• 프로젝트 코드는 인증이 아니다 — 추측 불가능하게 만들고 사용자와 묶어둘 것
• 속도 제한 기준은 IP가 아니다 — 트래픽이 전부 같은 대역에서 온다. 사용자 단위로 걸어야 한다
• 생성 기능에 성격 표시를 해두면 Claude가 항상 사용자 확인을 받는다 — 사고 방지가 공짜로 붙는다

앞선 버전에서는 “사진이 실제로 전달되는 유일한 곳”을 이유로 들었다. 그런데 인쇄용 이미지를 챗봇으로 나르지 않기로 하면서 그 이유는 약해졌다.

남은 이유는 두 가지다.

• 심사 기간이 5~10영업일로 예측 가능하다. Claude는 공개된 기준이 없어 계획을 세울 수 없다
• 실물 상품을 자사 사이트 결제로 넘기는 방식이 OpenAI 가이드라인에 명시적으로 권장돼 있어 반려 위험이 낮다

순서 자체는 유지하되, 근거가 “이미지” 아닌 “예측 가능성”으로 바뀐 것이다.

서울 리전 실측 단가, 1 USD = 1,377원 기준. EC2 t3.small + 기존 ALB에 규칙 추가가 권장 구성이다.

신경 쓸 비용 축

우리 서버가 직접 AI를 불러 사진을 분석하기 시작하면 자릿수가 바뀐다. 월 10만 회 기준 저렴한 모델도 월 50만 원, 상위 모델은 240만 원으로 서버비의 10~50배다. 초기 버전에서 서버측 AI 호출을 넣지 않는 것은 비용 판단이기도 하다.

앞선 버전에 있던 업스케일 GPU 비용은 삭제했다 — 업스케일 자체를 철회했기 때문이다.

공수

탈락시킨 선택지

• AWS Cognito — 필요한 로그인 규격 두 가지를 다 지원하지 않고, 우회하려면 절반을 직접 짜야 한다. 게다가 사용자당 과금이라 더 비싸다
• Bedrock AgentCore Gateway — 챗봇 연결에 필요한 인증 엔드포인트를 노출하지 않는다. AWS 자체 이슈로 “claude.ai 연동을 막는다”고 등록돼 있다
• Fargate — 월 $63.71 고정. 이 트래픽에는 과하다