# 클라우드를 임대하지 말고, 직접 소유하세요 > Clean Markdown view of GeekNews topic #26441. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26441](https://news.hada.io/topic?id=26441) - GeekNews Markdown: [https://news.hada.io/topic/26441.md](https://news.hada.io/topic/26441.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-06T09:40:46+09:00 - Updated: 2026-02-06T09:40:46+09:00 - Original source: [blog.comma.ai](https://blog.comma.ai/datacenter/) - Points: 11 - Comments: 3 ## Summary 클라우드 대신 **직접 데이터센터를 운영**하는 CommaAI는 약 500만 달러 규모의 인프라로 자율주행 모델 학습을 완전 자동화하고 있습니다. 클라우드의 비용 상승과 공급자 종속을 피하면서, 실제 전력·연산·대역폭 문제를 다루는 과정이 엔지니어링 품질을 끌어올린다는 점을 강조합니다. 약 600개의 GPU와 4PB SSD로 구성된 이 시스템은 **클라우드 대비 5배 저렴한 비용**으로 동일한 학습 성능을 달성하며, 기술 자립형 ML 인프라의 현실적 대안을 보여줍니다. ## Topic Body - **CommaAI**는 모든 모델 학습과 데이터 처리를 자체 **데이터센터**에서 수행하며, 약 **500만 달러 규모의 인프라**를 직접 운영중 - 클라우드 의존은 **비용 상승과 통제력 상실**로 이어질 수 있으며, 자체 컴퓨트 운영은 **엔지니어링 품질 향상**과 **비용 절감**을 가능하게 함 - 데이터센터는 약 **450kW 전력**, **600개의 GPU**, **4PB SSD 스토리지**, **간단한 냉각 및 네트워크 구조**로 구성되며, - 소프트웨어 스택은 **Ubuntu + Salt**, **minikeyvalue(mkv)** 스토리지, **Slurm** 스케줄러, **PyTorch 분산 학습**, **miniray** 분산 컴퓨트로 설계됨 - comma.ai는 이 구조를 통해 **자율주행 모델 학습을 완전 자동화**하며, 클라우드 대비 약 **5배의 비용 절감 효과**를 달성 --- ### 자체 데이터센터 운영의 이유 - 클라우드에 의존하면 **비용 증가와 공급자 종속**이 발생 - 클라우드 기업은 온보딩은 쉽지만 오프보딩은 어렵게 설계되어 있음 - 지속적 사용 시 높은 비용 구조에 갇히기 쉬움 - 자체 컴퓨트 운영은 **기술 자립성과 효율적 엔지니어링 문화**를 촉진 - 클라우드는 API·결제 시스템 중심의 관리가 필요하지만, 데이터센터는 **전력·연산·대역폭** 중심의 실제 기술 문제 해결을 요구 - ML 엔지니어링 측면에서도 **자원 제약이 코드 최적화와 근본적 개선을 유도** - 클라우드에서는 단순히 예산을 늘려 해결하지만, 자체 인프라에서는 **성능 개선이 필수** - 비용 측면에서 comma.ai는 약 **500만 달러를 투자**, 동일 작업을 클라우드에서 수행 시 **2,500만 달러 이상**이 필요했을 것으로 계산 ### 데이터센터 구성 요소 - ## 전력 - 최대 **450kW** 사용, 2025년 전력비 **540,112달러** - 샌디에이고 전력 단가가 **40센트/kWh**로 세계 평균의 3배 수준 - 향후 **자체 전력 생산 계획** 언급 - ## 냉각 - **외기 냉각 방식** 사용, CRAC 시스템보다 전력 효율적 - **48인치 흡기·배기 팬** 각 2개로 공기 순환 - **PID 제어 루프**로 온도·습도 자동 조절 (<45% 유지) - 전력 사용량은 수십 kW 수준 - ## 서버 및 스토리지 - **TinyBox Pro** 75대(총 600 GPU)로 구성, 자체 제작 - 각 장비는 **2 CPU + 8 GPU**, 학습 및 일반 연산용으로 사용 - 자체 제작으로 **유지보수 용이** - 스토리지는 **Dell R630/R730** 기반, 총 **4PB SSD** - **비중복(non-redundant)** 구조, 노드당 **20Gbps 읽기 속도** - 네트워크는 **100Gbps Z9264F 스위치 3대**, **Infiniband 스위치 2대**로 구성 ### 소프트웨어 인프라 - ## 기본 설정 - 모든 서버는 **Ubuntu + PXE 부팅**, **Salt**로 관리 - 단일 마스터 구조로 **99% 가동률** 유지 - ## 분산 스토리지 — **minikeyvalue (mkv)** - **3PB 비중복 스토리지**에 학습용 주행 데이터 저장 - **1TB/s 읽기 속도**, 캐싱 없이 직접 학습 가능 - **300TB 캐시용 배열**, **중복 저장 배열**에는 모델 및 메트릭 저장 - 각 배열은 **단일 마스터 서버**로 관리 - ## 작업 관리 — **Slurm** - **PyTorch 학습 작업**과 **miniray 분산 작업**을 스케줄링 - ## 분산 학습 — **PyTorch + FSDP** - **Infiniband 네트워크**로 연결된 두 개의 학습 파티션 운영 - 자체 학습 프레임워크로 **훈련 루프 자동화** - **모델 실험 추적 서비스** 제공 - **대시보드**, **커스텀 메트릭**, **모델 가중치 관리** 기능 포함 - [최신 모델 메트릭은 공개되어 있음](https://commaai.github.io/model_reports/) - ## 분산 컴퓨트 — **miniray** - **경량 오픈소스 태스크 스케줄러**, 유휴 머신에서 **Python 코드 실행** - **Dask보다 단순**, **Redis 중앙 서버**로 태스크 관리 - GPU 워커는 **Triton Inference Server**로 모델 추론 수행 - **수백 대 머신 병렬 확장** 가능 - 예: **Controls Challenge 기록**은 데이터센터 1시간 사용으로 달성 - ## 코드 관리 — **NFS 기반 모노레포** - 전체 코드베이스 **3GB 이하**, 모든 워크스테이션에 복제 - 작업 시작 시 **로컬 코드와 패키지 동기화**, **2초 내 완료** - 모든 분산 작업이 **동일 코드·환경**에서 실행되도록 보장 ### 통합 학습 파이프라인 - comma에서 가장 복잡한 작업은 **온폴리시(on-policy) 방식으로 주행 모델을 학습**시키는 것 - 이런 학습을 위해서는 **최신 모델 가중치**를 적용한 시뮬레이션 주행을 실행하여 **학습 데이터를 생성**해야 함 - 아래와 같은 단일 명령으로 전체 파이프라인 실행 가능 - `./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4` - 위 학습을 실행하는데 위에서 설명한 모든 인프라가 사용됨 - 이 간단한 명령어 하나뿐이지만, 여러 구성 요소를 조율하는 역할을 함 ### 결론 - comma.ai는 **자체 데이터센터 운영으로 비용 절감과 기술 자립**을 달성 - 동일한 접근을 통해 **기업이나 개인도 자체 인프라 구축을 할수 있을 것** ## Comments ### Comment 50747 - Author: kaydash - Created: 2026-02-06T14:56:28+09:00 - Points: 1 메모리가비싸다구! ### Comment 51034 - Author: harryhan2435 - Created: 2026-02-12T09:39:16+09:00 - Points: 1 - Parent comment: 50747 - Depth: 1 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ ### Comment 50699 - Author: neo - Created: 2026-02-06T09:40:47+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46896146) - 우리가 속한 산업에서는 **소유 vs 클라우드**가 스펙트럼의 양 끝에 있음 ① 클라우드는 초기 투자(capex)와 인력 부담이 적지만, **운영비용(opex)** 이 크고 변동성이 큼 ② Managed Private Cloud는 우리가 하는 일로, 오픈소스 기반으로 관리해주며 AWS 대비 약 50% 저렴함 ③ Rented Bare Metal은 하드웨어 자금 조달을 대신해주는 모델로, AWS보다 90% 저렴함 ④ 직접 구매 후 코로케이션하는 방식은 기술력과 규모가 있다면 가장 저렴함 Hetzner 같은 업체는 3년 ROI를 기준으로 운영하며, 3~4번 옵션은 규모가 크거나 인프라가 핵심인 기업에 적합함 스타트업은 1번, 중소기업은 2번이 현실적임 ([lithus.eu](https://lithus.eu)) - 문제는 클라우드의 비용 구조가 단순히 하드웨어 가격 때문이 아니라, **복잡한 아키텍처**로 유도되어 비효율이 커지는 데 있음 AWS의 ‘managed 서비스’들은 사용자가 서버 효율을 높일수록 AWS의 수익이 줄어드는 구조임 단순히 EC2 위에 Java 서버 4개와 복제 DB를 두는 식이면 훨씬 효율적임 결국 말도 안 되는 AWS 요금은 수많은 서비스를 남용할 때 발생함 - (Carolina Cloud의 derek@) 우리도 (4)번 모델을 선호하지만, 기술력이 부족한 사용자들은 1~3번에 머물러 **공공 클라우드의 고비용 구조**에 갇히게 됨 ‘사용량 기반’이라지만 실제로는 **기본요금과 최소 사용료**가 붙어 훨씬 비쌈 ([carolinacloud.io](https://carolinacloud.io)) - Hetzner는 매력적인 선택지임 Postgres나 VPN 같은 서비스를 직접 관리해야 하는 게 부담이지만, 월 1~1.5만 달러 이상이면 AWS보다 유리함 위험은 있지만 감수할 만한 가치가 있음 - 나는 월 500달러짜리 **베어메탈 서버**를 빌려 쓰는데, 관리 시간은 1년에 몇 시간뿐임 내 요구사항이 단순해서일 수도 있지만, 과하게 복잡한 클라우드보다 훨씬 낫다고 느낌 - 2년 전부터 코로케이션으로 옮겼고, 지금은 **30% 비용으로 더 큰 용량**을 확보함 RAM/스토리지의 후행 가격 인하 혜택도 있음 다만 **컴플라이언스 관리**는 조금 더 신경 써야 함 - 예전에는 이런 걸 그냥 **데이터센터**라고 불렀음 클라우드 이전에도 있었던 개념이고, 결국 **소유 vs 임대**, **중앙화 vs 분산화**의 반복임 기업이 극단적으로 한쪽만 선택하면 문제를 다시 맞닥뜨리게 됨 - 흥미로운 점은, 클라우드가 재무팀에 매력적이었던 이유가 세금 절감 효과였음 하지만 최근 법안([OBB](https://www.iqxbusiness.com/big-beautiful-bill-impact-on-capex/))으로 CapEx를 비용 처리할 수 있게 되면서 **온프렘 회귀**에 바람이 불고 있음 - 그렇다면 왜 **가격 경쟁력 있는 클라우드 대안**이 안 나오는가? AWS와 Azure가 시장을 장악해 가격 인하 유인이 없고, Google은 서비스 종료 리스크가 큼 - 클라우드 이전에는 내부 인프라팀이 병목이었음 클라우드는 이를 표준화하고 **단일 청구 체계**로 단순화했음 또 미국 외 지역에서는 서버 조달이 느려서 클라우드의 속도 이점이 컸음 - 온프렘 데이터센터는 **운영 부담**이 크고, 엔지니어링 리소스를 많이 잡아먹음 그래서 이 논쟁이 계속 반복됨 - 클라우드의 진짜 혁신은 “서비스 단위로 비용을 명확히 한 것”임 예전처럼 “누구한테 부탁해야 하지?” 대신 API로 접근 가능해짐 관련 맥락은 [이 글](https://gist.github.com/chitchcock/1281611)에 잘 정리되어 있음 - 샌디에이고처럼 온도 조절이 쉬운 지역이라도 **외부 공기 냉각**은 위험함 습기와 오염물질이 서버를 빠르게 망가뜨림 대신 **엔탈피 휠 쿨러(kyotocooling)** 같은 방식이 효율적이며, 냉각 효율 대비 전력 소모가 적음 외기 냉각은 장비 수명 단축 위험이 크므로 주의해야 함 - 필터링과 습도 45% 이하 유지로 꽤 좋은 결과를 얻은 사례도 있음 - 이런 걸 신경 써야 한다는 걸 몰랐음 그래서 나는 그냥 **클라우드**를 씀 — 이런 ‘모르는 위험’을 피할 수 있음 - 온프렘과 클라우드를 **병행**하는 게 현실적임 핵심 인프라는 신뢰할 수 있는 클라우드에 맡기고, **Slurm 작업** 등은 자체 서버에서 돌림 코로케이션도 여전히 유효한 옵션이며, 연구용 HPC도 고려할 만함 노르웨이에서는 민간 기업도 연구 HPC를 유료로 사용할 수 있음 - 나는 이탈리아에서 두 지역에 서버팜을 운영했는데, 직원 5명이 관리하며 **거의 100% 가동률**을 유지했음 연간 80만 유로로 700~800만 유로의 클라우드 비용을 절감했음 - 많은 개발자들이 자신이 **호스팅을 못한다고 착각**함 실제로는 생각보다 쉽고, 기술적 문제를 해결하는 재미도 있음 - Equinix나 Global Switch 같은 곳에서 공간을 임대하면, 전력·냉각·케이블 등은 모두 관리해줌 직접 두 지역에 서버룸을 두는 것도 충분히 가능함 - 우리는 여전히 Azure를 사용자 서비스용으로 사용함 GPU가 필요 없는 웹 서비스는 클라우드가 더 효율적임 GitHub도 여전히 신뢰할 만한 서비스로 사용 중임 - (농담조로) Slurm 풀에 Postgres 데몬이 꼬여서 **Rust**가 폭주한 적이 있었음 결국 안정화했지만, 하드웨어 엔지니어 입장에서는 소프트웨어 세계가 혼란스러움 - 프로젝트 초기에는 AWS에서 월 250달러로 시작하고, 월 3만 달러 수준이 되면 코로케이션으로 옮김 핵심은 **비용 계산 능력**임 — 좋은 엔지니어는 이를 근거로 경영진에 제안할 수 있어야 함 - 단순 계산을 넘어, 어떤 **인재를 끌어들이고 어떤 비즈니스**를 만들고 싶은지도 고려해야 함 ML 모델을 학습하는 회사라면 자체 인프라가 더 적합할 수도 있음 - 하지만 대부분의 회사에서 엔지니어는 플랫폼 선택에 관여하지 못함 경영진이 이미 결정하고 통보하는 경우가 99.999999%임 - 커리어 초반에는 클라우드가 당연한 선택이었는데, 이제는 **온프렘이 다시 유행**임 10년 후엔 또 반대 흐름이 올지도 모름 - 내 경험상 온프렘을 밀던 팀들은 항상 **유지보수의 피로감**을 과소평가했음 스타트업처럼 빠른 개발이 필요한 곳에서는 오히려 발목을 잡음 반면 유지 모드에 들어간 회사에서는 온프렘이 효율적이었음 나이가 들수록 “빨리, 예산 내에 끝내는 것”이 중요해지고, 인프라 자가 운영의 매력은 줄어듦 - 이번 흐름은 단순한 기술 주기가 아니라 **‘소유하지 못하는 사회’에 대한 반발**로 봄 음악, 집, 자동차까지 모두 구독 모델이 되면서, 기업도 **컴퓨팅 주권**을 되찾으려는 움직임이 있음 - 이런 순환은 늘 있었음 메인프레임 → PC → 서버룸 → 클라우드 → 엣지 컴퓨팅으로 이어지는 **중앙화 ↔ 분산화의 반복**임 결국 기술과 우선순위가 바뀌면 다시 되돌아옴 “네트워크가 곧 컴퓨터”라는 말이 다시 나오면, 또 한 바퀴 돈 것임 - (농담) 다음은 아마 **스페이스(스카이넷)** 단계일지도 모름 - 대부분의 기업이 온프렘을 피하는 이유는 **리스크 관리** 때문임 좋은 기업은 위험을 핵심 경쟁력에 집중시킴 단순히 비용이 아니라 **리스크 조정 비용**으로 판단해야 함 - 하지만 요즘은 기업들이 그 리스크를 **정확히 평가할 역량**이 있는지도 의문임 가격 경쟁력도 결국 차별화 요소 중 하나이기 때문임 - 핵심은 본업에 집중하는 것임 못 파는 제품을 더 잘 팔게 해주는 게 아니라면, 데이터센터에 시간 낭비하지 말아야 함 Google처럼 인프라 자체가 제품 경쟁력인 경우만 예외임 - 결국 **Opex가 Capex를 이기는 싸움**이 대부분임 - 온프렘의 진짜 장점은 **자유와 통제, 프라이버시**임 단순히 돈 문제가 아니라, 집을 소유하느냐 임대하느냐의 문제와 같음 - 하지만 원문에서도 비용은 마지막 항목으로 다뤄졌고, 그 외의 장점이 핵심임 - 2010년대 MBA식 교리는 “모든 걸 클라우드로 옮겨라”였음 리스크와 비용을 제3자에게 넘기는 게 정답으로 여겨졌음 하지만 실제로는 우리 데이터센터가 훨씬 저렴했고, **소프트웨어 구독료의 인상률**이 하드웨어보다 훨씬 높았음 - 물론 AWS는 전 세계에 **중복 데이터센터**를 두고 있어 안정성이 다름 하지만 그만큼 인건비와 관리비를 고려하면, 단순 비용 비교는 무의미함 토네이도 한 번에 회사가 날아갈 수도 있으니까, 결국 **리스크 대비 가치**로 판단해야 함