brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Jul 31. 2024

업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것

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

엑셀 파일로 오가는 중요한 데이터가 있는 파일을 보다가 스스로의 취향을 수용하여 조각조각 떠오르는 생각을 UML 클래스도로 그려 보았습니다. 과거에 주로 쓰던 표현이긴 하지만 개발자들이 흔히 '업무 분석'한다고 할 때 공통적으로 하는 지적 행위의 단면이 패턴으로 드러날 수도 있겠다 싶은 마음에 글로 써 봅니다.

평면적 데이터를 구조화하기

쓸모가 불분명하지만 일단 생각을 클래스도를 그려 본 후에 찬찬히 살펴보았습니다. 우선 단박에 구조가 보인다는 점이 마음에 들었습니다. 엑셀로 만들어진 목록은 오와 열이 맞춰져 있어 일목요일한 맛은 있는데, 구조가 드러나지는 않습니다.

글로 쓰니 '오와 열이 맞춰져'라고 썼지만, 제 머릿속에 먼저 떠오른 단어는 Serialzation이었습니다. 자바 프로그래밍을 할 때 입출력(IO) 과정에서 익숙해진 용어인데, 위키피디아 정의를 보면 다음과 같습니다.

In computing, serialization (or serialisation) is the process of translating a data structure or object state into a format that can be stored (e.g. files in secondary storage devices, data buffers in primary storage devices) or transmitted (e.g. data streams over computer networks) and reconstructed later (possibly in a different computer environment).

찾아보길 잘했습니다. 정의 내용에 등장하는 문구인 'a format that can be stored'을 제 경우에 대입해 보니 다름 아닌 엑셀 양식입니다. 엑셀 파일은 그 자체로 보관 역할도 하는 형식이죠. 이 정의에 비춰보면 제가 한 행동은 Serialzation을 역행하는 Deserialization의 일종이라고 할 수 있습니다. 거꾸로 엑셀 포맷을 데이터 구조(data structure)가 드러나는 형태로 번역한 것이니까요.

엑셀 일괄 업로드를 함수로 표현한다면?

이렇게 위키피디아를 찾은 덕분에 UML 클래스도를 그리며 느낀 느낌을 객관적 정의에서 대비할 수 있게 되었습니다.

the process of translating a data structure or object state into a format

지극히 주관적 느낌이 아니라 글로 전달 가능한 내용이라는 증거를 찾았다고 할 수도 있습니다. :)

암튼 위키피디아 정의를 보고 다시 엑셀에 대입을 해 보니 첫 행의 칼럼 설명 부분은 데이터 구조를 구성하는 항목과 이름에 해당합니다. 그리고, 이하의 행들의 레이아웃까지 포함하면 바로 그 데이터 구조가 됩니다. 반면, 첫 행을 제외한 이후의 행들이 바로 객체 상태를 엑셀 형식으로 담은 것이라 하겠습니다.

이렇게 제가 다루는 상황과 위키피디아 정의를 오가며 대응시키다 보니, 이번에는 엑셀을 이용한 일괄 업로드 기능을 함수로 나타내면 Deserialization 정의와 굉장히 유사하겠다는 생각이 듭니다. 위키피디아 정의 덕분에 이렇게 한 수 배웁니다.

이 부분은 글을 쓰는 과정에서 우연히 배운 것이고, 원래 쓰려던 내용은 아닙니다. 애초에 쓰려던 내용은 취향에 따라 UML 클래스도를 그리면서 얻은 점입니다. 그중에서도 '업무 분석'이라는 관점에서 어떤 효용성이 있는지 다루려고 했습니다. 그 과정에서 '구조가 보인다'는 이점을 먼저 확인했죠. 그런데 이를 설명하는 과정에서 드러난 속말 'Serialzation'을 검색하다 얻은 지식을 추가했습니다.

인지의 지도 기능 그리고 빠짐없이 망라하기

다시 앞서 캡처 한 그림을 인용합니다. 이렇게 구조화하면 어떤 이점이 있을까요? 첫 번째는 스스로도 간과했고 많은 사람이 간과하는 듯한 인지의 지도 기능입니다. 저는 클래스도를 그리는 과정에서 또 그린 결과를 보면서 대략 '이런 식으로' 정보가 구성된다는 사실을 알게 됩니다. 이는 마치 지도를 보는 일과 같습니다. 그래서 반복해서 다루다 보면 굳이 볼 필요 없을 정도로 쉽게 익숙해지기도 합니다.

반면에 처음 보는 사람은 낯선 길을 가는 듯이 불안한 마음으로 데이터를 접하게 될 수 있습니다. 구조화된 클래스도가 정보의 지도 역할을 해 준다는 측면을 그간 스스로도 간과했다는 사실을 배웠습니다. 또한, 지도를 메타포로 역할을 설명했을 뿐, 소프트웨어 개발이야 지리적 인접을 기준으로 관계가 그려지지 않습니다.

경계를 나눠 객체 혹은 개체로 구분한 개념 사이의 관계를 기준으로 하죠. 그중에서도 주로, 포함 관계와 사용 관계 아니면 상속 관계가 드러나죠. 그래서 MECE(Mutually Exclusive Collectively Exhaustive) 즉, 데이터가 포함, 사용, 상속의 측면에서 빠짐없이 망라한 구조인지 걸러내게 됩니다. 개발자들이 중요하게 생각하는 '중복 제거'를 개념 단계에서 적용한 것으로 보아도 무방합니다.

포함관계인가? 내부 속성인가?

한편, 클래스에서 관계 표현을 고민하다가 결정한 내용으로 인해 엑셀 문서에서는 볼 수 없었던 것을 보게 된 내용이 있습니다. '업무 분석'이라는 주제로 돌아가면 굉장한 소득이죠. 겉으로 드러나지 않는 내용을 얻게 된 것이니까요.

클래스도 표기 방법에 대한 결정이라는 아주 단순한 사고 과정에서 관계에 대해 스스로 묻고 따지도록 유도라는 사고의 도구가 됩니다. 이 과정에서 설사 업무를 잘못 이해하고 했던 결정이라도 스스로 그 이유를 알고 있기 때문에 업무에 대한 이해가 부족했던 부분은 큰 문제가 되지 않습니다.

예를 들어 보겠습니다. 첫 번째는 특정 데이터를 한 객체의 속성으로 둘 것인가? 아니면 객체로 구분한 후에 포함 관계를 만들 것이냐 결정하는 일입니다. 아래 그림의 두 개의 표현은 내용상 동일합니다. 둘 중에 무엇으로 나타내어도 되는 것이죠. 그러니 모델러에게 결정의 순간이 됩니다.

간결하게 하려면 오른편이 좋죠. 왼쪽처럼 해서 효능감이 생기는 경우는 어떤 경우일까요? 앞서 인용한 그림처럼 상품 정보 중에서 다른 정보와는 무관하고 오로지 가격 정보에만 영향을 미치는 무언가를 표현할 때 적합합니다. 이렇게 정보를 경계를 두어 별도로 떼어 낼 때 우리는 이를 '객체'라고 부를 수 있습니다. 그리고, 떨어져서 독립적이 되었으나 여전히 관계를 맺을 수 있어 포함(embedding)되는 대신에 구성(composition) 관계를 맺을 수 있습니다.

상속과 구성 혹은 위임 관계

관계를 표현하며 새로운 인사이트를 얻은 예가 하나 더 있습니다. 엑셀에서는 모두 상품 정보였으니까 행의 이름이 '한글본' 따위로 복수의 의미로 썼습니다. 그런데, 가격을 객체로 구분하니 '한글본'이라는 말이 어색했습니다. 그냥 어색하기만 할까? 라고 스스로 물었습니다. 그게 아닐 법합니다. 상품 정보의 경우 번역이나 현지에 맞는 표현 방식을 말하는데, 가격의 경우는 환율이나 수수료 따위의 거래 조건에 따라 달라지는 것이라 내용 면에서도 다르다고 할 수 있습니다.

그러면서 새로운 계열의 정보군이 생기는 듯합니다. 그게 바로 상속, 영어로는 Genetic 혹은 Hierarchical 분류입니다. 정보가 상속을 통해 일가(Familiy) 혹은 계통을 이룰 수 있습니다.

더불어 경험적으로 그 유명한 GoF 디자인 패턴에서 말한 'Composition over inheritance'도 연상하게 됩니다. 가급적 정보를 조합할 때 객체 관점에서는 상속보다는 구성(composition) 관계를 쓰는 것이 유리하다는 설계 원칙이죠.

하지만, 그것이 역할에 따른 분화일 때는 위임과 구성이 좋으나 불가분의 관계인 정보를 체계화할 때는 상속이 더 나은 경우가 있는데, 제가 분석한 경우가 딱 그 상황인 듯합니다.