비즈니스 소통에서 관심사의 분리와 일반화의 효과

설계: 생각을 ‘차려’ 물질로 만드는 힘

<모델링 과정의 효용성과 모델링 결과의 쓰임새>에 대한 지인의 피드백 중에 다음과 같은 내용이 있었습니다.

Event page 내 image, video 등만을 보여주는 tab을 신설하고 싶다는 요구사항이었는데요. 처음에는 단순하게 ImageTab으로 구성했더라구요. 그래서 Tab이라는 개념을 빼고, Event에 종속적인 media를 제공하는 것이니 EventMedia라는 개념으로 만드는게 어떨지 제안하고 그렇게 결정됐습니다.

개발자인 지인은 이 장면을 비즈니스 소통이라고 불렀죠. 아마도 요구사항을 다루는 대화가 비즈니스 정의를 다루고 있기 때문이 아닌가 짐작됩니다. 지인이 저렇게 제안한 이유를 듣지 못했지만, 나도 모르게 짐작을 하고 공감하게 되었습니다.

Separation of Concerns의 소통 효과

지인이 추가한 가치를 뭐라고 설명할 수 있을까요? 제 머릿속에서는 가장 먼저 separation of concerns(관심사의 분리, 이하 SoC)라는 말이 떠올랐습니다. 위키피디아 정의를 찾아보면 다음과 같습니다.

In computer science, separation of concerns (sometimes abbreviated as SoC) is a design principle for separating a computer program into distinct sections.

그렇다면 무슨 관심사를 분리한 것일까요? Tab은 지인이 '개념'이라고 말했지만, 물리적으로 명확하게 드러나고 경계도 분명한 대상입니다. 심지어 대개의 경우 프로그래밍 요소와 그대로 대응될 수도 있습니다. 많은 개발자들이 이를 UI 컴포넌트(구성 요소)라고 부르죠.

반면에 다시 한번 다발말[1]을 보면 EventMedia는 Event라는 개념 하위에 종속된 image, video 따위를 포괄하는 일반화 개념이었습니다.

제 머릿속에서는 자연스럽게 SoC와 관련한 다양한 연관 개념이 떠오르지만, 자제를 시키고 지인의 관심사인 비즈니스 소통 맥락에서만 생각을 더 풀어 놓기로 합니다. SoC는 비즈니스 소통에서 어떤 효과를 줄 수 있을까요?

간단히 예시를 들어 보겠습니다. 지인의 경우처럼 EventMedia를 정의하여 쓰면, 해당 개념을 image로 보여줄 것인지 video로 보여줄 것인지 하는 표현 형식에 대화의 초점이 갈 가능성이 높습니다. 다시 말해서 Tab의 크기나 모양에 대한 이야기는 배제되는 것이죠. 나중에 EventMedia에 대해 훨씬 더 명확한 소통이 이뤄진 후에 Tab의 모양을 이야기하는 편이 효과적일 수 있습니다. 더구나 어떤 EventMedia는 Tab이 아닌 다른 UI 구성요소를 활용하는 것이 사용자 경험에 더 유리할 수도 있고요.

Separation of Concerns와 BoundedContext

또한, SoC를 역할이나 책임과 연결 지으면 필요한 이야기만 나누도록 제한하는 효과를 만들 수도 있습니다. 예를 들어 UI 구성요소를 관장하는 팀이 따로 있다고 해 보죠. 그렇게 되면 앞선 비즈니스 소통은 EventMedia 자체에 대해서 형식과 사용자 경험에 대해서만 유효하다고 생각해 볼 수 있습니다. DDD 책에서 제안한 개념 중에서 BoundedContext라는 것이 있습니다. 저는 이를 <입장에 맞춰 맥락을 나눈 BoundedContext>라고 쓴 일이 있는데요.

소통의 맥락(Context)을 특정 주제로 묶어서 경계를 지어 두면(Bounded) 효과적인 역할 분담과 협업이 가능합니다.

글을 마치기 전에 한 가지를 더 살펴보기로 합니다. 바로 지인이 Event라는 개념 하위에 종속된 image, video 따위를 포괄하는 EventMedia라는 일반화(generalization) 개념을 만든 일인데요. 범주화의 일종이라고 할 수도 있지만, 개발자에게 일반화는 흔하게 쓰고 훈련하기도 하는 사고법입니다.

일반화(Generalize)와 OOP의 상속(inheritance)

객체지향 프로그래밍을 할 경우 일반화는 상속(inheritance)과 유사하게 쓰일 수 있습니다. 과거 UML 도구들은 상속 관계를 표현할 때 Generalize라고 쓰기도 했습니다. 엄밀히 따지만 Generalize는 개념적인 수준에서 쓰는 말이고, 상속은 OOP 즉 프로그래밍 표현이라 완전히 같은 말은 아닙니다. 하지만, 다수의 UML 도구들이 코드 자동 생성 기능을 제공하면서 Generalize로 표기하면 자바의 extends 키워드로 엮인 클래스 코드를 만들어 주면서 사실상 같은 뜻으로 쓰이기도 했습니다.

하지만, 적어도 비즈니스 소통에서 쓰인 일반화가 상속과 그대로 대응되지는 않습니다. 그러한 점을 잘 활용할 수 있습니다. 구체적으로 말해서 소통에서 드러나지 않은 여지가 있다는 점을 깨닫고 생각을 차려 낼 수 있다면, 소통이나 사고를 더 엄밀하게 할 수 있습니다.

예를 들어 보겠습니다. 앞서 지인이 Event라는 개념 하위에 종속된 image, video 따위를 포괄하는 EventMedia라는 일반화한 내용을 다음과 같이 표현할 수 있습니다. 객체지향 프로그래밍 경험이 있는 분들은 아마 UML 표기법을 잘 몰라도 다음 그림이 직관적으로 뭘 뜻하는지 알 수 있을 것입니다. 표기법 자체보다는 그 다음이 더 중요합니다.

이렇게 질문을 할 수 있어야 하죠.

그렇다면, event마다 미디어는 이미지 하나 혹은 묶음 하나이거나
비디오 하나 혹은 묶음 하나인건가?

비즈니스 소통에서 일반화의 효과

그런 쓰임새가 아니라면 다른 대안을 생각할 수 있어야겠죠. 비즈니스 소통을 통해 요구사항을 캐낼(?) 때에도 중요한 요령은 구체적으로 그리고 가급적 상대 눈에 보이는 방법으로 소통을 끌어가는 것입니다. 그러려면 구체적 대안을 가정할 수 있어야 하겠죠.

대안을 하나 생각해 보겠습니다. 아래 UML 클래스도는 EventMedia가 두 가지 즉, EventImages 혹은 EventVideos 다수를 포함한다는 표기법입니다. 그리고 EventMedia 박스 안에 쓰인 event라는 내용은 EventMedia의 속성인데, 특정 이벤트에 한정되어야 EventMedia의 존재가 성립되기 때문에 쓴 내용입니다.

프로그래머(혹은 소프트웨어 개발자)는 이런 사고 훈련이 된 사람들이 많습니다. 그들이 비즈니스에서 다른 생각을 하는 사람들에게 소프트웨어가 어떻게 펼쳐질 수 있는지 예를 들어 줄 필요가 있습니다. 그래서 일반화 그리고 일반화된 결과가 실제로 어떻게 다양하게 펼쳐질 수 있는지 그리고 그 효과는 뭔지 보여주는 일이 개발자가 비즈니스를 수행하는 사람들과 함께 시너지를 낼 수 있는 협업 방법의 하나가 될 수 있습니다.