Yoo HeehyeonYoo Heehyeon

1. 파티셔닝과 샤딩을 같은 말처럼 쓰면 안 되는 이유

파티셔닝과 샤딩은 둘 다 데이터를 나눈다는 점에서는 닮아 있다. 그래서 처음 접하면 비슷한 기술처럼 느껴진다.
그런데 실제로는 다루는 문제의 층위가 다르다.

• 파티셔닝은 큰 테이블을 한 DB 안에서 관리 가능하게 만드는 쪽에 가깝다.
• 샤딩은 한 DB 인스턴스로 감당할 수 없는 부하를 여러 인스턴스로 분산하는 쪽에 가깝다.

내 기준으로 가장 헷갈리지 않게 정리하면 이렇다.

파티셔닝은 한 집 안에서 방을 나누는 일이고, 샤딩은 집 자체를 여러 채로 나누는 일이다.
이 차이를 먼저 잡고 들어가야 뒤에 나오는 성능, 운영, 책임 주체 얘기가 자연스럽게 연결된다.

2. 데이터를 나눈다는 건 결국 비용을 나누는 일이다

DB가 커진다는 말은 단순히 row 수가 늘어난다는 뜻이 아니다. 실제로 문제를 만드는 건 저장 구조 하나가 너무 많은 비용을 떠안기 시작한다는 점이다.
대개 이런 징후가 보인다.

• 인덱스가 커지면서 조회 비용이 커진다.
• 디스크 I/O 병목이 두드러진다.
• 트랜잭션 경합과 락 대기가 늘어난다.
• 백업과 복구 시간이 길어진다.
• 서버 스펙을 올려도 개선 폭이 점점 줄어든다.

결국 "데이터가 많다"는 말은 추상적이다. 더 정확히 말하면 하나의 저장 구조로 감당해야 하는 비용이 너무 커졌다는 뜻이다.
그래서 데이터를 나눈다는 건 데이터를 보기 좋게 정리하는 일이 아니라, 조회 비용, 운영 비용, 확장 비용을 다시 배분하는 일에 가깝다.

3. 파티셔닝은 DB 내부 최적화에 가깝다

파티셔닝은 하나의 DB 인스턴스 안에서 큰 테이블을 여러 파티션으로 나누는 방식이다. 여기서 중요한 건 애플리케이션 입장에서는 여전히 하나의 테이블처럼 다룰 수 있다는 점이다.
즉 감각은 이렇다.

• 개발자는 평소처럼 테이블을 조회한다.
• DB 엔진이 내부적으로 어떤 파티션을 읽을지 판단한다.
• 데이터는 쪼개져 있지만 사용 경험은 하나처럼 유지된다.

이 말은 곧 파티셔닝의 책임 주체가 대체로 DB 쪽에 있다는 뜻이기도 하다.
그래서 파티셔닝은 애플리케이션 구조를 크게 흔들지 않으면서, DB 내부 성능을 다듬는 전략으로 이해하는 편이 맞다.

4. 파티셔닝이 진짜로 유효한 순간

파티셔닝은 단순히 "큰 테이블이니까 쪼개자"가 아니다. 어떤 데이터는 파티셔닝 효과가 크고, 어떤 데이터는 생각보다 미미하다.
내가 이해한 기준은 이렇다.

조회 범위가 명확할 때

날짜, 숫자 구간, 지역 코드처럼 조회 조건이 자주 특정 범위를 탄다면 파티셔닝 효과가 커진다.
이때 중요한 개념이 partition pruning이다. 전체를 훑는 대신 필요한 파티션만 보게 만들 수 있기 때문이다.

월별 로그 테이블이 대표적이다. 최근 1주일 데이터를 보는데 몇 년치 데이터를 같은 물리 단위로 붙들고 있을 이유가 없다.

오래된 데이터를 정리해야 할 때

로그나 이벤트 데이터는 시간이 지나면 지우거나 보관해야 한다.
이때 row 단위 delete는 생각보다 비싸다. 반면 파티션 단위로 나뉘어 있으면 오래된 월 데이터를 통째로 떼어내는 식으로 처리하기 쉽다.

그래서 파티셔닝은 조회 최적화이기도 하고, 보관 정책과 운영 자동화이기도 하다.

아직 단일 인스턴스 안에서 해결 가능할 때

이 점이 특히 중요하다.
파티셔닝은 보통 "아직 한 DB 안에서 버틸 수 있다"는 전제를 깔고 들어간다. 즉 완전한 분산 구조로 넘어가기 전 단계에서 가장 빛난다.

5. 파티셔닝 방식은 조회 패턴을 반영한 설계다

레인지, 리스트, 해시, 복합 전략은 그냥 종류표가 아니다. 어떤 조회 패턴과 어떤 데이터 분포를 상정하느냐에 따라 선택이 달라진다.

레인지 파티셔닝

날짜, 연도, 숫자 구간처럼 자연스러운 범위가 있을 때 가장 직관적이다.
로그, 주문, 결제 이력처럼 시간축을 타는 데이터는 대부분 여기서 먼저 떠올리게 된다.

장점은 사람이 봐도 이해하기 쉽다는 점이다. 대신 최신 파티션만 과하게 두꺼워지는 경우는 따로 봐야 한다.

리스트 파티셔닝

국가, 지역, 상태 코드처럼 값의 종류가 분명할 때 적합하다.
다만 값 분포가 고르지 않으면 특정 파티션에 부하가 몰릴 수 있다.

해시 파티셔닝

데이터를 비교적 고르게 나누고 싶을 때 유용하다.
반면 운영 관점에서는 직관성이 떨어진다. 사람이 보기에 분할 기준이 덜 자연스럽기 때문이다.

복합 파티셔닝

실무에서는 결국 한 가지로 안 끝나는 경우가 많다.
예를 들어 먼저 날짜로 자르고, 그 안에서 해시를 섞는 식이다.

결국 파티셔닝 방식 선택은 기능 이름을 고르는 일이 아니라, 조회 패턴과 데이터 편향을 어떻게 해소할지 정하는 일이다.

6. 샤딩은 DB 최적화가 아니라 시스템 설계 문제다

샤딩은 데이터를 서로 다른 물리적 DB 인스턴스로 나누는 방식이다.
여기서부터는 파티셔닝과 결이 확 달라진다.
이제 질문이 바뀐다.

• 이 데이터를 어떻게 저장할까
• 가 아니라
• 이 요청은 어느 DB로 보내야 하지

이 시점부터 문제는 DB 내부 최적화가 아니다. 애플리케이션 구조, 라우팅, 키 설계, 운영 체계가 전부 얽히기 시작한다.
그래서 샤딩은 멋진 기술이라기보다, 시스템이 꽤 어려운 단계에 들어섰다는 신호처럼 느껴진다.

7. 파티셔닝과 샤딩의 차이를 가르는 핵심 세 가지

내 기준으로는 세 가지를 보면 된다.

첫째, 물리적 위치가 다르다

• 파티셔닝은 같은 DB 인스턴스 안에서 나뉜다.
• 샤딩은 인스턴스 자체가 갈라진다.

이건 단순한 구조 차이가 아니다. 장애 범위와 운영 단위를 바꾼다.

둘째, 확장 방향이 다르다

• 파티셔닝은 한 대를 더 효율적으로 쓰는 쪽이다.
• 샤딩은 한 대로 안 되니 여러 대로 넘기는 쪽이다.

즉 파티셔닝은 스케일업 쪽의 최적화 성격이 강하고, 샤딩은 스케일아웃 쪽 성격이 강하다.

셋째, 책임 주체가 다르다

이게 가장 크다.

파티셔닝은 DB가 상당 부분 알아서 해 준다.
반면 샤딩은 애플리케이션이나 미들웨어가 어느 샤드로 보낼지 판단해야 하는 경우가 많다.

결국 샤딩부터는 저장 전략이 DB 설정이 아니라 서비스 코드와 아키텍처의 일부가 된다.

8. 샤딩이 비싼 이유는 기능이 아니라 복잡도에 있다

샤딩은 성능 한계를 넘기는 데 강력할 수 있다. 대신 시스템을 덜 단순하게 만든다.

가장 먼저 부딪히는 건 조인 문제다.

같은 DB 안에서는 자연스럽던 조인이 샤드가 갈라지는 순간 쉬운 일이 아니게 된다.
서로 다른 샤드에 있는 데이터를 합치려면 애플리케이션이 직접 모으거나, 별도 집계 구조를 둬야 한다.

이 말은 곧 데이터 모델링 단계에서부터 cross-shard join을 피하는 구조를 고민해야 한다는 뜻이다.

또 샤딩에서는 샤드 키가 생명이다.

• 특정 샤드에만 요청이 몰리면 핫스팟이 생긴다.
• 특정 사용자군만 무겁다면 균형이 깨질 수 있다.
• 나중에 샤드를 늘릴 때 재배치 비용이 커질 수 있다.

즉 샤딩은 DB를 여러 대 띄우는 일이 아니라, 분산을 전제로 키 설계를 다시 하는 일이다.

운영도 어렵다.

• 백업
• 복구
• 모니터링
• 재배치
• 스키마 변경
• 장애 대응

이게 샤드별로 벌어진다.
그래서 샤딩은 성능 개선책인 동시에 운영 복잡도 증가책이기도 하다.

9. 실무에서 보통 어떤 순서로 생각하게 되는가

내가 보기엔 실무에서는 대체로 이렇게 흐른다. 먼저 파티셔닝을 본다.

• 아직 단일 DB 안에서 버틸 수 있다.
• 조회 패턴이 명확하다.
• 시간축 데이터가 많다.
• 오래된 데이터 정리가 중요하다.

이 경우 파티셔닝은 비교적 낮은 비용으로 큰 효과를 낼 수 있다. 그 다음 샤딩을 본다.

• 단일 DB 서버 사양을 올려도 한계가 선명하다.
• 물리적으로 한 대에 몰아넣는 것 자체가 무리다.
• 지역별 데이터 분산이나 데이터 로컬리티가 필요하다.
• 서비스 구조상 자연스러운 분산 키를 잡을 수 있다.

여기서 중요한 건 "데이터가 많으니까 샤딩"이 아니다.
이제 문제의 성격이 단일 인스턴스 최적화로는 안 풀리는 수준인가를 먼저 봐야 한다.

10. 둘은 대체 관계가 아니라 서로 다른 층위다

파티셔닝과 샤딩은 서로 경쟁하는 카드처럼 보이지만, 실제로는 계층이 다르다.

• 파티셔닝은 DB 내부 구조를 다듬는 일에 가깝다.
• 샤딩은 시스템 전체를 분산 구조로 바꾸는 일에 가깝다.

그래서 둘 중 하나만 쓰는 게 아니라 같이 가는 경우도 자연스럽다.

• 샤딩으로 큰 축을 나누고
• 각 샤드 안에서 다시 파티셔닝으로 정리하고
• 그 위에 캐시나 별도 읽기 모델을 얹는 식이다
  즉 파티셔닝을 잘했다고 샤딩이 영영 필요 없어지는 것도 아니고, 샤딩을 도입했다고 파티셔닝 문제가 사라지는 것도 아니다.

11. 결론

파티셔닝은 큰 테이블을 다루는 기술이고, 샤딩은 큰 시스템을 다루는 기술이다.
둘 다 데이터를 나눈다는 점은 같지만 파티셔닝은 같은 DB 안에서 성능과 관리 효율을 끌어올리는 내부 최적화에 가깝고,
샤딩은 단일 인스턴스의 한계를 넘기 위해 시스템 자체를 분산 구조로 바꾸는 선택에 가깝다.

그래서 순서도 자연스럽다.
먼저 파티셔닝처럼 비용이 낮고 구조를 덜 흔드는 방법으로 버틸 수 있는지 본다. 그래도 안 되면 그때 샤딩을 본다.
샤딩은 멋져 보이지만, 실무에서는 대체로 더 비싸고 더 어렵고 더 늦게 꺼내는 카드다.