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

개요
대본을 수정한 후에는 기획, 스토리보드, 스타일, 캐릭터, 노드, 영상 간의 의존 관계에 따라 기존 결과를 점검한 뒤 다시 플레이테스트하고 내보내야 합니다. DramaFork는 영향을 받은 관련 완료 단계를 '업데이트 필요'로 표시하고 기존 내용을 확인용으로 보존합니다. 이 상태는 버전이 일치하지 않을 수 있음을 알리는 것이지, 모든 소재가 이미 삭제되었다는 뜻이 아닙니다.
이 글은 DramaFork가 2026년 10월 4일의 워크벤치 구현을 기준으로 정리한 것으로, 수정 영향과 점검 방법을 설명합니다. 구체적인 작업 진입점은 사용 중인 버전을 기준으로 하며, 코드 규칙을 이번 온라인 실측이라고 부르지 않습니다.
먼저 이야기의 어느 층을 바꿨는지 구분하기
한 줄의 대사, 한 인물의 목표, 하나의 전환이 가져오는 영향은 서로 다릅니다. 수정 전에 네 가지를 기록합니다: 변경 대상, 기존 내용, 새 내용, 보존해야 할 서사적 결과.
예를 들어 '쉬란은 원본 서류를 확인하라고 요구한다'를 '쉬란은 수령인을 믿고 물건을 바로 넘긴다'로 바꾸면, 영향을 받는 것은 자막만이 아닙니다. 인물의 행동, 카메라, 선택지 이전의 정보, 결말 조건을 모두 재검토해야 합니다.
의미가 변하지 않는 표현 하나만 교체하더라도 더빙, 자막, 스토리보드 대사가 여전히 일치하는지 확인해야 합니다. 점검 범위를 좁힐 수는 있지만, 수정 분량이 적다는 이유로 모든 후속 결과를 처리할 필요가 없다고 단정해서는 안 됩니다.
현재 워크벤치는 단계 관계에 따라 업데이트를 알릴 뿐, 문장별로 신구 대본의 의미 차이를 증명하지는 않습니다. 작성자는 이러한 알림 위에 구체적인 판단을 더해야 합니다.
의존 표로 점검 순서 정하기
| 변경이 발생한 곳 | 워크벤치가 연결하는 하위 점검 범위 | 작성자가 먼저 확인할 것 |
|---|---|---|
| 기획 | 대본, 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기 | 세계 규칙과 인물 목표가 바뀌었는지 |
| 대본 | 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기 | 행동, 정보, 분기, 결말이 여전히 대응하는지 |
| 스토리보드 | 노드, 영상, 미리보기, 내보내기 | 샷 번호, 내용 커버리지, 재생 순서 |
| 스타일 | 캐릭터, 영상, 미리보기, 내보내기 | 캐릭터 참조와 화면 표현이 통일되었는지 |
| 캐릭터 소재 | 영상, 미리보기, 내보내기 | 새 이미지와 이미 생성된 샷이 일치하는지 |
| 인터랙티브 노드 | 미리보기, 내보내기 | 선택 대상, 경로, 종료 조건 |
| 영상 소재 | 미리보기, 내보내기 | 소재가 올바르게 로드되고 앞뒤 샷을 잇는지 |
표의 범위는 의존 알림입니다. 항목별 검수를 대신할 수 없으며, 그 안의 모든 파일을 반드시 다시 생성해야 한다는 뜻도 아닙니다. 예를 들어 같은 장면은 기존 화면을 그대로 쓸 수 있지만, 작성자는 기존 화면에 이미 삭제된 동작이 남아 있지 않은지 확인해야 합니다.
점검은 상류에서 하류로 진행해야 합니다. 대본이 아직 변동 중일 때 노드와 영상을 먼저 처리하면, 방금 완료한 결과가 다시 만료되기 쉽습니다.
대본 수정 하나가 최종 작품까지 어떻게 전달되는가
구버전에서는 플레이어가 먼저 등록부를 조회한 뒤 물건을 넘길지 선택한다고 가정합시다. 신버전에서는 먼저 넘길지를 결정하고, 그 이후에야 확인할 기회가 생깁니다. 샷의 위치는 비슷할 수 있지만, 플레이어가 결정을 내릴 때 가진 정보는 이미 달라졌습니다.
첫 번째로 대본을 점검합니다: 새 순서가 플레이어에게 아직 안내되지 않은 위험을 지우게 하는가? 불확실성을 유지하려면 플레이어가 이해할 충분한 단서를 제공했는가?
두 번째로 스토리보드와 노드를 점검합니다: 선택지가 여전히 기존 샷 뒤에 나오는가? 버튼 문구가 플레이어가 이미 등록부를 봤다고 암시하지 않는가? 두 선택이 새 버전의 목표를 향하는가?
세 번째로 소재를 점검합니다: 기존 영상에 '방금 등록 시간이 맞지 않았어'가 나오면, 신버전에서 아직 얻지 못한 정보를 노출합니다. 화면이 재생되더라도 이 대사는 교체해야 합니다.
마지막으로 진입점에서 전체 경로를 걸어보며, 결말이 신버전 선택을 읽는지 확인합니다. 특정 샷 하나만 보아 문제가 없다는 것은 전체 경로의 인과가 올바르다는 증명이 아닙니다.
세 가지 결과를 각각 처리하기
계속 점검하며 재사용할 수 있는 내용: 장면 분위기, 변하지 않은 인물 외형,剧情 정보와 무관한 빈 샷. 그것이 의존하는 설정을 기록하고, 해당 설정이 여전히 성립하는지 확인합니다.
반드시改写하거나 교체해야 하는 내용: 새 행동과 충돌하는 대사, 삭제된 노드를 가리키는 선택지, 구 인물 상태가 나타나는 샷. 먼저 참조와 사실을 고치고, 그다음 다듬기를 고려합니다.
당장 판단할 수 없는 내용: 상태 관련 연기, 모호한 결말 피드백, 여러 경로가 공유하는 샷. 어떤 전제가 관련되는지 표시하고 관련 경로를 각각 플레이테스트합니다. 메인 라인 하나가 통과했다고 재사용 가능하다고 선언해서는 안 됩니다.
이 분류는 수동 검토 방법입니다. 단계가 어떻게 완료로 복구되는지, 어떤 소재를 다시 선택할 수 있는지는 워크벤치가 제공하는 작업에 따라 실행해야 하며, 모두 한 번에 재사용 확인하는 원클릭 기능이 있다고 가정해서는 안 됩니다.
수정 기록은 다른 사람이 이어서 작업할 수 있는 설명으로 쓰기
| 기록 항목 | 예시 |
|---|---|
| 수정 이유 | 확인을 선택 이후로 옮겨, 위험을 감수한다는 주제를 강화 |
| 변경 범위 | 대본 2장의 동작 순서와 관련 선택지 |
| 교체 필요 | 확인 결과를 미리 노출하는 대사와 샷 |
| 재검토 필요 | 두 경로의 결말 정보와 공유 샷 |
| 검수 결과 | 두 경로 모두 신버전 정보 순서대로 완료 |
| 납품 버전 | 새 내보내기 패키지 이름과 검수 완료 날짜 |
마지막 두 항목은 실제 검수 후에 작성해야 합니다. 실행 기록이 없으면 미검수로 유지하며, '수정 준비됨'을 '통과함'으로 쓰면 안 됩니다.
여러 사람이 번갈아 한 프로젝트를 처리할 때는 기록에 누가 대본을 맡는지, 누가 소재를 맡는지, 누가 플레이테스트를 맡는지도 밝혀야 합니다. 이는 업무 인수인계이며, 제품이 실시간 다인 협업 편집을 이미 제공한다는 뜻이 아닙니다.
다시 플레이테스트하고, 다시 납품하기
구 내보내기 패키지는 클라우드 대본이 수정되었다는 이유만으로 최신 납품물로 간주될 수 없습니다. 스토리보드, 노드, 소재가 일치하는지 확인한 뒤 영향을 받은 경로를 다시 플레이테스트하고, 선택 이전 정보, 즉각 피드백, 결말을 점검한 다음 새 패키지를 생성합니다.
DramaFork의 창작 흐름은 단계별 점검과 계속 수정을 강조합니다. 가장 실용적인 방법은 이 영향 표를 프로젝트의 변경 기록과 함께 두는 것입니다. 상류를 수정할 때마다 어떤 결과를 점검했고, 무엇이 아직 남아 있으며, 외부에는 어느 버전을 사용해야 하는지 설명할 수 있습니다.


