Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

내가 생각하는 스타트업 미니멀 인프라 스택

팀에서 "내가 생각하는 스타트업 미니멀 인프라 스택"이라는 주제로 공유하는 자리를 가졌다. 기억이 가물가물하긴 한데 인프라 일을 하다 보니 현재 인프라에도 많은 역사를 가진 레거시도 있고 엮인 게 많아서 쉽사리 해결하기 어려운 부분도 있고 하다 보니 처음부터 다시 세팅한다면 OO, XX는 꼭 하겠다 하는 부분이 있을까? 하는 얘기를 하다가 "내가 생각하는 스타트업 미니멀 인프라 스택"로 이어졌다.

공유하는 자리를 준비하다 보니 원래 시작과는 좀 다른 부분도 있지만 내가 스타트업에서 처음으로 인프라 세팅을 한다면 어떤 스택으로 구성할까? 하는 고민을 하게 됐고 최근에는 이런 고민을 별로 해본적이 없었다고 하는 생각을 했다. 고민은 계속해보긴 했는데 딱히 잘 생각나지 않아서 발표 안 해야지 하고 있다가 어제 쉬면서 약간 고민을 하긴 했다. 그래도 발표는 못 하겠다 하고 있다가 당일날 좀 준비해서 공유했다.

발표 자료는 그냥 각 스택 스크린숏 찍어서 만든 거라 별로 중요하지 않고 공유해보고 나니 한번 글로 정리해도 재밌겠다고 생각해서 글을 쓰게 되었다. 진짜 스타트업하려고 진지하게 고민한 건 아니고 기술 검토를 다 해본 것도 아니라서 가볍게 생각의 흐름 정도만 봐주면 좋을 것 같다.

어떤 스타트업인가?

스택을 정하려면 스타트업의 성격이 정해져야 한다고 생각했다. 서비스의 성격에 따라 당연히 인프라 스택도 달라질 테니까...

개발자에게 제공하는 SaaS라고 가정했다. 내가 가장 관심 있는 분야이고 창업할 생각은 없지만 혹시라도 하게 되면 개발용 SaaS를 하고 싶다고 항상 생각했다.

대표적으로 Sentry가 있고 오래전부터 내가 생각하는 가장 좋은 스타트업의 형태라고 생각했다. 엔지니어는 기본적으로 서비스의 너무 핵심적인 부분을 외부 서비스에 넘기면 불안해하는 경향이 있다고 생각한다. 장애 때 직접 처리를 못 하고 이메일만 보내고 있는 상황을 원하진 않을테니까... Sentry는 오류를 추적해 준다는 혜택을 개발자에게 주고 있지만 Sentry가 장애 났다고 서비스에 영향을 주진 않는다.(서비스의 오류를 보지 못할 수도 있지만...) Sentry가 장애 난 걸 본 적도 없긴 하지만 장애가 나더라도 대부분 크게 신경 쓰진 않을거라고 생각한다. 그리고 팀 플랜이 월 $26인데 회사 입장에서는 사실 그리 비싼 금액도 아니다.(서비스가 커지면 이 돈으로 안 되지만...)

그 외 요즘 배포 시스템을 만들고 있으니 CI/CD SaaS 같은 게 되려나 같은 생각도 했는데 창업 아이템을 정하는 건 아니니 개발자를 위한 SaaS 정도로 정의했다.

그리고 직원은 엔지니어 3명으로 했다. 직원도 3명이고 엔지니어도 3명이다. 회사가 너무 커지는 걸 원하지도 않고 시작할 때는 3명 정도면 충분할거라고 생각했고 개발자용 서비스를 만드니 엔지니어만 3명 있다고 가정했다. 다른 직군도 필요하겠지만 일단 소규모라고 생각하고 싶었고(돈도 없으니...) 일단 인프라 스택을 정하는 거니 엔지니어만 고려했다.

사용자는 월 500명이라고 가정했다. 월 500이 많은가 적은가는 애매하시면 시작 지점으로는 괜찮은 수라고 생각했다. 플랫폼 서비스나 소셜 네트워크 서비스가 아니기도 했고 개발 SaaS 같은 경우 free trial이나 무료 플랜을 동반해서 처음부터 과금 모델이 있을 가능성이 높다고 생각했고 소수겠지만 일부의 유료 플랜 사용자와 free trial/무료 플랜의 사용자로 500 정도면 좋다고 생각했다.

그리고 스타트업이지만 직접 돈을 벌어서 먹고사는 구조를 생각했다. 이게 될지는 모르겠지만 일단 목표가 그렇다는 거다. 그래서 처음부터 유료 플랜이 있는거고... 안되면 투자받아야겠지만 그게 중요한 건 아니고 아직 돈을 많이 벌진 못하니 비용을 최소화해야 한다는 의미가 된다.

미니멀 인프라 스택은?

Okta

며칠 전 동료가 새로 스타트업할 때 Okta을 쓸 거냐고 물었다. 난 당연히 쓸 거라고 대답했다. Okta는 간단히 말하면 인증 서비스로 보통 회사에서 쓰는 여러 서비스의 SSO로 묶는 역할을 한다. 회사의 주요 서비스인 Google 워크스페이스나 Slack 등은 퇴사하면 HR팀에서 정리 프로세스를 거치지만 그 외 사용하는 서비스가 꽤 많은데 사용자 관리를 다 제각각 하니까 관리도 잘되지 않고 퇴사자가 오랫동안 그대로 남아있거나 권한관리가 안되는 경우가 허다하다. Okta를 쓰면 이런 문제를 해결해준다.

내가 상상한 Okta의 SSO 경험보다는 불편한 구석이 있긴 하지만 보안 측면에서도 많은 부분을 해결해 준다고 생각한다. 그리고 기본 SSO 플랜은 사용자당 $2로 그리 부담될 가격은 아니다. 오히려 회사 규모가 커지면 비용도 커지기 때문에 아예 초기부터 Okta를 사용하면서 사용 경험을 하게 하는 게 좋다고 생각해서 동료의 질문에 당연히 쓰겠다고 했다.

Okta 홈페이지

근데 본격적으로 스택을 고민하다 보니 생각이 바뀌어서 Okta를 안 쓰기로 했다. Okta 자체는 비용이 많이 들지 않지만, 다른 서비스에서 꽤 높은 플랜을 사용해야만 SSO를 사용할 수 있다. SSO를 쓰려는 회사들이 대부분 구매력이 있기 때문에 각 서비스가 SSO 기능을 높은 플랜에 배치해 놓은 것이다. 그래서 Okta를 쓴다고 다 해결되는 게 아니라 Okta를 씀으로 인해서 다른 대부분 서비스의 비용이 많이 증가한다. 이는 감당하기 어려운 비용이라고 생각했고 3명이면 계정 관리를 하기 어려운 수준이 아니기 때문에 그냥 Okta를 사용하지 않기로 했다.

발표 끝나고 그럼 언제쯤 Okta를 도입할 거냐고 했을 때 좀 고민되긴 했지만, 직원이 20명 정도 되면 고려할만하지 않나 생각했다. 정확한 건 아니고 그냥 느낌으로 정한 숫자고 직원 수가 엄청나게 많아지는 스타트업을 꿈꾸는 것은 아니지만 너무 커졌을 때 도입하면 Okta로 통합하는 과정에 드는 수고가 너무 커질 것 같아서 20명 정도면 괜찮겠다 싶었다.

GitHub

GitHub 홈페이지

당연히 GitHub은 사용한다. GitHub은 사용하지 않을 이유가 없다고 생각한다.

GitHub 플랜

위는 플랜인데 초기에는 Free 플랜으로도 충분하다고 생각한다. 이젠 Free 플랜에서도 private 레파지토리를 맘껏 만들 수 있고 협업도 문제없다. GitHub 액션 등에 약간 들겠지만(private 저장소의 Actions는 유료다.) 하루 20개의 잡이 5분씩 돈다고 해도 계산기를 돌려보면 $24 정도이다.

GitHub을 쓰는 만큼 코드 저장소만 쓰지 않고 CI와 배포 파이프라인까지 모두 GitHub Actions로 구축할 생각이다. 이젠 GitHub Actions를 CD로도 쓸 만큼 퀄리티도 좋아졌다고 생각한다. 비용이 얼마나 나올지 모르지만, 사용한 만큼 나오니까 큰 상관은 없다.

DigitalOcean Kubernetes(DOKS)

DigitalOcean 홈페이지

서버는 DigitalOcean에서 제공하는 Kuberenetes 서비스에 올리기로 했다.

서버는 모노리스로 만들 것이고 난 모노리스를 더 선호하기 때문에 서비스가 아무리 커지더라도 모노리스로 더 이상 버틸 수 없을 만큼 버틸 생각이다. 그리고 아까 말한 서비스 규모를 생각하면 트래픽으로 서비스에 문제 될 일은 많지 않기 때문에 어디서 띄우던 큰 상관은 없었고 결국 운영 비용과 관리 비용이 중요하다고 생각했다.

서버를 모노리스로 만들더라도 컨테이너는 꼭 쓰고 싶었다. 로그 관리나 환경 변수 등 애플리케이션을 구성하는 방법에 어느 정도 영향을 미치기 때문에 컨테이너화는 되어 있어야 한다. 중간에 컨테이너화로 바꾸는 건 꽤 노력이 들고 전환하면서 장애가 발생할 수도 있으므로 처음부터 컨테이너화해두고 운영하면 이런 문제를 미리 차단할 수 있을꺼라고 생각했다. 그리고 컨테이너화만 해두면 언젠가 서비스가 커져서 Kubernetes로 가야 할 때 쉽게 전환할 수 있다.

근데 막상 컨테이너로 운영할 곳이 마땅치 않았다. 처음에는 AWS Fargate를 생각했는데 Fargate 경험도 없었고 가격을 봐도 별로 싸게 느껴지지 않았다. 막상 그렇게 생각하니까 AWS에 VPC 세팅하고 하는 것도 너무 귀찮게 느껴졌고 NAT 비용도 신경 쓰이기 시작했다.

그래서 어디서 운영하면 좋을까 고민하다가 DigitalOcean에 도달하게 되었다.

DigitalOcean 가격 계산기

비용 계산기로 대충 계산해 보니 월 $56 정도가 나왔다. 실제 서비스를 운영하면 이것보다는 좀 더 들겠지만, 서비스 규모를 생각하면 스토리지나 트래픽은 문제가 안 될 테고 로드 밸런서 하나에 PostgreSQL을 설정하고 Kubernetes 노드는 2개로 했다. 1 vCPU에 2GiB 메모리라 노드가 넉넉하진 않지만 내가 만들면 Node.js로 만들겠지 생각하고 일단 어느 정도는 돌릴 수 있을거라고 생각했다.

DOKS는 컨트롤 플레인이 무료이고 컨테이너 레지스트리도 제공해 주기 때문에 이 정도 비용이면 괜찮다는 생각이다. 그리고 AWS에 비해서 신경 쓸 것이 훨씬 적다고 생각했고 나중에 서비스 규모가 더 커지면 Kuberentes이기 때문에 이사 가기도 그리 어렵진 않을 것 같았다.

HA를 위해서 서버를 2대는 띄워놓겠지만 모노리스 서버고 1~2년 이상은 구조가 바뀌지 않을 거니 한번 설정하고 CI/CD 파이프라인을 구축하면 바꿀 일은 많지 않을거라고 생각했기에 그냥 처음부터 Kubernetes로 가기로 했다. Service Mesh나 복잡한 구성을 쓸건 아니고 그냥 컨테이너 띄워놓고 셀프 힐링의 혜택 정도를 얻으면서 쓸 생각이다.

또한 이 스타트업이 어떤 서비스를 만들지 모르지만 요즘 이런 서비스의 상당수가 고객의 인프라는 그대로 이용하고 컨트롤 플레인만 서비스로 제공하는 경우가 많아서 서버는 간단하게 유지할 수 있을거라고 생각했다. 예를 들어 에이전트나 파이프라인을 고객의 AWS 계정안에 설치하고 서버는 데이터만 받으면 에이전트나 파이프라인의 서버 운영 비용이나 트래픽은 해당 고객의 AWS에서 과금되므로 컨트롤 플레인을 제공하는 입장에서 비용에 추가할 필요가 없다.

Auth0

Auth0 홈페이지

사용자 인증에는 Auth0을 사용하기로 했다. 사용자 인증은 서비스의 핵심은 아님에도 꼭 필요한 기능이고 회원가입, 로그인뿐 아니라 비밀번호 찾기 등 필요한 페이지와 구현이 많다. 이런데 시간을 쓰기보다는 그냥 Auth0을 가져다 쓰고 핵심 기능에 더 집중하는 게 낫다고 생각했다.

Auth0 플랜

다행히 Auth0는 7,000 사용자까지는 무료 플랜으로 이용할 수 있기 때문에 이 스타트업에서는 한참 동안 무료로 쓸 수 있을거라고 생각한다.

Terraform

고민을 좀 했지만 Terraform Cloud는 쓰기로 했다. DigitalOcean도 당연히 지원하므로 Terraform으로 프로비저닝할 수 있고 Infrastructure as Code로 관리해 두면 무조건 도움이 된다. 여기에 역시 Terraform만한게 없다.

Terraform Cloud 플랜

Terraform Cloud도 5명 사용자까지는 무료이므로 직원이 3명인 이 스타트업에서도 무료로 사용할 수 있다. AWS를 쓰지 않기 때문에 S3 백엔드를 쓸 수 없는데, Terraform Cloud를 쓰면 해결되고 이젠 Cloud에서 제공하는 편의 기능도 꽤 있어서 오히려 좋다고 생각한다.

new relic

서버를 구축했으면 모니터링을 해야한다. 모니터링은 고민을 많이 했는데 지금 업무에서는 서비스 트래픽도 보고 다양하게 볼 게 많지만 이건 인프라가 복잡해서 그렇고 서버 구성이 간단하기 때문에 ping 서비스로 서비스 헬스체크 정도 확인하고 APM과 로그를 볼 수 있으면 모니터링의 큰 문제는 없을거라고 생각한다.

APM은 사실 선택권이 많지 않다. 그래서 고민하다가 요즘 제일 잘나가는 Datadog을 쓰려고 했다. 여기에 다 쌓아두면 편한 점이 많아서 쓰려고 했는데 APM이 호스트당 $31다. 서버를 $12에 쓰고 있는데 $31는 부담되었다.

new relic이 제공하는 기능

그러다 new relic에 도달했다. 요즘은 datadog이 제일 잘하지만, 그전에는 new relic을 많이 썼었고 꽤 좋아하던 서비스이다. 한 2년 만에 보는 건데 그사이에 꽤 달라졌고 원래 가격을 이렇게 파격적으로 제공했나 하는 생각이 들었다.

new relic 플랜

플랜만 보고는 좀 헷갈리긴 하는데 1명의 풀 플랫폼 사용자로 무료로 대부분의 서비스를 쓸 수 있을거라고 생각했고 어차피 데이터 인제스트가 그리 많을 것 같지도 않았다. 엔지니어가 3명이지만 어차피 서로 역할이 어느 정도 나뉘어져 있을 테고 서버 쪽은 내가 담당해서 주로 확인하면 되고 필요하다면 계정을 공유해서 쓰면 되지 않을까 생각했다. 쓰다 보면 추가 과금이 생길 수 있지만 그래도 datadog을 쓰는 것보다는 나을 거로 생각하고 대충 기능을 보니 원하는 기능은 충분해 보였다.

Sentry를 쓸 건지에 대한 질문도 있었는데 일단 안 쓸 것 같다. 이전에는 APM과 Sentry가 담당하는 오류 추적은 다른 영역이었지만 APM도 오류추적 기능을 강화하고 Sentry도 다른 기능을 추가하면서 기능이 꽤 겹치게 되었다고 생각한다. 일단은 new relic만 쓰다가 오류 추적이 좀 부족하다고 느껴지면 Sentry를 도입할 생각이고 여기도 무료 플랜이 있기 때문에 바로 도입해서 쓰면 된다. 그리고 이젠 Sentry에도 한 명의 개발자는 Codecov도 무료로 사용할 수 있다.

Infisical

서버 띄우고 모니터링도 준비되었으니 운영하는 데 큰 문제는 없을 것 같은데 마지막으로 생각난게 시크릿 관리다. 조직이 커지면서 시크릿 관리는 좀처럼 쉽지 않고 보안에 가장 영향을 줌에도 불구하고 잘 관리하기가 쉽지 않다. 여기선 조직 내 업무에 쓰이는 도구보다는 서비스와 관련된 서비스만 고려하고 있어서 당연히 1Password는 사용하겠지만 서버에 연결하기엔 좀 애매하다. 1Password Connect가 있기는 하지만 1Password의 사용방식을 생각하면 서버에 연결해서 사용하기에는 좀 우려되는 부분이 있다.(아직 테스트는 제대로 해보지 못했다.)

Infisical 홈페이지

Infisical는 비교적 최근에 본 서비스이다.(마찬가지로 테스트해 봐야지 하고 아직 못했다.) 서비스에서 사용할 DB 패스워드, API 토큰 등을 관리할 서비스가 있는 게 좋겠다고 생각하고 꼭 이 서비스일지는 모르지만 비슷한 류의 서비스는 포함 시킬꺼라고 생각한다. HashiCorp Vault를 사용하기엔 운영 부담이 있고 HCP Vault는 시간당 $0.03라서 한 달에 $21 이상 나온다.(개발 플랜이라서 그렇고 프로덕션에서 써도 된다는 HCP Standard를 쓰면 시간당 $1.58다.)

Infisical 플랜

다행히 Infisical은 초기 스타트업이 사용할 수 있는 무료 플랜을 제공한다. 이런 도구를 많이 찾아본 건 아니지만 관리가 어려운 시크릿 관리를 쉽게 하기 위한 다양한 기능을 제공하려는 거 같고 시크릿을 복사하지 않고 로컬에서 사용하는 시크릿도 CLI로 관리할 수 있는 게 더 맘에 들었다.(로테이션이나 서버 쪽 연동이 더 궁금하긴 한데 이건 테스트를 해봐야 알 것 같다.)

이런 서비스는 시크릿을 저 서비스에 저장해 두는 걸 믿을 수 있냐가 문제이긴 한데 기본은 할 회사인 거 같고 정 걱정되면 오픈소스로 제공하므로 직접 내부에 설치해서 사용할 수 있으니 크게 문제는 안될것 같다. 초기 스타트업에서는 시크릿을 로테이션 시키는게 몹시 어려운 일은 아니라고 생각하기도 한다.

에필로그

막상 고민하니 정리하긴 했지만, 최근에 막 써보고 싶은 플랫폼이 많지 않다고 하는 생각이 들었다. 어찌 보면 기회가 있을 거 같기도 하고... 개발 플랫폼도 많이 고도화되어서 그런 거 같기도 하고... 뭔가 힙한 느낌으로 최신 서비스를 많이 써보고 싶다는 생각도 들다가 마땅히 잘 생각 안 나기도 하면서 위처럼 정리했다. 본격적으로 고민하니까 많은 생각이 들고 재밌었다.

2023/04/15 01:44 2023/04/15 01:44