장안동베짱e's LoG# 머리 복잡할 때 보면 더 복잡해지는 블로그 RSS FEED

좀 이상한 부분 있으면 지적해주시고,

혹시 이소스를 사용하실려면,

리플달아주시고 가져가세요~ ^^흣

출처 : 골방 ( http://blog.netmarble.net/sannym/121347 )

ㄱ을 누르고 한자키를 눌렀을때
！ ＇ ， ． ／ ： ； ？ ＾ ＿ ｀ ｜ ￣ 、 、 。 · ‥ … ¨ 〃 ­ ― ∥ ＼ ∼ ´ ～ ˇ ˘ ˝ ˚ ˙ ¸ ˛ ¡ ¿ ː

ㄴ을 누르고 한자키를 눌렀을때
＂（ ）［ ］｛ ｝‘ ’ “ ” 〔 〕〈 〉《 》 「 」『 』【 】

ㄷ을 누르고 한자키를 눌렀을때
＋－＜＝＞± × ÷ ≠ ≤ ≥ ∞ ∴ ♂ ♀ ∠ ⊥ ⌒ ∂ ∇ ≡ ≒ ≪ ≫ √
∽ ∝ ∵ ∫ ∬ ∈ ∋ ⊆ ⊇ ⊂ ⊃ ∪ ∩ ∧ ∨ ￢ ⇒ ⇔ ∀ ∃ ∮ ∑ ∏

ㄹ을 누르고 한자키를 눌렀을때
＄ ％ ￦ Ｆ ′ ″ ℃ Å ￠ ￡ ￥ ¤ ℉ ‰ ? ㎕ ㎖ ㎗ ℓ ㎘ ㏄ ㎣ ㎤ ㎥ ㎥ ㎦ ㎙ ㎚ ㎛ ㎜ ㎝ ㎞ ㎟
㎠ ㎡ ㎢ ㏊ ㎍ ㎎ ㎏ ㏏ ㎈ ㎉ ㏈ ㎧ ㎨ ㎰ ㎱ ㎲ ㎳ ㎴ ㎵ ㎶ ㎷ ㎸ ㎹ ㎀ ㎁ ㎂ ㎃ ㎄ ㎺ ㎻ ㎼
㎽ ㎾ ㎿ ㎐ ㎑ ㎒ ㎓ ㎔ Ω ㏀ ㏁ ㎊ ㎋ ㎌ ㏖ ㏅ ㎭ ㎮ ㎯ ㏛ ㎩ ㎪ ㎫ ㎬ ㏝ ㏐ ㏓ ㏃ ㏉ ㏜ ㏆

ㅁ을 누르고 한자키를 눌렀을때
＃ ＆ ＊ ＠ § ※ ☆ ★ ○ ● ◎ ◇ ◆ □ ■ △ ▲ ▽ ▼ → ← ↑ ↓ ↔ 〓 ◁ ◀ ▷ ▶ ♤ ♠ ♡ ♥
♧ ♣ ⊙ ◈ ▣ ◐ ◑ ▒ ▤ ▥ ▨ ▧ ▦ ▩ ♨ ☏ ☎ ☜ ☞ ¶ † ‡ ↕ ↗ ↙ ↖ ↘ ♭ ♩♪ ♬ ㉿
㈜ № ㏇ ™ ㏂ ㏘ ℡ ? ª º

ㅂ을 누르고 한자키를 눌렀을때
─ │ ┌ ┐ ┘ └ ├ ┬ ┤ ┴ │ ━ ┃ ┏ ┓ ┛ ┗ ┣ ┳ ┫ ┻ ╋ ┠
┯ ┨ ┷ ┿ ┝ ┰ ┥ ┸ ╂ ┒ ┑ ┚ ┙ ┖ ┕ ┎ ┍ ┞ ┟ ┡ ┢ ┦ ┧
┩ ┪ ┭ ┮ ┱ ┲ ┵ ┶ ┹ ┺ ┽ ┾ ╀ ╁ ╃ ╄ ╅ ╆ ╇ ╈ ╉ ╊

ㅅ을 누르고 한자키를 눌렀을때
㉠ ㉡ ㉢ ㉣ ㉤ ㉥ ㉦ ㉧ ㉨ ㉩ ㉪ ㉫ ㉬ ㉭ ㉮ ㉯ ㉰ ㉱ ㉲ ㉳ ㉴ ㉵ ㉶ ㉷ ㉸ ㉹ ㉺ ㉻
㈀ ㈁ ㈂ ㈃ ㈄ ㈅ ㈆ ㈇ ㈈ ㈉ ㈊ ㈋ ㈌ ㈍ ㈎ ㈏ ㈐ ㈑ ㈒ ㈓ ㈔ ㈕ ㈖ ㈗ ㈘ ㈙ ㈚ ㈛

ㅇ을 누르고 한자키를 눌렀을때
ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮
⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂

ㅈ을 누르고 한자키를 눌렀을때
０１２３４５６７８９ⅰⅱⅲⅳⅴⅵⅶ ⅷ ⅸ ⅹ Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ

ㅊ을 누르고 한자키를 눌렀을때
½ ⅓ ⅔ ¼ ¾ ⅛ ⅜ ⅝ ⅞ ¹ ² ³ ⁴ ⁿ ₁ ₂ ₃ ₄

ㅋ을 누르고 한자키를 눌렀을때
ㄱ ㄲ ㄳ ㄴ ㄵ ㄶ ㄷ ㄸ ㄹ ㄺ ㄻ ㄼ ㄽ ㄾ ㄿ ㅀ ㅁ ㅂ ㅃ ㅄ ㅅ ㅆ ㅇ ㅈ ㅉ ㅊ ㅋ ㅌ ㅍ ㅎ
ㅏ ㅐ ㅑ ㅒ ㅓ ㅔ ㅕ ㅖ ㅗ ㅘ ㅙ ㅚ ㅛ ㅜ ㅝ ㅞ ㅟ ㅠ ㅡ ㅢ ㅣ

ㅌ을 누르고 한자키를 눌렀을때
ㅥ ㅦ ㅧ ㅨ ㅩ ㅪ ㅫ ㅬ ㅭ ㅮ ㅯ ㅰ ㅱ ㅲ ㅳ ㅴ ㅵ ㅶ ㅷ ㅸ ㅹ ㅺ ㅻ ㅼ ㅽ ㅾ ㅿ ㆀ ㆁ
ㆂ ㆃ ㆄ ㆅ ㆆ ㆇ ㆈ ㆉ ㆊ ㆋ ㆌ ㆍ ㆎ

ㅍ을 누르고 한자키를 눌렀을때
Ａ Ｂ Ｃ Ｄ Ｅ Ｆ Ｇ Ｈ Ｉ Ｊ Ｋ Ｌ Ｍ Ｎ Ｏ Ｐ Ｑ ＲＳＴＵＶＷＸＹＺ
ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ

ㅎ을 누르고 한자키를 눌렀을때
Α Β Γ Δ Ε Ζ Η Θ Ι Κ Λ Μ Ν Ξ Ο Π Ρ Σ Τ Υ Φ Χ Ψ
Ω α β γ δ ε ζ η θ ι κ λ μ ν ξ ο π ρ σ τ υ φ χ ψ ω

ㄲ을 누르고 한자키를 눌렀을때
Æ Ð Ħ IJ Ŀ Ł Ø Œ Þ Ŧ Ŋ æ đ ð ħ ı ij ĸ ŀ ł ø œ ß þ ŧ ŋ ʼn

ㄸ을 누르고 한자키를 눌렀을때
ぁ あ ぃ い ぅ う ぇ え ぉ お か が き ぎ く ぐ け げ こ ご さ ざ し じ す ず せ ぜ そ ぞ た だ ち ぢ っ つづ
てでとどなにぬねのはばぱひびぴふぶぷへべぺほぼぽまみむめもゃやゅゆょよらりるれろゎわゐゑをん

ㅃ을 누르고 한자키를 눌렀을때
ア ィ イ ゥ ウ ェ エ ォ オ カ ガ キ ギ ク グ ケ ゲ コ ゴ サ ザ シ ジ ス ズ セ ゼ ソ ゾ タ ダ チ ヂ ッ ツ ヅ テ
デ ト ド ナ ニ ヌ ネ ノ ハ バ パ ヒビピフブ プヘベペホボポマミ ムメモャヤュユョヨラリルレロヮワヰヱ
ヲン ヴヵヶ

ㅆ을 누르고 한자키를 눌렀을때
А Б В Г Д Е Ё Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю
Я а б в г д е ё ж з и й к л м н о п р с т у ф х ц ч ш щ ъ ы ь э ю

KLDPWiki
http://wiki.kldp.org/wiki.php/RecentChanges?action=rss_rc

KLDP BBS(http://bbs.kldp.org)
http://bbs.kldp.org/rdf.php

KLDP.net(http://kldp.net)
http://kldp.net/export/rss_sfnews.php

KLDP blog(http://blog.kldp.org)
http://blog.kldp.org/blog/feed

geekforum(http://geekforum.kldp.org)
http://geekforum.kldp.org/backend/rdf.xml

출처 : ♡GlitterSpring♡( http://blog.naver.com/skjykd/80011536999 )

출처 : 지식KIN 직접 검색


김해에서 제일 맛있는 삼겹살 집
가야대에 있는거는 모르겠는데요..
저 중앙여고 있는데.. 하나있어요..
가격도 저렴하고.. vj특공대에도 나왔어요..
이름이.. 대가집이에요..

---

인제대 밑에 싸고 괜찮은 집 있어요-
롯데리아 밑으로 쪼끔 내려가시면
"돼지따먹기" 라고 있어요
대패삼겹살. 1인분에 2500원짜리 있는데요.

---

금강병원 맞은편 골목에 있는 '야들야들'
원투쓰리 나이트 옆에 있는 고기부페집인데요;;
한명당 5천원이구요- 삼겹살이랑 칼집난 양념고기-_-a맛있어요
낙지랑 아이스크림;;도 추천하구요
근데 단점이랄까.. 어쩌다 한번씩 고기가 맛이 없을때가 있어요ㅋㅋ;;

그리구 금소리 시네마 주위에 있는건데요
보쌈정식집이예요 이름은 '서울보쌈'이였나-_-a
한명당 6천원이구요
걍 밥한공기에 보쌈대략 10점-_-a에 기타 밑반찬 나오는데 푸짐해요
밑반찬..쳐다만 바두 배부릅디다ㅋㅋㅋ

---

훌라밍고 나이트 건물에 있는 레스토랑...
거기가 유일하게 경양식 먹을만한곳이더군요....
돈까쓰는 특별히 6천원밖에 안하고..
함박은 12천원
그리고 좀더 가다가 토담집 이라는 비빔밥집이 있는데 분위기도 좋고 맛도 꽤...
시청옆에[가면 갈치집이있는데 괘얀음.

---

티발돈까스
싸고
밥도 더달라면 줌
그런데 아줌마가 계속달라고하면
신경질내요
시내에잇음돠 ㅋㅋ

출처 : 아침은 먹고 담배는 안묵는다. ( http://www.cyworld.com/microstrong )

케이스 도구는 양날의 검이다. 활용도에 따라서 소프트웨어를 죽일 수 도 있다. 래쇼날 로즈(이하 로즈) 같은 케이스 도구는 능숙하게 다룰 수 있어야 되기까지 많은 학습 곡선을 필요로 한다. 능숙해진 다음에도 여전히 불편하다.

하지만 IDE와 통합된 케이스 도구는 코드의 자동 생성 등의 많은 편리한 도구를 제공한다. IDE와 통합된 케이스 도구는 UML이라는 것에 너무 얽매이지만 않고 자유롭게만 사용한다면 아주 훌륭한 프로젝트 도우미가 될 수 있다.

전통적으로 MS의 개발 플랫폼에서 사용하는 개발 도구는 MS가 100% 독점하다시피 해 왔다. STL이나 MFC를 개발하거나 사용하는 도구는 거의 비주얼 C++가 독점적이었고, COM 기반의 개발을 위해 사용되는 도구는 거의가 비주얼 베이직이었다(COM 개발을 위해 비주얼 C++를 사용하는 경우도 많이 봤지만 그 당시 이슈가 되던 RAD와는 거리가 먼 환경이었다). 물론 볼랜드의 델파이 등을 많이 사용하기도 했지만 MS의 막강한 개발 도구 비주얼 스튜디오를 넘기에는 벅차 보였다.

닷넷 환경이 발표되고, 닷넷이 산업계에서 서서히 자리를 잡아가자 닷넷 개발 도구의 필요성이 절실해 졌고, 당연히 MS의 비주얼 스튜디오 닷넷이 닷넷 개발 도구의 최강자 자리를 당연히(!) 차지했다. 사실, 비주얼 스튜디오 닷넷이 없으면 닷넷 개발이 불가능하다고 생각하는 사람들도 많다.

볼랜드가 C# 빌더 등의 닷넷 환경을 지원하는 도구를 내 놓았고, 기타 여러 벤더들이 제품을 출시했지만 MS의 아성을 무너트리기에는 역부족이다. 비주얼 스튜디오 닷넷은 닷넷 환경이 존재하는 한 닷넷 기반 IDE의 최강자로서 그 자리를 내놓지는 않을 듯 하다.

그렇다면 비주얼 스튜디오 닷넷에는 약점이 없을까? 아니다, 분명히 약점은 존재한다. 그것도 아주 커다란, 치명적인 약점이 있다. MS는 닷넷 환경을 분명한 객체지향 개발 환경(닷넷 환경에서의 CBD는 객체지향이 없이는 존재할 수 없다)이라고 했다. 객체지향 개발 환경이라면 객체지향 설계 도구가 없다면 그 활용 범위가 반감될 수밖에 없는데, 비주얼 스튜디오 닷넷 엔터프라이즈 아키텍트 버전에 포함된 비지오가 어느 정도 그런 기능을 해 주긴 하지만, 다른 객체지향 개발 도구인 로즈나 볼랜드 투게더(이하 투게더) 등의 편리함과 기능성에는 결코 미치지 못한다.

설계 도구와 개발 도구의 진정한 결합. 이상적인 환경이지만 사실 구현하기 어려운 개발 환경임에 틀림없다. 비주얼 스튜디오 닷넷은 분명 막강한 개발 환경이고, 비주얼 스튜디오 닷넷을 사용하면서 투게더 또는 로즈 같은 개발 도구를 같이 사용할 수는 없을까 하는 생각을 누구나 한번쯤은 해 보았을 것이다. 정말 그럴 수 있을까? 대답은 "물론 있다"이다. 로즈와 투게더는 비주얼 스튜디오 닷넷 XDE를 제공한다(물론 구입해야 한다).

래쇼날 로즈 2000 XDE
객체지향 모델링 도구 중 가장 유명하며, 많이 사용되는 도구인 로즈는 2002년 MS의 비주얼 스튜디오 닷넷에 애드인되어 사용될 수 있는 ‘래쇼날 로즈 2000 XDE for 비주얼 스튜디오 닷넷’을 발표했다(어찌된 일인지 아는 사람도 별로 없고 사용하는 사람은 더더욱 없다). 로즈 XDE를 가지고 있다면 그 자리에서 설치해 보기를 바란다. 물론 설치하는 시스템에 비주얼 스튜디오 닷넷이 설치되어 있어야 한다.

<화면 1> 로즈가 설치된 비주얼 스튜디오 닷넷 2003

로즈를 처음 설치하고 나면 처음엔 아무것도 없다. 도구상자에 뭔가 추가된 것도 아니고, 특별히 뭔가가 설치되었다는 느낌을 받을 수가 없는데(굳이 뭔가 설치되었다는 느낌이라면 아마 비주얼 스튜디오 닷넷의 실행 속도가 눈에 띄게 느려졌다는 느낌이 될 것이다) 솔루션 탐색기를 눈여겨 보면 평소에 볼 수 없던 아이콘이 하나 생겨있음을 알 수 있다. 그 아이콘을 주저 없이 클릭해 보자.

<화면 2> 추가된 동기화 아이콘

동기화 아이콘을 클릭하면 로즈와 비주얼 스튜디오 닷넷이 동기화되어 mdx 파일을 생성한다. 그리고 Model Explorer 창이 새로 생기고 프로젝트에 포함되어 있는 개체들을 탐색할 수 있게 해준다.

<화면 3> 로즈 XDE를 이용하여 Iterator 패턴을 디자인한 모습

로즈를 사용하여 모델링을 어느 정도 마쳤으면, 다시 동기화 버튼을 눌러 순 공학할 수 있다.

<화면 4> 로즈가 생성한 C# 코드

감동의 기능

단점이라면, C#으로 작성한 메쏘드의 수정이 아주 불편하다. 또한, RUP를 너무 강조하는 경향이 있어 닷넷의 빠른 개발과는 어울리지 않는 부분이 엿보이고, 일일이 동기화를 해 주어야 코드와 설계가 연동이 되는데, 에러를 자주 발생하여 동기화가 되지 않는 경우가 빈번히 발생한다.

볼랜드 투게더
비주얼 스튜디오 닷넷에서 다른 유명한 설계 도구인 투게더를 사용할 수 있다. 투게더 역시 로즈와 마찬가지로 비주얼 스튜디오 닷넷에 애드인되어 설치된다. ‘볼랜드 투게더 for 비주얼 스튜디오 닷넷 2.0’을 설치하면 비주얼 스튜디오 닷넷에 투게더 VS.NET Model View라는 창이 생성된다.

<화면 5> 투게더 for 비주얼 스튜디오 닷넷 Model View

또한 솔루션 탐색기에 ModelSupport라는 폴더가 생성되고 폴더 내부에는 .txvpak이라는 확장자를 가지는 모델 파일이 생성된다. 이 파일을 더블클릭하여 모델링 도구를 사용하여 설계할 수 있는 설계 창을 열 수 있다.

<화면 6> 투게더를 사용해서 Iterator 패턴을 디자인 한 모습

투게더는 로즈와 달리, 코드의 실시간 생성을 지원한다. <화면 6>에서 보이는 클래스 아이콘을 더블클릭하면 코드를 곧 바로 생성하게 된다. 코드를 수정하건, 설계를 수정하건 간에 설계 또는 코드의 수정 사항이 즉시 상호간에 적용되게 되어있다.

감동의 기능

<화면 7> 자동 생성한 시퀀스 다이어그램

단점이라면 생성된 코드가 그다지 깔끔하지 않아 재 정렬을 해줘야 한다는 점 등이다. 앞에서 설명한 두 가지 도구의 치명적인 단점이 하나 있다. 닷넷 환경에서는 실행할 때 참조되는 라이브러리를 복사하고 실행시 참조하므로 개발 중 라이브러리를 수정하고 다시 컴파일하여도 누군가 파일을 사용 중이기 때문에 덮어쓸 수 없다는 메시지를 절대로 보여주지 않는다. 하지만 앞의 두 도구는 모델링에 사용하고 있는 참조되는 라이브러리를 ‘물고’있기 때문에 참조하는 프로젝트를 종료하고 컴파일한 후 다시 비주얼 스튜디오 닷넷을 실행하여 계속 진행해야 한다.

그리고 전통적으로 닷넷 개발에서는 RUP 같은 개발 방법론이 사용되지 않아, 만약 UML을 그렇게 많이 사용하지 않는 개발자라거나 다른 개발 방법론을 준수하는(MSF 등의) 프로젝트라면 사용할 수 있는 다이어그램은 클래스 다이어그램뿐이고, 너무 많은 도구를 제공함으로서 개발에 혼란이 오며, 비주얼 스튜디오 닷넷 자체가 너무 느려져서 개발자의 '성질'에 나쁜 영향을 끼칠 수 있다는 것이다.

비주얼 스튜디오 닷넷 2005에 포함된 모델링 도구
MS도 닷넷 환경이 객체지향 환경이고, 객체를 모델링 할 수 있는 통합된 개발 도구가 필요하다는 것을 모를 리가 없다. 그래서 MS는 비주얼 스튜디오 닷넷의 차기 버전인 비주얼 스튜디오 닷넷 2005에 그런 모델링 도구를 추가했다(전체적으로는 투게더와 비슷한 모습이고, 필자가 현재 기사를 작성하고 있는 시점에서는 클래스 다이어그램 기능 이외의 기능은 들어있지 않다).

비주얼 스튜디오 닷넷 2005의 클래스 다이어그램 기능을 알아보자. 비주얼 스튜디오 닷넷 2005는 특별히 이전 버전과 비교해서 달라진 기능이 없다. 웹 프로젝트를 다른 프로젝트와 구분해서 생성하는 정도가 외관상으로 볼 때 달라진 기능이라 할 것이다. 비주얼 스튜디오 닷넷에서 클래스 다이어그램을 그리고 실시간으로 변경될 수 있는 기능을 사용하려 한다면 이전 버전에서 새 항목 추가 메뉴를 선택하는 것과 같이 한다. 새 항목 추가 다이얼로그 박스를 유심히 살펴보면 클래스 다이어그램이라는 항목 아이콘이 보이고 그 항목을 사용하여 클래스 다이어그램을 작성할 수 있다.

<화면 8> 비주얼 스튜디오 닷넷 2005의 새 항목 추가 다이얼로그 박스

<화면 9> 비주얼 스튜디오 닷넷 2005를 사용해서 Iterator 패턴을 디자인 한 모습

장점
단점이라면, 그 외에 아무것도 없다는 것이다. 또한, 현재 베타 버전에서는 다른 라이브러리에 포함된 개체들을 클래스 다이어그램에 포함하는 인터페이스가 상당히 불편하다. 이는 개선되어야 할 점이다. 사실 투게더나 로즈같은 훌륭한 도구들을 사용하던 입장에서 비주얼 스튜디오 닷넷 2005의 설계 도구를 테스트 하는 입장에서는 전혀 새로울 것도 없고 감동적일 것도 없다.

또한 MS가 자사의 객체지향 개발 방법론을 연구하고 있다는 소문이 풍문에 들려오는 것을 보면, 정식 제품에는 다른 도구가 추가될 지도 모르고, 로즈나 투게더 같은 도구 정도의 많은 기능은 아니더라도 다른 많은 도구들이 추가될 것으로 보인다.

독이 될 수도 갈라드리엘의 별이 될수도
UML은 좋은 도구다. 하지만 대부분의 개발 팀에는 도움이 되기보다는 방해가 되기 일쑤다. UML에는 너무나 많은 것이 있고, 다 활용하기는 벅차고, 그렇다고 사용하지 않기에는 또 뭔가 빠진 듯한 느낌이 드는 것이 그것이다. 늘 절제하는 마음으로 UML을 사용한다면, UML은 아주 좋은 도구가 된다.

필자는 항상 이런 얘기를 한다. "로즈가 설치되어 있는 책상 위에는 항상 연필과 지우개, 그리고 종이가 있어야 한다" 특히 개발자의 입장에서는 UML이라는 도구는 독이 될 때는 한 모금에 사람을 죽일 수도 있는 치명적이 독이 될 수도, 또는 길을 안내해주는 갈라드리엘의 별이 될 수도 있다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

어쩌라고?

88년은 필자가 한창 8비트 컴퓨터였던 MSX2에 빠져있던 시기였다. 그 당시 교육용 컴퓨터로 16비트 컴퓨터가 채택되어 8비트 컴퓨터의 열렬한 지지자였던 필자의 가슴에 상처(?)가 되었던 기억이 난다.

10여년이 지난 지금 컴퓨터는 발전에 발전을 거듭해 64비트 CPU와 64비트 운영체제가 등장했다. 본 연재에서는 3회에 걸쳐 이제 곧 대중화될 64비트 윈도우에서 프로그래밍을 하기 위한 가이드를 제공한다. 부디 필자의 8비트 시절과 같은 실수를 범하지 말고 좀 더 넓어진 64비트 메트릭스에서 네오를 찾을 수 있기를 바란다.

연재 가이드

운영체제 : 윈도우 XP 64비트 에디션, 윈도우 2003 64비트 에디션
개발도구 : 에디터, 32/64비트 C/C++ 컴파일러
기초지식 : C/C++ 프로그래밍, 윈도우 구조 이해
응용분야 : 64비트 윈도우에서 동작하는 모든 프로그램

얼마 전 미국 시애틀 근교 레드몬드에 위치한 MS 본사에서는 인텔과 AMD 및 MS 개발자들이 주제 발표자로 나와 다양한 64비트 컴퓨팅 관련 주제를 다룬 64비트 개발자 세미나를 개최했다. 세미나에 참석한 MS 개발자들은 “64비트 컴퓨터에서 프로그래밍을 구현하는 것이 그렇게 어려운 일이 아니다”라고 설명했다.

16비트에서 32비트로 바뀔 때에 비해 32비트에서 64비트로 가기 위해 필요한 일의 양은 상당히 적을 것이라고 예상하고 있었다. 하지만 쉽다고 해서 아주 할일이 없다는 이야기는 아니다. 현재 32비트 윈도우에서 사용되는 가장 대중적인 CPU는 인텔 호환의 32비트 CPU(AMD도 인텔 호환이었다)이다. 32비트 프로그램을 제작할 때 기존 개발자는 하나의 소스를 작성하고 단 하나의 바이너리만을 생성하면 되었다.

그러나 64비트 윈도우에서 대중화된 64비트 CPU는 크게 두 가지 종류로 구분된다. IA64과 x64이다. IA64는 인텔에서 만든 아이태니엄을 기반으로 하며 개인 사용자보다는 기업 환경과 고성능 컴퓨팅을 목표로 하고 있다. x64는 AMD64를 기반으로 하고 있으며 32비트의 호환성과 64비트의 높은 성능을 목표로 하고 있다.

현재는 인텔에서 EM64T라는 AMD64 CPU의 클론을 제작할 만큼 x64가 대중적인 선호 측면에서 조금 더 앞서 있는 상황이다. 인텔의 시장 예측의 실패라고 할 수도 있는데, MS는 인텔이 주도한 IA64 시스템 대신 미래에는 <그림 1>과 같이 x64 시스템이 주류가 될 것으로 예상하고 있다.

<그림 1> 64비트 시스템의 현재와 미래 동향

IA64 또는 x64가 인기를 얼마나 더 많이 끄는가는 사실 개발자에게 그렇게 큰 관심사는 아니다. 단지 이렇게 두 부류의 64비트 시스템으로 나누어진 상황은 사용자 입장에서야 CPU의 종류가 다양해진 만큼 선택의 폭이 넓어져서 좋을 수 있지만 개발자 입장에서는 조금은 곤혹스러운 일이다.

왜냐하면 생성해내야 할 바이너리의 수가 두 가지 더 증가하기 때문이다. 기존의 32비트 시절에는 하나의 소스로 하나의 바이너리만 생성하면 되지만 앞으로 다가올 가까운 미래에는 하나의 소스로 32비트 바이너리, IA64 바이너리, x64 바이너리를 모두 생성해야 하기 때문에 개발자들의 부담은 더 커지게 된다.

64비트 CPU 정보 얻어오기
64비트 윈도우에서 내 시스템의 CPU가 인텔의 IA64인지 x64인지를 알고 싶다면 어떻게 해야 할까? GetNativeSystemInfo() 함수를 이용하면 CPU의 종류를 알아 낼 수 있다. 한 가지 주의할 점은 64비트 윈도우에서수행되는 32비트 프로세스는 GetNativeSystemInfo() 함수를 이용해야만 정확한 CPU 종류를 얻어 올수 있고, 64비트 프로세스라면 GetSystemInfo() 함수를 사용해도 무방하다. 64비트 프로세스에서 GetNativeSystemInfo() 함수를 사용하면 내부적으로 GetSystemInfo() 함수를 호출해 결과를 리턴한다.

<표 1> 64비트 윈도우에서 CPU 종류를 얻어올 수 있는 함수

이 밖에도 32비트 윈도우에서는 CPU를 32개까지 지원했지만 64비트 윈도우에서는 최대 64개까지 지원한다. 윈도우에서 내부적으로 CPU 정보를 유지할 때 각 비트별로 한 CPU씩 할당하기 때문에 64비트 윈도우에서는 더 많은 64개의 CPU를 지원할 수 있는 것이다.

주의할 점은 64비트 윈도우에서 실행되는 32비트 프로세스는 뒤에 설명할 WOW64가 CPU에 대한 정보를 32비트로 제한하기 때문에 32개의 CPU만 사용할 수 있다. 예를 들어 64비트 윈도우에 64개의 CPU가 있어도 32비트 프로세스에서 GetProcessAffinityMask() 함수나 SetThreadAffinityMask() 같은 함수를 이용하면 32개의 CPU에 대해서만 값을 얻어오거나 설정할 수 있다.

윈도우 안의 또 하나의 윈도우 WOW64
우리는 아직 32비트의 시대에 살고 있으며 가장 많이 사용하는 워드프로세서, 게임, 인터넷 메신저 모두 32비트 프로그램이다. 한때 스티븐 잡스가 만든 혁신적인 워크스테이션과 운영체제였던 넥스트와 넥스트스텝이 컴퓨터 업계에 큰 충격으로 다가온 적이 있었다.

그러나 그것들이 실패할 수밖에 없었던 가장 큰 이유 중 하나가 실제 소비가가 쓸 수 있는 응용 소프트웨어가 극히 적었다는 점이다. 이와 같이 무언가 새로운 것을 만들 때 이상적인 개념을 실체화하는 것도 중요하지만 이전 것에 대한 호환성을 제공하지 못한다면 결국 실패할 수밖에 없다.

호환성이 기술과 시장에 큰 영향을 끼친다는 것은 아이태니엄과 아이태니엄2로 64비트 CPU의 독자 노선을 걷던 독불장군 인텔이 결국 호환성을 중시한 AMD64 진영의 인기 앞에 승복하고 오히려 EM64T라는 클론 CPU를 만들어야 했다는 것에서도 알 수 있다. 즉, 사용자에게 사용되지 않고 팔리지 않는 기술은 사장되기 쉽다. MS는 이런 사실을 예전부터 너무나 잘 알고 있었다. MS-DOS에서 윈도우로 넘어갈 때도 새로운 기술보다는 이전 버전의 하위 호환성을 선택했고 결국 완전한 개인 사용자용 32비트 운영체제는 윈도우 2000에 와서야 빛을 볼 수 있었다.

이렇듯 호환성을 중시하는 MS는 새로운 64비트 윈도우에서 기존의 32비트 프로그램이 동작하도록 하기 위해 WOW(Windows On Windows)64를 탑재하고 있다. 64비트 윈도우는 대다수의 응용 프로그램이 완전한 64비트로 포팅되기 전까지 WOW를 통해 32비트 응용 프로그램을 사용할 수 있도록 하고 있다.

그러나 모든 경우에 호환성이 우선시되는 것은 아니다. 64비트 윈도우에서는 16비트 프로세스는 더 이상 동작할 수 없으며 커널모드 드라이버는 WOW64와 같은 에뮬레이션 레이어가 존재하지 않아서 반드시 64비트로 포팅해야 한다. 결론적으로 64비트 윈도우에서는 WOW64를 통해 수행되는 32비트 프로세스와 64비트 윈도우 상에서 곧바로 수행되는 64비트 프로세스가 모두 동작할 수 있다.

WOW64의 구성과 동작 방식
WOW64는 커널모드가 아닌 사용자모드에서 동작하며, 커널모드와 기존의 x86 버전의 Ntdll.dll 사이에 위치해서 32비트 응용 프로그램의 API 호출을 중간에서 가로챈 후 64비트 API 호출로 변환한다. WOW64를 구성하는 DLL과 각각의 기능은 <표 2>와 같다.

<표 2> WOW64를 구성하는 DLL

좀 더 자세히 설명하면 32비트 프로세스가 시작할 때 wow64.dll은 32비트 버전의 Ntdll.dll을 로드한다. 이때 Ntdll.dll은 프로세스 실행에 필요한 32비트 DLL들을 로드한다.

알아 두어야 할 점은 WOW64에서 사용하는 대부분의 32비트 DLL들은 별다른 수정 없이 설치되어 있지만 64비트 프로세스와 메모리를 공유해야 하는 몇 개의 32비트 DLL들은 WOW64에서도 정상적으로 동작할 수 있도록 조금 수정되었다는 사실이다. 그리고 64비트 Ntdll.dll은 32비트 프로세스에서 로드할 수 있는 유일한 DLL인데, wow64.dll은 64비트 ntdll.dll과 32비트 ntdll.dll 사이에서 썽킹을 수행해서 32비트 프로세스의 실행환경을 만들어 준다.

썽킹을 커널모드가 아닌 사용자모드에서 수행하는 이유는 썽킹 과정의 버그로 인해 BSOD(Blue Screen Of Death)가 발생하는 것을 방지하기 위해서이다. WOW64를 구성하는 모듈간의 관계는 <그림 2>를 살펴보면 쉽게 이해할 수 있다.

<그림 2> WOW64의 아키텍처

그렇다면 WOW64 환경에서 수행되는 32비트 프로세스의 성능은 어떨까? 여러 가지 요인에 의해 수행 성능이 결정될 수 있는데 첫 번째로 어떤 CPU에 의해 수행되느냐가 중요하다. 아이태니엄과 같은 IA64 계열의 CPU는 wow64cpu.dll이 32비트 명령어를 에뮬레이션하기 때문에 아무래도 성능이 낮을 수밖에 없다.

그러나 AMD64나 EM64T같은 x64 계열에서 수행되는 32비트 프로세스는 32비트 명령어를 CPU에서 직접 수행하기 때문에 32비트 윈도우에서 수행하는 것과 거의 동일한 성능으로 수행할 수 있다. WOW64에서 메모리를 다루는 것도 이 두 계열의 CPU에 따라 조금 다르다. IA64 계열은 기본적으로 8K 페이지를 사용하게 때문에 AWE(Address Windowing Extention)를 사용할 수 없고 GetWriteWatch(), ResetWriteWatch(), ReadFileScatter(), WriteFileGather() 함수를 사용할 수 없다.

반면에 x64 계열은 기존의 32비트 시스템과 동일한 4K 페이지를 사용하기 때문에 AWE를 사용할 수 있을 뿐만 아니라 사용자 주소 공간도 기존의 2GB가 아닌 4GB의 가상 주소 공간을 사용할 수 있다. 일반적인 가이드는 WOW64를 이용해 기존의 수많은 32비트 응용 프로그램을 수행할 수 있지만 WOW64에서 수행하려는 프로그램이 높은 성능을 요구하는 서버 응용 프로그램이라면 빠른 시일 내에 완전한 64비트 응용 프로그램으로 제작하길 바란다. MS는 WOW64 상에서 서버 응용 프로그램을 구동하는 것을 권장하지 않는다고 한다.

64비트와 32비트 프로세스/메시지 구분하기
현재 MS에서는 하나의 소스로 32비트 바이너리와 64비트 바이너리를 개발할 것을 권장하고 있다. 이 가이드에 맞추어 프로그램을 개발하다 보면 자신이 32비트 프로세스인지 또는 64비트 프로세스인지 판별해야 할 경우가 생기는데 IsWow64Process() 함수를 사용하면 쉽게 판별할 수 있다. 이 함수는 프로세스 핸들을 인자로 받아들이므로 다른 프로세스의 32비트 프로세스 여부를 판단하는 데 유용하게 사용될 수 있다.

그렇다면 64비트 프로세스에서 현재 받은 윈도우 메시지가 32비트에서 발생한 것인지 64비트에서 발생한 것인지를 구분해야 할 때는 어떻게 해야 할까? 64비트 윈도우에서는 IsWow64Message() 함수를 이용해 현재 쓰레드에서 마지막으로 받은 윈도우 메시지가 32비트에서 발생한 것인지 판별할 수 있다. 예를 들어 윈도우 메시지 안에 포인터 타입을 포함하는 데이터가 있고 그 포인터가 32비트 포인터일 경우 주의해야 하는데 이런 경우 IsWow64Message() 함수를 이용해 판별할 수 있다.

<표3> 32비트/64비트 프로세스와 메시지를 구분하는데 사용되는 함수

레지스트리 접근하기
앞서 보았듯이 64비트 윈도우에는 32비트 프로세스와 64비트 프로세스가 공존한다. 64비트 윈도우에서는 이 두 종류의 프로세스가 접근하는 두 가지 관점의 레지스트리가 존재하게 된다. 하나는 WOW64를 통해 수행되는 32비트 프로세스가 접근하는 레지스트리이고 다른 하나는 순수한 64비트 프로세스가 접근하는 레지스트리이다.

32비트와 64비트 프로세스 간에 서로 다른 관점을 유지하는 이유는 크게 두 가지가 있다. 첫 번째는 32비트 프로세스와 64비트 프로세스가 사용하는 레지스트리 상태를 분리하고 각각 저장하는 설정 값들을 중복되지 않게 구분하기 위해서이다. 두 번째는 서로 같은 위치의 레지스트리를 사용할 경우 상호간에 관리하는 값들을 훼손할 수 있기 때문에 안전한 수행환경을 제공하기 위해서 32비트 응용 프로그램과 64비트 응용 프로그램 레지스트리를 분리시켰다.

<화면 1>을 보면 32비트 프로세스가 사용하는 Wow6432Node 밑의 Microsoft 키와 64비트 프로세스가 사용하는 Microsoft 키가 나누어져 있음을 알 수 있다.

<화면 1> 64비트 윈도우에 존재하는 두 가지 레지스트리 뷰

너는 너대로 나는 나대로 - 레지스트리 접근경로 변경
WOW64는 32비트 프로세스가 레지스트리를 생성하거나 오픈하려고 할 때 몇 개의 키들에 대해서는 레지스트리 키 경로에 Wow6432Node를 덧붙인다. 이렇게 해서 64비트 프로세스가 접근하는 레지스트리 경로와 32비트 프로세스가 접근하는 레지스트리 경로가 변경된다. 모든 레지스트리 키가 이렇게 접근경로 변경(Redirection)이 되는 것은 아닌데 주로 다음과 같은 키들이 분리되며 이 키들을 제외한 다른 키들은 일반적으로 32비트와 64비트 프로세스가 같은 레지스트리 위치에 접근한다.

레지스트리 키 접근경로 변경은 로컬 시스템과 원격 시스템에 따라 다르게 일어나는데 윈도우 서버 2003 SP1 이전에는 로컬시스템 레지스트리에 접근할 때만 키 경로의 변경이 발생하고 RegConnectRegistry 함수를 사용해 원격 시스템에서 레지스트리에 접근할 때는 키 경로의 변경 없이 64비트 레지스트리에만 접근할 수 있다. 그러나 윈도우 서버 2003 SP1를 포함한 이후 버전의 64비트 윈도우에서는 원격 레지스트리에 접근하는 시스템이 32비트 윈도우라면 32비트 레지스트리를 접근할 수 있고 64비트 시스템이라면 64비트 레지스트리를 접근할 수 있다.

너와 나는 하나 - 레지스트리 복사·공유
다음과 같은 시나리오를 생각해보자. 먼저 깨끗한 상태의 64비트 윈도우를 설치하면 .doc 파일에 대한 기본 응용 프로그램으로 Wordpad.exe가 64비트 레지스트리에 등록되어 있다. 이 정보는 32비트 레지스트리에도 복사가 된다. 만약 이 운영체제에 32비트 버전의 MS 오피스를 설치한다면 .doc 파일에 대한 기본 응용 프로그램으로 32비트 레지스트리에 winword.exe가 등록된다. 그리고 이 정보는 64비트 레지스트리에도 복사가 된다. 이 경우 32비트와 64비트에 상관없이 .doc 파일에 대한 기본 응용 프로그램은 32비트 버전의 winword.exe가 된다.

여기에 64비트 버전의 마이크로소프트 오피스를 설치한다면 어떻게 될까? 64비트 레지스트리에 64비트 버전의 winword.exe 경로가 등록되고 이 값은 32비트 레지스트리에도 복사된다. 최종적으로는 .doc 파일에 대한 기본 응용 프로그램으로 64비트 버전의 winword.exe가 등록된 것이고 32비트나 64비트 상관없이 같은 경로의 winword.exe를 사용하게 된다. 결론적으로 32비트와 64비트 레지스트리 중 어떤 키들은 변경이 발생하면 서로 복사함으로서 32비트와 64비트의 설정을 동기화하고 64비트 윈도우에서 응용 프로그램이 유연하게 동작할 수 있도록 해준다.

COM의 경우를 생각해 보면 별도의 프로세스로 수행되는 Out-of-Process COM 등록의 경우 앞서 설명한 것처럼 32비트와 64비트 레지스트리 간에 복사가 일어나서 최종적으로 기록한 값이 동기화되게 된다. 반면에 같은 프로세스 주소 공간 안에서 동작하는 In-Process COM의 경우는 복사가 이루어지지 않고 32비트는 COM은 32비트 레지스트리에 64비트 COM은 64비트 레지스트리에 등록이 된다.

이런 현상은 어쩌면 너무나 당연할 결과인데 32비트와 64비트 간에 IPC나 RPC는 허용되는 반면 32비트 모듈이 64비트 프로세스 주소공간 안에서 동작할 수 없고 64비트 모듈이 32비트 프로세스 주소공간 안에서 동작할 수 없기 때문이다. 다음 키들은 32비트와 64비트 레지스트리에 별도로 존재하지만 변경이 발생할 경우 32비트와 64비트 키 간에 복사를 수행해 내용을 일치 시킨다.

다음 키들은 32비트와 64비트 레지스트리가 별도로 존재하지 않고 32비트와 64비트 프로세스가 공유해서 사용한다.

다음 키들은 32비트 레지스트리 키에 변경이 발생하면 64비트 레지스트리로 복사를 하고 32비트 레지스트리 키 값은 삭제된다. 이 키들이 특별하게 동작하는 이유는 주로 사용자가 로그온될 때 사용되는 키여서 32비트와 64비트 레지스트리 양쪽에 값이 기록된다면 하나의 프로그램을 두 번씩 수행하게 될 수도 있기 때문이다. 그래서 64비트 레지스트리에만 값을 유지하는 것이다.

32비트와 64비트 레지스트리 넘나들기
64비트 윈도우에서는 특별한 작업을 하지 않는다면 32비트 프로세스는 32비트 레지스트리에 접근하게 되고 64비트 프로세스는 64비트 레지스트리에만 접근할 수 있다. 만일 32비트 프로세스가 64비트 프로세스를 접근하는 것을 원하거나 64비트 프로세스가 32비트 프로세스를 접근하는 것을 원한다면 RegOpenKeyEx / RegCreateKeyEx / RegDeleteKeyEx와 같은 레지스트리 관련 API를 사용할 때 특별한 플래그를 부여하면 양쪽 모두의 레지스트리를 접근할 수 있다. 그 플래그는 <표 4>와 같다.

<표 4> 32비트/64비트 레지스트리를 접근하는 함수에서 사용되는 인자

파일시스템 접근하기
조금 먼저 생각해본 독자라면 앞서 레지스트리를 통해 보았듯이 64비트 윈도우에서 WOW64를 통해 수행되는 32비트 프로세스와 일반적인 64비트 프로세스는 서로 다른 파일시스템 뷰를 가지고 있다는 것을 예상할 수 있다. 64비트 윈도우에서는 두 종류의 프로세스가 서로 다른 파일시스템 뷰를 가지게 되는 것은 서로 참조하는 파일을 분리해서 64비트 프로세스는 64비트 DLL을 사용하고 32비트 프로세스는 32비트 DLL을 사용하게 하기 위해서이다. 그래서 64비트 윈도우를 설치하게 되면 <화면 2>와 같이 시스템 디렉토리가 각각 존재하는 것을 볼 수 있다.

<화면 2> 64비트 윈도우의 시스템 디렉토리

더 풀어서 설명하면 64비트 프로세스의 경우 파일 I/O 함수를 이용해 %systemroot%\System32 디렉토리를 접근하게 될 경우 C:\WINDOWS\system32 디렉토리에 접근하게 되겠지만, 32비트 프로세스가 파일 I/O 함수를 통해 %systemroot%\System32 디렉토리를 접근하게 될 경우 WOW64는 자동으로 C:\WINDOWS\SysWOW64 디렉토리로 접근경로를 변경한다. 그러나 다음 디렉토리들과 그 하위 디렉토리들은 접근경로 변경에서 제외된다.

파일시스템의 접근경로 변경은 GetSystemDirectiry()를 사용해 보면 분명하게 나타나는데, 32비트 프로세스에서 이 함수를 사용하면 시스템 디렉토리 밑의 SysWOW64를 얻어오게 되고 64비트 프로세스는 시스템 디렉토리 밑의 System32를 얻어오게 된다. 그렇다면 64비트 프로세스에서 32비트 프로세스가 사용하는 시스템 디렉토리를 얻어오려면 어떻게 해야 할까? 64비트 윈도우에서는 GetSystemWow64Directory() 함수를 이용해 이 답을 구할 수 있다.

또한 64비트 윈도우에서는 프로그램 설치 디렉토리인 %Program Files%에 대해서도 조금은 특별하게 관리하는데 시스템 디렉토리와는 달리 WOW64가 직접 접근경로 변경을 수행하지는 않는다. 대신 32비트 프로세스가 %Program Files% 문자열이 포함된 REG_EXPAND_SZ 형식의 데이터를 레지스트리에 기록하려고 할 때 WOW64는 이 데이터를 가로채서 %ProgramFiles(X86)%으로 바꾸어 레지스트리에 기록하며 마찬가지로 레지스트리를 읽을 때도 데이터를 가로채서 %ProgramFiles(X86)%으로 변경한다.

그러므로 프로그램 설치 디렉토리를 얻어와야 한다면 CSIDL_PROGRAM_FILES를 인자로 사용해서 SHGetSpecialFolderPath() 함수로 %Program Files%의 경로를 얻어오기를 권장한다.

이 함수를 이용하면 32비트 프로세스에서는 C:\Program Files(X86)를 얻어올 것이고 64비트 프로세스에서는 C:\Program Files를 얻어올 것이다. 이와 같이 64비트 윈도우에서 프로그래밍을 할 경우 접근경로 변경이 되는 디렉토리들은 소스 상에 하드코딩하지 말고, 반드시 지정한 종류의 디렉토리를 얻어오는 함수들을 이용해서 프로그램을 작성해야 한다.

이 밖에도 64비트 윈도우에서는 윈도우세션메니저(smss.exe)가 관리하는 KnwonDLL 리스트를 32비트와 64비트 두종류로 관리하고, 32비트 프로세스가 KnownDLLs에 접근할 경우 WOW64는 KnownsDLLs32로 접근경로 변경을 수행해 준다. KnwonDLLs 리스트는 레지스트리의 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager 밑에서 확인할 수 있다. <표 5>는 64비트 윈도우에서 파일시스템에 접근할 때 유용하게 사용되는 함수 리스트이다.

<표5> 64비트 윈도우 파일시스템에 관련된 유용한 함수

실제 64비트 윈도우에서 동작하는 32비트 응용 프로그램을 개발하다 보면 앞서 설명한 64비트 윈도우에서 제공하는 파일시스템 접근경로 변경 방식이 문제가 될 경우가 있다. 예를 들어 필자가 개발하는 안티바이러스 프로그램의 경우 악성코드가 시스템 디렉토리에 감염되어 치료를 시도하는데 원하는 경로가 아닌 접근경로 변경이 된 SysWOW64 밑을 접근하게 된다면 원하는 파일에 접근을 할 수 없기 때문에 문제가 된다.

즉, 전체적인 파일시스템을 접근경로 변경이 되지 않는 일반적인 상태로 접근하고 싶을 때는 Wow64EnableWow64FsRedirection() 함수를 사용해서 파일시스템 접근경로 변경을 끄면 된다. <리스트 1>을 참조하면, 32비트 프로세스에서 파일시스템 접근경로 변경을 끄고 notepad.exe를 접근하면 32비트 시스템 디렉토리에 있는 notepad.exe가 아닌 64비트 시스템 디렉토리에 있는 notepad.exe를 접근하게 된다.

<리스트 1> 파일시스템 접근경로 변경

// WOW64 파일시스템 접근경로 변경을 끈다. BOOL bRet = Wow64EnableWow64FsRedirection(FALSE); if (bRet == TRUE) { // 64비트 notepad.exe 파일핸들을 오픈한다. CreateFile("c:\\windows\\system32\\notepad.exe", GENERIC_EXECUTE, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); // WOW64 파일시스템 접근경로 변경을 켠다. Wow64EnableWow64FsRedirection(TRUE); }

그러나 접근경로 변경을 끈 상태에서 32비트 응용 프로그램을 동작시키기 위해선 조심해야 할 것이 있는데 참조하게 되는 DLL이 32비트가 아닌 64비트 DLL을 사용하게 될 수도 있다는 것이다. 이 경우 64비트 DLL이 32비트 프로세스에 로드가 되지도 않을 뿐더러 응용 프로그램의 구동에 심각한 문제를 발생시킬 수도 있다.

예를 들어 psapi.dll이나 advapi32.dll 같은 시스템 DLL의 경우 같은 이름으로 32비트와 64비트가 각각의 시스템 디렉토리에 별도로 존재하기 때문에 잘못 참조하게 될 수도 있다. 그러므로 필요한 부분에서만 접근경로 변경을 끄고 다시 켜주는 방법을 사용해야 한다.

WOW64로의 여행 CWowUtil
개발자라면 누구나 간단하고 쉽게 프로그래밍하기를 원한다. 어떤 사람들은 게으른 사람들이 개발을 가장 잘한다고도 하는데, 힘들고 귀찮을 일을 효율적으로 만들고 자동화하려는 노력을 가장 많이 하기 때문이라고 한다. 마찬가지로 필자도 그런 성향이 다분하다고 할 수 있는데 그래서 64비트 윈도우에서 32비트 호환 프로그램을 작성할 때 사용될만한 몇 가지 함수를 모아 다음과 같은 CWowUItil 클래스를 만들어 보았다.

이 클래스는 내부적으로 사용하는 시스템 DLL을 동적으로 로딩해서 시스템 함수들을 사용하기 때문에 64비트 윈도우가 아니어도 예외(Exception)가 발생하지는 않는다. 사족이지만 이런 클래스가 필요한 이유는 윈도우95부터 윈도우XP 및 윈도우2003까지 광범위한 운영체제에서 동작하는 프로그램을 하나의 소스로 작성할 때 편리하기 때문이다.

실제로 많은 패키지 소프트웨어가 시스템 함수들을 사용할 경우에 이와 유사한 클래스들을 작성해 사용한다. <리스트 2>는 클래스의 헤더이며 전체 소스는 이달의 디스켓을 참조하기 바란다.

<리스트 2> 클래스의 헤더

#include // Type Definition of WOW64 Util API Function Pointer typedef VOID (WINAPI *LPFN_GetNativeSystemInfo) ( LPSYSTEM_INFO lpSystemInfo ); typedef BOOL (WINAPI *LPFN_IsWow64Process) ( HANDLE hProcess, PBOOL Wow64Process ); typedef BOOLEAN (WINAPI *LPFN_Wow64EnableWow64FsRedirection) ( BOOLEAN Wow64FsEnableRedirection ); typedef UINT (WINAPI *LPFN_GetSystemWow64Directory) ( LPTSTR lpBuffer, UINT uSize ); typedef BOOL (WINAPI *LPFN_IsWow64Message) ( void ); class CWow64Util { public: CWow64Util(); virtual ~CWow64Util(); // Is.. BOOL IsWow64Process(); BOOL IsWow64Process( HANDLE hProcess ); BOOL IsWow64Message(); BOOL IsProcessorIA64(); BOOL IsProcessorAMD64(); // File System Redirection On/Off BOOL TurnOnWow64FSRedirection(); BOOL TurnOffWow64FSRedirection(); // Get Information UINT GetWow64SystemDirectory( LPTSTR lpBuffer, UINT uSize ); VOID GetWow64SystemInfo( LPSYSTEM_INFO lpSystemInfo ); private: HMODULE m_hKernel32; HMODULE m_hUser32; LPFN_GetNativeSystemInfo m_pfnGetNativeSystemInfo; LPFN_IsWow64Process m_pfnIsWow64Process; LPFN_Wow64EnableWow64FsRedirection m_pfnWow64EnableWow64FsRedirection; LPFN_GetSystemWow64Directory m_pfnGetSystemWow64Directory; LPFN_IsWow64Message m_pfnIsWow64Message; };

상부상조해야 하는 32비트와 64비트
앞서 언급했듯이 64비트 윈도우에는 두 가지 종류의 프로세스가 동작할 수 있다. 하나는 32비트 프로세스이고 다른 하나는 64비트 프로세스이다. 64비트 윈도우에서는 WOW64를 통해 32비트 프로세스가 별다른 어려움 없이 동작할 수 있도록 지원한다. 하지만 32비트 프로세스가 64비트 DLL을 사용하거나 64비트 프로세스가 32비트 DLL을 사용하는 것은 몇 가지 이유 때문에 허용되지는 않는다. 자세히 언급하겠지만 64비트 윈도우의 원칙은 <그림 3>과 같이 하나의 프로세스 주소 공간 안에 64비트와 32비트 코드가 공존하는 것을 허용하지 않는다.

<그림 3> 64비트 윈도우의 원칙

그렇다면 왜 하나의 프로세스 주소 공간 안에 32비트와 64비트 코드가 공존하는 것을 허용하지 않았을까? 크게 세가지 이유가 있는데 첫째는 32비트 DLL은 2G를 넘는 주소공간을 처리할 수 없기 때문이다. 예를 들어 64비트 프로세스에 32비트 DLL이 로드되고 이 DLL로 64비트 포인터가 넘어 간다면 32비트 DLL은 심각한 예외(Exception)가 발생할 것이다.

둘째는 32비트 DLL은 4K 페이지를 사용하고 x86 스타일의 예외처리(Exception Handling)를 수행하지만 IA64 계열은 8K 페이지를 사용하고 예외처리 방식도 다르기 때문이다. 셋째로 Kernel32.dll, User32.dll, Gdi32.dll 같은 시스템 DLL들은 하나의 프로세스에 32비트 또는 64비트 중의 단 한 종류만 로드되어야 하기 때문이다.

예를 들어 프로세스가 생성되면서 PEB(Process Environment Block)에 User32.dll이 제공하는 함수 포인터 배열이 저장되고 커널모드 윈도우 서브시스템인 Win32k.sys가 사용자모드 APC를 통해 함수 포인터 배열에 저장되어 있는 User32.dll 함수들을 사용하는 상황을 생각해 보자. 만일 64비트 버전의 User32.dll과 32비트 버전의 Use32.dll을 하나의 프로세스 안에서 동시에 로드해 놓고 있다면 어떤 함수를 호출해야 할지 결정할 수 없을 것이다.

대신 IPC(Inter Process Communication)나 RPC는 모두 32비트/64비트에 상관없이 동작하며 뮤텍스, 세마포, 파일핸들, 이벤트 등의 이름을 가진 커널 객체 및 윈도우 핸들(HWND)은 두 종류의 프로세스에서 공유해 사용할 수 있다.

COM의 경우에는 DLL과 같은 형태의 In-Process COM은 32비트와 64비트 프로세스끼리 공유할 수 없지만 실행파일 형태인 Out-Of-Process COM의 경우에는 32비트와 64비트 프로세스가 모두 사용가능하다. 액티브X의 경우는 DLL형식은 같은 종류의 인터넷 익스플로러에서만 사용가능하지만 실행파일 형식은 다른 종류 간에도 사용가능하다.

참고로 64비트 윈도우에는 32비트 인터넷 익스플로러와 64비트 인터넷 익스플로러가 모두 설치되어 있고 기본 웹 브라우저는 64비트 인터넷 익스플로러이다. 공유 메모리도 32비트와 64비트 프로세스 간에 공유 가능한데, 주의할 점은 공유 메모리 안의 데이터 중에 포인터가 있다면 32비트 프로세스와 64비트 프로세스 포인터 사이즈가 다르기 때문에 주의해야 한다.

이 밖에도 CreateProcess(), ShellExecute()와 같은 함수는 32비트와 64비트 프로세스에서 모두 사용하고 실행할 수 있다. 또한 일반적으로 디버거를 구현하는 데 사용되는 함수인 CreateRemoteThread() 함수는 64비트 프로세스에서 32비트 프로세스에 사용할 수 있다.

언젠간 가야하는 길, 64비트 컴퓨팅
현재까지는 고성능 컴퓨팅이나 엔터프라이즈 환경을 제외한다면 64비트 컴퓨팅이 개인 사용자에게 줄 수 있는 것이 무엇인지 와 닿지 않는 게 현실이다. 필자의 생각에는 모든 지형데이터를 메모리에 맵핑시켜놓고 게임을 즐길 수 있는 WOW(World Of Warcraft. 공교롭게도 Windows On Windows와 약자가 같다)의 64비트 버전이 나온다면 중간 중간 지형을 읽느라 뚝뚝 끊기는 화면 없이 와이번을 타고 멋진 경치를 즐길 수 있지 않을까 라고 상상하는 것 외에는 아직은 별다른 사용처를 찾지 못했다.

필자와 비슷한 생각을 아직은 많은 사람들이 하고 있고 수많은 사용자를 갖고 있는 대부분의 프로그램들조차 64비트 버전 발표 계획을 갖고 있지 않다. 아직은 32비트 응용 프로그램으로도 충분히 만족을 느끼기 때문이다.

그러나 그렇다고 해서 64비트 컴퓨팅으로 가야 하지 않아야 된다는 것은 아니다. 세상은 복잡해지고 있고 고객의 절실한 요구이건 기업의 이윤추구를 위한 허풍이건 간에 언젠간 가야 하는 길이 64비트 컴퓨팅이다.

그러므로 좀 더 넓은 시야를 가진 개발자라면 현재 16비트 응용 프로그램에 대한 지원이 종료되었듯이 윈도우의 32비트 프로그램에 대한 엄호는 언젠가 사라질 것을 예측하고 64비트 컴퓨팅을 대비해야 한다. 다음 글에서는 64비트 윈도우에서 달라진 점들을 개발자의 관점에서 살펴보도록 하겠다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

#include "comdef.h"
#include "mshtml.h"
#include "mshtmcid.h"
#include "mshtmhst.h"
#include "exdisp.h"
#include "objbase.h"


void CMercuryFormView::OnHomepage()
{
// TODO: Add your command handler code here
//ShellExecute(0, _T("open"), _T("C:\\Program Files\\Internet Explorer\\IEXPLORE.EXE"), _T("http://CarrotBoy.Net"), 0, SW_SHOWNORMAL);



HRESULT hr;
IWebBrowser2 *pWebBrowser = NULL;
VARIANT vtHeader2={0};
VARIANT vtTarget2={0};
VARIANT vtEmpty2={0};

vtHeader2.vt = VT_BSTR;
vtHeader2.bstrVal = SysAllocString(L"Content-Type: application/x-www-form-urlencoded\r\n");

vtTarget2.vt = VT_BSTR;
vtTarget2.bstrVal = SysAllocString(L"_top");

VariantInit(&vtEmpty2);

CoInitialize(NULL);
CoCreateInstance(CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER,IID_IWebBrowser2, (void**)&pWebBrowser);

pWebBrowser->put_Width(800); // 가로 폭
pWebBrowser->put_Height(600); // 세로 폭
pWebBrowser->put_Left(0); // 외쪽 포인트
pWebBrowser->put_Top(0); // 오른쪽 포인트
pWebBrowser->put_ToolBar(VARIANT_FALSE); // 익스플로어 툴바 없앰
pWebBrowser->put_MenuBar(VARIANT_FALSE); // 메뉴바 없앰
pWebBrowser->put_AddressBar(VARIANT_FALSE); // 주소창 없앰
pWebBrowser->put_StatusBar(VARIANT_FALSE); // 상태바 없앰
pWebBrowser->put_Visible(VARIANT_TRUE);
HWND exh;
pWebBrowser->get_HWND((long*)&exh);
SetForegroundWindow();

hr = pWebBrowser->Navigate(SysAllocString(L"http://CarrotBoy.Net"), &vtEmpty2, &vtTarget2, &vtEmpty2, &vtHeader2);
//hr = pWebBrowser->Navigate(SysAllocString(L"www.daum.net"), &vtEmpty2, &vtTarget2, &vtEmpty2, &vtHeader2);
if(SUCCEEDED(hr))
{
//SetVisited(); // 제대로 갔다면 링크를 방문한 색깔로 바꿈
}
else // 오류시 메시지
{
/*
CString msg="HyperLink Error";
if(E_INVALIDARG == hr) msg+=": Invalid Parameters.";
else if(E_OUTOFMEMORY == hr) msg+=": Out of memory.";
MessageBeep(MB_ICONEXCLAMATION); // Unable to follow link
AfxMessageBox(msg, MB_ICONEXCLAMATION | MB_OK);
*/
}

SysFreeString(vtHeader2.bstrVal);
SysFreeString(vtTarget2.bstrVal);
pWebBrowser->Release();

CoUninitialize();

}

요즘 신세대 알뜰족에게 최고의 인기를 얻고 있는 인터넷 초절약 사이트. 완전 공짜에서 할인 쿠폰, 그리고 반품 사이트까지…. 조금만 부지런하면 당신도 현명하고 행복한 짠돌이ㆍ짠순이가 될 수 있다.   한 번 클릭으로 부자되는 최소의 길로 당신을 안내한다. 에디터 | 박혜미

돌아온 거면 뭐 어때? 반품 사이트 반품 닷컴 (www.vanpum.com) 반품 리스트를 클릭하면 반품 사유까지 알 수 있어 제품을 안심하고 구입할 수 있는 사이트. 서울 삼성동 코엑스몰에 오프라인 매장도 갖고 있다. 재고 상품, 소비자 변심에 의해 반품된 상품, 매장 전시 제품 등으로 구분되어 판매되고 있으며, 제품 구매시 최소 3개월 이상의 A/S는 물론 100% 교환이나 환불까지 보증된다. 반품 럭셔리 (www.vpluxury.com) 유명 브랜드나 명품 중에서 반품과 매장 전시품을 골라 저렴하게 판매하는 사이트. 명품 감정사의 정품 검증 후 판매되므로 믿고 구입할 수 있다. 8만원 이하 구입시 3000원의 배송료가 부가되며, 3일 내 교환이나 반품 시 택배비 외에 4천원을 추가 지불해야 한다. 리퍼브 샵 (www.refurbshop.co.kr) 반품할인 뿐만 아니라 개인이나 단체에게 렌털했던 제품을 초저가인 9천 9백원에 판매하는 9900존 등이 있다. 정크존에서 구입한 제품 외의 모든 제품이 수령 후 3일 내에 교환 또는 환불이 가능하고 A/S도 보장된다. 유니즈 닷컴 (uniz.korea.com) 반품 및 이월상품을 전문적으로 파는 사이트. 유니즈가 강력하게 추천하는 베스트 반품 코너와 믿을 수 없는 가격의 헐값 땡처리 코너가 눈여겨볼 만하다. 분당 오리역 CGV 3층에 유니즈 닷컴 직영 매장도 있다. 조금씩 아끼는 재미, 쿠폰 사이트 메뉴판 (www.menupan.com) 먹을거리에 관한 한 이곳을 따를 수 없다. 맛있는 즐거움이 있는 메뉴판 닷컴. 할인 쿠폰은 물론 전국 최고의 맛집들에 대한 정보가 가득하다. 코코 펀 (www.cocofun.co.kr) 외식, 뷰티, 문화 등 다양한 카테고리의 쿠폰을 얻을 수 있다. 요일별 쿠폰과 모바일 프리미엄 서비스 외에도 매월 1일 오프라인으로 쿠폰 매거진 발행. 또오레 (www.ttoore.co.kr) 신촌, 홍대, 강남, 압구정을 비롯해 젊은이들이 많이 찾는 지역의 쿠폰이 있는 곳. 할인 쿠폰보다 조건부 무료 쿠폰이 많은 것이 특징. 배송료만 지불하면 쿠폰북 구독이 가능하다. 쿠폰 투유 (www.coupon2you.co.kr) 먹을거리, 볼거리 이외에 여행, 유학, 이사 등과 관련된 쿠폰이 많은 곳. 다양한 쿠폰을 온라인에서뿐만 아니라, 유명 주간지와 월간지에서 오프라인으로도 만날 수 있다. 씨티 스케이프 (www.cityscape.co.kr) 도시생활 정보와 함께 할인 쿠폰을 제공하는 사이트. 서울의 경우 업종별ㆍ지역별로 상세한 검색이 가능하다. 신속한 업데이트가 최고 장점이다. 한 푼도 낼 수 없다, 완전 공짜 사이트 * 무료 시사회로 감동 두 배 무비스트 (www.movist.com) 최신 영화 소개부터 20자 평까지 영화에 대한 모든 것을 제공하는 영화 전문 사이트. 전국 유명 극장 예매도 가능하고, 영화 관련 이벤트가 많아 여러모로 유용하다. 간단한 퀴즈만 풀면 개봉 예정작의 시사회에 자동 응모된다. 출발 비디오 여행 (www.imbc.com) 영화 정보 프로그램에서 진행하는 시사회 이벤트. 해당 프로그램의 방영이 끝나는 순간부터 이벤트가 진행되며, 별도의 사연 기재 없이 보고 싶은 영화만 클릭하면 된다. TV 프로그램이니만큼 좋은 영화가 많다. * 공짜로 꾸미는 휴대폰 네이트 온 (nateon.nate.com) 가장 인기가 높은 무료 문자 사이트로 회원 가입만 하면 문자 메시지가 월 100회 무료. 물론 011이 아니어도 가입이 가능하다. 메신저 기능도 있는 네이트 온은 최근 싸이월드 미니홈피와 연계되어 더욱 편리해졌다. 벨소리 바다 (www.ringbada.com) 이벤트에 참여하면 벨소리가 무료다. 또는 이곳에 게재되어 있는 타 사이트 회원 가입 이벤트를 통해 포인트를 적립하여 해당 금액에 해당되는 벨소리나 컬러링을 구입할 수 있다. 구라 코리아 (www.gurakorea.com) 인기 유머부터 엽기 동영상, 최신 플래시까지... 재미있는 요소들이 많다. 무엇보다도 회원 가입을 하면 매일 3건의 문자가 무료로 제공되고, 벨소리와 컬러링도 무료 서비스도 곧 시행될 예정이라고 한다. * 내 피부에 맞을까? 무료 화장품 샘플 DHC (www.dhckorea.com) 홈페이지에서 회원 가입만 하면 여성에게는 스베스베 샘플 4종 세트를, 남성에게는 DHC for Men 샘플 5종 세트를 무료로 보내준다. 3일 사용 분량으로 배송료도 없다. 이지함 (www.LJHmall.com) 구매 고객은 물론 신규회원에게도 클린징 젤과 선블록 로션을 비롯해 5종 세트로 구성된 샘플을 증정한다. 회원 가입 후 별도로 이벤트 메뉴에서 샘플 신청서를 작성하면 1회에 한해 샘플이 제공된다. 돈 버는 알뜰 정보 공유 카페 짠돌이 카페 (cafe.daum.net/mmnix) 국내 알뜰 카페의 전설인 회원 수 39만 7천 명의 짠돌이 카페. 알뜰 고수들의 수준 있는 절약 테크닉을 쉽게 배울 수 있다. 주부, 직장인, 학생 등으로 나누어 그에 알맞은 절약 노하우를 제시해 더욱 유익하다. 부자 클럽 (cafe.daum.net/3seoul) 회원 수 4천1백여 명의 알뜰하게 사는 방법이 가득한 다음 카페. 무료 문자와 벨소리는 물론 무료 시사회, 화장품, 만화, 운세까지 돈 한 푼 들이지 않고 모든 것을 누리는 노하우를 얻을 수 있다. 짠돌이 협회 (cafe.naver.com/zzandol2) 짠돌이 십계명이 인상적인 회원 수 9천 2백여 명의 짠돌이 협회 카페. 이곳 역시 학생과 직장인, 주부의 절약 연구소가 각각 만들어져 있으며, 1주일을 5천원으로 살아보는 ‘5천원의 행복’이란 메뉴가 재미있다.

UML과 개발 프로세스라는 것이 만나게 되면 각 프로세스 별로 UML을 활용하여 모델링을 하는 방법이 약간씩 달라지기 때문에 사용상 주의가 필요하게 된다. 이와 더불어 웹 애플리케이션 개발을 위한 UML 모델링은 어떻게 하면 좋은지에 대해서도 생각해볼 필요가 있다.

이번 글에서는 지금까지 UML을 이용하여 소프트웨어 개발을 수행하면서 느꼈던 개념상의 모호함과 모델링 시 주의할 점에 대해 살펴보고자 한다.

약 7년 전 필자는 UML에 관하여 세미나를 하려고 어느 업체를 방문한 적이 있었다. 세미나를 막 시작하려고 하는 순간 어느 분께서 'UML이 이번에 새로 나온 XML의 한 종류인가 보죠?'라고 질문을 했다. 과연 이 난관을 어떻게 헤쳐 나가야 할지 막막한 순간이 UML에 관한 이야기를 하려고 하면 지금도 떠오른다.

UML이 우리나라에 처음 소개되던 시기에는 많은 분들이 객체지향이나 모델링 언어에 대한 개념이 일반적이지 않았다. 하지만 약 7년이 지난 지금은 소프트웨어 개발을 하는 대부분의 종사자들은 UML이라는 것이 무엇이고 어디에 쓰는 것인지 알고 있다. 또한 소프트웨어를 개발하기 위해서는 적어도 UML 다이어그램 몇 개 정도는 그려줘야 할 것 같은 생각을 갖고 있다. 많은 인식의 변화가 있었지만 지금 이 순간에도 여전히 UML이라는 것을 제대로 활용하여 소프트웨어를 개발하고 있는지 제대로 알고 있는지는 의문을 갖지 않을 수 없다.

UML과 모델 그리고 산출물
UML과 모델, 산출물은 비슷한 것 같지만 실은 아주 다른 개념이다. 우리가 소프트웨어라는 것을 개발하기 위해 '무엇을 만들 것인가?'라는 질문에 답하기 위해서는 대상이 되는 문제영역을 정확히 알 필요가 있다. 소프트웨어 개발팀 혹은 개발자는 문제영역에 대하여 정확하게 이해하기 위한 가장 좋은 방법은 모델을 통하는 것이다. 모델은 문제영역의 현실을 단순화시킴으로써 우리가 만들고자 하는 시스템을 더 잘 이해할 수 있게 한다.

『The UML User Guide』에 의하면 모델링을 통해 우리는 다음과 같은 4가지 목적을 얻을 수 있다고 한다.

즉, 복합한 시스템에 대해 모델을 만드는 이유는 그러한 시스템을 전체적으로 이해할 수 없기 때문이다. UML은 앞에서 언급한 4가지 목적에 충실히 부합하기 때문에 소프트웨어를 개발함에 있어 모델링 언어로 UML을 이용한다.

UML 다이어그램이 산출물인가?
필자는 어느 프로젝트의 개발 프로세스 멘터링를 하기 위해 한 업체를 방문한 적이 있었다. 그 곳에서 도착하여 간단한 미팅을 한 후 가장 먼저 요구했던 정보는 고객과 합의한 활동과 산출물의 목록이었다. 그 문서에는 역시 예상대로 요구사항 산출물에 '유스케이스 다이어그램'이라는 것이 있었고 분석 산출물에 '클래스 다이어그램'이라는 것이 들어 있었다. 이외 여러 부분에 'XXX 다이어그램'이 눈에 띄었다.

UML 다이어그램이 산출물이 될 수 있는가? 결론적으로 말하자면 UML 다이어그램은 산출물이 아니다. 나중에 자세히 설명하겠지만 산출물의 한 종류가 모델이고 모델을 표현하기 위한 수단 중에 하나가 UML 다이어그램이다.

예를 들어 UML의 클래스 다이어그램을 생각해 보자. 다양한 종류의 산출물은 그 산출물이 표현하고자 하는 정보를 보여주기 위해 UML 다이어그램을 이용한다. 유스케이스 실현(Realization)의 VOPC(View of Participating Classes)에서도 사용하고 비즈니스 조직을 표현하고자 할 때도 클래스 다이어그램을 사용할 수 있다. 또한 아키텍처 메커니즘을 표현하고자 할 때도 클래스 다이어그램을 이용한다. 유스케이스 다이어그램의 경우도 비즈니스 유스케이스 모델을 표현할 때도 쓰이고 시스템 유스케이스 모델을 표현할 때도 쓰인다. 다양한 산출물에 UML 다이어그램을 쓴다.

요구사항에서 혹은 분석/설계에서 산출물로 클래스 다이어그램이라고 명시해 놓으면 과연 어떤 클래스 다이어그램인지 알 수 있을까? 또한 시퀀스 다이어그램이 산출물 목록에 버젓이 들어있다면 그 다이어그램은 과연 어떤 정보를 표현하려고 하는 다이어그램인지 알 수 없다. 다이어그램은 산출물의 의도를 표현하기 위해 사용하는 하나의 표현도구이다. 산출물은 절대로 아니다.

우리의 목적은 산출물이다
앞에서 UML은 산출물이 아니며 모델은 산출물의 한 종류라는 것의 이야기했다. 그렇다면 산출물을 무엇을 의미하는가? 일반적으로 산출물이라는 것은 종이 형태의 문서로 알고 있다. 하지만 산출물은 프로세스를 통해 프로젝트 기간 동안 만들어지는 의미를 갖는 모든 것을 일컫는다. 그 중 하나가 모델이며 실행 가능한 바이너리 형태의 컴포넌트, 문서, 소스코드, 스크립트 등이 해당한다. 산출물(Artifact)의 정의를 보면 다음과 같다.

<그림 1>은 산출물과 모델 그리고 UML과의 관계를 클래스 다이어그램으로 표현한 것이다.

<그림 1> 산출물의 종류와 UML간의 관계

모델링은 개발기간을 늘이는 원흉?
필자는 지금까지 여러 프로젝트에서 직접 개발에 참여하기도 했고 컨설팅 또는 멘터링 형태로 참여하면서 사람들로부터 많은 질문을 받아왔지만 그 중에 가장 많이 하는 질문은 “우리 프로젝트에 UML이 꼭 필요하겠습니까? 프로젝트 규모가 좀 작으면 UML을 적용하지 않아도 괜찮지 않을까요?”라는 것과 “UML을 적용하면 개발이 좀 늦어지지 않겠습니까?”라는 두 가지 질문이 대표적이다.

우선 첫 번째 질문의 의미를 생각해 보자. 프로젝트 규모가 작으면 UML을 굳이 적용하지 않고 두어 명 개발자들이 그냥 뚝딱뚝딱 시스템을 만들면 되지 않을까 하는 것이다. 필자도 비슷한 생각으로 모델링을 하지 않고 프로젝트를 진행해 본적이 있었다. 개발자 3명이 기능 수 약 100개 정도의 시스템을 개발한 적이 있었는데, 작고 간단한 시스템이었으므로 순진한 생각에 그냥 테이블 정도만 정리해 놓고 코딩부터 시작하면 쉽고 금방 될 줄 알았다.

하지만 상황은 그렇게 호락호락하지 않았다. 용어와 기능부터 명확히 정의되지 않았고, 시작부터 개발자간의 서로 다른 이해수준은 프로젝트를 암울하게 만들었다. 어렴풋한 이해를 바탕으로 만들어지는 코드는 만들고 나서 뜯어고치는 코드가 더 많아 졌고 비즈니스 컴포넌트간의 인터페이스로 수시로 어긋났다. 결국 간단하게나마 모델을 만들면서 진행하기로 했고 모델링 시간 약간 줄이려고 하다가 우왕좌왕한 만큼 시간을 허비한 결과로 나타났다. 꼭 UML이 아니더라도 어떤 형태로든지 모델링은 해놓았어야 했고 그것이 업계 표준인 UML로 했더라면 더 좋지 않았을까 하는 후회가 든다.

혼자 만들더라도 역시 UML로 모델링을 하는 것이 개발하는 중에도 좋고 개발하고 난 뒤를 생각해봐도 반드시 필요하다는 생각이다. 개발을 마치고 난 뒤에 누군가 그 시스템을 유지보수 해야 한다면 전 개발자가 UML을 이용하여 만들어 놓은 모델을 보고 아마 감사하게 생각 할 것이다. 또 개발하고 있는 순간에도 몇 명밖에 없지만 그 사람들끼리 의견 교환이나 문제 영역에 대한 공통적인 이해를 돕기 위해서도 필요하다. 혼자 개발하더라도 생각이 정리가 잘 안되면 UML로 아이디어를 정리하는 판에 다른 사람과 생각을 맞추는데 필요가 없겠는가?

“UML을 적용하면 개발 기간이 늦어진다”. 어떻게 보면 약간 황당할 정도의 이야기임에 틀림없다. UML 때문에 개발기간이 늘어나는 것이 아니라 익숙지 않은 UML을 모델링 언어로 선택함으로써 배우는 기간이 더 늘어나는 것이 정확한 의미가 아닐까 싶다. 심지어 어떤 프로젝트 매니저는 개발은 그냥 개발대로 나가고 산출물은 산출물대로 만들어 나가서 나중에 소스코드가 나오게 되면 역공학(Reverse Engineering)을 통해 UML 모델을 만들어내자는 제안을 하기도 했다. 모델과 코드간의 동기화를 위해 역공학을 이용하지만 과연 이것이 시간을 줄이는 방법일까?

개발 프로세스와 과도한 모델링
무엇을 모델링 할 것인가? 어느 정도의 정밀도 수준으로 모델링 할 것인가? 모델링의 범위는 어떻게 설정해야 하는가? 이러한 질문에 답하기 위해 이것저것 고민해보기도 하고 업계에 종사하는 분들과 메신저로 혹은 술자리에서 때로는 프로젝트 회의 시간에 토의를 많이 해 보았다. 그 중 필자가 알고 지내는 대부분의 개발자들의 한결같은 주장은 '과도한 모델링'의 압박에 시달린다는 것이었다. 이야기를 해 본 결과 실제로 개발자들이 느끼는 '과도한 모델링'의 기준은 주관적이었지만 몇몇 주장은 일견 수긍이 가기도 했다.

그 중에 하나가 프로세스의 적용 문제였는데 지구상에 존재하는 모든 프로젝트는 서로 다른 시스템을 만들고 있기 때문에 모든 프로젝트 천편일률적으로 적용되는 모델링 범위나 정밀도 수준은 없다. 하지만 그것을 프로젝트의 규모나 도메인의 종류 등의 일반화된 기준으로 묶고 그 기준에 해당하는 개발 프로세스를 제공해야 한다. 예를 들어 현재 우리나라에서는 RUP(Rational Unified Process)나 마르미와 같은 프로세스 프레임워크를 많이 사용한다. 또 SI 업체에서는 자체적으로 발전시켜온 방법론이나 앞에서 언급한 RUP 또는 마르미를 기반으로 하여 자체 프로세스를 개발하여 사용한다.

문제는 각 프로젝트마다 프로세스를 조정(Tailoring)해서 적용해야 하는데 현실은 그렇지 않다는 것이다. 심지어 이런 이야기를 들은 적도 있다. "CBD를 적용하기엔 우리 프로젝트 규모에 좀 안 어울리지 않나요? 아는 사람한테 물어봤더니 규모가 작으면 CBD가 안 어울린다고 하더라고요. 대신 굳이 CBD를 하려면 UML 모델링 툴을 반드시 도입해서 진행해야 한다고 하던데…" 누가 이 분에게 그런 이야기를 했는지 모르지만 이 정도 되면 거의 사기에 가깝다. 그 분이 생각한 CBD라는 것이 무엇이었는지 어림짐작되는 대목인데 마치 신발에 발을 맞추는 꼴이 되어 버렸다.

발을 보호하는 것이 1차적인 목표이고 멋도 부리는 것이 신발을 신는 2차 목표라고 보면, 우선 성공적인 프로젝트를 수행하기 위해 프로세스를 도입하고 이왕 개발할 것 좀 체계적으로 가이드를 받아보자는 목적도 있을 것이다. 객체지향이나 CBD와 같은 단어의 의미는 일단 논외로 하고 앞에서 언급한 프로세스 조정에 관하여 이야기 해보자.

프로세스 조정
앞에서 언급했듯이 RUP나 마르미는 일반적이고 범용적인 개발 프로세스이다. 세 달간 3명이 개발하는 프로젝트와 2년간 50명이 개발하는 프로젝트 모두 개발 프로세스가 같을 수 있겠는가? MS 워드와 같은 워드프로세서를 개발하는 것과 은행을 위한 전산 시스템을 개발하는 개발 프로세스가 같을 수 있겠는가?

서로 다른 특성을 갖는 프로젝트를 위해 프로세스 조정(Tailoring)이란 작업을 하게 되는데 여기서 유의해야 할 것은 조정할 수 있는 영역을 제한해야 한다는 것이다. 프로젝트 현장에서 편의대로 프로세스를 고치거나 누락시켜서는 안되고 프로세스 조정의 결과는 승인되어야 한다. 더 나아가 프로젝트 세부 유형에 따른 개발 프로세스를 제공한다면 더할 나위 없이 좋을 것이다. 프로세스의 대표적인 구성 요소로는 작업 영역, 작업 흐름, 활동, 산출물, 역할 등이 있다. 필자는 이 모든 것이 프로세스 조정 대상이 될 수 있다고 생각한다.

RUP의 경우 '프로세스 엔지니어'가 프로세스 조정 작업을 진행하고 마르미 경우 ‘도구 및 방법론 관리자’가 그 역할을 수행한다(XP의 경우는 코치라고 한다. 편의상 이 글에서는 모두를 프로세스 엔지니어라고 칭하겠다). 이런 역할의 특성상 다른 사람과의 의견 교환이나 대립이 있기 때문에 프로세스 엔지니어는 소프트웨어 개발에 관한 폭넓은 지식을 갖고 있어야 하며 의사소통 능력이 있어야 한다. 프로젝트 관리자나 프로젝트 리더 또는 시스템 분석가나 아키텍트를 설득해야 할 일이 있을 수도 있다.

프로젝트 관리자나 프로젝트 리더는 프로젝트 관리 관점으로 개발 프로세스를 바라볼 것이고 시스템 분석가나 아키텍트는 소프트웨어 시스템을 개발하는데 중요한 결정을 내리기 위한 관점으로 프로세스를 바라보며 자신의 의견을 제시 할 것이다. 이들의 의견을 통합하고 조정하며 고객의 요구를 반영하여 해당 프로젝트의 상황에 맞는 프로세스로 조정하게 된다.

<그림 2> 프로세스 엔지니어의 활동과 산출물

<그림 2>에서 프로세스 엔지니어는 현 개발 조직 평가, 개발 케이스(Development Case) 작성, 프로젝트 전용 템플릿 작성의 세 가지 활동을 하게 된다. 이에 따른 개발 조직 평가, 개발 케이스 프로젝트 전용 템플릿의 세 가지 산출물을 작성하는데 여기서 가장 핵심적인 산출물은 개발 케이스이다. 특정 프로젝트를 위한 프로세스를 조정하고 개발 케이스를 작성하기 위해서는 프로젝트의 상황을 이해 할 필요가 있는데 이를 위하여 현 개발 조직에 대한 평가가 이루어져야 한다. 또한 개발 조직 이외에도 고객에 대한 평가도 동시에 이루어져야 한다.

예를 들어, 기업을 위한 애플리케이션을 개발한다고 가정한다면 개발 완료 후에 고객은 유지보수를 위한 산출물을 요구할 것이다. 프로세스 엔지니어는 개발 조직 및 고객을 대상으로(좀 더 의미를 확장하자면 이해관계자를 의미 할 수 있다) 현 개발 조직에 대한 평가를 할 때 프로세스, 툴, 사람들의 능력, 사람들의 태도, 고객들, 사용 기술, 문제점, 개선 분야의 관점에서 개발 조직의 현재 상태를 평가한다.

프로세스 조정을 위한 요구사항을 파악하고 이를 근거로 프로세스 조정을 실시한다. 프로세스 조정의 결과는 개발 케이스이다. 프로세스 조정에 관한 자세한 사항을 알고 싶으면 RUP나 마르미 또는 Barry Boehm과 Richard Turner가 쓴 『Rebalancing Your Organization's Agility and Discipline』를 참조하면 도움이 될 것이다.

케이스 툴을 쓰면 생산성이 높아지는가?
Steve McConnell은 그의 저서인 『Professional Software Development(2003)』에서 코끼리에 관한 재미있는 이야기를 소개했다. 이야기를 요약하면 이렇다.

고대 이집트 어느 왕의 피라미드를 만드는 공사가 한 참 진행 중이었다. 엄청나게 큰 암석을 사람들이 일일이 날라야 했으므로 공사의 진척은 매우 더디었다. 그래서 공사 프로젝트 관리자는 고민 끝에 어디선가 코끼리라는 엄청난 동물이 있는데 이 동물은 사람이 운반하는 것 보다는 몇 배 혹은 몇십 배 높은 생산성은 낸다는 이야기가 얼핏 기억이 기억났다. 이 동물만 들여오면 지금까지 지연되었던 일정을 단번에 만회할 수 있을 것 같은 생각이 들었다.

공사 프로젝트 관리자는 그 동물을 도입하기로 결심하고 일을 추진했다. 코끼리라는 동물을 들여놓고 보니 과연 듣던 대로 몸집도 엄청나고 그에 걸맞게 힘도 대단했다. 공사 프로젝트 담당자는 입가에 미소를 머금으며 공사현장에 코끼리를 투입하라는 지시를 내렸다. 그러나 그 동물을 투입하는 순간 순조롭게 진행될 것 같은 공사가 점점 이상하게 진행되고 일정도 생각했던 것만큼 줄여지지 않았다. 줄여지기는커녕 오히려 사람이 진행했던 것보다 더 늦어지는 조짐이 보였다.

공사 프로젝트 관리자는 상황파악에 나섰는데 공사 현장에 가서 자세히 관찰을 해보니 문제를 바로 파악할 수 있었다. 바로 코끼리를 다룰 수 있는 사람이 없었던 것이었다. 그의 공사팀은 그런 동물을 부리면서 일을 한 적이 단 한번도 없었기 때문에 기존의 공사프로세스와 엄청난 혼선을 빗었다. 또 코끼리에 대해 아는 것이 전혀 없었기 때문에 코끼리를 돌보지 못해 걸핏하면 앓아눕기 일 수였고 몇몇 코끼리는 도망가 버려 엄청난 비용을 들여 도입한 코끼리가 무용지물이 되어 버렸다. 공사 진행은 그 만큼 지연되었고 코끼리를 포기할 수밖에 없었다"

필자가 보기엔 그 코끼리가 바로 케이스 툴이 아닌가 싶다. 프로젝트 생산성을 높이기 위해 케이스 툴을 도입하는 것은 바람직하지만 그 생산성을 높이기 위해서는 일정 기간의 훈련이 필요하다. 요즘 나오는 케이스 툴은 기능도 막강하고 더불어 복잡하다. 또 종류도 많아 수많은 케이스 툴과 연동도 필요하다. 일례로 IBM 래쇼날의 스위트 제품은 내장하고 있는 서브 제품만 해도 10여 가지가 넘는다. 다른 케이스 도구도 사정은 다를 바 없다.

프로젝트 현장의 요구는 이러한 제품을 좀 편하게 사용하고 싶어 한다. 소프트웨어 개발 라이프 사이클 전반에 걸쳐 케이스 툴을 적용하려고 서로 다른 회사 목적이 다른 툴을 서로 연계시켜야 한다. 이 일은 대단히 복잡하고 가변적이어서 앞의 요구를 충족시키려면 프로세스적으로나 케이스 툴에 대한 상당한 지식과 수준의 기술이 요구된다.

요구사항관리 도구와 분석/설계를 위한 모델링 도구와의 연계 부분, 모델링 도구와 개발 및 테스팅 도구와의 연계 부분이 대표적인 연계 부분이다. 또한 각 케이스 툴에서 쏟아져 나오는 다양한 모델과 문서들을 통합적으로 관리할 수 있는 형상 및 변경 관리와 각 작업영역(요구사항, 분석/설계, 구현, 테스트 등)을 기반으로 하여 반복 개념으로 프로젝트를 관리해야 하므로 실제 케이스 툴이 소프트웨어 개발을 도와주려면 아주 많은 것들을 고민해야 한다.

특히 프로젝트 현장에서 따르고 있는 프로세스를 정확히 지원해줘야 하므로 케이스 툴 자체의 유연성도 갖춰야 한다. 케이스 툴은 단어의 의미에서와 같이 소프트웨어 개발을 정말로 도와주는 케이스 툴이 되어야 하지 않을까 싶다.

머릿속 아이디어를 모델로 구체화하기
필자는 항상 프로젝트를 진행하다 보면 항상 딜레마에 빠지는 문제가 있다. 프로젝트에 참여하는 사람들이 UML을 잘 모르는 경우이다. UML을 모델링 언어로 채택한 프로젝트는 그 프로젝트에 참여하는 모든 사람들이 UML을 알고 있어야 한다는 전제조건이 따른다.

하지만 현실은 어떠한가? 프로젝트를 수주해야만 먹고 사는 개발 업체의 경우 UML을 알던 모르던 일단 수주를 해야만 하는 상황이다. 그 회사의 개발팀 구성원이 UML을 잘 알고 있다면 문제가 없겠지만 잘 모르는 경우 심하면 그 구성원 중 단 한 명도 제대로 알지 못하는 경우 문제가 아닐 수 없다.

이 때 가장 많이 활용하는 방법은 UML을 알고 있는 사람이나 업체를 고용하여 먼저 샘플을 만들게 한 후 그것을 템플릿으로 하여 모델링을 진행하는 것이다. 물론 이런 프로젝트가 많아야 필자 같은 사람들이 먹고 살긴 하겠지만 프로젝트 입장에서는 참 못마땅한 일이 아닐 수 없다.

예를 들어 UML을 알고 있는 사람이 시스템의 한 부분에 대하여 클래스 다이어그램을 그렸다고 하자. 그 클래스 다이어그램이 샘플로 나오면 다른 모든 사람들은 그 샘플을 기반으로 모델링을 시작하게 된다. 맞는지 틀리는지 자신의 판단 기준이 없는 채로 샘플을 '다른 이름으로 저장하기'로 해서 따로 하나는 만들어 놓은 다음 다이어그램을 그리고 저장을 한다. 예전에 학교에서 다른 친구 소스코드 구해다가 변수명 좀 바꾸고 약간 짜깁기해서 리포트를 제출하는 것과 비슷한 상황이 된다.

다이어그램이야 만들어 졌지만 모델링을 하는 사람이 그 모델이 적합한지 아닌지 판단할 수 없으므로 그려진 다이어그램을 들고 샘플을 만든 사람에게 달려와 이것저것 물어본다. 물론 어쩔 수 없는 상황이고 그런 과정을 거치면서 사람들의 모델링 실력이 향상되겠지만 모르면서 그림을 그리는 사람도 답답하고 프로젝트 진행에도 문제가 많다.
잘 모르는 사람이 프로젝트를 하는, 어떻게 보면 시작부터 이상하긴 하지만 어쩔 수 없다고 보고 조금이나 도움이 되도록 머릿속의 아이디어를 모델로 구체화 하는 과정을 소개하면 조금 낫지 않을까 싶다.

시작은 글쓰기부터
만들고자하는 모델이나 그리고자 하는 다이어그램에 따라 접근 방식이 다르겠지만 결국 시작은 머릿속의 생각을 글로 정리하는 것부터 시작한다. 글로 쓰기 귀찮다면 메모장이나 화이트보드에 본인의 생각을 간단하게나마 자유로운 형식으로 정리하면서 시작하게 된다.

예를 들어, 고과장이 애플리케이션 프레임워크를 모델링 한다고 가정해 보자. 프레임워크를 모델링하는 사람이 UML을 설마 모르진 않겠지만 이 사람이 어떤 과정을 거치면서 머릿속 아이디어에서부터 구체적인 모델을 만들어 가는지 살펴보자. 고과장은 프레임워크의 한 부분을 모델링하기 위해 고심하다가 머릿속에서만 맴도는 아이디어를 글로 써보기로 했다.

클라이언트에서 어떠한 메시지를 보내면 프레임워크에서는 그 메시지를 해석하여 어떤 비즈니스 로직을 수행할 지 결정하여 수행한다. 메시지에 따라 수행하는 비즈니스 로직은 메시지가 변해도 동일한 비즈니스 로직이 수행되어야 하거나 동일한 메시지에도 상황에 따라 비즈니스로 로직이 바뀔 수 있어야 한다.

써 놓고 읽어보니 대충 어떤 방향으로 만들어야 할지 느낌이 좀 오기 시작했다. 왠지 잘 될 것 같은 느낌으로 입가엔 미소를 머금으며 모델링 도구를 실행시켰다.

모델링을 시작하다
우선 고과장은 클라이언트와 클라이언트가 보내는 메시지를 받는 무엇인가가 있어야 하지 않을까 하는 생각이 들었다. 또 어떤 비즈니스 로직을 수행할지 판단하는 객체도 있어야 할 것 같고, 클라이언트가 보낸 메시지에 대응하는 비즈니스 로직을 갖고 있는 정보를 갖고 있는 객체도 있어야 할 것 같다.

고과장은 우선 '클라이언트', '메시지 판단자', '메시지와 비즈니스 로직 맵핑 정보' 등이 객체가 되지 않을까 생각했다. 모델링 툴을 띄워놓고 세 가지 객체를 그리고 나니 이들 간의 관계와 각 객체가 어떤 일을 해야 하는지(Responsibility)가 알쏭달쏭 했다. 그래서 이 세 가지 객체를 놓고 이들 객체가 서로 어떻게 인터랙션(Interaction)하는지 알아보기 위해 시퀀스 다이어그램을 그려보기로 했다.

<그림 3> 개념 정리를 위한 시퀀스 다이어그램

이렇게 그려놓고 보니 객체 간에 어떻게 교류하는지 눈에 들어와 더 구체적으로 생각할 수 있게 되었다. 고과장은 시퀀스 다이어그램을 보면서 차근차근 짚어보기로 했다. 클라이언트가 메시지를 '메시지 판단자'에게 보내면 해당 메시지에 대응하는 비즈니스 로직을 알려주고 메시지 판단자가 비즈니스 로직을 수행하여 클라이언트에게 보내주는 깔끔한 형태로 정리된 것 같았다.

뭔가 빠진 것 같은데?
하지만 객체 간에 어떻게 교류하는지 눈에는 보였지만 왠지 무엇인가 빠진 듯한 느낌이 들었다. 시퀀스 다이어그램을 쳐다보고 있으니 메시지 판단자가 '비즈니스 로직 수행'을 하는 것이 메시지 판단자의 역할에 비해 좀 오버하는 듯한 느낌이 들었다. 또 비즈니스 로직 수행이 잘 되었는지 아닌지 판단하는 부분도 있어야 할 듯 했다. 그래서 '비즈니스 로직 수행자'라는 이름은 좀 이상하지만 이런 객체를 따로 빼 두어 시퀀스 다이어그램을 보완하기로 했다.

<그림 1> 산출물의 종류와 UML간의 관계

비즈니스 로직 수행자를 넣어 시퀀스 다이어그램을 다시 그려보니 이제 뭔가 맞아 돌아가는 느낌이 들었다.

<그림 5>"그림 3"의 클래스 다이어그램

UML의 시퀀스 다이어그램과 클래스 다이어그램을 통해 객체간에 교류와 각 객체의 책임(Responsibility)를 찾아냈다.

설계를 위한 모델로 발전
이제 개념적으로 정리한 모델을 바탕으로 좀 더 구현하기 좋은 형태로 발전시켜 보자. 구현을 위해서는 좀 구체적인 형태로 정의하고 실제적인 비즈니스 로직 처리와 에러 처리를 표현하기 위한 무엇인가가 필요했다. 고과장은 고민 끝에 웹 서버로부터 아이디어를 얻었다. 웹 서버는 웹 브라우저와 커뮤니케이션을 위해 Request와 Response를 사용한다. 브라우저의 요청은 Request에 담아 웹 서버로 보내고 웹 서버의 응답은 Response에 담아 브라우저로 보내게 된다. 이런 비슷한 개념을 프레임워크에 적용해보면 어떨까 생각했다.

즉, 클라이언트의 요청은 BusinessRequest에 담아 보내고 서버의 응답은 BusinessResponse에 담아 보내되, 비즈니스 로직 수행시 Exception이 발생하면 BusinessResponse에 담아 메시지 판단자가 처리하게 하면 어떨까 하는 생각을 했다. 고과장은 이렇게까지 생각이 정리되자 시퀀스 다이어그램을 통해 아이디어를 구체화 해보기로 했다. 시퀀스 다이어그램은 <그림 6>과 같다.

<그림 6> 보다 더 구체화된 시퀀스 다이어그램

클라이언트 쪽의 예상 소스코드도 넣어 보고 메시지를 비즈니스ID라는 용어로 바꿔봤다. 또한 비즈니스ID의 해당 비즈니스 로직을 실행시키기 위해서는 리플렉션(Reflection)이라는 기술도 써야 할 것 같고 Exception 처리를 위한 부분도 따로 둬야겠다는 생각이 들어 BusinessResponse에 BusinessExcuteHelper가 Exception을 담아주는 형태로 모델링을 했다.

<그림 6>의 시퀀스 다이어그램을 보면 중간 중간 노트가 많이 달려있는 것을 볼 수 있다. 시퀀스 다이어그램의 중간 중간을 보면 샘플 코드나 리플랙션, Exception과 같은 구현을 염두 한 노트를 볼 수 있다. UML로 모델링을 할 때 노트의 역할은 필수 불가결한데 해당 다이어그램의 이해를 돕기 위해서나 모델러의 의도를 명확히 하기 위해서 또는 아직 불분명한 부분이 있을 경우 판단에 도움이 될 만한 주석을 달기 위한 수단으로 이용하면 좋다.

구체화된 모델
자 이제 구현을 위한 시퀀스 다이어그램도 그렸고 구체적으로 어떻게 접근하면 될지 방안이 섰기 때문에 최종 클래스 다이어그램을 그려보기로 했다. 클래스 다이어그램을 그리면서 고과장은 클라이언트가 보내는 메시지와 해당 비즈니스 로직 정보를 어떤 형태로 할 까 고민하다 XML 형태로 하는 것이 가장 좋을 것 같다는 판단이 들었다.

애플리케이션이 실행되면서 XML에 있는 정보를 읽어 캐싱하고 있는 형태로 만들고 그 역할은 BusinessMapper라는 객체에 해당 정보를 Map에 담아 두기로 했다. BusinessMapper는 단 하나만 존재해야 하므로 싱글턴(Singleton) 패턴을 적용하기로 했다(실제 구현을 하기 위해서는 보다 더 구체적으로 모델링을 해야겠지만). <그림 7>는 고과장의 아이디어를 반영한 최종 클래스 다이어그램이다.

<그림 7> 고과장 생각을 정리한 최종 클래스 다이어그램

이 클래스 다이어그램에서 XXX_ServerPage나 XXX_Action, XXX_ActionForm, XXX_Mgr과 같이 XXX라는 접두어가 붙은 클래스는 비즈니스 로직 개발자들이 직접 만들어야 하는 부분이다. 개발자들은 XXX라는 접두어가 붙은 클래스만 개발하면 되고 고과장이 만든 프레임워크에 끼워 넣어 어떤 메시지가 어떤 비즈니스 로직과 맵핑되는지 XML 파일만 편집하면 되는 구조로 모델링이 되었고 고과장의 생각대로 메시지와 비즈니스 로직과의 느슨한 관계를 유지할 수 있는 모델이 만들어 졌다.

일단 이런 구조의 프레임워크가 좋은 것인지 아닌지는 일단 논외로 하고 머릿속의 아이디어를 모델로 구체화하는 과정을 다시 한번 정리하자면 우선 1) 머릿속의 아이디어를 글로 정리하고 2) 정리한 글을 바탕으로 UML로 바꿔 본다. 이때 동적인 측면과 정적인 측면을 고려하고 전에 정리한 글에서 UML로 변환하는 과정에서 빠진 것은 없는지 미처 생각하지 못한 것들이 있는지 확인한다. 그냥 글로 확인하는 것보다는 UML의 시퀀스 다이어그램이나 엑티비티 다이어그램 등을 이용하여 확인하면 보다 더 정확하게 모델링할 수 있다. 3) 이렇게까지 진행이 되었으면 실제 구현을 위한 모델로 발전시켜 본다. 특정 플랫폼이나 개발언어, 미들웨어 등을 고려하면서 그려나간다.

결국 1)～3)까지가 실제 모델링을 통해 아이디어를 구체화 시켜나가는 모든 것이다. 1)번을 잘 하기 위해 각종 기법(예를 들어, 유스케이스나 유저스토리 등)이 동원되고 2)번을 잘 하기 위해 CRC 카드와 같은 기법이 사용된다. 3)번 역시 마찬가지로 각종 설계 패턴이나 J2EE 패턴과 같은 것을 참조한다. 개발 프로세스에 따라 어떤 모델을 만드는가, 어떤 산출물을 만드는가에 따라 그려야 할 다이어그램이나 모델의 정밀도가 다르겠지만 결국 1)～3)까지의 행위를 반복함으로써 우리가 얻고자 하는 모델을 얻어낼 수 있다.

쉽고도 어려운 유스케이스 모델링
1960년대 후반쯤 이바 야콥슨에 의해 만들어진 유스케이스는 1990년대에 들어서면서 아주 폭넓게 사용하는 요구사항 파악 및 분석 기법으로 자리 잡았다. 우리나라의 경우 아마도 대부분의 프로젝트에서는 유스케이스라는 이름의 산출물을 만들고 있고 만들었을 것이다. 필자도 여러 프로젝트를 하면서 유스케이스를 써서 요구사항 분석을 했었다.

초기 접근하기에 개념적으로 어려운 부분이 별로 없기 때문에 누구나 의욕적으로 참여하여 유스케이스를 작성해 해 나간다. 하지만 이 유스케이스라는 것이 단순해 보이지만 결코 만만치 않은 특성을 갖고 있다. 처음에는 쉬운 듯하지만 진행해 나갈수록 어려워지는 경향이 있다. 또한 프로젝트의 진행 상태나 규모에 따라 유스케이스 작성 방식이 달라진다. 이러한 특성 때문에 바쁜 프로젝트에서 뭔가 별 고민을 하지 않고 쉬운 작성 형식이나 방법을 목말라하는 개발자들에게는 혼돈의 연속일 수밖에 없다.

필자 개인적으로 유스케이스에 관해 잘 설명한 도서는 Alistair Cockburn의 『Writing Effective Use Cases (2001)』이다. 영어에 어려움을 겪는 분들은 번역본도 나와 있으니 구해서 한번 꼭 읽어보길 바란다. 이 책의 내용 중에 유스케이스 작성시 주의할 점이 있는데 그 중 현장에서 실제로 많이 나타나는 몇 가지를 소개하고자 한다. 일부 주의사항은 책에서 발췌하고 필자가 느낀 점을 중심으로 설명해본다.

유스케이스는 산문체 수필이다
유스케이스 다이어그램을 갖고 지지고 볶던 독자들에게는 약간 의아한 말일 수 있다. 사실 유스케이스는 텍스트 기반의 서술이다. UML의 유스케이스 정의를 보아도 '유스케이스는 시스템 전체나 유스케이스 일부 행동을 명세화 하고 순차적으로 발생하는 활동들을 서술하는 것이다. 시스템은 이러한 활동을 수행하여 액터에게 원하는 결과를 준다'라고 되어 있다. 그래픽으로는 타원으로 표현하고 중심에는 몇 단어로 이루어진 이름이 있다.

프로젝트를 진행하면서 다이어그램에 얽매여 오로지 다이어그램만으로 유스케이스를 작성하려고 하면 관련 팀은 점점 어려움으로 빠져 들게 된다. 유스케이스 다이어그램 그 자체가 담고 있는 정보는 매우 한정적이다. 유스케이스명과 어떤 액터와 관계가 있는지를 나타내는 선 몇 개, 복잡하게 뒤 얽힌 '포함(include)와 확장(extends)을 표현하는 점선들이 뒤덮여 있을 뿐이다. 사람들이 그 다이어그램을 보고 요구사항이 뭔지 정확하게 알 수 있을까?

단어 몇 개로 이루어진 유스케이스 명을 보고 무엇을 하는 유스케이스인지 추측을 할 뿐이다. 다이어그램의 정보가 충분치 않으므로 답답한 마음에 다이어그램에 갖가지 정보를 넣으려고 하고 유스케이스의 목표 수준은 점점 내려가고 복잡해지는 현상이 나타난다. 결국 아무도 이해할 수 없는 다이어그램이 만들어지면서 오히려 팀간의 명확한 이해의 공유는커녕 혼란만 가중시키는 결과를 낸다. 유스케이스 다이어그램만을 놓고 이틀 동안 논쟁만 하는 개발팀을 실제로 보았다. 다시 한번 강조하지만 유스케이스는 텍스트 형식의 서술이다. 액터와 유스케이스 간에 어떤 일이 일어나는지 글로 적음으로써 이해를 명확히 할 수 있다.

유스케이스와 사용자 매뉴얼
유스케이스 교육을 들어 봤거나 프로젝트를 해 본 분들이면 아마도 귀가 따갑게 유스케이스는 GUI에 관한 부분은 적지 않는 것이라고 들어왔을 것이다. 유스케이스를 작성하면서 유저 인터페이스에 관한 내용을 언급하기 시작하면 유스케이스가 점점 사용자 매뉴얼이나 화면 설계서처럼 변해간다.

유스케이스는 향후 작성할 분석/설계 모델이나 화면 설계 등의 모델의 기본 정보를 제공한다. 또한 유스케이스로 추적(Trace)할 수 있다. 아니 추적되어야 한다. 사용자 매뉴얼이나 화면 설계서가 분석/설계 모델의 상위 요건이 될 수 있는가? 결코 그렇지 않다. 유스케이스는 적당한 목표수준으로 작성함으로써 상위 요건으로써의 역할을 다 할 수 있어야 한다.

포함과 확장의 오남용
어떤 유스케이스 다이어그램을 보면 다이어그램 가득히 실선과 점선이 어지럽게 꼬여 있는 그림을 가끔 본다. 왜 이런 다이어그램이 나오는지는 앞에서 언급하였다. 필자의 경우 이런 다이어그램은 십중팔구 뭔가 잘못되었을 것이라는 예감이 뇌리를 스친다. 우선 복잡하면 제대로 파악할 수 없고 서로 이해를 명확하게 하지 못했을 가능성이 높으며 이해도가 떨어지는 상황에서 유스케이스가 제대로 작성되었을 리가 없다.

유스케이스 다이어그램이 복잡하면 각 유스케이스의 이벤트 흐름을 작성하면서 아주 여러 부분에 포함(include)과 확장(Extends)이 나타나게 되고 결국 전체적으로 유스케이스의 유지보수를 어렵게 만든다. 유지보수가 어렵게 되면 요구사항을 정확히 담는데 점점 힘들어지고 현실과 동떨어진 그저 서로 다른 이해수준으로 각자의 머릿속에만 존재하는 요구사항이 나오게 된다.

최초 확장이라는 개념이 등장하게 된 이유는 이전 시스템의 요구사항 파일을 건드릴 수 없다는 실행 지침 때문이었다(Alistair Cockburn, 2001). 그 당시 개발팀의 임무는 새로운 서비스를 추가하는 것이었고 기존의 요구사항 문서를 건드릴 수 없는 상황에서 원래의 요구사항은 한 줄도 건드리지 않은 채 새로운 요구사항을 추가했다. Alistair Cockburn은 확장이 필요할 경우 다이어그램 상에서 보여주지 말고 기존 유스케이스 안에서 확장 유스케이스의 참조를 그저 텍스트로 서술할 것을 권유한다. 다이어그램에 복잡하게 확장을 표현함으로써 정작 중요한 유스케이스를 볼 수 없게 만들기 때문이다. 필자도 그의 주장에 동의 한다.

케이스 툴로 유스케이스 작성하기
케이스 툴로 유스케이스를 작성한다는 것이 잘못되었다는 것은 아니다. 오히려 케이스 툴이 활용상의 문제로 인해 정확한 유스케이스를 작성하는데 걸림돌로 작용하는 현상을 이야기하고 싶은 것이다. 필자는 지금까지 프로젝트를 진행하면서 유스케이스의 고단함에 대해 무척 많은 고민을 했었다. 일반적으로 개발자들은 작문을 싫어하는 습성이 있지만 요구사항을 파악하고 분석하는 사람들은 일반 고객과의 의사소통이 많기 때문에 산문 형식의 문서 작성(Technical Writing)에 능숙해야 함에도 불구하고 대부분의 프로젝트에서는 이러한 사실을 애써 외면한다.

작성하기 귀찮은 유스케이스를 케이스 툴로 그리고 끝내 버리려는 생각을 한다. 사실 필자도 예외는 아니어서 웬만하면 케이스 툴에서 모든 걸 해결하고 싶은 유혹에 항상 시달렸다. 하지만 대부분의 케이스 툴은 유스케이스를 서술하기 위한 조그만 다이얼로그 창만을 제공한다. 유스케이스를 기술한 문서를 따로 하이퍼링크 방식으로 케이스 툴과 연결하는 방법을 주로 취했는데 사실 힘들고 불편하다. 만약 어떤 케이스 툴의 기능 중에 일정한 유스케이스 작성 형식의 레이아웃을 디자인할 수 있고 그 템플릿 안에서 유스케이스를 작성하면 다이어그램이 역으로 만들어지는 케이스 툴이 있다면 얼마나 좋을까 하는 생각을 해본다. 언제쯤이면 편하게 유스케이스 모델링을 할 수 있는 케이스 툴이 나올까?

분석/설계 모델과 MDA
분석(分析)은 그 단어의 의미에서도 알 수 있듯이 무엇인가를 어떠한 목적 때문에 나누어(分) 쪼개는(析)것이다. 소프트웨어 개발에서 나누어 쪼개야 할 필요가 있는 부분은 문제 영역으로 시스템을 개발하는 사람들이 문제 영역을 올바로 이해하기 위한 목적으로 분석을 한다. 이해한 것을 즉시 시스템으로 만들 수 없으므로 중간에 문제 영역의 이해와 실 시스템간의 가교역할을 하는 것이 있는데 그것이 바로 설계이다.

사실 웬만하면 설계를 하지 않고 시스템을 만들고 싶은데 구현 언어나 플랫폼 등의 영향을 많이 받기 때문에 분석한 결과를 바로 시스템화하기 힘든 것이다. 현재 분석에서 설계를 거치지 않고 바로 실 시스템으로 건너가기 위한 노력이 진행되고 있는데 독자 여러분들도 잘 알다시피 MDA(Model Driven Architecture)가 그것이다.

현재 소프트웨어를 만드는 사람들의 작업 행태는 당연하게 생각되지만 지루하게도 4단계를 거친다. 문제 영역을 파악하고 분석하여 그 결과를 바탕으로 설계한 후 소프트웨어를 구현한다. 만약 정말 MDA가 활성화 된다면 중간에 1가지 단계가 빠지는 3단계 개발 공정이 나올 것이며 그저 요구사항 파악해서 분석 모델을 만들어 놓으면 실행 시스템이 튀어나오는 정말 환상적인 세상이 오지 않을까 싶다. 그런데 정말 이런 세상이 가능할까?

현 컴퓨팅 시스템은 다 계층 분산 시스템인 관계로 많은 설계 요소와 다양한 관련 기술이 필요하다. 이 모든 기술을 모두 알 수 없으므로 특정 기술 기반을 가진 사람들이 한 프로젝트에 모여 개발을 하고 그 중 충분한 경험과 깊은 지식을 갖고 있는 누군가가 아키텍트라는 역할로 소프트웨어 개발을 이끌고 나간다.

아키텍트라는 일반 비즈니스 로직 개발자들의 개발 자유도를 통제하기 위해 '메커니즘'이 라는 것도 만들어 놓고, 마음이 안 놓이는지 '프레임워크'라는 것도 만들어 놓아 오직 비즈니스 로직 구현에 몰두할 수 있게 만들어 놓는다. 비즈니스 로직 개발하는 것도 '패턴'이라는 이름으로 개발하는 방식을 제한하는 경우가 많다. MDA에서는 이러한 부분을 프로파일로 작성한다. 이 프로파일을 바탕으로 비즈니스 분석 모델을 빌드하면 실행 컴포넌트가 나오게 된다.

현재도 제품으로 출시되어 있는 MDA 솔루션들이 있다. 필자가 보기엔 어떤 솔루션은 무늬만 MDA인 것도 있고 실제 MDA의 비전에 상당히 근접한 솔루션도 있었는데 모델링 도구에서 모델을 만들고 OCL을 작성해 놓으면 놀랍게도 실제로 시스템이 작동했었다. 다만 일부 표준을 지원하지 않아 문제가 되긴 했지만 말이다.

하지만 언젠가는 MDA가 우리 피부에 와 닿을 정도로 현실화 되리라 믿는다. 초창기 컴퓨팅 환경에서 고급 언어로 일컫는 3세대 언어들은 그 당시 개발자들에겐 환상적인 꿈의 개념이었다고 한다. 기계어와 어셈블리 수준에서 프로그래밍을 하던 그들에게는 자연어와 비슷한 모양의 개발 언어는 얼마나 환상적으로 보였을까? 지금 우리는 이와 같은 과도기를 겪고 있다고 필자는 생각한다. 독자 여러분들도 그런 시대를 대비하여 하루빨리 모델링 능력을 한껏 끌어올리기 바란다.

자바 웹 애플리케이션 모델링
만약 개발 프로세스가 비슷하다면 그 프로세스를 적용하여 개발하는 모든 애플리케이션 모델링의 방법은 거의 유사하다. 웹 애플리케이션이라고 해서 별다르게 특이한 것은 없겠지만 웹 애플리케이션의 특성상 몇 가지 짚고 넘어갈 부분이 있다. 사실 엄밀하게 말 하면 웹이라는 특성도 있지만 자바의 특성으로 인해 모델링 방법이 약간 달라지는 수준으로 볼 수 있다. 특히 현 엔터프라이즈 컴퓨팅 환경은 다 계층 분산 시스템이므로 계층과 분산에 관한 부분의 모델링이 강조된다.

또한 사용자 웹 인터페이스 모델링도 중요한 부분으로 생각할 수 있다. 웹 페이지의 특성상 HTML이라는 제약으로 인해 약간 특이한 점이 있다. 웹 페이지 모델링에서 폼(form)과 같은 구성요소는 스테레오 타입(stereo type)으로 정의하여 모델링을 한다. 또 웹 페이지는 화면의 흐름에서 해당 정보를 갖고 다니거나 세션을 참조하기 때문에 어디까지 해당 정보를 갖고 다닐지 세션을 어떻게 참조할 지가 모델링의 주요 포커스가 된다. 일단 개요 수준은 여기까지 하고 실제 예제를 보면서 모델링이 어떻게 진행되는지 살펴보자.

분석 모델
좀 전에도 언급했듯이 웹 애플리케이션도 역시 다른 시스템과 마찬가지로 요구사항 파악 및 분석으로부터 시작한다. 요구사항을 위한 모델링으로 유스케이스를 이용하는 것은 이미 앞에서 이야기했고 특집 4부에서 자세히 다룰 예정이므로 유스케이스 자체에 관한 설명은 하지 않겠다. 또한 웹 애플리케이션이나 다른 기술을 이용한 애플리케이션이나 요구사항과 분석 모델링의 기법은 사실 별반 다르지 않다. 분석 모델은 구현과 관계가 없는데 분산(distribution), 영속성(persistency), 커뮤니케이션(communication), 인증(authentication)과 같은 메커니즘과 상관없는 개념적인 모델이기 때문이다. 즉, 유스케이스 모델을 기반으로 분석관점으로 유스케이스 실현(realization)을 표현한 객체모델이 바로 분석 모델이다.

<그림 8> 분석 클래스 다이어그램의 예

<그림 8>은 분석 모델의 유스케이스 실현(realization)에 참여하는 분석클래스 다이어그램이다. RUP에 의하면 분석클래스는 <<boundary>>, <<control>>, <<entity>> 등 세 가지 종류의 스테레오 타입을 갖는다. 원래 스테레오 타입은 태기드 벨류(tagged value)와 함께 UML의 확장 메커니즘의 한 종류이기 때문에 필요하다면 추가적인 스테레오타입을 정하여 사용하여도 무방하다.

사용자 웹 인터페이스 모델링
사용자 웹 인터페이스 모델링 부분은 웹 애플리케이션을 개발하면서 모델링 하기에 가장 껄끄러운 부분이 아닌가 생각된다. Jim Conallen은 그의 저서 『Modeling Web Application Architectures with UML(2002)』에서 웹 인터페이스 모델링을 자세히 설명하고 있다. 한마디로 요약하자면 웹 애플리케이션 모델링을 위한 다양한 '스테레오 타입'을 만들어 냈다.

필자가 보기에는 실무 프로젝트에서 과연 이런 노가다 작업을 할 필요가 있을까 생각이 되지만 순수 모델링 관점에서 볼 때 웹 페이지를 모델링 하기 위한 작업으로서 의미는 있다고 본다. <그림 9>는 그가 제안한 웹 페이지를 모델링 예제이다. 참고하기 바란다.

<그림 9> Jim Conallen이 제안한 웹 인터페이스 모델링 예

실무 프로젝트에서 Jim Conallen이 제안한 방법으로 모델링 하는 경우를 본적은 없고 필요한 부분만을 발췌해 많이 단순화시킨 형태로 모델링을 진행한다. 사용자 인터페이스 모델은 화면 흐름, 참여 화면의 설명, 화면 이동 맵, 화면 클래스 다이어그램, UI 프로토타입 등으로 구성된다. 이중 UML로 모델링 하는 몇 가지를 소개하겠다.

화면 흐름
화면 흐름의 경우 비즈니스 로직 처리와는 전혀 관계없이 오직 해당 작업을 수행하기 위한 화면 관점에서 모델링을 한다.

<그림 10> 시퀀스 다이어그램으로 표현한 화면 흐름도

화면 이동 맵
화면 이동 맵은 각 화면의 구성 요소를 클래스 다이어그램으로 표현한 것이다.

<그림 11> 클래스 다이어그램으로 표현한 화면 이동 맵

웹 애플리케이션을 위한 프레임워크 모델링
자바를 이용하여 웹 애플리케이션을 개발하게 되면 우선 여러 제약 사항들이 나타나게 된다. 앞서 이야기한 페이지 제어 문제, 세션 처리 문제, 데이터 처리 문제, 다양한 프로토콜의 처리 문제, 까다로운 보안 문제, 웹과 분산 컴포넌트간의 동적 호출 문제, 예외처리 문제, 웹 애플리케이션과 레거시(legacy)와 인터페이스 문제 등 각 메커니즘에 관해 다루어야 할 부분이 많다. <그림 12>는 각 메커니즘을 고려한 일반적인 웹 애플리케이션의 시스템 구성도이다.

<그림 12> 일반적인 웹 애플리케이션의 시스템 구성도

이 그림에서 메커니즘으로 정리해야 할 주요 부분은 여러 가지가 있지만 그 중에서 Web Server와 Web App Server와의 연동 부분으로 JSP에서 어떠한 Action을 통해 EJB 비즈니스 컴포넌트를 수행시키고자 하는 부분과 데이터 처리하는 부분, 타 시스템과 인터페이스 기술을 만약 웹 서비스로 할 경우 웹 서비스 클라이언트와 웹 서비스 서버간의 메커니즘 등을 들 수 있다. 몇 부분에 대한 메커니즘에 대하여 모델을 보면서 살펴보자.

JSP에서 Action을 통해 비즈니스 컴포넌트를 수행하는 부분
이 부분의 경우 프리젠테이션 레이어와 비즈니스 레이어간의 느슨한 결합을 지원하기 위해 J2EE 패턴 중에 '비즈니스 델리게이트 패턴(business delegate pattern)'을 사용할 수 있다. 원래 비즈니스 델리게이트 패턴은 비즈니스 서비스 컴포넌트와 일어나는 복잡한 원격 통신에 관련된 사항을 클라이언트로부터 숨기기 위해 사용한다. 비즈니스 델리게이트에 관해 자세한 것을 알고 싶으면 자바 웹 사이트나 코어 J2EE 패턴을 참고하면 된다.

다음에 소개할 프로젝트의 상황 때문에 약간 변경이 되었는데 비즈니스 델리게이트는 원격 통신에 관한 처리와 함께 해당 프로젝트의 사정으로 EJB 비즈니스 컴포넌트와 일반 자바 클래스 형태의 비즈니스 컴포넌트, 그리고 웹 서비스를 통해 타 시스템의 비즈니스 컴포넌트도 함께 수행해야 했다.

따라서 비즈니스 컴포넌트가 EJB건 일반 자바 클래스건 SOAP 기반의 통신이던 간에 클라이언트는 그저 비즈니스 컴포넌트 아이디와 비즈니스 컴포넌트 쪽에 넘겨줘야 할 파라미터만 알고 있으면 되도록 설계하였다. 해당 비즈니스 컴포넌트는 비즈니스 델리게이트에서 리플렉션을 이용해 동적으로 수행되도록 했다.

<그림 13> 비즈니스 델리게이트 부분의 클래스 다이어그램

<그림 13>에서 BusinessMapper의 역할은 XML 형태의 컨피규레이션(Configuration)로 빠져있는 파일을 읽어 웹 애플리케이션이 기동할 때 캐싱하게 된다. 이 컨피규레이션 파일에 담겨있는 정보를 바탕으로 BusinessMap 클래스가 모델의 역할을 하게 되는데 BusinessMapper는 BusinessMap을 자신이 갖고 있는 Map에 담아 갖고 있는다. 또한 BusinessMapper는 JVM상에 오직 하나만 존재해야 했으므로 '싱글턴 패턴(singleton pattern)'을 적용하였다. 이것을 실제로 구현하기 위해서 필자는 자카르타의 커먼스(commons)의 다이제스터(digester)를 이용하여 구현했다.

<그림 14> 비즈니스 델리게이트 부분의 시퀀스 다이어그램

외부 시스템과 연동 부분
웹 서비스의 SOAP을 이용한 통신을 하기 위해서는 웹 서비스 RMI 리모트 인터페이스를 상속한 인터페이스를 상속한 스텁(stub)을 통해 비즈니스 컴포넌트를 수행하게 된다. 이 부분은 위에서 설명한 비즈니스 델리게이트 부분과 아주 관련이 깊은데 일반 자바 비즈니스 컴포넌트의 경우 같은 머신의 동일 컨텍스트에 존재하므로 스트럿츠 액션(Struts Action)에서 비즈니스 델리게이트를 통해 바로 부르면 비즈니스 델리게이트는 그저 리플렉션을 통해 해당 비즈니스 컴포넌트를 실행하면 된다.

하지만 웹 서비스 비즈니스 컴포넌트인 경우는 다른 머신에 존재하는 컴포넌트이므로 원격 호출에 대한 부분 동일한 방법으로 서비스의 위치를 찾아낼 수 있도록 J2EE 패턴 중에 '서비스 로케이터 패턴(service locator pattern)'을 이용하였다. 이 부분 역시 약간의 변형이 가해졌는데 다이내믹 바인딩 시간이 비교적 길기 때문에 서버에서 받아온 스텁을 웹 애플리케이션 서버 쪽에 풀(pool)을 하나 만들어 스텁을 한번 가져온 이후 풀에 넣어놓고 다음 호출부터는 풀에서 꺼내어 쓰도록 설계하였다. 필자는 이런 설계를 구현하기 위해 자카르타 커먼스에 있는 풀(pool)을 이용하였다. EJB의 경우도 이와 거의 유사하다. <그림 15, 16>은 웹 서비스 부분의 클래스 다이어그램과 시퀀스 다이어그램이다.

<그림 15> 웹 서비스 부분의 클래스 다이어그램

<그림 16> 웹 서비스 부분의 시퀀스 다이어그램

데이터 처리 부분
필자가 이 부분을 설계하고 구현해 놓고 보니 사실 메커니즘이라기보다는 일종의 유틸리티성의 헬퍼 클래스 성격이 짙었다. 주요 특징 중에 하나는 SQL 쿼리를 소스코드에 직접 넣지 않고 XML 형식의 파일로 뽑아내었다는 것이다. 데이터베이스를 통해 데이터를 주고받아야 하는 비즈니스 컴포넌트 입장에서는 쿼리 아이디와 Object 배열에 담긴 파라미터를 QueryHelper에 넘겨주면 쿼리를 실행하고 결과를 넘겨준다.

결과는 여러 형태로 받을 수 있는데 종류로는 Map 형태, Map의 리스트 형태, 특정 Bean 형태, Bean의 List 형태로 Object 객체에 담아 받아 올 수 있다. 필자는 이런 설계를 구현하기 위해 자카르타 커먼스에 있는 디비유틸(DBUtil)을 이용하였다. <그림 17, 18>은 데이터 처리 부분의 클래스 다이어그램과 시퀀스 다이어그램이다.

<그림 17> 데이터 처리 부분의 클래스 다이어그램

<그림 18> 데이터 처리 부분의 시퀀스 다이어그램

컴포넌트 모델링
컴포넌트 모델링의 과정은 컴포넌트를 식별하고 그것의 인터페이스를 정의하고 컴포넌트의 내부는 어떻게 작동하며 구현을 어떻게 할 건지에 대한 종합적인 과정이 필요하다. CBD(Component Based Development)에는 많은 이견들이 있지만 이 글에서는 현존하는 기법을 통해 컴포넌트 식별 방법을 아주 간략하게 설명하고 컴포넌트 모델링과정이 어떻게 진행되는지 궁금해 하는 독자들을 위해 각종 다이어그램을 보면서 살펴보기로 한다.

컴포넌트 인터페이스 정의
어찌됐던 간에 컴포넌트를 식별했으면 인터페이스를 정의한다. 이 단계에서 정의되는 컴포넌트 인터페이스는 Business Facade의 성격으로 각 인터페이스를 명세화 한다.

<그림 19> 컴포넌트 인터페이스

컴포넌트 내부 설계
컴포넌트 내부 설계는 앞에서 정의한 인터페이스를 구현하기 위한 설계를 일컫는다.

<그림 20> 컴포넌트 내부 설계 클래스 다이어그램

EJB 컴포넌트 설계
EJB 컴포넌트 자체에 관한 설계로 <그림 21>은 Customer 비즈니스 컴포넌트의 워크플로우를 관리하고 클라이언트 요청에 대해 Facade 역할을 수행하는 Stateless Session Bean 에 대한 클래스 다이어그램이다.

<그림 21> EJB 컴포넌트 설계 클래스 다이어그램

유능한 모델러로 거듭나기
지금까지 개발 프로세스 측면에서 바라본 모델링과 자바 웹 애플리케이션을 위한 모델을 보았다. 사실 아주 많은 내용을 한정된 페이지에 집어넣으려고 하다 보니 주마간산 격이 되어버렸는지도 모르겠다. 모델링이라는 것이 개인적인 주관과 경험에 많은 영향을 받는 것은 사실이다.

필자는 지금까지 모델링과 관련된 프로젝트와 교육을 여러 번 해보았지만 아직까지 잘된 모델링은 바로 이런 것이라고 꼭 집어 이야기하기 힘들다. 다만 어떤 모델은 보면 왠지 푸근하고 어떤 모델은 왠지 어색하다는 느낌이 든다. 그 느낌이 뭐라는 것도 아직 정확히 모르겠지만 말이다. 모델링을 잘 하기 위해 어떻게 트레이닝을 해야 할까라고 고민하던 중에 필자가 겪었던 짧은 경험이 떠올랐다.

올해 여름에 비슷한 일을 하는 사람들과 함께 어느 업체에 방문했던 적이 있었다. 날씨는 아주 더웠지만 차 안은 에어컨을 켜서 시원했다. 문제는 주차장에 차를 세워놓고 몇 시간 동안 뜨거운 여름 뙤약볕 아래 차를 세워놔야 하므로 일을 마치고 돌아올 시점에는 차 안이 불가마 찜질방 수준으로 될 거라는 것은 충분히 예상할 수 있는 상황이었다. 그때 누군가 “그늘 아래 세워놔야 할 텐데”라고 하자 어떤 사람이 “그늘 오리엔티드(Oriented)구먼”이라고 응수했다. 그러자 또 누군가 “오리엔티드는 아니지, 오리엔티드는 왠지 그늘 자체가 되어야 하는 듯한 느낌을 준다고, 그늘 드리븐(Driven)이 맞지 않을까? 드리븐은 목표를 향해 돌진하는 느낌을 주자나? 결국 우리는 지금 그늘을 찾아가고 있는 거고”라고 했다. 이때 필자는 “음～ 정확히 말하자면 그늘 베이스드(Based)가 어울릴 것 같은데? 우리는 그늘을 베이스로 깔고 앉아야 하잖아?”라고 주장하여 모두들 웃으며 짧은 말장난을 했던 기억이 있다.

예로 든 이야기에서 그 상황에 오리엔티드(Oriented)나 드리븐(Driven), 베이스드(Based)라는 용어의 의미에 정확하게 맞았는지는 일단 논외로 하겠지만 실제 모델링을 하는 상황에서는 이와 같은 일들이 자주 일어난다. 모델링을 하는 사람들은 그 상황에 맞는 의미를 정확히 파악하여 모델을 만들기 위한 노력을 끊임없이 해야 하고 특히 용어, 단어의 의미, 그리고 단어간의 관계에 대하여 고민해보고 정확하게 짚고 넘어가는 버릇을 들여야 하지 않을까 싶다.

우리가 지금 주제로 이야기하는 UML을 이용한 모델링이라는 것이 결국 모호성이 아주 높은 자연 언어를 몇 개의 모델링 요소로 표현하는 작업이기 때문에 소프트웨어 모델링을 할 때만 모델에 대하여 생각하는 것이 아니라 실생활 속에서 패러다임에 맞게 사고하는 지속적인 훈련을 해야만 한다.

앞에서 MDA에 관하여 짧게 언급 했지만 아마 앞으로 소프트웨어 개발에 있어서 모델은 점점 더 중요한 요소로 부각될 것이다. 필자도 그렇고 이 글을 읽는 독자 여러분도 지속적인 수련을 통해 더욱 유능한 모델러로 거듭나리라 믿는다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

인생은 뒤돌아볼 때에만 이해할 수 있지만..
우리는 앞으로 가면서..살아야 한다..

　　　　　　　　　　　- 키에르 케고르 -

7년 전 필자는 UML이라는 단어조차 들어본 적 없었다. 국내에서는 그래도 꽤 잘하는 비주얼 베이직 프로그래머라고 자부했는데 당시 봇물같이 쏟아지던 약어들에 질려 UML이라는 알파벳 세 글자로 이루어진 '신규어'에 별 신경을 쓰지 않았다.

몇 년이 지난 후, 필자도 객체지향이라는 무림 강호에 몸을 던지지 않을 수 없는 시점에 이르러서, 그 몇 년 전에 들었던 UML이라는 것이 무림에 출사표를 던지기 위한 필수 무공이었다는 사실을 깨달았다. 그리고 그 이름도 원망스러운 디자인 패턴!

비주얼 베이직이라는 한물간 초식에서는 ‘꽤’ 강자라고 생각했던 필자는 객체지향이라는 드넓은 무림에 발을 들여서는 초고수가 되어야 되겠다는 결심을 했고, 높은 내공을 쌓기 위한 필수 비급이라는 UML과 디자인 패턴을 익히기 시작했다. 그러면서 필자가 느낀 것은? ‘초고수는 아무나 하는 것이 아니구나’하는 것이었다.

필자는 디자인 패턴에 한이 맺힌 사람이다. 디자인 패턴을 며칠 밤씩 새워 가면서 공부할 때 느낀 고통은 이루 말할 수 없다. 가끔씩 감동을 느낄 때도 있었지만 대부분의 경우가 이해하기 힘들고 패턴에 따라 프로그램을 작성하기는 더 힘든 경우가 많았다.

결국은 객체지향에 대한 기초 지식이 부족하기 때문이라는 사부님의 조언을 듣고는 HTDP와 SICP 등의 패러다임 입문서, 리스코프나 메이어 등의 객체지향 이론서 등을 짧은 영어 실력에 열심히 번역하며 읽었다. 객체지향 디자인을 제대로 이해하기 위해서는 UML은 필수사항이었고, UML에 관련된 책도 열심히 사서 읽었다. 그때부터 필자의 머릿속에는 이상한 고정 관념이 생기기 시작했다.

결국은 내공이 좀 쌓이고, 디자인 패턴과 UML을 어렵지 않게 응용해서 프로그램을 짤 수 있는 수준이 되었을 무렵에, 필자는 병적으로 디자인 패턴과 UML에 집착하기 시작했다. 래쇼날 로즈 등의 케이스 툴을 사용해 설계를 하고 있으면, 화면에 보여 지는 여러 예쁜 아이콘들을 보면서 ‘아, 나는 살아 있구나’하는 존재의 가치를 느끼곤 했다.

그렇게 열심히 익힌 기술들을 이용해서 프로그램을 열심히 개발하던 어느 날 밤, 필자는 어떤 의문을 가지게 되었다. 왜 내가 동작하는 코드를 개발하지 않고 그림을 그리고 있을까? 프로그램을 작성하는 목적이 잘 동작하는 프로그램을 작성하는 것이지 출력해서 벽에 걸어놓을 미술 작품을 만들고자 하는 것이 아니지 않은가?

필자는 플라톤의 동굴의 비유에 비견될 만한 엄청난 진리를 깨달았다. UML이든, 디자인 패턴이든 꼭 필요한 부분에만 사용하면 되는 것이고, 프로그램을 작성하기 전 개념을 잡거나 최종적으로 정리하는데 유용한 도구, 특히 UML은 개발자들 간의 상호 커뮤니케이션에 아주 유용한 도구가 될 수 있다는 것을 알게 되었다.

필자는 UML 케이스 툴을 만드는 업체에 근무하는 개발자 몇 명을 잘 알고 있다. 대학원에서 꽤 실력을 쌓아 어렵게 취업한 후배들인데, 업체에 근무한지 3개월쯤 되면 이런 말을 한다.

1년쯤 근무하면 이런 말들을 한다.

3년쯤 근무한 후배는 이런 말을 한다.

악순환의 반복이랄지, 디자인 패턴과 UML이 남긴 폐해랄지, 이런 현상은 매년 계속된다.

아키텍트 입장에서 UML
필자가 조선 업계에서 근무할 때, 새로운 시리즈를 시작할 경우(배는 하나의 설계로 여러 척을 찍어낸다) 먼저 모형을 만들어서 테스트를 하는 것을 본 적이 있다. 모형을 만들어 수영장 같은 곳에서 테스트를 해 보고 실제로 배가 목표한 만큼의 성능을 낼 수 있는지 테스트 한다. 또한, 배를 설계할 때 거대한 캐드 시스템으로 설계한 후 파도와 바람 등에 견딜 수 있는지를 테스트한다.

배를 만들 때는 엄청난 비용과 시간이 소모되기 때문에 모형을 만들거나 컴퓨터상에서 수치로 테스트한다. 컴퓨터로 만들건, 정말 모형을 만들건, 그렇게 만들어진 것을 모델이라고 하고, 대부분의 경우 모형을 만드는 비용이 실제 배를 만드는 것보다 비용이 훨씬 적게 소모되므로 모델 테스트를 한다. 이런 모델을 만들어 테스트 해보는 과정을 ‘모델링’이라고 부른다.

배를 지을 때도 선실의 세부 구조나 엔진의 동작들은 모델링하지 않는다. 모델링이라는 것은 어떤 것이 실제로 잘 동작하는지를 알아보려고 만드는 것이다. 실제 크기대로 배를 지어 바다에서 항해해 가며 파도와 바람의 영향을 최소화하거나 풍랑에 버틸 수 있을지를 테스트 해 본다는 것은 비용이 너무 많이 드는 일이다. 모델을 만드는 이유는 모델을 만드는 비용이 실제 물건을 만드는 것보다 훨씬 적은 비용으로 설계가 제대로 되었는지 알고 싶어서이다.

소프트웨어를 만들 때도 이와 같은 이치가 적용된다. 하지만 소프트웨어를 설계할 때 사용하는 이 UML이라는 것은 조선 엔지니어나 토목 엔지니어들이 모델링을 하기 위해 사용하는 미니어처나 캐드 모델과 비교해 볼 때 훨씬 비효율적이고 테스트하기 곤란하다. UML 다이어그램에는 다른 공학 모델과 비교해 보았을 때 확고한 시험 기준을 세우기도 곤란하고 평가를 내릴 때도 주관적인 관점이 상당부분 차지할 수 밖에 없다.

조선이나 건축에서 모델을 만드는 것은 실제 배나 건물을 짓는 것과 비교할 때 비교도 할 수 없을 만큼의 적은 비용이 들지만, 소프트웨어를 설계하는 입장에서 실제 프로그램을 작성하는 것과 UML을 사용한 설계를 비교했을 때 비용적인 측면에서나 생산성적인 측면에서나 그렇게 차이 나지 않는다.

사실, UML을 사용해서 테스트하는 것보다 소스코드를 직접 수정하는 것이 비용이 훨씬 적게 들고 손쉬운 경우도 있다. 개발자의 입장에서는 더욱 그러하다. 하지만 UML을 사용해야 하는 이유는 무엇일까? 잘 사용하면 비용 절감의 효과를 가져 올 수 있고, 포괄적인 설계가 가능하다는 것이다.

UML 다이어그램이라는 것은 앞서 이야기 했듯이 다른 공학에 비해 모델을 사용했을 때 실제 건축물(소프트웨어에서는 실제 동작하는 코드)을 작성하는 것보다 비용이 명확하게 절약되는지가 명확하지 않다. 필자는 실제 프로그램을 작성하는 것보다 UML 다이어그램을 작성하는 것이 훨씬 시간이 많이 드는 경우를 허다하게 봤다(사실 그렇게 하지 않으면 제대로 된 프로그램이 나오지 않는 경우가 대부분이다).

UML 다이어그램은 세부적인 설계를 하기 보다는 포괄적인 설계를 구성하였을 때 그 전체적인 비용의 절감 효과를 가져 올 수 있다. 세부적인 그림을 UML 다이어그램으로 표시하기 보다는 전체적인 그림을 UML 다이어그램으로 표시하고 세부적인 표현은 코드로 작성하는 등의 탄력성 있는 설계 운영이 전체를 UML로 설계하는 것보다 훨씬 나은 효율을 가져올 수 있다는 것이다.

실제로 아키텍트들의 설계는 이러해야 한다. 아키텍트들은 UML 다이어그램을 세부적으로 표현하기 보다는 전체적인 그림을 그리고, 그린 그림이 실제 소프트웨어로 동작했을 때 바르게 동작할 수 있을 것인지를 개발자들과 토론하고 설계를 수정한다.

필자는 프로젝트를 시작할 때 전체 소프트웨어의 요구사항을 격자 형태로 나누고 각 부분을 개개의 개발자들에게 할당하는 경우를 본 적이 있다. 큰 부분으로 나뉜(이 큰 부분으로 나누는 것조차 PM급의 아키텍트가 하지 않는다. 그러한 큰 부분은 대 부분의 기업형 응용 프로그램이라면 부서별 또는 업무별로 자연스럽게 할당되어 있기 마련이다) 업무 분할대로 각 개발자가 ER-Diagram부터 클래스 다이어그램, 컴포넌트 다이어그램까지 작성하는 경우를 실제로 본 적이 있다.

큰 수정 없이 프로젝트가 진행되어 다행이었지만, 한 부분이라도 어긋난 부분이 있었다면 엄청난 비용이 소모되었을 것이다(사실 그렇게 작성된 프로그램은 전체적인 소프트웨어의 부품이 유기적으로 동작하는 소프트웨어가 아니고 각 부품이 각기 따로 동작하는 작은 프로그램들의 집합일 수밖에 없고, 실제로도 그러했다).

개발자 입장에서 UML
자, 이제 개발자 입장에서 UML을 생각해 보자. 실제로 개발자가 UML 다이어그램의 모든 부분을 다 알아야 하는가? 개발자가 프로그램을 작성하기 위해서 UML의 메타 모델을 모조리 이해하고 각 프로젝트와 다른 케이스 도구들에서 쓰이는 스테레오 타입들을 다 알아야 한다는 것이다.

필자는 여기에 반대한다. 필자는 주로 닷넷 기술들을 가지고 소프트웨어를 작성하고 강의하고 컨설팅을 수행하는데, 사실 닷넷 기술은 너무 빠른 속도로 변화하고 있다. 곧 출시될 비주얼 스튜디오 2005와 MS-SQL 서버 2005는 닷넷 프레임워크 2.0을 기반으로 하는데, 닷넷 프레임워크 2.0은 1.1 버전과는 상당히 다른 모습을 보여준다.

C#이나 비주얼 베이직 닷넷 같은 언어적인 측면에서만 봐도, 겉으로 보기에도 제네릭(Generic)이 포함되는 등 상당히 많은 부분이 변하였다(필자는 이 부분에서 상당히 불만이 많다. MS는 이런 부분을 발표만 하고는 다른 이야기가 없다.

여러 잡지에 소개되는 글들을 봐도 이런 기능들이 추가되었다. 이런 내용만 있지 실제적으로 테스트 해 볼 수 있는 코드를 제시하거나 근본적인 변화를 이야기하는 경우는 드물다). ASP.NET 2.0만 해도 ASP.NET 프레임워크가 전체적으로 변화한 부분도 몇 군데 있을 뿐더러 사용자 정의 컨트롤이 상당히 많이 추가되고 변화함으로 인해서 새로 익혀야 할 부분이 늘어났다.

ADO.NET도 마찬가지다. 개발자의 부담은 가중되고 실제적으로 필드에서 사용되어야 할 코드와 컨트롤들의 사용법을 익히는 것과 UML의 전체적인 내용을 학습하는 것 사이에서 갈등하게 된다.

디자인 패턴도 이럴 때 부담이 된다. 개발자 누구나가 디자인 패턴과 UML을 사용할 수 있어야 하고 열심히 학습해야 한다는 것은 알고 있지만, 현실적으로 당장 사용하여야 할 요소 기술과 끝이 보이지 않는 기반 기술을 사이에 두고 갈등하다 보면 당연히 당장 사용하게 되는 요소 기술 쪽으로 치우칠 수밖에 없다.

이럴 때 누군가에게 "UML을 조금 알아야 되겠는데 어떤 책을 봐야 되겠습니까?"라고 물어보면 그 누군가는 책을 산더미처럼 던져주고(보통 이런 경우에 이유 없이 원서를 권하는 경우가 많다. 안 그래도 바빠 죽겠는데 원서가 포함된 책 뭉텅이를 받은 개발자의 입에서는 욕 빼고는 나올 것이 없다) 이 책의 내용들을 거의 다 숙지해야 제대로 쓸 수 있다는 교과서의 화신 같은 이야기를 하게 된다. 사실, 이 말은 격무에 시달리는 개발자들에게 UML을 공부하지 말라는 이야기와 동일하게 밖에는 안 들린다.

개발자들은 프로젝트에 투입될 때 UML의 어떤 부분을 알아야 하는가? 사실 UP의 모든 부분을 다 안다는 것은 업무 형태와 업무량으로 볼 때 거의 불가능 하다고 볼 수 있다. 그렇다고 UML을 전혀 모르는 상태에서 개발에 투입되었다면 그 개발자의 앞길은 십자가를 지고 골고다 언덕을 오르는 예수님의 모습처럼 보일 것이 뻔하다. UML을 효과적으로 사용하기 위한 효과적인 길을 알아보자.

의사소통 수단으로서 UML
초보 개발자라면, 우선 UML의 표기법에 익숙해져야 한다. 이렇게 생긴 아이콘은 클래스고, 이렇게 생긴 화살표는 실제화고(물론 실제화를 이해하기 위해서는 객체지향을 이해하여야 한다는 원론적인 이야기를 피하기는 힘들다. 산 너머 산이다) 이렇게 생긴 화살표는 집단화이고 등의 표기법(Notation)을 익히는 것이 중요하다. 개발은 혼자 하는 것이 아니기 때문이다. UML은 개발자들끼리 설계 개념에 대한 의견을 주고받을 때 굉장히 편리한 도구로 사용될 수 있다. UML의 표기는 매우 명확한 의미를 전달해 줄 수 있다.

개발 경로로서의 UML
UML은 기업 형 소프트웨어를 작성할 때 구조의 개발 경로를 작성할 때 유용하다. PM이 이렇게 개발해라 하는 지시를 내리면 사실 그 지시라는 것은 추상화 된 개념이라서 바로 프로그램으로 옮기기가 곤란한 경우가 대부분이다. 이런 경우, 어떤 객체를 먼저 작성하여야 하고 어떤 객체는 어떤 객체에 의존하고 하는 식의 로드맵이 필요한데, UML은 이런 도구로서도 훌륭하다.

개발 경로로서 UML 다이어그램을 활용하려 한다면, 클래스 다이어그램, 객체 다이어그램, 시퀀스 다이어그램, 협력 다이어그램을 읽을 수 있고 작도할 수 있어야 한다. UML 표기법을 완벽하게 익힐 필요까지는 없을 테고, 적당히 다른 사람과 상호 통신할 수 있을 정도의 수준이면 충분하다.

스테레오 타입 등은 잘 알아야 하지 않느냐고? 처음엔 잘 몰라도 된다. "<<", ">>"가 붙은 기호는 스테레오 타입이라고만 아는 것으로 충분하다. UML이라는 것은 쓰다보면 이해가게 되어있는 아주 신기한 물건이다.

언제 다이어그램을 그려야 하는가?
UML은 도구일 뿐 그 자체가 목적이 되어서는 안된다. UML이 목적이 되는 경우도 물론 있긴 하다(대부분의 경우 UML이 목적이 되는 경우는 작성된 소프트웨어가 클라이언트 또는 감리에 의해 검수 받을 때뿐이다). UML을 남용하는 것은 소프트웨어 개발에 큰 걸림돌이 될 수 있다. 하지만 남용하지 말고 아껴서 사용한다면 큰 도움을 줄 수 있다. 예전의 ‘약 좋다고 남용 말고..."라는 표어는 UML에서 그대로 통한다.

다이어그램을 그려야 하는 경우 어떤 지침을 따르는 것이 좋을까? 모든 개발자들이 설계에서 특정한 부분의 구조를 이해해야 할 경우 다이어그램을 그리는 것이 좋다. 그림이 완벽할 필요는 없다. 모든 개발자들이 이해했다고 생각되면 그만 그리면 된다.

개발자들 간에 구조에 대한 분쟁이 일어날 경우 그림을 그리고 그림을 판독할 수 있는 중재자를 구할 때. UML 다이어그램은 아주 명확한 의미를 전달 할 수 있기 때문에 같은 생각이지만 다른 말을 통일시켜주는 역할을 할 수 있다. 새로운 아이디어를 떠올리고 그 아이디어를 주위 개발자 또는 상급자에게 칭찬받고 싶을 때 UML 다이어그램을 작성한다. 말로 떠드는 것보다 한번 보여주는 것이 200%의 효과를 발휘한다.

“백문이 불여일견”일 필요가 있을 때 UML 다이어그램을 작성한다. 그리고 마지막으로 클라이언트에게 ‘있어 보이는’ 문서를 보여줘야 할 필요가 있을 때 작성한다. 부차적인 설명이 없이도 다들 이해하리라 믿는다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

쟈스민 : 겨울철에는 빛이 많이 필요하겠지만, 여름철이나 봄가을의 따사로운 햇살은 차광이 살짝되는 밝은 실내가 좋은 환경입니다. 물은 보통정도 관리를 요하고, 추위에는 엄청 약합니다.

로즈마리 : 조금 건조한 환경을 좋아하며 빛을 엄청 좋아하는 식물입니다.
빛이 약하면 웃자라거나 힘없이 쳐지며 향기도 줄어들게 되죠. 과습은 치명적이니 주의하시고, 약산성의 토양이 좋습니다.

산세베리아 : 공기정화로 요즘 인기가 엄청 좋지요. 산세베리아도 약산성 또는 중성토양이 좋으며, 건조한 환경이 좋습니다. 습기가 차면 절대 안되구요. 빛을 좋아합니다. 실내적응력도 좋지만, 되도록 밝은곳에 두시길...

이상을 종합하면, 실내 가장밝은곳에 두고 키우심 되겠지요.
쟈스민이나 로즈마리와 같은 종보다는 오히려 아이비, 산세베리아 등과 같은 관엽이 좋지않았을까 생각해봅니다. 스킨답서스도 좋고.. 양치식물류도 좋구요 ^^

UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 알아보고 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠파장에 대해 알아본다. 또한 UML 2.0에서 개발자들이 주목해야 하는 세부 내용도 간단히 검토해 보자.

UML 2.0의 실로 엄청난 중요성을 미리 알고 대비할 것인지, 뒷짐 지고 좀 더 지켜볼지는 이번 글을 보고 판단해 주기를 바란다.

필자는 지난 2004년 마이크로소프트웨어 8월호에 MDA 관련 글을 기고하던 당시부터 지금까지 필자의 소속 회사가 지난 10여 년간 전문적으로 개발해 오던 인적 자원 관리(HRM) 시스템에 대한 획기적인(?) 개선 방안으로 MDA 기반의 시스템 개발을 추진하고 있다. 필자가 본격적으로 UML 2.0을 검토하기 시작한 것도 8월을 전후해서였다.

그러나 회사에서 표준으로 사용하는 모델링 도구 제작 업체에서는 4개월 전만 해도 UML 2.0을 지원하지 않았고, MDA 패러다임을 표방하면서도 아쉽게도 그 요체인 UML 2.0은 그저 각종 문서나 자료들을 통해서만 접할 수 있었다. 인사 비즈니스 프로세스 개선 작업(BPI)과 같은 초기 설계 작업은 UML 1.4 기반으로 추진해야 했고, 올 연말로 예정됐던 도구 공급사의 차기 버전을 기대해야 하는 상황이었다.

그러던 얼마 전, 필자는 해당 업체로부터 UML 2.0을 충실히 지원하게 된 새 버전의 케이스 도구를 입수했다. 비록 필자가 이미 여러 책이나 자료들을 통해 UML 2.0을 검토했었음에도, 막상 본격적으로 UML 2.0 지원 모델링 도구를 설치하고 작업을 착수하려던 그 순간의 첫 느낌을 말로 하자면 막막함 그 자체였다.

그 모델링 도구의 새로운 버전이 완전히 개편된 새로운 사용자 인터페이스로 구성됐으며 내부적으로도 상당한 기술적인 패러다임 전환이 있었던 것도 한 원인이었겠지만, 무엇보다도 근본적으로 UML 2.0이 내포한 그 가능성과 확장성에 대한 놀라움과 설렘이 교차하면서 만들어낸 미묘한 흥분과 두려움이었다는 것이 적절한 것 같다. 1620년 메이플라워호를 타고 미지의 땅 아메리카에 첫 발을 내디뎠던 이주민들의 마음이 이렇지 않았을까?

UML의 사회적 파장
UML 2.0 발표와 더불어 개발자들이 주목해야 하는 세부 내용을 살펴보기 전에 우선, UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 통해 향후 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠 파장에 대해 미리 가늠해 보는 시간을 가져 보기로 하겠다.

IT 시장 변화에 주목하자
이 시대 소프트웨어 산업에 종사하는 사람이, 딴 세상에 사는 사람(beings in heaven)이 아닌 이상, 자본주의 시대를 살아가는 현대인으로서 공급과 수요를 결정하는 시장 논리로부터 자유로울 수는 없다.

우리는 종종 뛰어난 기술력을 갖추고 있음에도 망하는 반면, 특별한 기술력을 가지고 있지 않음에도 번창하는 사람이나 기업을 종종 목격하곤 한다. 즉, 기술력이 곧 성공을 의미하지는 않는다. 마찬가지 논리로, UML 2.0이 아니라 그 어떤 뛰어난 기술이 존재한다 하더라도 IT 시장에서 그 기술력을 필요로 하지 않거나 수용할 수 없다면, 그 기술력의 시장 가치는 무의미할 수밖에 없다.

2000년을 전후해서 전세계적으로 Y2K 문제가 사회적 문제로 부각되고 시스템의 대공황 사태가 예고되던 시절, 아이러니컬하게도 당시 소프트웨어 산업에서는 사양길로 접어들었던 프로그래밍 언어의 전문가들이 국내의 IMF 사태와 맞물려 고액 연봉으로 대접 받으면서 해외로 진출했던 일이 기억난다. 역시 기술의 가치(technology value)는 시장 원리(market behavior)에 의해 결정될 수밖에 없음을 인정하지 않을 수 없다.

그런 관점에서 UML 2.0이 공식적으로 공표되는 전후의 소프트웨어 산업계 판도를 살펴보는 것은 의의가 있다. 세계적으로 이미 프로그램 개발 도구 시장은 그 성장세가 둔화됐고, 모델링 도구는 빠른 속도로 보편화되어 가고 있다. 지난 몇 년간 일어났던 IT 업계의 큰 사건들을 살펴보면 그러한 사실을 쉽게 확인할 수 있다.

이를테면 예전에는 비싸게 판매하던 개발 도구를 점차 저렴하게 행사 가격으로 판매한다거나, 개발자 저변 확산이라는 명목 하에 학교나 학원을 중심으로 무료로 배포하고 있다. 심지어는 이클립스 등과 같은 막강한 개발 도구를 오픈소스로서 인터넷을 통해 무료로 배포하고 있다.

몇 년 전 세계적인 소프트웨어 업체인 MS에서는 비지오(Visio)라는 2D 전용 도구 개발 업체를 인수했고, IBM은 세계적인 모델링 도구 전문 개발 업체인 래쇼날을 인수합병했으며, 연이어 볼랜드에서는 투게더를 사들였다. 한편, 국내외 UML 관련 포럼이나 협회들에서는 앞다퉈 UML 관련 인증 제도를 만들어 발표하면서 그 인지도를 넓혀 가기 위한 대대적인 작업을 벌이고 있다.

UML 인증 제도의 필요성이라든지, 인증 제도 자체의 신빙성이나 효용성에 대해 논하기 이전에, 어떠한 사상이나 개념이 제도화 되는 과정을 거치고 있다는 사실은 그 사상이나 개념이 해당 분야에서 도입기(intro)와 성장기(growth)를 거쳐 성숙기(mature)에 진입하고 있음을 암시하는 것이다.

표준화의 숨은 뜻
UML을 논하면서 표준화(standardization)라는 키워드를 빼놓을 수 없다. UML이 발표되기 전에 국방이나 MIS 분야 엔지니어들에게 친숙한 IDEF라든지 DFD, ER 혹은 Petri nets 등과 같은 정형 기법(formal method)으로 통칭되는 수많은 표기법(notation)과 지원 케이스 도구들이 존재했음에도 불구하고(참고자료: [1]번혹은 [2]번등), UML은 가장 단기간 동안 소프트웨어 공학 분야에서만큼은 빠른 속도로 사실상의 표준(de-facto)의 위치를 확보했다. 언뜻 생각해 보면 UML이 여타 표기법들을 교통정리해 준 안도감(?)이 들 수도 있겠지만, 겉으로 잘 드러나지 않는 그 내막에는 무서운 음모(?)가 도사리고 있다.

표준화 작업에 주도적인 역할을 수행하는 업체들이 왜 그토록 천문학적인 자본을 투자하면서 공개적인 표준화 작업에 동참하는 것일까? 여러 가지 복합적인 이유들이 있을 수 있겠지만, 결론적으로 표준화 경쟁이다.

유명한 예로, 1970년대부터 시작됐던 빅터(Victor)의 VHS 방식과 소니의 베타 방식으로 대표되는 비디오 표준 전쟁을 들 수 있고, 최근에는 유럽과 미국을 중심으로 벌어지고 있는 위성방송 표준화 전쟁을 들 수 있다. 표준화 전쟁에서의 승패는 곧 기업의 운명을 좌우하는 것이다.

표준화의 이면에는 높은 진입 장벽을 통해 허가 받지 않은 침입자(intruder)를 봉쇄하려는 무서운 저의가 자리 잡고 있다. 시야를 좀 더 넓혀 보면, 의사나 판사, 회계사 등. 통속적인 표현으로 소위 ‘사’자로 끝나는 직업들에 대한 사회적 가치관을 살펴보면 쉽게 이해할 수 있다.

사람 몸을 열어서 칼질하고, 같은 인간으로서 다른 인간을 판단하고, 숫자 가지고 씨름하는 직업이 산업혁명 이전에는 별볼일 없는 직업이었다. 인류의 보편적인 가치관으로 판단하더라도 결코 즐거운 일이 될 수 없음에도 불구하고 전세계적으로 공히 가장 선호하는 직업이자 사회적으로도 가장 대접받는 직업이 된 현실에 미루어 짐작해 보면, 왜 그토록 세계적인 소프트웨어 업체들이 표준화를 통해 높은 진입 장벽을 구축하고 제도화에 전념하는지 그 이유를 충분히 이해할 수 있다.

어려운 시험을 통과하지 않고 누구라도 일정한 요건만 갖추면 수행할 수 있는 일반적인 직종 중의 하나라면 그렇게들 동경하는 직종이 됐겠는가? UML 2.0이 경제적으로나 사회적으로 주목 받는 이유 중의 하나는 바로 그러한 맥락에서 비전문인과 전문가를 구별하는 높은 장벽(?)을 쌓을 수 있는 재료(material)를 확보하고 토대를 마련했다는 점에서 의의가 있는 것이다.

주목해야 할 UML 2.0의 핵심 메커니즘
1997년 11월 UML 1.1로 시작된 OMG의 표준화 노력은 2001년 5월 UML 1.4 발표와 더불어 부분적인 개정 작업(minor version upgrade)의 막을 내리고, 대대적인 수술 작업을 거쳐 2004년 연말을 전후로 드디어 그 실체를 드러내었다.

그 동안 쟁쟁한 세계적인 소프트웨어 벤더들간의 보이지 않는 이해 관계(?)에 얽혀 2002년 말로 예정됐던 최종 발표 시한을 2년여를 연장하면서 이제서야 그 대단원의 막이 마무리되고 있다. 향후 UML 2.0의 일정은 명실상부한 국제 표준(de jure)으로 자리매김하기 위해 ISO 설계 표준으로 추진 중인 것으로 알려져 있다.

UML 2.0이 주목 받는 가장 중요한 이유는 무엇일까? 처음 세상에 나오고 나서는 여기저기서 수많은 비판을 받았지만, 그것은 UML이 어떠한 플랫폼이나 도메인에도 의존하지 않고 소프트웨어 개발의 전 공정(SDLC)을 지원하는 방향으로 지향해왔다는 데에 그 원인을 찾을 수 있다. 즉, 요구사항 획득으로부터 마지막 테스트까지 모두 지원하는 표기법으로서 진화해 왔다는 것이다.

그리고 점진적으로 UML 2.0부터는 실행 모델(executable UML)이라는 기법을 수용함으로써, 소프트웨어 공학에서 궁극적으로 염원하던 분석 설계(analysis & design)와 실제 구현(implementation) 간의 차이(chasm)를 극복하는 성과를 보였기 때문이다.

OMG의 UML 2.0에 대한 제안요청서(RFP)의 주제이자 현재 채택된 명세서 초안은 크게 4가지의 영역으로 분류된다. CASE 도구 벤더들간의 모델 호환성 문제를 다루고 있는 다이어그램 호환(Diagram Interchange) 영역과 모델 수준에서의 요소(elements) 제어 및 제약 문제를 다루고 있는 OCL(Object Constraint Language) 영역, UML뿐만 아니라 OMG가 주관하는 각종 표준의 통합과 정의에 활용되는 메타 모델 수준의 기본 구조체(constructs)를 명시하고 있는 하부구조(Infrastructure), 그리고 메타 모델을 기반으로 사용자 수준에서 모델을 활용하여 시스템의 구조(structure)와 행위(behavior)를 정의하고 있는 14개의 다이어그램을 정의하고 있는 상부구조(Superstructure)로 분류할 수 있다.

UML 2.0의 본질을 제대로 이해하려면 핵심인 하부구조로부터 차근차근 살펴보는 것이 순서이겠지만, 지면과 주제를 고려할 때, 일반인들이나 설계자들이 UML 2.0을 처음 대면하는 경우 가장 먼저 관심을 가지게 되는 UML 구조체(user-level constructs)인 상부구조로부터 이야기를 풀어가는 방식을 택하기로 하겠다.

<그림 1> UML 2.0 표준 다이어그램

*빨간 밑줄: 새롭게 추가된 다이어그램, 녹색 밑줄: 명칭이 변경된 다이어그램

상부 구조는 크게 6개의 다이어그램으로 구성된 구조형 다이어그램(Structural Diagram)군과 7～8개의 다이어그램으로 구성된 행위형 다이어그램(Behavioral Diagram) 군으로 분류할 수 있는데, 각 군의 대표적인 복합 구조 다이어그램(Composite Structure Diagram)과 순차도(Sequence Diagram)를 중심으로 그 특징과 의의를 살펴보도록 하겠다.

이어서 UML 2.0의 기반을 설명하고 있는 하부구조의 의미는 무엇인지, 그리고 실제 설계 작업에서 하부구조의 접근법은 어떠한 방식으로 활용하게 될 것인지 논의하기로 하겠다.

상부구조 - 구조형 다이어그램
일명 아키텍처 다이어그램(architectural diagram)이라고도 불리는 복합 구조 다이어그램(composite structure diagram)은 UML의 핵심 다이어그램인 클래스 다이어그램의 변형된 형태이다. 이는 시스템 구조 설계에 있어 또 다른 핵심 축으로 평가 받고 있으며 가장 주목 받는 다이어그램 중의 하나이다.

복합 구조 다이어그램은 기본적으로 시스템 혹은 컴포넌트의 내부 구조(internal structure)를 명시적으로 중첩시켜 표현하고 있으며, 시스템 아키텍처의 보다 섬세한 분석과 설계 사상을 담을 수 있게 된 점이 가장 큰 매력으로 꼽을 수 있다.

그렇다면 왜 복합 구조 다이어그램이 주목받는지, 그리고 복합 구조 다이어그램은 왜 탄생하게 되었으며, 향후 어떠한 용도로 활용하게 될까? 보는 시각에 따라 의견을 달리 할 수 있겠지만, UML 1.x은 근본적으로 OOAD 수준의 설계 사상을 표현하기에 최적화된 표기법으로 평가되어 왔다.

UML 1.x에도 비록 컴포넌트 다이어그램이라는 것이 있기는 했지만, 실제 너무 빈약한 문맥(semantics)으로 인해 별로 활용되지 못했으며, 강경한 컴포넌트 신봉자들이나 대용량 시스템 혹은 전체 시스템을 통합적으로 표현하기 원했던 아키텍처 전문가 진영 개발자들에게는, 그저 객체 옹호론자들이 제시하는 옹색한 명분(?)에 지나지 않았다. 사실 UML 1.x 자체에도 명시하고 있듯이, 컴포넌트 다이어그램은 몇몇 다이어그램들과 더불어 클래스 다이어그램에 일종의 간단한 확장 메커니즘을 통한 단순한 관점(view) 변경 수준에 지나지 않았다.

비즈니스 컴포넌트에 관심이 많았던 컴포넌트 신봉자들의 경우, UML 1.x의 스테레오타입(stereotype)등의 확장 메커니즘을 통해 그럭저럭 UML 1.x과의 관계를 유지하면서도 BPM이라는 포괄적이고 확장된 별도의 비즈니스 컴포넌트 표기법을 병행하며 UML 1.x의 미비한 부분을 채워 나갔다.

아키텍처 전문가 진영에서는 상황이 조금 달랐는데, 대다수의 아키텍처 전문가 진영에서 관심을 가지고 있던 임베디드 혹은 리얼타임 도메인에서는 단순히 UML 1.x 정도의 확장 메커니즘으로는 그들이 필요로 하는 아키텍처를 통한 시뮬레이션 등과 같은 시스템의 섬세한 분석 및 설계라는 목적 달성이 거의 불가능했고, 그러한 목적 달성을 위해 UML의 확장 메커니즘을 활용한다는 것은 차라리 자신들만의 특정 영역에 필요한 표기법을 자체 정의하여 사용하는 것이 훨씬 경제적이었다는 것이다.

왜냐하면 이미 아키텍처 전문가 진영에서는 UML 1.x가 발표되기 이전에 광범위하게 수많은 ADL(Architectural Description Language)과 관련 시뮬레이션 도구들이 개발되어 활용되고 있었으며, 굳이 UML에 순응하는(compliant) 방안을 모색하기 위해 UML을 연구하고 고민할 시간적 여유나 명분이 없었던 것이다.

그러나 그러한 두 진영에서 근본적으로 해결하지 못한 결정적인 문제는 자신들이 독자적으로 발전시켰던 표기법 중에 어떠한 것도 명실상부한 사실 표준(de-facto)으로 합의하지 못했다는 것이다. 가령, 아키텍처 전문가 진영에서 필요로 하는 시스템 시뮬레이션 기능을 구현하는 데 사용하는 정형 기법의 경우 동일한 도메인에서조차 연구소나 익숙한 기법에 따라 서로 달리 정의하고 필요한 시뮬레이션 도구를 개발해야 했다.

국제적인 공동 작업은 말할 것도 없이 국내에서 서로 다른 연구기관이 공동 작업을 수행하기 위해서도 사전에 일정한 표준 정형 기법을 합의하고 정립한 후 과제를 수행해야 했으며, 최종적으로 통합하는 과정에서는 결국에 모델 수준에서의 통합을 포기하고 구현 수준에서 테스트를 통해 통합하는 방식을 따라야 하는 문제점을 내포하고 있었다.

덧붙여 두 진영에서 해결하지 못한 결정적인 문제 중의 하나는 실제 구현(code)에 필요한 낮은 추상화 수준의 설계에 대해서만큼은 어설픈 UML 1.x의 메커니즘만한 수준의 방안을 제시하지 못했다는 것이다.

UML 2.0에서 새롭게 등장한 복합 구조 다이어그램은 바로 지금까지 앞서 살펴 본 아키텍처 전문가 진영으로 대표되는 임베디드 혹은 리얼타임 도메인의 핵심 개념이자 도구였던 SDL(Specification Description Language)을 수용하여 탄생한 다이어그램이다.

<그림 2> UML 2.0 복합 구조 다이어그램 예

UML을 잠시라도 살펴 본 경험이 있는 개발자들이라면, 복합 구조 다이어그램의 개략적인 형태만을 보고서도 쉽게 그 특징을 이해할 수 있을 것이다. 즉, 복합 구조 다이어그램은 매우 직관적인 형태를 취하고 있으며, 기존의 UML 1.x에서 단순한 패키지 개념의 서브시스템 내부를 구성하고 있는 클래스 다이어그램으로만 표현이 가능하던 시스템 내부 구조를 보다 섬세하게 설계할 수 있게 됐다.

그렇다고 <그림 2>와 같이 대부분의 UML 2.0을 기반으로 한 샘플들처럼 임베디드나 리얼타임 도메인과 같이 상대적으로 소프트웨어의 비중이 작은 단위 시스템이나, 특정 MIS 분야의 단위 서브시스템의 내부 설계에만 국한되어 복합 구조 다이어그램을 활용하겠다고 생각한다면, UML 2.0의 본질을 제대로 이해하지 못하고 있는 것이다.

복합 구조 다이어그램의 형태는 앞서 언급한 아키텍처 전문가 진영에서 아키텍처를 표기하는데 가장 많이 활용하는 아키텍처 스타일인 C&C(Component & Connector) 뷰 타입(view type)과도 일맥상통하는데, 복합 구조 다이어그램을 활용하고자 하는 모델의 추상 수준을 높이면 대규모 시스템의 아키텍처도 매우 유용하게 설계할 수 있게 된다.

<그림 2>에서 벤딩머신(VendingMachine)으로 되어 있는 부분을 인사시스템이라 정의하고 내부 부분(parts)들을 그것을 구성하고 있는 단위 시스템으로 정의하게 되면, 외부 인터페이스를 통해 회계시스템(AS)이나 고객관리시스템(CRM) 등과 주고받아야 할 데이터나 정보를 명시적으로 설계에 반영할 수 있을 것이다.

바로 설계자가 의도하는 어떠한 추상화 수준의 모델이라도 UML 2.0의 복합 구조 다이어그램은 보다 섬세하게 설계할 수 있도록 일관된 문맥(context)과 의미(semantics)를 제공하고 있는 것이다.

상부구조 - 행위형 다이어그램
UML 2.0 상부구조 중 구조형 다이어그램은 말 그대로 구조적인 혁명을 꾀했다면, 행위형 다이어그램 군에서는 시스템의 동적 설계를 제대로 반영하기 위해 기존의 행위형 다이어그램 군 소속 다이어그램의 의미(semantics)를 보강하고 정제함으로써, 진화 방식을 선택했다는 표현이 적절할 것 같다.

그 근거로서 앞서 복합 구조 다이어그램으로 대표되는 구조형 다이어그램에서 수용한 SDL의 경우와는 다르게 UML 1.x에서 이미 수용하던 MSC(Message Sequence Chart) 개념을 UML 2.0에 와서는 전폭적으로 수용하여 순차도(Sequence Diagram)를 중심으로 행위형 다이어그램들의 유기적 결합 통로를 확보함으로써 시스템의 모델 수준에서의 논리적인 실행을 그대로 설계에 반영할 수 있는 발판을 마련했다.

<그림 3> UML 2.0 순차도의 예

<그림 3>에서 보는 바와 같이 UML 2.0 순차도의 가장 두드러진 특징은, 기존의 UML 1.x에서 지원하지 못했던 시스템의 분기, 참조, 병렬 실행 등과 같은 세세한 부분들까지도 지원이 가능하도록 중첩된(nested) 표기법 체계를 설계 기법으로 도입했다는 사실이다.

MSC와 같은 기법에 익숙한 개발자들에게는 언뜻 보기에 별로 특이할 것이 없어 보일지 모르지만, 중요한 사실은 UML 2.0을 표준 표기법으로 수용함으로써 어떠한 비즈니스 도메인이나 기술 영역에서도 <그림 3>의 순차도 뿐만 아니라 UML 2.0의 다른 다이어그램들과 유기적인 연결고리를 가지고 활용함으로써 거의 무한대에 가까운 표현 수단을 확보할 수 있다는 사실이다.

UML 2.0 상부구조 중 행위형 다이어그램의 갱신에 대해 많은 관심을 가지는 사람은 임베디드 혹은 리얼타임 진영에 종사하고 있는 개발자들이겠지만, 기존의 비즈니스 프로세스 모델링 분야에서 종사하던 개발자 진영도 깊은 관심과 기대를 가지고 있다.

필자 또한 비즈니스 프로세스 모델링과 관련하여 행위 형 다이어그램의 특성과 최적 방안을 모색하고 있는데, 동일 비즈니스 도메인에서조차 개별 기업마다 그 특성과 비즈니스 프로세스 처리 방식이 천차만별인 문제를 해결하고자 등장했던 워크플로우 엔진 혹은 설계 시스템(workflow engine or system)과 같은 전문적인 도구의 기능을 충분히 대치할 방안이 마련된 것으로 평가되고 있다.

하부구조 - 메타 모델
소프트웨어 공학 분야에서는 이런 속설이 있다. 자신의 분야에서 메타 모델 기반의 접근을 하게 되면 하나의 논문이 된다. 매일 고객들과 씨름하면서 현장에서 일하는 개발자들에게는 먼 나라 이야기처럼 들리고, 현실적으로는 일정 규모의 연구소 혹은 학교에서나 다루어질 만한 주제로 치부됐던 것이 사실이다.

UML 2.0 하부구조(Infrastructure)는 일반적으로 UML 2.0을 지칭할 때 생각하는 UML 2.0 상부구조뿐만 아니라 OMG의 또 다른 메타 모델 집합인 MOF, CWM 뿐만 아니라 미래의 새로운 표준을 정의하기 위해 심혈을 기울여 정의한 메타 모델이다.

OMG에서 처음 메타 모델 4계층 개념을 발표했을 때에는 그저 개념적인 내용으로만 인식하지 못했지만, UML 2.0의 실체가 드러나고 그것을 지원하는 케이스 도구들의 기능들이 메타 모델 기반 설계 방식을 지원함으로써, 이제는 메타 모델이라는 주제가 현장에서조차 피해갈 수 없는 현실 문제로 다가올 것이다. 그러므로 이제는 메타 모델 4계층 개념을 충분히 이해하고 응용하는 노력을 기울일 필요가 있다.

<그림 4> OMG 4계층 메타 모델 예

글의 주제와 지면 관계상 메타 모델에 대한 깊이 있는 논의를 하지는 못하지만, <그림 4>의 예로 간단히 살펴보자. 시스템 분석가나 설계자들이 일반적인 모델링 케이스 도구를 통해 특정 도메인 시스템을 설계한다고 했을 때의 메타 모델 수준(level)이 바로 사용자 모델을 도식하게 되는 M1 수준이다.

M2 수준은 그러한 UML 기반의 설계를 가능케 하는 어트리뷰트, 클래스, 인스턴스 등과 같은 모델 요소를 정의하는 메타 모델이며, UML 2.0의 하부구조는 바로 위 4계층 메타 모델 관점에서 M2 수준의 UML 메타 모델이 된다. M3 수준에 위치한 MOF(Meta Object Facility)는 M2 수준에 속한 메타 모델을 정의하는 메타메타 모델이 된다.

참고로 CWM(Common Warehouse Metamodel)은 M2 레벨이며, MOF의 내부 구조는 추상화된 UML 하부구조와 동일한 방식으로 정의하고 있다. 자세한 사항은 OMG UML 2.0 Infrastructure, 7. Language Architecture를 참조한다.

앞에서 살펴 본 바와 같이 OMG에서 UML 2.0 관련 제안요청서(RFP)를 제기한 목적은 단순히 UML 2.0을 체계적으로 정리하고자 한 것이 아니라, OMG의 또 다른 표준인 MOF와 CWM 및 미래의 새로운 표준을 체계적으로 정의하기 위한 용도로 제기됐던 것이다. 여기서 우리가 주목해야 할 사항은 UML 2.0 하부구조에 대한 제안요청서를 통해 제기한 또 다른 목적이다.

그것은 바로 지금까지 M1 수준에서 UML을 활용하던 사용자들이 보다 수월하게 M2 수준에서 UML을 커스터마이징하여 활용할 수 있는 메커니즘을 제공하는, 즉 이원화된 메커니즘을 제공하여 사용자들이 유연하게 특정 기술 도메인이나 비즈니스 도메인에 최적화된 방식으로 설계를 수행할 수 있도록 하자는 데 그 취지가 있었다.

그 핵심이 바로 UML 프로파일(UML Profiles)이다. 지금 UML 2.0 작업과 동시에 진행되고 있는 대표적인 기술 도메인 프로파일로는 우리들에게 친숙한 EJB 프로파일(Profile for EJB), 닷넷 프로파일(Profile for .Net)을 들 수 있다. 프로파일을 간단히 설명하면, 일종의 특정 기술이나 비즈니스에 적절한 커스터마이징된 확장 메커니즘을 사전 정의해 놓고, 추상화 수준이 서로 다른 모델들간의 전환(transformation)을 자동화시키는 핵심 메커니즘이다.

플랫폼 독립 모델(PIM: Platform Independent Model)로부터 특정 플랫폼 종속 모델(PSM: Platform Specific Model)로의 자동화된 전환이라는 MDA의 사상이 바로 대표적인 일례라고 볼 수 있다. UML 프로파일은 향후 MDA를 통해서 달성하려고 하는, 아니 궁극적으로 UML 2.0을 통해 달성하게 될 소프트웨어 공학의 핵심 화두인 소프트웨어 개발 생산성 향상의 핵심 메커니즘으로 평가 받고 있다.

만약 이 글을 읽는 개발자가 속한 관련 분야에 MIS 분산 시스템 개발의 사실 표준으로 통용되는 J2EE나 닷넷 등과 같은 개발 기술 표준 프레임워크가 존재한다면 다행스러운 일이다. 모델링 도구 벤더에서 제공하는 EJB 프로파일이나 닷넷 프로파일과 같은 기술 메타 모델은 그대로 활용하고, 관심 비즈니스 영역에 해당하는 표준 도메인 프로파일을 활용하거나, 독자적으로 정의해 설계 작업을 추진해 나갈 수 있기 때문이다.

하지만 최악의 경우 관련 분야에 기술이나 도메인 프로파일이 존재하지 않고, 더욱이 활용할 만한 케이스 도구조차 존재하지 않는다면 난감하다. 하지만 UML 2.0을 충분히 지원하는 범용 혹은 상용 케이스 도구를 통해 구현된 방식이나 기능을 살펴보면 놀랄 만큼 간결하다. 문제는 UML 2.0의 프로파일 방식과 같은 메커니즘을 이해하는 것이 아니라, 그 동안 개발자들이 간과해 왔던 문제, 가령 “해당 비즈니스 도메인을 제대로 이해하고 있었는가?” 등과 같은 근본적인 문제를 되돌아보는 계기가 될 것으로 생각된다.

어떻게 대처할 것인가
지금까지 UML 2.0 출시를 전후해서 전개되어 왔던 소프트웨어 산업계의 전반적인 흐름과 사회적 파장, 그리고 UML 2.0의 상부 및 하부구조의 핵심 메커니즘을 중심으로 간단히 살펴보았다. 그렇다면 과연 어디서부터 어떻게 UML 2.0을 시작할 것인가?

기본 원칙에 충실하자
우선 스스로에게 UML 1.4는 제대로 이해하고 활용해 왔는가라는 질문을 던져 보아야 한다. 필자의 경우 하는 일이 하는 일인만큼 UML 2.0이 발표되기 이전에도 자바나 비주얼 베이직 등과 같은 프로그래밍 용어나 주제에 비해 상대적으로 UML(1.x), OOAD, CBD, 방법론 등이라는 용어가 훨씬 낯설지 않았다.

당연히 주변에는 상대적으로 코딩보다는 현장에서 분석(analysis)이나 설계(design)를 전문으로 하거나, 학교나 학원 등에서 학생들을 가르치는 사람들이 많았지만 그 중에 UML 1.x 관련된 OMG 무료 명세를 제대로 살펴보았거나, 가까이 두면서 참조하는 사람은 찾아보기 어려웠다.

필자 가까이에 ‘UML 1.4 사용자 지침서’를 한글로 번역했던 분을 통해 확인해 보아도, 국내 출판사에서 출간한 책 부수로 미루어 UML 원문은 차치하고서라도 핵심 내용만을 추려서 발간한 그 UML 사용자 지침서마저 꼼꼼히 살펴 본 사람은 별로 보지 못한 것 같다. 필자도 예외는 아닌데, 돈이 없어서 혹은 원서이기 때문에라는 것은 이유가 되지 않았던 것이다.

그런데 UML 2.0이 공식 발표되는 이 시점에도 상황은 예전이나 별반 다르지 않은 것 같다. UML 2.0으로 공식 공표되기 전에 이미 오래 전부터 OMG에는 UML 관련 명세를 1.5의 형태로 인터넷에 배포하고 있었지만, 살펴본 사람은 찾기 어려웠다. UML 1.1이 처음 발표되던 시점에는 표기법으로서의 표준화 경쟁에서 판정승이 나지 않았던 때여서 그랬다고 하더라도, UML 2.0이 공표되는 이 시점에는 이미 국내외 많은 대학의 컴퓨터 관련학과에서 필수 과목으로 개설되었을 만큼 그 중요도와 필요성이 검증된 마당에 애써 그 사실을 외면하는 것은 더 이상 이유가 될 수 없다.

물론 지금까지의 현실은 그렇지 못했던 것이 사실이다. UML 전문가들마저도 UML 1.x의 설계 도구로서의 완성도가 받쳐주지 못했고, 무엇보다도 고객들도 유기적으로 논리적인 설계 모델을 기대하지 않았기 때문에 UML이라는 포장지를 가지고 피상적이고 개념적으로 대충 구색 맞추기식 설계 산출물을 만들어 주면 그만이었다.

그러나 앞으로의 상황은 그렇지 못할 것이다. 당장은 아니겠지만 UML 2.0 표기법이 소프트웨어 산업 시장에서 보편적으로 활용되고 국내외에서 하나 둘 그 무한한 잠재력과 가능성이 증명되어 그 시장 가치가 확연히 드러나기 시작하는 시점에는 우리 주변의 고객들 또한 단순히 보기 좋은 산출물 정도의 설계를 요구하지는 않을 것이다.

그렇다면 어디서부터 어떻게 준비해야 할 것인가? 그 실마리는 처음 접하면 이해하기 어렵고 복잡한 UML 2.0 관련 명세나 두꺼운 책에서 찾을 것이 아니고, 누구나 알고 있으면서도 충실하지 못했던 가장 기본적이고 원칙적인 원리를 고민하는 것부터 시작해야 한다.

원칙 하나, 도메인을 철저하게 분석하자
시스템을 설계한다고 했을 때, UML과 같은 설계 기법을 동원하여 작업하는 시스템 분석 및 설계자 그룹 외에 매우 중요한 역할을 수행하는 집단이나 개인을 가리켜 도메인 전문가 혹은 비즈니스 분석가라고 한다. 가장 이상적인 시스템 설계자는 두 가지 능력 즉, 해당 도메인에 대한 공인된 전문적인 지식을 가지고 있으면서 동시에 설계 능력을 고루 갖춘 인재일 것이다.

그러나 현장에서 그런 핵심 인재를 찾기는 어려운 것이 사실이다. IT 업계로만 보더라도 시스템 설계자와 개발자 간에 차이가 좀처럼 좁혀지지 않는데, 전혀 그 분야와 전공이 다른 비즈니스 전문가와 시스템 전문가 간에 느끼는 갈등은 말할 필요도 없다. 시스템을 설계해 본 사람은 누구라도 공감하겠지만, 시스템을 제대로 설계하려면 해당 도메인을 충분히 이해하고 철저하게 분석해야 한다. 그렇지 않으면 제대로 된 시스템을 설계할 수 없다.

시스템 설계자 입장에서 문제는 해당 도메인을 제대로 이해하기 위한 충분한 시간도 주어지지 않고, 나름대로 시스템 설계자가 충분히 이해한 것을 객관적으로 검증해 줄 만한 기준도 마련되어 있지 않다는 것이다. 설사 객관적 기준이 있더라도 그것은 현실적으로 거의 불가능하다는 것이다.

가령 회계 시스템을 설계하려면 회계사 자격증을 갖춰야 하는가? 물론 아니다. 그런데 우리는 주변에서 타의든 자의든 특정 도메인 시스템을 반복해서 설계하는 설계자의 경우 점점 해당 도메인에 대한 이해력이 높아지고, 회계사와 같은 공인된 자격증은 취득하지 못하더라도 나름대로 그 전문성을 인정받아 시장에서 높이 평가되는 경우를 보곤 한다.

비단 시스템 설계자에게만 해당되는 문제는 아니다. 조각조각 할당된 부분만 열심히 해야 하는 개발자에게도 비슷한 현상은 쉽게 찾아 볼 수 있다.

설계하고자 하는 해당 도메인에 대한 철저한 분석 없이는 일정한 추상화 수준을 유지한 유기적인 모델을 만들어 낼 수가 없다. 몇몇 책이나 발표 자료에서 설계 팁으로 이야기 하듯이 해당 도메인에서 반복적으로 등장하는 명사(nouns)를 클래스명으로 명명한다는 식으로 설계를 진행하다 보면 점점 헤어나지 못하는 미궁으로 빠져들게 된다. 결국에는 UML 2.0이라는 강력한 설계 도구를 가지고도 설계 따로, 코딩 따로라는 늪에서 벗어날 수 없다.

UML 표준화를 주도하는 OMG에 대해서 많은 사람들은 단순히 CORBA, ORB 등과 관련한 국제적인 기술 표준화 단체 정도로만 인식하고 있다. 하지만 앞서 주장한 도메인 지식 혹은 도메인 표준에 대한 중요성에 대해서는, 그러한 기술 표준화 단체로 출범한 OMG에서 2002부터 발족하여 추진하고 있는 DTF(Domain Task Forces) 위원회의 활동을 살펴보면 쉽게 이해할 수 있다.

이미 전략전술 통제(C4I), 재무(finance), 의료(healthcare), 제조(manufacturing), 우주항공(space), 통신(telecommunications), 운송(transportation) 등의 도메인을 필두로 그 표준화 작업을 진행 중에 있으며, 여러 표준화 단체들과 연합하여 다른 도메인으로까지 표준화 작업을 확장 중에 있다.

물론 아직까지 그 시도는 기술적인 관점에서의 접근이라는 한계를 크게 뛰어 넘고 있지는 못하지만 인터넷, 즉 IT 기술을 배제한 고전적 의미의 비즈니스는 점차 그 경쟁력을 잃어 가고 있는 현실을 생각할 때 OMG의 영향력은 쉽게 무시할 수 없는 것이 될 것이다.

원칙 둘, 모델의 추상 수준
사전적 의미로도 알 수 있듯이 모델은 본질적으로 어떤 특정 사물이나 현상에 비해 상대적으로 추상화되어 있는 무엇이기 때문에 똑같은 실체에 대한 서로 다른 모델은 서로 다른 추상화 수준(level of abstraction)을 가질 수밖에 없다.

<그림 5> 모델의 서로 다른 추상화 수준

<그림 5>를 보면 똑같은 자동차를 모델로 만든 것이지만, 상단의 자동차 그림(혹은 모델)은 추상화 수준이 높고 하단의 자동차는 추상화 수준이 낮다. 여기서 중요한 것은 추상화 수준의 높고 낮음은 상대적이라는 것이다. 우리가 UML에서 제시하는 여러 다이어그램을 가지고 모델을 제작한다는 것은 결국 목표하는 자동차나 건물 등과 마찬가지의 실체 즉, 특정 시스템 하나를 완성하기 위한 노력인 것이다.

즉, 설계 작업을 수행한다는 UML 1.4의 표기법을 동원하든 UML 2.0의 표기법을 동원하든 아니면 제3의 표기법을 활용하든 목표하는 시스템을 완성하기 위한 과정이지 다이어그램 혹은 표기법 자체가 목적이 되지는 않는다는 것이다. 이러한 똑같은 모델의 원리를 UML의 다이어그램을 가지고 설명할 수 있다. <그림 5>는 UML 1.4에서 제시하는 9개의 표준 다이어그램의 추상화 수준을 계량화하는 방안으로 방사형의 표로 도식해 본 것이다.

<그림 6> UML 1.4 다이어그램 추상화 분포

<그림 6>의 중앙에 위치한 지점을 설계자가 목적하는 목표 시스템의 코드 혹은 운영(run-time) 시스템이라고 한다면, 유스케이스 축에서 0.8으로 표시된 지점 정도의 추상화 수준으로 유스케이스를 작성한 것을 비즈니스 유스케이스라 할 수 있겠고, 0.4 정도의 지점 추상화 수준으로 작성한 것을 시스템 유스케이스라고 할 수 있을 것이다. 그렇게 가정해 본다면, 중앙에 가까운 지점의 추상화 수준으로 낮게 모델을 작성한다면 설계자가 목적하는 시스템은 보다 세세하게(detailed) 보이게 될 것이다.

유럽의 모든 길이 로마로 향하듯이, 어떠한 길(다이어그램)을 선택하더라도 종국에는 목적지(목표 시스템)에 도달할 수 있다. 하지만 각 다이어그램은 각자 목표하는 시스템으로 접근할 수 있는 추상화 수준의 한계를 가지고 있다.

가령, 유스케이스 다이어그램만을 가지고 시스템 설계를 완성할 수는 없는 것이다. 반면에, 클래스 다이어그램만 가지고 시스템 설계에 접근하다 보면 나무는 보고 숲을 보지 못하는 우를 범할 수 있다. 그러한 이유로 소프트웨어 설계에서 UML을 활용하여 목표 시스템을 설계할 때는 하나 이상의 다이어그램을 활용하게 된다.

대표적으로 많이 활용되는 다이어그램으로는 유스케이스, 클래스, 시퀀스 등을 들 수 있을 것이다. 문제는 여기서부터 시작 된다. 시스템 설계에 대표적인 3개의 다이어그램을 활용하든 아니면 9개의 다이어그램을 모두 활용하든 활용하는 다이어그램들이 각자 따로 존재하게 되는 것이다.

유스케이스 다이어그램 따로 클래스 다이어그램 따로 심지어는 동일한 시스템에 대한 유스케이스 다이어그램을 그리더라도 그리는 사람에 따라 서로 다른 추상화 수준(level of abstraction) 혹은 입도(granularity)의 유스케이스가 작성된다는 것이다. 이건 비즈니스 유스케이스니 이건 시스템 유스케이스니 하면서 무의미한 논쟁으로 치닫게 된다.

이러한 문제를 본질적으로 해결책하기 위해서는 그것이 UML 1.4이든 UML 2.0이든 각 다이어그램의 주된 용도(usage)와 목적(objectives), 그리고 그 한계를 충분히 이해하고, 각 다이어그램이 그러한 용도와 목적을 충족시키기 위해 제시하는 특성 표기법의 명확한 의미와 용도를 숙지해야 한다. 그 후에 활용하려는 다이어그램의 핵심 표기들 간의 추상화 수준에 대해 일관된 원칙(principle)을 우선 정립하고 설계 작업을 수행해야 한다.

가령 이러한 원칙 수립이 가능하다. 유스케이스 다이어그램을 통해 작성한 하나의 유스케이스를 하나의 활동도(Activity Diagram)로 도식하기로 했다면, 활동도의 활동(Activity)은 유스케이스 시나리오로 작성하는 사건 흐름(flow of event) 상의 단일 스텝(step)이라는 원칙을 설정하게 되면 일관된 설계 작업을 수행할 수 있다. 그러한 설계 전략을 위 <그림 6> 위에 상징적으로 표현해 보면, <그림 7>과 같이 도식할 수 있을 것이다.

<그림 7> 다이어그램 간의 추상화 수준 조정

지금까지 UML 1.4를 중심으로 모델의 추상 수준이라는 원리에 대해 살펴보았다. 그러한 모델의 추상 수준이라는 핵심 메커니즘은 본질적으로 UML 2.0이라고 해서 다르지 않다. 앞선 <그림 1>과 <그림 7>을 언뜻 비교해 보아도 UML 2.0에서는 표준 다이어그램의 개수로도 UML 1.4에 비해 수적으로 많이 늘어났으며(<그림 4>에서 빨간색으로 표시된 다이어그램), 이전부터 있었던 몇몇 다이어그램들은 명칭이 변경됐고(<그림 4>에서 초록색으로 표시된 다이어그램), 무엇보다도 전반적으로 모든 다이어그램들이 보다 섬세한 설계자의 의도를 반영할 수 있도록 세부적인 표기들이 많이 추가되고 세분화됐다. 즉, 사용할 수 있는 다이어그램 선택의 폭(width)이 넓어졌고, 설계자의 의도를 보다 정밀하게 반영할 수 있는 깊이(depth)도 깊어졌다.

원칙 셋, 모델 자체의 완성도를 높이자
앞서 소프트웨어 업계에서 최근 발생하고 있는 현상들을 통해 잠시 언급했지만, UML 관련 국내외 포럼이나 협회들을 중심으로 UML 자체 혹은 설계 능력 인증 제도가 점차 많아지고 있다. 필자가 인증 제도의 본질적인 목적이나 그 가치 자체를 부정하는 것은 아니지만, 올해 사회적으로 충격을 던져 주었던 대입 수능 시험에서의 대량 부정 사태라든지, 얼마 전부터 공공연하게 제기됐던 영어 관련 인증 제도 등에서 발생하고 있는 문제점 등에 비추어 UML 인증 제도에서도 충분히 발생할 수 있는 그 변별력 문제에 대해 우려를 감출 수 없다.

그러나 다행히도 UML 2.0이 가지고 있는 그 강력한 표현력(semantic expressiveness)과 섬세함(elements precision) 그리고 다이어그램들간의 유기적 연결성 지원(support for diagram interchange) 능력으로 인해 인증서를 가지고 있다고 들먹이지 않아도 모델 결과물 자체로 그 완성도를 검증(self verification)할 수 있다. 즉, 모델 결과물만으로도 충분히 설계자의모델링 역량을 충분히 증명할 수 있는기반을 제공하고 있는 것이다.

UML 2.0이 공식으로 발표되기 이전 특정 케이스 도구들을 중심으로 시도됐지만 UML 1.4의 제약으로 그 실효성(efficiency)을 의심받았던 코드 자동 생성(automatic code generation) 기능은 케이스 도구들이UML 2.0 엔진으로 교체함으로써 그 완성도를 높일 수 있게 됐다. 더 나아가 UML 2.0이 내포한 그 풍부한 표현력과 정교함은, 특정 플랫폼에 종속적인 코드를 생성해 내기 이전에 케이스 도구의 도움을 통해 모델들만을 가지고 사전에 시뮬레이션마저도 어려운 문제가 되지 않는다.

앞으로의 전망
지금까지 개발자들은 새로운 기술이나 제품이 출시되면, 여기저기서 화려한 수식어와 찬사로 밝은 미래를 전망하는 이야기에 너무나도 익숙해져 있다. 1997년 UML 1.1이 처음 세상에 나왔을 때도 마찬가지였다. 그런 맥락에서 단순히 UML 2.0이라는 새로운 패러다임에 무조건 주목하자고 주장하고 싶지는 않다. 실리에 밝은 국내외 소프트웨어 업체들과 협회들의 행보와 여러 가지 상황을 종합해 보아도 UML 2.0이 소프트웨어 산업계에 미칠 파장의 크기는 실로 엄청날 것으로 예상된다.

그것이 더 이상 거스를 수 없는 현실이라면 그러한 도전에 수동적으로 대처할 것인가, 아니면 능동적으로 대처할 것인가의 문제는 독자 스스로 선택할 문제이다. 혹시 이솝 우화에 나오는 거짓말하는 늑대 이야기에서처럼 중요하다는 말을 너무 자주 들어 개발자들이 UML의 중요성을 공허한 메아리 정도로만 치부하고 지나칠까 걱정될 뿐이다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다

출처 : http://monthly.chosun.com/board/view_content.asp?tnu=200405100065&catecode=B&cPage=1

「W 이론」의 창시자 - 서울工大 李冕雨 교수의 경고 理工系 기피 현상은 한국이 조선시대로 돌아가고 있다는 증거 근대화 시기의 理工系 선호는 예외의 시대 현상이었다 理工系 기피의 최종 피해자는 국민…있는 名門(서울大)도 없애겠다는 발상은 죽음에 이르는 病 李 冕 雨 1945년 개성 출생. 경기高·서울工大 섬유공학과 졸업. 美 미시간大 인간공학 박사. 서울工大 산업공학과 교수(1970~). 서울大 공학연구소 소장. 대한산업공학회 회장 역임. 저서로 「w이론을 만들자」, 「신사고이론20」, 「신창조론」 등. 상허대상(1993년), 세종문화상(1996년), 美 미시간大 100인의 우수박사상(1988년), 올해의 경기인 상(1993년), 미시간大 공대 우수동창상(1994년) 수상.   서울大는 관악산의 최고 대학  많은 사람들이 理工系(이공계) 교육의 위기를 얘기한다. 정확히 말하면 理工系의 위기가 아니라 대한민국의 위기다. 이건 아주 간단명료한 문제다. 살고 싶으면 이 문제를 해결해야 하고, 죽고 싶으면 지금까지 그랬듯이 그냥 놔두면 된다.     나는 1991년 「서울공대 白書(백서)」를 발간했다. 「서울대학은 국내 최고의 대학도 아니고, 세계 400위 안에도 못 드는 관악산의 최고대학」이라는 게 백서의 핵심 내용이었다. 지금까지 변한 것은 아무것도 없다. 서울대학은 지금도 관악산의 최고 대학일 뿐이다.     2002년 大選 때 서울大 폐지 이야기가 나왔을 때 나는 어안이 벙벙했다. 아니 관악산 골짜기의 골목대장밖에 안 되는 대학을 없애서 무얼 어쩌겠다는 것인가?     나는 「서울공대 白書」와 1992년에 펴낸 「W 이론을 만들자」에서 「오늘날 우리 공학교육의 위기는 5년 내지 10년 후 국가 전체의 위기로 냉큼 대두될 것이다」고 지적했다. IMF가 터지자 내 책을 읽은 많은 사람들이 『어쩌면 그렇게 족집게같이 예견을 했느냐』고 물었다. 그건 상식이 있는 사람이면 누구나 내다볼 수 있는 일이었다.     理工系 교육이 왜 국가위기를 진단할 수 있는 지표가 되는가? 이유는 간단하다. 국가 경제를 지탱하는 바퀴는 두 개다. 하나는 국가 경쟁력이고 하나는 가계부 작성이다. 돈을 잘 벌어야 하고, 번 돈을 잘 써야 하는 이치다. IMF는 벌이는 없고 가계부 작성도 엉망이었기 때문에 온 것이다.     IMF 외환위기 이후 가계부 작성을 투명하게 합리적으로 해야 한다는 사실을 우리는 뒤늦게 깨달았다. 엉망이었던 가계부 정리는 대충 끝났다. 구멍난 곳을 메우는 데 150조원이 넘는 돈이 들어갔다.     벌이를 하려면 기술이 있어야 한다. 「W 이론」에서 나는 세계 1등 기술만이 생존할 수 있다고 했다. 국제사회에서의 경쟁은 고스톱 판과 포커 판의 게임처럼 1등이 모든 것을 가져간다. 2등이나 3등은 家産(가산)만 탕진할 뿐이다.     당시에는 『도대체 무슨 얘기냐』는 사람들이 수두룩했지만, 이제 이 얘기에 이의를 제기하는 사람은 사라졌다. 예전에는 인구 1억 명이면 내수시장만으로 국가를 지탱할 수 있다고 했지만 요새는 인구가 문제가 아니다. WTO(세계무역기구), FTA(자유무역협정) 등 글로벌 네트워킹 때문에 인구가 10억 명이 넘어도 기술이 없으면 굶어야 한다.     우리나라는 과학기술 이외에 팔아먹을 것이 없다.     제주도를 天惠(천혜)의 관광지라고 하지만 1년에 비오는 날이 100일이 넘어 세계적인 관광지로는 부적격이다. 발리나 하와이에 가 본 사람들은 내 얘기에 금방 고개를 끄덕일 것이다. 관광국가로 먹고 살기에 우리의 문화유산은 너무 빈약하다.     벌이가 없으면 아무리 가계부를 잘 써도 소용이 없다. 우리가 돈을 벌 수 있는 원천은 과학기술뿐이다. 대한민국의 대학이 과학기술을 제대로 생산해 낼 수 있는 시스템을 갖추고 있느냐, 학생들이 과학기술을 제대로 배우고 있느냐는 우리나라가 5년 후, 10년 후 어디로 갈 것인지를 보여 주는 가장 중요한 지표가 될 수밖에 없다.     대한민국의 기업과 대학, 연구기관들은 세계에서 경쟁할 수 있는 源泉(원천) 기술을 연구 개발하고 있는가? 답은 너무나 절망적이다.     삼성전자가 핸드폰을 하나 만들 때 퀄컴에 지불하는 로열티가 판매가의 15% 정도다. 반도체를 만들려면 설비와 부품을 일본에서 모두 수입해야 한다. 앞으로 남고 뒤로 믿지는 장사다. 그것도 삼성전자의 얘기다.     정부는 「2만 달러 국민소득 달성을 위해 5大 성장전략 산업을 육성하겠다」고 한다. 독자적인 기술 없이 어떻게 5大 성장 전략 사업을 키우겠다는 말인가?       미련한 최후의 변절자들     지난해 서울공대생 23명이 사법고시에 합격했다.     적어도 100명에서 150명의 工大生이 머리를 싸매고 골방에서 법전을 외워대고 있다는 증거다. 아마 그것보다 더 많은 수의 학생들이 『나도 늦기 전에 고시공부를 해야 하지 않을까』 하며 마음의 갈피를 못 잡은 채 考試공부의 언저리를 헤매고 있을 것이다.     서울공대 학부생 5500명 가운데 10% 이상이 考試의 유혹에 시달리고 있다는 얘기다.     서울大 물리학과에 다니던 한 학생이 다시 大入 시험을 봐서 서울의대에 입학했다. 면접장에서 제자를 만난 물리학과의 한 교수는 기가 막혀서 『(수능시험에서) 물리 과목은 다 맞았겠지』라고 했다고 한다.     考試공부를 하고 있는 서울大 자연대 와 공대의 학생들은 고등학교 때부터 일찌감치 돈 잘 버는 의사·한의사·변호사가 되겠다고 작심한 아이들에 비교하면 미련한 「최후의 변절자」에 불과하다.     나는 이 제자들이 딱하기만 하다. 눈치 빠르게 일찌감치 돈 버는 쪽으로 갈 것이지 서울공대에는 왜 들어왔다는 말인가.     서울공대나 자연대학에 진학한 학생들은 모두 고등학교에서 수학과 과학을 특출나게 잘 했고, 과학기술을 연구해야겠다는 신념을 가졌던 친구들이다. 그런 아이들이 흔들리고 있다.     이유가 뭘까? 우리 사회가 『이공계 공부해야 이렇게 비전이 없는데 그래도 고집을 부리면서 理工系 공부를 계속 할 거냐』면서 이 아이들을 끊임없이 고문하고 있기 때문이다.     大田 대덕의 연구원들은 밤 12시까지 연구를 해야 한다.     왜냐하면 세계 최고의 연구자 학자들과 치열한 경쟁을 해야 하기 때문이다. 이들이 20代, 30代에 습득한 기술과 이론들은 순식간에 과거의 것이 되고 만다. 理工系 연구인력의 停年은 대부분 40代다.     理工系 인력은 과학기술의 발전 속도에 뒤지지 않기 위해 끊임없이 노력해야 한다. 그런데 이들을 기다리는 건 「사오정」이라는 운명이다. 과학기술 인력을 바라보는 우리 사회의 눈길에는 존경과 냉소가 뒤섞여 있다.     이들이 한국을 이끌어 가는 견인차라는 걸 어렴풋이 인식한다. 하지만 이들의 연구활동을 지탱하기 위해 무엇을 해야 할 지에 대해서는 생각하기 싫다. 국민의 이해부족과 낮은 지위와 보수 때문에 이공계 출신들은 절망의 늪에 빠져 있다.     이런데도 당신들은 자식들을 이공계에 보낼 것인가?     의대와 한의대에, 법과대학과 상과대학에 자녀들을 보내는 것은 인지상정이고 합리적인 판단이다. 개인차원의 합리적인 선택이 모여 사회차원의 非합리적 선택이 되는 현상을 미리 알고, 차단하는 것은 국가 지도자의 몫이다.       재벌 총수들 『공장이 없으면 파이낸싱이 안 되잖아』     두 재벌기업 총수에게 『왜 기술력도 확보되지 않은 공장들을 자꾸 늘려가느냐』고 물은 적이 있다. 두 사람의 대답이 똑같았다.     『李교수, 그러니까 理工系 출신들이 눈치 없다는 얘기를 듣는 거요. 공장이 없으면 파이낸싱이 안 되잖아』     두 총수가 이끌던 거대 재벌기업 두 개는 IMF 전후에 무너졌다.     그때 한 재벌 총수는 내게 이런 얘기를 했다.     『생산성 향상, 그거 별 의미가 없어요. 5~6% 이윤이 남는데 30% 생산성 향상시켜 봐야 기껏 2% 포인트 이윤을 더 남기는 겁니다. 공무원들하고 골프 치고, 술 먹고 해서 큰 프로젝트 하나 따오면 20%, 30% 이윤이 남아요. 로비 잘하는 게 생산성 향상시키는 것보다 열 배는 쉽게 돈 버는 일입니다』     공장을 세워서 은행 돈을 빌리고, 그 돈을 부동산에 투자하고, 덩치를 키워 정부의 특혜를 받고…. 그런 식으로 기업들은 살아왔다. 그 체질이 지금도 과히 많이 바뀌지 않았다. 서울大 법대와 상대를 나온 사람들은 재벌기업의 비서실, 기획실, 마케팅실에 근무하면서 정·관계에 포진한 동문들과 네트워크를 형성했다.     지금도 理工系 졸업생들은 『당신들이 중요하다』는 말만 듣지 계속 벽지 공장을 돌게 된다. 理工大 졸업생들의 좌절은 여기서 시작한다. 엔지니어들이 말도 못 하고 속을 끓이는 사이에 몇 년 후배인 法大·商大 출신들은 쭉쭉 승진을 한다.     理工系 졸업생은 승진에 한계가 있다. 경영진에 많이 기용되지를 못한다. 벽지의 공장에 처박혀 있으니까 「촌닭 같아서」임원으로는 못 쓰겠다는 것이다.     그래도 과거에는 엔지니어들에게 프라이드가 있었다. 공장에서 생산성을 향상시켰다고, 품질개선을 했다고 총수와 간혹 악수할 기회도 있었다.     1960년대, 1970년대에 기업들이 외국 기술과 기계를 도입하면, 영문 매뉴얼을 보고 가동시키는 일을 서울공대 출신들이 했다. 복잡한 영어 매뉴얼을 보고 다들 기겁을 하는데 그나마 서울공대생들이 그걸 해낼 수 있었다.     요즈음은 그 일을 외국에서 공부한 교포 출신들이 대체한다. 영어 실력이 서울공대생들보다 월등하기 때문이다. 기업 내부에서 『서울공대 나온 친구들이 기술을 알면 얼마나 더 아나, 교포 2세가 낫다. 미국에서 대학교 2학년 다니다가 왔다는데도 또랑또랑하고 매너 좋고, 아무나 만나도 섭섭하게 안 하고…』 이렇게 되는 것이다.       理工系가 아니라 理理系     왜 대학들은 이렇게 기술 경쟁력이 없는 공대생들을 양산하고 있을까?     서울工大는 물론이고 대다수 공과대학이 이론 교육에 치중한다.     강의 시간에 외국 이야기만 들으니 학생들은 감흥이 일지 않는다. 학생들이 『우리가 직접 실험하려면 어떻게 하면 됩니까』 하고 물으면 교수들은 『여기서는 못해』하고 의욕을 꺾어 버린다. 학생들은 교수들로부터 「너희는 안 된다」는 메시지를 계속 받는다.     서울工大 교수의 학위논문 80% 가까이가 이론이다. 理工系가 아니라 理理系(이이계)인 셈이다. 우리 공대생들은 실험을 해 본 적이 없기 때문에 유학 가면 다 촌닭이 된다.     이런 현실에 대해 교수들은 『실험실습비도 없고, 실험장비도 없다, 어차피 나만의 책임은 아니지 않느냐』며 항변한다.     그러니 理工系 출신들은 유학 가서도 다 이론 쪽으로 간다.     기업은 해외(주로 일본)에서 기술을 들여오고, 理工系 대학은 해외 학계의 발전 내용을 어학실력이 닿는 대로 번역해서 가르치고 있다. 産學(산학)협동이 있을 수 없다. 수요도 없고 공급도 없다. 기업과 대학 사이에 오가는 연구비는 기업들이 理工系 학생들을 조달하려는 차원에서 에이전시한테 주는 커미션일 뿐이다.     최근 들어 서울工大의 커트라인이 웬만한 지방의 의과대학보다 떨어진다. 『공대 지원자가 정원에 미달한다는 사실이 신문에 자꾸 보도되니까 공대가 더 죽는다』며 정원 미달 사실을 숨기는 것을 대책으로 들고 나오는 교수도 있다.     입학생들의 실력이 떨어져 수학·과학 「보충반」을 편성해야 할 지경이다.     『이런 수준의 학생들을 데리고 도대체 어떻게 교육을 하라는 말이냐』고 한탄하는 동료 교수들에게 나는 『대한민국 최고 수준의 학생들이 들어왔을 때 과연 우리가 그 아이들에게 세계 최고 수준의 공학교육을 했느냐』고 묻는다.     최근 정부에서 「理工系 학생들에게 장학금을 지원하겠다」, 「병역 혜택을 주겠다」고 나섰다. 나는 이런 대중적 구호를 보면 옛날 전봇대에 붙어있던 술집 여종업원 호객 구호가 생각난다.     「침식 제공, 선불 가」     정상적인 사람이라면 이런 구호를 보면 『아, 저곳은 절대로 가서는 안 되는구나』 하고 판단을 내릴 것이다.     「국민을 먹여 살리는 건 산업기술이고, 그것을 이끌어 가는 것이 理工系 교육」이라는 사실에 대한 근원적인 인식의 전환이 없이 몇 개의 사탕을 나눠 주는 것으로 理工系 교육을 살려낼 방도는 없다.     내 실험실의 졸업생들 중 11명이 국제학회에서 최우수 논문상을 받았다. 세계에서 유례가 없는 일이다. 그럼에도 졸업생들은 물론 교수인 나 역시 자부심보다는 미래에 대한 불안한 마음과 국가에 대한 서운한 마음이 먼저 드는 것, 이것이 우리 理工系의 현주소다.       이공계 기피의 역사적 뿌리     우리 사회는 기술을 賤視(천시)하던 조선조의 문화로 회귀하고 있다.     기술을 중시하고 理工系가 우대를 받았던 1960년대 이후의 시기는 기술을 냉대한 긴 역사에서 잠시 반짝한 예외적인 시기였다. 역사 속에서 내 선배 과학자 기술자들은 모두 처절한 최후를 맞았다.     신라 無影塔(무영탑: 경주 불국사의 석가탑)의 전설은 아주 로맨틱하다.     탑 만들기에 동원된 石工(석공)은 오랫동안 아내와 떨어져 살아야 했다. 아내는 남편이 너무나 그리운 나머지 스스로 물에 빠져 죽고 만다. 이 이야기가 전하는 메시지는 간단하다.     「탑 만드는 데 동원되면 죽도록 고생만 하고, 가정이 파탄난다」     佛事(불사)에 동원된 석공들에게 오두막 하나씩 지어 주고 거기서 아내가 밥을 지어 주게 했을 법한데도 위정자들은 전혀 신경을 쓰지 않았다. 무영탑의 전설이 주는 교훈은 「石工에게 시집가면 죽는다」였을지 모른다.     에밀레종 설화도 마찬가지다.     共鳴(공명) 설계는 컴퓨터 기술로도 파악하기가 어렵다. 신라 시대에 종을 만들려면 보통 고생이 아니었을 것이다. 시행착오를 거듭하는 과정에서 얼마나 독촉과 질책을 받았으면 끓는 쇳물에 제 아이를 넣어 볼 생각을 했을까?     아브라함은 아들 이삭을 제물로 바치는 흉내만 냈는데도 하나님으로부터 『대대손손 축복을 내리겠다』는 약속을 얻었다. 아들을 제물로 바쳐 맑고 그윽한 소리를 만들어낸 신라의 종 만드는 기술자가 그 후 행복하게 잘 살았다는 얘기는 전해지지 않는다.     이 설화 역시 「주조 기술자가 되려면 자식을 제물로 바칠 각오를 해야 한다」는 메시지를 새벽 안개처럼 은은하게 사방에 퍼지게 했을 것이다.     조선시대 기술직에 있던 사람들은 모두 천민 계층이었다.     장영실을 보자. 관노 출신 천민인 장영실은 당시 지극히 예외적으로 從 6품까지 벼슬이 올랐다. 세종이 신임을 하니 문반들의 시기 질투가 대단했다. 문반들은 「천민이 從 6품까지 올라가는 것을 좌시하면 안 된다」는 공감대 아래 세종에게 온갖 간언을 했으나 세종이 듣지 않았다.     그러다 장영실이 관리 책임을 맡고 있는 공주의 가마 손잡이가 부러져 공주의 가마가 구르고 말았다. 왕족의 신체에 상처를 입히면 모반죄에 해당하는 것이어서, 세종도 감싸줄 수가 없었다. 아마도 누군가가 가마 손잡이에 미리 톱질을 해 놓았을 것이라는 소문이 당시 돌았다고 한다. 중요한 것은 그 후 아무도 장영실이 어떻게 됐는지를 모른다는 것이다. 이 일화는 「과학 기술자로 출세하면 죽는다」는 메시지를 남긴다.       官尊民卑     국내의 몇 개 안 되는 과학관에 가서 보면 서양 과학자들은 출생연도와 사망연도가 전부 기록돼 있는데 우리나라 과학 기술자들은 하나같이 출생연도만 밝혀져 있을 뿐 사망연도는 물음표로 처리돼 있다. 과학 기술자들의 말로가 안 좋았다는 증거다.     나는 1990년대에 「손빨래 세탁기」, 「골고루 전자레인지」, 「따로따로 냉장고」 등을 개발해서 「올해의 히트상품」으로 선정된 제품 6개를 만들었다. 이 덕에 1996년에 문화관광부에서 주는 세종문화상(기술부문)을 받았다.     시상식 전날 예행연습이 있다고 해서 불려갔다. 단상에 올라가는 걸음걸이가 씩씩하지 못하다는 이유로 몇 번을 단상에 오르락내리락했다. 연습하러 나온 女高 합창대원들 앞에서 서울工大 교수의 자존심은 말이 아니었다.     이튿날 시상식장에서의 상황 역시 마찬가지였다. 당시 시상을 맡은 李壽成(이수성) 국무총리는 나와 함께 서울대학 교수로 일했던 분이다. 그의 연설이 이어지는 10여 분 내내 나는 객석을 등진 채 그를 바라보고 서 있어야 했다. 시상식의 주인은 상을 받는 사람이 아니었다.     기념 사진을 찍으려고 맨 앞에 앉아 사진기를 들고 있던 아내는 나의 뒤통수만 실컷 바라보고 있어야 했다. 상품 개발로 산업발전에 기여한 공로로 상을 받는 나는 수상 소감 한 마디 못해 보고 단상을 내려와야 했다.     조선 시대 장영실의 얘기가 아니라, 1996년 서울工大 교수가 겪은 일이다. 「이러니 다들 관료가 되려고 하지 누가 과학기술자가 되려고 하겠나」 하며 씁쓸했던 기억이 난다.       十面楚歌     나는 1986년부터 우리의 경제가 위기에 처했다고 떠들고 다녔다.     1992년 「W 이론을 만들자」에서 우리 경제가 十面楚歌(십면초가)에 둘러싸여 있다고 주장했다. 당시 우리의 산업구조는 선진국에서 도입한 낙후기술과 설비에 低임금을 결합한 허약 체질이었다.     주문자 상표를 부착한 얼굴 없는 수출로 우리 상품은 저급품으로 분류돼서 외국의 低소득층에 팔려 나갔다. 유통망과 애프터 서비스 시스템이 없어 단골을 확보하지 못했다. 이런 악순환이 이어져 실속 없는 산업팽창이 이뤄졌다.     1975년을 기점으로 우리 산업의 틀을 바꿔야 했다.     1975년까지만 해도 「低임금 양산조립」은 한국에게 보장된 독무대였다. 그렇지만 기술도입과 단순 모방만으로는 한계에 직면했고, 값싼 임금과 풍부한 노동력을 앞세운 중국이라는 넘을 수 없는 산이 눈앞에 있었다.     1975년의 기술도입료가 전년도에 비해 갑자기 4배나 늘어났다. 이때부터 독자적인 기술개발에 중점을 두었어야 했는데 우린 그걸 하지 못했다. 기술 도입료와 로열티가 계속 올라가자 기업들은 현장 작업자들만 다그쳤다.     지금도 관료와 기업인들은 『高임금 低효율이 해소되어야 경제위기가 해소된다』며 허리띠를 졸라매라고 한다. 허리띠만 졸라매면 위기가 해소된다는 말인가? 이웃집에서 카시미론 솜 이불을 팔아대는데 낡은 솜틀 기계의 생산성을 높인다고 경쟁에서 이길 수는 없다.     이것은 1975년식 사고방식이다.     제조업은 기술정보, 상품기획, 연구개발, 설계, 설비계획, 부품조달, 생산, 판매기획, 판매, 사후관리 등 대략 10단계의 과정으로 이뤄진다. 우리의 제조업은 상품기획과 연구개발 설계는 해외기술의 도입으로 대체했고, 판매 및 事後관리 단계는 외국 바이어들에게 기대 왔다. 우리 손으로 직접 담당하였던 것은 생산부분뿐이다.     우리 제조업이 살아남을 수 있는 응급 처방은 무엇일까.     우선 선진 제품의 모방에 심취했던 逆개발을 당장 중단해야 한다. 독자적으로 상품을 기획하고, 창의적인 연구개발의 주도권을 확보하려고 목숨을 걸어야 한다. 우리 기업들은 본격적으로 상품 기획을 해 본적이 없다.     선진기업에서 만든 제품을 도입하고 모방설계를 했으며, 세계시장에서 소비자 구매욕이 입증된 상품만 골라 뒤늦게 기획에 착수하였다.     나는 1989년 산학협동을 통해 「하이 터치」 프로그램을 수행했다. 아직까지 본 적이 없는 상품을 개발하자는 게 목표였다.     1989년에 만든 입체형 컴퓨터 키보드는 손목의 피로를 덜어 주는 제품이었다. 1993년에 출시되어 1조원 이상 팔린 맥킨토시 키보드보다 4년 앞선 기획 상품이었다. 한국의 대기업은 「이제까지 이런 제품을 본 기억이 없다」는 이유로 대량생산을 망설였다.     『그렇게 좋은 키보드라면 왜 IBM에서 아직까지 개발을 하지 않았겠는가』가 업체의 공통된 반응이었다. 우리 기업은 남의 것을 모방만 해왔기 때문에 남이 안 하는 것을 만들면 큰일이 나는 줄 안다.     비슷한 시기에 나는 리모콘으로 조정하는 자동 진공청소기를 개발했다. 최근 필립스가 제작해 국내에서 한 대에 200만원 이상으로 팔리는 자동 진공청소기와 똑같은 모양과 기능의 제품이다. 차이가 있다면 필립스는 진공청소기에 자동 감지장치를 장착했다는 것뿐이다.     자동 진공청소기의 기획 아이디어를 냈지만, 어느 전자제품 업체도 받아들이지 않았다.     나는 산학협동을 추진하면서 한국 기업인들 머리 속에 뿌리깊게 박혀 있는 「三不可(삼불가) 이론」을 발견했다.       경영혁신은 죽지 않으려고 하는 일     신제품 개발을 위한 상품기획 과정에서 새로운 아이디어가 나올 때마다 기업의 관리자들이 세 가지 이유를 들어 개발을 기피한다.     첫째, 새로운 아이디어를 받아들이면 가격 상승 요인이 발생한다는 이유다. 새로운 기능을 첨가하면 제품 원가가 올라가고 판매가도 높아지기 때문에 가격경쟁력이 떨어진다는 얘기다.     두 번째는 量産(양산)에 지장을 초래한다는 이유가 나온다.     나는 직육면체로 만든 제품의 모서리를 소비자들의 취향에 맞게 곡선으로 처리하자고 제안한 적이 있다. 기업 쪽에서 벌떼같이 들고 일어났다. 곡면으로 바꾸면 생산성이 저하된다는 것이다.     세 번째는 신뢰성을 보장할 수가 없다는 논리다. 새로운 기능이 첨가되면 부품이 늘어나고 고장률이 높아진다는 말이다. 새로운 아이디어를 낼 때마다 기업 측에서는 「三不可 이론」으로 신제품 개발에 반대했다.     어떤 기업이 일류기업인가?     일류기업은 누구보다 먼저 새로운 산업분야를 개척하고 최고 혹은 최초의 기술과 상품을 만들어 내야 한다. 둘째, 이 기업을 모방한 다른 기업들이 덩달아 돈을 벌어야 한다. 즉 보고 따라 하는 二流기업들이 있어야 한다는 얘기다.     그렇다면 초일류기업이란 무엇인가?     국적과 사업 분야를 막론하고 全세계의 일류기업들이 초일류 기업의 기술과 상품 경영철학을 본받아서 큰 이익을 내야 한다. 초일류로 분류될 수 있는 기업은 全세계에 몇 개 밖에 없다. 이런 기준대로라면 한국에는 불행하게도 초일류 기업이 없다.     삼성은 일류기업이지 초일류기업이 아니다.     삼성이 「新경영」을 추진할 때 삼성 임원들의 방마다 「잭 웰치」의 책이 꽂혀 있었다.     나는 삼성 임원들에게 『삼성은 아무리 몸부림을 쳐도 잭 웰치를 쫓아갈 수 없다』고 얘기했다.     삼성 사람들이 『왜 안 되냐』고 묻기에 나는 이렇게 설명했다.     『잭 웰치는 현재 1등이거나 가까운 장래에 1등이 될 수 있는 2등을 빼놓고는 다 잘라냈다. 삼성이 그렇게 할 수 있나? 삼성그룹이 공중 분해되어도 좋은가? 잭 웰치가 한 번에 10만 명을 감원했다. 한국적 정서를 이겨내고 수만 명을 감원시킬 자신이 있나? 잭 웰치는 아침부터 저녁까지 나와서 직접 서류 나르고 재떨이 던지며 경영혁신에 달라붙었다. 당신 회사의 회장이 그렇게 할 수 있나?』     삼성 관계자들은 『新경영을 하려는 총수의 강력한 의지를 확인할 수 있었다. 분위기가 사뭇 달라졌다』고 항변했다. 나는 『경영 혁신은 총수의 의지를 확인하려고 하는 것도 아니고, 회사의 분위기를 바꾸려고 하는 것도 아니다. 안 하면 죽기 때문에 하는 것이 경영혁신』이라고 했다.     그러면 삼성 관계자들은 대개 이런 질문을 던졌다.     『죽기 살기로 경영혁신을 안 하는데 왜 삼성은 안 죽습니까?』     내 대답은 이렇다.     『지금 사방에 암 걸려서 링거 꼽고 누워있는 환자들이 수두룩한데 폐병 걸린 환자를 죽일 수는 없지 않나?』     한국에서 경영혁신을 하겠다는 기업들은 대개 「전담추진반」을 둔다.     전담추진반은 보통 상무급이 팀장이 된다. 이 사람들이 어떻게 상급자인 사장들의 목을 자르겠는가?       IMF 경영혁신의 최대 피해자는 연구인력     IMF 이후 제일 먼저 잘려나간 것이 「전담추진반」에 연줄을 확보하지 못한 연구소의 연구인력들이었다.     총수가 직접 나서서 「우리 기업이 죽지 않으려면 어떻게 해야 하는가」를 밤새워 고심했다면 연구인력은 제일 마지막 감원대상이 되었을 것이다. 패러다임 전환의 대상이 되어야 할 사람들이 패러다임 전환을 주도했다.     이게 대한민국 기업의 비극이고, 나라의 비극이다.     한국은 기업의 회장이 구설수를 외면하기 때문에 직접 나서서 구조조정을 하지 않는다. 그러나 잭 웰치는 「전담추진반」을 두면 안 된다는 걸 알기 때문에 자신이 직접 감원대상을 고르고, 자르고, 불필요한 부서와 인력을 잘라 냈다.     1997년 초 한 경영자 모임에서 내게 강연을 요청했다.     당시 「가격 경쟁력만이 살길이다」는 구호가 위력을 떨치던 시절이었다. 나는 강연을 하면서 『아직도 가격 경쟁력을 강조하는 정부 관료와 기업 경영자는 머리에 총상을 입은 사람들』이라고 직설적으로 얘기했다.     기업활동에서 가능한 한 끝까지 피해야 할 것이 바로 경쟁사와 가격경쟁을 벌이는 것이다. 가격경쟁이란 최후의 승자 하나만이 남을 때까지 출혈을 하면서 계속해야 하는 죽음의 경기이기 때문이다. 그런데 모두가 나서서 「죽음의 경기만이 우리가 살길」이라고 아직도 외치고 있다.     우리의 제품들은 제조원가가 높은 반면에 판매가가 낮아서 가격 경쟁력을 따질 시기를 지난 지 오래다. 우리 제조업은 미국, 일본, 싱가포르, 대만에 비해 높은 금융 비용과 부동산 가격, 물류 비용, 로열티, 실질 임금 등이 높아 「5高」에 시달리고 있다.     우리 기업들은 울타리를 친 내수시장에서 국내 가격을 높게 받아 연명해 왔다. 마치 친척들에게는 비싼 값을 받고 일반인에게는 싼 값에 물건을 팔아 이윤을 남긴 것과 같다.     운동경기에서 우리 팀이 계속 실점을 하면 관중들은 『작전을 바꾸어야 한다』고 충고한다. 우리의 과거 작전은 가격 경쟁력이었으나, 가격 경쟁력 작전으로 가서는 중국은 물론 대만, 홍콩, 싱가포르와 상대가 될 수 없다.     우리가 살길은 가격을 높여서 받을 수 있는 「가격 결정권」을 확보하는 길뿐이다. 제품가격을 높이고도 물건을 파는 방법은 독특한 제품, 경쟁상대가 없는 高附加(High Touch) 제품을 만드는 수밖에 없다.     세계 초일류기업이 되겠다고 몸부림을 쳐야 한다.     중국에는 풍부하고 저렴한 노동력은 물론 화상 네트워킹과 마케팅 능력이 있고, 일본에는 기술력이 있는데 우리가 무슨 근거로 가격 결정권을 가질 수 있을까?     해답은 창의력에 있다.     우리에게 창의력이 있다고 주장하는 데 두 가지 근거가 있다.     첫 번째는 우리 민족이 지금까지 모든 걸 해봤는데 아직까지 안 해 본 것이 바로 창의력이다. 혹시 창의력이 있을지 모른다. 두 번째는 나 스스로 경험을 통해 우리가 창의력이 많다는 결론에 도달했다.     창의력을 가지고 소규모 실험을 해서 세계시장에 성공여부를 타진한 다음 군단 병력에게 파는 식으로 가야 한다. 우리의 3大 효자 상품인 휴대폰, LCD, 자동차 산업은 5년 안에 중국의 추격을 받아 자멸할 운명이다.       「가격 결정권」만이 살길이다     글로벌 마켓에 진출하는 것이 문제가 아니라, 글로벌 마켓을 독점 내지 선점해야만 살아남을 수 있다. 가격 결정권만 가지면 우리는 동양의 맹주가 될 수 있다.     우리 기업이 가격결정권을 가지려면 패러다임을 전환해야 한다.     내가 내놓은 아래의 물음들에 독자들이 응답을 해주었으면 한다.     「정부가 5년 이내에 理工系 기피문제에 대한 바람직한 대책을 내놓을 확률이 몇 퍼센트라고 생각하는가?」     「기업이 5년 이내에 정부지원 없이 국제경쟁력 강화를 위한 방안을 추진할 확률은 몇 퍼센트라고 보는가?」     「대학이 5년 이내에 스스로 교육개혁을 추진할 확률은 몇 퍼센트일까?」     「학부모들이 내 자식만은 편안한 직업을 가져야 한다는 생각을 바꾸고, 자녀에게 理工系 대학 진학을 권유할 확률은 몇 퍼센트라고 생각하는가?」     어떤 항목이든 『10% 이상』이라고 대답한 사람은 응급실로 가야 한다. 온전한 정신이 아니기 때문이다. 패러다임의 전환에는 자기혁신이 필요하다. 패러다임을 바꾸지 않으면 모든 노력은 무위로 돌아갈 것이다.     우리 산업은 도시가스에 밀려 설 자리를 뺏긴 구공탄 공장에 비유될 수 있다.     생산성을 향상해 하루에 구공탄을 10%씩 더 찍으면 구공탄 공장은 살아날 수 있을까? 구공탄 공장의 「高임금·低효율」이 해소되면 구공탄 공장은 살아남을 수 있을까? 대답은 둘 다 『아니오』이다.     도시가스가 도입되는 초기에 『도시가스로 업종을 전환하라』고 했다면 연탄공장 사장은 이렇게 대답했을 것이다.     『패러다임의 변화, 웃기지 마라. 온돌방이 존재하는 한, 겨울철이 존재하는 한 구공탄은 영원하다』     연탄공장은 그렇게 戰意(전의)를 불 태우다가 흔적도 없이 사라졌다.     얼음가게와 냉장고, 우마차와 용달차, LP와 CD 모두 똑같은 원리다. LP 5000장을 모은 음악 애호가에게 CD로 바꾸라고 한다면 쉽게 바꿀 수 있겠는가? 오스트리아에 여행 갔을 때 밥 굶으면서 산 오페라 판, 유학할 때 아내에게 잔소리 들어가며 산 클래식 전집, 눈물이 앞을 가릴 것이다.     그래서 음악 애호가도 이렇게 외친다.     『클래식이 존재하는 한, 아니 오페라가 존재하는 한 LP는 영원하다』     그러나 지금은 축음기 생산이 중단되어 더 이상 LP를 들을 수 없게 되지 않았는가.     과거의 산업구조가 일직선인 走路(주로)를 눈감고 뛰기만 하면 되는 마차 경주였다면, 지금의 산업구조는 폴로 게임이다. 말의 눈을 절대 가리면 안 되고 走路도 일직선이 아니고 그라운드다. 어디로 갈지 모르며 빨리 달리는 게 능사가 아니라 빨리 설 줄 알아야 하고 세 박자 쉬었다가 달릴 수도 있고, 세 걸음 뛰다가 정지도 해야 하는 복잡한 게임이다.     그런데 우리나라는 마차 경주 챔피언들이 폴로 복장을 하고 나와서 설치고 있는 형국이다.     요즈음 우리의 국가 목표는 국민소득 2만 달러 달성이다.     GNP로 국가의 비전을 내세우는 나라는 찾아보기 어렵다. 우리의 의식은 거의 필리핀 수준이다.     우리에게는 「이웃을 돕겠다」, 「인류에 혹은 국제사회에 기여하겠다」는 정신이 희박하다. 패러다임의 전환을 시도하기 조차 힘들다. 원래 패러다임의 전환은 극히 일부가 시도하는 것이고 시도한 사람 중에 극히 일부가 성공한다. 그러나 패러다임 전환이 이뤄지지 않으면 우리 모두가 죽는다.       理工系 기피의 최종 피해자는 국민     조선조의 한 왕이 정승들에게 『광풍이 몰아치는 벌판에서 초가삼간을 유지하는 방법이 무엇이냐』고 물었다. 영의정은 이렇게 대답했다.     『사방의 문을 활짝 열어 놓고, 광풍이 쇠잔해지기를 기다리면 됩니다』     이 얘기는 우리나라 지도계층의 철학을 잘 보여 준다.     사방의 문을 열어 놓으면 초가집은 무너지지 않겠지만, 방 안에 있던 民草(민초)들은 다 어떻게 될 것인가? 모두 바람에 날려가서 죽지 않았을까? 우리는 그런 방식으로 끈질기게 버텨왔다. 7년 전쟁에서 절반에 가까운 민초들이 사라진 임진왜란이 대표적인 예가 아닐까?     理工系의 위기는 역사적 뿌리가 깊다.     理工系의 위기에는 기업과 대학, 사회 전체가 복잡하게 얽혀 있다. 잭 웰치의 얘기에서 거론했듯이, 理工系의 위기는 해결하지 않으면 우리가 죽는다는 각오로 달라붙어야 할 문제다. 정책 구호나 유인책 몇 가지로 해결될 수 없는 문제다. 理工系 기피현상은 대학이나 理工系 대학생들의 문제가 아니다. 국가와 기업, 우리 사회 전체가 理工系 기피현상의 최종 피해자가 될 것이기 때문이다.     결론은 간단하다. 살고 싶으면 해결해야 하고, 죽고 싶으면 지금까지 그랬듯이 그냥 놔두면 된다.●

 

출처 : DELPAI.COM ( http://delpai.com/tt/index.php?pl=390&ct1=-1 )

---

병재, 연태, 형배, 계도 같이 휴가나와서..
한살 두살 나이를 먹어도 다들 예전 같아보여서 좋았다.

“물리치료학과인데 보는 어르신마다 무조건 어깨를 주무르라고 하십니다. 어르신들! ‘물리치료학과’는 어깨 주무르기 배우는 과가 아니거든요 (훌쩍).”

물리치료학과에 다니는 한 대학생의 푸념이다. “단지 물리치료학과에 다니는 이유만으로 만나는 사람들마다 나에게 안마를 부탁한다”며 그는 연신 “물리치료학과는 결코 마사지나 안마 과가 아님”을 강조한다.

최근 웹상에서는 ‘학과별 애로사항’이라는 제목의 글이 화제가 되고 있다. 각 학과별로 학생들이 학과의 명칭 때문에 겪는 어려움 또는 웃지 못할 에피소드를 모아 놓은 것이다. ‘그 학과 학생이라서 어떠한 오해를 받고 있는 지’를 실제 경험담도 모아 놓은 이 글은 게시판에 올라올 때 마다 수많은 네티즌들의 댓글이 잇따른다.

다음카페 ‘연이말(http://cafe.daum.net/nowwetalk)’에서는 이 글이 올라오자 많은 댓글이 달리며 “게시물에 공감한다”는 글이 쏟아지기도 했다.

‘학과별 애로사항’은 지난 2004년 7월, ‘그림자’님이 유머사이트 심심이(http://www.simsimi.com)에 ‘저는 러시아과입니다’라는 게시물을 올린 것이 발단이 됐다.
‘그림자’님은 전공이 각각 러시아어, 토목, 어류양식학, 컴퓨터공학인 네티즌의 '애로사항'을 올렸는데 이 게시물에 수많은 네티즌들이 공감한다면서 ‘우리 과는 이런 애로 사항이 있다’는 댓글들이 줄을 이었다.

예를 들어 동양학과에 다니는 한 여대생은 “사람들이 동양학과는 국악 틀어 놓고 그림 그리는 줄 알았다고 합니다. 가끔 한복 입고 그리냐고 묻는 사람도 있어요. 또 연말이면 연하장에 ‘난’ 그려 달라고 졸라대서 아주 귀찮습니다”라며 전공이 ‘동양학과’여서 겪게되는 초난감한 점들을 털어왔다.

다음은 사이트 심심이에 ‘그림자’님이 올린 글 ‘저는 러시아과입니다’ 전문.

▽저는 러시아과 입니다
저는 러시아어 과입니다. 저보고 예쁘고 섹시한
러시아 무용수를 소개 시켜 달랍니다. -_-;

게다가 요사인 어디서 구했는지
징그러운 러시아포르노를 가지고 와서는
해석해 달랍니다.
무슨 해석이 필요하다고…. -_-;;;;;;;

뭡니까~ 이게 러시아 포르노 나빠~요!

▽전 그냥 토목과입니다만
뭐 다들 부럽군요. 다들 뭔가 특기가 있어 보이지 않습니까??
전 토목과입니다만.
왜 맨날....
"우와 그럼 술 잘 마시겠네요?"
토목과가 술 마시는 과입니까...
아~! 억울. ㅜ_ㅜ

▽어류양식학 전공입니다.
보통 줄여서 양식과 양식과 부르죠.
제 동기중에 한명은 신검 받을때 자기 전공적는 란에다가 양식과 적었다가
지금 취사병으로 군복무 하고 있습니다.-_-;
특히나 간부식당 취사병으로 빠지는 비율이 그렇게 높다네요.

전 참고로 부대 금붕어 관리병도 잠깐 했었다는~

▽컴공의 비애..ㅠ.ㅠ
컴퓨터 공학과의 비애
- 컴퓨터에 관한한 만능이어야 된다.
- 모든 컴퓨터부품 시세를 꿰뚫고 있어야 한다.
- 컴퓨터 에러에 관한한 해박한 지식을 갖추어야 한다.

컴퓨터 공학과는 모든 통신사의 통신라인을 깔아줄 수 있어야 되고 설정 방법 또한 능통
해야 된다. 특히 허브나 라우터를 통한 인터넷공유기술은 반드시 익혀야 한다 -_-..

친구 : 우리집 인터넷 갑자기 안 되는데 왜 그래?
나 : 그... 글세..?..?
친구 : 컴퓨터 공학과가 그것도 몰라?
나 : -_-....

친구 : 그럼 우리 집에 와서 좀 고쳐줘
나 : -_-.......

컴공 욕보이지 않게 하려면 가서 고쳐줘야 된다..
그런데 가서 본다고 뭐 뾰족한 방법이 있나.
그냥 어쩌다 될 수도 있고 안 될 수도 있는 거다.

(집에 가서 랜카드랑 랜선을 만지작 거리던 중 -_-;;)
친구 : 어? 이제 되네. 와 고마워. 근데 이왕 온 김에 인터넷 공유 좀 시켜줘
나 : 어..?... -_-;;

친구 : 저 방에 있는 컴터는 인터넷 안되잖아.. 어디서 보니까 뭐 달면 그냥 다같이 인터넷
도 쓰고 그러던데 나도 그거 해줘.
나 : 그거... 회사에다가 다중연결신청해.
친구 : 돈 더 내야 되잖아! 그냥 좀 해줘! 컴퓨터공학과가 그것도 못 해주냐! "
나 : -_-.........(난감하다)

- 모든 컴퓨터부품 시세를 꿰뚫고 있어야 한다.
친구 : 야! 나 RW 하나 살려고 하는데 그거 얼마냐? "
나 : 글세 -_-?.. 왜 나한테 묻지..?
친구 : 야! 컴퓨터공학과가 그런것도 모르냐!! "
나 : -_-;;;

또다른 친구는...
친구 : 나 컴퓨터 살려고 하는데 얼마 있어야 돼?
나 : 음 한 100~150만원 정도 있음 되지 않을까?
친구 : 니가 최대한 싸게 살수 있게 좀 해줘
나 : 최대한 어떻게 싸게 -_-;;;?.


- 컴퓨터 에러에 관한한 해박한 지식을 갖추어야 한다.
친구 : 야 프로그램 실행시키니까 에러래. 에러 안 나게 좀 해봐라.
나 : -_-... 무 무슨 프로그램인데.. -_-...

친구 : 어 게임인데 자꾸 에러나 고쳐줘.. "
나 : 내가 무슨수로 -_-....
친구 : 컴퓨터 공학과가.!!..................... (중략)

▷출처 :http://www.simsimi.com/nori/board_nori_view.php?id=fun&code=25466&page=1&st=off&sc=on&key=토목과&premium=


위 게시물은 당시 큰 화제를 모으며, 각 포털 사이트 게시판으로 퍼져나갔고 댓글로 계속 ‘각 학과별 네티즌들의 애로사항’이 올라오자 게시물의 양도 조금씩 늘어나고 있다. 또, 언제부턴가는 제목도 ‘학과별 애로사항’으로 바뀌었다.

▽“원자력 공학과입니다. 다들 애 못 낳는다고 그러는데... ㅠ.ㅠ 털썩!”
▽“저는 경제학과입니다. 친구들이 주식 사달랍니다”
▽“저는 고분자 공학과입니다. 흔히들 고자라고 부르더군요. -.-;”
▽“저는 사회학과입니다. 결혼식이나 행사만 있으면 사회보라고 합니다.”
▽“신방관데 신방과면 PD 될 꺼니까 자기 딸 좀 자기아들 좀 눈도장 찍겠다고 항상 말씀하시는 이웃 아주머니들! 신방과라고 다 PD되고 방송국 가는 거 아니걸랑요? ㅠ_ㅠ (요샌 오히려 못 간다고 -_-)”
▽“아는 동생이 게임과 다니는데 아주 울분을 토합니다. 녀석이 가장 싫어하는 말이 게임과라고 하면 ‘스타 잘 하겠네요’라는 거라고 하더군요.



위의 댓글에서 보는 것 처럼 네티즌들은 이런 게시물이 올라오면 자신이 다니는 과에 관한 재미 있는 댓글을 많이 올린다. 주로 일반인의 선입견, 쓴웃음이 나오게 하는 에피소드 등이지만 태권도를 전공한다는 한 남성 네티즌은 “사체과 태권도 전공인데 맨날 여자애들이 호신술 가르쳐 달라고 하네요”라는 조금은 행복한(?) 고민을 올려놓아 눈총을 받기도 했다.

도깨비뉴스 리포터=미스터 봉구 mrbong@dkbnews.com

---

맨날 컴퓨터 고쳐달라는 사람들 때문에 미치겠다;
물론 나는 컴퓨터를 오래 사용 했기 때문에 요구하는 것들은 대부분 고칠수 있다.
그런데 컴퓨터 학과니깐 뭐 좀 고쳐봐라, 해봐라 이런건;;
그리고 우리가 배우는 건 주로 프로그램개발및 제작인데,
집에오면 엑셀, 파워포인트, 한글 이런거 세부기능 모른다고 무지하게 야단 맞는다;
컴퓨터 학과가 그것도 모르냐고;
가르쳐 주지 않으니 당연히 모를수 밖에;;
배운거라곤 1학년 입학했들때 전교생이 다듣는 실용전산?
그것도 대충 사용방법만 배웠지. 세부기능 까진 가르쳐 주지 않는다.
아마 대학교에서 세부기능 가르쳐 주는 과는 1%도 안되지 싶다.
왜냐하면 가르칠 필요도 배울 필요도 없기 때문이다.
배울 필요가 없다는 말은 그런게 쓸모 없는 기술이란 얘기가 아니라,
학원가서 배우면 초등학생도 배울수 있는 하급기술이기 때문이다.
(지금 술먹고 글을써서 그런지 글이 술술 써지는듯한 느낌이 드는건 왜일까..?)
아무튼 상-중급자에겐 그냥 자신이 필요할때 필요한 기능만 습득해서 쓰면 되는기술이다.

체육과 출신의 수영선수가 꼭 태권도까지 잘 할 필요가 없는것과 비슷한 예이다.
분명,
이 수영선수도 체육과 출신인지라, 자신이 필요한때(예를 들어 불가피하게 아마추어태권도 대회에 출전해야 할때) 조금만 배우면 일반인보다 금세 태권도 기술을 습득할수 있을것이라 생각한다.

세상 사람들아 제발 고정관념을 버려라.
못한다고 따지지말고!!
못하는게 아니라 할 필요가 없어서 안하는거다.

출처 : http://www.roadplus.com (로드플러스)

출처: http://miniwini.com/miniwinis/bbs/index.php?bid=share&mode=read&id=3655 (미니위니)

이메일 주소 이미지 만들러가기 : http://cat.powerdb.net/email/



e-mail 아이콘을 자동으로 만들어줍니다.


메일주소






[아래는 수정한거..]
MSN주소


캐럿보이넷

---

덧) 예전에 이글을 올렸던것 같은데... 올릴려다 말았었나..?