시작하기
기본 개념
전송이 끊긴 위치를 기준으로 남은 파일 처리하기
파일 전송이 진행되는 동안 네트워크 연결이 끊기더라도 모든 파일의 상태가 동일하지는 않습니다.
예를 들어 여러 파일을 전송하는 도중 연결이 중단되면 일부 파일은 이미 대상 시스템에 정상적으로 반영되었을 수 있고, 특정 파일은 전송 중간에 중단되며, 이후 파일은 아직 전송을 시작하지 않은 상태일 수 있습니다.
따라서 재개 작업에서는 단순히 전체 작업을 다시 실행하는 것이 아니라 현재 파일별 처리 상태를 기준으로 다시 처리해야 하는 범위를 결정합니다.
| 파일 상태 | 중단 시점의 상태 | 연결 복구 후 처리 |
|---|---|---|
| 완료 파일 | 대상에 정상 반영 | 다시 전송하지 않음 |
| 전송 중 파일 | 중간에 연결 중단 | 중단 지점부터 재개 |
| 대기 파일 | 아직 전송 시작 전 | 순서에 따라 전송 시작 |
| 실패 파일 | 전송 또는 연결 오류 발생 | 재시도 정책 적용 |
예를 들어 10개의 파일을 순서대로 전송하던 중 7번째 파일에서 연결이 끊겼다면, 이미 완료된 1~6번째 파일은 그대로 유지하고 중단된 파일과 이후 파일을 중심으로 작업을 이어갈 수 있습니다.
Source Files
01 ━━━━━━━━━━━━━━━━━━━━━ Completed
02 ━━━━━━━━━━━━━━━━━━━━━ Completed
03 ━━━━━━━━━━━━━━━━━━━━━ Completed
04 ━━━━━━━━━━━━━━━━━━━━━ Completed
05 ━━━━━━━━━━━━━━━━━━━━━ Completed
06 ━━━━━━━━━━━━━━━━━━━━━ Completed
07 ━━━━━━━━━━━╳ Interrupted
08 ····················· Pending
09 ····················· Pending
10 ····················· Pending
│
│ Connection Restored
▼
07 ━━━━━━━━━━━━━━━━━━━━━ Resume
08 ━━━━━━━━━━━━━━━━━━━━━ Transfer
09 ━━━━━━━━━━━━━━━━━━━━━ Transfer
10 ━━━━━━━━━━━━━━━━━━━━━ Transfer

이렇게 구성하면 연결 중단 이후에도 전체 작업을 처음부터 반복하는 대신 실제로 복구가 필요한 파일과 전송 구간만 이어서 처리하는 흐름을 만들 수 있습니다.
재개 기준
대용량 단일 파일과 여러 파일의 중단 상태 다르게 관리하기
전송 재개 방식은 전송하는 파일의 구성에 따라 다르게 활용할 수 있습니다.
하나의 대용량 파일을 전송하는 경우에는 파일 전체를 다시 보내는 대신 중단된 위치를 기준으로 남은 데이터를 이어서 처리하는 방식이 중요합니다.
반면 여러 파일을 전송하는 경우에는 이미 완료된 파일과 아직 처리되지 않은 파일을 구분하는 것이 중요합니다.
| 전송 환경 | 중단 시 상태 | 재개 방식 |
|---|---|---|
| 대용량 단일 파일 | 파일 일부 전송 완료 | 중단된 지점부터 전송 재개 |
| 다수의 파일 | 일부 파일 완료 | 완료 파일 유지 후 다음 파일 처리 |
| 여러 대상 동시 전송 | 대상별 진행 상태 다름 | 중단된 대상 중심으로 재개 |
| 정기 자동 전송 | 다음 실행 시간 존재 | 이전 실행 상태와 중복 여부 확인 |
예를 들어 수십 GB 이상의 백업 파일 하나를 원격 스토리지로 전송하는 경우와, 수천 개의 로그 파일을 여러 서버에서 수집하는 경우에는 동일한 재개 정책을 적용할 필요가 없습니다.

따라서 전송 환경을 구성할 때는 어떤 파일이 얼마나 오래 전송되는지, 중단 후 어떤 단위로 다시 처리할 것인지를 함께 고려할 수 있습니다.
복구 흐름
연결이 복구될 때까지 기다린 뒤 자동으로 전송 이어가기
일시적인 네트워크 장애가 발생했다고 해서 즉시 새로운 전송 작업을 생성할 필요는 없습니다.
연결 상태를 확인한 뒤 대상 시스템이나 네트워크가 다시 사용 가능한 상태가 되면 기존 작업의 처리 상태를 기준으로 전송을 이어갈 수 있습니다.
┌───────────────┐
│ File Transfer │
└───────┬───────┘
│
▼
Connection Lost
│
▼
┌─────────────────────┐
│ Current State Saved │
└──────────┬──────────┘
│
▼
Connection Check
↙ ↘
Not Available Restored
│ │
└────── Wait ─────┘
│
▼
Resume Transfer
│
▼
Continue Run

이 과정에서 중요한 것은 새로운 전송 요청을 만드는 것과 기존 작업을 재개하는 것을 구분하는 것입니다.
일시적인 네트워크 문제라면 기존 Run의 상태를 유지하면서 전송을 이어가고, 복구할 수 없는 문제인 경우에만 별도의 확인과 재실행이 필요합니다.
IT 엔지니어
복구 정책
네트워크 중단 시 자동으로 처리할 범위와 횟수 정하기
전송 재개 환경에서는 연결이 끊겼을 때 무조건 계속 재시도하도록 구성하기보다, 어느 정도까지 자동으로 복구할 것인지 기준을 설정합니다.
예를 들어 짧은 연결 중단은 자동으로 복구를 시도하고, 지정된 시간 동안 연결이 복구되지 않거나 반복적으로 실패하면 해당 작업을 확인이 필요한 상태로 전환할 수 있습니다.

전송 환경에 따라 다음과 같은 정책을 구성할 수 있습니다.
| 설정 항목 | 활용 |
|---|---|
| 재개 여부 | 연결 복구 후 기존 작업을 이어서 실행 |
| 재시도 횟수 | 일시적인 오류를 자동으로 다시 처리 |
| 대기 시간 | 재시도 전 연결 복구 시간 확보 |
| 실패 파일 처리 | 전체 작업 대신 실패 항목 중심으로 재처리 |
| 최종 실패 조건 | 자동 복구를 중단하고 운영 확인으로 전환 |
| 알림 조건 | 반복 실패 또는 최종 실패 발생 시 알림 |
예를 들어 본사와 지점 사이의 네트워크가 간헐적으로 끊기는 환경에서는 재시도 횟수를 충분히 설정할 수 있고, 운영 시간이 제한된 배치 작업에서는 일정 횟수 이후 바로 운영자가 확인하도록 구성할 수 있습니다.
상태 확인
Run에서 중단 원인과 파일별 처리 상태를 함께 확인하기
자동 재개가 가능한 환경이라도 연결이 반복적으로 끊기거나 특정 파일만 계속 실패하는 경우에는 실제 실행 상태를 확인해야 합니다.
Runs에서는 전체 전송 작업의 상태를 확인하고, 상세 화면에서는 파일별 처리 결과와 중단이 발생한 위치를 확인할 수 있습니다.
Run: Nightly Backup Transfer
Status
Resumed
Connection Events
22:14 Transfer Started
22:47 Connection Interrupted
22:52 Connection Restored
22:52 Transfer Resumed
23:18 Completed
Files
────────────────────────────
backup_01.tar Completed
backup_02.tar Completed
backup_03.tar Resumed
backup_04.tar Completed

이때 단순히 최종 상태만 확인하는 것이 아니라 다음 항목을 함께 살펴볼 수 있습니다.
연결이 끊긴 시점
전송이 중단된 파일 또는 구간
자동 재개가 시작된 시점
재시도된 파일
재시도 횟수
최종 전송 결과
이를 통해 자동 복구가 정상적으로 동작했는지와 실제로 어떤 파일이 영향을 받았는지 함께 확인할 수 있습니다.
실패 재처리
자동으로 복구되지 않은 파일만 다시 시도하기
연결이 복구되었더라도 특정 파일이 정상적으로 처리되지 않을 수 있습니다.
예를 들어 Source 파일이 변경되었거나 Target의 저장 공간과 접근 상태에 문제가 발생한 경우에는 단순한 네트워크 재연결만으로 작업이 완료되지 않습니다.
이 경우에는 자동 재시도와 운영자의 확인이 필요한 상황을 구분할 수 있습니다.
| 상황 | 자동 처리 | 추가 확인 |
|---|---|---|
| 일시적인 네트워크 단절 | 연결 복구 후 자동 재개 | 필요 없음 |
| 대상 서버 응답 지연 | 설정된 횟수만큼 재시도 | 반복 시 대상 상태 확인 |
| 특정 파일 전송 실패 | 해당 파일 재시도 | 계속 실패 시 파일 확인 |
| 경로 변경 | 자동 재개 중단 | Source 또는 Target 경로 수정 |
| 권한 문제 | 자동 복구 불가 | 접근 권한 조정 |
| 재시도 횟수 초과 | 최종 실패 처리 | Run 상세 확인 후 Retry |

이렇게 하면 모든 오류를 자동으로 반복 처리하지 않고, 네트워크 문제처럼 자동 복구가 가능한 상황과 설정 변경이 필요한 상황을 구분할 수 있습니다.
최종 확인
재개된 작업이 대상 시스템까지 정상적으로 완료되었는지 확인하기
전송이 다시 시작되었다고 해서 작업이 완료된 것은 아닙니다.
연결 복구와 파일 재처리가 모두 끝난 후에는 대상 시스템에 필요한 파일이 정상적으로 반영되었는지 확인합니다.
Connection Interrupted
│
▼
Transfer Paused
│
▼
Connection Restored
│
▼
Resume
│
▼
Failed Files Retried
│
▼
All Files Processed
│
▼
Target Verification
│
▼
Completed

최종 결과에서는 전송 자체의 완료 여부와 함께 실제 복구 과정도 확인할 수 있습니다.
| 확인 결과 | 의미 |
|---|---|
| Completed | 중단 이후 모든 파일이 정상적으로 처리됨 |
| Completed after Resume | 연결 복구 후 전송을 이어서 완료 |
| Completed after Retry | 실패 파일 재시도 후 완료 |
| Failed | 자동 복구 범위를 초과하거나 환경 문제 발생 |
| Action Required | 운영자가 Source·Target 또는 권한을 확인해야 함 |
이 레시피를 적용하면 전송 시작 → 네트워크 중단 감지 → 현재 처리 상태 유지 → 연결 복구 확인 → 중단된 파일과 남은 작업 재개 → 반복 실패 파일 재시도 → Run에서 복구 과정 확인 → 대상 파일 반영 검증까지 하나의 흐름으로 구성할 수 있습니다.
이를 통해 네트워크가 일시적으로 불안정한 환경에서도 전체 파일을 처음부터 다시 전송하지 않고, 이미 완료된 작업은 유지하면서 실제로 복구가 필요한 부분만 이어서 처리하는 전송 환경을 구성할 수 있습니다.