2005년 5월 24일 화요일
호기심의 안테나를 세워라
(예병일의 경제노트, 2005.5.24)처음 기내에 비치된 잡지에서 메모리 폼 베개를 봤을 때 '이걸 어디다 쓰면 좋을까?'라고 생각했던 것도 단순한 호기심에서였다.
만약 그 때 호기심이 발동하지 않았다면 오늘의 나와 트윈세이버는 없을지도 모른다.
수없이 많은 사람이 내가 본 잡지를 봤을 터이고, 또 수없이 많은 사람이 메모리 폼 베개 기사를 봤겠지만 그것을 개발해야겠다고 생각한 사람은 없었으니 말이다.
트윈세이버를 운영하며 창의적인 아이디어가 절실할 때가 많다.
그럴 때 나는 항상 다니던 일이 아닌 다른 길로 돌아가는 방법으로 생각의 전환을 시도한다. 익숙하지 않은 길을 가다 보면 익숙하지 않은 생각이 떠오르기 때문이다.
항상 '호기심'의 안테나를 세워놓아야 합니다.
호기심은 세상에 대한 관심, 내 일에 대한 적극성의 다른 표현입니다. 어떤 일에든 '심드렁'한 태도와 정반대되는 자세입니다.
메모리 폼 베개를 만드는 트윈세이버 황병일 사장. 그도 호기심을 잃지 않는 사람입니다.
황 사장은 IMF 당시 부도를 맞아 신용불량자가 되었습니다.1998년 단돈 45만 원을 들고 무작정 일본으로 건너갔던 그는 메모리 폼 베개라는 사업 아이템을 찾았습니다.
1999년 개발을 시작했고 1년여만에 제품을 만들어 냈습니다. 한 때 신용불량자였던 그는 2003년‘1000만 불 수출탑’을 수상할 정도로 재기에 성공했습니다.
그가 다시 일어설 수 있었던 계기는 기내에서 봤던 한 잡지의 기사에서 시작됐습니다. 그 어려운 상황 속에서도 '호기심'을 잃지 않았던 그에게 새로운 길이 보였던 것입니다.
황 사장은 아이디어가 떠오르지 않을 때면 다니지 않던 새로운 길로 돌아가곤 한다고 합니다. 익숙하지 않은 길, 환경을 걷다 보면 새로운 생각이 떠오를 때가 많다는 것이지요.
호기심은 세상에 대한 관심, 내 일에 대한 적극적인 자세입니다. 이런 호기심을 잃지 않는 사람에게는 아무리 어려운 상황 속에서도 '새로운 길'이 열리기 마련입니다.
2005. 5. 19. 18:29, Programming/.Net
「오픈소스 닷넷」모노 설치와 구동
오픈소스 모노 프로젝트는 비 윈도우 시스템에서도 닷넷 개발을 가능하도록 해줬다. 이로써 윈도우 시스템 뿐 아니라 유닉스와 맥 OS X에서도 동작하는 코드를 개발할 수 있게 됐다. 모노를 설치하고 간단하게 이용해보면서 이 개발 플랫폼에 대해 좀더 알아보도록 하자.
모노는 닷넷 프레임워크에 기반한 오픈소스 개발 플랫폼이다. 닷넷 플랫폼은 윈도우 뿐 아니라 맥 OS X와 여러 유닉스·리눅스 운영체제에서 동작하는 애플리케이션을 개발할 수 있도록 하기 때문에 선택의 폭이 한층 넓어졌다.
모노는 무엇인가?
모노는 C# 언어와 CLI(Command Language Infrastructure)가 유럽 컴퓨터 제조연합(ECMA)의 표준으로 받아들여졌기에 만들어질 수 있었다.
모노 라이브러리에는 닷넷 호환 라이브러리(ADO.NET, System.Windows.Forms, ASP.NET)와 모노에만 들어있는 써드파티 클래스 라이브러리가 포함돼 있다. 또한 모노 런타임을 애플리케이션에 내장시킴으로써 패키징과 배포를 간단하게 하는 것도 가능하다. 게다가 모노 프로젝트는 IDE, 디버거, 문서 브라우저도 제공한다.
모노 설치법
모노는 프로젝트웹사이트에서 자유롭게 다운로드 받아 설치할 수 있다. 현재 리눅스, 윈도우, OS X 세가지 운영체제별로 다운로드할 수 있으며 리눅스용은 일반 설치, 수세, 레드햇으로 세분화돼 있다. 소스코드를 다운로드 받아서 컴파일할 수도 있으며-현재 사용중인 플랫폼이 지원되지 않는다면 유일한 선택이다-적당한 설치 패키지를 다운로드할 수 있다. 이 글에서는 설치 패키지를 다운로드 받아서 이용한다고 가정한다.
플랫폼에 맞는 적절한 패키지를 다운로드 했다면 이제 설치해보자. 설치 과정은 운영체제에 따라 다를 수 있다. 현재 나는 윈도우 XP와 수세 리눅스 9.2에서 모노를 구동하고 있다. 윈도우에서는 쉽게 설치할 수 있지만 다른 경우에는 그리 만만하지 않다.
리눅스에서 설치하려면 모노 플랫폼을 지원하기 위해 여러 파일이 필요하다. 예를 들어 수세용으로 다운로드받아야 하는 파일들은 다음과 같다.
- mono-devel-1.0.6-1.ximian.9.1.i586.rpm - C# 컴파일러가 포함된 모노 코어 패키지
- mono-core-1.0.6-1.ximian.9.1.i586.rpm - 모노 코어 런타임
- mono-data-1.0.6-1.ximian.9.1.i586.rpm - 데이터베이스 코어
각 파일들은 모두RPM형식이다. rpm 명령어를 사용해 리눅스에서 설치할 수도 있다. 예를 들어 코어 모노 런타임은 다음과 같이 설치할 수 있다.
rpm -i mono-core-1.0.6-1.ximian.9.1.i586.rpm
모노를 설치한 이후 시스템 경로에 위치를 추가해야 한다. 그래야 전체 경로를 입력하지 않고 쉽게 명령어를 입력해 이용할 수 있다. 윈도우의 경우 제어판으로 들어가서 할 수 있으며 리눅스의 경우 export PATH 명령을 사용할 수 있다.
팁: 모노 설치에 애를 먹고 있다면Got Mono? 웹사이트에서 설치 문제를 해결할 수 있는 팁들을 찾아보길 추천한다.
모노 툴셋
모노를 설치하고 나면 다양한 툴들을 이용할 수 있다. 몇 가지를 살펴보자.
- 모노 - JIT를 사용하지 않고 애플리케이션을 실행하는 모노 인터프리터. 이걸 이용해 명령줄에서 애플리케이션을 구동할 수 있다. MS 닷넷 프레임워크에는 이런 툴이 없다
- mcs - MS C# 컴파일러(csc.exe)와 동일한 명령줄 옵션을 모두 받아들이는 C# 컴파일러
- monodies - 애플리케이션을 중간단계 언어(IL)로 디스어셈블하는 툴. MS의 ildasm.exe와 유사한 기능을 제공한다
포함된 툴들의 목록과 각 명령어 옵션에 대해 자세히 알고 싶다면 모노 문서를 참조하기 바란다.
모노 애플리케이션 개발하기
이제 이 툴들을 어떻게 사용하는지 보기 위해 간단한 모노 애플리케이션을 만들어보자. 아래는 콘솔에 메시지를 출력하는 코드이다.
using System;
namespace Builder.Samples {
public class MonoDemo {
public static void Main(string[] args) {
Console.WriteLine("Check out TechRepublic.com");
} } }
MonoDemo.cs라는 이름으로 저장하자. 이제 C# 컴파일러를 이용해서 컴파일하자.
mcs MonoDemo.cs
컴파일하면 MonoDemo.exe 파일이 생성된다. .exe 파일 확장자는 윈도우 시스템에서는 일반적인 것이지만 리눅스 시스템에서는 좀 이상하게 보일 수도 있다. 명령 줄에서 예제 파일을 실행시켜 보자.
mono MonoDemo.exe
이 예제를 통해 나타내려 했던 건 모노나 윈도우 닷넷 프레임워크가 동작하는 윈도우, 리눅스, 맥 OS X 등 어떤 플랫폼에서라도 컴파일된 파일이 구동될 수 있다는 점이다. 바로 모노 컴파일러가 IL이라는 중간 형태의 코드로 C# 코드를 컴파일하기 때문이다.
MS C# 컴파일러도 동일한 작업을 수행한다. 그러나 모노에서는 닷넷 클래스 라이브러리가 아직 완벽하게 구현되지 않은 상태이며 모노에만 있는 라이브러리도 있다. 결과적으로 모노로 개발된 모든 애플리케이션이 MS 닷넷 프레임워크에서 동작할 수는 없다는 의미이며 그 반대도 마찬가지다.
양자간 호환성을 유지하려면 대상 플랫폼과 향후 요구 사항을 이해해야 하며 개발 기간동안 계속 이 부분을 염두에 두면서 작업해야 할 것이다. 또한 모노 웹사이트를 자주 방문해 프로젝트의 진행 상황을 숙지해야 한다. 왜냐하면 클래스 라이브러리와 같은 새로운 내용이 계속 추가되고 있기 때문이다. 이런 상황은 MS 닷넷 프레임워크도 마찬가지다.
우려되는 일들
모노는 윈도우 플랫폼에 대해 갖고 있는 C# 관련 지식을 리눅스와 여타 플랫폼에도 적용할 수 있다는 장점을 제공한다. 그러나 윈도우를 제외한 다른 플랫폼에서 닷넷을 사용해 본격적으로 개발을 하는 건 주저할 수밖에 없다. MS는 C# 뿐 아니라 CLI도 공동체에 기증했지만 ADO.NET과 ASP.NET 같은 여타 기술은 그렇게 하지 않았기 때문이다.
이렇다보니 MS가 ASP.NET과 ADO.NET 엔진도 모노에서 이용할 수 있도록 할지는 여전히 의문이다. 그리고 IIS와 윈도우가 아닌 다른 웹서버에서 애플리케이션이 운용되는 상황은 MS에 타격을 줄 것이다.
어쩌면 명확한 근거가 없는 이야기일지도 모르겠지만 나는 이 점에 주목하고 있다. 그리고 마지막으로 지적하고 싶은 문제는 C# 말고 다른 언어에 대한 지원이 없다는 것이다. 이 때문에 VB.NET 프로그래머들은 모노에 시큰둥한 반응을 보이고 있다.
한번 빠져봅시다!
모노 프로젝트는 오픈소스 프레임워크에 기반한 인상깊은 결과물이라 할 수 있다. 모노 프로젝트는 닷넷 프레임워크의 많은 기능을 지원하며 2.0의 기능도 현재 지원하거나 지원할 예정에 있다. 또한 GNOME 인터페이스와 같은 리눅스 기반 애플리케이션을 개발할 때 모노에만 존재하는 라이브러리를 사용하는 경우도 있기 때문에 리눅스 개발에 힘을 실어주고 있다. 게다가 모노는 윈도우 개발자들이 리눅스를 접해볼 수 있는 좋은 기회이기도 하다. @
Tony Patton (TechRepublic) 2005/05/18
원문보기
원문 :http://www.zdnet.co.kr/techupdate/lecture/dotnet/0,39024986,39136472,00.htm
새로운 소비 트렌드, 트레이딩 업 2005년 5월 18일 수요일
새로운 소비 트렌드, 트레이딩 업
(예병일의 경제노트, 2005.5.17)전세계 중산층 소비자들 사이에서는 지금 트레이딩 업이라는 새로운 소비현상이 나타나고 있다.
트레이딩 업이란 중가제품을 주로 구입하던 중산층 이상의 소비자가 품질이나 감성적인 만족을 얻기 위해 비싼 제품에도 기꺼이 높은 가격을 지불하는 소비패턴을 일컫는 표현이다.
뉴 럭셔리 상품과 서비스는 일반 상품보다 품질, 품격 및 소비자가 느끼는 감정적 만족감의 수준이 훨씬 높고 가격은 고가로 책정되어 있지만 중가시장 소비자들이 구매가 가능한 범위다.
뉴 럭셔리 상품은 우리가 익히 알고 있는 가격-수요 곡선을 탈피해 있다. 그것은 가격은 높으면서 판매량도 높은, 이제껏 보지 못한 새로운 현상을 보여주고 있다.
'트레이딩 업'이 소비에서의 '키워드'로 부상하고 있습니다.
이런 현상이 일시적인 유행으로 끝날지, 아니면 새로운 소비 트렌드로 자리를 잡을지는 조금 더 지켜보아야 겠지만, 이런 움직임이 한국은 물론 전 세계적으로 강력하게 나타나고 있는 것만은 분명해 보입니다.
트레이딩 업이란 중산층 이상의 소비자가 감성적인 만족을 얻기 위해 가격이 비싼 제품을 기꺼이 구매하는 경향을 의미합니다.
여기서 중요한 것은 '감성적인 만족'과 '높은 가격'입니다. 소비자에게 감성적으로 어필할 수 있다면, 높은 가격대임에도 불구하고 물건이 더 많이 팔리는 것입니다.
소비자들은 일부 이런 트레이딩 업 소비를 하는 대신, 다른 대부분의 물건들은 대형 할인점 등에서 싼값에 구매를 합니다. '트레이딩 다운'입니다.
즉 실용성 위주의 트레이딩 다운을 통해 절약한 돈으로 자신이 정말 좋아하는 비싼 제품을 구매하는 트레이딩 업을 하는 겁니다.
가만히 생각해 보세요. 당신도 지금 그런 소비행태를 취하고 있지 않습니까?
이런 소비 트렌드는 기업에게 기회와 위협을 동시에 던져주고 있습니다. 새로운 소비층이 생긴 것은 기회이지만, 평균적인 품질과 가격의 제품만 만드는 기업에게는 매우 커다란 위협으로 다가올 겁니다.
트레이딩 업의 대상이 될 수 있는 고품질의 제품과 트레이딩 다운의 대상이 될 수 있는 매우 싼 가격의 제품. 이 두 카테고리에 들어가지 않는 '평범한 기업'은 점차 설자리를 잃어갈 가능성이 높다는 얘깁니다.
우리가 '트레이딩 업' 현상을 주목해야하는 이유입니다.
|
|
리더는 자신에게 분노한다 2005년 5월 17일 화요일
리더는 자신에게 분노한다
(예병일의 경제노트, 2005.5.17)20년 동안 GE를 멋지게 이끈 잭 웰치와 애플의 스티브 잡스는 분노한 사람들이다. 그들은 더 좋은 세상을 꿈꾸지만 그 꿈이 계속해서 실현되지 않을 때 화를 (대개는 자기 자신에게) 낸다.
그들은 현재의 상태에 대해 왕짜증을 낸다. 서쪽에서 떠오르지 않는 해 때문에 단단히 화가 난 그들은 당장 뭔가 행동을 취하기로 결심한다.
'화나지 않은' 사람을 리더로 삼지 마라. 사실상 '화나지 않은' 사람을 아예 고용하지도 마라.
당신의 눈을 보고 다음과 같이 말하는 사람이 이상적인 리더 후보다.
"이렇게 엉망인 곳은 세상 어디에도 없을 겁니다. 하지만 좋은 방향으로 바꿀 기회가 주어지면 기꺼이 책임을 떠맡겠습니다." 이렇게 말할 수 있는 사람은 그리 많지 않다.
리더는 분노합니다. 아니 분노하는 사람만이 리더의 역할을 제대로 할 수 있습니다.
분노는 다른 말로 표현 하면 '자기 자신에 대한 분노'입니다. 또 다른 말로는 '열정'
이라고 표현 할 수도 있습니다.
타인에게 분노를 표출하고, 짜증을 내는 '소인배'를 말하는 게 아닙니다. 이런 사람일 수록 오히려 타인에게는 관대하고, 겉으로는 평온해 보이는 경우가 더 많습니다.
현재의 상태에 대한 분노, 변화에 대한 의지, 미래에 대한 열정이 없다면 조직을 성공으로 이끌기 어렵습니다.
자기 스스로를 성공으로 이끌기도 물론 어렵습니다.
리더는 자기 자신에게, 현재의 상태에 분노합니다.
|
|
리더의 포퓰리즘(populism)과 캐어(care) 2005년 5월 13일 금요일
리더의 포퓰리즘(populism)과 캐어(care)
(예병일의 경제노트, 2005.5.13)인기에 영합하는 행동(Populism)도 혼란을 초래하는 원인의 하나다. 실패하는 리더들이 보이는 또 하나의 문제점은 인기나 호감에 연연하는 것이다.
우리 주위에는 부하에 대한 따끔한 질책을 꺼리는 성격 좋은 리더들도 있다. 그런데 이것도 사실 인기주의에 영합하는 소극적 형태의 하나일 수 있다.
문제는 그 결과 부하들에게 성과에 대한 상벌을 명확히 하지 않는 경우처럼, 오히려 고성과자의 사기를 떨어뜨리는 문제를 초래할 수 있다는 것이다.
또한 대외적으로 성과를 내보이고 싶어하는 개인적 욕심 역시 장기적인 조직의 성과에는 부정적인 영향을 초래하게 된다.
노용진의 '리더십 실패의 함정과 성공의 지혜' 중에서 (LG경제연구원, 2005.5.6)
리더는 포퓰리즘(populism)과 캐어(care)를 구분해야 합니다.
리더의 포퓰리즘은 어느 시대, 어느 분야에서건 그 구성원들에게 커다란 후유증을 가져다 줍니다. 조직의 진정한 이익, 장기적인 목표가 아닌, 지금 인기를 끌 수 있는 일에 진력하는 리더. 당장은 조직원들의 뜨거운 호응을 받기도 하지만, 시간이 지나면 결국 그들에게 남는 것은 허망함과 좌표상실 뿐입니다.
리더라면 지금 인기를 얻지 못하더라도 기업이나 나라의 진정한 이익을 위해, 장기적인 목표를 위해 전력해야 합니다.
포퓰리즘은 이것 뿐만이 아닙니다. '좋은 것이 좋은 것이다'라는 자세로 부하에게 따끔한 질책을 하지 않는 리더도 '인기영합'이라는 포퓰리즘에 빠진 리더입니다. 잘못을 해도, 태만해도 질책하지 않는 가운데, 다른 정상적이고 능력있는 직원들은 깊은 좌절에 빠집니다.
리더는 포퓰리즘에 빠져서는 안되고 조직원들을 캐어(care)해야 합니다. 직원이나 국민에게 다가가서 그들이 필요로하는 것, 원하는 것이 무엇인지 파악하고 그 문제들을 해결해주는 리더.
자기 개인의 인기가 아닌, 그들의 입장에서 항상 고민하기에 그는 조직에게 이익이 되는 올바른 길을 걸어갈 수 있습니다.
진정한 리더는 포퓰리즘(populism)이 아니라 캐어(care)에 있습니다.
|
|
Are you still hungry? 2005년 5월 16일 월요일
Are you still hungry?
(예병일의 경제노트, 2005.5.16)P&G의 최고 직원들은 명석하고 의견이 분명하며 일에 열심이고 의지가 굳으며 부지런하고 창의적이다.
그러나 이 모든 특징을 한 가지로 집약해서 표현한다면, 이들은 승리를 갈구한다.
승리는 다음번에 대박을 터뜨릴 제품이나 브랜드를 개발하는 것만이 아니다. 물론 이것도 언제나 중요한 목표이기는 하다.
그러나 승리란 점진적인 성과, 전반적인 비용의 상당한 절감, 경쟁을 통해 라이벌의 몫을 뺏는 것 등을 가리키기도 한다.
P&G는 직원들에게 경쟁적인 업무 태도를 장려해왔고, 작은 성과라도 꾸준히 이루어낼 수 있는 지원 제도 및 정책을 개발해왔다.
"I'm still hungry."
우리에게 깊은 인상을 남겼었던 거스 히딩크.
얼마전 TV 화면에서 본 그는 역시 인상적이었습니다.
"나는 여전히 배가 고프다." 중요한 경기에서 승리한 직후 가진 인터뷰에서 그는 이렇게 말하고 있었습니다.
당신은 지금 배가 고프다는 자세로 일에 임하고 있습니까? '헝그리 정신'으로 무장해 있나요?
70, 80년대만 해도 우리는 '헝그리 정신'이라는 단어를 많이 들으며 생활했습니다. 맨주먹 밖에 없는, 하지만 헝그리 정신으로 무장한 한 청년이 권투로 세계 챔피언이 되는 것도 보았고, 역시 헝그리 정신으로 가득 찬 학생이나 기업가들이 자신의 분야에서 커다란 성취를 하는 모습도 많이 목격했습니다.
하지만 어느샌가 우리는 이런 '헝그리 정신'이라는 단어를 자주 듣지 못하게 됐습니다.
평소에 승리를 갈구하는 사람만이 작은 성과, 점진적인 성과를 낼 수 있고, 그런 사람만이 커다란 성취를 이룰 수 있습니다.
"Are you still hungry?"
|
|
당신은 목표가 무엇입니까? 2005년 5월 6일 금요일
당신은 목표가 무엇입니까?
(예병일의 경제노트, 2005.5.6)목표를 가지고 있는 사람은
*집중력을 단련시켜 수많은 사건 속에서 기회를 발견한다.
*먼저 우선 순위를 정하고 자신의 에너지와 수단을 적절하게 분배시키는 데 집중한다.
*우리의 앞길을 가로막고 우리의 의식을 마비시키는, 겉으로만 중요해 보이는 진부한 것들을 보다 쉽게 포기할 수 있다. 또한 이때 수반되는 유혹에 대해 보다 쉽게 "아니오"라고 말할 수 있다.
목표가 뚜렷해야 집중력도 생깁니다. 그리고 무엇에 집중해야 기회도 보입니다.
목표가 뚜렷해야 여러가지 일들 중에 무엇이 더 중요한지 우선순위를 정할 수 있습니다. 우선순위가 정해져야 한정된 나의 자원을 적절하게 분배할 수 있지요.
목표가 뚜렷해야 다른 것들을 포기할 수도 있게됩니다. 유혹이 말을 걸어와도 무시하기 쉽습니다.
목표가 뚜렷해야 동기부여도 됩니다. 내가 진정 원하는 것이 분명하게 앞에 있다면, 기쁜 마음으로 자발적으로 뛰어들 수 있습니다.
목표가 뚜렷해야 어려움이 와도 극복하기 쉽습니다. 그래야 실패하더라도 스스로를 추스리고 다시 시도할 수 있습니다.
당신의 목표는 무엇입니까?
|
|
망치형 인간, 모루형 인간 2005년 5월 9일 월요일
망치형 인간, 모루형 인간
(예병일의 경제노트, 2005.5.9)괴테는 이렇게 말했다. 인간은 망치가 될지 모루(단 쇠를 놓고 두드리는 판)가 될지 결정을 내려야 한다고.
직장에서 기대할 것이라고는 월말에 송금되는 월급밖에 없다고 생각하는 사람은 자신을 일찌감치 모루로 만들어 버린 사람이다. 그의 머리 위로 일상이라는 망치가 가차없는 공격을 해댈 것이다.
그런가 하면 우리가 살고 있는 사회에는 망치(보스)가 되기 위해서 위를 향해 돌진하는 사람들도 수없이 많다.
직장생활에서 결정을 내리고 책임을 질 것인가, 아니면 다른 사람이 생각해 낸 일을 시키는 대로 따르기만 할 것인가를 선택해야 한다.
대장간에 망치와 모루가 있습니다.
모루는 작업할 재료를 올려놓는 대(臺)를 말합니다. 모루에 재료를 올려놓고 망치로 두드립니다.
직장에서, 아니 인생에서 망치가 될 것인가 아니면 모루가 될 것인가.
삶을 주도적으로 이끌어갈 것인가에 대한 이야기입니다.
같은 신입사원 중에도 '망치'로 살아가는 사람과 '모루'로 살아가는 사람이 있습니다. 주어진 여건속에서 적극적으로 자신의 일을 찾아, 만들어 하는 사람이 있고, 그저 시키는 일, 주어지는 일만 처리하겠다는 자세로 지내는 사람이 있습니다.
이런 '망치' 신입사원과 '모루' 신입사원의 미래는 당연히 엄청난 차이가 나게 마련입니다.
신입사원뿐 아니라, 팀장도, 임원도, 학생도 마찬가지입니다.
모루가 아니라 망치가 되어봅시다.
적극적이고 주도적인 '망치형 인간'만이 보람과 성취를 이룰 수 있습니다.
|
|
2005년 5월 4일 수요일
리더, 움직이지 않는 거울 같은 마음
(예병일의 경제노트, 2005.5.4)'장자'는 이상적인 리더상에 대해 다음과 같이 말한다.
"역경에도 불만을 품지 않고 영달을 기뻐하지도 않고 만사를 있는 그대로 맡기며 작위를 부리지도 않는다. 실패해도 걱정하지 않고 성공해도 의기양양해하지 않는다."
또한 이렇게 말한다.
"마음은 거울 같은 것이다. 자신은 전혀 움직이지 않는다. 오는 것은 그대로 비추지만, 떠나버리면 어떤 흔적도 남기지 않는다. 따라서 어떤 사태에도 대응할 수 있으며 또한 상처도 입지 않는다."
중국의 고전 '장자'.
'장자'에서 그려지는 이상적인 리더는 자신의 능력으로 천하를 제대로 다스리지만, 일반인의 눈에는 잘 드러나지 않고 오히려 무능하게 보이는 모습입니다. 무언의 설득력으로 사람들을 감화시키는 리더입니다.
지금 이 시대의 이상적인 리더상과는 일부 맞지 않는 부분이 있을 수도 있지만, '장자'의 시각에서 배울 점도 많습니다.
리더는 역경에 부딪치거나 실패하더라도 걱정하거나 좌절하지 않습니다. 반대로 커다란 성공을 거두어도 의기양양해하지 않지요.
그런 리더의 마음은 움직이지 않는 '거울'입니다. 역경이 오건 성공이 오건, 그것을 있는 그대로 비추고, 또 그것들이 떠나버리면 또 없는 그대로를 비춥니다.
이런 흔들림 없는 리더의 자세는 21세기를 살아가는 우리에게도 반드시 필요한 덕목인 듯합니다.
|
|
2005. 5. 4. 08:54, Programming/.Net
[기업 환경에 닷넷 적용하기] ① 프리젠테이션 레이어 설계 연재순서
1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용 닷넷은 아직도 ‘정말 큰 규모의 응용 프로그램의 동작은 어려운’ 환경으로 인식되고 있다. 하지만 실제로는 그렇지 않다. 닷넷은 거대한 기업에서도 힘을 발휘할 수 있는 환경이다.
이 연재에서는 닷넷 플랫폼에서 기업형 환경을 쉽게 구축할 수 있도록 해주는 구조와 그 구조에 맞는 설계를 도와주는 기업형 응용 프로그램 패턴에 대해 기업형 구조와 설계 패턴을 중심으로 기업형 아키텍처와 엔터프라이즈 디자인 패턴에 대해 설명하는 것을 목적으로 한다.
IT 기술은 다른 어떤 공학 기술과 비교할 수 없을 정도로 빠르게 진화한다. 객체지향 기술이 끝인가 싶더니, 컴포넌트 기반 기술, MDA(Model Driven Architecture), SOA(Service Oriented Architecture) 등 수없이 많은 새로운 것이 등장하고 또 없어지기를 반복한다. 현재로서는 실무에 가장 잘 적용되는 기술로 CBD(Component Based Development)가 각광받고 있고, 실무에서도 CBD를 개발에 적용하려 하지만, 경험이 부족한 많은 개발자들은 이런 CBD를 어떻게 개발에 적용해야 할지 막막한 경우가 대부분이다.
제대로 된 CBD를 위해서는 기반 아키텍처를 구성하는 것이 제일 중요하다. 기업형 응용 프로그램에서 CBD를 제대로 하기 위한 아키텍처를 설계하는 방법이 제일 좋다. 하지만, 아키텍처 설계에는 많은 비용과 시간이 소모되므로 신뢰할 만한 기업에서 미리 설계해 놓은 아키텍처를 기반으로 새 아키텍처를 구성하거나 또는 기 설계된 아키텍처를 기반으로 응용 프로그램을 구성하는 것이 일반적이다.
‘어떤 컴포넌트를 만들어야 하는가?’에 대한 올바른 가이드라인을 제시해주는 아키텍처를 찾아 제대로 적용하는 것이 중요하다 할 수 있는데, MS에서 제시하는 엔터프라이즈 솔루션 아키텍처(Enterprise Solution Architecture)는 닷넷 기반 기업형 응용 프로그램을 작성할 때 기반이 될만한 가장 좋은 구조라 할 수 있다.
자바의 아성에 대한 도전
지난 98년, 썬 마이크로시스템즈는 당시 각광받던 자바의 여러 기술들을 확장해 기업 환경에서 신뢰성 있게 동작할 수 있는 기업형 분산 트랜잭션 지원 시스템인EJB를 발표했다.
EJB는 거대한 기업형 응용 프로그램에서 반드시 필요한 기술들인 분산 트랜잭션, 이기종 데이터베이스 분산질의, 원격 프로시저 호출 등의 구현을 지원하는 기업 환경이었고, 자바가 주로 동작하는 운영체제인 유닉스가 탁월한 안정성을 보장하는 신뢰성 있는 운영체제였다. 이런 여러 장점들과 경쟁상대로 꼽을만한 기업형 응용 프로그램 개발 환경이 당시로서는 드물었으므로 EJB는 IT 시장에서 독보적이기까지 한 존재로 성장했다.
MS의ASP는 서버 사이드 스크립트 역사상 가장 성공한 개발 환경이다. 1998년 윈도우 NT의 옵션팩에 포함되어 배포된 ASP 2.0은 세계적으로 3000만 명의 프로그래머들을 양산하며 웹 프로그래밍 환경에서 가장 많이 사용되는 서버 사이드 프로그래밍 환경이 되었다.
하지만 ASP와MTS,COM등 3가지 프로그래밍 환경이 주를 이루던 MS의 개발 환경은 기업 시장에서 힘을 발휘하기에는 자바와 비교하여 역부족이었다. 간단하지만 재사용성이나 가용성적인 측면에서 객체지향 언어를 기본으로 하고 컴포넌트 기술을 기반으로 하는 자바와 비교할 때, 그리고 MS의 개발 환경이 동작하는 윈도우 NT가 유닉스와 비교할 때 안정성과 신뢰성 측면에서 많은 불안 요소와 개발 지연성을 가지고 있었기 때문이다.
MS는 이에 대응하여 닷넷이라는 새로운 프로그래밍 환경을 발표했다. IT 시장의 흐름에 발 빠르게 대응해 기업 시장에서 자바의 아성에 도전하려는 듯 재사용성 및 가용성, 교체 가능성 등 자바의 장점들을 모두 가지려는 시도였다. 더 쉬운 프로그래밍과 변화하는 비즈니스 환경에 좀 더 손쉽게 대응할 수 있는 컴포넌트를 가진 닷넷은 패키지 응용 프로그램이나 소규모의 웹 응용 프로그램 등에 사용되던 이전 환경에서 벗어나 기업에서 MS 로고가 힘을 발휘할 수 있는 여건을 마련했다.
이는 MS가 2000년에 발표한 윈도우 2000 서버 제품군의 탁월한 성능이 큰 힘을 발휘했다. 닷넷 환경은 자바에 대응할 수 있는 대규모 기업형 응용 프로그래밍에 적합하게 설계되었고, 신뢰성 있게 동작하며, 쉬운 프로그래밍 인터페이스와 발전된 프레임워크를 가지고 있는 기업형 응용 프로그램 제작/배포 환경이다.
닷넷은 거의 모든 코드를 관리되는 환경에서 작성할 수 있기에 운영체제의 API에 직접 액세스하는 등의 위험요소를 줄일 수 있고, 컴포넌트 기반 프로그래밍 환경으로 구성되어 높은 재사용성과 교체 가능성 및 유지 보수성을 기대할 수 있게 구성되었다. 항상 하는 말이지만 닷넷 환경은 MS가 실로 오랜만에 만들어낸 ‘작품’이다.
하지만 환경이 제아무리 훌륭하다 하더라도, 그것에 걸 맞는 훌륭한 응용 프로그램의 작성은 힘들기 마련이다. 기반 아키텍처를 구성하고, 그 기반으로 프로그램을 작성한다는 것은 몇 권 분량의 책이나 몇 주 분량의 기사로 설명할 수 있는 것이 아니다.
또한 CBD라는 것이 양날의 검이 될 수 있는 것이기에 실제 프로그램을 작성하는 시간이나 비용보다 기반 프레임워크가 아키텍처를 구성하는 데 걸리는 시간이 훨씬 많이 소모될 수 있다. 이런 문제에서 본다면 프로그래밍 환경에서 중요한 것은 기반 구조가 아니라 생산성이 될 수 있다.
닷넷은 그 어떠한 프로그래밍 환경보다 생산성이 뛰어나지만 그것만으로는 한계가 있다. 한정된 인력이 거대한 규모의 프로젝트를 진행할 때, 또는 한정된 인력으로 구성된 회사가 여러 프로젝트를 동시에 진행할 때가 대표적인 경우다. 제대로 설계된 아키텍처는 프로그래밍의 길잡이 노릇을 해 줄 뿐만 아니라, 프로젝트를 성공적으로 이끌 수 있는 이정표 역할을 해 준다.
컴포넌트는 '어떻게' 구성돼야 하는가?
시작한 프로젝트가 CBD라고는 하는데, 이 CBD라는 것이 애매모호한 경우가 많다. 특히 ASP 개발자라면 페이지에다 로직을 프로그래밍하고 실행해보고 테스트해보고 성공하면 배포하고 돌아가지 않는다면 디버깅하고 하는데 익숙하다. 그리고 작성한 페이지의 데이터베이스 액세스 로직 등을 비주얼 베이직 등을 이용해 COM 컴포넌트로 컴파일해서 ASP 페이지에서 CreateObject 메쏘드를 호출해서 사용하는 것 정도도 익숙하다.
하지만 이 CBD라는 것이 어떤 컴포넌트를 어떻게 만들어서 어떻게 조립해서 사용해야 하는 것인지에 대한 경계가 모호하다. N-티어 구조니,MVC모델이니 하는 말은 지겹도록 많이 들었지만, 막상 프로그래밍에 그런 구조를 응용하려면 생각대로 잘 되지 않는 경우가 많다.
이런 경우에 필요한 것은 컴포넌트를 ‘어떻게’ 만들어야 할지가 문제가 아니다. ‘어떤’ 컴포넌트를 만들어야 할지에 대한 결정이 급선무가 된다. 정립되어 있는 아키텍처는 이런 질문에 대한 답을 보여준다. 일반적으로 거의 모든 엔터프라이즈 아키텍처는 <그림 1>과 같은3단계 계층으로 구성된다. 지겹도록 보아왔지만 실제 응용 프로그램 작성에는 그다지 도움이 되지 않았던 그림이다.
사실, <그림 1>은 CBD 기반 개발에서 어떠한 컴포넌트를 작성해야 하는지를 명확하게 보여준다. 애플리케이션 개발에서 약식 구조도로 가장 많이 사용되는 <그림 1>은 응용 프로그램이 재사용성을 가지기 위해 어떻게 설계되어야 하는 지에서부터, 컴포넌트의 동작범위, 컴포넌트의 종류, 컴포넌트의 개수까지도 개념 차원에서 정리할 수 있는 아키텍처 구조이다. 응용 프로그램 작성에서 그다지 도움이 되지 못했던 이유는 개발자들이 각 레이어에 존재하는 컴포넌트들의 역할을 명확하게 파악하지 못해서이다.
개발자들은 각각의 레이어가 소프트웨어 컴포넌트의 논리적인 구분이라는 것을 알고 있다. 하지만 그 ‘논리적인’ 이라는 것의 사전적 의미(특히 한글로 번역했을 때의 모호함)와 조금의 거리가 있기 때문에 이러한 구조에 처음 접해보는 개발자는 <그림 1>의 아키텍처에서 프리젠테이션 레이어에 위치하는 컴포넌트를 어떻게 작성해야 하는지 감이 잘 잡히지 않기 마련이다.
역할 구분이 모호한 컴포넌트 문제
어떤 컴포넌트가 어디까지의 역할을 담당해야 하는지에 대한 구분이 모호할 때, 다음과 같은 컴포넌트가 나올 수도 있다. 실제로 <리스트 1>과 같이 작성되어 동작하는 컴포넌트를 본 적이 있고 사용도 하고 있다.
| <리스트 1> 프리젠테이션, 비즈니스 엔티티, 데이터 서비스가 혼재된 UI 컴포넌트 |
| |
|
using System;
using System.Data;
using System.Data.SqlClient;
using System.Web.UI.WebControls;
// 전체 프로젝트에서 공용으로 사용하는 컨트롤 네임스페이스
namespace CommonControls {
// 이름을 보면 알 수 있다. 학과 정보를 표시하는 드롭다운 리스트이다.
// 드롭다운 리스트 클래스를 상속하여 확장했다.
public class DepartmentDropDownList : DropDownList {
DataSet myDataSet = new DataSet();
// 객체 생성자
// 데이터베이스에 액세스하여 데이터를 자신에 바인딩한다.
public DepartmentDropDownList () : base() {
SqlDataAdapter myAdapter = new SqlDataAdapter("Select objectID, objectValue from objects", new SqlConnection());
myAdapter.Fill(myDataSet);
this.DataSource = myDataSet.Tables[0];
this.DataBind();
}
protected override void OnSelectedIndexChanged(EventArgs e) {
...
}
}
}
|
| |
|
작성한 컴포넌트를 눈여겨 살펴보면 3계층의 모든 요소들이 하나의 논리적/물리적인 컴포넌트에 모여 있음을 알 수 있다. 이렇게 작성된 컴포넌트를 웹 페이지에 끼워 넣고 동작시켜도 전혀 문제가 없다. 이런 기법은 많이 쓰여 왔고, 하나의 컴포넌트가 모든 동작을 다 구현함으로서 구조가 간단해지고 사용자 인터페이스(이하 UI) 컨트롤을 가져다 쓰는 페이지의 코드를 줄일 수 있다는 장점 등도 가질 수 있다.
간단한 프로그램을 작성할 때, 확장성을 고려하지 않은 소규모의 UI 중심 응용 프로그램을 작성할 때는 이런 프로그래밍 방식도 고려해 볼만하다. 하지만 기업형 응용 프로그램이라면 당연히 이야기가 달라진다. 기업형 응용 프로그램에서 앞의 구조로 프로그램을 진행한다는 것은 위험요소가 아주 많은, 재사용성을 전혀 고려하지 않은 위험한 방법이다.
이와 같은 드롭다운 리스트 컨트롤을 네임 스페이스 이름에 걸맞게 공용 컴포넌트로 선언했다고 가정해 보자. 필자가 본 실제 동작하며 현업에 사용되는 <리스트 1>과 같은 구조의 UI 컴포넌트가 사용된 시스템은 꽤 큰 규모의 사원 관리 시스템이었는데, 새 사원이 가입했을 때 사원의 급여를 책정하는 페이지에는 사원의 국민연금 가입여부, 사학 연금 가입 여부, 의료 보험 등급 등을 결정하는 10여 개의 드롭다운 리스트가 포함되어 있었다.
문제점을 살펴보자. 우선, 데이터베이스에 연결하는 부분이다. 각각의 드롭다운 리스트 컨트롤은 직접 데이터베이스에 연결하는 코드를 가지고 있다.
한 페이지에 10개의 드롭다운 리스트 컨트롤이 삽입됐다는 페이지는 사원의 상세 정보를 가져오는 두세 개의 쿼리를 실행하는 연결 이외에 각각의 드롭다운 리스트가 가진 데이터베이스 연결을 가지고 있다. 최소한 하나의 페이지가 11개의 데이터베이스 연결을 가지고 있다는 뜻이 된다.
<리스트 1>과 같이 구성된 컴포넌트가 페이지에 삽입됐다면 하나의 데이터베이스 연결이 여러 개의 쿼리를 실행하여 각각의 컨트롤에 바인딩하는 아주 당연한 연결 기법을 사용할 수 없게 된다. 데이터베이스 연결이 커넥션 풀링을 사용하고 있다면, 10명 정도의 사용자가 같은 페이지에 액세스하여 여러 개의 페이지 리로드를 10번씩만 하면 100개의 커넥션이 생기게 된다. 커넥션 풀에 각각의 커넥션이 30초 동안 유지된다고 하면, 각 사용자가 드롭다운 리스트의 항목을 바꾸면서 작업을 계속하게 되면, 웬만한 커넥션 풀은 꽉 찬 커넥션을 감당하지 못하고 뻗게 된다.
다음 문제는, 각각의 컨트롤이 상호작용하도록 프로그램을 구성하기가 힘들다는 점이다. 만약 사용자가 국민연금에 가입하고 있다면 사학연금에는 가입하지 못한다. 하나의 드롭다운 리스트가 사용자의 연금 종류를 표시하고 있다. 다른 드롭다운 리스트가 국민연금의 연금 보험료를 표시하고 있다면, 또는 연금 종류를 표시하는 드롭다운 리스트의 항목이 변경되면 컨트롤을 통째로 바꿔야 한다.
실제로 동작하는 프로그램은 페이지에 드롭다운 리스트를 40개쯤 포함시켜 놓고 컨트롤의 항목이 변경되면 컨트롤의 Visible 속성을 변경하여 숨기고 보여주고 하는 기법을 사용했다. 페이지가 무거워질 뿐더러, 데이터베이스 커넥션 풀에서의 문제는 더욱 심각해지고, 리소스를 낭비하게 된다.
전체 응용 프로그램에서 드롭다운 리스트가 표현해야 하는 항목이 한두 개 밖에 되지 않는다면 <리스트 1>과 같은 기법을 사용해 볼 수도 있겠지만, 수많은 항목을 표현하는 드롭다운 리스트가 필요한 기업형 응용 프로그램에서는 이와 같은 방법을 써서는 전체 응용 프로그램이 너무 무거워지고, UI 컴포넌트의 개수가 너무 많아질 뿐더러 여러 문제가 발생하게 된다. <리스트 2>는 문제를 조금 개선한 드롭다운 리스트이다.
|
public class DepartmentDropDownList : DropDownList {
string tableName = "";
DataSet myDataSet = new DataSet();
// 객체 생성자
// 객체가 생성될 때 페이지에서 지정한 테이블에 액세스할 수 있도록 코드가 수정되었다.
public DepartmentDropDownList () : base() {
SqlDataAdapter myAdapter = new SqlDataAdapter("Select objectID, objectValue from "+ this.tableName, new SqlConnection());
myAdapter.Fill(myDataSet);
this.DataSource = myDataSet.Tables[0];
this.DataBind();
}
// 컨트롤이 액세스할 테이블의 이름을 컨트롤이 삽입될 페이지에서 지정할 수 있도록 한다.
public string TableName {
get {return this.tableName;}
set {this.tableName = value;}
}
...
}
|
| |
|
이 코드를 수정했다고 해도, 근본적인 문제는 해결되지 않는다. 데이터베이스 연결 및 커넥션 풀 문제는 여전히 지속되며, 컨트롤 간의 상호작용을 구성하기 위해서는 상당히 많은 라인의 코드를 작성해야만 한다. 하고 싶은 말은 이와 같은 방법으로 프로그래밍하면 안 된다는 것이다.
역할 구분은 분명히 해야 한다
엔터프라이즈 솔루션 아키텍처는 여기서 출발한다. 조금 냉정하게 말하자면, 지금까지 언급한 코드를 쓴 개발자라면 객체지향의 기본부터 다시 시작해야 할 것이다. 엔터프라이즈 아키텍처는 기본적으로 MVC의 구조를 가지고 있어서 모델(객체)과 뷰(컨트롤)의 역할이 완벽하게 구분돼야 한다.
3-티어 아키텍처를 기반으로 프로그래밍한다면, <리스트 1>과 <리스트 2>에서 작성한 컨트롤의 동작은 3단계 계층에 존재하는 컴포넌트를 모두 사용해야 한다는 결론이 나온다. 각 레이어에는 <그림 2>와 같은 개체(컴포넌트)들이 동작해야 한다.
보기에 컴포넌트 구조가 복잡해지고 컴포넌트 토폴로지가 증가할 것 같지만 이 구조를 따라 프로그래밍을 한다면 앞서 언급한 모든 문제가 해결된다. 우선 데이터베이스 연결 문제는 모든 데이터베이스의 연결을 데이터 레이어 계층의 컴포넌트에 위임함으로써 하나의 연결을 사용한다거나 또는 풀링을 사용하지 않는 등 일관된 정책을 유지할 수 있다. 또한 모든 드롭다운 리스트는 바인딩되기 전까지 데이터를 표현하는 DataSet 개체로부터 자유로우므로 드롭다운 리스트 간의 상호작용을 구성할 수 있다.
이런 3-티어 아키텍처는 응용 프로그램의 구성에 있어 많은 탄력성을 제공해 줄 수 있다. 페이지의 변경을 감시하는 옵저버(observer)나 UI 컴포넌트들의 상호작용을 관리해주는 메디에이터(mediator)를 구성한다거나 하는 등의 설계 계선을 꾀할 수 있다. 따라서 유연한 구조의 재사용성과 교체 가능성, 유지 보수성이 뛰어난 응용 프로그램을 만들 수 있게 된다.
엔터프라이즈 솔루션 아키텍처를 기반으로 한 응용 프로그램을 개발하기 위해 개발자는 다음 사항을 반드시 지켜야 한다.
◆ 수직적 관계의 모든 컴포넌트들은 느슨한 결합 관계를 가져야 한다. 예를 들면, 프리젠테이션 계층에 존재하는 특정 컨트롤이 자신을 표현하는 데이터를 가지고 있거나 다른 특정한 컴포넌트를 반드시 필요로 하는 구조여서는 안 된다.
◆ 비즈니스 컴포넌트는 자신을 보여줄 수 있는 공통된 방법을 가지고 있어야 한다. 비즈니스 계층의 컴포넌트에 포함된 개체가 프리젠테이션 계층에서 보여져야 할 경우 특정한 일관된 규칙을 가져 같은 방법으로 보여질 수 있어야 한다.
◆ 데이터베이스 연결은 일관되며 공통된 규칙을 지킬 수 있도록 집중화되어야 한다. 모든 비즈니스 컴포넌트들은 일관된 규칙으로 데이터베이스에 액세스할 수 있도록 구성되어야 한다.
| | 이전 버전의 MS 환경에서는 OCX이건 액티브X이건 모듈이건 간에 독립적으로 컴파일된 유닛은 모두 컴포넌트라고 불러서 현재 문맥에서 말하는 컴포넌트가 어떤 것을 말하는지 헷갈릴 때가 많았다. 닷넷 환경이 나오면서 이러한 혼란을 줄이기 위해 어셈블리(assembly)라는 용어를 등장시켜 문맥상에서 말하는 컴포넌트의 종류를 쉽게 구분할 수 있도록 했다.
일반적으로 컴포넌트라는 용어는 전체 솔루션에서 일부분이거나 또는 각각의 조각(부품)이라는 의미로 사용된다. 어셈블리나 액티브X 같은 컴파일된 유닛, 웹 페이지, 웹 서비스, 비즈토크 오케스트레이션 등 모든 결합될 수 있는 응용 프로그램의 부품을 컴포넌트라고 부른다.
|
|
|
| |
| |
어떤 컴포넌트를 만들어야 하는가?
3-티어 아키텍처로는 2% 부족하다고 느낄 것이다. 응용 프로그램 또는 서비스는 다른 종류의 작업을 수행하는 여러 컴포넌트들로 구성된다. 복잡한 기업형 응용 프로그램이라면 수백 개의 컴포넌트로 구성된다. 하지만 앞에서 살펴봤듯이 수없이 많은 컴포넌트는 사용자의 요구와 관계없이 비슷한 종류의 컴포넌트로 구성되는 경우가 대부분이다. 3-티어 아키텍처는 그런 비슷한 종류의 컴포넌트를 구별할 수 있게 하지만, 조금 더 세분화하여 분류할 수 있다.
<그림 3>은 완벽히 분류되지는 않았지만, 대부분의 대규모 응용 프로그램에서 공통적으로 사용되는 일반적인 컴포넌트의 유형을 보여준다. 그다지 친절해 보이지는 않지만, 자세히 들여다보면 응용 프로그램의 아키텍처를 어떻게 구성해야 하는지를 한눈에 보여주는 그림이라 할 수 있다(MSDN 웹사이트에서는 이러한 그림이나 문서를 쉽게 찾아볼 수 있다).
<그림 3>은 대규모의 응용 프로그램에서 공통으로 사용되는 일반적인 컴포넌트의 유형을 잘 설명하고 있다. 한 장의 그림이긴 하지만 각각의 컴포넌트가 어떻게 동작해야 하느냐에 대한 물음, 예를 들면 UI 프로세스 컴포넌트 단계를 구성하는 컴포넌트는 어떤 동작을 해야 하는지, 어떻게 구성돼야 하는지에 관련된 의문을 명확하게 설명해 주지는 못한다. MSDN 웹사이트나 gotdotnet 웹사이트에서 설명을 찾아볼 수 있다. UI 컴포넌트가 어떤 구성을 가져야 하는지, 어떤 컴포넌트여야 하는지에 대한 설명은 다음과 같다.
"대부분의 솔루션들은 사용자가 애플리케이션과 상호작용할 수 있는 방법을 제공할 필요가 있다. 소매 애플리케이션의 예제에서 고객들은 웹 사이트를 통해 상품을 보고 주문할 수 있다. 판매 대리인은 윈도우 운영체제 기반의 애플리케이션을 이용해 회사로 전화를 건 고객의 주문 데이터를 입력할 수 있다. 사용자 인터페이스는 사용자를 위한 데이터 포맷을 지정하고 제시하며 사용자들로부터 입력될 데이터를 요구하고 검증하기 위해 윈도우 폼, ASP.NET 페이지, 컨트롤 혹은 그 밖의 다른 기술을 이용해서 구현된다."
아키텍처에 대한 기본 지식이 있는 개발자라면 이 간단한 설명으로도 이해할 수 있겠지만, 아키텍처 기반 개발 경험이 없는 개발자이거나 처음 공부하는 사람이라면 더 헷갈릴 수 있는 가능성이 크다. 필자가 강의를 진행할 때(특히 디자인 패턴이나 추상화 기법들을 강의할 때) 수강자들이 어려운 이론을 들으면 반드시 하는 말이 "코드를 보여주세요"라는 것이다. 정말, ‘백문이 불여일견’이라는 속담이 여기서도 통하게 되는데, 백번 말로 설명해도 이해 안가는 경우에는 아키텍처를 기반으로 작성된 애플리케이션의 예제를 한번 보는 것이 설명을 백번 듣는 것보다 훨씬 더 도움이 된다.
MS는 이전에 J2EE 기술과 성능 비교에서 펫샵(Petshop) 응용 프로그램을 사용해 자사의 환경 성능을 테스트했는데, 이 펫샵이라는 응용 프로그램은 엔터프라이즈 솔루션 아키텍처에 기반하여 작성되었다. 말이나 그림으로 잘 이해되지 않는 독자라면 당장에 MS 웹사이트에 접속해 펫샵 3.0을 컴퓨터에 설치하고 코드를 살펴보기 바란다.
이해가 가는 독자라도 코드를 보는 것이 훨씬 도움이 된다. 물론, 코드만 본다고 되는 것은 아니고 그림과 코드를 비교해가면서 살펴보는 것이 좋다.
펫샵 3.0을 설치하고 비주얼 스튜디오 닷넷을 사용해 코드를 볼 준비가 됐다면, 이제부터 아키텍처에 기반한 애플리케이션이 어떻게 작성되고 동작하며, 각 컴포넌트는 어떻게 작성되고 구성되며 어떤 역할을 해야 하는지를 알아보도록 하자. 이번 연재에서는 프리젠테이션 계층 컴포넌트가 어떻게 구성되는지에 대해 알아본다(비즈니스 컴포넌트와 데이터 액세스 컴포넌트는 다음 호에 알아보도록 한다)
프리젠테이션 계층 구조와 설계
<그림 2>에 나타나 있는 구조에서 프리젠테이션 계층을 구성하는 부분은 <그림 4>와 같다. 프리젠테이션 계층에는 UI 컴포넌트와 UI 프로세스 컴포넌트, 두 종류의 컴포넌트가 존재한다.
UI 컴포넌트는 말 그대로 사용자와 상호 작용하는 객체들이 모인 물리적 객체 집합이다. 이 계층에는 System.Windows.Forms 네임스페이스의 개체들과 System.Web.UI 네임스페이스의 개체들이 존재한다. 웹 기반 응용 프로그램이라면 TextBox 컨트롤, Button 컨트롤, DropDownList 컨트롤, DataGrid 컨트롤 등 ASP.NET 페이지에 직접 붙여 넣는 컨트롤들이 모두 이 범주에 속한다고 볼 수 있다.
UI 컴포넌트
UI는 크게 세 가지 역할을 수행해야 한다. 첫 번째 역할은 사용자에게 데이터를 보여주는 것이다. 예를 들면 현재 로그인한 사용자의 이름을 보여주기 위해 Label 컨트롤을 사용하거나 상품의 목록을 보여주기 위해 DataGrid 컨트롤을 사용하는 등이다.
여기서 주의해야 할 점은 Label 컨트롤에 로그인한 사용자의 이름을 보여주기 위해 Label 컨트롤을 수정해 Label 컨트롤이 직접 HttpContext 개체나 Cookie 등에 액세스하지 않는다는 것이다. Label 컨트롤이나 DataGrid 컨트롤은 단지 어떤 데이터를 받아들여서 표시할 수 있는 역할만을 해야 한다.
두 번째는 사용자의 입력을 받아들이고 입력된 데이터를 하위 컴포넌트에 전달하는 역할이다. 입력된 데이터를 하위 컴포넌트에 전달하기 위해서는 함수를 호출해야 한다. 하지만 사용자의 이벤트를 받아들이는데 있어 가장 많이 사용되는 버튼 컨트롤이 이러한 함수를 직접 호출하는 형태여서는 안된다. 사용자의 입력을 받아들이는 UI 컴포넌트는 단지 속성과 이벤트만을 가지고 있을 뿐, 직접적인 함수의 호출 로직을 가지는 것은 금물이다.
세 번째는 입력된 데이터를 사용자가 검증하는 역할이다. 사용자가 입력한 데이터가 정수형인지, 날짜인지 등의 애플리케이션 내에서 유효한 값인지를 검증할 수 있는 클라이언트 수준에서의 로직이 필요하다. 종합해 보면, 로그인한 사용자의 이름을 웹 페이지에 보여주는 UI는 <그림 5>와 같이 작성되어야 한다.
UI 컴포넌트는 사용자에게 데이터를 보여주고 사용자 입력 데이터를 검증하고 백앤드로 요청하며 사용자가 데이터에 수행하고자 하는 작업을 알려주는 등 사용자 행위를 검증하는 역할을 담당한다. 그리고 또 중요한 것은 UI는 사용자가 특정 시점에 특정 작업만을 수행하도록 행위를 제한할 수 있어야 한다. 다시 종합하여 생각해보면 UI 컴포넌트는 다음과 같은 사항들을 준수해야 한다.
◆ 트랜잭션을 생성하거나 또는 트랜잭션에 참여하거나 트랜잭션을 지원해서는 안된다.
◆ 데이터를 표시하기 위해서는 UI 프로세스 컴포넌트를 참조하거나 하위 계층의 컴포넌트를 참조해야 하지 자신이 직접 데이터를 포함하고 있으면 안된다.
◆ 사용자에게 데이터를 받아들이는 작업을 위한 시각화된 신호와 검증을 지원해야 하며 사용자의 요구에 적절한 컨트롤을 제공한다.
◆ 사용자 이벤트가 발생됐을 때 이를 컨트롤러에 전달하여 컨트롤러의 함수를 호출할 수 있어야 한다.
참조 구현 모델인 펫샵에서 UI가 어떻게 구성되어 있는지 살펴보도록 하자. 펫샵은 <그림 6>과 같은 로그인 사용자 인터페이스를 가지고 있다.
로그인 사용자 인터페이스를 구성하는 Signin.aspx 페이지의 뷰를 구성하는 html 소스의 일부는 <리스트 3>과 같다.
| <리스트 3> Signin UI의 View를 구성하는 html 코드 |
| |
|
<%@ Register TagPrefix="PetsControl" TagName="NavBar" Src="Controls/NavBar.ascx" %>
<%@ Page Language="c#" CodeBehind="SignIn.aspx.cs" Inherits="PetShop.Web.SignIn" EnableSessionState="true" AutoEventWireup="false" %>
<HTML>
<HEAD>
....
<!--사용자 입력을 받아들이는 Form -->
<form id="frmSignIn" runat="server" method="post">
<table cellpadding="1" cellspacing="0">
<tr>
<td class="label">User ID:</td>
<td>
<! -- 적절한 사용자 입력 컨트롤 -->
<asp:textbox id="txtUserId" runat="server" text="DotNet" columns="15" maxlength="20" />
<!-- 입력된 값 검증 -->
<asp:requiredfieldvalidator id="valUserId" runat="server" controltovalidate="txtUserId" errormessage="Please enter user ID." enableclientscript="False" />
</td>
</tr>
<tr>
<td class="label">Password:</td>
<td>
<asp:textbox id="txtPassword" runat="server" value="DotNet" columns="15" maxlength="20" textmode="Password" />
<asp:requiredfieldvalidator id="valPassword" runat="server" controltovalidate="txtPassword" errormessage="Please enter password." enableclientscript="False" />
</td>
</tr>
</table>
<!-- Controller의 함수 호출 -->
<p><asp:imagebutton id="btnSubmit" runat="server" onclick="SubmitClicked" imageurl="Images/buttonSubmit.gif" alternatetext="Submit" />
</form>
|
| |
|
닷넷 펫샵의 로그인 UI의 컨트롤러는 Signin.aspx.cs 페이지에 구성되었다. 페이지는 View에 포함된 버튼 컨트롤이 클릭 이벤트를 발생하여 컨트롤러의 이벤트 핸들러 함수를 호출하면 사용자가 입력한 아이디와 패스워드를 알맞은 문자열로 검증하고 Business Process Component의 함수를 호출하여 로그인을 처리한다. 아키텍처에 기반한 '제대로 된' 처리를 보여준다.
| <리스트 4> Signin UI의 컨트롤러(Page 객체를 상속하는 코드 비하인드 코드이다) |
| |
|
protected void SubmitClicked(object sender, ImageClickEventArgs e) {
if (Page.IsValid) {
// Get the user info from the text boxes
string userId = WebComponents.CleanString.InputText(txtUserId.Text, 50);
string password = WebComponents.CleanString.InputText(txtPassword.Text, 50);
// Hand off to the account controller to control the naviagtion
ProcessFlow.AccountController accountController =
new ProcessFlow.AccountController();
if (!accountController.ProcessLogin(userId, password)){
// If we fail to login let the user know
valUserId.ErrorMessage = MSG_FAILURE;
valUserId.IsValid = false;
}
}
}
|
| |
|
UI 프로세스 컴포넌트
UI 프로세스 컴포넌트는 사용자와의 상호작용이 단계적인 흐름을 예측할 수 있도록 구성될 때 유용하다. 로그인 UI의 경우 로그인을 시도한 사용자가 유효한 회원이 아닌 경우 에러 메시지를, 유효한 회원이 로그인 했을 경우 요청한 페이지로 이동한다는 단계적인 흐름을 간단히 예측할 수 있다.
또 사용자가 물품을 구매하는 프로세스의 경우 쇼핑카트에 물품을 입력하고, 전체 가격을 보여주고, 지불에 관한 정보를 입력하도록 한다. 그런 다음 배송 주소 정보를 입력하도록 요구하고 쇼핑 카트에 담긴 상품을 마이그레이션한 후 주문 정보를 입력한다.
프로세스 내에서 단계가 유지될 때 주문된 상품이 무엇이고 주문한 사용자는 누구이며 신용카드의 정보는 어떤 것인지에 대한 프로세스의 상태를 유지 관리할 필요가 있다. 이런 경우 UI 프로세스 컴포넌트를 작성하여 사용자의 프로세스 조절을 중앙 집중화할 수 있다. 특히, 다중 UI 페이지일 경우 더욱 유용하게 사용될 수 있다.
UI 프로세스 컴포넌트는 UI처럼 HTML로 구성되거나 페이지를 상속받는 개체로 구성되지 않는다. 일반적으로 UI에서 호출되는(주로 컨트롤러에서 호출되는) 메쏘드를 지닌 닷넷 클래스로 구성된다.
UI 프로세스 컴포넌트의 작성은 상당히 어렵다. UI 프로세스 컴포넌트가 제공할 만한 추상화가 필요한지를 주의 깊게 생각하지 않으면 UI 프로세스 컴포넌트의 사용은 오히려 프로젝트의 진행에 장애 요소가 될 수 있다. 하지만 주의 깊은 추상화로 UI 프로세스 컴포넌트를 구성하면, 다음과 같은 여러 장점들을 꾀할 수 있다.
◆ 사용자 상호작용의 상태를 지속할 수 있다.
◆ 다중 사용자 인터페이스를 쉽게 디자인하고 구성할 수 있다.
◆ 같은 사용자 프로세스가 여러 사용자 인터페이스에 재사용될 수 있다.
◆ 애플리케이션의 유지 관리 탄력성을 얻을 수 있다.
◆ 다른 복잡한 작업들을 쉽게 추가할 수 있게 해 준다.
UI 컴포넌트는 일반적으로 다음과 같은 기능을 구현해야 한다. 대규모 기업형 애플리케이션이라면 대부분이 반드시 필요한 기능들이며, 아키텍처에 기반하지 않고 개발된 응용 프로그램들은 이런 반드시 필요한 기능들을 여러 계층에 분산시켜 놓기 마련인데, 이런 기능들을 가지는 컴포넌트를 생성하여 중앙 집중과 관리함으로서 얻을 수 있는 이점은 무궁무진하다 할 수 있다.
◆ UI 컴포넌트는 UI와 연동되는 데이터의 흐름이다. 컨트롤의 로직들을 재개발하지 않고 상호작용 흐름을 연동할 수 있는 제어를 제공해야 한다.
◆ 논리적인 사용자와 시스템의 상호작용 흐름을 제어 추상화하여 UI 프로세스 컴포넌트를 사용하는 구현으로부터 분리되도록 작성돼야 한다.
◆ 예외 발생시에 사용자 프로세스의 흐름을 제어할 수 있어야 한다.
◆ 사용자의 상태에 대한 현재 상태를 유지해야 한다.
◆ 일반적으로 비즈니스 컴포넌트 또는 데이터 액세스 로직과 연동하여 내부 상태를 초기화하도록 한다.
◆ 사용자 상호작용에 의해서 영향을 받는 비즈니스 엔티티를 저장하는 비즈니스 상태를 유지할 수 있도록 한다.
◆ 엔터프라이즈 서비스로 구성하지 않는다.
UI 프로세스 컴포넌트는 <그림 7>과 같이 설계돼야 한다. 그럼 닷넷의 구현 모델을 살펴보도록 하자. <리스트 5>는 닷넷 펫샵의 UI 프로세스 컴포넌트 중 로그인를 처리하는 프로세스 컴포넌트의 소스코드이다.
| <리스트 5> 펫샵의 로그인 UI 프로세스 컴포넌트 코드의 일부 |
| |
|
private const string ACCOUNT_KEY = "ACCOUNT_KEY";
private const string URL_DEFAULT = "default.aspx";
private const string URL_SIGNIN = "SignIn.aspx";
private const string URL_ACCOUNTCREATE = "MyAccount.aspx?action=create";
private const string URL_ACCOUNTSIGNIN = "MyAccount.aspx?action=signIn";
private const string URL_ACCOUNTUPDATE = "MyAccount.aspx?action=update";
...
public bool ProcessLogin(string userId, string password){
// 비즈니스 로직 레이어 개체를 사용하여 로그인을 처리한다.
Account account = new Account();
AccountInfo myAccountInfo = account.SignIn(userId, password);
// 로그인이 성공하면 상태를 세션에 저장하고 요청 페이지로 리디렉션한다.
if (myAccountInfo != null) {
HttpContext.Current.Session[ACCOUNT_KEY] = myAccountInfo;
// 사용자를 어떤 페이지로 보낼 것인지를 결정한다.
If (FormsAuthentication.GetRedirectUrl(userId,
false).EndsWith(URL_DEFAULT)) {
FormsAuthentication.SetAuthCookie(userId, false);
HttpContext.Current.Response.Redirect(URL_ACCOUNTSIGNIN, true);
}else{
// 사용자를 페이지로 되돌려 보낸다.
FormsAuthentication.SetAuthCookie(userId, false);
HttpContext.Current.Response.Redirect(
FormsAuthentication.GetRedirectUrl(userId, false), true);
}
return true;
}else {
// 로그인이 실패했을 경우
return false;
}
}
|
| |
|
사용자가 로그인 프로세스를 거친 후 어떤 동작을 제어하는 <리스트 5> 이외에도 UI 프로세스 컴포넌트가 수행해야 하는 동작들에 대한 구현 코드가 들어 있다. 독자들은 펫샵 3.0을 설치했을 것이므로 상세 구현 코드는 생략하겠다.
| <리스트 6> 로그인 UI 프로세스 컴포넌트의 구현 |
| |
|
// 사용자 객체 생성
public bool CreateAccount(AccountInfo newAccountInfo){}
// 사용자 상태 갱신
public void UpdateAccount(AccountInfo updatedAccountInfo){}
// 로그인한 사용자의 정보를 알아냄
public AccountInfo GetAccountInfo(bool required){}
// 사용자가 자주 이용하는 카테고리를 알아냄
public string GetFavouriteCategory(){}
// 로그아웃 처리
public void LogOut(){}
|
| |
|
아키텍처 설계는 쉬운 일이 아니다
이 글을 읽은 독자는 다음과 같이 반문할 지도 모르겠다.
"결국은 객체지향에서 이야기하는 추상화이고 디자인 패턴이네요?"
답은 다음과 같다.
"그렇죠. 사실 추상화 수준과 디자인 패턴을 모르고서는 이를 이해하기 힘듭니다."
아키텍처를 설계한다는 것은 정말 쉬운 일이 아니다. 잘못 설계된 아키텍처는 언젠가 문제를 일으키기 마련이고, 프로젝트를 겉잡을 수 없는 방향으로 이끌게 된다. 아키텍트를 꿈꾸는 개발자라면, 당장에 아키텍처를 설계해 보겠다고 겁 없이 덤비기보다는 신뢰성 있는 기업에서 작성해서 발표한 아키텍처 구조를 잘 살펴보고 이해한 후 차근차근히 공부하는 자세가 필요하다. 한강의 기적이 하루아침에 이루어진 것이 아니듯이, 실력 있는 아키텍트와 제대로 된 아키텍처는 하늘에서 뚝 떨어지는 것이 아니다.
다음 글에서는 비즈니스 로직 컴포넌트와 데이터 액세스 로직 컴포넌트의 구성과 사용에 대해 알아볼 것이다. 마지막으로 이번 연재를 토대로 ‘닷넷 엔터프라이즈 솔루션 아키텍처’를 주제로 한 세미나를 준비 중에 있다. 좀 더 상세한 자료를 원한다면,http://www.nogatech.net에서 다운받을 수도 있다.@
* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.
김상훈 (동명정보대학 정보기술원 연구원) 2005/05/03
원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39135761,00.htm
2005. 4. 26. 19:56, Technology/UML·모델링
[객체지향 SW 설계의 원칙] ② 사례연구, 단일 책임 원칙 - 헤어져서 행복해진 사례연구, 단일 책임 원칙 연재순서
1회.다시 보면 크게 보이는 개방-폐쇄 원칙
2히.헤어져서 행복해진 사례연구, 단일 책임 원칙
3회.인터페이스 분리의 원칙
4회. 리스코프 치환 원칙
5회. 의존 관계 역전의 원칙
6회. 정리 오래 전 질레트가 여러 분야로 사업을 다각화한 적이 있다. 자신의 경쟁력 있는 분야인 면도날, 면도기 사업을 벗어나 샴푸 등 일용품 사업에까지 뛰어든 것이다. 면도용품도 일용품이니 사업분야 간 시너지 효과가 있을 것이라는 판단이었던 듯하다.
하지만 실적은 나지 않았고 주가는 곤두박질쳤으며 결국은 많은 손실을 입은 채로 다각화한 사업분야를 정리해야만 했다. 현재는 면도용품 사업에 집중해서 세계 최고의 면도용품 회사라는 명성과 실적을 되찾게 되었다.
이처럼 많은 기업들이 위험을 분산시키고 실적을 향상시키기 위해서 다각화(diversification)를 한다. 하지만 많은 경우 다각화는 오히려 위험을 증가시키고 실적을 악화시킨다. 이를 들어 월 스트리트의 전설적인 투자가로 불리는 피터 린치(Peter Lynch)는 “다각화는 대부분 다악화(diworsfication)로 끝난다”고 충고한다. 실제 그는 자신의 포트폴리오에 다각화를 시도하는 기업은 가능한 배제하며, 경험상 이러한 결정을 후회한 적은 거의 없다고 자신 있게 말한다.
스탠포드의 짐 콜린스 교수는 피터 린치의 경험을 트럭 수십 대에 해당하는 자료를 분석한 결과로 지지해 준다. 그의 연구에 따르면 위대한 기업으로 도약한 기업들은 모두가 우직하게 한 우물을 팠다고 한다. 다음은 그가 "좋은 기업에서 위대한 기업으로"란 책에서 ‘예상치 못한 발견’이라 놀라며 서술한 내용이다.
“좋은 회사에서 위대한 회사로 도약한 기업들은 고슴도치 - ‘한 가지’만 알고 그것에 집중하는 단순하고 촌스러운 동물-에 가깝다. 비교 기업들은 여우 - 많은 것을 알지만 일관성이 결여된 꾀 많고 교활한 동물-에 가깝다.”
어떤 단일 조직이 여러 분야로 다각화하게 되면 조직 내에서 다른 목표를 추구하는 사람들 간의 이질감이 발생하고 또한 한 가지에 집중하지 못하고 힘이 흩어지기 때문에 다각화는 쉽사리 다악화로 변질된다. 소프트웨어 세계에서도 이와 비슷하게 다각화를 경계하라는 원리가 있다. 바로 하나의 클래스는 하나의 책임만을 가져야 한다는 ‘단일 책임 원칙(이하 SRP)’이다.
이번 글에서는 프로그램에서 객체가 가지는 책임이란 것이 무엇인지, 그리고 왜 객체가 단일 책임만 가지는 것이 좋은지를 살펴볼 것이다. 또한 현재 객체가 이미 여러 책임을 지니고 있는 여우 객체인 경우 나타날 수 있는 문제점(악취)과 이를 고슴도치 객체로 바꾸는 방법에 대해서도 논의해 본다.
단일 책임 원칙의 개요
다음은 국제 거래 은행에서 사용하는 ‘잔고’라는 클래스이다. 잔고 클래스는 다음과 같은 인터페이스를 갖는다. 이 클래스의 인터페이스는 직관적으로 단순하고 기능적으로 완결된 클래스일 수 있다. 하지만 만약 두 개의 서로 다른 애플리케이션이 잔고 클래스를 사용한다고 했을 때 이 두 사용자 클래스는 서로 다른 메쏘드를 이용하게 된다. 환율 조정 애플리케이션은 ‘환율 계산’ 메쏘드를 이용할 것이고 이율 관리 애플리케이션은 금액에 관한 인터페이스를 이용할 것이다.
하지만 이 각 애플리케이션이 각각 배포됐을 때 잔고 클래스는 정체성의 혼란이 생긴다. 왜냐하면 이율관리 애플리케이션에 배포될 때는 ‘환율 계산’ 메쏘드가 무용하게 되고 환율 조정 애플리케이션과 배포될 때는 금액에 관한 인터페이스가 소외되기 때문이다. 문제는 여기서 그치지 않는다. 만약 환율 계산 메쏘드의 시그니처가 변경될 경우 환율 계산을 요청하는 잔고 클래스의 다른 메쏘드들이 같이 변경되어야 한다. 간결하게 설계한 잔고 클래스는 확실히 문제를 내장하고 있었다.
문제의 원흉은 무엇일까? 잔고 클래스는 사실은 두 가지 책임을 가지고 있다. 수리적 이율 연산을 담당하는 ‘환율 계산’의 책임과 금액에 관련한 처리를 담당하는 메쏘드들이 또 다른 책임이다. 또한 하나의 클래스 안에 필요에 의해 두 가지 책임이 공존할 때 서로의 의존관계는 심각하게 강결합되기 때문에 변경에 대한 충격이 전달될 수밖에 없다.
확실히 두 가지 책임을 담당해야 하는 한 클래스는 불편한 점이 많다. 지난 글에 소개한 OCP는 ‘확장’이 설계적 관전 포인트라면 단일 책임 원칙(Single Responsibility Principle : SRP)은 ‘변경’이 관전 포인트가 될 것이다. 이 ‘변경’의 거북함을 조장하는 요소는 서로 다른 ‘책임’이 혼재해 있다는데 있다.
SRP의 키워드는 책임으로 요약되는데, 그렇다면 책임이란 무엇일까? 책임이란 ‘변경을 위한 이유’이다. 만약 하나의 클래스에 변경을 위한 두 가지 이상의 이유가 있다면 그 클래스는 한 가지 이상의 책임을 갖고 있는 것이다. <그림 1>의 잔고 클래스는 변경의 내용이 두 가지로 요약된다. 금액과 환율이다. 즉, 잔고 클래스는 금액과 환율의 책임을 갖고 있다.
SRP는 하나의 클래스에 한 가지 책임을 가르치는 원칙이다. 우리는 설계 관점에서 우리가 인식하지 못하는 SRP 위반을 자주 하게 된다. 이 위반을 경계하기 위해 깊은 통찰력이 필요하지도 않다. 단지 머리에 ‘책임’이란 단어를 상기하는 습관이면 된다.
위반 사항에는 대가가 따른다. SRP를 위반할 경우 따르는 재앙은 첫 번째로 ‘왕따’가 발생한다는 것이다. 잔고 클래스가 이율 관리 애플리케이션과 배포됐을 때 확실히 ‘환율 계산’ 메쏘드는 소외된다. 즉 만약 A라는 책임과 B라는 책임을 갖고 있는 클래스가 있을 경우 A만 필요로 하는 애플리케이션은 항상 B를 들고 다녀야 한다.
문제는 여기서 그치지 않는다. 두 번째 재앙은 무관한 메쏘드에 변경이 발생할 경우 불필요한 변경 임팩트가 전달된다. 만약 ‘환율 계산’ 메쏘드가 변경됐을 경우 이율 관리 애플리케이션은 사용하지도 않는 ‘환율 계산’ 메쏘드 때문에 다시 컴파일해야 하고 리테스트해야 하며 재배포해야 한다. 이율 관리와 전혀 무관한데도 불구하고... 사실은 이 임팩트의 영향은 더 심각한데 다음의 케이스 스터디에서 살펴보겠다.
이미 구현된 소프트웨어에서 이 재앙들은 다시 (『리팩토링』에서 소개하는) 악취(bad smell)로 분류될 수 있다. 즉, 무관한 변경에 피해를 당한다든가 불필요한 요소가 따라다닐 경우 SRP를 적용해야 하는 빨간불(bad smell)로 생각해도 무방하다. 그렇다면 SRP는 어떤 구조를 제안하고 있을까?
마틴 파울러의 엔터프라이즈 패턴을 이용한 케이스 스터디
지금은 DB에 관한 여러 우수한 툴들이 제공되고 DB와 관련한 좋은 설계방식이 많이 제안되고 있다. 그래서 과거에 복잡하고 장황했던 DB 관련 코드들이 현재는 이런 툴과 기법을 통해 많이 단순화, 은닉되고 있지만 일반적으로 개발자가 간단하게 DB 관련 클래스를 설계할 때는 <그림 2>과 같은 방식을 사용한다.
이 Person이란 클래스는 세 가지 필드를 가지고 있고 이 클래스의 행위를 처리하는 메쏘드(비즈니스 로직 메쏘드)와 DB를 접근하기 위한 CRUD(Create, Read, Update, Delete) 메쏘드를 가지고 있다. Person이란 객체가 비즈니스 로직 메쏘드에 의해 상태변화가 일어났을 경우 (필드가 CRUD 됐을 경우) 적절한 시점에서 DB에 그 변화된 값을 반영해야 하며 이때 DB 접근 메쏘드를 사용하게 된다.
이렇게 비즈니스 로직 메쏘드와 DB 처리 메쏘드를 분리하는 이유는 하나의 메쏘드에 비즈니스 로직 루틴과 DB 처리 루틴이 혼재하게 됐을 때 메쏘드의 처리 루틴의 복잡도가 2배 이상 증폭되기 때문이다. 만약 분리시키지 않았다면 자바의 경우 Connection, PreparedStatement, ResultSet 같은 JDBC 클래스들이 비즈니스 로직과 무관하게 전체 루틴 사이에 등장하게 된다. 또한 이런 루틴은 필연적이게도 루핑을 하며 ResultSet에서 레코드를 읽어 와서 어떤 처리를 한다든가 변수에 대입하는 루틴이 작성되게 된다.
하지만 이런 메쏘드는 DB 처리 루틴이 변할 때 비즈니스 코드를 변경해야 하며 그 역의 경우도 발생하게 된다. 즉 하나의 책임이 변할 때 역시 필연적이게도 다른 책임도 같이 변하게 된다. SRP 위반의 두 번째 재앙의 대표적인 사례가 이런 경우이다.
이런 경우를 이번 호의 언어로 풀이하자면 하나의 메쏘드에 두 가지의 책임(‘비즈니스 로직’과 ‘DB 로직’)이 같이 있었기 때문이며 이를 분리하여 관리하는 설계가 <그림 2>의 액티브 오브젝트 패턴이다. 액티브 오브젝트 패턴은 이렇게 DB관련 처리를 따로 메쏘드로 캡슐화하며 비즈니스 로직과 DB 메쏘드를 분리시킴으로써 깔끔한 설계와 효과적인 관리를 보장하는 장점을 갖는다.
액티브 오브젝트 패턴은 하나의 메쏘드에서 두 가지 책임을 분리시켰을 뿐이지 하나의 클래스에서 두 가지 책임을 분리시키지 못했다. 즉 <그림 2>의 Person 클래스에는 여전히 Person 객체에 대한 DB에 접근 책임과 Person의 비즈니스 로직 책임이 혼재되어 있다. 데이터 맵퍼 패턴은 이 두 책임을 분리시키는 구조를 제안하고 있다(<그림 3> 참조).
사실 데이터 맵퍼 패턴은 우리가 흔히 DAO(Data Access Object)로 알고 있는 인터페이스로 실현화되어 익히 사용하고 있는 패턴이다. 흔히 『Core J2EE Patters』에서 소개된 ‘DAO 패턴’으로 DAO를 알게 된 자바 개발자는 DAO 개념이 J2EE에서 제안된 것으로 알고 있다. 하지만 DAO는 마이크로소프트에서 4GL 언어 아키텍처 작업 당시 객체단위 DB 접근 인터페이스로 제안한 DB 접근 객체 인터페이스다.
데이터 맵퍼는 클래스가 비즈니스 로직에 집중할 수 있도록 DB 접근 루틴을 데이터 맵퍼 클래스로 분리시킴으로써 액티브 오브젝트 패턴에서 필자가 제기했던 ‘한 지붕 두 책임’의 문제를 해결한다. 데이터 맵퍼 패턴을 따르면 객체와 데이터베이스, 맵퍼 간의 독립성이 유지되며, 객체와 DB 간에 데이터를 이동시키는 맵퍼 레이어를 제공받게 된다. 따라서 DB 테이블이 변하거나 DB 접근 루틴이 변한다 해도 Person 클래스는 변경의 충격에서 안전하다.
또한 데이터 맵퍼를 사용하면 Person 객체의 이용방식도 자연스럽게 DB 관련 부분과 Person 사용으로 분리된다. 즉 최초 DB에 저장된 Person 객체를 생성할 경우 PersonDAO에게 load를 요청해 DB에서 Person을 얻어오고, 사용자는 자연스럽게 Person 객체의 비즈니스 로직 부분만 집중하게 된다. 이 Person 객체를 변경하거나 삭제를 원할 경우 각각 PersonMapper를 통해 insert, update를 요청하여 DB 작업을 위임한다.
액티브 오브젝트 패턴의 경우 이 두 가지 책임에 관한 사용자의 작업이 명백히 분리되지 못했는데 데이터 맵퍼 패턴을 사용하므로 사용자의 Person 객체에 관한 책임을 사용하는 목적과 방법이 명확해진다(Person 객체의 인터페이스인지, DB 관련 작업인지).
이로써 액티브 오브젝트와 데이터 맵퍼 패턴으로 최초의 Person 클래스의 책임은 명확하게 분리될 수 있었다. 하지만 만약 Person 객체의 상태변화가 압도적으로 많아서 DB 접근이 빈번하게 이뤄지고 이 빈번한 DB 접근 비용으로 인해 성능장애가 올 경우를 상상해 보자. 우리는 이와 같은 경우 DB 접근 비용을 감소시키기 위해 일반적으로 맵퍼 레이어 뒤에 캐싱 레이어를 둔다. 즉 Person 클래스에게 또 하나의 ‘캐싱’이라는 책임이 더해진다.
가령 앞서 제기한 문제처럼 ‘boby’라는 Person 객체를 n번 load한다고 했을 때 기존 방식으로는 n번 DB에 SELECT해야 한다. 하지만 SELECT는 한번만으로도 족하다. 한번 load된 객체를 재사용한다면 DB 접근은 n-1번 생략할 수 있다.
문제는 이 캐시란 책임을 어디에 두느냐일 것이다. 액티브 오브젝트처럼 (같은 클래스의) 메쏘드 단위로 클래스 내에 분리시킬 것인가, 데이터 맵퍼처럼 클래스 단위로 서로 분리시킬 것인가, 아니면 더 큰 컴포넌트나 패키지로 분리할 것인가의 분리 단위 결정이 갈등요소가 된다.
여기서 설계자는 분리의 ‘크기(granularity)’를 고민한다. 작은 단위로 섬세하게 사용할 수 있는 미세단위(fine-grained)로 구분할 것인가, 아니면 단순하지만 입도가 큰(COARSE-GRAINED) 단위로 구분할 것인가에 대해서 말이다. 이 문제의 경우 애플리케이션에서 문제 영역이 각각 서로 다른 케이스 바이 케이스로 이루어지기 때문에 명백히 일관적으로 적용할 가이드라인을 제공하기 힘들다.
하지만 그 기준은 대상에 대한 복잡도, 크기, 용도가 된다. 복잡도가 높고 부피가 큰데 반해 그 용법이 단순하다면 COARSE-GRAINED가 적합하다. 역으로 복잡도가 낮고 부피가 작으며 용법이 다양하다면 fine-grained가 적합하다.
여하튼 이 경우 보통 식별자 맵 패턴이 사용되는데 식별자 맵은 DB를 통해 얻어온 객체를 캐시하는 맵이다(<그림 4>에서 식별자 맵은 클래스 크기로 분리하고 있다). 한번 load된 객체는 식별자 맵에 등록되고 두 번째 load 요청부터 DB에 SELECT할 필요 없이 식별자 맵에서 가져오면 된다.
| | ‘높은 응집도, 낮은 결합도(High Cohesion, Loose Coupling)’의 원리는 1970년대 Larry Constantine과 Edward Yourdon이 정의했던 아주 고전적인 원리이다. 이것은 현재 모든 소프트웨어 시스템 고유의 유지보수성과 적응성을 측정하는 가장 좋은 방법으로 사용되고 있다. 소프트웨어 디자인뿐만 아니라 아키텍처 평가에도 이 원리가 기준이 되는데, 그 이유는 이 원리의 적용 효과가 아주 명백하기 때문이다.
이 원리의 예외는 거의 찾아보기 힘들만큼 보편성을 가지고 있어서 마치 물리학의 엔트로피 법칙처럼 절대적인 기반원리를 제시한다. 낮은 응집도를 갖는 구조는 변경이나, 확장 단계에서 많은 비용을 지불해야 하며 높은 결합도의 경우도 마찬가지이다.
응집도는 ‘하나의 클래스가 하나의 기능(책임)을 온전히 순도 높게 담당하고 있는 정도’를 의미하며 이들은 서로 조화될수록 그 구조는 단순해진다. 응집도가 높은 동네에서 내부 개체가 변했을 때 다른 개체에 충격을 주는 것은 오히려 당연한 징후이다. 이들은 하나의 책임아래 서로 유기적인 관계를 갖고 있기 때문에 내부 개체가 변했을 때 다른 개체의 변경 확률이 높아진다. 마치 예쁜 부츠를 사면 부츠에 어울리는 치마를 입어야 하듯이… 응집도의 종류는 다양한데 다음은 권장할 만한 순기능적 응집 관계들이다.
* 기능적 응집(Functional Cohesion)
일관된 기능들이 집합된 경우를 말하며 <그림 3>의 데이터 맵퍼는 DB 처리라는 기능 항목의 높은 응집성을 갖는다.
* 순차적 응집(Sequential Cohesion)
한 클래스 내에 등장하는 하나의 소작업(메쏘드)의 결과가 다음 소작업(메쏘드)의 입력으로 사용되는 관계(파이프라인 방식의 처리 체인 관계).
* 교환적 응집(Communicational Cohesion)
동일한 입력과 출력 자료를 제공하는 메쏘드들의 집합을 말하며, 팩토리 클래스는 전형적인 교환적 응집도가 높은 인터페이스를 갖는다.
* 절차적 응집(Procedural Cohesion)
순서적으로 처리되어야 하는 소작업(메쏘드)들이 그 순서에 의해 정렬되는 응집관계
* 시간적 응집(Temporal Cohesion)
시간의 흐름에 따라 작업 순서가 정렬되는 응집관계
* 논리적 응집(Logical Cohesion)
유사한 성격의 개체들이 모여 있을 경우를 말하며 java.io 클래스들의 경우가 대표적인 예이다.
이와 반해 결합도는 ‘클래스간의 서로 다른 책임들이 얽혀 있어서 상호의존도가 높은 정도’를 의미하며 이들이 조합될수록 코드를 보기가 괴로워진다. 이유는 서로 다른 책임이 산만하고 복잡하게 얽혀있기 때문에 가독성이 떨어지고 유지보수가 곤란해지기 때문이다. 이유는 필요 없는 의존성에 있다. 마치 키보드의 자판 하나가 고장나도 키보드 전체를 바꿔야 하는 것처럼. 하나의 변경이 엄청난 민폐를 야기하는 관계이다. 다음은 수용할 수 있는 수준의 결합 관계들이다.
* 자료 결합(Data Coupling)
두 개 이상의 클래스가 매개변수에 의해서 결합 관계를 가지므로 낮은 수준의 결합도로 연관되는 경우
* 스탬프 결합(Stamp Coupling)
자료 결합의 경우에서 매개변수 일부만을 사용하는 경우
* 제어 결합 (Control Coupling)
두 클래스간의 제어 이동이 매개변수를 이용하여 사용되는 경우로 커맨드 패턴이 대표적인 사례이다(지난 연재 기사 OCP 참조).
|
|
|
| |
| |
즉 순서는 ‘1. 우선 key에 해당하는 객체를 식별자 맵에서 찾는다( 1.1. 없다면 DB에서 얻어온다. 1.2. 식별자 맵에 등록한다). 2. 리턴한다’'의 절차를 밟는다. 마치 싱글톤 패턴처럼 한 번의 접근을 보장함으로써 DB 접근 비용을 감소시킨다.
이와 더불어 실제 엔터프라이즈 애플리케이션 설계 시 데이터 접근의 동기화, 동시성 처리, 풀링, O/R 맵핑 등의 ‘책임’들이 등장하게 되는데 이 각 책임들을 담당하는 클래스를 분리시키고 이들 간의 관계를 잘 정의할수록 복잡도는 감소하고 아키텍처는 깨끗해진다.
현재 제공되고 있는 DB 관련 프레임워크는 이 책임들을 맡는 기능을 구현한 녀석들이다. SRP의 효과가 바로 여기에 있다. SRP를 적용하면 무엇보다도 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있다.
하지만 무조건 책임을 분리한다고 SRP가 적용되는 건 아니다. 가령 데이터 맵퍼 클래스의 메쏘드들이 각각의 insert, delete, update, load 클래스로 분리됐을 경우를 생각해 보자. 마치 절차적 언어에서와 같은 함수 단위의 클래스가 될 것이다. 각 메쏘드 역할에 따른 책임들이 분리되었지만 설계는 장황해지고 관계는 복잡해진다. 하지만 이 문장은 틀린 문장이다. 동일한 책임을 갖는 여러 메쏘드들이 분리된 것이다. 즉 분리의 기준은 책임이며 분리의 목적은 복잡도 감소에 있다.
반면 각각 분리된 insert, delete, update, load 클래스들이 있다고 했을 때 이들은 한 책임아래 병합되어야 할 것이다. 왜냐하면 이들은 병합될수록 관계는 단순해지고 설계가 일목요연해지기 때문이다. 그렇다면 이 서로 상반된 관계, 즉 어떤 경우는 분리를 할수록 설계가 깨끗해지고, 반대로 어떤 경우는 병합을 할수록 설계가 깨끗해지는데 이 차이는 무엇일까?
각 개체 간의 응집력이 있다면 병합이 순작용의 수단이 되고 결합력이 있다면 분리가 순작용의 수단이 된다. 응집력이 있다는 것은 여러 개체가 같은 책임아래 있다는 것을 의미하며 결합력이 있다는 것은 한 개체가 여러 책임을 갖고 있다는 의미가 된다. 따라서 응집도는 높을수록, 결합도는 낮을수록 좋은 설계 품질을 보장받는다.
SRP 위반의 악취들
SRP는 하나의 객체가 하나의 책임, 즉 하나의 ‘변경의 이유’만 지니게 함으로써 설계를 단순하게 하고 변화에 기민하게 만들어 준다. 필자는 서두에 SRP 위반했을 때 재앙을 악취로도 소개했는데 이번에 소개할 악취들은 『리팩토링』에서 구체화된 악취들이다. SRP 위반의 악취는 ‘여러 원인에 의한 변경(divergent change)’와 ‘산탄총 수술(shotgun surgery)’을 들 수 있다.
여러 원인에 의한 변경
여러 원인에 의한 변경은 한 클래스를 여러 가지 다른 이유로 고칠 필요가 있을 때 발생한다. 즉, 하나의 클래스에 여러 책임이 혼재하고 있어서 하나의 책임의 변화가 다른 책임에게 영향을 준다. 그리고 이 책임이 두 개보다 훨씬 많은 여러 개로 혼재된다면 이 클래스는 심각한 고문관이 된다. 더욱이 이 구조는 더 괴로운 경우로 심화될 수 있다.
<그림 1>의 ‘잔고 클래스’에서 ‘환율 계산’이란 책임의 변화로 다른 금액 관련 책임들의 인터페이스까지 칼을 대야 할 상황에 이른다면 작은 ‘환율 계산’의 변경이 전혀 무관한 금액 관련 인터페이스를 이용하는 모든 사용자 클래스까지 변경해줘야 하는 것이다. 이런 위험 상황을 소개한 것이 ‘여러 원인에 의한 변경’이라는 나쁜 냄새이다.
‘여러 원인에 의한 변경’을 해결하는 방법은 경우에 따라 다르다. 다음은 여러 원인에 의한 변경을 해결하는 리팩토링 기법이다.
◆ Extract Class는 혼재된 각 책임을 각각의 개별 클래스로 분할하여 클래스 당 하나의 책임만을 맡도록 하는 것이다. 액티브 오브젝트 패턴에서 데이터 맵퍼 패턴으로의 진화가 대표적인 사례가 된다. 여기서 관건은 책임만 분리하는 것이 아니라 분리된 두 클래스간의 관계의 복잡도를 줄이도록 설계하는 것이다.
◆ 만약 Extract Class된 각각의 클래스들이 유사하고 비슷한 책임을 중복해서 갖고 있다면 Extract Superclass를 사용할 수 있다. Extract Class된 각각의 클래스들의 공유되는 요소를 부모 클래스로 정의하여 부모 클래스에 위임하는 기법이다. 따라서 각각의 Extract Class들의 유사한 책임들은 부모에게 명백히 위임하고 다른 책임들은 각자에게 정의할 수 있다.
| | 윤성준, 조재박 님이 번역하고 대청미디어에서 출간된 마틴 파울러의『리팩토링』 한국어판을 보면 여러 원인에 의한 변경(divergent change)이 ‘확산적 변경’이라 되어 있다. 하지만 확산적 변경이라 했을 때는 변경이 다른 클래스로 확산된다는 느낌이 강하고, 클래스가 여러 변경 원인에 의해 변경된다는 느낌이 언뜻 오지 않는다.
그래서 이번 글에서는 divergent를 수렴(convergent)에 대응하는 의미가 아닌 ‘다른’의 뜻으로 세기고 divergent change를 ‘여러 원인에 의한 변경’이라 하겠다. They hold divergent opinions on controversial issues like abortion(그들은 낙태와 같은 논란이 되는 이슈에 대해 서로 다른 의견을 주장했다)에서의 divergent 용례를 참고하면 될 듯하다. 흔히들 ‘확산적 변경’과 뒤에 소개할 ‘산탄총 수술’을 잘 구분하지 못하는데 ‘확산적 변경’을 ‘여러 원인에 의한 변경’으로 바꾸어 이해하면 이 둘의 구분이 조금 더 직관적으로 다가올 것이다.
|
|
|
| |
| |
산탄총 수술
산탄총을 발사하면 하나의 탄환이 부서지면서 여러 개의 탄환으로 확산되어 발사된다. 따라서 (상상하기도 싫지만) 산탄총을 맞은 대상의 총상은 온몸 전체에 퍼지게 된다. 만약 이런 환자를 수술하는 의사는 마치 수십 발의 총을 맞은 환자를 수술하는 것처럼 힘들 것이다.
‘산탄총 수술(shotgun surgery)’은 ‘여러 원인에 의한 변경’과 비슷한 듯 하면서도 정 반대의 내용을 갖는다. ‘여러 원인에 의한 변경’이 하나의 클래스가 여러 변경 원인(책임)을 지니는 반면, 산탄총 수술은 어떤 변경이 있을 때 여러 클래스를 수정해야 하는 증상이다. 즉 어떤 변경의 대상이 여러 곳에 분포되어 마치 산탄총 총상 환자를 수술해야 하는 것 같은 많은 노동비용이 따른다.
‘산탄총 수술’이 괴로운 이유는 단지 수술 부위가 많다는 것만이 아니다. 이 수술을 했음에도 불구하고 혹시 치료하지 못한 상처가 존재할 수 있다는 가능성이 ‘산탄총 수술’의 더 큰 위험성이다. 가령 하나의 테이블을 조작하는 DB 처리문이 애플리케이션 전역에 퍼져 있는 상황에서 DB 테이블의 구조가 바뀌게 됐을 경우에 발생하는 재앙과 같다. 수술도 고되지만 모든 환부를 찾아야 하는 집중력과 긴장감이 개발자를 더욱 힘들게 한다.
산탄총 수술이란 악취는 하나의 책임이 여러 클래스에 분산되어 있기 때문에 발생한다. 한 클래스가 너무 많은 책임을 맡고 있어도 곤란하지만, 책임을 식별하지 못해 이를 담당할 클래스를 만들지 않고 여러 클래스에 흩뿌려 놓는 것 또한 문제가 있다. 이는 보통 프로그램의 전체 책임을 올바로 분담하지 못해서 발생하게 된다.
이 악취는 Move Field와 Move Method를 통해 책임을 기존의 어떤 클래스로 모으거나, 이럴만한 클래스가 없다면 새로운 클래스를 만들어 해결할 수 있다. 즉 산발적으로 여러 곳에 분포된 책임들을 한 곳에 모으면서 설계를 깨끗하게 한다. 즉 응집성을 높이는 작업이 필요하다.
산탄총 수술의 냄새는 특히 설정 정보(configuration information), 로깅(logging), DB 처리에서 발생하기 쉬운데 이들을 다룰 때는 항상 산탄총 수술의 악취를 경계해야 한다. 예를 들어 한 곳에서 관리할 필요가 있는 설정 정보를 여러 클래스에서 나누어 처리하고 있다면 이는 산탄총 수술을 할 수 있는 좋은 본보기가 된다.
이를테면 쓰레드, 커넥션, 오브젝트 풀의 크기 값이나 DB, 서버의 주소 정보들을 각각의 클래스에 자체적으로 관리하고 있다면 이들을 설정 파일이나 설정 관리자에게 Move Field하는 것이 바람직하다. 더 나아가 플러그인을 도입해 설정 정보를 통해 동적으로 행위 변화를 통제(Enable Configurable Behavior with Plugin)하는 것도 생각해 볼만하다. 또한 XML 처리나 프로토콜 해석을 담당하는 메쏘드가 여러 곳에 분포되었다면 각각의 유틸성 클래스로 Move Method하는 것이 바람직하다.
‘여러 원인에 의한 변경’과 ‘산탄총 수술’이란 악취를 SRP를 어긴 신호로 여기고 제거한다면 변경이 여러 곳으로 확산되지 않을 뿐 아니라 책임을 적절히 분배함으로 인해 코드의 가독성 향상, 유지보수 용이라는 이점까지 누릴 수 있다. 또한 적절한 책임 분배는 객체지향 원리들의 대전제 격인 OCP뿐 아니라 다른 원리들을 적용하는 기초가 되어준다.
| | 리팩토링에서 소개하는 대부분의 냄새들(코멘트, 비대한 클래스에서 시작해 산탄총 수술까지)은 객체간의 책임 분배와 직간접적으로 관련이 있는데, 항상 코드를 최상으로 유지한다는 리팩토링의 근본 정신은 곧 항상 객체들의 책임을 최상의 상태로 분배한다는 것이기 때문이다. 그리고 다음의 리팩토링 기법들은 ‘객체들의 책임을 최상의 상태로 분배’하는 가장 기본이 된다.
Extract Class(6)
Move Method(6)
Extract Method(4)
Move Field(4)
이들은 가장 많은 냄새를 해결하는 리팩토링 기법들을 정리한 것으로 괄호 안의 숫자는 냄새를 해결하는 데 사용된 빈도수이다. 고급스럽고 우아한 고급 리팩토링 기법이나 빅 리팩토링 기법은 때때로 유용하지만, 이들은 항상 유용하다.
필자는 앞의 4개의 리스트에 ‘Rename *’를 추가하여 5개의 리팩토링 기법을 가장 단순하면서도 중요한 핵심 리팩토링 기법으로 여긴다. 파울러의 책에는 Rename Method만이 수록되어 있지만, Rename Class, Rename Field, Rename Parameter 역시 굉장히 자주 쓰이며 실제 이클립스의 리팩토링 기능을 보면 이 모두가 하나로 Rename이라 되어 있다. 그리고 경험에 비추어 보면 어느 리팩토링 기능보다도 Rename을 자주 사용하게 된다. 올바른 클래스 이름은 해당 클래스의 책임을 나타낼 수 있는 가장 좋은 방법이다.
코딩을 하면서 키보드 앞에 A4 용지를 놓고 수시로 CRC 카드, 클래스 다이어그램, 시퀀스 다이어그램을 간략히 그려보며 객체들 간의 책임을 점검해 보고, 리팩토링을 수행하는 것은 분명 좋은 SRP를 어기는 코드를 사전에 어느 정도 방지할 수 있는 좋은 대비책이 되어줄 것이다. 할 수만 있다면, ‘사후 대처’보다는 ‘사전 예방’이 더 좋은 해결책이지 않은가?
|
|
|
| |
| |
위대함보다 단순함은 없다
눈동자의 초점이 분산되면 난시가 되고 마음이나 정신의 초점이 정상을 상실하고 분산하는 상태가 지속되면 정신착란 혹은 정신 분열이 온다. 마찬가지로 클래스가 하나의 책임에 집중하지 못한 채 이것저것 두리번거리는 여우와 같고, 이러한 클래스들이 누적된다면 프로그램은 점점 유지보수, 변경에 대응하기 어려워진다. 어쩌면 ‘툭’하고 잘못 건드리면 정신착란이 올지도 모를 일이다.
소프트웨어는 항상 변경을 전제한다. 따라서 변경에 민감하게 반응하지 못하는 설계는 프로젝트를 힘들게 한다. “소프트웨어 설계에는 두 가지 방법이 있다. 한 가지는 분명히 결함이 없도록 단순하게 설계하는 것이고 다른 한 가지는 분명한 결함이 없도록 가능하면 복잡하게 설계하는 것이다"라는 명언이 있다.
SRP를 적용하면 클래스의 숫자가 늘 수는 있다. 하지만 클래스 숫자의 증가가 프로그램의 복잡도 증가와 비례하는 것은 아니다. 오히려 SRP를 잘 따르는 프로그램은 적절한 책임 분배로 인해 클래스 숫자와 프로그램의 복잡도가 반비례하는 경향이 있다고도 할 수 있게 된다.
위대함보다 단순함은 없다. 실제로 단순한 것이 위대한 것이다. 그리고 이 단순함의 중심에는 단일 책임의 원칙이 있다.@
* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.
저자 :최상훈 (핸디소프트), 송치형 (서울대) 2005/04/25
원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39135552,00.htm
걸을 땐 슈퍼맨의 망토를 펄럭이자 2005년 4월 25일 월요일
걸을 땐 슈퍼맨의 망토를 펄럭이자
(예병일의 경제노트, 2005.4.25)걸음걸이를 익혀라. 가장 좋은 방법은 등 뒤에 망토를 걸치고 있다고 생각하고 펄럭이는 망토를 느끼며 걷는 것이다.
이것은 일정한 간격으로 성큼성큼 걷는 방법으로서, 우리가 보여 주고 싶어하는 확신과 일관성에 제일 맞는 걸음걸이다.
올바른 걸음걸이.
깔끔한 외모, 품위 있는 옷차림 등과 함께 개인의 첫인상을 결정해주는 중요한 요소입니다.
하지만 많은 사람들이 자신의 걸음걸이에 별로 신경을 쓰지 않고 지냅니다. 모든 것이 그렇지만, 걷는 것도 노력하면 익힐 수 있습니다.
로만 브라운이 제안한대로, 강한 인상을 주는 걸음걸이를 만들기 위해 '슈퍼맨의 망토'를 생각해보면 좋을 듯 합니다.
슈퍼맨의 망토가 내 등 뒤에서 펄럭이고 있다고 생각하는 것이지요. 그런 생각을 하며 일정한 간격으로 성큼성큼 걸어보는 겁니다.
자신있고 강한 메시지를 주위 사람들에게 전해줄 수 있을 겁니다.
* * *
안녕하십니까, 예병일입니다.
경제노트 오프라인 무료 세미나 모임의 장소에 대해 많은 분들께서 의견을 주셨습니다. 특히 장소후원 제안을 해주신 자바씨티 코리아, 한국생산성본부, 코트라 등에 계신 가족께 진심으로 감사드립니다.
좀 더 숙고해서 정기모임에 적합한 장소가 확정되면 다시 알려드리겠습니다.
감사합니다.
예병일 드림.
|
|
짧은 리프레쉬를 통해 효율을 높이는 사람들 2005년 4월 22일 금요일
짧은 리프레쉬를 통해 효율을 높이는 사람들
(예병일의 경제노트, 2005.4.22)나는 매일 낮잠을 자는데 그것이 충만한 인생을 살아가는 데 방해되지는 않는다.
나는 심야 2시, 때로는 새벽 5시까지 일을 하는 경우가 많다. 대신 식사하기 전이나 후에 잠깐 동안 누워 휴식한다. 비행기나 열차나 자동차로 여행을 할 때에는 15분 정도 잠을 잔다.
이렇게 하고부터는 수면 시간이 3시간 정도 줄었고, 전보다 건강해졌으며, 무엇을 하더라도 좀더 효율적으로 할 수 있게 되었다.
이른 새벽이나 아침시간을 집중적으로 활용해 커다란 성과를 올리는 사람들이 있습니다. 거꾸로 남들이 다 잠든 밤 늦은 시간을 이용해 많은 일들을 하는 사람도 있습니다.
모두 그 시간들이 각자에게 효율을 높이는데 적합하기 때문에 가능한 일입니다.
하지만 사람인 이상, 깨어있는 시간 내내 고도의 집중력을 발휘하기는 어렵습니다. 오후 시간대에는 출근 직후의 상쾌함도 사라지기 쉽고 능률도 떨어지기 쉽습니다.
그래서 이런 상태를 이겨내고 몸과 마음에 다시 활력을 불어 넣을 수 있는 '자신만의 리프레쉬 방법'을 하나쯤 찾아야할 필요가 있습니다.
프랑스인인 저자는 낮잠에서 길을 찾았습니다. 하루 15분씩 낮잠을 자는 것으로 오후 시간대를 더욱 효율적으로 사용할 수 있었고, 게다가 일하는 시간도 새벽 2시, 때로는 새벽 5시까지로 늘릴 수 있었다고 말합니다. 15분의 낮잠이 수면시간 3시간을 줄였다는 경험담입니다.
저자 말고도 '토막잠'을 활용하며 밤잠을 4시간 정도로 줄이고 많은 일을 이룬 유명인들이 많습니다.
그 방법이 15분간의 낮잠일 수도 있고, 15분간의 산책일 수도 있고, 음악감상, 또 다른 그 무엇일 수도 있겠습니다. 그것이 무엇이든 나에게 맞는 '나만의 리프레쉬 방법'을 찾아서 활용하면 시간들을 효율적으로 사용할 수 있습니다.
* * *
경제노트 가족들의 오프라인 무료 세미나 모임에 대해 많은 분들께서 문의를 해오셨습니다. 행사 진행 자원봉사를 희망해주신 많은 분들께 다시 한번 감사드립니다.
모임은 장소만 확정되면 가급적 5월중에 시작하려 준비하고 있습니다. 시간대는 평일(수 또는 목요일) 저녁 7시~9시 정도로 계획하고 있습니다.
현재 경제노트 가족분들이 편하게 오실 수 있는 100~200명 수용 규모의 강의장을 물색하고 있는데, 아직 좋은 곳을 발견하지 못했습니다. 지하철 역에서 걸어갈 수있을 정도의 거리에 있는 장소를 찾고 있는데, 장소가 빨리 정해지면 행사 시작도 그만큼 빨라질 것으로 보입니다.
혹시 추천할 만한 모임장소가 있으면 메일이나 댓글로 알려주시면 감사하겠습니다.
상쾌한 봄 날, 항상 즐겁게 보내시기 바랍니다.
|
|
2005. 4. 20. 22:08, Technology/RFID
RFID 도입, 성공하려면「표준 목매지 마라」 RFID는 맨 처음 동물을 대상으로 적용됐다. 그리고 이제 인류의 팔로 옮겨갔다. 이 조그만 센서가 여러 곳에 이식돼 사용되는 모습은 이제 더 이상 공상 과학 영화의 한 장면에만 나오는 것이 아니다.
올 연초 존 하람카 박사는 환자가 의식을 잃거나 반응이 없을 때처럼 위급한 상황에서 RFID를 사용할 수 있는지 시험해보기 위해 마이크로칩을 스스로 자신의 몸에 주입했다. 병원 직원들은 이름, 혈액형, 의료 기록과 같은 개인 정보를 얻기 위해 마치 바코드처럼 태그를 읽어들일 수 있다.
하지만 이와 같은 응용 실험이 진행되는 동안 한편에서는 RFID의 실전 배치가 상용화 단계에 진입하고 있다.
시장 조사 업체 인-스탯은 기업들이 2009년까지 RFID 태그에 28억달러를 지출할 것으로 예측하고 있다. 작년까지만 해도 RFID 시장은 전세계적으로 도합 3억달러 정도에 불과했다. 향후 4~5년 내에 엄청난 성장세를 보일 것이란 전망이다.
EPC글로벌의 이사이자 시스코 시스템즈의 인터넷 비즈니스 솔루션 그룹 부사장인 모센 모아자미는 이 신기술이 공급망 관리(SCM)와 재고 관리 분야를 개선시킬 수 있는 잠재력을 갖고 있다고 말했다. EPC글로벌은 IBM, NEC, 인텔처럼 첨단기술 기업들로 구성된 전세계적인 연합체로 RFID의 적용 표준을 개발하고 있다.
모아자미는 RFID로 물류와 자산 관리, 그리고 다른 운영 효율성을 개선하면 전체적으로 3~5%의 공급망 비용을 절감할 수 있을 것이라고 말했다. 그는 특히 전세계적으로 재고 비용이 3250억달러나 되는 현실에서 RFID는 회사들에게 매력적인 제안이 아닐 수 없다고 강조했다. 3250억달러 중 2240억달러는 초과 재고를 관리하는 데 쓰이고 나머지 450억달러는 재고가 부족한 물품에서 초래된 손실이다.
인텔에서 전세계 소매 고객 패키지 상품 산업 부문을 총괄하는 존 C. 스타인은 다양한 연구로부터 얻은 수치를 언급하며 기업들이 “안전을 보장”하기 위해 평균 11주 기간동안의 재고를 확보하고 있다고 언급했다. 그는 “11주 동안 단지 창고 안에 재고로 쌓여 있는 상태로 아무 것도 하지 않는다… 수백만 달러를 버리고 있는 셈”이라고 말했다.
스타인은 RFID가 유통망에 새로운 가능성을 제시하고 있으며, 안전 재고처럼 쓸모없이 쌓여있기만 한 문제를 해결할 수 있는 데이터를 생성해 운영상의 효율을 가져다줄 것이라고 말했다.
| | RFID를 이용하면 무선 전파를 통해 데이터를 얻어낼 수 있으며 전자 칩이나 태그에 저장할 수도 있다. RFID 리더는 바코드 스캐닝이나 적외선과 달리 태그에 눈에 보이는 선을 만들지 않고도 무선으로 정보를 추출해 낼 수 있다. 전송은 1㎝에서 30m 범위의 거리 내에서 수행할 수 있다.
몇몇 RFID 태그는 미리 정의한 때마다 주변 온도를 자동으로 측정한다. 이 기능은 기후 변화로 인해 부패하기 쉬운 제품을 유통망을 통해 공급할 시 모니터링하는 데 사용할 수 있다.
RFID는 바코드보다 많은 데이터를 저장할 수 있기 때문에 재고 목록을 가시화하고 운영 효율성을 개선하며, 심지어 더 나은 건강관리 서비스를 제공하는 방법으로도 각광받고 있다. |
|
|
| |
| |
당면한 문제들이처럼 RFID로 떠들썩한 분위기임에도 불구하고 여전히 산적한 문제가 많다. IBM 아세안/남아시아 지역 BCS 사업부에서 유통 부문 전략·이노베이션 분야를 이끌고 있는 크라우드 링겟은 “어떤 면에서 보면 RFID는 성숙기에 접어든 상태로 미 육군에서 수십년동안 사용돼 왔다. 하지만 여전히 상업적으로 적용된 사례는 적다”라고 말했다. 링겟은 이 지역에서 이뤄지는 대부분의 일은 바로 교육으로, RFID를 적용하기 위해 뭐가 필요한지 고객들에게 설파하는 데 중점을 두고 있다고 전했다. 소규모 프로젝트가 진행중이긴 하지만 실제 적용된 사례는 “극소수”에 불과하다는 것이 그의 설명이다. 뒤이어 링겟은 “정부가 RFID를 추진하고는 있지만 아직 기업 고객들 사이에서는 RFID 기술을 쓸 수 있는지 막연한 관심만 보이고 있는 정도다. 또한 비용이 얼마나 들지, 투자비용을 실제로 어떻게 회수할 수 있는지 방안에 대해 우려하기도 한다”라고 털어놓았다. 반면 미국과 유럽에서는 본격적인 대규모 적용 사례가 광범위하게 등장하고 있다. 링겟은 결과만 놓고 보자면 아태 지역에서 RFID로 가시적인 매출을 올리는 곳은 극소수에 불과하다고 말했다. RFID 확산에 필수적이라 할 수 있는, 규모의 경제가 존재하지 않는 상황에서는 아태지역에 RFID를 적용하는 데 드는 비용의 경우 떨어지는 속도가 매우 느릴 수밖에 없다고 그는 덧붙였다. 엄청난 투자는 별개로 한다 해도 성능 문제에 대한 우려는 계속 남아있다. 링겟은 금속성 제품과 액체로 된 제품에 붙여진 태그에서 나타나는 인식 문제가 여전히 남아있다고 말했다. 그는 “이런 종류의 제품에서는 인식율이 꽤 낮을 수 있다. 그래서 전자업계와 소비재 업계에서 특히 이 문제로 고심하고 있다”라고 설명했다. 하지만 이런 당면한 문제에도 불구하고 RFID를 초기에 적용한 이들은 그다지 후회하고 있지 않다. 싱가폴에 위치한 LHT 홀딩스는 RFID가 붙은 화물 받침대를 임대해주고 있다. 이 회사의 고객들에는 칼스버그 싱가폴, F&N 코카 콜라 앤 푸드, MDD 비버리지 등이 있다. LHT 홀딩스의 중역인 마이 얍은 “신기술을 적용할 때면 으레 그렇듯 RFID 적용 시에도 어려움이 있을 거라는 건 인지하고 있다. 하지만 우리는 RFID에 투자한 것이 장기적 안목에서 이득을 가져다 줄 것이고 더 나은 고객 서비스를 제공할 수 있게 해주며 경쟁력을 더 강화해줄 것이라고 긍정적으로 보고 있다”라고 말했다. 얍은 “초기 도입에 드는 비용이 싸다고 말할 수는 없지만 기술에 대한 인식이 늘고 정부 지원이 제공되면서 RFID 가격은 대량 생산과 맞물려 하락하게 될 것”이라고 덧붙였다. 싱가포르 정부는 지난해 11월 싱가폴에서 개발된 시스템들이 미국, 유럽 시스템과 상호 동작할 수 있도록 RFID 애플리케이션용 주파수 범위를 확장했다. 또한 싱가포르 정부는 자국 내에서의 RFID 기술의 적용과 개발을 선도하기 위해 3년 동안 싱가포르 달러 1000만달러(미화 590만달러)를 투자하기로 약속했다. IBM의 링겟은 차세대 RFID, 특히 UHF 기반 EPC글로벌 G2 표준(Class 1 Generation 2; C1G2)이 적용되면 상황이 더 좋아질 것이라고 전했다. 차세대 RFID?지난해 11월 공개된, 특허 사용료가 없는 프로토콜 표준은 RFID 구현의 걸림돌로 작용하고 있는 상호 동작 문제를 해결해줄 것으로 기대되고 있다. EPC글로벌 싱가폴의 총 책임자 탄 진 순에 따르면 G2를 이용할 경우 서로 다른 제조업체들의 장비도 상호동작할 수 있어 다르게 만들어진 태그라도 한개의 리더로 읽어 데이터를 추출해낼 수 있게 된다. RFID 업계에서는 새 표준에 부합하는 제품을 이제 막 내놓기 시작했다. G2가 적용된 하드웨어는 앞으로 계속 출시될 것으로 예상되고 있다. 여기서 또다른 문제가 발생한다. 기업들은 G2 제품이 폭넓게 이용될 때까지 기다린 다음 RFID로 첫 발을 내딛는 것이 현명한 판단일까? IBM의 링겟에 따르면 대답은 ‘아니오’다. 기업들이 협력업체가 세운 요구 사항을 충족시켜야 할 경우라면 더욱 그렇다. 링겟은 이런 회사들이라면 차세대 RFID 기술로 옮겨갈 수 있는 로드맵을 세우는 것과 병행해 현재 주어진 요구에 부합할 수 있도록 계속 작업해나가야 한다고 지적했다. 링겟은 G2 표준을 맞추는 게 그다지 큰 문제가 되지 않는 회사라면 자기 페이스대로 나가도 된다고 말했다. 그는 “현재로선 G2가 정확히 언제쯤 적용될지 불명확하다”라며 “태그 제조업체들이 실제로 어떻게 나올지도 명확하지 않고, 얼마나 생산할 수 있을지도 확실치 않다”라고 부연설명했다. 하지만 링겟은 앞으로 “인프라를 적절하게 구축하기 위해선” 소규모 파일럿 프로젝트를 시행하는 것도 고려해야 한다고 말했다. 이렇게 해야 G2 표준이 시장에 나왔을 때 몽땅 “갈아엎기”보다 저렴한 비용으로 차근차근 구축해나갈 수 있을 것이라고 그는 덧붙였다. 또한 링겟은 더 중요한 문제는 제품에 다양한 RFID 태그를 시험하는 데 걸리는 시간과 노력을 과소 평가하는 것이라며 현재 여러 기업들은 이미 뜻하지 않는 복병과 마주치고 있다고 강조했다. 즉 링겟의 설명은 회사들이 사업 이득에만 과도하게 치중하지 말아야 하며, 이 기술을 적용한 비즈니스 사례로 만들 요량으로만 RFID를 사용하지는 말아야 한다는 것이다. 그는 모든 것이 제대로 동작하게 하려면 시간이 걸린다며 “사례 창출로는 결코 충분하지 않다. 게다가 기업들이 사례만으로 RFID로 이동할 것이라고 보지도 않는다”라고 덧붙였다. 예를 들어 최상의 인식율을 얻을 수 있는 태그의 위치를 찾으려면 끊임없이 시험해보는 것 말고는 왕도가 없다. 링겟은 “회사 각각이 경험해서 풀어가야 할 문제”라고 밝혔다. IBM은 내부적으로 뉴욕의 피쉬킬 반도체 공장에서 웨이퍼 운반기를 추적하는 데 RFID를 사용하고 있다. 공장 곳곳에 설치되어 있는 RFID 리더는 태그가 붙은 운반기를 스캔해 데이터를 추출한 후 웨이퍼 운반기가 생산 라인을 따라 이동할 때 각 위치를 확인해준다. IBM은 RFID를 적용함으로써 자사 직원들을 좀더 부가가치가 있는 제조 작업으로 재배치할 수 있었다고 전했다. 링겟은 “완제품으로 따지면 200만달러의 가치를 지닌 웨이퍼 캐리어를 정확한 위치로 이동시키는 데 직원들은 많은 시간과 노력을 들였다. 이런 일은 생산 장비를 가동시키는 것처럼 우선순위가 높은 작업을 수행할 때 혼란을 가중킬 수 있다. 결국 생산은 느려지고 산출량은 감소하며 이득은 줄게 된다”라고 설명했다. 이에 덧붙여 링겟은 “웨이퍼 운반기에 RFID를 하나씩 적용할 때마다 한 사람이 지닌 능력을 더 가치있는 제조 부문에 전념시킬 수 있게 된다. 또한 제품 결함과 생산 지연 또한 줄어들었다”라고 밝혔다. @ Eileen Yu (CNETAsia) 2005/04/19
원문보기
원문 :http://www.zdnet.co.kr/news/digital/0,39024418,39135601,00.htm
프로페셔널은 결과로 말한다 2005년 4월 18일 월요일
프로페셔널은 결과로 말한다
(예병일의 경제노트, 2005.4.18)프로페셔널 세계에서의 사람의 가치 평가는 기본적으로 '일의 성과'에 좌우된다.
부단한 자기계발과 인격도야에도 많은 힘을 쏟아야겠지만, 프로는 결과로 말한다.
그저 열심히 하는 것 만으로는 의미가 없다. 최고의 결실을 획득할 수 있도록 진력해야 한다.
프로페셔널은 '결과'로 말해야 합니다. 냉정한 이야기이고 비정한 말이지만, 그래야 합니다.
열심히 하는 것만으로도 충분했던 시절이 있었습니다. 그 푸근했던 시간들은 학교문을 나서면서 잊어야 합니다. 아마추어라는 단어가 '아름다움'으로 다가오는 상황이 있고, '미숙함'으로 이해되는 상황이 있습니다. 그 두 상황을 분명히 구별해야 합니다.
한 나라의 대통령은, 한 기업의 CEO는 열심히 일하는 것만으로 모든 것을 이해받을 수 없습니다. 인격을 갖춘 것만으로 실패를 용서받을 수 없습니다.
그들은 국민들을, 직원들을 편안하게 먹여살려야하는 의무가 있습니다. 그걸 '결과'로 보여주는 프로페셔널이 되어야 합니다.
대통령이나 CEO만 그런 건 아닙니다. 부장, 과장, 신입사원... 그 어느 자리에 있던, 프로페셔널은 '결과'로 말해야 합니다.
|
|
미국의 백만장자에게서 배우는 부자가 되는 길 2005년 4월 14일 목요일
미국의 백만장자에게서 배우는 부자가 되는 길
(예병일의 경제노트, 2005.4.14)내가 학교에 다니고 있을 때, 아내는 교사였습니다. 우리의 수입은 적었지요. 그러나 우리에게는 항상 규칙이 있었습니다. 저축하는 것이었죠. 그때도 우리는 저축을 했습니다. 돈이 없으면 투자를 할 수 없습니다. 그러니 첫번째로 해야할 일은 저축이지요.
11세 때도 나는 식료품점에서 일하고 받은 첫 봉급 50달러를 저축했습니다. 오늘날도 마찬가지입니다. 단지 현재는 동그라미의 수가 달라졌다는 것뿐이지요. 동그라미는 더 많아졌지만, 규칙과 원칙은 같습니다.
절약과 저축은 부자가 되기 위한 필수요인입니다.
반대로 '부자로 보이기 위해서', '즐거운 소비를 위해서'라는 목표로 일을 하는 태도는 부자가 되는 것을 불가능하게 해주는 방해요인입니다.
토마스 스탠리 박사가 미국의 백만장자를 연구하면서 만난 한 부자는 "나의 원칙은 저축하는 것"이라고 말했습니다. 먼 옛날 11살 때 아르바이트를 했을 때도, 그리고 지금 많은 돈을 벌고 있을 때도, 동그라미의 수만 달라졌을 뿐 그 원칙은 동일하다고 말했다고 합니다.
스탠리 박사가 만난 백만장자 사업가인 앨런은 자신의 인생 목표가 '부자로 보이는 것'이 아니라 '재정적으로 자립하는 것'이라고 밝혔다고 합니다.
"당신의 목표가 재정적인 안정이라면 당신은 그렇게 될 것입니다. 하지만 만일 당신의 동기가 즐거운 인생살이에 쓸 돈을 버는 것이라면.... 결코 성공할 수 없을 것입니다."
규모는 각자 다르지만, 우리 주위에는 소비를 위해, 부자로 보이기 위해, 즐거움을 위해 돈을 벌고 있는 사람들이 있습니다.
반면에 어떤 이들은 '재정적으로 자립하기 위해' 돈을 벌고 있는 사람도 있습니다. 누가 '진정한 부자'가 되고 행복한 삶을 만들어 나갈지는 너무도 명확합니다.
1. 당신 가족이 연간 의식주 비용으로 지출하는 액수가 얼마인지 알고 있습니까?
2. 당신의 재정적 미래를 계획하는 데 많은 시간을 투자합니까?
3. 당신은 검소합니까?
스탠리 박사가 당신에게 묻고 있습니다.
당신은 이 질문 모두에 "예"라고 답하셨습니까?
* * *
오프라인 경제노트 가족 공부모임 계획에 대한 따뜻한 성원에 감사드립니다. 이틀 동안 이메일과 댓글을 통해 100분 가까운 가족들이 모임 진행에 '자원봉사 가족'으로 참여하고 싶다는 말씀을 주셨습니다.
그리고 대한무역투자진흥공사(KOTRA)의 김현아님께서 강의장 제공 후원 의사를 밝혀주신 등 많은 분들께서 성원을 보내주셨습니다. 모든 분들께 고마운 마음입니다.
앞으로도 오프라인 무료 세미나 모임과 관련, 아래 내용에 대해 많은 의견주시면 고맙겠습니다.
1. 모임진행 자원봉사
2. 강의장 제공 후원(100~200석 규모)
3. 기업 후원
4. 강의를 듣고 싶은 강사 및 주제, 세미나 희망 요일 및 시간대
가족 여러분들의 따뜻한 성원에 진심으로 감사드립니다.
예병일 드림.
|
|
2005. 4. 12. 03:05, Technology/UML·모델링
[UML 제대로 알기] ⑤ 표준 넘나드는 UML의「적절한 사용」 연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용 UML은 표준 표기법으로써 그 자리를 확고히 했다. 이제는 한 걸음 더 나아가 UML을 보다 효과적으로 사용할 수 있는 방법을 생각해 볼 때이다.
음계를 이용하여 아름다운 음악을 작곡하듯이 UML을 이용하여 좋은 소프트웨어를 개발하는, 이른바 UML 사용의 베스트 프렉티스를 생각해야 한다. 간혹 베스트 프렉티스가 UML 표준을 준수하지 않는 경우도 있는데 중요한 것은 표준 준수 여부가 아니라 어느 것이 더 효과적이냐는 것이다. 성공적인 소프트웨어 개발을 위해서라면 표준을 넘나들 수도 있어야 한다.
이에 이번 글에는 유즈 케이스를 중심으로 UML을 잘 표현하기 위한 시맨틱을 제대로 정리하고 사용하는 방법에 대한 고찰해 보겠다.
* UML에서 유스케이스는 액터, 유스케이스, 유스케이스 다이어그램 등을 모두 포함하는 전체를 지칭하는 [유스케이스]와 특정 기능을 설명하는 유스케이스의 두 가지로 쓰인다. 이 글에서는 구분을 위해 전체를 지칭하는 것은 대괄호를 붙여 [유스케이스]로 사용하고 특정 기능을 설명하는 유스케이스는 그냥 유스케이스로 쓰겠다.
[유스케이스]는 시스템이 사용자에 의해서 어떠한 형태로 사용되는지를 기술하는 UML의 표준 표기법이다. 다르게 말하면 시스템이 갖추어야 하는 여러 기능적, 비기능적 요구사항(주로 기능적 요구사항)을 표현하는 방법이 [유스케이스]이다. 이전에도 요구사항을 기술하는 방법은 여러 가지가 있었지만 모델링의 표기법이 UML로 통합되면서 유스케이스가 요구사항을 기술하는 일반적인 방법으로 사용되어 오고 있다.
그런데 [유스케이스]는 표준 표기법임에도 불구하고 UML의 다른 표기법에 비해 그 구성 요소가 적고 그것들을 활용해서 표현하는 방식에 있어서 자유도가 매우 높다. UML의 구성 요소 중 UML 사용의 시맨틱적 요소가 가장 큰 것이 [유스케이스]라 할 수 있다. 유스케이스 사용의 다양한 방식들 중 많은 사람들의 지지를 받고 있는 이른바 베스트 프랙티스를 살펴봄으로써 유스케이스의 효과적인 사용법을 알아보기로 하자.
[유스케이스]의 큰 그림
[유스케이스]는 크게 [유스케이스] 모델과 [유스케이스] 기술서로 구성되어 있다. [유스케이스] 모델에 관한 것은 표준에 의해 정의되어 있지만 유감스럽게도 [유스케이스] 기술서는 특별히 표준이라 할 수 있는 것이 없다. 다만 방법론을 다루는 쪽이나 [유스케이스]를 많이 사용해 본 사람들이 [유스케이스] 기술서 작성을 언급할 뿐이다. [유스케이스] 모델은 [유스케이스]의 구성 요소인 액터와 유스케이스, 그리고 그들의 전체적인 관계를 다이어그램의 형태로 가진다. [유스케이스] 모델을 통해 시스템의 전체적인 개요와 구성을 쉽게 알 수 있다. [유스케이스] 모델에 나타난 구성 요소의 세부적인 내용은 [유스케이스] 기술서에 작성한다.
[유스케이스] 모델
[유스케이스]는 소프트웨어 시스템이 무엇을 만들어야 하는지, 어떠한 기능을 제공해야 하는지를 기술하는 표기법을 통칭해서 부르는 말이다. [유스케이스]는 시스템을 사용하는 사용자와 내가 만들어야 하는 시스템 자체를 설명하는 방법이다. [유스케이스]에서는 시스템을 사용하는 사용자를 액터(actor)라 하고 시스템의 행동을 유스케이스(use case)라고 한다. 그리고 내가 만들려고 하는 소프트웨어 시스템을 주제영역(subject)이라고 한다. 내가 만들 시스템에 대한 유스케이스들은 주제영역 안에 존재하고 주제영역 밖의 액터와 연결된다. <그림 1>은 [유스케이스] 다이어그램의 전형적인 예이다.
|
| | <그림 1> [유스케이스] 다이어그램의 전형적인 예 |
액터라고 해서 모두 사용자를 지칭하는 것만은 아니다. 주제영역으로 정의되는 시스템과 연결되어 상호작용하는 외부 시스템도 액터로 정의한다. 하나의 시스템을 여러 팀이 나누어 개발할 때 다른 팀에서 만든 모듈도 나의 팀의 관점에서 본다면 액터로 정의할 수 있다. 쉽게 말해서 내가 만들어야 하면 유스케이스이고 남이 만들면 액터가 된다. <그림 1>과 같은 [유스케이스] 다이어그램을 통해 시스템이 어떠한 액터들과 상호작용하며 어떤 기능을 액터에게 제공하는 지를 일목요연하게 알 수 있다.
[유스케이스] 모델 구성 요소에 대한 세부적인 내용은 [유스케이스] 기술서에 정의하고 [유스케이스] 다이어그램에서는 어떤 [유스케이스] 기술서와 연결되는지 정도를 첨가해 주면 된다. 이는 현존하는 대부분의 UML 모델링 툴이 지원해 주는 기능이다.
‘역할’을 뜻하는 액터
액터는 시스템의 사용자 측면을 정의할 때 사용한다. 액터는 보통 특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 시스템이 수행하는 역할이라고 정의하고 <그림 2>와 같이 표기한다.
여기서 주목해야 할 것은 역할이라는 말이다. 액터의 표기법이 사람 모양을 하고 있어서 사람만이 액터라는 선입견을 가질 수 있는데 사람과는 관계가 없고 그 사람이 수행하는 역할과 더 밀접한 관계가 있다.
액터는 역할에 더 가깝기 때문에 사람 이름보다 직책 이름이 많이 사용된다. 만약 웹사이트 애플리케이션이라면 사이트 회원, 비회원, 관리자 등이 액터로 사용될만한 것들이다.
관심을 갖고 있는 주제영역 시스템과 상호작용하는 외부 시스템도 전형적인 액터이다. 외부 시스템은 주제영역 내의 시스템의 요청에 따라 정보를 제공하는 것이 일반적이다. 전자상거래가 필요한 시스템이라면 외부 시스템으로 신용 정보나 금융 정보 등을 제공하는 시스템을 생각할 수 있고, 여행 상품을 제공하는 시스템이라면 외부 시스템으로 호텔 예약 시스템이나 교통편 예약 시스템 등을 생각할 수 있겠다. 다음은 액터의 전형적인 사례이다.
◆ 사람 : 텔레마케터, 관리자 등
◆ 외부 시스템 : 신용 정보 시스템, 예약 시스템 등
◆ 장치 : 온도 감응 장치, 출입 통제 장치 등
◆ 외부 조직 : 금융감독원, 보안 조직 등
◆ 이벤트 : 매일 밤 12시, 월급날 등
이벤트도 액터?
액터는 시스템의 기능적 요구사항을 정의할 때 매우 유용하게 사용된다. 특히 이벤트 발생 시점과 같은 액터는 시스템의 기능적 요구사항을 정의하는 데 매우 유용하다. 주기적으로 수행되는 배치 작업이 일반화되어 있는 현대의 시스템에서 이벤트 발생 시점은 매우 훌륭한 액터가 된다.
사실 시간과 같은 이벤트를 액터로 해도 되느냐 하는 부분에 대해서는 논란의 여지가 있는 것도 사실이다. 액터는 시스템을 사용함으로써 원하는 목적을 달성하려는 사람 혹은 외부 시스템으로 정의하기도 하는데, 시간 자체는 특별한 목적을 가지지 않기 때문에 액터로 해서는 안 된다고 주장하는 경우도 있다.
[유스케이스]는 그 사용에 있어 자유도가 높기 때문에 이러한 논쟁이 유달리 많기도 하다. 중요한 것은 시스템의 요구사항을 [유스케이스]로 정의하고 보다 많은 사람이 그것을 통해 서로의 생각을 얼마나 잘 공유할 수 있느냐는 것이다. 이벤트를 액터로 하는 것은 시스템의 기능 정의에 많은 도움이 된다고 생각한다.
액터의 분류
[유스케이스]의 창시자인 이바 야콥슨은 액터를 주요(primary) 액터와 보조(secondary) 액터의 두 가지로 분류했다. 주요 액터는 시스템에 어떠한 작업의 실행을 요구하는 능동적인 입장의 액터로 유스케이스를 기동하는 역할을 수행한다. 보조 액터는 시스템의 요청에 따라 수동적으로 어떤 작업을 해 주는 액터로써 유스케이스로부터 어떠한 요청이나 메시지를 전달 받는 액터를 말한다. 최근에는 액터를 더 세분화해서 분류하기도 하는데, 액터의 성격에 따라 크게 네 가지로 나눌 수 있다.
◆ 유스케이스를 기동시키는 액터
◆ 시스템의 요청에 따라 정보를 제공하는 외부 액터
◆ 시스템이 제공하는 정보를 단순히 수신하는 액터
◆ 다른 액터와 시스템간의 상호 작용을 돕는 프록시 역할의 액터
네 가지 액터 유형 중 특이한 것이 프록시 역할을 하는 액터이다. 액터는 유스케이스와 연결될 뿐 액터와 액터는 서로 연결되지 않게 하는 것이 일반적인 액터의 설계 방식으로 여겨져 왔다. 그러나 액터끼리 서로 연결되게 모델링을 하는 것이 시스템을 좀 더 이해하기 쉽게 만드는 경우도 있다.
<그림 3>은 전화로 예약을 받는 시스템의 예이다. 시스템을 직접 사용하는 사용자는 전화를 받는 창구 직원이 되겠지만 예약이라는 목적을 가지는 것은 고객이기 때문에 고객이 창구 직원에게 전화를 걸어 시스템을 사용하는 것은 <그림 3>처럼 모델링하는 것이 보다 효과적이게 된다. <그림 3>과 같은 시스템은 보통 클라이언트/서버 유형이 애플리케이션인 경우가 많은데 이후 시스템을 웹으로 확장시켜 고객이 직접 웹 사이트를 통해 예약이 가능하도록 하게 되면 창구 직원 액터가 웹을 통한 예약 유스케이스로 변환될 수도 있다.
유스케이스
시스템이 액터에게 주목한 만한 결과를 내놓기 위해 수행하는 여러 작업들의 집합을 유스케이스라고 한다. 즉, 앞서 나온 예약 접수나 구매 주문, 주문 현황 점검과 같은 것들이 유스케이스이다. 유스케이스는 시스템이 수행하는 특정 기능에 대해서 그 기능의 수행을 원하는 액터와 시스템간의 상호 작용과 시스템 내부에서 발생하는 모든 가능한 사항을 기술한다. 유스케이스는 <그림 4>와 같이 표기한다.
유스케이스의 구성 요소는 여러 가지가 있지만 이름과 작업 흐름이 제일 중요하다. 유스케이스 이름은 [유스케이스] 모델에서 중요하고 작업 흐름은 [유스케이스] 기술서에서 중요하다. 유스케이스의 이름을 지을 때는 동사나 동사구의 형태로 능동형을 사용하는 것이 좋다. 유스케이스의 작업 흐름을 기술할 때 유의해야 할 점은 ‘무엇’에 대한 것을 작성해야 한다는 것이다.
간혹 유스케이스가 무엇이 아닌 ‘어떻게’를 기술하게 작성하는 경우가 있는데, 이는 그리 바람직하지 않은 모습이다. 유스케이스는 시스템이 무엇을 제공하고 액터는 무엇을 얻는가를 기술하는 방편이지 시스템을 어떻게 구축할 것인가에 대한 것은 아니다.
유스케이스 간의 관계
유스케이스와 유스케이스 사이에는 서로 밀접하게 연관되어 있어 상호간에 관계를 가지는 경우가 있다. 유스케이스는 포함(include), 확장(extend), 일반화(generalization)의 세 가지 관계 유형이 있다.
포함 관계
하나의 유스케이스가 유스케이스 내의 작업 흐름의 과정 안에 다른 유스케이스의 작업 흐름을 포함하게 하는 관계이다. 포함 관계는 <그림 5>와 같이 표기한다.
유스케이스는 액터와 시스템간의 상호 작용이나 시스템 내부의 작업 등을 기술한다. 이때 여러 유스케이스에서 비슷한 작업이 공통으로 발생하는 경우가 있을 수 있다. 이때 이렇게 공통으로 발생하는 유스케이스의 특정 부분을 하나의 유스케이스로 따로 분리하고 포함 관계를 통해 정의하는 것이 가능하다. 이는 프로그램에서 서브 루틴을 호출하는 개념과 유사하다.
포함 관계에서 유스케이스는 ‘포함하는(including) 유스케이스’와 ‘포함되는(included) 유스케이스’로 나눌 수 있다. 유스케이스는 액터가 그 작업 흐름을 기동시키는데, 포함 관계에서 ‘포함되는 유스케이스’는 액터가 아닌 ‘포함하는 유스케이스’가 작업 흐름을 기동시킨다. 그래서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 없으면 제 구실을 하지 못하고 ‘포함하는 유스케이스’에 합쳐져야 제 기능을 하게 된다.
포함 관계에서 ‘포함되는 유스케이스’를 ‘포함하는 유스케이스’에 포함시킬지 여부는 ‘포함하는 유스케이스’에서 결정한다. 보통 조건절과 같은 내용이 ‘포함하는 유스케이스’에 들어가게 되고 조건절의 만족 여부에 따라 ‘포함되는 유스케이스’를 수행할 지가 결정된다. <그림 6>과 같은 유스케이스가 포함 관계의 가장 전형적인 예이다.
주문 결제 유스케이스는 액터가 결정한 결제 형태에 따라 현금 결제, 카드 결제, 포인트 결제 유스케이스 중에 하나를 포함하게 된다. 포함 관계는 유스케이스 간의 관계를 설정할 때 가장 쉽게 사용할 수 있는 관계 설정 방법이다.
확장 관계
하나의 유스케이스의 흐름이 다름 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계이다. 확장 관계는 <그림 7>과 같이 표기한다.
확장 관계에서 유스케이스는 ‘확장되는 유스케이스’와 ‘확장하는 유스케이스’로 나눌 수 있다. ‘확장되는 유스케이스’가 액터와 상호작용하면서 작업 흐름을 수행하던 중 확장하는 조건이 만족하게 되면 그 만족되는 시점에서 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’에 합쳐져서 작업 흐름을 수행한다. 예를 들면 특정 작업을 수행하던 중 사용자가 도움말 버튼을 눌러서 도움말 내용을 확인하는 것 같은 작업이 전형적인 확장 관계이다.
확장 관계에서는 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 특정 지점으로 합쳐지게 되는데, 이 지점을 확장 지점(Extension point)이라고 한다. 확장 지점은 ‘확장되는 유스케이스’에 위치하게 되고 ‘확장되는 유스케이스’는 여러 개의 확장 지점을 가질 수 있다. ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 어떤 확장 지점으로 확장될 것인가는 확장 관계에 표시한다. 확장 관계는 확장하는 조건과 어떤 확장 지점으로 확장될 것인가에 대한 정보를 보유한다.
유스케이스가 합쳐져서 보다 큰 작업을 한다는 점에서는 포함 관계와 확장 관계가 크게 다를 바는 없지만 그 적용되는 방법과 내용상에 있어서는 몇 가지 차이점이 존재한다.
첫째, 포함 관계는 ‘포함하는 유스케이스’가 주 흐름 유스케이스이고 ‘포함되는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것인 데 반해 확장 관계에서는 ‘확장되는 유스케이스’가 주 흐름 유스케이스이고 ‘확장하는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것이 된다.
둘째, 포함 관계에서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 정상적으로 동작하기 위해서 반드시 필요한 필수 요소인 데 반해 확장 관계에서 ‘확장하는 유스케이스’는 선택 사항으로써 ‘확장되는 유스케이스’는 ‘확장하는 유스케이스’와 상관없이 독립된 기능을 수행할 수 있다.
보통 유스케이스에 내용을 추가할 때는 포함 관계나 확장 관계 중 어느 방법을 사용하더라도 큰 무리가 없다. 약간의 차이가 있다면 포함 관계로 내용을 추가하려고 할 때에는 내용 추가의 기반이 되는 ‘포함하는 유스케이스’의 내용 변경이 반드시 동반되어야 하는 데 반해 확장 관계로 내용을 추가할 때는 내용 추가의 기반이 되는 ‘확장되는 유스케이스’의 내용 변경이 불필요하다는 것이다. 따라서 이미 존재하는 유스케이스 도큐먼트 내용의 수정이 가능한지 불가능한지 여부가 포함 관계로 내용을 추가할 것인지 확장 관계로 내용을 추가할 것인지를 선택하는 기준이 될 수 있다.
일반화 관계
유스케이스 간의 일반화 관계는 객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미이다. 일반화 관계는 <그림 8>과 같이 표기한다.
자식 유스케이스는 새로운 작업 흐름이나 별도의 속성, 확장 지점, 다른 유스케이스와의 관계 등을 정의할 수 있다. 하나의 유스케이스는 여러 개의 부모 유스케이스를 가질 수 있고, 자신이 여러 유스케이스의 상위 유스케이스가 될 수도 있다.
유스케이스의 레벨
UML에 정의되어 있는 [유스케이스]의 표준에는 유스케이스에 대한 레벨이나 범위에 대한 개념이 없다. 레벨이나 범위는 유스케이스를 작성하는 과정에서 그 필요성이 자연스럽게 도출된 개념들이다. 레벨이 높은 유스케이스가 넓은 범위의 내용을 광범위하게 다루고 레벨이 낮은 유스케이스가 보다 적은 범위의 내용을 상세히 다룬다. <그림 9>는 유스케이스의 레벨에 대한 개념을 보여준다.
보통 유스케이스의 레벨은 그 유스케이스를 필요로 하는 사람에 따라 다르게 구성된다. 전체 시스템을 개괄적으로 보기를 원하는 매니저나 관리자들은 보다 높은 레벨로 구성된 유스케이스를 필요로 한다. 이들에게는 어떻게 유스케이스가 수행되는가는 주 관심 분야가 아니고 보다 높은 레벨의 관점으로 시스템을 바라보고 싶어 한다. 반면 요구사항 분석을 통해 시스템 전체의 모습을 구성해야 하는 시스템 분석가들은 보다 세부적으로 어떠한 기능을 수행하는지를 볼 수 있는 수준이 필요하다.
반면 개발자들은 요구되는 기능을 어떻게 실제로 구현할 것인지를 정의할 수 있는 수준의 유스케이스를 필요로 한다. 유스케이스를 통해 요구사항에 대한 의사소통을 하는 사람의 역할이 무엇이냐에 따라 유스케이스는 다른 레벨의 형태를 띠게 된다.
유스케이스의 레벨에 관련해서는 ‘왜’라는 물음과 ‘어떻게’란 물음이 중요한 역할을 한다. <그림 10>에서와 같이 유스케이스의 작업 흐름 내용에 대해서 ‘왜’라는 물음에 대한 답이 상위 레벨 유스케이스가 되고 ‘어떻게’라는 물음에 대한 답이 하위 레벨 유스케이스가 된다.
적절한 레벨은?
유스케이스가 많이 사용됨에 따라 유스케이스가 어느 정도의 범위를 커버하도록 구성하는 것이 가장 적절한지에 대한 많은 고민이 있어왔다. 유스케이스를 작성하는 데 있어서 전형적으로 등장하는 좋지 않은 예 중에 하나가 같은 레벨의 유스케이스 간에 상세화 정도의 차이가 생기는 것이다. 같은 레벨의 유스케이스는 비슷한 정도의 범위를 비슷한 상세화 정도로 기술해야 한다.
레벨은 크게 요약(summary), 사용자 목적(user goal), 하위 기능(sub function)으로 나눌 수 있다. 사용자 목적 레벨이 요구사항을 분석하는 데 가장 적절한 수준이다. 사용자 목적 레벨에서 ‘왜’라는 질문을 통해서 내용을 정리하면 요약레벨의 유스케이스가 되고 ‘어떻게’라는 질문을 통해서 내용을 상세화하면 하위 기능 유스케이스가 된다. 사용자 목적 레벨의 유스케이스를 판단할 때 다음과 같은 정도의 기준을 사용할 수 있다.
◆ 액터가 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도의 작업
◆ 작업이 완료되었을 때 액터가 자리를 뜨는데 어려움이 없는 정도
하나의 유스케이스는 사건 흐름에 보통 3~9 스텝 정도를 밟는 것이 좋다. 단 2스텝으로 끝나버린다거나 10스텝 이상으로 길어지는 것은 유스케이스를 이해하는 데 별로 좋지 않다. 만약 스텝이 길다면 다음의 예와 같은 스텝들을 하나의 스텝으로 합쳐서 스텝의 수를 조절할 수 있다.
◆ 같은 액터가 여러 스텝을 점유한 경우
◆ 액터가 사용자 인터페이스를 사용하는 부분을 여러 스텝을 통해 기술한 경우
그래도 스텝이 길다면 그 유스케이스는 너무 큰 유스케이스이거나 너무 상세화된 유스케이스인 경우가 대부분이다. 유스케이스가 크다면 여러 개의 유스케이스로 나누는 것을 고려해야 하고 너무 상세화된 유스케이스라면 ‘왜’라는 질문을 통해 레벨을 높이도록 해야 한다.
[유스케이스] 기술서
앞에서 [유스케이스]라고 하는 요구사항 분석 설계 표기법에 사용하는 여러 요소들에 대해 살펴보았다. UML이 [유스케이스]에 대해 표준으로 정의하고 있는 것은 액터나 유스케이스, 유스케이스 간의 관계와 같은 구성 요소와 그들이 서로 어떻게 연계되어 전체적인 모습을 보여주는 지와 같은 것들이다. 이것은 요구사항 분석 설계 메커니즘으로써의 [유스케이스]의 반쪽밖에 되지 않는다.
[유스케이스]의 또 다른 반쪽은 [유스케이스] 기술서라고 하는 문서의 형태로 존재하는데, 이는 표준으로 정의되어 있지 않다. 오히려 방법론 등에서 [유스케이스] 기술서를 어떠한 형태로 어떻게 작성해야 하는지를 제시하고 있다. 그래서 다양한 형태의 [유스케이스] 기술서가 정의되어 사용되고 있다. 그러면서 베스트 프랙티스가 정립되면서 표준이라 할 수 있을 정도의 [유스케이스] 기술서가 만들어 졌다.
구성 요소
[유스케이스] 기술서에는 대체로 다음과 같은 내용들이 들어가게 된다.
◆ 이름 : 유스케이스의 이름
◆ 반복 : 반복이 이루어진 횟수. 버전과 유사한 개념
◆ 액터 : 유스케이스와 관련된 액터들의 목록
◆ 범위 : 유스케이스가 어떤 수준의 범위를 다루는지에 대한 설명
◆ 레벨 : 유스케이스가 어느 레벨의 것인지에 대한 설명
◆ 요약 : 유스케이스가 어떠한 일을 하는 지를 개략적으로 설명하는 내용
◆ 주 작업 흐름 : 유스케이스가 수행하는 작업의 흐름을 여러 스텝으로 기술한 내용 중 가장 전형적으로 발생하는 것. 유스케이스가 설명하는 업무의 80% 정도가 주 작업 흐름에서 커버한다.
◆ 대안 흐름 : 주 작업 흐름을 따르는 과정에 조건에 따라 다르게 작업하는 것을 기술한 내용
◆ 예외 흐름 : 작업 흐름이 진행되는 과정에서 예외사항이 발생하였을 경우 어떻게 처리해야 하는 지를 기술한 내용
◆ 사전 조건 : 유스케이스가 제대로 작동하기 위해 사전에 만족되어야 하는 조건을 기술
◆ 사후 조건 : 유스케이스가 끝나면 어떠한 결과가 제공되는지를 기술
◆ 비즈니스 룰 : 유스케이스의 작업 흐름과 관련해서 업무 규칙에 관한 내용을 기술
◆ 사용자 화면 : 사용자 인터페이스 화면에 대한 내용
◆ 작성자 : 유스케이스의 작성자
◆ 작성일 : 유스케이스 작성일
몇 가지의 기술서 작성 양식
앞에서 여러 가지 [유스케이스] 기술서의 구성 요소에 대해서 설명했지만 일반적으로는 [유스케이스] 기술서의 구성 요소들 중 필요한 것을 선별하여 [유스케이스] 기술서 양식을 만들어서 [유스케이스]의 내용을 만드는 데 사용하게 된다. [유스케이스] 기술서의 양식은 프로젝트의 규모나 문서화를 얼마나 세세하게 할 것인지 등을 살펴보고 적합한 수준에서 결정한다.
프로젝트의 규모가 크거나 프로젝트에 대한 위험 부담이 높은 프로젝트에서는 대개 엄격한(rigorous) 방법론을 사용하는 것이 일반적이다. 엄격한 방법론에서는 산출물의 형식이나 내용의 유무를 중요하게 생각한다. [유스케이스] 기술서에도 예외가 아니어서 항목이나 내용이 많고 그 내용을 규칙에 따라 작성하도록 요구한다. 유스케이스의 엄격한 양식에는 앞서 기술한 [유스케이스] 기술서의 구성 요소가 거의 대부분 들어간다.
프로젝트의 규모가 작아서 산출물 작성의 형식에 그리 큰 비중을 두지 않는 경우나 혹은 기민한 방법론을 채택해서 산출물의 신속한 작성과 변경이 요구되는 경우는 [유스케이스] 기술서의 형식을 간략하게 사용하는 경우도 있다. <표 1>은 간략화한 양식의 예이다.
| <표 1> [유스케이스] 기술서의 간략화한 양식 |
| |
|
유스케이스 25 로그인
주요액터: 사용자
범위: 애플리케이션
레벨: 하위기능
사용자는 시스템에 자신을 알리기 위해 로그인을 한다. 사용자는 사용자이름과 패스워드를 입력한다. 시스템은 사용자를 확인하기 위해 사용자가 제시한 사용자이름과 패스워드를 검증한다. 사용자 이름과 패스워드가 일치하면 시스템은 사용자에게 시스템을 사용할 수 있는 권한을 준다.
만약 사용자가 제시한 사용자이름과 패스워드가 관리자 레벨의 것일 경우 사용자는 시스템을 조작할 수 있는 권한을 함께 부여 받는다.
만약 사용자이름이 존재하지 않거나 패스워드가 틀릴 경우 권한의 부여는 거부되고 사용자는 시스템을 이용할 수 없게 된다.
|
| |
|
| <표 2> RUP에서 제시하고 있는 유스케이스 기술서 양식 |
| |
|
1. Use Case Name
1.1. Brief Description
…text…
1.2. Actors
…text…
1.3. triggers
…text…
2. Flow of events
2.1. Basic flow
…text…
2.2. Alternative flows
2.2.1. Condition 1
…text…
2.2.2. Condition 2
…text…
2.2.3. …
3. Special Requirements
3.1. platform
…text…
3.2. …
4. Preconditions
…text…
5. Postconditions
…text…
6. Extension Points
…text…
|
| |
|
점증적이며 반복적인 작성 프로세스
소프트웨어 개발 방법론에서는 점증적·반복적 접근이 많이 사용되는데 [유스케이스]의 작성에도 예외는 아니다. 대부분의 [유스케이스] 작성 프로세스가 반복을 통해 점증적으로 [유스케이스]의 내용을 추가하는 방식을 취하고 있다. <그림 11>은 세 번의 반복을 통해 점진적으로 유스케이스의 항목을 추가해 나가는 유스케이스 작성 프로세스의 모습을 간략히 한 모습이다.
|
| | <그림 11> 점진적으로 유스케이스 항목을 추가해 나가는 모습 |
초기(Initial) 단계에서는 시스템의 범위를 정하고 액터와 유스케이스를 찾는다. 여기서 액터와 유스케이스는 이름과 간략한 요약 정도만을 기술해 주면 된다. 기반(Base) 단계에서는 초기 단계에서 찾아낸 액터와 유스케이스의 내용을 보강한다. 각 유스케이스에 대해서 사건 흐름을 기술하고 선행 조건과 사후 조건을 기술한다. 상세(Elaboration) 단계에서는 유스케이스의 모든 세부 항목을 완성 시키는 단계이다. 각 유스케이스에 사건 흐름에 대해 대안 흐름과 예외 흐름을 추가한다.
코번의 12 단계 정의
writing effective use case의 저자인 코번은 유스케이스를 작성하는 12단계를 정의했다.
[1] 시스템의 범위와 경계 설정
[2] 시스템에 관계된 모든 액터 찾기
[3] 액터가 시스템을 통해 얻으려고 하는 목적들 찾기
[4] 각 액터에 대한 최상위 유스케이스(summary use case) 설정
[5] 최상위 유스케이스들에 대한 정제 작업(시스템 범위의 재확인)
[6] 상세 작업을 할 유스케이스 선택
[7] 이해 관계자와 그들의 목적, 선행 조건, 후행 조건 등을 뽑아냄
[8] 주 성공 작업 흐름 작성
[9] 대안 흐름과 예외 흐름 찾기
[10] 대안 흐름과 예외 흐름 작성
[11] 복잡한 스텝을 하위 유스케이스로, 자잘한 스텝들은 모아서 하나로 합치는 작업 수행
[12] 유스케이스 조절 작업(읽기는 쉬운지, 구색은 갖췄는지, 이해 관계자는 만족하는지) 수행
코번의 12단계도 앞서 설명한 작업 절차와 그리 큰 차이는 보이지 않는다. 중요한 것은 반복적으로 점증적으로 [유스케이스]를 작성해 나간다는 것이다.
UML을 제대로 사용하려면 이것은 기억하자
[유스케이스] 모델과 [유스케이스] 기술서 등 [유스케이스]와 관련한 여러 가지를 살펴보았다. 이제는 [유스케이스]와 관련해서 유의해야 할 점을 짚어 보기로 하자.
액터와 유스케이스의 연결
UML 표준에는 액터와 유스케이스의 연결에 단순한 직선 연결만을 사용하고 있는데 화살표를 사용해서 나름의 의미를 부여하는 경우도 있다. 다음은 화살표 사용의 몇 가지 사례이다.
◆ 주요 액터가 유스케이스를 기동하는 경우에만 액터에서 유스케이스 쪽으로 화살표 머리 사용
◆ 주요 액터가 유스케이스를 기동하거나 유스케이스가 보조 액터를 기동하는 경우 기동하는 쪽으로 화살표 머리 사용.
◆ 단 방향 커뮤니케이션에만 화살표 머리 사용. 기대되는 응답이 없는 경우에 사용한다(예 : 프린터로 명령을 보내는 경우, 정부 기관에 내용을 통보하는 경우)
[유스케이스] 다이어그램에서 화살표를 사용할 때에는 데이터의 흐름이 아니라 커뮤니케이션의 기동 방향을 보여주는 데 사용하는 것이 좋다. 데이터는 보통 액터와 유스케이스 사이에 양방향으로 흐르는 것이 일반적이기 때문에 데이터의 흐름으로 화살표를 사용하게 되면 양방향 화살표가 되게 되고 이것은 다이어그램을 어지럽히는 원인이 된다.
전통적인 실수들
[유스케이스]를 작성하는 데 있어서 다음과 같은 실수가 자주 발생한다.
◆액터가 없는 유스케이스, 시스템이 없는 유스케이스
액터와 유스케이스는 반드시 서로 연결되어 있어야 한다. ‘포함되는 유스케이스’나 ‘확장하는 유스케이스’의 경우도 포함 또는 확장되어 액터와 연결된다. 간혹 혼자 동떨어져 있는 유스케이스가 있는 시스템이 보이기도 하는데 이는 잘못 작성된 것이다.
◆사용자 인터페이스의 내용을 너무 상세히 담고 있는 [유스케이스]
[유스케이스]는 기능적 요구사항을 담는 것이기 때문에 사용자 인터페이스의 상세한 내용은 담지 않는다. 다만 사용자 인터페이스를 상세하게 설명한 문서에 대한 참조 정도를 추가하면 된다.
◆너무 낮은 레벨의 [유스케이스]
구현에 대한 상세한 내용이 담겨 있는 [유스케이스]는 적절하지 않다. [유스케이스]에 소스코드 레벨의 설명이 들어 있는 경우가 간혹 있는데 ‘왜’라는 물음을 통해 상위레벨의 [유스케이스]로 만드는 것이 좋다.
◆전산인의 언어를 사용한 유스케이스
[유스케이스]는 요구사항을 기술하고 그것을 통해 여러 관여자 들과 의사소통을 하기 위해 만드는 것이다. [유스케이스]에 사용하는 용어는 많은 사람이 이해할 수 있도록 보편적인 용어를 사용해야 한다.
◆애플리케이션 관점의 유스케이스
유스케이스는 액터의 관점에서 기술해야 한다. 시스템의 관점에서 기술한 유스케이스는 적절하지 않다.
◆‘~해야 한다’ 식의 표현
요구사항을 기술하는 전통적인 방법에서는 ‘시스템은 ~해야 한다’는 식의 표현이 자주 등장한다. 이러한 표현을 [유스케이스]에서는 사용하지 않는 것이 좋다. 만약 고객의 요구로 ‘~해야 한다’는 식의 표현을 넣어야 한다면 [유스케이스]의 요약 부분에 넣는 것이 좋다. 작업 흐름 부분에는 ‘~해야 한다’가 아닌 ‘~한다’라는 표현을 사용해야 한다.
유스케이스 작성에 대한 10가지 잘못
[1]다른 형태의 요구사항 문서는 만들 필요가 없다. [유스케이스]면 요구사항을 충분히 반영할 수 있다.
아니다. 요구사항 문서는 요구사항을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 요구사항은 ER모델이 적합하고, 화면 구조에 대한 요구사항은 그래픽이 가미된 문서가 더 적합하다.
[2]읽는 사람이 [유스케이스]의 목적에 대해 이해하기 힘들게 한다. [유스케이스]의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 [유스케이스]를 실제로 구현할 때 어떻게 해도 상관없을 것이다.
[유스케이스]를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 [유스케이스]를 작성할 필요가 있다. 간혹 어떻게 [유스케이스]를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다.
[3][유스케이스]의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 사용자는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가?
[유스케이스]는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 [유스케이스]를 작성해야 한다.
[4][유스케이스] 기술서에 비기능적 요구사항과 사용자 인터페이스 디테일을 포함시킨다.
유스케이스의 작업 흐름에 사용자 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 사용자 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다.
[5]초기 [유스케이스] 다이어그램에 포함 관계와 확장 관계를 많이 사용한다. 그러면 유스케이스를 작은 단위의 것으로 나눌 수가 있다.
초기 버전의 유스케이스는 상위레벨의 유스케이스를 작성하고 반복을 거치면서 보다 상세화한 유스케이스를 작성하는 것이 좋다. CRUD를 처리하는 유스케이스가 대표적인데, 초기에는 ‘관리하다’라는 유스케이스로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 유스케이스로 세분화한다.
[6]비즈니스 룰을 정의하는 것에는 관여하지 말라.
비즈니스 룰을 만들고 사용하는 것은 사용자이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 [유스케이스]를 통해 표현하도록 독려해야 한다.
[7][유스케이스]의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다.
[유스케이스]는 요구사항에 대한 표준 표기법인데, 소프트웨어 시스템에 대한 요구사항을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다.
[8]만약 사용자를 [유스케이스] 정의에 관여시킨다면 그냥 그래라. 왜 사용자와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다.
될대로 되라는 식의 태도는 좋지 않다. 사용자에게 [유스케이스]를 충분히 이해시키고 [유스케이스]를 통해 효과를 볼 수 있도록 노력해야 한다.
[9][유스케이스]를 한 번에 아주 상세하게 만들어라.
반복적으로 점증적으로 [유스케이스]를 작성하는 것이 좋다.
[10][유스케이스]를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다.
반복적으로 점증적으로 작성하고 중간중간 계속 사용자나 도메인 전문가의 피드백을 받아야 한다.
아름다운 표현 양식이 되길 바라며
요구사항을 수집하는 일은 오래 걸리거나, 잘못된 것을 기록하거나, 발생하지 않을 일을 추측하거나, 시간에 맞춰 허겁지겁 끝내는 등과 같은 결과를 초래하는 경우가 많다. 이는 요구사항 수집이 비생산적인 경로를 거치거나, 요구사항 수집을 무시하거나, 요구사항 수집 자체만을 위해 매달리거나, 요구사항을 한 사람이 결정하기 때문에 발생한다.
[유스케이스]는 이러한 요구사항 수집에 사용하기 좋은 방법 중 하나이다. [유스케이스]의 표준을 따라 보편화된 방법으로 요구사항을 기술하면 보다 많은 사람들이 사용할 수 있을 것이다. 물론 표준에 대한 준수 여부보다는 [유스케이스]의 내용을 어떠한 생각을 가지고 채워 넣었느냐가 더욱 중요하다.
UML은 단순한 표기법에 지나지 않지만 아주 좋은 표기법임에는 틀림없다. 마치 한글처럼. 아름다운 우리말을 한글이 잘 표현하듯이 소프트웨어 개발에 대한 여러분의 멋진 생각들을 UML을 통해 잘 표현해 보기를 바란다.@
* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.
이경원 (한국오라클) 2005/04/11 [UML 제대로 알기] ④ 닷넷 환경 UML 툴 활용 가이드 연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용 케이스 도구는 양날의 검이다. 활용도에 따라서 소프트웨어를 죽일 수 도 있다. 래쇼날 로즈(이하 로즈) 같은 케이스 도구는 능숙하게 다룰 수 있어야 되기까지 많은 학습 곡선을 필요로 한다. 능숙해진 다음에도 여전히 불편하다.
하지만 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 |
로즈를 처음 설치하고 나면 처음엔 아무것도 없다. 도구상자에 뭔가 추가된 것도 아니고, 특별히 뭔가가 설치되었다는 느낌을 받을 수가 없는데(굳이 뭔가 설치되었다는 느낌이라면 아마 비주얼 스튜디오 닷넷의 실행 속도가 눈에 띄게 느려졌다는 느낌이 될 것이다) 솔루션 탐색기를 눈여겨 보면 평소에 볼 수 없던 아이콘이 하나 생겨있음을 알 수 있다. 그 아이콘을 주저 없이 클릭해 보자.
동기화 아이콘을 클릭하면 로즈와 비주얼 스튜디오 닷넷이 동기화되어 mdx 파일을 생성한다. 그리고 Model Explorer 창이 새로 생기고 프로젝트에 포함되어 있는 개체들을 탐색할 수 있게 해준다.
|
| | <화면 3> 로즈 XDE를 이용하여 Iterator 패턴을 디자인한 모습 |
로즈를 사용하여 모델링을 어느 정도 마쳤으면, 다시 동기화 버튼을 눌러 순 공학할 수 있다.
감동의 기능
[1] 너무 깔끔한 코드를 생성하고 닷넷 환경에서 권장하는 주석 내용들을 그대로 생성해준다. 다른 도구들은 생성한 코드의 indentation이 잘 되지 않거나 참조한 라이브러리의 네임 스페이스를 제대로 표시하지 않는 경우가 많은데, 그런 단점이 사라졌다.
[2] 참조한 라이브러리의 개체들을 모두 설계에 사용할 수 있게 해준다. 다른 모델링 도구들은 기본으로 포함되거나 직접 작성한 개체들만이 사용가능 한 경우가 대부분인데, 최상의 도구다운 기능을 보여준다.
[3] 깔끔하고 예쁜 출력을 지원한다. 다른 설계 도구의 경우 한 페이지 또는 두 페이지에 깔끔하게 출력할 수 있는 기능에 대한 지원이 부족한데, 깔끔하고 예쁘장한 산출물을 만들 수 있도록 도와준다.
[4] ASP.NET/ASP/Service Page 들에 대한 설계를 지원한다. Web Presentation Pattern을 응용한 설계가 필요할 때 아주 유용하다.
단점이라면, C#으로 작성한 메쏘드의 수정이 아주 불편하다. 또한, RUP를 너무 강조하는 경향이 있어 닷넷의 빠른 개발과는 어울리지 않는 부분이 엿보이고, 일일이 동기화를 해 주어야 코드와 설계가 연동이 되는데, 에러를 자주 발생하여 동기화가 되지 않는 경우가 빈번히 발생한다.
볼랜드 투게더
비주얼 스튜디오 닷넷에서 다른 유명한 설계 도구인 투게더를 사용할 수 있다. 투게더 역시 로즈와 마찬가지로 비주얼 스튜디오 닷넷에 애드인되어 설치된다. ‘볼랜드 투게더 for 비주얼 스튜디오 닷넷 2.0’을 설치하면 비주얼 스튜디오 닷넷에 투게더 VS.NET Model View라는 창이 생성된다.
|
| | <화면 5> 투게더 for 비주얼 스튜디오 닷넷 Model View |
또한 솔루션 탐색기에 ModelSupport라는 폴더가 생성되고 폴더 내부에는 .txvpak이라는 확장자를 가지는 모델 파일이 생성된다. 이 파일을 더블클릭하여 모델링 도구를 사용하여 설계할 수 있는 설계 창을 열 수 있다.
|
| | <화면 6> 투게더를 사용해서 Iterator 패턴을 디자인 한 모습 |
투게더는 로즈와 달리, 코드의 실시간 생성을 지원한다. <화면 6>에서 보이는 클래스 아이콘을 더블클릭하면 코드를 곧 바로 생성하게 된다. 코드를 수정하건, 설계를 수정하건 간에 설계 또는 코드의 수정 사항이 즉시 상호간에 적용되게 되어있다.
감동의 기능
[1] 필자가 투게더를 사용해 보고 가장 감동적이었던 기능은 시퀀스 다이어그램을 실시간으로 생성해 주는 기능이었다. 메쏘드가 특정 객체들을 사용하도록 구성되었으면, 투게더는 그 메쏘드의 시퀀스 다이어그램을 아주 믿을만한 수준으로 자동 생성해 준다. <화면 7>은 Petshop 3.0의 AccountController 클래스의 CreateAccount 메쏘드의 시퀀스를 자동 생성한 것이다.
[2] 여러 디자인 패턴에 기반한 설계를 지원한다(로즈 역시 이 기능을 지원한다). GOF 디자인 패턴에 기반하여 설계를 하고자 하면 투게더는 디자인 패턴에서 각 객체들의 역할을 보여주며 각 역할을 하는 객체를 추가하고 삭제하는 Node by Pattern 도구를 지원한다. 투게더는 디자인패턴에 기반한 설계를 쉽고 오류 없이 할 수 있도록 도와주며 특히 디자인 패턴을 공부하는 사람에게 아주 유용한 도구가 될 수 있다.
단점이라면 생성된 코드가 그다지 깔끔하지 않아 재 정렬을 해줘야 한다는 점 등이다. 앞에서 설명한 두 가지 도구의 치명적인 단점이 하나 있다. 닷넷 환경에서는 실행할 때 참조되는 라이브러리를 복사하고 실행시 참조하므로 개발 중 라이브러리를 수정하고 다시 컴파일하여도 누군가 파일을 사용 중이기 때문에 덮어쓸 수 없다는 메시지를 절대로 보여주지 않는다. 하지만 앞의 두 도구는 모델링에 사용하고 있는 참조되는 라이브러리를 ‘물고’있기 때문에 참조하는 프로젝트를 종료하고 컴파일한 후 다시 비주얼 스튜디오 닷넷을 실행하여 계속 진행해야 한다.
그리고 전통적으로 닷넷 개발에서는 RUP 같은 개발 방법론이 사용되지 않아, 만약 UML을 그렇게 많이 사용하지 않는 개발자라거나 다른 개발 방법론을 준수하는(MSF 등의) 프로젝트라면 사용할 수 있는 다이어그램은 클래스 다이어그램뿐이고, 너무 많은 도구를 제공함으로서 개발에 혼란이 오며, 비주얼 스튜디오 닷넷 자체가 너무 느려져서 개발자의 '성질'에 나쁜 영향을 끼칠 수 있다는 것이다.
비주얼 스튜디오 닷넷 2005에 포함된 모델링 도구
MS도 닷넷 환경이 객체지향 환경이고, 객체를 모델링 할 수 있는 통합된 개발 도구가 필요하다는 것을 모를 리가 없다. 그래서 MS는 비주얼 스튜디오 닷넷의 차기 버전인 비주얼 스튜디오 닷넷 2005에 그런 모델링 도구를 추가했다(전체적으로는 투게더와 비슷한 모습이고, 필자가 현재 기사를 작성하고 있는 시점에서는 클래스 다이어그램 기능 이외의 기능은 들어있지 않다).
비주얼 스튜디오 닷넷 2005의 클래스 다이어그램 기능을 알아보자. 비주얼 스튜디오 닷넷 2005는 특별히 이전 버전과 비교해서 달라진 기능이 없다. 웹 프로젝트를 다른 프로젝트와 구분해서 생성하는 정도가 외관상으로 볼 때 달라진 기능이라 할 것이다. 비주얼 스튜디오 닷넷에서 클래스 다이어그램을 그리고 실시간으로 변경될 수 있는 기능을 사용하려 한다면 이전 버전에서 새 항목 추가 메뉴를 선택하는 것과 같이 한다. 새 항목 추가 다이얼로그 박스를 유심히 살펴보면 클래스 다이어그램이라는 항목 아이콘이 보이고 그 항목을 사용하여 클래스 다이어그램을 작성할 수 있다.
|
| | <화면 8> 비주얼 스튜디오 닷넷 2005의 새 항목 추가 다이얼로그 박스 |
|
| | <화면 9> 비주얼 스튜디오 닷넷 2005를 사용해서 Iterator 패턴을 디자인 한 모습 |
장점
[1] 아무래도 비주얼 스튜디오 닷넷에 애드인된 것이 아닌 빌트인된 모델링 도구이다 보니 애드인된 도구보다는 강한 결합성을 가진다. 빌트인되었을 때의 가장 큰 기대점은 아무래도 성능적인 측면인데 아직 베타 버전이기에 평가 내리기가 이른 듯 하다. 하지만 꽤 만족할만한 성능을 보여주고 있으며, C# 또는 비주얼 베이직 닷넷에 종속적인 멤버들만을 포함하므로 닷넷 개발에 어울리는 도구가 될 듯 하다.
[2] 비주얼 스튜디오 닷넷에 포함된 도구이다 보니 닷넷 개발에 가장 어울리는 코드를 생성하고 다른 도구들과 통합하여 사용할 수 있다. 닷넷에 추가된 수많은 새로운 개념들과 도구들을 사용할 수 있다.
[3] 비주얼 스튜디오 닷넷에는 지면 관계상 다 소개할 수는 없지만 모델링에 관계된 많은 새로운 도구들이 추가되었다. XML 디자인이나 데이터베이스 디자인, 배포 디자인까지 비주얼 스튜디오 닷넷에서 할 수 있다. 이런 기능들은 평소 비주얼 스튜디오를 사용하던 개발자들에게 아주 친숙한 환경을 제공해 줄 수 있다.
단점이라면, 그 외에 아무것도 없다는 것이다. 또한, 현재 베타 버전에서는 다른 라이브러리에 포함된 개체들을 클래스 다이어그램에 포함하는 인터페이스가 상당히 불편하다. 이는 개선되어야 할 점이다. 사실 투게더나 로즈같은 훌륭한 도구들을 사용하던 입장에서 비주얼 스튜디오 닷넷 2005의 설계 도구를 테스트 하는 입장에서는 전혀 새로울 것도 없고 감동적일 것도 없다.
또한 MS가 자사의 객체지향 개발 방법론을 연구하고 있다는 소문이 풍문에 들려오는 것을 보면, 정식 제품에는 다른 도구가 추가될 지도 모르고, 로즈나 투게더 같은 도구 정도의 많은 기능은 아니더라도 다른 많은 도구들이 추가될 것으로 보인다.
독이 될 수도 갈라드리엘의 별이 될수도
UML은 좋은 도구다. 하지만 대부분의 개발 팀에는 도움이 되기보다는 방해가 되기 일쑤다. UML에는 너무나 많은 것이 있고, 다 활용하기는 벅차고, 그렇다고 사용하지 않기에는 또 뭔가 빠진 듯한 느낌이 드는 것이 그것이다. 늘 절제하는 마음으로 UML을 사용한다면, UML은 아주 좋은 도구가 된다.
필자는 항상 이런 얘기를 한다. "로즈가 설치되어 있는 책상 위에는 항상 연필과 지우개, 그리고 종이가 있어야 한다" 특히 개발자의 입장에서는 UML이라는 도구는 독이 될 때는 한 모금에 사람을 죽일 수도 있는 치명적이 독이 될 수도, 또는 길을 안내해주는 갈라드리엘의 별이 될 수도 있다.@
* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.
김상훈 (동명정보대학 정보기술 연구원) 2005/03/31
원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134587,00.htm
자기경영의 네가지 길, 文, 行, 忠, 信 2005년 4월 11일 월요일
자기경영의 네가지 길, 文, 行, 忠, 信
(예병일의 경제노트, 2005.4.11)子以四敎하시니 文, 行, 忠, 信이니라.
文은 교양으로, 지식을 뜻합니다. 현대를 바쁘게 살아가고 있는 샐러리맨들이 일부러 시간을 내어 책을 읽거나 저명한 분의 강연회를 찾아 다니는 등 자기계발을 한다는 것이 그리 쉽지만은 않다.
行은 행동이란 뜻이다. 행동이 뒤따르지 않는 지식은 아무 쓸모가 없다.
忠은 남을 위한 헌신을 뜻한다. 모임 속에서 자신의 이기적인 욕망만 좇으며 살아간다면 결국은 고립되고 성공도 이루기 어렵다.
信은 신념을 뜻한다. 어떤 일이든 꼭 해내고 말겠다는 강한 의지를 지니라는 것이다.
문행충신(文,行,忠,信). 옛 가르침이지만, 현대를 살아가는 사람에게도 도움이 되는 자기경영의 네가지 길입니다.
문(文). 교양과 지식을 의미합니다. 지난 3월 한 달 동안 책을 몇 권 읽으셨나요? TV, 컴퓨터보다는 책이나 잡지를 가까이 해야합니다. 교육과 세미나, 조찬강연 같은 모임에도 적극적으로 참여해야 합니다.
책을 가까이 하고 배우는데 열심인 사람은 눈빛부터 다르고 풍기는 향기부터 다릅니다.
행(行)은 행동과 실천입니다. 아무리 훌륭한 지식을 쌓았다 해도, 행동하지 않으면 의미가 없습니다. 아무리 멋진 계획안을 만드는데 성공했다 해도, 실행하지 않으면 한낱 종이 조각에 불과합니다.
충(忠)은 헌신입니다. 내가 속한 회사에, 모임에, 가정에 헌신해야 합니다. 실리만 추구하며 항상 계산적으로 행동하는 사람은, 단기적으로는 작은 이익을 취할 수 있을지 모르지만, 장기적으로는 결코 성공할 수 없습니다.
신(信)은 신념입니다. 강한 의지입니다. 어쩌면 '헝그리 정신'이 부족한 이 시대 많은 한국인들에게 가장 필요한 덕목일지 모릅니다.
* * *
저의 자그마한 소망은 경제노트가 가족 여러분들의 성공적인 자기경영에 조금이나마 도움이 되었으면 하는 것입니다.
인터넷이라는 온라인 매체를 통해 가족 여러분들을 만난지 1년 3개월여. 이제 오프라인에서도 경제노트 가족들의 모임을 열려 합니다.
오는 5월쯤부터, 매주 1회, 저자나 CEO 등 훌륭한 분들을 강사로 모시고 가족들이 함께 모여 공부하는, 정보를 나누고, 좋은 사람들을 만나는 그런 오붓한 자리를 준비하고 있습니다. 경제노트 가족의 오프라인 공부모임입니다. 물론 무료입니다.
무료특강 행사 진행을 번갈아서 가끔 도와주실 '자원봉사 가족'이나, 행사를 후원해주실 기업, 100~200석 규모의 강의장을 후원해주실 기업은 경제노트 사이트 하단 '운영자에게'로 메일 주시면 감사하겠습니다. 따뜻한 후원이 있으면 행사가 더욱 빛나겠지만, 후원이 없더라도 모임은 진행됩니다.
그리고 꼭 만나보고 싶은 저자나 유명인사가 있으시면 댓글로 추천해주세요. 가족 여러분들의 생각대로 준비하려 합니다.
또 오프라인 공부모임 외에도 다른 좋은 의견이나 제안이 있으시면 제게 말씀해주시기 바랍니다.
경제노트를 통해 가족 여러분 모두가 성공적으로 자기경영을 해나가고, 소망을 성취하시길 기원합니다.
저도 매일 글을 쓰면서 가족 여러분들께 많은 도움을 받고 있답니다.
예병일 드림.
|
|
리더가 진정 해야할 일 2005년 4월 8일 금요일
리더가 진정 해야할 일
(예병일의 경제노트, 2005.4.8)진정한 리더는 모든 일을 다 할 필요가 없단다.
하지만 리더는 해야할 일이 무엇인지를 분명하고 명확하게 설명하는 방법을 알아야 한다. 그리고 다른 사람들이 목표를 달성하도록 권한을 부여할 줄도 알아야지.
리더가 모든 걸 다 직접할 필요는 없지만, 리더는 부하직원들에게 공동으로 주어진 목표의 진행과정을 단계별로 살펴볼 필요는 있지.
리더와 매니저. 비슷하지만 다른 개념들입니다.
리더는 프로야구로 말하면 구단주쯤에 해당됩니다. 그 야구단의 목표와 비전을 정합니다.
매니저는 그 팀의 감독이나 코치에 해당됩니다. 선수들이 최고의 기량을 발휘하도록 관리하고 지도합니다.
물론 편의상의 구분입니다. 실제로는 리더와 매니저의 요소가 한 사람에게 섞여있지요. 그리고 그 비율은 그의 위치에 따라 적절히 달라져야 합니다.
처음 사회생활을 시작할 때는 부하(팔로워)로서 필요한 덕목을 갖춰야 합니다. 제대로 된 팔로워만이 후에 매니저가 될 수 있고, 제대로 된 매니저만이 궁극적으로 리더가 될 수 있습니다.
리더에게는 조직원이 해야할 일이 무엇인지를 명확하게 설명하는 능력이 중요합니다. 명확하게 임무와 권한을 부여하고 진행상황을 점검해야 합니다. 물론 경우에 따라서는 매니저 역할을 일부 해야할 때도 있지만, 리더가 조직의 모든 일을 직접 다 할 필요는 없습니다.
리더에게는 팀을 위해 더 중요한 일이 있습니다. 목표를 정하고 그 목표 명확히 설명하고 그 목표로 이끄는 것, 이것이 리더가 해야할 일입니다.
|
|
|
