558. 서버리스 아키텍처 (Serverless / FaaS)

핵심 인사이트 (3줄 요약)

1. 본질: 서버리스(Serverless/FaaS) 아키텍처는 "서버가 없다"는 사기성 짙은 거짓말이 아니라, **"개발자가 1년 365일 램(RAM), CPU, OS 보안 패치를 관리하던 짐덩어리를 클라우드 벤더(AWS, Google)에게 100% 떠넘겨버리고(Offloading), 오직 순수한 '비즈니스 코드(함수)'만 허공에 띄워 놓는 극강의 인프라 은닉 사상"**이다.
2. 가치: 24시간 내내 켜져 있으면서 돈을 퍼먹던 낡은 서버를 죽였다. 평소엔 서버가 완전히 꺼져 있어 요금이 0원(Pay-as-you-go)이다. 그러다 이벤트(트래픽)가 10만 건 몰려오면 단 1초 만에 10만 개의 마이크로 함수 컨테이너가 팝콘 튀듯 터져 나와 트래픽을 집어삼키고 쿨하게 소멸하는 '비용 효율성 10,000%'와 '무제한 스케일 아웃'의 끝판왕이다.
3. 융합: 하지만 트래픽 0에서 첫 컨테이너를 띄울 때 3초간 뻗는 **콜드 스타트(Cold Start, 559장)**라는 치명적 발목 잡기가 존재하며, 이를 무마하기 위해 이벤트 주도 아키텍처(EDA)의 비동기 백그라운드 큐(SQS/Kafka)와 융합되어 진정한 클라우드 네이티브의 최종 진화형(Next-Gen Cloud)으로 군림한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념:

  • Serverless: "서버 관리에 대한 신경을 쓴다(Server) ➡ 신경 쓸 게 없다(Less)". 물리적 서버는 AWS 창고에 당연히 존재하지만 나한텐 투명 인간이다.
  • FaaS (Function as a Service): 서버리스의 핵심 뇌 구조. 옛날엔 Spring Boot 거대 앱을 올렸다. 이젠 무식하게 통째로 올리지 말고, 결제_함수(), 이미지_리사이징_함수() 처럼 100줄짜리 쪼꼬만 함수(Function) 쪼가리 단위로 배포해서 이벤트가 터질 때만 잠깐 실행하고 죽이는 초경량 모델이다.

• 필요성 (EC2 깡통 서버의 낭비 지옥): 티켓팅 오픈은 금요일 밤 8시에 10만 명이 몰린다. 평일 낮엔 10명 들어온다. 옛날 아키텍트는 8시 트래픽을 막으려고 EC2 서버 100대를 1년 내내 켜뒀다. 평일 내내 서버 CPU 점유율은 1%인데, 사장님은 매달 1천만 원씩 AWS 고지서를 냈다(유휴 자원 낭비 99%). 게다가 매달 리눅스 커널 보안 패치하느라 데브옵스는 밤을 새웠다. **"트래픽이 올 때만 서버가 켜지고, 트래픽이 빠지면 0원으로 셧다운 되는 마법의 인프라가 필요해!"**라는 자본주의적 피눈물이 서버리스 혁명을 낳았다.

• 💡 비유: 기존 서버(EC2)는 **'자가용 자동차 구매'**와 똑같습니다. 출퇴근 1시간 탈 건데, 보험료 1년 치, 주차장 비용 24시간 치, 엔진오일(OS 패치) 교체까지 내 돈과 땀을 다 쏟아야 합니다(인프라 관리 낭비). 서버리스는 **'우버(카카오택시)'**입니다. 필요할 때 버튼 누르면 차(함수)가 1초 만에 내 앞에 오고, 탄 거리(ms, 밀리초 단위 실행 시간)만큼만 딱 요금을 내고 쿨하게 헤어집니다. 주차비(유휴 서버 유지비)도 0원, 엔진 고장(하드웨어 장애)도 우버 본사(AWS)가 다 알아서 고칩니다. 압도적 해방감입니다.

• 등장 배경 및 발전 과정:

  1. IaaS (EC2 시대): 컴퓨터 깡통 렌탈. 리눅스 깔고 톰캣 깔고 내가 다 함. 자유도는 높으나 노가다 지옥.
  2. PaaS / CaaS (Docker, K8s 시대): 컨테이너로 예쁘게 말아서 배포. OS 세팅은 안 해도 되지만 24시간 켜놔야 하고 K8s 오케스트레이션 러닝 커브에 다 죽어 나감.
  3. FaaS (AWS Lambda의 충격, 2014~): 2014년 AWS가 람다(Lambda)를 발표했다. "니들 도커 껍데기도 만들지 마! 걍 Node.js, Python 함수 소스코드만 텍스트 복붙해서 창에 넣어! 트래픽 오면 우리가 알아서 컨테이너 1만 개 띄워서 실행시켜 줄게!" 진정한 No-Ops(인프라 관리 제로)의 넥스트 클라우드가 폭발했다.

• 📢 섹션 요약 비유: 옛날엔 전기를 쓰려면 집 앞마당에 **개인용 소형 화력발전소(EC2)**를 지어 석탄을 때워야 했습니다. 석탄이 떨어지면 불이 꺼졌죠. 서버리스는 벽에 뚫린 **'콘센트(플러그)'**입니다. 내가 원할 때 코드만 꽂으면(이벤트 발생) 전기가 무한대로 콸콸 쏟아져 들어오고, 코드를 뽑으면(종료) 요금 미터기는 정확히 그 찰나의 순간에 멈춥니다. 발전소가 어디서 어떻게 도는지는 내 알 바 아닙니다. 나는 그저 전기(비즈니스 가치)만 씁니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. FaaS의 생명 주기 (이벤트 주도 파이프라인)

서버리스는 무조건 '트리거(방아쇠)'가 있어야만 눈을 뜬다. 누군가 깨워줘야 한다.

[ 🛡️ S3 이미지 리사이징 자동화 시나리오 ]

1. Trigger (이벤트 발생): 유저가 10MB짜리 원본 이미지를 AWS S3(스토리지)에 업로드 쾅!
2. Awake (함수 기상): S3가 "야 이미지 들어왔어!" 이벤트를 AWS Lambda 엔진에 툭 던진다.
3. Execution (컨테이너 임시 소환): AWS 인프라가 0.1초 만에 허공에서 컨테이너를 1개 만들어 내고, 그 안에 개발자가 짜둔 Python 리사이징_함수() 텍스트 코드를 쑤셔 박아 실행한다.
4. Die (수습 후 자살): 파이썬 코드가 이미지를 1MB 썸네일로 줄여서 DB에 저장한다. 저장 끝나면 람다는 가차 없이 컨테이너를 찢어버리고 자살(소멸)한다. ▶ 특징: 과금은 이 파이썬이 실행된 딱 '300ms (밀리초)' 분량의 컴퓨팅 비용 0.01원만 과금된다. 1년 내내 켜두는 게 아니다!

2. 서버리스의 흑마법: 미친듯한 오토스케일링 (Auto-Scaling)

K8s나 EC2의 오토스케일링과는 차원이 다른 괴물.

• 기존 EC2/K8s 스케일링 (느림): 트래픽 폭주 ➡ CPU 80% 찍음 ➡ 스케일 그룹이 감지함 ➡ 새 EC2 켜고 톰캣 켜고 라우터 붙임 ➡ 최소 3분~10분 소요. 이미 트래픽 다 뒤지고 클레임 폭주함.

• Serverless 스케일링 (1초 컷): 트래픽 1만 개가 동시 폭주 ➡ AWS 인프라가 그냥 무지성으로 람다(Lambda) 컨테이너 1만 개를 1초 만에 허공에서 팝콘 튀기듯 펑펑펑펑 생성해서 트래픽 1만 개에 1:1로 물려버린다. 트래픽이 0개가 되면? 1만 개 컨테이너가 일제히 터져서 사라진다. 개발자는 설정 1줄 건드리지 않아도 트래픽의 파도(Spike)를 100% 무결점으로 서핑해 낸다.

• 📢 섹션 요약 비유: 기존 오토스케일링이 **'식당 손님이 100명으로 늘어나면, 사장님이 헐레벌떡 인력 사무소에 전화해서 알바생 5명 불러다 30분 뒤에 투입하는 아슬아슬한 버티기'**라면, 서버리스는 손님 1명이 가게 문을 열 때마다 식당 뒷문에서 **'닌자 알바생 1명이 펑! 하고 소환되어 그 손님 주문만 딱 받고 펑! 하고 연기처럼 사라지는 1:1 무한 그림자 분신술'**입니다. 손님이 1만 명 오면 닌자도 1만 명이 생깁니다. 병목이 수학적으로 불가능합니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 클라우드 인프라 진화 최후의 삼국지 (IaaS vs CaaS vs FaaS)

아키텍트가 프로젝트 시작할 때 인프라 비용/노가다를 고르는 트레이드오프 표.

과목 융합 관점

• 소프트웨어 공학 (상태 비저장, Stateless의 강제성): 서버리스 함수는 트래픽이 끝나면 1초 만에 찢어져 죽는다. 따라서 개발자가 코드 안에 let userCount = 0; userCount++; 이딴 짓으로 메모리에 상태(State)를 저장하려 들면 다음 호출 때 초기화(0)되어 개박살이 난다. 서버리스 세계에서 모든 함수는 100% 무상태(Stateless)여야 한다. 무언가 상태를 유지하고 싶다면 무조건 외부의 Redis, DynamoDB(완전 관리형 DB)로 0.01초 만에 쏘고 쿨하게 죽어야(Persist to External) 하는 마이크로서비스 설계 철학의 궁극적 강제 집행이다.

• 클라우드 컴퓨팅 (Event-Driven Architecture와의 영혼 파트너): 538장에서 본 EDA는 사실 서버리스가 없으면 팥 없는 찐빵이다. "S3 이미지 업로드됨(Event) ➡ Lambda 기상(Action) ➡ DB 저장 완료됨(Event) ➡ SNS/SQS 알림톡 발송 Lambda 기상(Action)". 이처럼 AWS의 수십 개 서비스들이 서로 이벤트를 던지면, 람다 함수가 공중에서 잠깐씩 튀어나와 접착제(Glue Code)처럼 본드 칠을 하고 사라지는, 24시간 도는 서버 없이 100% 이벤트의 흐름(Flow)만으로 굴러가는 거대한 무중력 아키텍처 생태계가 완성된다.

• 📢 섹션 요약 비유: IaaS(EC2)가 **'내 땅을 사서 벽돌을 쌓아 올린 전원주택(관리 빡셈, 자유도 높음)'**이고, CaaS(도커)가 **'월세 원룸(안에 가구 배치는 내 맘대로)'**라면, FaaS(서버리스)는 **'초 단위로 빌려 자는 최고급 캡슐 호텔'**입니다. 이불 빨래, 방 청소(서버 관리)는 호텔 직원이 다 해줍니다. 나는 피곤할 때(트래픽) 잠깐 누워서 눈 붙이고 잔 시간(ms)만큼만 돈을 내고 쿨하게 나갑니다. 방을 꾸밀 자유는 없지만, 속도와 가성비는 미쳤습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 'Vendor Lock-in(벤더 종속성)'의 독가스, AWS 벗어날 수 있나?: 스타트업 대표가 "우리 AWS Lambda 서버리스로 다 짰으니까 인프라 관리 필요 없다!" 신나 했다. 3년 뒤 AWS 요금이 비싸져서 네이버 클라우드나 GCP로 이사가려 했다. 그런데 람다 함수 코드들이 AWS API Gateway, DynamoDB, S3 이벤트 트리거와 거미줄처럼 한 몸으로 얽혀서 떡이 되어 있었다. 코드를 단 1줄도 떼어내서 옮길 수가 없었다. 서버리스 꿀을 빤 대가로 AWS 제국의 영원한 노예(Vendor Lock-in)로 족쇄가 채워진 끔찍한 종속성의 파국이다.

   • 아키텍트의 해결책: 헥사고날 아키텍처(Hexagonal Architecture) 기반의 비즈니스 뇌 분리 수술이다. 서버리스를 쓸 땐 AWS SDK를 내 핵심 로직에 비비면 안 된다! 아키텍트는 람다의 handler(event, context) 입구 껍데기 코드와, 내 순수한 결제_계산() 로직 코드를 완벽히 파일로 찢어야(Port & Adapter) 한다. AWS 종속적인 트리거 파싱 로직은 껍데기에만 두고, 핵심 계산은 순수 자바스크립트로만 돌아가게 격리해 둬라. 그래야 나중에 AWS가 싫어지면 껍데기만 살짝 뜯어 버리고 구글 클라우드 펑션(GCP Function) 껍데기로 갈아 끼워 1주일 만에 대탈출(Migration)에 성공할 수 있다.

2. 시나리오 — 서버리스의 무한 스케일링이 낳은 하위 DB(RDBMS) 디도스(DDoS) 대참사: 블랙프라이데이에 트래픽 10만 건이 몰렸다. AWS Lambda가 신나서 함수 컨테이너 1만 개를 1초 만에 띄웠다(오토스케일링 짱짱맨!). 문제는 이 람다 1만 개가 각자 밑에 있는 낡은 오라클(Oracle/MySQL) DB에 "돈 빼!"라고 Connection을 1만 개 동시에 쑤셔 박은 것이다! 람다는 무한 확장이지만 낡은 관계형 DB의 커넥션 풀(Pool) 한계는 고작 500개다. DB가 람다의 무자비한 커넥션 융단폭격을 맞고 그 자리에서 뻗어버리며 회사 전산망이 날아갔다 (스케일 불균형의 비극).

   • 아키텍트의 해결책: 연결 다중화 방어막 (RDS Proxy) 및 큐(Queue) 댐 설계다. 서버리스(무한)가 레거시 DB(유한)를 직접 찌르게 두는 건 살인 행위다. 1) 아키텍트는 람다와 DB 사이에 **AWS RDS Proxy (커넥션 풀 관리자)**라는 중간 댐을 박아둬서, 1만 개의 람다 접속을 500개의 DB 커넥션으로 예쁘게 모아서 뚫어주는 쿠션 역할을 세워야 한다. 2) 애초에 결제 트래픽이면 람다가 직접 DB 찌르지 말고, 무조건 **SQS(큐)**에 1만 개 이벤트를 툭 던지고 자살하게 만든다. 그 뒤에 백그라운드 람다 10개가 큐를 천천히 주워 먹으며 DB를 살살 찌르도록 속도를 제어(Throttling)하는 완충 지대를 구축해야 진정한 클라우드 아키텍트다.

도입 체크리스트

• 비즈니스적: "24시간 내내 트래픽이 쉴 새 없이 1만 TPS를 찍는 꾸준한 도메인인가? 아니면 띄엄띄엄 치고 빠지는 간헐적(Spiky) 도메인인가?" 여기서 잘못 고르면 파산한다. 서버리스 요금제(ms당 과금)는 트래픽이 적거나 뾰족뾰족할 때 쓰면 EC2보다 10배 쌉니다. 하지만 넷플릭스 영상 스트리밍 코어나, 1년 365일 내내 트래픽이 꽉 차서 들어오는 메인 DB API를 람다로 띄웠다간? EC2 서버 사서 1년 켜두는 것보다 서버리스 요금이 수십 배(10x) 더 폭발적으로 비싸게 청구되어 회사 기둥뿌리 뽑힌다. **"항시 켜놔야 하는 코어는 무조건 EC2/K8s로 박고, 어쩌다 도는 배치 작업이나 이미지 썸네일 따기, 삐죽삐죽한 이벤트 처리만 서버리스로 찢어버리는 양동 작전(Hybrid)"**이 최고의 갓성비다.
• 기술적: 함수의 실행 시간이 15분을 넘어가는 무거운 배치(Batch) 작업인가? AWS Lambda의 절대 헌법: "아무리 길어도 15분 지나면 무조건 컨테이너 찢어 죽임(Timeout 강제 킬)." 만약 1시간 동안 DB 1억 줄 읽어서 통계 내는 거대 자바 배치 프로그램을 람다에 올리면 15분 만에 허공에서 목이 날아가서 영원히 작업을 못 끝낸다. 람다는 무조건 빠르고 가벼운 1초 컷 API에 몰빵하고, 무거운 배치는 AWS Batch나 ECS(도커) 컨테이너로 돌려야 한다.

안티패턴

• "람다 함수 1개(Fat Function) 안에 API 50개를 라우팅 치는 모놀리스 욱여넣기": serverless.yml 1개에다가 Spring Boot 100MB짜리 뚱뚱한 프레임워크를 통째로 말아 넣고, 람다 컨테이너 1개 안에서 /user, /pay, /cart 50개 API를 다 IF문으로 라우팅 쳐서 받아내는 극악의 "서버리스 모놀리스" 짓거리. 컨테이너 용량이 200MB가 되면서 콜드 스타트(부팅) 지연 시간이 10초를 돌파해 유저들이 다 도망가고, 함수 1개 고쳤다고 50개 API가 다 같이 배포되는 서버리스 철학의 100% 붕괴다. "서버리스는 무조건 1 API = 1 마이크로 함수(Function) 매핑 룰을 지켜서 극단적으로 뼈를 깎고 가볍게 찢어발겨야만 그 속도와 독립성의 진가가 나온다."

• 📢 섹션 요약 비유: 서버리스에 거대 뚱뚱한 프레임워크(Spring)를 통째로 넣는 짓은, **'동네 슈퍼 갈 때 타는 전동 킥보드(Lambda)에, 캠핑 트레일러(Spring Boot)를 무식하게 쇠사슬로 매달고 언덕을 오르려는 짓'**입니다. 킥보드 모터가 다 타버립니다(콜드 스타트 10초 폭발). 전동 킥보드엔 지갑 하나(순수 로직 100줄)만 덜렁 들고 가볍게 치고 빠져야 1초 만에 마트를 다녀올 수 있습니다. 무거운 걸 옮겨야 하면 정직하게 화물 트럭(EC2/K8s)을 부르는 게 맞습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 엣지 컴퓨팅(Edge Computing)과의 융합 폭발 (Cloudflare Workers): 지금은 람다가 AWS '서울(Seoul)' 리전이라는 짱박힌 데이터센터에서 돈다. 미국 유저가 호출하면 태평양 건너느라 100ms 딜레이가 생긴다. 이젠 서버리스 함수가 전 세계 통신사 기지국(Edge) 300곳으로 흩뿌려진다! 유저가 뉴욕에서 버튼을 누르면 뉴욕 기지국 캐시 서버에 숨어있던 Cloudflare Worker(초경량 함수)가 0.001초 만에 V8 V8 Isolate 엔진으로 빛의 속도로 실행되어 응답을 뱉는다. 지구촌 단위의 물리적 네트워크 지연(Latency) 한계를 아예 박살 내버리는 궁극의 엣지 서버리스 시대가 이미 열렸다.
• 서버리스 데이터베이스의 강림 (Serverless DB/Aurora Serverless): 옛날엔 "앱(Lambda)은 무한대로 늘어나는데, 밑에 달린 DB가 서버리스가 아니라 EC2 고정형이라 뻗는다"는 반쪽짜리 혁명이었다. 이젠 클라우드 거인들이 아예 RDBMS(Aurora, Cockroach)나 NoSQL(DynamoDB)조차 서버리스로 만들어버렸다! 평소엔 DB가 자면서 요금 안 나가다가, 트래픽 쏟아지면 DB CPU 코어가 1초 만에 1개에서 100개로 미친 듯이 쫙 늘어나서 쿼리를 다 씹어 먹는 'Full-Stack Serverless(앱부터 DB까지 100% 오토 스케일링)' 천하 통일이 엔터프라이즈의 종착지가 되고 있다.

참고 표준

• AWS Lambda: 2014년에 등장하여 클라우드 역사상 가장 위대한 "서버리스"라는 종교를 창시한 1티어 갓파더 툴.
• CNCF Serverless Whitepaper: 클라우드 네이티브 재단이 "FaaS가 뭐고, 어떻게 짜야 병신같이 안 짜는지" 규격을 잡아둔 아키텍처 바이블.

서버리스 아키텍처 (Serverless / FaaS)는 소프트웨어 공학이 인프라(하드웨어)라는 무거운 철창을 완전히 끊어내고, 오직 '비즈니스의 순수한 논리(Code)' 그 자체만 둥둥 떠다니는 클라우드의 이상향(Utopia)에 도달한 가장 완벽한 쾌감의 아키텍처다. 우리는 수십 년 동안 내 코드를 돌리기 위해 리눅스를 깔고, 톰캣을 깔고, 포트를 열고, 해커의 방화벽을 막는 지저분한 배관공 노릇(Ops)에 개발 인생의 절반을 갈아 넣었다. 서버리스는 선언한다. "그딴 쓰레기 같은 인프라 조립은 AWS 노예 1만 명의 몫이다. 천재 개발자인 너희는 오직 돈을 버는 계산 로직 100줄만 텍스트 파일로 던져라. 나머지는 신(Cloud)이 알아서 해 주리라." 트래픽이 0일 땐 먼지처럼 사라져 자본의 피를 아끼고, 트래픽이 100만 건 터질 땐 허공에서 100만 명의 그림자 무사(Container)를 1초 만에 소환해 내는 그 자비 없는 파괴력. 물론 콜드 스타트라는 3초의 덜컹거림과 악독한 벤더 종속(Lock-in)의 사슬을 차야 하는 치명적 악마의 거래다. 하지만 개발자가 서버라는 쇳덩이의 존재 자체를 뇌에서 100% 딜리트(Delete)하고, 오직 사용자의 요구사항(기능) 하나에만 모든 에너지를 레이저처럼 쏠 수 있게 만들어준 그 압도적인 생산성의 폭발은 클라우드 네이티브 진화의 돌이킬 수 없는 절대 지향점(Next-Gen)이다.

• 📢 섹션 요약 비유: 기존 인프라(EC2)는 **'직접 요리 재료를 사고, 가스 불을 켜고 조리한 뒤, 설거지(OS 패치)까지 다 해야 하는 집밥'**입니다. 밥 한 끼 먹기 드럽게 힘듭니다. 서버리스는 최고급 **'밀키트 초고속 전자레인지(FaaS)'**입니다. 나는 딱 100줄짜리 내 전용 밀키트 레시피(함수 코드)만 툭 던져넣고 1초 만에 버튼을 누릅니다. 그러면 전자레인지 1만 대가 동시에 켜져서 요리를 다 구워낸 뒤 알아서 흔적도 없이 쓰레기통으로 사라집니다. 주방 청소도, 설거지도, 가스비도 걱정할 필요 없는 진정한 요리(비즈니스 로직) 해방의 예술입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 내가 밤에 불을 밝히기 위해 평소에 발전소(EC2 서버)를 24시간 내내 빙글빙글 돌려놓고 있으면 기름값(비용)이 엄청나게 많이 들어서 아까워 죽겠어요!
2. 그래서 나는 똑똑하게, **내가 박수(이벤트 트래픽)를 딱! 칠 때만 허공에서 전구 요정 1만 마리가 뿅! 하고 나타나 불을 확 밝히고, 박수가 끝나면 1초 만에 연기처럼 사라지는 마법(FaaS/서버리스)**을 썼어요!
3. 요정은 내가 박수 쳐서 튀어나와 일한 딱 그 시간(1초 단위)만큼만 월급을 달라고 한답니다. 평소엔 0원을 내고, 필요할 때만 무한대로 요정을 소환하는 짱 빠른 클라우드 요술을 '서버리스'라고 부른답니다!