데이터 모델링, 이제 테이블 위로 올려보자!

데이터 모델링, 정말 오래된 이야기죠? 새로운 데이터 모델링 서적이나 연구 조사, 최근 개발 내용들을 찾아보면 더욱 분명해지는 것 같아요. 우리 모두 데이터를 모델링하는 올바른 방법을 가지고 있는지 한번쯤 고민해봐야 할 시점인 것 같아요.

데이터 모델의 주요 목적은 데이터가 비즈니스 규칙에 따라 일관되게 데이터베이스에서 이해되고, 저장되고, 검색되도록 하는 것이에요. 데이터 모델 시각화를 통해 여러 사람, 여러 팀이 더 효율적으로 소통할 수 있다는 장점도 있죠. 효과적인 시각화는 분류, 통일, 지식 완성, 추론 등 높은 수준의 인지 능력을 키워주거든요.

데이터 모델러는 누구일까요?

우리는 모델링을 수용하지만, 그게 먼지 쌓인 기업 저장소에 다이어그램 몇 개 넣어두기 위한 건 아니잖아요.
– 애자일 선언문

원래 요구 사항이 뭐였는지 알아내려고 애쓰다가 마치 '돌려 말하기' 게임하는 느낌 받은 적, 혹시 있으신가요? 데이터 모델은 바로 이런 상황을 방지하기 위해 존재해요. 직관적인 시각화를 통해 지식을 공유하고 엔지니어, QA, 제품 관리자, 데이터 분석가, DevOps, 기술 문서 작성자 간의 커뮤니케이션을 개선할 수 있죠.

애자일이 잘못된 디자인에 대한 변명이 될 수는 없어요. 물론, 우리는 빠르게 움직이고 변화에 적응하며 유연한 시스템을 제공해야 해요. 예전처럼 긴 전체 설계 단계를 감당할 여유는 없지만, 그렇다고 우리의 임무가 쉬워진 건 아니에요. 전체 그림이 어떻게 조화를 이루는지 모르는 채로 퍼즐을 맞춰야 하니까요.

소프트웨어 엔지니어, DevOps, 제품 관리자는 설계 단계가 여러 덩어리로 나뉘기 시작하면서 모델링을 담당하게 되었어요. 모델이 기술자와 비기술자 모두에게 효과적인 의사소통 도구가 되려면 명확하고 이해하기 쉬워야겠죠?

엄격한 스키마와 복잡한 모델링 프로세스를 갖춘 관계형 데이터베이스는 급격한 변화에 적합하지 않아요. 스키마 마이그레이션은 정말이지 누구도 좋아하지 않는 데이터베이스 작업 중 하나죠. 데이터베이스가 활성화되어 프로덕션에 들어가면 쉽게 변경하고 싶지 않을 거예요. 바로 이런 점을 민첩하게 지원하는 데이터 모델이 해결하려는 것이죠. 즉, 데이터 무결성을 유지하면서 지속적인 발전을 지원하는 거예요.

관계형 스키마 추상화 누수

수년 동안 관계형 데이터 모델이 표준이었죠. 그런데 정규화된 관계형 스키마 모델이 논리적 엔터티를 효율적으로 표현할 수 없다면 어떨까요?

스키마를 정규화하면 중복이 줄어들고 이상 현상이 제거돼요. 데이터베이스에 효율적으로 쓰는 것은 바로 여기에 달려있죠. 정규화된 스키마는 중복성이나 중복이 없는 방식으로 구성되는데요. 데이터의 일부가 변경되면 한 곳에서만 변경하면 되고, 변경 사항이 여러 위치에 있는 여러 데이터 복사본에 적용되는지 확인할 필요가 없어요. 하지만, 단순 읽기 쿼리에도 비용이 많이 드는 JOIN 작업이 필요하다는 단점이 있죠.

임피던스 불일치(Impedance mismatch)는 전자 산업에서 채택한 용어로, 객체와 테이블 간의 불일치를 의미해요. 객체 지향 모델은 상속이나 구성을 통해 객체를 연결하는 반면, 관계형 모델은 외래 키로 연결된 테이블 모음이죠. 우리는 ORM을 미들웨어로 사용해서 레이어 간의 차이점을 변환하고 추상화해서 이러한 격차를 해소하고 있어요.

애플리케이션 계층의 객체는 관계형 데이터베이스의 여러 테이블에 나뉘어 저장되죠. 객체가 필요할 때마다 JOIN 테이블을 통해 원래 객체를 생성하게 돼요. 이렇게 데이터를 분할하고 다시 합치는 방식으로 ORM 계층은 데이터베이스의 데이터 구조를 추상화하는 거예요.

Hibernate와 같은 객체 관계형 매핑(ORM) 프레임워크는 이런 변환 레이어에 필요한 반복적인 코드를 줄여주지만, 두 모델 간의 차이점을 완전히 감출 수는 없어요.

데이터는 관계에 기반하며 복잡해요

그렇다면 정규화된 데이터베이스 안에서 다양한 유형의 관계는 어떻게 저장될까요?

일대다/다대일 관계는 별도의 테이블에 저장돼요. '하나' 항목의 각 식별자는 해당 항목에 속한 각 행의 '다' 테이블에 저장되는 방식이죠.

일대다 관계는 관계형이 아닌 스키마에서 "다"를 삽입하거나 중첩하여 구현되는 경우가 많아요. 객체 중첩을 사용하면 한 번의 작업으로 읽고 쓸 수 있어서 임피던스 불일치 문제가 해결되지만, 객체 중첩에 대한 RDBMS 지원은 좋지 않아요.

관계는 관계형 모델과 애플리케이션 개발 프로세스에 복잡성을 더하죠. 다대다 관계를 해결하는 핵심은 두 엔터티를 분리하고, 세 번째 교차 엔터티를 사용해서 두 엔터티 사이에 두 개의 일대다 관계를 만드는 거예요. 교차 엔터티에는 일반적으로 두 연결된 엔터티의 속성이 포함돼요.

RDBMS를 사용해서 거의 모든 경우를 구현할 수 있다는 점은 분명해요. 하지만 이게 정말 일반적인 접근 방식일까요? 계층적으로 중첩된 객체가 저장될 때 중첩된 객체의 깊이를 알 수 없게 돼요. 연결된 도메인 객체를 사용하는 경우, 이러한 관계를 효과적으로 탐색하는 데 어려움을 겪게 되죠.

Graph 모델이 할 수 있는 일

시간이 지날수록 점점 더 많은 영역이 복잡해지고, 객체 간의 관계는 더욱 강력해지고, 세상은 점점 더 상호 연결되고 있어요. 관계를 기본적으로 수용하는 데이터베이스만이 연결을 효율적으로 저장, 처리 및 쿼리할 수 있죠. Graph Database는 모델의 데이터와 함께 연결을 저장해요.

Graph Database에서는 데이터 간의 관계가 데이터 자체만큼 중요해요. 미리 정의된 모델로 데이터를 제한하지 않고 데이터를 보관하기 위한 것이죠. 대신 데이터는 우리가 처음 그리는 것처럼 저장돼요. 각 항목이 다른 항목과 어떻게 연결되거나 관련되는지를 보여주는 거죠.

고도로 상호 연결된 데이터의 경우, 계층적/문서 모델은 어색하고 관계형 모델은 그럭저럭 괜찮지만, Graph 모델이 가장 자연스러워요.

화이트보드 친화적인 모델링

데이터 모델링 구성 요소는 개념적, 논리적, 물리적(대부분의 경우 DB 스키마)이라는 세 가지 독립적인 스키마로 이루어져 있어요.

 

개념 맵은 개념 간의 관계를 시각화하는 도구예요. 개념 매핑은 학습 심리학 분야에서 시작되었고, 격차와 허점을 식별하는 데 유용하며 과학 과목의 학습을 향상시키는 데 도움이 된다는 것이 입증되었어요.

UML 및 엔터티 관계 다이어그램은 비즈니스 측 도구로는 실패했지만, 개념 매핑은 그 자리에서 쉽게 받아들여져요. 개념 매핑을 통해 기업인과 기술 전문가 모두 직관적이고 시각적으로 소통할 수 있죠. 또한 조기 학습에 대한 현재 지식은 개념 지도를 강조하고 있어요.

논리적 데이터 모델

Graph Database가 가장 잘하는 일은 연결된 데이터를 표현하는 거예요. 모델을 표현하는 것은 다음 두 가지 관점을 전달하는 것이죠.

1. 구조(연결성)
2. 의미(정의)

이 두 가지가 함께 맥락을 아주 잘 설명해줘요. Node는 엔터티 유형을 나타내는데, 저는 이걸 비즈니스 객체 유형이라고 부르는 걸 더 좋아해요. Relationship으로 더 잘 알려진 Edge는 연결성을 나타내며, 이름 덕분에 Node에 의미론적 명확성과 컨텍스트를 제공하죠. 개념 맵은 교육 심리학의 경험을 활용해서 설계 단계에서 학습 속도를 높여줘요. 이것이 바로 레이블된 Property Graph 모델이 현재 사용 가능한 최고의 범용 데이터 모델 패러다임인 이유예요. 솔루션 데이터 모델링에 사용되는 Property Graph의 메타모델을 Property Graph로 표현하면 다음 모델과 같아요.

Property Graph는 규범적인 스타일(예: UML에 있는 것과 같은)이 없다는 점에서 개념 맵과 비슷해요. 그러니 마음껏 자신만의 스타일을 찾아보세요. 독자들과 잘 소통했다면, 그걸로 충분한 거예요.

“내 언어의 한계는 내 세계의 한계를 의미합니다.”
– 루트비히 비트겐슈타인

그의 책 Data-Intensive Application Design에서 Martin Kleppmann은 이렇게 말했어요. "데이터 모델은 소프트웨어 개발에서 가장 중요한 부분일 거예요. 왜냐하면 데이터 모델은 작성 방법뿐만 아니라 문제에 대한 우리의 생각에도 큰 영향을 미치기 때문이죠."

수년 동안 관계형 모델링 및 정규화에 초점을 맞춰왔죠. 하지만 제가 쓴 것처럼, 그런 접근 방식에는 문제가 있어요. 정규화된 테이블 컬렉션은 우리가 보드에서 계획한 것과는 거리가 멀거든요. 비즈니스 분석가/데이터 모델러 이외의 다른 사람에게는 엔터티 간의 관계가 명확하지 않죠(Crow’s foot notation - 아시는 분?).

Graph 스키마는 정규화된 테이블 구조에 맞게 데이터 모델을 억지로 끼워 맞추지 않아요. Graph 데이터 모델은 화이트보드에 그려진 모습 그대로 유지되죠! 바로 이 점 때문에 Graph 데이터 모델이 "화이트보드 친화적"이라는 이름을 얻게 된 거예요. 또한 스키마 변경을 피하려고 애쓰기보다는, 당연한 것으로 받아들이고 대비하는 거죠.

Graph 스키마는 직관적이고, 학습하기 쉽고, 의사소통에 용이하며, 보드에 그리는 순간부터 스토리지 레이어까지 일관성을 유지한다는 점에서 이야기할 가치가 있다고 생각해요.

"모든 모델은 틀렸지만, 어떤 모델은 유용하다."
– 조지 박스

참고 자료:

[1] Martin, Data-Intensive Application Design (2017), O'Reilly Media, Inc.

[2] F, Thomas. Graph Data Modeling for NoSQL and SQL (2016), 기술 간행물.

---

• Graph 데이터 모델
• Property Graph

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지