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

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

1. 별무리

예상 시간: 20초

안녕하세요. 별무리에서 온디바이스 인공지능 개발을 맡고 있는 김민석입니다. 지금부터 감히사람이에이전트를이기려해 팀의 프로젝트 중간 진행 상황을 발표하겠습니다.

앱의 기능을 소개하기에 앞서, 저희가 어떤 문제에서 출발했는지 먼저 말씀드리겠습니다.

2. 문제 정의

예상 시간: 1분

저희가 주목한 문제는 캐릭터와 함께한 시간이 다음 경험으로 충분히 이어지지 않는다는 점입니다.

기존 인공지능 캐릭터 서비스에서는 대화를 오래 나누더라도 그 내용이 게임 속 관계나 공간의 변화로 남지 않는 경우가 많습니다. 반대로 캐릭터 육성 게임에서는 성장과 꾸미기의 재미가 있지만, 반복되는 일일 과제가 숙제처럼 느껴져 게임을 그만두게 되기도 합니다.

기획 초기에는 외로움 해소와 먼저 다가오는 캐릭터를 중심으로 대상을 넓게 설정했습니다. 그러나 기획심의에서 외로움 고위험군과 일반적인 10대와 20대 사용자는 이용 목적과 접근 방식이 다르다는 의견을 받았습니다. 이에 따라 1차 사용자를 캐릭터 육성과 꾸미기, 서브컬처 콘텐츠를 좋아하는 10대와 20대로 구체화했습니다.

그리고 이들이 실제로 육성 게임에서 무엇을 좋아하고, 어떤 이유로 떠나는지 확인하기 위해 탐색 설문을 진행했습니다.

3. 사용자 조사

예상 시간: 1분

설문에는 모두 46명이 참여했고, 이 가운데 육성 게임을 이용해 본 응답자는 24명이었습니다.

육성 게임에서 재미있었던 요소로는 캐릭터의 성장과 외형 변화가 가장 많이 선택되었습니다. 반면 게임을 그만둔 이유로는 매일 해야 할 일이 숙제처럼 느껴졌다는 응답이 가장 많았습니다.

저희는 이 결과에서 사용자가 원하는 것이 단순한 반복 관리가 아니라, 자신이 좋아하는 캐릭터가 달라지고 함께한 경험이 남는 과정이라고 판단했습니다. 그래서 캐릭터가 성장하는 즐거움은 유지하되, 접속하지 않았다는 이유로 관계가 감소하거나 불이익을 받는 구조는 사용하지 않기로 했습니다.

이 문제 정의와 조사 결과를 바탕으로 만든 앱이 별무리입니다.

4. 별무리는 어떤 앱인가

예상 시간: 1분 10초

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

사용자가 앱에 들어오면 캐릭터가 오늘 함께할 일을 제안합니다. 사용자는 캐릭터와 대화하거나 미니게임을 플레이할 수 있고, 모은 가구로 방을 꾸미며 시간을 보낼 수도 있습니다.

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

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

이 경험을 게임의 반복 구조로 정리하면 다음과 같습니다.

5. 게임 순환

예상 시간: 1분 10초

별무리의 기본 순환은 캐릭터의 제안에서 시작합니다.

사용자는 캐릭터와 대화하거나 사건과 미니게임을 함께 경험합니다. 그 결과는 관계 수치와 기억, 재화와 방의 상태에 반영됩니다. 이렇게 쌓인 상태는 다음 접속에서 캐릭터의 대화와 새로운 제안에 다시 사용됩니다.

예를 들어 캐릭터와 리듬게임을 성공적으로 마치면 친밀도와 이해도, 재화가 증가하고 플레이 기록이 추억으로 남습니다. 반대로 게임에 실패하더라도 관계 수치는 감소하지 않습니다. 같은 보상이 반복해서 지급되지 않도록 지급 기록도 별도로 관리합니다.

따라서 별무리에서 대화와 게임은 서로 분리된 기능이 아닙니다. 사용자가 캐릭터와 함께한 행동이 게임 상태로 남고, 그 상태가 다음 대화에 영향을 주는 하나의 순환으로 연결됩니다.

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

6. 기술 과제

예상 시간: 50초

첫 번째 문제는 긴 대화 기록을 그대로 사용하지 않으면서도 캐릭터가 필요한 기억을 다시 찾게 만드는 것입니다.

두 번째 문제는 언어 모델이 알람이나 일정과 같은 기기 기능을 잘못 실행하지 못하도록 막는 것입니다.

세 번째 문제는 Unity에서 관리하는 게임 상태와 Swift에서 실행하는 온디바이스 인공지능을 하나의 iOS 앱 안에서 안정적으로 연결하는 것입니다.

저희는 이 세 가지 문제를 각각 로컬 기억, 결정론적 검증 하네스, 플랫폼 간 계약으로 나누어 개발하고 있습니다. 먼저 전체 시스템에서 각 영역이 어떤 책임을 맡는지 설명드리겠습니다.

7. 시스템 구조

예상 시간: 1분 20초

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

Swift 영역은 Gemma를 이용한 캐릭터 대화, EmbeddingGemma를 이용한 기억 검색, 그리고 알람과 캘린더 같은 iOS 기능을 담당합니다. Unity와 Swift는 공유 JSON 형식과 C ABI를 기준으로 데이터를 주고받습니다.

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

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

이 구조에서 캐릭터가 이전 경험을 기억하는 과정은 다음과 같습니다.

8. 로컬 기억

예상 시간: 1분 20초

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

Gemma가 대사를 생성하면서 사용자의 선호나 중요한 사건에 해당하는 저장 신호를 함께 만들면, Swift가 신호의 형식을 확인한 뒤 필요한 내용만 SQLite에 저장합니다. 신호가 없거나 형식이 잘못된 경우에는 저장하지 않으며, 같은 기억이 한 요청에서 두 번 기록되지 않도록 중복 저장도 차단합니다.

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

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

현재 기억을 저장하고 검색하는 코드는 iOS 제품 코드에 반영되어 있습니다. 다만 사건을 플레이한 뒤 기억이 저장되고, 앱을 다시 실행했을 때 다음 대화에 반영되는 전체 흐름은 실기기 통합 검증이 남아 있습니다.

기억뿐만 아니라 기기 기능을 실행할 때에도 언어 모델의 판단을 그대로 신뢰하지 않습니다.

9. 인공지능과 코드의 경계

예상 시간: 1분 30초

Gemma는 캐릭터의 대사와 기억 저장 후보, 그리고 알람이나 일정에 필요한 설정값 후보를 생성합니다. 그러나 Gemma가 게임 상태나 기기 기능을 직접 변경할 수는 없습니다.

사용자가 자연어로 알람이나 캘린더 기능을 요청하면, 먼저 라우터가 해당 문장이 실제 실행 요청인지 판단합니다. 실행 요청으로 분류된 경우에만 사용할 도구를 선택하고, Gemma가 날짜와 시간, 제목과 같은 설정값 후보를 만듭니다.

이후 Swift 코드가 JSON 형식과 날짜 범위, 지원하는 기능인지 여부를 확인합니다. 사용자가 해당 기능을 해금하는 가구를 보유했는지 확인하고, 운영체제 권한이 필요한 경우에는 실제 요청이 발생한 시점에 권한을 요청합니다. 마지막으로 사용자에게 실행 내용을 보여주고 확인을 받은 뒤에만 기기 기능을 실행합니다.

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

일반 대화를 실행 요청으로 잘못 판단하는 문제를 줄이기 위해 별도의 경량 분류기도 실험했습니다.

10. 도구 분류 실험

예상 시간: 1분 20초

일반 대화를 알람이나 일정 요청으로 잘못 분류하면 사용자의 신뢰가 크게 떨어질 수 있습니다. 따라서 저희는 정규식부터 시작해 임베딩 라우터와 경량 MLP를 차례로 비교했습니다.

현재 보유한 고정 평가 데이터는 모두 192건이며, 도구 호출 문장 168건과 일반 대화 24건으로 구성되어 있습니다.

최종적으로 유사 문장쌍을 이용해 학습한 MLP는 전체 분류 정확도 94.79퍼센트와 도구 요청 재현율 94.64퍼센트를 기록했습니다. 일반 대화 24건 가운데 1건을 도구 요청으로 잘못 분류했으며, 일반 대화 오분류율은 4.17퍼센트였습니다. MLP 가중치의 크기는 약 193KiB입니다.

이 결과는 현재 고정된 평가 데이터에서 확인한 수치이며, 실제 사용자 발화 전체에 대한 성능을 보장하지는 않습니다. 앞으로 다양한 말투와 모호한 요청을 포함한 외부 평가 데이터를 추가해 오분류를 계속 확인할 계획입니다.

이제 개별 기술이 아니라, 현재 제품 전체가 어디까지 구현되고 검증되었는지 말씀드리겠습니다.

11. 구현과 검증 현황

예상 시간: 1분 20초

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

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

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

반면 최신 홈과 대화, 기억, 방 꾸미기 화면은 설계가 정리되었고 Unity 반영을 진행하고 있습니다. 화면 설계가 끝났다는 사실을 실기기에서 전체 기능이 동작한다는 의미로 사용하지는 않습니다.

현재 가장 큰 미완료 항목은 한 번의 설치로 모델을 준비하고, 대화와 플레이, 기억 저장과 재실행, 기기 기능 실행까지 이어지는 전체 통합 흐름입니다.

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

12. 실기기 확인

예상 시간: 1분 10초

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

이 자료는 각 화면이 실제 기기에서 실행되었다는 증거입니다. 다만 화면 사이의 모든 상태 전이와 모델 다운로드, Gemma 로딩, 기억 저장과 재실행까지 하나의 흐름으로 성공했다는 증거는 아닙니다.

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

저희는 남은 통합 위험을 막연한 향후 계획으로 두지 않고, 하나의 시험 흐름과 통과 기준으로 관리하려고 합니다.

13. 통합 검증 계획

예상 시간: 1분 10초

통합 검증은 실제 배포 모델을 포함한 하나의 서명된 iOS 빌드를 기준으로 진행합니다.

먼저 앱을 처음 설치한 상태에서 Apple과 Google 로그인을 확인하고, 모델 파일의 전체 다운로드와 중단 후 이어받기, 이미 받은 파일의 재사용을 검증합니다. 이후 Gemma를 로드해 대화를 생성하고, 대화에서 선택된 기억이 저장되는지 확인합니다.

앱을 종료한 뒤 다시 실행했을 때 저장된 기억과 게임 상태가 복구되고, 이전 경험이 다음 대화에 반영되는지도 확인합니다. 네이티브 기능은 가구 해금, 운영체제 권한, 사용자 확인, 실행과 취소가 모두 올바르게 처리되는지 시험합니다.

각 단계에서는 첫 응답 시간과 최대 메모리 사용량, 발열과 배터리 소모를 함께 측정합니다. 실패한 단계는 로그와 화면 기록을 남기고, 다시 실행했을 때 같은 결과를 재현할 수 있도록 관리하겠습니다.

이 전체 흐름은 세 팀원이 맡은 영역을 연결해야 완성할 수 있습니다.

14. 팀과 역할

예상 시간: 50초

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

저는 Swift와 온디바이스 인공지능을 담당합니다. LiteRT-LM 추론, 기억 엔진, 도구 분류와 평가 하네스를 개발하고 있습니다.

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

각자 기술 영역은 나누어 맡았지만, Unity와 Swift는 JSON과 C ABI 계약으로 연결하고, 클라이언트와 백엔드는 OpenAPI 계약을 기준으로 통합하고 있습니다. 각 팀원은 자신이 맡은 기능뿐만 아니라 다음 영역과 연결되는 지점까지 함께 책임집니다.

15. 초기 반응

예상 시간: 50초

현재까지 베타 참여를 위한 연락처 제출은 24건이었고, 이 가운데 유효한 이메일은 22건이었습니다.

이 수치를 실제 사용자 유지율이나 구매 의향이 검증된 결과로 해석하지는 않습니다. 현재 단계에서는 제품에 관심을 보인 초기 사용자를 확보했다는 신호로 보고 있습니다.

앞으로 이 참여자를 대상으로 캐릭터 선호, 방 꾸미기 경험, 재방문 이유와 이탈 이유를 확인할 계획입니다. 초기 유입은 YouTube Shorts와 X를 중심으로 비교하고, 어떤 캐릭터와 플레이 장면이 실제 참여로 이어지는지 확인하겠습니다.

이 결과는 출시 콘텐츠와 수익 모델을 결정할 때 사용하겠습니다.

16. 사업화와 연구

예상 시간: 1분

별무리는 캐릭터와의 관계 성장과 필수 스토리를 기본 경험으로 제공합니다. 사용자가 관계를 유지하기 위해 결제하도록 만들지는 않습니다.

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

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

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

17. 다음 점검의 기준

예상 시간: 40초

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

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

이 네 가지 기준을 통과해 iOS 정식 출시로 이어 가겠습니다. 이상으로 별무리 프로젝트 발표를 마치겠습니다. 감사합니다.

발표 전 확인 사항

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