프로젝트 일등공신은 바로 A.O.M
지난 2년 반이라는 기간 동안 유럽, 인도네시아, 베트남, 중국의 총 4개의 해외법인 시스템을 오픈 하였습니다. 2년 반이라는 짧은 시간 동안 어떻게 4개의 시스템을 오픈 할 수 있었을까요? 이의 가장 큰 일등공신을 상품 시스템에 적용 된 A.O.M 아키텍처 덕분이라고 생각합니다. 물론 탁월한 능력을 가진 이모PM님과 현업, 많은 개발자분들의 노력 등, 여러 다른 이유도 있을 테지만 말입니다. 그러면 A.O.M을 일등공신으로 택한 이유는 무엇일까요? 앞으로 찬찬히 설명 해 보도록 하겠습니다.
Why A.O.M?
앞에서 언급했던 4개의 법인은 모두 저 마다 나라의 규정에 맞는 상품들을 가지고 있습니다. 이 말은 규정이 달라지면 규정에 맞게 상품을 다시 만들어야 된다는 말이 됩니다. 바로 여기에서 A.O.M의 대 활약이 펼쳐집니다. 만약 A.O.M이 적용되지 않았다면 우리는 매번 프로젝트마다 상품을 새로 만들고 있었을 것입니다. 시스템 사용자가 아닌 개발자가 상품을 일일이 만들어야 했다는 말이됩니다. 이 얼마나 비참한 노릇일까요? 상품이 한 두 개도 아니고 매번 그 수 백 개의 상품들을 만들어야 된다니요!! 하지만 A.O.M이라는 요 기특한 녀석이 바로 우리의 일을 현격하게 줄여 주었습니다. 우리는 단지 상품을 구성 할 수 있는 환경만 만들어 주면 되었습니다. 시스템은 상품 구성에 필요한 환경을 제공하고 사용자가 시스템 상에서 상품을 기획하고 만들면 되는 것입니다. 이정도면 A.O.M이 일등공신이라 할 만 하지 않을까요? 자. 이제 이유를 알았으니 A.O.M이 무엇인지 살펴 볼 차례입니다.
What is A.O.M?
A.O.M (Adaptive Object Model 이하AOM)은 AOM 아키텍처는 1998년도 일리노이대학교 얼바나-샴페인 캠퍼스(University of Illinois at Urbana-Champaign)의 컴퓨터과학과(Department of Computer Science)에서 개최한 ‘MetaData Pattern Mining Workshop 1998’에서 구체화 되었습니다. 이 워크샵의 목적은 OOPSLA(Object-Oriented Programming Systems, Languages and Applications)‘ 97에서 소개된 메타데이터 및 오브젝트 모델(Object Model)과 관련한 데모에 대한 아이디어를 구체화하고 정리하는 데 있었습니다. 이에 따라 OOPSLA‘ 97에서 소개된 데모의 절반 이상이 오브젝트모델이나 메타라는 공통된 주제를 바탕으로 작성 되었습니다. 하지만 각 데모 발표자 별로 같은 아이디어를 갖고 있음에도 불구하고 서로 다른 용어를 사용한다는 문제가 있었습니다. 이에 따라 워크숍에서는 액티브 오브젝트 모델(Active Object Model)이란 이름으로 이러한 생각들을 정리 했습니다. 액티브 오브젝트 모델은 말 그대로 동적인 객체 모델이란 뜻인데, 이 때 정리된 내용은 고객별로 각기 다른 요구사항을 수용할 수 있는 설정 가능하며 유연성이 높고 실시간으로 적용이 가능한 애플리케이션을 개발할 수 있는 아키텍처 스타일을 칭했습니다.
이렇게 구체적으로 액티브 오브젝트 모델에 대한 정의가 이뤄지자 이를 이루는 시스템에 필요한 패턴들을 정리하기 시작했고 ‘OOPSLA‘ 98 MetaData Workshop’에서 이것을 이루는 아키텍처 패턴들을 구체화 했습니다. OOPLSA‘ 98이 끝난 후 결과물로서AOM을 이루는 여러 패턴들이 도출됐으며 AOM에 대한 개념도 더욱 체계적으로 정리 되었습니다. 이후 AOM은 OOPLSA의 단골 주제로 계속 논의됐는데, 죠셉 요더(Joseph Yoder)가 OOPLSA ‘2000에서 기존에 사용해 왔던 액티브 오브젝트 모델이란 이름 대신 어댑티브 오브젝트모델(Adaptive Object Model)이라고 AOM의 이름을 변경 했습니다. 참고로 AOM은 어댑티브 오브젝트 모델 이외에도 다이내믹 오브젝트 모델(Dynamic Object Model)로도 불립니다.
A.O.M의 기본구조와 패턴 이해하기
![](/content/images/2021/01/AOM-------1.png" alt="AOM의 기본구조)
위 그림은 AOM 아키텍처의 기본적인 구조(Class Diagram)인데 Operational level과 Meta level으로 나뉘어 있습니다. Meta level은 새로운 유형의 객체를 정의하는데 사용 합니다. 만약 AOM에서 관리하는 객체에 존재하지 않는 객체를 관리하게 될 경우 EntityType 클래스에 새로운 객체가 등록되며, 또한 해당 객체의 속성에도 새로운 타입이 존재하는 경우 AttributeType 클래스에 등록 됩니다. 이렇게 등록된 타입 중 특별한 Rule이 필요한 경우 Meta level 안에 있는 Rule 클래스를 이용해 필요한 행위를 하게 됩니다. 이번 모화재 해와 법인 상품 모델에 적용된 부분은 위 그림의 붉은 점선영역 부분으로 AOM에서 가장 중요한 코어패턴들 중 Type Object 패턴과 Property패턴으로 구현 되었습니다. (이 두 패턴이 중요한 이유는 AOM이 두 패턴을 중심으로 Type Square패턴을 사용하여 런타임 시에 필요한 인스턴스를 제공하여 주기 때문입니다.) AOM을 구성하는 패턴에는 이 밖에도 수 많은 패턴들이 존재 하지만 상품 시스템의 적용범위를 벗어나므로 이번에는 위 세가지 패턴을 중심으로 설명 하도록 하겠습니다.
Type Object 패턴: Type Object 패턴은 1996년 랄프 존슨(Ralph Johnson)과 바비 울프(Bobby Woolf)가 PLoP’96 컨퍼런스에서 발표한 패턴입니다. Type Object 패턴은 인스턴스들를 해당 인스턴스들의 클래스로부터 분리시킴으로써 그 클래스들이 하나의 다른 클래스의 인스턴스들로 구현될 수 있도록 합니다. Type Object 패턴은 새로운 클래스들을 런타임 시에 생성될 수 있도록 해 줌으로써 하나의 시스템이 자신의 타입 결정 규칙을 제공할 수 있게 합니다.
Property 패턴: Property 패턴은 인스턴스 생성시 객체 안에 존재하는 서로 다른 타입의 속성을 대신 생성 합니다. String과 같은 단일 클래스이거나 List나 Map이나 Set과 같은 컬렉션 객체의 경우 Property패턴은 각각의 클래스 타입에 따라 각 속성 객체를 생성 합니다. Type Object 패턴이 인스턴스 자체의 타입변경에 초점을 맞추었다면 Property 패턴은 인스턴스 내부에서 가지고 있는 속성들에 관한 타입변경까지 그 영역을 넓혔다고 생각하면 이해가 쉽겠습니다. 보통 Property 패턴은 단독으로 사용하지 않으며 Type Object 패턴과 함께 사용 합니다. 그 이유는 속성만 동적으로 변경하는 경우가 많지 않기 때문입니다. 이렇게 Type Object 패턴과 Property 패턴을 묶어서 사용하는 경우를 Type Square 패턴이라고 부릅니다.
Type Square 패턴: Type Square 패턴은 Type을 관리하는 Type Object 패턴과Property 패턴의 조합 모양이 정사각형을 닮아서 지어진 이름입니다. 아래 그림은 Type Square패턴의 구조를 나타냅니다. Type Object 패턴의 구조에서 Class가 Type Square 패턴의 Entity에 해당됩니다. 하지만 동일하지는 않습니다. 왜냐하면 Type Square의 개체는 Property의 집합을 포함하고 있기 때문입니다. 역시 Type Object 패턴의 TypeClass가 EntityType입니다. 개체와 마찬가지로 EntityType은 PropertyType을 포함하고 있습니다. 이를 통하여 해당 개체에 속해있는 Property들을 묶는 동시에 Property 패턴에 필요한 Type을 PropertyType으로 분리하여 속성에 관련된 사항들을 관리할 수 있도록 하였습니다.
AOM의 상품 시스템에 적용
EntityType: 상품 시스템의 Entity는 크게 담보(Coverage), 목적물(Object), 정보항목(InformationItem) 등이 있었습니다. 따라서 각 담보Entity, 목적물Entity, 정보항목의 Entity Type이 존재 할 수 있습니다. 물론 필요하다면 사용자가 필요한 EntityType을 추가할 수 있습니다. 상품 시스템에서는 Entity라는 용어 대신 Element라는 용어를 사용하였습니다.
Entity: 상품 시스템의 Entity는 담보(Coverage), 목적물(Object), 정보항목(Information Item)이 될 수 있었습니다.
AttributeType: 상품 시스템에서 Attribute를 갖는 것으로는 상품, 담보, 정보항목 등이 있었습니다. 따라서 상품속성타입, 담보속성타입, 정보항목 속성타입이 존재 할 수 있었고 추가적인 속성타입이 발생한다면 사용자가 새로운 속성타입을 추가 할 수 있었습니다. 상품 시스템에서는 Attribute라는 용어 대신 Property라는 용어를 사용하였습니다.
Attribute: 상품 시스템의 Attribute는 상품속성, 담보속성, 정보항목 속성이 존재 하였습니다.
이상의 내용을 도식화하여 표현하면 다음과 같습니다.
결론
AOM을 사용하여 획기적으로 런타임 시에 상품구성에 필요한 여러 요소들과 속성들을 동적으로 구성하여 상품을 기획할 수 있었습니다. 모쪼록 여러 프로젝트에서 이 A.O.M 패턴이 널리 사용되어 보다 강력한 확장성을 구현 하는 데 많은 도움이 되었길 바라는 바이며, 다소 부족하거나 수정이 필요한 사항에 대해서는 코멘트나 메일로 많은 조언부탁드리겠습니다.
참고자료
- Ralph Johnson & Bobby Woolf, (The Type Object Pattern),
- Joseph W. Yoder & Ralph Johnson,‘ The Adaptive Object-Model Architectural
Style’, http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsWICSA3.pdf - 월간 마이크로 소프트 2008. 08 AOM아키텍처를 이루는 패턴
