평면적 데이터를 구조화하고 묻따풀로 설계하기
설계: 생각을 ‘차려’ 물질로 만드는 힘
<업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것>에서 다루었던 '평면적 데이터를 구조화하기'는 다른 분들도 실용적으로 활용할 수 있다는 생각에 조금 더 구체적으로 설명해 보겠습니다.
평면적 데이터를 구조화하기
여러분이 낯선 업무를 다루는 엑셀 파일을 만났다고 가정하면 아마 거의 비슷하게 적용할 수 있지 않을까 싶습니다. 여기서 설명하는 사례는 중국의 동영상 플랫폼에서 주로 활동하는 왕홍(influencer) 소속사의 소개 파일입니다.
먼저 시트 이름은 클래스 후보입니다.
그리고 시트의 컬럼은 클래스의 속성으로 대응시키면 간단하게 UML 클래스도를 만들기 시작할 수 있습니다.
2단계 칼럼은 Aggregation(集積) 관계로 나타내기
여기까지는 기계적으로 할 수 있는데, 다단계 칼럼을 만나면 고민을 하게 될 수 있습니다. 제 경우에도 2단계 칼럼이 있네요. 제 경우는 경험이 도리어 여러 가지 불필요한 생각을 하게 만드는데요. <업무 분석 과정에서 UML 클래스도를 쓰면 얻는 것>에서 설명한 바 있는데, 속성은 포함 관계로 표현할 수 있습니다.
다만, 이 경우는 포함 관계 보다는 Aggregation으로 보입니다. 한국말로는 뭐라 하나 살펴보는데 깔끔하게 '이거다' 싶은 말은 모르겠고 '집적(集積)'이 가장 마음에 듭니다.
그렇게 정하면 다음 클래스도처럼 2단계 칼럼의 상위 칼럼은 클래스 이름으로 하고, 시트 이름에서 출발한 클래스와 집적 관계를 갖게 합니다. 그러고 나서 하위 칼럼은 새로 만들어진 클래스의 속성으로 집어 넣습니다. 간단하죠?
2단계 칼럼을 UML 집적(Aggregation) 관계로 풀어내는 방법만 안다면 나머지는 거의 기계적으로 할 수 있습니다.
묻따풀은 분석과 설계를 위한 훌륭한 방법
여기까지 했다면 최초에 목표한 '평면적 데이터를 구조화하기'는 끝났다고 할 수 있습니다. 그런데 사실 조금 더 지적인 작업은 여기서 시작합니다. 흔히 '분석'이라고 부르는 행동도 여기서 도메인 전문가[1]에게 질문을 하는 일로 시작합니다. 더러는 '분석'이라는 행동이 '설계'와 경계가 모호해지기도 합니다. 이는 자연스러운 일인데, 이해한 내용을 만드는 입장에서 그대로 받아들이지 않고 '더 나은 관계와 구조를 모색'하기 때문입니다.
묻따풀은 최봉영 선생님께서 만드신 말로 묻고 따져서 풀어보는 과정을 말합니다. 다양한 이유로 묻따풀을 할 수 있는데, 저는 설계를 <자기중심에서 팀 중심으로 확대하기>의 일환으로 보았기 때문에 팀의 지식이 되도록 묻따풀하고 그 내용을 나만 머릿속에 두지 않기 위해 표현하는 일에 초점을 맞춰 보겠습니다.
설계 경험에 의해 눈에 띄는 정제[2] 작업이 두 가지 있습니다. 하나씩 해 보죠. 먼저 집적(Aggregation)으로 추가한 클래스 이름에 개선의 여지가 없는지[2] 보겠습니다. 보통 엑셀의 경우는 하나의 행(row)을 레코드 개념으로 써서 하위 데이터를 담습니다. 그러다 보니 2단계로 쓰면 상위 칼럼 이름이 핵심 개념 혹은 개체를 나타내고, 하위 칼럼은 그 맥락으로 줄여서 쓰는 일이 자연스럽습니다.
하지만, 평면에서 계층화로 바꾼다는 말은 떨어져 나가서 객체가 된 새로운 클래스도 '따로 또 같이' 존재할 수 있도록 명실상부한(self-descriptive) 이름을 주는 일이라 할 수 있습니다. 제 경우 抖音은 글로벌 서비스 TikTok의 중국 서비스명이고 小红书 역시 유사한 동영상 서비스를 제공하는 플랫폼인데, 이들과 艺人清单가 집적 관계를 갖는다는 것은 어색합니다.
클래스도 정제: 의미를 좁힌 이름 사용하기
艺人清单로는 연예인 혹은 왕홍(influencer) 명세를 말하기 때문이죠. 그래서 제미나이 도움을 받아서 개선에 쓰일 단어를 찾았습니다.
(더 조사하는 대신에) 제미나이를 믿기로 하죠.
속성에 대해 적절한 데이터 타입 따져 보기
다음에 특별한 도메인 지식 없이 엑셀 내용만으로 할 수 있는 일은 데이터 타입을 추론하는 일입니다. 각 칼럼의 내용을 보면서 속성 값이 어떤 타입인지 생각해 보는 일이죠. 어떤 내용은 프로그래머라면 상식적으로 추론할 수 있는 내용도 있습니다. 반면에 의미나 척도 따위를 알기 위해 질문을 만들어 도메인 전문가를 찾아야 하는 경우도 있죠. 둘 다 유의미한 분석이나 설계 활동이 될 수 있습니다. 그리고, 구현을 위해서는 필수적인 활동이기도 합니다.
이하 작업은 간략하게 설명하고 마치겠습니다. 먼저 단순 데이터 타입 예를 들어 숫자냐 금액이냐 문자냐 수준의 내용도 있겠죠. 그리고 일종의 라벨(label)로 범주화 할 수 있는 경우들이 있습니다. 프로그래밍 언어의 enum 타입과 비슷한 것들인데, 이들을 추출하여 제대로 다루면 응용 프로그램의 품질을 높일 수 있습니다.
그 이외에 논의와 확인이 필요한 아이디어가 나올 수 있습니다.
펜 규모(粉丝量)를 기준으로 등급을 분류하던데 기준이 되는 수치는 무엇인가?
기타(其他平台)로 표현한 다른 플랫폼은 어떻게 취급하는가?
나열 순서(序号)는 어떤 의미를 지니는가?
분석의 네비게이터 역할을 하는 엑셀 내용
한편, 엑셀 내용을 보다가 다른 분석 대상을 발견하게 되는 경우도 있습니다. 제 경우는 특정 셀의 값을 브라우저에 입력했더니 아무나 로그인 할 수 없는 별도의 페이지가 존재하는 것을 알 수 있었습니다.
UML로 어떻게 표현하나요?
UML 모델링 전문 도구가 있지만 요즘은 저도 쓰지 않습니다. 개인적으로는 두레이 기본 편집기에 내장된 PlantUML을 씁니다.
꼭 두레이를 쓰지 않아도 PlantUML을 쓸 수 있는데, 클래스도의 경우 아래 링크에 접속해서 사용법을 익히고 작성이나 작성 연습도 직접 해 볼 수 있습니다.
https://plantuml.com/ko/class-diagram
주석
[1] Domain expert를 번역해 쓰는 말로 추정하는데, 현실에서 그런 말은 잘 안 써서 매우 어색합니다. 보통 외주 개발이나 업무 자동화를 할 때는 '해당 업무를 오래 하신 분'이 여기에 해당하고, 스타트업에서 새로운 아이디어로 제품을 개발할 경우는 제품 관리자나 기획자가 여기에 해당한다고 할 수 있습니다.
[2] 정제라는 단어가 영어 단어 refinement의 번역어로 쓰던 것이라 어색한데요. 뒤이어 자연스럽게 쓴 '개선의 여자가 없는지' 살피고 개선하는 행위라고 할 수 있습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
