15. 계층형 데이터 모델 (Hierarchical Model) - 트리 구조

핵심 인사이트 (3줄 요약)

본질: 데이터를 나무(Tree) 형태의 계층적 부모-자식(Parent-Child) 구조로 조직화하여, 최상위 루트 노드에서 하위로 내려가는 1:N 관계를 정의한 초창기 데이터 모델이다.

가치: 데이터 검색 경로가 고정(Pointer Navigation)되어 있어 특정 하향식 질의에 대해서는 검색 속도가 극도로 빠르고 예측 가능하다는 장점이 있다.

융합: RDB의 등장으로 DBMS 주류에서는 밀려났으나, XML, JSON 문서 구조, 윈도우 레지스트리, LDAP 디렉터리 서비스 등 현대의 트리 기반 데이터 포맷의 근간이 되었다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

1960년대, 아폴로 우주 계획과 같은 거대 프로젝트를 수행하기 위해 폭발적으로 증가하는 부품(BOM, Bill of Materials) 데이터를 효율적으로 관리할 시스템이 필요해졌다. 당시 천공 카드나 플랫 파일 시스템으로는 연관된 데이터 조각들을 빠르게 찾고 연결하는 데 한계가 뚜렷했다.

이러한 배경에서 IBM은 북미항공우주국(Rockwell)과 협력하여 최초의 상용 DBMS인 IMS(Information Management System)를 개발했다. 이때 도입된 구조가 바로 계층형 데이터 모델(Hierarchical Data Model)이다. 조직도나 가계도처럼 현실 세계의 많은 데이터가 '조직-부서-팀원'과 같이 하향식 종속성을 가지는 것에 착안하여, 모든 데이터를 1:N(일대다) 부모-자식 트리 형태로 모델링한 것이다.

그러나 비즈니스가 고도화되면서 학생이 여러 과목을 듣고(M), 과목도 여러 학생을 받는(N) 다대다(N:M) 관계가 빈번해졌고, 하나의 자식이 무조건 단 하나의 부모만 가져야 한다는 계층형 모델의 엄격한 구조적 한계는 치명적인 데이터 중복과 모델링의 복잡성을 초래하게 되었다.

[그림 1: 계층형 데이터 모델의 트리 아키텍처 (1:N 부모-자식 관계)]

                   [부서] (Root Node) - 부모 개체
                     │
         ┌───────────┴───────────┐ (1:N 관계)
         ▼                       ▼
    [사원_A] (Child)         [사원_B] (Child)
         │                       │
     ┌───┴───┐               ┌───┴───┐ (1:N 관계)
     ▼       ▼               ▼       ▼
 [프로젝트1] [프로젝트2]    [프로젝트1] [프로젝트3]
  (Leaf)      (Leaf)       (중복 발생) (Leaf)

이 도식은 데이터가 상단 루트에서 하위 리프 노드로 뻗어나가는 계층 모델의 본질을 보여준다. 부서 하위에 사원이 종속되고, 사원 하위에 프로젝트가 종속된다. 여기서 핵심적인 문제는 구조의 경직성이다. 만약 다수의 사원이 동일한 [프로젝트1]을 수행할 경우, 계층 구조에서는 해당 프로젝트 데이터가 사원 A 밑에도, 사원 B 밑에도 각각 중복 저장되어야만 하는 데이터 무결성 위협과 공간 낭비 병목이 드러난다.

📢 섹션 요약 비유: 회사의 결재 서류가 무조건 사장 → 부장 → 사원의 단일 수직 계통으로만 움직여야 하고, 타 부서와는 직접 협업할 수 없는 꽉 막힌 군대식 조직도와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

계층형 모델은 내부적으로 데이터 레코드들을 물리적인 포인터(Pointer) 연결 리스트로 관리한다. 따라서 '연산(Operation)' 방식이 SQL처럼 선언적이지 않고, 개발자가 레코드를 하나씩 따라 내려가는 네비게이션 방식(절차적 질의)을 띤다.

핵심 구성 요소	설명	내부 동작 및 특징	비유
루트 개체 (Root Record)	트리 구조의 최상위 진입점	모든 검색은 반드시 루트 노드에서 출발하여 하위 포인터를 따라 내려가야 함	나무의 굵은 기둥 밑동
부모-자식 관계 (Parent-Child)	노드 간의 1:N 종속성 링크	자식 노드는 단 1개의 부모만 가질 수 있으며, 부모 삭제 시 자식도 연쇄 삭제(Cascade)됨	생물학적 단일 유전 가계도
순회 포인터 (Navigation Pointer)	물리적 주소의 연결선	Next-Child, Next-Sibling 포인터를 사용하여 인접 레코드를 절차적으로 탐색	건물 내 일방통행 복도와 계단
삽입/삭제 제약조건	구조 유지를 위한 엄격한 무결성 제약	부모 레코드가 존재하지 않으면 자식 레코드를 아예 삽입할 수 없는 삽입 이상 발생	기초 공사 없이 지붕을 올릴 수 없음

탐색 메커니즘 (전위 순회 - Pre-order Traversal) 계층형 모델에서 시스템이 데이터를 스캔할 때는 트리 자료구조의 전위 순회 방식을 따른다. 루트부터 시작해 왼쪽 자식 노드를 최하단까지 먼저 쭉 훑고, 그다음 형제(Sibling) 노드로 넘어가는 식이다. 이 때문에 데이터가 물리적으로 디스크에 연속해서 저장되는 군집(Clustering) 효과가 발생하여, 동일 부모 아래의 자식들을 일괄 조회할 때 엄청난 성능적 이점을 누린다.

[그림 2: 물리적 포인터 기반의 데이터 탐색 흐름 (Navigation)]

[메모리 상의 포인터 연결]

[부서 레코드: 영업부] ──(Child Pointer)──┐
                                         ▼
                                  [사원 레코드: 김영업] ──(Sibling Pointer)──> [사원 레코드: 이영업]
                                         │                                            │
                             (Child Pointer)                              (Child Pointer)
                                         ▼                                            ▼
                               [매출 레코드: 1월 100만]                    [매출 레코드: 1월 50만]

* 개발자 질의(Code) : "GET 영업부" -> "GET FIRST 사원 UNDER 영업부" -> "GET NEXT 사원" ...

이 흐름도는 계층형 데이터 모델에서 데이터가 실제로 어떻게 물리적으로 연결되고 프로그래머가 이를 어떻게 호출하는지를 묘사한다. 이 구조의 맹점은 데이터 간의 물리적 연결(Pointer) 구조를 응용 프로그래머가 전부 완벽히 알고 있어야만 코드를 작성할 수 있다는 점이다. 즉, 데이터의 물리적 독립성이 완전히 결여되어 있어, DB 구조가 약간만 변경되어도 모든 프로그램의 네비게이션 로직 코드를 전부 재작성해야 하는 유지보수성의 재앙을 낳게 된다.

📢 섹션 요약 비유: 목적지 주소를 검색하면 알아서 경로를 찾아주는 요즘 내비게이션(SQL)과 달리, "앞으로 10보, 왼쪽으로 5보, 계단 한층 내려가기"라는 지시서를 개발자가 직접 한 땀 한 땀 코딩해야 하는 구식 로봇 조종과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

초기 모델인 계층형 모델과 그 한계를 극복하려 등장한 망형 모델(Network), 그리고 최종 승자가 된 관계형 모델(RDBMS)을 비교하면 데이터 독립성 진화의 역사를 알 수 있다.

비교 항목	계층형 모델 (Hierarchical)	망형 모델 (Network)	관계형 모델 (Relational)
논리적 구조	트리 (Tree) - 상하 종속	그래프 (Graph) - 거미줄 연결	2차원 표 (Table) - 독립적 집합
관계 지원	1:1, 1:N (단일 부모)	1:N, N:M (다중 부모 허용)	1:1, 1:N, M:N (교차 테이블을 통한 구현)
데이터 독립성	매우 낮음 (물리적 포인터 종속)	낮음 (여전히 포인터 네비게이션)	매우 높음 (포인터 은닉, 논리적 조인)
질의 언어 형태	절차적 탐색 (GET NEXT)	절차적 탐색 (Find Owner)	비절차적 선언 (SQL SELECT)
성능 (특정 경로)	최고 (포인터 직접 접근 I/O)	우수	상대적 저하 (Join 연산 오버헤드 존재)

데이터베이스의 왕좌는 관계형 모델에 내주었지만, 계층형 모델의 '트리 기반 종속성' 패러다임은 IT 생태계 다른 곳에서 화려하게 부활하여 융합되었다. XML(eXtensible Markup Language)과 JSON(JavaScript Object Notation)이 그 대표적인 예이다. 웹에서 데이터를 교환할 때, 데이터는 자체적으로 태그 중첩(Nested) 구조를 갖는 트리 형태가 네트워크 직렬화 및 파싱에 훨씬 직관적이고 빠르기 때문이다.

[그림 3: 계층형 모델의 구조적 제약(삽입/삭제 이상) 발생 시뮬레이션]

상황: 신입사원 '최신입'이 아직 어떤 부서에도 배치되지 않음.

[계층형 모델 DB]
  [루트 부서] ──> (없음: NULL)
       │ (자식 연결 불가!)
       ▼
   [신입사원] (오류! 부모 레코드가 없으면 자식 노드를 시스템에 입력조차 할 수 없음)

=> 해결책 억지 구현: 가상의 더미 부서(Dummy Dept)를 만들어 강제로 연결해야 하는 쓰레기 데이터 양산 문제 발생.

이 매트릭스 도해는 계층 모델이 갖는 최악의 병목인 '이상 현상(Anomaly)'을 적나라하게 보여준다. 트리의 구조적 무결성 규칙(부모 없는 자식은 존재할 수 없다)이 너무 엄격하여 유연한 비즈니스 상황(부서 미배정 사원)을 수용하지 못한다. 반대로 부서를 삭제하면 멀쩡한 사원 데이터까지 연쇄 삭제되는 현상은 현대 데이터 모델링에서 가장 경계하는 안티패턴이다.

📢 섹션 요약 비유: 서류를 파일 폴더(부모) 안에 종이(자식)로 끼워 넣는 방식입니다. 새 문서를 샀는데 아직 넣을 폴더를 안 정했다고 해서 서랍에 보관조차 할 수 없는 황당한 상황과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

오늘날 새로운 정보 시스템을 구축할 때 계층형 DBMS(IMS 등)를 채택하는 경우는 메인프레임 레거시 시스템 유지를 제외하고는 전무하다. 그러나 시스템 아키텍트와 개발자는 계층형 구조가 갖는 '압도적인 부분 검색 속도'의 이점을 살려 특정 실무 도메인에 트리 구조 데이터 모델을 적극 차용(Decision)한다.

1. 실무 시나리오: 조직도 및 권한 인증 인프라 구축 (LDAP)

상황: 사내 5만 명 직원의 조직 정보(본부-실-팀-사원)와 접근 권한을 초당 수천 번씩 조회하는 인증 시스템(SSO) 설계. 관계형 DB 조인 시 성능 저하 우려.
판단: 이런 하향식 읽기 전용(Read-heavy) 및 트리 탐색 요건에는 RDB보다 계층형 디렉터리 구조를 띄는 **LDAP(Lightweight Directory Access Protocol) 서버(Active Directory 등)**를 도입하는 것이 정답이다. 최상위(DC)부터 단위 조직(OU)을 거쳐 사용자(CN)로 이어지는 계층적 식별자(DN) 구조가 인증 쿼리의 레이턴시를 최소화한다.

2. 실무 시나리오: NoSQL Document 설계의 중첩(Embedded) 구조 판단

상황: MongoDB 환경에서 '블로그 게시글'과 '댓글' 데이터를 어떻게 모델링할 것인가?
판단: 댓글이 다른 게시물에 공유될 일(N:M)이 전혀 없고 오직 해당 게시글(1)에만 강하게 종속(N)된다면, 관계형의 분리된 테이블 설계 대신, 하나의 도큐먼트 안에 댓글 배열을 통째로 밀어넣는 계층적 임베디드(Embedded) 패턴을 사용하는 것이 디스크 읽기 I/O 횟수를 1회로 줄이는 최적의 모델링이다.

[그림 4: 현대 시스템에 계승된 계층형 구조의 실무 적용 흐름도]

[비즈니스 데이터 요건 분석]
            │
            ▼
[다대다(N:M) 관계인가? 상태 변경(Update)이 잦은가?]
     ├─ 예 ──> [관계형 RDBMS 또는 Graph DB 도입] (정규화, 테이블 조인)
     │
     └─ 아니오 (1:N 종속성 명확, 읽기 위주의 하향 탐색)
            ▼
[어떤 계층형 파생 기술을 도입할 것인가?]
     ├─ 설정/인증 정보 ──> [LDAP / Registry] (트리 구조의 빠른 경로 검색)
     ├─ 문서/API 교환 ──> [JSON / XML] (중첩된 노드 직렬화/파싱 최적화)
     └─ NoSQL 데이터 ──> [MongoDB 중첩 모델] (부모 도큐먼트 내 자식 배열 포함)

이 의사결정 트리는 계층형 모델의 한계 때문에 RDB가 표준이 되었지만, 특정 조건(1:N 종속, 하향 탐색, 읽기 집중)이 완벽히 맞아떨어질 때는 트리형 데이터 구조(JSON 중첩, LDAP 등)를 부분적으로 혼용하는 것이 성능상 유리하다는 아키텍처 판단 기준을 제시한다.

📢 섹션 요약 비유: 단일 레일로만 움직이는 구형 기차(계층형)는 복잡한 도심 교차로(관계형)에서는 쓸모없지만, 공항 터미널 간 직통 셔틀(1:N 고정 검색)로 쓸 때는 그 어떤 교통수단보다 빠르고 효율적입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

데이터 독립성의 부재, 다대다 관계 표현의 불가, 프로그래밍의 복잡성이라는 세 가지 치명적 단점으로 인해, 범용 DBMS로서의 계층형 데이터 모델 시대는 1980년대 관계형 모델의 등장과 함께 종말을 고했다.

하지만 컴퓨터 과학의 역사에서 사라진 기술은 없다. 계층형 모델이 제시했던 "부모로부터 자식으로 이어지는 물리적 인접 배치(Clustering)"와 "루트-리프를 잇는 고속 경로 탐색(Navigation)" 철학은, 오늘날 NoSQL의 도큐먼트 지향 모델과 객체 파일 스토리지(S3 등)의 폴더-파일 구조에 그대로 계승되어 살아 숨 쉬고 있다. 기술사적 관점에서 우리는 과거 실패한 모델을 무조건 배척할 것이 아니라, 그 아키텍처가 어떤 환경적 요건(초고속 하향 탐색)에서 빛을 발하는지 이해하고 현대 시스템 설계의 '무기' 중 하나로 다용(多用)할 줄 알아야 한다.

📢 섹션 요약 비유: 구형 진공관 라디오(계층형 DBMS)는 스마트폰(RDBMS)에 밀려 사라졌지만, 그 속에 쓰이던 증폭 기술(트리 탐색)의 원리는 오늘날 최고급 하이엔드 오디오(LDAP, NoSQL)의 핵심 부품으로 화려하게 부활한 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

망형 데이터 모델 (Network Model) | 계층형의 단일 부모 제약을 허물고 다중 부모(N:M)를 허용하도록 진화한 그래프 형태의 후속 데이터 모델
데이터 독립성 (Data Independence) | 계층형 모델이 확보하지 못했던, 물리적 포인터 구조가 변해도 프로그램 코드를 수정하지 않아도 되는 특성
임베디드 도큐먼트 (Embedded Document) | 현대 NoSQL(MongoDB)에서 부모 데이터 안에 자식 데이터를 배열로 중첩시키는, 계층형 모델의 직접적 후예 패턴
LDAP (Lightweight Directory Access Protocol) | 분산 환경에서 사용자 및 자원 정보를 계층적 트리 구조로 관리하고 고속으로 검색하기 위한 프로토콜
B-Tree | DBMS의 인덱스 자료구조로, 계층형 모델과 유사한 트리 구조를 이용하여 노드 단위의 검색을 최적화하는 물리적 기술

👶 어린이를 위한 3줄 비유 설명

계층형 모델은 할아버지 밑에 아빠, 아빠 밑에 나만 올 수 있는 엄격한 족보(가계도) 방식이에요.
위에서 아래로 순서대로 찾아가니까, 아빠를 알면 내 정보를 1초 만에 아주 빨리 찾을 수 있어요.
하지만 치명적인 단점이 있는데, 엄마 쪽 가족(다대다 연결)은 이 족보에 같이 그릴 수가 없어서 시대가 지나며 사라지게 되었답니다.