문제: 베타테스터가 스토어 프로모션 코드로 결제했는데 S코인을 받지 못했고, 영구히 실패하는 영수증은 앱을 켤 때마다 서버로 재전송됐다. 결정: 서버가 "다시 보내도 소용없다"는 신호( terminal )를 응답에 싣고 실패한 영수증을 거부 기록으로 남겨 재전송을 끊었다. 막힌 정당한 결제는 예외 규칙과 수동 적립으로 구제했다. 결과: 영구 실패 영수증을 재전송하면 그 다음부터 terminal 응답을 받고 앱이 더 보내…
문제 푸시 알림은 놓치면 끝이라 사용자별 알림함이 필요했다. 그런데 모든 발송을 서버가 알림함에 펼쳐 쓰면 쓰기 건수가 수신자 수만큼 늘고, 언어별 토픽처럼 서버가 수신자를 모르는 발송은 펼칠 수조차 없다. 결정 서버가 수신자를 uid로 풀 수 있는 발송(uid 지정, 세그먼트, 동의 기반 토픽)은 발송 시점에 서버가 알림함에 쓰고, 풀 수 없는 언어 토픽( lang-* )과 가입 환영 공지만 앱이 열릴 때 클라이언트가 채운다. 대가…
문제 GCS 직접 호출로 한 번 줄였는데도 이미지 한 장에 1.39s가 걸렸다. 원인은 파일 자체였다. 에셋이 전부 무손실 PNG였고, 측정한 이미지는 477KB였다. 결정 PNG를 품질 82의 WebP로 바꾸고, 변환과 GCS 업로드(캐시 헤더, URL 맵 포함)를 셸 스크립트 두 개로 묶었다. 대가 손실 압축이라 화질이 조금 깎이는데, 얼마나 깎였는지는 재지 않았다. WebP를 못 읽는 환경을 위한 폴백도 두지 않았다. 결과 …
서비스를 고도화하는 작업을 진행하면 할수록 초기에 잘 동작하는 것처럼 보였던 설계가 발목을 잡는 순간이 온다. 최근 우리 서비스의 결제 및 가격 구조를 개편하면서 이 사실을 다시 한번 느꼈다. 기존에는 콘텐츠마다 가격을 따로 정할 수 있게 설계돼 있었다. 그런데 출시를 앞두고 프로모션을 기획해야 하는 시점이 오자 이 구조가 기술 부채로 돌아왔다. 이 글에서는 흩어진 가격 데이터를 SSoT(Single Source of Truth, 단일 진실 …
문제 결제 서버가 Google Play Developer API로 영수증을 검증할 때 "insufficient permissions"로 계속 실패했다. 시도 서버의 서비스 계정을 Play Console 사용자로 추가했지만 그대로였다. 해결 기존 인앱 상품을 비활성화하고 새로 등록하자 검증이 통과했다. 지난 글 에서 만든 서버로 구글 플레이 인앱 결제 영수증 검증 API를 호출하다가 참 황당한 에러를 만났다. 서버 …
문제 안드로이드와 영수증 형식이 전혀 다른 iOS(StoreKit 2 JWS)를 같은 원칙, 같은 지급 로직 위에 올려야 했다. 결정 JWS는 로컬에서 풀어 값싼 사전 거절에만 쓰고, 진위는 App Store Server API 조회로 판단한다. 플랫폼별 검증은 따로 두고 재화 지급은 공통 함수 하나로 모았다. 대가 결제마다 애플 서버 왕복이 필요하고, 플랫폼별 검증 코드라는 유지보수 대상이 하나 늘었다. 결과 두 플랫폼이 같은…
문제 클라이언트가 "결제했다"고 알리면 그대로 재화를 주는 구조는 패킷 변조나 재전송 한 번으로 무너진다. 결정 클라이언트는 Purchase Token만 넘기고, 서버가 Google Play Developer API로 직접 검증한 뒤 Firestore 트랜잭션 밖·안 이중 체크로 한 번만 지급한다. 대가 결제마다 스토어 API 왕복이 한 번 늘고, 대기(Pending) 결제와 환불은 이 설계 범위 밖에 남았다. …
문제 2026년 3월 20일, main에 직접 푸시한 코드가 Cloud Run에 자동 배포된 뒤 채팅 요청이 500을 냈다. 원인은 Gemini 호출의 400 INVALID_ARGUMENT 였고 로컬에서는 한 번도 보지 못한 에러였다. 결정 외부 의존성을 mock으로 바꾼 pytest를 만들고, PR마다 포매터·린터·테스트·Docker 빌드를 돌리는 GitHub Actions CI를 붙였다. main에는 PR로, CI가 통과한 것만 들…
문제 출시 전 로컬에서 여러 유저의 동시 플레이를 흉내 내려고 1분 안에 요청을 10번가량 보내자, 평소 2~3초이던 응답이 27.5초까지 늘었다. 플레이어가 용의자에게 질문하고 27초를 기다리는 상황이다. 결정 LLM 호출 창구를 AI Studio(개발자, 실험용)에서 GCP Vertex AI(엔터프라이즈용)로 옮겼다. SDK는 그대로 두고 클라이언트 생성 부분만 바꿨으며, 인증은 API 키 대신 Cloud Run 서비스 계정의 IAM …
문제 트래픽이 없어 인스턴스가 0개일 때 첫 메시지를 보내면 컨테이너 기동과 Firestore 적재가 겹쳐, 응답까지 15.3초가 걸렸다(Cloud Run 요청 로그 1건). 결정 최소 인스턴스를 두지 않고, 서버 기동 시 스토리 데이터를 메모리에 적재하고, 프롤로그 진입 시 앱이 예열 요청( /health )을 보내도록 했다. 대가 예열한 인스턴스가 실제 채팅 요청을 받는다는 보장은 없다. 인스턴스마다 캐시를 따로 들고 있어서, …
Firebase Storage의 편리함 속에 숨겨진 Latency 개발 중인 프로덕트에서 이미지 로딩 속도가 눈에 띄게 느리다는 것을 발견했다. 사실 처음 원격 파일 저장소를 활용할 때도 "왜 이렇게 로딩 속도가 느릴까" 생각은 하고 있었지만 지금껏 미뤄오다 드디어 해결하고자 한다. (연구에 따르면 지연시간이 1초 증가할 때마다 이탈률이 무려 10% 증가 한다고...!) 네트워크 탭을 열어 프로파일링을 해보니, 이미지 한 장…
Our website uses cookies to improve your experience. Learn more
확인