"장시간 구동되어도 환각을 최소화하여 스스로 행동목표를 설정하는 LLM 오케스트레이션 엔진"을 핵심 기술 자산으로 하는 래빗홀컴퍼니 주식회사. KAIST에서 출발한 8인 규모의 스타트업으로, 자체 엔진이 구동하는 첫 상용 타이틀 “타임라인 스타즈”를 2026년 11월 공개를 목표로 준비하고 있습니다. AI 캐릭터의 추론 부하가 시간대별로 크게 변동하는 워크로드를 AWS 도쿄 리전에서 운영하며, 클래스메소드코리아의 지원으로 초기 설정 부담 해소와 운영 가시성 확보를 이루었습니다. 김남해 인프라팀장의 이야기를 들었습니다.
 

 

 

자체 LLM 오케스트레이션 엔진으로 AI 캐릭터 게임을 구동

 

 

 

 

주요 특징은 다음과 같습니다.

 

 

 

 

일본 시장을 겨냥한 AWS 선택과 추론 워크로드의 과제

 

기반 인프라 환경으로 AWS를 선택한 데에는 네 가지 이유가 결정적이었습니다. 당사는 일본 시장을 가장 먼저 공략하는 게임 회사이므로 일본 리전이 필수였고, AWS 도쿄 리전이 이 조건을 가장 확실하게 충족했습니다. 또한 AI 캐릭터 서비스는 유저 접속 패턴에 따라 추론 부하가 급격히 변하기 때문에, 트래픽에 맞춰 즉시 확장/축소되는 오토스케일링 구조가 필요했습니다. 8인 규모의 팀이라 관리형 서비스를 최대한 활용해 개발 인력이 엔진과 콘텐츠에 집중할 수 있는 환경이 필요했던 점, 수행 중인 국가 R&D 과제에도 안정적인 서버 운영 환경이 요구되었던 점도 함께 작용했습니다.

 

 

 

주요 AWS 활용 서비스

 

・ Amazon EC2(+ Auto Scaling, ELB) : LLM 오케스트레이션 서버와 게임 백엔드의 주 구동 환경입니다. 추론 요청의 시간대별 편차가 크기 때문에 Auto Scaling으로 인스턴스를 자동 증감시키고 로드밸런서로 요청을 분산합니다.

 

・ Amazon S3(+ Amazon CloudFront) : 캐릭터 원화/라이브2D/음성 등 게임 에셋과 로그를 S3에 보관하고, CloudFront로 한국/일본 유저에게 동일한 로딩 경험을 제공합니다.

 

・ Amazon RDS / Amazon DynamoDB / Amazon ElastiCache : 정합성이 중요한 유저 계정/결제 이력은 관계형 DB에, 캐릭터의 기억/관계처럼 빈번히 변하는 상태 데이터는 NoSQL과 캐시 계층에 분리 저장합니다. "기억을 엔진 밖으로 분리한다"는 Stateless 아키텍처를 그대로 구현한 구조입니다.

 

・ Amazon CloudWatch(+ AWS CloudFormation) : 서버 지표와 로그를 수집/발행하고, 대시보드와 알람 구성을 코드형 인프라(IaC)로 관리해 리전을 추가하더라도 동일한 관측 체계를 재현합니다.

 

・  AWS Lambda(+ Amazon API Gateway) : 결제 검증처럼 간헐적으로 발생하는 작업을 서버리스로 처리하여, 상시 대기 인스턴스 비용을 제거했습니다.

 

 

도입 과정에서 당면한 과제는 크게 세 가지였습니다.

 

첫째는 AWS 초기 설정값이었습니다. 계정 보안, 권한 체계, 로그 보관, 비용 알림 같은 초기 설정을 어떻게 잡아야 할지가 첫 번째 고민이었습니다. 인프라 전담 인력이 없는 상황에서 초기값을 잘못 잡으면 이후 보안 사고나 예상하지 못한 과금으로 이어질 수 있었기 때문입니다.

 

둘째는 LLM 추론 비용과 지연의 동시 압박이었습니다. 일반적인 상태유지(Stateful)LLM 구조는 대화가 누적될수록 문맥 토큰이 늘어 연산량이 급증하고, 누적된 문맥이 오히려 중요한 규칙을 잊게 만드는 "문맥 오염"을 일으킵니다. 서비스가 커질수록 인프라 비용이 기하급수적으로 늘어나는 구조여서, 아키텍처 자체를 Stateless로 재설계하고 캐릭터의 기억을 외부 데이터베이스로 분리해야 했습니다.

 

셋째는 소규모 팀의 인프라 운영 역량이었습니다. 8인 규모에서 인프라 전담을 두기 어려워, 2026년 6월 DevOps 인력을 채용하고 관측 스택을 재구축하기 전까지는 장애 원인 파악에 시간이 오래 걸렸습니다.

 

 

클래스메소드코리아의 지원에 대하여

 

클래스메소드코리아를 처음 알게 된 것은 2025년 게임 전시회 "지스타(G-STAR)" 행사장에서였습니다. 당사가 다루는 워크로드는 일반적인 웹 서비스가 아니라 AI 추론이 실시간으로 얽힌 게임 백엔드이기 때문에, 인프라 파트너가 게임 도메인의 특수성 — 출시 직후 트래픽 급증, 인앱결제 무결성, 글로벌 리전 배치 — 을 이해하고 있는지가 중요한 판단 기준이었고, 게임 업계 행사에서 직접 만나 뵈었다는 점이 의미가 컸습니다.

 

 

최종적으로 결정한 이유는 게임/콘텐츠 도메인에 대한 이해를 전제로 기술 논의를 시작할 수 있었다는 점, 일본에 본사를 둔 클래스메소드 그룹으로부터 도쿄 리전 운영과 일본 현지 사정에 대한 조언을 한 창구에서 받을 수 있었다는 점, 멤버스의 초기 설정/유지보수 지원으로 인프라 전담 인력 없이도 AWS를 안정적으로 시작할 수 있었다는 점, 그리고 국내 법인과 계약해 국가 R&D 과제의 정산 절차를 맞출 수 있었다는 점입니다.

 

2025년 12월 AWS 계정을 클래스메소드 멤버스로 옮긴 뒤, 보안 설정과 관리자 권한 계정 발급, 로그 관리 같은 초기 설정과 유지보수를 지원받았습니다. 초기 세팅을 직접 고민하는 부담이 줄어 도입이 수월했고, 출시를 앞둔 인프라 용량/비용 자문과 분기별 비용 최적화 리포트도 소규모 팀의 운영 부담을 덜어 주었습니다.

 

운영 체계 측면에서는 2026년 상반기에 서버 관측 스택을 전면 재구축하여, 이상 징후를 사후가 아닌 발생 시점에 인지할 수 있게 되었습니다. 대시보드와 알람을 코드형 인프라로 관리하면서 환경을 다시 세우거나 리전을 추가할 때의 수작업 재설정도 사라졌고, 유저 데이터 백업/복구 전략을 함께 수립하여 서비스 오픈 전에 사고 대응 시나리오를 확보하였습니다. 일정 측면에서도 서버 아키텍처 문서화와 결제 모듈 마무리를 계획보다 두 달 앞당겨 6월에 조기 완료하였는데, 관리형 서비스 활용으로 인프라 구성 시간을 줄인 것이 직접적인 요인이었습니다.

 

 

 

서비스의 향후 비전 및 계획

 

당사는 "자체 엔진으로 게임을 만들고, 그 엔진으로 IP 협업을 넓힌다"는 방향으로 사업을 설계하고 있습니다. 먼저 "타임라인 스타즈"를 2026년 11월 한국에서 공개한 뒤 일본에도 출시하여, 두 시장에서 엔진의 상용 안정성과 유저 반응을 확인합니다. 이어서 같은 엔진으로 새로운 AI 캐릭터 게임을 만들어 라인업을 넓히고, IP를 가진 기업/창작자와 함께 AI 캐릭터 콘텐츠를 만드는 협업을 추진합니다. 또한 CES 2027 유레카파크 대전통합관 참가가 확정되어, 현지에서 "타임라인 스타즈"를 선보일 예정입니다.

 

 

AWS 인프라 측면에서는 출시 직후 트래픽 급증 구간에 대비해 부하 테스트를 진행하고, 그 결과에 맞춰 인스턴스 구성과 오토스케일링 정책을 다듬을 계획입니다. 실시간 TTS API와 캐릭터 이미지의 생성·배포를 담당하는 서버를 구성해 콘텐츠 파이프라인을 자동화하고, 고위험 대화 감지/차단 모듈을 인프라 레벨에 통합하는 작업도 준비하고 있습니다. 현재 도쿄 리전 구성을 기반으로 진출 시장에 맞춘 리전 추가를 검토하고 있으며, 타이틀이 늘어나면 같은 엔진 인프라를 타이틀별로 확장해 운영할 계획입니다. 이때 추론 가속을 위한 GPU 인스턴스 도입이 예상됩니다.

 

인프라를 파는 회사는 많지만, 우리가 무엇을 만들고 있는 지부터 이해하려는 파트너는 드뭅니다. 클래스메소드코리아와는 대화가 기술 사양이 아니라 서비스 이야기에서 시작될 수 있었고, 지원이 정해진 체계 안에서 움직인다는 점도 신뢰가 갔습니다. 분기별로 제공되는 최적화 리포트도 저희 서비스의 구조와 실제 사용 패턴에 맞추어 정리된 내용이어서, 인프라 전담 인력이 없던 시기에도 무엇을 점검해야 하는지 판단할 수 있었습니다. 저희처럼 인프라 전담 인력을 두기 어려운 소규모 팀이라면, 클라우드를 ‘구매’하기보다 '같이 설계할 상대'를 찾는 편이 결과적으로 빠릅니다. AI 추론처럼 트래픽 예측이 어려운 워크로드를 다루면서 해외 시장까지 보고 계신 스타트업이라면, 한 번 상담해 보시기를 권합니다