유니버설 데이터 모델과 패턴

유니버설 데이터 모델과 패턴
작성자 : 렌 실버스톤 (Len Silverston)
2012 년 11 월
이 기술 백서의 미국 뉴욕에 소재한 SourceMedia 에 기고된 아티클입니다. 저자인 렌 실버스톤 (Len
Silverston)이 SourceMedia 사에 알리고 보내준 원문을 번역한 것이며, 번역의 일부 용어는 가급적 이미 한국에
출간된 렌 실버스톤의 “The Data Model Resource Book (Volumn 3)” :지앤선 출판사의 번역 용어에 맞추도록
노력하였습니다.
Devgear
서울특별시 반포 1 동 743-14
4 층 ㈜데브기어
(T) 02.595. 4288
10.
유
니
버
설
데
이
터
모
델
과
패
턴

Embarcadero Technologies White Paper
데브기어 기술페이지 tech.devgear.co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 ask@embarcadero.kr
도입
웹스터 사전에 따르면 유니버설(Universal)이란 “보편적으로 적용 가능한” 또는 “전체적인 관점에서
적용되는” 이라고 정의된다. 데이터 모델에서도 몇가지 매우 공통된 패턴을 보편적으로 적용될 수
있으며, 이를 통해 보다 높은 품질의 모델을 전체적인 차원에서 만들 수 있다. 더욱이 이러한 패턴을
재사용하게 되면 시간과 노력을 절감할 뿐만 아니라, 실무에서는 이미 검증된 모델을 필요에 따라
바로 적용할 수 있으며, 추가로 발생될 수 있는 미래의 요구사항에 대해서도 유연한 모델과 구조를
갖출 수 있게 된다. 또한 데이터 공유의 기반이 되는 모델과 구조는 일관성을 갖추게 된다.
이 아티클에서는 “유니버설” 데이터 모델을 구축할 수 있는 몇가지 공통 패턴인 역할(Roles) 패턴,
상태(Statuses) 패턴, 분류(Categories) 패턴을 설명한다.
각 패턴 별로는 각 유형을 모델링 하는 구체적(Specific) 방식과 추상적(Abstract) 방식 모두를
보여줄 것이다. 어떤 것이 옳은 방식일까? 나는 올바른 데이터모델 또는 잘못된 데이터 모델이란
없으며 다만 데이터를 모델링하는 다양한 방식에 대해 찬성이나 반대가 있을 뿐이라고 믿는다. 보다
구체적인 데이터 모델일 수록 보다 이해하기 쉽다는 장점을 가지며 비즈니스 규칙이 강제되고
있다는 것을 파악하기가 쉽다. 반면에 보다 추상적인 모델일 수록 변화에 대해 훨씬 쉽게 적용될 수
있기 때문에 유연성과 유지관리 측면에서 장점이 있다. 구체적 패턴과 추상적 패턴이 각각 언제
사용되는지에 대해서는 이 아티클의 후반부에서 다루도록 하겠다.
역할(Roles)
역할은 관계자(Party)가 수행하는 역할 즉 관계자가 쓰고 있는 “모자”를 나타낸다. 역할(role)에는
두가지 유형 즉 선언적(declarative) 역할 과 맥락적(contextual) 역할이 있다. 선언적(declarative)
역할은 관계자가 담당하는 역할을 “선언한다”. 즉 어떤 관계자의 역할을 “직원”이라고 선언하는
방식이다. 맥락적(contextual) 역할은 관계자가 다른 엔티티와의 관계 상 어떻게 행동하는 가를
나타낸다. 예를 들면 어떤 관계자는 PRODUCT(제품)이라는 엔티티의 맥락에서는 제품 관리자라는
역할을 수행하고, 또 어떤 관계자는 PROJECT(프로젝트)라는 엔티티 내에서는 품질 보증 관리자의
역할을 할 수도 있다.
선언적 역할 (Declarative Roles)
대부분의 기업은 고객, 직원, 파트너, 공급자 등등 개인이나 조직이 수행하는 역할 즉 “핵심
엔티티”의 정보를 유지하고 관리한다. 하지만 사람들이 종종 깨닫지 못하는 점이 있는데, 바로 데이터
모델에 들어 있는 역할(role)이 해당 관계자와 완전히 동일하지 않으며 그 관계자의 역할과는
무관하게 그 관계자 자체에 대한 정보가 존재한다는 점이다.
가령 우리가 ABC 라는 회사를 하나의 고객사로만 보고 있다면, 가끔 전체 그림을 보지 못할 수
있다. ABC 라는 어느 관계자는 기업의 한 고객사일 수 있으면서 또한 파트너사나 공급사일 수도 있고
많은 다른 역할을 할 수도 있다. 우리가 이런 사실을 부정하고 이 관계자를 오직 하나의 고객사로만
본다면 이 회사 자체에 대한 정보는 여러 곳에서 나타날 것이다. 즉 각 역할 별로 각각 정보가 존재할
것이다. 하지만, PARTY(관계자) 엔티티(개인이든 조직이든 무관하게)는 하나만 존재한다고 보게 되면,

Embarcadero Technologies White Paper - 3 -
10.
유
니
버
설
데
이
터
모
델
과
패
턴
이 PARTY(관계자)는 자신이 수행하는 다양한 역할(role)에 따라서 알아볼 수 있게 된다. 우리가
모델을 보다 현실에 가깝도록 만들수록 모델은 보다 견실하게 된다.
(그림 1: 구체적인 선언적 역할 패턴)
그림 1 에서는 역할(role)과 관계자(party)를 모델링하는 보다 구체적 패턴과 이 패턴의 사용 사례를
보여준다. 각 역할은 각각의 엔티티로 표현될 수 있고 이 모든 역할들은 하나의 PARTY(관계자)
엔티티와 연관된다. 예를 들어 CUSTOMER(고객), SUPPLIER(공급사), PARTNER(파트너) 라는 역할
엔티티가 있고 각 역할 엔티티 모두가 하나의 PARTY(관계자)에 연결된다. 그 결과 하나의 동일한
관계자(party)가 고객, 공급사, 파트너가 될 수 있고, 그 정보 (이름, 연락처 등)는 한번에 관리된다.
이와 같이 구체적 모델은 비교적 이해하기 쉽다. 하지만 이 모델이 가지는 이슈 중 하나는 바로
하나의 관계자가 앞으로도 계속 이 역할들만 수행한다고 볼 수 없다는 점이다. 따라서 새로운 역할이
존재하게 되면 이 모델에 엔티티를 하나 더 추가해야 한다. 게다가 모든 역할에는 공통된 정보가
있을 수 있는데 예를 들면 역할들의 모든 유형 사이에는 모두가 관계 추적 정보 등을 가지고 있다.

(그림 2: 유연한 선언적 역할 패턴)
그림 2 의 패턴과 사례에서는 선언적 역할에 대해 보다 유연한 데이터 모델을 보여준다. PARTY
ROLE(관계자 역할) 엔티티는 PARTY(관계자)와 ROLE TYPE(역할 유형) 간의 교차엔티티(associative
entity) 이다. PARTY ROLE (관계자 역할) 엔티티는 발생할 수 있는 다양한 역할들에 대한 하나의
슈퍼타입이다. 이것은 관계자에 효과적인 “태그”를 붙여서 하나 또는 그 이상의 역할을 담아낸다.
ROLE TYPE(역할 유형)은 존재할 수 있는 역할에 대한 정보를 보유한다. 예를 들어 고객, 공급사,
파트너, 작업자 등이다. 그림 2 의 좌측에는 어떤 회사든지 사용할 수 있는 패턴을 우측에는 몇몇
회사에 적용될 수 있는 사례 즉 제품 생산 회사의 사례를 보여주고 있다.
이 모델의 장점은 계속해서 새로운 역할이 발견되더라고 ROLE TYPE 을 하나 추가하면 쉽게
담아낼 수 있다는 점이다. ROLE TYPE (역할 유형)은 수행하고 있는 역할 또는 그 역할이 가진 권한에
따라 ROLE TYPE 과 관련된 정보가 추가될 수 있다. 예를 들면 제품 가격 책정 이라는 같은 정보가
ROLE TYPE 과 관련되어 추가될 수 있다. 이런 스타일의 모델링에서 알아두어야 할 점은 ROLE TYPE
엔티티 뿐만 아니라 서브 타입이 나타난다는 점이다. 왜냐하면 정보는 하나의 역할 유형에 관련되는
것이 일반적이지만(예: 가격 할인 또는 ROLE TYPE 과 관련된 권한 등), 어떤 정보는 특정 역할 자체에
관련되기 (예: 직원을 위한 급여) 때문이다..
맥락적 역할 (Contextual Roles)
맥락적 역할은 하나의 관계자가 또 다른 엔티티와의 문맥 관계 상에서 어떻게 관여하는가 (또는
관여하였었는가) 하는 것을 정의한다. 예를 들어 하나의 프로젝트에서 투입된 사람이나 조직은
몇가지 역할을 할 수 있을 것이다. 한 개인이나 조직은 하나의 프로젝트를 위한 후원자, 작업자,
관리자, 팀장, 조력자, 또는 품질 관리자 등이 될 수 있다. 이러한 방식은 주문, 계약, 배송, 지불, 제품
등과 같은 엔티티와 같이 여러 역할을 가질 수 있는 여러 엔티티에도 그대로 적용될 수 있다. 예를
들어 하나의 배송은 수신자, 발송자, 배송자, 승인자, 입고자 등등의 역할을 가질 수 있다.

10.
유
니
버
설
데
이
터
모
델
과
패
턴
(그림 3: 구체적인 문맥적 역할 패턴)
그림 3은 구체적 모델링 스타일을 사용하여 맥락적 역할을 모델링한 패턴과 그 사례이다. 이
패턴에서는 하나의 엔티티에 많은 수의 역할이 있을 수 있고 각 역할은 M:M 교차 또는 1:M 관계를
사용하여 관계 맺어진다. 예를 들어 하나의 특정 PROJECT에는 여러 SPONSOR(후원자), 여러
WORKER(작업자), 하나의 PROJECT MANAGER(프로젝트 관리자), 하나의 PROJECT LEAD(프로젝트
팀장)이 있을 수 있다. 이 역할들은 앞서 살펴본 패턴을 사용하여 먼저 선언되었을 수도 있고 또는
별도로 선언할 필요가 없는 단지 맥락상의 역할일 수도 있다. 이 패턴 사용 시의 장점은 상대적으로
이해하기가 쉽고 필요한 특정 비즈니스 규칙을 강제할 수 있다는 점이다. 예를 들어 하나의
프로젝트(project)에는 오직 한 명의 프로젝트 관리자(project manager)와 오직 한 명의 프로젝트
팀장(project lead)만이 있도록 할 수 있다.
이 패턴의 단점은 비즈니스 규칙과 비즈니스 처리 프로세스란 언제든 변화할 수 있는 것이므로, 이
경우 데이터 모델 (과 그 하부의 데이터베이스)가 변경되어야 한다는 점이다. 예를 들어, 만약 품질
관리자라는 역할이 나중에 추가되거나, 비즈니스 규칙이 변경되어 복수의 프로젝트 관리자를 동일한
프로젝트에 둘 수 있게 된다면 (동시에든 또는 시간이 바뀌면서 교체되는 경우이든) 어떻게 할
것인가?

(그림 4: 유연한 문맥적 역할 패턴)
이런 이유로 그림 4에서는 보다 유연한 패턴을 보여준다. 이 패턴은 하나의 엔티티가 얼마든지
많은 PARTY(관계자)와 그와 관련된 ROLE TYPE(역할 유형)을 얼마든지 가질 수 있고 시간이 얼마든지
흘러도 수용할 수 있다. 이 패턴을 사용하면 발생될 수 있는 새로운 모델링 요구 사항의 모든 유형을
받아낼 수 있다. 즉 언제든지 새로운 역할을 추가할 수 있다.
하지만 이 패턴 사용 시의 결점은 이 패턴의 경우 훨씬 추상적이어서 이해하기가 더욱 어렵다는
점이다. 또한 이 모델은 특정 비즈니스 규칙, 예를 들어 오직 한 명의 프로젝트 관리자만이 존재할 수
있다 와 같이 필요한 규칙을 강제하지 않는다. 하지만 우리가 데이터베이스를 견고하고 안정된
토대로 만들어서 새로운 비즈니스 규칙에도 변경되지 않도록 하려면 이 패턴이 가장 이상적이다.
상태(Statuses) 패턴
날짜 속성과 날짜시간 속성은 모델에서 언제든지 필요하다. 모델러는 그림 5 와 6 의 패턴을
사용하기를 원할 것이다.
(그림 5: 구체적 상태 패턴)

10.
유
니
버
설
데
이
터
모
델
과
패
턴
그림 5 는 구체적 스타일의 모델링을 사용하여 상태를 모델링하는 패턴과 이 패턴이 적용된 사례를
보여준다. 이 모델에서 ORDER(주문: 요구되는 정보에 따라 구매주문 또는 판매주문 또는 두가지
모두 해당될 수 있다)은 상태 정보를 위한 모든 유형을 가지고 있고 이러한 상태는 추적될 수 있어야
한다. 하지만 만약 새로운 상태가 필요하다면 예를 들어 주문이 지연되었고 새로운 출고 예정일이
예상된다면? 해당되는 상태의 과거 기록 또한 유지해야 한다. 예를 들어 최초에 기록된 출고
예정일과 새롭게 예상되는 출고일에 대한 EXPECTED SHIPMENT(출고 예상) 데이터를 각각 유지해야
한다.
(그림 6: 유연한 상태 패턴)
따라서, 그림 6 에서 보여주는 유연한 패턴과 그 사례처럼 상태를 모델링할 수 있다. 이 패턴은
얼마든지 많은 상태를 수용할 수 있으며 각 상태의 과거 기록을 언제까지고 유지할 수 있다. 이와
같은 패턴은 요구사항, 견적서, 청구서, 상품, 관계자 등의 모든 상태 정보를 가지는 다른
엔티티들에도 동일하게 적용될 수 있다.
분류(Categories) 패턴
또 하나 자주 발생되는 데이터 모델링의 공통 패턴은 바로 엔티티를 카테고리로 나누는 분류
패턴이다. 데이터 모델은 종종 다양한 분류, 유형, 그룹, 군(패밀리) 등 엔티티를 분류하는 여러 방식을
가지게 된다. 예를 들어 상품 그룹, 상품 유형, 상품 군, 고객 유형, 장비 유형, 산업 구분 등 엔티태의
분류는 매우 다양하다.

(그림 7: 구체적 분류 패턴)
그림 7 은 하나의 엔티티를 단순하게 구분하고 유형 지을 수 있도록 "유형" 엔티티를 해당
엔티티와 1:M 관계로 연결하는 방법이다. 예를 들어 다이어그램의 오른쪽에 표시된 것과 같이 하나의
상품은 PRODUCT TYPE (서비스, 상품, 솔루션 등), PRODUCT FAMILY (가정용 상품, 차량용 상품,
사무용 상품 등), 또는 PRODUCT LINE (상업용 상품라인, 주거용 상품라인 등) 엔티티가 될 수 있다.
게다가 유형 자체도 자신을 분류하는 유형이 있을 수 있으므로 PRODUCT FAMILY(상품군)는 재귀
관계를 가지데 된다. 예를 들어 사무용 상품군을 더 분류하면 컴퓨터 상품군, 사무 보조 상품군
등등의 유형으로 분류될 수 있다.
이 패턴은 다양한 상품 분류를 명확하게 이해할 수 있다는 장점이 있지만 이러한 스타일의
모델링에는 단점이 있다. 만약 상품 카테고리에 새로운 유형이 향후에 추가된다면, 예를 들어 상품에
사용되는 재료의 유형이나 해당 상품의 판매 목표가 되는 산업군 등이 추가된다면, 또는 창의적인
영업팀이나 마케팅팀이 새로운 카테고리를 필요로 한다면 어떻게 할 것인가?

10.
유
니
버
설
데
이
터
모
델
과
패
턴
(그림 8: 유연한 분류 패턴)
그림 8 은 보다 유연한 패턴과 엔티티 분류 사례를 보여준다. 이 패턴은 얼마든지 많은 분류를
허용하며 분류의 단계도 얼마든지 담아낼 수 있다. 예를 들어 엔티티 하나 즉 PRODUCT(상품)은 많은
방식으로 분류될 수 있고 분류의 단계도 많을 수 있다. 따라서 이러한 유연한 모델이 적절할 것이다.
PRODUCT CATEGORY 엔티티는 모든 유형의 카테고리를 다양한 단계로 가질 수 있고 PRODUCT
CATEGORY ROLLUP 은 어느 상품 카테고리가 모여서 어느 상위 단계의 카테고리가 되었는지를
가진다. 예를 들어 PRODUCT ID 2222 "Johnson bond paper 2000"은 사무 보조 용품으로 분류되는
동시에 서비스가 아니라 제품(good)으로 분류될 수 있다. PRODUCT CATEGORY CLASSIFICATION 은
이 상품을 최하위 단계의 분류까지 연결하여 내려갈 수 있게 한다 (그 결과 Johnson bond 는
사무보조용품이 된다), 그리고 나서 PRODUCT CATEGORY ROLLUP 은 이 상품 카테고리인
사무보조용품은 상위 카테고리인 "사무용 상품"에 포함되며 "가정용품"카테고리가 그
"제품군"카테고리 안에 들어있다는 것을 보여준다.
구체적 모델 VS 추상적 모델
지금까지 여러분은 이러한 여러 패턴 들 중 하나의 패턴을 보아왔을 것이다. 모델을 만드는 데는
여러가지 방법이 있다. 이 아티클은 몇가지 모델링 방식과 몇가지 패턴만을 다루고 있다. 하지만
실제로는 훨씬 더 많고 다양한 패턴이 존재한다. 무엇보다 구체적 스타일로 모델을 만들 것인가
아니면 추상적 스타일로 만들 것인가를 먼저 결정하는 것이 바로 모델링의 큰 줄기를 바꾸는 변수가
될 것이다.
구체적 패턴을 쓸 것인지 추상적 패턴을 쓸 것인지를 어떻게 알 수 있을까? 처음에는 우선 다음과
같은 질문을 할 수 있다 "데이터 모델의 목적이 무엇인가?" 데이터 모델에는 두 개의 중요한 목적이
있다고 믿는다. 1) 필요한 정보을 표현하고 커뮤니케이션하기 위해서, 그리고 2) 데이터베이스 설계를
위한 바람직한 기반을 모델링하기 위해서가 그것이다. 이 두 목적은 서로 양립하기가 어렵다. 만약

필요한 정보를 파악하고 표현하고 커뮤니케이션하기 위한 목적이라면 모델러는 보다 구체적 모델을
만들어서 업무 담당자의 구체적 니즈가 반영된 모델을 만들어야 한다. 예를 들어 하나의
프로젝트에는 후원자 여러명, 작업자 여러명, 프로젝트 관리와 프로젝트 팀장을 각 한 명으로 정해진
숫자에 맞게로 표현한다. 이는 그림 3 과 같다.
만약 모델의 목적이 데이터베이스 설계를 위한 바람직한 기반을 모델링하는 것이라면 모델러는
유연성을 확보해야 할 것이고 그림 4 와 같은 패턴을 사용할 것이다. 이 경우 얼마든지 많은 관계자와
역할을 시간에 관계없이 수용할 수 있으므로 데이터 모델이 견고하게 되고 새로운 비즈니스
프로세스나 규칙이 발생하더라고 거의 변경되지 않을 것이다. 이 모델에서는 구체적 모델이 담고
있던 많은 규칙들을 다른 부가물의 형식으로 데이터 모델에 표현하게 된다.
만약 여러분이 자크만 프레임워크(Zachman Framework)를 지지한다면, 데이터 모델에는 다양한
청중들이 있으며, 결구 이것은 두개의 모델을 필요로 하게 된다는 것을 알 것이다. 오너/비즈니스
대표를 위한 모델과 설계자/아키텍트를 위한 모델이 그것이다. 오너나 비즈니스 대표를 위해
만들어진 모델은 보다 구체적 모델이며 따라서 구체적 패턴을 적용하여 그들의 요구 사항을
표현하고 커뮤니케이션 하여야 한다. 설계자와 아키텍트를 위한 모델은 유연성과 변화 적응력, 유지
관리 비용 절감에 비중을 두고 설계 된다. 따라서 보다 추상적이고 유연한 패턴을 사용한 모델
유형으로 만들어 지게 된다.

10.
유
니
버
설
데
이
터
모
델
과
패
턴
(그림 9: 구체적 스타일과 및 유연한 스타일을 동시에 표현한 문맥적 역할 패턴)
"비즈니스 데이터 모델"과 "아키텍트 데이터 모델"을 유지관리하고 이 둘 사이를 연결하고 상호
참조하는 것은 상당한 양의 작업이 될 수 있다. 이에 대한 가능한 해법은 그림 9 와 같이 하나의
모델에 구체적 패턴과 추상적 패턴 두가지 모두를 담아내는 것이다. 뷰(View)를 만들어서 모델의
추상적 관점뿐만 아니라 구체적 관점을 보여줄 수 있다. 예를 들어 뷰를 하나 만들고 이 뷰 안에
다양한 작업 관계자들의 역할과 구체적 관계를 표현한 수 있다. 말하자면 후원자들, 작업자들,
프로젝트 관리자, 프로젝트 팀장을 만들고 요구사항을 검증하는데 사용한다. 그리고 나서 다시
모델의 아키텍트 관점의 뷰를 만들어서 작업 관계 (프로젝트, 행위, 과업 등 작업 단위들) 그리고 이와
관계된 얼마든지 많을 수 있는 다른 관계자와 역할을 시간이 흐르더라도 모두 담아낼 수 있는 지를
보여줄 수 있다.
유니버설한 접근법
대부분의 데이터 모델은 매우 공통된 유형의 데이터로 관리될 필요가 있다. 예를 들명 상태, 분류,

역할 등은 다양한 관계자에서 모두 필요로 한다. 이와 같이 반복되는 데이터 구조를 모델링하는 데는
몇가지 방법이 있다. 그리고 그 모델링 방식은 이러한 데이터를 모델링하는 사람이 얼마나 구체적인
또는 추상적인 접근을 선택하느냐에 따라 크게 달라진다. 각 패턴을 모델링하는 (구체적 스타일과
추상적 스타일을 모두 포함하여) 몇가지 효과적인 대안을 제시해 보고, 또 각 대안들 사이에서 선택을
하기 위한 기준를 제시함으로써, 우리는 보다 조직화되고 훨씬 품질이 높은 데이터 모델을 보다 짧은
시간 내에 만들 수 있다.
저자 소개
렌 실버스톤 (Len Silverston) 은 베스트셀러 저자이자 컨설턴트이며
강연자이며, 30년이 넘도록 수많은 회사와 조직에서 정보, 시스템, 사람을
통합할 수 있도록 돕고 있다. 렌은 데이터 모델링, 데이터 관리, 정보 통합의
인간 공학 분야의 생각의 리더(thought leader)로서 가장 유명한 전문가 중 한
사람으로 인정받고 있다. 또한 Computer Literacy 베스트셀러 리스트 12에
랭크된 The Data Model Resource Book (Volumn 1과 2, 3)의 저자이다. 이
책에는 수백개의 재사용 모델로 전체를 구성하는 데이터모델 들에 대해
설명하고 있다. (Volumn 3은 지앤선 출판사를 통해 2012년 한국어
번역서로도 출간되었다.) 렌 실버스톤은 2004년 DAMA International Professional Achievement
Award 를 수상하기도 하였다.
엠바카데로 테크놀로지는, 1993 년에 설립한 데이터베이스 툴 제작사입니다. 2008 년에 볼랜드의 개발툴 부문
「CodeGear」를 합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 환경에서
소프트웨어 애플리케이션을 설계, 구축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다.
미국 기업의 총수입 랭킹 「포천 100」중 90 개 기업과 전세계 300 만 이상의 고객이, 엠바카데로의
Delphi®、C++Builder®, JBuilder® 등 CodeGear™제품과 ER/Studio®、DBArtisan®, RapidSQL® 등
DatabaseGear™ 제품을 채용해, 생산성의 향상과 혁신적인 소프트웨어 개발을 실현하고 있습니다. 엠바카데로
테크놀로지스는, 샌프란시스코에 본사를 두고, 세계 각국에 지사를 전개하고 있습니다. 보다 자세한 내용은,
http://www.devgear.co.kr를 참고하시기 바랍니다.

유니버설 데이터 모델과 패턴

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to 유니버설 데이터 모델과 패턴

Similar to 유니버설 데이터 모델과 패턴 (20)

More from Devgear

More from Devgear (20)

유니버설 데이터 모델과 패턴