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

만들고.플레이하세요.

크리에이터 블로그

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

자동 진행을 언제 멈출까: DramaFork 프로젝트에 세 가지 수동 검토 질문 설정하기

자동 진행은 이미 충분히 생각해 둔 부분을 빠르게 펼치는 데 적합하고, 일시 정지는 '재작업 비용이 여러 하위 단계로 번지는' 위치에만 둡니다. 두 사람 소규모 팀이라면 검토 지점을 세 개만 두는 것을 권합니다: 기획 확정 전, 시나리오에서 스토리보드로 넘어가기 전, 고비용 영상 일괄 생성 전. 각 검토 지점에서는 질문 하나만 답하고, 답이 끝나면 통과시키거나 되돌리며, 모든 단계를 확인하도록 요구하지 않습니다.

D
DramaFork Editorial Team인터랙티브 스토리텔링과 AI 제작
2026.09.27예상 읽기 시간: 7분
제작 흐름이 기획, 시나리오, 고비용 소재 전에 세 개의 검토 등을 지난다.
목차
크리에이터 블로그
  1. 01들어가며
  2. 02검토 지점 1: 기획 확정 전, '캐릭터 경계가 못 박혔는가' 묻기
  3. 03검토 지점 2: 시나리오에서 스토리보드로 넘어가기 전, '핵심 노드의 선택지가 모두 상태를 바꾸는가' 묻기
  4. 04검토 지점 3: 고비용 영상 일괄 생성 전, '이번 소재 묶음이 모두 확정된 캐릭터와 스타일에 의존하는가' 묻기
  5. 05세 검토 지점 대조
  6. 06이견 기록과 완료 점검
글 맨 위로

들어가며

자동 진행은 이미 충분히 생각해 둔 부분을 빠르게 펼치는 데 적합하고, 일시 정지는 '재작업 비용이 여러 하위 단계로 번지는' 위치에만 둡니다. 두 사람 소규모 팀이라면 검토 지점을 세 개만 두는 것을 권합니다: 기획 확정 전, 시나리오에서 스토리보드로 넘어가기 전, 고비용 영상 일괄 생성 전. 각 검토 지점에서는 질문 하나만 답하고, 답이 끝나면 통과시키거나 되돌리며, 모든 단계를 확인하도록 요구하지 않습니다.

아래에서는 가상의 교육용 예시를 하나로贯穿합니다: 두 사람 팀 '회등조'가 인터랙티브 영화 게임 《안개항 우편배달부》를 만들고, 구성원은 작가 아란과 아티스트 라오저우입니다. 예시 속 대화, 숫자, 결론은 방법을 설명하기 위해 지어낸 것이며, 실제 측정 자료가 아닙니다.

검토 지점 1: 기획 확정 전, '캐릭터 경계가 못 박혔는가' 묻기

기획 단계에서는 캐릭터의 정체성, 목표, 필요, 비밀, 초기 관계, 아크와 경계가 나옵니다. 앞의 세 항목은 보통 빨리 쓰지만, 놓치기 쉬운 것은 경계입니다: 이 캐릭터는 절대 무엇을 하지 않는가, 무엇을 알지 못하는가, 무엇 때문에 입장을 바꾸지 않는가. 경계를 못 박지 않으면 뒤에서 시나리오가 계속 그를 위해 이유를 만들어 줍니다.

회등조의 기획에서 주인공 우편배달부 아쉬의 목표는 '마지막 편지를 수신인 손에 전하는 것', 필요는 '자신이 없어도 그만인 사람이 아니라는 인정', 비밀은 '그가 죽은 편지 한 통을 몰래 뜯어본 것'입니다. 아란이 처음 쓴 경계는 '무고한 사람을 해치지 않는다' 한 줄뿐이었습니다. 라오저우는 검토할 때 물었습니다: 수신인이 바로 그때 그 죽은 편지의 발신인이라면, 아쉬는 다시 편지를 뜯을까? 아란은 그렇다고, 하지만 그건 극의 클라이맥스이지 일상 행동은 아니라고 답했습니다.

그래서 경계는 두 줄로 바뀌었습니다: 일상에서는 편지를 뜯지 않는다; 수신인이 죽은 편지와 직접 관련이 있다고 확인된 경우에만 뜯고, 뜯은 뒤에는 반드시 플레이어가 대가를 보게 해야 한다. 이 수정은 10분밖에 걸리지 않았지만, 시나리오 단계까지 남겨 두었다면 아쉬가 등장하는 모든 장면을 다시 써야 했을 것입니다.

통과 조건: 모든 주요 캐릭터의 경계를 '하지 않는다……除非……' 구문으로 쓸 수 있다. 되돌림 조건: 경계에 형용사만 있고 구체적 행동이 없다. 이견 기록은 한 줄이면 충분합니다. 예를 들어 '라오저우: 아쉬의 편지 뜯기 동기가 부족하다고 봄, 아란은 보류, 시나리오 단계에서 다시 검증'.

검토 지점 2: 시나리오에서 스토리보드로 넘어가기 전, '핵심 노드의 선택지가 모두 상태를 바꾸는가' 묻기

시나리오가 스토리보드로 들어간다는 것은 글이 촬영 가능한 화면과 인터랙션 노드로 바뀐다는 뜻입니다. 노드는 DramaFork에서 표로 조직되며 드래그 그림이 아니므로, 각 선택지가 상태 변화에 대응하는 것이 가장 좋습니다. 그렇지 않으면 스토리보드가 이후에 영향을 주지 않는 예쁜 장면만 잔뜩 찍게 됩니다. 이 글은 DramaFork가 정리했으며, 현재 프로젝트 구현에 따라 설명합니다: 시나리오를 바꾸면 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기와 내보내기에 영향을 주고, 완료된 단계는 업데이트 필요로 표시되며, 이전 데이터는 보존되지만 시스템이 이전 소재의 표현이 여전히 성립하는지 대신 판단해 주지는 않습니다.

회등조는 《안개항 우편배달부》 3막에 선택지 세 개를 두었습니다: 편지를 부두 관리인에게 넘긴다, 편지를 태운다, 직접 뜯는다. 아란은 처음에 세 선택지 모두에 서로 다른 대사를 썼지만, 상태 변화는 '편지를 뜯었는가' 하나뿐이었습니다. 라오저우는 관리인에게 넘기기와 태우기가 이후 스토리보드에서 차이가 없으니 선택지 두 개를 헛되이 만든 셈이라고 지적했습니다.

고치는 방법은 세 선택지가 각각 다른 상태를 바꾸게 하는 것입니다: 관리인에게 넘기기는 '아쉬와 항구 세력의 관계'를 바꾸고, 태우기는 '아쉬의 죽은 편지에 대한 태도'를 바꾸며, 뜯기는 '비밀이 드러났는가'를 바꿉니다. 그래야 스토리보드에 촬영 가능한 세 가지 화면 차이가 생깁니다.

통과 조건: 각 핵심 선택지가 이후에 참조될 상태를 최소 하나 바꾼다. 되돌림 조건: 선택지가 대사만 바꾸고 상태는 바꾸지 않는다. 이 단계는 문장 하나하나를 심사할 필요는 없고, 스토리보드로 들어갈 노드만 심사합니다.

검토 지점 3: 고비용 영상 일괄 생성 전, '이번 소재 묶음이 모두 확정된 캐릭터와 스타일에 의존하는가' 묻기

영상 생성은 보통 텍스트보다 비싸므로, 일시 정지는 일괄 제출 전에 둡니다. 판단 기준은 '화면이 예쁜가'가 아니라 '이번 영상들이 의존하는 캐릭터 설정과 스타일이 아직 바뀔 수 있는가'입니다. 캐릭터 경계나 스타일이 아직 수정 중이라면, 먼저 한두 개 시험 영상을 만들고 한 번에 다 깔지 마세요.

회등조는 부두 전경, 우편배달부 달리기, 편지 뜯기 클로즈업 세 가지 영상을 생성하려 합니다. 아란은 방금 아쉬의 경계를 고쳤고, 라오저우의 스타일 시안도 '차가운 회색'에서 '차가운 회색에 따뜻한 노란 가로등 추가'로 조정했습니다. 두 사람은 먼저 편지 뜯기 클로즈업만 생성하기로 했습니다. 이 장면이 캐릭터 표정과 스타일에 동시에 의존하기 때문입니다. 시험 영상이 나온 뒤 라오저우는 따뜻한 노란 가로등이 클로즈업에서 얼굴을 빼앗는다는 것을 발견하고, 스타일을 다시 차가운 회색 위주로 바꿨습니다. 세 가지를 함께 생성했다면 부두 전경과 달리기도 다시 만들어야 했을 것입니다.

통과 조건: 이번 영상들이 의존하는 캐릭터, 스타일, 노드가 모두 확정되었고, 시험 영상으로 표현 방향을 확인했다. 되돌림 조건: 의존 항목 중 하나라도 아직 수정 중이거나, 시험 영상이 예상과 크게 다르다. 실패한 소재 작업은 개별적으로 다시 시도할 수 있고, 전체 묶음을 처음부터 다시 할 필요는 없습니다.

세 검토 지점 대조

검토 지점 답할 질문 하나 통과 되돌림
기획 확정 전 캐릭터 경계가 못 박혔는가 경계를 '하지 않는다……除非……'로 쓸 수 있다 경계에 형용사만 있다
시나리오에서 스토리보드로 넘어가기 전 핵심 선택지가 상태를 바꾸는가 각 선택지가 이후 상태를 최소 하나 바꾼다 선택지가 대사만 바꾼다
영상 일괄 생성 전 의존 항목이 모두 확정되었는가 캐릭터, 스타일, 노드가 확정되고 시험 영상도 통과 의존 항목 중 하나라도 아직 수정 중

이견 기록과 완료 점검

이견 기록은 세 열만 쓰는 것을 권합니다: 누가 제기했는가, 어느 단계를 겨냥했는가, 보류인가 검증 대기인가. 회등조의 기록에는 '라오저우: 아쉬의 편지 뜯기 동기 부족, 아란은 보류, 시나리오 단계에서 다시 검증'이라는 항목이 하나 있습니다. 시나리오 단계에서도 여전히 성립하지 않으면 스토리보드에서 억지로 메우지 말고 검토 지점 1로 돌아가 경계를 고쳐야 합니다.

완료 점검은 이렇게 물을 수 있습니다: 세 검토 지점이 모두 질문 하나만 물었는가; 각 되돌림 조건이 고쳐야 할 그 자료를 바로 가리킬 수 있는가; 이견 기록에 다음 단계에서 처리되지 않은 '검증 대기' 항목이 남아 있는가. 세 답이 모두 긍정이면 자동 진행을 계속 돌려도 됩니다; 하나라도 부정이면 그 단계에 먼저 멈추고, 하위 소재로 상위의 모호함을 메우지 마세요.

작은 행동: 현재 프로젝트의 기획이나 시나리오를 열고, 주요 캐릭터 하나를 골라 '하지 않는다……除非……'로 경계를 한 줄 써 보고, 그것이 어떤 선택지가 존재해야 하는지 바로 판단할 수 있는지 보세요.

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

계속 읽기

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