웹 재고 시스템 라벨·영수증 인쇄, 세 가지 방식 비교

창고에 웹 기반 재고·주문 시스템을 넣으면 화면은 대개 첫날부터 잘 돕니다. 입고 등록도 되고 재고 현황도 보입니다. 그런데 라벨 프린터 앞에서 막힙니다. 인쇄 버튼을 눌렀는데 아무것도 안 나오거나, 바코드가 A4 여백을 낀 이상한 크기로 나옵니다.

대부분 프린터 고장이 아닙니다. 브라우저가 라벨 프린터에게 할 말을 못 하는 구조 때문입니다. 이 차이를 모르고 견적을 받으면 "웹으로 만든다면서 왜 창고 PC마다 프로그램을 또 깔아야 하냐"는 질문이 개발 막바지에 터집니다.

브라우저는 프린터에 명령을 직접 보내지 못합니다

라벨 프린터와 영수증 프린터는 문서를 받지 않습니다. ZPL(지브라 라벨 명령어)이나 ESC/POS(영수증 프린터 명령어)라는 텍스트 명령을 받아서 점을 찍습니다. 사람이 보면 알 수 없는 문자열 한 줄이 그대로 바코드가 됩니다.

문제는 이 문자열을 프린터까지 보낼 통로입니다. 프린터는 보통 TCP 9100 포트로 이 명령을 받는데, 브라우저의 자바스크립트에는 임의의 TCP 연결을 여는 기능이 없습니다. 웹 페이지가 보낼 수 있는 것은 HTTP 요청뿐입니다.

브라우저가 주는 인쇄 기능은 사실상 인쇄 대화상자 하나입니다. 화면을 운영체제에 넘기는 기능이지, 명령어 원문을 프린터에 꽂는 기능이 아닙니다.

라벨이 안 나오는 진짜 이유는 프린터가 아니라, 브라우저에서 프린터까지 가는 길이 처음부터 없다는 데 있습니다.

WebUSB와 Web Serial은 우회로가 되지 못합니다

브라우저에서 장치를 직접 다루는 WebUSB, Web Serial API가 있기는 합니다. 다만 MDN은 두 API를 모두 "제한적 지원"으로 표시합니다. 널리 쓰이는 브라우저 일부에서 아예 동작하지 않는다는 뜻입니다.

조건도 까다롭습니다. HTTPS에서만 되고, 사용자가 버튼을 눌러 장치를 직접 골라야 권한이 생깁니다. 창고 직원이 출근할 때마다 팝업에서 프린터를 다시 선택하는 운영은 현실적이지 않습니다.

아이패드의 사파리나 파이어폭스가 섞인 현장이라면 이 방식은 그 자리에서 무너집니다. 견적 후보로 올릴 만한 경로가 아닙니다.

그래서 창고 PC마다 설치 프로그램이 붙습니다

없는 길을 만드는 가장 흔한 방법이 로컬 인쇄 에이전트입니다. PC에 작은 프로그램을 깔아 두면, 그 프로그램이 자기 PC 안에서 대기하다가 웹 화면이 보낸 인쇄 요청을 받아 프린터로 옮겨 줍니다.

지브라의 Browser Print가 대표적입니다. 설치하면 로컬 주소의 9100·9101 포트에서 대기하고, 웹 페이지는 자바스크립트로 그 주소에 요청을 보냅니다. 회사 서버가 아니라 그 PC 안에서만 오가는 통신입니다.

그래서 "웹인데 왜 설치가 필요하냐"는 질문의 답은 이렇습니다. 설치하는 것은 업무 프로그램이 아니라 브라우저와 프린터를 잇는 번역기입니다. 업무 로직은 서버에, 화면은 브라우저에 그대로 있습니다.

에이전트의 진짜 비용은 설치가 아니라 관리입니다

설치 자체는 몇 분이면 끝납니다. 비용은 그다음에 생깁니다. Browser Print는 자체 서명 인증서를 쓰는데, 인증서 이름이 "BrowserPrint"로 되어 있어 접속 주소와 맞지 않는다는 오류가 지브라 개발자 포럼에 사례로 올라와 있습니다. 인증서 저장소는 2년마다 다시 만들어집니다.

포트 충돌도 잦습니다. 9100이나 9101을 다른 프로그램이 이미 쓰고 있으면 에이전트가 뜨지 않습니다. PC가 20대면 이 일이 20번 생기고, 대규모 윈도우 업데이트 뒤에 한 번 더 생깁니다.

견적서에 "설치 지원" 한 줄만 있고 유지보수 항목이 없다면, 그 비용은 나중에 담당자의 시간으로 청구됩니다.

유료 에이전트는 그 관리 부담을 월정액으로 바꿉니다

직접 만들지 않고 상용 서비스를 쓰는 길도 있습니다. PrintNode는 각 PC에 클라이언트를 깔고 클라우드를 거쳐 인쇄 작업을 내려보냅니다. 공식 가격표는 Lite 무료(월 50건·PC 1대), Essential 월 9달러(5,000건·3대), Standard 월 29달러(25,000건·5대), Premium 월 99달러(200,000건·PC 무제한)입니다.

여기서 1건은 페이지 수와 상관없이 인쇄 요청 하나입니다. 라벨을 장당 한 건씩 뽑는 창고라면 건수가 빠르게 오릅니다. 하루 1,000장이면 Standard 요금제의 월 25,000건을 한 달 안에 넘깁니다.

무료 대안인 QZ Tray는 오픈소스지만, 공식 문서 기준으로 무료 배포판에는 제한이 걸려 있고 이를 푸는 전자 인증서는 유료입니다. 공짜로 시작했다가 현장에서 매번 확인창을 누르는 구성이 되기 쉽습니다.

프린터 내장 프린트 서버는 창고 PC를 아예 지웁니다

두 번째 선택지는 PC를 빼고 프린터가 직접 서버와 이야기하게 만드는 방식입니다. 지브라의 Cloud Connect(Weblink)는 Link-OS 펌웨어에 들어 있는 기능으로, 프린터가 WebSocket과 HTTPS로 서버에 스스로 접속합니다. 중간 소프트웨어가 없습니다.

스타마이크로닉스의 CloudPRNT는 방향이 반대입니다. 프린터가 주기적으로 서버에 POST로 상태를 보내며 일감을 묻고, 있으면 GET으로 가져가고, 다 찍으면 DELETE로 완료를 알립니다. 엡손 TM 시리즈의 ePOS-Print도 같은 계열입니다.

창고 PC가 없어지니 설치도 인증서 갱신도 사라집니다. 대신 서버 쪽에 프린터를 상대하는 전용 통로를 새로 만들어야 하고, 그 개발 공수가 견적에 들어갑니다.

내장 서버 방식은 프린터 기종에 묶입니다

이 방식의 값은 하드웨어로 냅니다. Cloud Connect는 Link-OS 프린터 전반에서 되지만 보급형인 Link-OS Basic 계열은 제외됩니다. 창고에 이미 깔린 프린터가 지원 목록 밖이면 교체 비용부터 계산해야 합니다.

브랜드가 섞이면 더 커집니다. 지브라의 WebSocket 방식과 스타의 폴링 방식은 프로토콜이 완전히 달라서, 두 브랜드를 함께 쓰는 창고는 서버 코드를 두 벌 만들어야 합니다.

프린터를 새로 사는 편이 창고 PC 스무 대를 평생 관리하는 것보다 싼 경우가 실제로 많습니다.

PDF 인쇄는 가장 싸 보이지만 라벨에서 어긋납니다

세 번째는 서버에서 PDF를 만들어 브라우저로 열고 인쇄하는 방식입니다. 추가 설치가 없고 어떤 프린터든 되니 견적이 가장 쌉니다. A4 거래명세서나 검수증에는 이 방법이 맞습니다.

라벨은 다릅니다. 인쇄 대화상자는 사용자가 프린터와 배율을 고르게 되어 있어서, 100×50mm 라벨에 A4 기준 배율이 걸리면 바코드 선 굵기가 틀어집니다. 스캐너가 못 읽는 라벨은 안 나온 것과 같습니다.

크롬에는 대화상자를 건너뛰는 SilentPrintingEnabled 정책과 kiosk-printing 실행 옵션이 있습니다. 다만 이것도 PC마다 정책을 심는 작업이라, 설치가 없다는 장점이 절반은 사라집니다.

세 방식 중 무엇을 견적에 넣을지 이렇게 가르세요

바코드 라벨이 업무의 중심이고 창고마다 PC가 이미 있습니다 → 로컬 인쇄 에이전트
프린터를 새로 도입·교체할 예산이 있고 무인 매장이나 지점을 늘릴 계획입니다 → 프린터 내장 프린트 서버
인쇄물이 A4 문서 위주이고 밀리미터 단위 정확도가 필요 없습니다 → PDF 인쇄
태블릿이나 휴대폰에서 찍어야 합니다 → 내장 프린트 서버, 에이전트는 설치 자체가 불가능합니다

지브라 프린터를 쓰면서 PDF 방식을 포기하기 아깝다면 중간 길도 있습니다. PDF Direct 가상 장치를 프린터에 올리면 프린터가 PDF를 직접 해석합니다. 다만 zDownloader로 설치해야 하고 활성화 라이선스를 사야 합니다.

이럴 때는 이 비교가 아예 맞지 않습니다

인터넷이 자주 끊기는 창고에서는 클라우드를 거치는 방식이 모두 탈락합니다. PrintNode도 Cloud Connect도 외부 접속이 전제입니다. 이때는 창고 안에 인쇄 서버를 두고 9100 포트로 직접 쏘는 옛날 구조가 여전히 정답입니다.

프린터의 외부 접속을 막는 폐쇄망도 같습니다. 반대로 인쇄가 하루 몇 장뿐이라면 어떤 구조를 골라도 체감 차이가 없으니, 가장 싼 PDF로 시작하고 문제가 생길 때 옮기는 편이 낫습니다.

비슷한 현장 이슈는 실무 가이드에 모아 두었고, 재고·주문 시스템 구축 문의는 Codeforest로 받고 있습니다. 지브라 Cloud Connect의 지원 범위는 지브라 공식 페이지에서 확인하세요.

결론: 인쇄 방식은 개발 막바지가 아니라 견적 단계에서 정하세요

브라우저가 ZPL과 ESC/POS를 직접 보내지 못한다는 사실은 우회할 수 있는 조건이 아닙니다. 그래서 웹 시스템이라도 창고 PC에 에이전트를 깔거나, 프린터를 내장 서버 지원 기종으로 바꾸거나, 라벨 정확도를 포기하고 PDF로 가는 세 갈래 중 하나를 반드시 고르게 됩니다.

이 선택은 개발이 끝난 뒤에 바꾸기가 가장 비쌉니다. 프린터 대수와 브랜드, 하루 인쇄 건수, 창고의 네트워크 상태를 먼저 적어 두고, 그 숫자를 견적서에 올려 두세요. 그래야 나중에 설치 프로그램이 왜 필요하냐는 질문이 생기지 않습니다.