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


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


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

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

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

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

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

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

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

어찌 보면 뜬 구름같은 분류기준이 복잡한 결정에는 지대한 도움을 주기도 한다.

Programming is Hard, Let's Go Scripting...은 스크립트에 대해 이야기 하고 있지만, 언어 설계자들이 고민했을 법한 주요 요인에 대해서 열거하고 있는 것이 눈에 띄었다. 비단 언어 설계가 아니더라도 메모해두면 영감을 줄 만한 내용이다.

모두 symmetry를 이루어 기억하기에 좋다. 애플리케이션 설계와 언어 설계의 문맥이 다른 만큼 binding, evaluation, typology의 의미는 상이하게 적용할 수 있다. 언어설계에서 binding이란 linking과 컴파일시 심볼 해석 등에 관여 되겠지만, 애플리케이션에선 조금 다르다. 순간 mapping과 혼란을 겪게 되는데, 마침 데이터 바인딩에 대해 언급한 글을 찾아서 설명을 생략한다. typology는 애플리케이션 설계에 대응시키가 어려울 수도 있다. 마지막의 둘은 binding을 애플리케이션 영역에 적용하면 등장할 법한 녀석들이 아닐까 하는 생각이 스치는데, 여튼 애플리케이션 영역에서 비스무리한 놈을 슬쩍 끼워 넣었다.


dispatch란 메시지(message)에 대해 객체(object)를 대응시키는 것이다. 애플리케이션 영역으로 확장해서 보면 multiple dispatch 사례로 멀티 쓰레드를 떠올릴 수 있다. 타입 레벨과 인스턴스 레벨로 나누어보면 또 다른 차원의 해석도 가능하다. 또한, 필터/인터셉터류의 기술을 생각해보라. 동일한 dispatch에 대해서도 상황에 따라 다른 인스턴스를 만들어낼 수 있다.¹

So basically, multiple dispatch is like democracy.
주의를 끄는 표현인데, 많은 사람들이 예상하듯이 병렬 프로그래밍이 주류로 부상하리라는 예상을 떠오르게 한다. 병렬 처리나 다중화는 이미 곳곳에 편재한다. 서버 클러스터링, 데이터 그리드, 풀링, 멀티 쓰레딩, 유얼코어, 쿼드코어, 미러링,  ...


떠오르는 생각은 많지만 커멘트는 자제하겠다. ㅡㅡ;

그 외에도 주옥같은 분류를 다수 제시하고 있다.