거의 모든 시스템에서 업무에서 사용하는 모든 코드(개별 엔티티로 관리하는 목록성 코드를 제외)를 공통코드 엔티티에서 통합하여 관리하는 것이 일반적이다. 공통코드에 대한 구조도 거의 유사한 형태이며, 많은 고민 없이 설계가 이루어지기도 한다. 공통코드는 어떤 유형이 있는지 살펴보고, 좀 더 활용할 수 있는 부분이 있는지 확인해 보자. 

가장 일반적인 경우는 아래 그림처럼 공통 코드 유형과 공통코드로 구성한 형태이다.

식별자가 코드유형ID, 코드 조합으로 구성되어 있으며, SQL로 고객유형코드 조회 시 코드유형ID = ‘1000’ 조건을 추가하여 사용한다. 코드유형ID 대신 코드유형영문명 = ‘CUST_CLS’ 처럼 코드유형 영문명을 사용하면 코드유형ID 보다 직관적이어서 코딩 생산성을 높일 수 있다. 

또한, 아래 그림처럼 공통코드유형과 공통코드 엔티티를 하나로 합쳐 순환 관계로 관리하는 형태도 있을 수 있으며, 엔티티 형태만 다를 뿐 다른 부분은 크게 다르지 않다.

또 다른 형태로 공통코드 식별자를 ‘10001’(개인고객)처럼 코드(코드유형ID+코드) 속성으로만 구성하고 코드유형ID는 일반 속성으로 관리할 수도 있다.

이렇게 하면 코드명을 조회하기 위해 코드유형ID = ‘1000’ 조건을 추가하지 않아도 된다. 코드에 대한 공통유형ID 조건 없이 코딩 할 수 있으므로 코딩 생산성이 높고, 코드 값만 보고도 코드유형을 알 수 있다. 차세대 시스템을 구축하면서 현행 시스템의 특정 컬럼이 어떤 코드유형을 사용하는지 알 수 없어 소스까지 확인하는 경우를 종종 볼 수 있었는데, 이러한 번거로운 문제가 자연스럽게 해결된다. 다만, 코드가 길어져 저장공간을 많이 차지하는 문제가 있을 수 있지만, 숫자 형으로 설계하면 저장공간을 절약할 수 있어 많이 고민할 필요는 없다. 

코드유형 또는 코드 간에 종속관계 등이 포함된 형태의 좀 더 복잡한 구성에 대해 살펴보자. 예를 들어, 고객 유형은 개인과 법인으로 나누고, 고객상세유형으로 개인은 개인과 개인사업자로 법인은 영리법인, 비영리법인, 단체로 다시 분류한다고 해보자. 화면의 고객유형에서 법인을 선택했을 때 고객상세유형 콤보박스에 법인에 해당하는 영리법인, 비영리법인, 단체만 조회되도록 해야 한다. 고객 유형에 따라 고객상세유형에 저장할 수 있는 값의 범위가 정해져 있는 것이다(종속관계).

또한, 특정 코드유형이 다른 코드유형의 부분집합으로 관리하는 경우도 있다. 예를 들어, 은행코드는 “경남”, “광주”, “국민”, “기업”, … 등 모든 은행코드를 관리하고, 거래은행코드는 “국민”, “하나”, “신한”만 관리할 수 있다. 이 경우 코드유형을 별도로 생성하거나 코드유형 변경 없이 데이터 구조를 다르게 가져갈 수 있다.

이 외에도 다양한 유형의 공통코드 형태가 있을 수 있으나, 프로젝트 상황에 맞게 확장해 나가면 크게 어렵지 않을 것이다.

비투엔 유동오 이사