데이터베이스(DB) 모델을 설계할 때 말하는 종(縱, 세로)과 횡(橫, 가로)의 개념

데이터베이스(DB) 모델을 설계할 때 말하는 종(縱, 세로)과 횡(橫, 가로)의 개념은 데이터가 디스크에 "어떤 방향으로 묶여서 저장되고 처리되느냐"를 의미합니다.

우리가 흔히 보는 엑셀 표를 상상하면 이해하기 아주 쉽습니다. 어떤 DBMS를 선택하느냐에 따라 이 표를 가로로 잘라서 저장할지, 세로로 잘라서 저장할지가 결정되며, 이는 시스템의 성능을 좌우하는 거대한 차이를 만들어냅니다.

1. 횡(橫)의 개념: 행 중심 로우 스토어 (Row-oriented)

횡은 엑셀 표에서 '줄(Row)' 단위로 데이터를 취급하는 방식입니다. 한 사람의 이름, 나이, 직급, 급여를 한 묶음으로 가로 방향으로 저장합니다.

• 저장 방식: [개인1의 데이터 전체] → [개인2의 데이터 전체] → [개인3의 데이터 전체]
• 대표적인 DBMS: Oracle, MySQL, PostgreSQL, Tibero 등 (전통적인 RDBMS)

💡 장점 (언제 좋을까?)

• 데이터를 통째로 넣고 수정할 때: 한 명의 회원가입 정보를 추가하거나, 특정 직원의 주소를 수정할 때 아주 빠릅니다. 해당 줄(Row)만 찾아가서 건드리면 되기 때문입니다.
• 주로 쓰이는 곳: 은행 거래, 쇼핑몰 주문 시스템 등 실시간으로 데이터가 계속 쌓이고 수정되는 OLTP(온라인 트랜잭션 처리) 환경.

2. 종(縱)의 개념: 열 중심 컬럼 스토어 (Column-oriented)

종은 엑셀 표에서 '칸(Column)' 단위로 데이터를 취급하는 방식입니다. 이름은 이름끼리, 급여는 급여끼리 세로 방향으로 모아서 저장합니다.

• 저장 방식: [모든 사람의 이름 모음] → [모든 사람의 나이 모음] → [모든 사람의 급여 모음]
• 대표적인 DBMS: 빅데이터 플랫폼 및 데이터웨어하우스(DW)용 DB (Amazon Redshift, Google BigQuery, ClickHouse, Apache Cassandra 등)

💡 장점 (언제 좋을까?)

• 대규모 통계 및 분석을 할 때: "우리 회사 전 직원의 급여 총합이나 평균 나이를 구해줘"라는 명령을 내렸다고 가정해 봅시다.
  • 횡 방식 DB: 원하지 않는 이름, 주소, 전화번호까지 포함된 데이터 전체 줄을 다 읽어야 해서 느립니다.
  • 종 방식 DB: 디스크에서 '급여'나 '나이' 컬럼이 저장된 구역만 통째로 읽어오면 끝납니다. 읽기 작업량이 극적으로 줄어듭니다.
• 데이터 압축률이 높음: 같은 칸(컬럼)에는 보통 비슷한 데이터(예: 성별 필드의 '남/여')가 반복되기 때문에 압축 효율이 엄청나게 좋습니다. 디스크 용량을 아낄 수 있죠.
• 주로 쓰이는 곳: 데이터 분석, 통계 리포트, BI 시스템 등 대용량 데이터를 조회하는 OLAP(온라인 분석 처리) 환경.

3. 한눈에 비교하기 (요약)

구분	횡(橫) 중심 (Row-oriented)	종(縱) 중심 (Column-oriented)
개념	데이터를 가로 줄(행) 단위로 저장	데이터를 세로 칸(열) 단위로 저장
핵심 목적	빠른 입력, 수정, 삭제 (기록용)	빠른 대용량 조회, 집계, 분석 (분석용)
데이터 접근	한 놈의 모든 정보가 필요할 때 유리	모든 놈의 특정 정보만 필요할 때 유리
적합한 업무	결제, 예약, 회원가입 (OLTP)	통계 분석, 로그 데이터 분석 (OLAP, DW)

결론: 모델러가 기억해야 할 점

데이터 모델을 설계할 때는 "이 서비스가 주로 데이터를 쓰는(Write) 서비스인가, 아니면 대량으로 읽고 분석(Read)하는 서비스인가?"를 먼저 파악해야 합니다.

• 매초 수천 건의 트랜잭션이 발생하는 마이크로서비스라면 횡 방식(RDBMS) 기반으로 모델을 쪼개고 정규화해야 합니다.
• 수억 건의 누적 데이터를 바탕으로 대시보드를 그리거나 패턴을 분석해야 한다면, 종 방식(빅데이터/DW) DB를 선택하고 이에 맞게 모델을 반정규화(와이드 테이블 형태)하여 설계해야 최고의 성능을 낼 수 있습니다.

참고1. 

기존 dbms에서 db 설계는 횡(row)방식으로 되어 있다. db를 대시보드 만들기 위해 종(column)방식으로 일부 설계해서 만들어야 한다. 이럴 경우 인덱스 튜닝이 필요하가?

 

결론부터 말씀드리면, "횡(Row) 방식에서 쓰던 전통적인 방식의 인덱스 튜닝은 필요 없거나 무의미해지지만, 종(Column) 방식에 맞는 새로운 형태의 튜닝(정렬 및 압축 기법)이 필요하다"가 정답입니다.

대시보드 구현을 위해 데이터웨어하우스(DW)용 컬럼 스토어 DB를 추가로 도입하거나 테이블을 변환할 때, 인덱스에 대한 관점이 어떻게 바뀌는지 쉽게 설명해 드리겠습니다.

1. B-Tree 인덱스(전통적인 인덱스)가 필요 없는 이유

우리가 Oracle, MySQL, Tibero 같은 횡(Row) 방식 DB에서 인덱스를 잡았던 이유는 무엇일까요? 책 뒤편의 '찾아보기(색인)'처럼, 수많은 데이터 중 특정 한 줄(Row)을 빠르게 찾아가기 위함이었습니다.

하지만 대시보드용 종(Column) 방식 DB는 수억 건의 데이터 중 특정 한 줄을 찾는 게 목적이 아닙니다. 대신 "지난달 매출 컬럼 전체를 읽어서 더해라" 같은 대량 집계를 수행합니다.

• 자체적인 인덱스 효과: 컬럼 스토어는 데이터를 컬럼별로 묶어서 디스크에 저장하기 때문에, '매출' 컬럼을 조회하면 다른 컬럼(이름, 주소 등)은 쳐다보지도 않고 매출 데이터만 디스크에서 연속적으로 쭉 읽어옵니다.
• 이 과정 자체가 이미 엄청나게 빠르기 때문에, 횡 방식에서 쓰던 전통적인 B-Tree 인덱스를 따로 만들 필요가 없으며, 대부분의 컬럼 지향 DBMS는 이런 인덱스 자체를 지원하지 않거나 권장하지 않습니다.

2. 대신 '종(Column) 방식'에서 해야 하는 튜닝 (새로운 개념)

인덱스는 필요 없지만, 대시보드가 수억 건의 데이터를 1~2초 만에 시각화하려면 컬럼 스토어에 최적화된 튜닝을 반드시 설계 단계에서 반영해야 합니다.

① 정렬 키(Sort Key / Clustering Key) 지정

컬럼 스토어 DB에서 가장 중요한 튜닝입니다. 대시보드는 보통 '최근 1년', '특정 지역', '특정 상품군'처럼 조회 조건(WHERE 절)이 들어갑니다.

• 데이터를 디스크에 저장할 때 기준일자나 조회 조건에 자주 쓰이는 컬럼을 기준으로 정렬해서 저장하도록 설정해야 합니다.
• 이렇게 하면 DB가 디스크의 특정 블록들을 통째로 건너뛰고(Block Skipping) 필요한 구간의 컬럼만 읽을 수 있어 성능이 수십 배 올라갑니다. (이것이 컬럼 스토어의 인덱스 역할을 합니다.)

② 데이터 압축(Compression) 방식 선택

종 방식은 같은 컬럼에 유사한 데이터 유형이 모여 있어 압축률이 극도로 높습니다. 디스크에서 읽어오는 데이터 용량 자체가 줄어들면 대시보드 속도도 빨라집니다.

• 숫자가 주로 들어가는 컬럼, 문자가 들어가는 컬럼에 맞게 DBMS가 제공하는 최적의 압축 알고리즘(예: Run-Length Encoding, Delta Encoding 등)이 적용되도록 세팅해야 합니다.

③ 데이터 모델 설계의 변화 (반정규화)

횡 방식에서는 테이블을 쪼개는 '정규화'와 '조인(Join)'이 중요했지만, 대시보드용 종 방식에서는 오히려 테이블을 하나로 길게 합치는 반정규화(Wide 테이블 / Star Schema) 형태로 설계해야 합니다. 대시보드 전용 마트(Data Mart)를 만들 때 조인을 최소화하도록 모델을 단순화하는 것 자체가 가장 큰 튜닝입니다.

💡 요약하자면

• 기존 RDBMS에서 하던 "이 컬럼에 인덱스 추가해 주세요" 형태의 튜닝은 하지 않으셔도 됩니다.
• 대신 대시보드 설계 시 "어떤 컬럼을 기준으로 데이터를 정렬해서 쌓을 것인가(Sort Key)"와 "대시보드가 조인 없이 한 번에 읽어갈 수 있도록 테이블을 어떻게 합칠 것인가(반정규화)"를 고민하셔야 성공적인 대시보드용 DB를 구축하실 수 있습니다.

참고2: 종과 횡 의미