이어서 하기 — 중단된 작업을 처음부터 다시 돌릴 때 생기는 비용 (2026)

오래 걸리는 작업은 반드시 한 번은 중간에 멈춥니다.

네트워크가 끊기거나, 외부 서비스가 답을 안 주거나, 서버가 재시작됩니다.

이때 설계의 차이는 “멈췄다”가 아니라 “멈춘 뒤 무엇부터 다시 하느냐”에서 갈립니다.

처음부터 다시가 기본값이면 실패 한 번의 비용이 작업 전체의 비용이 됩니다. https://dinsightlab.com

처음부터 다시가 비싼 이유

같은 작업을 다시 돌리면 시간과 돈이 두 배로 듭니다.

여기까지는 예상 가능한 비용입니다.

문제는 그 뒤입니다.

외부에 이미 보낸 요청이 다시 나갑니다.

메일이 두 번 발송되고, 주문이 두 번 접수되고, 결제가 두 번 시도됩니다.

되돌릴 수 있는 계산은 다시 해도 되지만, 밖으로 나간 동작은 다시 하면 안 됩니다.

재시작 설계의 핵심은 이 둘을 갈라 두는 일입니다.

체크포인트는 단계 사이에 둔다

중간 저장은 “오래 걸리는 단계 사이”에 둡니다.

한 단계가 끝나면 그 결과를 저장하고, 다음 단계는 저장된 결과를 읽어서 시작합니다.

이렇게 하면 중단 시 되돌아가는 거리가 한 단계로 줄어듭니다.

저장 지점이 너무 촘촘하면 저장 자체가 비용이 되고, 너무 성기면 되돌아가는 거리가 길어집니다.

기준은 단계 하나의 비용입니다.

다시 하기 아까운 단계 뒤에는 저장을 두고, 몇 초면 끝나는 계산은 그냥 다시 합니다. https://dinsightlab.com

두 번 실행해도 결과가 같게

재시작을 전제하면 같은 요청이 두 번 들어오는 상황을 피할 수 없습니다.

그래서 각 동작에 고유한 식별자를 붙이고, 이미 처리한 식별자는 건너뜁니다.

결제나 주문처럼 외부로 나가는 동작은 대부분 이 방식을 지원합니다.

지원하지 않는다면 우리 쪽에서 “이미 보냈다”는 기록을 남겨야 합니다.

기록을 남기는 시점도 중요합니다.

보내기 전에 남기면 실제로는 안 나갔는데 보냈다고 판단할 수 있고, 보낸 뒤에 남기면 그 사이에 멈췄을 때 두 번 나갑니다.

완전한 해법은 없고, 둘 중 어느 쪽 실패가 덜 아픈지로 고릅니다.

사람이 끼어드는 지점도 중단이다

중단은 사고로만 생기지 않습니다.

승인 대기처럼 의도된 중단도 있습니다.

승인을 기다리는 동안 작업이 메모리에만 있으면 서버가 재시작될 때 사라집니다.

그래서 “사람을 기다리는 상태”도 저장되어야 하고, 며칠 뒤에 이어서 진행할 수 있어야 합니다.

이 요구가 들어오는 순간 작업은 함수 호출이 아니라 상태를 가진 흐름이 됩니다.

확인 순서

1. 작업을 단계로 쪼개고 각 단계의 소요 시간과 비용을 적습니다.

2. 되돌릴 수 있는 단계와 밖으로 나가는 단계를 표시합니다.

3. 비싼 단계 뒤에 중간 저장을 둡니다.

4. 밖으로 나가는 동작에 고유 식별자를 붙입니다.

5. 사람을 기다리는 상태도 저장 대상에 넣습니다.

다섯 가지를 처음부터 다 만들 필요는 없습니다.

다만 어디까지 안 만들었는지는 알고 있어야, 사고가 났을 때 무엇이 두 번 실행될지 예상할 수 있습니다.

2026년 9월 기준으로 이런 재시작 기능을 기본으로 제공하는 도구가 늘고 있지만, 무엇을 다시 해도 되는지 정하는 일은 여전히 만드는 쪽의 몫입니다. https://dinsightlab.com