Apache Cassandra란 무엇인가요?

최종 업데이트: 2026년 7월 24일

Apache Cassandra는 여러 서버에서 대용량 데이터를 처리하도록 설계된 오픈소스 분산형 NoSQL 데이터베이스입니다. 분산형 아키텍처는 단일 장애점을 제거하여 노드 또는 데이터 센터 중단과 관계없이 온라인 상태를 유지해야 하는 고가용성, 쓰기 중심 워크로드에 적합한 안정적인 선택입니다.

Apache Cassandra의 기원과 발전

Facebook(현재 Meta) 엔지니어인 아비나쉬 락슈만과 프라샨트 말릭은 Facebook의 받은 편지함 검색을 지원하기 위해 Cassandra를 만들었습니다. 속도 저하 없이 여러 서버에서 대규모 데이터 세트를 저장하고 검색할 수 있는 시스템이 필요했습니다.

이를 빌드하기 위해 팀은 이미 확립된 두 가지 데이터베이스 모델에서 영감을 얻었습니다. Google의 2006년 Bigtable 논문의 와이드 컬럼 스토리지 모델과 Amazon Dynamo의 분산 링 아키텍처를 결합했습니다. 이들은 다른 사람들이 믿지 않는 예측을 한다는 '저주'를 빗대어 신화 속 트로이의 예언자 카산드라의 이름을 프로젝트에 붙였습니다.

이 프로젝트는 엔지니어링 커뮤니티 전반에 그 잠재력이 분명해지면서 빠르게 발전했습니다.

2008년: Facebook이 Cassandra 소스 코드를 Google Code의 오픈소스 프로젝트로 공개했습니다.
2009년: Apache 인큐베이터에 프로젝트가 수용되어 커뮤니티 주도 소프트웨어로 전환되었습니다.
2010년: Cassandra가 Apache Software Foundation의 최상위 프로젝트로 승격되어 업계에서 입지를 굳혔습니다.
2011년: 버전 1.0 출시로 프로젝트가 성숙 단계에 접어들었음을 알렸고, Netflix, eBay, Twitter와 같은 기업에서 널리 채택되었습니다.
2021년: 버전 4.0 출시로 수천 개의 버그 수정과 광범위한 테스트를 통해 안정성 기준을 높였습니다.
2024~2026년: 5.0 이상의 최신 버전은 벡터 검색, 스토리지 연결 인덱싱(SAI), 향상된 보안과 같은 최신 기술을 지원하여 데이터베이스를 최신 AI 및 빅데이터 워크로드에 적합하게 유지합니다.

오랜 역사를 지닌 만큼 많은 기업이 시스템을 구동하는 데 신뢰하고 있습니다. Cassandra는 고가용성 시스템을 위한 검증된 선택이지만, 설계 장단점을 평가하면 기존 아키텍처를 자체 관리하는 것이 최신 애플리케이션 요구사항에 적합한지 팀이 결정하는 데 도움이 됩니다.

Apache Cassandra의 용도는 무엇인가요?

Cassandra는 스마트(IoT) 센서의 정보, 애플리케이션 로깅, 파이프라인 모니터링과 같이 꾸준한 데이터 스트림이 필요한 작업에 자주 사용됩니다. 또한 대규모로 데이터를 빠르게 저장하고 쿼리하는 것이 중요한 이벤트 추적 및 추천 시스템에도 널리 사용됩니다.

다운타임을 감당할 수 없는 시스템은 Cassandra를 사용합니다. Cassandra의 멀티 데이터 센터 복제와 비동기식 쓰기 덕분에 서비스 중단이나 데이터 손실 없이 전체 데이터 센터를 오프라인으로 전환할 수 있기 때문입니다. 많은 글로벌 기업이 이 기능을 사용하여 여러 리전에서 앱을 연중무휴로 실행합니다.

Apache Cassandra의 아키텍처는 어떻게 작동하나요?

Cassandra는 모든 노드가 동일한 피어 투 피어 설계를 사용합니다. 이러한 노드는 분산된 링으로 설정되며 일관된 해싱이라는 방법을 사용하여 데이터를 균등하게 분산하고 병목 현상을 방지하며 단일 장애점이 없도록 합니다. 또한 읽기 또는 쓰기가 성공했는지 확인할 때 데이터베이스가 얼마나 엄격한지 선택할 수 있으므로 특정 애플리케이션 요구사항에 따라 속도와 최신 데이터 중 하나를 결정할 수 있습니다.

이 데이터베이스는 와이드 칼럼 저장소라는 모델을 사용합니다. 이 모델은 일반 스프레드시트와 유사하지만 더 유연하게 데이터를 키스페이스, 행, 동적 열로 구성하는 데 도움이 됩니다. 따라서 앱이 성장함에 따라 쉽게 변경할 수 있는 방식으로 데이터를 설계할 수 있습니다.

기능	Apache Cassandra	기존 RDBMS
데이터 모델	비정규화	정규화
스키마 유연성	실행 중에 변경 가능	다운타임 필요
색인 구조	로그 구조 병합 트리	B 트리
쓰기 최적화	기본	보조
CAP 포지셔닝(일관성, 가용성, 파티션 내성)	AP(가용성 및 파티션 내성)	CA(일관성 및 가용성)
쿼리 기능	CQL(JOIN 없음)	JOIN이 포함된 전체 SQL

기능

Apache Cassandra

기존 RDBMS

데이터 모델

비정규화

정규화

스키마 유연성

실행 중에 변경 가능

다운타임 필요

색인 구조

로그 구조 병합 트리

B 트리

쓰기 최적화

기본

보조

CAP 포지셔닝(일관성, 가용성, 파티션 내성)

AP(가용성 및 파티션 내성)

CA(일관성 및 가용성)

쿼리 기능

CQL(JOIN 없음)

JOIN이 포함된 전체 SQL

Cassandra가 데이터를 저장하고 처리하는 방법

Cassandra 스토리지 엔진은 로그 구조 병합(LSM) 트리를 사용하여 데이터를 처리합니다. 수신되는 쓰기는 내구성을 위해 커밋 로그에 기록되고 Memtable을 통해 메모리에 보관됩니다. Memtable이 가득 차면 변경할 수 없는 정렬된 문자열 테이블(SSTable)로 디스크에 플러시됩니다.

이러한 추가 전용 설계 덕분에 Cassandra는 쓰기 집약적인 처리량에 탁월합니다. 인플레이스 업데이트를 방지함으로써 시스템은 무작위 디스크 I/O에 의존하는 기존 시스템보다 훨씬 빠르게 수신 데이터를 처리할 수 있습니다.

자주 묻는 질문(FAQ)

Cassandra에 관해 자주 묻는 질문과 답변을 확인해 보세요.

Apache Cassandra의 용도는 무엇인가요?

항상 온라인 상태를 유지하고 스트리밍 로그나 센서 데이터와 같이 많은 양의 데이터 쓰기를 처리해야 하는 앱에 사용되는 분산 데이터베이스입니다.

Cassandra는 SQL 데이터베이스인가요, NoSQL 데이터베이스인가요?

Cassandra는 NoSQL 데이터베이스입니다. SQL과 유사한 CQL이라는 언어를 사용하지만 복잡한 조인이나 심층 트랜잭션 안전성과 같은 모든 기능을 지원하지는 않습니다.

Kafka와 Cassandra의 차이점은 무엇인가요?

Kafka는 데이터를 실시간으로 이동하는 데 사용되는 반면 Cassandra는 데이터를 안전하게 저장하는 데 사용됩니다. 이러한 두 가지 솔루션은 하나의 시스템에서 함께 사용되는 경우가 많습니다.

Apache Cassandra와 MongoDB는 어떻게 비교되나요?

Cassandra는 대규모로 많은 데이터를 작성하는 데 가장 적합합니다. MongoDB는 유연한 구조를 가진 다양한 유형의 데이터를 검색해야 하는 경우에 더 적합한 문서 데이터베이스입니다.

Cassandra는 OLTP인가요, OLAP인가요?

Cassandra는 온라인 트랜잭션 처리(OLTP)를 위해 만들어졌습니다. 즉, 간단하고 빠른 읽기 및 쓰기를 처리하는 데 적합합니다. 대규모 보고서를 실행하거나 모든 데이터를 한 번에 스캔하는 것과 같은 복잡한 분석 작업에는 적합하지 않습니다.

Apache Cassandra의 이점

확장성

더 많은 작업을 처리하기 위해 노드를 추가할 수 있으며, 이를 위해 시스템을 끌 필요가 없습니다.

단일 장애점 없음

모든 노드가 동일하기 때문에 시스템이 매우 안정적입니다.

자동 데이터 복사

시스템은 데이터를 여러 위치에 자동으로 저장합니다.

빠른 쓰기

스토리지 설계는 한 번에 많은 수의 쓰기를 처리하도록 빌드되었습니다.

조정 가능한 일관성

쿼리별로 데이터의 엄격성을 제어할 수 있습니다. 완벽한 정확도를 원한다면 '모든' 노드를 선택하고, 가능한 한 가장 빠른 속도를 원한다면 '하나'의 노드를 선택하세요.

공급업체 종속 없음

표준 하드웨어에서 실행되므로 특정 클라우드 제공업체에 종속되지 않습니다. 필요한 경우 온프레미스 설정과 여러 클라우드 간에 데이터를 이동할 수 있습니다.

관리형 서비스를 사용하여 Cassandra 워크로드 최적화

자체 Cassandra 시스템을 실행하려면 많은 오버헤드가 필요합니다. 필요한 공간을 계획하고, 서버를 설정하고, 수리를 처리하고, 백업을 확보하고, 시스템이 실행되는 동안 업데이트를 수행해야 합니다.

관리형 서비스는 번거로운 작업을 대신 처리하여 이러한 상황의 판도를 바꿔줍니다.

유지보수 자동화: 관리형 서비스는 압축 및 노드 복구와 같은 프로세스를 자동화하여 애플리케이션 속도를 저하시키지 않고 적시에 실행되도록 할 수 있습니다.
용량 계획 및 자동 확장: 관리형 서비스를 사용하면 필요한 서버 수를 추측하는 대신 트래픽을 모니터링하고, 비용을 절감하고, 성능 병목 현상을 방지할 수 있습니다.
백업 및 복구 간소화: 데이터 손실은 어떠한 경우에도 용납될 수 없습니다. 관리형 서비스는 백업을 더 쉽고 자동화된 방식으로 수행하므로 문제가 발생할 경우 데이터를 빠르게 복원할 수 있습니다.
선제적 모니터링: 이러한 서비스에는 디스크 응답 시간 지연 또는 높은 CPU 사용량과 같은 문제의 징후를 중단이 발생하기 전에 감시하는 기본 제공 대시보드가 함께 제공됩니다.
패치 및 업그레이드: 소프트웨어를 최신 상태로 유지하는 것은 보안과 성능에 매우 중요합니다. 관리형 서비스는 백그라운드에서 이러한 업데이트를 처리하는 데 도움이 되며, 데이터베이스가 항상 온라인 상태를 유지하도록 순차적 업그레이드를 사용하는 경우가 많습니다.

이러한 운영 작업을 관리형 플랫폼으로 이전하면 데이터베이스의 인프라 관리에 대해 걱정할 필요 없이 사용자를 위한 가치를 추가하는 데 집중할 수 있습니다.

적절한 Cassandra 배포 전략 선택

Cassandra 워크로드를 실행하는 방법을 결정할 때는 세 가지 주요 경로가 있습니다.

첫째, 오픈소스 Cassandra를 자체 관리할 수 있습니다. 이 경우 소프트웨어를 완전히 제어할 수 있지만 팀에서 기본 인프라를 관리해야 합니다.
둘째, 일상적인 운영의 번거로움 없이 동일한 친숙한 환경을 제공하는 관리형 Cassandra 호환 서비스를 선택할 수 있습니다.
마지막으로, Google Cloud Bigtable 또는 Spanner와 같은 클라우드 네이티브 대안을 선택할 수 있습니다. 이러한 대안은 동일한 고가용성 및 높은 처리량 패턴을 위해 특별히 설계되었지만 최신 클라우드 생태계와 원활하게 작동하도록 설계되었습니다.

올바른 경로를 선택하려면 팀의 전문성과 구체적인 비즈니스 요구사항 사이에서 균형을 맞춰야 합니다. 다음 체크리스트를 참고하여 의사 결정 과정을 진행하세요.

질문	'예'라고 답한 경우	'아니요'라고 답한 경우
데이터베이스를 수정하고 조정할 시간이 있나요?	'데이터베이스 배관'을 전담하는 엔지니어가 있다면 자체 관리형 클러스터를 처리할 수 있습니다.	인프라 유지보수에 엔지니어링 시간을 낭비하지 않으려면 관리형 서비스를 선택하세요.
완벽한 일관성보다 '온라인 상태 유지'가 더 중요한가요?	Cassandra의 AP 모델은 고가용성 앱에 적합합니다.	엄격한 데이터 보안을 갖춘 분산 시스템의 확장성을 제공하는 Cloud Spanner를 고려해 보세요.
성장함에 따라 빠르게 확장해야 하나요?	트래픽 급증을 처리하기 위해 자동 확장을 제공하는 관리형 서비스 또는 Bigtable을 사용합니다.	정적 클러스터도 작동할 수 있지만, 사용량이 많은 기간에는 성능 병목 현상이 발생할 위험이 있습니다.
관리형 서비스를 사용하면 업무의 안정성이 높아질까요?	물론입니다. 관리형 서비스는 백업과 패치를 자동화하여 인적 오류를 방지합니다.	수동 유지보수와 잠재적인 구성 실수로 인한 더 높은 위험을 감수해야 합니다.
인프라 이동성을 목표로 하고 있나요?	자체 관리형은 클라우드 간에 이동하거나 온프레미스에서 실행에 있어 최고의 자율성을 제공합니다.	운영 부담을 줄이는 대신 클라우드 관련 이점을 수용합니다.

질문

'예'라고 답한 경우

'아니요'라고 답한 경우

데이터베이스를 수정하고 조정할 시간이 있나요?

'데이터베이스 배관'을 전담하는 엔지니어가 있다면 자체 관리형 클러스터를 처리할 수 있습니다.

인프라 유지보수에 엔지니어링 시간을 낭비하지 않으려면 관리형 서비스를 선택하세요.

완벽한 일관성보다 '온라인 상태 유지'가 더 중요한가요?

Cassandra의 AP 모델은 고가용성 앱에 적합합니다.

엄격한 데이터 보안을 갖춘 분산 시스템의 확장성을 제공하는 Cloud Spanner를 고려해 보세요.

성장함에 따라 빠르게 확장해야 하나요?

트래픽 급증을 처리하기 위해 자동 확장을 제공하는 관리형 서비스 또는 Bigtable을 사용합니다.

정적 클러스터도 작동할 수 있지만, 사용량이 많은 기간에는 성능 병목 현상이 발생할 위험이 있습니다.

관리형 서비스를 사용하면 업무의 안정성이 높아질까요?

물론입니다. 관리형 서비스는 백업과 패치를 자동화하여 인적 오류를 방지합니다.

수동 유지보수와 잠재적인 구성 실수로 인한 더 높은 위험을 감수해야 합니다.

인프라 이동성을 목표로 하고 있나요?

자체 관리형은 클라우드 간에 이동하거나 온프레미스에서 실행에 있어 최고의 자율성을 제공합니다.

운영 부담을 줄이는 대신 클라우드 관련 이점을 수용합니다.

Google Cloud로 비즈니스 문제 해결

신규 고객에게는 Google Cloud에서 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Google Cloud 영업 전문가와 고유한 문제에 대해 자세히 논의해 보세요.

Bigtable 및 Spanner를 사용하여 Google Cloud에서 Cassandra 워크로드 실행

Cassandra를 직접 관리하는 작업에서 벗어나고 싶다면 Google Cloud에서 제공하는 두 가지 유용한 솔루션인 Bigtable과 Spanner를 사용해 보세요.

이미 Cassandra를 사용하여 와이드 칼럼 스토리지와 높은 쓰기 처리량을 활용하고 있다면 Bigtable이 적합할 수 있습니다. 이를 사용하려면 기존 Cassandra 키스페이스와 테이블을 Bigtable 테이블에 매핑한 다음 Cloud Bigtable 클라이언트 라이브러리를 사용하도록 애플리케이션 코드를 업데이트하면 됩니다. Bigtable은 완전 관리형이므로 이전에는 Cassandra에서 수동으로 조정해야 했던 샤딩과 부하 분산을 자동으로 처리합니다.

Cassandra 워크로드가 strong consistency가 필요할 정도로 커졌거나 SQL의 관계형 기능이 필요한 경우 Spanner도 좋은 선택이 될 수 있습니다. 이를 사용하려면 표준 SQL을 사용하여 스키마를 정의해야 하며, 이 과정에서 비정규화된 Cassandra 데이터의 일부를 정규화해야 할 수 있습니다. Cassandra와 동일한 수평 확장성을 제공하지만, 전역 strong consistency와 완전한 관계형 SQL 지원이라는 이점이 추가되었습니다.