119. DRM (Data Reference Model, 데이터 참조 모델)

⚠️ 이 문서는 대한민국 정부나 거대 기업이 수백 개의 정보 시스템을 지을 때, 각 부처가 자기들 마음대로 '이름', '주소', '결제금액' 같은 데이터를 엑셀이나 DB에 중구난방의 포맷으로 저장하는 끔찍한 사일로(Silo)를 막기 위해, **전 국가(전사)의 데이터 분류 체계, 표준 단어장(메타데이터), 그리고 데이터 교환(API) 형식을 법으로 통일하여 선언해 둔 거대한 '국가 공인 데이터 백과사전'인 'DRM(데이터 참조 모델)'**을 다룹니다.

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

  1. 본질: 앞서 배운 BRM이 '무슨 업무'를 하냐는 것이라면, DRM은 그 업무를 돌릴 때 '어떤 데이터(What Data)'를 주고받으며, 그 데이터의 규격(Type/Length)은 어때야 하는지를 통일하는 규칙이다.
  2. 가치: 이 모델이 없으면 행안부의 주민등록 시스템과 국세청의 세금 시스템이 데이터를 주고받을 때마다 번역기(ETL)를 새로 짜느라 수백억의 혈세가 낭비된다. DRM을 지키면 전 부처의 데이터가 물 흐르듯 1초 만에 연계되는 데이터 댐(Data Lake)이 완성된다.
  3. 기술 체계: 단순히 단어장만 있는 게 아니라 크게 3덩어리로 나뉜다. 데이터를 카테고리별로 묶는 데이터 분류(Data Classification), '이름=VARCHAR(20)'처럼 규격을 정하는 데이터 구조(Data Structure/Standard), 그리고 남들과 공유하기 위한 데이터 교환(Data Exchange) 모델로 구성된다.

Ⅰ. 바벨탑의 붕괴: 부처별 데이터 사일로(Silo)의 참사

각자 자기 나라 말로 문서를 쓰면 정보 공유는 불가능하다.

  1. 규격 불일치와 데이터 연계의 악몽:
    • 과거 병무청은 남성 데이터를 저장할 때 성별 컬럼을 [성별: 1(남성), 2(여성)] 형태의 숫자로 짰다.
    • 반면 보건복지부는 [GENDER: M(Male), F(Female)] 형태의 영문자로 짰다.
    • 나중에 두 부처의 데이터를 묶어서 '청년 복지 지원 시스템'을 만들려 하자, 1을 M으로 번역하고 2를 F로 바꾸는 복잡한 데이터 변환(Mapping) 스크립트를 밤새워 짜야 했고, 번역 에러로 지원금이 엉뚱한 데 입금되는 사고가 터졌다.
  2. DRM (데이터 참조 모델)의 강력한 통제:
    • 국가(행안부)가 분노하여 '대한민국 공공기관 데이터 표준 사전(DRM)'을 두꺼운 책으로 찍어내어 배포했다.
    • "오늘부터 대한민국 공공 IT 시스템을 개발하는 모든 SI 업체는, DB를 짤 때 성별 컬럼은 무조건 [SEX_CD: 1, 2]라는 표준 코드와 규격만 써야 한다! 어기면 시스템 오픈 안 시켜준다!"

📢 섹션 요약 비유: 세계 각국의 식당들이 자기들 맘대로 재료 이름을 부릅니다. 누구는 'Potato', 누구는 '감자', 누구는 '대지의 사과'라고 적어서, 중앙 창고에서 식재료를 시킬 때 주문이 꼬여서 난장판이 됩니다. DRM은 "앞으로 전국 모든 식당의 장부에는 무조건 통일된 상품 코드 'P-001(감자)'이라고만 적어라"라고 엑셀 양식을 강제로 통일시켜, 전국 식당의 재고를 1초 만에 파악하게 해주는 기적의 장부 규칙입니다.

Ⅱ. DRM의 3대 핵심 기둥 (구조의 해부)

단순한 엑셀 단어장이 아니다. 철학적 분류부터 공유 API 규칙까지 포괄한다.

  1. 데이터 분류 (Data Classification):
    • "국가가 가진 엄청난 양의 데이터를 조각내어 진열장에 묶자."
    • 행정, 복지, 재무, 인사 등 큰 카테고리로 데이터를 묶는다. 이 분류 체계는 앞서 배운 업무 분류표(BRM)와 찰떡같이 매핑된다. (예: BRM[보건복지] 업무를 띄우면 $\rightarrow$ 자연스럽게 DRM[환자 데이터 묶음]이 딸려 나온다.)
  2. 데이터 구조 및 표준 (Data Structure):
    • 현업 개발자(DBA)들이 가장 많이 쳐다보는 곳이다.
    • 데이터 요소(Data Element): '주소', '주민등록번호' 같은 속성값들의 사전.
    • 메타데이터(Metadata): "주민번호 앞자리는 무조건 VARCHAR(6)이다"라는 규격.
    • 이 DRM 카탈로그를 통과하지 않은 엉뚱한 변수명(Addr_new 등)을 DB에 몰래 만들면 데이터 품질 감리에서 100% 적발되어 철퇴를 맞는다.
  3. 데이터 교환 (Data Exchange):
    • "표준을 맞췄으면, 이제 남의 데이터를 쉽게 훔쳐 쓸 수 있게 API를 뚫어라."
    • 데이터를 부처 간에 주고받을 때 XML로 줄지, JSON으로 줄지, REST API 통신 규격은 어떻게 맞출지에 대한 국가 표준 프로토콜을 정의한다.

📢 섹션 요약 비유: 대형 마트(국가)의 물류 시스템을 세팅합니다. 1단계(데이터 분류)로 마트의 코너를 '수산물', '정육', '과일'로 큼직하게 묶어 간판을 답니다. 2단계(데이터 구조)로 모든 삼겹살 팩 뒤에 바코드를 붙일 때 '글자 폰트는 10pt, 무게 표시는 소수점 1자리까지'라는 바코드 인쇄 규격을 강제합니다. 3단계(데이터 교환)로 딴 마트에서 우리 삼겹살을 빌려달라고 할 때, 어느 규격의 택배 박스(XML/JSON)에 담아서 트럭에 실어 보낼지 박스 포장 규칙을 정해두는 3단 콤보입니다.

Ⅲ. 공공 데이터 개방과 마이데이터(MyData)의 기반

내 데이터를 내가 뽑아 쓸 수 있는 핀테크 혁명은 이 뼈대 위에서 피어났다.

  1. 오픈 API와 공공 데이터 포털:
    • DRM 덕분에 전국의 모든 공공 데이터(날씨, 부동산, 교통)가 하나로 쫙 정렬되고 통일되었다.
    • 정부는 이를 '공공데이터포털(data.go.kr)'에 모아 OpenAPI 형태로 민간(스타트업)에 활짝 개방했다. 규격이 통일되어 있으니, 대학생 개발자도 1시간 만에 지하철 알림 앱을 뚝딱 만들어 낼 수 있게 된 것이다.
  2. 마이데이터(MyData) 생태계의 숨은 공신:
    • 요즘 유행하는 토스(Toss)나 뱅크샐러드가 1초 만에 내 모든 은행 계좌, 국세청 세금 내역, 국민건강보험공단 진료 내역을 한 화면에 쭉 끌어모아 보여주는 마법의 비결이 무엇일까?
    • 바로 정부와 금융권이 십수 년 전부터 이 DRM(데이터 표준 규격)과 데이터 교환 API 표준을 피 튀기게 맞춰놓았기 때문이다. 이 거대한 보이지 않는 철도망(DRM)이 깔려 있지 않았다면, 내 자산 데이터를 합치는 핀테크(FinTech) 혁명은 결코 일어날 수 없었다.

📢 섹션 요약 비유: 철도청이 전국 모든 기차역의 철로 너비(궤간)를 1,435mm(DRM 표준)로 완벽하게 뜯어고쳐 통일했습니다. 철로 규격이 통일되자마자, KTX 한 대가 서울(국세청)부터 부산(국민은행)까지 한 번도 기차를 갈아타지 않고 다이렉트로 논스톱 질주하며 내 소중한 짐(마이데이터)을 1초 만에 집 앞까지 배달해 줄 수 있게 된 전국구 고속철도망 개통의 기적입니다.