사장님 입점신청 자동승인 주기를 10분에서 10초로

사장님의 입점신청 요청들은 자동승인 처리가 시작되기까지 최소 3분에서 최대 12분 59초가 걸렸습니다. 이 대기를 10초 이내로 줄인 과정을 기록한 글입니다. 그림 출처: AI 자동생성(https://youmind.com) 세 줄 요약 큐 역할을 하는 DB에 후보를 모았다가 처리하던 2단계 스케줄러(10분 주기)를 걷어내고, 요청 테이블과 처리 상태 테이블을 한 번에 보는 조회와 10초 폴링으로 변경했습니다. 자동승인 대상건 생성 후 처리 시작까지 최대 12분 59초 → 10초 이내로 개선했습니다(유입량이 처리 가능량을 넘지 않는다고 가정). 워커(자동승인 스케줄러가 도는 서버) N대 전부가 각각 폴링하고, 동시성은 락 안에서 상태를 확인하고 기록하는 구간이 막습니다. 처리 중간에 멈춘 건은 별도 클렌징 스케줄러가 되살립니다. 10초 폴링으로 주기를 기존의 1/60로 줄이면서도 외부 시스템으로 가는 부하는 변하지 않았습니다. 승인? 자동승인? 가게 사장님이 배달의민족에 입점하려면 계약과 승인 절차를 거쳐야 합니다. 이 요청들을 접수해서 승인까지 관리하는 사내 시스템이 있고, 저희 팀이 그 시스템을 개발하고 운영합니다. 서류가 다 갖춰졌고, 정책상 반려 사유가 없고, 앞 단계가 모두 끝난 요청은 사람이 판단할 것이 없습니다. 이러한 업주계약, 광고계약 요청을 시스템이 대신 승인하는 것이 자동승인입니다. 그런데 자동승인이 빠르지 않았습니다. 요청이 생긴 뒤 처리가 시작되기까지 최소 3분에서 최대 12분 59초가 걸렸고, 그동안 그 건은 담당자 목록에 그냥 밀린 일로 남아 있었습니다. 담당자가 기다리지 않고 직접 처리하면, 자동승인의 지연이 그대로 사람의 일로 넘어갑니다. 자동승인 대상의 대다수가 생성 즉시 자동승인이 가능한 요청들입니다. 반면 만들어질 때는 조건을 다 채우지 못했다가 나중에 갖춰지는 요청은, 조건이 갖춰진 뒤에도 다음 재시도 시각까지 기다립니다. 이 글은 주기를 줄이기 위해 어떤 고민을 했는지에 대한 기록입니다. 기존 구조에서 최소 대기 구간이 존재했던 이유 기존 자동승인은 두 개의 스케줄러로 나뉘어 있었습니다. enqueue(수집) 스케줄러: 매시 07분부터 10분 간격(07분, 17분, 27분 …)으로 요청건이 저장된 imr 테이블에서 자동승인 후보를 찾아 auto_approve_outbox 테이블에 NEW 상태로 적재 enqueue에 주어진 시간은 다음 process 실행 전까지, 즉 3분 p...