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

만들고.플레이하세요.

크리에이터 블로그

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

DramaFork 대본 수정 후, 어떤 소재를 다시 확인해야 할까? 변경 영향 표

대본을 수정한 후에는 기획, 스토리보드, 스타일, 캐릭터, 노드, 영상 간의 의존 관계에 따라 기존 결과를 점검한 뒤 다시 플레이테스트하고 내보내야 합니다. DramaFork는 영향을 받은 관련 완료 단계를 '업데이트 필요'로 표시하고 기존 내용을 확인용으로 보존합니다. 이 상태는 버전이 일치하지 않을 수 있음을 알리는 것이지, 모든 소재가 이미 삭제되었다는 뜻이 아닙니다.

D
DramaFork Editorial Team인터랙티브 스토리텔링과 AI 제작
2026.09.03예상 읽기 시간: 6분
수정된 대본, 스토리보드, 캐릭터 스케치, 필름 릴이 서로 연결된 모습을 보여주는 도해.
목차
크리에이터 블로그
  1. 01개요
  2. 02먼저 이야기의 어느 층을 바꿨는지 구분하기
  3. 03의존 표로 점검 순서 정하기
  4. 04대본 수정 하나가 최종 작품까지 어떻게 전달되는가
  5. 05세 가지 결과를 각각 처리하기
  6. 06수정 기록은 다른 사람이 이어서 작업할 수 있는 설명으로 쓰기
  7. 07다시 플레이테스트하고, 다시 납품하기
글 맨 위로

개요

대본을 수정한 후에는 기획, 스토리보드, 스타일, 캐릭터, 노드, 영상 간의 의존 관계에 따라 기존 결과를 점검한 뒤 다시 플레이테스트하고 내보내야 합니다. DramaFork는 영향을 받은 관련 완료 단계를 '업데이트 필요'로 표시하고 기존 내용을 확인용으로 보존합니다. 이 상태는 버전이 일치하지 않을 수 있음을 알리는 것이지, 모든 소재가 이미 삭제되었다는 뜻이 아닙니다.

이 글은 DramaFork가 2026년 10월 4일의 워크벤치 구현을 기준으로 정리한 것으로, 수정 영향과 점검 방법을 설명합니다. 구체적인 작업 진입점은 사용 중인 버전을 기준으로 하며, 코드 규칙을 이번 온라인 실측이라고 부르지 않습니다.

먼저 이야기의 어느 층을 바꿨는지 구분하기

한 줄의 대사, 한 인물의 목표, 하나의 전환이 가져오는 영향은 서로 다릅니다. 수정 전에 네 가지를 기록합니다: 변경 대상, 기존 내용, 새 내용, 보존해야 할 서사적 결과.

예를 들어 '쉬란은 원본 서류를 확인하라고 요구한다'를 '쉬란은 수령인을 믿고 물건을 바로 넘긴다'로 바꾸면, 영향을 받는 것은 자막만이 아닙니다. 인물의 행동, 카메라, 선택지 이전의 정보, 결말 조건을 모두 재검토해야 합니다.

의미가 변하지 않는 표현 하나만 교체하더라도 더빙, 자막, 스토리보드 대사가 여전히 일치하는지 확인해야 합니다. 점검 범위를 좁힐 수는 있지만, 수정 분량이 적다는 이유로 모든 후속 결과를 처리할 필요가 없다고 단정해서는 안 됩니다.

현재 워크벤치는 단계 관계에 따라 업데이트를 알릴 뿐, 문장별로 신구 대본의 의미 차이를 증명하지는 않습니다. 작성자는 이러한 알림 위에 구체적인 판단을 더해야 합니다.

의존 표로 점검 순서 정하기

변경이 발생한 곳 워크벤치가 연결하는 하위 점검 범위 작성자가 먼저 확인할 것
기획 대본, 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기 세계 규칙과 인물 목표가 바뀌었는지
대본 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기 행동, 정보, 분기, 결말이 여전히 대응하는지
스토리보드 노드, 영상, 미리보기, 내보내기 샷 번호, 내용 커버리지, 재생 순서
스타일 캐릭터, 영상, 미리보기, 내보내기 캐릭터 참조와 화면 표현이 통일되었는지
캐릭터 소재 영상, 미리보기, 내보내기 새 이미지와 이미 생성된 샷이 일치하는지
인터랙티브 노드 미리보기, 내보내기 선택 대상, 경로, 종료 조건
영상 소재 미리보기, 내보내기 소재가 올바르게 로드되고 앞뒤 샷을 잇는지

표의 범위는 의존 알림입니다. 항목별 검수를 대신할 수 없으며, 그 안의 모든 파일을 반드시 다시 생성해야 한다는 뜻도 아닙니다. 예를 들어 같은 장면은 기존 화면을 그대로 쓸 수 있지만, 작성자는 기존 화면에 이미 삭제된 동작이 남아 있지 않은지 확인해야 합니다.

점검은 상류에서 하류로 진행해야 합니다. 대본이 아직 변동 중일 때 노드와 영상을 먼저 처리하면, 방금 완료한 결과가 다시 만료되기 쉽습니다.

대본 수정 하나가 최종 작품까지 어떻게 전달되는가

구버전에서는 플레이어가 먼저 등록부를 조회한 뒤 물건을 넘길지 선택한다고 가정합시다. 신버전에서는 먼저 넘길지를 결정하고, 그 이후에야 확인할 기회가 생깁니다. 샷의 위치는 비슷할 수 있지만, 플레이어가 결정을 내릴 때 가진 정보는 이미 달라졌습니다.

첫 번째로 대본을 점검합니다: 새 순서가 플레이어에게 아직 안내되지 않은 위험을 지우게 하는가? 불확실성을 유지하려면 플레이어가 이해할 충분한 단서를 제공했는가?

두 번째로 스토리보드와 노드를 점검합니다: 선택지가 여전히 기존 샷 뒤에 나오는가? 버튼 문구가 플레이어가 이미 등록부를 봤다고 암시하지 않는가? 두 선택이 새 버전의 목표를 향하는가?

세 번째로 소재를 점검합니다: 기존 영상에 '방금 등록 시간이 맞지 않았어'가 나오면, 신버전에서 아직 얻지 못한 정보를 노출합니다. 화면이 재생되더라도 이 대사는 교체해야 합니다.

마지막으로 진입점에서 전체 경로를 걸어보며, 결말이 신버전 선택을 읽는지 확인합니다. 특정 샷 하나만 보아 문제가 없다는 것은 전체 경로의 인과가 올바르다는 증명이 아닙니다.

세 가지 결과를 각각 처리하기

계속 점검하며 재사용할 수 있는 내용: 장면 분위기, 변하지 않은 인물 외형,剧情 정보와 무관한 빈 샷. 그것이 의존하는 설정을 기록하고, 해당 설정이 여전히 성립하는지 확인합니다.

반드시改写하거나 교체해야 하는 내용: 새 행동과 충돌하는 대사, 삭제된 노드를 가리키는 선택지, 구 인물 상태가 나타나는 샷. 먼저 참조와 사실을 고치고, 그다음 다듬기를 고려합니다.

당장 판단할 수 없는 내용: 상태 관련 연기, 모호한 결말 피드백, 여러 경로가 공유하는 샷. 어떤 전제가 관련되는지 표시하고 관련 경로를 각각 플레이테스트합니다. 메인 라인 하나가 통과했다고 재사용 가능하다고 선언해서는 안 됩니다.

이 분류는 수동 검토 방법입니다. 단계가 어떻게 완료로 복구되는지, 어떤 소재를 다시 선택할 수 있는지는 워크벤치가 제공하는 작업에 따라 실행해야 하며, 모두 한 번에 재사용 확인하는 원클릭 기능이 있다고 가정해서는 안 됩니다.

수정 기록은 다른 사람이 이어서 작업할 수 있는 설명으로 쓰기

기록 항목 예시
수정 이유 확인을 선택 이후로 옮겨, 위험을 감수한다는 주제를 강화
변경 범위 대본 2장의 동작 순서와 관련 선택지
교체 필요 확인 결과를 미리 노출하는 대사와 샷
재검토 필요 두 경로의 결말 정보와 공유 샷
검수 결과 두 경로 모두 신버전 정보 순서대로 완료
납품 버전 새 내보내기 패키지 이름과 검수 완료 날짜

마지막 두 항목은 실제 검수 후에 작성해야 합니다. 실행 기록이 없으면 미검수로 유지하며, '수정 준비됨'을 '통과함'으로 쓰면 안 됩니다.

여러 사람이 번갈아 한 프로젝트를 처리할 때는 기록에 누가 대본을 맡는지, 누가 소재를 맡는지, 누가 플레이테스트를 맡는지도 밝혀야 합니다. 이는 업무 인수인계이며, 제품이 실시간 다인 협업 편집을 이미 제공한다는 뜻이 아닙니다.

다시 플레이테스트하고, 다시 납품하기

구 내보내기 패키지는 클라우드 대본이 수정되었다는 이유만으로 최신 납품물로 간주될 수 없습니다. 스토리보드, 노드, 소재가 일치하는지 확인한 뒤 영향을 받은 경로를 다시 플레이테스트하고, 선택 이전 정보, 즉각 피드백, 결말을 점검한 다음 새 패키지를 생성합니다.

DramaFork의 창작 흐름은 단계별 점검과 계속 수정을 강조합니다. 가장 실용적인 방법은 이 영향 표를 프로젝트의 변경 기록과 함께 두는 것입니다. 상류를 수정할 때마다 어떤 결과를 점검했고, 무엇이 아직 남아 있으며, 외부에는 어느 버전을 사용해야 하는지 설명할 수 있습니다.

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

계속 읽기

더 많은 글 보기
변경 기록이 수정 원인, 새로운 다리 동작, 영향을 받는 소재를 연결한다.
제품 워크플로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.