1.서론

다양한 프로젝트에 참여하며 이미지나 비디오와 같은 파일을 전송하는 기능 구현이 빈번히 요구되었다. 당시에는 단순한 구현에 그치는 경우가 많았지만, 파일 전송은 오버헤드가 큰 작업으로 요구사항과 서비스 성능 등 여러 측면에서 신중한 고려가 필요하다는 점을 깨달았다. 또한, 현재 존재하는 다양한 구현 방식에 대한 자료들을 접하며 선택 가능한 방법과 동작 원리에 대한 설명이 부족하다는 점을 느꼈고, 이를 직접 정리해보고자 한다.

2절에서는 파일 전송을 위한 통신 방식의 선택지를, 3절에서는 클라이언트 측 파일 전송 방식의 선택지를, 4절에서는 저장 아키텍처 설계 옵션을 소개한다.

결론에서는 각 방식을 비교하고, 상황에 따른 적절한 선택지와 권장 사항을 제시한다.

2. 파일 전송을 위한 통신 방식의 비교

2.1. HTTP POST 요청과 MIME을 통한 파일 전송

가장 일반적으로 사용되는 방법은 HTTP POST 요청을 통해 이미지 파일을 전송하는 것이다. 이 방법은 클라이언트(프론트엔드)가 서버(백엔드)에 파일을 전송하는 기본적인 방식이다.

  • Content-Type: 전송할 때 Content-Type 헤더를 multipart/form-data로 설정하여 파일을 전송한다. 이 방식은 파일과 데이터를 함께 전송하는데 적합하다.
  • 데이터 포맷: FormData 객체를 사용하여 파일을 포함한 데이터를 생성하고 전송한다. 이는 브라우저가 자동으로 MIME 타입과 경계를 처리해준다.

multipart/form-data는 MIME(Multipurpose Internet Mail Extensions)의 일종이다. 이 유형의 MIME는 주로 웹 폼을 통해 파일과 데이터를 함께 전송할 때 사용된다.

  • 장점: 파일과 다른 데이터 필드를 함께 전송할 수 있어 유연하게 사용할 수 있다. 대부분의 서버 프레임워크에서 이 방식을 지원하며, 구현이 상대적으로 간단하다.

  • 단점: 폼 데이터를 인코딩하고 디코딩하는 과정에서 오버헤드가 발생할 수 있다. 특히 대용량 파일의 경우 속도가 느려질 수 있다.

MIME과 multipart/form-data

  • MIME 타입: MIME은 인터넷에서 파일의 유형을 정의하기 위해 사용되는 표준이다. multipart/form-data는 여러 개의 부분으로 나뉘어진 데이터를 포함할 수 있는 MIME 타입으로, 각 부분은 자체적으로 독립적인 콘텐츠 타입을 가질 수 있다.

  • 사용 용도: 일반적으로 HTML 폼에서 파일 업로드와 같은 다양한 데이터 타입을 전송하기 위해 사용된다. 예를 들어, 이미지 파일, 텍스트 데이터 등을 함께 전송할 수 있다.

  • 구조: multipart/form-data는 각 데이터 부분이 boundary로 구분되며, 각 부분은 헤더와 본문으로 구성된다. 헤더는 해당 부분의 메타데이터를 포함하고, 본문은 실제 데이터이다.

따라서 multipart/form-data는 MIME의 한 종류이며, 주로 웹에서 파일 업로드와 같은 작업에 널리 사용된다.

예시 코드 (JavaScript) 
  const formData = new FormData(); formData.append('image', selectedFile); // selectedFile은 사용자가 선택한 파일 객체

  fetch('/upload', { method: 'POST', body: formData, }) 
  .then(response => response.json()) 
  .then(data => { console.log('Success:', data); }) 
  .catch((error) => { console.error('Error:', error); });

2.2. Base64 인코딩을 통한 이미지 전송

이미지를 Base64로 인코딩하여 텍스트 데이터로 변환한 후 전송하는 방식이다. 이때 JSON 요청의 본문(body) 등에 Base64 인코딩된 이미지를 넣어 전송한다. 이 방식은 이미지 데이터가 상대적으로 작을 때 유용하다.

  • 인코딩: 이미지를 Base64로 인코딩하면 바이너리 데이터가 문자열 형식으로 변환된다.

  • 전송: 이 문자열을 JSON 형태로 포함하여 전송할 수 있다.

  • 장점: 이미지 데이터를 텍스트 형태로 전송하기 때문에 특정 상황에서 HTTP 헤더에 맞추기 쉬우며, 간단하게 데이터를 송수신할 수 있다.
  • 단점: 이미지 크기가 30% 정도 더 커지기 때문에 네트워크 부하가 증가할 수 있으며, Base64 인코딩/디코딩의 추가 처리 과정이 필요하다.
예시 코드 (JavaScript) 

  const reader = new FileReader(); reader.onloadend = function() { const base64data = reader.result; // Base64 인코딩된 이미지 데이터 
  fetch('/upload', { 
  method: 'POST', 
  headers: { 'Content-Type': 'application/json', }, 
  body: JSON.stringify({ image: base64data }), }) 
  .then(response => response.json()) 
  .then(data => { console.log('Success:', data); }) 
  .catch((error) => { console.error('Error:', error); }); }; 

  reader.readAsDataURL(selectedFile); // selectedFile은 사용자가 선택한 파일 객체

2.3. Websocket을 사용한 방식

WebSocket을 사용하면 클라이언트와 서버 간의 지속적인 연결을 유지하면서 이미지를 전송할 수 있다. 이는 실시간 통신이 필요한 애플리케이션에서 유용하다.

  • 전송: WebSocket을 통해 바이너리 데이터를 전송할 수 있으며, 이미지 파일을 Blob 형태로 전송할 수 있다.
예시 코드 (JavaScript) 
  const socket = new WebSocket('ws://yourserver.com/socket');

  socket.addEventListener('open', function (event) { const reader = new FileReader(); 
  reader.onload = function() { const arrayBuffer = reader.result; // ArrayBuffer로 읽어들인다. 
  socket.send(arrayBuffer); // 이미지 데이터 전송 
  }; 

  reader.readAsArrayBuffer(selectedFile); // selectedFile은 사용자가 선택한 파일 객체 });

2.4. 스트림 방식

이미지 데이터를 일정 크기로 잘라 스트림 형태로 전송하는 방식이다. 이는 주로 chunked 전송 또는 WebSocket을 통해 이미지 데이터의 일부를 지속적으로 백엔드에 전송할 때 사용된다. 스트림 전송은 연속된 데이터의 흐름을 실시간으로 전송하는 방식이다. 스트림은 일반적으로 데이터가 준비됨에 따라 즉시 전송되며, 청크와 다르게 별도의 종료 신호를 통해 끝나는 것이 아닌, 스트림 종료로 데이터를 처리한다. 스트림 방식은 실시간 데이터를 클라이언트와 서버 간에 지속적으로 전송하는 데 적합하며, 데이터 전송 중간에 양방향 통신이 가능하다.

  • 장점: 대용량 파일을 효율적으로 전송할 수 있어 실시간 전송에 적합하다. 특히 대용량 미디어 파일이나 실시간 이미지 전송(예: CCTV나 라이브 스트리밍)에 유리하다.
  • 단점: 구현이 다소 복잡하며, 서버와 클라이언트 모두 스트림 데이터를 처리할 수 있어야 한다. 일반적인 API 요청 방식보다 비동기 처리와 연결 관리가 더 어렵다.

스트림 형태는 데이터를 한 번에 모두 전송하지 않고, 작은 조각으로 나누어 일정한 순서로 연속적으로 전송하는 방식이다. 스트림은 데이터의 흐름을 의미하며, 이를 통해 데이터를 실시간으로 읽고 쓸 수 있다. 파일이나 대용량 데이터를 모두 메모리에 로드하지 않고 순차적으로 처리할 수 있어 메모리 사용량을 절약하고 효율적인 처리가 가능하다.

예시 코드 (JavaScript)

이 예시에서는 서버가 이미지 파일을 스트림으로 클라이언트에 전송하며, 클라이언트는 이를 Blob 객체로 받아서 이미지를 표시한다.

  • 서버
  const express = require('express');
  const fs = require('fs');
  const path = require('path');

  const app = express();
  const PORT = 3000;

  // 이미지 스트림 전송 엔드포인트
  app.get('/stream-image', (req, res) => {
    const imagePath = path.join(__dirname, 'image.jpg'); // 전송할 이미지 경로
    const readStream = fs.createReadStream(imagePath); // 이미지 스트림 생성
    
    // 클라이언트로 이미지 스트림 전송
    res.setHeader('Content-Type', 'image/jpeg');
    readStream.pipe(res);
  });

  app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
  });
  • 클라이언트
  fetch('http://localhost:3000/stream-image')
    .then(response => response.blob())
    .then(blob => {
      const imageURL = URL.createObjectURL(blob); // Blob 객체로부터 이미지 URL 생성
      const img = document.createElement('img');
      img.src = imageURL; // 이미지 URL을 img 태그에 적용
      document.body.appendChild(img); // 이미지 렌더링
    })
    .catch(error => console.error('Error fetching the image:', error));

2.5. Chunked 전송 방식

Chunked 전송은 데이터를 일정한 크기의 청크(조각)로 나누어 전송하는 방식이다. HTTP/1.1 프로토콜의 전송 인코딩 기능 중 하나로, 서버가 응답을 동적으로 생성해야 하거나 데이터의 총 크기를 미리 알 수 없을 때 유용하다. 이 방식에서는 청크 단위로 데이터를 보내며, 각 청크에는 청크의 길이를 명시하는 메타데이터가 포함된다. 클라이언트는 모든 청크가 전송될 때까지 데이터를 수신하며, 마지막 청크를 통해 전송 종료를 알 수 있다.

  • 특징: 데이터를 조각내어 전송하지만, 각 청크는 전체 메시지의 일부로서 전달된다.
  • 장점: 데이터의 총 크기를 알 수 없는 상황에서 유리하며, 동적 콘텐츠 응답을 효율적으로 처리할 수 있다.
  • 적용 예시: HTML 페이지 또는 대형 JSON 데이터를 청크 단위로 클라이언트에게 스트리밍하는 경우.

Chunked 전송은 데이터를 일정한 크기의 청크(chunk) 단위로 나누어 순차적으로 전송하는 방식이다. 주로 HTTP 프로토콜에서 Transfer-Encoding: chunked 헤더와 함께 사용되며, 데이터가 준비되는 즉시 나누어 보내므로 대용량 데이터 전송이나 실시간 전송에 유리하다. 청크 전송을 통해 수신 측은 데이터의 전체 길이를 미리 알지 않아도 점진적으로 데이터를 처리할 수 있다.

예시 코드 (JavaScript)

Express에서 Chunked 전송 방식을 명확히 구현한 예시 코드다. 이 예시에서는 이미지 데이터를 청크 크기를 명시하며 전송한다.

  // server.js

  const express = require('express');
  const fs = require('fs');
  const path = require('path');

  const app = express();
  const PORT = 3000;

  // 이미지 요청 처리 라우트
  app.get('/image', (req, res) => {
      const imagePath = path.join(__dirname, 'path/to/your/image.jpg');
      const readStream = fs.createReadStream(imagePath);
      
      // Transfer-Encoding을 chunked로 설정
      res.setHeader('Content-Type', 'image/jpeg');
      res.setHeader('Transfer-Encoding', 'chunked');

      readStream.on('data', (chunk) => {
          // 각 청크를 보내기 전에 크기 정보를 추가
          res.write(chunk.length.toString(16) + '\r\n');
          res.write(chunk);
          res.write('\r\n');
      });

      readStream.on('end', () => {
          // 마지막 청크 전송
          res.write('0\r\n\r\n');
          res.end();
      });

      readStream.on('error', (error) => {
          console.error('Error reading the image:', error);
          res.sendStatus(500);
      });
  });

  // 서버 시작
  app.listen(PORT, () => {
      console.log(`Server is running on http://localhost:${PORT}`);
  });
  • res.setHeader('Transfer-Encoding', 'chunked')로 응답 헤더에 청크 전송을 명시한다.
  • data 이벤트 핸들러 내에서 각 청크의 길이를 16진수로 전환하고, 청크 크기와 데이터를 함께 전송한다.
  • end 이벤트에서 마지막 청크를 나타내는 “0\r\n\r\n”을 전송하여 클라이언트에게 전송 완료를 알린다.

2.5.1 chunked방식과 stream방식의 차이:

Chunked 전송과 스트림 전송은 모두 데이터를 나누어 보내는 방식이지만, 구현 방식과 데이터 처리 방식에서 차이가 있다.

특성 Chunked 전송 스트림 전송
전송 구조 일정 크기의 청크로 나눠서 전송 연속된 데이터의 흐름을 전송
종료 신호 마지막 청크에 종료 신호 포함 스트림 종료로 전체 데이터 전송 완료 표시
실시간성 실시간보다는 일괄 처리에 가까움 실시간 처리에 적합
주요 활용 HTTP 응답, 동적 HTML/JSON 데이터 전송 비디오/오디오 스트리밍, 실시간 데이터 전송

결론적으로, Chunked 전송은 정해진 크기의 청크로 데이터를 일괄 전송할 때 유리한 반면, 스트림 전송은 실시간 데이터를 전송하는 데 최적화되어 있다.

2.6. 파일전송 프로토콜 사용(FTP)

FTP (File Transfer Protocol)는 파일 전송을 위한 표준 네트워크 프로토콜로, 여러 클라이언트와 서버 간에 파일을 전송할 수 있도록 한다. FTP의 보안성을 높이기 위한 방법으로 SFTP와 FTPS가 있다. 아래에서는 FTP, SFTP, FTPS의 개념과 특징을 설명하겠다.

2.6.1. FTP (File Transfer Protocol)

FTP는 클라이언트와 서버 간에 파일을 전송하는 데 사용되는 프로토콜이다. FTP는 TCP/IP 프로토콜 위에서 동작하며, 주로 다음과 같은 기능을 제공한다.

  • 파일 전송: 클라이언트에서 서버로 또는 서버에서 클라이언트로 파일을 전송할 수 있다.
  • 디렉터리 목록: 서버의 파일 및 디렉터리 목록을 조회할 수 있다.
  • 파일 삭제 및 이름 변경: 서버에서 파일을 삭제하거나 이름을 변경할 수 있다.

FTP는 기본적으로 암호화되지 않으므로 보안에 취약하다.

2.6.2. SFTP (SSH File Transfer Protocol)

SFTP는 SSH(Secure Shell) 프로토콜을 통해 파일 전송을 수행하는 프로토콜이다. SFTP는 FTP와는 달리 보안성을 고려하여 설계되었으며, 주요 특징은 다음과 같다.

  • 암호화: 모든 데이터 전송이 SSH를 통해 암호화되므로 보안성이 높다.
  • 단일 연결: 데이터와 제어 신호가 같은 연결을 통해 전달된다.
  • 방화벽 친화적: 포트가 하나만 사용되기 때문에 방화벽에서 관리하기가 용이하다.

SFTP는 비밀번호 인증 외에도 공개키 기반 인증을 지원하여 보안성을 더욱 강화할 수 있다.

2.6.3. FTPS (FTP Secure)

FTPS는 FTP 프로토콜에 SSL/TLS 보안 프로토콜을 추가하여 보안성을 강화한 것이다. FTPS는 두 가지 모드, 즉 명시적(Explicit)과 암시적(Implicit) 모드로 운영된다.

  • 명시적 FTPS: 클라이언트가 FTP 서버에 연결한 후, 명시적으로 SSL/TLS 암호화를 요청한다. 일반 FTP 포트(21번)를 사용한다.
  • 암시적 FTPS: 클라이언트가 SSL/TLS 연결을 위해 전용 포트(990번)로 직접 연결한다. 연결이 설정될 때부터 암호화된다.

FTPS는 기존의 FTP와 호환성이 있으나, 추가적인 보안 계층을 제공하여 전송 중 데이터의 기밀성을 보장한다.

2.6.4. 파일전송 프로토콜 비교

특성 FTP SFTP FTPS
보안 수준 낮음 높음 높음
암호화 없음 SSH로 암호화 SSL/TLS로 암호화
포트 사용 21번 (제어) 22번 21번 (명시적), 990번 (암시적)
연결 구조 별도 제어 및 데이터 채널 단일 채널 별도 제어 및 데이터 채널
방화벽 친화성 낮음 높음 중간
  • FTP는 기본 파일 전송 프로토콜이지만 보안성이 부족하다.
  • SFTP는 SSH를 기반으로 하여 높은 보안성을 제공한다.
  • FTPS는 SSL/TLS를 사용하여 FTP의 보안성을 강화한 방법이다.
  • SFTP와 FTPS는 모두 안전한 파일 전송을 위해 널리 사용된다.

3. 클라이언트 이미지 전송 전략

3.1 Blob(Binary Large Object) 객체로 메모리에 파일 전체를 로드하고 사용

프론트엔드에서 Blob 형태로 이미지를 백엔드에 전송하는 방식이다. Blob 객체는 파일 데이터에 대한 원시적인 접근을 제공하며, 특정 조건에서는 스트림 방식으로 처리될 수도 있다. 웹에서 바이너리 데이터를 다루기 위해 사용하는 방식으로, 파일이나 이미지와 같은 큰 이진 데이터를 다룰 때 자주 사용된다. Blob 객체는 JavaScript에서 제공하는 데이터 타입으로, 텍스트, 이미지, 비디오 등 다양한 형태의 데이터를 파일 형태로 저장하고 전송할 수 있게 해준다.

  • 장점: 다른 데이터와는 별도로 원시 바이너리 데이터를 직접 전송하므로 효율적이다.
  • 단점: 브라우저 내 메모리에 큰 데이터를 올려서 파일처럼 취급할 수 있다. 하지만 클라이언트 측의 메모리에 의존하기 때문에 지나치게 큰 데이터를 사용하면 메모리 부담이 될 수 있다.
예시 코드 (JavaScript) 
  // HTML에서 이미지 파일을 선택하는 input 요소
  <input type="file" id="imageInput" />

  // Blob으로 변환하고 서버로 전송하는 JavaScript 코드
  const inputElement = document.getElementById('imageInput');
  inputElement.addEventListener('change', async (event) => {
    const file = event.target.files[0];
    
    if (file) {
      // Blob 객체 생성
      const blob = new Blob([file], { type: file.type });

      // Fetch API를 이용한 서버 전송
      const formData = new FormData();
      formData.append('file', blob, file.name);

      try {
        const response = await fetch('/upload', {
          method: 'POST',
          body: formData,
        });
        if (response.ok) {
          console.log('File uploaded successfully');
        } else {
          console.error('File upload failed');
        }
      } catch (error) {
        console.error('Error uploading file:', error);
      }
    }
  });

3.2 Readstream으로 메모리에 파일 일부만 로드하여 사용

이미지와 같은 대용량 파일을 클라이언트에서 업로드할 때, 전체 파일을 한 번에 메모리에 로드하는 방식은 메모리 사용량이 많아 효율적이지 않다. 이를 개선하기 위해 ReadStream을 사용하면 파일을 일정 크기로 나누어 메모리에 부분적으로 로드하고 전송할 수 있다.

장점

  • 메모리 효율성: 한 번에 전체 파일을 로드하지 않아 메모리 사용량을 줄일 수 있다.
  • 대용량 파일 처리 가능: 제한된 메모리에서도 큰 파일을 처리할 수 있다.
  • 전송 제어 용이성: 각 청크(chunk)를 제어하거나 전송 상태를 모니터링할 수 있다.

단점

  • 구현 복잡성: 단순 업로드 방식에 비해 스트리밍 로직을 추가 구현해야 한다.
  • 전송 속도 영향: 청크 크기와 네트워크 조건에 따라 전송 속도가 달라질 수 있다.

구현 방식

  1. 파일을 ReadStream으로 읽어들인다.
  2. 읽은 데이터를 HTTP/2 또는 WebSocket 등으로 서버에 전송한다.
  3. 서버에서 데이터를 청크 단위로 받아서 처리하거나, 최종적으로 파일을 재구성한다.
예시 코드 (JavaScript) 
  const fs = require('fs');
  const axios = require('axios');

  const filePath = './large-image.jpg';
  const serverEndpoint = 'https://example.com/upload';

  const stream = fs.createReadStream(filePath);

  stream.on('data', (chunk) => {
    console.log(`Sending chunk of size: ${chunk.length}`);
    axios.post(serverEndpoint, chunk, {
      headers: {
        'Content-Type': 'application/octet-stream',
      },
    }).catch(err => console.error('Error sending chunk:', err));
  });

  stream.on('end', () => {
    console.log('File upload completed');
  });

#### 클라이언트에서 사용할 전송 프로토콜

  • HTTP/2: 멀티플렉싱을 지원하여 하나의 연결에서 여러 청크를 동시에 전송할 수 있어 효율적이다. 대규모 데이터 전송 시에도 안정성과 성능을 유지할 수 있다.
  • WebSocket: 양방향 통신을 지원하므로, 클라이언트와 서버 간에 실시간 데이터 스트리밍이 필요한 경우 적합하다.
  • GRPC: Protocol Buffers 기반의 효율적인 직렬화와 HTTP/2를 활용하여 고성능 스트리밍을 제공한다. 특히, 마이크로서비스 환경에서 추천된다.

ReadStream을 이용한 스트리밍 방식은 대용량 파일 전송에서 효율적인 선택지가 될 수 있으며, 특히 제한된 리소스를 사용하는 환경에서 유리하다.

3.2 Readstream으로 메모리에 파일 일부만 로드하여 사용

4. 백엔드 선택 옵션

–

백엔드에서 이미지를 수신하고 처리하는 방식은 주로 데이터의 크기, 처리 성능, 시스템의 리소스 상황에 따라 달라진다. 이미지 업로드를 처리하는 백엔드 시스템은 데이터를 효율적으로 저장하고, 전송 중 오류를 최소화하는 동시에 최적의 성능을 보장해야 한다. 아래에서는 이미지 업로드 시 사용할 수 있는 여러 가지 저장 방식과 관련된 구현 옵션을 설명한다.

4.1. In-Memory Buffering (메모리 버퍼링)

In-Memory Buffering은 데이터가 서버로 전송될 때 메모리에 저장된 후 필요한 경우 디스크로 옮겨지는 방식이다. 주로 소규모 이미지 파일 처리에 적합하며, 메모리의 빠른 접근 속도를 활용하여 처리 성능을 극대화한다. 하지만 메모리 용량에 제한이 있기 때문에 대용량 파일을 처리하는 경우 시스템의 성능을 저하시킬 수 있다.

4.1.1. 특징

  • 빠른 데이터 접근 속도: 메모리에 데이터를 저장하기 때문에 디스크보다 빠르게 데이터를 처리할 수 있다.
  • 소규모 데이터 처리에 유리: 이미지 파일이 작거나 중간 크기의 경우 유리하다.
  • 메모리 제한: 대용량 파일을 처리할 때는 메모리 부족 문제가 발생할 수 있다.
예시 코드 (클라이언트 - 스트림 방식)

클라이언트는 fetch API나 XMLHttpRequest를 사용하여 데이터를 스트리밍 형식으로 서버에 전송할 수 있다.

클라이언트에서 이미지 파일을 스트리밍하여 전송하는 예시는 아래와 같다:

  const file = document.getElementById('imageInput').files[0];
  const formData = new FormData();
  formData.append('image', file);

  fetch('/upload', {
    method: 'POST',
    body: formData,
  }).then(response => {
    console.log('Upload successful');
  }).catch(error => {
    console.error('Upload error', error);
  });
예시 코드 (서버 - 스트림 방식)

클라이언트는 fetch API나 XMLHttpRequest를 사용하여 데이터를 스트리밍 형식으로 서버에 전송할 수 있다.

클라이언트에서 이미지 파일을 스트리밍하여 전송하는 예시는 아래와 같다:

  const express = require('express');
  const fs = require('fs');
  const app = express();
  const multer = require('multer');
  const upload = multer({ storage: multer.memoryStorage() });  // 메모리 저장 방식

  // 스트리밍 방식으로 파일 업로드 처리
  app.post('/upload', upload.single('image'), (req, res) => {
    const imageBuffer = req.file.buffer;  // 파일이 메모리에 저장됨

    // In-Memory Buffering: 메모리에서 처리 (디스크로 저장하지 않고 메모리에서 바로 처리)
    // 예시로 이미지 크기를 확인하거나 다른 처리를 할 수 있습니다.
    console.log('파일 크기:', imageBuffer.length);

    // 메모리에서 처리 후 응답
    res.status(200).send('파일 업로드 완료');
  });

  app.listen(3000, () => {
    console.log('서버가 3000번 포트에서 시작됨');
  });
예시 코드 (백엔드 - 멀티파트 방식)

백엔드에서 클라이언트로부터 이미지 파일을 멀티파트 방식으로 수신받는 방법은 아래와 같다. Node.js의 express와 multer를 사용한 예시를 제공한다.

  const express = require('express');
  const multer = require('multer');
  const upload = multer({ storage: multer.memoryStorage() });

  const app = express();

  app.post('/upload', upload.single('image'), (req, res) => {
    const imageBuffer = req.file.buffer;
    // 메모리에 저장된 이미지 파일을 처리하는 로직을 추가
    res.send('Image uploaded successfully');
  });

  app.listen(3000, () => console.log('Server running on port 3000'));

4.2. Direct-to-Disk Storage (디스크 직접 저장)

Direct-to-Disk Storage는 데이터가 서버로 전송될 때 즉시 디스크에 기록되는 방식으로, 메모리 사용을 최소화하는 방법이다. 대용량 이미지 파일을 처리할 때 유용하며, 메모리 부족을 방지할 수 있다. 그러나 디스크에 데이터를 직접 기록하는 방식은 메모리보다 처리 속도가 느려질 수 있다는 단점이 있다.

4.2.1. 특징

  • 메모리 절약: 데이터가 바로 디스크로 기록되므로 메모리의 부담이 적다.
  • 대용량 파일 처리에 유리: 큰 이미지 파일을 처리하는 데 적합하다.
  • 속도 저하: 디스크 접근이 메모리보다 느리므로 성능에 영향을 줄 수 있다.
예시 코드 (백엔드 - 멀티파트 방식)

백엔드에서는 파일을 디스크에 직접 저장하는 방식으로 처리한다. multer를 사용하여 파일을 디스크에 저장하는 예시는 아래와 같다.

  const express = require('express');
  const multer = require('multer');
  const upload = multer({ dest: 'uploads/' });

  const app = express();

  app.post('/upload-to-disk', upload.single('image'), (req, res) => {
    const filePath = req.file.path;
    // 디스크에 저장된 파일 경로를 사용하여 후속 처리
    res.send(`File uploaded successfully to ${filePath}`);
  });

  app.listen(3000, () => console.log('Server running on port 3000'));

4.3. Hybrid Storage (하이브리드 저장)

하이브리드 저장 방식은 메모리 버퍼링과 디스크 직접 저장을 조합한 방식이다. 대용량 파일을 처리할 때, 데이터를 메모리에 잠시 저장한 후 일정 용량이 넘으면 디스크에 저장하는 방식이다. 이 방식은 메모리의 속도를 유지하면서도, 메모리 부족 문제를 방지할 수 있다.

4.3.1. 특징

  • 빠른 성능과 효율적인 메모리 사용: 메모리와 디스크의 장점을 결합하여 효율적으로 데이터를 처리한다.
  • 복잡한 구현: 두 가지 방식을 적절히 조합해야 하므로 구현이 다소 복잡할 수 있다.
예시 코드 (JavaScript)

multer를 사용하여 메모리 버퍼링 후, 일정 크기 이상이면 디스크에 저장하는 방법을 구현할 수 있다.

  const express = require('express');
  const multer = require('multer');
  const upload = multer({ 
    storage: multer.memoryStorage(), 
    limits: { fileSize: 5 * 1024 * 1024 }  // 5MB 제한
  });

  const app = express();

  app.post('/upload-hybrid', upload.single('image'), (req, res) => {
    if (req.file.size > 5 * 1024 * 1024) {  // 5MB 이상이면 디스크에 저장
      const diskStorage = multer({ dest: 'uploads/' });
      diskStorage.single('image');
      res.send('File uploaded and stored on disk');
    } else {
      const imageBuffer = req.file.buffer;
      res.send('File uploaded to memory');
    }
  });

  app.listen(3000, () => console.log('Server running on port 3000'));

4.4. 결론

이미지 업로드 구현 시, 백엔드에서의 저장 방식은 데이터의 크기와 서버의 리소스 상태에 따라 적절히 선택해야 한다. In-Memory Buffering은 빠른 데이터 접근을 제공하지만, 메모리 부족 문제가 발생할 수 있고, Direct-to-Disk Storage는 대용량 데이터를 처리하는 데 유리하나 속도가 다소 느릴 수 있다. Hybrid Storage 방식은 이 두 가지 방법을 결합하여 성능과 메모리 효율성을 동시에 고려할 수 있다. 각 방식의 장단점을 잘 이해하고, 시스템에 맞는 방식을 선택하는 것이 중요하다.

5. 이미지 저장 아키텍처 설계 옵션

5.1. 백엔드 서버에 직접 저장

백엔드 서버의 파일 시스템에 이미지를 직접 저장하는 방법이다. 이 방식은 서버의 저장 공간을 직접 관리할 수 있기 때문에 관리 측면에서 단순하다. 그러나 서버의 디스크 용량이 한정되어 있어 이미지가 많아지면 서버의 저장 공간이 부족할 수 있고, 이를 해결하려면 서버 확장이나 저장소 관리를 위한 추가 비용이 발생할 수 있다. 또한, 대용량 이미지 데이터를 저장할 경우 성능 저하가 발생할 수 있다.

5.1.1. 장점

  • 직접적인 파일 시스템 관리가 가능하다.
  • 별도의 외부 서비스를 이용하지 않으므로 초기 설정이 간단하다.
  • 서버 내에서 이미지 저장과 관련된 모든 작업을 처리할 수 있어 편리하다.

5.1.2. 단점

  • 서버의 저장 공간에 제한이 있어 대규모 환경에서 확장이 어려울 수 있다.
  • 서버 장애 시 데이터 손실 위험이 있을 수 있다.
  • 데이터 복구나 백업 관리가 복잡할 수 있다.

5.2. 클라우드 S3 이용

Amazon S3와 같은 클라우드 스토리지 서비스를 이용하여 이미지를 저장하는 방식이다. S3는 고가용성과 확장성을 제공하며, 대규모 데이터를 효율적으로 관리할 수 있다. 클라우드 환경에서 자동으로 확장되므로, 파일이 많아지거나 서버의 용량이 부족할 때 유연하게 대응할 수 있다. 또한, 안정성이 높고 백업이나 장애 복구가 용이하다.

5.2.1. 장점

  • 확장성이 뛰어나며 대규모 데이터를 손쉽게 처리할 수 있다.
  • 고가용성과 안정성 제공.
  • 백업과 복구가 간편하며, 서버 장애 발생 시에도 클라우드 서비스의 보장된 기능을 통해 복구가 가능하다.

5.2.2. 단점

  • 외부 서비스를 사용하므로 비용이 발생할 수 있다.
  • 인터넷 연결 상태에 따라 업로드 및 다운로드 속도가 영향을 받을 수 있다.
  • 데이터를 클라우드로 전송하는데 시간이 걸릴 수 있다.

5.3 프리싸인 URL 이용 (Presigned URL)

클라이언트가 이미지 파일을 직접 클라우드 스토리지로 업로드할 수 있도록 하는 방식이다. 서버는 프리싸인 URL을 생성하여 클라이언트에게 전달하고, 클라이언트는 해당 URL을 통해 이미지를 클라우드로 업로드한다. 이를 통해 서버는 파일 전송을 처리하지 않으므로, 서버의 부담을 줄일 수 있다. 특히 대용량 파일을 처리할 때 유용하다.

5.3.1. 장점

  • 서버 부담을 줄일 수 있다.
  • 클라이언트가 직접 업로드하기 때문에 서버에서 파일을 처리하지 않아 성능이 향상된다.
  • 파일 전송에 대해 서버 측에서 별도의 처리 없이 클라우드 스토리지에서 직접 업로드가 이루어져 효율적이다.

5.3.2. 단점

  • 프리싸인 URL의 유효시간 관리가 필요하다.
  • URL 생성 과정에서 보안 이슈가 발생할 수 있다.
  • 클라이언트 측에서의 파일 업로드 오류가 발생할 수 있다.

5.4. 분산 파일 시스템

Hadoop HDFS, Ceph 등과 같은 분산 파일 시스템을 이용하여 대규모 환경에서 이미지를 저장하는 방법이다. 이러한 시스템들은 데이터의 분산 저장과 고가용성을 보장하며, 장애 복구 기능을 제공한다. 특히, 여러 서버에 데이터를 분산하여 저장하기 때문에 대용량 파일 처리에 효율적이다. 데이터 손실 방지와 성능 최적화를 위한 다양한 기능들이 포함되어 있다.

5.4.1. 장점

  • 고가용성과 장애 복구를 지원한다.
  • 대용량 데이터를 효율적으로 저장하고 관리할 수 있다.
  • 데이터 분산 저장을 통해 성능을 최적화할 수 있다.

5.4.2. 단점

  • 설정과 관리가 복잡하다.
  • 하드웨어와 네트워크 자원에 의존하므로, 적절한 인프라가 필요하다.
  • 시스템을 구축하고 유지하는 데 비용이 들 수 있다.

5.5. 하이브리드 스토리지 전략

하이브리드 스토리지 전략은 일부 데이터를 로컬에 캐싱하고, 나머지는 클라우드 스토리지에 저장하는 방식이다. 이 접근 방식은 자주 사용되는 데이터는 빠르게 접근할 수 있도록 로컬에 저장하고, 덜 자주 사용되는 대용량 데이터는 클라우드에서 관리하는 방법이다. Latency를 최소화하고 비용을 절감할 수 있는 전략으로, 최적의 성능을 제공한다.

5.5.1. 장점

  • 자주 접근하는 데이터는 로컬에 저장하여 빠른 응답 속도를 제공할 수 있다.
  • 대용량 데이터를 클라우드에서 관리하여 비용 절감과 확장성을 제공할 수 있다.
  • 빠른 데이터 접근과 효율적인 스토리지 관리가 가능하다.

5.5.2. 단점

  • 두 저장소를 관리해야 하므로 복잡도가 증가할 수 있다.
  • 로컬 스토리지와 클라우드 간의 데이터 동기화 문제가 발생할 수 있다.

6. 성능적 측면의 고려사항

6.1. 프로그레시브 이미지 업로드 (Progressive Image Upload)

프로그레시브 이미지 업로드는 대용량 이미지나 비디오를 업로드할 때, 전체 이미지가 아닌 저해상도 버전을 먼저 업로드하고, 이후 고해상도 버전을 점진적으로 전송하는 방식이다. 이 방식은 사용자 경험을 향상시키고, 네트워크 대역폭을 효율적으로 활용하는 데 유리하다.

6.1.1. 동작 방식

  • 저해상도 이미지 전송:
    • 이미지의 저해상도 버전이 서버로 업로드된다. 파일 크기가 작고 빠르게 업로드할 수 있어 사용자는 이미지가 빠르게 로드된다.
  • 고해상도 이미지 전송:
    • 저해상도 이미지가 서버에 전송되면, 이후 고해상도 이미지의 데이터가 점진적으로 전송된다. 이를 통해 고해상도 버전은 점차적으로 업로드되어 품질 향상이 이루어진다.
  • 사용자 경험:
    • 사용자는 처음에 저해상도 이미지를 빠르게 볼 수 있으며, 점차 고해상도 이미지로 품질이 향상된다. 이 방식은 특히 인터넷 속도가 느린 환경에서 유용하다.

6.1.2. 구현 예시

  • 파일을 일정 크기로 분할하여 (예: 1MB씩) 여러 번에 걸쳐 점진적으로 전송하거나, 압축된 낮은 해상도의 이미지를 먼저 전송하고 나중에 고해상도 버전을 전송할 수 있다.

6.1.3. 장점

  • 빠른 초기 로딩: 사용자가 빠르게 이미지를 확인할 수 있어 반응속도가 향상된다.
  • 네트워크 자원 절약: 전체 이미지를 한 번에 전송하지 않고 점진적으로 전송하므로 대역폭을 효율적으로 사용할 수 있다.
  • 사용자 경험 향상: 처음에 저해상도 이미지를 빠르게 볼 수 있어, 사용자는 기다리는 시간 동안 지루함을 덜 느낄 수 있다.

6.1.4. 단점

  • 복잡한 구현: 서버 측에서 고해상도 이미지가 전송될 때까지 관리하고 처리해야 할 데이터가 많기 때문에 구현이 복잡할 수 있다.
  • 저해상도 이미지 품질 저하: 초기에는 이미지 품질이 낮기 때문에, 첫 번째 로딩 단계에서 품질이 떨어질 수 있다.

6.2. 전송 중단 복구 (Resumable Upload)

전송 중단 복구(Resumable Upload)는 대용량 파일을 업로드할 때, 네트워크 장애나 연결 문제로 인한 전송 실패나 중단 상황에서 업로드를 이어받을 수 있는 기능을 제공하는 방식이다. 이 방식은 파일 전송 중간에 네트워크 연결이 끊어졌을 때, 전송을 중단한 지점부터 다시 이어서 전송할 수 있게 도와준다.

6.2.1. 동작 방식

  • 전송 시작 및 분할:
    • 파일을 여러 개의 작은 청크(chunk)로 나누어 전송한다. 각 청크는 일정한 크기로 분할되며, 전송 상태가 서버에 저장된다.
  • 전송 중단 발생 시 복구:
    • 전송이 중단되거나 실패하면, 서버는 어디까지 전송되었는지 정보를 기억하고, 클라이언트는 이를 바탕으로 전송을 중단된 지점부터 이어서 시작한다.
  • HTTP Range 요청 및 WebRTC DataChannel 사용:
    • HTTP Range 요청은 특정 범위의 데이터를 요청할 수 있는 HTTP 프로토콜 기능이다. 이를 활용하여 클라이언트가 서버로부터 파일을 청크 단위로 요청할 수 있다.
    • WebRTC DataChannel을 사용하면 네트워크 연결이 끊어졌을 때도 파일 전송을 재개할 수 있는 기능을 제공하며, 연결이 안정적이지 않더라도 효율적인 전송이 가능하다.

6.2.2. 구현 방법

  • HTTP Range 요청:
    • 클라이언트가 특정 바이트 범위만 요청하고, 서버가 해당 범위의 데이터를 전송하는 방식으로 구현된다.
  • WebRTC DataChannel을 활용한 복구:
    • WebRTC는 실시간 데이터 전송에 강점을 가지며, DataChannel을 이용한 전송은 데이터를 일정 크기로 쪼개어 전송하고, 전송 실패 시 재전송 기능을 내장하고 있어 안정적인 전송 복구를 지원할 수 있다.

6.2.3. 장점

  • 대용량 파일 전송에 유용: 대용량 파일을 업로드할 때, 네트워크가 불안정하거나 중단되었을 때 전송을 재개할 수 있어, 파일 전송의 중단을 최소화할 수 있다.
  • 사용자 경험 향상: 사용자가 대용량 파일을 업로드하는 동안, 전송이 중단되더라도 다시 시작할 수 있어 사용자가 불편을 겪지 않게 된다.
  • 대역폭 효율성: 실패한 부분만 재전송하기 때문에 대역폭을 효율적으로 활용할 수 있다.

6.2.4. 단점

  • 복잡한 구현: 서버에서 업로드 상태를 추적하고, 전송 중단 시 재개하기 위한 상태 관리를 해야 하므로 구현이 복잡할 수 있다.
  • 지원되는 환경의 제한: WebRTC와 같은 기술은 지원하는 브라우저나 환경이 제한적일 수 있어, 모든 사용자에게 동일한 경험을 제공하기 어려울 수 있다.

6.2.5. 예시

  • HTTP Range 요청을 이용한 복구: 클라이언트가 Range 헤더를 사용하여 서버에 파일을 요청하면, 서버는 해당 범위만 전송한다. 예를 들어, 10MB 파일을 1MB씩 나누어 전송하고, 중단된 지점부터 재개할 수 있도록 한다.

8. 결론

위에서 비교한 선택사항들을 표로 정리한다.

8.1. 전송방식

구현 방식 장점 단점 적합한 사용 사례
FTP - 안정적인 대용량 파일 전송
- 파일 전송 속도가 빠름		 - 보안 설정이 복잡
- 최신 웹 표준과 호환성 부족		 - 대규모 파일 전송이 필요한 내부 시스템
WebSocket - 실시간 양방향 통신 지원
- 연결 유지로 효율적인 데이터 전송		 - 구현 복잡도 증가
- 연결 유지로 리소스 소비 증가		 - 실시간 이미지 업로드가 필요한 애플리케이션 (예: 라이브 방송 플랫폼)
HTTP (multipart/form-data) - 널리 사용되는 표준
- 다양한 브라우저 및 서버와의 호환성
- 구현이 간단		 - 대규모 파일 전송 시 비효율적
- 데이터 전송 중단 복구 기능 미흡		 - 소규모 이미지 업로드가 빈번한 웹 애플리케이션 (예: 사용자 프로필 이미지 업로드)
스트리밍 - 대규모 파일의 지속적 전송에 유리
- 낮은 지연 시간		 - 서버 및 클라이언트의 복잡한 구현 필요
- 네트워크 불안정 시 전송 효율 저하		 - 동영상 업로드 및 실시간 처리 플랫폼
청크 - 대용량 데이터의 분할 전송 가능
- 전송 중단 복구 용이		 - 구현 복잡도 증가
- 관리 및 상태 추적 필요		 - 대규모 데이터 업로드가 필요한 환경 (예: 클라우드 스토리지)
Base64 - 텍스트 기반 전송으로 다양한 프로토콜과 호환 가능
- JSON 및 XML 내에서 직접 전송 가능		 - 파일 크기 약 33% 증가
- 대용량 파일 전송에 비효율적		 - 소규모 이미지 데이터의 인라인 전송 (예: JSON 내에 포함된 이미지 데이터)

8.2. 클라이언트

클라이언트 이미지 전송 방식 장점 단점 적합한 사용 사례
Blob 객체로 메모리에 한 번에 올리기 - 구현이 간단
- 브라우저 API 활용 가능
- 전송 속도 빠름		 - 대용량 파일 처리 시 메모리 부족 문제 발생 가능
- 전송 중단 복구 불가		 - 소규모 이미지 업로드 (예: 사용자 프로필 이미지 업로드)
메모리로 조금씩 올려서 전송하기 (스트리밍) - 대용량 파일 처리 가능
- 전송 중단 시 복구 가능
- 네트워크 대역폭 효율적 활용		 - 구현 복잡도 증가
- 클라이언트와 서버 간 동기화 필요		 - 대규모 이미지 또는 동영상 업로드 (예: 클라우드 스토리지 업로드)

8.3. 백엔드

백엔드 선택 옵션 장점 단점 적합한 사용 사례
In-Memory Buffering (메모리 버퍼링) - 빠른 데이터 처리 속도
- 데이터 일시 저장 및 처리에 적합
- IO 대기 시간 최소화		 - 메모리 제한으로 인해 대용량 데이터 처리 어려움
- 서버 장애 시 데이터 유실 가능		 - 실시간 처리 요구사항이 있는 애플리케이션
- 작은 크기의 데이터 처리 시스템
Direct-to-Disk Storage (디스크 직접 저장) - 대용량 데이터 저장 가능
- 데이터 영속성 보장
- 장애 발생 시 데이터 복구 가능		 - 디스크 IO로 인한 처리 속도 저하
- 초기 저장 시 처리 속도 느림		 - 대규모 데이터 저장 시스템
- 안정적인 데이터 저장 및 복구가 중요한 서비스

8.4. 아키텍처

이미지 스토리지 아키텍처 장점 단점 적합한 사용 사례
백엔드 서버에 직접 저장 - 서버에서 직접 관리 가능
- 설정 및 구현이 간단		 - 확장성 제한
- 대용량 데이터 처리에 부담
- 장애 발생 시 데이터 유실 가능		 - 소규모 프로젝트나 제한된 사용자 수를 가진 애플리케이션
클라우드 S3 이용 - 고가용성 및 확장성 제공
- 데이터 내구성 높음
- 대규모 데이터 처리 적합		 - 클라우드 서비스 비용 발생
- 초기 설정 및 인증 복잡		 - 대규모 사용자 기반 서비스
- 고용량의 데이터 저장 및 처리 요구되는 시스템
프리싸인 URL 이용 - 서버의 데이터 처리 부담 감소
- 클라이언트가 직접 업로드 가능
- 대역폭 효율적 활용		 - 서버에서 URL 생성 로직 추가 필요
- 인증 및 보안 관리 추가 필요		 - 대규모 사용자 기반 서비스
- 클라이언트가 대량의 파일을 업로드하는 애플리케이션

참조