AWS Lambda와 Fargate가 우리가 앱을 구축하는 방식을 바꾸는 방법

Source: Dev.to

번역을 진행하려면 번역이 필요한 실제 텍스트(본문)를 제공해 주시겠어요?
본문을 알려주시면 원본 형식과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

티루파티에서 열린 AWS 학생 커뮤니티 데이 참석

장소: 모한 바부 대학교

저는 단순히 참가자로서가 아니라 AWS 커뮤니티 빌더로서 클라우드 지식을 초보자와 관심 있는 모든 사람에게 공유하는 것을 좋아합니다. Avinash Dalvi가 진행한 세션 **“코드에서 컨테이너까지: Lambda를 넘어선 서버리스 이해”**는 Lambda를 언제 사용하고, 다른 옵션을 언제 고려해야 하는지에 대한 명확한 가이드를 제공했기 때문에 바로 눈길을 끌었습니다.

배경 설명: “Lambda를 넘어선 서버리스”란?

이 강연은 서버리스 마인드셋을 유지하면서 코드를 작성하는 단계에서 컨테이너를 사용하는 단계로 전환하는 과정을 설명하면서 시작되었습니다. 핵심 포인트는 서버리스가 단순히 Lambda 함수만을 의미하는 것이 아니라, AWS가 인프라를 관리하는 동안 여러분은 코드에 집중할 수 있게 해주는 사고 방식이라는 점이었습니다.

Avinash는 AWS User Group Bengaluru의 리더이자 AWS Community Builder임을 소개했으며, 이는 청중에게 내용이 이론이 아니라 실제 현장 경험에 기반하고 있음을 확신시켰습니다. 그는 다음을 강조했습니다:

• Lambda가 빛을 발하는 경우
• Lambda가 한계에 부딪히는 경우
• AWS Fargate와 같은 서비스가 그 격차를 메우는 방법

서버리스 마인드셋 전환

“서버가 필요해” → “X가 발생하면 코드를 실행해야 해”

서버리스 모델에서는 **필요한 것(런타임, 메모리, 타임아웃)**을 선언하면 나머지는 AWS가 처리합니다. 트리거는 다음과 같이 다양합니다:

• S3 파일 업로드
• API 요청
• 예약(cron) 작업
• 다른 AWS 서비스에서 발생하는 이벤트

피자, 드실래요? 음식으로 설명하는 서버리스

직접 만들기 vs. 피자 주문하기

전통적인 서버(예: EC2)는 집에서 요리하는 것과 같습니다: 주방을 관리하고, 오븐을 계속 가동하며, 요리하지 않을 때도 비용을 지불합니다.

서버리스는 피자 주문과 같습니다: 주문(코드)을 전달하고, 원하는 토핑·크기·베이스를 설명하면 AWS가 나머지를 처리합니다. 먹은 만큼만 비용을 지불합니다.

서버리스 피자 주문하기

연사는 피자 비유를 활용해 서버리스 애플리케이션을 구축하는 과정을 단계별로 설명했습니다:

이러한 비유를 통해 학생들은 일상적인 피자 선택이 클라우드 컴퓨팅 선택과 어떻게 연결되는지 쉽게 이해할 수 있었습니다.

Lambda 실전 (그리고 한계)

간단한 Lambda 예시: 이미지 리사이저

import boto3
from PIL import 

Source: …

import os

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # 1️⃣ Extract bucket & key from the S3 event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key    = event['Records'][0]['s3']['object']['key']

    # 2️⃣ Download the image to /tmp
    download_path = f'/tmp/{os.path.basename(key)}'
    s3.download_file(bucket, key, download_path)

    # 3️⃣ Open, resize, and save a thumbnail
    with Image.open(download_path) as img:
        img.thumbnail((128, 128))
        thumb_path = f'/tmp/thumb-{os.path.basename(key)}'
        img.save(thumb_path)

    # 4️⃣ Upload the thumbnail back to S3
    thumb_key = f'thumbnails/{os.path.basename(key)}'
    s3.upload_file(thumb_path, bucket, thumb_key)

    return {
        'statusCode': 200,
        'body': f'Thumbnail saved to {thumb_key}'
    }

Lambda가 여기서 잘 작동하는 이유:

• 작고 트리거 기반의 워크로드
• 짧은 실행 시간(몇 초)
• 최소한의 상태( /tmp 스토리지를 사용)

전형적인 사용 사례: 이미지 리사이징, 썸네일 생성, 간단한 API, 경량 데이터 처리.

Lambda가 한계에 부딪히는 경우

Lambda의 제한이 문제가 되는 시나리오:

• 장시간 실행 작업 – 최대 타임아웃이 15분.
• 높은 메모리/CPU 요구 – 워크로드가 Lambda가 제공하는 리소스를 초과할 수 있음.
• 콜드 스타트 지연 – 큰 패키지나 VPC에 연결된 함수에서 눈에 띔.
• 복잡한 네트워킹 – 지속적인 연결, 맞춤 VPC 설정, 저지연 서비스 간 통신 필요.
• 상태 유지 워크로드 – Lambda는 무상태이며, 상태를 유지하려면 외부 서비스(DynamoDB, S3 등)가 필요함.

이러한 경우 AWS Fargate의 컨테이너 또는 다른 관리형 서비스가 서버리스의 많은 장점(사용량 기반 요금, 자동 스케일링, 서버 관리 불필요)을 유지하면서 필요한 유연성을 제공합니다.

전체적으로 이번 세션은 “서버리스”가 하나의 제품이 아니라 사고방식이라는 점을 다시 한 번 상기시켜 주었습니다. Lambda이든 컨테이너이든, 혹은 하이브리드 접근이든 목표는 AWS가 무거운 작업을 처리하도록 하고, 여러분은 가치 창출에 집중하는 것입니다.

Lambda vs Fargate – 언제 어떤 서버리스 옵션을 사용해야 할까

세 가지 일반적인 비디오 처리 단계에 대한 간단 비교

왜 실패할까요?

• 비디오 처리는 ≈ 45 분이 걸릴 수 있습니다.
• Lambda는 강제 타임아웃 제한이 있습니다 (슬라이드에서는 15 분).
• 환경에 대한 더 많은 제어가 필요할 수 있습니다.
• 더 큰 종속성이나 특수 도구가 필요할 수 있습니다.

서버리스 기술이 강력하더라도, 작업에 맞는 적절한 도구를 선택해야 합니다. 바로 AWS Fargate가 필요한 이유입니다.

Lambda vs Fargate: Same pizza shop, different options

Comparing Lambda and Fargate

Bottom line – Lambda는 표준 메뉴에서 빠르게 주문하는 것과 같고, Fargate는 직접 레시피와 재료를 가져오면서도 주방을 직접 관리하지 않아도 되는 옵션이다.

Fargate – “당신만의 레시피 가져오기”

“당신만의 레시피 가져오기” – 애플리케이션을 컨테이너(Docker 이미지)로 패키징하면, AWS가 서버를 직접 관리할 필요 없이 실행해 줍니다.

“Fargate – 자유”의 세 가지 관점

1. 더 많은 제어

• 모든 프로그래밍 언어
• 모든 런타임 버전
• 사용자 정의 OS‑레벨 의존성
• Lambda에서는 쉽게 실행할 수 없는 특정 도구/라이브러리

2. 더 큰 용량

• 몇 시간 또는 며칠 동안 실행 가능
• 15분 제한 없음
• 훨씬 높은 메모리 및 CPU 옵션

3. 더 다양한 사용 사례

• 장시간 실행 프로세스
• 전통적인 환경을 기대하는 레거시 애플리케이션
• 특정 런타임 요구가 있는 마이크로서비스
• 배치 작업 및 백그라운드 처리

Fargate는 여전히 서버리스(관리할 서버가 없음)지만, 컨테이너 수준의 유연성을 제공합니다.

시도해볼 수 있는 아키텍처 패턴

슬라이드에서 실용적인 패턴

이러한 패턴은 교실에서 배운 개념을 실제 프로젝트(학교 앱, 부업, 인턴십 등)와 연결합니다.

서버리스를 NOT 사용할 때

트레이드오프에 대해 솔직하게

서버리스가 항상 최선의 선택은 아닙니다. 다음과 같은 경우에는 부적합할 수 있습니다:

• 지속적이고 높은 트래픽이 있어 항상 켜져 있는 인프라를 사용하면 비용이 더 저렴할 수 있는 경우.
• 환경을 보다 낮은 수준에서 깊은 제어가 필요한 경우.
• 작업이 서버리스 함수가 처리할 수 있는 시간보다 오래 실행되는 경우.
• 요구사항이 불확실하고 초기에 관리형 서비스를 너무 많이 사용해 복잡해질 위험이 있는 경우.

서버리스는 또 다른 도구일 뿐이며, 진정한 역량은 컨테이너나 기본 EC2 인스턴스와 비교해 언제 사용해야 하는지를 아는 것입니다.

Lambda vs Fargate: 간단한 의사결정 트리

선택을 위한 사고 모델

1. 코드를 실행해야 하나요?

   • 아니오 → 컴퓨팅이 필요 없습니다.
   • 예 → 계속 진행합니다.

2. 15분 이내에 작업이 끝나나요?

   • 예 →
     • 표준 런타임(Python, Node.js 등)이며 의존성이 관리 가능한가요?
       • 예 → Lambda (가장 빠르고 저렴함).
       • 아니오 → Fargate(또는 다른 컨테이너 기반 접근법) 고려.
   • 아니오 → 맞춤형 환경이 필요한 장기 실행 프로세스는 Fargate 사용.

세션의 주요 요점

• Serverless = “피자 주문하기” – 편리하지만 올바른 조각(Lambda vs Fargate)을 선택해야 합니다.
• Lambda는 짧고 무상태 함수와 표준 런타임에 적합합니다.
• Fargate는 컨테이너 유연성과 무제한 런타임을 제공하며, 여전히 서버 관리가 필요 없습니다.
• 트레이드‑오프(비용, 지연 시간, 제어, 실행 시간)를 이해하는 것이 필수적입니다.
• 새로운 프로젝트를 설계할 때 결정 트리와 아키텍처 패턴을 체크리스트로 활용하세요.

행복한 개발 되세요! 🚀

주요 내용

• 직접 레스토랑을 운영하지 마세요 – AWS가 인프라를 처리하도록 하세요.
• Lambda와 Fargate를 이해하세요 – 무작정 하나를 선택하지 마세요.
• 서버가 아니라 코드에 집중하세요 – 운영 파이프라인이 아니라 비즈니스 로직을 작성하세요.
• 가치에 대해 지불하고, 유휴 시간에 대해선 지불하지 마세요 – 코드가 실행될 때만 비용이 발생합니다.

개인적으로 가장 큰 교훈은 “서버리스는 Lambda에만 국한된 것이 아니다” 라는 점이었습니다. 컨테이너를 사용할 때도 AWS가 리소스를 설정하고 확장해 주는 한, 애플리케이션에 주력한다면 서버리스라고 생각할 수 있습니다.

결론

이번 AWS Student Community Day in Tirupati 세션은 정말 도움이 많이 되었습니다. 좋은 기술 발표는 단순히 기능을 나열하는 것이 아니라, 여러분이 사물을 이해하는 방식을 바꾸어 주기 때문입니다. 피자 예시, Lambda의 한계에 대한 자유로운 토론, 그리고 “서버리스 컨테이너” 옵션으로서 강력한 Fargate 소개는 특히 이 서비스들을 처음 배우는 학생들에게 주제를 더 쉽게 파악하도록 만들었습니다.

AWS Community Builder 로서 이런 행사는 저에게 큰 동기부여가 됩니다. 올바른 예시와 사고 방식을 통해 호기심이 얼마나 빠르게 실제 프로젝트로 이어질 수 있는지를 보여주기 때문이죠.

이 주제가 흥미롭다면, 여러분 일상에서 작은 사용 사례를 하나 골라보세요—예를 들어 앱에서 이미지를 처리하거나 정기적인 정리 작업을 실행하는 것처럼—그리고 Lambda 혹은 Fargate 로 구현해 보세요. 직접 손을 움직여 경험하는 것이 어떤 발표보다도 더 큰 배움을 줍니다.

저자 소개

AWS 커뮤니티 빌더로서, 저는 직접 경험하고 이벤트를 통해 배운 것을 공유하는 것을 즐기며, 다른 사람들이 길을 찾는 데 도움을 주는 것을 좋아합니다. 이 내용이 도움이 되었거나 질문이 있으면 언제든지 연락 주세요! 🚀

🔗 LinkedIn에서 저와 연결하세요

References

• 이벤트: AWS Student Community Day Tirupati
• 주제: AWS Lambda와 Fargate가 앱 구축 방식을 바꾸는 방법
• 날짜: 2025년 11월 01일

또한 게시된 곳

• AWS Builder Center
• Hashnode