5인팀 스타트업 첫 인프라, AWS 서버리스 고른 이유

5인팀 스타트업의 첫 인프라를 결정해야 했던 때가 있었어요. 기획 1·디자이너 1·개발 2·영업 1. AI 코드 어시스턴트가 지금처럼 자리잡기 전이었고, 제품은 아직 PMF도 투자도 받기 전이었습니다.

런웨이는 짧고, 검증해야 할 엣지 기능은 많고, 고객 피드백은 빨리 받아야 했어요. “뭘로 시작하지”라는 질문 앞에서 저는 꽤 오래 머뭇거렸습니다. 기술은 재밌지만 잘못 고르면 제품 속도 전체가 멈춘다는 걸 알고 있었거든요.

결론부터 쓰면, 그 시점의 저는 Lambda와 RDS Serverless v2 조합을 골랐어요. 지금 다시 돌아봐도 같은 판단을 할 것 같습니다.

서버리스, 왜 이 단계에 맞나

초기 스타트업에서 인프라 비용은 단순한 월 청구서가 아니라 제품 속도·런웨이·의사결정 속도를 동시에 갉아먹는 변수예요. EC2 한 대를 계속 띄워두면 트래픽이 0일 때도 시간당 과금이 돌고, RDS를 상시 가동해 두면 야간과 주말에도 고정비가 빠져나갑니다.

서버리스는 서버를 직접 운영하지 않고 사용한 만큼 과금하는 실행 모델이에요. Lambda는 요청이 있을 때만 실행 환경이 뜨고, Aurora Serverless v2는 ACU 단위로 용량이 자동 조절됩니다. 여기에 CloudWatch도 프리 티어 범위 안에서 기본 지표·로그·알람 수준은 충분히 커버돼서, 초기엔 모니터링 비용을 따로 걱정할 필요가 없었어요.

PMF 전 단계에서 이 과금 구조가 주는 심리적 여유는 생각보다 커요. 배포했다가 아무도 안 써도 청구서 금액이 무섭지 않습니다. 그게 도전하는 빈도를 늘리거든요.

팀 제약이 판단 축으로 이어졌어요

제가 이 선택을 할 때 머리로 먼저 그린 건 팀·시기 제약 4개였어요. 신기한 게, 그 제약들이 하나씩 판단 축으로 그대로 연역되더라고요.

개발자 2명뿐이면 인프라 전담이 없다는 뜻이라, 관리 부담이 적어야 했어요. AI 코드 어시스턴트가 없던 시기였으니 도구 세팅·모니터링·배포 파이프라인을 직접 짜는 공수를 최소화해야 했고, PMF 전이라 고정비를 0에 가깝게 두고 싶었습니다. 거기에 빠른 피드백 루프까지 원했으니 배포·롤백 속도까지 필요했어요.

네 축이 모두 가리키는 답이 서버리스였어요. 유행이라서가 아니라, 제약에서 연역된 결과였습니다.

그럼에도 알아야 할 3가지 한계

유행처럼 “서버리스 좋다”만 쓰고 싶지는 않아요. 제 기준에선 이 조합이 가진 한계도 같이 봐야 선택의 의미가 살아납니다.

1. 콜드 스타트

Lambda는 일정 시간 호출이 없으면 실행 환경이 내려가고, 다음 첫 호출에서 실행 환경 재기동 지연이 생겨요. 평소엔 체감이 거의 없지만 로그인·결제 같이 첫 응답 속도가 지표에 바로 연결되는 엔드포인트에선 사용자 불만으로 이어질 수 있어요.

Provisioned Concurrency로 어느 정도 완화할 수 있지만, 미리 띄워두는 만큼 비용과 복잡도가 다시 올라갑니다. 공짜 완화는 아니에요.

2. 호출당 단가 자체는 비쌈

사용량 과금은 매력적이지만, 호출 하나당 단가로만 놓고 비교하면 상시 가동되는 EC2·RDS보다 높아요. 트래픽이 일정 수준을 넘어가면 고정 인스턴스가 더 싸지는 비용 역전 구간이 분명히 존재합니다.

구체 수치는 규모·리전·실행 시간에 따라 달라지니, AWS Lambda 요금 페이지와 공식 요금 계산기를 직접 돌려보는 게 가장 정확해요.

3. 스케일·유연성 제약

Lambda는 계정·리전별 동시 실행 쿼터가 있고, Aurora Serverless v2도 최소·최대 ACU 범위 제약이 있어요. VPC 내 RDS에 Lambda에서 접근할 때는 ENI·네트워킹까지 추가로 고려해야 합니다.

프로덕트가 엄청 잘돼서 동시 접속이 폭발하는 구간이 오면, 이 쿼터와 네트워킹이 하나씩 병목으로 떠올라요. 그때 다시 손을 대야 하는 지점이 분명히 있습니다.

한계를 알고도 고르는 2가지 이유

그럼에도 저는 그 시점의 5인팀에 같은 선택을 권할 것 같아요. 이유는 두 가지로 압축됩니다.

이유 1. 단가 역전까지 가는 건 쉽지 않아요

냉정하게 보면, PMF 전 단계에서 서버리스 단가 역전점 근처까지 가는 서비스가 많지 않아요. 제 기준에선 거기 도달했다면 이미 매출이 붙기 시작했거나 투자 라운드가 지나간 뒤일 가능성이 높습니다.

그 구간에 닿고 나서 컨테이너·ECS·k8s로 옮겨도 전혀 늦지 않아요. 오히려 그 시점엔 인프라 전담 인력을 뽑을 여유까지 생겨 있을 확률이 높습니다. 문제가 구체화된 뒤에 구체화된 도구를 꺼내는 게 초기 팀엔 더 안전해요.

이유 2. 인프라 관리 부담을 통째로 위임할 수 있어요

초기 스타트업은 서버 비용도 아껴야 하고, 인프라를 전담할 사람을 뽑기도 현실적으로 쉽지 않은 상황이 겹쳐요. 시드 수준 런웨이에서 풀스택·인프라 인재를 따로 확보하는 건 예산 측면에서도 인재풀 측면에서도 만만치 않거든요.

설령 한 명 뽑을 여유가 생긴다 해도, 팀에 사람이 늘면 의사결정 경로와 커뮤니케이션 비용이 함께 늘어납니다. 개발자 2명이 직접 감당하던 배포·모니터링 이슈가 3명의 논의 주제가 되고, 그 논의가 결국 기능 출시 속도를 깎아요. 제 기준에선 이게 오히려 더 큰 병목이라 느꼈습니다.

서버리스는 이 구조 자체를 바꿔요. EC2 이미지 만들고 배포 파이프라인 짜고 DB 백업 자동화하는 부담을 AWS가 가져가는 구조예요. 서버 비용도 아끼면서, 동시에 인프라 전담 채용·추가 커뮤니케이션 비용까지 한 번에 줄이는 게 그 시점 제 판단에선 가장 현실적인 해법이었습니다.

비슷한 초기 팀 기준을 정리하면 제 기준에선 이렇습니다.

언제 갈아타야 하나 — 전환 4신호

서버리스를 고른 뒤엔 “언제 갈아타야 하나”를 꾸준히 감시해야 해요. 제가 머릿속에 체크리스트로 두고 있는 4신호입니다.

네 신호 중 하나만 들어오면 예열, 두 개 이상 겹치면 본격 이전 논의를 시작하는 리듬으로 저는 보고 있어요.

레스덕의 정리

돌아보면 이 선택은 서버리스가 유행이라 한 것이 아니라, 5인팀이라는 조건과 PMF 전이라는 시점, 개발자 2명이라는 한계에서 연역된 결과였어요. 같은 상황이 다시 와도 저는 Lambda와 RDS Serverless v2를 먼저 꺼낼 것 같습니다.

물론 우려가 없지는 않았어요. “스타트업 인프라 비용 월 30～50만 원 정도 아끼려다가 나중에 스택 이전에서 더 큰 비용을 치르는 건 아닐까” 하는 생각이요. 그래도 그 당시 제가 가진 정보와 제 포지션에서 할 수 있는 최선이 이 선택이었다고 느꼈고, 지금도 그 판단에 후회는 없습니다.

다만 이 판단은 AI 코드 어시스턴트가 없던 시기의 것이에요. 같은 5인팀이 지금 시작한다면 개발·운영 워크플로우가 완전히 달라지는데, 그 기록은 다음 글에서 풀어볼게요.