현재 내가 개발 중인 비회원 기반 선물 추천 서비스는 사용자가 프론트엔드에서 guest_id를 통해 고정 질문과 GPT 기반 질문에 답변하고 이 응답을 바탕으로 프론트에서 OpenAI API를 호출해 대표 키워드를 추출한 후 백엔드는 이 키워드들을 기준으로 DB에 캐시된 상품 목록을 조회하여 가장 적절한 상품들을 추천해주는 구조이다.
지금까지는 모든 백엔드 서비스를 EC2에서 Spring Boot 기반으로 실행하고 있었다. 프론트엔드 팀원과의 대화에서 서버리스의 장점이 언급되었고 그 계기로 "우리 서비스 구조에도 서버리스를 적용할 수 있을까?"라는 고민이 시작되었다. 특히 EC2의 유지보수, 고정 인프라 비용, 배포 파이프라인 구성 등 여러 운영적인 부분에서 서버리스로 전환했을 때 얻을 수 있는 이점이 클 것 같았다. 그래서 이 서비스가 AWS Lambda + API Gateway + RDS + Redis 구조로 충분히 구현 가능할지를 고민하고 실제로 적합한 선택일지를 아키텍처적 관점에서 검토해보았다.
서버리스 구조로 전환하면 어떤 구성이 될까?
서버리스 아키텍처는 "필요할 때만 실행되고 사용한 만큼만 과금되는" 구조로 운영 편의성과 비용 효율성을 동시에 챙길 수 있다. 내가 구상한 서버리스 기반 구성은 다음과 같다.
| 기존 구성 | 서버리스 전환 시 대안 |
|---|---|
| Spring Boot API 서버 | AWS Lambda (Java 21 + SnapStart) |
| REST API endpoint | API Gateway |
| MySQL | Amazon RDS 또는 Aurora Serverless v2 |
| Redis | ElastiCache for Redis (VPC 필요) |
※ OpenAI API는 백엔드에서 호출하지 않고 프론트엔드에서 직접 호출하여 대표 키워드를 생성함.
-> 백엔드는 추천 키워드 기반 상품 조회 및 결과 저장, 세션 추적만 수행
기대되는 장점
서버리스는 다음과 같은 이점을 가지고 있다. 특히 비용 효율성과 탄력성 측면에서 매력적이다.
-
무중단 자동 확장 (Auto Scaling)
사용자 요청이 몰릴 경우 Lambda 함수가 자동으로 늘어나며 부하를 분산시킨다. EC2처럼 EC2 Auto Scaling을 직접 구성할 필요가 없다. -
비용 효율성
트래픽이 적은 시간에는 비용이 거의 발생하지 않는다. 특히 비회원 기반 서비스처럼 간헐적 사용량이 있는 구조에 적합할 수 있다. -
서버 관리 불필요
보안 패치, 인스턴스 재시작, 로그 모니터링 등 EC2 운영에 들어가는 유지보수 부담이 줄어든다. -
FaaS에 맞는 기능 분리 가능
예를 들어 추천 생성, 추천 저장, GPT 호출 등을 각각 독립적인 Lambda로 분리하면 테스트 및 배포 단위가 작아져 유지보수가 쉬워진다.
현실적인 제약사항
막상 구체적으로 Lambda로 구현 가능한지 검토해보니 현실적인 제약 사항이 꽤 많았다. 특히 내 서비스가 실시간성과 외부 연동이 중요한 구조이기 때문에 Lambda의 한계가 뚜렷이 드러났다.
-
Spring Boot + Java의 Cold Start 문제
- Lambda에서 Java 기반(Spring Boot) 애플리케이션은 Cold Start가 비교적 길다. (몇 초 이상)
- SnapStart로 완화할 수 있지만 Redis나 DB 연결이 매번 새로 이루어지므로 여전히 응답 지연이 존재한다.
-
Redis 사용 시 VPC 필수
- Lambda에서 ElastiCache Redis에 접근하려면 반드시 VPC에 연결되어야 한다. 이로 인해 Lambda의 네트워크 초기화 시간이 추가되어 Cold Start 시간이 더 늘어나게 된다. 실시간 추천 처리에서 1~2초의 지연도 사용자 경험에 큰 영향을 줄 수 있다.
- Redis를 쓰지 않으면 세션 추적과 캐싱 구조가 복잡해진다.
-
복잡한 상태 관리가 어려움
- Lambda는 기본적으로 무상태 함수이며 내부에 세션이나 연결 상태를 유지하기 어렵다.
guest_id기반 흐름 추적, 추천 결과 캐싱 등을 구현하려면 DB/Redis에 모든 상태를 저장해야 하며 이 과정이 서버리스 함수와 충돌하거나 과도하게 복잡해진다.
결론은 EC2가 현재 구조에 더 적합하다
서비스 특성과 현재 구조를 고려했을 때 서버리스보다는 EC2 기반이 훨씬 안정적이라고 판단했다. 실시간 상품 추천은 빠른 응답이 핵심인데 Lambda의 Cold Start로 인해 안정성이 떨어질 수 있다. 또한 Redis와 RDS 등 외부 서비스와의 연결이 빈번하며 이들 모두 VPC 기반으로 접근할 경우 Lambda 초기화 속도가 느려지된다. 상태 관리, 인증 흐름, 예외 처리 등을 모두 함수 단위로 나누기에는 구조가 너무 복잡해지고 유지보수 부담이 커질 수 있다. 따라서 메인 서비스는 EC2 기반으로 유지하되 서버리스는 특정 부가 기능에 한정해 점진적으로 도입하는 방향이 가장 이상적이라 판단했다.
📝 배운점
단순히 “서버리스가 좋다더라”가 아니라 “우리 서비스 구조에 맞는가?”가 더 중요하다는 사실을 이번 기회에 확실히 느꼈다.
처음엔 EC2에 비해 서버리스가 운영 부담이 적고 비용적으로도 효율적일 것이라는 기대가 있었다. 특히 서비스 초기에는 사용자 수가 많지 않기 때문에 “요청이 있을 때만 실행되는 구조면 더 합리적이지 않을까?”라는 생각이 자연스럽게 들었다. 하지만 실제로 구조를 분석해보니 이 서비스는 단순 트리거성 로직이 아니라 실시간성과 빠른 응답, 상태 유지가 중요한 구조였고 그에 따라 Lambda의 Cold Start, Redis 연결 제약, 복잡한 상태 관리 문제들이 예상보다 크게 다가왔다. 무엇보다 중요한 건 사용자 경험인데 상품 추천 결과가 1~2초만 늦어져도 사용자 이탈이 발생할 수 있고 GPT 기반 서비스 특성상 이미 응답 지연 요소가 있는 상황에서 백엔드까지 느려지는 구조는 치명적일 수 있다. 결국 비용 효율성을 기대하며 서버리스 전환을 고려했지만 성능과 사용자 경험 측면에서는 오히려 손해가 될 수 있다는 판단에 이르렀고 이로 인해 서버리스 도입을 보류하게 되었다. 대신 구조를 잘게 나눠서 향후 로그 수집이나 비동기 처리, 알림 전송처럼 응답 속도가 중요하지 않은 기능들만 서버리스로 점진적 분리하는 방향이 현실적인 전략이라는 확신을 갖게 되었다.
