• 홈
  • 블로그
  • 갤러리
  • 가격
  • 홈
  • 블로그
  • 갤러리
  • 가격
창작 시작

만들고.플레이하세요.

크리에이터 블로그

홈/블로그/제품 워크플로

DramaFork 플레이어블 프리뷰 문제 분류 방법: 스토리, 인터랙션, 소재는 각각 어느 단계로 돌아가 수정할까?

플레이어블 프리뷰에서 문제가 생겼을 때, 먼저 노드를 고치려 하지 마세요. 한 줄 증상 기록으로 '누가 언제 무엇을 보았는지'를 명확히 적고, 그것이 스토리, 인터랙션, 소재 중 어디에 속하는지 판단하세요. 스토리류는 기획이나 시나리오로, 인터랙션류는 인터랙션 노드로, 소재류는 스토리보드, 스타일, 캐릭터 소재 또는 영상으로 돌아갑니다. 수정 후에는 영향을 받은 하위 단계만 재검토하고, 프리뷰가 돌아간다고 해서 배포 테스트 통과로 간주하지 마세요.

D
DramaFork Editorial Team인터랙티브 스토리텔링과 AI 제작
2026.09.27예상 읽기 시간: 6분
프리뷰 화면이 문 앞에서 멈춰 있고, 옆에서 시나리오, 인터랙션, 소재로 분류해 진단하는 모습.
목차
크리에이터 블로그
  1. 01개요
  2. 02먼저 증상 기록을 쓰고, 그다음 분류
  3. 03인터랙션 문제는 노드로 돌아가 수정
  4. 04소재 문제는 스토리보드, 스타일, 캐릭터 또는 영상으로 돌아가 수정
  5. 05스토리 문제는 기획 또는 시나리오로 돌아가 수정
  6. 06상위 변경 후 최소 재검토 경로
  7. 07완료 점검
글 맨 위로

개요

플레이어블 프리뷰에서 문제가 생겼을 때, 먼저 노드를 고치려 하지 마세요. 한 줄 증상 기록으로 '누가 언제 무엇을 보았는지'를 명확히 적고, 그것이 스토리, 인터랙션, 소재 중 어디에 속하는지 판단하세요. 스토리류는 기획이나 시나리오로, 인터랙션류는 인터랙션 노드로, 소재류는 스토리보드, 스타일, 캐릭터 소재 또는 영상으로 돌아갑니다. 수정 후에는 영향을 받은 하위 단계만 재검토하고, 프리뷰가 돌아간다고 해서 배포 테스트 통과로 간주하지 마세요.

아래에서는 가상의 교육 예시를 관통해서 사용합니다: 인터랙티브 영화 게임 《안개항 야간 근무》, 주인공은 야간 등대 관리인 린처, 목표는 날이 밝을 때까지 버티고 실종된 선원의 행방을 밝히는 것, 비밀은 그가 같은 해역에서 배를 버리고 탈출한 적이 있다는 것, 초기 관계에서는 관제사 선란과 서로 신뢰하지 않습니다. 이하 인물, 숫자, 대사는 모두 가상이며, 어떤 실제 프로젝트와도 대응하지 않습니다.

먼저 증상 기록을 쓰고, 그다음 분류

증상 기록에는 네 가지 항목을 포함하는 것이 좋습니다: 발생 시점, 플레이어가 본 내용, 예상 내용, 재현 가능한 최단 경로. 시점은 구체적인 노드까지 적어야 합니다. 예를 들어 '노드 N-07 진입 후 처음 옵션이 표시될 때'처럼요. '중간 부분이 이상해요'라고 쓰면 위치를 특정할 수 없습니다.

《안개항 야간 근무》의 세 가지 기록은 이렇게 채울 수 있습니다:

번호 발생 시점 플레이어가 본 것 예상 초기 판단
S1 노드 N-03 옵션 표시 시 세 옵션의 어조가 거의 동일 최소 하나의 옵션이 린처의 배 버리고 탈출한 과거 은폐를 드러내야 함 인터랙션
S2 '선란에게 캐묻기' 선택 후 재생된 영상 선란은 웃고 있는데 대사는 추궁 표정과 추궁 어조가 일치 소재
S3 N-05에서 N-06으로 진입 바로 날이 밝고, 배 수색 과정이 빠짐 중간에 수색 장면이 있어야 함 스토리

분류 기준은 '텍스트가 잘못됐는지, 화면이 잘못됐는지, 아니면 사건 순서가 잘못됐는지'입니다. S1의 옵션 텍스트는 노드가 담당하므로 인터랙션; S2의 화면은 영상 소재에서 오므로 소재; S3는 사건 누락이므로 스토리입니다.

인터랙션 문제는 노드로 돌아가 수정

S1의 근원은 노드 문안입니다. 노드는 표로 조직되며, 한 행이 하나의 표시 위치에 대응하고, 드래그 그림이 아닙니다. 수정할 때는 먼저 해당 노드에 장착된 영상과 조건이 변경되지 않았는지 확인하고, 옵션 텍스트만 고칩니다.

원래 옵션:

  • 등대에 왜 왔는지 묻는다
  • 오늘 밤 조위를 묻는다
  • 아무것도 묻지 않는다

다음으로 변경:

  • 등대에 왜 왔는지 묻는다
  • 오늘 밤 조위를 묻고, 겸사겸사 '백구호'를 아는지 떠본다
  • 아무것도 묻지 않고, 몸을 돌려 케이블을 점검한다

두 번째 옵션은 린처의 비밀을 떠볼 수 있는 방향으로 만들고, 세 번째 옵션은 회피 자세를 줍니다. 수정 후에는 N-03 이후의 프리뷰 구간만 재검토하고, 세 옵션이 각각의 후속으로 진입할 수 있는지 확인하며, 전체 라인을 재검토하지 않습니다.

소재 문제는 스토리보드, 스타일, 캐릭터 또는 영상으로 돌아가 수정

S2의 표정과 대사 충돌은 먼저 입력에 이 표정을 요구했는지 판단합니다. 스토리보드는 화면 속 동작과 감정 의도를 결정하고, 스타일은 영상 질감을 제약하며, 캐릭터 소재는 인물 참고를 제공하고, 영상이 실제 생성 결과입니다. 이 예시의 스토리보드에는 이미 '엄숙한 추궁'이 명확히 적혀 있고, 참고에도 웃는 요구가 없지만, 생성된 클립은 여전히 웃고 있습니다. 먼저 이 영상 작업부터 확인할 수 있으며, 화면만 보고 모델 내부에서 어느 프레임을 선택했는지 추론해서는 안 됩니다.

처리 방식은 해당 스토리보드와 참고를 확인하고, 필요하면 동작 설명을 명확히 한 뒤, 이 영상 작업만 별도로 재시도하는 것입니다. 인물 참고 자체에 적용되지 않는 표정이 있다면, 캐릭터 소재 단계로 돌아가 수정하고, 해당 참고를 사용하는 다른 클립도 점검합니다. 재시도 후에도 실제 출력을 봐야 합니다. 여기의 문제 해결에는 타임라인이나 프레임별 표정 교체 기능은 포함되지 않습니다.

스토리 문제는 기획 또는 시나리오로 돌아가 수정

S3는 배 수색 과정이 빠져 있으며, 사건 구조에 속합니다. 먼저 시나리오로 돌아가 N-05와 N-06 사이에 수색 장면을 추가합니다: 린처가 화물창을 점검하고, 잘린 케이블을 발견하고, 상층에서 발소리를 듣습니다. 추가 후, 기획의 '실종된 선원의 행방을 밝힌다' 목표에 대응하는 단락이 생깁니다.

시나리오를 고치면 스토리보드, 스타일, 캐릭터, 노드, 영상, 프리뷰, 내보내기에 하향 영향을 줍니다. 실제 작업 시에는 관련 있고 이미 완료된 단계만 업데이트 필요로 표시하고, 이전 데이터는 보존합니다. 의미적으로 정확한 자동 차분도, 원클릭 확인 재사용도 없으므로 수동으로 확인해야 합니다: 새로 추가한 수색 단락이 기존 스토리보드와 영상 표현을 여전히 성립하게 하는지.

상위 변경 후 최소 재검토 경로

세 가지 증상을 각각 수정한 후, 재검토 범위는 변경 계층에 따라 결정됩니다:

  1. 노드 문안만 변경: 해당 노드 및 직접 후속의 프리뷰 구간을 재검토합니다.
  2. 영상 소재만 변경: 해당 영상이 장착된 노드의 재생 효과를 재검토합니다.
  3. 시나리오에 새 단락 추가: 새 단락에 대응하는 스토리보드, 영상, 노드, 그리고 앞뒤 노드와의 연결을 재검토합니다.
  4. 캐릭터 소재 변경: 해당 캐릭터를 사용하는 모든 영상과 프리뷰 구간을 재검토합니다.

재검토 시 동일한 증상 기록으로 결과를 채웁니다. 예를 들어 S1은 '수정 완료, 세 옵션의 어조 구분 가능', S2는 '해당 영상 재시도 완료, 실제 표정과 추궁 일치', S3는 '수색 단락 추가 완료, N-05에서 N-06 연결 완전'으로 기록합니다. 이는 여전히 가상의 작성 예시이며, 실제 프로젝트는 관찰 결과에 따라 기록해야 합니다.

완료 점검

  • 각 증상에 발생 시점, 본 내용, 예상 내용, 최단 재현 경로가 있다.
  • 분류 결론이 구체적인 단계를 가리키며, '전체를 다시 조정'이라고 쓰지 않는다.
  • 노드를 고칠 때는 노드만, 영상을 고칠 때는 영상만 움직이며, 무관한 단계에 영향을 주지 않는다.
  • 상위 변경 후, 관련 있고 이미 완료된 단계만 업데이트 필요로 표시하고, 이전 데이터는 보존한다.
  • 재검토 범위가 변경 계층에 대응하며, 전체 라인 재실행을 유일한 수단으로 삼지 않는다.
  • 프리뷰가 연속 재생된다고 해서 배포 테스트 통과가 아니다; 내보낸 후에도 소재 패키지 설명에 따라 점검해야 한다.

이 글은 DramaFork가 정리했으며, 현재 프로젝트 구현에 따라 설명합니다. 플레이어블 프리뷰는 노드와 소재 연결을 점검하는 데 사용되며, 내보낸 후의 플레이어빌리티 검증을 대체하지 않습니다. ZIP 성공은 플레이어빌리티 검증이 아니며, localhost는 다른 사람의 컴퓨터에서 그 사람의 로컬을 가리키므로 범용 접근 가능한 도메인으로 사용할 수 없습니다.

다음 단계: 최근에 겪은 프리뷰 증상 하나를 골라, 위 표에 한 행을 채우고, 발생 시점과 최단 재현 경로를 적은 뒤, 그것이 스토리, 인터랙션, 소재 중 어디로 돌아갈지 결정하세요.

제품 기능 알아보기 인터랙티브 작품 체험

계속 읽기

더 많은 글 보기
변경 기록이 수정 원인, 새로운 다리 동작, 영향을 받는 소재를 연결한다.
제품 워크플로2026.09.30 · 6분

인터랙티브 스토리의 변경 기록 작성법: 원인, 변경, 영향받는 루트 구분하기

변경 기록은 세 칸으로 작성한다: 원인, 변경, 영향받는 루트. 원인은 "왜 바꾸는지"를 설명하고, 변경은 "무엇을 바꾸는지"를 명확히 쓰며, 영향받는 루트는 "어떤 소재와 분기가 재검토되어야 하는지"를 나열한다. 아래에는 가상의 교육용 예시를 관통해서 사용한다: 어떤 인터랙티브 영화 게임이 원래 2장에 "끊어진 다리" 노드를 두었고, 플레이어는 밧줄을 찾아야 강을 건널 수 있었다; 작가는 나중에 끊어진 다리를 "지연된 나룻배"로 바꾸었는데, 그 이유는 원래 설계가 한 온화한 루트를 어색하게 만들었기 때문이다. 이하 인명, 숫자, 대사는 모두 가상이며, 작성법 시연에만 사용된다

두 창작자가 모호한 의견을 구체적인 장면 동작을 가리키는 수정서로 바꾸는 모습.
제품 워크플로2026.09.29 · 6분

두 창작자가 교대로 검토할 때, '여기가 틀렸어'를 실행 가능한 수정서로 쓰는 방법은?

'여기가 틀렸어'를 수정서로 바꾸는 핵심 동작은 하나뿐입니다. 모든 의견을 버전, 노드, 현상, 기대, 이유, 책임, 검증이라는 일곱 칸에 넣는 것입니다. 두 사람이 교대로 검토할 때는 먼저 각자 독립적으로 수정서를 작성하고, 충돌 항목을 병합한 뒤에야 원고를 수정합니다. 아래에서는 가상의 교육용 예시로 전체 과정을 진행하며, 인물, 대사, 수치는 실제 측정 자료가 아닙니다.

한 컴퓨터의 로컬 서비스와 다른 컴퓨터가 길 건너 서로 마주 보고, 공용 연결 다리가 도달 가능한 주소를 알려주는 모습.
제품 워크플로2026.09.29 · 6분

원격 소재 패키지에 localhost가 나타나면, 왜 다른 컴퓨터에서는 열리지 않을 수 있을까?

원격 패키지의 소재 주소가 localhost를 가리키면, 컴퓨터를 바꾼 뒤에는 수신자 자신의 컴퓨터로 요청이 갑니다. 제작자 컴퓨터의 서비스는 ZIP과 함께 옮겨지지 않으므로 "내 쪽에서는 재생된다"는 것만으로 다른 사람도 재생할 수 있다고 증명할 수 없습니다. 처리 순서는 실제 요청 주소 확인, 애플리케이션 도메인 대조, 재내보내기, 다른 기기에서 검증입니다.

제작의 복잡함은 Agent에게, 창작의 결정권은 당신에게.

하나의 이야기 아이디어에서 시작해 대본, 캐릭터, 장면과 분기를 구성하고 플레이 가능한 첫 버전을 만드세요.

제품

  • 가격
  • 주요 기능
  • 제작 과정
  • 작품 예시
  • 자주 묻는 질문

둘러보기

  • 인터랙티브 갤러리
  • 크리에이터 블로그
  • 크리에이터 파트너십

법적 고지

  • 개인정보 처리방침
  • 이용약관
© 2026 DramaFork/AI 인터랙티브 스토리 스튜디오
Press Enter to send, or drag away and release.