대본 변경 로그는 수정이 끝난 뒤 적는 회고 문서가 아닙니다. 변경 요청이 들어온 순간부터 후보 상태, 검토, 승인, 공식본 배포와 수신 확인을 연결하는 통제 문서입니다. 파일명만 관리하면 “무엇이 왜 바뀌었는지”와 “어느 부서가 다시 움직여야 하는지”를 놓치기 쉽습니다.
1. 변경 요청이 들어온 순간 행을 만든다
승인된 변경만 기록하면 검토 과정에서 사라진 안과 이미 준비에 영향을 준 요청을 추적하기 어렵습니다. 요청 시각, 요청자, 기준 대본 버전, 변경 위치와 요청 이유를 먼저 적고 상태를 ‘요청’으로 둡니다.
요청자는 사람 이름만 쓰기보다 역할을 함께 표시합니다. 예를 들어 “연출 / S#18 장소 제약 반영 요청”처럼 적으면 이후 판단 책임과 맥락을 이해하기 쉽습니다.
2. 변경 전후를 한 행에서 비교한다
“대사 수정”처럼 요약만 쓰지 말고 변경 전과 변경 후를 분리합니다. 긴 원문 전체를 공개 로그에 복사할 필요는 없습니다. 씬·페이지·콘티 컷처럼 위치를 식별하고, 행동이 달라지는 핵심 차이를 짧게 기록하세요.
| 요청·기준 | 변경 전 → 후 | 영향·승인 | 공식본·수신 |
|---|---|---|---|
| 7/25 18:10 연출 기준 v06 · S#18 |
카페 회의 → 사무실 회의 대사 2줄 삭제 |
미술·조명·차량 제작 검토 → 연출 승인 21:18 |
v07 · 21:34 배포 미술 21:38 / 조명 21:40 / 차량 21:42 |
가상 예시입니다. 실제 프로젝트에서는 민감한 원문 대신 필요한 식별 위치와 업무 영향만 공유할 수 있습니다.
3. 영향 부서를 ‘다시 해야 할 일’로 적는다
부서명만 체크하면 무엇을 확인해야 하는지 다시 물어야 합니다. 변경으로 생기는 행동을 함께 적으세요.
- 미술: 사무실 세트 배치와 모니터 화면 준비
- 조명: 창문 암막과 프리라이트 시작 시각 재확인
- 차량: 카페 이동 취소, 사무실 주차 대수 변경
- 의상·분장: 씬 순서 변경에 따른 연속성 재확인
- 제작: 대관·콜타임·식사·회사 이동 반영
4. 요청·검토·승인·배포 상태를 분리한다
‘수정됨’은 촬영 기준이라는 뜻이 아닙니다. 요청, 검토, 승인, 배포, 사용 중지 상태를 구분하고 각 전환의 책임자와 시각을 기록합니다. 승인된 내용이 파일과 일정·콜시트에 반영되기 전에는 ‘배포 완료’로 바꾸지 않습니다.
5. 적용 버전과 공식 파일명을 연결한다
변경 행에는 실제 적용된 대본 버전과 공식 파일명을 연결합니다. 파일명 규칙은 대본 버전 혼선을 막는 파일명·배포·승인 규칙처럼 프로젝트·회차·문서 종류·버전·배포 시각을 일정하게 사용하세요.
6. 배포 대상과 수신 확인을 영향 범위에 맞춘다
모든 사람에게 같은 알림을 보내기보다 변경의 영향을 받는 부서 책임자를 배포 대상으로 지정합니다. 공식 채널과 배포 시각, 확인 시각을 남기고 개인 메시지로 전달된 추가 지시는 변경 로그에 다시 모읍니다.
7. 롤백 기준과 이전 버전의 상태를 남긴다
장소 승인 취소나 출연 조건 변경처럼 새 안을 사용할 수 없을 때 어느 버전과 계획으로 돌아갈지 정합니다. 이전 파일을 삭제하지 말고 사용 중지 상태와 최신본 링크를 표시하세요. 이미 내려받은 문서까지 회수할 수 없기 때문입니다.
변경 로그의 목표는 수정 횟수를 세는 것이 아니라, 변경이 어떤 행동을 만들었고 누가 공식본을 확인했는지 증명하는 것입니다.
대본 변경 로그에 관해 자주 묻는 질문
승인되지 않은 변경도 기록해야 하나요?
기록하되 상태를 요청 또는 검토로 명확히 표시하세요. 승인 전 후보가 촬영 기준으로 오해되지 않도록 공식본과 시각적으로 구분해야 합니다.
메신저 대화가 남아 있으면 로그가 필요 없나요?
메신저는 결정 위치가 흩어지고 새 참여자가 맥락을 찾기 어렵습니다. 공식 로그에는 결정에 필요한 핵심 정보와 원문 위치를 모으고, 민감한 대화 원문은 권한이 제한된 곳에 보관하세요.
변경 로그와 대본 파일은 어디에 보관해야 하나요?
공식본을 찾는 프로젝트 공간 하나를 정하고, 로그의 적용 버전에서 해당 파일로 이동할 수 있게 연결하세요. 개인 드라이브나 마지막 메신저 첨부파일을 기준으로 삼지 않는 것이 중요합니다.
