인쇄소 입고 데이터 점검과 견적을 생성형 AI로 단축하는 실무 절차
재단 여백 누락이나 검정 설정 실수로 재인쇄… 인쇄소의 입고 데이터 확인과 견적 회신을, Claude Code에 맡길 부분과 사람이 판단할 부분으로 나눠 단축하는 절차를 정리했습니다.
금요일 저녁, 거래처에서 “이대로 진행해 주세요”라며 PDF가 도착했습니다.
저(그리고 함께 일하는 인쇄소 현장)가 자주 겪는 건, 바쁜 금요일일수록 사고가 터지는 패턴입니다. 얼핏 보면 깔끔한 전단지. 재단 여백도 있는 것처럼 보였습니다. 월요일에 찍어 보니 재단된 가장자리에 흰 줄이 떴습니다. 자세히 보니 재단 여백이 2mm밖에 없었고, 그것도 가장 눈에 띄는 사진 가장자리였습니다. 거래처는 “데이터대로 보냈는데”라고 하고, 이쪽은 이미 찍어 버렸습니다. 누구 탓이냐를 따지기 전에, 종이와 잉크와 시간이 이미 사라졌습니다.
입고 데이터 점검과 견적 회신. 이 두 가지는 인쇄소의 이익을 조용히 깎아 먹는 자리입니다. 오늘은 이 부분을 생성형 AI(Claude Code)에게 잡일로 맡기고, 사람은 판단만 하는 형태로 다시 짠 이야기를 적습니다.
핵심 요약
- 입고 점검과 견적 회신은 사람의 집중력에 기대면 금요일 저녁에 반드시 무너진다. 이 자리를 기계 문지기로 받는다.
- Claude에게 맡기는 건 “읽기·골라내기·정렬하기·초안 쓰기”까지. 최종 OK와 색 교정, 가격의 최종 결정은 사람이 쥔다.
- 그대로 쓸 수 있는 프롬프트 양식, 입고 점검 체크리스트, 견적 회신 템플릿, PDF 형식을 기계로 점검하는 검증 스크립트를 실었다.
- 하루 20건의 견적이라면 회신 초안만으로 월 20시간 안팎이 절약되는 계산. 재인쇄 1회를 막으면 종이값만으로 수만 원.
- 입고 데이터에는 개인정보나 미공개 상품정보가 들어간다. AI에 넘기기 전 가리는 법과 외부 전송 규칙을 먼저 정한다.
먼저 독자상. 누구를 위한 이야기인가
상정하는 건 소~중규모 인쇄소에서 영업도 겸하는 DTP 오퍼레이터입니다. Illustrator·InDesign·PDF를 매일 다루고, 견적도 직접 회신합니다. 혼자서 입고 접수부터 색 교정 수배까지 돌리는 사람입니다.
이런 현장에는 도구를 늘릴 여유가 없습니다. 새 시스템을 도입하는 결재도, 익힐 시간도 없습니다. 그래서 “지금 있는 PDF와 엑셀 그대로, 확인 누락만 줄이고 싶다”가 본심이라고 생각합니다. 이 글도 거기에 맞춥니다. 거창한 기간 시스템 이야기는 하지 않습니다.
인쇄소의 입고~납품 흐름을, 일단 늘어놓는다
맡길 자리를 정하려면 자기 일을 공정으로 쪼개는 게 먼저입니다. 대개 이렇게 되어 있을 겁니다.
| 공정 | 할 일 | 사고가 나기 쉬운 곳 |
|---|---|---|
| 1. 수주·청취 | 사이즈, 부수, 종이, 가공, 납기를 듣는다 | 빠뜨림. 뒤늦은 “양면이었어요” |
| 2. 견적 | 부수별 단가, 판비, 가공비를 계산해 회신 | 계산 실수, 회신 지연으로 수주 실패 |
| 3. 입고 접수 | 거래처에서 데이터를 받는다 | 구버전 입고, 폰트 미포함 |
| 4. 데이터 점검 | 재단 여백, 해상도, 색, 재단선, 글자 깨짐 | 누락으로 인한 재인쇄 |
| 5. 교정·색 교정 | 거래처에게 확인받는다 | OK라는 확답이 애매함 |
| 6. 제판·인쇄·가공 | 실제로 찍는다 | 앞 공정의 실수가 여기서 드러남 |
| 7. 발송·청구 | 납품하고 청구 | 수량 착오 |
생성형 AI가 효과를 내는 건 2번 견적 초안과, 4번 데이터 점검의 1차 접수입니다. 5번 색 교정과 6번 이후는 기계에 넘기지 않습니다. 이유는 뒤에 적습니다.
자주 생기는 재작업과, 그 정체
재인쇄가 되는 패턴은 매번 대개 같은 얼굴들입니다.
- 재단 여백(재단선 바깥 여백)이 부족해 재단 후에 흰 줄이 뜬다
- 이미지 해상도가 낮다. 웹에서 가져온 72dpi 사진을 그대로 입고
- 검정 면이 리치 블랙으로 되어 있어, 판 어긋남으로 글자가 초록이나 빨강으로 번진다
- 폰트가 포함되지 않아, 다른 PC에서 열면 다른 서체로 바뀐다
- RGB 그대로 입고되어, 인쇄에서 색이 칙칙해진다
- 재단선이 없거나, 완성 사이즈가 지정과 다르다
까다로운 건 이게 전부 “얼핏 봐서는 알 수 없다”는 점입니다. 사람 눈으로 하나씩 골라내는 건 가능하지만, 금요일 저녁에 10건이 오면 집중력이 버티지 못합니다. 기계가 어울리는 지루한 확인의 전형입니다.
Use case 1: 입고 전 1차 점검을 기계에게 시킨다
사람이 하면 놓치는 항목을, 체크리스트로 만들어 AI에게 먼저 돌리게 합니다. 노림수는 “사람의 최종 확인을, 처음부터 전 항목 보는 작업에서, AI가 빨간 표시를 한 곳만 확인하는 작업으로 바꾸는” 것입니다.
아래 체크리스트를, 입고할 때마다 돌려 씁니다.
- 완성 사이즈가 지정과 일치하는가
- 재단 여백이 상하좌우 3mm 이상 있는가
- 배치 이미지의 실효 해상도가 실측 크기에서 300dpi 이상인가
- 컬러 모드가 CMYK인가(RGB 혼재가 없는가)
- 글자(특히 작은 검정 글자)가 K100 단색인가, 리치 블랙이 아닌가
- 폰트가 모두 포함, 또는 윤곽선 처리되어 있는가
- 재단선·센터 재단선이 있는가
- 페이지 수·터잡기 방향이 지정대로인가
- 투명 효과나 오버프린트의 의도하지 않은 설정이 없는가
PDF 속성이나 프리플라이트 결과 텍스트를 AI에 넘기고, 이 리스트로 대조시키면 빠진 줄을 그대로 짚어 줍니다.
Use case 2: 견적 회신 초안을 30초로 만든다
견적은 계산 그 자체보다 “회신 쓰기가 귀찮아 뒤로 미뤄지는” 것이 수주 실패의 원인입니다. 청취 내용을 항목별로 넘기기만 하면, 정중한 회신문 초안을 내게 합니다.
가격표(단가 로직)는 자사의 것을 AI에게 가르쳐 둡니다. 계산의 최종 확인은 사람이 하지만, 문면과 항목의 배열은 AI에게 맡겨도 됩니다.
Use case 3: 문의 메일에서, 빠뜨린 질문을 가려낸다
거래처의 문의는 대개 정보가 부족합니다. “명함을 100장 부탁합니다”만 옵니다. 여기서 “단면/양면은? 용지는? 납기는?”을 되물을 질문 리스트를, AI에게 먼저 만들게 합니다.
물어야 할 것의 누락이 줄어, 견적의 재작업이 줄어듭니다. 이건 수수하지만, 왕복 횟수가 한 번 줄기만 해도 반나절 빨리 마무리됩니다.
AI에게 맡길 범위와, 사람이 반드시 판단할 범위
여기가 제일 중요합니다. 선 긋기를 잘못하면, AI가 “자신만만하게 틀리는” 사고가 됩니다.
| 작업 | AI에게 맡긴다 | 사람이 판단한다 |
|---|---|---|
| 체크리스트 대조 | ○ 누락을 골라낸다 | 최종 OK의 판단 |
| 해상도·재단 여백 수치 읽기 | ○ 수치를 늘어놓는다 | 사진 가장자리가 눈에 띄는지 감각적 판단 |
| 견적 문면 초안 | ○ 문장을 쓴다 | 가격의 최종 결정, 할인 판단 |
| 빠뜨린 질문 만들기 | ○ 목록화 | 거래처와의 관계를 감안한 표현 |
| 색 교정·색의 최종 판단 | × | ◎ 사람 눈으로 반드시 |
| 인쇄기로의 송출 | × | ◎ 사람이 누른다 |
색만큼은 절대로 넘기지 않습니다. 모니터의 색과 잉크의 색은 별개이고, 종이나 날씨에 따라서도 변합니다. 여기는 베테랑 눈의 일입니다. AI는 “데이터상의 설정이 이상하지 않은가”까지만, 인쇄 결과의 좋고 나쁨은 판단시키지 않는다고 정해 두세요.
이 선 긋기의 사고방식은, 엔지니어가 아닌 사람이 AI를 어떻게 쓸지 적은 비엔지니어를 위한 Claude Code 이야기와 한 줄기입니다. 맡길 범위를 좁게 시작하는 게 요령입니다.
복사해 쓰는 프롬프트 양식
입고 점검의 1차 접수에 쓰는 프롬프트입니다. { } 안을 자기 안건으로 바꿔 주세요.
당신은 인쇄소의 베테랑 DTP 오퍼레이터입니다.
지금 넘길 입고 데이터의 정보를, 아래 체크리스트로 대조해 주세요.
[안건 정보]
- 완성 사이즈: A4(210×297mm)
- 용지·부수: 코트 90kg / 1000부
- 면: 양면 컬러
[체크리스트]
1. 완성 사이즈가 지정과 일치하는가
2. 재단 여백이 상하좌우 3mm 이상 있는가
3. 배치 이미지의 실효 해상도가 실측 300dpi 이상인가
4. 컬러 모드가 CMYK인가(RGB 혼재가 없는가)
5. 작은 검정 글자가 K100 단색인가(리치 블랙이 아닌가)
6. 폰트가 포함 또는 윤곽선 처리되어 있는가
7. 재단선이 있는가
[출력 규칙]
- 각 항목을 "OK / 확인 필요 / NG"로 판정하고, 이유를 한마디 덧붙인다
- 수치를 읽을 수 없는 항목은 "데이터 부족"이라 적고, 추측으로 채우지 않는다
- 마지막에, 거래처에 확인할 질문을 항목별로 낸다
“추측으로 채우지 마라” “데이터 부족은 데이터 부족이라 적어라”를 반드시 넣습니다. 이게 없으면 AI는 모르는 곳을 그럴듯하게 채워, 거짓 안심을 돌려줍니다. 프롬프트를 세밀하게 다듬는 법은 Claude Code 프롬프트 설계(응용)에 정리했습니다.
견적 회신 템플릿
회신 초안은 이 틀에 흘려 넣게 합니다.
{거래처명} 귀하
견적 의뢰 감사합니다. 아래와 같이 제안드립니다.
■ 사양
- 품목: {명함/전단지/책자 등}
- 사이즈: {사이즈}
- 용지: {종이 종류·평량}
- 부수: {부수}
- 가공: {PP/박/접지 등}
■ 금액(부가세 별도)
- 인쇄비: {금액}
- 판·데이터 조정비: {금액}
- 합계: {금액}
■ 납기
입고 확정 후 {영업일수} 영업일
데이터 점검 결과, {확인 사항이 있으면 기재}.
궁금한 점이 있으시면 편하게 알려 주세요.
실행할 수 있는 검증 스크립트
“재단 여백이 있는가”를 매번 PDF를 열어 재는 건 귀찮습니다. PDF의 페이지 사이즈(MediaBox / TrimBox)를 읽어, 재단선에서의 여백이 3mm 이상 있는지를 대충 판정하는 Node.js 스크립트를 둡니다. pdf-lib를 씁니다.
npm init -y
npm install pdf-lib
node check-bleed.mjs sample.pdf
import { PDFDocument } from "pdf-lib";
import { readFile } from "node:fs/promises";
const PT_PER_MM = 72 / 25.4; // 1mm = 약 2.835pt
const MIN_BLEED_MM = 3;
const file = process.argv[2];
if (!file) {
console.error("사용법: node check-bleed.mjs <PDF파일>");
process.exit(1);
}
const bytes = await readFile(file);
const pdf = await PDFDocument.load(bytes);
pdf.getPages().forEach((page, i) => {
const media = page.getMediaBox();
// TrimBox가 없으면 MediaBox를 완성 크기로 간주(재단 여백 없음일 가능성이 높음)
const trim = page.getTrimBox?.() ?? media;
const bleedPt = Math.min(
trim.x - media.x,
trim.y - media.y,
media.x + media.width - (trim.x + trim.width),
media.y + media.height - (trim.y + trim.height)
);
const bleedMm = bleedPt / PT_PER_MM;
const ok = bleedMm >= MIN_BLEED_MM - 0.05;
console.log(
`P${i + 1}: 재단 여백 약 ${bleedMm.toFixed(1)}mm -> ${ok ? "OK" : "확인 필요"}`
);
});
이걸로 전 페이지의 재단 여백이 목록으로 나옵니다. “확인 필요”가 뜬 페이지만, 사람이 Illustrator로 열어 보면 됩니다. 처음부터 전 페이지를 재는 것보다 압도적으로 빠릅니다. 이 스크립트는 어디까지나 1차 필터이고, 최종 판단은 사람이 한다는 전제입니다. 명령어 조작이 익숙하지 않다면 Claude Code 도입 가이드부터 시작하면 막히기 어렵습니다.
도입 전과 후로, 무엇이 바뀌었나
숫자로 대략 적습니다. 어디까지나 제 주변 소규모 인쇄의 체감값입니다.
| 항목 | 도입 전 | 도입 후 |
|---|---|---|
| 입고 1건의 점검 시간 | 약 15분 | 약 6분(빨간 곳만 확인) |
| 견적 회신 작성 | 약 12분 | 약 3분(초안을 고치기만) |
| 빠뜨림으로 인한 왕복 | 안건의 30% | 10% 미만 |
| 재인쇄 | 월 1~2회 | 거의 제로를 노린다 |
시간 절약을 ROI로 환산하면, 하루 20건의 견적에서 회신이 9분 짧아지면 하루 3시간, 월 60시간 규모. 보수적으로 봐도 월 20시간은 확실합니다. 거기에 재인쇄를 1회 막으면, 종이·잉크·기계 준비로 수만 원이 사라지지 않고 끝납니다. 새 소프트웨어를 사지 않았으니, 절약된 시간이 그대로 이익 쪽에 얹힙니다.
보안과 개인정보 주의점
이 부분을 건너뛰면 효율화는커녕 신용을 잃습니다. 인쇄소가 다루는 데이터는 거의 전부가 남의 기밀입니다.
- 명함·DM에는 이름, 주소, 전화번호 등 개인정보가 실립니다. 회원 명부 인쇄라면 더더욱 무겁습니다.
- 신상품 전단지는 출시 전 미공개 정보입니다. 새면 거래 중단도 있습니다.
- 그래서 AI에 넘기는 건 “사이즈·해상도·색 설정·재단 여백” 같은 형식 데이터에 한하고, 본문의 개인정보나 상품명은 가린 뒤에 넘깁니다.
- 검증 스크립트처럼 로컬에서 완결되는 처리는 데이터를 밖으로 내보내지 않아 안심도가 높습니다. 무거운 개인정보는 이쪽에서 처리합니다.
- 외부 AI 서비스에 보낼 경우, 입력이 학습에 쓰이지 않는 설정인지, 계약상 어떻게 다뤄지는지를 반드시 확인합니다. 사내 규칙을 한 장 만들어 둡니다.
선 긋기는 단순합니다. “거래처에 보여서 혼나지 않을 데이터인가”를 넘기기 전에 자문합니다. 망설여지면 넘기지 않습니다. 사내에서 무엇을 AI에 보여도 되는지 규칙 만들기는 CLAUDE.md 작성법의 사고방식을 응용할 수 있습니다. 프로젝트마다의 약속을 파일에 적어 두는 발상입니다. 일상 업무 속 시간 절약의 다른 예는 Claude Code 생산성 팁도 참고하세요.
PDF의 기술 사양 자체를 정확히 짚고 싶은 사람은, Adobe의 공식 정보(Adobe 공식 사이트) 등 1차 정보를 찾아보세요. 재단 여백이나 재단선의 권장값은 인쇄소마다 다르므로, 자사의 입고 규정이 최우선입니다.
자주 묻는 질문
Q. AI가 “OK”라고 한 데이터를 그대로 찍어도 되나요. 안 됩니다. AI의 판정은 1차 필터입니다. 특히 색과 사진 가장자리의 보임은 사람 눈으로 반드시 확인하세요. AI는 “데이터상 설정의 누락”을 골라낼 뿐, 인쇄 결과의 책임은 지지 못합니다.
Q. 우리 오퍼레이터는 명령어가 서툽니다. 검증 스크립트는 필수인가요. 필수는 아닙니다. 체크리스트와 프롬프트만으로도 효과가 있습니다. 스크립트는 “재단 여백을 매번 재는 게 귀찮다”는 사람을 위한 추가 장비입니다. 우선 프롬프트부터 시작하세요.
Q. 거래처의 개인정보를 AI에 읽혀도 괜찮나요. 원칙적으로 안 됩니다. 형식 데이터(사이즈·해상도·색)만 넘기고, 이름이나 주소는 가립니다. 본문을 읽히고 싶을 때는 외부로 전송되지 않는 로컬 방식을 쓰거나, 더미로 바꾼 뒤에 넘기세요.
Q. 견적 금액도 AI에 정하게 해도 되나요. 금액의 최종 결정은 사람이 합니다. AI는 자사의 가격표에 맞춰 초안을 만들 뿐. 할인이나 특급 요금의 판단은 관계를 아는 사람만 할 수 있습니다.
Q. 도입에 며칠 걸리나요. 체크리스트와 회신 템플릿을 정비하기만 하면 반나절입니다. 프롬프트를 자사의 입고 규정에 맞춰 1~2주 운용하며 고치면, 판정 정밀도가 현장에 익숙해집니다.
마무리: 판단은 놓지 않고, 지루함만 놓는다
입고 점검도 견적도, 귀찮은 건 “판단”보다 “골라내기와 받아쓰기”입니다. 그곳을 AI에게 대신시키고, 사람은 빨간 표시가 붙은 곳과, 색과, 가격만 봅니다. 역할을 이렇게 다시 나누면, 금요일 저녁이라도 사고가 줄어듭니다.
회사 전체로 입고 멈춤 방식이나 담당의 역할을 다시 보고 싶다면, 연수·상담에서 현장 흐름에 맞춘 구성을 함께 다듬을 수 있습니다. 우선 자기 손으로 시험해 보고 싶은 사람은 무료 PDF·교재에서 체크리스트와 프롬프트를 가져가세요.
실제로 시험한 결과
손에 있는 샘플 PDF를 몇 개 준비해, 위 검증 스크립트를 돌렸습니다. 재단 여백 0mm로 만든 한 장은 “P1: 재단 여백 약 0.0mm -> 확인 필요”라고 제대로 골라냈고, 3mm로 만든 판은 제대로 “OK”가 떴습니다. MediaBox만 가진 PDF는 재단 여백 없음으로 판정되므로, TrimBox를 가진 출력(재단선 포함 PDF/X)이 아니면 정확히 잴 수 없다는 한계도 그 자리에서 보였습니다.
입고 점검 프롬프트에는, 일부러 “해상도를 읽을 수 없는 정보”를 섞어 넘겨 봤습니다. 지시대로 추측으로 채우지 않고 “데이터 부족”이라 돌려준 게 수확이었습니다. 반대로, 리치 블랙인지 아닌지는 넘긴 텍스트 정보만으로는 다 판정할 수 없어, 여기는 결국 Illustrator를 열어 사람이 봐야 했습니다. AI에 넘길 수 있는 곳과, 눈으로 볼 수밖에 없는 곳의 경계가, 돌려 보고서야 비로소 또렷해졌습니다. 처음부터 전부 맡기려 하지 말고, 지루한 골라내기만 넘긴다. 이 거리감이 인쇄소 현장에는 딱 좋아 보입니다.
무료 PDF: Claude Code 치트시트
이메일을 입력하면 명령, 리뷰 습관, 안전한 워크플로를 정리한 PDF를 받을 수 있습니다.
개인정보를 안전하게 관리하며 스팸을 보내지 않습니다.
작성자 소개
Masa
Claude Code 실무 워크플로와 팀 도입을 검증하는 엔지니어입니다.
관련 글
제작사가 Claude Code에 고객 사이트를 맡기기 전 권한 체크리스트
고객 사이트를 안전하게 AI로 수정하기 위한 에이전시용 권한과 검증 절차입니다.
SaaS 고객지원 버그 신고를 Claude Code로 재현 절차로 바꾸는 방법
모호한 문의를 재현 단계, 증거, 개발자 전달 메모로 정리하는 지원팀 워크플로입니다.
Obsidian 묵은 메모를 Claude Code 지시서로 바꾸는 10분 루틴
Obsidian에 쌓인 메모가 매번 쓸모없어지는 분께. 사실·결정·미확인으로 분류해 Claude Code가 그대로 움직일 지시서로 바꾸는 아침 10분의 형(型)을 소개합니다.