서버리스만으로 부족했던 운영 콘솔 백엔드 설계

운영 콘솔 아키텍처 시리즈 6/9

서버리스는 운영 부담을 크게 줄여준다. 트래픽이 없을 때 비용이 거의 없고, 갑작스러운 요청도 자동으로 확장된다. 그래서 운영 콘솔을 만들 때 모든 API를 Lambda로 만들고 싶어질 수 있다.

하지만 모든 요청이 Lambda에 잘 맞는 것은 아니다. 반대로 모든 요청을 상주 서버로 처리하는 것도 답은 아니었다.

문제 상황

운영 리포트 콘솔에는 성격이 다른 API가 섞여 있었다.

하나는 대시보드나 목록 조회처럼 짧고 자주 호출되는 API다. 내부 운영자가 화면을 이동할 때마다 호출되고, 응답은 빠를수록 좋다. 내부 인증 쿠키를 확인하고, RDB 커넥션 풀을 사용해 여러 집계 쿼리를 실행한다.

다른 하나는 리포트 생성처럼 드물지만 오래 걸리는 API다. 사용자가 버튼을 누르면 수 초에서 수십 초 동안 데이터를 모으고 파일을 만든다. 동시에 여러 명이 요청할 수도 있지만 평소에는 거의 호출되지 않는다.

두 워크로드를 같은 실행 모델에 넣으면 한쪽이 불리해진다.

선택지

첫 번째 선택지는 모든 API를 Lambda로 만드는 것이었다. 운영 부담은 낮지만, 자주 호출되는 조회 API에서 DB connection storm과 cold start가 문제가 될 수 있다.

두 번째 선택지는 모든 API를 Express 같은 상주 서버로 만드는 것이었다. DB 커넥션 풀과 쿠키 인증은 자연스럽지만, 오래 걸리는 리포트 생성이 서버 리소스를 오래 점유한다. 별도 큐나 워커를 구성하지 않으면 응답 지연이 다른 요청에 영향을 줄 수 있다.

세 번째 선택지는 워크로드별로 나누는 것이었다. 짧고 잦은 조회는 상주 API 서버가 처리하고, 드물고 무거운 작업은 Lambda가 처리한다.

세 번째 방식을 선택했다.

최종 결정

상주 API 서버와 Lambda를 함께 사용한다.

워크로드	특성	실행 모델
대시보드 조회	짧고 잦음	상주 API 서버
내부 인증 확인	쿠키 기반, 매 요청 필요	상주 API 서버
리포트 생성	드물고 오래 걸림	Lambda 또는 worker
파일 업로드/다운로드 준비	이벤트성, 독립 실행	Lambda

구현 구조

상주 API 서버는 내부 운영자가 자주 호출하는 조회 API를 맡는다. Node.js Express 같은 일반적인 웹 서버를 사용하고, DB 커넥션 풀을 유지한다.

Browser
  -> GET /api/dashboard
  -> Application server
  -> Connection pool
  -> RDB

이 구조에서는 매 요청마다 DB 연결을 새로 만들 필요가 없다. 서버 프로세스가 살아 있는 동안 일정 개수의 커넥션을 유지하고 재사용한다.

Lambda는 리포트 생성이나 동기화처럼 독립적인 작업을 맡는다.

Browser
  -> POST /api/reports
  -> API Gateway
  -> Lambda
  -> Object storage

호출 빈도는 낮지만 한 번 실행될 때 무거운 작업은 Lambda의 사용량 기반 과금과 자동 확장이 잘 맞는다.

얻은 것

각 워크로드에 맞는 실행 환경을 선택할 수 있었다. 조회 API는 cold start 없이 빠르게 응답하고, DB 커넥션 풀도 안정적으로 유지된다.

반대로 리포트 생성은 상주 서버의 요청 처리 흐름에서 분리된다. 리포트를 만드는 동안 대시보드 조회가 느려지지 않는다. Lambda 동시 실행을 통해 여러 리포트 작업도 독립적으로 처리할 수 있다.

비용 측면에서도 균형이 맞았다. 상주 서버는 꼭 필요한 조회와 인증 처리에만 사용한다. 오래 걸리지만 드문 작업은 사용한 만큼만 비용을 낸다.

포기한 것

백엔드가 두 종류가 되면서 클라이언트 API 설정이 복잡해진다. 어떤 요청은 상주 API 서버로 가고, 어떤 요청은 API Gateway로 간다. 인증, 에러 포맷, 로깅 방식도 통일하지 않으면 사용성이 떨어진다.

운영 문서도 더 중요해진다. 장애가 났을 때 "이 화면은 어느 백엔드를 호출하는가"를 바로 알 수 있어야 한다.

다시 설계한다면

프론트엔드 API 클라이언트를 처음부터 명확히 분리하겠다.

liveApiClient    -> 짧고 잦은 조회
jobApiClient     -> 리포트 생성과 작업 상태 조회

또한 에러 응답 형식은 두 백엔드가 공유하도록 맞추겠다. 실행 모델은 달라도 프론트엔드가 받는 에러 구조는 같아야 한다.

규모가 커진다면 상주 서버는 단일 인스턴스보다 managed container 환경으로 옮길 수 있다. 다만 처음부터 오케스트레이션을 도입하기보다, 실제 운영 복잡도가 필요해질 때 옮기는 편이 낫다.

정리

서버리스와 상주 서버는 경쟁 관계가 아니다.

짧고 잦은 조회, 쿠키 인증, DB connection pool이 필요한 API는 상주 서버가 잘 맞는다. 드물고 오래 걸리며 독립적으로 실행되는 작업은 Lambda가 잘 맞는다. 중요한 것은 기술 선호가 아니라 요청 패턴을 기준으로 실행 모델을 나누는 것이다.

함께 볼 GitHub 저장소

• ops-console-architecture-playbook