[Data Modeling] 강대웅의 데이터 세상 열기! - 2편

[Data Modeling] 강대웅의 데이터 세상 열기! 1편 - 보기  

3. 자연으로부터 배우는 지혜, Subtyping

프로젝트와 데이터 기술력 증진(?)에 매몰되어 있던 직원들에게 정서적 안정을 부여하고 감성을 고양하기 위해 ‘자연으로부터 배우는 지혜’라는 주제로 행사를 한 바 있다.

아래 사진은 본 행사에서 동료들이 보았던 풍경의 한 조각이다. 무엇이 보이는가?

 

필자의 눈에는 문득, Supertype Entity와 Subtype Entity가 보였다.고 하면 정신병자, 워커홀릭, 또는 데이터홀릭 소리를 들을지도 모르겠다. 그 날 숲해설사로부터 들었던 나무들의 이름을 열거해보면, 향나무, 소나무, 해송, 금송, 백목련, 자목련, 참나무, 상수리나무, 굴참나무, 갈참나무, 졸참나무, 떡갈나무, 신갈나무, ...

 

이 나무들을 분류해보면,

 

향나무

소나무: 해송, 금송

목련: 백목련, 자목련

참나무: 상수리나무, 굴참나무, 갈참나무, 졸참나무, 떡갈나무, 신갈나무

 

이렇게 열거해 놓으면 Supertype Entity와 Subtype Entity를 연상해 볼 수 있겠는가…

 

대상을 Supertype과 Subtype으로 분류하는 Subtyping은 1980년경에 Category Theory에서 처음으로 공식 언급되었다고 한다. 그러니까, 대상을 범주화하여 분류할 수 있다면 Supertype Entity와 Subtype Entity로 구별하여 설계할 수 있다는 의미가 될 것이다.

 

혹, 데이터 모델링에 대한 관심이 지대하다면 눈에 스며드는 세상의 빛들과 귀에 들려오는 소리들까지도 대상으로 삼아 모델링하는 습관을 들여보기를 권고한다.

 

대학 1학년 때 한창 당구에 몰입해있던 그 시절... 강의하시던 교수님 후두(後頭)(‘뒤통수’라고 썼다가 순화했음) 우 상단 1/3 지점을 강하게 오시(?)로 치면 멋진 우라(?)가 나오겠구나 상상해보곤 하던 그 시절… 세상이 당구공과 각(Angle)으로 보였던 것은 필자만의 추억은 아닐 터… ㅎ

 

데이터 모델링에 심취해보자. 세상 모든 것들이 Entity와 Attribute, 그리고 Relationship으로 보일 그 날까지...

4. ‘코드’란 무엇인가?

속성(Attribute)들 중 '~코드'인 것들이 무척 많음을 모델링을 해 본 사람이라면 잘 알고 있을 것이다. 데이터 표준화의 한 영역인 표준 도메인 중 매우 큰 비중을 차지하는 것도 표준 코드인 것이다.

 

몇 년 전, 행정표준코드(www.code.go.kr) 관리자로부터 본인의 애로사항에 대해 사적인 자리에서 들은 적이 있는데, 내용인 즉 행정표준코드 중 '기관코드' 관리가 너무 어렵다는 것이었다. 하루에도 수십 개의 기관이 생성 및 소멸하고 있는데, 이를 종합 관할하는 주무부처가 없어서 필요에 따라 팩스나 이메일을 통해 기관코드 변경 요청이 접수되면 이를 반영하고 있으며, 변경 요청 대상 기관에 '삼성SDS 멀티캠퍼스', '동서증권 연수원', '꽃나라 유아원' 등 행정 또는 공공 기관으로 분류하기 어려운 것들에 대해서도 등록요청이 있고, '동아대학교 총무처 취업전담팀'과 같은 세부조직에 대한 요청도 있다고 한다.

이러한 이유로, 관리 업무가 점점 증가하고 있고, 관리도 잘 안되고, 요청된 기관을 표준코드에 반영해야 할 지, 반영을 거절해야 할 지 고민만 쌓여가고 있어, 좋은 방안이 좀 제시되었으면 한다는 것이다.

위 이야기에 대해 부연 설명을 더하자면, 행정표준코드의 기관코드를 사용하고 있는 NEIS(국가교육정보시스템)에서 교육기관에 '서울대학교'와 같은 국공립 교육기관뿐만 아니라, '삼성SDS 멀티캠퍼스', '동서증권 연수원', '꽃나라유아원' 등도 교육기관으로 관리할 필요가 있으므로 행정표준코드에 등록을 요청하고 있는 실정이며, 때로는 '동아대학교 총무처 취업전담팀'과 같이 팀 수준의 조직 등록의 필요성이 제기되기도 한다. 또한, 기관코드는 다른 표준코드와는 달리 '조직의 소재지 정보'와 같은 몇 가지 부가적인 정보를 포함하고 있다.

 

이 질문에 대해, 본인은 우선 기관코드가 '코드'입니까? 하는 다소 동문서답 격인 질문을 하였는데, 이는 ‘기관코드에 대한 효율적인 관리 방안'에 대한 논의를 뒤로 하고, 기관코드가 과연 코드인가? 표준코드로 관리할 대상인가? 라는 좀 더 본질적인 문제에 대한 접근이 필요하다고 느꼈기 때문이다.

 

위 이야기는 2005년도에 '행정정보 공동활용 및 DB표준화' 사업과 2006년도 '행정표준코드 추가 제정'에 관한 일련의 사업(이 후, 매년 우리 회사가 추가 제정 사업을 반복 수행한 바 있음)을 수행하면서 행정표준코드 담당자와 나눈 대화에 기초한 것이다.

 

여러분들의 생각은 어떠한가?

- 데이터 영역에서 '코드'란 무엇인가?

- 기관코드는 코드이다? 코드가 아니다? 그 이유는?

아주 단순한 질문이지만, 행정표준코드 중 기관코드 문제 발생의 원천적 원인에 대해 생각해보자.

위 질문의 요지는 식별자와 코드를 구별할 수 있겠는가에 관한 것이었다. 기관코드는 식별자인가 코드인가 뭐 이런 식의 토론인 셈이다.

 

결론부터 얘기하자면, 기관코드는 식별자이면서 코드라고 말하고 싶다.

우리가 얘기하는 식별자란, Entity의 각 개별 Instance들을 유일하게 식별할 수 있는 방법을 응용 또는 사용자에게 제공하는 장치(정보, 데이터)라 할 수 있겠다. '식별자이면서 코드'란, 식별자이지만 값을 표현하는 방식이 '코드'라는 것이다. 엄밀히 말하자면 '코드'라기 보다는 '코딩'이 맞는 표현일 것이다.

 

식별자 데이터 값을 표현하기 위해 코딩 수법을 써서 표현하는 경우 식별자의 이름 말미에 '~코드'라고 붙이는 경우를 흔히 볼 수 있다. 기관코드, 사원코드 등이 대표적이다.

 

식별자와 대별되는 개념으로써의 '코드'는 표준화 시 도메인 분류에서 흔히 언급되는데, 이 때의 코드는 식별자와 혼용되지 않고 오로지 데이터 집합, 즉 Instance들의 집합에 대한 분류로 사용된다. 도메인 개념으로써 식별자와 코드를 대별(상호배타적)시키기 위해 도메인이나 속성 명칭 뒤에 식별자의 경우 '~ID', '~번호' 등을 붙이도록 하고 코드의 경우는 '~코드'를 붙이도록 하는 것이 추세이기도 하다.

 

다시 좀 더 본질적인 질문에 접근하여, 사실(Fact, 현실세계)을 데이터로 표현하는 방식 중 코딩방식(수법)이 있으며 이 방식을 사용하여 표현하는 경우 '~코드'라는 식의 명명을 하기도 한다. 식별자도 데이터이므로 이를 표현하기 위해 코딩방식을 사용할 수 있는 것이다. 주민등록번호의 경우도 주민등록시스템에서 코딩이 이루어진 결과라고 할 수 있겠다. 다만, 명칭을 '주민등록코드'라고 하지 않았을 뿐이다.

데이터 표준화 시, ‘코드’는 데이터 집합을 분류하기 위한 용도의 도메인으로 한정하고, 식별자 성격의 것에 대해서는 비록 코딩방식으로 데이터 값을 표현한다 하더라도 ‘ID’, ‘번호’ 등으로 명명할 것을 권고한다.