TL;DR
문구표와 디자인 파일이 다르면 어느 쪽이 맞는지 제작사가 추측하게 두지 마세요.
정확한 문자열의 기준 원본과 실제 배치된 제작 파일의 역할을 나누어 정합니다.
최종 승인은 두 자료가 일치한 상태에서 해야 합니다.
문구 원본을 정해도 도안 검토는 남습니다
문구표에는 회사명이 맞게 적혀 있는데 디자인 파일에는 옛 표기가 남을 수 있습니다. 반대로 디자인에서 승인한 줄바꿈이나 강조가 문구표에는 반영되지 않을 수 있습니다. 두 문서가 같은 정보를 다른 형태로 담고 있다는 사실을 인정하고 각각 무엇의 기준인지 정해야 합니다.
문구표는 정확한 글자·숫자·기호를 확인하는 기준으로, 디자인 파일은 그 내용이 실제 어디에 어떻게 배치됐는지 확인하는 기준으로 둘 수 있습니다. 어느 한쪽을 우선한다고 적는 것만으로 둘의 불일치가 해결되지는 않습니다. 제작 시작 전에 차이를 해소하는 절차가 필요합니다.
원고에는 위치 식별도 함께 적으세요
여러 면과 여러 품목에 문구가 들어가면 문장 목록만으로는 배치 대상을 찾기 어렵습니다. 각 문구에 짧은 식별자를 붙여 품목·면·위치와 연결하세요. ‘작은 문구’나 ‘뒷부분’처럼 서로 다르게 해석할 수 있는 말보다 실제 도안에서 찾을 수 있는 이름이 좋습니다.
| 문구표 정보 | 확인할 내용 | 디자인에서 대조할 대상 |
|---|---|---|
| 문구 식별자 | 같은 문장을 찾는 기준 | 해당 품목과 면의 텍스트 |
| 확정 문자열 | 철자·기호·숫자 | 누락·대체·추가된 문자 |
| 배치 조건 | 줄바꿈 등 합의한 표현 | 읽는 순서와 위치 |
| 승인 버전 | 이번 제작의 확정본 | 실제 전달할 도안 버전 |
설명용 주석과 인쇄할 문구를 같은 칸에 넣지 않도록 주의하세요. 괄호 안의 말이 제작 지시인지 실제로 인쇄할 문자열인지 모호할 수 있습니다. 원고가 복사되어 배치되는 단계에서도 구분이 유지되게 양식을 정합니다.
자동 비교는 어디까지 도와줄까요?
2026년 10월 확인한 Microsoft Word의 문서 비교 안내는 두 문서의 차이를 별도 문서로 보여 주는 기능을 설명합니다. 이런 기능은 문구 버전 사이의 변경을 찾는 데 사용할 수 있지만, 도형으로 바뀐 문자나 실제 인쇄 배치까지 자동으로 검증한다고 볼 수는 없습니다.
문구가 윤곽선으로 변환됐다면 화면의 형태와 확정 문자열을 직접 대조해야 할 수 있습니다. 텍스트를 추출해 비교하는 경우에도 빠진 항목이나 읽는 순서가 달라진 것은 없는지 확인하세요. 비교 결과가 없다는 이유만으로 그림 속 문구까지 모두 같다고 승인하면 안 됩니다.
한 글자 수정은 어디에서 시작하나요?
정확한 문자열을 바꿀 권한이 있는 담당자가 문구표를 갱신하고 디자이너가 제작 파일에 반영합니다. 제작사가 발견한 오타라도 임의로 고친 뒤 넘기기보다 요청자에게 확인받는 편이 명확합니다. 고유명칭이나 의도한 표기일 수 있기 때문입니다.
수정 회신에는 해당 문구 식별자와 새 문자열을 적고, 도안 반영 뒤에는 어느 버전에 들어갔는지 남깁니다. 메신저로 보낸 수정 문장만 현재 기준으로 남아 있으면 다음 담당자는 옛 문구표를 사용할 수 있습니다. 수정한 원고와 디자인을 같은 승인 묶음으로 갱신하세요.
승인자가 마지막에 확인할 것은 무엇인가요?
문구를 처음 쓴 사람은 익숙한 내용으로 읽기 쉬우므로 다른 검토자가 실제 최종 파일을 확인하는 것이 좋습니다. 문장 전체뿐 아니라 이메일 주소·숫자·띄어쓰기·작은 각주도 대상에 포함합니다. 검토한 파일과 실제로 업체에 보내는 파일이 같은지 마지막으로 대조해야 합니다.
불일치를 발견했다면 어느 자료가 틀렸는지 확인하기 전 생산 지시를 내리지 않습니다. ‘문구표 우선’이라는 조건으로 제작사가 알아서 디자인을 고치게 두는 것보다, 바뀐 최종 도안을 다시 확인하는 편이 제작 결과를 구체적으로 합의할 수 있습니다.
마무리
문구와 배치는 서로 다른 기준 자료가 될 수 있지만 실제 제작 시점에는 같은 내용을 말해야 합니다. 클림은 기획·디자인·생산·검수·납품을 함께 맡으며, 원고와 제작 파일의 대조 범위는 상담에서 논의할 수 있습니다.
