플러터 S3 직접 업로드, 서버 부하와 비용 절감의 핵심

오늘날 성공적인 모바일 앱 서비스의 뒤에는 사용자가 끊임없이 생성하는 수많은 파일 데이터가 있습니다. 인스타그램의 사진과 릴스, 유튜브의 동영상, 중고 거래 앱의 상품 이미지까지. 하지만 사용자가 늘어나는 만큼, 혹은 그보다 더 가파르게 증가하는 파일 데이터는 개발팀에게 '서버 부하'와 '인프라 비용'이라는 거대한 숙제를 안겨줍니다. 혹시 여러분의 Flutter 앱이 사용자가 업로드하는 모든 파일을 애플리케이션 서버를 통해 S3 같은 스토리지로 전달하고 있지는 않으신가요? 그렇다면 서비스가 성장할수록 서버는 점점 더 버거워지고, 네트워크 비용은 눈덩이처럼 불어나는 '비용 폭탄'을 맞이할 위험이 매우 큽니다.

이 글에서는 이러한 문제를 뿌리부터 해결하고, 여러분의 Flutter 앱을 한 단계 더 높은 수준의 아키텍처로 진화시킬 'AWS S3로 직접 파일 업로드' 전략을 심도 있게 파헤칩니다. 서버리스의 핵심인 API GatewayLambda를 활용해 보안과 효율을 동시에 잡는 Pre-signed URL 생성부터, 수많은 개발자를 함정에 빠뜨리는 IAM 권한 문제CORS 설정까지, 실전에서 마주할 모든 과정을 총정리하여 상세히 안내합니다. 이 가이드를 끝까지 정독하시면, 서버 걱정, 비용 걱정 없이 무한히 확장 가능한 파일 업로드 시스템을 구축하는 견고한 토대를 마련하게 될 것입니다.

왜 파일 업로드는 서버를 거치면 안 될까?

현대적인 아키텍처를 도입하기 전에, 왜 기존의 '서버 경유' 방식이 더 이상 지속 가능하지 않은지 명확히 이해해야 합니다. 전통적인 파일 업로드 방식은 다음과 같은 흐름을 따릅니다.

[전통 방식] Flutter App → Application Server (EC2, Spring Boot 등) → AWS S3

  1. 데이터 수신: Flutter 클라이언트가 수십 MB에 달하는 이미지나 동영상 파일을 HTTP 요청 Body에 담아 우리가 직접 운영하는 애플리케이션 서버로 전송합니다.
  2. 서버 처리: 서버는 이 거대한 파일 데이터를 네트워크 소켓으로부터 모두 읽어들여 메모리나 임시 디스크 공간에 잠시 보관합니다.
  3. 데이터 재전송: 서버는 AWS SDK를 사용하여 방금 받은 파일 데이터를 다시 AWS S3 버킷으로 업로드합니다.

이 방식은 논리적으로 단순해 보이지만, 서비스 규모가 커지면서 다음과 같은 치명적인 단점들을 드러냅니다.

평가 항목 전통 방식 (서버 경유) 현대 방식 (S3 직접 업로드)
서버 부하 모든 파일 데이터가 서버의 CPU, 메모리, 네트워크를 점유하여 핵심 비즈니스 로직 처리 성능을 심각하게 저하시킴. (높음) 서버는 가벼운 URL 생성 요청만 처리. 파일 데이터는 서버를 전혀 거치지 않아 부하가 거의 없음. (매우 낮음)
네트워크 비용 '서버 → S3' 구간에서 불필요한 아웃바운드 트래픽 비용이 발생. 1TB 업로드 시 약 100달러 이상의 추가 비용 발생 가능. (높음) 클라이언트에서 S3로 직접 전송되므로 서버의 아웃바운드 비용이 발생하지 않음. (없음)
확장성 파일 업로드 트래픽 증가 시, 애플리케이션 서버 전체를 증설해야 하므로 구조가 복잡해지고 비용이 급증. (낮음) 파일 업로드는 S3와 Lambda가 처리하므로 사실상 무한한 확장성을 가짐. 애플리케이션 서버는 영향을 받지 않음. (높음)
사용자 경험 서버의 처리 속도가 병목이 되어 업로드 속도가 느려지고, 서버 전체의 응답성이 저하됨. (나쁨) 클라이언트가 S3에 직접 최적의 경로로 업로드하므로 속도가 빠르고 안정적임. (좋음)

1. 서버 부하 및 성능 저하: 본업을 잃어버린 서버

이 아키텍처의 가장 근본적인 문제는 모든 파일 데이터가 비즈니스 로직을 처리해야 할 애플리케이션 서버를 '경유'한다는 점입니다. 서버는 파일 전송을 처리하는 동안 CPU, 메모리, 네트워크 대역폭 등 핵심 자원을 고스란히 소모합니다. 수십, 수백 메가바이트(MB)에 달하는 파일들이 동시에 100개만 업로드되어도 서버는 본연의 임무(게시글 처리, 사용자 인증, 데이터 조회 등)를 처리할 여력을 잃고 전체 서비스의 응답 속도는 현저히 느려집니다. 이는 마치 중요한 서류 결재를 해야 할 임원이 택배 상자를 일일이 받아서 다시 포장해 보내는 것과 같은 극심한 비효율입니다.

2. 불필요한 네트워크 비용: 내지 않아도 될 통행료

AWS를 비롯한 클라우드 환경에서 비용을 결정하는 가장 중요한 요소 중 하나는 '데이터 전송(Data Transfer)' 비용입니다. 일반적으로 클라우드 서비스로 데이터가 들어오는 '인바운드(Inbound)' 트래픽은 거의 무료입니다. 하지만 서비스에서 데이터가 밖으로 나가는 '아웃바운드(Outbound)' 트래픽에는 상당한 비용이 부과됩니다.

  • (1단계) 클라이언트 → 서버: 이 구간은 서버의 '인바운드' 트래픽입니다. (비용 거의 없음)
  • (2단계) 서버 → S3: 이 구간은 서버의 '아웃바운드' 트래픽입니다. (치명적인 비용 발생!)

사용자가 1GB 파일을 업로드하면, 우리 서버는 1GB의 아웃바운드 데이터를 S3로 보내는 데 비용을 지불해야 합니다. 어차피 최종 목적지는 S3인데, 굳이 우리 서버를 거치면서 비싼 통행료를 내고 있는 셈입니다. 서비스가 활성화되어 사용자들이 매일 1TB의 파일을 업로드한다면, 이 구간에서만 매달 100달러 이상의 불필요한 비용이 추가로 발생할 수 있습니다.

[현대 방식] Flutter App ↗ (2. 실제 파일 업로드) ↗ AWS S3
Flutter App ↔ (1. 업로드 허가 요청/응답) ↔ Application Server (API Gateway + Lambda)

이러한 문제들을 해결하는 현대적인 해답이 바로 클라이언트에서 S3로 직접 업로드하는 방식입니다. 파일 데이터는 더 이상 우리 서버를 괴롭히지 않고 클라이언트에서 S3로 직행합니다. 우리 서버는 단지 "이 사용자는 이 파일을 업로드할 자격이 있다"는 것을 증명하는 가벼운 '임시 허가증'만 발급해주는 역할로 축소됩니다. 그리고 이 구조의 핵심 열쇠가 바로 Pre-signed URL입니다.

Pre-signed URL, 보안과 효율을 모두 잡는 열쇠

클라이언트가 S3에 직접 파일을 업로드하게 하려면, S3는 이 요청이 신뢰할 수 있는 요청인지 확인해야 합니다. 이를 위해 AWS 자격 증명(Access Key ID와 Secret Access Key)이 필요합니다. 하지만 이 강력한 자격 증명을 Flutter 앱 코드 안에 하드코딩하는 것은 우리 집 현관문 비밀번호를 문 앞에 크게 써 붙여놓는 것과 같은, 절대 해서는 안 될 최악의 보안 사고입니다. 앱이 디컴파일되는 순간 자격 증명은 그대로 노출되고, 해커는 우리의 S3 버킷에 무제한으로 접근해 데이터를 훔치거나 삭제하고, 심지어 우리의 AWS 계정으로 암호화폐를 채굴하여 상상조차 하기 힘든 '요금 폭탄'을 안겨줄 수 있습니다.

Pre-signed URL(미리 서명된 URL)은 이 딜레마를 매우 우아하게 해결합니다. 그 원리는 다음과 같습니다.

  1. [1단계: 허가 요청] Flutter 앱이 파일 업로드를 시작하기 전, 우리 서버(API)에 "profile-images/user-123.jpg 라는 이름으로 파일을 올릴 예정이니, 임시 업로드 허가증을 발급해주세요." 라고 요청합니다.
  2. [2단계: 검증 및 생성] 서버는 이 요청을 보낸 사용자가 로그인된 정식 사용자인지, 해당 파일을 업로드할 권한이 있는지 등을 먼저 확인합니다. 모든 검증을 통과하면, 서버만이 안전하게 보관하고 있는 AWS 자격 증명을 사용하여 아주 제한적인 권한을 가진 특별한 URL을 생성합니다.
    이 URL에는 다음과 같은 정보가 암호화된 서명과 함께 포함됩니다:
    • 누가(Who): 이 URL을 생성한 주체 (서버의 AWS 자격 증명)
    • 무엇을(What): profile-images/user-123.jpg 라는 특정 객체(파일)
    • 어떤 작업을(Action): 객체를 생성하는 작업 (HTTP PUT 요청)
    • 언제까지(When): 앞으로 5분(300초) 동안만 유효함
  3. [3단계: 허가증 반환] 서버는 이렇게 생성된, 유효 시간이 짧고 특정 작업만 허용하는 Pre-signed URL을 Flutter 앱에게 응답으로 전달합니다.
  4. [4단계: 직접 업로드] Flutter 앱은 이 URL을 목적지로 삼아 HTTP PUT 요청을 보냅니다. 요청의 본문(Body)에는 실제 이미지 파일 데이터를 담습니다. S3는 이 요청을 받고 URL에 포함된 서명과 각종 파라미터를 검증합니다. 서명이 유효하고, 유효 시간 이내이며, 지정된 작업(PUT)과 객체 키가 일치하면 요청을 승인하고 파일을 안전하게 저장합니다.

이 방식의 핵심은, Flutter 앱은 단 한 번도 강력한 AWS 자격 증명에 직접 접근하지 않는다는 것입니다. 앱이 갖는 것은 오직 짧은 시간 동안 특정 파일 하나를 올리는 데만 사용할 수 있는 '일회용 티켓'뿐입니다. 설령 이 URL이 중간에 탈취되더라도 유효 시간이 지나면 쓸모가 없어지며, 해커는 이 URL을 가지고 파일을 삭제하거나 다른 파일을 읽는 등의 다른 작업을 절대 수행할 수 없습니다.

실전! 서버리스 파일 업로드 아키텍처 설계

이제 우리가 구축할 전체 시스템의 청사진을 그려보겠습니다. 우리는 이 효율적인 아키텍처를 서버리스(Serverless) 구성 요소들을 적극 활용하여 더욱 강력하고 비용 효율적으로 만들 것입니다.

Flutter App <--> AWS API Gateway <--> AWS Lambda <--> AWS S3

  • Flutter App: 사용자 인터페이스를 제공하고, 업로드 버튼 클릭 시 API Gateway를 통해 Lambda 함수를 호출하여 Pre-signed URL을 요청합니다. URL을 받으면 해당 URL로 파일 데이터를 직접 S3에 전송하는 주체입니다.
  • AWS API Gateway: Flutter 앱으로부터의 HTTP 요청을 안전하게 받아 처리하는 '관문'입니다. /presigned-url과 같은 특정 엔드포인트로 들어온 요청을 뒤에 있는 Lambda 함수로 전달(trigger)하는 역할을 합니다. 인증, 요청량 제어(Throttling), 로깅 등 다양한 부가 기능을 제공합니다.
  • AWS Lambda: Pre-signed URL을 생성하는 핵심 로직을 수행하는 '두뇌'입니다. Node.js, Python 등 원하는 언어로 코드를 작성할 수 있으며, 요청이 있을 때만 실행되고 실행된 시간(밀리초 단위)만큼만 비용을 지불하므로 극도로 경제적입니다.
  • AWS S3 (Simple Storage Service): 최종적으로 파일이 저장되는 안전하고 내구성이 뛰어난 '저장고'입니다. 거의 무한에 가까운 확장성을 제공하여 파일 수나 용량에 대한 걱정에서 완전히 해방될 수 있습니다.

1단계: S3 버킷 생성과 CORS, 첫 번째 함정 피하기

코드를 작성하기에 앞서, 파일이 저장될 S3 버킷을 준비하고 가장 중요한 설정 중 하나인 CORS(Cross-Origin Resource Sharing)를 구성해야 합니다. 놀랍게도 많은 개발자들이 이 단계를 놓치거나 잘못 설정하여 원인 모를 네트워크 오류에 몇 시간씩 시달리곤 합니다.

  1. AWS Management Console에 로그인하여 S3 서비스로 이동합니다.
  2. '버킷 만들기'를 클릭하고, 전역적으로 고유한 버킷 이름을 입력합니다 (예: my-flutter-uploads-2025-unique). 리전은 사용자와 가장 가까운 곳(예: ap-northeast-2, 서울)을 선택합니다.
  3. '모든 퍼블릭 액세스 차단' 설정을 반드시 활성화된 상태로 유지합니다. Pre-signed URL을 사용하면 버킷 자체를 외부에 공개할 필요가 전혀 없습니다. 이것이 보안의 첫걸음입니다.
  4. 버킷 생성을 완료한 후, 생성된 버킷의 상세 페이지에서 '권한' 탭으로 이동합니다.
  5. 아래로 스크롤하여 '교차 출처 리소스 공유(CORS)' 섹션을 찾고 '편집' 버튼을 클릭합니다.

CORS 설정은 왜 필수일까요?

웹 브라우저와 최신 앱 프레임워크는 '동일 출처 정책(Same-Origin Policy)'이라는 강력한 보안 규칙을 따릅니다. 이는 악성 스크립트가 사용자의 허락 없이 다른 웹사이트의 리소스를 마음대로 가져오지 못하게 막는 중요한 방어 장치입니다. 우리의 Flutter 앱(또는 웹)은 우리 서버(API Gateway 도메인)와 통신하지만, 파일을 업로드할 때는 전혀 다른 도메인인 S3(s3.ap-northeast-2.amazonaws.com)로 직접 요청을 보내야 합니다. 이때 S3 서버가 "다른 출처(도메인)에서 온 이 업로드 요청을 허용하겠다"고 명시적으로 응답 헤더에 포함시켜주지 않으면, 클라이언트는 이를 보안 위협으로 간주하고 요청을 차단해 버립니다. 이것이 바로 악명 높은 CORS 오류의 정체입니다.

따라서 S3 버킷에 다음과 같은 CORS 규칙을 추가하여, 우리 앱(어떤 출처에서든)이 파일을 올리는 PUT 요청을 보낼 수 있도록 허용해주어야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 <CORSRule>
   <AllowedOrigin>*</AllowedOrigin>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
   <MaxAgeSeconds>3000</MaxAgeSeconds>
   <ExposeHeader>ETag</ExposeHeader>
 </CORSRule>
</CORSConfiguration>
  • <AllowedOrigin>*</AllowedOrigin>: 모든 출처에서의 요청을 허용합니다. 개발 환경에서는 편리하지만, 프로덕션 환경에서는 <AllowedOrigin>https://your-app-domain.com</AllowedOrigin>과 같이 실제 서비스 도메인을 명시하는 것이 보안상 더 안전합니다.
  • <AllowedMethod>PUT</AllowedMethod>: Pre-signed URL을 통한 업로드는 HTTP PUT 메서드를 사용하므로 이를 허용합니다.
  • <AllowedHeader>*</AllowedHeader>: 모든 헤더를 허용합니다. Content-Type 같은 헤더가 포함된 요청을 받아들이기 위해 필요합니다.

이 설정을 저장하면 S3 버킷 준비는 완료됩니다. 이 단계를 건너뛰면 Flutter 클라이언트에서 S3로 파일을 업로드할 때 99% 확률로 네트워크 오류 또는 CORS 관련 오류가 발생하니 반드시 확인해야 합니다.

2단계: 핵심 로직, Pre-signed URL 생성 Lambda 함수

이제 Pre-signed URL을 생성하는 서버리스 함수를 작성할 차례입니다. AWS Lambda에서 가장 널리 쓰이는 Node.js와 Python 두 가지 버전의 예시를 모두 살펴보겠습니다. 여러분의 팀 기술 스택에 맞는 것을 선택하세요.

Node.js (AWS SDK v3) 예시

최신 AWS SDK v3는 필요한 패키지만 모듈식으로 가져올 수 있어 더 가볍고 효율적입니다. Lambda 함수를 생성하고 런타임을 Node.js 18.x 이상으로 설정한 후, Lambda 함수의 '구성' > '환경 변수'에 BUCKET_NAME을 여러분의 S3 버킷 이름으로 설정해주세요.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import { randomUUID } from 'crypto'; // Node.js 내장 모듈 사용

// S3 클라이언트 인스턴스를 생성합니다.
// Lambda 실행 환경의 리전을 자동으로 사용합니다.
const s3Client = new S3Client({});

// 환경 변수에서 S3 버킷 이름을 가져옵니다.
const BUCKET_NAME = process.env.BUCKET_NAME;

export const handler = async (event) => {
    // API Gateway로부터의 요청인지 확인하고 로그를 남깁니다.
    console.log("Received event:", JSON.stringify(event, null, 2));

    if (!BUCKET_NAME) {
        throw new Error("BUCKET_NAME environment variable is not set.");
    }
    
    // 클라이언트에서 파일 확장자를 받을 수 있습니다. (e.g., event.queryStringParameters.ext)
    // 여기서는 간단히 '.jpg'로 고정합니다.
    const fileExtension = ".jpg";
    
    // randomUUID()를 사용하여 충돌 가능성이 거의 없는 고유한 파일 키를 생성합니다.
    // 'uploads/' 라는 prefix를 붙여 S3 내에서 폴더처럼 관리할 수 있습니다.
    // 실제 앱에서는 `uploads/user-id/random-uuid.jpg` 처럼 사용자 ID를 조합하면 더 좋습니다.
    const fileKey = `uploads/${randomUUID()}${fileExtension}`;

    // Pre-signed URL 생성을 위한 명령(Command) 객체를 생성합니다.
    const command = new PutObjectCommand({
        Bucket: BUCKET_NAME,
        Key: fileKey,
        // ContentType: 'image/jpeg', // 업로드될 파일의 타입을 지정할 수 있습니다.
    });

    try {
        // getSignedUrl 함수를 사용하여 URL을 생성합니다.
        // 유효 시간을 300초 (5분)으로 설정합니다. 이 시간 내에 업로드가 완료되어야 합니다.
        const signedUrl = await getSignedUrl(s3Client, command, { expiresIn: 300 });

        console.log("Successfully created pre-signed URL:", signedUrl);

        // 클라이언트에게 성공 응답을 반환합니다.
        // CORS를 위해 Access-Control-Allow-Origin 헤더를 포함하는 것이 안전합니다.
        return {
            statusCode: 200,
            headers: {
                "Access-Control-Allow-Origin": "*",
                "Content-Type": "application/json"
            },
            body: JSON.stringify({
                uploadURL: signedUrl,
                key: fileKey, // 클라이언트가 업로드 성공 후 파일 키를 알 수 있도록 전달합니다.
            }),
        };
    } catch (error) {
        console.error("Error creating pre-signed URL", error);
        return {
            statusCode: 500,
            headers: {
                "Access-Control-Allow-Origin": "*",
                "Content-Type": "application/json"
            },
            body: JSON.stringify({ message: "Error creating pre-signed URL", error: error.message }),
        };
    }
};

Python (Boto3) 예시

Python과 Boto3 라이브러리를 사용한 예시입니다. 런타임을 Python 3.9 이상으로 설정하고, 마찬가지로 환경 변수 BUCKET_NAME을 설정합니다.

import boto3
import uuid
import json
import os
from botocore.exceptions import ClientError
import logging

# 로깅 설정
logger = logging.getLogger()
logger.setLevel(logging.INFO)

# S3 클라이언트 생성 (리전은 실행 환경에서 자동으로 가져옴)
s3_client = boto3.client('s3')

# 환경 변수에서 버킷 이름 가져오기
BUCKET_NAME = os.environ.get('BUCKET_NAME')

def handler(event, context):
    if not BUCKET_NAME:
        logger.error("BUCKET_NAME environment variable is not set.")
        return {
            'statusCode': 500,
            'body': json.dumps({'message': 'Internal server error: BUCKET_NAME not configured'})
        }

    logger.info(f"Received event: {json.dumps(event)}")
    
    # 고유한 파일 키 생성
    file_extension = ".jpg" # 필요시 클라이언트로부터 파라미터로 받을 수 있음
    file_key = f"uploads/{uuid.uuid4()}{file_extension}"
    
    try:
        # Boto3의 generate_presigned_url 함수를 사용하여 URL 생성
        presigned_url = s3_client.generate_presigned_url(
            'put_object',
            Params={
                'Bucket': BUCKET_NAME,
                'Key': file_key,
                # 'ContentType': 'image/jpeg' # 특정 Content-Type 강제 가능
            },
            ExpiresIn=300,  # URL 유효 시간 (초)
            HttpMethod='PUT'
        )
        
        logger.info(f"Successfully created pre-signed URL for key: {file_key}")
        
        # 클라이언트에 성공 응답 반환
        return {
            'statusCode': 200,
            'headers': {
                'Access-Control-Allow-Origin': '*',
                'Content-Type': 'application/json'
            },
            'body': json.dumps({
                'uploadURL': presigned_url,
                'key': file_key
            })
        }
        
    except ClientError as e:
        logger.error(f"Error generating pre-signed URL: {e}")
        return {
            'statusCode': 500,
            'headers': {
                'Access-Control-Allow-Origin': '*',
                'Content-Type': 'application/json'
            },
            'body': json.dumps({'message': 'Could not generate pre-signed URL'})
        }

3단계: API Gateway, 세상과 Lambda를 잇는 관문

이제 Flutter 앱이 호출할 수 있는 공용 HTTP 엔드포인트를 만들 차례입니다. API Gateway가 이 역할을 수행합니다.

  1. AWS Console에서 API Gateway 서비스로 이동합니다.
  2. 다양한 API 타입 중 'HTTP API'의 '구축'을 선택합니다. HTTP API는 REST API보다 더 간단하고 저렴하며, 이런 단일 목적의 서버리스 엔드포인트에 매우 적합합니다.
  3. '통합' 단계에서 '통합 추가'를 클릭합니다.
    • 통합 유형: Lambda
    • Lambda 함수: 위에서 생성한 Lambda 함수 (예: presigned-url-generator-nodejs)를 선택합니다.
  4. API 이름을 지정하고(예: FlutterFileUploadApi) 다음으로 넘어갑니다.
  5. '경로 구성' 단계에서 라우트를 설정합니다.
    • 메서드: GET (URL을 '요청'하는 것이므로 GET이 적합합니다)
    • 리소스 경로: /presigned-url (또는 /generate-upload-url 등 원하는 경로)
    • 통합 대상: 방금 생성한 Lambda 통합을 선택합니다.
  6. 나머지 설정은 기본값으로 두고 API를 생성합니다.
  7. 생성이 완료되면 대시보드에서 '호출 URL'을 확인할 수 있습니다. 이 URL이 바로 Flutter 앱에서 API를 호출할 때 사용할 최종 엔드포인트입니다. (예: https://abcdef123.execute-api.ap-northeast-2.amazonaws.com)
  8. 중요: 왼쪽 메뉴에서 'CORS'를 선택하고, '액세스 제어 허용 출처'에 *를 입력하고 필요한 헤더(Content-Type 등)와 메서드(GET)를 허용하도록 설정합니다. 이는 S3의 CORS와는 별개로, API Gateway 자체에 대한 CORS 설정이며, 브라우저나 앱이 API Gateway에 접근할 수 있도록 허용하는 역할을 합니다.

4단계: '콜드 스타트' 미스터리, 진짜 범인은 IAM 권한

이제 모든 조각이 맞춰진 것처럼 보입니다. 하지만 이 상태에서 테스트를 해보면 많은 개발자들이 기묘한 문제에 부딪힙니다. 바로 "한동안 앱을 사용하지 않다가 파일 업로드를 시도하면 첫 번째 시도가 실패하고, 곧바로 다시 시도하면 성공하는 현상"입니다. 이 문제를 겪은 개발자들은 Lambda의 '콜드 스타트(Cold Start)'를 원인으로 지목하고, 타임아웃 때문이라고 추측하며 첫 요청은 무시하거나 함수를 주기적으로 '깨우는(warm-up)' 등의 임시방편을 사용하곤 합니다. 하지만 이것은 문제의 증상일 뿐, 근본적인 원인이 아닙니다.

이 문제의 진짜 범인은 99%의 경우 Lambda 함수에 부여된 'IAM 실행 역할(Execution Role)'의 권한 부족입니다.

현직 풀스택 개발자

getSignedUrl 이나 generate_presigned_url 함수는 단순히 URL 문자열을 만드는 마법이 아닙니다. 이 함수는 내부적으로 AWS에게 다음과 같이 요청하는 것과 같습니다.

"지금 이 코드를 실행하는 주체(Lambda의 실행 역할)의 권한을 빌려서, '특정 S3 버킷에 객체를 쓰는(PutObject) 행위'를 할 수 있는 임시 URL을 만들려고 합니다. 과연 이 실행 역할은 정말로 해당 S3 버킷에 PutObject를 할 권한을 가지고 있나요?"

만약 Lambda의 실행 역할에 s3:PutObject 권한이 없다면, AWS SDK는 권한 검증에 실패하여 유효하지 않은 서명을 가진 URL을 생성하거나 아예 생성 자체에 실패합니다. 콜드 스타트 시에 이 문제가 두드러지는 이유는, 초기화 과정에서 이 권한 확인을 포함한 모든 절차가 처음부터 실행되면서 권한 부족 문제가 수면 위로 드러나기 때문입니다.

따라서, 이 미스터리를 해결하는 유일하고 올바른 방법은 Lambda 함수의 실행 역할에 S3 버킷에 대한 정확한 IAM 권한을 부여하는 것입니다.

올바른 IAM 정책 설정하기

  1. AWS Console에서 IAM 서비스로 이동합니다.
  2. 왼쪽 메뉴에서 '역할'을 선택하고, API Gateway와 연동된 Lambda 함수가 사용하는 역할을 찾습니다. (Lambda 함수 '구성' 탭의 '권한'에서 확인할 수 있습니다.)
  3. 해당 역할을 클릭하고 '권한' 탭에서 '권한 추가' > '인라인 정책 생성'을 선택합니다.
  4. JSON 편집기를 선택하고, 다음 정책을 붙여넣습니다. 이것이 바로 '최소 권한의 원칙'을 따르는 가장 안전하고 권장되는 정책입니다.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::your-s3-bucket-name/*"
            ]
        }
    ]
}
  • "Action": "s3:PutObject": S3에 객체를 생성(업로드)하는 작업만 정확히 지정합니다.
  • "Resource": "arn:aws:s3:::your-s3-bucket-name/*": 위 작업을 어느 자원에 대해 허용할지 지정합니다. your-s3-bucket-name을 여러분의 버킷 이름으로 반드시 바꾸고, /*를 붙여 버킷 안의 모든 객체(파일)에 대해 적용한다는 의미입니다.

정책 이름을 지정하고(예: AllowS3PutObjectForPresignedUrl) 정책을 생성하면 모든 설정이 끝납니다. 이제 Lambda 함수는 콜드 스타트 여부와 관계없이 첫 번째 요청부터 항상 유효한 Pre-signed URL을 성공적으로 생성할 것입니다.

경고: 인터넷 예제에서 "Action": "s3:*" 와 같이 와일드카드를 사용한 정책을 흔히 볼 수 있습니다. 이는 해당 버킷에 대한 모든 작업(읽기, 쓰기, 삭제, 권한 변경 등)을 허용하는 매우 위험한 권한입니다. Lambda 함수 코드에 아주 작은 보안 취약점이라도 존재할 경우, 버킷의 모든 데이터가 유출되거나 삭제될 수 있는 심각한 위험을 초래하므로 절대 프로덕션 환경에서 사용해서는 안 됩니다.

5단계: 최종 조립, Flutter 클라이언트 구현

이제 모든 백엔드 준비가 끝났습니다. Flutter 앱에서 이 강력한 서버리스 시스템을 사용하는 코드를 작성해 보겠습니다. `http` 패키지와 `image_picker` 패키지가 `pubspec.yaml`에 추가되어 있다고 가정합니다.

import 'dart:io';
import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;
import 'package:image_picker/image_picker.dart';
import 'dart:convert';

class S3UploaderScreen extends StatefulWidget {
  const S3UploaderScreen({super.key});

  @override
  State<S3UploaderScreen> createState() => _S3UploaderScreenState();
}

class _S3UploaderScreenState extends State<S3UploaderScreen> {
  // 3단계에서 확인한 API Gateway의 호출 URL에 리소스 경로를 더해 입력합니다.
  final String presignedUrlApiEndpoint = 'https://abcdef123.execute-api.ap-northeast-2.amazonaws.com/presigned-url';

  File? _selectedImage;
  final ImagePicker _picker = ImagePicker();
  String _statusMessage = '이미지를 선택하여 업로드를 시작하세요.';
  bool _isUploading = false;
  String? _uploadedFileKey;
  double _uploadProgress = 0.0;

  Future<void> _pickImage() async {
    final XFile? pickedFile = await _picker.pickImage(source: ImageSource.gallery);
    if (pickedFile != null) {
      setState(() {
        _selectedImage = File(pickedFile.path);
        _statusMessage = '이미지가 선택되었습니다. 업로드 버튼을 누르세요.';
        _uploadedFileKey = null;
        _uploadProgress = 0.0;
      });
    }
  }

  Future<void> _uploadImage() async {
    if (_selectedImage == null) {
      setState(() => _statusMessage = '업로드할 이미지를 먼저 선택해주세요.');
      return;
    }
    if (_isUploading) return;

    setState(() {
      _isUploading = true;
      _statusMessage = '업로드 준비 중... Pre-signed URL 요청...';
      _uploadProgress = 0.0;
    });

    try {
      // 1단계: 서버(Lambda)에 Pre-signed URL 요청
      final getUrlResponse = await http.get(Uri.parse(presignedUrlApiEndpoint));

      if (getUrlResponse.statusCode != 200) {
        throw Exception('Pre-signed URL을 받아오는데 실패했습니다. 응답: ${getUrlResponse.body}');
      }

      final responseData = json.decode(getUrlResponse.body);
      final String uploadUrl = responseData['uploadURL'];
      final String fileKey = responseData['key'];

      setState(() => _statusMessage = '파일 업로드 중...');

      // 2단계: 받은 URL로 파일 업로드 (HTTP PUT 요청)
      final fileBytes = await _selectedImage!.readAsBytes();
      final uploadResponse = await http.put(
        Uri.parse(uploadUrl),
        headers: {
          'Content-Type': 'image/jpeg', // 업로드하는 파일의 MIME 타입
        },
        body: fileBytes,
      );

      if (uploadResponse.statusCode == 200) {
        setState(() {
          _statusMessage = '업로드 성공!';
          _uploadedFileKey = fileKey; // 업로드된 파일의 S3 키 저장
          _uploadProgress = 1.0;
        });
        print('업로드 성공. S3 객체 키: $fileKey');
        // 이제 이 fileKey를 여러분의 애플리케이션 서버로 보내
        // 데이터베이스(RDS, DynamoDB 등)에 저장하는 후속 작업을 수행합니다.
      } else {
        throw Exception('S3 업로드 실패: ${uploadResponse.statusCode}\n응답: ${uploadResponse.body}');
      }
    } catch (e) {
      setState(() => _statusMessage = '오류 발생: $e');
      print('오류: $e');
    } finally {
      setState(() => _isUploading = false);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Flutter S3 Direct Uploader')),
      body: SingleChildScrollView(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          crossAxisAlignment: CrossAxisAlignment.stretch,
          children: [
            Container(
              height: 300,
              decoration: BoxDecoration(
                border: Border.all(color: Colors.grey.shade300),
                borderRadius: BorderRadius.circular(12),
              ),
              child: _selectedImage != null
                  ? ClipRRect(borderRadius: BorderRadius.circular(12), child: Image.file(_selectedImage!, fit: BoxFit.cover))
                  : const Center(child: Icon(Icons.photo, size: 80, color: Colors.grey)),
            ),
            const SizedBox(height: 24),
            Text(
              _statusMessage,
              textAlign: TextAlign.center,
              style: const TextStyle(fontSize: 16, fontWeight: FontWeight.w500),
            ),
            if (_uploadedFileKey != null)
              Padding(
                padding: const EdgeInsets.symmetric(vertical: 8.0),
                child: SelectableText('S3 Key: $_uploadedFileKey', textAlign: TextAlign.center, style: TextStyle(color: Colors.green.shade800, fontSize: 12)),
              ),
            const SizedBox(height: 24),
            ElevatedButton.icon(
              icon: const Icon(Icons.image_search),
              onPressed: _pickImage,
              label: const Text('갤러리에서 이미지 선택'),
              style: ElevatedButton.styleFrom(padding: const EdgeInsets.symmetric(vertical: 12)),
            ),
            const SizedBox(height: 12),
            ElevatedButton.icon(
              icon: _isUploading
                  ? const SizedBox(width: 20, height: 20, child: CircularProgressIndicator(color: Colors.white, strokeWidth: 3))
                  : const Icon(Icons.cloud_upload),
              onPressed: _isUploading ? null : _uploadImage,
              label: Text(_isUploading ? '업로드 중...' : 'S3로 업로드'),
              style: ElevatedButton.styleFrom(
                backgroundColor: _isUploading ? Colors.grey : Colors.blueAccent,
                padding: const EdgeInsets.symmetric(vertical: 12),
              ),
            ),
          ],
        ),
      ),
    );
  }
}

이 코드는 이미지 선택부터 Pre-signed URL 요청, 그리고 S3로의 최종 파일 업로드까지 전체 과정을 명확하게 보여줍니다. 특히 업로드 성공 후 반환받은 fileKey를 여러분의 애플리케이션 데이터베이스에 저장하면, 해당 파일을 사용자 프로필이나 게시물과 연결하여 영구적으로 관리할 수 있습니다.

총정리: 완벽한 시스템을 위한 최종 체크리스트

Flutter와 AWS 서버리스 기술을 활용한 현대적인 파일 업로드 시스템 구축 여정을 마무리하며, 성공적인 구현을 위해 반드시 확인해야 할 핵심 사항들을 체크리스트 형태로 정리했습니다. 프로젝트 진행 시 이 목록을 마지막으로 꼭 확인해보세요.

  • [✅] S3 버킷 보안: 버킷이 생성되었고, '모든 퍼블릭 액세스 차단'이 활성화되어 있는가?
  • [✅] S3 CORS 정책: S3 버킷의 '권한' 탭에 클라이언트의 PUT 요청을 허용하는 CORS 규칙이 올바르게 설정되었는가? (가장 흔한 실패 원인!)
  • [✅] Lambda 실행 역할(IAM): Lambda 함수의 실행 역할에 s3:PutObject 권한을 부여하는 IAM 정책이 '최소 권한 원칙'에 따라 정확하게 연결되었는가?
  • [✅] Lambda 환경 변수: Lambda 함수에 BUCKET_NAME 환경 변수가 정확하게 설정되었는가?
  • [✅] API Gateway 설정: HTTP API가 생성되고, GET /presigned-url과 같은 경로가 Lambda 함수와 올바르게 통합되었는가? API Gateway 자체의 CORS 설정도 확인했는가?
  • [✅] Flutter 클라이언트 구현: 클라이언트 코드가 (1) GET으로 API Gateway에 URL을 요청하고, (2) 반환된 URL을 사용하여 PUT으로 S3에 직접 파일을 업로드하는 2단계 프로세스를 따르는가?
  • [✅] 파일 키 관리: S3에 저장될 파일의 키(이름)가 UUID 등을 통해 고유하게 생성되어 파일 덮어쓰기 충돌을 방지하는가?
  • [✅] 후속 처리 연동: 파일 업로드 성공 후 Lambda로부터 반환된 파일 키(key)를 받아, 애플리케이션의 메인 데이터베이스에 저장하는 로직이 준비되었는가?

이 가이드에서 제시한 아키텍처와 원칙, 그리고 코드를 통해 여러분은 더 이상 파일 업로드로 인한 서버 부하와 비용 걱정 없이, 사용자의 콘텐츠 생산을 마음껏 지원하는 안정적이고 확장성 높은 Flutter 애플리케이션을 만들 수 있을 것입니다. 이는 단순한 기능 구현을 넘어, 비즈니스의 성장에 따라 유연하게 대처할 수 있는 강력한 기술적 자산을 확보하는 길입니다.

Post a Comment