처음 배우는 데이터베이스 14편 | 네트워크형 데이터 모델 - 미소의 그림같은 삶

처음 배우는 데이터베이스 14편

데이터 모델과 관계형 구조 네트워크형 데이터 모델

처음 배우는 데이터베이스 14편 | 네트워크형 데이터 모델

계층형 구조가 가진 한계를 넘어, 하나의 데이터가 여러 관계와 연결될 수 있도록 설계한 모델이 바로 네트워크형 데이터 모델입니다. 오늘 글에서는 네트워크형 모델이 왜 등장했는지, 어떤 구조로 동작하는지, 관계형 데이터베이스와 무엇이 다른지를 차근차근 이해해보겠습니다.

Intro | 왜 네트워크형 데이터 모델을 배워야 할까요?

데이터베이스를 처음 공부하실 때 많은 분들이 관계형 데이터베이스부터 접하십니다. 오늘날 가장 널리 쓰이는 방식이기 때문에 자연스러운 흐름입니다. 그런데 데이터베이스의 역사를 조금 거슬러 올라가 보면, 관계형 모델이 등장하기 전부터 데이터를 체계적으로 저장하고 조회하려는 다양한 시도가 존재했습니다. 그 가운데 중요한 위치를 차지하는 모델이 계층형 데이터 모델과 네트워크형 데이터 모델입니다. 앞선 글에서 살펴본 계층형 모델은 부모와 자식이 한 줄기 나무처럼 연결되는 구조를 가집니다. 구조가 분명하고 빠르게 탐색할 수 있다는 장점이 있었지만, 현실 세계의 관계를 표현할 때 답답한 지점도 적지 않았습니다. 한 학생이 여러 과목을 수강하고, 한 과목에 여러 학생이 참여하는 상황처럼 하나의 데이터가 여러 곳과 동시에 연결되는 장면을 표현하려면 계층형 구조만으로는 무리가 있었기 때문입니다.

네트워크형 데이터 모델은 바로 그 지점에서 등장합니다. 한 데이터가 여러 부모와 이어질 수 있고, 여러 경로를 따라 접근할 수 있도록 설계함으로써 현실의 복잡한 관계를 훨씬 유연하게 담아내려 했습니다. 데이터베이스 이론을 처음 배우는 입장에서는 “지금은 관계형 데이터베이스가 주류인데 굳이 네트워크형 모델까지 알아야 할까?”라는 생각이 들 수 있습니다. 그런데 이 모델을 공부하면 데이터 구조를 바라보는 눈이 넓어집니다. 왜 관계형 모델이 혁신이었는지, 왜 예전 시스템은 구조 변경에 민감했는지, 왜 데이터 접근 경로가 설계의 핵심이었는지 같은 질문에 더 깊이 답할 수 있게 됩니다. 역사 속 모델을 배우는 일이 낡은 지식을 외우는 과정으로 끝나지 않는 이유가 여기에 있습니다.

이번 글에서는 네트워크형 데이터 모델의 기본 정의에서 출발해, 계층형 모델과 다른 점, 핵심 구조인 레코드와 집합 관계의 의미, 실제 시스템에서 어떤 장면에 어울렸는지, 그리고 현대 데이터베이스 학습에서 어떤 의미를 갖는지까지 차례대로 살펴보겠습니다. 글을 끝까지 읽으시면 “네트워크형 모델이 무엇인가”를 아는 수준을 넘어, “왜 그런 구조가 필요했는가”, “무엇을 잘 표현했고 어디에서 어려움이 생겼는가”까지 분명하게 이해하실 수 있을 것입니다.

핵심 요약 1

네트워크형 데이터 모델은 하나의 레코드가 여러 레코드와 복수의 관계를 맺을 수 있도록 설계된 모델입니다.

핵심 요약 2

계층형 모델의 엄격한 트리 구조를 넘어, 다대다 관계를 더 자연스럽게 다룰 수 있다는 점이 큰 장점입니다.

핵심 요약 3

구조가 유연한 대신 접근 경로와 포인터 의존성이 강해, 설계와 유지보수가 까다롭다는 약점도 함께 지닙니다.

네트워크형 데이터 모델의 기본 정의와 등장 배경

네트워크형 데이터 모델은 데이터를 레코드(record) 단위로 저장하고, 레코드와 레코드 사이를 연결 관계로 묶어서 표현하는 모델입니다. 이름에 들어 있는 “네트워크”라는 말처럼, 전체 구조는 한 방향으로만 뻗는 나무가 아니라 여러 점과 선이 연결된 그물망에 가깝습니다. 계층형 모델에서는 한 자식이 하나의 부모에만 소속되는 구조가 일반적이었지만, 네트워크형 모델에서는 하나의 레코드가 여러 상위 레코드와 연결될 수 있습니다. 이런 특징 덕분에 보다 복잡한 업무 관계를 담아내기 쉬워졌습니다.

이 모델이 중요하게 다뤄졌던 배경에는 현실 업무의 복잡성이 있었습니다. 예를 들어 대학 학사관리 시스템을 떠올려 보겠습니다. 한 학생은 여러 강의를 수강할 수 있고, 한 강의에는 여러 학생이 등록할 수 있습니다. 또 한 교수는 여러 강의를 맡을 수 있고, 한 강의는 특정 학과의 교육과정 속에 배치됩니다. 계층형 구조로 억지로 만들면 어느 한쪽을 중심으로 나무를 세운 뒤 다른 관계를 우회적으로 붙여야 했습니다. 설계가 복잡해지고 데이터 중복도 늘어나기 쉬웠습니다. 네트워크형 모델은 이런 다중 연결 관계를 보다 자연스럽게 수용하기 위해 고안되었습니다.

은행 시스템도 좋은 예시가 됩니다. 고객 한 명이 여러 계좌를 가질 수 있고, 공동명의 계좌처럼 하나의 계좌에 여러 고객이 연결되기도 합니다. 또 한 계좌는 다양한 거래 내역과 이어지고, 거래는 지점 정보나 담당 직원 정보와 연결될 수 있습니다. 현실 세계의 관계는 직선적이지 않습니다. 여러 개체가 겹겹이 연결된 상태로 움직입니다. 네트워크형 모델은 그 복잡함을 구조적으로 붙잡아 두려는 시도였다고 보시면 이해가 쉬워집니다.

중요한 포인트
네트워크형 데이터 모델은 “트리 구조의 확장판”으로 보면 편합니다. 다만 뿌리와 가지가 한 줄로 고정되지 않고, 여러 경로를 따라 데이터에 도달할 수 있다는 점에서 훨씬 복잡하고 유연합니다.

핵심 구조: 레코드, 집합 관계, 포인터 중심 접근

네트워크형 모델을 이해할 때 먼저 알아두어야 할 것은 레코드 타입과 집합 타입입니다. 레코드 타입은 비슷한 성격의 데이터를 묶는 단위입니다. 학생 레코드, 과목 레코드, 교수 레코드처럼 생각하시면 됩니다. 그리고 집합 타입은 서로 다른 레코드 간의 관계를 정의하는 장치입니다. 여기에서 보통 owner와 member라는 개념을 사용합니다. 어떤 레코드가 관계의 주체가 되고, 다른 레코드가 그 관계에 소속되는 방식입니다. 다만 한 레코드는 하나의 집합에서는 member가 되면서, 다른 집합에서는 owner가 될 수도 있습니다. 이 지점이 네트워크형 모델을 복합적으로 만드는 핵심입니다.

예를 들어 병원 예약 시스템을 생각해보겠습니다. 의사 레코드와 진료과 레코드, 환자 레코드, 예약 레코드가 있다고 해보겠습니다. 한 진료과에는 여러 의사가 소속되고, 한 의사는 여러 예약과 연결됩니다. 또 환자 한 명도 여러 예약을 가질 수 있습니다. 예약 레코드는 의사와 환자를 이어주는 역할을 담당할 수 있습니다. 이렇게 되면 데이터는 나무처럼 한 방향으로 정렬되지 않고, 서로 다른 관계 집합을 통해 다양한 길로 연결됩니다. 사용자는 의사에서 예약으로, 예약에서 환자로, 환자에서 다시 과거 진료 이력으로 접근할 수 있습니다.

이 과정에서 중요한 것이 포인터(pointer)입니다. 네트워크형 데이터 모델은 레코드 사이의 연결을 포인터로 관리하는 경우가 많았습니다. 말하자면 “어느 레코드 다음에 어떤 레코드가 이어지는지”, “어떤 관계 집합에 속해 있는지”를 직접 가리키는 방식입니다. 컴퓨터 입장에서는 매우 효율적일 수 있습니다. 이미 설계된 경로를 따라 빠르게 이동할 수 있기 때문입니다. 반대로 설계자가 어떤 경로를 중심으로 조회가 일어날지 충분히 고려하지 못하면, 나중에 탐색이 복잡해지고 프로그램도 손을 많이 타게 됩니다.

쇼핑몰 시스템에서도 비슷한 장면을 볼 수 있습니다. 고객, 주문, 상품, 배송, 결제라는 레코드가 있을 때 고객은 여러 주문과 이어지고, 한 주문은 여러 상품과 연결되며, 주문은 결제와 배송 상태와도 함께 연결됩니다. 네트워크형 모델은 이런 다중 관계를 포인터 기반으로 구성해 조회 속도를 높이려 했습니다. 당시 하드웨어 환경과 처리 성능을 고려하면 상당히 실용적인 접근이었습니다. 다만 구조를 이해하는 사람에게는 명확하지만, 구조를 모르는 사람에게는 매우 난해할 수 있습니다. 데이터의 의미보다 접근 경로가 앞에 서는 순간, 설계는 강력하면서도 동시에 부담스러워집니다.

네트워크형 모델은 “관계”를 잘 다루지만 “경로”에 민감합니다

관계 자체를 풍부하게 표현할 수 있다는 점은 분명한 강점입니다. 하지만 실제 접근은 미리 정해둔 경로와 연결 구조에 의존하는 경우가 많아, 설계 변경이 잦은 환경에서는 관리 부담이 커질 수 있습니다.

계층형 모델과의 차이, 그리고 왜 더 유연하다고 평가받았을까요?

계층형 모델과 네트워크형 모델은 모두 관계형 데이터베이스 이전 세대의 대표적인 데이터 모델입니다. 두 모델 모두 데이터를 구조적으로 정리하고, 미리 설계한 연결을 통해 빠르게 탐색하려 했다는 공통점을 가집니다. 다만 계층형 모델은 부모와 자식이 위아래로 정렬된 트리 구조가 핵심이어서, 한 자식이 복수의 부모를 갖는 상황을 자연스럽게 다루기 어렵습니다. 반면 네트워크형 모델은 레코드가 여러 관계 집합에 동시에 참여할 수 있어 현실 업무에 더 가까운 장면을 그릴 수 있습니다.

수강신청 시스템을 다시 예로 들면 차이가 더 분명해집니다. 계층형 모델에서는 학과 아래 교수, 교수 아래 강의, 강의 아래 수강학생 같은 방식으로 트리를 잡을 수 있습니다. 그런데 학생 중심으로 조회하려고 하면 불편해집니다. 한 학생이 여러 강의를 듣는 구조를 정리하려면 중간에 별도의 장치를 두거나 같은 정보가 반복 저장될 가능성이 커집니다. 네트워크형 모델은 학생과 강의 사이를 별도 관계로 연결할 수 있으므로 다대다 구조를 훨씬 설득력 있게 표현합니다. 조회 경로도 학생에서 강의로, 강의에서 학생으로, 교수에서 강의로 이동할 수 있습니다.

공공행정 시스템에서도 같은 차이를 확인할 수 있습니다. 주민, 민원, 담당 부서, 처리 이력, 관련 법령 정보가 연결된 구조를 생각해 보겠습니다. 계층형 방식은 어느 하나를 중심으로 나무를 세워야 하므로, 주민 중심 구조로 설계하면 부서 중심 분석이 어려워질 수 있고, 부서 중심 구조로 설계하면 주민 이력 추적이 번거로워질 수 있습니다. 네트워크형 모델은 하나의 민원이 주민과 부서, 처리 이력, 관련 서류와 동시에 관계를 맺는 식으로 표현할 수 있어서 행정 업무의 실제 흐름을 반영하기에 더 적합했습니다.

다만 더 유연하다는 평가가 곧 더 쉽다는 뜻은 아닙니다. 구조가 복잡해질수록 설계자는 전체 관계망을 머릿속에 그릴 수 있어야 하고, 프로그래머는 어느 경로로 데이터에 접근할지 세밀하게 지정해야 했습니다. 자유도가 높아질수록 책임도 커진다고 볼 수 있습니다. 네트워크형 모델은 계층형보다 표현력이 풍부했지만, 그만큼 관리 난도가 높아졌습니다. 이 점이 훗날 관계형 모델이 환영받은 배경 가운데 하나로 이어집니다.

비교 항목	계층형 데이터 모델	네트워크형 데이터 모델
기본 구조	트리 구조	그물망 구조
부모-자식 관계	자식은 보통 하나의 부모에 소속	하나의 레코드가 여러 관계에 참여 가능
다대다 관계 표현	표현이 까다로움	비교적 자연스러움
접근 방식	상하 구조 중심 탐색	포인터와 관계 경로 중심 탐색
설계 난도	비교적 직관적	복잡하고 정교함이 요구됨

표만 보면 네트워크형 모델이 계층형 모델보다 더 발전된 형태처럼 보일 수 있습니다. 실제로 표현력 측면에서는 한 걸음 나아간 모델이라고 볼 수 있습니다. 다만 실무에서는 “표현이 가능하다”와 “관리하기 쉽다”가 서로 다른 문제입니다. 계층형은 제한이 많은 대신 구조가 선명하고, 네트워크형은 유연한 대신 전체 관계망을 이해해야 합니다. 두 모델의 차이는 우열보다도, 어떤 문제를 어떤 방식으로 해결하려 했는가에 더 가깝습니다.

네트워크형 모델의 장점과 한계

먼저 장점부터 보겠습니다. 네트워크형 데이터 모델은 복잡한 현실 관계를 비교적 충실하게 담아낼 수 있습니다. 학생과 과목, 고객과 계좌, 환자와 예약, 주문과 상품처럼 다대다 관계가 반복적으로 나타나는 장면에서 강점을 발휘합니다. 또 포인터를 활용한 직접 접근 방식은 특정 경로가 정해져 있을 때 빠른 처리에 도움이 됩니다. 대용량 처리 환경에서 저장 구조와 접근 경로를 세밀하게 설계하던 시기에는 상당히 매력적인 모델이었습니다.

반면 한계도 뚜렷합니다. 가장 큰 어려움은 구조 의존성입니다. 데이터의 내용과 프로그램 로직이 연결 구조에 깊게 묶이기 쉽습니다. 설계를 조금만 바꾸어도 응용 프로그램을 함께 수정해야 할 가능성이 커집니다. 관계형 데이터베이스에서는 SQL을 통해 “무엇을 원하는지”를 비교적 선언적으로 표현할 수 있지만, 네트워크형 모델에서는 “어떤 길을 따라 어디로 갈지”를 더 구체적으로 다뤄야 하는 경우가 많았습니다. 그만큼 개발과 유지보수 부담이 늘어납니다.

또 교육 관점에서도 난도가 높습니다. 초보자는 데이터의 의미를 먼저 이해해야 하는데, 네트워크형 모델은 구조와 연결 규칙을 동시에 익혀야 합니다. 한 레코드가 어떤 관계 집합에 속하는지, 어느 경로로 접근하는지가 중요하기 때문에 설계 문서를 충분히 읽지 않으면 전체 모습을 파악하기 어렵습니다. 시스템이 오래 운영될수록 관계 구조가 누적되어, 신규 인력이 업무를 익히는 데 시간이 더 걸릴 수도 있습니다.

예를 들어 오래된 기업의 재고·물류 시스템을 떠올려 보겠습니다. 공급업체, 창고, 품목, 입출고 기록, 발주 정보가 복잡하게 얽혀 있는 경우 네트워크형 구조는 특정 운영 절차를 빠르게 처리하는 데 강점을 줄 수 있습니다. 하지만 유통 채널이 늘어나거나 온라인 판매 경로가 추가되면서 구조를 바꾸어야 할 때는 문제가 커질 수 있습니다. 기존 연결을 어디까지 유지하고, 새 관계를 어떤 방식으로 확장할지 판단하기가 쉽지 않기 때문입니다. 구조가 촘촘할수록 변경 비용도 커집니다.

유연한 모델이 항상 편한 모델은 아닙니다

네트워크형 모델은 복잡한 관계를 품을 수 있지만, 그 복잡함이 설계와 운영의 부담으로 되돌아오기도 합니다. 데이터베이스 이론에서는 늘 “표현력”과 “관리 용이성” 사이의 균형을 함께 보아야 합니다.

관계형 데이터베이스와 비교하면 무엇이 다를까요?

오늘날 데이터베이스를 공부하는 분들에게 가장 중요한 비교 대상은 관계형 데이터베이스입니다. 관계형 데이터베이스는 데이터를 표 형태의 릴레이션으로 표현하고, 키를 통해 관계를 맺습니다. 반면 네트워크형 모델은 레코드 간 연결을 구조 속에 직접 내장하는 성격이 강합니다. 이 차이는 매우 큽니다. 관계형 모델에서는 데이터 구조와 접근 방식이 어느 정도 분리됩니다. 사용자는 SQL로 원하는 조건을 말하고, DBMS가 적절한 실행 계획을 찾아 처리합니다. 하지만 네트워크형 모델에서는 접근 경로가 설계와 프로그램에 더 깊게 들어가 있습니다.

병원 예약 예시로 다시 비교해보겠습니다. 관계형 데이터베이스라면 환자 테이블, 의사 테이블, 예약 테이블을 두고 외래키로 연결하면 됩니다. 그리고 “특정 의사의 이번 주 예약 환자 목록”이나 “환자별 최근 진료 이력” 같은 질문을 SQL 질의로 비교적 유연하게 작성할 수 있습니다. 네트워크형 모델에서는 같은 정보를 훨씬 직접적인 경로로 따라갈 수 있지만, 구조와 경로를 사전에 세밀하게 설계해야 합니다. 질문이 바뀌거나 새로운 분석 요구가 생기면 경로 중심 설계의 약점이 드러날 수 있습니다.

물론 네트워크형 모델을 과거의 낡은 방식으로만 볼 필요는 없습니다. 오늘날 그래프 데이터베이스를 공부할 때도 “데이터와 데이터 사이의 연결을 어떻게 다룰 것인가”라는 질문이 다시 중요해집니다. 기술적 구현과 이론적 배경은 다르지만, 관계 그 자체를 중요한 정보로 본다는 점에서는 학습적 연결고리가 있습니다. 그래서 네트워크형 모델을 공부하면 현대 데이터 기술을 바라볼 때도 도움이 됩니다. 데이터베이스의 진화는 이전 세대를 부정하면서만 진행된 것이 아니라, 이전 모델이 풀고자 했던 문제를 더 나은 방식으로 재구성하는 과정이기도 했습니다.

실무 체크포인트

• 네트워크형 모델은 다대다 관계가 많은 업무를 표현하는 데 강점을 가집니다.
• 포인터와 경로 설계가 중요하므로, 구조 문서화가 매우 중요합니다.
• 요구사항 변경이 잦은 환경에서는 유지보수 비용이 커질 수 있습니다.
• 관계형 데이터베이스가 왜 널리 확산되었는지 이해하는 데 좋은 비교 기준이 됩니다.

기억해 둘 점

네트워크형 데이터 모델의 핵심은 “하나의 데이터가 여러 관계 속에 들어갈 수 있다”는 데 있습니다. 이 관점을 붙잡고 보면 계층형 모델과의 차이도 훨씬 선명해지고, 관계형 데이터베이스가 제시한 추상화의 가치도 더 깊이 이해할 수 있습니다.

용어사전

레코드(record) : 하나의 데이터 단위를 나타내는 저장 구조입니다. 학생 한 명, 고객 한 명, 주문 한 건처럼 개별 정보를 담습니다.

레코드 타입(record type) : 같은 성격의 레코드를 묶는 논리적 유형입니다. 학생 레코드 타입, 과목 레코드 타입처럼 이해하시면 됩니다.

집합 타입(set type) : 레코드와 레코드 사이의 연결 관계를 정의하는 단위입니다.

owner / member : 집합 관계 안에서 주체가 되는 레코드와, 그 관계에 속하는 레코드를 구분하는 개념입니다.

포인터(pointer) : 연결된 다음 레코드나 관계 위치를 가리키는 참조 정보입니다. 네트워크형 모델의 탐색 효율성과 구조 의존성을 함께 만들어내는 핵심 요소입니다.

FAQ

Q1. 네트워크형 데이터 모델은 지금도 사용되나요?
전통적인 형태로는 예전보다 비중이 많이 줄었습니다. 다만 역사적 이해 측면에서 매우 중요하고, 복잡한 연결 구조를 다루는 현대 기술을 이해할 때도 배경 지식으로 도움이 됩니다.

Q2. 계층형 모델보다 무조건 더 좋은가요?
표현력은 더 풍부하지만 관리가 더 쉽다고 말하기는 어렵습니다. 어떤 구조를 얼마나 자주 바꿔야 하는지에 따라 평가가 달라집니다.

Q3. 관계형 데이터베이스와 가장 큰 차이는 무엇인가요?
관계형 데이터베이스는 데이터를 표와 키 중심으로 다루고, 질의를 선언적으로 작성할 수 있습니다. 네트워크형 모델은 연결 구조와 접근 경로가 더 직접적으로 설계에 반영됩니다.

Q4. 초보자도 꼭 알아야 하나요?
시험이나 전공 수업을 준비하신다면 꼭 알아두시는 편이 좋습니다. 현대 DBMS만 공부할 때보다 데이터베이스 이론의 흐름이 훨씬 선명해집니다.

참고자료 성격의 안내

네트워크형 데이터 모델은 시험 대비용 암기 항목으로만 접근하면 금방 헷갈립니다. 계층형 모델, 관계형 모델과 나란히 놓고 비교하면서 “어떤 관계를 더 잘 표현하는가”, “구조 변경에 얼마나 민감한가”, “접근 경로를 누가 결정하는가”를 함께 보시면 훨씬 오래 기억에 남습니다.

네트워크형 데이터 모델은 데이터베이스 역사에서 매우 의미 있는 전환 지점입니다. 계층형 모델이 제공한 정돈된 구조를 넘어, 현실 세계의 복잡한 관계를 더 풍부하게 담아내려는 시도가 이 모델 안에 들어 있습니다. 학생과 과목, 고객과 계좌, 환자와 예약처럼 실제 업무는 늘 여러 연결을 동반합니다. 네트워크형 모델은 그 복잡한 관계를 무시하지 않고 데이터 구조 속에 적극적으로 반영하려 했습니다. 그래서 데이터베이스 이론을 배우는 과정에서 이 모델을 만나게 되면, 과거 기술의 한 장면을 보는 것이 아니라 “데이터를 어떻게 이해할 것인가”라는 오래된 질문과 마주하게 됩니다.

동시에 이 모델은 표현력이 커질수록 설계와 운영이 얼마나 어려워질 수 있는지도 잘 보여줍니다. 복잡한 관계를 담을 수 있다는 장점은 분명 매력적입니다. 하지만 구조가 복잡해질수록 프로그램은 경로에 더 민감해지고, 요구사항 변화에 대응하는 일도 더 어렵게 됩니다. 이 지점에서 관계형 데이터베이스가 왜 큰 전환으로 받아들여졌는지를 이해할 수 있습니다. 관계형 모델은 연결 구조를 좀 더 추상화하고, 사용자가 원하는 결과를 중심으로 질의할 수 있도록 길을 열어주었습니다. 네트워크형 모델을 배우는 일은 관계형 모델의 가치까지 함께 배우는 길이라고 해도 좋습니다.

다음 학습에서는 관계형 데이터 모델로 넘어가 보시면 아주 좋은 흐름이 됩니다. 네트워크형 모델에서 보았던 복잡한 연결 관계가 관계형 모델에서는 테이블과 키로 어떻게 재구성되는지 살펴보면, 데이터베이스 개론의 중심축이 한층 또렷하게 잡히실 것입니다. 지금 단계에서는 “네트워크형 모델은 여러 관계를 표현하는 데 강하지만, 구조 의존성이 크다”는 핵심을 먼저 단단히 기억해 두시면 충분합니다.

복잡한 현실의 관계를 담아내려는 시도, 그 중심에 네트워크형 데이터 모델이 있습니다.

시리즈 안내

이 글은 처음 배우는 데이터베이스 시리즈의 14편입니다. 앞선 글에서는 데이터 모델의 개념과 분류, 그리고 계층형 데이터 모델을 살펴보았습니다.

다음 편에서는 관계형 데이터 모델을 다루며, 오늘 살펴본 네트워크형 모델과 비교하면서 현대 데이터베이스의 기본 틀을 더 선명하게 정리해보겠습니다.

여러 갈래로 연결되는 데이터를 이해하는 순간, 데이터베이스 구조를 보는 시야도 훨씬 넓어집니다.