스풀링이란: 이메일 큐와 인쇄 큐가 작업을 버퍼링하는 방식

스풀링(spooling)은 빠르게 작업을 만드는 producer와 상대적으로 느리거나 일시적으로 사용할 수 없는 device·remote service 사이에 작업을 queue로 저장하고 scheduler가 나중에 처리하는 구조다. 사용자는 프린터가 실제 출력을 끝내거나 상대 메일 서버가 최종 배달을 마칠 때까지 foreground에서 기다리지 않아도 된다.

POP3와 SMTP, spool file을 같은 종류의 기술로 묶으면 역할이 흐려진다. SMTP는 메일 제출·서버 간 전달 프로토콜이고 POP3는 도착한 maildrop에 접근하는 프로토콜이다. spool은 전송이나 출력이 당장 끝나지 않을 때 작업 상태와 데이터를 보관하는 queueing 구조다.

스풀러를 이루는 네 부분

producer
  ↓ 작업 제출
spool storage와 metadata
  ↓
scheduler
  ↓ 순서·재시도 결정
worker 또는 backend
  ↓
printer 또는 remote mail server

구성 요소	책임
producer	메일·인쇄 작업과 옵션을 제출한다.
spool storage	payload와 목적지, 상태, 재시도 정보를 보관한다.
scheduler	처리할 작업과 시점을 선택한다.
worker·backend	외부 장치나 서버에 실제 전달을 시도한다.

spool이 반드시 단일 “스풀 파일” 하나인 것은 아니다. 구현에 따라 payload file, control file, database row와 journal을 함께 사용할 수 있다. 중요한 것은 작업이 process memory를 넘어 보관되고 비동기적으로 상태가 바뀐다는 점이다.

작업 상태를 명시해야 하는 이유

스풀 시스템은 단순한 FIFO보다 많은 상태를 가진다.

accepted → queued → active → completed
                 ├→ deferred → retry
                 ├→ held
                 └→ failed

• accepted: 시스템이 작업 책임을 받아들였다.
• queued: 실행 순서를 기다린다.
• active: worker가 현재 처리 중이다.
• deferred: 일시 오류로 다음 시도까지 기다린다.
• held: 운영자 정책이나 오류로 자동 처리를 멈춘다.
• completed·failed: 성공 또는 더 이상 자동 처리하지 않는 최종 상태다.

API 요청이 성공했다는 사실과 외부 효과가 완료됐다는 사실을 분리해야 한다. 작업 ID를 반환하고 이후 상태를 조회하게 하는 구조가 필요한 이유다.

메일 큐에서 SMTP는 어떻게 연결될까

메일 앱은 message submission server에 메일을 맡기고, MTA는 상대 domain의 MX를 찾아 server-to-server SMTP로 전달한다. 상대 서버가 일시적인 4xx 응답을 보내거나 연결할 수 없으면 MTA는 메시지를 queue에 두고 정책에 따라 다시 시도할 수 있다.

메일 제출
  ↓
incoming mail queue
  ↓ queue manager
상대 MTA 전달 시도
  ├─ 2xx 수락 → queue에서 완료 처리
  ├─ 4xx 임시 실패 → deferred 후 재시도
  └─ 5xx 영구 실패 → 반송·실패 처리

Postfix의 queue manager는 새 메일 전달, 실패한 전달의 재시도와 완료된 메시지 제거를 scheduling한다. read-only로 현재 queue를 나열할 때는 다음 명령을 사용할 수 있다.

postqueue -p

JSON line 형식이 지원되는 버전이라면 다음 명령도 있다.

postqueue -j

출력에는 queue ID, sender·recipient와 실패 이유가 포함될 수 있어 운영 정보와 개인정보를 그대로 외부에 공유하면 안 된다. queue flush나 삭제는 상태를 바꾸는 작업이므로 원인과 대상 ID를 확인한 뒤 별도 절차로 수행한다.

SMTP·IMAP·POP3와 MX의 전체 역할은 이메일 전송 과정에서 분리해 정리했다.

POP3는 발송 queue가 아니다

POP3는 사용자 agent가 server의 maildrop에서 메시지를 나열하고 가져오는 프로토콜이다. DELE로 삭제 표시한 메시지는 정상적으로 QUIT해 update state에 들어갈 때 server에서 제거되는 모델을 가진다.

따라서 “POP3는 내려받으면 기본적으로 서버 메일을 즉시 삭제한다”라고 일반화하면 안 된다. client 설정, 명령과 session 종료 상태에 따라 server 보관 여부가 달라진다. POP3 mailbox와 발송 MTA queue는 서로 다른 저장소와 lifecycle이다.

CUPS 인쇄 큐에서는 무엇을 저장할까

CUPS는 중앙 scheduler가 printer, class, job과 notification을 관리한다. 인쇄 요청을 받으면 queue와 document, option을 가진 job을 만들고 filter·backend를 거쳐 printer로 보낸다.

CUPS 설계 문서의 기본 spool directory에는 job별 control file과 data file이 저장될 수 있다.

• control file: IPP job metadata와 상태
• data file: 제출된 인쇄 document

현재 job과 printer 상태를 읽는 명령은 다음과 같다.

lpstat -o
lpstat -p -d

프린터가 꺼져 있거나 종이가 없으면 job이 queue에서 기다릴 수 있다. queue가 있다는 사실은 인쇄 완료를 뜻하지 않는다. job state와 printer state, backend 오류를 함께 확인한다.

스풀링이 해결하는 것과 새로 만드는 문제

얻는 점	함께 생기는 운영 문제
producer와 device 속도 분리	queue가 계속 쌓일 수 있음
일시 장애 뒤 재시도	retry storm과 중복 처리 위험
작업 순서와 우선순위 제어	starvation과 head-of-line blocking
process 재시작을 넘는 보관	disk full, 손상, orphan job
작업 상태 추적	metadata·payload의 개인정보 보호

queue length만 보면 원인을 알 수 없다. 유입률, 처리율, 가장 오래된 작업의 age, retry 횟수, destination별 실패율을 같이 본다. 평균 지연보다 oldest job이 사용자 체감과 장애 지속 시간을 더 잘 드러낼 때가 많다.

장애를 확인하는 순서

1. producer가 작업 ID를 받고 accepted 상태가 됐는지 확인한다.
2. spool storage의 여유 공간과 권한, 손상 여부를 본다.
3. queued·active·deferred·held 중 어디에 머무는지 구분한다.
4. destination별 마지막 오류와 다음 retry 시각을 확인한다.
5. worker가 살아 있고 처리율이 유입률을 따라가는지 본다.
6. 외부 장치·SMTP server가 복구된 뒤 queue age가 실제로 줄어드는지 확인한다.
7. 재처리 전에 작업이 멱등한지, 이미 외부 효과가 발생했는지 확인한다.

보안과 보존 정책

메일 본문과 인쇄 문서는 spool에 평문으로 남을 수 있는 민감 데이터다. 최소한 다음을 명시한다.

• spool directory와 관리 API의 접근 권한
• storage 암호화와 backup 포함 여부
• 성공·실패 job의 보존 기간
• log에 남길 queue ID와 숨길 payload·address
• 삭제 요청과 장애 복구 시 일관성
• multi-tenant 환경에서 queue와 document 격리

비동기화는 처리 시간을 없애지 않는다. 기다리는 위치를 foreground request에서 관리 가능한 queue로 옮기는 것이다.

참고 자료

• RFC 5321: Simple Mail Transfer Protocol
• RFC 1939: Post Office Protocol, Version 3
• Postfix Queue Scheduler
• Postfix postqueue(1)
• OpenPrinting CUPS Design Description
• OpenPrinting lpstat(1)