객체지도 만들기 「객체지향의 사실과 오해 | 조영호 | 2015 | 위키북스」

객체지향에서 설계는 크게 '기능 설계'와 '구조 설계'로 분류한다. 기능 중심의 설계는 현재 필요한 기능을 최대한 효과적으로 구현하는 것에 집중한다. 따라서 특정 기능이 아닌 영역이나 다른 분야로 설계를 확장하기가 힘들다. 가령, 카지노 업소라면, 해당 카지노 업소에서만 사용할 수 있도록 설계하는 식이다. 반면, 구조 중심의 설계는 구조 내에서 기능은 수시로 변할 수 있다는 점을 전제로 구현하며, 브랜드만 변경하면 어느 곳에서 모두 사용가능한 pc방 관리 프로그램과 같은 설계방식을 떠올릴 수 있다. 

 

객체지향 설계는 당연히 구조중심의 방식을 채택하지만 구조와 기능 중에서 어느 방법이 좋은지는 사실상 단언하기 어렵다. 아무리 훌륭한 구조를 사용했더라도 사용자는 어플리케이션 내부를 들여다볼 수 없다는 점을 고려했을 때, 과도한 구조와 설계가 독이 될 수도 있다.(경영자 관점) 결국, 사용자는 어플리케이션을 통해서 자신의 목적을 충분히 달성하기만 하면 된다.(사용자 관점) 따라서 일회성 이벤트와 같은 단기 프로젝트를 굳이 '구조적 설계'로 대응할 필요가 없다. 비효율적이기 때문이다. 상황에 따라서 구조를 지향하는 객체지향 방식보다 함수지향 방식이 훨씬 좋을 수 있다. 

 

 

｜선택

개발자, 설계자는 구조 중심의 '정적 모델'과 기능 중심의 '동적 모델'을 동시에 볼 수 있는 안목이 있어야 한다. 훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분조건이라면, 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요조건이다. 성공적인 소프트웨어는 훌륭한 기능을 제공하는 동시에 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있다. 소프트웨어에서 유일한 규칙은 요구사항이 항상 변경된다는 점이며, 이에 따라 설계자는 변경에 유연한 설계를 해야함과 동시에 기능 역시 효율적으로 작동되게끔 조절해야 한다. 개발자의 삶은 항상 변화에 준비가 된 삶이어야 한다. 개발자가 미래의 변경을 정확하게 예측할 수는 없지만 미래의 변경에 대비할 수는 있다. 이것이 유연한 설계다. 변경된 사항을 미리 예측하고 기능을 촘촘하게 설계하는 방식은 위험하다. 미래는 알 수 없다. 대비만 있을 뿐이다.

 

객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다. 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다. 이것이 객체를 기반으로 책임과 역할을 식별하고 메시지를 기반으로 객체들의 협력 관계를 구축하는 이유다. 안정적인 객체 구조는 변경을 수용할 수 있는 유연한 소프트웨어를 만들 수 있는 기반을 제공한다. 

 

 

｜유연성

객체지향 설계를 설계도로 표현하자면, 기능은 유스케이스 다이어그램으로 나타낼 수 있고 구조는 클래스 다이어그램으로 표현할 수 있다. 대부분 '유스케이스 다이어그램'을 강조하고 사용자 요구분석을 통해 유스케이스를 반드시 뽑아내라고 한다. 그런데 유스케이스를 너무 강조하다보면 자칫 기능중심으로 설계가 이뤄질 수 있다. 물론 다양한 케이스를 조합하다보면 좀더 일반적인 모델이 도출되겠지만 문제는 사용자가 해당 어플리케이션을 아직 한번도 접해보지 않았다는 것에 있다. 현실을 그대로 소프트웨어로 옮기는 임베디드 분야는 사용자의 유스케이스가 효율적이겠지만 '게임', 'vr'과 같은 가상 소프트웨어는 사용자의 경험이 크게 도움되지 않는다. 오히려 방해될 수도 있다. 

 

 

 

｜도메인 모델링 

도메인이 뭘까? 사전적인 용어는 아래와 같다. 

 

1. (지식·활동의) 영역; (책임의) 범위
2. (특히 옛날 개인·정부 등의) 소유지
3. 도메인

 

구조 중심의 설계를 도메인 모델링이라 하는데, 도메인 모델링에서는 유스케이스를 신뢰할 필요가 없다. 유저(고객)는 출시될 어플리케이션을 통해 어떠한 '목적'을 달성할 것인지를 말해주면 그것으로 된 것이다. 추상적인 분야의 어플리케이션일수록 유저가 생각하는 기능이 설계에 도움되지 않을 가능성이 높다. 만일 도메인 모델을 설계방식으로 채택했다면 유저에게 길을 묻지 말자. 도메인 주체들이 요청하고 응답하는 메시지에 집중하면서 지도를 만들어야 한다. 지도가 완성되면, 기능은 지도에 표시된 길을 따라 자연스럽게 흘러간다. 이를 객체지도라 하는데, 객체 지도는 빠르게 변화하는 기능을 수용할 자리를 제공하며, 안정적이며 재사용 가능하면서도 범용적이다. 

 

객체지향 설계에서 '도메인'은 '범위'라는 용어에 집중한다. 도메인은 사람이 생각하는 '세계'라 할 수 있다. 가령, '네이버'라는 도메인으로 접속하면 '네이버'라는 세계에 접속하는 것이다. 그곳에는 네이버가 설정한 여러 주체들이 협력관계를 형성하면서 서비스를 제공해준다. 하지만 도메인은 생각하는 사람마다 달라진다는 특이점이 있다. 가령,'놀이동산'을 생각해보자. 10살 미만 어린이, 20대 대학생, 콘텐츠 사업가, 유통업자 등... 사람이 처한 상황에 따라 '놀이동산'이란 세상을 보는 방법과 인식하는 객체들이 달라진다.

 

1] 10세 미만 어린이 : 재미있는 놀이기구, 동물원, 맛있는 음식점, 마음대로 하는 곳

2] 20대 대학생 : 시급높은 분야, 시설관리 분야, 현장직 등...

3] 콘텐츠 사업가 : 현금수익 직접 모델, 홍보관련 채널, 체험형 수익창출 공간 등....

 

똑같은 놀이동산도 연령, 직업, 성별, 성향 등...에 따라 그속에 속한 주체들이 달라진다. 만일 사업가의 기준에서 '놀이동산'이란 객체지향 설계를 한다면, 주인공(도메인 주체)들은 "체험형 수익창출 기구", "라이센스 수익창출 도구", "판매형 수익창출 도구". "기업홍보형 수익창출 도구" 등...으로 나눠질 것이다. 또한 판매형 수익창출 도구(레스토랑, 스낵샵, 팬시 등...)는 해당 재고량을 공급업자에게 요청(메시지)한다. 공급업자는 캐릭터나 상품 브랜드 제작업자에게 요청(메시지)을 해서 제품을 공급(메시지 응답)한다. 

 

도메인은 사람에 따라 달라지기 때문에 설계에 있어 가장 먼저 해야할 일은 '목적'찾기다. 사용자는 목적이 있기 때문에 소프트웨어를 이용한다. 설계자는 사용자가 생각하는 목적을 찾는 분야의 전문가가 되어야한다. 설계할 소프트웨어에 대해 사용자들이 생각하는 도메인들의 공통점을 모아서 최대한 일반화를 하는 일이 설계자의 첫번째 할일이다. 이 과정에서 유스케이스는 도움을 줄 수 있지만 그 뿐이다. 굳이 필요하지는 않다. 중요한 것은 오직 사용자가 생각하는 도메인 주체들과 목적이다.

 

설계자는 사용자 도메인을 만들고, 해당 주체들이 보내는 메시지에 주목한다. 만일 메시지가 하위구조로 내려간다면 객체를 생성하고, 협력관계 그리고 책임을 설정한다. 이렇게 책임설정이 끝났을 때 비로소 유스케이스 모델링(기능)이 필요하다. 흔히 알고 있는 것과 달리 도메인 방식에서 유스케이스 모델링은 설계의 시작이 아닌 중간 부분에서 자연스럽게 나와야 한다. 과거 UML관련 책에서는 유스케이스만 만들면 그 속에 있는 명사들은 '속성', 동사는 '메서드'로 만들면 쉽다고 나오는데 이는 착각이다. 유스케이스를 객체로 변환하는 작업은 예술적인 영역이다. 유스케이스는 설계 기법도, 객체지향 기법도 아니다. 유스케이스는 단지 사용자가 바라보는 소프트웨어 외부 관점일 뿐이다. 유스케이스는 객체지향과도 상관이 없다. 유스케이스와 객체의 구조 사이에는 아주 커다란 간격이 존재하기 때문이다. 이 둘 사이의 간격을 자동으로 해결할 수 있는 방법은 없다. 유스케이스는 객체의 구조나 책임에 대한 어떤 정보도 제공하지 않는다. 게임유저가 게임엔진의 구조에 관해 말할 필요도 없고, 알지도 못한다. 또, 알아서도 안 된다. 유저의 말이 진리라는 어설픈 설명에 속지말자.

 

유스케이스는 '시작점'과 '종료지점'을 알 수 있기 때문에 첫 번째 메시지 그리고 사용자가 달성하려는 목표를 알 수 있다는 점에 사용하면 된다. 이후부터는 도메인 모델을 만들고, 도메인 모델은 기능들을 담을 수 있는 은유적인 주체(객체)들을 생성한다. 이후 철저하게 메시지를 따라가면서 숨바꼭질 하듯 협력관계에 있는 객체들을 찾아내고 책임과 역할을 설정하면 객체지도가 완성된다.