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

만들고.플레이하세요.

크리에이터 블로그

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

DramaFork 스토리보드에 동작 하나가 빠졌는데, 왜 뒤의 소재가 안 맞을 수 있을까?

스토리보드에서 동작이 빠졌을 때는 먼저 앞 샷의 출구와 뒤 샷의 입구를 대조할 수 있다. 예를 들어 샷 7이 끝날 때 종이배가 아직 린완의 손에 있었는데 샷 8이 시작될 때는 이미 탁자 위에 있다면, 그 사이에 종이배를 내려놓는 동작이 없다. 작성자는 이번 이동을 보충한 뒤 노드와 영상이 예전 설명을 그대로 쓰고 있는지 확인해야 한다. 뒤 샷의 글자만 고친다고 해서 이미 완성된 클립도 함께 바뀌었다고 증명할 수는 없다.

D
DramaFork Editorial Team인터랙티브 스토리텔링과 AI 제작
2026.09.25예상 읽기 시간: 6분
캐릭터가 빈 탁자 위에 종이배를 내려놓아 인접한 스토리보드 샷 사이에서 빠진 동작을 채우는 장면.
목차
크리에이터 블로그
  1. 01개요
  2. 02먼저 빠진 항목이 어느 층까지 전달되는지 보자
  3. 03종이배 사례로 샷 앞뒤 대조를 한 번 해 보자
  4. 04빠진 부분을 보충한 뒤, 의존 관계에 따라 하위를 점검하자
  5. 05완료 점검
글 맨 위로

개요

스토리보드에서 동작이 빠졌을 때는 먼저 앞 샷의 출구와 뒤 샷의 입구를 대조할 수 있다. 예를 들어 샷 7이 끝날 때 종이배가 아직 린완의 손에 있었는데 샷 8이 시작될 때는 이미 탁자 위에 있다면, 그 사이에 종이배를 내려놓는 동작이 없다. 작성자는 이번 이동을 보충한 뒤 노드와 영상이 예전 설명을 그대로 쓰고 있는지 확인해야 한다. 뒤 샷의 글자만 고친다고 해서 이미 완성된 클립도 함께 바뀌었다고 증명할 수는 없다.

아래에서는 가상의 교육용 예시로 전체 흐름을 한 번 따라가 본다. 예시에 나오는 프로젝트 이름, 캐릭터 이름, 숫자는 모두 지어낸 것으로, 점검 방법을 보여 주기 위한 것이지 실제 측정 자료가 아니다.

먼저 빠진 항목이 어느 층까지 전달되는지 보자

DramaFork의 창작 흐름은 아이디어, 기획, 대본, 스토리보드, 스타일, 캐릭터 소재, 인터랙션 노드, 영상, 플레이 가능한 미리보기, 내보내기 순이다. 스토리보드는 중간보다 뒤쪽에 있어서 아래로 노드, 영상, 미리보기, 내보내기에 영향을 준다. 즉, 스토리보드 표에서 동작 하나가 빠지면 그림 한 장만 빠지는 것이 아니라, 하위 여러 층이 완전한 정보를 받지 못하게 된다.

변경 위치 하위에서 점검해야 할 완료된 단계
기획 대본, 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기
대본 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기
스토리보드 노드, 영상, 미리보기, 내보내기
스타일 캐릭터, 영상, 미리보기, 내보내기
캐릭터 영상, 미리보기, 내보내기
노드 또는 영상 미리보기, 내보내기

이 표의 역할은 다음과 같은 점을 일깨우는 것이다. 스토리보드를 보충한 뒤에는 스토리보드 자체만 들여다보지 말아야 한다. 이미 완성된 노드와 영상이 예전 스토리보드를 참조하고 있다면, 업데이트 필요로 표시해야 한다. 예전 데이터는 대조하기 쉽도록 보존되지만, 그것이 새 버전에 그대로 쓸 수 있다는 뜻은 아니다.

종이배 사례로 샷 앞뒤 대조를 한 번 해 보자

가상 프로젝트 이름은 《종이배 야항》이고, 첫 막은 낡은 부두 당직실에서 벌어진다. 대본 노드에 적힌 내용은 다음과 같다.

  • 노드 A: 린완이 종이배를 들고 당직실에 들어와 탁자 위에 올려놓는다.
  • 노드 B: 린완이 천 아저씨에게 종이배에 적힌 서명을 아는지 묻는다.
  • 노드 C: 천 아저씨가 모른다고 말하고 몸을 돌려 창문을 닫는다.

그런데 스토리보드 초고에는 이렇게 적혀 있다.

  • 샷 7: 린완이 종이배를 들고 문을 밀고 들어오고, 탁자는 비어 있다.
  • 샷 8: 종이배가 이미 탁자 위에 있고, 린완이 앉는다.
  • 샷 9: 린완이 천 아저씨에게 종이배에 적힌 서명을 아는지 묻는다.

여기서 빠진 것은 대본에 이미 정해진 내려놓기 동작이다. 종이배가 손에서 탁자로 옮겨 가지만 그 이동이 표현되지 않았다. 샷을 보충할 때는 린완이 소유자라는 사실을 유지해야 하며, 화면을 이어 붙이기 위해 임시로 천 아저씨가 안방에서 종이배를 꺼내 오는 것으로 바꾸면 안 된다. 스토리보드 수정은 대본을 이행해야 하며, 정말로 소유자를 바꾸려면 먼저 대본으로 돌아가 새로운 인과를 확인해야 한다.

점검할 때는 먼저 샷 앞뒤 대조표를 하나 만든다. 각 행에는 샷 하나만 적고, 세 가지를 중점적으로 본다. 어느 대본 노드에 대응하는지, 입구 동작은 무엇인지, 출구 동작과 보이는 물건은 무엇인지.

샷 대응 노드 입구 동작 출구 동작 보이는 물건
7 A 문이 밀려 열림 린완이 자리 잡고 서고, 종이배를 들고 있음, 탁자는 빔 문, 탁자, 종이배
7 보충 A 린완이 자리 잡고 서고, 종이배를 들고 있음 린완이 종이배를 탁자 위에 올려놓음 문, 탁자, 종이배
8 A 종이배가 이미 탁자 위에 있음 린완이 앉음 탁자, 종이배, 의자
9 B 린완이 종이배를 바라봄 입을 열어 질문함 탁자, 종이배, 천 아저씨

‘7 보충’을 넣으면 그 샷의 출구는 ‘종이배가 탁자 위에 있음’이고, 샷 8의 입구도 같은 상태다. 만약 원래 샷 8에 이미 내려놓기 동작이 있었다면 새 샷을 추가할 필요가 없다. 먼저 실제 설명을 확인해서, 빠진 항목을 한 번 고치면서 중복을 만들지 않도록 해야 한다. 동작은 공용 샷에 넣을 수도 있고 별도 샷을 차지할 수도 있으며, 핵심은 출처와 이동이 분명한 것이다.

이 단계의 핵심은 입구와 출구가 반드시 이어져야 한다는 점이다. 앞 샷의 출구 물건은 뒤 샷의 입구 물건이 되어야 하고, 앞 샷의 출구 동작은 뒤 샷의 입구 상태가 되어야 한다. 한쪽이라도 맞지 않으면 중간에 한 칸이 빠졌거나, 어느 한 칸이 잘못 쓰였다는 뜻이다.

빠진 부분을 보충한 뒤, 의존 관계에 따라 하위를 점검하자

스토리보드를 고친 뒤에는 서둘러 모든 소재를 다시 생성하지 말자. 현재 의존 관계상 스토리보드 변경은 노드, 영상, 미리보기, 내보내기에 영향을 준다. 이렇게 할 수 있다.

  1. 노드 표를 열어 샷 7, 8, 9를 참조하는 인터랙션 노드를 찾고, 노드 설명 안의 동작과 물건이 이미 동기화되었는지 확인한다.
  2. 시스템이 관련 완료 단계에 표시하는 ‘업데이트 필요’ 알림을 보고, 자신의 검토 기록에 예전 노드와 예전 영상을 나열해 항목별로 대조한다.
  3. 플레이 가능한 미리보기에서 이 구간이 재생될 때 종이배가 올바른 시점에 나타나는지 확인한다.
  4. 내보내기 전에 로컬 소재 패키지와 원격 링크 패키지가 모두 업데이트된 버전을 가리키는지 확인한다.

여기에는 정밀한 의미 자동 차분도 없고, 한 번에 확인하는 재사용도 없다. 창작자는 이번 수정이 기존 소재의 어떤 표현을 바꾸었는지 사람이 직접 대조해야 한다. 단지 동작 하나를 보충한 것뿐이라면 샷 7과 8의 영상만 다시 만들어야 할 수 있다. 노드 설명도 바뀌었다면 미리보기와 내보내기도 함께 점검해야 한다.

완료 점검

빠진 부분을 보충한 뒤에는 아래 몇 가지로 마무리 점검을 한다.

  • 각 샷의 입구 동작은 앞 샷의 출구에서 찾을 수 있다.
  • 각 샷의 출구 물건은 다음 샷의 입구에서 찾을 수 있다.
  • 스토리보드에 등장하는 물건은 대본 노드에 출처가 있고, 갑자기 나타나지 않는다.
  • 이미 완성된 노드, 영상, 미리보기, 내보내기 중 예전 스토리보드를 참조하는 것은 모두 업데이트 필요로 표시되어 있다.
  • 예전 데이터는 여전히 보존되어 있어 수정 전후의 차이를 비교하기 쉽다.

이 몇 가지가 모두 맞으면 이번 보충으로 새로운 단절점이 남지 않았다는 뜻이다. 다음으로 현재 의존 관계에 따라 노드부터 시작해 영상, 미리보기, 내보내기를 층별로 점검할 수 있다. 이 글은 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.