1. 기본 정보
목적 작품과 Goal 계약의 안정 식별자 및 기본 설명을 정합니다. 작성 plot.id, 제목, 한 줄 요약, 예상 시간, contract.id를 서로 구별해 입력합니다. 좋은 예 plot.id = moon-archive, “달의 기록 보관소에서 사라진 서약서를 찾는다.” 금지·검증 발행 뒤 ID를 표시 이름처럼 바꾸거나 삭제한 ID를 다른 작품 뜻으로 재사용하지 말고, 제목·요약 누락 lint를 해결합니다.
창작 가이드
여운 Studio V3 · 작품 작성부터 검수·공개까지
처음이라면 작품 골격을 먼저 만들고, 참조와 인물 목소리를 점검한 뒤 실제 플레이테스트를 진행하세요. 저장과 lint 통과는 공개 승인이 아닙니다. 제출 전에는 창작자 권리·출품 정책도 함께 확인해야 합니다.
1. 권장 작업 순서
- 창작자 어드민에서 작품을 만들고 Studio 편집기로 이동합니다.
- 한 문장의 전제와 독자가 처음 행동하고 싶어지는 entry hook을 정합니다.
- 세계·인물·목표·사실·선택 가능 행동을 연결하고 저장합니다.
- 표지와 인물 초상화를 업로드하고 권리·출처와 대체 텍스트를 확인합니다.
- Lint 오류를 모두 해결한 뒤 sandbox에서 실제 런타임 플레이테스트를 합니다.
- 완성도 체크리스트와 번역을 검토하고 제출합니다. 반려되면 사유가 지정한 부분을 수정해 새 revision으로 재제출합니다.
2. 작품 골격
긴 설정집보다 독자가 실제로 겪을 수 있는 구조를 먼저 완성하세요.
- 전제와 entry hook: 누가, 어디에서, 지금 무엇을 해결해야 하는지 한 문장으로 씁니다. 첫 장면에는 독자가 바로 말하거나 행동할 이유가 있어야 합니다.
- 세계와 사실: 장소, 규칙, 알려진 사실과 비밀을 나눕니다. 비밀은 누가 어떤 사건으로 알 수 있는지까지 정합니다.
- 인물과 배역: 주연·조연의 욕구, 경계, 서로의 관계와 장면별 참여 여부를 정합니다. 모든 인물이 모든 사건을 보았다고 가정하지 마세요.
- Goal Graph: 시작 상태, 달성 조건, 실패·우회 경로, 주요 milestone을 연결합니다. 하나의 정답 문장만 강요하기보다 의미 있는 여러 접근을 허용합니다.
- 행동 가능성: 독자가 말하기, 조사하기, 이동하기, 제안하기처럼 실제로 시도할 수 있는 행동과 세계가 허용하지 않는 경계를 적습니다.
- 결말과 연속성: 결말 조건과 인물이 이후 관계를 선택할 때 참고할 관계 근거를 설계합니다. 플롯이나 Lore가 호감도·기억·capability·상호선택을 직접 부여하게 만들 수는 없습니다.
- 발견 정보: 제목, 장르, 태그, 소개, content notes, 연령등급을 실제 내용과 일치시켜 독자가 기대한 작품을 만나게 합니다.
3. Stable ID와 참조
이름은 독자에게 보이는 표시이고 ID는 작품 내부 연결을 지키는 주소입니다.
- 한 번 사용한 character·actor·goal·fact ID는 표시 이름을 바꾸거나 번역해도 바꾸지 않습니다. 삭제 후 같은 ID를 다른 뜻으로 재사용하지 마세요.
- 직접 입력보다 Studio의 검색 가능한 reference selector를 사용해 존재하는 대상을 연결합니다.
- 사실 참조는 stableNamespace:localId 형태를 사용합니다. 다른 설정집과 local ID가 같아도 namespace가 다르면 서로 다른 사실입니다.
- 존재하지 않는 참조, namespace 충돌, 순환 dependency는 발행을 막습니다. 모듈을 분리하거나 해제하기 전 영향 미리보기와 lint를 확인하세요.
- 공유 LoreModule은 정확한 revision을 수동으로 고정합니다. 원작자의 최신 revision이 기존 작품에 자동 반영되지 않으므로 diff를 확인한 뒤 명시적으로 업데이트합니다.
Studio 20개 섹션 필드 레퍼런스
아래 순서는 실제 일반 스토리 편집기의 탭 순서와 같습니다. 리딩룸 작품은 기본 정보·고객 참여·카탈로그·세계관·인물·관계 캐스팅만 표시됩니다.
2. 고객 참여 방식
목적 고객 자신, 고객 자신+접근 방식, 읽기·상담형 중 실행 계약을 고릅니다. 작성 일반 자유 참여는 self, 시작 카드 선택이 필요하면 self_with_approach, Goal Graph 없는 리딩룸은 reading_advisory와 안내·질문 제안을 채웁니다. 좋은 예 “고객 자신+접근 방식—새 세계선 시작 때 조사 관점을 선택.” 금지·검증 비활성화된 캐릭터 빙의를 저장할 수 없으며, 방식 전환 시 계약·오프닝·결말이 삭제될 수 있으므로 경고와 diff를 확인합니다.
3. 접근 방식 카드
목적 같은 고객이 사용할 조사 관점·도구와 시작점을 2~12개 공개 카드로 제시합니다. 작성 안정 ID, 제목·hook·난이도·가능 행동·브리핑·첫 협업, 시작 장소·마일스톤, 공개 가능한 FactRef, 허용 Affordance와 전용 오프닝을 연결합니다. 좋은 예 “직접 확인하기—봉인을 관찰하고 기록 담당자에게 질문한다.” 금지·검증 고객의 직업·정체성을 강제로 대신 쓰거나 hidden/secret 사실을 카드에 노출하지 말고, 모든 참조와 English 인간 검수 상태를 확인합니다.
4. 접근별 오프닝
목적 선택한 접근 카드마다 다른 첫 장면을 만듭니다. 작성 variant·scene ID, 플레이 계약의 장소, 시간·제목·첫 지문, 참여 actor, 초기 Director event, narrator/character 사건을 연결합니다. 좋은 예 “기록실·늦은 밤—참여 actor ‘archivist’가 빈 서약함을 가리킨다.” 금지·검증 고객의 대사·생각·감정·자발 행동을 미리 저작하지 말고, character 사건의 화자가 실제 참여 actor인지와 접근 카드 연결을 검사합니다.
5. 플레이 스타일
목적 진행 구조, 이동, 시간 건너뛰기와 실패 처리를 발행 revision에 고정합니다. 작성 guided_loop, open_journey, hybrid 중 하나를 고르고 체크포인트 또는 장소·연결·앵커 fact·복구 경로를 채웁니다. 좋은 예 hybrid: “기록실↔정원, 핵심 앵커 seal_examined, 놓친 단서는 사서 증언으로 복구.” 금지·검증 NPC 자율성이나 서버 세계 사실을 해제하는 규칙을 쓰지 말고, 시작 장소·연결·필수 fact의 참조와 경로를 검증합니다.
6. 카탈로그
목적 목록·상세 화면에서 고객이 작품을 발견하고 안전하게 선택하게 합니다. 작성 승인된 커버, 장르·분위기 태그, 짧고 구체적인 entryHook, content notes를 입력합니다. 좋은 예 “봉인이 깨지기 전, 누구의 서약이 사라졌는지 직접 추적하세요.” 금지·검증 원문에 없는 자극적 약속이나 주의사항 누락을 피하고, 커버가 같은 creator의 approved asset인지 확인합니다.
7. 세계관·Lore
목적 세계 namespace, 공통 규칙, 모델이 단정하면 안 되는 지식과 공유 설정을 관리합니다. 작성 안정 world ID·제목·규칙·forbiddenKnowledge를 적고, LoreModule은 최대 5개까지 정확한 승인 revision을 manual pin한 뒤 diff로 갱신합니다. 좋은 예 “달빛 없는 밤에는 봉인문이 읽히지 않는다.” 금지·검증 레거시 embedded loreEntries, namespace 충돌·순환·미해결 참조, Lore의 관계/Goal 직접 변경은 발행할 수 없습니다.
8. 인물 카드
목적 1~8명 인물의 정체성·판단·목소리·지식·초상화를 정의합니다. 작성 안정 ID, 이름·요약, 가치·경계와 core 동기를 먼저 정한 뒤 register·호칭·averageLength·questionFrequency·emotionDirectness·침묵 방식·문장 패턴·금지 표현·관계/위기 변화·좋은/나쁜 대사 예시를 채웁니다. 행동 규칙은 지시와 좋은/나쁜 사례를, 반응 예시는 반응 원칙과 실제 장면 한 줄을 한 쌍으로 쓰고, fact로 해금되는 authoredSecrets와 native world/facts를 연결합니다. 좋은 예 “polite, 짧게 답하되 확인하지 않은 사실은 단정하지 않는다”; 원칙 “걱정될수록 잔소리 대신 필요한 물건을 먼저 둔다”, 예시 “재윤은 말없이 따뜻한 우유를 네 앞에 놓는다.” 금지·검증 무조건 복종·관계값 직접 변경·모르는 비밀 주입을 금지하고, 오래된 문자열 규칙은 확인 없이 구조화 형식으로 덮어쓰지 마세요. authored secret 번역과 연결 초상화 승인도 확인합니다.
9. 관계 캐스팅
목적 인물 카드 중 이 작품의 관계 인물과 시작 presence·연속성 자격을 정합니다. 작성 character 참조, 작품 내 역할, present/offscreen/absent, continuationEligible, eventCode·의미·원문·필요 fact가 있는 연속 기억을 연결합니다. 좋은 예 “archivist / 안내자 / present / promise_kept 뒤 ‘약속을 지킨 밤’.” 금지·검증 NPC ID나 존재하지 않는 fact를 연결하거나 조건 없이 기억을 부여하지 말고, eligible 인물은 상호선택 정책 준비 상태를 충족해야 합니다.
10. NPC
목적 관계 인물과 분리된 사건 인물의 역할·지식·행동을 정의합니다. 작성 안정 ID, 이름·역할, knowledge boundary, 말투·행동·반응, 관계방 가능 여부, 초기 presence, FactRef로 해금되는 비밀 문장을 적습니다. 좋은 예 “guard / 문지기 / 경보 원인만 알고 범인은 모름 / 기본 offscreen.” 금지·검증 비밀을 공개 접근 카드에 쓰거나 해금 전 말하게 하지 말고, 관계 중심 인물이 아니라면 relationshipCapable을 켜지 않습니다.
11. 등장 계획
목적 인물·NPC가 조건에 따라 등장·퇴장·화면 밖으로 전환되는 시점을 정합니다. 작성 규칙 ID, actor 참조, 목표 presence, all/any/none fact 조건, 최소 유지 턴, entry focus와 안내문을 입력합니다. 좋은 예 alarm_rung 성립 뒤 guard를 present로 전환하고 “복도에서 발소리가 가까워진다.” 금지·검증 absent 인물을 과거 사건 목격자로 만들지 말고, 중복·모순 전환과 존재하지 않는 actor/fact를 검사합니다.
12. 게스트 동행
목적 다른 작품에서 관계를 맺은 인물이 이 작품에 들어올 수 있는 슬롯과 경계를 정합니다. 작성 최소·최대 인원, 슬롯 ID·라벨·필수 여부, allowed_list 또는 active_connection, 역할, 지식 경계·로컬 제약, {{guestName}} 도착문을 작성합니다. 좋은 예 “동행자 0~1명, 현재 연결 인물, 이 세계의 마법은 처음 본다.” 금지·검증 새 능력·세계 지식을 자동 부여하지 말고, min/max와 allowlist 소유·공개 참조를 확인합니다.
13. 사실(Facts)
목적 Goal 상태와 인물 지식의 근거가 되는 안정 사실을 정의합니다. 작성 local ID·설명·public/discovered/hidden과 state_only/observable/tellable/secret을 고르고, 시작부터 참인 것만 initialFactIds에 넣습니다. 좋은 예 seal_examined / “봉인의 균열을 확인했다” / discovered+observable. 금지·검증 모델 문장만으로 사실을 만들거나 secret을 observable로 노출하지 말고, FactRef가 필요한 곳에서는 worldNamespace:localId와 중복 ID를 검사합니다.
14. 마일스톤
목적 여러 fact를 사람이 이해할 수 있는 진행 단계로 묶습니다. 작성 안정 ID, 설명, 공개 범위, completeWhen의 all/any/none Fact 조건을 구성합니다. 좋은 예 identify_owner: seal_examined과 witness_heard가 모두 성립. 금지·검증 마일스톤 자체가 fact나 관계값을 변경한다고 쓰지 말고, 시작부터 완료되거나 어떤 Affordance로도 도달할 수 없는 조건을 Goal 분석으로 찾습니다.
15. Affordance
목적 고객 자유문장을 실행 가능한 서버 행동과 결과 fact로 연결합니다. 작성 안정 ID·설명, 다양한 positive/negative examples, 선택적 semantic anchors, 인식·실행 조건, eventCode, add/remove facts, 연출·차단 안내를 채웁니다. 좋은 예 inspect_seal; 긍정 “봉인을 자세히 본다”, 부정 “봉인을 뜯어 버린다”; 성공 시 seal_examined 추가. 금지·검증 관계·기억을 직접 쓰거나 고객이 NPC 행동을 확정하게 하지 말고, 조건·결과 참조와 오인식 예문을 테스트합니다.
16. Goal Graph
목적 현재 Facts·Affordances·Milestones·Endings를 시각화하고 실제 서버 GoalRuntime으로 도달성을 검사합니다. 작성 원래 탭에서 계약을 저장한 뒤 전체 경로 검사 또는 Affordance 순서 builder를 실행합니다. 좋은 예 inspect_seal → question_archivist → restore_oath 경로를 서버에서 실행. 금지·검증 이 화면이 별도 그래프 상태를 저장한다고 가정하지 말고, 실패 trace와 도달 불가 엔딩을 원본 필드에서 수정합니다.
17. 엔딩
목적 최대 12개 endingId의 도달 조건·결과 유형·마지막 연출을 정의합니다. 작성 ID·라벨, true_ending/partial_ending/bad_ending, all/any/none fact 조건을 넣고 필요하면 ID 전용 연출을, 아니면 outcome 기본 연출을 사용합니다. 좋은 예 oath_restored—서약 복구 fact가 있을 때 true ending 전용 장면. 금지·검증 결말 효과로 관계·기억·capability를 직접 부여하지 말고, 중복 ID·12개 제한·도달성·연출 누락을 검사합니다.
18. 공통 오프닝
목적 작품의 공통 첫 연출을 작성합니다. 작성 narrator 또는 character 역할, 표시 이름과 짧은 지문·대사를 순서대로 배치합니다. 좋은 예 narrator: “닫힌 기록실 문틈으로 푸른 빛이 샌다.” 금지·검증 고객의 말·생각·감정·행동을 대신 확정하지 말고, 빈 text와 character 이름 누락을 확인합니다.
19. 정책·Director
목적 고위험 행동과 eventCode별 보조 연출, 정체된 장면을 움직이는 Director event, 기억이 실제 행동으로 드러나는 EchoBeat를 정의합니다. 작성 실제 Affordance/eventCode를 참조하고 Director의 ID·kind·주도 actor·quiet_turns/no_progress_attempts/after_fact 트리거·조건·우선순위·연출 지시를 채웁니다. EchoBeat에는 최소/재사용 대기 턴, 목적, 허용 기억 출처·주제·종류·선호 극성, 불일치 시 fallback 또는 suppress, 일치/대체 행동을 작성합니다. 각 행동의 evidenceTermsAny 중 적어도 하나는 고객에게 커밋될 narration 문장에 그대로 들어가야 합니다. 좋은 예 “우유” 선호 기억이 맞으면 “재윤은 따뜻한 우유를 네 앞에 놓는다”; 기억이 없을 때 suppress라면 대체 행동은 만들지 않습니다. 금지·검증 내부 directive나 검증 토큰을 고객용 설명으로 공개하거나, Director/EchoBeat가 관계·기억·capability를 직접 바꾸게 하지 마세요. 존재하는 actor/fact/eventCode, 고위험 확인 경로, 기억 불일치와 증거 문구를 모두 테스트합니다.
20. 상호선택 정책
목적 실제 committed fact와 인물의 참여 방식으로 관계 근거를 쌓고, 문맥별 accept/defer/decline을 캐릭터가 판단하게 합니다. 작성 evidence의 source fact·participant/observer/direct_target·reason·축/고유 신호 효과와, 5개 문맥의 최소 축·신호·필수/금지 사건·대상·기본 결과를 저작합니다. 좋은 예 promise_kept에 참여한 인물의 trust+1; 신호 2 이상이면 accept, 그 외 기본 defer. 금지·검증 Plot/Lore가 결과를 직접 지정하거나 근거 부족 기본값을 accept로 우회하지 말고, continuation eligible 인물의 ending/private-room 규칙과 서버 판단 미리보기를 검사합니다.
4. 인물 목소리
말끝 몇 개보다 인물이 판단하는 기준을 먼저 써야 장면이 달라져도 같은 사람으로 느껴집니다.
- 핵심: 원하는 것, 두려운 것, 지키는 가치, 넘지 않는 경계, 잘못을 인정하는 방식과 압박받을 때의 반응을 구체적으로 씁니다.
- 말하기: 높임말·호칭·문장 길이·직설성·침묵·농담의 빈도를 정하고, 평온·갈등·친밀 장면의 짧은 예시를 각각 제공합니다.
- 연기 재료: 문장 패턴과 금지 표현은 단어 목록이 아니라 “어떤 상황에서 어떻게 말하는가”가 보이게 쓰고, 좋은 예시와 나쁜 예시는 같은 상황을 대비해 작성합니다. 행동 규칙과 반응 예시의 기존 문자열은 Studio의 명시적 변환 안내를 확인한 뒤 구조화하세요.
- 지식: 인물이 관찰했거나 전달받은 사실만 말하게 하고, 작가만 아는 비밀과 다른 인물의 속마음을 분리합니다.
- 관계 근거: 약속을 지킴, 경계를 존중함처럼 인물이 중요하게 보는 행동을 relationship evidence rule로 작성합니다. 콘텐츠가 결과 스탯을 직접 쓰게 하지 마세요.
- 검증: 같은 질문을 평온·위기·다인물 장면에서 시험하고, 모든 인물이 비슷한 문장과 판단을 내리면 가치·경계·말투 예시를 더 구체화합니다.
5. 이미지 업로드 규격과 권리
- 허용 형식: 정적 JPEG, PNG, WebP. 파일당 최대 5MB이며 원본 가로·세로는 각각 64~4096px여야 합니다. SVG, GIF와 실행 가능한 콘텐츠는 허용하지 않습니다.
- 권장 구도: 표지는 3:4 비율의 1200×1600px, 인물 초상화는 1:1 비율의 1200×1200px를 권장합니다. 중앙 기준으로 잘릴 수 있으므로 얼굴과 중요한 글자를 가장자리에 두지 말고 crop 미리보기를 확인하세요.
- 접근성: 이미지가 전달하는 인물·장면을 설명하는 대체 텍스트가 필수입니다. 파일명이나 “이미지”만 쓰지 마세요.
- 처리: 확장자가 아니라 실제 이미지 형식과 크기를 검사하며, 승인용 파생 이미지에서 EXIF 등 메타데이터를 제거합니다. 승인 대기·반려·삭제 상태의 이미지는 새 발행본에 사용할 수 없습니다.
- 권리: 직접 만들었거나 상업적 이용·재허락 권한을 확보한 이미지만 올립니다. AI 도구, 제3자 소재, 실존 인물·브랜드 사용 여부와 허락 근거를 정확히 공개해야 합니다.
자세한 보증과 신고 절차는 창작자 권리·출품 정책과 권리 신고 절차를 따릅니다.
6. Lint·플레이테스트·검수·리비전
- 저장: 저장 상태와 충돌 알림을 확인합니다. 다른 창에서 수정했다면 local/server diff를 검토한 뒤 필요한 내용을 복구합니다.
- Lint: 오류를 누르면 연결된 섹션과 필드로 이동합니다. 누락된 필수값뿐 아니라 깨진 참조, 비밀 지식 누출, 관계 상태 직접 쓰기와 발행 품질 조건을 모두 해결합니다.
- 실제 플레이테스트: sandbox에서 자유문장, 목표 경로, 다인물 응답, Lore 검색, 기억·지식, 결말과 상호선택을 확인합니다. sandbox 결과는 실제 고객 관계 데이터에 반영되지 않습니다.
- 제출: 흐름은 draft → submitted → changes_requested 또는 approved → scheduled → published입니다. 창작자가 저장한 초안이 즉시 공개되지는 않습니다.
- Revision: 승인된 발행 revision은 바뀌지 않습니다. 공개 중인 작품을 수정해도 기존 live revision은 유지되고, 새 revision이 승인된 뒤에만 공개 포인터가 이동합니다.
7. 번역과 인간 검수
- 번역본에서도 stable ID와 참조는 그대로 두고, 독자에게 보이는 제목·설명·대사·선택지·content notes만 번역합니다.
- 자동 번역은 초안입니다. 원문의 인물 관계, 높임말, 호칭, 고유명사, 금지 표현과 연령등급을 이해하는 사람이 최종 검수해야 합니다.
- 직역보다 인물 목소리와 장면의 의도를 보존하되, 원문에 없는 사실·감정·선택 조건을 새로 만들지 않습니다.
- 각 언어에서 잘림, 누락, 변수·참조 오류를 확인하고 실제 플레이테스트를 다시 실행합니다. 언어별 품질 gate를 통과하기 전에는 해당 locale을 공개하지 마세요.
제출 전 마지막 확인
- 첫 장면에서 독자가 무엇을 할 수 있는지 분명한가?
- 각 인물의 욕구·경계·목소리와 알고 있는 사실이 구별되는가?
- 깨진 참조 없이 목표와 결말까지 실제로 도달할 수 있는가?
- 표지·초상화의 권리, 출처, alt text와 승인 상태를 확인했는가?
- 모든 공개 언어를 사람이 검수하고 sandbox에서 끝까지 플레이했는가?