16. 망형 데이터 모델 (Network Model) - 그래프 구조

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

1. 본질: 계층형 모델의 단일 부모 종속성(1:N) 한계를 극복하기 위해, 데이터를 노드(개체)와 간선(포인터)의 유향 그래프(Directed Graph) 형태로 연결하여 N:M(다대다) 관계를 허용한 데이터 모델이다.
2. 가치: 현실 세계의 복잡한 네트워크적 비즈니스 관계를 데이터 무결성을 잃지 않으면서 디스크 레벨의 물리적 연결(Link List)로 정밀하게 구현해냈다.
3. 융합: 고도의 프로그래밍 복잡성으로 인해 관계형 모델(RDBMS)에 패배했으나, 그 밑바탕이 된 '관계 중심의 포인터 순회 탐색' 사상은 현대의 그래프 데이터베이스(Graph DB, Neo4j)로 완벽하게 계승/발전되었다.

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

1960년대 후반, 최초의 상용 모델이었던 계층형 데이터 모델(트리 구조)은 심각한 구조적 병목에 직면했다. 한 학생이 여러 과목을 수강하고 한 과목도 여러 학생에게 수강되는 일상적인 다대다(N:M) 비즈니스 환경에서, 트리 구조는 자식이 단 하나의 부모만 가져야 한다는 규칙 때문에 엄청난 데이터 중복 저장과 갱신 이상(Anomaly) 현상을 유발했다.

이 복잡한 얽힘 문제를 해결하기 위해 CODASYL(데이터 시스템 언어 위원회) DBTG 그룹은 망형 데이터 모델(Network Data Model)을 제안했다. 이 모델의 핵심 혁신은 자식 레코드가 여러 부모 레코드와 연결될 수 있도록 허용한 것이다. 이를 통해 조직, 사람, 제품, 주문이 거미줄처럼 복잡하게 얽힌 현실 세계를 그래프 형태의 물리적 포인터 묶음으로 추상화할 수 있었다.

그러나 "자유롭게 연결할 수 있다"는 것은 곧 "탐색 구조가 극도로 복잡해진다"는 것을 의미했다. 데이터가 거미줄처럼 얽혀 있어, 데이터를 조회하려면 프로그래머가 복잡한 포인터 경로를 한 치의 오차도 없이 코딩해야만 하는 심각한 데이터 종속성(Data Dependency) 문제를 낳게 되었다.

[그림 1: 망형 데이터 모델의 N:M 그래프 연결 구조 (Owner-Member 체계)]

    [고객 개체: 홍길동]           [고객 개체: 이순신]
           │ └─────────┐         ┌─────────┘ │
           │           │         │           │
 (Member 링크)        (다중 부모 허용 구조)   (Member 링크)
           ▼           ▼         ▼           ▼
      [계좌_A]       [계좌_B (공동계좌)]     [계좌_C]
           │                 │               │
           └───────┐         │      ┌────────┘
                   ▼         ▼      ▼
                 [은행 지점: 강남 본점]

이 도식은 한 계좌(계좌_B)가 고객 홍길동과 이순신이라는 두 개의 부모 노드(Owner)를 동시에 가지며 연결되는 모습을 보여준다. 계층형 모델에서는 불가능했던 다중 상속(N:M 매핑)이 가능해져 중복 데이터 생성을 완벽히 막아낸 혁신적인 상태를 묘사한다. 하지만 이 노드들 간의 선 화살표는 단순한 논리적 개념이 아니라 디스크 내부의 '물리적 포인터 주소 체계'였기 때문에 선 하나가 끊어지면 전체 망이 붕괴되는 리스크를 안고 있었다.

📢 섹션 요약 비유: 망형 데이터 모델은 서울의 복잡한 지하철 환승 노선도처럼, 출발지와 목적지(N:M)를 자유롭게 연결해 주지만 노선이 너무 얽혀있어 처음 보는 사람은 길을 잃기 십상인 거대 미로와 같습니다.

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

망형 데이터 모델은 데이터를 레코드 타입(Record Type)과 레코드 간의 관계를 맺어주는 세트 타입(Set Type)으로 엄격하게 정의한다. 이를 구현하기 위해 복잡한 환형 연결 리스트(Circular Linked List) 자료구조를 엔진 내부에 차용한다.

다대다(N:M) 구현의 핵심: 교차 레코드 (Intersection Record) 망형 모델도 순수하게 M:N 포인터를 직접 그리면 무한 루프나 교착에 빠진다. 따라서 실무 설계에서는 M:N 관계를 두 개의 1:N 세트로 쪼개고, 그 중간에 물리적인 '교차 레코드(연결 노드)'를 두어 해결했다. 이는 훗날 관계형 DB의 '매핑 테이블(Mapping Table)' 설계 기법의 직접적인 원형이 되었다.

[그림 2: 망형 데이터베이스 내부의 환형 연결 리스트(Circular Linked List) 탐색 포인터 체계]

[오너 레코드: IT 부서] ──────────────────────────┐ (First Pointer)
       ▲                                         │
       │                                         ▼
(Owner Pointer)   ┌─(Next)─> [멤버: 홍개발] ─(Next)─> [멤버: 김운영]
       │          │                              │
       └─(Prior)──┘<─────────(Prior)─────────────┘

* 개발자 탐색 쿼리:
  1. FIND ANY 부서 USING 'IT 부서'
  2. FIND FIRST 사원 WITHIN 부서_사원_세트
  3. FIND NEXT 사원 WITHIN 부서_사원_세트 (조건 충족 시까지 루프)

이 구조도는 겉보기에는 단순한 집합처럼 보이지만, 실제 스토리지 엔진 내부에서는 오너와 멤버가 'First, Next, Prior, Owner'라는 4중 포인터 체인으로 강하게 결합되어 있음을 드러낸다. 이런 포인터 탐색 구조의 치명적인 병목은 애플리케이션 코드가 물리적 포인터 이름과 경로 순서에 100% 종속된다는 것이다. 만약 성능을 위해 디스크 포인터 구조를 재배열하면, 모든 애플리케이션의 FIND NEXT 반복문 코드를 전면 수정해야 하는 악몽(데이터 종속성 심화)이 펼쳐진다.

📢 섹션 요약 비유: 친구 집을 찾아갈 때 "서울시 강남구 123번지(SQL)"를 입력하는 게 아니라, "역에서 내려서 왼쪽으로 100m 걷고 두 번째 골목 우회전(포인터 순회)"하라는 지시서를 개발자가 직접 쓰는 셈입니다. 길 공사(DB 구조 변경)가 나면 지시서를 다 폐기해야 합니다.

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

망형 모델의 실패와 현대 그래프 DB의 부활을 관계형 모델과 비교하여 분석하면, 데이터베이스 아키텍처의 패러다임 이동(Paradigm Shift)을 뚜렷하게 관찰할 수 있다.

왜 망형 모델은 멸망했는가? (트레이드오프 분석) 망형 모델은 CPU 파워가 극히 제한적이던 시절, 디스크에서 레코드를 한 번의 I/O로 빠르게 낚아채기 위해 '성능'에 모든 것을 걸어 '개발 생산성(데이터 독립성)'을 희생한 아키텍처다. 반면 E.F. Codd의 관계형 모델은 하드웨어 성능 발전을 믿고, 포인터를 없애는 대신 수학적 조인(Join) 연산으로 추상화하여 프로그래머를 포인터 미로에서 해방시켰다. 이 생산성의 차이가 승패를 갈랐다.

[그림 3: 관계 표현에 따른 탐색 성능 및 유연성 트레이드오프 매트릭스]

        [데이터 독립성 (유연성 & 생산성)]
               ▲
               │          [RDBMS]
      높음     │         (SQL: 논리적 매칭)
               │                 *
               │
      중간     │                          [Graph DB]
               │                         (패턴 매칭 + 엣지 포인터)
               │                                *
               ├─────────────────────────────────────────> [탐색 성능 (조인 속도)]
               │                  *
      낮음     │          [망형 모델]           (Index-Free 고속 연결)
               │   (하드코딩 포인터 체인)
               ▼

이 분석 그래프는 데이터베이스 역사의 변증법적 진화를 시각화한다. 망형 모델은 탐색 속도는 빠르지만 유연성이 바닥이라 도태되었다. RDBMS는 유연성을 극대화했으나 대량의 딥 조인(Deep Join) 시 성능이 기하급수적으로 저하된다. 현대의 그래프 DB(Neo4j)는 망형 모델의 포인터 연결 성능 아이디어(Index-Free Adjacency)를 차용하되, RDBMS처럼 선언적 질의어(Cypher)를 덧씌워 두 마리 토끼(성능과 유연성)를 모두 잡은 아키텍처 진화의 결과물임을 알 수 있다.

📢 섹션 요약 비유: 망형 모델이 조종석 버튼이 100개인 수동 헬리콥터였다면, RDBMS는 목적지만 누르면 가는 자율주행 자동차입니다. 그리고 현대 그래프 DB는 자율주행 기능에 날개까지 단 플라잉카라 할 수 있습니다.

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

실무에서 직접적인 CODASYL 기반의 망형 DBMS(예: IDMS)를 도입하거나 구축하는 프로젝트는 이제 지구상에 존재하지 않는다. 하지만, 시스템 엔지니어는 관계가 고도로 복잡한(Highly Connected) 데이터를 다룰 때 망형 모델의 아키텍처적 한계와 교훈을 바탕으로 올바른 기술 스택을 선택(Decision)해야 한다.

1. 실무 시나리오: 소셜 네트워크 서비스(SNS) 친구 추천 엔진 구축

• 상황: "나의 친구의 친구 중 나와 같은 학교를 나온 사람"을 찾는 기능(Depth 3 이상의 N:M 조인)을 RDBMS 상에서 구현했으나, JOIN 연산이 3번 이상 중첩되며 카티션 프로덕트가 폭발해 쿼리가 수 분간 정체되는 장애(병목) 발생.
• 판단: 이런 연결 중심(Relationship-Centric)의 쿼리는 RDBMS의 구조적 한계다. 과거 망형 모델이 잘하던 '포인터 직결 탐색' 방식이 필요하다. 따라서 의도적인 반정규화를 무리하게 수행하기보다는, 백엔드 데이터베이스를 그래프 모델(Neo4j, Amazon Neptune 등)로 분리 마이그레이션하여 포인터 순회 방식으로 밀리초(ms) 단위의 응답을 확보해야 강건한 아키텍처가 된다.

2. 객체-관계 매핑(ORM) 설계 시 N+1 문제 대응 판단

• 현상: JPA나 Hibernate를 사용할 때, 부모 엔티티를 조회하면 자식 엔티티들을 가져오기 위해 수십 개의 추가 쿼리가 발생하는 N+1 성능 저하 현상 발생.
• 안티패턴: 망형 모델처럼 객체(Object)의 참조 포인터(Get/Set)를 무한정 따라가며 지연 로딩(Lazy Loading)을 방치하는 행위.
• 해결책: 객체 그래프 네비게이션의 맹점을 끊어내고, RDB의 강점인 집합 연산 능력을 활용하여 Fetch Join 등을 통해 한 번의 SQL로 테이블을 결합(Eager Loading)하여 메모리에 올리도록 아키텍처 튜닝을 지시해야 한다.

[그림 4: 딥 조인(Deep Join) 요건 발생 시 아키텍처 분기 의사결정 트리]

[데이터 요건: 여러 테이블 간의 복잡한 다대다 연결 및 다단계 탐색 필요]
               │
               ▼
[조인의 깊이(Depth)와 탐색 관계의 빈도가 어느 정도인가?]
       ├─ Depth 2~3 이내 (일반적 업무 요건)
       │       ▼
       │  [RDBMS 유지] ──> 중간 매핑 테이블(Intersection) 설계 및 인덱스 튜닝
       │
       └─ Depth 4 이상 또는 관계(연결) 자체가 핵심 비즈니스인 경우 (추천, 사기탐지 등)
               ▼
   [그래프 모델 적용 검토] ──> 과거 망형 모델의 후예인 Neo4j 등 Graph DB 도입
               │               (Index-Free Adjacency로 조인 연산 오버헤드 완벽 회피)

이 의사결정 트리는 데이터의 '관계' 깊이에 따라 RDB로 버틸지, 그래프 기반의 모델로 아키텍처를 전환할지를 결정하는 기준선이다. 조인이 깊어질수록 RDBMS는 지수적인 성능 저하를 겪는 반면, 포인터를 따라가는 망형/그래프 아키텍처는 깊이와 무관하게 선형적인 탐색 속도를 유지한다는 시스템 구조적 차이에 기인한 판단이다.

📢 섹션 요약 비유: RDBMS가 엑셀 표로 된 깔끔한 주소록이라면, 엑셀 표에서 "A의 친구의 동생의 회사 동료"를 찾는 건 눈이 빠지는 작업입니다. 이때는 인물들이 선으로 이어진 마인드맵(그래프/망형 모델) 보드를 꺼내 드는 것이 현명한 판단입니다.

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

데이터베이스 역사에서 망형 데이터 모델은 성능과 기능(N:M 허용)을 위해 복잡성을 통제하지 못한 "안티패턴의 위대한 교보재"로 평가받는다.

1970년대 CODASYL 표준에 의해 주도되었으나, Codd 박사의 논문 "A Relational Model of Data for Large Shared Data Banks"에 의해 철저하게 논파당하며 데이터베이스 기술의 주도권은 '비절차적이고 논리적인(SQL) RDBMS'로 완전히 넘어갔다. 하지만 현대 인공지능(AI)과 빅데이터 시대에 접어들며, 지식 그래프(Knowledge Graph), 시맨틱 웹, 소셜 분석 등 극도로 복잡하게 얽힌 데이터를 초고속으로 실시간 처리해야 하는 요건이 폭증하고 있다. 이에 따라 망형 모델이 1970년대에 꿈꾸었던 "데이터 간의 촘촘한 물리적 연결망"이라는 이상향은, 하드웨어의 눈부신 발전과 선언적 쿼리(Cypher 등) 엔진이라는 새 옷을 입고 **그래프 데이터베이스(Graph Database)**라는 이름으로 화려하게 귀환하여 현대 데이터 아키텍처의 필수 융합 스택으로 자리매김하고 있다.

📢 섹션 요약 비유: 망형 데이터 모델은 시대를 너무 앞서갔지만 조종법이 괴랄하여 외면받았던 '최초의 비행 기계'와 같습니다. 지금은 그 도면을 바탕으로 컴퓨터가 대신 조종해 주는 세련된 첨단 드론(그래프 DB)으로 세상을 날고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

• 계층형 데이터 모델 (Hierarchical Model) | 망형 모델의 이전 세대로, 트리 구조와 1:N 단일 부모 제약이라는 한계를 가졌던 초기 데이터 모델
• 관계형 데이터 모델 (Relational Model) | 망형 모델의 복잡한 포인터를 제거하고 수학적 테이블 집합과 키 매핑으로 대체한 현대 DBMS의 사실상 표준
• 그래프 데이터베이스 (Graph Database) | 망형 모델의 노드-엣지 연결 개념을 현대적으로 계승하여 딥 조인 성능 한계를 극복한 NoSQL 시스템
• 데이터 독립성 (Data Independence) | 망형 모델이 실패한 가장 큰 원인으로, 하드웨어 물리 포인터 구조와 애플리케이션 코드를 분리하는 설계 원칙
• N:M 관계 (다대다 관계) | 망형 모델이 계층형과 달리 허용했던 다중 부모 연결 구조이자, RDB에서는 매핑 테이블을 통해 구현해야 하는 복잡한 비즈니스 요건

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

1. 망형 모델은 친구들과 손과 발을 모두 끈으로 묶어서 거미줄처럼 다 같이 연결된 형태예요.
2. 끈이 연결되어 있어서 누구와 누가 친구인지 선을 따라가면 바로 알 수 있어서 아주 빨라요.
3. 하지만 친구가 늘어날수록 끈이 너무 많이 꼬여서 한 명만 움직여도 모두가 넘어지는 복잡한 문제가 생겨서 지금은 쓰지 않는 방법이 되었어요.