정규화와 DW 스키마, 면접 준비 끝내기

안녕하세요! 오늘은 데이터 직군 면접에서 단골 질문으로 자주 등장하는 ‘정규화와 비정규화’, 그리고 ‘스타 스키마와 스노우플레이크 스키마’에 대해 이야기해보려고 합니다. 데이터 분야 취업이나 이직을 준비하는 주니어분들이라면 이 개념들을 한번은 확실히 정리해 두는 것이 좋을 것 같아, 이번에 정리해 보았습니다.

정규화와 비정규화를 쉽게 이하기 위해, 집에 있는 옷장을 한번 떠올려보시죠.

옷장

옷을 정리하는 방식이 두 가지 있다고 상상해 봅시다.

첫 번째는 종류별로 완벽하게 분류하는 방식이에요. 셔츠는 셔츠끼리 놓고, 바지는 바지끼리 놓는 거죠. 심지어는 색상별, 계절별로 더 세밀하게 나누기도 합니다. 이것이 바로 ‘정규화’예요. 모든 물건이 정해진 위치에 있고 중복되는 것이 없죠. 셔츠를 찾으려면 셔츠가 있는 곳으로 바로 가면 되니까 관리도 편리합니다.

반면에 ‘자주 입는 옷들을 한곳에 모아두는 방식’도 있어요. 매일 입는 티셔츠나 자주 손이 가는 바지, 평소에 즐겨 신는 양말을 옷장 앞쪽에 한데 모아두는 형태죠. 이는 ‘비정규화’ 방식과 비슷합니다. 같은 티셔츠가 일반 옷장과 자주 입는 옷 코너에 중복으로 존재하게 될 수도 있지만, 매일 아침마다 옷을 고르는 데 소요되는 시간을 크게 단축할 수 있죠.

이처럼 정규화와 비정규화는 데이터를 어떤 방식으로 구성할지에 대한 철학적인 차이를 나타냅니다. 그럼 지금부터 본격적으로 데이터베이스 관점에서 이 두 가지 개념을 살펴보겠습니다.

정규화: 데이터 중복을 제거한다 정규화는 데이터베이스 내의 중복을 최소화하고, 데이터를 논리적으로 서로 관련된 단위에 따라 나누는 과정입니다. 도서관에서 책을 주제별로 명확하게 분류해 놓는 방식과 비슷하죠.

정규화 된 테이블

위 이미지를 보시면, 전형적인 정규화된 구조의 예제를 보실 수 있습니다. 브랜드 정보, 카테고리 정보, 제품 정보가 각각 별도의 테이블로 깔끔하게 분리되어 있죠.

브랜드 테이블을 자세히 보면, ‘Samsung’이라는 브랜드는 딱 한 번만 등록되어 있습니다. ‘South Korea’라는 국가 정보 역시 마찬가지로 중복되지 않고 한 번만 존재합니다. 만약 Samsung의 국가 정보가 변경되어야 한다면 바로 이 한 곳만 수정하면 끝나는 거죠. 이것이 바로 정규화가 가진 가장 큰 장점입니다.

반면 비정규화는 아래 이미지처럼 여러 테이블을 하나로 합치는 방식입니다.아래 이미지를 보시면, “Samsung”이라는 브랜드명과 "South Korea"라는 국가명이 여러 행에서 반복됨을 알 수 있죠.이런 현상이 바로 데이터 중복입니다.

비정규화된 테이블

데이터 중복이 발생하는 이유는 위 이미지에서 확인할 수 있듯이, 차원 테이블(Dimension Table)을 분리(정규화)하지 않고 하나의 테이블로 합쳐두었기 때문입니다. 분석 작업을 더 쉽게 하려면 차원을 단순화하는 편이 효과적인데, 이 과정에서 중복된 정보를 여러 행에 반복 저장하게 됩니다. 특히 차원 정보가 방대하거나 계층 구조가 깊을 때는 같은 브랜드명이나 지역명이 반복해서 나타나는 경우가 많아지게 되죠.

데이터가 실제 활용을 위해 준비된 형태는 사실 이렇게 비정규화된 모습입니다. 대시보드나 데이터 분석을 할 때, 그리고 서비스 영역으로 데이터를 전달할 때의 데이터 단에서는 주로 이런 비정규화 구조를 가지게 되죠.

지금까지 정규화와 비정규화의 기본 개념에 대해 살펴보았습니다. 이제부터는 이러한 개념이 실제 데이터 웨어하우스 설계에서 어떻게 이용되는지를 ‘스타 스키마’와 ‘스노우플레이크 스키마’를 중심으로 구체적으로 알아보겠습니다.

스타 스키마 스타 스키마(Star Schema)는 팩트 테이블(Fact Table)을 한가운데에 두고, 여러 차원 테이블(Dimension Table)들이 이 팩트 테이블과 직접 연결된 구조를 의미합니다. 팩트 테이블 안에는 주로 측정되는 값(매출액, 판매 수량 등)과, 각 차원 테이블을 연결하기 위한 키(Key) 정보가 들어 있습니다. 그리고 차원 테이블에는 이 측정값(Fact)을 보다 상세히 설명해주는 다양한 속성들이 담기게 됩니다.

스타 스키마

이 구조는 중앙에 있는 팩트 테이블이 주변의 여러 차원 테이블들로 둘러싸여 있어, 마치 별(Star) 모양처럼 보이기 때문에 ‘스타 스키마’라고 불립니다. 조인(Join)이 단순하기 때문에 쿼리(Query) 속도가 빠르고, 분석하기에 직관적으로 이해하기 쉽습니다. 다만, 차원 데이터가 복잡하고 계층이 깊어질수록 중복된 데이터가 반복적으로 발생할 수 있습니다.

중복이 발생하는 이유는, 앞서 살펴봤듯이 차원 테이블을 별도로 분리(정규화)하지 않고 하나로 합쳐놓았기 때문입니다. 분석을 쉽고 빠르게 수행하려면 차원을 최대한 단순화하여 관리하는 게 좋은데, 그 과정에서 어쩔 수 없이 중복된 정보를 여러 행에 걸쳐 저장하게 되는 겁니다. 차원 정보가 매우 방대하거나 계층 구조가 복잡하고 깊어질수록 동일한 브랜드나 지역 정보가 반복적으로 등장하게 되는 이유가 바로 여기에 있습니다.

하지만 쿼리가 매우 단순하게 작성될 수 있어 분석 작업이 빠르고 쉽다는 장점이 있습니다.

스노우플레이크 스키마 스노우플레이크 스키마(Snowflake Schema)는 스타 스키마에서 차원 테이블을 여러 계층으로 정규화한 구조입니다. 이름 그대로 눈송이(Snowflake)가 중심에서 바깥으로 세부적으로 퍼져 나가는 모양과 유사하기 때문에 이렇게 불립니다. 하나의 차원을 보다 세밀한 테이블로 나누어 데이터를 정리하기 때문에 데이터 중복을 줄일 수 있으며, 데이터가 변경될 때의 관리도 더욱 편리해집니다.

예를 들어, 브랜드 정보는 별도의 ‘브랜드 차원 테이블(Brand Dimension Table)’로, 카테고리 정보는 또 다른 별도의 테이블로 나눌 수 있습니다. 이렇게 테이블을 세분화하면 특정 브랜드에 변경 사항이 발생하더라도 해당 브랜드 차원만 업데이트하면 되므로 더욱 효율적입니다.

아래 이미지는 앞서 스타 스키마에서 살펴본 매출 데이터 웨어하우스의 예시를 스노우플레이크 스키마로 확장한 모습입니다.

스노우플레이크 스키마

복잡해 보이지만 사실 별것 아니고, 차원 테이블(Dimension Table)을 여러 계층으로 더 세밀하게 정규화해 둔 것에 불과합니다.

스타 스키마와 다르게, 차원 테이블이 여러 계층으로 쪼개진 것이 특징입니다. 앞서도 언급했지만, 이름 그대로 눈송이(snowflake)가 중심에서 바깥으로 결정체 모양으로 뻗어 나가듯 여러 단계로 세분화된 구조를 지니고 있어, '스노우플레이크 스키마'라고 부르는 것이죠.

중앙에는 팩트 테이블(FACT_Sales)이 있고, 이와 연결된 주요 차원 테이블들(DATE_DIMENSION, PRODUCT_DIMENSION, STORE_DIMENSION)이 존재합니다. 스타 스키마였다면 여기서 구조가 끝이 났을 텐데, 스노우플레이크 스키마는 여기서 한 단계 더 나아갑니다.

가장 큰 특징은 차원 테이블이 또 다른 차원 테이블로 분리되었다는 점입니다. 스노우플레이크 스키마는 차원을 세분화해 중복을 줄이고 일관성 관리를 쉽도록 하지만, 구조가 복잡해져서 조인이 많아질 수 있습니다. 설계와 유지보수 측면에서도 더 많은 노력이 들 수 있습니다. 사용자나 분석가 입장에서도 테이블이 많으면 관계를 이해하기가 까다롭습니다.

정말 실무에서도 이렇게 하나요? 그런데 지금까지 설명드린 개념들은 사실 조금은 오래된(outdated) 방식이라고 볼 수도 있어요.

ETL, 즉 데이터를 추출(Extract)하고 정제(Transform)하여 적재(Load)하는 일반적인 과정을 그대로 따라서 데이터 웨어하우스(Data Warehouse)를 구축하던 방식에선, 데이터를 어떻게 하면 효율적으로 저장할지 고민하는 것이 2000년대 중반까지는 중요했어요. 당시의 제한적이었던 컴퓨터의 저장 능력과 계산 능력을 고려하여, 데이터를 어떻게 최적화할지에 대한 내용이었죠.

하지만 현대는 상황이 조금 다릅니다.

2010년대 이후의 데이터 처리 환경은 완전히 달라졌어요. 하둡(Hadoop)이나 스파크(Spark)와 같은 분산 처리 기술의 등장으로 데이터 처리 능력이 폭발적으로 향상되었습니다. 테라바이트(TB), 페타바이트(PB) 단위의 대규모 데이터 처리도 가능해졌죠. 그리고 이런 환경에서는 전통적인 ETL 방식이 오히려 데이터 처리 과정에서 병목 현상을 일으키기 시작했습니다.

매일 수십 테라바이트(TB)씩 쌓이는 데이터를 일일이 정규화하고 모델링해서 데이터 웨어하우스(Data Warehouse)에 넣는다고 생각해봅시다. 이 과정에서 얼마나 많은 시간이 걸릴까요?

기업들이 분석 결과를 실시간에 가깝게 빠르게 얻고 싶어 하는 요구가 늘어나는 가운데, 전통적인 ETL 방식으로는 이런 요구사항을 충족시키기가 점점 어려워진 겁니다.

ELT의 등장: “변환은 나중에!” 그래서 등장한 것이 ELT(Extract, Load, Transform) 패러다임입니다. 이 방식은 데이터를 일단 원시(Raw) 형태 그대로 저장해두었다가, 필요할 때 변환(Transform)하여 사용하는 방식이죠. 이는 마치 창고에 모든 물건을 일단 쌓아놓은 다음, 필요할 때 물건을 꺼내 그때그때 가공해서 사용하는 것과 비슷합니다.

ETL: 데이터 → 정제/변환 → 저장 → 분석 ELT: 데이터 → 저장 → 필요시 변환 → 분석

이런 방식이 가능해진 이유는 컴퓨팅 파워와 저장 공간의 비용이 크게 낮아졌기 때문입니다. 이제는 "저장 공간을 아끼기 위해 정규화를 해야 할까?"보다 "분석 속도와 유연성을 위해 비정규화된 형태로 저장할까?"를 고민하는 시대가 된 거죠.

최근에는 데이터 레이크(Data Lake)와 데이터 웨어하우스(Data Warehouse)의 장점을 결합한 '레이크하우스(Lakehouse)' 아키텍처가 주목받고 있어요.

데이터 레이크 : 대량의 원시 데이터를 저비용으로 저장, 유연성 높음 데이터 웨어하우스 : 구조화된 데이터로 빠른 쿼리 및 분석 가능 레이크하우스 : 두 가지 장점을 모두 취함

아파치 아이스버그(Apache Iceberg), 델타 레이크(Delta Lake), 아파치 후디(Apache Hudi)와 같은 오픈소스 프로젝트들은 이런 레이크하우스 아키텍처를 구현하는 핵심 기술입니다. 이 기술들은 데이터 레이크에 테이블 형태의 구조를 부여하여, SQL 쿼리로 빠르게 분석할 수 있게 해줍니다.

분산 처리의 핵심: Spark와 EMR 현대 데이터 처리 환경을 이야기할 때 빼놓을 수 없는 것이 바로 아파치 스파크(Apache Spark)입니다. 스파크(Spark)는 하둡 맵리듀스(MapReduce)의 한계를 뛰어넘어 메모리 기반의 빠른 분산 처리를 가능하게 만든 혁신적인 기술이에요. 특히 데이터 레이크에 저장된 대용량 데이터를 처리할 때 그 진가를 발휘합니다.

이런 스파크 작업을 쉽게 실행할 수 있도록 AWS에서는 EMR(Elastic MapReduce) 서비스를 제공합니다. EMR은 스파크, 하이브(Hive), 프레스토(Presto) 등 다양한 빅데이터 프레임워크를 관리형으로 제공하여, 인프라 관리 부담 없이 대규모 데이터 처리를 할 수 있게 해주죠.

EMR과 Iceberg를 함께 사용하면 S3와 같은 객체 스토리지에 저장된 데이터를 효율적으로 분석할 수 있어요. 예를 들어, 로그 데이터를 S3에 Iceberg 형식으로 저장해두고, EMR Spark 클러스터를 통해 필요할 때만 분석 작업을 수행하는 식으로요.

클라우드 네이티브 분석 플랫폼: BigQuery의 등장 한편, 구글(Google)의 빅쿼리(BigQuery)는 완전히 다른 접근 방식을 제시했습니다. 기존 하둡 생태계처럼 클러스터를 관리할 필요 없이, SQL만으로 페타바이트 규모의 데이터를 분석할 수 있는 서버리스 데이터 웨어하우스예요.

빅쿼리의 가장 두드러지는 특징은 사용한 만큼만 비용을 지불하는 비용 모델과 놀라운 확장성입니다. 데이터 용량이 10GB든, 10TB든 쿼리 결과가 단 몇 초 만에 나오죠. 또한 머신러닝 모델을 SQL 내에서 바로 학습시키고 예측까지 수행할 수 있는 'BigQuery ML' 같은 혁신적인 기능도 제공합니다.

빅쿼리가 레드시프트(Redshift)와 같은 기존 데이터 웨어하우스 솔루션과 근본적으로 다른 점은 바로 '아키텍처'에 있습니다. 빅쿼리리는 처음부터 클라우드를 위해 설계된 완전한 서버리스 아키텍처를 채택했어요.

쉽게 이해하자면, 레드시프트가 '전용 서버'를 임대하는 개념이라면, 빅쿼리는 '필요할 때만 컴퓨팅 파워를 빌리는' 개념이에요. 자동차에 비유하면 레드시프트는 차를 직접 구매하는 방식이고, 빅쿼리는 필요할 때마다 우버(Uber)를 부르는 개념과 흡사하죠.

많은 기업들이 실시간에 가까운 비즈니스 인텔리전스(Business Intelligence)를 위해 빅쿼리를 활용하고 있지만, 세간에서는 빅쿼리의 사용 비용이 상대적으로 비싸다는 이야기가 나오기도 합니다.

마치며 현대의 데이터 분석 환경에서는 데이터의 속도와 다양성, 그리고 분석의 유연성이 더욱 중요해졌습니다. 이제는 “정규화를 얼마나 엄격히 할 것인가?”보다는 “어떻게 하면 데이터를 활용해 더 빠르게 인사이트(Insight)를 얻을 수 있을까?”라는 질문이 보다 중요해진 시대가 되었죠.

결국 회사의 데이터 환경이나 분석 요구사항, 보유한 기술에 따라서 최적의 접근법은 달라질 수 있습니다. 중요한 것은 교과서적인 방법론에 지나치게 얽매이기보다는, 실제 비즈니스의 문제를 효과적으로 해결할 수 있는 실용적인 접근 방식을 선택하는 것이 아닐까 생각합니다.

*ELT와 델타레이크(Data Lake), 레이크하우스(Lakehouse)에 대한 내용은 다음에 따로 글로 정리해서 발행해보겠습니다.