렌더링 대량 백필을 4배 단축

렌더링 작업의 백필을 처리할 때, sleep 시간을 동적으로 조절할 수 있는 --fast 플래그를 추가했다. 1회성 대량 작업에서는 sleep을 0.7~1.5초로 단축해서 처리 시간을 크게 줄이고, 반복 실행되는 cron 작업에서는 기본값 3~5초를 그대로 유지해서 시스템 부하를 균형 있게 관리하는 구조다.

렌더 백필이 느린 이유

렌더링 봇의 백필 작업은 기본적으로 대량의 항목을 순차 처리한다. 한 항목마다 렌더 요청을 보내고 응답을 받는데, 서버 부하나 네트워크 지연을 고려해서 의도적으로 sleep을 걸어둔다. 특히 cron으로 자동 실행되는 증분 업데이트(예: 매 시간 새로 추가된 항목 렌더링)는 몇 시간까지 돌 수 있으니, 각 항목 사이에 3~5초를 두는 게 일반적이다. 이렇게 하면 웹 서버에 한 봇이 집중적으로 요청을 보내는 부하를 분산할 수 있고, "자정부터 아침 6시까지는 이 정도 load가 날 것 같다" 같은 예측도 가능하다.

그런데 가끔 긴급하게 "지난 3개월 데이터를 다시 렌더링해줘" 같은 요청이 들어온다. 항목 수가 천 개, 수천 개면 기본 속도로는 1~2시간이 걸린다. 물론 기다릴 수도 있지만, 개발 환경에서 배포 전 테스트하거나 시간이 촉박할 땐 답답하다. 그래서 "일시적으로 빠르게 처리할 수 있는 옵션이 있으면 좋겠다"고 생각했고, 이게 --fast 플래그의 출발점이었다.

--fast 플래그: 상황에 맞춘 속도 조절

// 사용 예시
node bot/popmart_render.js --fast          // 0.7~1.5s sleep으로 빠르게
node bot/popmart_render.js                 // 기본값 3~5s sleep

실제 구현은 간단하다. 커맨드 라인 인자에서 --fast 플래그를 받으면 sleep 범위를 줄인다. 1회성 작업이니까 "한 번만 빨리 처리하고 끝내자"는 철학으로, sleep을 0.7초 근처에서 1.5초 정도 사이로 랜덤하게 건다.

왜 하필 0.7~1.5초인가? 단순히 "가장 빠른 게 최고"라고 해서 0초에 갈 수는 없다. 서버가 동시 요청을 처리하는 데 어느 정도 시간이 필요하고, 완전히 no-delay로 가면 서버나 네트워크에 무리가 간다. 그래서 최소한의 쿠션(0.7초)을 두되, 약간의 지터(jitter)를 더해서 요청들이 정확히 같은 시점에 몰리지 않도록 했다. 0.7~1.5초도 "충분히 빠르면서 동시에 무리가 가지 않는 선"의 타협점이다.

기본값을 유지한 이유

여기서 중요한 의사결정이 있다. cron에서 기본값 3~5초는 그대로 둔다는 거다.

cron 작업은 매일, 매시간 자동으로 돈다. 봇 입장에서는 "내가 몇 개 항목을 처리하든 상관없이, 스케줄대로 계속 실행될 거다"라는 뜻이다. 만약 기본값을 0.7~1.5초로 낮추면, 시스템은 항상 "급할 때 같은 속도"로 작동하게 된다. 그러면 서버 입장에서 부하 패턴을 예측할 수 없고, 야간에 갑자기 부하가 몰려올 수도 있다.

또한 렌더링 작업이 여러 봇에서 동시에 실행될 수 있다면? 한 봇은 3초, 다른 봇은 0.7초씩 요청하면 합쳐져서 순간 부하가 폭증할 수 있다. 이런 누적 효과를 방지하려면 정상 상황에서는 보수적인 간격을 유지해야 한다.

결론적으로 --fast는 "필요할 때만 쓰는 응급 모드"이고, 기본값은 "항상 안전한 속도"라는 책임 분리 원칙을 따랐다. 팀 누군가가 나중에 "백필이 느린데, 기본값도 빠르게 못 해?" 물을 때도 "지금처럼 쓰는 쪽이 더 나은 이유가 있다"고 설명할 수 있다.

트레이드오프와 배운 점

이런 식의 "일회성 최적화"를 구현할 때 자주 마주치는 함정:

• flag 폭발: --fast, --slow, --medium, --turbo 이렇게 옵션이 자꾸 늘어난다. 유지보수가 복잡해진다. 처음부터 "두 가지 모드 (기본 vs --fast)"로 명확하게 정하는 게 중요하다.

• 기본값의 보수성: 누군가는 "--fast도 괜찮으니까 기본값도 빨리 해봐"라고 말할 수 있다. 하지만 기본값은 "상황 파악 전 가장 안전한 선택지"여야 한다. 나중에 문제가 터졌을 때 책임을 지려면 처음부터 보수적으로 가야 한다.

• 모니터링: --fast로 돌릴 때와 기본으로 돌릴 때의 성능, 에러율, 응답시간을 추적할 수 있으면 나중에 의사결정이 쉬워진다. "정말로 --fast가 안전한가"를 데이터로 증명할 수 있으니까.

이번 작업을 통해 배운 건, "플래그 하나"라도 설계할 때 "왜 이 값인가", "왜 기본값은 따로인가", "어떤 모니터링이 필요한가" 같은 질문을 미리 하는 게 코드의 안정성과 팀의 신뢰도를 크게 높인다는 것.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.