Elon Musk는 사용자들이 하루에 읽을 수 있는 트윗 수에 엄격한 제한을 두겠다고 발표했습니다. 구체적으로는, 인증된 계정은 하루에 최대 6,000개의 게시물을 읽을 수 있고, 인증되지 않은 계정은 600개, 새로 생성된 인증되지 않은 계정은 300개까지 읽을 수 있습니다.

Musk는 이러한 제한이 ‘데이터 스크래핑 및 시스템 조작’ 문제를 해결하기 위한 것이라고 주장했지만, 이 주장의 타당성에는 의문이 듭니다. Twitter는 세계에서 가장 큰 소셜 미디어 플랫폼 중 하나로, 이미 데이터 스크래핑을 방지하기 위한 엄격한 정책을 운영 중입니다 (참고: https://developer.twitter.com/en/developer-terms/agreement-and-policy). 지난 10년 넘게 Twitter는 데이터 스크래핑 및 시스템 조작에 적극적으로 대응해 왔으며, 일반적으로 웹사이트는 IP 주소 차단 기능을 통해 데이터 스크래핑을 방지할 수 있다는 사실도 잘 알려져 있습니다.

대규모 언어 모델(LLM)의 등장으로 인해 데이터 스크래핑에 대한 우려가 커진 것은 사실이지만, 인증된 계정에도 제한을 가하는 것은 논리적으로 맞지 않아 보입니다. 인증 계정은 이미 서비스 요금을 지불하고 정부에서 인증한 신분 정보를 제출했기 때문에, 이들 계정이 악용될 위험은 매우 낮습니다. 경험 많은 엔지니어로서 저는 ‘데이터 스크래핑과 시스템 조작’이라는 이유는 단지 구실일 뿐이라고 생각합니다. 실제 이유는 Twitter의 내부 데이터 인프라가 확장성 문제를 겪고 있거나, 운영 비용이 너무 높기 때문일 수 있습니다.

Twitter와 그 데이터 인프라에 대한 사실들

Elon Musk가 2022년 10월 27일 Twitter를 인수한 이후 발생한 주요 사건들을 정리해 보겠습니다:

Twitter 앱 성능 문제: Elon Musk는 여러 국가에서 Twitter 앱의 속도가 느리다는 점을 공개적으로 인정했습니다. 그는 이 문제의 원인을 홈 타임라인을 렌더링하기 위해 1,000개 이상의 비효율적으로 묶인 RPC 호출이 실행된다고 밝혔습니다.
인력 감축: Twitter는 대규모 구조조정을 단행하며 약 6,000명 이상의 직원을 해고했으며, 이는 전체 직원의 약 80%에 해당합니다.
Twitter Blue 도입: Twitter는 유료 월간 구독 서비스인 “Twitter Blue”를 출시했습니다. 이 구독자는 계정에 파란색 인증 배지를 포함한 다양한 기능을 추가로 이용할 수 있습니다.
트윗 기능 강화: Twitter Blue 구독자는 최대 25,000자까지 트윗을 작성할 수 있는 기능을 제공받았으며, 1080p 해상도로 최대 2시간까지 긴 동영상을 업로드할 수 있는 기능도 추가되었습니다。

그렇다면, 세계 최대의 소셜 미디어 플랫폼을 뒷받침하는 Twitter의 데이터 인프라는 어떤 모습일까요? 사실 Twitter는 몇 년 전부터 자체 데이터 센터에서 Google Cloud(GCP)로 이전을 시작했습니다 (관련 블로그 참고). Twitter는 자체 인프라에서 GCP로 이전함으로써 수십억 건의 이벤트를 실시간으로 효율적으로 처리하고, 방대한 사용자에게 원활한 서비스를 제공할 수 있다고 판단했습니다。

이러한 복합적인 요소들을 종합해 보면, Elon Musk는 GCP의 확장성과 비용 효율성에 대한 강한 신뢰를 바탕으로 Twitter 엔지니어의 대규모 해고가 플랫폼에 큰 영향을 주지 않을 것이라 믿었음을 추론할 수 있습니다. 동시에 Twitter는 기존 사용자 기반을 수익화하기 위한 새로운 기능 도입도 계속 진행해 왔습니다. 하지만 현실은 냉혹했습니다. GCP의 서비스는 지나치게 비쌌고, 기대했던 높은 확장성을 합리적인 비용으로 제공하지 못했습니다。

Elon에게 도움이 될 수 있는 오픈소스 솔루션들

Elon이 비용을 절감하고 수억 명의 Twitter 사용자들이 하루 600개 이상의 게시물을 열람할 수 있도록 하기 위해, Google Cloud의 고비용 서비스를 대체할 수 있는 오픈소스 기술을 적극 도입할 것을 강력히 권장합니다. Twitter의 내부 아키텍처를 면밀히 살펴보면, 대체 가능한 네 가지 핵심 구성 요소를 식별할 수 있습니다。

Cloud Pub/Sub

Cloud Pub/Sub은 Google Cloud에서 제공하는 메시지 큐 서비스입니다. 이는 분산형이고 내결함성을 갖추며, 확장 가능한 메시징 시스템으로서 대량의 데이터 스트림을 효율적으로 처리하도록 설계되어 있습니다. 메시지 큐는 발신자와 수신자를 분리하여 비동기 통신을 가능하게 하며, 분산 시스템의 구성 요소 간에 유연한 연동을 제공합니다。

Twitter에서는 사용자 트윗, 답글, 리트윗, 좋아요 등 다양한 이벤트가 Cloud Pub/Sub에 직접 수집된 뒤 다른 시스템에 의해 처리 및 저장됩니다。

Twitter는 내부적으로 Apache Kafka(https://kafka.apache.org/)를 사용하고 있지만, Google의 Cloud Pub/Sub도 함께 활용하고 있습니다. 그러나 Twitter는 다음과 같은 오픈소스 시스템으로 Cloud Pub/Sub을 대체할 수 있는 유연성을 가지고 있습니다：

Apache Pulsar (https://pulsar.apache.org/) : Apache 재단에서 개발한 분산 메시징 플랫폼으로, 극도로 낮은 지연 시간, 멀티 테넌시, 지역 간 지오 리플리케이션, 계층형 저장 기능 등의 특징을 제공합니다。
Redpanda (https://redpanda.com/) : Kafka와 호환되며, C++로 구현된 고성능 메시징 서비스입니다. Kafka보다 6배 저렴하고 10배 빠른 성능을 제공한다고 주장합니다。

Dataflow

Dataflow는 Google Cloud에서 제공하는 스트림 처리 서비스입니다. 실시간으로 생성되는 데이터 스트림을 분석 및 처리하기 위해 설계된 시스템으로, 기업이 실시간 분석을 수행하고 이벤트에 신속하게 대응할 수 있도록 합니다。

Twitter는 메시지 큐에서 데이터를 가져와 실시간 분석을 수행한 뒤, 이를 후속 시스템에 적재하기 위해 스트림 처리 시스템을 활용합니다。

만약 Twitter가 Dataflow를 대체하고자 한다면, 다음과 같은 대표적인 오픈소스 대안이 있습니다：

Apache Flink (https://flink.apache.org/) : Apache 재단에서 개발한 통합 스트리밍 및 배치 처리 플랫폼입니다. Java API와 SQL 인터페이스를 지원하며, Kafka, Pulsar, HDFS, Iceberg, Hudi 등 다양한 시스템과의 통합이 가능하고, 방대한 생태계를 자랑합니다。
RisingWave (https://www.risingwave.com/) : 스트림 처리를 위해 특별히 설계된 분산 SQL 데이터베이스입니다. 실시간 애플리케이션 개발의 복잡성을 줄이고 비용을 절감하는 데 중점을 두고 있습니다. Rust로 구현되었으며, Flink보다 10배 빠른 성능과 높은 비용 효율성을 자랑합니다. PostgreSQL과의 호환성 덕분에 스트림 처리 초보자도 쉽게 사용할 수 있습니다。

BigQuery

BigQuery는 Google Cloud의 레이크하우스(Lake House) 솔루션입니다. 레이크하우스는 저장, 관리, 분석 기능을 통합하여 대규모의 구조화 및 반구조화 데이터를 처리할 수 있는 통합 확장형 솔루션을 제공합니다。

Twitter에서는 Dataflow를 통해 수집된 데이터가 BigQuery에 지속적으로 기록됩니다. BigQuery는 Twitter 직원들이 전체 Twitter 데이터셋에 대한 정교한 분석을 수행할 수 있도록 해줍니다。

BigQuery를 대체하는 작업은 복잡할 수 있습니다. 계산(Compute) 계층과 저장(Storage) 계층 두 부분 모두를 대체해야 하기 때문입니다。

다음은 BigQuery의 계산 계층을 대체할 수 있는 오픈소스 시스템들입니다：

Presto (https://prestodb.io/) : 다양한 소스의 데이터를 SQL로 질의할 수 있게 해주는 오픈소스 분산 SQL 쿼리 엔진입니다. 다양한 데이터 포맷을 지원하며, 다양한 저장소 시스템과 통합됩니다。
Trino (https://trino.io/) : Trino는 원래 PrestoSQL이라는 이름으로 알려졌던 고성능 분산 SQL 쿼리 엔진입니다. 다양한 파일 포맷, 데이터베이스, 데이터 레이크에 걸친 효율적인 질의를 지원합니다.
Trino와 Presto 사이에는 흥미로운 배경이 있습니다: Presto는 Facebook에서 시작된 프로젝트이며, 2020년 12월 커뮤니티의 상당수가 프로젝트를 포크(fork)하여 Trino로 이름을 바꿨습니다. 더 자세한 내용은 이 블로그에서 확인할 수 있습니다。
Velox (https://github.com/facebookincubator/velox) : Facebook에서 Presto를 재구현한 고성능 분산 SQL 쿼리 엔진으로, C++로 작성되었습니다. Facebook과 ByteDance 등 대형 기술 기업에서 채택되었으며, 매우 빠른 처리 속도를 자랑합니다。
ClickHouse (https://clickhouse.com/) : 초고속 분석을 위한 오픈소스 컬럼형 데이터베이스 관리 시스템입니다. 대규모 데이터 처리에 특화되어 있으며, 실시간 쿼리 처리 능력 또한 탁월합니다. 세계에서 가장 빠른 실시간 분석 시스템 중 하나로 손꼽힙니다: ClickHouse 벤치마크 참조。

BigQuery의 저장 계층은 다음과 같은 오픈소스 시스템으로 대체할 수 있습니다：

Apache Hudi (https://hudi.apache.org/) : 거의 실시간 데이터 적재와 대규모 데이터 관리를 지원하는 분산 데이터 레이크 저장 시스템입니다. 레코드 수준의 업데이트와 삭제, 증분 처리, 수명 주기 관리 등의 기능을 제공합니다。
Apache Iceberg (https://iceberg.apache.org/) : 대규모 데이터 분석을 위한 테이블 포맷으로, ACID 트랜잭션, 스키마 진화, 시점 조회(time travel) 기능을 지원하여 안정적이고 효율적인 분석을 가능하게 합니다。
Delta Lake (https://delta.io/) : 기존 데이터 레이크 위에서 ACID 트랜잭션, 확장 가능한 메타데이터 관리, 데이터 버전 관리 등을 제공하는 오픈소스 저장 계층입니다. 빅데이터 워크로드에 신뢰성과 성능을 부여하며, 데이터 무결성과 일관성을 보장합니다。

Bigtable

Bigtable은 Google Cloud에서 제공하는 NoSQL 데이터베이스이자 키-값 저장소 서비스입니다. 이는 분산형이며, 고성능과 확장성을 갖춘 데이터베이스 시스템으로, 전통적인 관계형 데이터베이스와는 다른 특정 목적과 사용 사례를 위해 설계되었습니다。

Twitter는 소비자 서비스를 지원하기 위해 Bigtable을 사용합니다. 사용자 중심의 플랫폼인 Twitter는 수많은 데이터와 사용자 상호작용을 처리해야 하므로, 매우 빠르고 확장 가능한 데이터베이스 시스템이 필수적입니다。

만약 Twitter가 Bigtable을 오픈소스 대안으로 교체하고자 한다면, 다음과 같은 선택지가 있습니다：

MongoDB (https://www.mongodb.com/) : 가장 인기 있는 NoSQL 데이터베이스 중 하나로, 유연성과 확장성이 뛰어납니다. 문서 기반의 데이터 모델을 제공하며 다양한 사용 사례에 적합합니다. 사용이 쉽고 쿼리 기능이 강력하다는 평가를 받고 있습니다。
Cassandra (https://cassandra.apache.org/) : 고가용성 및 대규모 데이터 처리에 적합한 고확장성, 내결함성 NoSQL 데이터베이스입니다. 다수의 범용 서버에 걸쳐 데이터를 분산시켜 처리할 수 있습니다。
ScyllaDB (https://www.scylladb.com/) : Cassandra와 호환되는 NoSQL 데이터베이스로, Cassandra보다 더 나은 성능과 낮은 자원 사용량을 제공합니다. 노드 수를 줄이면서도 2배에서 8배 빠른 성능을 제공한다고 주장하며, 비용 절감과 오버헤드 감소에 효과적입니다。

결론

Elon은 읽기 제한을 둘 필요가 없습니다. 확장성과 비용 절감을 달성할 수 있는 다양한 방법이 존재합니다. 유료 사용자든 무료 사용자든, 읽기 제한을 두는 것은 Twitter의 역동적인 생태계에 심각한 부정적 영향을 미칠 수 있습니다. 대신, Elon은 Google Cloud의 고비용 서비스를 대체할 수 있는 오픈소스 솔루션을 적극 검토하여 Twitter를 더 나은, 자유롭고 무제한적인 소셜 미디어 플랫폼으로 만들기 위한 노력을 기울여야 합니다！

하루 600트윗 제한의 진짜 이유는 GCP 비용? Elon Musk가 모르는 오픈소스 활용 전략