스타트업에 복잡한 클라우드 인프라가 정말 필요할까?

 (hadijaveed.me)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 초기 스타트업은 첫날부터 Kubernetes나 자동 확장까지 갖추기보다, 제품을 만들고 product-market fit을 찾는 데 시간을 쓰는 편이 나을 수 있음
  • 20~30개 Lambda 함수와 SQS, CloudWatch에 흩어진 로그는 디버깅·변경·배포를 어렵게 만들었고, 단일 NodeJS 컨테이너나 Flask/FastAPI 앱과 Redis로 단순화할 여지가 있었음
  • EKS 위 7개 마이크로서비스로 CRUD와 비즈니스 로직을 나눈 사례에서는, 기능 개발보다 인프라 운영에 더 많은 시간이 들어감
  • 단일 VM도 EC2, GCP VM, Hetzner, latitude.sh 같은 선택지와 40GB RAM·멀티코어급 서버를 활용하면 초기 서비스에 충분한 컴퓨팅을 제공할 수 있음
  • 단순한 구성이라도 HTTPS, 제한된 SSH/SSM, CI/CD, DNS, DB 백업, 대기 VM, 재해 복구, 보안 규칙, 백업 보존 정책은 갖춰야 실무에 쓸 수 있음

초기 스타트업에 과한 인프라가 생기는 방식

  • Pieter Levels는 여러 micro-SaaS를 단일 서버에서 운영하며 클라우드 인프라 복잡성을 피하고 product-market fit에 집중한 사례로 소개됨
  • 이 방식이 모든 팀에 맞는 답은 아니지만, 배포와 인프라 관리가 복잡함 자체를 위해 복잡해지는 상황을 잘 보여줌
  • MVP 이후의 작은 개발팀은 배포와 데이터베이스 관리에서 어려움을 겪을 수 있으나, 모든 프로젝트가 첫날부터 Kubernetes, 복잡한 분산 시스템, 자동 확장을 필요로 하지는 않음
  • 단순한 인프라는 팀이 좋은 제품을 만들고 시장 적합성을 찾는 데 더 많은 시간을 쓰게 해줌
  • 엔터프라이즈 규모 회사는 컴플라이언스와 대규모 인력이라는 별도 문제가 있지만, 초기 스타트업이 그 복잡성을 그대로 따라 할 필요는 없음

실제 사례: 복잡성이 만든 운영 부담

  • Lambda 과부하

    • 서로 다른 서비스를 위해 20~30개의 Lambda 함수가 존재함
    • SQS와 여러 백그라운드 작업도 Lambda 기반으로 구성됨
    • 로그가 CloudWatch 전반에 흩어져 있어 원인 추적이 어려워짐
    • 디버깅이 고통스럽고 변경이 까다로우며, 모노레포에서도 배포가 복잡해짐
    • 단일 NodeJS 컨테이너나 Python Flask/FastAPI 앱, Redis 기반 백그라운드 작업으로 더 단순하게 만들 수 있었음

  • 마이크로서비스 과잉

    • Kubernetes EKS 위에 7개의 작은 마이크로서비스가 올라가 있었음
    • CRUD와 비즈니스 로직이 별도 서비스로 분리됨
    • Kubernetes는 강력하지만, 해당 팀은 기능 개발보다 인프라에 더 많은 시간을 씀
    • 그 규모에서 그 정도의 서비스 분리가 꼭 필요한지는 의문으로 남음

단일 서버 접근이 현실적인 이유

  • 단일 서버 구성은 현대 VM의 성능을 적극 활용하는 방식임
    • Hetzner, latitude.sh에서 예산 친화적인 강력한 VM을 구할 수 있음
    • GCP VMs, EC2 인스턴스도 합리적인 가격대임
    • 40GB RAM과 여러 코어를 갖춘 서버는 여러 분산 서비스, 여러 Lambda, 여러 ECS task보다 나은 선택일 수 있음
    • 모든 것이 한곳에 모여 있어 운영과 관리가 쉬워짐
    • 수백만 QPS 확장은 실제로 그 시점이 왔을 때 다루면 되고, 그때는 인프라 팀이 있을 가능성이 높음
  • 안정적인 단일 VM 운영에는 기본 운영 장치가 필요함
    • EC2, GCP VM, Hetzner 같은 견고한 머신
    • 웹에는 HTTPS, 배포에는 IP 제한 SSH나 SSM 같은 안전한 접근
    • 무중단 배포를 위한 CI/CD
    • DNS 설정
    • 정기적인 데이터베이스 백업
    • 이중화를 위한 대기 VM
    • 견고한 재해 복구 전략과 테스트된 평균 복구 시간이 필요하며, 백업 VM으로 달성 가능함

Docker Compose와 Docker Compose Anywhere

  • Docker Compose는 로컬 개발에서 여러 서비스를 한 명령으로 관리하기 좋지만, 프로덕션에서는 덜 활용되고 있음
    • Docker Swarm은 deprecated됐다고 언급됨
    • Docker Compose는 업데이트 중 다운타임이 생길 수 있음
    • 프로덕션 배포 가이드가 있으며, 단순성과 프로덕션 준비성 사이의 균형이 필요함
  • Docker Compose Anywhere는 단일 VM 구성을 더 단순하게 만들기 위한 주말 프로젝트임
    • GitHub Actions로 Linux 서버를 원클릭 설정함
    • GitHub Container Registry와 Docker Rollout을 사용해 무중단 지속 배포를 지원함
    • 환경 변수와 시크릿 관리를 제공하며, 보안 개선을 위해 age나 sops를 고려 중임
    • GitHub Actions 기반 자동 Postgres 백업을 제공함
    • 단일 VM에서 여러 앱을 지원함
    • Traefik과 Let’s Encrypt로 SSL을 자동화함
    • Next.js, Go, Python, Node.js 앱 등을 배포할 수 있음

단순해도 빠질 수 없는 보안과 운영 원칙

  • 보안과 데이터 보호는 단순 구성에서도 생략할 수 없음
    • 필요한 포트만 여는 엄격한 방화벽 규칙이 필요함
    • SSH 키를 안전하게 관리하고, AWS에서는 SSM, GCP에서는 CLI를 선호함
    • 보안 강화를 위해 bastion host를 사용할 수 있음
    • 시크릿을 보호하고 WAF나 Cloudflare 사용을 고려함
    • 암호화된 데이터베이스 백업을 S3 또는 동등한 안전한 클라우드 스토리지로 전송함
    • 추가 이중화를 위해 디스크 스냅샷을 정기적으로 생성함
    • 백업과 스냅샷에 대한 보존 정책을 구현함
  • 엔지니어의 우선순위는 설정의 단순성을 지키고 핵심 제품에 집중하는 데 있음
  • Google 엔지니어링이나 대기업 방식을 흉내 내는 복잡한 구성, 새로운 도구에 쉽게 주의가 분산될 수 있음
  • 스타트업이든 아니든 가장 중요한 일은 사용자와 대화하고 product-market fit을 찾는 것임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여러 프로젝트에서 유행 기술 때문에 피땀 흘린 적이 많음
    팀 규모는 작다면서 “무한 확장성”이 필요하다는 이유로 믿기 힘들 정도로 낮은 품질의 결과물을 만들곤 했고, LTS가 뭔지도 제대로 이해 못 하는 미숙한 팀이 Kubernetes가 필요하다고 결정하는 일도 있었음
    지금은 어떤 제공자에서든 원하는 크기의 강화된 VM을 만들고, 그 위에서 Docker 서비스나 Python 백엔드, 정적 파일 서빙을 돌릴 수 있는 간결한 Puppet 코드를 갖고 있음
    Hetzner VM이 2코어든 48코어든 5분 안에 서비스를 만들고, 소스 관리되는 매니페스트로 설정을 통제하며, 커스텀 Naemon 플러그인으로 설정 준수 여부를 감시함
    완전히 재현 가능한 프로세스인데, 스타트업 팀들은 클라우드에서 눈송이 같은 일회성 구성을 만들며 매달 수천 유로를 쓰고도 2017년 DevOps 선구자들이 하던 것보다 못한 결과물을 내고 있음
    이 주제로 The Emperor's New clouds라는 글도 썼음: https://logical.li/blog/emperors-new-clouds/

    • 커리어를 시작했을 때는 보통 Solaris, 나중에는 SuSe나 RedHat이 깔린 베어메탈 서버에서 셸 스크립트로 모든 걸 처리했음
      “Docker나 다른 기술 없이 어떻게 구성을 재현하냐”는 질문을 이해한 적이 없음
      스크립트는 결정적이었고, 의존성 버전은 고정되어 있었고, 설정과 입력 인자와 실행 순서도 동일했으며, 결정적인 계산 장치에서 돌았음
      재현이 안 될 이유가 없었음
    • 이런 불평에는 Kubernetes가 항상 뜬금없이 끼어드는 느낌임
      강화된 VM에 Docker가 있다고 말하는 대신 kubelet이 있다고 하면 되고, 임시방편의 “docker services” 여러 개 대신 아주 적은 비용의 k8s 제어 평면으로 그 VM들을 모두 제어할 수 있음
      그 방식이 왜 더 나은지 모르겠고, 오히려 더 나빠 보임
      나쁜 클라우드 인프라는 AWS가 파는 모든 걸 다 쓰려다가 전체 인프라가 지나치게 높은 추상화 계층에 묶여 다른 플랫폼으로 이전할 수 없게 되는 경우임
      k8s는 그런 것과 전혀 다름
    • 이 구성을 어떻게 모니터링하나? 접근 제어는 어떻게 하나? Hetzner가 아닌 다른 제공자에 배포하려면 어떻게 하나? 로그는 어떻게 보나? 다른 사람들은 어떻게 유지보수하나? 백업, cron 작업, 오프라인 노드, 새 인그레스, 추가 저장소 프로비저닝은 어떻게 처리하나?
      이 중 하나라도 “직접 만든 것”이나 “스크립트 하나 쓰면 됨”으로 답한다면, 바로 그게 k8s가 가치 있는 이유임
    • 진지하게 묻자면, 왜 Docker를 쓰나? 둔한 오버헤드를 그냥 없앨 수 있음
      Python 백엔드라면 VPS에서 빌드 스크립트를 그대로 재현하면 됨: pip install requirements.txt > python main.py > nano /etc/systemd/system/myservice.service > systemd start myservice > 끝
      인스턴스 확장은 이 명령들을 bash 스크립트 build_my_app.sh에 넣으면 되고, 그게 새 Dockerfile 같은 역할을 하며 어떤 서버에도 수십 초 안에 설치 가능함
    • 동의하지만, 내게 클라우드에는 큰 장점이 하나 있음
      IaaS로 쓰면 다른 제공자의 VPS를 포함한 다른 방식보다 프로토타입을 훨씬 빨리 만들 수 있음
      특히 Google Cloud는 잠금 효과가 적고, 놀람 최소화 원칙에도 더 잘 맞음
      다만 프로토타입을 만든 뒤에는 더 싼 곳에서 다시 구축할지 물어봐야 함
      디스크를 거의 무한히 확장할 수 있고 스냅샷도 되는 점은 좋으며, 클라우드는 프로토타입을 프로덕션 부하까지 확장해 실제 필요한 규모를 측정하게 해줄 수 있음
      하지만 Cloud Run, Lambda 같은 “클라우드 마법”에 기대면 배우고 디버깅하는 데 드는 시간이 결국 예전 방식으로 하는 것만큼이나 걸렸음

  • 작은 스타트업에서 거의 이런 식으로 하고 있음
    GPU가 섞인 작업 큐 자동 확장 같은 복잡한 부분은 있지만, 핵심은 단일 VM의 nginx, 웹앱, Postgres, Redis임
    B2B라 트래픽도 거의 없음
    개발자들이 Linux 노트북이나 다른 플랫폼의 Linux VM에서 같은 구성을 그대로 돌릴 수 있고, 데모나 테스트를 위해 원하면 각자 클라우드 VM도 가질 수 있음
    새 시스템 부트스트랩은 SSH 키를 체크인하고 셸 스크립트를 실행하는 정도임
    디버깅이 쉽고, 복잡하거나 비싸지 않으며, 수평 확장이 필요해지기 전까지 꽤 많이 수직 확장할 수 있음
    모두에게 맞지는 않지만 시드 단계 이전에는 완전히 적절하다고 봄

    • 관심 있다면 주요 Git 호스팅 둘 다, 아마 다른 곳도, 사용자명을 이미 등록된 SSH 키로 매핑하는 엔드포인트가 있음: https://github.com/mdaniel.keys https://gitlab.com/mdaniel.keys
      “공개키를 체크인”하는 방식에서 한 단계 간접화한 것이고, 사용자가 Git 변경 없이 자기 키를 교체할 수 있음
      또 원래 설명과는 꽤 벗어나지만, SSH 키 임대는 오프보딩 상황을 훨씬 잘 처리해줘서 정말 좋음: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
      링크를 찾다가 Vault가 일회용 비밀번호도 제공한다고 주장하는 문서도 발견했음 <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
      다만 나는 확고한 “PasswordLogin no” 진영이라, 그쪽은 각자 조심해서 써야 함
    • 나는 이런 구성을 Redis 없이 했음
      Postgres는 뭐든 할 수 있음
    • 이 접근의 단순함이 좋음
      그런 구성에서 VM의 설정과 업데이트는 어떻게 추적하나?

  • 답은 “아니, 그렇지 않다”임
    내 SaaS는 처음엔 단일 서버에서 돌렸고, 제품-시장 적합성을 얻은 뒤에는 여러 서버로 옮겼음
    이들은 Hetzner의 베어메탈 서버이고, 마이크로서비스는 없으며 Kubernetes도 다루지 않지만 분산 데이터베이스는 운영함
    이 베어메탈 서버들은 클라우드 제공자의 가상 머신에 비해 엄청나게 강력함
    몇 년 전 직접 측정도 했음: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
    전체적으로 이 접근은 터무니없을 정도로 효과적임
    Kubernetes 같은 복잡성을 다루지 않아도 되고, 복잡한 시스템에서 필연적으로 생기는 연쇄 장애도 피하며, 개발 시간과 유지보수, 월 서버 비용을 절약함
    흔한 주문은 “그런데 확장은 어떻게 하냐”인데, 아직 확장이 필요할지 모르고, 이런 강력한 컴퓨터와 합리적 설계만 있으면 3~5대 서버로도 아주 멀리 갈 수 있음
    물론 집 벽장에 비즈니스를 돌리자는 뜻은 아님
    서버 관리를 위해 자동화는 여전히 필요하고, 나는 ansible과 terraform을 씀

    • 확장 얘기는 훌륭한 도깨비 방망이임
      소프트웨어가 아주 짧은 시간 안에 엄청 성공할 거라는 낙관을 자극하고, 사람들은 그걸 믿고 싶어 함
    • 답은 “상황에 따라 다르다”임
      글을 읽은 건지 제목만 본 건지 모르겠음
      아래쪽 A few considerations 섹션까지 내려가 보면 웃기 힘들 것임
      그 “몇 가지 고려사항”은 특히 매우 민감한 정보를 저장하거나 전송한다면 상당한 보안 작업 덩어리임
      이런 상황에서 HIPAA 같은 준수 요건은 어떻게 처리하나?
      프로그래머에는 두 종류가 있음
      다 봤다고 생각하는 사람과, 거의 아무것도 못 봤다는 걸 아는 사람임
      그래서 이런 절대적인 단정은 피곤함

  • Kubernetes의 핵심 20%는 디플로이먼트, 파드, 서비스, 블루-그린 배포 처리 방식, 선언적 정의, 네임스페이스 분리 같은 부분이고, 이건 정말 좋음
    이 단순한 기본만 지키고, 관리형 클라우드 Kubernetes 서비스를 쓰며, 상태를 가진 데이터베이스는 클러스터 밖에 두면 좋은 경험이 됨
    문제가 생기는 건 “클라우드 네이티브” 토끼굴로 빨려 들어가 온갖 틈새 오픈소스 시스템, 오퍼레이터, ambassador, 사이드카 패턴 등을 쓰기 시작할 때임
    그런 것들은 서로 독립적이지만 연결되는 여러 기술 팀과 다양한 프로그래밍 언어가 공존하는 환경을 위한 것임

    • 나에게 Kubernetes는 딱 그 정도임
      이런 논의에서 사람들이 서로 다른 두 가지를 말하는 경우가 많다고 느낌
      내게는 Docker Compose보다 나은, 균일한 배포 방식일 뿐임
      제어 평면에는 아주 적은 비용만 내고, 워커는 kubelet이 있는 일반 VM임
      하지만 많은 사람에게 “Kubernetes”는 위의 두 번째 문단을 뜻하는 것 같음
      꼭 그렇게 쓸 필요는 전혀 없음
      k3s 클러스터를 설정해보고 워크로드, 서비스, 인그레스만 배워도 됨
      임시방편 VM과 Docker 구성들을 대체하는 데 필요한 건 그 정도임
    • 여러 회사와 프로젝트에서 일하며 나도 같은 결론에 도달했음
      99%는 docker-compose++ 정도만 필요하거나 원함
      무중단 배포가 기본으로 되고, 복제본 집합이나 다른 복제·분산 메커니즘을 위한 단순한 설정 시스템이 있으면 거의 끝임
      딱 그것만 해주는 무언가가 있으면 좋겠음
      Kubernetes는 짐이 많고, Docker Compose는 중요한 프로덕션 요구사항에는 조금 너무 기본적임
    • 정확히 이거임
      Kubernetes에는 어떤 용도에도 맞게 조절할 수 있는 노브와 다이얼이 백만 개쯤 있지만, 마찬가지로 무시하고 핵심 기능만 써서 단순하게 유지할 수도 있음
      괜찮은 배포, 아주 쉬운 로그와 지표, 좋은 개발자 경험을 금방 갖춘 구성을 만들 수 있음
    • 회사에서 Kubernetes를 쓰고 있다는 걸 알게 됐음
      평판이 워낙 안 좋고 이전에 써본 적도 없어서, 내부 도구용 서버를 세팅해도 되냐고 물었을 때 최악을 각오했음
      실제로는 세팅한 사람이 30분짜리 튜토리얼을 해줬고, 개념 전체를 설명해준 뒤 서버를 배포할 만큼의 정보를 줬으며, 아무 문제 없이 배포했음
      git push로 자동 배포가 되도록 하는 것도 아주 빨리 끝냈음
      내게는 너무 당연한 선택처럼 보였음
      서비스가 문자 그대로 하나뿐인 게 아니라면 훨씬 쓰기 쉬움
      다만 내가 직접 설치하지는 않았으니, 나쁜 평판은 아마 그 부분에서 오는지도 모르겠음

  • 이력서에 k8s가 없으면 누가 새 직장을 얻겠나 :)
    진지하게는, 많은 사람이 대규모 인프라를 배우려고 일부러 어려운 길을 택한다고 봄
    또 흔한 이유는 “고객이 엄청 많아지면 훨씬 쉬워진다”거나 “수요에 따라 동적으로 확장할 수 있다”는 것임
    만드는 사람에게는 다 타당하지만, 창업자나 전문 CTO에게는 그만큼 타당하지 않음

    • 거칠게 들릴 수 있지만, 필요 없는데도 그렇게 하는 건 비전문적인 낭비와 남용임
      어떤 사람들은 잠재 고객의 요구와 일정에는 신경 쓰지 않고, 그럴듯한 헛것을 만들며 돈을 태움
      타이어를 갈러 정비소에 갔더니 정비사가 자기 성장 욕구 때문에 로우라이더 유압 장치와 회전 휠캡을 달고 싶어서 3주가 걸린 것과 비슷함
      최악은 다음 사람에게 본질적으로 모호해진다는 점임
      뭔가가 거기에 있는 이유가 실제로 필요해서인지, 그냥 반짝이는 장식인지 알 수 없음
    • 홈랩 서브레딧의 복잡성 수준만 봐도 됨
      사람들이 흥미 때문에 하는지, 기술을 좋아해서 하는지, 아니면 말한 것처럼 이력서에 k8s를 넣으려고 기술 관료적으로 실력을 올리려는 건지 잘 모르겠음
      나는 “관리하기 고통스러워 보인다”는 생각만 듦
    • 처음 이해한 수준으로 반쯤 말아 올린 k8s 배포들과, 그때 만들어진 안티패턴과 잘못된 방식이 넘치는 난장판을 몇 년 동안 풀어내는 프로젝트를 봤음
      그래서 k8s 인프라는 더 좁은 범위의 진짜 숙련자들, 적어도 멘티들을 이끌 숙련자들이 설계하고 작업하는 편이 낫다고 봄
      그리고 필요 없는 경우, 즉 대부분의 스타트업·소기업·보통 규모 기업은 더 쓰기 쉬운 기존 패러다임을 유지하면 됨
    • 브라질 유니콘 은행 Nubank는 “이게 통한다면 우리가 빠르게 대규모에 도달했기 때문일 것”이라는 식으로 접근했고, 처음부터 그 규모를 지원하는 아키텍처로 시작했음
      그들은 선택에 매우 만족했고, 블로그에 자세히 써왔음
      “고객이 엄청 많아지면 훨씬 쉬워진다”가 실제로 맞아떨어진 경우임
    • 이력서 주도 개발은 알아볼 줄 배워둘 가치가 있음

  • 낡고 자주 피곤한 논쟁이지만, 그래도 내 2센트를 보태겠음
    첫날부터 복잡한 프레임워크를 골라야 하냐면, 팀에 그 경험이 충분하지 않은 한 아마 아님
    다만 내가 반대하는 건, 맞춤 프로세스와 커스텀 도구로 인프라를 관리하는 게 항상 검증된 도구보다 유지보수 노력이 적을 거라는 생각임
    직접 만든 프로세스가 전혀 단순하지 않고 핵심 제품에서 시간을 많이 빼앗는데도 “복잡성”이라는 허수아비를 완고하게 거부하는 태도임
    모두가 바이너리를 VPS에 복사하고 서비스를 재시작하는 단순함을 좋아함
    하지만 곧 설정과 비밀 관리가 필요해지고, 가용성·중복성을 위해 서버가 여러 대가 되면 점진 배포, 부하 분산, 롤백 등이 필요해짐
    스테이징 환경도 원할 것이고, 이 워크플로를 쉽게 복제해야 함
    팀이 커지면 프로덕션 비슷한 환경을 로컬에서 돌릴 수 없다는 점도 드러남
    그렇게 계속 요구사항이 추가됨
    결국 새 요구사항마다 남들이 이미 풀어둔 표준 해법에 기대는 대신 자기만의 특별한 방식으로 해결해야 함
    나중에는 매몰 비용 문제가 됨
    알고 이해하는 커스텀 도구를 버리고, 모르는 “복잡성”으로 옮길 것인가?
    투자할수록 나중에 옮기기 어려워짐
    내 제안은 나중에 표준 도구로 전환하기 쉽게 만드는 관행을 처음부터 따르라는 것임
    즉 1일차부터 컨테이너로 배포하고, 12요소 방법론을 채택하는 식임
    그리고 필요한 기능 때문에 고생하기 시작하면, 늦기보다 일찍 검증된 도구로 전환하는 게 낫다
    미지에 대한 두려움이 근거 없었음을 알 가능성이 크고, 장기적으로 인프라에 쓰는 시간이 줄어들 것임

    • 이 문제를 두고 느끼는 양가감정을 잘 정리한 말임
      내가 고려해본 접근은 첫날부터 표준 도구, 즉 k8s + gitops로 시작하되 여전히 단일 VM에서 돌리는 것임
      어떻게 생각하나?
    • 또 다른 측면은 직접 만든 SDLC 시스템에 이미 익숙한 업계 인력을 채용하는 게 말 그대로 불가능하다는 점임
      반면 이런 “복잡한” 클라우드 시스템을 이해하고 terraform으로 배포·유지보수할 수 있는 “클라우드 엔지니어”는 많이 찾을 수 있음
      바로 투입 가능한 기술 세트임

  • VM, 블록·블롭 저장소, DNS, IdP, 도메인 등록기관
    클라우드에서 내가 편하게 써본 건 이 정도뿐임
    FaaS와 그 친구들로 들어가면 내게는 정말 이상해짐
    프로덕션 환경이 돌아가는 머신을 들여다볼 수 없다는 걸 감당하기 어려움
    클라우드 대시보드로 디버깅하는 경험은 형편없음
    Microsoft의 접근이 실제로 “작동”하는 것에 가장 가깝다고 보지만, 그래도 정말 끔찍하고 다시는 건드리고 싶지 않음
    10년이 지난 뒤에도 내 이상적인 아키텍처는 여전히 단일 VM에서 모놀리식 코드베이스가 로컬 SQLite 인스턴스들과 통신하는 형태임
    NVMe 저장소의 등장이 이 방식에 꽤 큰 힘을 실어줬음
    백업은 블록 저장 장치 스냅샷으로 처리하고, 트랜잭션 내구성은 필요하면 WAL 복제로 처리함
    멍청할 정도로 단순함
    비즈니스와 고객에 집중할 수 있게 해줌
    고객은 이런 것에 전혀 관심 없고, 돈도 내지 않을 것임
    모든 코드와 인프라는 순수한 마이너스 요소라서 가능한 한 적게 가져가야 함

    • VM, 블록·블롭 저장소, DNS, IdP, 도메인 등록기관은 클라우드 서비스를 만드는 가장 비싼 방식임
      사람들이 클라우드가 온프레미스보다 비싸다고 말할 때 종종 이유가 이거임
      VM을 24시간 내내 돌릴 거라면 더 나은 선택지가 있음

  • 마이크로서비스 책에서도 먼저 모놀리스를 만들라고 함
    실제 사용자 반응을 얻기 전에는 시스템을 어떻게 나눠야 할지 알 수 없고, 서비스를 재구성하는 것보다 모놀리스를 쪼개는 편이 더 쉬움
    모놀리스를 영원히 쪼갤 필요가 없을 수도 있음
    Stripe도 결국 Rails 모놀리스에서 일부를 떼어냈지만, 모놀리스는 놀랄 만큼 멀리 감
    Django/Rails 같은 모놀리스보다 디버깅이 쉬워지기는 어려움
    다만 인프라가 어디로 갈지 조금 내다보는 건 도움이 됨
    우리 회사의 초기 버전은 단일 VM에서 Django Docker 컨테이너로 만들었고, 배포는 수동 docker pull; docker stop; docker start였음
    이 구성으로 생각보다 오래 버텼음
    Docker는 의존성 패키징 문제를 피해가는 방법으로 좋음
    초기에는 새 DB 드라이버를 설치했을 때 서버에 필요한 C 헤더 파일이 있는지, Mac과 설정이 다른지 같은 문제가 성가실 수 있음
    우리는 시드 연장 라운드 이후 신뢰성과 확장성이라는 비즈니스 요구 때문에 k8s로 옮겼고, k8s는 시리즈 B까지 잘 버텨줬음
    모든 걸 Docker화해둔 덕분에 전환도 쉬웠지만, 초기 단계에서는 복잡성을 공격적으로 줄였음

    • 맞음
      그리고 프레임워크가 제공하는 기능의 허접한 버전을 다시 만들지 말고 프레임워크를 제대로 써야 함
      이 면에서는 숙련자 한 명이 미숙련자 10명보다 더 나은 성과를 냄
      시간이 지날수록 차이가 누적됨
      사람들이 모놀리스에 질리는 진짜 이유의 절반은 나쁘고 제대로 운영되지 않는 모놀리스 때문이라고 봄
    • 재미있게도 모놀리스 책은 더 작은 서비스들로 나누라고 함
      데이터는 자체 서비스에 저장해야 한다고 말하고, 관계형·전문 검색 같은 다중 패러다임 접근이 필요하면 여러 서비스가 될 수도 있음
      사용자 경험도 자체 서비스를 써야 함
      최소한 그 사이에 또 다른 서비스가 있어야 하고, 보통 Django와 Rails가 여기에 들어감
      선택적으로 인증, 금융 거래 같은 추가 서비스도 필요할 수 있다고 함

  • 한 프로젝트를 약 6년 동안 월 10달러 VPS 하나에서 운영했음
    lowendtalk에서 얻은 영구 할인 덕분에 실제로는 더 적게 냈고, 게임 서버 중심 VPS 제공자였음
    내가 설정을 망쳐서 깨끗한 OS 재설치를 하느라 하루 내내 내려간 한 번과, 제공자가 사전 공지 후 IP 주소를 바꾼 한 번을 제외하면 거의 99.999 수준의 안정성이었음
    VPS 기술은 정말 많이 발전했고 매우 안정적임
    노드 디스크는 RAID 1로 구성되어 있고, 노드 유지보수 때 VM 자체도 다른 머신으로 쉽게 라이브 마이그레이션할 수 있음
    스냅샷도 찍을 수 있음
    나에게 클라우드 인프라는 더 높은 안정성 때문이 아니라, IAM, 비밀 관리, 코드형 인프라 같은 협업과 운영 관리 기능, 또는 HIPAA 같은 데이터센터 준수 이유 때문에 선택할 것 같음

    • 어느 제공자인가? 좋아 보임

  • 상황에 따라 다름
    개인적으로는 클라우드 기반 해법이 시간을 많이 절약해줘서 좋아함
    다만 무엇을 쓸지 매우 선별적으로 고르고, 너무 복잡해서 명백히 역효과인 해법도 있음
    나는 작은 부트스트랩 스타트업을 운영함
    우리에게는 스스로에게 급여를 줄 돈도 부족하고, 나는 부업 컨설팅으로 생계를 유지함
    이렇게 예산과 시간이 제한되어 있으니 무엇을 쓸지 아주 신중해야 함
    그래서 Google Cloud 같은 것을 좋아함
    GCP 청구액은 한 달 수백 유로로 꽤 낮음
    더 싼 제공자로 옮길 수도 있지만, 그 시간 투자를 정당화하기 어렵고, 예전에 쓴 AWS와 비교하면 Google의 UI와 도구도 마음에 듦
    Kubernetes는 쓸 일이 없음
    빈 클러스터를 돌리는 비용만으로도 현재 월 GCP 청구액보다 비쌀 것임
    마이크로서비스 함정에 빠지지 않았기 때문에 필요도 없음
    하지만 Docker는 좋아함
    소프트웨어 배포를 바보처럼 쉽게 만들어줌
    우리 웹사이트는 부하 분산기와 Google CDN을 통해 서빙되는 Google Storage 버킷임
    같은 부하 분산기가 REST 호출을 모놀리스를 실행하는 VM 두 대에 라우팅함
    이 VM들은 관리형 DB, 관리형 Elasticsearch, 관리형 Redis와 통신함
    DB와 Elasticsearch는 비싸지만, 관리형으로 쓰면 시간과 수고가 많이 절약됨
    우리가 가진 건 거의 이게 전부이고, 단순하고 그렇게 비싸지도 않음
    전체를 Hetzner 같은 곳으로 옮기면 비용을 50%쯤 줄일 수 있을 것임
    해볼 만할 수는 있지만 내게 아주 급한 일은 아님
    그 관리형 서비스를 잃으면 내 삶이 더 어려워짐
    일부 고객이 AWS를 선호하는 것 같아서 언젠가는 AWS로 돌아가야 할 수도 있고, 그런 점도 있음

답변달기