현실의 업무는 어떻게 데이터가 될까? 데이터 모델의 역할

새로운 업무체계를 만들 때 가장 먼저 화면부터 그리는 경우가 있다. 담당자는 익숙한 신청서나 보고서를 펼쳐 놓고 입력칸과 버튼의 위치를 정한다. 화면이 눈에 보이니 일이 빠르게 진행되는 듯하지만, 막상 개발이 시작되면 같은 단어를 두고 서로 다른 뜻으로 이해했다는 사실이 드러난다.

‘장비 상태’가 현재 상태인지 점검 당시의 상태인지, ‘소속’이 장비의 관리부서인지 실제 운용부서인지에 따라 저장해야 할 값과 관계가 달라진다. 처음에는 작은 표현 차이처럼 보였던 문제가 검색, 통계와 다른 체계의 연동 단계에서는 전혀 다른 결과를 만든다.

앞선 글에서는 SQL이 저장된 데이터에 질문하고, 인덱스가 필요한 기록으로 가는 길을 줄이는 원리를 살펴보았다. 그러나 질문이 정확하고 길이 빨라도 현실의 대상을 잘못 나누어 저장했다면 믿을 만한 답을 얻기 어렵다. 데이터 모델은 코드를 작성하기 전에 무엇을 하나의 대상으로 볼지, 어떤 특징을 기록할지, 대상 사이의 관계를 어떻게 남길지를 정하는 설계도다.

한줄 요약
데이터 모델은 현실의 사람·물건·사건과 그 관계를 데이터베이스가 다룰 수 있는 구조로 옮기는 약속이다. 좋은 모델은 표를 보기 좋게 그리는 데서 끝나지 않고 업무의 의미와 규칙을 여러 사람이 같은 방식으로 이해하게 한다.

같은 보고서를 보고도 서로 다른 데이터베이스를 만들 수 있다

정비보고서 한 장에는 장비명, 점검일, 고장 증상, 교체 부품과 담당자가 함께 적힐 수 있다. 종이에서는 한 장이 하나의 업무 단위이므로 자연스럽다. 그렇다고 데이터베이스에도 이 항목을 한 테이블에 그대로 옮겨야 하는 것은 아니다.

장비는 점검이 끝난 뒤에도 계속 존재하고 한 대가 여러 번 정비를 받을 수 있다. 부품 하나가 여러 장비에 사용될 수도 있고, 정비 한 건에 부품이 여러 개 들어갈 수도 있다. 보고서의 모양만 따라가면 장비 정보와 정비 사건, 부품 사용내역이 한 행에 뒤섞인다. 시간이 지나 장비의 소속이 바뀌거나 같은 부품을 두 개 사용하면 어느 값을 반복하고 무엇을 따로 기록해야 하는지 애매해진다.

데이터 모델링은 서식을 복사하는 작업이 아니라 그 안에 섞여 있는 대상을 찾아내는 일에서 출발한다. 장비, 정비, 부품과 담당자는 서로 다른 생명주기를 가진다. 각각을 독립된 대상으로 볼지, 어떤 관계로 연결할지는 업무에서 지켜야 할 규칙을 살펴 결정한다.

이 과정이 빠지면 화면마다 필요한 표를 따로 만들기 쉽다. 정비 화면과 재고 화면이 각자 장비명을 저장하고, 보고서 체계는 또 다른 명칭을 쓰게 된다. 처음에는 개발 속도가 빨라 보이지만 시간이 흐를수록 같은 장비를 가리키는 값이 갈라지고 연동할 때마다 별도의 변환 규칙이 늘어난다.

먼저 이름을 붙일 대상과 그 대상의 특징을 가려낸다

데이터 모델에서는 사람, 주문, 장비와 정비 사건처럼 따로 식별하고 관리할 대상을 엔터티라고 부른다. 엔터티는 반드시 손으로 만질 수 있는 물건일 필요는 없다. 계약, 임무, 장애와 위치 변경처럼 일정한 의미를 가진 사건이나 개념도 독립적으로 관리해야 한다면 엔터티가 될 수 있다.

각 대상이 가진 특징은 속성으로 표현한다. 장비에는 식별번호, 종류, 도입일과 현재 상태가 있을 수 있고, 정비에는 접수 시각, 조치 내용과 완료 시각이 들어갈 수 있다. 여기서 중요한 것은 값을 많이 모으는 일이 아니다. 그 값이 누구의 특징인지 분명하게 정하는 일이다.

정비 당시의 장비 위치를 남겨야 한다면 현재 위치와 같은 속성으로 덮어써서는 안 된다. 현재 위치는 장비의 현 상태이고 정비 당시 위치는 특정 사건이 일어났을 때의 기록이다. 값의 모양이 같더라도 의미와 시간 기준이 다르면 서로 다른 곳에서 관리해야 할 수 있다.

엔터티와 속성을 나누는 기준은 기술자가 혼자 정하기 어렵다. 업무 담당자는 어떤 정보가 실제로 바뀌는지, 무엇을 과거 기록으로 보존해야 하는지 알고 있다. 개발자는 그 규칙이 중복과 모순 없이 저장될 구조를 살핀다. 데이터 모델은 두 관점이 처음으로 구체적으로 만나는 자리다.

선으로 이어 놓았다고 관계가 설명되는 것은 아니다

고객과 주문 사이에는 관계가 있다. 고객 한 명은 주문을 여러 번 할 수 있고 주문 한 건은 특정 고객에게 속한다. 장비와 정비도 비슷해 보이지만 운용 규칙에 따라 달라질 수 있다. 정비 대상이 여러 장비로 구성된 체계 전체일 수도 있고, 정비 한 건에 여러 작업조가 참여할 수도 있다.

따라서 관계를 그릴 때에는 연결 여부뿐 아니라 수량과 필수 여부를 함께 정해야 한다. 고객이 아직 주문하지 않았어도 등록될 수 있는지, 담당자가 없는 장애 접수가 허용되는지, 한 부품이 여러 장비 형식에 쓰일 수 있는지를 확인해야 한다. 이런 규칙이 관계의 모양을 결정한다.

한쪽의 여러 기록이 다른 쪽의 여러 기록과 연결되는 경우에는 관계 자체를 별도의 대상으로 다루기도 한다. 주문과 상품 사이의 주문상세, 정비와 부품 사이의 부품사용내역이 대표적이다. 사용 수량이나 교체 사유처럼 두 대상이 만나는 순간 생기는 값은 어느 한쪽의 속성으로 넣기보다 관계 기록에 두는 편이 자연스럽다.

ERD라고 부르는 개체-관계 다이어그램은 이런 엔터티와 관계를 눈으로 확인하도록 돕는다. 다만 네모와 선을 많이 그리는 것이 목적은 아니다. 선 하나가 실제 업무에서 어떤 약속을 뜻하는지 설명할 수 있어야 한다. 그렇지 않으면 보기에는 정교하지만 누구도 같은 방식으로 해석하지 못하는 그림이 된다.

개념·논리·물리 모델은 같은 설계를 다른 높이에서 본다

데이터 모델은 흔히 개념, 논리와 물리 단계로 나누어 설명한다. 세 단계가 서로 무관한 문서라는 뜻은 아니다. 멀리서 업무의 큰 구조를 보고, 점차 세부 규칙을 더한 뒤, 실제 데이터베이스에 구현할 모양으로 구체화하는 과정에 가깝다.

개념 데이터 모델에서는 조직이 중요하게 관리할 대상과 큰 관계를 확인한다. 장비, 부대, 정비와 부품이 존재하며 서로 어떤 업무 관계를 맺는지를 보여준다. 이 단계에서는 특정 데이터베이스 제품의 자료형이나 인덱스보다 업무의 범위와 공통 언어를 맞추는 일이 우선이다.

논리 데이터 모델은 속성, 식별자, 관계의 수량과 무결성 규칙을 더 구체적으로 정한다. 장비를 무엇으로 식별하고 정비 기록이 어느 장비를 참조하는지, 값이 반드시 있어야 하는지 등을 표현한다. 관계형 데이터베이스라면 정규화를 통해 각 사실의 책임이 알맞게 나뉘었는지도 살핀다. 여전히 특정 제품의 저장공간이나 장비 사양과는 거리를 둔다.

물리 데이터 모델에 이르면 실제 사용할 데이터베이스에 맞추어 테이블명과 열 이름, 자료형, 키, 제약조건과 인덱스를 정한다. 조회량이 큰 테이블을 어떻게 나눌지, 어떤 값을 빠르게 찾게 할지, 저장과 변경 비용은 어느 정도인지도 고려한다. 앞서 살펴본 인덱스가 이 단계에서 구체적인 설계 요소가 된다.

현장에서는 세 단계를 언제나 별도 문서로 완벽하게 만들지는 않는다. 규모가 작은 체계라면 한 모델 안에서 함께 다룰 수도 있다. 그래도 업무의 의미와 기술 구현을 구분해 생각하는 습관은 필요하다. 특정 제품의 열 이름부터 정해 버리면 왜 그 데이터가 필요한지보다 구현 방식이 논의를 끌고 갈 수 있기 때문이다.

현재 상태와 변화의 이력을 구분해야 과거를 복원할 수 있다

장비의 현재 소속만 보여주는 화면이라면 장비 테이블에 소속값 하나를 두는 것으로 충분해 보인다. 하지만 지난달 어느 부대가 운용했는지, 소속이 바뀐 뒤 발생한 장애가 어느 기간에 속하는지 확인해야 한다면 현재 값만으로는 답할 수 없다.

이 경우 소속 변경을 별도의 이력으로 남기고 적용 시작일과 종료일을 관리할 수 있다. 같은 방식으로 장비 상태, 담당자와 설치 위치도 변화 시점을 보존할지 결정해야 한다. 모든 값을 이력으로 만들면 구조와 조회가 무거워지고, 반대로 모두 덮어쓰면 과거 상황을 설명할 근거가 사라진다.

무엇을 이력으로 남길지는 보고서 목록만 보고 정하기 어렵다. 감사와 정산, 장애 분석, 책임 범위와 작전 상황 재구성처럼 시간이 지난 뒤 제기될 질문을 예상해야 한다. 데이터 모델은 현재 화면의 요구만 담는 설계도가 아니라 미래에 어떤 질문에 답할 것인지 정하는 기록이기도 하다.

정보체계 사이의 연동은 데이터 의미가 같을 때 비로소 시작된다

두 체계가 같은 형식의 파일을 주고받는다고 해서 같은 정보를 이해하는 것은 아니다. 한쪽의 ‘가동’이 임무 투입 가능을 뜻하고 다른 쪽에서는 전원이 켜진 상태만 뜻한다면 값의 글자가 같아도 의미는 다르다. 반대로 ‘정상’과 ‘운용 가능’처럼 표현이 달라도 같은 기준을 가리킬 수 있다.

C4I에서는 센서 정보, 표적, 부대, 플랫폼과 임무 같은 대상이 여러 체계를 오간다. 어느 범위까지 하나의 대상으로 볼지, 식별값은 누가 부여하는지, 위치와 시각의 기준은 무엇인지 합의되지 않으면 체계마다 맞는 데이터가 전체에서는 충돌할 수 있다.

데이터 모델은 연동 항목표를 만들기 전 공통 의미를 맞추는 기준이 된다. 각 체계의 구조가 달라도 같은 현실의 대상을 어떻게 표현하는지 비교할 수 있기 때문이다. 이 차이를 확인하지 않은 채 인터페이스만 연결하면 변환 프로그램이 업무의 해석까지 떠맡게 되고, 규칙이 바뀔 때마다 어디를 고쳐야 하는지 찾기 어려워진다.

정보가 빠르게 들어오는 환경일수록 처음의 작은 정의 차이가 크게 번진다. 잘못 연결된 한 건이 다른 화면과 통계, 판단지원 결과로 복제될 수 있다. 데이터 모델링이 개발 초기에만 필요한 산출물이 아니라 체계 운영과 연동 변경 과정에서도 계속 관리되어야 하는 이유다.

짧은 생각
정보체계를 오래 바라보면 화면의 기능보다 이름 하나를 정하는 일이 더 어렵게 느껴질 때가 있다. 이름에는 대상의 범위와 책임, 시간의 기준이 함께 들어가기 때문이다. 설계 단계에서 충분히 묻지 않은 질문은 운영 단계에서 데이터 불일치와 연동 오류의 모습으로 다시 돌아온다.

좋은 모델은 완성된 그림보다 검증 가능한 질문에 가깝다

데이터 모델을 검토할 때에는 도형의 모양보다 실제 업무 질문을 던져 보는 편이 도움이 된다. 장비가 다른 부대로 이동하면 어느 기록이 바뀌는가. 정비 한 건에 부품 여러 개를 사용할 수 있는가. 현재 담당자가 바뀌어도 과거 조치자의 이름을 확인할 수 있는가. 삭제된 대상의 이력은 어떻게 남는가.

답을 모델 안에서 일관되게 찾을 수 없다면 엔터티가 빠졌거나 관계와 시간 규칙이 충분히 표현되지 않았을 가능성이 있다. 반대로 모든 예외를 처음부터 구조에 넣으려다 모델이 지나치게 복잡해질 수도 있다. 실제 업무에서 반드시 지켜야 할 규칙과 드물게 수작업으로 처리할 예외를 구분해야 한다.

지금까지 행과 열, 키, 정규화, SQL과 인덱스를 거쳐 데이터 모델까지 이어졌다. 각각은 별개의 기술처럼 보였지만 현실의 사실을 정확하게 저장하고, 관계를 지키며, 필요한 순간에 다시 꺼내기 위한 하나의 과정이다.

다음 글에서는 잘 설계된 데이터도 체계 밖으로 나가는 순간 왜 다시 의미가 달라질 수 있는지 살펴보려 한다. 형식이 다른 두 시스템이 정보를 주고받기 위해 필요한 데이터 교환과 표준의 원리를 이해하면, 데이터베이스 안의 설계가 C4I와 체계 연동으로 확장되는 길도 보이기 시작할 것이다.