서버리스 아키텍처 완벽 입문 가이드

서버 관리 걱정 없이 코드만 작성하는 서버리스의 세계로 안내합니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 상황과 비유로 풀어낸 서버리스 아키텍처 입문서입니다.

1. 서버리스란 무엇인가

입사 6개월 차 김개발 씨는 오늘도 서버 점검 알림에 잠을 설쳤습니다. 새벽 3시에 울리는 서버 다운 알림, 주말마다 해야 하는 서버 업데이트.

"서버만 없다면 얼마나 좋을까?" 하고 중얼거리던 그때, 선배 박시니어 씨가 말했습니다. "그럼 서버리스를 한번 써보는 게 어때요?"

서버리스란 말 그대로 서버가 없다는 뜻이 아닙니다. 정확히는 개발자가 서버를 직접 관리하지 않아도 되는 클라우드 컴퓨팅 모델입니다.

마치 전기를 쓸 때 발전소를 직접 관리하지 않는 것처럼, 서버리스에서는 코드 실행에만 집중하고 나머지는 클라우드 제공자가 알아서 처리합니다.

다음 코드를 살펴봅시다.

// AWS Lambda 함수 예제 - 가장 기본적인 서버리스 함수
exports.handler = async (event) => {
    // 요청이 들어올 때만 실행됩니다
    const name = event.queryStringParameters?.name || '손님';

    // 비즈니스 로직에만 집중
    const greeting = `안녕하세요, ${name}님!`;

    // 응답 반환
    return {
        statusCode: 200,
        body: JSON.stringify({ message: greeting })
    };
    // 함수가 끝나면 자동으로 리소스 해제
};

김개발 씨는 지금까지 회사에서 전통적인 서버 기반 개발을 해왔습니다. EC2 인스턴스를 띄우고, 운영체제를 설치하고, 보안 패치를 적용하고, 모니터링 시스템을 구축하는 일까지 모두 개발팀의 몫이었습니다.

특히 힘들었던 것은 새벽 시간대 장애 대응이었습니다. 서버가 다운되면 누군가는 깨어나서 재부팅을 해야 했고, 트래픽이 갑자기 증가하면 급하게 서버를 추가해야 했습니다.

개발보다 서버 관리에 더 많은 시간을 쓰는 것 같았습니다. "서버리스가 뭔데요?" 김개발 씨가 물었습니다.

박시니어 씨는 커피를 한 모금 마시고 설명을 시작했습니다. "서버리스는 말 그대로 서버가 없는 건 아니에요.

정확히는 서버를 우리가 관리하지 않는다는 뜻이죠." 쉽게 비유하자면, 서버리스는 마치 택시를 이용하는 것과 같습니다. 자동차를 직접 소유하면 주차비, 보험료, 정비비용이 계속 나갑니다.

운전하지 않을 때도 비용이 발생하죠. 하지만 택시는 필요할 때만 부르고, 탄 시간만큼만 요금을 냅니다.

차량 관리는 택시 회사가 알아서 합니다. 서버리스도 마찬가지입니다.

코드가 실행될 때만 컴퓨팅 리소스를 사용하고, 그 시간만큼만 비용을 지불합니다. 서버 관리는 AWS, Google Cloud, Azure 같은 클라우드 제공자가 알아서 해줍니다.

김개발 씨는 위의 코드를 살펴보았습니다. 놀랍게도 서버 설정이나 네트워크 구성 같은 코드가 전혀 없었습니다.

오로지 비즈니스 로직만 있었습니다. "이 코드는 언제 실행되나요?" 김개발 씨가 물었습니다.

"바로 그게 핵심이에요." 박시니어 씨가 답했습니다. "HTTP 요청이 들어올 때, 파일이 업로드될 때, 데이터베이스에 변경이 생길 때처럼 이벤트가 발생할 때만 실행됩니다.

요청이 없으면 아예 실행되지 않죠." 위 코드의 첫 번째 줄을 보면 exports.handler라는 함수를 정의합니다. 이것이 바로 Lambda 함수의 진입점입니다.

이벤트가 발생하면 AWS Lambda가 자동으로 이 함수를 호출합니다. 세 번째 줄에서는 요청 파라미터에서 이름을 추출합니다.

만약 이름이 없다면 기본값으로 '손님'을 사용합니다. 여섯 번째 줄에서 인사말을 생성하고, 아홉 번째 줄부터 HTTP 응답을 만들어 반환합니다.

가장 중요한 부분은 마지막 주석입니다. 함수가 끝나면 자동으로 리소스가 해제됩니다.

개발자가 메모리를 정리하거나 연결을 닫을 필요가 없습니다. 다음 요청이 올 때까지 아무런 리소스도 사용하지 않습니다.

실제 현업에서 이것이 얼마나 큰 장점인지 예를 들어보겠습니다. 쇼핑몰 웹사이트를 운영한다고 가정해봅시다.

평소에는 하루에 1000명 정도의 방문자가 있지만, 블랙프라이데이 같은 특별 세일 기간에는 10만 명이 몰립니다. 전통적인 서버 방식이라면 10만 명을 감당할 수 있는 서버를 1년 내내 유지해야 합니다.

364일은 서버의 99%가 놀고 있는 셈이죠. 하지만 서버리스를 사용하면 자동으로 확장됩니다.

1000명이 접속하면 필요한 만큼만, 10만 명이 접속하면 그만큼만 리소스가 할당됩니다. 비용도 실제 사용한 만큼만 나갑니다.

물론 서버리스가 만능은 아닙니다. 하지만 적절한 상황에서 사용하면 엄청난 효율을 가져다줍니다.

김개발 씨는 이제 이해가 되었습니다. "그러니까 제가 해야 할 일은 이 함수 안의 코드만 작성하면 되는 거네요?" "정확합니다!" 박시니어 씨가 웃으며 답했습니다.

"서버 관리는 AWS에게 맡기고, 우리는 가치를 만드는 코드에만 집중하는 거죠." 서버리스를 이해하면 개발자로서 한 단계 더 성장할 수 있습니다. 인프라 관리에서 해방되어 진짜 중요한 비즈니스 로직에 집중할 수 있기 때문입니다.

실전 팁

💡 - 서버리스는 '서버가 없다'가 아니라 '서버 관리를 하지 않는다'는 의미입니다

이벤트 기반으로 동작하므로 요청이 없으면 비용이 발생하지 않습니다
자동 확장되므로 트래픽 급증에도 안정적으로 대응할 수 있습니다

2. 서버리스 vs 서버 기반

"그럼 모든 걸 서버리스로 만들면 되는 거 아닌가요?" 김개발 씨가 신이 나서 물었습니다. 박시니어 씨는 고개를 가로저었습니다.

"아니요, 각각 장단점이 있어서 상황에 맞게 선택해야 해요. 비교해보면 더 명확하게 이해할 수 있을 거예요."

서버 기반 아키텍처는 개발자가 서버를 직접 관리하며 항상 실행 상태를 유지합니다. 반면 서버리스 아키텍처는 이벤트가 발생할 때만 실행되고 클라우드 제공자가 모든 인프라를 관리합니다.

각각의 방식은 서로 다른 비용 구조, 확장성, 관리 복잡도를 가지고 있습니다.

다음 코드를 살펴봅시다.

// 전통적인 서버 기반 (Express.js)
const express = require('express');
const app = express();

// 서버는 24시간 실행됩니다
app.get('/api/greeting', (req, res) => {
    const name = req.query.name || '손님';
    res.json({ message: `안녕하세요, ${name}님!` });
});

// 서버가 계속 떠 있어야 함
app.listen(3000, () => {
    console.log('서버가 3000 포트에서 실행 중...');
});

// 서버리스 (Lambda)는 요청이 올 때만 실행
// 위의 Lambda 코드와 비교해보세요

박시니어 씨는 화이트보드에 두 개의 다이어그램을 그리기 시작했습니다. 하나는 전통적인 서버, 다른 하나는 서버리스 아키텍처였습니다.

"먼저 전통적인 서버 기반 방식을 볼까요?" 박시니어 씨가 왼쪽 다이어그램을 가리켰습니다. 김개발 씨가 지금까지 사용해온 방식은 서버 기반 아키텍처였습니다.

EC2 인스턴스나 온프레미스 서버에 Node.js나 Python 같은 런타임을 설치하고, Express나 Django 같은 웹 프레임워크로 애플리케이션을 만듭니다. 그리고 이 서버는 24시간 365일 계속 실행됩니다.

마치 가게를 운영하는 것과 같습니다. 손님이 오든 안 오든 가게 문을 열어두고, 전기세와 임대료를 계속 내야 합니다.

직원도 항상 대기하고 있어야 하죠. 위의 Express.js 코드를 보면, 11번째 줄에서 app.listen(3000)을 호출합니다.

이 순간부터 서버는 계속 실행됩니다. 요청이 1초에 한 번 오든, 하루에 한 번 오든, 아예 안 오든 상관없이 서버는 계속 떠 있습니다.

메모리를 차지하고, CPU 사이클을 소비하고, 비용이 발생합니다. "그럼 서버리스는 어떻게 다른가요?" 김개발 씨가 물었습니다.

박시니어 씨는 오른쪽 다이어그램을 가리켰습니다. "서버리스는 필요할 때만 깨어나는 방식이에요." 서버리스는 마치 자판기와 같습니다.

평소에는 전원만 켜져 있다가, 동전을 넣고 버튼을 누르는 순간에만 작동합니다. 음료를 뽑아주고 나면 다시 대기 상태로 돌아갑니다.

실제로 작동한 시간만큼만 에너지를 소비합니다. Lambda 함수는 HTTP 요청, 파일 업로드, 데이터베이스 변경 같은 이벤트가 발생할 때만 실행됩니다.

요청을 처리하고 나면 자동으로 종료됩니다. 다음 요청이 올 때까지 아무런 리소스도 사용하지 않습니다.

이제 비용을 비교해보겠습니다. 서버 기반 방식에서는 고정 비용이 발생합니다.

AWS EC2 t3.medium 인스턴스는 한 달에 약 30달러입니다. 트래픽이 적든 많든 이 비용은 동일합니다.

만약 사용자가 거의 없는 사내 도구를 만든다면? 하루에 10번 정도만 사용되는데도 한 달 내내 서버 비용을 내야 합니다.

서버리스는 종량제 비용입니다. Lambda는 요청 100만 건당 0.20달러, 실행 시간 GB-초당 0.0000166667달러를 청구합니다.

게다가 매달 100만 건의 무료 요청이 제공됩니다. 사내 도구처럼 트래픽이 적으면 거의 무료로 운영할 수 있습니다.

확장성 측면에서도 큰 차이가 있습니다. 서버 기반에서 트래픽이 갑자기 10배 증가하면 어떻게 될까요?

서버가 다운될 수 있습니다. 급하게 서버를 추가하려면 최소 몇 분에서 몇 시간이 걸립니다.

로드밸런서 설정도 변경해야 하고, 오토 스케일링 정책도 조정해야 합니다. 서버리스는 자동으로 확장됩니다.

동시 요청이 1개든 10,000개든 Lambda는 자동으로 필요한 만큼의 인스턴스를 생성합니다. 개발자는 아무것도 할 필요가 없습니다.

설정도 필요 없습니다. 하지만 서버리스가 항상 좋은 건 아닙니다.

콜드 스타트라는 문제가 있습니다. 한동안 요청이 없다가 새로운 요청이 오면, Lambda는 새로운 실행 환경을 준비해야 합니다.

이 과정에서 몇 백 밀리초에서 몇 초까지 지연이 발생할 수 있습니다. 실시간 거래 시스템처럼 밀리초 단위의 응답 속도가 중요한 서비스에는 적합하지 않을 수 있습니다.

또한 서버리스는 실행 시간 제한이 있습니다. AWS Lambda는 최대 15분까지만 실행할 수 있습니다.

대용량 동영상 인코딩처럼 오래 걸리는 작업에는 적합하지 않습니다. 김개발 씨는 고개를 끄덕였습니다.

"그러니까 각각 장단점이 있어서, 상황에 맞게 선택해야 하는 거네요?" "바로 그겁니다!" 박시니어 씨가 답했습니다. "API 서버, 이미지 처리, 데이터 변환 같은 작업은 서버리스가 훌륭합니다.

하지만 WebSocket 서버, 게임 서버, 장시간 실행되는 배치 작업은 전통적인 서버가 더 나을 수 있어요." 둘 중 어느 것이 더 좋다는 게 아닙니다. 프로젝트의 특성, 예산, 트래픽 패턴을 고려해서 적재적소에 사용하는 것이 중요합니다.

실전 팁

💡 - 트래픽이 불규칙하거나 적다면 서버리스가 비용 효율적입니다

밀리초 단위의 일관된 응답 속도가 필요하면 서버 기반을 고려하세요
두 방식을 혼합해서 사용하는 하이브리드 아키텍처도 가능합니다

3. FaaS 개념 이해

"서버리스를 검색하다 보니까 FaaS라는 용어가 자주 나오던데, 이게 뭔가요?" 김개발 씨가 물었습니다. 박시니어 씨는 웃으며 답했습니다.

"FaaS는 서버리스의 핵심 개념이에요. 함수 하나하나가 독립적인 서비스가 되는 거죠."

**FaaS(Function as a Service)**는 서버리스 컴퓨팅의 대표적인 형태로, 개별 함수를 배포하고 실행하는 클라우드 서비스입니다. 개발자는 함수만 작성하고, 클라우드 제공자가 실행 환경, 확장, 모니터링을 모두 처리합니다.

AWS Lambda, Google Cloud Functions, Azure Functions가 대표적인 FaaS 플랫폼입니다.

다음 코드를 살펴봅시다.

// 이미지 업로드를 처리하는 FaaS 함수
const AWS = require('aws-sdk');
const sharp = require('sharp');

exports.handler = async (event) => {
    // S3에 이미지가 업로드되면 자동 실행
    const bucket = event.Records[0].s3.bucket.name;
    const key = event.Records[0].s3.object.key;

    // 원본 이미지 다운로드
    const s3 = new AWS.S3();
    const image = await s3.getObject({ Bucket: bucket, Key: key }).promise();

    // 썸네일 생성 (이 함수의 단 하나의 책임)
    const thumbnail = await sharp(image.Body)
        .resize(200, 200)
        .toBuffer();

    // 썸네일 저장
    await s3.putObject({
        Bucket: bucket,
        Key: `thumbnails/${key}`,
        Body: thumbnail
    }).promise();

    return { statusCode: 200, body: '썸네일 생성 완료' };
};

김개발 씨는 회사 게시판 시스템을 개발할 때 이미지 업로드 기능을 구현한 적이 있습니다. 사용자가 이미지를 올리면 서버에서 받아서 저장하고, 썸네일을 만들고, 데이터베이스에 정보를 기록했습니다.

모든 로직이 하나의 큰 애플리케이션 안에 들어 있었습니다. "FaaS는 그것과 어떻게 다른가요?" 김개발 씨가 물었습니다.

박시니어 씨는 레고 블록을 예로 들었습니다. "전통적인 서버는 하나의 큰 블록이에요.

안에 모든 기능이 다 들어있죠. 반면 FaaS는 작은 레고 블록들을 조립하는 것과 같아요." **FaaS(Function as a Service)**는 말 그대로 함수를 서비스로 제공하는 것입니다.

하나의 함수가 하나의 독립적인 마이크로서비스가 됩니다. 각 함수는 단 하나의 책임만 가집니다.

위의 코드를 보면, 이 함수는 오직 썸네일 생성만 합니다. 이미지를 받고, 리사이즈하고, 저장합니다.

그게 전부입니다. 사용자 인증, 파일 검증, 데이터베이스 저장 같은 다른 작업은 다른 함수들이 담당합니다.

여섯 번째 줄을 보면 흥미로운 점이 있습니다. 이 함수는 S3 이벤트를 감지합니다.

누군가 S3 버킷에 이미지를 업로드하면 자동으로 이 함수가 실행됩니다. 개발자가 스케줄러를 만들거나 모니터링 코드를 작성할 필요가 없습니다.

일곱 번째와 여덟 번째 줄에서는 업로드된 파일 정보를 가져옵니다. 버킷 이름과 파일 키를 추출합니다.

열한 번째 줄에서는 S3 클라이언트를 생성하고, 열두 번째 줄에서 원본 이미지를 다운로드합니다. 핵심은 열다섯 번째 줄부터입니다.

sharp 라이브러리를 사용해서 이미지를 200x200 픽셀로 리사이즈합니다. 그리고 스무 번째 줄부터 생성된 썸네일을 thumbnails/ 폴더에 저장합니다.

이 모든 과정이 이벤트 기반으로 자동 실행됩니다. 개발자는 함수만 작성하면 됩니다.

실제 서비스에서 FaaS가 어떻게 활용되는지 살펴보겠습니다. 넷플릭스는 동영상 인코딩에 AWS Lambda를 사용합니다.

사용자가 동영상을 업로드하면, 수백 개의 Lambda 함수가 동시에 실행되어 각기 다른 해상도와 포맷으로 인코딩합니다. 4K, 1080p, 720p, 모바일용 등 모든 버전을 병렬로 처리합니다.

만약 전통적인 서버로 이걸 처리한다면? 엄청난 수의 서버를 유지해야 합니다.

코카콜라는 자판기 관리 시스템에 FaaS를 사용합니다. 전 세계 수백만 대의 자판기가 재고 정보를 전송하면, 각 이벤트마다 Lambda 함수가 실행되어 데이터를 처리하고 분석합니다.

자판기마다 서버를 둘 수는 없으니까요. 김개발 씨는 문득 궁금해졌습니다.

"그럼 함수끼리는 어떻게 통신하나요?" "좋은 질문이에요!" 박시니어 씨가 답했습니다. "FaaS 함수들은 보통 이벤트 체인으로 연결됩니다." 예를 들어 사용자가 회원가입을 한다고 가정해봅시다.

첫 번째 함수가 사용자 정보를 데이터베이스에 저장합니다. 이 작업이 완료되면 DynamoDB Streams가 이벤트를 발생시킵니다.

두 번째 함수가 이 이벤트를 받아서 환영 이메일을 보냅니다. 세 번째 함수는 사용자 분석 데이터를 업데이트합니다.

각 함수는 독립적입니다. 하나가 실패해도 다른 함수에 영향을 주지 않습니다.

이메일 발송이 실패해도 회원가입 자체는 정상적으로 완료됩니다. 느슨한 결합이 이루어지는 거죠.

FaaS의 가장 큰 장점은 관심사의 분리입니다. 각 함수가 하나의 일만 잘하면 됩니다.

코드가 짧아지고, 테스트하기 쉬워지고, 유지보수가 간단해집니다. 하지만 주의할 점도 있습니다.

함수가 너무 많아지면 관리가 복잡해질 수 있습니다. 100개의 함수가 서로 얽혀 있다면?

디버깅이 어려워집니다. 따라서 적절한 수준으로 함수를 그룹화하는 것이 중요합니다.

김개발 씨는 이제 FaaS의 개념이 명확해졌습니다. "함수 하나가 하나의 서비스가 되는 거네요.

마치 레고 블록처럼요!" "정확합니다!" 박시니어 씨가 엄지를 들어 올렸습니다. "작은 함수들을 조합해서 큰 시스템을 만드는 거죠." FaaS를 잘 활용하면 유연하고 확장 가능한 시스템을 빠르게 구축할 수 있습니다.

각 함수에 집중하다 보면 자연스럽게 좋은 아키텍처가 만들어집니다.

실전 팁

💡 - 하나의 함수는 하나의 책임만 가지도록 설계하세요

함수 간 통신은 이벤트 기반으로 느슨하게 결합하세요
너무 많은 함수로 쪼개면 관리가 복잡해질 수 있으니 적절한 균형을 찾으세요

4. 서버리스 장점

월요일 아침, 김개발 씨는 주말 내내 걱정했던 서버 점검을 무사히 마쳤습니다. 하지만 박시니어 씨는 편안한 표정이었습니다.

"저는 주말에 아무것도 안 했어요. 제가 만든 서버리스 시스템은 알아서 잘 돌아가거든요." 김개발 씨는 서버리스의 장점이 궁금해졌습니다.

서버리스 아키텍처는 운영 부담 제로, 자동 확장성, 비용 최적화, 빠른 개발 속도라는 네 가지 핵심 장점을 제공합니다. 개발자는 인프라 관리에서 완전히 해방되어 비즈니스 로직에만 집중할 수 있으며, 사용한 만큼만 비용을 지불하는 완벽한 종량제 모델을 경험할 수 있습니다.

다음 코드를 살펴봅시다.

// 자동 확장되는 API 엔드포인트
exports.handler = async (event) => {
    // 동시 요청이 1개든 10,000개든 자동으로 처리
    const userId = event.pathParameters.userId;

    // 비즈니스 로직에만 집중
    const user = await getUserFromDB(userId);
    const recommendations = await calculateRecommendations(user);

    // 인프라 걱정은 AWS가 알아서
    return {
        statusCode: 200,
        body: JSON.stringify(recommendations)
    };
};

// 서버 관리, 스케일링, 로드밸런싱,
// 보안 패치 등은 모두 자동으로 처리됩니다

async function getUserFromDB(userId) {
    // DB 조회 로직
    return { id: userId, preferences: ['기술', '여행'] };
}

async function calculateRecommendations(user) {
    // 추천 알고리즘
    return ['서버리스 강의', '클라우드 여행기'];
}

김개발 씨는 지난주 금요일 밤을 떠올렸습니다. 갑자기 트래픽이 폭증하면서 서버가 다운되었고, 급하게 서버를 추가하느라 밤을 새웠습니다.

주말에는 보안 패치를 적용하고 서버를 재부팅했습니다. 월요일 아침인데도 피곤함이 가시지 않았습니다.

반면 박시니어 씨는 활기찬 모습이었습니다. "주말에 뭐 하셨어요?" 김개발 씨가 물었습니다.

"가족들이랑 등산 다녀왔어요. 제 서비스는 서버리스라서 신경 쓸 게 없었거든요." 박시니어 씨가 웃으며 답했습니다.

첫 번째 장점은 운영 부담이 없다는 것입니다. 전통적인 서버를 운영하려면 해야 할 일이 산더미처럼 쌓입니다.

운영체제 업데이트, 보안 패치 적용, 서버 모니터링, 로그 관리, 백업 설정, 장애 대응 등. 개발보다 운영에 더 많은 시간을 쓰게 됩니다.

하지만 서버리스에서는 이 모든 것을 클라우드 제공자가 알아서 처리합니다. 보안 패치가 나오면?

AWS가 자동으로 적용합니다. 서버가 다운되면?

AWS가 자동으로 복구합니다. 개발자는 코드만 작성하면 됩니다.

위의 코드를 보세요. 어디에도 서버 설정이나 인프라 코드가 없습니다.

오직 비즈니스 로직만 있습니다. 사용자 정보를 가져오고, 추천 알고리즘을 실행하고, 결과를 반환합니다.

그게 전부입니다. 두 번째 장점은 완벽한 자동 확장입니다.

김개발 씨가 운영하는 서비스는 평소에 하루 1,000명 정도가 사용합니다. 하지만 어느 날 TV에 소개되면서 갑자기 100,000명이 몰렸습니다.

서버는 감당하지 못하고 다운되었습니다. 급하게 서버를 추가했지만, Auto Scaling 설정이 제대로 되어 있지 않아서 시간이 오래 걸렸습니다.

서버리스는 이런 걱정이 없습니다. Lambda는 동시 요청 수에 따라 자동으로 확장됩니다.

요청이 1개 오면 1개의 인스턴스가, 10,000개가 오면 10,000개의 인스턴스가 자동으로 생성됩니다. 설정도 필요 없고, 기다릴 필요도 없습니다.

순식간에 확장됩니다. 세 번째 장점은 비용 최적화입니다.

김개발 씨의 회사는 사내 도구를 위해 EC2 서버를 24시간 운영합니다. 실제로는 업무 시간(9시~6시)에만 사용되는데도 말이죠.

한 달에 30달러의 서버 비용이 나갑니다. 하지만 실제 사용 시간은 전체의 20%도 안 됩니다.

80%는 그냥 버려지는 셈입니다. 서버리스는 사용한 만큼만 비용을 지불합니다.

요청이 100번 오면 100번치 비용만 나갑니다. 게다가 Lambda는 매달 100만 건의 무료 요청을 제공합니다.

사내 도구처럼 트래픽이 적은 서비스는 거의 무료로 운영할 수 있습니다. 실제 사례를 보겠습니다.

어떤 스타트업은 서버 기반에서 서버리스로 마이그레이션한 후 월 인프라 비용이 500달러에서 50달러로 90% 감소했습니다. 동일한 서비스를 10분의 1 비용으로 운영하게 된 것입니다.

네 번째 장점은 빠른 개발 속도입니다. 김개발 씨가 새로운 API를 만들려면 여러 단계를 거쳐야 했습니다.

EC2 인스턴스 생성, 보안 그룹 설정, 로드밸런서 구성, 도메인 연결, SSL 인증서 설정 등. 코드를 작성하기도 전에 인프라 설정에 하루가 걸렸습니다.

서버리스는 코드만 작성하면 끝입니다. Lambda 함수를 만들고, API Gateway를 연결하면 즉시 전 세계에서 접근 가능한 API가 완성됩니다.

30분이면 충분합니다. 인프라 설정은 클라우드가 알아서 해줍니다.

실제로 많은 스타트업이 서버리스로 **MVP(Minimum Viable Product)**를 빠르게 출시합니다. 시장 반응을 보고 나서 확장하거나 수정하는 것이 훨씬 효율적이기 때문입니다.

다섯 번째 장점은 내장된 고가용성입니다. 전통적인 서버는 단일 장애 지점이 될 수 있습니다.

서버 하나가 다운되면 전체 서비스가 중단됩니다. 고가용성을 위해 여러 가용 영역에 서버를 배치하고, 로드밸런서를 설정하고, 헬스 체크를 구현해야 합니다.

복잡하고 비용도 많이 듭니다. Lambda는 기본적으로 여러 가용 영역에 분산되어 실행됩니다.

한 데이터센터가 통째로 다운되어도 서비스는 계속됩니다. 개발자가 아무것도 설정하지 않아도 자동으로 고가용성이 보장됩니다.

김개발 씨는 이제 왜 박시니어 씨가 주말을 편안하게 보낼 수 있었는지 이해했습니다. 서버리스는 운영 부담을 없애주고, 자동으로 확장되며, 비용을 절감하고, 개발 속도를 높여줍니다.

"이제 이해가 되네요." 김개발 씨가 말했습니다. "다음 프로젝트는 꼭 서버리스로 해봐야겠어요!" 서버리스의 장점을 제대로 활용하면, 더 적은 비용으로 더 안정적인 서비스를 더 빠르게 만들 수 있습니다.

그리고 주말에는 등산을 갈 수 있습니다.

실전 팁

💡 - 운영 인력이 부족한 스타트업이나 소규모 팀에게 특히 유용합니다

트래픽 패턴이 불규칙한 서비스는 비용 절감 효과가 큽니다
MVP를 빠르게 출시하고 검증할 때 서버리스를 활용하세요

5. 서버리스 단점과 제약

서버리스의 장점에 매료된 김개발 씨는 모든 프로젝트를 서버리스로 바꾸려고 했습니다. 하지만 박시니어 씨가 제동을 걸었습니다.

"잠깐만요. 서버리스도 완벽하지는 않아요.

단점과 제약사항을 알아야 제대로 사용할 수 있죠."

서버리스는 콜드 스타트 지연, 실행 시간 제한, 상태 관리의 어려움, 벤더 종속성이라는 명확한 제약을 가지고 있습니다. 이런 한계를 이해하지 못하고 무분별하게 사용하면 오히려 문제가 발생할 수 있습니다.

적절한 상황에서 올바르게 사용하는 것이 중요합니다.

다음 코드를 살펴봅시다.

// 콜드 스타트 문제 예시
exports.handler = async (event) => {
    // 첫 요청시 초기화 시간이 추가됨 (수백ms ~ 수초)
    const heavyLibrary = require('tensorflow'); // 큰 라이브러리 로딩

    // 한동안 요청이 없다가 다시 호출되면
    // 새로운 컨테이너를 시작하는 시간이 걸림

    const result = await processData(event.data);
    return result;
};

// 실행 시간 제한 (Lambda는 최대 15분)
exports.longRunningTask = async (event) => {
    // 이런 작업은 서버리스에 부적합
    for (let i = 0; i < 1000000; i++) {
        await processLargeFile(i); // 몇 시간 걸리는 작업
    }
    // 15분이 지나면 강제 종료됨!
};

// 상태를 유지할 수 없음
let counter = 0; // 이 값은 요청마다 초기화됨
exports.statefulHandler = async (event) => {
    counter++; // 의미 없는 코드
    return counter; // 항상 1을 반환
};

김개발 씨는 신나는 마음으로 기존 프로젝트를 서버리스로 마이그레이션하기 시작했습니다. 하지만 곧 문제에 부딪혔습니다.

실시간 채팅 서비스의 응답 속도가 들쭉날쭉했고, 대용량 동영상 처리 작업은 중간에 끊겼습니다. "무엇이 잘못된 걸까요?" 김개발 씨가 좌절한 표정으로 물었습니다.

박시니어 씨는 차분하게 설명하기 시작했습니다. "서버리스는 만능이 아니에요.

명확한 한계가 있죠." 첫 번째 문제는 콜드 스타트입니다. Lambda 함수가 한동안 호출되지 않으면 실행 환경이 종료됩니다.

다시 요청이 오면 새로운 컨테이너를 시작하고, 런타임을 로딩하고, 코드를 초기화해야 합니다. 이 과정에서 수백 밀리초에서 심하면 몇 초까지 지연이 발생합니다.

위 코드의 세 번째 줄을 보세요. TensorFlow 같은 무거운 라이브러리를 로딩하면 콜드 스타트 시간이 더 길어집니다.

사용자가 버튼을 눌렀는데 3초 동안 아무 반응이 없다면? 사용자는 버그라고 생각할 것입니다.

실제 사례를 보겠습니다. 한 쇼핑몰은 결제 API를 Lambda로 만들었습니다.

대부분의 요청은 빠르게 처리되었지만, 새벽 시간대에 첫 주문이 들어오면 5초 넘게 걸렸습니다. 콜드 스타트 때문이었습니다.

고객들은 결제가 느리다고 불만을 제기했습니다. 해결 방법은 있습니다.

Provisioned Concurrency를 사용하면 함수를 미리 워밍업해 둘 수 있습니다. 하지만 이것은 추가 비용이 발생합니다.

서버리스의 비용 이점이 줄어드는 셈입니다. 두 번째 문제는 실행 시간 제한입니다.

AWS Lambda는 최대 15분까지만 실행할 수 있습니다. 그 이상 걸리는 작업은 중간에 강제 종료됩니다.

위 코드의 열 번째 줄처럼 대용량 파일을 처리하거나, 복잡한 데이터 분석을 수행하거나, 머신러닝 모델을 학습시키는 작업은 서버리스에 적합하지 않습니다. 김개발 씨가 만들려던 동영상 인코딩 시스템은 한 파일당 30분 이상 걸렸습니다.

Lambda로는 불가능했습니다. 이런 경우에는 AWS Batch나 ECS Fargate 같은 다른 서비스를 사용해야 합니다.

세 번째 문제는 상태를 유지할 수 없다는 점입니다. 위 코드의 스물한 번째 줄을 보세요.

counter라는 변수를 선언하고 요청마다 증가시키려고 합니다. 하지만 이것은 작동하지 않습니다.

Lambda 함수는 **무상태(Stateless)**입니다. 각 요청은 독립적으로 처리되며, 이전 요청의 데이터를 기억하지 못합니다.

WebSocket 서버처럼 연결 상태를 유지해야 하는 서비스는 어떻게 할까요? 가능은 하지만 복잡합니다.

DynamoDB나 ElastiCache 같은 외부 저장소에 상태를 저장해야 합니다. 코드가 복잡해지고 비용도 증가합니다.

네 번째 문제는 벤더 종속성입니다. Lambda 함수는 AWS에 강하게 결합되어 있습니다.

AWS의 API, SDK, 서비스들을 사용하게 됩니다. 나중에 Google Cloud나 Azure로 옮기려면?

코드를 전부 다시 작성해야 할 수도 있습니다. 박시니어 씨는 예전에 이런 경험을 했습니다.

Lambda로 만든 시스템을 Google Cloud로 마이그레이션하려다가 3개월이 걸렸습니다. API가 다르고, 동작 방식이 다르고, 제약사항도 달랐습니다.

거의 처음부터 다시 만드는 수준이었습니다. 다섯 번째 문제는 디버깅의 어려움입니다.

전통적인 서버에서는 로그를 보고, 디버거를 붙이고, 단계별로 실행해볼 수 있습니다. 하지만 Lambda는 로컬 환경과 다릅니다.

같은 코드가 로컬에서는 잘 작동하는데 Lambda에서는 안 될 수 있습니다. 여러 Lambda 함수가 연결된 시스템에서 문제가 생기면?

어느 함수에서 오류가 났는지 찾기 어렵습니다. 분산 추적 시스템을 구축해야 하는데, 이것도 추가 작업입니다.

여섯 번째 문제는 비용의 불확실성입니다. 서버리스는 사용한 만큼만 비용을 낸다고 했습니다.

좋은 점이지만, 반대로 생각하면 예측이 어렵다는 뜻입니다. 갑자기 트래픽이 폭증하면?

예상치 못한 거액의 청구서를 받을 수 있습니다. 실제로 어떤 개발자는 Lambda 함수에 버그가 있어서 무한 루프를 돌았습니다.

하루 만에 수천 달러의 비용이 청구되었습니다. 서버였다면 고정 비용이었겠지만, 서버리스는 실행한 만큼 과금됩니다.

김개발 씨는 고개를 끄덕였습니다. "그러니까 실시간 채팅이나 장시간 작업은 서버리스가 적합하지 않군요." "정확해요." 박시니어 씨가 답했습니다.

"서버리스는 강력한 도구지만, 적재적소에 사용해야 합니다. 모든 문제의 해답은 아니에요." 서버리스의 한계를 이해하면 더 현명하게 사용할 수 있습니다.

장점을 살리고 단점을 피하는 것, 그것이 진짜 실력입니다.

실전 팁

💡 - 실시간성이 중요하거나 일관된 응답 속도가 필요하면 Provisioned Concurrency를 고려하세요

15분 이상 걸리는 작업은 AWS Batch나 Step Functions를 사용하세요
벤더 종속성을 줄이려면 Serverless Framework 같은 추상화 도구를 사용하세요

6. 서버리스 활용 사례

"그럼 실제로 서버리스는 어떤 곳에 쓰면 좋을까요?" 김개발 씨가 물었습니다. 박시니어 씨는 노트북을 열어 실제 프로젝트들을 보여주기 시작했습니다.

"생각보다 훨씬 다양한 곳에 사용할 수 있어요. 몇 가지 대표적인 사례를 보여드릴게요."

서버리스는 REST API 백엔드, 이미지/동영상 처리, 실시간 데이터 처리, 예약 작업, 웹훅 처리 등 다양한 실무 시나리오에서 활용됩니다. 특히 트래픽이 불규칙하거나, 이벤트 기반 처리가 필요하거나, 빠른 개발이 중요한 경우에 탁월한 효과를 발휘합니다.

다음 코드를 살펴봅시다.

// 사례 1: 이미지 썸네일 자동 생성
const AWS = require('aws-sdk');
const sharp = require('sharp');
const s3 = new AWS.S3();

exports.createThumbnail = async (event) => {
    // S3에 이미지 업로드되면 자동 실행
    const bucket = event.Records[0].s3.bucket.name;
    const key = decodeURIComponent(event.Records[0].s3.object.key);

    // 원본 이미지 다운로드
    const originalImage = await s3.getObject({
        Bucket: bucket,
        Key: key
    }).promise();

    // 여러 크기의 썸네일 생성
    const sizes = [
        { width: 200, prefix: 'thumb-small' },
        { width: 400, prefix: 'thumb-medium' },
        { width: 800, prefix: 'thumb-large' }
    ];

    // 병렬로 처리
    await Promise.all(sizes.map(async (size) => {
        const resized = await sharp(originalImage.Body)
            .resize(size.width)
            .toBuffer();

        return s3.putObject({
            Bucket: bucket,
            Key: `${size.prefix}/${key}`,
            Body: resized,
            ContentType: 'image/jpeg'
        }).promise();
    }));

    return { statusCode: 200, body: '썸네일 생성 완료' };
};

박시니어 씨는 첫 번째 화면을 보여주었습니다. 인스타그램 같은 소셜 미디어 서비스의 아키텍처였습니다.

"가장 흔한 사례는 이미지 처리예요." 박시니어 씨가 설명을 시작했습니다. 사용자가 사진을 업로드하면 원본 그대로 저장하는 것이 아닙니다.

여러 크기의 썸네일을 생성해야 합니다. 모바일 화면용 작은 이미지, 태블릿용 중간 이미지, 데스크톱용 큰 이미지.

프로필 사진은 원형으로 잘라야 하고, EXIF 데이터는 제거해야 합니다. 전통적인 방식이라면 업로드 API에서 이 모든 작업을 처리해야 합니다.

서버가 바쁘게 돌아가고, 사용자는 처리가 끝날 때까지 기다려야 합니다. 업로드가 많은 시간대에는 서버가 버벅거립니다.

위 코드를 보세요. 서버리스 방식은 완전히 다릅니다.

사용자가 이미지를 S3에 업로드하면, 자동으로 Lambda 함수가 실행됩니다. 여섯 번째 줄에서 이벤트를 받아서 어떤 파일이 업로드되었는지 확인합니다.

열여섯 번째 줄부터 흥미로운 부분이 시작됩니다. 세 가지 크기의 썸네일을 정의합니다.

그리고 스물네 번째 줄에서 Promise.all을 사용해 병렬로 처리합니다. 세 개의 썸네일이 동시에 생성됩니다.

빠르고 효율적입니다. 가장 중요한 점은 사용자가 기다릴 필요가 없다는 것입니다.

업로드만 하면 끝입니다. 썸네일 생성은 백그라운드에서 자동으로 진행됩니다.

사용자 경험이 훨씬 좋아집니다. 실제로 Airbnb는 숙소 사진 처리에 Lambda를 사용합니다.

하루에 수백만 장의 사진이 업로드되지만, 모두 자동으로 처리됩니다. 사람이 관여할 필요가 없습니다.

"두 번째 사례는 REST API 백엔드예요." 박시니어 씨가 다음 화면을 보여주었습니다. 많은 스타트업이 모바일 앱의 백엔드를 Lambda로 만듭니다.

사용자 인증, 데이터 조회, 게시물 작성 같은 API를 각각 Lambda 함수로 구현합니다. API Gateway와 연결하면 즉시 RESTful API가 완성됩니다.

한 배달 앱 스타트업은 점심시간에 트래픽이 폭증합니다. 오전 11시부터 오후 1시까지 하루 트래픽의 80%가 몰립니다.

전통적인 서버라면 피크 시간대를 감당할 서버를 24시간 운영해야 합니다. 하지만 Lambda는 필요할 때만 확장됩니다.

비용이 70% 절감되었습니다. "세 번째는 실시간 데이터 처리입니다." 박시니어 씨가 계속 설명했습니다.

IoT 센서들이 계속 데이터를 전송한다고 가정해봅시다. 온도, 습도, 위치 정보 같은 데이터가 초당 수천 건씩 들어옵니다.

이것을 실시간으로 분석하고, 이상 징후를 감지하고, 알림을 보내야 합니다. Kinesis Data Streams와 Lambda를 연결하면 간단합니다.

데이터가 스트림에 들어오는 즉시 Lambda 함수가 처리합니다. 동시에 수천 개의 Lambda가 실행되어 병렬 처리합니다.

지연 시간은 밀리초 단위입니다. 실제로 넷플릭스는 사용자 시청 데이터를 실시간으로 분석합니다.

무엇을 보고 있는지, 언제 멈췄는지, 어떤 장르를 좋아하는지. 이 데이터로 즉시 추천 알고리즘을 업데이트합니다.

수억 명의 사용자를 서버리스로 처리합니다. "네 번째는 예약 작업이에요." 박시니어 씨가 말했습니다.

매일 새벽 3시에 데이터베이스를 백업하고, 매주 월요일에 리포트를 생성하고, 매달 1일에 결제를 처리하는 작업들. 이런 것을 크론 잡이라고 부릅니다.

전통적으로는 크론 서버를 따로 운영해야 했습니다. 하지만 CloudWatch Events와 Lambda를 사용하면 간단합니다.

스케줄만 설정하면 정해진 시간에 자동으로 실행됩니다. 서버를 유지할 필요가 없습니다.

한 이커머스 회사는 매일 밤 재고 데이터를 동기화합니다. 오프라인 매장과 온라인 쇼핑몰의 재고를 일치시키는 작업입니다.

Lambda 하나로 해결됩니다. 실행되는 5분 동안만 비용이 발생합니다.

"다섯 번째는 웹훅 처리입니다." 박시니어 씨가 마지막 사례를 보여주었습니다. 결제 시스템, 채팅 봇, CI/CD 파이프라인 같은 서비스들은 웹훅을 사용해 이벤트를 전송합니다.

결제가 완료되면 웹훅이 날아오고, GitHub에 코드가 푸시되면 웹훅이 날아옵니다. 이런 웹훅을 받을 엔드포인트가 필요합니다.

Lambda가 완벽합니다. 이벤트가 올 때만 실행되고, 자동으로 확장되고, 관리할 필요가 없습니다.

Slack 봇을 만든다고 해봅시다. 사용자가 메시지를 보내면 Slack이 웹훅을 전송합니다.

Lambda 함수가 이것을 받아서 처리하고 응답합니다. 사용자가 적을 때는 비용이 거의 없고, 사용자가 많아지면 자동으로 확장됩니다.

김개발 씨는 감탄했습니다. "생각보다 훨씬 다양하게 쓸 수 있네요!" "맞아요." 박시니어 씨가 웃으며 답했습니다.

"핵심은 이벤트 기반이고 트래픽이 불규칙한 작업입니다. 그런 경우에 서버리스는 최고의 선택이죠." 실제로 많은 기업들이 하이브리드 아키텍처를 사용합니다.

핵심 서비스는 전통적인 서버로 운영하고, 부가 기능은 서버리스로 구현합니다. 각각의 장점을 살리는 것입니다.

김개발 씨는 이제 자신의 프로젝트 중 어떤 부분을 서버리스로 만들 수 있을지 명확하게 보였습니다. 이미지 업로드, 일일 리포트 생성, 웹훅 처리.

모두 서버리스로 바꿀 수 있었습니다. 서버리스의 활용 사례를 알면 실무에 바로 적용할 수 있습니다.

이론이 아니라 실전입니다.

실전 팁

💡 - 이벤트가 발생할 때만 실행되는 작업에 서버리스를 우선 고려하세요

트래픽 패턴이 예측하기 어려운 서비스는 서버리스가 비용 효율적입니다
기존 시스템에 서버리스를 점진적으로 추가하는 하이브리드 접근도 좋습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#Serverless#Lambda#FaaS#CloudComputing

서버리스 아키텍처 완벽 입문 가이드

# 서버리스 아키텍처 완벽 입문 가이드 서버 관리 걱정 없이 코드만 작성하는 서버리스의 세계로 안내합니다. 초급 개발자도 쉽게 이해할 수 있도록 실무 상황과 비유로 풀어낸 서버리스 아키텍처 입문서입니다. --- ## 목차 1. [서버리스란_무엇인가](#서버리스란-무엇인가) 2. [서버리스_vs_서버_기반](#서버리스-vs-서버-기반) 3. [FaaS_개념_이해](#faas-개념-이해) 4. [서버리스_장점](#서버리스-장점) 5. [서버리스_단점과_제약](#서버리스-단점과-제약) 6. [서버리스_활용_사례](#서버리스-활용-사례) --- ## 1. 서버리스란_무엇인가 입사 6개월 차 김개발 씨는 오늘도 서버 점검 알림에 잠을 설쳤습니다. 새벽 3시에 울리는 서버 다운 알림, 주말마다 해야 하는 서버 업데이트. "서버만 없다면 얼마나 좋을까?" 하고 중얼거리던 그때, 선배 박시니어 씨가 말했습니다. "그럼 서버리스를 한번 써보는 게 어때요?" **서버리스**란 말 그대로 서버가 없다는 뜻이 아닙니다. 정확히는 개발자가 서버를 직접 관리하지 않아도 되는 클라우드 컴퓨팅 모델입니다. 마치 전기를 쓸 때 발전소를 직접 관리하지 않는 것처럼, 서버리스에서는 코드 실행에만 집중하고 나머지는 클라우드 제공자가 알아서 처리합니다. 다음 코드를 살펴봅시다. ```javascript // AWS Lambda 함수 예제 - 가장 기본적인 서버리스 함수 exports.handler = async (event) => { // 요청이 들어올 때만 실행됩니다 const name = event.queryStringParameters?.name || '손님'; // 비즈니스 로직에만 집중 const greeting = `안녕하세요, ${name}님!`; // 응답 반환 return { statusCode: 200, body: JSON.stringify({ message: greeting }) }; // 함수가 끝나면 자동으로 리소스 해제 }; ``` 김개발 씨는 지금까지 회사에서 전통적인 서버 기반 개발을 해왔습니다. EC2 인스턴스를 띄우고, 운영체제를 설치하고, 보안 패치를 적용하고, 모니터링 시스템을 구축하는 일까지 모두 개발팀의 몫이었습니다. 특히 힘들었던 것은 새벽 시간대 장애 대응이었습니다. 서버가 다운되면 누군가는 깨어나서 재부팅을 해야 했고, 트래픽이 갑자기 증가하면 급하게 서버를 추가해야 했습니다. 개발보다 서버 관리에 더 많은 시간을 쓰는 것 같았습니다. "서버리스가 뭔데요?" 김개발 씨가 물었습니다. 박시니어 씨는 커피를 한 모금 마시고 설명을 시작했습니다. "서버리스는 말 그대로 서버가 없는 건 아니에요. 정확히는 **서버를 우리가 관리하지 않는다**는 뜻이죠." 쉽게 비유하자면, 서버리스는 마치 **택시를 이용하는 것**과 같습니다. 자동차를 직접 소유하면 주차비, 보험료, 정비비용이 계속 나갑니다. 운전하지 않을 때도 비용이 발생하죠. 하지만 택시는 필요할 때만 부르고, 탄 시간만큼만 요금을 냅니다. 차량 관리는 택시 회사가 알아서 합니다. 서버리스도 마찬가지입니다. 코드가 실행될 때만 컴퓨팅 리소스를 사용하고, 그 시간만큼만 비용을 지불합니다. 서버 관리는 AWS, Google Cloud, Azure 같은 클라우드 제공자가 알아서 해줍니다. 김개발 씨는 위의 코드를 살펴보았습니다. 놀랍게도 서버 설정이나 네트워크 구성 같은 코드가 전혀 없었습니다. 오로지 **비즈니스 로직**만 있었습니다. "이 코드는 언제 실행되나요?" 김개발 씨가 물었습니다. "바로 그게 핵심이에요." 박시니어 씨가 답했습니다. "HTTP 요청이 들어올 때, 파일이 업로드될 때, 데이터베이스에 변경이 생길 때처럼 **이벤트가 발생할 때만** 실행됩니다. 요청이 없으면 아예 실행되지 않죠." 위 코드의 첫 번째 줄을 보면 `exports.handler`라는 함수를 정의합니다. 이것이 바로 Lambda 함수의 진입점입니다. 이벤트가 발생하면 AWS Lambda가 자동으로 이 함수를 호출합니다. 세 번째 줄에서는 요청 파라미터에서 이름을 추출합니다. 만약 이름이 없다면 기본값으로 '손님'을 사용합니다. 여섯 번째 줄에서 인사말을 생성하고, 아홉 번째 줄부터 HTTP 응답을 만들어 반환합니다. 가장 중요한 부분은 마지막 주석입니다. **함수가 끝나면 자동으로 리소스가 해제**됩니다. 개발자가 메모리를 정리하거나 연결을 닫을 필요가 없습니다. 다음 요청이 올 때까지 아무런 리소스도 사용하지 않습니다. 실제 현업에서 이것이 얼마나 큰 장점인지 예를 들어보겠습니다. 쇼핑몰 웹사이트를 운영한다고 가정해봅시다. 평소에는 하루에 1000명 정도의 방문자가 있지만, 블랙프라이데이 같은 특별 세일 기간에는 10만 명이 몰립니다. 전통적인 서버 방식이라면 10만 명을 감당할 수 있는 서버를 1년 내내 유지해야 합니다. 364일은 서버의 99%가 놀고 있는 셈이죠. 하지만 서버리스를 사용하면 **자동으로 확장**됩니다. 1000명이 접속하면 필요한 만큼만, 10만 명이 접속하면 그만큼만 리소스가 할당됩니다. 비용도 실제 사용한 만큼만 나갑니다. 물론 서버리스가 만능은 아닙니다. 하지만 적절한 상황에서 사용하면 엄청난 효율을 가져다줍니다. 김개발 씨는 이제 이해가 되었습니다. "그러니까 제가 해야 할 일은 이 함수 안의 코드만 작성하면 되는 거네요?" "정확합니다!" 박시니어 씨가 웃으며 답했습니다. "서버 관리는 AWS에게 맡기고, 우리는 **가치를 만드는 코드**에만 집중하는 거죠." 서버리스를 이해하면 개발자로서 한 단계 더 성장할 수 있습니다. 인프라 관리에서 해방되어 진짜 중요한 비즈니스 로직에 집중할 수 있기 때문입니다. **실전 팁** 💡 - 서버리스는 '서버가 없다'가 아니라 '서버 관리를 하지 않는다'는 의미입니다 - 이벤트 기반으로 동작하므로 요청이 없으면 비용이 발생하지 않습니다 - 자동 확장되므로 트래픽 급증에도 안정적으로 대응할 수 있습니다 --- ## 2. 서버리스_vs_서버_기반 "그럼 모든 걸 서버리스로 만들면 되는 거 아닌가요?" 김개발 씨가 신이 나서 물었습니다. 박시니어 씨는 고개를 가로저었습니다. "아니요, 각각 장단점이 있어서 상황에 맞게 선택해야 해요. 비교해보면 더 명확하게 이해할 수 있을 거예요." **서버 기반 아키텍처**는 개발자가 서버를 직접 관리하며 항상 실행 상태를 유지합니다. 반면 **서버리스 아키텍처**는 이벤트가 발생할 때만 실행되고 클라우드 제공자가 모든 인프라를 관리합니다. 각각의 방식은 서로 다른 비용 구조, 확장성, 관리 복잡도를 가지고 있습니다. 다음 코드를 살펴봅시다. ```javascript // 전통적인 서버 기반 (Express.js) const express = require('express'); const app = express(); // 서버는 24시간 실행됩니다 app.get('/api/greeting', (req, res) => { const name = req.query.name || '손님'; res.json({ message: `안녕하세요, ${name}님!` }); }); // 서버가 계속 떠 있어야 함 app.listen(3000, () => { console.log('서버가 3000 포트에서 실행 중...'); }); // 서버리스 (Lambda)는 요청이 올 때만 실행 // 위의 Lambda 코드와 비교해보세요 ``` 박시니어 씨는 화이트보드에 두 개의 다이어그램을 그리기 시작했습니다. 하나는 전통적인 서버, 다른 하나는 서버리스 아키텍처였습니다. "먼저 전통적인 서버 기반 방식을 볼까요?" 박시니어 씨가 왼쪽 다이어그램을 가리켰습니다. 김개발 씨가 지금까지 사용해온 방식은 **서버 기반 아키텍처**였습니다. EC2 인스턴스나 온프레미스 서버에 Node.js나 Python 같은 런타임을 설치하고, Express나 Django 같은 웹 프레임워크로 애플리케이션을 만듭니다. 그리고 이 서버는 **24시간 365일 계속 실행**됩니다. 마치 **가게를 운영하는 것**과 같습니다. 손님이 오든 안 오든 가게 문을 열어두고, 전기세와 임대료를 계속 내야 합니다. 직원도 항상 대기하고 있어야 하죠. 위의 Express.js 코드를 보면, 11번째 줄에서 `app.listen(3000)`을 호출합니다. 이 순간부터 서버는 계속 실행됩니다. 요청이 1초에 한 번 오든, 하루에 한 번 오든, 아예 안 오든 상관없이 서버는 **계속 떠 있습니다**. 메모리를 차지하고, CPU 사이클을 소비하고, 비용이 발생합니다. "그럼 서버리스는 어떻게 다른가요?" 김개발 씨가 물었습니다. 박시니어 씨는 오른쪽 다이어그램을 가리켰습니다. "서버리스는 **필요할 때만 깨어나는** 방식이에요." 서버리스는 마치 **자판기**와 같습니다. 평소에는 전원만 켜져 있다가, 동전을 넣고 버튼을 누르는 순간에만 작동합니다. 음료를 뽑아주고 나면 다시 대기 상태로 돌아갑니다. 실제로 작동한 시간만큼만 에너지를 소비합니다. Lambda 함수는 HTTP 요청, 파일 업로드, 데이터베이스 변경 같은 **이벤트가 발생할 때만** 실행됩니다. 요청을 처리하고 나면 자동으로 종료됩니다. 다음 요청이 올 때까지 아무런 리소스도 사용하지 않습니다. 이제 비용을 비교해보겠습니다. 서버 기반 방식에서는 **고정 비용**이 발생합니다. AWS EC2 t3.medium 인스턴스는 한 달에 약 30달러입니다. 트래픽이 적든 많든 이 비용은 동일합니다. 만약 사용자가 거의 없는 사내 도구를 만든다면? 하루에 10번 정도만 사용되는데도 한 달 내내 서버 비용을 내야 합니다. 서버리스는 **종량제 비용**입니다. Lambda는 요청 100만 건당 0.20달러, 실행 시간 GB-초당 0.0000166667달러를 청구합니다. 게다가 매달 **100만 건의 무료 요청**이 제공됩니다. 사내 도구처럼 트래픽이 적으면 거의 무료로 운영할 수 있습니다. 확장성 측면에서도 큰 차이가 있습니다. 서버 기반에서 트래픽이 갑자기 10배 증가하면 어떻게 될까요? 서버가 다운될 수 있습니다. 급하게 서버를 추가하려면 최소 몇 분에서 몇 시간이 걸립니다. 로드밸런서 설정도 변경해야 하고, 오토 스케일링 정책도 조정해야 합니다. 서버리스는 **자동으로 확장**됩니다. 동시 요청이 1개든 10,000개든 Lambda는 자동으로 필요한 만큼의 인스턴스를 생성합니다. 개발자는 아무것도 할 필요가 없습니다. 설정도 필요 없습니다. 하지만 서버리스가 항상 좋은 건 아닙니다. **콜드 스타트**라는 문제가 있습니다. 한동안 요청이 없다가 새로운 요청이 오면, Lambda는 새로운 실행 환경을 준비해야 합니다. 이 과정에서 몇 백 밀리초에서 몇 초까지 지연이 발생할 수 있습니다. 실시간 거래 시스템처럼 밀리초 단위의 응답 속도가 중요한 서비스에는 적합하지 않을 수 있습니다. 또한 서버리스는 **실행 시간 제한**이 있습니다. AWS Lambda는 최대 15분까지만 실행할 수 있습니다. 대용량 동영상 인코딩처럼 오래 걸리는 작업에는 적합하지 않습니다. 김개발 씨는 고개를 끄덕였습니다. "그러니까 각각 장단점이 있어서, 상황에 맞게 선택해야 하는 거네요?" "바로 그겁니다!" 박시니어 씨가 답했습니다. "API 서버, 이미지 처리, 데이터 변환 같은 작업은 서버리스가 훌륭합니다. 하지만 WebSocket 서버, 게임 서버, 장시간 실행되는 배치 작업은 전통적인 서버가 더 나을 수 있어요." 둘 중 어느 것이 더 좋다는 게 아닙니다. 프로젝트의 특성, 예산, 트래픽 패턴을 고려해서 **적재적소에** 사용하는 것이 중요합니다. **실전 팁** 💡 - 트래픽이 불규칙하거나 적다면 서버리스가 비용 효율적입니다 - 밀리초 단위의 일관된 응답 속도가 필요하면 서버 기반을 고려하세요 - 두 방식을 혼합해서 사용하는 하이브리드 아키텍처도 가능합니다 --- ## 3. FaaS_개념_이해 "서버리스를 검색하다 보니까 FaaS라는 용어가 자주 나오던데, 이게 뭔가요?" 김개발 씨가 물었습니다. 박시니어 씨는 웃으며 답했습니다. "FaaS는 서버리스의 핵심 개념이에요. 함수 하나하나가 독립적인 서비스가 되는 거죠." **FaaS(Function as a Service)**는 서버리스 컴퓨팅의 대표적인 형태로, 개별 함수를 배포하고 실행하는 클라우드 서비스입니다. 개발자는 함수만 작성하고, 클라우드 제공자가 실행 환경, 확장, 모니터링을 모두 처리합니다. AWS Lambda, Google Cloud Functions, Azure Functions가 대표적인 FaaS 플랫폼입니다. 다음 코드를 살펴봅시다. ```javascript // 이미지 업로드를 처리하는 FaaS 함수 const AWS = require('aws-sdk'); const sharp = require('sharp'); exports.handler = async (event) => { // S3에 이미지가 업로드되면 자동 실행 const bucket = event.Records[0].s3.bucket.name; const key = event.Records[0].s3.object.key; // 원본 이미지 다운로드 const s3 = new AWS.S3(); const image = await s3.getObject({ Bucket: bucket, Key: key }).promise(); // 썸네일 생성 (이 함수의 단 하나의 책임) const thumbnail = await sharp(image.Body) .resize(200, 200) .toBuffer(); // 썸네일 저장 await s3.putObject({ Bucket: bucket, Key: `thumbnails/${key}`, Body: thumbnail }).promise(); return { statusCode: 200, body: '썸네일 생성 완료' }; }; ``` 김개발 씨는 회사 게시판 시스템을 개발할 때 이미지 업로드 기능을 구현한 적이 있습니다. 사용자가 이미지를 올리면 서버에서 받아서 저장하고, 썸네일을 만들고, 데이터베이스에 정보를 기록했습니다. 모든 로직이 하나의 큰 애플리케이션 안에 들어 있었습니다. "FaaS는 그것과 어떻게 다른가요?" 김개발 씨가 물었습니다. 박시니어 씨는 레고 블록을 예로 들었습니다. "전통적인 서버는 **하나의 큰 블록**이에요. 안에 모든 기능이 다 들어있죠. 반면 FaaS는 **작은 레고 블록들**을 조립하는 것과 같아요." **FaaS(Function as a Service)**는 말 그대로 **함수를 서비스로** 제공하는 것입니다. 하나의 함수가 하나의 독립적인 마이크로서비스가 됩니다. 각 함수는 **단 하나의 책임**만 가집니다. 위의 코드를 보면, 이 함수는 오직 **썸네일 생성**만 합니다. 이미지를 받고, 리사이즈하고, 저장합니다. 그게 전부입니다. 사용자 인증, 파일 검증, 데이터베이스 저장 같은 다른 작업은 다른 함수들이 담당합니다. 여섯 번째 줄을 보면 흥미로운 점이 있습니다. 이 함수는 **S3 이벤트를 감지**합니다. 누군가 S3 버킷에 이미지를 업로드하면 자동으로 이 함수가 실행됩니다. 개발자가 스케줄러를 만들거나 모니터링 코드를 작성할 필요가 없습니다. 일곱 번째와 여덟 번째 줄에서는 업로드된 파일 정보를 가져옵니다. 버킷 이름과 파일 키를 추출합니다. 열한 번째 줄에서는 S3 클라이언트를 생성하고, 열두 번째 줄에서 원본 이미지를 다운로드합니다. 핵심은 열다섯 번째 줄부터입니다. **sharp 라이브러리**를 사용해서 이미지를 200x200 픽셀로 리사이즈합니다. 그리고 스무 번째 줄부터 생성된 썸네일을 `thumbnails/` 폴더에 저장합니다. 이 모든 과정이 **이벤트 기반**으로 자동 실행됩니다. 개발자는 함수만 작성하면 됩니다. 실제 서비스에서 FaaS가 어떻게 활용되는지 살펴보겠습니다. 넷플릭스는 동영상 인코딩에 AWS Lambda를 사용합니다. 사용자가 동영상을 업로드하면, 수백 개의 Lambda 함수가 동시에 실행되어 각기 다른 해상도와 포맷으로 인코딩합니다. 4K, 1080p, 720p, 모바일용 등 모든 버전을 병렬로 처리합니다. 만약 전통적인 서버로 이걸 처리한다면? 엄청난 수의 서버를 유지해야 합니다. 코카콜라는 자판기 관리 시스템에 FaaS를 사용합니다. 전 세계 수백만 대의 자판기가 재고 정보를 전송하면, 각 이벤트마다 Lambda 함수가 실행되어 데이터를 처리하고 분석합니다. 자판기마다 서버를 둘 수는 없으니까요. 김개발 씨는 문득 궁금해졌습니다. "그럼 함수끼리는 어떻게 통신하나요?" "좋은 질문이에요!" 박시니어 씨가 답했습니다. "FaaS 함수들은 보통 **이벤트 체인**으로 연결됩니다." 예를 들어 사용자가 회원가입을 한다고 가정해봅시다. 첫 번째 함수가 사용자 정보를 데이터베이스에 저장합니다. 이 작업이 완료되면 DynamoDB Streams가 이벤트를 발생시킵니다. 두 번째 함수가 이 이벤트를 받아서 환영 이메일을 보냅니다. 세 번째 함수는 사용자 분석 데이터를 업데이트합니다. 각 함수는 독립적입니다. 하나가 실패해도 다른 함수에 영향을 주지 않습니다. 이메일 발송이 실패해도 회원가입 자체는 정상적으로 완료됩니다. **느슨한 결합**이 이루어지는 거죠. FaaS의 가장 큰 장점은 **관심사의 분리**입니다. 각 함수가 하나의 일만 잘하면 됩니다. 코드가 짧아지고, 테스트하기 쉬워지고, 유지보수가 간단해집니다. 하지만 주의할 점도 있습니다. 함수가 너무 많아지면 관리가 복잡해질 수 있습니다. 100개의 함수가 서로 얽혀 있다면? 디버깅이 어려워집니다. 따라서 적절한 수준으로 **함수를 그룹화**하는 것이 중요합니다. 김개발 씨는 이제 FaaS의 개념이 명확해졌습니다. "함수 하나가 하나의 서비스가 되는 거네요. 마치 레고 블록처럼요!" "정확합니다!" 박시니어 씨가 엄지를 들어 올렸습니다. "작은 함수들을 조합해서 큰 시스템을 만드는 거죠." FaaS를 잘 활용하면 유연하고 확장 가능한 시스템을 빠르게 구축할 수 있습니다. 각 함수에 집중하다 보면 자연스럽게 좋은 아키텍처가 만들어집니다. **실전 팁** 💡 - 하나의 함수는 하나의 책임만 가지도록 설계하세요 - 함수 간 통신은 이벤트 기반으로 느슨하게 결합하세요 - 너무 많은 함수로 쪼개면 관리가 복잡해질 수 있으니 적절한 균형을 찾으세요 --- ## 4. 서버리스_장점 월요일 아침, 김개발 씨는 주말 내내 걱정했던 서버 점검을 무사히 마쳤습니다. 하지만 박시니어 씨는 편안한 표정이었습니다. "저는 주말에 아무것도 안 했어요. 제가 만든 서버리스 시스템은 알아서 잘 돌아가거든요." 김개발 씨는 서버리스의 장점이 궁금해졌습니다. 서버리스 아키텍처는 **운영 부담 제로**, **자동 확장성**, **비용 최적화**, **빠른 개발 속도**라는 네 가지 핵심 장점을 제공합니다. 개발자는 인프라 관리에서 완전히 해방되어 비즈니스 로직에만 집중할 수 있으며, 사용한 만큼만 비용을 지불하는 완벽한 종량제 모델을 경험할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // 자동 확장되는 API 엔드포인트 exports.handler = async (event) => { // 동시 요청이 1개든 10,000개든 자동으로 처리 const userId = event.pathParameters.userId; // 비즈니스 로직에만 집중 const user = await getUserFromDB(userId); const recommendations = await calculateRecommendations(user); // 인프라 걱정은 AWS가 알아서 return { statusCode: 200, body: JSON.stringify(recommendations) }; }; // 서버 관리, 스케일링, 로드밸런싱, // 보안 패치 등은 모두 자동으로 처리됩니다 async function getUserFromDB(userId) { // DB 조회 로직 return { id: userId, preferences: ['기술', '여행'] }; } async function calculateRecommendations(user) { // 추천 알고리즘 return ['서버리스 강의', '클라우드 여행기']; } ``` 김개발 씨는 지난주 금요일 밤을 떠올렸습니다. 갑자기 트래픽이 폭증하면서 서버가 다운되었고, 급하게 서버를 추가하느라 밤을 새웠습니다. 주말에는 보안 패치를 적용하고 서버를 재부팅했습니다. 월요일 아침인데도 피곤함이 가시지 않았습니다. 반면 박시니어 씨는 활기찬 모습이었습니다. "주말에 뭐 하셨어요?" 김개발 씨가 물었습니다. "가족들이랑 등산 다녀왔어요. 제 서비스는 서버리스라서 신경 쓸 게 없었거든요." 박시니어 씨가 웃으며 답했습니다. 첫 번째 장점은 **운영 부담이 없다**는 것입니다. 전통적인 서버를 운영하려면 해야 할 일이 산더미처럼 쌓입니다. 운영체제 업데이트, 보안 패치 적용, 서버 모니터링, 로그 관리, 백업 설정, 장애 대응 등. 개발보다 운영에 더 많은 시간을 쓰게 됩니다. 하지만 서버리스에서는 이 모든 것을 **클라우드 제공자가 알아서** 처리합니다. 보안 패치가 나오면? AWS가 자동으로 적용합니다. 서버가 다운되면? AWS가 자동으로 복구합니다. 개발자는 **코드만 작성**하면 됩니다. 위의 코드를 보세요. 어디에도 서버 설정이나 인프라 코드가 없습니다. 오직 비즈니스 로직만 있습니다. 사용자 정보를 가져오고, 추천 알고리즘을 실행하고, 결과를 반환합니다. 그게 전부입니다. 두 번째 장점은 **완벽한 자동 확장**입니다. 김개발 씨가 운영하는 서비스는 평소에 하루 1,000명 정도가 사용합니다. 하지만 어느 날 TV에 소개되면서 갑자기 100,000명이 몰렸습니다. 서버는 감당하지 못하고 다운되었습니다. 급하게 서버를 추가했지만, Auto Scaling 설정이 제대로 되어 있지 않아서 시간이 오래 걸렸습니다. 서버리스는 이런 걱정이 없습니다. Lambda는 **동시 요청 수에 따라 자동으로 확장**됩니다. 요청이 1개 오면 1개의 인스턴스가, 10,000개가 오면 10,000개의 인스턴스가 자동으로 생성됩니다. 설정도 필요 없고, 기다릴 필요도 없습니다. 순식간에 확장됩니다. 세 번째 장점은 **비용 최적화**입니다. 김개발 씨의 회사는 사내 도구를 위해 EC2 서버를 24시간 운영합니다. 실제로는 업무 시간(9시~6시)에만 사용되는데도 말이죠. 한 달에 30달러의 서버 비용이 나갑니다. 하지만 실제 사용 시간은 전체의 20%도 안 됩니다. 80%는 그냥 버려지는 셈입니다. 서버리스는 **사용한 만큼만** 비용을 지불합니다. 요청이 100번 오면 100번치 비용만 나갑니다. 게다가 Lambda는 매달 **100만 건의 무료 요청**을 제공합니다. 사내 도구처럼 트래픽이 적은 서비스는 거의 무료로 운영할 수 있습니다. 실제 사례를 보겠습니다. 어떤 스타트업은 서버 기반에서 서버리스로 마이그레이션한 후 월 인프라 비용이 500달러에서 50달러로 **90% 감소**했습니다. 동일한 서비스를 10분의 1 비용으로 운영하게 된 것입니다. 네 번째 장점은 **빠른 개발 속도**입니다. 김개발 씨가 새로운 API를 만들려면 여러 단계를 거쳐야 했습니다. EC2 인스턴스 생성, 보안 그룹 설정, 로드밸런서 구성, 도메인 연결, SSL 인증서 설정 등. 코드를 작성하기도 전에 인프라 설정에 하루가 걸렸습니다. 서버리스는 **코드만 작성하면 끝**입니다. Lambda 함수를 만들고, API Gateway를 연결하면 즉시 전 세계에서 접근 가능한 API가 완성됩니다. 30분이면 충분합니다. 인프라 설정은 클라우드가 알아서 해줍니다. 실제로 많은 스타트업이 서버리스로 **MVP(Minimum Viable Product)**를 빠르게 출시합니다. 시장 반응을 보고 나서 확장하거나 수정하는 것이 훨씬 효율적이기 때문입니다. 다섯 번째 장점은 **내장된 고가용성**입니다. 전통적인 서버는 단일 장애 지점이 될 수 있습니다. 서버 하나가 다운되면 전체 서비스가 중단됩니다. 고가용성을 위해 여러 가용 영역에 서버를 배치하고, 로드밸런서를 설정하고, 헬스 체크를 구현해야 합니다. 복잡하고 비용도 많이 듭니다. Lambda는 기본적으로 **여러 가용 영역**에 분산되어 실행됩니다. 한 데이터센터가 통째로 다운되어도 서비스는 계속됩니다. 개발자가 아무것도 설정하지 않아도 자동으로 고가용성이 보장됩니다. 김개발 씨는 이제 왜 박시니어 씨가 주말을 편안하게 보낼 수 있었는지 이해했습니다. 서버리스는 운영 부담을 없애주고, 자동으로 확장되며, 비용을 절감하고, 개발 속도를 높여줍니다. "이제 이해가 되네요." 김개발 씨가 말했습니다. "다음 프로젝트는 꼭 서버리스로 해봐야겠어요!" 서버리스의 장점을 제대로 활용하면, 더 적은 비용으로 더 안정적인 서비스를 더 빠르게 만들 수 있습니다. 그리고 주말에는 등산을 갈 수 있습니다. **실전 팁** 💡 - 운영 인력이 부족한 스타트업이나 소규모 팀에게 특히 유용합니다 - 트래픽 패턴이 불규칙한 서비스는 비용 절감 효과가 큽니다 - MVP를 빠르게 출시하고 검증할 때 서버리스를 활용하세요 --- ## 5. 서버리스_단점과_제약 서버리스의 장점에 매료된 김개발 씨는 모든 프로젝트를 서버리스로 바꾸려고 했습니다. 하지만 박시니어 씨가 제동을 걸었습니다. "잠깐만요. 서버리스도 완벽하지는 않아요. 단점과 제약사항을 알아야 제대로 사용할 수 있죠." 서버리스는 **콜드 스타트 지연**, **실행 시간 제한**, **상태 관리의 어려움**, **벤더 종속성**이라는 명확한 제약을 가지고 있습니다. 이런 한계를 이해하지 못하고 무분별하게 사용하면 오히려 문제가 발생할 수 있습니다. 적절한 상황에서 올바르게 사용하는 것이 중요합니다. 다음 코드를 살펴봅시다. ```javascript // 콜드 스타트 문제 예시 exports.handler = async (event) => { // 첫 요청시 초기화 시간이 추가됨 (수백ms ~ 수초) const heavyLibrary = require('tensorflow'); // 큰 라이브러리 로딩 // 한동안 요청이 없다가 다시 호출되면 // 새로운 컨테이너를 시작하는 시간이 걸림 const result = await processData(event.data); return result; }; // 실행 시간 제한 (Lambda는 최대 15분) exports.longRunningTask = async (event) => { // 이런 작업은 서버리스에 부적합 for (let i = 0; i { counter++; // 의미 없는 코드 return counter; // 항상 1을 반환 }; ``` 김개발 씨는 신나는 마음으로 기존 프로젝트를 서버리스로 마이그레이션하기 시작했습니다. 하지만 곧 문제에 부딪혔습니다. 실시간 채팅 서비스의 응답 속도가 들쭉날쭉했고, 대용량 동영상 처리 작업은 중간에 끊겼습니다. "무엇이 잘못된 걸까요?" 김개발 씨가 좌절한 표정으로 물었습니다. 박시니어 씨는 차분하게 설명하기 시작했습니다. "서버리스는 만능이 아니에요. 명확한 한계가 있죠." 첫 번째 문제는 **콜드 스타트**입니다. Lambda 함수가 한동안 호출되지 않으면 **실행 환경이 종료**됩니다. 다시 요청이 오면 새로운 컨테이너를 시작하고, 런타임을 로딩하고, 코드를 초기화해야 합니다. 이 과정에서 수백 밀리초에서 심하면 몇 초까지 지연이 발생합니다. 위 코드의 세 번째 줄을 보세요. TensorFlow 같은 **무거운 라이브러리**를 로딩하면 콜드 스타트 시간이 더 길어집니다. 사용자가 버튼을 눌렀는데 3초 동안 아무 반응이 없다면? 사용자는 버그라고 생각할 것입니다. 실제 사례를 보겠습니다. 한 쇼핑몰은 결제 API를 Lambda로 만들었습니다. 대부분의 요청은 빠르게 처리되었지만, 새벽 시간대에 첫 주문이 들어오면 5초 넘게 걸렸습니다. 콜드 스타트 때문이었습니다. 고객들은 결제가 느리다고 불만을 제기했습니다. 해결 방법은 있습니다. **Provisioned Concurrency**를 사용하면 함수를 미리 워밍업해 둘 수 있습니다. 하지만 이것은 추가 비용이 발생합니다. 서버리스의 비용 이점이 줄어드는 셈입니다. 두 번째 문제는 **실행 시간 제한**입니다. AWS Lambda는 최대 **15분**까지만 실행할 수 있습니다. 그 이상 걸리는 작업은 중간에 강제 종료됩니다. 위 코드의 열 번째 줄처럼 대용량 파일을 처리하거나, 복잡한 데이터 분석을 수행하거나, 머신러닝 모델을 학습시키는 작업은 서버리스에 적합하지 않습니다. 김개발 씨가 만들려던 동영상 인코딩 시스템은 한 파일당 30분 이상 걸렸습니다. Lambda로는 불가능했습니다. 이런 경우에는 **AWS Batch**나 **ECS Fargate** 같은 다른 서비스를 사용해야 합니다. 세 번째 문제는 **상태를 유지할 수 없다**는 점입니다. 위 코드의 스물한 번째 줄을 보세요. `counter`라는 변수를 선언하고 요청마다 증가시키려고 합니다. 하지만 이것은 작동하지 않습니다. Lambda 함수는 **무상태(Stateless)**입니다. 각 요청은 독립적으로 처리되며, 이전 요청의 데이터를 기억하지 못합니다. WebSocket 서버처럼 연결 상태를 유지해야 하는 서비스는 어떻게 할까요? 가능은 하지만 복잡합니다. **DynamoDB**나 **ElastiCache** 같은 외부 저장소에 상태를 저장해야 합니다. 코드가 복잡해지고 비용도 증가합니다. 네 번째 문제는 **벤더 종속성**입니다. Lambda 함수는 AWS에 강하게 결합되어 있습니다. AWS의 API, SDK, 서비스들을 사용하게 됩니다. 나중에 Google Cloud나 Azure로 옮기려면? 코드를 전부 다시 작성해야 할 수도 있습니다. 박시니어 씨는 예전에 이런 경험을 했습니다. Lambda로 만든 시스템을 Google Cloud로 마이그레이션하려다가 3개월이 걸렸습니다. API가 다르고, 동작 방식이 다르고, 제약사항도 달랐습니다. 거의 처음부터 다시 만드는 수준이었습니다. 다섯 번째 문제는 **디버깅의 어려움**입니다. 전통적인 서버에서는 로그를 보고, 디버거를 붙이고, 단계별로 실행해볼 수 있습니다. 하지만 Lambda는 **로컬 환경과 다릅니다**. 같은 코드가 로컬에서는 잘 작동하는데 Lambda에서는 안 될 수 있습니다. 여러 Lambda 함수가 연결된 시스템에서 문제가 생기면? 어느 함수에서 오류가 났는지 찾기 어렵습니다. **분산 추적** 시스템을 구축해야 하는데, 이것도 추가 작업입니다. 여섯 번째 문제는 **비용의 불확실성**입니다. 서버리스는 사용한 만큼만 비용을 낸다고 했습니다. 좋은 점이지만, 반대로 생각하면 **예측이 어렵다**는 뜻입니다. 갑자기 트래픽이 폭증하면? 예상치 못한 거액의 청구서를 받을 수 있습니다. 실제로 어떤 개발자는 Lambda 함수에 버그가 있어서 무한 루프를 돌았습니다. 하루 만에 수천 달러의 비용이 청구되었습니다. 서버였다면 고정 비용이었겠지만, 서버리스는 실행한 만큼 과금됩니다. 김개발 씨는 고개를 끄덕였습니다. "그러니까 실시간 채팅이나 장시간 작업은 서버리스가 적합하지 않군요." "정확해요." 박시니어 씨가 답했습니다. "서버리스는 강력한 도구지만, **적재적소에** 사용해야 합니다. 모든 문제의 해답은 아니에요." 서버리스의 한계를 이해하면 더 현명하게 사용할 수 있습니다. 장점을 살리고 단점을 피하는 것, 그것이 진짜 실력입니다. **실전 팁** 💡 - 실시간성이 중요하거나 일관된 응답 속도가 필요하면 Provisioned Concurrency를 고려하세요 - 15분 이상 걸리는 작업은 AWS Batch나 Step Functions를 사용하세요 - 벤더 종속성을 줄이려면 Serverless Framework 같은 추상화 도구를 사용하세요 --- ## 6. 서버리스_활용_사례 "그럼 실제로 서버리스는 어떤 곳에 쓰면 좋을까요?" 김개발 씨가 물었습니다. 박시니어 씨는 노트북을 열어 실제 프로젝트들을 보여주기 시작했습니다. "생각보다 훨씬 다양한 곳에 사용할 수 있어요. 몇 가지 대표적인 사례를 보여드릴게요." 서버리스는 **REST API 백엔드**, **이미지/동영상 처리**, **실시간 데이터 처리**, **예약 작업**, **웹훅 처리** 등 다양한 실무 시나리오에서 활용됩니다. 특히 트래픽이 불규칙하거나, 이벤트 기반 처리가 필요하거나, 빠른 개발이 중요한 경우에 탁월한 효과를 발휘합니다. 다음 코드를 살펴봅시다. ```javascript // 사례 1: 이미지 썸네일 자동 생성 const AWS = require('aws-sdk'); const sharp = require('sharp'); const s3 = new AWS.S3(); exports.createThumbnail = async (event) => { // S3에 이미지 업로드되면 자동 실행 const bucket = event.Records[0].s3.bucket.name; const key = decodeURIComponent(event.Records[0].s3.object.key); // 원본 이미지 다운로드 const originalImage = await s3.getObject({ Bucket: bucket, Key: key }).promise(); // 여러 크기의 썸네일 생성 const sizes = [ { width: 200, prefix: 'thumb-small' }, { width: 400, prefix: 'thumb-medium' }, { width: 800, prefix: 'thumb-large' } ]; // 병렬로 처리 await Promise.all(sizes.map(async (size) => { const resized = await sharp(originalImage.Body) .resize(size.width) .toBuffer(); return s3.putObject({ Bucket: bucket, Key: `${size.prefix}/${key}`, Body: resized, ContentType: 'image/jpeg' }).promise(); })); return { statusCode: 200, body: '썸네일 생성 완료' }; }; ``` 박시니어 씨는 첫 번째 화면을 보여주었습니다. 인스타그램 같은 소셜 미디어 서비스의 아키텍처였습니다. "가장 흔한 사례는 **이미지 처리**예요." 박시니어 씨가 설명을 시작했습니다. 사용자가 사진을 업로드하면 원본 그대로 저장하는 것이 아닙니다. 여러 크기의 썸네일을 생성해야 합니다. 모바일 화면용 작은 이미지, 태블릿용 중간 이미지, 데스크톱용 큰 이미지. 프로필 사진은 원형으로 잘라야 하고, EXIF 데이터는 제거해야 합니다. 전통적인 방식이라면 업로드 API에서 이 모든 작업을 처리해야 합니다. 서버가 바쁘게 돌아가고, 사용자는 처리가 끝날 때까지 기다려야 합니다. 업로드가 많은 시간대에는 서버가 버벅거립니다. 위 코드를 보세요. 서버리스 방식은 완전히 다릅니다. 사용자가 이미지를 S3에 업로드하면, **자동으로 Lambda 함수가 실행**됩니다. 여섯 번째 줄에서 이벤트를 받아서 어떤 파일이 업로드되었는지 확인합니다. 열여섯 번째 줄부터 흥미로운 부분이 시작됩니다. 세 가지 크기의 썸네일을 정의합니다. 그리고 스물네 번째 줄에서 `Promise.all`을 사용해 **병렬로 처리**합니다. 세 개의 썸네일이 동시에 생성됩니다. 빠르고 효율적입니다. 가장 중요한 점은 사용자가 기다릴 필요가 없다는 것입니다. 업로드만 하면 끝입니다. 썸네일 생성은 **백그라운드**에서 자동으로 진행됩니다. 사용자 경험이 훨씬 좋아집니다. 실제로 Airbnb는 숙소 사진 처리에 Lambda를 사용합니다. 하루에 수백만 장의 사진이 업로드되지만, 모두 자동으로 처리됩니다. 사람이 관여할 필요가 없습니다. "두 번째 사례는 **REST API 백엔드**예요." 박시니어 씨가 다음 화면을 보여주었습니다. 많은 스타트업이 모바일 앱의 백엔드를 Lambda로 만듭니다. 사용자 인증, 데이터 조회, 게시물 작성 같은 API를 각각 Lambda 함수로 구현합니다. API Gateway와 연결하면 즉시 **RESTful API**가 완성됩니다. 한 배달 앱 스타트업은 점심시간에 트래픽이 폭증합니다. 오전 11시부터 오후 1시까지 하루 트래픽의 80%가 몰립니다. 전통적인 서버라면 피크 시간대를 감당할 서버를 24시간 운영해야 합니다. 하지만 Lambda는 필요할 때만 확장됩니다. 비용이 **70% 절감**되었습니다. "세 번째는 **실시간 데이터 처리**입니다." 박시니어 씨가 계속 설명했습니다. IoT 센서들이 계속 데이터를 전송한다고 가정해봅시다. 온도, 습도, 위치 정보 같은 데이터가 초당 수천 건씩 들어옵니다. 이것을 실시간으로 분석하고, 이상 징후를 감지하고, 알림을 보내야 합니다. Kinesis Data Streams와 Lambda를 연결하면 간단합니다. 데이터가 스트림에 들어오는 즉시 Lambda 함수가 처리합니다. 동시에 수천 개의 Lambda가 실행되어 **병렬 처리**합니다. 지연 시간은 밀리초 단위입니다. 실제로 넷플릭스는 사용자 시청 데이터를 실시간으로 분석합니다. 무엇을 보고 있는지, 언제 멈췄는지, 어떤 장르를 좋아하는지. 이 데이터로 즉시 추천 알고리즘을 업데이트합니다. 수억 명의 사용자를 서버리스로 처리합니다. "네 번째는 **예약 작업**이에요." 박시니어 씨가 말했습니다. 매일 새벽 3시에 데이터베이스를 백업하고, 매주 월요일에 리포트를 생성하고, 매달 1일에 결제를 처리하는 작업들. 이런 것을 **크론 잡**이라고 부릅니다. 전통적으로는 크론 서버를 따로 운영해야 했습니다. 하지만 CloudWatch Events와 Lambda를 사용하면 간단합니다. 스케줄만 설정하면 정해진 시간에 자동으로 실행됩니다. 서버를 유지할 필요가 없습니다. 한 이커머스 회사는 매일 밤 재고 데이터를 동기화합니다. 오프라인 매장과 온라인 쇼핑몰의 재고를 일치시키는 작업입니다. Lambda 하나로 해결됩니다. 실행되는 5분 동안만 비용이 발생합니다. "다섯 번째는 **웹훅 처리**입니다." 박시니어 씨가 마지막 사례를 보여주었습니다. 결제 시스템, 채팅 봇, CI/CD 파이프라인 같은 서비스들은 웹훅을 사용해 이벤트를 전송합니다. 결제가 완료되면 웹훅이 날아오고, GitHub에 코드가 푸시되면 웹훅이 날아옵니다. 이런 웹훅을 받을 엔드포인트가 필요합니다. Lambda가 완벽합니다. 이벤트가 올 때만 실행되고, 자동으로 확장되고, 관리할 필요가 없습니다. Slack 봇을 만든다고 해봅시다. 사용자가 메시지를 보내면 Slack이 웹훅을 전송합니다. Lambda 함수가 이것을 받아서 처리하고 응답합니다. 사용자가 적을 때는 비용이 거의 없고, 사용자가 많아지면 자동으로 확장됩니다. 김개발 씨는 감탄했습니다. "생각보다 훨씬 다양하게 쓸 수 있네요!" "맞아요." 박시니어 씨가 웃으며 답했습니다. "핵심은 **이벤트 기반**이고 **트래픽이 불규칙**한 작업입니다. 그런 경우에 서버리스는 최고의 선택이죠." 실제로 많은 기업들이 하이브리드 아키텍처를 사용합니다. 핵심 서비스는 전통적인 서버로 운영하고, 부가 기능은 서버리스로 구현합니다. 각각의 장점을 살리는 것입니다. 김개발 씨는 이제 자신의 프로젝트 중 어떤 부분을 서버리스로 만들 수 있을지 명확하게 보였습니다. 이미지 업로드, 일일 리포트 생성, 웹훅 처리. 모두 서버리스로 바꿀 수 있었습니다. 서버리스의 활용 사례를 알면 실무에 바로 적용할 수 있습니다. 이론이 아니라 실전입니다. **실전 팁** 💡 - 이벤트가 발생할 때만 실행되는 작업에 서버리스를 우선 고려하세요 - 트래픽 패턴이 예측하기 어려운 서비스는 서버리스가 비용 효율적입니다 - 기존 시스템에 서버리스를 점진적으로 추가하는 하이브리드 접근도 좋습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, Serverless, Lambda, FaaS, CloudComputing

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

서버리스 아키텍처 완벽 입문 가이드

목차

1. 서버리스란 무엇인가

2. 서버리스 vs 서버 기반

3. FaaS 개념 이해

4. 서버리스 장점

5. 서버리스 단점과 제약

6. 서버리스 활용 사례

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

보안 아키텍처 구성 완벽 가이드