CUPS 프린트 서버 구축기 (도커 설치, 빅솔론 연결, 유지보수)

회사에서 라벨 프린터를 네트워크로 연결해달라는 요청을 받았을 때, 솔직히 이건 예상보다 훨씬 복잡한 일이었습니다. Synology NAS 안의 도커 컨테이너에 CUPS를 올리고, 거기에 빅솔론(Bixolon) 라벨 프린터를 붙여서, 웹에서 버튼 하나로 라벨이 출력되게 만드는 것이 목표였습니다. 결과적으로는 성공했지만, 지금 돌아보면 처음부터 다시 설계하고 싶은 부분이 한두 군데가 아닙니다.

CUPS 도커 설치, 생각보다 단순했지만 함정이 있었습니다

저희 회사 서버는 Synology DS720+였고, 그 위에 Docker를 올려서 여러 서비스를 운영하고 있었습니다. 프린터 연결을 위해 Ubuntu 기반의 컨테이너를 하나 새로 만들고, 그 안에 CUPS(Common UNIX Printing System)를 설치했습니다. CUPS란 애플이 개발한 뒤 오픈소스로 공개된 인쇄 관리 시스템으로, 현재는 대부분의 리눅스 배포판에서 네트워크 인쇄를 처리하는 표준으로 자리 잡고 있습니다.

설치 자체는 터미널에서 명령어 한 줄이면 끝납니다. Ubuntu 환경에서 sudo apt install cups를 실행하면 의존 패키지까지 함께 설치되고, 완료 즉시 CUPS 서버가 자동으로 시작됩니다. 여기까지는 정말 막힘이 없었습니다. 문제는 그다음이었습니다.

CUPS의 설정 파일은 /etc/cups/cupsd.conf에 있는데, 이 파일의 구조가 Apache HTTP 서버 설정 파일과 동일한 문법을 따릅니다. 즉, 웹 서버 설정에 익숙한 분이라면 금방 적응할 수 있습니다. 저는 처음에 이 설정 파일을 그대로 건드렸다가 원래 상태로 되돌리느라 시간을 꽤 낭비했습니다. 지금은 반드시 원본을 백업해두고 시작하는 것을 권장합니다. 실제로 공식 문서(출처: Ubuntu Server Documentation)에서도 설정 전에 원본 파일을 복사해두라고 명시하고 있습니다.

도커 환경에서 CUPS를 올릴 때 특히 조심해야 할 부분이 하나 있습니다. 기본 설정에서 CUPS는 루프백 인터페이스(127.0.0.1), 즉 자기 자신에게만 접근을 허용합니다. 루프백 인터페이스란 컴퓨터가 자기 자신과 통신하기 위한 가상 네트워크 인터페이스를 뜻합니다. 도커 컨테이너는 별도의 네트워크 안에 있기 때문에, 외부에서 접근하려면 설정 파일에서 Listen 지시어를 반드시 수정해야 합니다. 저도 이 부분을 놓쳐서 처음에 웹 인터페이스에 아예 접속이 안 됐고, 한참을 헤맸습니다.

빅솔론 프린터 연결, IP 고정이 핵심입니다

CUPS 서버를 띄운 다음 과제는 빅솔론 라벨 프린터를 실제로 연결하는 것이었습니다. 이 단계에서 가장 먼저 해야 할 일은 프린터의 IP 주소를 고정하는 것입니다. 고정 IP(Static IP)란 네트워크 장비에 변하지 않는 주소를 부여하는 방식으로, 공유기가 재부팅되거나 프린터가 껐다 켜져도 항상 동일한 주소로 접근할 수 있게 해줍니다.

저는 빅솔론이 연결된 공유기의 관리 페이지에 접속해서 MAC 주소 기반으로 IP를 고정했습니다. 이 작업 없이 CUPS에 프린터를 등록하면, 나중에 IP가 바뀌었을 때 인쇄가 갑자기 안 되는 상황이 생깁니다. 그런 상황이 현장에서 발생하면, 저는 원격에서 설정을 다시 잡아줘야 하는데, 이게 생각보다 꽤 번거롭습니다.

IP를 고정한 뒤에는 CUPS 웹 인터페이스에 접속해서 빅솔론 드라이버를 설치하고 프린터를 추가했습니다. CUPS 웹 인터페이스는 기본적으로 http://서버IP:631/admin에서 열립니다. IPP(Internet Printing Protocol)란 네트워크를 통해 인쇄 작업을 주고받기 위한 표준 프로토콜로, CUPS가 이 방식을 기본으로 사용합니다. 여기서 한 가지 더 주의할 점은 CUPS의 접근 제어 설정입니다.

설정 파일 안의 Location 지시어는 어떤 네트워크 대역에서 CUPS에 접근할 수 있는지를 제어합니다. 이 설정을 업데이트하지 않으면 외부 호스트에서는 “Forbidden” 오류만 보입니다. 저희 사무실 네트워크 대역을 허용 목록에 추가하고, 방화벽에서 631번 포트도 열어준 뒤에야 정상적으로 접근이 됐습니다. 아래는 연결 작업의 순서를 정리한 것입니다.

  1. 공유기 관리 페이지에서 빅솔론 프린터의 MAC 주소를 확인하고 고정 IP를 할당합니다.
  2. CUPS 설정 파일에서 Listen 지시어를 수정해 서버의 실제 네트워크 IP를 추가합니다.
  3. Location 블록에 사무실 네트워크 대역을 허용 목록으로 추가합니다.
  4. 방화벽(ufw)에서 631/tcp 포트를 개방합니다.
  5. CUPS 웹 인터페이스에서 빅솔론 드라이버를 설치하고 프린터를 추가합니다.
  6. 설정 변경 후 sudo systemctl restart cups.service로 CUPS 서비스를 재시작합니다.

이 순서대로 진행하니 연결 자체는 깔끔하게 됐습니다. 프린터가 CUPS에 잡히는 순간은 솔직히 꽤 뿌듯했습니다.

웹 인쇄 구현, Excel에서 mPDF로 돌아온 이유

프린터 연결이 끝난 다음 과제는 저희 회사 웹사이트에서 버튼 하나로 라벨을 출력하게 만드는 것이었습니다. PHP로 구축된 사내 개발 사이트가 있었고, 처음에는 PHP의 Excel 생성 라이브러리인 PhpSpreadsheet를 Composer로 설치해서 직접 라벨 형식의 Excel 파일을 만들어 출력하는 방식을 시도했습니다. Composer란 PHP 프로젝트에서 외부 라이브러리 의존성을 관리하는 도구입니다.

그런데 이 방식이 생각처럼 잘 되지 않았습니다. Excel 파일을 CUPS가 직접 처리하게 하는 것은 호환성 문제가 있었고, 라벨 크기와 여백을 정확하게 맞추는 것도 쉽지 않았습니다. 결국 선택한 방법은 Excel로 데이터를 구성한 뒤, mPDF라는 PHP 라이브러리를 이용해 PDF로 변환하고, 그 PDF를 CUPS가 빅솔론에 전송해서 인쇄하는 방식이었습니다. mPDF란 HTML과 CSS를 기반으로 PDF 파일을 생성해주는 PHP 라이브러리입니다.

이 방식은 실제로 잘 작동했습니다. PDF는 CUPS가 PostScript Printer Description(PPD) 기반으로 처리하기에 가장 적합한 포맷이기도 합니다. PPD란 특정 프린터의 기능과 속성을 정의한 표준 파일 형식으로, CUPS가 이를 참조해 인쇄 옵션을 처리합니다. 다만 이 구조는 유지보수 측면에서 제가 나중에 크게 후회하게 된 선택이기도 합니다.

CUPS의 에러 로그는 /var/log/cups/error_log에서 확인할 수 있습니다. 인쇄가 안 될 때는 이 로그가 첫 번째 단서가 됩니다. 기본 로그 레벨은 “info”인데, 문제가 잘 잡히지 않을 때는 설정 파일의 LogLevel 지시어를 “debug”나 “debug2″로 바꾸면 훨씬 자세한 정보를 얻을 수 있습니다. 단, 문제 해결 후에는 반드시 원래 레벨로 되돌려야 로그 파일이 과도하게 커지는 것을 막을 수 있습니다.

유지보수의 현실, 웹 자동화가 항상 정답은 아닙니다

구축을 마치고 시간이 꽤 지난 지금, 솔직히 가장 큰 고민은 기술적인 문제가 아닙니다. 시스템이 돌아가고 있는 현장에서 라벨 하나가 틀어졌다는 연락이 오면, 저는 원격으로 Excel의 셀 너비(width)와 높이(height) 값을 수정하고, PHP가 새 Excel을 생성하도록 코드를 바꾸고, 다시 PDF로 변환해서 결과를 확인해야 합니다. 그런데 현장을 직접 볼 수가 없으니, 확인할 때마다 영상 통화를 하거나 현장 직원에게 사진을 보내달라고 요청하는 일이 반복됩니다. 이게 정말 지치는 일입니다.

제가 직접 써봤는데, 이런 구조는 개발자가 항상 대기하고 있어야만 운영이 가능합니다. 만약 제가 퇴사하고 개발 담당자가 새로 들어오지 않는다면, 그 시스템은 라벨 한 줄이 틀어져도 아무도 고칠 수 없는 상태가 됩니다. 이건 시스템이 아니라 의존성입니다.

사실 라벨 출력만 놓고 보면, 빅솔론 프린터는 자체적으로 Windows PC와 연결해 Excel 파일을 직접 인쇄하는 방식도 지원합니다. 개발을 모르는 직원도 Excel 파일을 열고 인쇄 버튼을 누르면 되는 구조입니다. 웹에서 버튼 하나로 출력하게 만드는 것이 사용성 측면에서는 훨씬 편리하지만, 유지보수 비용을 현실적으로 따지면 범용 프로그램으로 해결할 수 있는 영역은 그렇게 두는 편이 맞다는 생각이 점점 강해지고 있습니다.

물론 자동화의 가치는 분명히 있습니다. 주문이 들어올 때마다 DB에서 데이터를 끌어와 라벨을 자동으로 출력하는 것은 Excel로는 불가능한 영역입니다. 하지만 그 편의성의 대가가 개발자 종속이라면, 도입 전에 반드시 유지보수 시나리오를 함께 설계해야 한다고 봅니다. 이 부분에서 저는 처음 설계 때 충분히 고민하지 못했다는 후회가 있습니다. Bixolon 공식 사이트(출처: Bixolon 공식 사이트)에서도 다양한 인쇄 연동 방식을 제공하고 있으니, 구축 전에 어떤 방식이 자신의 환경에 맞는지 먼저 검토해보는 것이 좋습니다.

자주 묻는 질문

Q. Synology NAS에 CUPS를 Docker로 올리는 것이 가능한가요?

A. 가능합니다. Ubuntu 기반의 Docker 컨테이너를 생성하고 그 안에 CUPS를 설치하면 됩니다. 다만 컨테이너의 네트워크 설정을 호스트 모드(host mode)로 맞추거나 포트 포워딩을 정확하게 해줘야 NAS 외부에서 CUPS 웹 인터페이스에 접근할 수 있습니다. 이 설정을 빠뜨리면 컨테이너 안에서만 동작하고 외부에서 프린터에 접근이 안 됩니다.

Q. CUPS에서 빅솔론 라벨 프린터가 인식이 안 될 때 어떻게 해야 하나요?

A. 가장 먼저 프린터의 IP가 고정되어 있는지 확인하십시오. 유동 IP 상태에서는 재부팅 후 주소가 바뀌어 연결이 끊깁니다. 그다음으로 CUPS 에러 로그(/var/log/cups/error_log)를 확인하고, 필요하면 cupsd.conf의 LogLevel을 debug로 변경해서 상세 로그를 살펴보십시오. 드라이버 호환성 문제일 경우 빅솔론 공식 홈페이지에서 리눅스용 PPD 파일을 별도로 내려받아 등록해야 할 수 있습니다.

Q. PHP에서 Excel 파일을 바로 CUPS로 인쇄할 수 없나요?

A. 기술적으로 쉽지 않습니다. CUPS는 PostScript나 PDF, 혹은 특정 이미지 포맷을 처리하는 데 최적화되어 있고, Excel 바이너리 파일을 직접 처리하는 기능이 없습니다. 그래서 PhpSpreadsheet로 Excel을 생성한 뒤 mPDF 같은 라이브러리를 통해 PDF로 변환하고, 그 PDF를 CUPS에 전달하는 방식이 현실적인 선택입니다. 변환 과정에서 레이아웃이 틀어지는 경우가 있으므로, mPDF의 HTML 템플릿을 직접 조정하는 방식이 더 정밀하게 제어됩니다.

Q. CUPS 설정 변경 후 반드시 재시작해야 하나요?

A. 그렇습니다. cupsd.conf 파일을 수정했다면 반드시 sudo systemctl restart cups.service 명령으로 CUPS 서비스를 재시작해야 변경 사항이 반영됩니다. 재시작 없이는 기존 설정이 그대로 유지되기 때문에, 설정을 바꿨는데 왜 적용이 안 되지 하고 헤매는 상황이 생깁니다.

Q. 웹에서 라벨 자동 출력 대신 Excel로 운영하는 게 현실적으로 더 나은 경우는 언제인가요?

A. 출력 빈도가 낮고, 인쇄 담당자가 고정되어 있으며, 사내 개발 인력이 없거나 유지보수가 불확실한 환경이라면 Excel 직접 출력이 훨씬 현실적입니다. 웹 자동화는 구축 비용보다 유지보수 비용이 더 클 수 있고, 개발자 한 명에게 시스템이 종속되는 리스크가 생깁니다. 자동화가 필요한 상황은 주문 연동, 대량 출력, DB 자동 연동 등 사람이 개입하기 어려운 영역에 한정하는 것이 좋습니다.

정리하면, CUPS와 Docker 조합으로 네트워크 프린트 서버를 구축하는 것 자체는 충분히 가능하고 작동도 잘 됩니다. 문제는 그 위에 얼마나 복잡한 자동화를 쌓느냐입니다. 구축할 때는 유지보수 시나리오를 반드시 함께 설계하십시오. 퇴사 후에도 비개발자가 운영할 수 있는가, 라벨 하나가 틀어졌을 때 원격에서 혼자 고칠 수 있는가를 기준으로 삼는다면, 어느 수준까지 자동화할지 자연스럽게 결론이 나옵니다.

—
참고: https://ubuntu.com/server/docs/how-to/networking/cups-print-server/
https://www.bixolon.com

Similar Posts