Back to list
Author BY CM Sirius_Alpha · ·
WebLemon SqueezyGEOSEOClaude Design
· 4 min read

PixelVibe - 프로젝트 정리

목차3

(본래는 Project에 포함되어있었으나, Blog 쪽에서 여러 시도나 회고들을 남기는게 더 나을 것 같아서 분리하였다.)

Pixel Vibe를 개발하면서 새롭게 시도해본 내용들이다.

사실 대부분의 개발은 AI한테 시켰기에 웹 개발이나 구조는 크게 신경 안썼는데(예전에 읽어봐서 기억도 안난다), 어쨌거나 이 글에서는 새롭게 시도하였던 내용들을 정리해보고자 한다.

결제 시스템

  • LemonSqueezy를 사용해보았다. 아직 프로젝트 상품(store) 승인이 안나서 대기중.
    • 결제 과정을 간소화해주는 서비스를 사용했음에도, 처음 설정에 시간이 좀 걸렸다.
  • 사실 결제 시스템 도입 그 자체보다는, Firebase Auth + Firestore + LemonSqueezy + Cloudflare Worker의 유기적인 조합을 통해 Free/Pro 사용자의 기능 차등을 서버 없이 구축하였다는 점이 더 중요한 것 같다.

대략적으로 정리해본 결제 플로우
대략적으로 정리해본 결제 플로우

  • 공부를 위해 잠깐 정리해보자면:
    1. 사용자가 어떤 경로든 업그레이드 intent를 보일 시, 로그인 상태를 확인한다.
      • 로그인 사용자라면 브라우저 단에서 Firestore로부터 해당 사용자의 정보를 리스닝 하고있다.
      • 아니라면 로그인/회원가입 ㄱㄱ, 어쨌건 누가 구독을 시도하는지는 알 수 있어야한다.
    2. 그림에서는 빠졌지만 사용자가 기존에 상품을 구독중이지 않았다면 LemonSqueezy 결제창으로 이동한다.
      • 이곳에서 결제 정보 등록 및 결제가 이루어진다.
      • 이는 다른 경로로 환불, 구독 취소 등의 이벤트가 발생할 경우에도 마찬가지
    3. 성공적으로 구독/환불/취소가 완료되면, CloudFlare Workers를 호출
      • 자체 서버를 열고 Web hook용 엔드포인트를 여는 것 보다, 그냥 잘 만들어진 CloudFlare Workers를 쓰는게 정신 건강상으로 이롭다.
      • 아무튼, Lemon Squeezy에서 적절한 이벤트를 POST 하면, CloudFlare Workers 내에서는
        • 서명 검증 (위조 방지) → 이벤트 분류 → JWT 생성 (계정 인증) 단계를 거친 후 Firestore API로 업데이트를 요청.
    4. Firestore은 이 요청을 받아서, 사용자의 구독 정보나 최근 활동을 업데이트한다.
      • 이때, 브라우저가 Firestore의 유저 정보를 리스닝 하고 있으므로, 정보 변환이 있다면 자연스러운 UI refresh가 발생한다.
      • 예를들어, 구독 츄라이 배너를 지운다던가, 메인 화면으로 리다이렉트 한다던가 등

내가 조치를 덜 취한건지, Lemon Squeezy 측에서 보름 넘게 아무 진전이 없었다. 그런데 이 글을 쓰면서도 의아해서 다시 문의해볼까 했더니, 정말 ‘취재가 시작되자’ 이메일이 날아왔다.

대충 검토할 때 도움될만한 정보 알아서 보내라는 뜻
대충 검토할 때 도움될만한 정보 알아서 보내라는 뜻

어차피 가이드 페이지도 만들어두었기 때문에, 그냥 그 링크 첨부해서 reply 보냈다.

GEO/SEO

  • 내가 직접 한 것은 아니지만, 어쨌거나 클로드한테 지시를 내리기 위해서는 내가 뭐라도 알아야 했다.

    • 이론적인 내용 말고 실전적인 내용까지 적용해서 검토하도록 지시해보았다.
    • 사실 나라고 잘 아는건 아니지만, 그래도 몇 가지 주워들은게 있어서 그 내용을 발전시키고자 하였다.
    • 그렇다. 그냥 Gemini/Claude한테 에이전트 생성 도와달라고 헬프쳤다.

  • 대략적으로 검토 및 확인 요청 사항들은:

    • Semantic HTML Hierarchy / Schema Markup / Rendering Strategy에 따른 전략
      • 봇과 AI가 페이지를 이해하기 위해서는, 적절한 HTML 태그가 적절한 위치에 적절적절한 구조를 이루는 것이 중요함
      • AI/bot은 빌드 시 정의된 정적 HTML 구조를, 사용자는 실제 동적 UI 등이 불러와진 페이지를 보게 됨 (프리 렌더링 방식)
      • 따라서 지침대로라면 HTML 구조가 잘 짜여져있고 의미있는 메타 정보를 제공하는지를 위주로 검토하였을 것임
    • robots.txt를 통한 봇/크롤러 접근 차단 여부
      • ClaudeBot, GPTBot 같은 AI 에이전트들의 접근이 허용되었는가? (GEO)
    • Proof Architecture
      • 대충 이 정보가 신뢰할만한 내용인지, 설명과 reference들이 충분한지 등
      • 그 외로, 얼마나 일관성있게 정보를 전달하는지 = 구조적인 측면도 검토함
    • 그 외의 요소들
      • 언어, 대체 텍스트, Meta tags, sitemap.xml 유효성 등

서브 에이전트가 위 지침을 토대로 초벌로 검토하고, Claude Code가 실제 코드베이스를 탐색하면서 알짜배기만 보고하는 방식. 서브 에이전트는 93라인 21,000자 정도로 작성되었다 - 물론 Recommend 옵션에 따라 claude가 작성해줬다.

그 외

사실, 초기에 Claude Design에게 내 아이디어를 설명한 후 “디자인 시안 뽑아줘” 했더니, 기능까지 거의 85% 이상 구현해서 가져왔다.

Q. ?? 이거까지 해달란 적 없었는데?

A. 어차피 클라이언트 사이드에서 다 처리할거 아님? 그래서 해봤음 ㅎㅎ

  • 과거
    • 인간 디자이너가 두 장의 시안을 만들어서 “이거 버튼 누르면 2번 화면처럼 바뀔거에요”였음.
    • 나는 시안 두 장을 가져가서, “A는 기본 디폴트 상태고, 이 버튼을 누르면 어떤 로직이 돌아서 B 화면처럼 바뀌는거야” 설명
  • 현재
    • 기능 명세랑 디자인 시스템 문서를 던져주면, “이거 버튼 누르면 대충 이렇게 실행됨. 세부 기능은 님이 수정하셈 ㅇㅇ”까지 나옴
    • 클로드 코드가 이 내용을 fetch 해오면, 단순한 레이아웃 뿐 아니라 기능 뼈대까지 한번에 가져오는 것

이러한 이유로, 앞으로 가면 갈수록 코딩 지식이나 디자인 지식도 그렇지만, 내 머리에서 그려진 시안을 ‘어떤 용어로 어떻게 표현할 것인가’가 더욱 중요해지는 것 같다. 이를 위해서 레퍼런스 이미지도 많이 모아두고, UI/UX 용어, 자주 사용되는 패턴 등의 용어도 좀 더 공부해야할 것 같고.

Comments

링크가 복사되었습니다