제록스 프리플로우 코어(FreeFlow Core)가 고객 PDF를 거부할 때 — 26개의 문제 파일이 접수 검사(Intake)에 대해 알려준 것

2026-10-17 · 고객 파일 접수 PDF 검사 프리플로우 프리플라이트 한컴 한글

제본 인쇄소의 하루는 고객이 보낸 PDF로 시작됩니다. 주문이 들어오면 고객은 원고를 PDF로 전달하고, 작업자는 이를 제록스 프리플로우 코어(Xerox FreeFlow Core)와 같은 인쇄 워크플로우에 투입합니다. 대부분의 파일은 문제없이 통과하지만, 일부 파일이 워크플로우에서 멈춰 서면서 문제가 발생합니다. 오류 대화상자에는 원인이 명확히 표시되지 않는 경우가 대부분입니다. 작업자는 파일을 열어 아크로뱃(Acrobat)에서 다시 저장해 보지만, 그래도 해결되지 않으면 결국 고객에게 전화를 걸게 됩니다.

본 글은 국내의 한 중형 제본 인쇄소 현장에서 실제로 문제를 일으킨 26개의 고객 PDF 파일을 분석한 기록입니다. 단 한 줄의 텍스트 색상을 변경하자마자 통과된 파일도 있었습니다. 어떤 경고는 심각해 보였지만 실제 인쇄 결과물에는 아무런 영향이 없었습니다. 어떤 파일은 어떤 도구로도 복구할 수 없어 고객에게 다시 요청해야만 했습니다. 접수 단계에서 파일들을 이 세 가지 그룹으로 분류하는 것이 바로 Pressria Bridge(PB) 1.6.0의 고객 파일 접수(Customer Intake) 기능이 수행하는 역할입니다.

인쇄 워크플로우는 표준 규격의 PDF를 전제로 합니다

FreeFlow Core와 같은 워크플로우는 인입된 PDF를 프리플라이트(사전 검사)하고, 폰트를 아웃라인(윤곽선)으로 변환한 뒤, 터잡기(Imposition) 및 출력 단계로 넘깁니다. 이 모든 과정은 PDF가 표준 규격에 맞게 제작되었다는 것을 전제로 합니다. 하지만 고객 PDF는 전문 디자인 프로그램에서만 생성되는 것이 아닙니다. 한컴 한글(HWP), 파워포인트, 워드, 스캐너 소프트웨어 등 다양한 프로그램에서 만들어집니다. 이들 중 일부는 규격상 허용되지만 특이한 구조를 사용하기도 하고, 아예 손상된 상태인 경우도 있습니다.

26개 파일에서 발견된 문제는 크게 세 가지 유형으로 나뉩니다.

수정 가능 — 단 하나의 구조나 속성이 워크플로우를 가로막고 있는 경우입니다. 원본은 그대로 보존하고 별도의 수정본을 생성합니다.
경고로 표시되지만 인쇄에는 무해함 — 작업자가 신경 쓸 필요가 없는 항목입니다. 이러한 경고가 지나치게 많으면 진짜 문제가 묻혀버리게 됩니다.
수정 불가 — 파일 내에 데이터 자체가 유실된 경우입니다. 유일한 해결책은 고객에게 파일을 다시 받는 것뿐입니다.

파일은 접수 단계에서 세 그룹으로 분류됩니다. 수정 가능한 파일은 수정본이 생성되고, 인쇄에 무해한 경고는 정보(Info)로만 표시되며, 수정 불가 파일은 인쇄 폴더로 넘어가지 않고 고객에게 반송됩니다.

사례 1: 페이지 하단의 한 줄짜리 저작권 문구 — RGB 색상의 Type3 텍스트

800페이지가 넘는 한 파일이 FreeFlow Core의 제본 처리 과정에서 지속적으로 실패했습니다. 오류가 발생하는 구간은 797~808페이지로, 총 12페이지였습니다. 범위를 좁히기 위해 797~798페이지만 따로 추출하여 몇 가지 변형 파일을 제작한 후, 인쇄소 현장에서 각각 FreeFlow Core에 투입해 테스트했습니다.

파일	변경 사항	FreeFlow Core 결과
A	변경 없는 원본	✕ 실패
B	각 페이지가 별도의 사본을 사용하도록 Type3 폰트 분리	✕ 실패
C	페이지 하단의 저작권 문구 삭제	✓ 통과
D	해당 문구의 텍스트 색상만 변경 (RGB → CMYK)	✓ 통과
E	해당 문구의 텍스트를 아웃라인(패스)으로 변환	… 멈춤 (처리 완료되지 않음)

원인은 각 페이지 하단에 위치한 저작권 표시 문구였습니다. 페이지의 다른 모든 요소는 그레이스케일의 일반 폰트를 사용하고 있었지만, 유독 그 문구 한 줄만 Type3 폰트로 설정되어 있었으며 DeviceRGB 파란색으로 채워져 있었습니다(한컴 한글의 PDF 내보내기 과정에서 생성된 것으로 추정됩니다).

Type3 폰트는 PDF 그리기 연산자(drawing operators)를 사용해 글리프를 직접 정의합니다. TrueType이나 Type1 폰트처럼 폰트 프로그램을 내장하는 대신, 글자 하나하나마다 작은 드로잉을 담고 있는 셈입니다. 이 파일의 Type3 글리프는 자체 색상 정보가 없었기 때문에, 텍스트가 그려질 당시 활성화되어 있던 현재 색상(여기서는 RGB 파란색)으로 렌더링되었습니다.

FreeFlow Core가 왜 이 특정 조합에서 실패하는지에 대한 공식 문서는 공개되어 있지 않습니다. 그러나 검증을 통해 확인한 사실은 세 가지로 요약됩니다:

해당 문구를 삭제하면 파일이 정상 통과합니다 (C).
텍스트 색상만 CMYK로 변경해도 정상 통과합니다 (D).
"폰트 문제"를 해결하겠다고 텍스트를 아웃라인으로 변환하면 워크플로우가 작업을 끝내지 못하고 멈춰버립니다 (E).

따라서 PB는 가능한 한 최소한의 변경만을 수행합니다. Type3 글리프가 그려지는 동안 적용되는 RGB 색상(칠 및 획)만을 CMYK로 변환한 후 본래의 색상 상태를 복원합니다. 폰트 자체는 변경하지 않으며, 동일한 색상 상태를 공유하는 다른 도형이나 이미지에도 영향을 주지 않습니다. 변환 시에는 출력용 ICC 프로파일을 사용하며, 설정된 프로파일이 없을 경우 기본 프로파일을 사용합니다. 무채색(R=G=B)은 작은 글자가 4도 혼합 블랙(Rich Black)으로 변하지 않도록 K(먹) 판으로만 분판합니다. 변경 작업 후에는 PB가 수정 전후의 페이지를 직접 렌더링하여 비교하며, 대상 글리프 외에 다른 영역에서 조금이라도 차이가 발견되면 해당 수정을 자동으로 폐기합니다.

분석한 26개 파일 중 1건이 이러한 구조였습니다. 흔한 경우는 아니지만, 한컴 한글로 제작된 교재나 유인물을 자주 접하는 인쇄소라면 충분히 겪을 수 있는 문제입니다.

여기서 얻은 교훈이 하나 더 있습니다. 처음에 아크로뱃 프리플라이트(Acrobat Preflight)에서 테스트했을 때는 폰트를 분리하는 방식(B)이 해결책인 것처럼 보였습니다. 하지만 실제 FreeFlow Core에서는 실패했습니다. 데스크톱 도구를 통과했다고 해서 실제 인쇄 워크플로우 통과가 보장되는 것은 아니며, 최종 판단은 항상 실제 운영 워크플로우 현장에서 이루어져야 합니다.

사례 2: 심각해 보이지만 인쇄에는 영향이 없는 경고 — 숨겨진 텍스트

스캔 후 OCR(광학 문자 인식)을 거친 PDF에는 화면에는 보이지 않는 텍스트 레이어가 포함되어 있습니다. 검색이나 텍스트 복사를 위해 삽입된 것으로, PDF 내부에서는 보이지 않음(텍스트 렌더링 모드 3)으로 지정되어 있습니다. 초기에는 이를 경고(Warning)로 분류했습니다. 폰트를 아웃라인으로 변환할 때 이 숨겨진 텍스트가 겉으로 드러나 인쇄되어 버린다면 심각한 인쇄 사고로 이어질 수 있기 때문입니다.

이에 실제 검증을 진행했습니다. 숨겨진 텍스트 레이어가 있는 48페이지짜리 파일에 아크로뱃 프리플라이트의 '폰트를 아웃라인으로 변환' 수정 규칙을 적용해 보았습니다. 숨겨진 텍스트를 그리던 10,240개의 연산자가 모두 사라졌으며, 48페이지 전체에서 변환 전후의 렌더링 결과에 차이가 전혀 없었습니다. 즉, 아웃라인 변환 과정에서 투명 텍스트가 겉으로 인쇄되는 일은 발생하지 않았습니다.

이에 따라 이 항목을 '정보(Info)'로 등급을 낮췄습니다. 검사 보고서에는 "검색용 숨은 텍스트 포함 — 인쇄에 영향 없음"이라고만 기록되며, 전체 판정 위험도를 높이지 않습니다.

숨겨진 텍스트에서만 사용된 폰트가 PDF에 임베딩되어 있지 않은 경우, PB는 수정본에 호환 대체 폰트를 포함시키고 "숨겨진 텍스트 전용 미포함 폰트 — 인쇄에 영향 없음"으로 표기합니다. 물론 폰트 누락 자체는 규칙에 따라 여전히 '경고(Warning)' 상태로 유지됩니다.

불필요한 경고를 줄이는 것 역시 중요한 기능입니다. 매번 작업자가 "이 파일 괜찮은 건가?" 하고 고민해야 한다면, 정작 중요한 치명적 위험 신호들도 다른 사소한 경고들과 똑같은 수준으로 흘려보내게 되기 때문입니다.

사례 3: 수정이 불가능한 파일 — 그리고 "제 PC에서는 잘 열리는데요"

26개 파일 중 3개는 파일 자체가 손상된 상태였습니다.

한 파일은 특정 PDF 엔진에서 아예 열리지 않았고, 다른 엔진에서는 열렸지만 168~170페이지가 백지로 표시되었습니다.
또 다른 파일은 저장이 중간에 중단된 것처럼 뒷부분이 잘려 있었습니다.
나머지 한 파일은 상호 참조 테이블(xref)이 손상되어 뷰어 엔진마다 페이지 수를 다르게 인식했습니다(한 엔진은 180페이지, 다른 엔진은 216페이지로 인식).

이러한 파일이 까다로운 이유는 고객의 PC에서는 정상적으로 열리기 때문입니다. 아크로뱃과 같은 뷰어 프로그램은 손상된 파일을 열 때 자체적으로 복구를 시도합니다. 복구 안내 메시지가 잠깐 스쳐 지나간 뒤 문서가 열리지만, 그 과정에서 일부 페이지가 백지가 되거나 누락됩니다. 고객은 "내 컴퓨터에선 잘만 열린다"고 말하고, 인쇄소는 중간에 백지가 섞인 채 인쇄 사고를 낼 위험을 고스란히 떠안게 됩니다.

손상되어 유실된 데이터는 다시 만들어낼 수 없습니다. 따라서 접수(Intake) 단계의 역할은 다음 세 가지입니다:

손상된 파일을 인쇄 워크플로우로 전달하지 않을 것.
작업자에게 무엇이 문제인지 정확히 보여줄 것 (예: 168~170페이지 손상).
고객과의 확인 및 재수급 소요 시간을 최소화할 것.

PB는 이러한 파일을 '치명적(Critical)'으로 분류하고 인쇄 폴더로 복사하지 않습니다. 주문과 함께 인입된 파일인 경우, 작업자는 접수 내역에서 [재업로드 요청] 버튼을 눌러 고객에게 즉시 알림을 보낼 수 있습니다. 이 버튼은 '치명적(Critical)' 판정을 받은 파일에만 나타나며, 인쇄소가 메시지 템플릿을 등록해 둔 경우에 활성화됩니다. 국내의 경우 인쇄소 자체 명의의 알림톡(카카오톡 비즈니스 메시지)으로 발송되며, 다음 내용이 포함됩니다:

파일명 및 구체적인 문제 내역 (예: "일부 페이지(168~170p) 손상")
원본 프로그램에서 PDF를 다시 저장해 달라는 요청
재업로드 전용 링크

고객이 다시 업로드한 파일은 새로운 접수 건으로 인입되어 자동으로 재검사를 거칩니다.

메시지 문구도 개선했습니다. 초기에는 "파일이 손상되어 열리지 않습니다"라고 발송했으나, 고객 PC에서는 자동 복구 후 열리기 때문에 잦은 문의가 있었습니다. 현재는 손상된 페이지 번호가 확인되면 해당 페이지 번호를 메시지에 정확히 명시하여 안내합니다.

접수 단계에서 일어나는 일 — Pressria Bridge 고객 파일 접수

고객이 업로드 페이지에서 파일을 올리면, PB는 이를 수신하여 검사하고, 자동 수정 가능한 파일은 수정본을 생성한 뒤, 인쇄 가능한 파일만을 인쇄 폴더로 전달합니다. 처음 파일이 PB로 인입되는 과정은 고객 파일 접수 문서를 참고하세요.

주문별 자동 정리(국내) — 온라인 쇼핑몰 주문과 연동되어 접수된 파일의 경우, 구매자명(또는 설정에 따라 수령인명)과 전화번호 뒷자리 4자리가 파일명에 자동으로 부여되며 고객별 전용 폴더가 생성됩니다 (예: original-name_홍길동-1234_120p.pdf). 파일명에 페이지 수가 함께 표기되므로 작업자가 파일을 열어보지 않고도 분량을 바로 확인할 수 있습니다.
간지(구분표지) 자동 생성 — 설정에서 활성화하면 PB가 각 고객 폴더마다 주문자 정보가 인쇄된 1페이지짜리 간지(슬립 시트) PDF를 자동으로 생성합니다. 규격은 해당 폴더 내 파일들에서 가장 많이 사용된 판형에 맞춰집니다.
정밀 검사 — 파일 손상, 누락된 폰트, 구조적 오류(삭제된 페이지 참조 등), 서로 다른 판형 혼재(혼합 판형), 별색(Spot Color) 유무 등을 검사합니다.
수정본 생성 — 원본은 그대로 보존되며, 수정 사항은 별도의 수정본에만 적용됩니다.
- 누락된 기본 폰트를 호환 가능한 폰트로 자동 임베딩
- 내부 구조 정리 및 정상화
- Type3 텍스트의 RGB 색상을 CMYK로 자동 변환
- 인쇄 및 편집 제한 암호 해제 (단, 문서 열기 암호는 해제하지 않음)
인쇄 폴더로 자동 복사 — 설정에서 복사 경로를 지정해 두면 검사를 통과한 파일이 FreeFlow 핫폴더(입력 폴더)로 자동 복사됩니다.
- 수정본이 생성된 파일은 수정본이 복사되며, 치명적(Critical) 판정을 받은 파일 및 간지는 인쇄 폴더로 복사되지 않습니다.
- 파일 복사 시 임시 파일명으로 먼저 기록된 후 복사가 완료되면 본래 파일명으로 변경되므로, 워크플로우가 덜 복사된 불완전한 파일을 먼저 가져가는 사고를 방지합니다.
- 네트워크 공유 경로(SMB 등)도 지원합니다.
재업로드 요청(국내) — 사례 3에 설명된 것처럼 접수 내역 화면에서 알림톡을 발송합니다.

PB가 의도적으로 하지 않는 작업들

폰트를 임의로 아웃라인(곡선화)하지 않습니다. 이는 FreeFlow Core가 담당해야 할 영역입니다. PB가 미리 아웃라인으로 변환해 버리면 사례 E처럼 워크플로우 처리가 멈춰버릴 위험이 있습니다. PB는 누락된 폰트를 PDF 내에 정상적으로 임베딩하는 수준까지만 안전하게 처리합니다.
열기 암호는 강제로 제거하지 않습니다. 인쇄 및 편집 권한 제한은 해제하지만, 내용 자체를 열람하기 위한 문서 열기 암호는 고객에게 직접 확인받아야 합니다.
원본 파일을 직접 수정하지 않습니다. 모든 수정은 별도의 복사본 파일로 분리되어 생성됩니다. Type3 색상 수정의 경우 수정 전후를 직접 렌더링하여 무결성을 검증하며, 다른 수정 사항 역시 수정한 부분 외에 페이지 내 다른 요소에 변화가 없는지 철저히 대조합니다. 조금이라도 이상이 발견되면 해당 수정은 즉시 취소됩니다.
손상된 파일을 "어떻게든 억지로" 인쇄하려 하지 않습니다. 불완전하게 복구하여 어떻게든 살아남은 페이지만 인쇄했다가 발생하는 재인쇄 손실보다, 고객에게 정상 파일을 다시 받는 것이 결과적으로 훨씬 비용과 시간을 아끼는 길입니다.

실무 접수 체크리스트

PB 사용 여부와 상관없이 현장에서 즉시 적용할 수 있는 팁입니다.

한글(HWP)이나 파워포인트로 생성된 PDF가 워크플로우에서 멈추면, 오류가 나는 구간의 페이지만 추출하여 테스트해 보세요. 범위를 좁히면 문제를 일으키는 구체적인 객체를 찾아낼 수 있습니다.
의심되는 객체를 삭제한 버전과 특정 속성(예: 색상) 하나만 변경한 버전을 만들어 실제 운영 워크플로우에 직접 통과시켜 보세요. 일반 데스크톱 프로그램의 프리플라이트 통과 결과만으로 섣불리 단정해서는 안 됩니다.
검출된 경고 항목들을 "이것이 실제 인쇄 결과물에 영향을 미치는가?"라는 단 하나의 기준으로 재분류해 보세요. 영향이 없는 항목들은 단순 '정보(Info)'로 낮추어 작업자의 피로도를 줄여야 합니다.
뷰어에서 열 때 복구 알림이 뜨는 파일은 절대 그대로 인쇄하지 마세요. 가능하다면 두 개 이상의 서로 다른 PDF 뷰어 엔진에서 열어 페이지 수가 일치하는지 비교해 보아야 합니다.
고객에게 재전송을 요청할 때는 "파일이 이상하다"고만 하지 말고, 구체적으로 몇 번 페이지에서 어떤 문제가 발생했는지 명확하게 설명해 주세요.

마치며

출력 장비와 워크플로우 소프트웨어는 갈수록 고도화되고 있지만, 여기에 들어가는 원본 파일들은 여전히 한컴 한글이나 파워포인트에서 제작되고 있습니다. 이 격차를 메우는 가장 비용 효율적인 단계는 출력 직전이 아니라 맨 처음 '접수(Intake)' 단계입니다. 수정 가능한 것은 소리 없이 안전하게 수정하고, 문제없는 것은 안심하고 넘기며, 수정 불가능한 파일은 최대한 빠르게 고객에게 되돌려 보내는 것. 이것이 바로 PB 고객 파일 접수 기능이 존재하는 이유입니다.

고객 파일 접수 · PDF 자동 검사 및 복구 안내 →

참고 자료

Xerox — FreeFlow Core — 인쇄 워크플로우 제품 개요
ISO 32000-1:2008 (Adobe 제공 PDF 규격 문서) — 섹션 9.6.5, Type 3 폰트

Pressria는 화이트 레이어 생성, 커팅선 처리, 네스팅, 일러스트레이터 연동 등 인쇄 제작 워크플로우를 자동화합니다. 자세한 내용은 pb.pressria.com에서 확인하실 수 있으며, verify.pressria.com에서 파일 사전 검증 도구를 사용해 보실 수 있습니다.

Xerox 및 FreeFlow는 Xerox Corporation의 상표이며, Acrobat은 Adobe의 상표입니다. 기타 제품명은 해당 소유자의 상표입니다.