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

만들고.플레이하세요.

크리에이터 블로그

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

DramaFork 기획 단계에서 서로 모순되는 요구를 어떻게 점검할까?

기획 단계에서 가장 흔히 생기는 문제는 각 요구를 따로 보면 합리적이지만, 함께 놓으면 서로 발목을 잡는다는 점이다. 점검 방법은 기획 표를 다시 채우는 것이 아니라 다섯 가지 요구를 뽑아 두 개씩 대조하는 것이다: 이야기 목표, 플레이어 정체성, 규모, 형식, 결말 약속. 방법은 먼저 이것들을 판단 가능한 짧은 문장으로 쓰고, 각 쌍마다 “이 두 가지가 동시에 성립할 수 있는가”를 묻고, 동시에 성립할 수 없는 것을 충돌 목록에 적고, 마지막으로 축소 방안으로 그중 하나를 바꾸는 것이지 다섯 가지를 모두 유지하는 것이 아니다.

D
DramaFork Editorial Team인터랙티브 스토리텔링과 AI 제작
2026.09.25예상 읽기 시간: 6분
고양이 편집자가 항구 회관 모형 옆에 놓인 작은 도시 모형들의 배치를 조정한다.
목차
크리에이터 블로그
  1. 01안내
  2. 02먼저 다섯 가지 요구를 판단 가능한 짧은 문장으로 쓴다
  3. 03두 개씩 대조해 동시에 충족할 수 없는 조합을 먼저 찾는다
  4. 04모순을 머릿속에 두지 말고 충돌 목록으로 쓴다
  5. 05두 가지 축소 방안
  6. 06완료 점검
글 맨 위로

안내

기획 단계에서 가장 흔히 생기는 문제는 각 요구를 따로 보면 합리적이지만, 함께 놓으면 서로 발목을 잡는다는 점이다. 점검 방법은 기획 표를 다시 채우는 것이 아니라 다섯 가지 요구를 뽑아 두 개씩 대조하는 것이다: 이야기 목표, 플레이어 정체성, 규모, 형식, 결말 약속. 방법은 먼저 이것들을 판단 가능한 짧은 문장으로 쓰고, 각 쌍마다 “이 두 가지가 동시에 성립할 수 있는가”를 묻고, 동시에 성립할 수 없는 것을 충돌 목록에 적고, 마지막으로 축소 방안으로 그중 하나를 바꾸는 것이지 다섯 가지를 모두 유지하는 것이 아니다.

아래에서는 가상의 교육용 예시로 전체 흐름을 따라간다. 예시 속 세계, 캐릭터, 숫자는 방법을 설명하기 위해 만든 것이며 실제 측정 자료가 아니다.

먼저 다섯 가지 요구를 판단 가능한 짧은 문장으로 쓴다

한 프로젝트를 《안개항 7일》이라고 가정하고, 초기 기획을 이렇게 썼다고 하자:

  • 이야기 목표: 플레이어는 7일 동안 안개항 결항의 진실을 밝히고, 공개할지 결정한다.
  • 플레이어 정체성: 신임 항만 기록원이며, 집행권이 없고 기록과 대화로만 진행할 수 있다.
  • 규모: 단일 장면 단편, 예상 플레이 시간 약 20분.
  • 형식: 인터랙티브 영상 게임, 대화 선택지와 소량의 조사 노드 중심; 초고에서는 각 장이 다섯 도시를 넘나든다고도 요구한다.
  • 결말 약속: 플레이어는 자신이 무엇을 바꿨는지 분명히 알 수 있고, 두 가지 이상의 결말을 본다.

이 다섯 문장은 모두 참·거짓을 판단할 수 있어 “미스터리, 몰입, 대입감”보다 훨씬 유용하다. 판단 기준은 다른 작가가 읽었을 때 어느 부분이 그것을 위반했는지 지적할 수 있는가이다.

두 개씩 대조해 동시에 충족할 수 없는 조합을 먼저 찾는다

대조할 때 5×5를 전부 나열할 필요는 없고, 가장 충돌하기 쉬운 세 그룹을 먼저 본다: 규모 대 형식, 정체성 대 목표, 목표 대 결말 약속.

대조 조합 요구 A 요구 B 동시 성립 가능 여부
규모 × 형식 단일 장면 단편, 20분 각 장이 다섯 도시를 넘나듦 불가
정체성 × 목표 집행권 없는 기록원 결항 진실을 밝히고 공개 여부 결정 가능하지만 진행 수단이 제한됨
목표 × 결말 약속 진실 규명 두 가지 이상 결말 가능, 공개 또는 비밀로 다른 결과 발생

첫 번째 행이 바로 이 문제에서 검출해야 할 전형적 모순이다. “단일 장면”은 공간 수를 제한하고, “각 장이 다섯 도시를 넘나듦”은 각 장마다 최소 다섯 장소를 요구하므로 둘은 동시에 충족될 수 없다. 이것은 창의성의 좋고 나쁨 문제가 아니라 수량상의 직접 충돌이다.

두 번째 행은 모순을 이루지 않지만 작성 방식을 바꾼다: 기록원은 집행권이 없으므로 “밝힌다”는 기록, 대화, 대조를 통해서만 완료할 수 있고 수색이나 체포로는 할 수 없다. 이 항목은 제약으로 적어야 하며, 각본 단계에서 갑자기 주인공이 문을 부수게 해서는 안 된다.

세 번째 행도 모순이 아니다. 동일한 확정된 진실은 공개, 비밀 유지, 또는 다른 대상에게 넘기는 것에 따라 다른 결말을 낳을 수 있다. 다중 결말은 서로 모순되는 여러 진실을 요구하지 않으며, 필요한 것은 플레이어의 결정과 가시적 결과 사이의 차이다.

모순을 머릿속에 두지 말고 충돌 목록으로 쓴다

충돌 목록은 네 열을 포함하는 것이 좋다: 충돌 번호, 관련 요구, 충돌 유형, 반드시 바꿔야 할 항목.

번호 관련 요구 충돌 유형 반드시 바꿔야 할 항목
C1 단일 장면 단편 × 각 장이 다섯 도시를 넘나듦 수량 충돌 규모를 바꾸거나 장소 수를 바꾼다
C2 20분 × 두 가지 이상 결말 분량 추정 필요, 직접 모순은 아님 단일 완전 경로 기준으로 시간 추정
C3 집행권 없음 × 공개 여부 결정 진행 경로 명확화 필요 플레이어가 자료를 누구에게 넘기는지 명확히 한다

C2는 위험 기록일 뿐이며 이미 입증된 충돌로 위장할 수 없다. 한 번의 플레이는 보통 하나의 결말에 도달하므로, 서로 배타적인 두 경로의 시간을 그대로 더할 수 없다. 먼저 각 경로의 대화와 영상 길이를 나열한 뒤 20분을 유지할 수 있는지 판단한다; 아직 추정하지 않았다면 먼저 결말을 잘라낼 필요는 없다.

C3도 “집행권이 없다”에서 곧바로 “소식을 공개할 수 없다”가 도출되지는 않는다. 작가는 이 작품의 전파 규칙을 따로 써야 한다: 예를 들어 공식 공고는 서장이 서명하고, 기록원은 자료를 서장이나 기자에게 넘길 수 있다. 이때 플레이어가 결정하는 것은 누구에게 넘길지, 넘길지 여부이지, 갑자기 공고 서명 권한을 얻는 것이 아니다. 규칙을 먼저 기획에 써야 이후 대사에 근거가 생긴다.

두 가지 축소 방안

경성 충돌 C1에 대해 두 가지 축소 방안을 제시한다; C2는 계속 추정하고, C3은 규칙을 보완한 뒤 판단하며, C1과 혼동하지 않는다.

방안 1: 단일 장면을 지키고 장소를 줄인다. “각 장이 다섯 도시를 넘나듦”을 “전편이 항만 대청에 집중”으로 바꾸고, 다섯 도시는 다섯 통의 편지로 조사 대상이 되며 더 이상 하나씩 보여주지 않는다. 이렇게 하면 공간 규모는 그대로이고 형식도 그대로이며, 대가는 여행으로 장면 전환을 할 수 없어 기록과 대화로 진행해야 한다는 점이다.

방안 2: 다섯 도시를 지키고 규모를 바꾼다. “단일 장면 단편”을 “다중 장면 작품”으로 바꾸고, 하나의 완전 경로 시간을 다시 추정한다. 장소는 유지되지만 소재 수량과 전환 작업이 늘어난다; 20분과 결말 수량 모두 재평가해야 하며, 추정하지 않은 채 원래 분량을 약속할 수 없다.

두 방안 모두 하류를 동시에 점검해야 한다: 기획을 바꾸면 각본, 스토리보드, 스타일, 캐릭터, 노드, 영상, 미리보기, 내보내기에 영향을 준다. 시스템은 의존성에 따라 관련 완료 단계를 “업데이트 필요”로 표시하고 기존 데이터는 보존한다; 창작자는 기존 소재 표현이 여전히 성립하는지 다시 확인해야 하며, 상태 표시를 구체적 충돌이 이미 해결되었다는 뜻으로 받아들여서는 안 된다.

완료 점검

수정한 뒤에는 같은 표로 다시 대조해 잔여 충돌이 없는지 확인한다:

  1. 다섯 가지 요구가 모두 판단 가능한 짧은 문장으로 쓰였는가.
  2. 각 충돌 쌍에서 둘 다 모호하게 남긴 것이 아니라 그중 하나만 바꿨는가.
  3. 변경된 요구가 스토리보드, 캐릭터, 노드 등 하류 설명에 이미 동기화되었는가.
  4. 결말 약속이 규모, 형식, 플레이어 정체성과 일치하는가.
  5. 충돌 목록에 “왜 이렇게 바꿨는가”에 대한 한 문장 이유가 남아 있는가.

2번을 못 지킨다면 아직 상호 배타적 요구를 동시에 유지하고 있다는 뜻이며, 각본 단계에서 다시 충돌한다.

이 글은 DramaFork가 정리했으며, 현재 프로젝트 구현 설명에 따른다: 기획은 검토 가능하고 편집 가능한 단계이며, AI가 보조로 진행할 수 있지만 모든 충돌을 자동으로 식별한다고 주장하지 않는다. 프롬프트 제약이 매번 올바른 출력을 보장하지 않으므로 충돌 목록과 축소 결정은 여전히 창작자가 스스로 판단해야 한다.

다음 행동: 현재 기획의 다섯 가지 요구를 각각 판단 가능한 한 문장으로 쓰고, 먼저 “규모 × 형식” 조합만 대조해 동시에 성립할 수 없는 항목을 표시하라.

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

계속 읽기

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