NotebookLM 추리 프롬프트를 62개 사건 색인과 10단계 플레이가 되는 한국어 게임으로 바꿔 보았다-요약에서 멈추지 않고, 출처·각색·검증 상태를 분리한 Expo/React Native prototype 제작기

📝 한줄 요약

NotebookLM에서 만든 추리게임 아이디어를 대화형 답변으로 끝내지 않고, 실제로 눌러서 조사할 수 있는 Expo/React Native 게임 prototype으로 옮겼다. 프롬프트는 게임 규칙의 기준으로, Sherlock canon database XLSX는 사건 콘텐츠의 기준으로 분리했다. 그 결과 62개 사건 색인, 1개 playable 사건, 10단계 조사 규칙, 한국어 화면, 웹 가독성 개선까지 실제 브라우저에서 확인했다.

바쁘시면 이것만 읽어도 됩니다:

• NotebookLM 프롬프트는 게임의 분위기와 규칙을 설명했지만, 그대로는 실행 가능한 앱이 아니었다.

• 사건 제목만 보고 62개 사건을 모두 창작하지 않고, 원본 XLSX를 canon metadata의 기준점으로 삼았다.

• 처음 보이던 목록을 62개 전체 색인으로 확장했다.

• 실제 플레이 가능한 사건은 현재 정체성 사건 1개이며, 나머지 61개는 검증 전 INDEXED 상태다.

• 조사 행동은 정확히 10단계를 소비하고, 사건 검토는 단계를 소비하지 않는다.

• 고정 UI와 플레이 콘텐츠를 한국어로 바꾸고, 웹에서는 주요 글꼴을 1.16배로 키웠다.

• TypeScript, Expo 웹 번들, Expo Doctor, 실제 브라우저 행동까지 확인했다.

• 아직 상용 출시 앱은 아니다. iOS/Android 네이티브 시뮬레이터, 저장소 영속화, 나머지 사건의 playable 전환은 다음 단계다.

🎯 이런 분들께 도움됩니다

• NotebookLM의 결과물을 실제 서비스나 앱으로 옮기고 싶은 분

• AI에게 게임 아이디어를 받은 뒤 어디부터 구조화해야 할지 막막한 분

• 원작·자료 기반 콘텐츠와 창작 요소를 구분해야 하는 분

• 바이브코딩으로 실행 가능한 prototype을 만들고 싶은 분

• “코드는 만들어졌다고 하는데 실제로 어디까지 된 것인지” 확인하고 싶은 분

• 여러 사건·문서·스프레드시트를 하나의 앱 콘텐츠 목록으로 연결하고 싶은 분

😫 문제 상황 — 좋은 프롬프트만으로는 게임이 실행되지 않았다

출발점은 NotebookLM에 넣은 The Sherlock Files 게임 프롬프트였다. 프롬프트에는 셜록 홈즈 분위기, 사건 선택, 단서 조사, 용의자 질문, 이론 검증, 범인 지목, 10단계 제한 같은 게임 아이디어가 들어 있었다.

문제는 프롬프트가 게임의 설계 의도는 설명해도, 앱이 실제로 따라야 할 상태와 데이터를 결정해 주지는 않는다는 점이었다.

화면에 사건 제목을 나열하는 것만으로는 부족했다.

• 어떤 행동이 조사 단계를 소비하는가?

• 사건 검토는 무료 행동인가?

• 단서를 몇 개 찾았을 때 범인을 지목할 수 있는가?

• 오답을 고르면 사건은 어떻게 끝나는가?

• 10번째 행동 뒤에도 계속 조사할 수 있는가?

• 원작에 없는 살인 설정을 원작의 사실처럼 보여 주지 않으려면 어떻게 해야 하는가?

• 사건 제목은 많지만, 실제로 검증된 용의자·단서·해답 데이터는 어디에 있는가?

처음 보이는 마인드맵에는 사건 목록이 있었지만, 목록만으로 62개 사건의 세부 내용을 임의로 채우면 원작과 창작 설정의 경계가 무너질 수 있었다.

ALT

셜록 홈즈 - 스크린샷

그림 1. NotebookLM에서 Sherlock Holmes 전집 & 게임 노트와 62개 출처를 확인한 출발점. 출처 수가 많다는 사실과 실제 playable 데이터가 준비됐다는 사실은 별개의 문제였다.

그래서 목표를 “셰어록 홈즈 게임을 한 번에 완성하기”로 잡지 않고, 먼저 다음 세 가지를 분리하는 것으로 바꾸었다.

1. 프롬프트 — 게임의 분위기와 플레이 규칙

2. canon database — 작품명, 원본 파일, 사건 요약, 핵심 단서, 게임 활용 역할

3. 앱 엔진 — 실제 화면과 상태 전환

🌱 처음에는 무엇을 몰랐나

처음에는 “AI에게 게임을 만들어 달라고 하면 게임이 나오는 것”과 “게임을 운영할 수 있는 데이터 구조를 설계하는 것”이 거의 같은 일이라고 생각하기 쉽다.

하지만 실제로는 다르다.

화면이 예쁘게 나오는 것과 게임 규칙이 일관되게 작동하는 것도 다르다. 한 번은 화면에 사건 목록이 보이는데 실제로는 이전 번들이 남아 있어 10개 목록이 계속 보이는 문제가 있었다. 코드를 고쳤는데도 화면이 바뀌지 않으면, 코드가 틀린 것인지 개발 서버가 오래된 것인지 구분해야 한다.

또 하나의 오해는 “원작 제목을 알고 있으니 사건 내용을 채울 수 있다”는 생각이었다. 제목과 요약만으로 용의자·단서·해답을 모두 만들면, 그것은 canon 데이터베이스가 아니라 창작 데이터베이스가 된다.

이번 작업에서 배운 기준은 간단했다.

AI에게 맡기는 범위가 넓어질수록, 무엇이 사실이고 무엇이 각색인지 표시하는 구조가 먼저 필요하다.

🛠️ 사용한 도구

• NotebookLM 프롬프트: 게임 분위기와 플레이 규칙의 출발점

• Hermes Agent / TARDIS: 요구사항 분해, 파일 생성, 검증, 실행 흐름 조율

• Expo / React Native / TypeScript: 크로스플랫폼 앱 prototype

• Sherlock canon database XLSX: 62개 작품의 콘텐츠 기준 원천

• 브라우저 실행 검증: 실제 사건 목록·조사 행동·단계 변화 확인

• TypeScript·Expo Doctor·Expo export: 정적·번들·프로젝트 설정 검증

🔧 작업 과정

1. 프롬프트를 “화면 설명”이 아니라 상태 전이로 바꾸기

처음에는 게임 프롬프트를 그대로 앱 화면으로 옮기려 했다. 그러나 화면부터 만들면 규칙이 버튼 뒤에 숨는다.

먼저 게임의 흐름을 다음처럼 고정했다.

DEFAULT
  → 사건 선택
  → GAME / 조사 화면
      → 사건 검토: 무료 검토
      → 용의자 심문 / 증거 조사 / 이론 검증 / 범인 지목: 1단계 소비
      → 사건 해결 또는 사건 실패

그 다음 엔진이 다음을 책임지도록 했다.

• 현재 조사 단계

• 발견한 단서

• 질문한 용의자

• 마지막 조사 기록

• 정답·오답 결과

• 10번째 행동 이후 자동 실패

핵심은 UI가 “3/10단계”라고 말해서 3단계가 되는 것이 아니라, 엔진의 상태가 3이기 때문에 UI가 그렇게 보이도록 만든 것이다.

이렇게 분리해 두면 나중에 화면 디자인을 바꾸거나 모바일과 웹의 표현을 달리해도 게임 규칙은 흔들리지 않는다.

2. 첫 사건은 원작과 각색을 구분해 playable로 만들기

첫 playable 사건으로 정체성 사건(A Case of Identity)을 선택했다. 이 작품은 정체성과 위장이라는 게임 소재는 풍부하지만, 원작 자체가 정본 살인 미스터리는 아니다.

그래서 앱에 살인 사건을 추가하되, 원작의 사실인 것처럼 표현하지 않았다.

이거 참조해

이 요청을 받은 뒤 canon record와 playable adaptation을 분리했다.

• 원작 연결: 정체성 사건(A Case of Identity)

• 앱의 사건: 원작에서 영감을 받은 창작 살인 미스터리

• 화면 표시: 원작 기반 각색

• 출처 표시: Canon DB #3과 원본 파일명

• 편집 주석: 원작 자체는 canonical murder가 아니라는 점을 명시

playable 사건에는 4명의 용의자와 5개의 단서를 넣었다.

• James Windibank

• Hosmer Angel

• Mary Sutherland

• Elias Finch

• 타자기 서명

• 변장용 안경과 수염

• 상속 동기

• 허술한 사무실 알리바이

• 역추적을 방해하는 문구점 단서라는 red herring

이 구조는 “원작을 그대로 재현했다”가 아니라 “원작의 인물·정체성 모티프를 기반으로 게임 규칙에 맞는 각색을 했다”는 사실을 코드와 화면 양쪽에서 보존한다.

3. 제목 목록을 임의의 사건 데이터로 착각하지 않기

초기 화면에는 10개 정도의 사건 제목이 보였다. 하지만 제목만 보고 각 사건을 모두 playable로 채우는 것은 빠른 것처럼 보여도 위험했다.

이후 전달받은 XLSX에는 Sherlock Canon 시트에 62개 작품이 정리되어 있었다. 각 행에는 다음 정보가 있었다.

• 작품 번호와 제목

• 작가

• 작품 유형

• 원본 파일명

• 사건·등장인물·핵심 단서 요약

• 공개 이용 여부

• 게임 활용 역할

이때부터 사건을 두 가지 상태로 나눴다.

그 결과 10개 임시 목록은 62개 canon 색인으로 확장되었고, 동시에 61개 사건을 억지로 완성한 척하지 않을 수 있었다.

XLSX 원본도 앱 프로젝트 안에 보존했다. 다음에 원본이 갱신되면 사람이 62개 행을 다시 옮겨 적는 대신, 같은 변환 절차로 manifest를 재생성할 수 있다.

ALT

셜록 클론 데이터베이스

그림 2. XLSX 원본에서 변환한 canon manifest의 일부. 작품명·원본 파일명·검증 상태를 분리하고, 실제 playable로 승격된 03번 사건만 PLAYABLE로 표시했다.

4. “실제로 실행되는가?”를 확인하기

앱을 만든 뒤 가장 중요한 요청은 다음이었다.

그럼 앱으로는 어떻게 실행해

이 질문은 기능 구현과 실행 안내를 분리하게 해 주었다. 앱이 만들어졌다고 말하는 것과 사용자가 직접 열 수 있는 것은 다르기 때문이다.

브라우저에서 실제로 확인한 결과는 다음과 같았다.

• 사건 목록: 62개 색인 완료

• playable record: 캐논 DB #3 · 원본 파일명: 1891 _ A Case of Identity.md

• 조사 시작: 0/10단계

• 메리 서덜랜드 심문 후: 1/10단계

• 발견 단서: 1개

• canon 기반 타자기 단서: e/r 마모와 손목 압박 자국

이 검증으로 “화면이 뜬다”에서 끝나지 않고, 실제 버튼을 눌렀을 때 상태가 변한다는 것까지 확인했다.

전환점 — 코드가 아니라 기준점을 먼저 만든다

이번 작업의 전환점은 62개 사건을 모두 playable로 만들지 않은 것이다.

처음에는 많은 사건을 넣는 것이 완성도처럼 보였다. 하지만 실제로는 다음 구분이 더 중요했다.

• 자료에 실제로 있는 것

• 게임 규칙상 추가한 것

• 아직 검증하지 않은 것

• 지금 당장 플레이할 수 있는 것

이 네 가지를 구분하자 앱은 작아졌지만 신뢰도는 높아졌다.

AI와 함께 만드는 작업에서 “더 많이 생성하기”보다 “어디까지 검증됐는지 표시하기”가 먼저라는 것을 배웠다.

5. 실패한 순간도 결과물의 일부로 기록하기

canon manifest를 연결한 뒤 브라우저에 계속 10개 색인만 보이는 문제가 있었다. 코드에는 62개가 생성되어 있었지만 실행 화면은 이전 목록을 보여 주었다.

원인은 코드가 아니라 8081 포트를 점유한 이전 Expo Node 프로세스였다. 오래된 개발 서버를 종료하고 캐시를 비운 뒤 다시 시작하자 화면에 62개 색인 완료가 나타났다.

Expo 설정에서도 한 번 오류가 있었다. SDK 57 설정 검사에서 지원되지 않는 splash 필드가 지적되었고, 필요하지 않은 설정을 제거한 뒤 Expo Doctor 검사를 다시 실행했다.

이 경험에서 얻은 실전 원칙은 다음과 같다.

화면이 바뀌지 않을 때는 코드를 다시 고치기 전에 번들·캐시·포트·실행 프로세스를 확인한다.

✅ 결과 — 작동하는 첫 번째 vertical slice

Before vs After

시간 절약 효과는 아직 측정하지 않았다. 이번 결과물은 상용 서비스가 아니라 실행 가능한 첫 vertical slice이기 때문이다. 대신 “완성된 것처럼 보이는 화면”과 “실제로 규칙이 움직이는 앱”을 구분할 수 있게 되었다.

검증된 결과물

• 62개 사건 색인 화면

• 정체성 사건(A Case of Identity) playable 화면

• 4명의 용의자

• 5개의 단서와 1개의 red herring

• 질문·증거 조사·이론 검증·고발·사건 검토

• 10단계 조사 시계

• 정답 고발과 오답 고발

• 10번째 행동 자동 실패

• canon source label과 adaptation note

그림 3. 실제 브라우저에서 확인한 정체성 사건 플레이 화면. 캐논 DB #3, 0/10단계, 발견 단서와 4명의 용의자가 한 화면에서 연결된다.

검증 기록

• npx tsc --noEmit: 통과

• npx expo export --platform web: 통과

• npx expo-doctor: 20/20 checks passed

• git diff --check: 통과

• 브라우저에서 홈 화면·정체성 사건·용의자 심문·사건 검토를 직접 확인

• 브라우저 콘솔 오류: 0건

아직 하지 않은 것

• 나머지 61개 사건의 playable 전환

• iOS Simulator와 Android Emulator의 직접 실행

• AsyncStorage/SQLite 기반 진행 상태 영속화

• 음성·일러스트·스토어 배포

• NotebookLM 원문 파일 전체의 locator 대조

이 항목들을 완료했다고 쓰지 않은 것도 이번 사례의 중요한 결과다. 검증하지 않은 범위를 TODO로 남겨야 다음 작업의 출발점이 분명해진다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 프롬프트를 세 가지로 분리하기

   • 규칙: 무엇이 게임 행동인가

   • 콘텐츠: 무엇이 원작·자료에서 왔는가

   • 실행: 앱 상태가 어떻게 움직이는가

2. 자료의 출처를 화면에 노출하기
   출처를 내부 파일에만 숨기지 않고 사건 화면에 표시하면, 사용자가 지금 보고 있는 것이 원작인지 각색인지 바로 판단할 수 있다.

3. indexed와 playable을 분리하기
   자료 목록에 들어왔다는 사실과 실제 플레이할 수 있다는 사실은 다르다. 상태를 분리하면 콘텐츠를 늘리면서도 검증 기준을 낮추지 않을 수 있다.

4. 버튼 하나를 눌러 상태가 바뀌는지 확인하기
   정적 검사만으로는 게임 경험을 확인할 수 없다. 실제 화면에서 시작·조사·검토·고발을 순서대로 눌러야 한다.

이렇게 하면 안 돼요

1. 사건 제목만 보고 용의자와 해답을 전부 창작한 뒤 원작 사실처럼 표시하지 않기

2. 웹 export가 성공했다고 iOS·Android 네이티브 실행까지 완료했다고 쓰지 않기

3. 개발 서버가 오래된 화면을 보여 주는데 코드를 무작정 다시 고치지 않기

4. 데이터가 많아 보이게 하려고 검증되지 않은 사건을 PLAY로 표시하지 않기

5. NotebookLM이 모든 원문 사실을 보장한다고 가정하지 않기

🌍 다른 업무에 적용한다면?

이 구조는 추리게임에만 쓰이지 않는다.

예를 들어 법률강의나 사내 규정 교육 앱을 만든다고 하자.

• 강의 원문·법령·규정은 canon database 역할을 한다.

• 학습 목표와 퀴즈 규칙은 prompt/spec 역할을 한다.

• 학습자의 선택·힌트·오답·완료 상태는 deterministic engine이 관리한다.

• 원문 근거가 있는 문제와 교육용 각색 문제를 화면에서 구분한다.

• 검증되지 않은 문제는 INDEXED, 검수 완료 문제만 PLAY로 승격한다.

이렇게 하면 AI가 생성한 교육 콘텐츠를 그대로 배포하는 대신, 출처와 검수 상태를 포함한 단계적 학습 앱으로 발전시킬 수 있다.

🤝 배워서 남 주기

이번 결과물의 가장 재사용 가능한 부분은 셜록 홈즈 사건 자체보다 다음 작업 방식이다.

1. 원본 자료를 프로젝트 안에 보존한다.

2. 원본을 앱이 읽을 수 있는 manifest로 변환한다.

3. 모든 항목에 출처와 상태를 붙인다.

4. playable 콘텐츠에는 별도의 품질 기준을 적용한다.

5. 실행 화면에서 실제 상태 전이를 검증한다.

6. 미완성 범위를 숨기지 않고 다음 작업 목록으로 남긴다.

이 구조를 템플릿으로 남기면 다른 사람도 자기 분야의 자료를 가져와 “자료 기반 인터랙티브 앱”으로 확장할 수 있다. AI에게 완성품을 요구하는 대신, 자료·규칙·검증 상태를 함께 설계하는 방법을 공유하는 것이다.

🕊️ 홍익인간 관점

이 사례가 줄이는 것은 단순한 코딩 시간만이 아니다.

• 원작을 잘못 인용할 위험을 줄인다.

• AI가 만든 결과물을 어디까지 믿어야 하는지 판단하기 쉽게 한다.

• 비개발자도 “실행됨”과 “검증됨”을 구분할 수 있게 한다.

• 사건·교육·법률·업무 매뉴얼을 인터랙티브 콘텐츠로 만들 때 출처를 잃지 않게 한다.

• 처음부터 모든 것을 완성해야 한다는 부담 대신, 검증된 작은 단위부터 확장하게 한다.

결과적으로 한 사람이 만든 prototype이 다른 사람에게는 자료 기반 앱을 설계하는 작은 기준표가 될 수 있다.

🇰🇷 한국어 사용자를 위한 현지화

첫 실행 화면을 확인한 뒤, 한국인 사용자가 바로 사용할 수 있도록 고정 영어 문구를 전면 정리했다.

• 홈 화면·게임 모드·사건 파일·버튼·상태바를 한국어로 변경

• 62개 사건 제목에 한국어 표시명을 연결

• 용의자·단서·내레이션·이론 검증·성공/실패 문장을 한국어로 변경

• 이론 입력 접근성 레이블과 영문 placeholder도 한국어로 변경

• REVIEW CASE를 사건 검토, FREE ACTION을 무료 행동으로 변경

• 원본 파일명과 작품 원제는 출처 추적을 위해 provenance 영역에만 보존

• 한국어 이름인 윈디뱅크, 제임스, 핀치, 문구점을 이론 입력에서도 인식하도록 보정

실제 브라우저에서 홈 화면, 정체성 사건, 용의자 심문, 사건 검토를 확인했고 고정 UI 영어 탐지 결과는 false였다. 즉, 단순히 번역 파일을 만든 것이 아니라 사용자가 실제로 누르는 경로까지 한국어로 검증했다.

🖥️ 웹에서 읽기 쉽게 다듬기

한국어 문구를 바꾼 뒤 실제 브라우저에서 다시 확인하니, 긴 한국어 문장과 출처 정보가 상대적으로 작게 느껴졌다. 그래서 모바일 크기를 무작정 키우는 대신 웹에서만 글자 배율을 조정했다.

• 웹 전용 글꼴 배율: 1.16배

• 사건 제목·본문·상태바·단서·용의자·버튼·출처 문구에 같은 기준 적용

• 글자 크기와 줄 간격을 함께 조정해 카드 겹침과 잘림 방지

• 모바일은 기존 크기를 유지

브라우저에서 사건 제목이 약 20px로 계산되는 것을 확인했고, 정체성 사건 플레이 화면에서도 줄바꿈·카드 경계·버튼 겹침 이상이 없었다. 이 작업은 디자인 취향이 아니라, 실제 사용자가 읽고 누를 수 있는지를 확인하는 QA 단계였다.

🚀 앞으로의 계획

1. XLSX의 61개 indexed 사건 중 우선순위가 높은 사건부터 원문 locator를 대조한다.

2. 사건별 4–6명 용의자, 3–5개 단서, 공정한 해답을 작성한다.

3. AsyncStorage 또는 SQLite로 조사 진행 상태를 저장한다.

4. iOS Simulator와 Android Emulator에서 네이티브 실행을 검증한다.

5. 원작·각색·교육용 창작 콘텐츠를 시각적으로 더 명확히 구분한다.

6. 검수 완료 사건만 playable catalogue로 승격한다.

📋 재사용 가능한 프롬프트

프롬프트 1: 자료 기반 사건 콘텐츠 만들기

다음 자료를 기준으로 [사건명]의 게임 콘텐츠 초안을 작성해 주세요.

반드시 다음을 구분하세요.

• 원문에 직접 근거가 있는 사실

• 자료에서 합리적으로 추론한 내용

• 게임 플레이를 위해 새로 만든 각색 요소

• 아직 자료에서 확인되지 않은 내용

결과는 용의자 4–6명, 단서 3–5개, red herring 1개 이하, 공정한 해답 1개 구조로 작성하세요. 각 항목에 근거가 된 원문 위치 또는 확인 필요를 붙이고, 확인되지 않은 내용은 playable로 표시하지 마세요.

[사건명], [원문 자료], [게임 규칙]을 실제 프로젝트에 맞게 바꿔 사용하세요.

프롬프트 2: 앱 상태 전이 검증하기

다음 인터랙티브 콘텐츠의 규칙을 실제 사용자 흐름 기준으로 검증해 주세요.

• 무료 행동과 단계 소비 행동을 구분할 것

• 모든 소비 행동이 정확히 1단계만 증가하는지 확인할 것

• 정답·오답·10번째 행동의 종료 상태를 확인할 것

• 종료 뒤 추가 행동이 가능한지 확인할 것

• 새로고침·재시작·중단 후 상태가 어떻게 되는지 확인할 것

• 각 검증 항목에 PASS, FAIL, NOT RUN을 표시할 것

검증하지 않은 환경을 완료된 것처럼 쓰지 말고, 실제로 실행한 화면·로그·테스트 결과를 근거로 보고하세요.