기업 내부 프로젝트의 오픈소스화 사례 by gpt

Kubernetes (Google)

개발 배경 및 목적

Kubernetes(쿠버네티스)는 Google이 내부에서 오랫동안 운용해온 컨테이너 관리 시스템 경험을 바탕으로 탄생한 오픈소스 프로젝트이다. 2000년대 초반부터 Google은 Borg라는 클러스터 관리 시스템을 운영하여 수십만 개의 작업을 대규모 클러스터에서 스케줄링해왔으며 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium), 이러한 경험을 외부 클라우드 생태계에 활용하고자 했다. 2014년 Google 엔지니어 Joe Beda, Brendan Burns, Craig McLuckie 등이 Borg 및 차세대 시스템 Omega의 개념을 반영한 새로운 프로젝트를 시작했고, 이것이 Kubernetes로 발전하였다 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium) (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium). Kubernetes라는 이름은 Borg의 코드명 “Project 7”(스타트렉의 “Seven of Nine”에서 유래)을 반영한 것으로, 2014년 첫 공개 당시부터 오픈소스로 개발되었다 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium). 주요 목표는 컨테이너화된 애플리케이션의 배포·운영을 자동화하고, Google 내부만이 아닌 외부에서도 동작할 수 있는 범용 클러스터 관리 도구를 만드는 것이었다.

기술적 문제와 도전

Google 내부 Borg를 통해 얻은 교훈과 한계가 Kubernetes 설계에 큰 영향을 주었다. Borg는 강력했지만 몇 가지 제약이 있었다. 예를 들어 아키텍처적으로 Borg는 Google 전용 인프라에 깊이 결합된 모놀리식 시스템이라 변경이나 외부 공개가 어렵고, 사용성 측면에서 선언적 설정(Declarative config)이나 애플리케이션 수준의 헬스 체크를 지원하지 않아 유연성이 떨어졌다 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium). 또한 자원 격리 측면에서 Borg에서는 한 물리 노드의 모든 컨테이너가 IP/포트 공간을 공유했기 때문에, 작업마다 사용할 포트를 미리 선언하고 스케줄러가 이를 조율해야 하는 번거로움이 있었다 (Borg: The Predecessor to Kubernetes | Kubernetes). 이러한 구조는 포트 충돌이나 할당 문제를 일으켜 사용자들이 불편을 겪는 운영상의 Pain Point로 지적되었다 (Borg: The Predecessor to Kubernetes | Kubernetes).

초기 Kubernetes 팀은 성능 및 확장성에 대한 도전도 겪었다. Borg는 Google 내부에 최적화되어 있었기 때문에, 이를 기반으로 새롭게 구현한 Kubernetes가 다양한 환경(온프레미스, 클라우드 등)에서 동일한 성능과 안정성을 내도록 해야 했다. 예를 들어, etcd 기반의 새로운 상태 저장 방식이나 컨트롤러 아키텍처를 도입하면서 대규모 클러스터에서의 확장 한계를 테스트하고 개선해야 했다. Kubernetes 공개 당시 초기 버전은 소규모 클러스터 위주로 설계되었지만, 2016년경에는 2000개 노드에 6만 개 이상의 파드를 돌릴 수 있을 정도로 성능과 규모 면에서 발전하여 초기 한계를 극복해 나갔다 (Updates to Performance and Scalability in Kubernetes 1.3 -- 2,000 node 60,000 pod clusters | Kubernetes). 이처럼 성능 튜닝(예: 스케줄러 최적화, 컨트롤 플레인 컴포넌트의 부하 분산)과 안정성 개선(예: 장애 노드 자동 복구 등)이 Kubernetes 초기 개발 단계의 큰 도전이었다.

조직적 문제

Kubernetes를 오픈소스로 만드는 과정에서는 내부 조직적인 어려움도 상당했다. 처음에 Google 경영진 일부는 이 프로젝트가 너무 핵심적이고 가치가 커서 외부에 공개해서는 안 된다고 여겨 여러 차례 반대했다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 실제로 Kubernetes (당시 코드네임 Project Seven) 팀은 약 6개월에 걸쳐 최고경영진을 끈질기게 설득해야 했으며, 여러 팀과 임원들의 이견 조율이 필요했다 (Kubernetes: How a Rejected Internal Project Became a Global Standard) (Kubernetes: How a Rejected Internal Project Became a Global Standard). Google 기술 인프라 부문 VP인 Eric Brewer도 초기에는 회의적이었으나, 논의 끝에 클라우드 시대에 산업 변화를 이끌기 위해서는 오픈소스로 외부 협력을 끌어내야 한다는 점을 깨닫게 되었다고 전해진다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 이처럼 설계 철학에 대한 내부 저항(“왜 우리의 핵심 기술을 공개해야 하는가”에 대한 우려)과 우선순위 갈등을 해결하는 것이 큰 과제였다.

또한 프로젝트 팀 자체도 Google 본사의 Borg 팀과 다른 위치(시애틀)에서 시작되었기 때문에, 내부 자원 확보와 협업에 어려움이 있었다. 초기 Kubernetes 팀은 소수의 엔지니어로 시작하여 빠르게 프로토타입을 만들어야 했는데, 한정된 인력과 시간으로 핵심 기능을 구현해야 했다. Docker 컨테이너 생태계의 급속한 성장 속도를 따라가기 위해 불과 3개월 만에 시제품을 개발하여 DockerCon 2014에서 발표해야 했고, 이는 팀에 상당한 압박으로 작용했다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 요약하면, 내부 승인 과정의 지연, 다른 팀의 지원 확보, 프로젝트 추진력 유지 등이 조직적인 주요 도전이었다.

문제 해결 전략 및 조치

기술적 문제 해결: Kubernetes 팀은 Borg의 단점으로 지목된 부분들을 설계 단계부터 보완했다. 예를 들어 Pod 단위의 IP 할당(IP-per-Pod)을 도입하여 각 작업 그룹이 고유한 IP를 가지도록 함으로써 Borg에서 겪은 포트 충돌 문제를 해소했다 (Borg: The Predecessor to Kubernetes | Kubernetes). 또한 Borg의 작업 단위를 좀더 유연한 추상화(Pod)로 변경하고, 내부 서비스 디스커버리와 로드밸런싱 개념을 Service라는 1급 객체로 제공했으며, Borg에서는 정적으로 정의되던 작업 그룹을 Kubernetes에서는 Label을 붙여 동적으로 선택할 수 있게 함으로써 사용자들이 다양한 기준으로 워크로드를 관리할 수 있게 했다 (Borg: The Predecessor to Kubernetes | Kubernetes). 아키텍처 측면에서는 Borg의 모놀리틱한 설계를 탈피하여 etcd를 이용한 상태 저장, 컨트롤러-에이전트 패턴, 선언적 API 등을採용함으로써 유연성과 이식성을 높였다 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium). 이를 통해 Google 내부 전용이던 기능들을 외부에서도 사용할 수 있도록 모듈화했고, 다양한 환경에 적응하도록 설계했다.

조직적 문제 해결: Kubernetes 팀은 경영진 설득을 위해 지속적으로 프로젝트의 외부 영향력을 강조했다. 수차례 프레젠테이션과 토론을 거쳐, 마침내 최고 경영진(Urs Hölzle 등)의 승인을 얻어낼 수 있었다고 한다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). Brendan Burns, Craig McLuckie 등 핵심 멤버들은 “승인을 받는 데 걸린 시간이 실제 코드를 개발하는 데 걸린 시간보다 길었다”라고 회고할 정도로 오픈소스 공개를 위한 내부 절차에 공을 들였다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 또한 커뮤니티 전략의 일환으로, Google은 외부 파트너와의 협업을 일찍부터 모색했다. 예를 들어 Red Hat의 엔지니어들이 출시 전부터 Kubernetes 개발에 참여했다. 실제로 Red Hat의 Clayton Coleman은 DockerCon 발표 직전 Kubernetes 소스 접근 권한을 받아 Go 언어 스타일 가이드에 맞게 코드를 다듬는 등 기여를 시작했고, 그는 “자신이 Kubernetes의 최초 외부 기여자 중 하나”였다고 밝히고 있다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 이런 조치는 Kubernetes를 단순한 내부 프로젝트가 아니라 업계 공동의 프로젝트로 자리매김시키는 데 큰 역할을 했다. 그 결과 2015년에는 Kubernetes를 중립적으로 운영하기 위한 재단(CNCF)이 설립되고, 다양한 기업과 개발자들이 참여하는 활발한 오픈소스 커뮤니티가 형성되었다 (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium).

오픈소스로 공개한 경험과 영향

Google이 Kubernetes를 개발하고 오픈소스로 공개한 경험은 회사와 업계 모두에 큰 영향을 미쳤다. 내부적으로 Borg를 운영하며 쌓은 대규모 시스템 노하우와 문제점에 대한 인식은 Kubernetes 설계에 고스란히 반영되어, 오픈소스 사용자들도 Google 수준의 기술을 활용할 수 있게 되었다. Google의 인프라 총괄인 Eric Brewer가 깨달았던 것처럼, 클라우드 산업의 변화를 주도하기 위해서는 혼자만의 힘으로는 안 되고 오픈소스를 통해 업계의 협력을 이끌어야 한다는 전략적 판단이 Kubernetes 공개에 작용했다 (Kubernetes: How a Rejected Internal Project Became a Global Standard). 실제로 “수천 명의 외부 기여자”가 참여하는 커뮤니티를 형성함으로써 Google은 컨테이너 오케스트레이션 분야의 사실상 표준(de-facto standard)을 만들어낼 수 있었다 (Kubernetes: How a Rejected Internal Project Became a Global Standard) (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium). 또한, 내부에서 겪은 성능 병목이나 확장성 이슈를 해결한 경험은 프로젝트를 오픈소스로 내놓은 뒤에도 계속 개선을 주도하는 밑거름이 되었다. Google은 Kubernetes를 Apache 2.0 라이선스로 공개하고 클라우드 네이티브 재단(CNCF) 산하에서 투명하게 운영함으로써, 내부 기술을 외부와 공유하여 생태계를 성장시키는 성공 사례를 남겼다. 이처럼 내부 적용 경험과 문제 해결 노하우를 토대로 공개된 Kubernetes는 현재 전세계 대부분의 클라우드/인프라 업체가 지원하는 컨테이너 오케스트레이션의 표준 플랫폼으로 자리잡았다. (The Evolution of Kubernetes: From Borg to K8s and How it Became the Standard for Container Orchestration | by Roman Glushach | Medium)

ClickHouse (Yandex)

개발 배경 및 목적

ClickHouse는 러시아의 Yandex가 웹 애널리틱스 서비스인 Yandex.Metrica의 백엔드로 개발한 컬럼 지향 OLAP 데이터베이스이다. Yandex.Metrica는 전세계 2위 규모의 웹 분석 플랫폼으로, 사용자 웹사이트의 페이지 뷰, 클릭 등의 이벤트 데이터를 실시간으로 수집하여 맞춤형 리포트를 생성해준다 (ClickHouse History | ClickHouse Docs). 2009년경 이 서비스를 처음 구축할 당시에는 MySQL 등의 전통적인 DB를 사용하여 데이터를 집계했지만, 사용자가 임의로 지정하는 세그먼트와 지표 조합에 대해 즉석에서 통계 리포트를 생성해야 하는 요구를 기존 기술로는 감당하기 어려웠다 (ClickHouse History | ClickHouse Docs) (ClickHouse History | ClickHouse Docs). 예를 들어 미리 정해놓은 집계 결과만 제공하면 새로운 요구에 대응할 수 없고, 모든 가능한 조합을 미리 계산해두려면 저장공간과 일관성 관리 문제가 발생했다 (ClickHouse History | ClickHouse Docs). 이에 Yandex.Metrica 팀은 사전 집계 없이 원시 데이터에 직접 빠른 질의를 수행할 수 있는 전용 데이터베이스가 필요하다고 판단했고, 이러한 목표를 가지고 탄생한 프로젝트가 바로 ClickHouse였다 (ClickHouse History | ClickHouse Docs). 궁극적으로 페타바이트급 비(非)집계 이벤트 데이터를 실시간 처리하면서도 사용자가 자유롭게 질의할 수 있는 분석 플랫폼을 만드는 것이 초기 개발 목적이었다.

기술적 문제와 도전

Yandex.Metrica 팀은 ClickHouse를 개발하기 전후로 여러 기술적 난관을 겪었다. 초기에는 MySQL의 MyISAM 스토리지 엔진을 활용하여 데이터를 저장했는데, 데이터 규모가 폭증하면서 심각한 성능 병목과 운영 문제가 드러났다. MyISAM 기반 시스템에서 2011년경 이미 5,800억 행이 넘는 기록을 저장하고 있었고 디스크 배열이 항상 100% 가동될 정도로 부하가 컸다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 이러한 상태에서는 디스크 고장률이 높아져 RAID를 자주 복구해야 했고, 복제본(replica) 지연이 커져서 일시적으로 복제를 포기하고 다시 구축해야 하는 일도 있었다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 장애 발생 시 복구나 운영의 어려움이 빈번했고, 마스터-슬레이브 전환 역시 매우 번거로운 작업이었다.

이를 개선하기 위해 2010년부터 도입된 것이 Metrage라는 내부 시스템이다. Metrage는 LSM Tree 기반으로 쓰기 성능을 높이고 읽기는 주로 Primary Key 범위 조회로 한정하여 MyISAM의 한계를 극복한 솔루션이었다 (Evolution of Data Structures in Yandex.Metrica) (Evolution of Data Structures in Yandex.Metrica). Metrage 도입 후 Yandex.Metrica의 UI 응답 속도가 크게 향상되어, 이전에는 90퍼센타 분위수 응답 시간이 26초에 달하던 페이지 리포트가 0.8초만에 나오게 되었다는 측정 결과도 있었다 (Evolution of Data Structures in Yandex.Metrica). 스트리밍 데이터에 대한 실시간 배치 집계를 통해 쓰기 부하를 견디면서 읽기 성능을 확보한 것이다. 하지만 Metrage에는 중대한 제약이 있었는데, 미리 정해진 형태의 집계 결과만 저장하기 때문에 새로운 유형의 쿼리에 대응하기 어려웠다. 예를 들어 Metrica에서 40종의 리포트를 미리 정의해 집계해두면 그 외의 임의 조합 리포트는 제공할 수 없었고, 높이 세분화된 키(예: URL 등)에 대해 집계하면 오히려 데이터 양이 줄지 않는 등 한계가 분명했다 (Evolution of Data Structures in Yandex.Metrica). 이 때문에 사용자가 자유롭게 정의하는 커스텀 리포트 요구를 충족시키기 위해서는 별도의 저장소가 필요했고, 보완적으로 도입된 것이 OLAPServer였다. OLAPServer는 단일 테이블 전용의 단순한 컬럼 지향 DB엔진으로 동작했는데, 실시간 데이터 갱신을 지원하지 못하고 하루 몇 차례 일괄 적재만 가능했으며 지원 데이터 타입도 숫자형에 국한되는 등 제한이 많았다 (ClickHouse History | ClickHouse Docs). 요컨대 MyISAM+Metrage+OLAPServer 조합으로는 대용량 데이터의 실시간 유연 쿼리라는 목표를 완벽히 달성하기 어려웠고, 이 한계를 타개하기 위해 새로운 아키텍처가 요구되었다. 이러한 배경에서 개발된 것이 ClickHouse이며, 개발팀은 기존 시스템들의 병목 지점을 제거하는 데 집중했다.

ClickHouse를 실제 Yandex 서비스에 적용하는 과정에서도 성능 튜닝과 확장성 측면의 도전이 이어졌다. 초기 버전의 ClickHouse를 Yandex.Metrica에 적용하면서, 수백 대에 이르는 서버 클러스터에서 쿼리 일관성과 복제된 데이터의 동기화, 그리고 수평적 확장 한계를 테스트해야 했다. 예를 들어 수십 조(rows)의 행을 가진 테이블에서 초당 수백만 행을 스캔하는 쿼리를 처리하면서, 서버 노드를 증설하면 성능이 선형적으로 향상되는지를 검증하는 등 많은 실험과 최적화가 필요했다 (Evolution of data structures in Yandex.Metrica - High Scalability -) (Evolution of data structures in Yandex.Metrica - High Scalability -). 또한 다양한 분석 쿼리(복잡한 JOIN, 서브쿼리 등)를 지원하기 위해 생겨나는 메모리 사용 패턴이나 질의 최적화 문제들을 해결해야 했으며, 컬럼형 DB 특유의 데이터 압축과 벡터 연산 최적화를 통해 CPU 효율을 극대화하는 작업도 뒤따랐다. 이러한 일련의 기술 과제들은 ClickHouse가 단순한 전용 솔루션에서 벗어나 범용 고성능 분석 DBMS로 거듭나기 위한 과정이었다.

조직적 문제

Yandex 내부에서 새로운 데이터베이스를 개발하고 주력 서비스에 적용하는 데에는 조직적인 난관도 적지 않았다. 우선 Yandex.Metrica 팀이 사내 여러 부서와 협업해야 했다. 데이터베이스 인프라를 자체 개발하려면 운영팀, 다른 데이터 소비자 팀과의 의사소통과 협조가 필수였는데, 초기에 새로운 기술 스택에 대한 불안이나 관성이 존재했다. 기존에는 MySQL 및 자체 개발한 Metrage/OLAPServer에 의존하던 파이프라인을 ClickHouse로 전환하는 것에 대해 일부 내부 저항이나 신중론이 있었을 것으로 추측된다. 또한 ClickHouse 클러스터는 수백 대 규모로 확장되었기에, 운영상의 장애 대응 프로세스나 모니터링 체계를 새롭게 구축해야 했고, 이는 여러 팀 (시스템 엔지니어링, SRE 등) 간 협력이 필요한 일이었다. 설계 철학에 대한 내부 이견도 초기에는 있었을 수 있다. 예를 들어 전통적 RDBMS와 다른 아키텍처(컬럼 지향, 최종 일관성 등)를 도입하는 것에 대한 데이터베이스 그룹 내 논의, 그리고 사내 기존 솔루션(MySQL, Vertica 등) 대비 새 시스템을 채택하는 것에 대한 의사결정 과정이 필요했다.

하지만 Yandex는 톱다운 지원과 작은 성공의 축적을 통해 이러한 조직적 문제를 극복해 나갔다. 초기에는 Yandex.Metrica 팀이 작은 규모로 ClickHouse를 부분 적용하여 성능 향상을 입증하고, 점진적으로 범위를 넓혀가는 전략을 취했다. 내부 사용자(데이터 애널리스트, 서비스 오너 등)들에게 새로운 시스템의 장점을 투명하게 보여줌으로써 심리적 저항을 줄였고, 성공 사례가 쌓이자 다른 부서들도 이를 받아들이게 되었다. 그 결과 ClickHouse는 현재 Yandex 검색 로그 분석, 광고 데이터 분석, 전자상거래 등의 수십 개 부서에서 활용되는 공용 인프라로 자리매김하였다 (Evolution of Data Structures in Yandex.Metrica) (Evolution of Data Structures in Yandex.Metrica). “만약 이 시스템이 Yandex.Metrica의 극한 요구사항을 감당해냈다면, 우리의 데이터 문제도 해결할 수 있다”는 신뢰가 조직 내에 형성되면서 기술 스택 전환이 가속화된 것이다 (Evolution of Data Structures in Yandex.Metrica).

문제 해결 전략 및 조치

기술적 해결: ClickHouse 개발팀은 대용량 데이터 실시간 처리를 위한 핵심 요구사항을 정의하고 그에 부합하는 여러 설계 전략을 적용했다 (Evolution of data structures in Yandex.Metrica - High Scalability -) (Evolution of data structures in Yandex.Metrica - High Scalability -). 첫째, 선형적인 스케일 아웃을 위해 공유-없음(shared-nothing) 분산 아키텍처를採용하였다. 노드 수를 유연하게 늘려가며 성능을 높일 수 있도록 설계한 결과, Yandex.Metrica의 메인 ClickHouse 클러스터는 3년간 60대에서 426대로 확장되었고 장애 복원을 위해 서로 다른 데이터센터에 분산 배치되었다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 이 클러스터는 필요 시 단일 쿼리에 수백 대의 노드 자원을 동원하여 초당 2TB 이상의 데이터를 처리할 수 있을 만큼 확장성이 검증되었다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 둘째, 고성능 최적화를 위해 컬럼 저장 방식, SIMD를 활용한 벡터화 연산, 고속 압축(LZ4) 등을 통합했다. 그 결과 내부 벤치마크에서 ClickHouse는 자사 웹 로그 분석 쿼리에 대해 상용 컬럼 지향 DBMS보다 평균 2.8 ~ 3.4배 빠른 성능을 보였고 ([Evolution of data structures in Yandex.Metrica - High Scalability -](https://highscalability.com/evolution-of-data-structures-in-yandexmetrica/#:~

:text=High%20efficiency,V)), MapReduce 스크립트로 처리하던 기존 방법들보다 3자릿수(1000배) 이상의 속도 향상을 이뤘다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 셋째, 기능적 유연성을 갖추도록 SQL 지원을 강화했다. 분산 쿼리를 위한 OLAP SQL 확장, 서브쿼리와 조인 지원, URL 파싱이나 고급 배열 및 통계 함수, 스케치 알고리즘 기반 근사 집계 함수 등 웹 분석 도메인에 특화된 기능을 추가하여 실제 서비스 요구를 대부분 수용할 수 있게 했다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 이러한 다각도의 기술 조치를 통해 ClickHouse는 야ндекс 내부 환경에 최적화되면서도 범용 DBMS 수준의 기능성과 성능을 갖추게 되었다.

조직적 대응: Yandex는 ClickHouse를 성공적으로 안착시키기 위해 점진적 도입과 내부 홍보 전략을 활용했다. 앞서 언급한 대로 작은 워크로드부터 시작해 성능 개선을 입증함으로써 회의적인 내부 시각을 돌렸고, 크로스 팀 협업을 장려하여 개발팀과 운영팀, 서비스팀 간의 지식을 공유했다. 또한 ClickHouse 개발 주도자인 Alexey Milovidov를 비롯한 핵심 인력들이 사내 기술 블로그와 세미나에서 성과를 발표하고, 다른 서비스 팀이 요구하는 기능을 적극 수용함으로써 내부 고객 만족도를 높였다. 그 결과 ClickHouse는 Yandex 내 여러 용도로 확산되었고, “만약 ClickHouse가 Yandex.Metrica의 과제를 해결했다면, 다른 어떤 분석 요구에도 충분한 성능 여력이 있다” (Evolution of Data Structures in Yandex.Metrica)는 인식이 퍼지면서 조직 차원의 지지를 얻는 선순환을 만들었다.

오픈소스로 공개한 경험과 영향

Yandex는 내부에서 충분히 검증된 ClickHouse를 2016년 6월에 아파치 2.0 라이선스로 오픈소스로 공개했다 (Yandex Opensources ClickHouse). 내부적으로 해결한 문제들이 웹 규모 데이터를 다루는 다른 기업들도 직면한 공통의 문제라는 판단 하에, Yandex는 ClickHouse를 공개함으로써 외부 커뮤니티의 피드백과 기여를 받아 더욱 발전시키고 업계 표준으로 자리잡게 하려는 전략을 취했다. 실제로 공개 후 반응은 매우 긍정적이어서, 공개 1년 만에 Cloudflare와 Vertamedia 등 수백 개의 기업들이 ClickHouse를 도입하여 대용량 로그 분석, 광고 데이터 실시간 집계 등에 활용하기 시작했다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 예를 들어 Cloudflare는 하루 750억 건에 달하는 DNS 트래픽 로그 분석에 ClickHouse를 사용했고, Vertamedia라는 광고 플랫폼은 PB급 데이터를 ClickHouse로 처리했다는 사례가 소개되었다 (Evolution of data structures in Yandex.Metrica - High Scalability -). 광범위한 채택은 곧 오픈소스 커뮤니티의 성장으로 이어져, 전세계 개발자들이 버그 수정, 신규 기능 추가, 다양한 플랫폼 지원 등에 기여하게 되었다. Yandex는 2021년에 ClickHouse 개발 조직을 별도 회사로 스핀오프하고, 핵심 엔지니어들이 전업으로 커뮤니티와 상업 지원을 맡도록 하는 등 오픈소스 생태계 조성을 이어갔다. 이 모든 과정에서, 내부에서 겪은 문제와 해결 경험이 프로젝트의 방향성을 이끌었다는 점이 중요하다. Yandex 내부의 성과가 없었다면 외부 신뢰를 얻기 어려웠을 것이지만, Metrica를 통해 단련된 ClickHouse의 능력을 공개함으로써 “한 번 내부에서 증명된 기술은 보편적인 솔루션이 될 수 있다”는 것을 보여준 셈이다. Yandex의 이러한 결정은 자사 브랜드 제고와 글로벌 개발자 커뮤니티의 호응을 얻었고, 현재 ClickHouse는 고성능 OLAP DB의 대표격으로 성장하고 있다.

Apache Iceberg (Netflix)

개발 배경 및 목적

Apache Iceberg는 Netflix가 자체 데이터 레이크 환경의 한계를 극복하기 위해 시작한 내부 프로젝트에서 출발했다. 2010년대 중반 Netflix의 데이터 인프라는 Apache Hive 메타스토어 기반으로 구축되어 있었는데, 증분 데이터 업데이트가 어렵고 대용량 파일 목록을 다루기 비효율적인 Hive 테이블 형식 때문에 문제가 발생했다 (Introduction from the original creators of Iceberg – Tabular). 예를 들어 Hive는 ACID 트랜잭션을 지원하지 않아서 테이블에 병행 쓰기가 일어나거나 중간에 작업이 실패하면 데이터가 손상되어 쿼리 정확성에 문제가 생겼다 (Introduction from the original creators of Iceberg – Tabular). 또한 파티션 폴더 구조를 일일이 디렉터리 listing하여 파일을 찾는 방식이라, 데이터가 수십만 개 파일로 존재하는 테이블에서는 쿼리 시 심각한 지연이 발생했다 (Introduction from the original creators of Iceberg – Tabular). 스키마를 변경하거나 컬럼을 삭제하는 경우에도 별도의 관리 정보가 없어 스키마 진화 과정에서 데이터 불일치나 오류가 잦았고, 적정한 파일 크기나 파티셔닝 전략을 엔지니어가 수동으로 조정해야 하는 등 운영 부담이 컸다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular). 이 모든 약점은 Netflix처럼 페타바이트 이상의 데이터를 AWS S3(객체 저장소)에 저장하는 환경에서 더욱 두드러졌는데, S3에서는 디렉터리 listing의 지연이 HDFS 대비 10배 이상이고 목록이 Eventually Consistent(지연된 일관성)이라 Hive 메타스토어와 실제 S3 상태가 맞지 않는 문제가 빈번했다 (Introduction from the original creators of Iceberg – Tabular). Netflix 내부 사용자들은 이러한 신뢰성 저하로 데이터 품질을 의심하게 되었고, 데이터 플랫폼 엔지니어들은 임시로 문제를 덮기 위한 다양한 “반창고식” 해결책을 투입했다. 예를 들어, S3의 느린 목록 조회와 불일치 문제를 줄이기 위해 Hive 목록 조회 로직을 가로채어 일관성 검증을 추가하고, Hive 메타스토어(HMS)를 포크하여 파티션 교체 작업 시 데이터 부정합이 없도록 수정했으며, 파일 복사본을 피하기 위해 S3 멀티파트 업로드를 활용하고, S3 파일시스템 계층의 일부 안전장치를 끄는 등 작업을 했다 (Introduction from the original creators of Iceberg – Tabular). 그러나 이러한 땜질식 접근으로는 근본적인 한계를 해소할 수 없었고, 성능 개선 역시 미미했다 (Introduction from the original creators of Iceberg – Tabular). 결국 Netflix는 테이블 포맷 자체를 새로 설계해야 한다는 결론에 이르렀고, 2017년 Ryan Blue와 Daniel Weeks를 중심으로 Iceberg 프로젝트를 시작했다 (Iceberg at Netflix and Beyond with Ryan Blue - Software Engineering Daily). 목표는 기존 Hive 테이블 포맷의 제약을 모두 없애고, 데이터 웨어하우스 수준의 신뢰성과 기능을 데이터 레이크에 도입하는 것이었다. 즉, ACID 트랜잭션 지원, 대규모 메타데이터 관리로 성능 향상, 스키마 및 파티션 관리 자동화 등이 Iceberg의 핵심 개발 목적이었다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular).

기술적 문제와 도전

Iceberg 팀이 해결해야 했던 주요 기술 문제는 세 가지로 요약된다: 정확성(데이터 일관성), 성능 및 확장성, 데이터 레이크 운영의 복잡성이다 (Introduction from the original creators of Iceberg – Tabular). 첫째로, 정확성 측면에서 Hive 테이블은 트랜잭션 부재로 인해 원자적 commit이 불가능했는데, Iceberg에서는 이를 위해 스냅샷 기반의 ACID 트랜잭션 모델을 도입했다. Iceberg 테이블은 일정 시점의 스냅샷으로 구성되며 새 데이터를 커밋할 때 기존 스냅샷을 원자적으로 다음 버전으로 치환하는 방식으로 동작한다 (softwareengineeringdaily.com) (softwareengineeringdaily.com). 이를 통해 여러 엔진(Spark, Presto 등)이 한 테이블을 동시에 읽고 쓰더라도 일관성이 유지되며, 중간 실패에도 테이블이 손상되지 않게 만들었다. 둘째, 성능/확장성 문제로 지적된 디렉터리 기반 파일 관리 방식은 Iceberg에서 고급 메타데이터 관리로 대체되었다. Iceberg는 테이블당 매니페스트(manifest)라는 메타데이터 파일에 모든 데이터 파일의 리스트와 각 파일의 통계 정보를 기록해 둔다 (Introduction from the original creators of Iceberg – Tabular). 이를 통해 쿼리 시 디렉터리를 일일이 조회하지 않고도 필요한 파일을 빠르게 찾아 파일 수준 프루닝(pruning)을 할 수 있고, 억단위 파일이 있는 테이블도 메타데이터만으로 처리가 가능해졌다. 특히 S3처럼 지연이 큰 스토리지에서 대량의 파일 목록을 다루는 병목을 해소하여, Iceberg 도입 후 Netflix는 대규모 테이블에서도 Hive 대비 월등한 조회 성능과 확장성을 얻었다고 한다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular). 셋째, 운영 복잡성 부분에서는 숨겨진 파티셔닝(hidden partitioning) 기법과 풍부한 테이블 스키마 진화 기능을 추가했다. Hive에서는 사용자가 일일이 테이블을 어떤 기준으로 파티셔닝할지 결정하고 관리해야 했지만, Iceberg는 테이블의 데이터를 자동으로 분류하고 파티션 키를 노출하지 않는 방식을 취해 사용자 오류로 인한 데이터 빠짐이나 중복을 없앴다 (Introduction from the original creators of Iceberg – Tabular). 그리고 스키마 변경 이력도 메타데이터에 관리하여, 컬럼 추가/삭제나 타입 변경을 해도 과거 스냅샷과 호환성을 유지할 수 있게 했다. 이 외에도 시간 여행(time travel) 기능(과거 스냅샷 시점으로 쿼리 가능)으로 결과 재현성을 높이고, 분기(branch) 기능을 통해 실제 테이블에 적용하기 전 데이터 검증 작업을 할 수 있게 하였으며, MERGE 등 행 수준 DML 연산도 지원하여 데이터 수정 작업을 단순화했다 (Introduction from the original creators of Iceberg – Tabular). 이러한 기능들은 모두 Netflix 내부에서 겪었던 데이터 정합성 문제, 느린 쿼리, 높은 운영 부담을 해결하기 위한 것으로, Iceberg 설계에 반영된 기술적 해법들이다. 결과적으로 Iceberg는 데이터 레이크에 SQL 테이블의 추상화를 도입하여, 사용자가 대용량 파일의 집합이 아닌 하나의 일관된 테이블로 데이터를 다룰 수 있게 만들었다.

조직적 문제

Netflix가 Iceberg를 내부에 적용하고 오픈소스로 추진하는 과정에서는 몇 가지 조직적 과제도 존재했다. 기존 Hive 기반 플랫폼에서 새로운 Iceberg 기반으로 전환하는 것은 단순히 기술 교체를 넘어 여러 팀의 작업 방식에 영향을 미쳤다. 데이터 플랫폼 팀은 이 프로젝트를 “10년에 한 번 있을까 말까 한 근본적 개혁”으로 인식하고, 서두르기보다는 정확성과 완성도를 높이는 데 집중했다 (Introduction from the original creators of Iceberg – Tabular). 예를 들어 Netflix 엔지니어들은 처음에 트랜잭션과 스키마 진화처럼 시급한 문제를 우선 해결했지만, 성능 개선과 기타 데이터 품질 문제(파티션 관리 등)도 놓치지 않고 한 번에 해결하고자 했다 (Introduction from the original creators of Iceberg – Tabular). 이는 새로운 테이블 포맷을 도입했다가 나중에 다시 바꾸는 일이 없도록 하기 위함이었다. 이러한 접근으로 인해 프로젝트 기간이 길어질 수 있었지만, 조직 내에서는 장기적 이득을 위해 초기 투자와 변경을 수용해야 했다.

또한 사내 여러 이해관계자의 조율이 필요했다. Netflix의 데이터 소비자는 데이터 사이언티스트, 애널리스트부터 각 서비스 엔지니어까지 다양했는데, 새로운 Iceberg 포맷으로의 마이그레이션은 쿼리 엔진(Spark 등)의 업그레이드, 기존 파이프라인 수정 등이 수반되었다. 이를 위해 Iceberg 팀은 기존 Hive 테이블과의 공존 전략을 취해 점진적으로 이전하고, 사용자 교육과 문서를 통해 변화에 대비했다. 팀 간 충돌보다는 긴밀한 협업으로 문제를 풀어나가는 Netflix 문화 덕분에 비교적 원활하게 전환이 이뤄진 것으로 보인다. 실제로 Netflix는 사내에서 Iceberg를 도입한 후, 몇 년에 걸쳐 모든 데이터를 Iceberg 테이블로 이전하여 현재는 Hive 대신 Iceberg가 데이터 레이크의 표준이 된 상태이다.

특筆할 점은, Netflix가 프로젝트 초기부터 외부 협력을 적극 모색했다는 것이다. Iceberg를 사내 전용으로 개발하지 않고, 시작 단계에서부터 오픈소스化를 염두에 두었기 때문에 Netflix 엔지니어들은 다른 기업들과 교류하며 요구사항을 수렴했다. Iceberg 개발이 한창이던 시기에 Apple을 비롯한 대형 기술 기업들도 유사한 문제식을 갖고 있었고, Netflix는 이들과 정보를 공유하며 Iceberg의 설계에 반영했다 (softwareengineeringdaily.com). Iceberg가 2018년 말 오픈소스로 공개된 직후에는 Expedia, Airbnb, LinkedIn, Salesforce 등의 데이터 엔지니어들이 프로젝트에 참여하여 코드를 함께 개선해 나갔다 (softwareengineeringdaily.com). Netflix 내부적으로 볼 때, 타 회사와의 협업은 조직 경계를 넘어선 도전이었지만 이를 통해 더 견고하고 범용적인 솔루션을 만드는 데 성공했다. 또한 Netflix 경영진 역시 오픈소스에 우호적이어서, 프로젝트를 Apache 재단에 기부하는 결정이 순조롭게 이루어졌다. Netflix는 이미 여러 내부 도구(예: Hadoop 최적화 라이브러리, 스케줄러 등)를 오픈소스화한 전례가 있었기 때문에, Iceberg도 이러한 오픈 문화 속에서 추진될 수 있었다.

문제 해결 전략 및 조치

기술적 해결: Iceberg 팀은 앞서 열거한 기술 문제들을 해결하기 위해 테이블 포맷 레벨에서 혁신을 이루었다. 가장 중요한 트랜잭션 문제는 다단계 트리 구조의 메타스토어와 스냅샷 교체 기법으로 풀었다 (softwareengineeringdaily.com) (softwareengineeringdaily.com). 여러 파일로 이루어진 테이블을 일련의 스냅샷(메타데이터 트리)으로 관리하고, 새로운 데이터 커밋 시 기존 스냅샷의 루트 포인터를 원자적으로 교체함으로써 ACID의 원자성(Atomicity)을 달성했다. 이는 Git의 커밋 스냅샷 교체와 유사한 원리이며, Iceberg의 표준 SQL 같은 동시성 모델의 기반이 되었다 (softwareengineeringdaily.com) (softwareengineeringdaily.com). 성능 향상을 위해서는 철저한 메타데이터 분리 전략을 취했다. Iceberg는 Hive 메타스토어 대신 자체 카탈로그 서비스를 통해 메타데이터(테이블의 스냅샷, 파일 목록, 통계 등)를 관리하고, 쿼리 엔진들은 이를 통해 필요한 부분만 읽도록 최적화했다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular). 그 결과 쿼리 엔진(Spark, Trino 등)이 Iceberg 테이블을 조회할 때 수천 개 파일이 있는 디렉터리도 통째로 스캔하지 않고 메타데이터 기반으로 필터링하여 큰 폭의 성능 개선을 얻었다. 데이터 품질과 스키마 문제에는 엄격한 스키마 관리와 자동 파티셔닝으로 대응했다. 컬럼의 추가/삭제 이력과 파티션 변화 이력을 모두 기록하여, 과거 쿼리와 신규 쿼리가 충돌하지 않고 공존하게 했다. 또한 숨겨진 파티션 기법을 통해 사용자는 단순히 테이블에 데이터만 쓰면 되고 Iceberg가 내부적으로 적절히 분할해서 관리하므로, 잘못된 파티션 키 선정으로 인한 오류가 제거되었다 (Introduction from the original creators of Iceberg – Tabular). 부가적으로, Time Travel 기능 구현을 위해 이전 스냅샷들을 보존하고 카탈로그에서 지정된 시간점의 스냅샷을 가리킬 수 있도록 했으며, Branch/Tag 기능을 통해 실험용 테이블 버전을 만들어본 뒤 문제없으면 본 테이블에 병합(commit)하는 패턴도 가능하게 했다 (Introduction from the original creators of Iceberg – Tabular). 이러한 기술적 조치들은 Netflix 내부의 다양한 장애 시나리오와 요구사항(예: ETL 중간에 쿼리 결과가 오염되지 않게 하기, 몇 분 간격으로 스트리밍 데이터 컴팩션 수행, 여러 엔진이 동시에 동일 데이터를 안전하게 공유 등)을 충족하기 위해 설계된 것이다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular).

조직적 대응: Iceberg 개발 과정에서 Netflix는 오픈 커뮤니티와의 협력을 문제 해결의 한 축으로 삼았다. 앞서 언급한 대로 Apple 등과 공동으로 요구사항을 논의하고, Apache 재단의 인큐베이션 프로젝트로 참여를 유도함으로써 더 많은 인력이 Iceberg 개선에 투입될 수 있었다 (softwareengineeringdaily.com). 이는 내부 인적자원만으로 해결하기 벅찬 부분(예: 다양한 엔진 통합, 광범위한 테스트)을 타사 전문가들과 함께 함으로써 리스크를 줄이는 효과를 거두었다. Netflix 조직 내에서는 데이터 플랫폼 팀이 주축이 되어 Iceberg를 개발했지만, 최종적으로 이를 사용하게 될 데이터 사이언스팀, 플랫폼 운영팀 등의 요구를 적극 수렴하기 위해 내부 설득 작업도 병행했다. 프로토타입 단계부터 중요한 사용자들에게 시연하고 피드백을 받아 기능을 개선했으며, 문서화와 교육을 통해 새로운 시스템에 대한 학습 장벽을 낮추었다. 이러한 조직적 노력 덕분에 Netflix 내부에서 Iceberg로의 전환이 순조롭게 진행되었고, 다른 기업과의 협업을 통한 품질 향상으로 안정적인 버전 1.0을 이루어낼 수 있었다.

오픈소스로 공개한 경험과 영향

Netflix는 Iceberg를 태동시킬 때부터 오픈소스化를 전제로 한 철학을 갖고 있었다. “우리만의 문제가 아니라 업계 전체의 문제를 풀어야 한다”는 인식 하에, 프로젝트 초기에 Eric Sammer 등 업계 전문가를 자문하고 여러 회사를 끌어들인 것이다 (Kubernetes: How a Rejected Internal Project Became a Global Standard) (softwareengineeringdaily.com). 결국 2018년 11월 Iceberg를 Apache Software Foundation에 기부하여 누구나 참여할 수 있는 오픈소스 프로젝트로 전환했고 (Iceberg at Netflix and Beyond with Ryan Blue - Software Engineering Daily), 이는 Iceberg의 폭발적인 성장으로 이어졌다. 공개 이후 Apple, Airbnb, LinkedIn, Expedia 등 대형 데이터 조직들이 앞다투어 Iceberg를 채택하거나 기여했고, 불과 1 ~ 2년 만에 Iceberg는 주요 클라우드 데이터 플랫폼들이 지원하는 개방형 테이블 포맷의 표준이 되었다 ([Iceberg at Netflix and Beyond with Ryan Blue - Software Engineering Daily](https://softwareengineeringdaily.com/2024/03/07/iceberg-at-netflix-and-beyond-with-ryan-blue/# (Introduction from the original creators of Iceberg – Tabular). Iceberg의 중립적 오픈소스 지배구조(Apache 프로젝트)는 다양한 이해관계자가 안심하고 참여할 수 있게 했고, Netflix도 그 커뮤니티의 한 구성원으로서 기여를 이어가고 있다. Netflix 입장에서, 내부에서 축적된 문제 해결 경험을 오픈소스로 공유한 것은 일석이조의 효과를 가져왔다. 첫째, 내부적으로는 더 이상 Hive의 한계를 임시방편으로 막지 않고 근본적인 해결책(Iceberg)을 도입함으로써 플랫폼 신뢰성과 생산성이 크게 향상되었다 (Introduction from the original creators of Iceberg – Tabular) (Introduction from the original creators of Iceberg – Tabular). 둘째, 외부적으로는 Netflix가 Iceberg를 공개함으로써 업계 표준 확립에 기여하고 데이터 생태계의 주도권을 확보하게 되었다. Netflix 혼자였다면 이루기 어려웠을 폭넓은 엔진 호환성과 검증이 여러 회사의 참여로 가능해졌고, 이는 다시 Netflix가 혜택을 누리는 선순환을 만들었다. 요약하면, Netflix의 내부 시행착오와 배운 교훈들이 Iceberg를 탄생시켰고, 그 과정을 오픈소스로 전환함으로써 더 큰 성과를 거둘 수 있었다. Iceberg는 현재도 활발한 오픈소스 커뮤니티 개발이 진행되고 있으며, 클라우드 기반 데이터 분석의 게임체인저 중 하나로 평가받고 있다.