INNORIX
전송 빌더전송 파인더개발자리소스고객사
무료 시작하기
INNORIX

LET FILES
MOVE THEMSELVES

INNORIX는 모든 시스템과 환경에서 파일 이동과 자동화를 제공하는 엔터프라이즈 파일 인프라 기업입니다.
5,000개 이상의 기업 및 공공기관에서 사용하고 있습니다.

시작하기

  • 필요한 전송 만들기
  • 필요한 전송 찾기

주요 전송

  • 팀 업무 폴더 동기화
  • 고객에게 대용량 파일 전송
  • 여러 시스템 파일 탐색
  • FTP·SFTP·SCP·rsync 전환
  • 앱에 파일 전송 추가
  • 웹 업로드·다운로드 적용
  • AI·데이터 워크플로 구축
  • 모든 전송 둘러보기→

개발자

  • 개발자 센터
  • 구현 예제
  • API 빠른 시작
  • 개발자 가이드
  • API 레퍼런스
  • GitHub

리소스

  • 리소스 센터
  • 제품 가이드
  • 외부 서비스 연동
  • 배포 및 관리
  • 도움말 센터

고객사

  • 정부
  • 공공부문
  • 제조
  • 엔지니어링
  • 금융
  • 유통
  • IT/통신
  • 미디어
  • 의료
  • 교육

플랜

  • 가격 및 플랜

회사

INNORIX 소개

Exabyter를 찾고 계신가요?

이제 INNORIX Platform에 통합되었습니다

기타 INNORIX 제품

Al.bert — 스마트 교통 AI

글로벌 오피스

  • 미국 뉴욕
  • 대한민국 서울
  • 베트남 호찌민
  • 오피스 위치 보기→

(C)2026 INNORIX. All rights reserved.

  • 보안
  • 상태
  • 이용약관
  • 개인정보 처리방침
  • 쿠키 정책
  1. 가이드
  2. 네트워크 중단 후 파일 전송을 자동으로 재개하기

네트워크 중단 후 파일 전송을 자동으로 재개하기

INNORIX에서 중단된 파일 전송 재개을 구성하고 연결된 시스템 간 파일 작업을 일관되게 운영하는 방법을 알아보세요.

IT 엔지니어개발자
  • AI 학습 데이터와 모델 파일의 전체 흐름 자동화하기
  • AI 모델 파일을 여러 엣지 장비에 배포하기
  • 폐쇄망·망분리 환경에서 파일을 승인 반입·반출하기
  • 승인된 파일을 여러 지점에 동시에 배포하기
  • Azure Blob에서 사내 서버로 파일 전달하기
  • 데이터베이스 덤프, 백업, 아카이브 파일을 원격 보관처로 자동 전달하기
  • 지점·공장·엣지 장비의 파일을 중앙으로 수집하기
  • CI/CD 빌드 결과물을 여러 서버에 배포하기
  • 서로 다른 클라우드 스토리지 사이에서 파일 이동하기
  • 서로 다른 AWS 계정의 S3 버킷 사이에 파일 전송하기
  • 고객별 파일 작업 공간 제공하기
  • 고객에게 만료 조건이 있는 대용량 다운로드 링크 제공하기
  • 고객이 브라우저에서 대용량 파일을 업로드하게 하기
  • 고객 작업 공간으로 대용량 파일 직접 보내기
  • 데이터베이스 백업 파일을 오브젝트 스토리지에 보관하기
  • Datadog으로 파일 전송 실패와 복구 알림 받기
  • 웹, 앱, 업무 시스템에 파일 전송 기능 추가하기
  • 파일 도착 후 검증·변환·후속 작업 실행하기
  • NAS, 파일 서버의 대량 파일을 클라우드로 이전하기
  • FTP 배치 작업을 관리형 파일 흐름으로 전환하기
  • Google Cloud Storage에서 Amazon S3로 직접 전송하기
  • Grafana에서 파일 전송 상태 대시보드 만들기
  • 전송된 파일의 해시값으로 무결성 자동 검증하기
  • 새 파일이 생기면 지정한 곳으로 자동 전송하기
  • Kubernetes에서 오브젝트 스토리지로 결과 파일 보내기
  • Git 밖의 대용량 파일과 빌드 결과물 자동 전달하기
  • Git으로 관리하기 어려운 파일을 자동 전달하기
  • 분산 서버의 로그·진단 파일을 중앙으로 모으기
  • 미디어 원본과 처리 결과를 단계별로 자동 전달하기
  • 수신 파일을 Microsoft Defender로 검사하고 후속 처리하기
  • 여러 단계의 파일 전송을 하나의 흐름으로 자동화하기
  • 승인된 파일을 여러 팀·지점에 자동 배포하기
  • 협력사 파일을 업무 시스템으로 자동 분류하기
  • 협력사·공급망과 정기적으로 파일 교환하기
  • 매일·매주 반복되는 파일 전송 자동화하기
  • 네트워크 중단 후 파일 전송을 자동으로 재개하기
  • rsync 작업을 관리형 파일 흐름으로 전환하기
  • 정해진 시간에 반복 파일 전송 예약하기
  • 소프트웨어·펌웨어를 여러 장비에 배포하고 결과 확인하기
  • 소프트웨어 패키지를 여러 서버·지점에 배포하기
  • 팀 폴더의 변경 파일을 여러 장비에 자동 반영하기
  • 팀 업무 폴더를 여러 PC에 자동 반영하기
  • 여러 장비의 파일을 한곳에서 찾고 직접 전송하기
  • 웹사이트에 대용량 파일 업로드·다운로드 기능 추가하기
  • 채널을 구독해 새 파일을 자동으로 받기
  • Amazon S3에서 Azure Blob으로 직접 전송하기
  • Amazon S3에서 Cloudflare R2로 파일 이전하기
  • Amazon S3 파일을 Linux 서버로 자동 내려받기
  • SCP 셸 스크립트를 CLI 기반 전송으로 전환하기
  • SFTP 계정과 배치 전송을 중앙에서 관리하기
  • Slack·Teams에서 파일 전송을 실행하고 상태 알림 받기
  • Windows 폴더의 파일을 Amazon S3로 자동 업로드하기
  • Windows와 Linux 서버 사이에 파일을 직접 전송하기

시작하기#

기본 개념#

전송이 끊긴 위치를 기준으로 남은 파일 처리하기

파일 전송이 진행되는 동안 네트워크 연결이 끊기더라도 모든 파일의 상태가 동일하지는 않습니다.

예를 들어 여러 파일을 전송하는 도중 연결이 중단되면 일부 파일은 이미 대상 시스템에 정상적으로 반영되었을 수 있고, 특정 파일은 전송 중간에 중단되며, 이후 파일은 아직 전송을 시작하지 않은 상태일 수 있습니다.

따라서 재개 작업에서는 단순히 전체 작업을 다시 실행하는 것이 아니라 현재 파일별 처리 상태를 기준으로 다시 처리해야 하는 범위를 결정합니다.

파일 상태 중단 시점의 상태 연결 복구 후 처리
완료 파일 대상에 정상 반영 다시 전송하지 않음
전송 중 파일 중간에 연결 중단 중단 지점부터 재개
대기 파일 아직 전송 시작 전 순서에 따라 전송 시작
실패 파일 전송 또는 연결 오류 발생 재시도 정책 적용

예를 들어 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에서 복구 과정 확인 → 대상 파일 반영 검증까지 하나의 흐름으로 구성할 수 있습니다.

이를 통해 네트워크가 일시적으로 불안정한 환경에서도 전체 파일을 처음부터 다시 전송하지 않고, 이미 완료된 작업은 유지하면서 실제로 복구가 필요한 부분만 이어서 처리하는 전송 환경을 구성할 수 있습니다.

이전매일·매주 반복되는 파일 전송 자동화하기다음rsync 작업을 관리형 파일 흐름으로 전환하기

이 페이지에서

  • 시작하기
  • 기본 개념
  • 재개 기준
  • 복구 흐름
  • IT 엔지니어
  • 복구 정책
  • 상태 확인
  • 실패 재처리
  • 최종 확인