결제를 붙이는 건 코딩이 아니라 행정이다

4월 12일부터 24일까지, 화조당은 "서비스"에서 "사업"으로 넘어가는 관문을 통과했다. 결제 시스템을 붙이고, 법적 요건을 갖추는 일. 코드를 짜는 것보다 서류를 준비하는 게 더 어렵다는 걸, 이 2주 동안 뼈저리게 느꼈다.

도메인, 파이프라인, 그리고 기억하는 AI

4월 12일. 먼저 hwajodang.com 도메인을 Cloudflare에서 구매했다. 연 $9.77. 도메인 비용이 커피 두 잔 값이라니, 좋은 세상이다. Vercel에 연결하고, 커스텀 도메인으로 서비스가 돌아가기 시작했다.

같은 날 n8n과 ComfyUI를 연결해서 이미지 생성 파이프라인을 구축했다. 유나(화조당의 AI 상담사)의 이미지를 자동으로 생성하고 관리하는 흐름이다. 수동으로 하나씩 만들던 걸 파이프라인 하나로 자동화하니, 작업 속도가 완전히 달라졌다.

그리고 사용자 기억 시스템(User Facts)을 만들었다. Haiku 모델이 대화에서 사용자의 개인적 사실 — 이름, 생년월일, 고민거리, 가족 상황 같은 것들 — 을 자동으로 추출해서 저장한다. 다음 대화에서 유나가 "지난번에 말씀하셨던 직장 고민은 좀 나아지셨어요?"라고 물어볼 수 있게 되는 거다. 사주 상담이라는 게 결국 사람 이야기니까, AI가 사용자를 기억하는 건 핵심 기능이다.

이용약관과 개인정보처리방침도 이날 작성했다. 서비스를 만들 때는 이런 문서가 "나중에 하면 되지"라는 생각이 들지만, 결제를 붙이는 순간 "지금 당장" 필요해진다. 결제 심사에서 가장 먼저 확인하는 게 이런 법적 문서들이다.

이중 결제 시스템이라는 설계

4월 13일. 결제 시스템의 큰 그림을 완성했다.

화조당은 한국 사용자와 해외 사용자를 동시에 타겟한다. 한국은 원화(KRW), 해외는 달러(USD). 결제 수단도, PG사도 달라야 한다. 그래서 이중 결제 시스템을 설계했다.

• 포트원 V2 — 한국 사용자용. 토스페이먼츠 연동. 카드결제, 간편결제.
• Lemon Squeezy — 해외 사용자용. PayPal, 해외 카드 지원.

충전 플랜은 3개로 심플하게 가져갔다.

충전식 포인트 모델을 선택한 이유가 있다. 사주 상담은 월정액보다 건당 과금이 자연스럽다. 한 달에 한 번 볼 수도 있고, 집중적으로 매일 볼 수도 있으니까. 사용자 입장에서 부담 없이 시작할 수 있는 구조다.

이날 Capacitor 네이티브 앱 전략도 정했다. Next.js 웹앱을 Capacitor로 감싸서 iOS/Android 네이티브 앱으로 배포하는 전략이다. 웹 하나 만들어서 앱스토어까지 가져가겠다는 구상. 1인 개발에서 이런 멀티플랫폼 전략이 가능해진 것도 기술의 진보다.

고객 문의를 대화로 만들다

4월 17일. 고객 문의 시스템을 완전히 뜯어고쳤다.

기존에는 단순한 Q&A 형태였다. 질문 하나, 답변 하나. 그런데 실제 고객 문의는 한 번에 끝나지 않는다. "이건 어떻게 되나요?" → "아, 그러면 이건요?" → "감사합니다, 그런데 하나만 더..." 이런 흐름이 자연스럽다.

그래서 대화 스레드 시스템으로 전환했다. 하나의 문의가 하나의 스레드가 되고, 그 안에서 대화가 이어진다. 카카오톡 채팅방처럼.

여기에 AI 초안 생성 기능을 넣었다. 고객 문의가 들어오면 AI가 먼저 답변 초안을 만들어둔다. 내가 확인하고, 수정하고, 보내면 된다. 1인 운영에서 이건 필수다. 잠자는 동안에도 문의가 쌓이니까, 아침에 일어나면 초안이 준비되어 있는 게 전혀 다른 경험이다.

관리자 모바일 UI도 2차 리디자인했다. 이동 중에 스마트폰으로 문의 확인하고 답변하는 플로우. 관리자 화면은 결국 내가 가장 많이 쓰는 화면이니까, 여기에 시간을 투자하는 건 당연한 일이다.

심사라는 이름의 행정 전쟁

4월 19일. 이 날이 이 2주의 하이라이트다.

토스페이먼츠 실연동 심사를 신청했다. 테스트 연동은 쉽다. API 키 넣고, 결제 플로우 만들고, 테스트 카드로 결제하면 끝. 그런데 실연동은 다른 세계다.

사전점검에서 바로 실패했다.

첫 번째, 유선번호 누락. 사업자 연락처에 유선번호가 있어야 한다. 070 번호를 알아보고 세팅했다. 두 번째, 가격 페이지 미공개. 결제 심사를 받으려면 사용자가 가격을 볼 수 있어야 한다. 가격 페이지를 만들어서 배포했다. 이런 것들이 코드의 문제가 아니라 "정합성"의 문제다. 서비스의 모든 요소가 일관되게 갖춰져 있어야 심사를 통과한다.

그리고 해외 결제 쪽에서 예상치 못한 벽을 만났다.

Lemon Squeezy가 화조당을 거절했다. 사유: fortune telling은 고위험 카테고리(high-risk category). 사주, 타로, 점술 관련 서비스는 차지백(chargeback) 리스크가 높다는 거다. 해외 PG사 입장에서 이해가 안 되는 건 아니다. 하지만 준비해왔던 연동 코드가 한순간에 무용지물이 됐다.

여기서 멈출 수 없었다. 바로 Gumroad로 전환했다. Gumroad는 디지털 상품 판매 플랫폼이라 결제 심사가 상대적으로 유연하다. 연동 코드를 Gumroad API로 교체하고, 웹훅 설정하고, 결제 플로우를 다시 테스트했다. 당일 완료. 거절당한 날 저녁에 새 결제 시스템이 돌아가고 있었다.

이 경험에서 배운 건 명확하다. 결제를 붙이는 건 코딩이 아니라 행정이다. 코드는 하루면 바꿀 수 있지만, 심사 기준을 이해하고, 거절당했을 때 대안을 찾고, 법적 요건을 맞추는 건 전혀 다른 능력이 필요하다. 기술 스택을 고르듯이 PG사도 전략적으로 골라야 한다.

SNS 자동화의 기반

4월 22일. 마케팅 채널 준비를 시작했다.

Threads 자동화 기반공사. Meta API 토큰을 발급받고, n8n에서 자동 포스팅 워크플로우의 뼈대를 잡았다. 유나의 사주 팁이나 운세 콘텐츠를 자동으로 Threads에 올리는 구상이다.

유나 이미지도 정리했다. 679장에서 635장으로. 품질 기준에 못 미치는 이미지들을 솎아냈다. 그리고 캡션 70장을 작성했다. 이미지 하나하나에 유나의 성격과 어울리는 문구를 달아야 하니까, 이건 자동화하기 어려운 영역이다. AI가 초안을 잡고, 내가 다듬는 방식으로 작업했다.

입점심사, 그리고 행정의 끝없는 루프

4월 24일. 포트원 입점심사에 진입했다.

Footer를 리팩토링했다. 사업자 정보, 이용약관, 개인정보처리방침 링크가 정확하게 노출되도록. 개인정보처리방침에 위탁업체 정보도 추가했다. PG사를 통한 결제 처리는 개인정보 위탁에 해당하니까, 이걸 명시하지 않으면 심사에서 걸린다.

그리고 통신판매업 변경신고를 접수했다. 사업 내용이 바뀌면 신고 내용도 업데이트해야 한다. 이것도 결제 심사의 필수 조건.

돌이켜보면 이 2주는 "코드를 짜는 시간"보다 "서류를 준비하는 시간"이 더 길었다. 이용약관, 개인정보처리방침, 사업자 정보, 통신판매업 신고, PG사 심사 서류. 코드는 밤에 짜고, 낮에는 행정을 했다.

세 결제사를 거치며 배운 것

포트원, Lemon Squeezy, Gumroad. 세 결제사를 거치면서 깨달은 것들을 정리하면 이렇다.

1. 심사 기준을 먼저 확인하라. 코드부터 짜지 말고, 내 서비스가 해당 PG사의 금지 카테고리에 해당하는지 먼저 확인해야 한다. Lemon Squeezy에서 거절당한 건, 사전에 약관을 읽었으면 피할 수 있었다.

1. 법적 문서는 결제보다 먼저 준비하라. 이용약관, 개인정보처리방침, 사업자 등록 정보, 통신판매업 신고. 이게 없으면 심사 자체가 시작되지 않는다.

1. 대안은 항상 준비해둬라. Lemon Squeezy가 거절당했을 때 당일에 Gumroad로 전환할 수 있었던 건, 결제 로직을 추상화해뒀기 때문이다. PG사에 종속되지 않는 구조를 만들어놓으면, 전환 비용이 극적으로 줄어든다.

1. 1인 개발자에게 행정 능력은 기술 능력만큼 중요하다. 코드를 잘 짜는 것만으로는 서비스를 런칭할 수 없다. 심사를 통과하고, 법적 요건을 맞추고, 사업자 등록을 관리하는 것. 이게 다 "개발"의 일부다.

다음 포스트에서는 유나의 이미지 시스템과 프롬프트 엔지니어링 이야기를 써보겠다. AI 캐릭터를 "살아있게" 만드는 작업은, 결제 심사와는 또 다른 종류의 집요함이 필요했다.