[스타트업/기술] Sleuth 프로토타입에서 프로덕션까지 | 전체 포스팅 모음

byhyeon_B • • 2 min read
0

Sleuth는 플레이어가 AI 용의자와 직접 대화하며 단서를 모으고 범인을 지목하는 모바일 추리 게임이다. 6명이 함께 만들고 운영하며, 나는 공동창업자로서 백엔드와 LLM 인프라, 결제, 콘텐츠 제작 도구를 주로 맡았다.

이 글은 Sleuth를 만들며 쓴 기술 글 17편을 한 곳에 모은 목차다. 1절에는 구성도로 전체 모양을 보고, 2절에 개발 과정에서 주로 고민했던 대표 작업 세 가지를 기록해두었다. 3절은 17편 전부를 팀과 서비스가 기술적으로 변화했던 순서대로 네 단계로 나눠 정리했다. 단계가 바뀔 때마다 풀어야 할 질문도 바뀌었다. 처음에는 "초기 검증을 위해 어떻게 빨리 만들까"였고, 마지막에는 "AI가 한 일을 사람과 시스템이 어떻게 검증할까"였다.


1. Sleuth 운영 개요

Sleuth를 쓰는 사람은 셋이다. 게임을 하는 플레이어, 푸시와 공지를 보내는 운영자(마케터와 PM), 사건 시나리오를 만드는 제작자다. 서비스의 구성도 이 세 사람을 기준으로 나뉜다.

Sleuth 구성도

Sleuth의 구성. 실선은 플레이어와 운영자의 요청이 지나는 길이고, 점선은 콘텐츠를 미리 만들어 올리는 제작 경로다. 동그라미 숫자는 3절의 단계 번호다.

플레이어의 앱(Flutter)이 호출하는 서버는 둘이다. 대화 서버는 FastAPI로 만들어 Cloud Run에서 돌리고, 용의자의 답변과, 게임이 끝나고 추리를 검증하는 수사보고서 채점을 담당한다. 결제 서버는 Node.js(Express)로 만들었고, Google Play와 App Store의 영수증을 스토어에 직접 확인한 뒤 게임 재화를 지급한다. 운영 백오피스(Express, React)는 운영자가 개발자를 거치지 않고 푸시와 알림함 메시지, 공지를 보내는 도구다. 데이터는 Firestore와 Cloud Storage에 둔다.

사건 시나리오는 플레이어의 요청과 상관없이 미리 만들어 둔다. Claude Code 기반 제작 파이프라인이 초안을 만들고, 데스크톱 제작 도구가 검증과 이미지 작업을 거쳐 데이터를 올린다. 대화 서버는 올라온 사건 데이터를 읽기만 하도록 각각의 역할을 구분해두었다.



2. 대표 작업 세 가지

아래는 17편 중 설계 판단이 가장 많이 담긴 작업 세 가지다. 각 작업을 문제, 결정, 결과 순서로 정리하고 관련 글을 읽는 순서대로 붙였다. 각 글 끝에는 측정 조건과 남은 한계, 다시 검토할 조건을 따로 적어 두었다.

① LLM 대화 서버: 앱이 부르던 LLM을 서버로

문제. 프로토타입에서는 앱에서 LLM API를 직접 불렀다. API 키와 프롬프트가 앱 안에 있었고, 호출 비용도 서버에서 통제할 수 없었다.

결정. LLM 호출을 FastAPI 서버로 옮겨 키 관리와 프롬프트 조립을 서버가 맡게 했다. 서버는 쓰지 않을 때 인스턴스가 0개까지 줄어드는 Cloud Run에 올려 고정비를 없앴고, 그 대가인 첫 요청 지연(콜드 스타트)은 시작 시 캐시 적재와 앱의 예열 요청으로 줄였다. 이후 AI 호출을 Vertex AI로 옮기면서 API 키 대신 서비스 계정 권한으로 인증하게 보안도 개선했다.

결과. 첫 메시지 응답이 예열 뒤 15.3초에서 4.7초가 됐다(각 1건 측정). Vertex AI로 옮긴 뒤 응답 지연의 중앙값은 약 1.96초였다.

② 콘텐츠 제작 파이프라인: AI 시대를 위한 새로운 콘텐츠 저작 도구

문제. 추리 시나리오를 한 편 늘리려면 매번 외부 제작사와 새로 계약해야 했고, 받은 원고도 게임이 읽는 데이터 형식으로 다시 가공해야 했다. 팀에는 전담 작가가 없었다.

결정. 용의자 한 명을 이루는 항목을 고정된 형식(스키마)으로 정하고, Claude Code 세션 하나가 설계, 작성, 검수 역할을 차례로 맡는 10단계 제작 파이프라인을 만들었다. 사람 없이 돌던 에이전트가 검수 없이 승인 단계를 스스로 통과 처리한 일을 겪은 뒤에는, 다음 단계로 넘어가도 되는지를 LLM이 아니라 디스크의 파일을 직접 검사하는 스크립트(게이트)가 판정하게 바꿨다.

결과. 구조적인 게이트 강제를 통해 원하는 포멧의 결과물을 얻을 수 있었고, 결과적으로 자체 스튜디오를 통해 개발자 없이도 1인 저작이 가능해졌다. 이 파이프라인으로 만들고 제작 도구에서 다듬은 작품 7건이 와디즈 펀딩 캠페인으로 공개도 됐다.

③ 인앱결제: 영수증 검증을 위한 서버 도입

문제. 앱이 보내는 "결제 완료" 신호만 믿으면 위조된 요청이나 같은 영수증의 중복 지급을 막을 수 없다.

결정. 결제 서버가 영수증을 스토어에 직접 확인하고, 지급 직전 트랜잭션 안에서 한 번 더 확인하게 설계했다. App Store는 검증 방식이 달라 별도 계층으로 나누고, 재화 지급 로직만 공통으로 묶었다. 출시 뒤에는 검증을 통과한 다음에 생기는 문제를 다뤘다. 계속 실패하는 영수증이 반복해서 들어오는 것을 끊고, 영수증이 그 계정의 것인지 대조하고, 로그에는 결제 정보 원문 대신 되돌릴 수 없는 키만 남겼다.

결과. 테스트 환경에서 같은 유저가 동시에 20건을 요청하는 상황을 60번 반복해, 60번 모두 재화가 정확히 한 번만 차감되는 것을 확인했다. 유저는 안전하게 재화를 지급받고, 우리도 안전하게 결제를 확인하는 구조를 만들었다.


3. 17편 전체: 서비스의 기술 변천사

17편을 네 단계로 묶었다. 단계 안에서는 발행 순서로 놓았고, 괄호는 발행 시기다. 각 줄에는 그 글에서 무엇을 정했고 어떤 결과가 나왔는지를 적었다.

① 빠르게 만들기: Firebase 하나로 검증하기

처음 목표는 게임이 재미있는지 빨리 확인하는 것이었다(25년 2월 경). 서버를 직접 짜는 대신 Firebase에 인증과 데이터, 저장소를 맡겼고, 원격으로 일하는 팀의 협업 방식도 비슷한 시기에 정했다.

② Firebase 밖으로: LLM 호출과 이미지를 서버가 맡기

본격적으로 출시를 준비하면서, 앱이 LLM을 직접 부르는 구조로는 키와 비용을 지킬 수 없다는 점이 걸리기 시작했다. LLM 호출부터 서버로 옮겼고, 서버가 생기자 이번에는 고정비, 첫 요청 지연, 외부 API 지연이 새 문제가 됐다. 이미지 로딩도 같은 시기에 Firebase 계층을 걷어내고 다시 설계했다. 앱을 처음 만들었을 때는 콘텐츠 이미지들도 전부 클라이언트에 포함했던 시기가 있었다.

③ 돈을 다루는 서버: 결제는 철저하게

결제는 틀리면 돈이 잘못 나가는 영역이라 출발점부터 달랐다. 앱의 신호를 믿지 않고 서버가 스토어에 직접 확인한다는 원칙을 세우고, 흩어져 있던 가격 데이터를 한곳으로 모은 뒤, 출시 후에는 검증을 통과한 다음에 생기는 실패까지 다뤘다.

④ 팀 생산성 높이기: 운영과 콘텐츠 제작

서비스가 어느정도 돌아가기 시작하자 다음 과제는 개발자와 외부 작가에게 묶여 있던 일을 줄이는 것이라고 생각했다. 공지와 알림은 운영자가 직접 보내게 했고, 시나리오는 외주 대신 LLM 파이프라인으로 만들었다. AI native를 지향하되, 사람의 승인과 스크립트의 게이트를 통과하도록 만들었다.

새 글을 발행하면 이 목록에 이어서 업데이트해보도록 하겠다.

4.94 / 169 rates
hyeon_B

안녕하세요! AI 기술을 이용해 더 나은 세상을 만들어 나가고 싶은 과기원생 Hyeon이라고 합니다. 저는 앞으로 인공지능 시대에는 지식을 '활용'하는 능력이 중요해질 것이라고 생각합니다. 대부분의 일들은 인공지능이 뛰어난 모습을 보이지만, 인공지능은 데이터로 부터 연관관계를 학습하기 때문에 지식들을 새로 통합해서 활용하는 능력이 부족합니다. 인공지능이 뉴턴 전에 만들어졌다면 사과가 떨어지는 이유에 대답하지 못했을 것이고, 아인슈타인 전에 만들어졌다면 중력이 어떻게 생기는지 설명하지 못했을 것입니다. 따라서 앞으로 우리는 '본질'을 탐구하고 그 본질로부터 다른 곳에 적용하며 인공지능을 현명하게 활용해야 할 것입니다. 함께 인공지능 시대를 준비합시다!

댓글 쓰기

다음 이전

POST ADS1

POST ADS 2