196. 서버리스 아키텍처 엔터프라이즈 통합 백엔드 (BaaS 기반 결합)

⚠️ 이 문서는 기업이 새로운 웹이나 모바일 앱을 런칭할 때, 전통적으로 로그인(Auth), 데이터베이스, 푸시 알람 등을 처리하기 위해 거대한 백엔드 서버(WAS)를 직접 띄우고 운영하던 방식을 전면 폐기하고, AWS Cognito, Firebase 같은 BaaS(Backend as a Service)와 Lambda 같은 FaaS(Function as a Service)를 레고 블록처럼 조립하여 '서버 운영 관리 제로(0)'로 서비스를 통합해 내는 서버리스(Serverless) 아키텍처를 다룹니다.

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

  1. 본질: "서버가 없다"는 뜻이 아니라, "개발자가 관리하고 패치해야 할 리눅스 OS와 WAS 서버가 없다"는 뜻이다. 모든 백엔드 인프라 관리를 클라우드 제공자(CSP)에게 100% 외주 주는 궁극의 관리형 모델이다.
  2. 가치: 고객이 1명일 때는 요금이 0원이고, 이벤트로 100만 명이 몰려오면 서버가 알아서 100만 대급으로 자동 확장(Auto-scaling)된 후 트래픽이 빠지면 다시 0원이 되는 극단적인 '쓴 만큼만 내는(Pay-as-you-go)' 가성비와 유연성을 자랑한다.
  3. 기술 체계: 로그인과 DB는 **BaaS(Firebase, Supabase)**에 위임하고, 맞춤형 비즈니스 로직(결제 처리 등)만 **FaaS(AWS Lambda)**에 짧은 함수 코드로 짜서 올려 클라이언트(프론트엔드)가 이들을 API 게이트웨이로 직접 찔러 연동하는 구조를 띤다.

Ⅰ. 팻 백엔드(Fat Backend)의 종말과 서버리스의 부상

개발자는 로그인 로직을 짜려고 코딩을 배운 것이 아니다.

  1. 전통적인 3-Tier 백엔드의 고통:
    • 모바일 앱을 하나 만들려면, 백엔드 팀은 회원가입/로그인 코드를 짜고(Spring Security), DB를 깔고(MySQL), 알림 서버를 구축해야 했다.
    • 트래픽이 터질까 봐 새벽에 오토스케일링을 감시해야 하고, 리눅스 보안 패치하느라 밤을 새운다. 진짜 돈 버는 '핵심 비즈니스 로직' 개발 시간은 20%도 안 된다.
  2. BaaS (Backend as a Service)의 혁명:
    • 구글(Firebase), AWS(Amplify)가 선언했다. "네가 짜려는 그 로그인 로직, DB CRUD 로직은 전 세계 99%의 앱이 다 똑같이 쓴다. 우리가 완벽하게 만들어 API로 뚫어놨으니 넌 프론트엔드에서 API만 호출해서 써라."
    • 개발팀은 서버를 띄울 필요조차 없이, 프론트엔드 코드 안에서 firebase.auth().signIn() 한 줄만 치면 완벽한 보안이 적용된 구글/카카오 소셜 로그인이 1분 만에 완성된다.

📢 섹션 요약 비유: 옛날엔 식당을 열려면 밀 심어서 밀가루 만들고, 소 키워서 고기 뽑아(직접 서버 구축) 만두를 빚어야 했습니다. BaaS는 깐깐하게 다 만들어진 '밀키트 세트(인증, DB, 스토리지)'를 도매상에서 사다가, 우리는 주방(서버) 없이 매장 식탁(프론트엔드)에서 버너로 끓여서 손님에게 바로 내는 무점포 식당 혁명입니다.

Ⅱ. FaaS (Function as a Service)와 커스텀 로직 통합

BaaS가 다 해주지만, 우리 회사만의 독특한 결제 로직은 구글이 대신 짜주지 않는다.

  1. FaaS의 조각 코드 (AWS Lambda):
    • 커스텀 비즈니스 로직(예: 결제 완료 시 10% 포인트 적립)은 서버리스 펑션(Function)에 작성한다.
    • 거대한 톰캣(Tomcat) 서버를 띄우지 않고, 파이썬이나 자바스크립트로 딱 50줄짜리 '함수'만 짜서 AWS Lambda에 업로드(Deploy) 해둔다.
  2. 이벤트 구동 (Event-driven) 호출:
    • 이 함수는 평소에는 죽은 듯이 잠자고 있다(비용 0원).
    • 고객이 프론트엔드에서 [결제] 버튼을 누르는 이벤트가 API Gateway를 찌르는 그 순간, AWS가 0.1초 만에 컨테이너를 띄워서 그 50줄짜리 코드를 한 번 휙 실행하고 결과를 뱉은 뒤 다시 함수를 죽여버린다.
  3. 초광속 오토스케일링:
    • 1만 명이 동시에 결제 버튼을 누르면? 클라우드는 순식간에 람다(Lambda) 함수 1만 개를 1초 만에 병렬로 쫙 띄워서 한방에 처리해 버린다. 인간이 로드밸런서를 세팅할 필요가 아예 없다.

📢 섹션 요약 비유: 평소엔 사무실에 직원이 0명(비용 0원)입니다. 손님이 벨을 누르면 그 순간 허공에서 알바생(Lambda)이 뿅 하고 나타나 1건의 서류 작업(함수 실행)을 끝내고 0.1초 만에 다시 허공으로 사라집니다. 손님 1만 명이 동시에 벨을 누르면, 알바생 1만 명이 동시에 나타나서 각자 1장씩 처리하고 싹 사라지는 귀신같은 극한의 인력 운영입니다.

Ⅲ. 엔터프라이즈 서버리스 통합의 딜레마 (콜드 스타트)

완벽해 보이지만 큰 기업들이 100% 서버리스로 못 넘어가는 치명적 이유가 있다.

  1. 콜드 스타트 (Cold Start) 지연:
    • 람다(Lambda) 함수는 평소에 죽어있으므로, 첫 손님이 버튼을 눌렀을 때 AWS가 창고에서 코드를 꺼내와 컨테이너를 띄우고 실행 준비를 하는 데 1~2초가량의 초기 지연 시간(Cold Start)이 발생한다. (특히 무거운 Java 스프링 환경에서 치명적)
    • 빠른 응답이 생명인 게임 서버나 주식 트레이딩 시스템에는 서버리스를 절대 쓸 수 없는 이유다.
  2. 상태 보존 불가 (Stateless)와 벤더 종속 (Lock-in):
    • 람다는 실행 끝나면 죽어버리므로 메모리에 변수나 사용자 로그인 세션을 저장할 수 없다. 모든 상태는 무조건 외부 DB(DynamoDB 등)에 써야 해서 구조가 복잡해진다.
    • 게다가 구글 Firebase의 DB 로직과 AWS Lambda의 문법으로 코드 전체를 도배해 놓으면, 훗날 클라우드 요금이 올라도 다른 회사로 이사(Migration) 가기 불가능해지는 치명적인 벤더 종속(Vendor Lock-in)의 볼모가 된다.

📢 섹션 요약 비유: 알바생이 뿅 하고 나타나는 건 좋은데, 첫 번째 손님이 벨을 누르면 알바생이 자다 깨서 옷 입고 나오느라 2초를 기다려야 합니다(콜드 스타트). 게다가 이 알바생은 심각한 치매(Stateless)라서 1초 전에 만난 손님 이름도 기억 못 해 매번 장부(외부 DB)를 뒤져야 하고, 알바생 인력 사무소(AWS)가 내년부터 시급을 2배 올린다고 협박해도 다른 사무소로 바꿀 수가 없는 노예 계약(벤더 종속) 상태에 빠진 것입니다.