외주 프로젝트에서 final_v3처럼 보이는 파일명을 받았다고 바로 작업 기준으로 삼으면, 나중에 “그건 중간본이었어요”라는 답을 들을 수 있습니다. 파일명은 식별자일 뿐 승인 기록은 아닙니다.
작은 팀이라면 새 도구를 만들기 전에 승인 로그 한 줄을 남기는 것부터 시작해 보세요.
승인 로그의 4개 필드
| 필드 | 기록할 내용 |
|---|---|
| 파일 식별자 | 정확한 파일명과 보관 위치 |
| 수신 시점 | 언제, 어느 채널로 받았는지 |
| 승인 근거 | 누가 어떤 답장으로 기준을 확정했는지 |
| 적용 범위 | 어느 화면, 문서, 납품물에 적용하는지 |
예를 들어 “10월 11일 메일로 받은 시안_B.pdf, 고객 담당자가 같은 스레드에서 B 기준이라고 확인, 첫 화면 문구에 적용”처럼 씁니다. 파일명만 적으면 나중에 같은 이름의 파일이 다시 왔을 때 구분하기 어렵습니다.
상태를 먼저 분리하면 덮어쓰기가 줄어듭니다
수신한 파일을 곧바로 승인된 파일로 취급하지 말고, 받음 → 확인 필요 → 승인됨 → 대체됨의 상태를 구분합니다. 새 파일이 도착했을 때 기존 승인본을 삭제하지 말고 새 후보를 확인 필요 상태로 둡니다. 고객의 확정 답장이 오면 그때 적용 범위를 바꿉니다.
이 원칙은 디자인 시안뿐 아니라 가격표, 정책 문구, 번역본, 데이터 내보내기 파일에도 통합니다. 다만 파일에 민감한 정보가 있다면 공개 협업 보드에 원본을 붙이지 말고 접근 권한이 제한된 보관 위치만 기록하세요.
고객에게 보낼 확인 질문
A([파일명], [수신 날짜])와 B([파일명], [수신 날짜])에서 [차이]가 확인됩니다. 이번 [적용 범위]는 어느 파일을 기준으로 진행할까요? “A 기준”, “B 기준”, 또는 “새 파일 전달 예정” 중 하나로 답해 주시면 됩니다. 기준 확인 전에는 해당 부분을 보류하고 영향이 없는 작업은 계속하겠습니다.
회신 뒤에는 “B([정확한 파일명])를 [적용 범위]의 기준으로 삼겠습니다”라고 한 줄로 다시 남깁니다. 이 확인 메일의 URL이나 메시지 ID를 승인 근거 필드에 연결하면, 다음 버전이 도착했을 때도 결정의 출처를 찾을 수 있습니다.
핵심은 파일 버전을 많이 만드는 것이 아니라, 어떤 버전이 승인됐는지 재현 가능하게 남기는 것입니다. 여러분은 고객 파일의 승인 근거를 어디에 기록하시나요?
