Younghoe.Info (final edition)

최근 '체계 통합'이라고 부를 만한 작업을 했다.
막막했다. 개념 수준의 요소와 기술, 물리적 장치, 논리적 채널 등을 풀어내어 한 장의 개념도로 엮는 일이다.
거기에 제약사항으로 준수할 개념도가 몇 개 있었다.
이런 부류의 작업은 어떻게 해야 할까?
직관과 촉박한 상황에 의해 찾아낸 방법을 다시 뒤쫓으며 일반화를 시도한다.

작업 단계 구분

1. 카테고리를 준비한다. 혹은 빌딩 블록을 담을 영역을 구분한다.
입자(granularity)를 고르게 하려고 시간을 보내거나
영역 이름 짓는데 필요 이상 시간을 쓸 수 있으니 조심해야 한다.
주안점은 4~7개 정도로 나누기도 쉽고, 기억하는 데 무리가 없는 수준 유지다.

2. 참고자료나 제약사항에서 가져온 빌딩 블록을 배분한다.
바로 빌딩 블록을 가공하지 않고 원천(raw) 상태로 영역에 일단 포진시킨다.
무언가 엉성해 보여도 무시하는 능력이 주안점이다. :)
어떤 경우는 지적 수준에 관계없이 적절한 매핑이 어려운 예도 있다.

3. 영역 안에 빌딩 블록이 많은 경우 하위 영역을 만든다.
문서가 많으면 파일을 만들고, 파일이 많으면 디렉터리를 만드는 이치다.

4. 확보한 자료에 있는 모든 빌딩 블록을 영역 안에 포진할 때까지 2, 3번을 반복한다.

5. 비어 있는 영역이나 요소 창작
전체를 조망하는 관점을 유지하면 참조만으로는 부족한 부분이 생긴다.
이를 찾아내는 일은 창작활동이니 특별한 기법이 있기는 어렵다.
서태지가 말한 '창작의 고통'을 경험해야 한다.
하지만, 참고자료나 제약사항으로 주변을 매워 놓으면 확실히 도움이 된다.

6. 적절한 수준으로 가공한다.
필요 없는 내용 제거
중복하는 요소 하나로 합치기
이름 고치기
없는 요소 추가하기

7. 연관 체계와의 조화
연관 있는 다른 체계와 자연스럽게 융화할 수 있는지 검토가 필요하다.

6. 전문가 검토

일반 원칙/기법
A. 문답법 활용
1~7번에 걸쳐 항상 소크라테스의 대화법인 문답법을 적극적으로 활용한다.
주변에 아무도 없다면 자문자답이라도 해야 한다.

B. 개념 모델링 도구
생각의 동선을 줄여주는 전지와 포스트잇을 강추한다.
만일 매우 복잡한 모델링이라면 넓은 벽면 두 개쯤 마음껏 쓸 수 있는 회의실이
효율을 더욱 높여줄 수 있다.

2003년인가 2004년인가 인증샷인데... 이번엔 커다란 회의실 두 개 벽면을 모두 사용했다.

The Timeline/Milestone pattern라는 글을 보는데 마침 고민하던 문제라 모델이 한눈에 들어왔다. 결산 프로세스에 대해 고민하던 중이어서인지 꽤 인상적이다. 기사가 다룬 문제는 지표까지 관리한다는 점이나 특정 기술을 전제하고 있어 차이가 있지만, 참조할 내용이 있다는 점만으로도 고마운 그림이다. 도해(diagram)를 사용함에 있어서도 문제 상황을 보여주는 그림



정보의 구성을 다룬 그림


그리고, 주요 상태도




시스템 수준의 큰 그림




핵심이 되는 컴포넌트의 상호작용을 그린 그림은 훌륭한 모델링 결과이고 효과적인 전개다. 모델링을 하려면 이 정도는 해야 할텐데...

우발적인 장타였는데 이야기가 길어진다. 앞에 작성한 글이 주장하는 바가 불명확해 덧붙이는 글을 쓴다.

모델에서 코드를 생성하는 접근 자체에 대해 찬성과 반대 중에 한 가지 답만 하라면, 대답은 상황에 따라 다르다. 먼저 소프트웨어 공학의 미래를 위해선 이런 시도가 필요하다고 본다. 학교나 연구소에서 해야 할 실험을 프로젝트에서 시도하지만 않으면 말이다. 다음으로 모델링이나 설계를 공부하려는 개발자라면 강력 추천이다. 모델과 코드 사이에서의 추상화 수준의 차이를 이해하고, 모델링 도구와 IDE의 차이, 모델링 도구의 한계와 효용성 등을 알아야만 적절히 활용할 수 있다. 도구는 잘 알아야 잘 쓸 수 있는 법이다. 하지만 역시 공부는 개인적으로 해야지 프로젝트에서 제품을 만들면서 하는 방법은 옳지 않다. 프로젝트에서 코드 생성을 찬성할 경우는 언제일까?

아직은 행위 중심의 객체 설계가 힘든 현실을 인정한다면, ERD와 대응할 수 있는 수준의 도메인 객체의 관계를 뽑을 수 있는 프로젝트라면 모델과 코드의 연계를 권하고 싶다. 둘 중 한 쪽만 변경하고, 동기화를 하는 방법은 운영 단계에서 특히 효과를 발휘한다. 반면 운영 단계에선 모델을 쓸 생각이 없어 별도의 설계 문서를 요구한다면, 모델은 곧 현실과 마치 화석처럼 현실과 멀어질 수 있다.

Anemic model과 같이 객체가 데이터 운반이나 구조체 정도로 쓰이는 형국을 비난하는 말이 있긴 하지만, 대규모 프로젝트에서는 ERD와 대응할 수 있는 수준의 객체 모델을 만들어내는 경우는 극히 드물다. Level 1은 넘어야 다음 단계로 갈 수 있는 법이다.

컴포넌트를 채용해서 개발했고 즉, CBD이고 동시에 운영 단계에서 컴포넌트가 실제로 의미를 지니는 경우라면 컴포넌트 인터페이스는 모델과 코드 동기화를 확보하면 유용하다. 컴포넌트 인터페이스 변경은 상당한 공수를 요하기 때문에 유지보수를 맡은 개발자도 사람답게 살기 위한 절차를 마련해둘 수 있다. 필요한 시간을 보고하고, 모델을 수정해 작업 흔적을 남긴 후에 코드에 반영한다. 이 때, 자동생성하는 부분과 개발자가 작성하는 코드는 물리적으로 분리하기를 권장한다. 최근의 모델링 도구는 개발자가 작성한 코드에 덮어쓰기를 하는 일은 드물지만, 자칫 실수하면 여전히 기존 코드를 날릴 수 있기 때문이다. 또한, 모델 수준에서 의미가 있는 정보는 프로그래밍 코드 수준이 아니다. 그래서 코드에서도 추상화 정도가 높은 인터페이스 영역과 구현체를 분할하는 방법은 권장할만한 방법이기도 하다.

그러나 위와 같은 수준에 도달한 조직은 많지 않다. 아쉽게도 다음과 같은 현상을 자주 접할 수 있다.

• 프로젝트 주관사 혹은 고객사 QA 담당자가 한 가지 방법 허용한다면 표준화 하라고 한다. 내용면에서보면 강제하는 형식이 맞지 않는데도 말이다. 이런 경우는 획일화란 용어를 권장해주고 싶다.  
• 프로젝트 초기에 배운 방법이나 가이드나 나온 형식대로 방대한 UML 모델을 작성한다. 유스케이스 모델을 작성하다 보면 너무 간단한 내용을 어렵게 그리는 듯한 느낌을 받는다. 그리고 업무 별로 수 백개의 다이어그램이 거의 유사하다. 업무명이나 데이터를 담는 클래스 이름만 다르고 나머지는 거의 동일해서 모델링이 단순 작업으로 전락한다.
• 객체가 너무 많아 ERD를 역공학으로 읽어와서 객체 모델로 변경한다. 객체가 너무 잘게 쪼개져서 있어 걸핏하면 Join을 해야 하는 형국이다. 속성 이름이 대부분 약어라 도저히 알 수가 없다. 유지보수를 위해서는 엑셀로 테이블과 속성 이름을 설명하는 문서를 작성해야한다. (그렇다면 모델은 용도는 무얼까?)
• 중요한 업무 규칙은 UML 모델에 담기 어려워서 설계를 이중으로 하는 느낌이다. 그러는 가운데 개발 단계가 다가왔다. 일단 코드를 만들어야 하는데, QA 담당자가 설계를 완성하고 코드 생성을 통해서 만든 코드로만 구현을 하라고 한다.
  
• 공동작업하던 모델이 마구 꼬인다. CVS/SVN/ClearCase 등을 연계해서 써보니 충돌을 해결하는 작업이 너무 힘들다. 그냥 동시에 작업을 하지 못하게 하고 공통으로 쓰는 객체는 공통 담당자를 두어 통합하게 한다. 막판에 일이 몰리면, 통합 담당자가 죽어 나거나, 암묵적 합의에 의해 대강 알아서 해결한다. (동일한 쓰임을 갖는 객체가 다른 이름으로 여러 개 존재한다.)
  

더 길어지면 자칫 비관적인 글로 오인할 듯 해 그만둔다. 이야기가 너무 길어질 해서 이제 마무리를 해야겠다. 느닷 없긴 하지만 MDA를 소개하고자 한다. 쉽게 말해 MDA는 모델과 코드를 좀 더 유기적으로 연계하여 개발 공정을 개선하려는 시도이다.

앞서 언급했던 2003년 프로젝트에 참여할 당시 모델링 도구에 대한 환상을 가지고 있던 나에게 가장 획기적으로 보였던 도구는 MDA 툴이었다. 당시는 OMG가 MDA 판촉에 열을 올리던 때였고, 아크스타일러, 카비라가 시장 선도 업체였다. 당시 시장 선도 UML 모델링 도구였던 Rose나 2인자 Together는 선언부 정도의 코드는 모델과 코드 사이의 양방향 변환, 일명 RTE(Round-Trip-Engineering)를 지원했다. 그 수준도 조악하다 느낄 정도였는데, 여하튼 내부 구현 코드 생성은 이상에 지나지 않았다. 그러던 차에 만난 카비라 시연은 놀라웠다. UML 모델에 몇 가지 규칙을 일종의 스크립트로 입력한 후에 적용한 플랫폼 유형을 선택하고, 변환을 시도하면 해당 플랫폼에서 구동 가능한 모델(Platform Specific Model)이 나오는데 이는 바로 실행이 가능했다. 놀라움은 얼마 가지 않아 궁금함으로 바뀌었다. 가변적인 업무 규칙을 어떻게 스크립트 언어만으로 표현할 수 있고, 접속자가 많아지면 과연 그에 맞게 규모 가변성(Scalability)를 제공할까?

쉽게 답을 찾을 수 있었다. 해당 툴을 도입해서 팔려던 시도는 결국 국내에서 한 곳도 레퍼런스를 찾지 못하고 실패로 돌아갔다. 지금 보니 해당 업체도 방향을 약간 전환한 듯 하다. MDA를 위해 등장한 UML2.x는 많이 발전한 듯 보이지만, MDA는 여전히 무척 느린 행보로 진행하고 있고 얼마후 등장한 MDD는 MDA로 가기 위한 과도기 성격처럼 보인다. UML을 전문적으로 연구하는 어떤 분의 말에 따르면 유럽의 자동차 업계에서 MDA는 실적이 있다고 한다.

하지만 정보시스템/엔터프라이즈 영역에서 가변적인 요소를 체계적으로 정리해서 정형화를 단기간에 하겠다고 한다면 이는 풋내기로 볼 수 밖에 없다. 마틴 파울러가 illogic이라고 표현한 기업/조직의 역사가 만들어낸 일반화 하기 힘든 비즈니스 규칙을 수식으로 풀어내기엔 소프트웨어 공학은 아직 많이 어리다. 솔직히 내 생전에 얼마나 비슷하게라도 가능할지 의문이긴 하지만, MDA는 어찌 보면 많은 소프트웨어 공학 관계자에겐 꿈이자 실현 가능하게 보이는 지향점이다.

만일 여러분이 복잡한 절차를 간략히 요약하여 2페이지 남짓의 워드로 만들었다고 해보자. 작업의 순서와 판단에 따른 분기 등의 정보를 집약해서 표현하거나 추상화/개념화 하기 위해 도식화를 한다. 그런데 만약 다음과 같은 그림을 그렸다면...


나는 이 그림을 보고 '전용면적이 좁은 아파트' 혹은 '터무니 없이 큰 베란다' 같은 것이 떠올랐다. 차라리 도식화를 하지 않고, 행위를 표현한 글이 폰트를 7, 8 배 키운 후 앞에 순번을 다는 것이 같은 공간을 쓰면서 훨씬 더 정보를 잘 표현하는 방법일 것이다. 그림의 50%를 넘는 여백은 ... 무언가 채워지기 전까지 주차장으로 써야 할까 :)

펌질하다 알게 된 포스트: :::Starry Night::: :: 주기율표

와우~ 놀랍다. 예전에 모델링 하면 UML 다이어그램만 떠올리던 때와 달리.. 요즘에야 '공간을 활용하는 역량', '정보의 응축', '조직화', '균일한 추상화 수준' 같은 것들을 생각할 수 있게 되었다. :::Starry Night::: :: 주기율표의 그림을 보라. 앞에 나열한 단어 같은건 무시하고, 보기만 해도 눈이 즐겁지 않은가.



그리고 이 그림^[각주:1]. 보는 순간 나도 이런 그림을 그려보고 싶다는 욕심이 생긴다.

당신이 생각하는 TDD에서 나눈 대화 후에 내가 왜 TDD에 관심을 가졌던가 떠올랐다. 생각해보면 TDD라는 말을 사용하여 몇차례 강의까지 했음에도 불구하고, 아무도 TDD가 무어냐고 나에게 묻지 않았던 것 같다. 내가 TDD를 처음 찾은 것은 UP/RUP 혹은 CBD 방법론을 써서 UML 모델링을 할 때의 취약성 때문이었다. 설계 언어로써 UML은 한계가 많다. 결국, 10여년이 지났어도 UML은 설계서를 Unified 하지 못한 것 같다. 유용하게 쓰이는 것은 높은 추상화 수준에서 클래스 다이어그램이나 객체가 스무개를 넘지 않는 작은 시퀀스 다이그램정도다.

내가 과거에 답답했던 것은 가이드에 의해 만들어내는 UML설계모델의 수많은 다이어그램들이 별로 유기적으로 코드로 이어지지 못하고 있다는 점이다. 내가 만들어야 했던 것은 요구사항부터 구현으로 이어지는 전체 표준 프로세스였다. 결국 유스케이스에서 테스트케이스를 만들게 하고, 이 때 설계한 내용을 구현에 반영하게 했다. 그때, 해결하지 못했던 것은 요구사항에 대응하는 Acceptance test수준에서 컴포넌트 테스트, 그 하위의 클래스 테스트까지 체계화하고, 유기적으로 연계할 방법이었다.

그로부터 2~3년이 흘렀다. 토비형 질문을 통해 내 머리속에서 추출한 TDD의 정의는 내가 TDD를 어떻게 써먹었는가를 여실히 보여준다. 당시 내 입장에선, 지금 이곳에서 유용한 내용을 실천하는 것이지, 원론적인 TDD는 아니었으니까.(지금은 2~3년 전과 같은 상황이 아니고, 이젠 TDD를 Kent Beck이 정의한대로 이해할 필요가 있기 때문에 다시 TDDBE책을 열어봤다. Preface를 꼭 보시기 바란다. ^^)


2~3년이 지났지만, 밑줄친 저 부분에 대한 대답은 여전히 요원하다. 나비효과로 토비형과의 대화에서 'TDD에 어떻게 관심을 가졌는지'를 떠올렸지만, 밑줄친 과제(?)는 쉽게 잊지 못하는 것 같다. 내가 DDD에 관심을 갖았던 것도 거의 같은 이유다. UML을 소모적인 다이어그래밍에 쓰지 않고, 어떻게 설계모델을 구현에 유기적으로 반영할 것인가?

마침 다시 한번 모델링을 돌아볼 기회가 왔다. 어제부터 일을 잠시 쉬면 머리 속에서 모델링에 대한 아이디어가 모락모락 피어난다.

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


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


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

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

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

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

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

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

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