하나의 큰 서버를 사용하라 (2022)

• 논쟁의 본질은 모놀리식 vs 마이크로서비스가 아니라 분산 시스템이 개발/운영 오버헤드 대비 가치가 있는가에 대한 판단임
• 현대의 단일 서버는 수십~수백 코어, TB급 메모리, 수십~수백 Gbps I/O로 대부분의 웹 서비스를 감당할 충분한 성능 여력을 가짐
• 실제 벤치마크는 한 대의 서버로 Nginx 50만 RPS, PostgreSQL 7만 IOPS, NoSQL 100만 IOPS, 4K 인코딩 75 FPS 등 고성능 처리가 가능함
• 클라우드를 사용하면 편의성과 가용성이 높지만, 비용 프리미엄이 상당하여 투자 대비 효율을 따져야 함
• 활용 패턴이 극도로 변동적인 경우만 클라우드 네이티브, 서버리스 아키텍처가 비용적으로 이점이 발생
• 하지만 서버리스/미세 VM 구성의 비용 프리미엄이 크며 작업 부하가 지속적/예측 가능하다면 수직 확장이 경제적
• 가용성은 주/보조(또는 2×2) 이중화와 상이한 하드웨어 조합으로 상당 부분 해결 가능하며, CDN·백업만 분산으로 사는 전략이 합리적임

---

개요: 분산 시스템보다 “큰 서버 한 대”의 가치

• “모놀리식 vs. 마이크로서비스” 논쟁의 핵심은 분산 시스템 도입의 실제적인 개발자 시간 및 비용 소모 가치에 대한 판단
• 현대 소프트웨어는 서버의 가상화와 다양한 추상화 레이어 위에서 동작하며, “서버리스”나 “베어메탈”도 결국 물리 서버 자원 위에 구축됨
• 오늘날의 서버는 우리가 생각하는 것 이상으로 성능 대비 비용 효율이 높음
  • 과거 대비 서버 스펙이 코어 수·메모리 대역폭·PCIe 레인·NVMe 스토리지 측면에서 비약적으로 상승했으며, 많은 서비스가 분산 없이도 목표 QPS를 달성 가능함

서버 하드웨어의 강력한 성능

• Microsoft Azure의 예시 서버는 AMD 3세대 서버 CPU 2개, 총 128코어 256쓰레드 구성을 가짐
• 단일 서버에서 4 TFLOPs 수준의 연산 성능 실현, 지난 2000년대 초반 슈퍼컴퓨터 성능 능가
• 16슬롯 DDR4-3200 RAM 소켓당 배치로 최대 8TB 메모리 확장성 확보, 실용적 구입선에서도 1TB 메모리 지원됨
• 총 128개의 PCIe Gen4 레인, 30개 NVMe SSD와 50~100Gbps 네트워크 카드로 고성능 저장소 및 네트워크 연결 가능

이런 단일 서버로 가능한 일들 (벤치마크 인용)

• 400–800 Gbps 비디오 전송, NoSQL 100만 IOPS, PostgreSQL 7만 IOPS, Nginx 50만 RPS 달성 가능
• Linux 커널 20초 빌드, x264 4K 75FPS 인코딩 등 CPU·메모리·I/O 집약 작업에서도 높은 처리량을 보임

서버 임대·구매 비용 비교

• OVHCloud: 128 코어/512GB RAM 서버가 월 약 $1,318에 렌트 가능
• Hetzner: 32코어/128GB RAM 서버를 월 €140에 제공하며, 사이즈에 따라 가격대가 달라짐
• AWS의 m6a.metal: 96 물리코어/768GB RAM 서버가 시간당 $8.29, 월 약 $6,055로 클라우드 프리미엄이 큼
• Dell에서 유사 사양 서버 직접 구입 시 약 $40,000, 약 8개월 내에 클라우드 대비 투자금 회수 가능
• 서버리스로 동일 처리량을 가정하면 인스턴스 대비 5.5배, 저가 호스팅 대비 25배 비용 프리미엄 추정

왜 분산 시스템이 각광받았나

• 과거(2010년 전후) CPU·메모리·저장장치 성능 한계로 대용량 서비스는 여러 서버 조합이 필요했음
• 최근 대형 단일 서버·NVMe SSD·높은 메모리 대역폭으로 단일 노드 처리 한계가 크게 향상됐지만, VM 및 컨테이너 단위는 여전히 소규모 서버 자원을 기준으로 설계됨

하나의 큰 서버만으로 충분한 경우

• 10k QPS 이하 대부분의 웹 서비스는 한 대로 충분하며, 단순 서비스는 백만 QPS급까지 가능
• 비디오 스트리밍조차 컨트롤 플레인은 단일 서버가 현실적이며, 벤치마크·공통 성능 테이블로 적정 서버 크기 산정 가능함
• 특수 상황 외에는 주 서버와 백업 서버 구성만으로 가용성 보장도 충분

“넓게”보다 “높게”: 대량 서버군보다는 소수의 대형 서버 선호

• 클러스터가 필요해도 큰 서버 몇 대가 작은 서버 다수보다 조정 오버헤드(O(n)) 가 낮음
  • 즉, 장기적으론 서버 수를 줄이고 사양을 키우는 편이 효율적임
• 서버리스, 단명 컨테이너 기반에서는 오버헤드 비율이 특히 커짐
• 단점은 단일 장애점이지만 주/보조(서로 다른 DC) 만으로도 상당 부분 해소 가능함
• 더 견고하게는 2×2 구성(주 DC 2대 + 보조 DC 2대) 과 서로 다른 하드웨어/제조 배치로 상관 고장을 회피
• 렌탈 시 서버 모델 다양화로 동일 배치 디스크·SSD의 연쇄 고장 리스크를 줄일 수 있음

클라우드 사용의 장점과 한계

• 클라우드는 가용성·복구 속도·운영 편의가 강점이며 프리미엄 비용을 지불할 가치는 있음
  • 다운되는 일 없이 비용 내에서 신속한 재구동 가능, 그리드로 관리되는 대규모 자원 풀 활용 가능
  • 임대형 서버 제공자는 가격은 저렴하나 품질·네트워크·프리미엄 지원 등에서 한계가 있음
• 다만 클라우드 영업은 오토스케일 VM, 서버리스, 매니지드 HA DB 등 벤더 종속형 아키텍처를 권장하므로 비용·복잡도를 경계할 필요 있음
• 대규모 트래픽 처리 그 자체는 클라우드 네이티브의 주된 이유가 아니며, 단일 대형 서버로도 수백만 사용자 동시 제공이 가능한 사례가 많음

피크 부하 비용과 버스티 부하 기준

• 누군가는 피크에 맞춰 용량을 준비하므로, 결국 피크 비용은 공급망 어딘가에서 청구됨
• 버스티·일시적 작업(예: 단발성 대규모 시뮬레이션)은 서버리스/오토스케일이 경제적이지만, 지속적·예측 가능 부하는 큰 서버 고정 운영이 비용 효율적임
• 1년 약정/스팟/세일즈 협상을 활용하면 인스턴스 비용은 더 낮아지고, 서버리스 대비 프리미엄은 더 커짐

“클라우드 프리미엄”의 정량적 평가

• AWS lambda 등 서버리스 컴퓨팅은 동일 서버 대비 5~30배 비용 프리미엄 발생 가능
• 가정: $8.2944/시간 서버가 1k QPS, 768GB RAM 제공 시, 동일 처리량을 Lambda로 대체하면 약 $46/시간으로 5.5배 프리미엄
• OVH 렌탈 대비 25배 프리미엄 추정, 5% 이용률만 확보해도 저가 호스팅이 서버리스보다 경제적
  • 장기 계약, 스팟 인스턴스 등 활용 시 프리미엄 차는 더 커질 수 있음
• QPS가 달라도 메모리-시간 환산으로 프리미엄 배수는 유사하며, 워크로드 크기에 맞춰 서버 스케일링이 핵심임

흔한 반론과 오해

• “클라우드면 시스템 운영 인력 불필요”: 역할명만 Cloud Ops로 바뀌었을 뿐이며, 문서·변경 추적·디프리케이션 대응 역량이 필요해 인건비 상승 요인임
• “클라우드는 보안 업데이트 안 해도 됨”: 일부는 면제되나 자동화 쉬운 영역에 국한되며, 라이브러리 감사·구성 검증은 여전히 필요함
• “클라우드는 고가용성 설계로 안심”: 복잡성 증가가 새로운 취약성을 만들고, 리전·프로바이더 이중화도 상관 장애를 완전히 제거하지 못함
• “클라우드는 개발 속도가 빠름”: 초기 민첩성은 장점이므로 사용하되, 비용 변곡점을 모니터링해 적기 전환이 필요함
• “우리 트래픽은 매우 버스티함”: 이 경우 서버리스·오토스케일이 적합함
• “CDN은?”: 지연·대역폭 절감은 필수 분산 구매 대상이며, 백업도 마찬가지로 사서 쓰는 영역임

모놀리식 vs. 마이크로서비스와 서버 구조

• "큰 서버"는 곧 모놀리식 아키텍처와 연결되나, 한 대 서버에서 여러 컨테이너 형태로 마이크로서비스 구성도 가능
  • 하지만 프로세스 간 통신·배포·관측 오버헤드가 단일 호스트에서도 부담으로 작용하여, 복잡성 대비 실질 성능 이익은 크게 줄어드는 구조
• 초기·중소 규모에는 모놀리식 또는 소수 서비스가 운영 단순성 측면에서 유리함

결론

• 대부분의 경우, 수평 확장이나 클라우드 중심 아키텍처보다는 수직 확장(한 대의 큰 서버) 선택이 더 단순하고 경제적임
• 주/보조 이중화·이기종 하드웨어·CDN/백업 외부화를 결합하면 실무적 신뢰성을 확보 가능하며, 지속적 부하 환경에서 총소유비용(TCO) 우위가 큼
• 견고한 하드웨어 중복 전략만 확보하면, “한 대의 큰 서버” 방식이 실제 서비스에 매우 적합한 선택임

[GN⁺]

Hacker News 의견

• 클라우드 요금(Cloud Tax)의 가장 큰 문제점 중 하나는, 엔지니어들이 고민할 수 있는 솔루션의 범위 자체를 인위적으로 제한하게 되는 점임. 예를 들어, $200/월 정도를 AWS에 지불하면 4 vCPU와 16GB RAM 서버를 얻을 수 있는데, 이 정도면 5년 전 개발용 노트북 정도 스펙임. 반면 Hetzner에선 동일한 비용으로 48코어, 128GB RAM 서버를 빌릴 수 있음. 연산 성능 격차가 어마어마함. 10배 더 큰 용량이 있으면 충분히 효과적인 방법론도, 작은 노드에선 의미가 없어짐. 이런 조건들은 때로는 더 복잡한 시스템을 만드는 엔지니어링 시간을 아끼는 방안이기도 함. 물론 내구성 등 다른 고려도 필요하지만, 반대로 전용 서버는 noisy neighbor 걱정 없이 일관된 성능을 보장해줌
  • 2025년에는 편의성과 복잡한 절차 없이 fly.io 같은 서비스를 일반 목적에 쓸 수 있게 됨, 특정 프레임워크엔 Vercel 같은 선택지도 있음(특정 스택에 특화된 좋은 옵션). 그 이상이 필요하다면 OVH/Hetzner/Latitude에서 실제 괴물급 머신을 저렴하게 렌트 가능함. 단지 블로그 운용 정도라면 VPS가 정말 많음. 전통적 클라우드는 이제 규제나 사내 프로세스, 비효율을 위한 용도밖에 안 쓰임. 개발 생산성도 기계 단가도 제로라는 생각임. 정말로 아무 제약이 없는 팀이 DMV식 인가 시스템, 시끄러운 인텔 노드, 비싼 마진, 형편없는 지원을 좋아하지 않는 이상, 대부분 의미 없음
  • 이건 그 이상임—베어메탈 서버를 쓰면 네트워크 지연(latency), VM의 메모리 대역폭 지연/경합, 별도의 캐싱 구조 등 필요 없고, 예를 들어 Postgres에 RAM을 왕창 부여하고 리눅스 디스크 캐싱만 써도 됨. 훨씬 단순하게 빠름
  • 왜 소소한 서비스에도 다짜고짜 AWS를 써야 하는지 이해가 안 됨. 나는 당신처럼 복잡한 수준은 아니지만, 클라이언트가 소규모 PHP 웹앱+AWS 서버/SQS/S3 조합을 $100/월에 사용 중이었음. 이걸 Python/Django/PostgreSQL(최초엔 SQLite)로 구현해서 $25/월 VPS로 옮겼음. PDF OCR, 가격 업데이트, 누락 제품 찾기, 사이트 서비스 등 전부 4코어 6GB RAM으로 잘 돌고 있음. 사용자가 100명을 훨씬 넘길 일 없는 내재용 앱이라, 언젠가 커져도 마이그레이션이 매우 쉬움. 지금 수준으론 AWS $100서버 쓸 이유가 없음, 진짜 대규모로 확장 전까진
  • 완전 동의함. sqlite 같은 내장 데이터베이스를 쓰고, 쓰기(batch)를 최적화하면 Hetzner로도 엄청나게 멀리 갈 수 있음. "과도한 용량 예약해서 낭비" 주장은 AWS만 벗어나면 말이 안 됨(가성비가 넘사벽). 오히려 시스템 복잡할수록 단일 노드보다 오히려 신뢰성과 복원력이 떨어지는 경우도 많음. 뭔가 하나만 고립되어 망가지는 일이 거의 없음
  • 내 생각은 오히려 반대임. Hetzner를 소규모 사이트에 아주 좋아하지만, 대형 프로젝트에선 클라우드가 사실상 제약이 없는 느낌임. 내 시간이 값어치 있을 정도의 프로젝트면, 호스팅 비용이 $200이나 $2000이나 무의미함. AWS CDK/Terraform+GitHub Actions와 Docker/K8s/Ansible+CI 파이프라인 개발 시간 차이도 딱히 모르겠음. bare metal 방식이 훨씬 엔지니어링 시간을 세이브해준다고는 못 느꼈음. Fargate+RDS 같은 IaC도 편함. 만약 진짜로 파일 스토리지를 분리, 확장, 내구성 필요하거나, 서브도메인 동적 생성 등 각종 인프라 계층 데디케이티드 서비스 여러 개를 통합해야 한다면, 오히려 새로운 서비스 학습·통합 부담이 훨씬 큼. 실은 클라우드 이전 시대부터 이런 일 해왔고, 수익형 프로젝트면 클라우드 비용은 투자의 가치가 있다고 봄. 비용이 너무 부담스러운 프로젝트라면 그냥 비즈니스보단 취미 임. RAID나 여러 클러스터 파일 시스템 관리하는거, 웬만한 스타트업/회사 자원이나 내 시간으론 하고 싶지 않음. Arch+Emacs 만지는 거 좋아하는 취향 vs 맥북에 만족하는 취향처럼 느껴짐. 커널 스케줄러 바꾸고 싶으면 Arch 쓰라고 하겠지만, 아니면 맥북 추천함. 한편, 진짜 예산이 없다면 raw throughput이 중요한 경우엔 데디 서버가 딱이긴 했던 경험도 있음(수천불 아낌). 만약 성공했다면 그때부터 버티컬 스케일 했을 것 같고, 이건 드문 케이스임
• HN(해커뉴스)은 실서비스용 서버와 백업 서버, 이렇게 2대를 운영 중임. 하드웨어 이슈나 업그레이드 필요하면 즉시 페일오버 가능해서 유용한 패턴임. 단, 서버가 완전 동일 클론이면 둘 다 동시에 터질 수 있으니 주의해야함
  • SSD처럼 치명적이진 않지만, AMD CPU에도 재밌는 에러가 있었음. 1044일 정도 지나면 특정 코어가 완전히 멈추는 이슈였음 AMD EPYC Rome CPU Hang 사례
  • HN(해커뉴스) 다운타임 관련 통계 있는지 궁금함. 지난 10년 간 한두 번 다운된 것만 기억나고, 체감상 99.99% 이상 업타임으로 보임
• 나는 10년 넘게 하이브리드 콜로+퍼블릭 클라우드를 써왔고, 일정 규모부터는 항상 비용 최적화에 최고였음. 하드웨어 효율도 계속 좋아지고 있음. 네트워크/인프라 관리자가 필요하지만, 사실 요즘은 관리가 매우 쉽고 오히려 "클라우드" 관리자도 기본적으로 필요해서 인건비 절감 효과는 거의 없음. 콜로케이션 옵션은 다양하고, 공급자들이 대역폭을 묶어서 팜. 한때 8개 dell vrtx 클러스터, SAN, 500+ VM(대형 msSQL부터 kube까지) 돌렸는데, 퍼블릭 클라우드였으면 예약 할인까지 해도 청구서가 6자리(만 달러 단위) 넘을 상황이었음. 그런데 콜로 비용은 $2,400/월(power 중심)이었음. 퍼블릭 클라우드 노드의 현저한 속도 저하도 항상 놀라움(똑같은 CPU/VCPU 세대여도). 기기 딜, 업데이트, 라이선스, 지원계약 파악은 잘 해야하지만 현실적으로 충분히 관리 가능함. 그리고 이제는 클라우드와 네트워킹도 쉽게 연결 가능해서 fiber drop 받아서 vpc랑 연결하면 끝임
  • 콜로케이션은 내 하드웨어 구입해서, 데이터센터에 전력/랙/회선만 임대하는 걸로 이해하는데, 진짜로 그런지 궁금함. 일반 bare metal 서버 렌탈보다 어떤 점이 좋은지 알고 싶음
• 친구들과 몇 년째 이 주제 논의 중임. 로컬 인프라의 가장 큰 단점은, 이걸 제대로 운영할 전문 인력이 필요하다는 점임. 이 글은 상위 규모에 집중했지만, 하위 시장은 이미 장비 좀 있다면 소규모 랙이나 네트워킹으로 1년 만에 손익분기점이 됨. 요즘 클라우드 프리미엄을 감안하면, 관리자 한 명 고용해도 로컬 인프라가 더 경제적일 듯함
• 내가 창업에 참여했던 기업에서는 엔터프라이즈 자동화 엔진 만들었는데, 팀에서는 솔루션을 SaaS로 배포해서 매출 극대화하고 싶어했음. 사실 multi-tenant DB 스키마+VPS로도 충분했지만, 팀이 kubernetes 학습과 클라우드 네이티브 스택에 골몰, 1년간 개발환경/운영 자동화에 전념함. 결국 회사는 얼마 못 가서 망함
  • 하지만 엔지니어들은 그 경험으로 k8s 이력 생겨서 새로운 취업길을 또 찾을 수 있었음
  • 나 역시 비슷한 경험임—5년 뒤에 필요할지 모를 문제를 미리 해결하느라 너무 많은 시간 삽질함. 대부분 프로젝트랑 초기 스타트업은 그냥 PaaS나 nginx+docker 컨테이너 정도면 충분함. 어느 순간 진짜 아픔(pain point)이 오면 그때 고민하면 됨
  • 그래서 나는 '청구서가 진짜 아플 때'까지는 그냥 PaaS 좋아함. heroku/render/fly 비용 내면서 PMF(Product-Market Fit)에 집중. 아니면 서버 재미로 K8s에 투자하며 VC 돈 태우다가, 다음 직장으로 반복 이직하는 루트도 존재함
• 많은 비즈니스가 그만큼 중요하지도 않음. 운영 중단됐다고 어쩌겠냐고 스트레스 많이들 받는데, 사실 그들이 다루는 서비스는 엄청나게 중요한 게 아님. 한낮에 프로덕션 환경이 날아가도, 좀 귀찮겠지만 세상 안 망함. 이런 기업들은 단순 오피스 서버로 250명 거뜬히 쓰던 걸, 굳이 클라우드로 바꾸다 예산만 폭증함. 클라우드는 특정 작업엔 탁월하지만, 나머진 마케팅 과장에 가까움. 다만 많은 엔지니어들이 '완벽한 확장성'에 집착, 적당히 좋은 솔루션 대신 이상적인 아키텍처만 찾는 경향이 있음
  • 내가 예전 같이 일한 팀원 한 명은 일하면서 늘 이렇게 얘기하곤 했음. "적어도 우리가 실수한다고 누구 죽는 일은 없으니까, 너무 걱정할 필요 없다"는 마인드였음. 훨씬 더 책임감 큰 일을 했던 경험이 있던 분이라서, 어려운 상황에서도 그 마인드에 큰 도움이 되었음
• 100% 가동시간 달성 목표로 복잡한 구조를 만들다 보면, 오히려 신뢰성이 떨어지는 실수를 자주함. 대부분 비즈니스는 가끔 1~2시간 다운이나 데이터 유실도 사실 감내할 수 있음. 이런 기대치만 먼저 주지시키면, 훨씬 단순하고 신뢰성 높은 구조로 엔지니어링 할 수 있음
  • 비용도 훨씬 저렴함. 다만 이런 기대치는 엔지니어 말고, 비기술 경영진은 수용 못하는 경우가 많음(특히 데이터 유실은 거의 용납 안 함). 엔지니어는 환경만 관리한다지만 현실에선 그러기가 쉽지 않고, 실수하면 무능해 보일 수 있음
• 상당히 좋은 아티클임. 이 방식(비클라우드)으로 확장할 때는 CDN 추가도 고민할 만함. CDN 쓰면 WAF와 DNS 페일오버 효과도 있음. 다만 비클라우드 방식이면 직접 DB 운영해야 하는 점이 조금 아쉬움. 그래서 클라우드 DB도 옵션으로 주는 공급자를 고려하거나, 액티브/패시브 구조라면 패시브 노드를 클라우드 VM+오토스케일로 더 저렴하게 운영하는 것도 답임. 요즘 서버임대 가격 정말 저렴해서 4GB VPS도 $6 정도, 32GB 쿼드코어 베어메탈도 $90선. serversearcher.com 같이 가격 비교 사이트 쓰면 유용함
  • Postgres를 도커 컨테이너에 올리고, 정기적으로 백업만 돌려도 별문제 없었음. 운영도 간단해서 불편할 게 딱히 없음
  • 단일 머신에선 Postgres/MySQL보다 sqlite로 훨씬 높은 성능, 쉬운 관리 가능함
• 나 역시 VPS에서 서비스 돌림. 클라우드는 이미 오래전에 버렸음. 내 프로젝트가 돈 벌기 시작하면, 기기 사서 콜로 넣을 계획임. 클라우드는 데이트앱 같은 느낌이었는데, 이제 재미는 끝났고, 진짜 뭔가 생산적인 걸 하고 싶어짐
  • 콜로 자체도 문제로 가득 차 있음. 데이터센터 전력 장애 등으로 하드웨어 죽는 건 정말 흔함. 역설적으로 내 집 전기가 더 안정적. 수 분짜리 다운타임이 매출 수백만에 영향 줄 사업 아니라면, 대부분은 지하실에서 서버 돌려도 별 문제 없음. 많은 사람들이 99.999% uptime이나 대역폭 필요성 엄청 과대평가함. 콜로가 생각만큼 싸지도 않음. 데이터센터 전기요금이 일반/비즈니스, 주거용 전기요금보다 비싼 경우도 많음. 진짜 저렴한 건 인터넷/광선로 뿐이고, 요즘은 5~10Gbit 비즈니스용도 100유로에 가능해진 나라가 많음(예전엔 1Gbit만 해도 2천 유로 이상 부름)
• 비용이나 용량 분석을 떠나서, 업계 트렌드 자체를 거스르는 게 쉽지 않음. '하드웨어를 아예 신경쓰지 않는' 이점이 진짜 존재함. 게다가 capex(자본지출)는 무조건 피해야 한다는 사고도 강하게 존재(서버 하드웨어는 선투자 비용 큼). 그리고 AWS 리전이 장애나도 '우리 책임' 같지 않지만, 사내 서버 나가면 '우리 책임'처럼 보이는 매커니즘도 있음
  • capex(자본지출)를 극단적으로 꺼리는 건 거의 VC 투자 구조 영향임—투자자들이 고속 성장만 요구하면 선투자(서버구입)는 논리상 정당화 불가임. 반면, 안정적 비즈니스는 매년 소규모 capex를 무난하게 소화 가능함
  • 서버 하드웨어를 반드시 사야하는 건 아님—Hetzner 같은 곳에서 임대도 충분함. '하드웨어 신경쓰지 않아도 되는' 이점은 구체적으로 어떤 것인지 더 설명 듣고 싶음
  • capex 아끼려는 사고방식은 실제로 존재함. 계산기만 쓸 줄 알아도 요즘은 서버값이 전체 비즈니스에 큰 의미 없는 수준임. 정작 비싼 건 서버 주위의 그 '공간'이므로, 대부분은 서버가 아니라 공간(랙/전력)을 빌리는 것임
  • 기업이 진짜로 돈을 내는 건 결과적으로 '책임의 추상화(abstraction of responsibility)'임. 대기업 중역들은 MS, AWS처럼 대기업 솔루션을 택하면 안심함
  • 베어메탈 서버 렌탈하면, capex나 유지보수 걱정할 필요 없음