지난 글 에서는 안드로이드 생태계에서 구글 플레이 API를 활용하여 서버 검증 아키텍처를 어떻게 구축하는지 다루었다. 클라이언트의 상태를 신뢰하지 않고 서버가 주도권을 쥐어야 한다는 원칙은 iOS 환경인 앱스토어(App Store) 결제에서도 동일하게 적용된다. 하지만 Flutter를 통해 크로스 플랫폼 앱을 개발하면서, 구글과 애플이 Proof of Purchase을 다루는 방식에 꽤 큰 아키텍처적 차이가 있음을 알게 되었다. 애플은 WWD…
이제 실제로 사용자에게 가치를 제공하고 그에 대한 정당한 대가를 받는 '결제 시스템'을 구축해야 할 시점이 왔다. 현재 개발 중인 서비스에 S-Coin이라는 재화 시스템을 도입하면서, 구글 플레이 스토어(Android)와 앱스토어(iOS)의 인앱결제(In-App Purchase) 프로세스를 연동하기로 했다. 이 글에서는 2편에 걸쳐 구성될 결제 시스템 구축기의 첫 번째로, 구글 플레이 스토어 인앱결제의 아키텍처와 검증 원리에 대…
서비스 출시 준비 중 발견한 치명적인 문제점 지난 시간 에 이어 sleuth의 백엔드 서버(FastAPI & Cloud Run) 로직을 프로덕션 환경을 위해 고도화하는 작업에 집중하고 있다. 평소처럼 로컬 환경에서 새로운 기능을 테스트해 보니 매끄럽게 잘 동작하기에, 큰 고민 없이 main 브랜치에 코드를 직접 푸시하고 배포를 진행했다. 팀에 개발을 담당하는 인력이 많이 없기도 하고, 백엔드 서버를 지금은 혼자 구축하고 있기에 편의를…
지난 글들에서는 Sleuth의 코어 로직을 클라이언트에서 분리하여 FastAPI로 백엔드를 구축하고, 이를 GCP Cloud Run이라는 서버리스 인프라에 안착시킨 과정을 정리했다. (Cloud Run의 Scale-to-Zero와 콜드 스타트 최적화에 대한 내용은 이전 포스팅 을 참고하길 바란다.) 내부 아키텍처가 갖추어졌으니, 이제 실제 운영 환경의 쏟아지는 트래픽을 견뎌낼 수 있는지 검증할 차례다. 하지만 테스트를 시작하자마자 코드가 아닌…
앞서 다룬 FastAPI 는 LLM serving을 최우선 목표로 삼은 서비스에서 파이썬의 AI 생태계를 완전히 활용할 수 있다는 점에서 최적의 기술이었다. 코드가 준비되었으니 다음은 '이 서버를 어디에 띄울 것인가'라는 물리적인 인프라 고민으로 넘어갈 차례다. 이 챕터에서는 FastAPI 기반의 Sleuth 백엔드가 어떻게 클라우드 네이티브의 이점을 활용할 수 있었는지 정리해보고자 한다. Cloud Run과 Scale-to-Z…
Firebase Storage의 편리함 속에 숨겨진 Latency 개발 중인 프로덕트에서 이미지 로딩 속도가 눈에 띄게 느리다는 것을 발견했다. 사실 처음 원격 파일 저장소를 활용할 때도 "왜 이렇게 로딩 속도가 느릴까" 생각은 하고 있었지만 지금껏 미뤄오다 드디어 해결하고자 한다. (연구에 따르면 지연시간이 1초 증가할 때마다 이탈률이 무려 10% 증가 한다고...!) 네트워크 탭을 열어 프로파일링을 해보니, 이미지 한 장…
Our website uses cookies to improve your experience. Learn more
확인