문제: 사람 없이 돌던 에이전트 루프가 중간 결과물을 건너뛰고, 검수 없이 체크포인트 승인을 스스로 기록 했다. 이를 막으려 만든 게이트도 체크포인트 A와 B에서는 검수 역할이 적어 낸 숫자를 그대로 믿었다. 결정: 체크포인트 승인은 게이트 스크립트가 기록 하게 했다. 시나리오 파일이 이미 만들어진 B와 C에서는 게이트가 스키마 검증기를 직접 돌려 승인 여부를 정한다. 결과: B 승인 시점에 스키마 결함이 있으면 승인이 거부된다. 전에는 …
이번 편에서는 42 글로벌프로그램의 피날레, Seattle Tech Week와 프로그램을 통해 느낀 점들을 돌아보고자 합니다. 혹시 프로그램에 참여하게 된 배경과 초반부가 궁금하시다면 이전 글들을 참고바랍니다. 기회를 발견하고 참여하기까지의 과정: [42 글로벌프로그램] 다시 미국에 오다 - (1편) 2년 만의 미국 생활과 프로그램 전반부: [42 글로벌프로그램] 다시 미국에 오다 - (2편) 플라이휠 그렇게 다섯 주가 지나고, 6주차엔…
문제: 추리 시나리오를 한 편 늘리려면 매번 외부 제작사와 새로 계약해야 했다. 팀에는 전담 작가도, 완성된 원고를 검수할 사람도 없었다. 결정: 용의자 한 명을 이루는 필드와 개수를 스키마로 고정하고, Claude 세션 하나가 설계 역할, 작성 역할, 검수 역할을 차례로 맡는 10단계 저작 파이프라인을 만들었다. 다음 단계로 넘어가도 되는지는 Python 스크립트(게이트)가 판정한다. 게이트는 산출물 존재와 승인 상태를 검사하고, 체크…
문제 푸시 알림은 놓치면 끝이라 사용자별 알림함이 필요했다. 그런데 모든 발송을 서버가 알림함에 펼쳐 쓰면 쓰기 건수가 수신자 수만큼 늘고, 언어별 토픽처럼 서버가 수신자를 모르는 발송은 펼칠 수조차 없다. 결정 서버가 수신자를 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를 호출하다가 참 황당한 에러를 만났다. 서버 …
문제 클라이언트가 "결제했다"고 알리면 그대로 재화를 주는 구조는 패킷 변조나 재전송 한 번으로 무너진다. 결정 클라이언트는 Purchase Token만 넘기고, 서버가 Google Play Developer API로 직접 검증한 뒤 Firestore 트랜잭션 밖·안 이중 체크로 한 번만 지급한다. 대가 결제마다 스토어 API 왕복이 한 번 늘고, 대기(Pending) 결제와 환불은 이 설계 범위 밖에 남았다. …
문제 출시 전 로컬에서 여러 유저의 동시 플레이를 흉내 내려고 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 )을 보내도록 했다. 대가 예열한 인스턴스가 실제 채팅 요청을 받는다는 보장은 없다. 인스턴스마다 캐시를 따로 들고 있어서, …
Our website uses cookies to improve your experience. Learn more
확인