[42 글로벌프로그램] 다시 미국에 오다 - (1편)
2024년 6월 19일(UTC-4), 첫 미국에 왔던 순간. 그로부터 약 2년 후 2026년 6월 22일(UTC-7), 다시 미국으로 왔다. 이 글에서부터 총 3번에 걸쳐 그 동안의 서사에 대해 기록해 보고자 한다. 2번째, 2달 간의 미국 생활!
PNG를 WebP로 바꿔 이미지 로딩을 최적화 했던 게 '읽기'의 비용을 줄이는 일이었다면, 이번엔 '쓰기'의 비용을 줄이는 이야기다. 백만 명에게 알림 하나를 보낼 때, 그 알림함을 누가 — 서버가? 클라이언트가? — 만드느냐에 따라 청구서의 자릿수가 달라진다. 지난 몇 주간 슬루스의 메시징 서버에 인앱 알림함(Inbox) 기능을 설계했다. 별것 아닌 기능처럼 보이지만, 막상 들어가 보니 분산 시스템 설…
지난번 Firebase Storage의 오버헤드를 줄이기 위해 GCP Bucket 직접 호출로 전환 하며 Latency를 한 차례 개선한 적이 있다. 당시 네트워크 홉(Hop)을 줄임으로써 유의미한 성능 향상을 이뤄냈지만, 프로덕트를 직접 사용해 보며 여전히 아쉬움이 남았다. 이미지 하나를 불러오는 데 여전히 1초 남짓한 시간이 걸리고 있었기 때문 이다. 지난번 1차례 개선 결과 페이지 이동과 동시에 매끄럽게 이미지가 렌더링되는 다른 서비…
서비스를 고도화하는 작업을 진행하면 할수록 초기에 잘 동작하는 것처럼 보였던 설계가 발목을 잡는 순간이 온다. 최근 우리 서비스의 결제 및 가격 구조를 개편하면서 이 사실을 다시 한번 뼈저리게 느꼈다. 기존에는 각 콘텐츠마다 가격을 개별적으로 설정할 수 있도록 설계되어 있었다. 하지만 본격적으로 서비스 출시를 앞두고, 프로모션을 기획해야 하는 시점이 오자 이 구조는 기술 부채로 다가왔다. 오늘은 파편화된 데이터 구조의 한계를 SSoT(Sing…
지난 시간 을 통해 만든 서버에서 구글 플레이(Google Play) 인앱 결제 영수증 검증을 위해 백엔드 서버에서 API를 호출하는 과정 중 참 황당한 에러를 마주했다. 서버 로그에 남은 에러 메시지는 다음과 같았다. error_code: "internal" error_message: "The current user has insufficient permissions to perform the requested o…
지난 글 에서는 안드로이드 생태계에서 구글 플레이 API를 활용하여 서버 검증 아키텍처를 어떻게 구축하는지 다루었다. 클라이언트의 상태를 신뢰하지 않고 서버가 주도권을 쥐어야 한다는 원칙은 iOS 환경인 앱스토어(App Store) 결제에서도 동일하게 적용된다. 하지만 Flutter를 통해 크로스 플랫폼 앱을 개발하면서, 구글과 애플이 Proof of Purchase을 다루는 방식에 꽤 큰 아키텍처적 차이가 있음을 알게 되었다. 애플은 WWD…
Our website uses cookies to improve your experience. Learn more
확인