[객체지향의사실과오해] 06 - 객체 지도

---

 

✔️ 객체 지도

프로그래머의 가장 큰 숙제는 '변화하는 요구사항에 얼마나 더 잘 대응할 수 있는가?' 이다.

예를 들어보자. 고양이 스낵바에 새로운 신입 셰프냥이 들어왔다. 신입 셰프냥은 아직 메뉴 숙지에 미숙해서 레시피를 다 외우지 못했다.

이때 손님냥이 알바냥에게 딸기라떼를 주문했고, 알바냥은 신입 셰프냥에게 딸기라떼를 만들라고 지시했다.

하지만 신입 셰프냥은 딸기라떼 레시피를 몰라서 어떻게 해야 할지 고민 중인 상황이라면, 어떤 행위를 할 수 있을까?

 

1. 수석 셰프냥에게 딸기라떼 만드는 방법 물어보기
2. 레시피 북을 참고하여 딸기라떼 만들기

먼저, 첫 번째 방법의 경우, 만약 딸기라떼의 레시피를 얻을 수는 있지만, 변화하는 요구사항에 대응할 수 없다.

만약 손님이 추가적으로 ‘엇, 근데 딸기라떼에 들어가는 우유를 두유로 바꿔주실 수 있을까요?’ 라고 말을 했을 때

신입 셰프냥은 또 다시 멘붕에 빠져 수석 셰프냥을 귀찮게 할지도 모른다.

반면에, 레시피 북을 보게 된다면 여러 가지 상황에 대비할 수 있다.

우유가 아닌 두유를 넣을 때의 비율, 딸기 시럽의 비율 등 더 정확한 정보를 담고 있기 때문이다.

이와 같이, 사용자의 요구사항은 변할 수밖에 없기 때문에 ‘딸기라떼를 만들어달라’는 기능 자체에 집중하는 것이 아닌, ‘다양한 재료들로 여러 메뉴를 만들 수 있는’ 구조 중심의 개발을 진행하는 것이 좋다.

---

✔️ 기능 설계 vs 구조 설계

사용자의 요구사항은 기능을 기반으로 하기 때문에 훌륭한 소프트웨어를 만들기 위한 충분 조건이 될 수 있다.

그러나, 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요 조건이다.

탄탄한 구조를 가지고 있으면, 자연스럽게 새로운 기능을 안정적으로 빠르게 개발할 수 있기 때문이다.

(진흙탕에서 개발하는 게 쉬울까, 아니면 싱그러운 풀밭에서 개발하는 게 쉬울까?)

기능 기반으로 설계하게 되면, 각 기능들이 서로 밀접하게 관련이 있기 때문에

요구사항에 따라서 하나의 기능이 바뀌면 다른 기능들까지 영향을 받게 된다.

 

개발자는 늘 변화하는 요구사항에 대해 우리는 최대한 적은 비용으로 대응할 수 있도록 만드는 것이 숙명이다.

그리고 이를 위해서는 안정적인 구조가 꼭 필요하다.

---

✔️ 객체지향 세계 구축하기

먼저, 사용자에게 제공할 기능과, 기능을 담기 위한 구조를 준비해야 한다.
여기서 기능이란, 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위를 의미하며 대표적으로 '유스케이스 모델링' 이라는 기법을 사용할 수 있다.

반대로, 구조는 사용자나 이해 관계자들이 도메인에 대해 생각하는 개념과, 개념들과의 관계로 표현하는 것을 의미하며, 대표적으로 '도메인 모델링' 이라는 기법을 사용할 수 있다.

 

 

🌱 안정적인 재료 파밍하기 - 구조 설계

앞서 '도메인 모델링'이라는 말을 했는데, 도메인 모델링이라는 것이 뭘 의미하는 것일까?

이는 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태를 말한다.

한마디로 정의하자면, '멘탈 모델'이라고도 할 수 있다.

 

정말 쉽게 예를 들어보자. 우리는 다음과 같은 문장들을 접했다고 생각해보자.

- 물건을 살 수 있다.
- 물건을 팔 수 있다.
- 물건을 팔면 돈을 벌 수 있다.
- 물건을 사기 위해서는 돈이 필요하다.
...

 

우리는 앞서 제시된 4가지의 문장을 보면, 자연스럽게 '상점' 과 같은 두루뭉실한 것들을 머릿속에 떠올릴 수 있다.

대상에 대해서 우리의 뇌는 구조화를 하여 생각을 한 것이며, 하나의 멘탈 모델을 그렸다고 볼 수 있다.

 

멘탈 모델은 크게 사용자 모델 / 디자인 모델 / 시스템 이미지 3가지를 포괄하도록 추상화한 소프트웨어 모델이다.

디자이너와 사용자는 직접 교류하지 않고, 오직 시스템을 통해서 서로 소통하게 된다.

 

우리가 객체지향을 사용하면 사용자들이 이해하고 있는 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.
물론, 이 말이 현실의 구조를 그대로 따라가야 한다는 것은 아니다. ‘모방’하는 것이 아닌, ‘은유’를 통해서 재창조를 진행하는 것이며,

현실 객체가 할 수 없는 행동이나 가지지 않는 특성들을 가질 수도 있다. (= 이를 ‘표현적 차이’, ‘의미적 차이’라고도 한다)

 

예를 들어, 우리가 코드를 설계할 때 '커피'라는 객체에게 무료인지 판단하는 기능을 부여해줄 수 있다.

class Coffee(
    val price: Int
) {

    fun isFree(): Boolean {
        return price == 0 
    }
}

 

하지만 실세계에서 커피가 무료인지 행동할 수 있는가? 없다. 우리는 객체지향 세계에서만 이를 재창조한 것이다.

 

즉, 우리는 사용자가 이해하고 있는 도메인의 모델을 은유하여 코드에 나타내는 것이 목표이며,

이러한 사용자 모델의 경우 비교적 변경될 가능성이 적기 때문에 도메인 모델로 나타냈을 때 안정적인 구조를 설계할 수 있게 된다.

(우리가 이해하고 있는 '커피'라는 개념이 갑자기 '치킨'으로 바뀌지 않는 것처럼.)

 

🌱 불완전한 재료 파밍하기 - 기능 설계

사용자들은 시스템을 통해서 달성하고 싶은 목표가 존재하며, 시스템은 이에 대한 기능들을 제공해야 한다.

이는 곧 사용자와 시스템 간의 상호작용을 만들며, 이러한 상호작용을 텍스트로 정리한 것이 바로 ‘유스케이스’이다.

 

사용자의 목표가 곧 유스케이스의 핵심이며, 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다. 
- 마틴 파울로

 

위 문장을 보면, 왜 유스케이스가 '사용자 액터 다이어그램'이라고 불리는지 이해할 수 있을 것이다.

유스케이스의 가장 큰 핵심은 '사용자가 달성하고 싶은 목표'를 나타내는 것이기 때문이다.

유스케이스는 크게 다음과 같은 특징들을 가지고 있다.

 

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 ‘텍스트’일 뿐이다.

2. 여러 시나리오들의 집합으로 구성될 수 있다.

3. 단순한 기능의 집합이 아닌, 문맥을 통해 어떠한 이야기를 제공해야 한다.

4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 않는다. (자주 변경되는 요소를 제외하고, 행위에만 집중)

비슷하게, 내부 설계에 대한 정보 역시 드러내지 않는다.

 

유스케이스를 기반으로 객체를 변환하는 것은 창조일 뿐이며, 유스케이스를 통해 객체의 변화가 더 쉬워지는 것은 아니다.

유스케이스는 객체에 대해 어떠한 정보도 제공하지 않는다. 그저 도메인 모델에 대한 힌트 정도일 뿐이다.

---

 

✔️ 재료를 모아모아 - 기능과 구조를 통합하기

우리는 안정적인 구조를 도메인 모델로, 불안정한 기능을 유스케이스로 나타내는 방법을 알았다.

이제는 코드로서 객체들의 책임으로 분리를 해야 한다.

시스템은 사용자의 목표를 만족시키기 위해 협력하는 커다란 객체로 볼 수 있으며, 그 내부에는 더 작은 객체들로 쪼개질 수 있다.

시스템에 할당된 큰 책임이 작은 단위의 책임들로 분리되고, 필요한 메시지에 대해 식별해나가면서 객체들에게 책임을 할당할 수 있게 된다.

 

그리고, 이러한 객체들을 구현하기 위해 클래스를 추가하고, 속성과 함께 메서드를 추가하게 되면

시스템의 기능이 완성되어 나가는 모습을 볼 수 있을 것이다.

 

객체 설계는 요구사항을 식별하고 도메인 모델을 생성한 후,
소프트웨어 클래스에 메서드들을 추가하고,
요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하는 것이다. 
- Larman (2001)

 

이러한 책임 주도 설계를 통해 유스케이스로부터 메시지와 사용자가 달성하려는 목표를,

도메인 모델로부터 안정적인 구조를 제공받아서 협력하는 객체들의 공동체를 만들어내게 된다.

앞서 얘기했던 내용에 대해 큰 그림을 그려보자면 다음과 같다.

 

도메인 모델을 중심으로 객체 구조를 설계하고, 유스케이스의 기능을 객체의 책임으로 분배하는 것이다.

그렇다면, 왜 도메인 모델을 기반으로 객체의 구조를 설계할까?

 

앞서 커피 예시를 들었던 것처럼, 도메인 모델을 구성하는 개념은 (정말 완전히 뒤엎는 게 아닌 이상) 안정적으로 유지되기 때문이다.

안정적으로 유지되는 이유는, 도메인 모델을 구성하는 개념들 사이의 관계는 비즈니스 규칙을 기반으로 하고 있기 때문이다.

시스템의 비즈니스 정책이 정말 크게 변하지 않는 한, 비교적 안정적으로 유지되기 때문에 전체적인 구조가 한 번에 흔들리지 않는다.

 

그리고, 우리는 이러한 것들을 객체지향을 사용하여 코드로서 잘 녹여내게 된다면,

코드의 변경으로서 역으로 도메인의 변경도 유추할 수 있기 때문에 (가역성, reversibility)

협업의 관점으로서, 그리고 유지 보수의 관점으로서도 큰 장점을 얻어갈 수 있게 된다.