firebase

[스타트업/기술] 인앱결제 Part 3 | 검증에 성공한 뒤에 시작되는 문제들

문제 영구 실패 영수증의 무한 재전송, 남의 것인 영수증, 검사에 막히는 정당한 결제. 결정 영구 실패는 terminal 신호와 거부 행(poison pill)으로 끊고, 소유권은 uuidv5로 대조하고, 로그엔 HMAC 지문만 남기고, 막힌 결제자는 런북을 붙인 수동 적립으로 구제한다. 대가 구제는 사람의 판단에 기대고, poison pill이 Pending 결제를 영구 거부하는 결함을 만들었다. 결과 같은 uid 동시 20…

hyeon_B•

[스타트업/기술] 알림함 아키텍처: Fan-out on Write vs Fan-out on Read | 비용을 '구독자 수'가 아닌 '활성 유저 수'에 비례시키기

문제 토픽 브로드캐스트를 서버가 받은함에 펼치면 발송 1건의 Firestore 쓰기가 구독자 수만큼 늘어난다. 게다가 순수 토픽은 서버가 구독자가 누구인지조차 모른다. 결정 서버가 수신자를 uid로 풀 수 있는 발송(uid 지정, 세그먼트, 동의 기반 토픽)은 쓰기 시점에 서버가 펼치고, 풀 수 없는 순수 브로드캐스트( lang-* )만 앱이 열릴 때 클라이언트가 채운다. 대가 멱등성, 동의 재검증, 커서 관리를 클라이언트가 직접 …

hyeon_B•

[스타트업/기술] WebP 변환을 통한 이미지 로딩 최적화 및 GCS 업로드 자동화 | PNG 대비 용량 89%, 지연 시간 81% 개선

문제 GCS 직접 호출로 한 번 줄였는데도 이미지 한 장에 1.39s가 걸렸다. 원인은 파일 자체였다. 에셋이 전부 무손실 PNG였고, 측정한 이미지는 477KB였다. 결정 PNG를 품질 82의 WebP로 바꾸고, 변환과 GCS 업로드(캐시 헤더, URL 맵 포함)를 셸 스크립트 두 개로 묶었다. 대가 손실 압축이라 화질이 조금 깎이는데, 얼마나 깎였는지는 재지 않았다. WebP를 못 읽는 환경을 위한 폴백도 두지 않았다. 결과 …

hyeon_B•

[스타트업/기술] SSoT 기반 카탈로그 시스템 설계 | 파편화된 가격 데이터의 비효율성을 극복하고 프로모션 구조 구축하기

서비스를 고도화하는 작업을 진행하면 할수록 초기에 잘 동작하는 것처럼 보였던 설계가 발목을 잡는 순간이 온다. 최근 우리 서비스의 결제 및 가격 구조를 개편하면서 이 사실을 다시 한번 느꼈다. 기존에는 콘텐츠마다 가격을 따로 정할 수 있게 설계돼 있었다. 그런데 출시를 앞두고 프로모션을 기획해야 하는 시점이 오자 이 구조가 기술 부채로 돌아왔다. 이 글에서는 흩어진 가격 데이터를 SSoT(Single Source of Truth, 단일 진실 …

hyeon_B•

[스타트업/기술] Node.js & App Store 인앱결제 | 결제 시스템 아키텍처 (Part 2)

문제 안드로이드와 영수증 형식이 전혀 다른 iOS(StoreKit 2 JWS)를 같은 원칙, 같은 지급 로직 위에 올려야 했다. 결정 JWS는 로컬에서 풀어 값싼 사전 거절에만 쓰고, 진위는 App Store Server API 조회로 판단한다. 플랫폼별 검증은 따로 두고 재화 지급은 공통 함수 하나로 모았다. 대가 결제마다 애플 서버 왕복이 필요하고, 플랫폼별 검증 코드라는 유지보수 대상이 하나 늘었다. 결과 두 플랫폼이 같은…

hyeon_B•

[스타트업/기술] Node.js & Google Play 인앱결제 | 결제 시스템 아키텍처 설계 (Part 1)

문제 클라이언트가 "결제했다"고 알리면 그대로 재화를 주는 구조는 패킷 변조나 재전송 한 번으로 무너진다. 결정 클라이언트는 Purchase Token만 넘기고, 서버가 Google Play Developer API로 직접 검증한 뒤 Firestore 트랜잭션 밖·안 이중 체크로 한 번만 지급한다. 대가 결제마다 스토어 API 왕복이 한 번 늘고, 대기(Pending) 결제와 환불은 이 설계 범위 밖에 남았다. …

hyeon_B•

[스타트업/기술] GitHub Actions CI 파이프라인 | 프로덕션 배포 전 런타임 에러를 차단하는 테스트 자동화

문제 2026년 3월 20일, main에 직접 푸시한 코드가 Cloud Run에 자동 배포된 뒤 채팅 요청이 500을 냈다. 원인은 Gemini 호출의 400 INVALID_ARGUMENT 였고 로컬에서는 한 번도 보지 못한 에러였다. 결정 외부 의존성을 mock으로 바꾼 pytest를 만들고, PR마다 포매터·린터·테스트·Docker 빌드를 돌리는 GitHub Actions CI를 붙였다. main에는 PR로, CI가 통과한 것만 들…

hyeon_B•

[스타트업/기술] FastAPI와 클라우드 네이티브 | Cloud Run 도입과 백엔드 전환기 (Part 2)

문제 트래픽이 없어 인스턴스가 0개일 때 첫 메시지를 보내면 컨테이너 기동과 Firestore 적재가 겹쳐, 응답까지 15.3초가 걸렸다(Cloud Run 요청 로그 1건). 결정 최소 인스턴스를 두지 않고, 기동할 때 스토리 데이터를 한 번에 메모리에 올리는 Startup Cache와, 유저가 프롤로그를 읽는 동안 앱이 /health 를 미리 부르는 Client-Side Warm-up으로 버티기로 했다. 대가 예열한 인스턴스가 실…

hyeon_B•

[스타트업/기술] Firebase Storage 이미지 로딩 최적화 | GCP Bucket 직접 호출을 통한 Latency 개선

Firebase Storage의 편리함 속에 숨겨진 Latency 개발 중인 프로덕트에서 이미지 로딩 속도가 눈에 띄게 느리다는 것을 발견했다. 사실 처음 원격 파일 저장소를 활용할 때도 "왜 이렇게 로딩 속도가 느릴까" 생각은 하고 있었지만 지금껏 미뤄오다 드디어 해결하고자 한다. (연구에 따르면 지연시간이 1초 증가할 때마다 이탈률이 무려 10% 증가 한다고...!) 네트워크 탭을 열어 프로파일링을 해보니, 이미지 한 장…

hyeon_B•

[Firebase] 왜 스타트업의 빠른 프로토타이핑에 'BaaS'가 필수일까?

창업가로서 서비스를 구상하고 MVP(Minimum Viable Product)를 기획하다 보면 항상 '리소스의 한계'라는 벽에 부딪힌다. 아이디어를 빠르게 시장에서 검증해야 하는 프로토타이핑 단계에서, 사용자가 마주할 프론트엔드에 더해 인증, 데이터베이스, API 서버, 파일 스토리지까지 갖춘 '제대로 된' 백엔드를 구축하는 것은 많은 시간과 인력을 요구한다. '이 아이디어가 정말 시장에서 통할까?'…

hyeon_B•
게시물 더보기
검색결과 없음