얼마전엔가 다음과 같은 질문은 받을 일이 있다.


어떻게 대답했는지 잘 기억이 안나지만 대략 다음과 같을 것이다.


설계하면 UML을 떠올리는 사람들이 많다. 프로그래밍하면 프로그래밍 언어를 떠올릴 수 있으니까 어찌 보면 이상한 것이 아니라고 할 수도 있다. 하지만, 프로그래밍과 설계는 정확도와 추상화 수준에서 큰 차이를 보인다. 실행가능한 UML이나 검증 가능한 모델에 대해서 오래전부터 노력이 있었지만, 아직은 널리 쓰이는 상황은 아니다. 대부분 설계를 한다는 경우 그 양상을 보면 너무나도 다르다. 흔히 볼 수 있는 설계의 행태를 보면 다음과 같다:

• 화면 설계서를 작성하고, ERD를 만든다. 거기에 더해서 CBD 프로젝트를 하라니까 클래스 다이어그램과 시퀀스 다이어그램을 적당히 그린다.
• 전문 설계서를 작성하고, 인터페이스의 메소드 시그너처를 확정한다.
• 배치 부분이나 시스템 연계 부분은 생략하고, 웹 애플리케이션쪽만 유스케이스 Realization으로 모델링을 한다.
• 화면 기획서를 작성한다.

ERD의 경우는 이미 오래전부터 쓰여왔고, 개념모델부분은 널리 쓰이지 않지만, 논리모델과 물리 모델은 대중화 되어 있다. 반면, UML 모델은 클래스 다이어그램을 작성할 수 있는 사람은 많지만, 설계모델을 자유롭게 표현할 수 있는 사람은 매우 드물다.

국내 대표적인 SI 업체 표준 산출물 이름이 '액티비티 다이어그램', '클래스 다이어그램'인 경우를 보고 깜짝 놀랜 일이 있다. 물론, 내막을 들어보면 이해할만한 이유가 있었다. 그러나, 기본적으로는 맞지 않는 표현이다. 만일 JEE 웹 애플리케이션을 '자바 코드', 'JSP 파일', 'JS 파일', 'XML 파일', '기타 텍스트 파일' 등으로 분류해서 제출하는 것과 비슷하다. 액티비티 다이어그램은 업무 분석 과정에서 쓰일 수도 있고, 분석 모델에서 쓰이거나 설계 모델에서 쓰일 수도 있고, 더러는 프로그램 내부 로직을 표현하는데 쓰일 수도 있다. 또, 객체 내부 상태 표현에 적합한 상태도(statechart)마저 액티비티 다이어그램의 일종이다.

배경 설명만 깔아놨는데 다시 질문으로 돌아가보면:

리뷰때 무슨 다이어그램을 보여줄지 혹은 다이어그램 자체를 보여줄지 말지는 적절한 수단을 선택하는 문제다. 그 전에 무엇을 리뷰 혹은 검토할지 결정해야 한다. 설계를 굳이 둘로 나누자면 API 설계와 메커니즘 설계로 나눌 수 있다. API 설계는 인터페이스 설계라고 할 수도 있고, CBD 어휘를 쓰자면 컴포넌트 외부 설계다. 밖으로 노출하는 즉, 제공하는 서비스가 무엇이냐 관점을 표현하는 것이다. 메커니즘 설계는 CBD라면 컴포넌트 내부 설계라고 할 수 있고, 대상의 객체 수나 입장에 따라서 패턴 적용의 문제가 되거나 알고리즘 설계와 동일한 작업일 수도 있다. 여하튼 클래스 내부적으로 효과적으로 작동하여 원하는 서비스를 적절하게 제공할 수 있는 것이 목적이다.

이전에 이글과 저글 등에서 누차 언급했지만, 모델링은 의사소통 도구이기에 API 설계와 메커니즘 설계시점에 의사소통이 활발하게 일어나게 사용하면 된다. 다시 말하면, 자신의 설계 방향과 결정사항을 잘 표현할 수 있고, 상대방이 쉽게 이해하고 의견을 제시할 수 있게 표현해야 한다.