Agent-Run Business from Zero: 4. Wiring Up Shopify & External Providers

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

에이전트 운영 사업을 구현하기 위해 Shopify와 외부 제공업체의 연결을 마련했지만, 실제 결제·제작·실물 수령까지의 검증은 아직 남아 있다.

📌 핵심 요점

1. Shopify와 Printful의 역할을 분리했다. Shopify는 상거래를 맡고, 자체 작업 프로세스가 맞춤 상품을 Printful API로 전달하는 구조다. 이번에 확인한 것은 연결과 읽기 기능이며, 개발 스토어와 별도로 실제 판매 스토어를 준비해야 한다.
2. 이미지 추출은 초기 가능성을 확인했다. 제품용 AI 연결에는 OpenRouter를 선택했고, Gemini 3.1 Flash를 유망한 이미지 모델로 평가했다. 실제 의류 사진 네 장의 추출 작업은 약 11~14초, 기록된 비용은 총 27센트로 건당 약 6~7센트였다. 다만 선명한 사진 중심의 소규모 시험이다.
3. 학습 금지와 데이터 무보관을 구분해야 한다. 검토한 제공자 정책에는 학습에 사용하지 않아도 프롬프트를 30일간 보관하는 사례가 있었다. 정확한 모델·제공자·지역별 보관 조건은 추가 확인이 필요하다.
4. DigitalOcean 기반 인프라 예산은 월 107달러로 구체화됐다. 관리형 PostgreSQL 15달러와 Spaces 저장소 5달러를 포함한 금액으로, 기존 두 항목 외 추가 예산은 87달러다. 배포 과정에서는 데이터베이스 접근 제한, 로컬 디스크 부족, 불필요한 인프라 추가 등의 문제가 발생했다.
5. 운영 자동화의 역할과 완료 기준을 정했다. 일반 거래는 애플리케이션이 처리하고, 에이전트는 통제된 도구로 진단·지원·예외를 맡는 구상이다. 영상 종료 시점은 9단계 중 비공개 호스팅을 마무리하는 3단계이며, 최종 기준은 사진 업로드부터 실제 결제와 티셔츠 수령까지다.

🧩 배경과 문제 정의

• Shopify 기반 주문형 인쇄 사업의 기본 로직과 랜딩 페이지는 마련됐지만, 상당수 기능은 임시 구현 상태이며 실제 서비스로 배포되지 않았다. 외부 서비스 계정과 API를 연결해 작동 가능한 시스템으로 전환해야 한다.
• Shopify가 상거래를 담당하고 자체 작업 프로세스가 맞춤 상품을 Printful에 전달하는 구조를 목표로 한다. 이를 위해 쇼핑몰·제작 업체·AI 제공자와 함께 데이터베이스와 파일 저장소도 준비해야 한다.
• 핵심 기능인 의류 이미지의 디자인 추출은 품질뿐 아니라 데이터 보관 정책, 처리 속도, 호출 비용을 검증해야 한다. 실제 주문부터 제작까지의 전체 과정 테스트와 출시 준비는 후속 과제로 남아 있다.

🕒 시간순 섹션별 상세정리

1. 외부 서비스 연결에서 실제 주문 검증으로 이어지는 출시 준비

• 이번 작업은 기존 기반 위에 Shopify와 주문형 인쇄 계정을 만들고 실제 제품·서비스를 연결하는 단계다. 이후 이미지 추출과 상품 재설계 기능에 상당한 테스트가 필요할 것으로 예상한다 [00:34]
• 실제 티셔츠를 주문해 처음부터 끝까지 검증할 계획이지만, 이번 영상에서 진행할지는 미정이며 다음 영상이 될 가능성이 높다. 테스트 성공 후 마케팅을 준비하고, 출시 이후에는 에이전트와 Shopify 기능으로 운영을 이어갈 구상이다 [01:08]

2. 새 모델로 기존 구현을 검토했지만 배포는 아직 미완료

• 기존 작업은 주로 GPT Soul과 Fable 5로 진행했으며, 이후 나온 Fable 5.1과 Astra로 검토와 일부 수정을 수행했다. Claude Code 세션을 Hermes 데스크톱 앱으로 가져와 이번 작업에는 Astra를 사용한다 [03:01]
• 13개 구축 단계는 거쳤지만 상당수는 임시 기능이다. 랜딩 페이지는 완성됐고 두 차례 독립 감사에서 확인한 취약점 5개도 수정했으나, 로직이 마련됐을 뿐 실제 배포 시스템은 아직 작동하지 않는다 [04:23]

3. 필수 계정 목록을 정하고 Shopify 개발 환경 구성

• 필요한 외부 서비스는 Shopify, Printful, AI API 제공자, Postgres, 클라우드 파일 저장소다. 도메인은 앞선 작업에서 이미 구매했으며, 계정 설정을 하나씩 진행한다 [05:01]
• Shopify 파트너 계정 등록과 이중 인증 설정을 개발 환경 준비 절차로 잡는다. 사업 정보를 입력해 파트너 계정을 만든 뒤 개발 대시보드에서 테스트용 스토어 생성을 시작한다 [05:38]

4. 개발 스토어와 실제 판매 스토어의 역할 분리

• 개발 스토어는 Basic을 선택하고 미래 기능 미리보기를 끈 상태로 생성한다. 현재 목적은 테스트이며, 실제 운영에는 결국 유료 요금제가 필요할 것으로 예상한다 [07:10]
• Shopify 개발 스토어는 실제 거래 처리나 운영용으로 사용할 수 없다. 출시 준비가 되면 별도의 실제 판매 스토어를 마련해야 하며, 지금 만든 스토어를 최종 공개 매장으로 취급하지 않는다 [08:01]

5. 상품 읽기 권한만으로 Shopify 앱 연결 준비

• 개발 대시보드에서 앱을 생성한 뒤, API 연결 확인을 위한 최소한의 읽기 전용 테스트 구성을 적용한다. 이 단계의 목적은 실제 판매 기능 활성화가 아니라 연결 경로 확보다 [08:25]
• 접근 범위는 상품 읽기로 제한하고 앱 버전을 릴리스한 다음 개발 스토어에 설치한다 [09:44]

6. 로컬 자격 증명 저장과 Shopify 연결 확인

• 앱 설정의 클라이언트 ID와 클라이언트 시크릿을 로컬 환경변수 파일에 저장한다. 자격 증명 입력 과정은 화면에 노출하지 않는다 [11:27]
• Shopify 연결이 작동하면서 테스트 스토어 설정을 마친다. 초기 설정은 정확성을 확인하기 위해 직접 수행하며, 운영을 시작한 뒤에는 개입을 줄이려는 의도다 [12:07]

7. Printful 표준 연동 대신 맞춤 주문 전달 구조 선택

• Printful 계정을 만든 뒤 API 기반 수동 주문 스토어를 구성한다. Shopify는 상거래를 담당하고 자체 작업 프로세스가 개별 맞춤 상품을 Printful로 보내는 방식이다 [13:15]
• 이 구조에 맞춰 Printful의 표준 Shopify 통합은 연결하지 않고, API 연결 방식으로 별도 스토어를 생성한다 [13:43]

8. 제한된 Printful 토큰으로 인증과 상품 조회 검증

• 스토어 범위의 제한된 비공개 토큰을 만들고, 상품 동기화 읽기와 주문 조회 관련 권한을 설정한다. 토큰은 Git에서 제외되는 로컬 환경변수 파일에 저장해 테스트 연결에 사용한다 [14:19]
• Printful 인증과 읽기 전용 스토어 상품 조회가 성공한다. 실제 API 연결은 확보했지만 결제와 주문 이행은 아직 활성화하지 않은 상태다 [16:11]

9. 제품용 AI 제공자로 OpenRouter 선택

• 기존 계정이 있는 New Portal과 OpenRouter를 검토한다. New Portal은 할인 장점이 있지만 Hermes 밖에서 API 키만으로 사용할 수 있는지는 확신하지 못하며, OpenRouter는 별도 API 활용이 가능한 후보로 본다 [16:22]
• 내부 에이전트에는 New Portal을, 제품에는 OpenRouter를 사용하기로 한다. 데이터 무보관 정책을 선택 이유로 들지만, 구체적인 모델 제공자의 설정은 추가 검증 과제로 남는다 [17:06]

10. 이미지 모델 선정에서 학습 금지와 데이터 무보관 구분

• 다음 검증 대상은 정확한 모델·제공자·지역별 데이터 보관 설정이다. 미국 조건으로 필터링한 후보에는 Lux 2 Max와 Lux 2 Flex가 포함되며, 이미지 생성 비용도 함께 고려한다 [18:59]
• 후보가 무보관 관련 목록에 없다는 사실만으로 데이터 보관을 단정할 수는 없다. 그러나 확인한 제공자 정책에는 입력과 출력을 학습에 사용하지 않더라도 프롬프트를 30일간 보관한다는 내용이 있어 요구 조건에 문제가 된다 [20:08]

11. Gemini를 선택하고 지출 한도 내에서 합성 이미지 테스트

• 품질·비용·속도를 고려해 Gemini를 테스트하기로 한다. 상대적으로 낮은 비용을 기대하지만, 계정 잔액이 과도하게 소모되지 않도록 테스트 지출 한도는 2달러로 설정한다 [21:37]
• 첫 합성 참조 이미지 테스트는 성공한다. 티셔츠와 천의 세부 요소를 제거하면서 보이는 텍스트와 작은 탐험가 그림을 유지했고, 비용은 약 4센트였다 [22:53]

12. 실제 아동복 사진 네 장으로 디자인 추출 확대

• 합성 이미지 대신 실제 의류로 목표 기능을 더 직접적으로 검증한다. 아이들 옷에서 닭·꽃·소 무늬와 텍스트가 포함된 사례를 골라 네 가지 입력을 준비한다 [23:36]
• 네 장의 추출 작업은 약 11~14초가 걸렸다. 첫 결과들은 기대보다 좋았으며, 원본과 완전히 같기보다는 같은 스타일을 유지하는 수준을 수용 가능한 기준으로 본다 [24:44]

13. 추출 품질은 유망하지만 불명확한 사진 검증은 남음

• 일부 결과에는 주름처럼 보이는 흔적과 무늬 연속성 문제가 있지만, 소 그림과 작은 텍스트까지 처리한 결과는 긍정적으로 평가한다 [25:10]
• 기록된 비용은 총 27센트로, 건당 약 6~7센트다. 다만 이번 입력은 직접 선명하게 촬영한 사진들이어서, 더 불명확한 실제 사진과 어려운 사례를 추가로 시험해야 한다 [25:42]

14. 호출 비용을 무료 이용 한도와 추가 구매 구상에 반영

• 건당 6~7센트라도 무제한 무료 제공은 어렵다고 판단한다. 무료 계정에 월별 사용량을 배정하고, 예를 들어 월 5달러를 건당 6센트로 계산하면 약 83회 사용할 수 있다는 구상을 검토한다 [26:27]
• 한도를 넘으면 추가 사용량을 구매하는 방안도 고려하지만 가격 정책은 더 생각해 보기로 한다. 현재 AI 설정은 채택하고, 추출 파이프라인의 결과도 긍정적으로 평가한다 [27:05]

15. 호스팅 비교에 관리형 데이터베이스와 에이전트 운영 조건 추가

• 앱 서비스·백그라운드 작업·관리형 데이터베이스를 한 계정에서 다룰 수 있다는 이유로 Render가 추천된다. 익숙한 Railway 계정도 있어, 요구사항에 맞는 상위 5개 대안과 가격 비교를 요청한다 [27:33]
• 비교 과정에서 DigitalOcean에 대한 과거의 좋지 않은 경험이 선택에 영향을 준다. Railway는 데이터베이스 자동 관리가 제공되지 않는다는 조사 내용을 근거로 사용 가능성을 재검토한다 [28:38]

16. 백그라운드 워커의 역할과 DigitalOcean 선택

• 초기 비용은 월 약 50달러로 예상하며, 호스팅의 우선 후보는 DigitalOcean App Platform이다. 워커는 아트 재구성, 디자인 평가, 이미지 삭제를 수행하는 백그라운드 처리기로, 그 자체가 AI 에이전트일 필요는 없다 [30:59]
• 웹 서버와 워커를 별도로 호스팅하는 구성이 비용에 영향을 준다. 워커에는 조정과 로컬 처리를 위한 일반적인 CPU와 메모리가 필요하다 [31:23]

17. 개발 프로젝트와 접근 토큰 설정

• 호스팅과 데이터베이스를 위한 Keepsake Threads 프로젝트를 DigitalOcean에 만들고, 환경은 우선 개발용으로 지정한다 [32:59]
• 에이전트의 DigitalOcean 접근을 위해 토큰을 생성한다. 프로젝트 읽기 전용 범위를 선택하고 키를 로컬 환경변수 파일에 저장한다 [33:48]

18. 월 15달러의 관리형 PostgreSQL 구성

• 관리형 데이터베이스 호환성 검증을 위해 PostgreSQL 17을 선택한다. 기본 일반 사양의 비용은 월 15달러이며, 리전은 뉴욕 NYC1로 정한다 [35:28]
• 데이터베이스를 생성하고 자신의 IP를 신뢰할 수 있는 소스에 추가해 네트워크 접근을 제한한다 [35:51]

19. 데이터베이스 호환성과 권한 격리 문제 해결

• 같은 클러스터의 별도 테스트 데이터베이스에서 마이그레이션과 권한 격리를 시험한다. 실제 스키마와 제한된 런타임 권한이 관리형 서비스에서도 작동하는지 확인하는 절차다 [37:02]
• 역할 관련 문제가 발생한다. 안전하게 격리된 호환성 데이터베이스는 생성됐지만 기존 마이그레이션은 변경하지 않은 상태에서 검증이 막혀 추가 수정이 필요해진다 [38:16]

20. 전체 흐름 테스트를 위한 9단계 계획

• 계정 설정 이후에도 사람의 개입이 얼마나 필요한지 불명확해, 전체 흐름 테스트까지의 단계를 나누고 각 단계에 필요한 입력을 표시하는 계획을 세운다 [40:25]
• 계획은 테스트 기반, 실제 로컬 고객 입력, 비공개 호스팅, 실제 AI, 디자인 라이브러리, 제품 증명, Shopify 결제 테스트, 이행·지원 흐름, 최종 전체 수용 테스트를 다루는 9단계로 구성된다 [40:56]

21. 실제 결제와 실물 수령까지 확장된 완료 기준

• 전체 흐름 테스트는 개발 사이트에서 실제 고객처럼 의류 사진을 올리고 디자인을 생성·승인한 뒤 티셔츠를 주문해 실물을 받는 것으로 정의한다. 임시 데이터로 흐름만 확인하는 수준을 넘어 실제 제품 경험을 검증하는 목표다 [41:56]
• 이 목표에 맞춰 단계별 완료 기준을 조정하되 초기 구현 작업은 유지한다. 실제 카드 정산이 없는 테스트 결제와 실제 Shopify 결제 중 실제 결제를 선택하며, 결과에 따라 여러 번 주문할 가능성도 남겨 둔다 [42:45]

22. 초기 두 단계의 자율 실행과 축적된 스킬

• 사람의 개입이 필요 없는 첫 두 단계는 에이전트가 진행한다. 세 번째 비공개 호스팅 단계부터 DigitalOcean 배포와 저장소 등의 추가 예산이 필요하다 [43:21]
• KT Builder 프로필에는 개발 과정에서 축적된 스킬이 있으며, 권한 경계 설계 스킬은 196회 사용된 최다 사용 항목이다. 제한된 검증, 문서 검토, GitHub 코드 리뷰, 에이전트 세션 모니터링 등의 스킬도 포함된다 [44:20]

23. 비공개 호스팅에 필요한 구성과 추가 비용

• 첫 두 단계가 완료되고 실제 저장소와 CAPTCHA를 포함한 비공개 호스팅 단계로 진입한다. 필요한 구성에는 웹 서비스, 신뢰할 수 있는 입력 처리기, 스캐너, 백그라운드 워커, 기존 관리형 PostgreSQL과 비공개 객체 저장소가 포함된다 [45:29]
• 중간 수준의 권장안은 월 약 89달러의 추가 비용으로 드러난다. 총액이 100달러를 조금 넘는 수준은 수용 가능하다고 판단하지만, 비용을 회수할 수 있을지는 아직 기대에 머문다 [46:16]

24. 일반 거래는 애플리케이션, 예외 처리는 에이전트가 담당

• 에이전트가 운영하는 사업에는 관리형 앱 호스팅과 통제된 운영 기능을 제공하는 구성이 권장된다. 무제한 자격 증명을 가진 서버를 제공하는 방식보다 옵션 B가 적절한 출발점이라는 판단이다 [46:43]
• 예측 가능한 거래는 애플리케이션이 자동 처리하고, 에이전트는 통제된 도구로 진단·지원·예외를 처리한다. 운영 에이전트 자체는 별도로 구축하기로 한다 [47:12]

25. Cloudflare와 DigitalOcean의 목적별 API 접근 분리

• Cloudflare API 토큰 설정이 성공하면서 Shopify, Printful, OpenRouter, Cloudflare, DigitalOcean 등 약 다섯 서비스의 API 토큰을 갖추게 된다 [49:15]
• Turnstile 접근에는 별도의 전용 API 토큰을 추가한다. 설정을 마치면서 Cloudflare가 통합 준비 상태가 된다 [49:36]

26. 객체 저장소 생성과 비밀정보의 수동 관리

• DigitalOcean Spaces에 표준 저장소 버킷을 생성한다. CDN은 비활성화하며 비용은 월 5달러다 [51:42]
• 저장소 접근 키를 추가로 생성하고 새 환경변수 파일에 저장한다 [52:00]

27. 배포 전 점검과 로컬 저장공간 장애

• 저장소 설정 검증을 통과한 뒤 유료 앱 서비스를 시작하기 전에 배포 설정과 테스트를 준비한다 [52:58]
• 9단계 계획상 아직 세 번째 비공개 호스팅 단계다. 실제 AI를 고객 흐름에 연결하는 작업, 디자인 라이브러리, 제품 증명과 인쇄 파일, Shopify 결제, 실제 유료 주문과 실물 검사가 남아 있다 [53:53]

28. 월 107달러 예산 승인과 비공개 GitHub 연결

• 인프라 예산은 월 107달러로 드러난다. 기존 데이터베이스 15달러와 저장소 5달러를 제외하면 월 87달러가 추가되며, 이를 승인한다. 비용을 월 수익으로 회수하는 것은 장기적인 기대이며 초기부터 가능하다고 단정하지 않는다 [55:53]
• 배포를 위한 비공개 GitHub 저장소와 개발 브랜치를 준비한다. GitHub CLI로 에이전트가 저장소 관리를 수행하도록 한다 [56:30]

29. 컨테이너 배포 중 사용량 한도와 DB 접근 장애

• GitHub에 올린 코드로 개발 사이트의 배포용 컨테이너를 빌드한다. 구성은 웹, 의류 입력 처리·스캔, 쓰기 처리·백그라운드 워커의 세 부분으로 설명되며, 기존 입력 시스템을 비공개로 호스팅하는 작업이 계속된다 [57:55]
• 이틀 연속 작업한 끝에 사용량 한도에 도달한다. 주간 한도 초기화까지 4일이 남은 상황에서 사용 가능한 초기화 두 번 중 한 번을 사용해 작업을 재개한다 [58:25]

30. 불필요한 인프라 복잡성 발견과 업로드 성공

• 배포와 서비스 연결에 몇 시간이 더 걸리면서 에이전트가 같은 문제를 반복하고 필요 이상의 인프라를 추가한다는 불만이 생긴다. 단순한 로그인 게이트로 충분한데 불필요한 인프라 계층 두 개를 만들었다는 판단에 이른다 [59:31]
• Astra는 전반적으로 잘 작동했지만 후반에 구성을 지나치게 복잡하게 만들었다는 평가다. 이어 테스트 앱에서 업로드 확인이 성공하고 캡처 성공 메시지가 나타난다 [59:59]

31. 마케팅 준비에 필요한 시간을 고려한 후속 작업 계획

• 3단계는 거의 끝난 것으로 판단하며, 다음 작업으로 마케팅 전략을 계획할 예정이다. 페이스북·인스타그램 계정 생성 등에 시간이 걸릴 수 있어 실행 시점에 앞서 준비하려 한다 [1:00:50]
• 마케팅은 처음 시도하는 영역이며 전문 분야도 아니므로 진행 과정은 아직 불확실하다. 마케팅 전략 계획 이후에는 테스트와 전체 작업 흐름의 최종 점검을 진행할 예정이다 [1:01:08]

32. 이미지 업로드 오류 확인과 출시 전 검증 과제

• 의류 항목에서 이미지 업로드를 시험하자 안전하게 완료하지 못했다는 오류가 반복됐지만, 실제 파일은 저장소에 도달했다. 업로드 버튼을 두 번 누른 것이 오류 원인으로 추정되며, 최종적으로 업로드는 성공했다 [1:02:14]
• 현재 작업은 호스팅을 개발 사이트에 연결하는 3단계의 마무리다. 테스트 단계에 가까워졌으며, 다음 회차에서 마케팅 전략을 계획하고 그다음 회차에서 실제 테스트를 진행할 예정이다 [1:02:48]

🧾 결론

• 주요 제공업체 선정과 API 연결을 마련하면서 임시 구현을 실제 서비스로 옮길 기반을 확보했다. 출시 준비가 완료된 상태는 아니다.
• 이미지 추출의 초기 품질과 호출 비용은 긍정적이지만, 어려운 입력과 인쇄 결과까지 확인해야 고객 경험을 판단할 수 있다.
• 계정 생성과 비밀정보 처리는 사람이 직접 수행했다. 운영 에이전트도 별도 구축 과제로 남아 있어, 현재 단계에서 완전 자율 운영을 입증했다고 보기는 어렵다.
• 배포 후 업로드는 성공했지만 오류 메시지도 반복됐다. 저장소 도달 여부와 사용자 화면의 성공·실패 판정을 함께 검증해야 한다.

📈 투자·시사 포인트

• 사업성 판단에는 호출 비용과 인프라 비용을 함께 봐야 한다. 건당 약 6~7센트의 이미지 처리 비용 외에 월 107달러의 인프라 예산이 제시됐다. 이 수치만으로 전체 사업 원가나 수익성을 확정할 수는 없다.
• 무료 사용량은 비용 한도와 연결된다. 월 5달러를 건당 6센트로 나누면 약 83회라는 계산을 검토했으며, 초과 사용량 판매도 구상했다. 이는 확정된 고객 요금제가 아니다.
• 에이전트 운영을 고려하면 제공업체의 자동화 인터페이스도 중요해진다. DigitalOcean 선택에는 CLI·MCP 지원과 기존 사용 경험이 영향을 줬다.
• 구현 속도와 운영 단순성을 함께 관리해야 한다. 후반부에는 에이전트가 같은 문제를 반복하고 불필요한 계층을 추가했다는 평가가 나왔다. 이 사례에서는 실제 흐름 검증과 구성 단순화가 출시 준비의 중요한 과제로 드러난다.

⚠️ 불확실하거나 확인이 필요한 부분

• OpenRouter 선택 이유로 무보관 정책을 들었지만, 최종 사용하는 모델·제공자·지역 조합의 실제 보관 조건이 모두 확인됐는지는 불명확하다. 학습 미사용 정책만으로 무보관을 판단하면 안 된다.
• 이미지 추출 결과는 선명하게 촬영한 소수 사례에 기반한다. 흐린 사진, 심한 주름, 복잡한 무늬에서도 품질·속도·비용이 유지되는지는 추가 시험이 필요하다.
• 월 107달러는 제시된 인프라 예산이다. 실제 운영 비용과 매출로 이를 회수할 수 있는지는 아직 검증되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 선택한 이미지 모델의 제공자·지역·데이터 보관 조건을 확인하고, 학습 미사용과 무보관을 구분해 기록한다.
• 불명확한 의류 사진과 어려운 무늬를 추가 시험하고, 추출 품질·처리 시간·호출 비용을 비교한다.
• 비공개 호스팅의 업로드 오류를 재현해 중복 클릭과 저장 완료 판정의 관계를 확인한다.
• 실제 판매 스토어 준비와 결제 연결을 진행하고, 사진 업로드·디자인 승인·실제 결제·제작·실물 수령까지 검증한다.

❓ 열린 질문

• 원본과 같은 스타일을 유지하는 추출 결과가 실제 고객 기대와 인쇄 품질 기준을 충족할까?
• 실제 주문과 지원 과정에서 사람의 개입은 얼마나 필요하며, 어떤 예외를 운영 에이전트에 맡길 수 있을까?
• 무료 사용 한도와 추가 구매 가격을 어떻게 정해야 고객 경험과 비용 회수를 함께 만족시킬 수 있을까?