백그라운드 작업

웹 서비스는 오랫동안 요청 하나에 응답 하나를 돌려주는 방식으로만 움직였습니다. 사용자가 버튼을 누르면 서버가 일을 다 끝낸 다음에야 화면에 결과가 떴습니다. 서버는 요청을 받아 처리하고 응답을 돌려주는 프로그램입니다. 일이 0.2초 만에 끝나는 동안에는 이 방식에 아무 불편이 없었습니다.

불편은 일이 길어지는 자리에서 드러났습니다. 페이지덱이 300쪽짜리 문서를 PDF 로 내보내는 기능을 처음 내놨을 때 처리에 40초가 걸렸습니다. 브라우저는 응답을 30초쯤 기다리다 연결을 끊습니다. 사용자는 도는 아이콘만 보다가 오류 화면을 받았고, 다시 눌러도 같은 자리에서 끊겼습니다.

지현에게 들어온 문의는 이런 문장이었습니다. "내보내기를 눌렀는데 아무 일도 안 일어나요." 실제로는 서버가 일하고 있었지만 그 사실을 전할 통로가 없었습니다. 사용자 쪽에서는 일하는 중과 고장 난 중이 똑같아 보였습니다.

해법은 일을 빠르게 만드는 쪽이 아니라 기다리는 사람을 풀어 주는 쪽이었습니다. 접수했다는 응답만 즉시 돌려주고 실제 처리는 뒤로 미루는 것입니다. 이렇게 떼어 낸 일감을 백그라운드 작업이라고 부릅니다.

요청을 받은 자리에서 일을 끝내지 않고, 할 일을 적어 둔 뒤 곧바로 응답을 돌려주고, 적어 둔 것을 별도의 프로그램이 꺼내 실행합니다. 네 단계로 나뉩니다.

1. 접수 — 요청이 오면 서버는 "PDF 내보내기, 문서 4821, 요청자 지현" 같은 내용을 작업 기록으로 남깁니다. 남기는 데는 0.05초쯤 걸립니다.
2. 응답 — 그 자리에서 "접수했습니다, 작업 번호 9f3c" 를 돌려줍니다. 사용자 화면은 여기서 풀립니다.
3. 실행 — 워커라고 부르는 프로그램이 기록을 꺼내 실제 일을 합니다. 워커는 사용자 요청을 직접 받지 않고 쌓인 작업만 처리하는 쪽입니다.
4. 전달 — 끝나면 결과를 저장하고 알립니다. 화면이 몇 초마다 상태를 되묻거나, 서버가 먼저 알림을 보냅니다.

카페에서 음료를 주문하면 영수증과 진동벨을 먼저 받고 자리로 돌아가는 것과 같은 구조입니다. 주문하는 줄과 만드는 자리가 떨어져 있어 앞사람 음료가 오래 걸려도 뒷사람 주문이 막히지 않습니다.

작업마다 대기·진행·완료·실패 같은 상태를 답니다. 상태가 있어야 화면이 어디까지 왔는지 물어볼 수 있고, 실패한 작업만 골라 다시 돌릴 수 있습니다. 보통 실패하면 몇 분 간격으로 두세 번 자동 재시도합니다.

재시도에는 대가가 따릅니다. 실제로는 성공했는데 결과를 돌려받는 길만 끊기면 시스템은 실패로 보고 한 번 더 실행합니다. 그래서 뒤에서 도는 작업은 멱등성을 갖추도록 만듭니다. 같은 요청을 여러 번 실행해도 결과가 한 번 실행한 것과 같아지는 성질입니다. 결제 완료 메일이 세 통 나가는 사고가 대개 이 지점에서 납니다.

응답 시간 안에 끝나지 않는 일, 그리고 결과를 사용자가 지금 화면에서 볼 필요가 없는 일이 전부 뒤로 넘어갑니다. 페이지덱에서는 네 갈래로 나옵니다.

1. 메일과 알림 발송 — 외부 발송 업체를 거치느라 한 통에 2~3초가 걸립니다. 공지를 100명에게 보내면 4분이 넘고, 그동안 화면을 붙잡아 둘 수는 없습니다.
2. 파일 만들기와 변환 — PDF 내보내기, 업로드한 이미지의 축소판 생성, 사용량 내역 엑셀 다운로드가 여기 붙습니다.
3. 외부 시스템 연동 — 결제가 승인되면 회계 시스템에 내역을 넘깁니다. 상대 서버가 느려지거나 잠깐 멈춰도 페이지덱 화면까지 같이 멈추면 안 되니 떼어 놓습니다.
4. 집계와 정리 — 어제 사용량을 팀별로 합산하고, 30일이 지난 임시 파일을 지웁니다. 이런 작업을 순서대로 엮어 분석용 데이터를 만드는 흐름이 데이터 파이프라인입니다.

무엇을 뒤로 뺄지 가르는 기준은 하나입니다. 사용자가 이 결과를 지금 이 화면에서 봐야 하는가. 문서 제목을 고치는 일은 고친 제목이 바로 보여야 하니 응답 안에서 처리합니다. 300쪽 PDF 는 다 만들어진 뒤에 받아도 되니 뒤로 뺍니다.

판단과 실행을 가르는 선도 같은 자리에 있습니다. "무료 플랜은 문서를 세 개까지" 같은 규칙, 즉 비즈니스 로직에 해당하는 검사는 응답 안에서 끝냅니다. 거절할 요청이라면 접수부터 하지 않는 편이 낫습니다. 검사를 통과한 뒤의 무거운 실행만 뒤로 넘깁니다.

"이건 백그라운드로 빼죠. 응답 안에서 처리하면 타임아웃 납니다."

처리 시간이 브라우저가 기다려 주는 한계를 넘으니 요청과 처리를 떼어 놓자는 제안입니다.

"백그라운드 작업이 세 시간째 밀려 있어요. 워커를 늘려야 할 것 같습니다."

들어오는 작업이 처리하는 속도보다 빨라 대기가 쌓였고, 처리하는 쪽을 증설해야 한다는 뜻입니다.

"그 메일은 백그라운드로 나가니까 버튼 누르고 바로 안 와도 정상입니다."

지연이 고장이 아니라 설계된 동작이라는 설명입니다.

페이지덱이 내보내기 기능을 다시 만들 때 태오가 40초라는 측정값을 가져오자, 지현은 그 시간을 줄이는 방법 대신 사용자가 40초를 어떻게 보내야 하는지를 물었습니다. 결론은 버튼을 누르면 "만들고 있습니다" 를 띄우고 완료되면 알림을 보내는 쪽이었습니다.

일주일 뒤 수아가 500쪽짜리 문서도 되느냐는 고객사 질문을 전해 왔습니다. 응답 안에서 처리하던 시절이면 안 된다고 답해야 했지만, 뒤로 뺀 뒤로는 시간이 더 걸릴 뿐 되는 일이 됐습니다.

뒤로 빼면 작업이 빨라진다고 읽는 경우가 가장 많습니다. 버튼을 누른 직후 화면이 즉시 돌아오니 그렇게 보일 수밖에 없습니다. 하지만 PDF 를 만드는 데 걸리는 40초는 그대로입니다. 옮긴 것은 처리 시간이 아니라 기다리는 사람입니다. 이 차이를 놓치면 느린 원인을 덮어 둔 채 넘어가고, 월요일 아침처럼 요청이 몰리는 시간대에 대기 줄이 30분까지 늘어난 뒤에야 문제가 드러납니다.

뒤에서 도니까 실패해도 사용자에게 안 보인다고 여기는 것도 흔합니다. 화면에 오류가 뜨지 않으니 조용히 넘어간 것처럼 느껴집니다. 실제로는 반대입니다. 응답이 없는 실패는 아무도 모르는 실패라서, 실패 기록과 알림을 따로 만들어 두지 않으면 사고를 개발팀이 아니라 고객이 먼저 발견합니다. 그러면 "결제했는데 영수증 메일이 안 와요" 같은 문의가 며칠 치 쌓인 뒤에야 원인을 찾게 됩니다.