status:: active

별무리 중간점검 발표 대본 v0.2

  • 발표 시간: 약 19분
  • 발표 구성: 본문 16장
  • 도입 흐름: 문제 정의 → 사용자 조사 → 별무리 소개 → 실제 이용 흐름
  • 작성 기준: 화면 문구를 그대로 읽지 않고, 주장과 근거를 설명한 뒤 다음 장으로 연결합니다.
  • 주의 사항: 화면 설계, 코드 구현, 자동 검증, 실기기 확인을 서로 다른 증거로 구분합니다.

1. 프로젝트 별무리

예상 시간: 20초

안녕하세요. 저희는 프로젝트 별무리를 개발하는 감히사람이에이전트를이기려해 팀입니다. 저는 발표를 맡게 된, 팀장 및 게임 개발 역할을 맡은 김민성입니다. 지금부터 저희 팀의 프로젝트 중간 진행 상황을 발표하겠습니다. 앱의 기능을 소개하기에 앞서, 저희가 어떤 문제에서 출발했는지 먼저 말씀드리겠습니다.

A. 목차

발표 목차입니다.

문제 정의

2-1. 문제 정의 - 지속적 동기 부여 문제 (설문조사)

예상 시간: 1분 10초

저희가 주목한 문제는 캐릭터기반 AI 서비스나 게임에서, 사용자와 캐릭터가 함께한 시간이 다음 경험으로 충분히 이어지지 않는다는 점입니다.

기존 인공지능 캐릭터 서비스에서는 대화를 오래 나누더라도 그 내용이 게임 속 관계나 공간의 변화로 남지 않는 경우가 많습니다. 반대로 일반적인 캐릭터 육성 게임에서는 성장과 꾸미기의 재미가 있지만, 반복되는 일일 과제가 숙제처럼 느껴져 게임을 그만두게 되기도 합니다. 실제로 저희 설문에서 육성 게임을 이용했던 응답자의 대부분이 육성 게임에서 재미있었던 요소로는 캐릭터의 성장과 외형 변화가 가장 많이 선택되었습니다. 반면 게임을 그만둔 이유로는 매일 해야 할 일이 숙제처럼 느껴졌다는 응답이 가장 많았습니다.

2-2. 기존 서비스 비교와 별무리의 차이

예상 시간: 1분

실제 서비스 기준으로 보면 Character.AI는 대화마다 최대 5개의 메시지를 고정하고, 별도 기억란에 최대 400자의 정보를 입력하는 기억 기능을 제공합니다. Replika도 대화에서 형성된 기억과 레벨, 재화, 아바타 및 방 꾸미기를 제공합니다. 즉 선행 서비스에도 기억이나 단순한 꾸미기 기능은 이미 있습니다. 따라서 저희는 단순히 기억 기능을 제공하는 것만으로는 차별점이 되기 어렵다고 판단했습니다.

-> 화살표 플로우

저희가 주목한 차이는 기억과 게임 상태가 서로 연결되는 방식입니다. 별무리에서는 대화에서 얻은 선호와 사건, 미니게임 결과가 관계와 보상, 방의 변화로 남습니다. 그리고 이렇게 달라진 게임 상태는 다시 다음 대화와 플레이에 반영됩니다. 결국 별무리에서는 한 번의 대화와 플레이가 그 자리에서 끝나지 않고, 다음 만남을 바꾸는 재료가 됩니다.

2-3. 문제 정의 - 민감 정보 처리 문제

예상 시간: 1분 20초

또 하나의 문제는 대화 데이터의 처리 방식입니다. Replika의 현행 개인정보 처리방침에는 사용자의 문자와 음성 메시지, 사진과 영상이 처리 대상에 포함되며, 대화 응답을 생성하기 위해 비식별화와 최소화 조치를 거친 대화 데이터가 외부 언어 모델 제공자에게 전송된다고 명시되어 있습니다. 그럼에도 불구하고 25년 4월, 이탈리아 개인정보 감독기관은 개인정보 처리의 법적 근거와 고지, 연령 확인의 문제를 이유로 Replika 운영사인 Luka에 500만 유로의 과징금을 부과한 적이 있습니다. 이렇게 친밀한 대화를 다루는 서비스에서 개인정보 문제는 가능성에 그치는 위험이 아니라 실제 제재와 신뢰 문제로 이어진 사례가 있습니다.

-> 화살표 플로우

따라서 별무리는 이 문제를 완전한 온디바이스 추론을 통해 해결하고자 합니다. google 오픈소스 모델 gemma4-e2b-it 소형 언어 모델의 추론과 기억 검색을 완전히 스마트폰 안에서 수행하고, 대화 원문과 장기 기억도 기기에 저장합니다.

게임 소개

3. 별무리 소개

예상 시간: 1분 10초

별무리는 캐릭터와 나눈 대화와 함께한 플레이가 관계와 기억, 방의 변화로 남는 모바일 육성 게임입니다.

사용자는 캐릭터와 대화하거나 미니게임을 플레이할 수 있고, 모은 가구로 방을 꾸미며 시간을 보낼 수도 있습니다. 이 과정에서 남은 취향과 사건, 게임 기록은 다음 대화와 캐릭터의 반응에 이어집니다.

(와이어 프레임 보여주기)

여기서 중요한 점은 한 번의 만남이 그 자리에서 끝나지 않는다는 것입니다. 대화에서 알게 된 취향과 함께 겪은 사건은 기억으로 남고, 게임에서 얻은 재화와 가구는 방의 변화로 이어집니다. 사용자가 다시 돌아오면 이전에 쌓인 기억과 게임 상태가 다음 대화와 캐릭터의 반응에 반영됩니다.

현재 화면에 보이는 이미지는 저희가 구현하고 있는 사용자 경험을 정리한 최신 화면 설계안입니다. 실제 구현과 검증 현황은 뒤에서 별도로 구분하여 말씀드리겠습니다.

5. 게임 순환 구조

예상 시간: 1분 10초

별무리의 개인화 순환은 사용자의 행동과 게임 플레이에서 시작합니다. 캐릭터와의 대화, 미니게임과 미션, 산책과 수면, 방 상호작용이 기록으로 남습니다.

이 중 오래 남길 가치가 있는 선호와 사건은 Preference와 Event 기억으로 선택해 저장합니다. 대화 원문과 장기 기억은 서버로 보내지 않고 사용자 기기 안에서 처리합니다.

다음 대화에서는 EmbeddingGemma가 현재 발화와 관련된 기억을 검색하고, 장면에 맞는 정보와 함께 Gemma의 응답에 반영합니다. 그 결과 캐릭터는 이전에 함께한 경험을 참고해 더 맞는 반응을 만들 수 있습니다.

저희는 이 개인화 경험이 몰입과 만족을 높이고, 다시 대화하거나 게임을 플레이하는 재참여로 이어지는 구조를 만들고자 합니다.

이 순환을 모바일 기기에서 구현하려면 크게 두 가지의 기술 문제를 해결해야 했습니다.

기술 소개

6. 기술 과제

예상 시간: 50초

이제 핵심 기술에 대해서 설명드릴 온디바이스AI개발을 담당한 김민석입니다.

첫 번째 문제는 긴 컨텍스트에서 성능 붕괴 현상을 보이는 gemma에게, 캐릭터와 사용자 간의 대화 기록을 그대로 사용하지 않으면서도 캐릭터 페르소나로서의 필요한 기억을 다시 찾게 만드는 것입니다.

두 번째 문제는 비결정론적이고 낮은 출력 정확도를 보이는 소형 언어 모델이 알람이나 일정과 같은 기기 기능을 잘못 실행하지 못하도록 막는 것입니다.

AI 개발자로서 이 두 가지 문제를 각각 로컬 기억, 결정론적 검증 하네스 나누어 개발하고 있습니다. 기술 구조를 설명하기 전에 각 영역을 담당하는 팀원을 먼저 소개하겠습니다.

7. 팀과 역할

예상 시간: 50초

김민성 팀원은 Unity 게임 클라이언트와 프론트엔드를 담당합니다. 전반적인 게임 상태와 화면, 사건과 미니게임, 가구와 방 꾸미기 흐름을 개발하고 있습니다.

저 김민석은 Swift와 온디바이스 인공지능 개발을 담당합니다. 모바일 추론엔진은 LiteRT-LM 과, Memory 엔진, Tool Calling 등의 SLM 네스를 개발하고 있습니다.

김해울 팀원은 Spring Boot 백엔드와 AWS 인프라를 담당합니다. 로그인과 세션, API와 데이터 모델링, S3 모델 다운로드 전달 경로를 개발하고 있습니다.

각자 기술 영역은 나누어 맡았지만, Unity와 Swift는 JSON과 C언어 기반의 Application Binary Interface 계약으로 연결하고, 클라이언트와 백엔드는 REST API 계약을 기준으로 통합하고 있습니다. 이제 이 세 영역이 실제 제품에서 어떻게 연결되는지 설명드리겠습니다.

8. 시스템 구조

예상 시간: 1분 20초

별무리의 게임 상태는 Unity 게임 엔진이 전적으로 관리합니다. 관계 수치와 재화, 가구 보유 상태, 미니게임 결과처럼 게임 규칙에 영향을 주는 값은 Unity의 코드만 변경할 수 있습니다.

네이티브 앱단인 ios Swift 영역에서 SLM 을 전적으로 관리합니다. Gemma를 이용한 캐릭터 대화, EmbeddingGemma를 이용한 메모리 서치, 그리고 알람과 캘린더 같은 네이티브 iOS 기능을 담당합니다. Unity와 Swift는 공유 JSON 스키마와 C ABI를 기준으로 데이터를 주고받습니다.

Spring Boot 백엔드는 Apple과 Google OAuth2.0 로그인, 앱 세션, 모델 파일 전달을 담당합니다. 모델 파일은 AWS S3에 비공개로 보관하고, 인증된 사용자가 단기 CloudFront 서명 주소를 발급받아 내려받도록 구성했습니다.

저희 서비스에서 대화 원문과 장기 기억 등의 민감 데이터는 절대로 백엔드로 보내지 않습니다. 해당 정보는 사용자 기기에 저장하며, 서버에는 로그인 세션과 모델 전달에 필요한 정보만 전송합니다.

9-1. 컨텍스트 붕괴 실험

예상 시간: 40초

저희는 모든 대화를 장기 기억으로 저장하지 않습니다.

선행 실험에서 gemma의 발표된 32K 컨텍스트 윈도우를 실질적으로 사용하는 것은 어려웠습니다. 14K 부근에서 정확도가 압도적으로 하락하는 붕괴 현상이 있었고, 이는 컨텍스트 윈도우를 최대한 효율적으로 관리하는 기술적 난이도를 요구했습니다. ![[Pasted image 20260821210550.png]]

9-2. 선택적 기억 저장과 검색

예상 시간: 1분 20초

Gemma가 대사를 생성하면서 사용자의 선호나 중요한 사건에 해당하는 저장 신호를 함께 만들면, Swift가 신호의 형식을 확인한 뒤 필요한 내용만 SQLite에 저장합니다. 사용자의 중요한 일상 사건인 Event, 사용자의 취향에 해당하는 Preference 태그만 스키마로 저장하게 됩니다. 신호가 없거나 형식이 잘못된 경우에는 저장하지 않으며, 같은 기억이 한 요청에서 두 번 기록되지 않도록 중복 저장도 차단하는 하네스를 구축해두었습니다.

새로운 대화가 시작되면 EmbeddingGemma가 현재 발화와 관련성이 높은 기억을 검색합니다. 검색 점수가 threshold 에 미치지 못하는 기억은 사용하지 않고, 선택된 기억만 현재 게임 상태와 함께 Gemma의 입력에 추가합니다.

이 방식은 긴 대화 전체를 매번 모델에 넣지 않고도, 사용자가 이전에 말한 취향이나 함께 겪은 사건을 다음 대화에 반영하기 위한 설계입니다.

10. 도구 호출을 통제하는 결정론적 하네스

예상 시간: 1분 10초

Gemma는 캐릭터의 대사를 생성하는 동시에, 알람이나 일정에 필요한 설정값의 후보를 만듭니다. 하지만 Gemma가 게임 상태를 바꾸거나 기기 기능을 직접 실행할 수는 없습니다.

사용자가 자연어로 기능을 요청하면 약 0.2MB 크기의 경량 MLP가 먼저 해당 문장에 실제 실행 의도가 있는지 판단합니다. 실행 요청으로 분류된 경우에만 EmbeddingGemma가 알람, 타이머, 캘린더와 같은 도 구 가운데 하나를 선택합니다. 이후 Gemma는 선택된 도구에 필요한 날짜와 시간, 제목의 후보만 생성합니다.

실제 실행 여부는 Swift로 구현한 결정론적 하네스가 판단합니다. 하네스는 Gemma가 생성한 JSON 형식과 날짜 범위를 검사하고, 사용자가 해당 기능을 해금하는 가구를 보유했는지 확인합니다. 운영체제 권 한이 필요한 경우에는 해당 기능을 처음 요청한 시점에만 권한을 요청하며, 마지막에는 사용자에게 실행 내용을 보여주고 확인을 받습니다.

사용자가 취소하거나 권한을 거부하면 아무 기능도 실행하지 않습니다. 모델이 잘못된 형식이나 범위를 출력하더라도 코드 검증을 통과하지 못하면 알람이나 일정은 변경되지 않습니다.

11. 도구 의도 분류 실험

예상 시간: 1분 10초

일반 대화를 도구 요청으로 잘못 판단하는 문제가 발생한다면 이는 심각한 UX경험을 초래할것입니다. 즉 저희는 false positive activation을 줄이는 것이 핵심이라고 판단했고, 정규식 기반 라우터, 임베딩 라우터와 젬마를 라우터로 쓰는 경우, 경량 MLP 구조를 비교했습니다. 현재 보유한 192건의 고정 평가 데이터에서 자체 파인튜닝한 MLP는 도구실행 의도 분류 전체 정확도 94.79퍼센트와 도구 요청 Recall 94.64퍼센트를 기록했습니다. 일반 대화 24건 가운데 1건을 도구 요청으로 잘못 분류하는 오활성률은 4.17퍼센트까지 줄이는데 성공했습니다.

정리하면 인공지능 모델은 실행 후보를 제안하고, 실제 상태 변경은 정해진 규칙과 사용자 확인을 통과한 하네스 코드만 수행합니다. 저희는 이 구조를 통해 작은 모델의 실수가 실제 기기 기능의 오작동으로 이어지지 않도록 했습니다.

이제 이러한 개별 기술이 현재 제품에 어디까지 적용되었는지 말씀드리겠습니다.

구현 현황

12. 구현과 검증 현황

예상 시간: 1분 20초

현재 상태는 화면 설계, 코드 구현, 자동 검증, 실기기 확인으로 나누어 관리하고 있습니다.

Unity에서는 관계와 재화, 가구 보유와 배치, 미니게임 기록, 추억과 저장 구조를 구현했습니다. 주요 상태 전이와 중복 보상, 저장 마이그레이션은 자동 ci로 확인하고 있습니다.

Swift에서는 온디바이스 대화, 기억 저장과 검색, 도구 분류와 설정값 검증 코드를 구현했습니다. 백엔드에서는 OAuth2 로그인과 세션 관리, 비공개 모델 전달 경로를 개발했습니다.

반면 최신 홈과 대화, 기억, 방 꾸미기 화면은 설계가 정리되었고 Unity 반영을 진행하고 있습니다. 현재 가장 큰 미완료 항목은 한 번의 설치로 모델을 준비하고, 대화와 플레이, 기억 저장과 재실행, 기기 기능 실행까지 이어지는 전체 통합 흐름입니다.

실제 iPhone에서 확인한 범위도 별도로 말씀드리겠습니다.

13. 실기기 확인

예상 시간: 1분 10초

2026년 8월 12일, iPhone 14 Pro에서 계정 연결, 캐릭터 선택, 첫 만남과 홈 화면이 표시되는 것을 확인했습니다.

특히 모델 준비 과정에서는 실패 상태도 확인했습니다. 따라서 성공 화면만 보여주는 대신, 모델 다운로드와 복구 과정까지 포함해 실제 사용자가 처음 앱을 설치하는 조건에서 다시 검증해야 합니다.

현재 확인한 구현 범위를 바탕으로 iOS 앱을 완성하고, 출시 이후에는 다음과 같은 방식으로 사용자를 확보하고 서비스를 운영할 계획입니다.

14. 출시 후 마케팅 및 서비스 전략

예상 시간: 50초

출시 초기에는 YouTube Shorts와 X를 중심으로 별무리를 알리겠습니다. YouTube Shorts에는 캐릭터별 대사와 미니게임 장면, 방 꾸미기 전후 모습, 이전 대화가 다음 만남에 반영되는 순간을 짧은 영상으로 제작해 게시하겠습니다. X에서는 캐릭터 설정과 일러스트, 개발 과정과 업데이트 내용을 꾸준히 공유하고, 투표와 댓글을 통해 사용자가 원하는 캐릭터 콘텐츠를 확인하겠습니다.

조회 수와 팔로워 수만 확인하지 않고, 스토어 방문 후 설치 비율과 온보딩 완료율, 다음 날과 일주일 뒤의 재방문율을 함께 살펴보겠습니다. 대화와 미니게임 이용, 상점 진입과 상품 선택도 확인해 어떤 콘텐츠가 실제 재방문과 구매로 이어지는지 판단하겠습니다.

출시 후에는 반응이 좋은 캐릭터의 코디와 가구, 짧은 사건 콘텐츠를 우선 확장하겠습니다. 앱 안의 의견 접수와 X의 반응을 함께 확인하고, 업데이트 방향과 일정을 꾸준히 공유하면서 사용자가 기다릴 수 있는 운영 흐름을 만들겠습니다.

15. 사업화와 연구

예상 시간: 1분

별무리는 캐릭터와의 관계 성장과 필수 스토리를 완전한 무료 기본 경험으로 제공합니다. 하지만 수익 모델은 캐릭터 코디 아이템과 가구, 공간 테마처럼 자신의 취향을 표현하는 꾸미기 상품을 중심으로 검토하고 있습니다. 먼저 iOS에서 재방문과 꾸미기 반응, 가격 수용도를 확인한 뒤 상품 구성을 조정하고 Android로 서비스를 확장할 계획입니다.

기술 개발 과정에서 만든 개인화 기억 저장과 검색, 모바일 SLM 추론 구조는 연구 결과로도 정리할 예정입니다. 제한된 기기 자원과 문맥 안에서 어떤 기억을 선택해야 대화의 일관성이 유지되는지 평가하고, 기억 검색 품질과 응답 품질, 실제 모바일 추론 성능을 측정해 논문 투고를 추진하겠습니다.

마지막으로 다음 점검에서 어떤 결과를 증명할 것인지 말씀드리겠습니다.

16. 다음 점검의 기준

예상 시간: 40초

다음 점검에서는 구현한 화면의 수보다 하나의 빌드에서 전체 사용자 경험이 반복되는지를 기준으로 진척을 설명하겠습니다.

첫째, 첫 실행부터 모델 준비와 대화, 플레이, 기억 저장과 재실행까지 같은 빌드에서 반복되어야 합니다. 둘째, 네이티브 기능은 올바른 요청만 실행하고 잘못된 요청과 사용자 취소를 안전하게 처리해야 합니다. 셋째, 실제 지원 후보 기기에서 응답 시간과 메모리, 발열과 배터리를 측정해야 합니다. 넷째, 출시 후 실제 운영과정에서 사용자의 리텐션과 캐릭터 기반의 꾸미기 반응을 기록해야 합니다.

아직 부족하지만, 남은 시간 동안 최선을 다해 노력하고 분발하여 이 네 가지의 수용 기준을 통과해 iOS 정식 출시로 이어 가겠습니다. 이상으로 별무리 프로젝트 발표를 마치겠습니다. 감사합니다.

발표 전 확인 사항

  • 11번 슬라이드의 고정 평가 데이터가 학습 데이터와 실제로 분리되어 있는지 확인합니다.
  • 13번 슬라이드의 실기기 확인 날짜, 기기 모델과 빌드 식별자를 증거 자료와 대조합니다.
  • 최신 화면 설계에는 화면 설계, 실제 기기 화면에는 실기기 확인을 표시합니다.
  • 기술 용어를 처음 말할 때에는 역할을 먼저 설명하고 용어를 뒤에 붙입니다.
  • 화면의 문장을 그대로 읽지 않고, 수치와 결과가 의미하는 바를 설명합니다.

근거 자료