CodeName : Passion

객체설계[4] - 객체지향 설계 원칙(기본)

스쿨쥐 — Sun, 13 Nov 2011 20:50:50 +0900

우리는 나이가 들면서 중요한 것을 가끔 잊고 삽니다. 하지만 가끔씩 이런 것을 어린 아이들로부터 다시 배우기도 합니다. 그 중 하나가 '왜?'라는 질문입니다. '왜?'라는 질문에 화를 내는 이유는 내가 모르는 것을 인정하기 싫거나, 특별한 이유없이 나의 생각을 상대방에게 강요하고 있다는 불편한 진실을 드러내고 싶지 않기 때문이라고 생각합니다.

하지만 개발자라면 이 '왜?'라는 질문을 적극적으로 하고, 스스로 답을 찾는 노력이 반드시 필요합니다. 마찬가지로 우리가 객체지향 설계 원칙을 따르는 이유에 대한 질문도 필요하고, 그에 대해 이미 지난 글을 통해서 알아본 바 있습니다. ([패턴/객체지향] - 객체설계[3] - 객체지향 설계 원칙을 따르는 이유)

보통 '왜?'라는 질문에 대해서 이해가 되기 시작하면 그 다음 단계는 '어떻게?'라는 질문을 하게 됩니다. 오늘 배우실 객체지향 설계 원칙이 바로 이 '어떻게?'라는 질문에 대한 답이 되겠네요. 오늘은 그 원칙의 핵심을 먼저 알려드리겠습니다.

1. 설계의 목표를 파악한다. (재설계의 경우 재설계의 원인을 파악한다.)
2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.
3. 바뀌는 부분을 캡슐화한다.

끝입니다. 너무 간단한가요? 아니면 너무 추상적이라서 여전히 어떻게 해야할 지 감이 안잡히시나요? 원래 기본이라는 것은 쉬워보이지만 그 의미를 깨닫기까지 아주 많은 노력과 시간이 필요합니다. 앞으로 상세하게 알아볼 모든 내용이 이 3가지 원칙에서 거의 벗어나지 않습니다.

소개팅을 한번 예로 들어볼까요? 우리의 목표는 소개팅하는 과정을 표현하고, 그 결과를 boolean 값으로 나타낸다고 가정해보겠습니다.

1. 설계의 목표를 파악한다.

public boolean 소개팅() {
...
}

2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.

바뀌지 않는 부분 : [1. 소개받는다. 2. 만난다. 3. 헤어진다.]로 이어지는 절차
바뀌는 부분 : 소개받는 방법, 만나서 데이트 하는 방법, 헤어지는 방법 등

3. 바뀌는 부분을 캡슐화한다.

public boolean 소개팅() {
// 1. 소개받는다.
소개받음();

// 2. 만나서 데이트한다.
만나서 데이트();

// 3. 헤어진다.
헤어짐();
}

private void 소개받음() {
// 소개받는 방법을 구체적으로 기술
...(친구를 괴롭혀서 강제로 소개해달라고 함)
}

private void 만나서 데이트() {
// 만나서 데이트 하는 방법을 구체적으로 기술
...(영화보고, 근사한 곳에서 저녁식사를 함)
}

private void 헤어짐() {
// 헤어짐
...(집까지 바래다주고, 애프터 신청을 정중하게 함)
}

자, 어떠신가요? 조금은 이해가 되시는가요? 바뀌지 않는 부분인 절차적인 부분은 소개팅()에 구현이 되었고, 바뀌는 부분은 private 메서드로 빼서 상세한 내용을 기술하면서 소개팅()에서는 그 내용을 알 수 없도록 캡슐화한 것입니다.

캡슐화를 하는 방법은 다양합니다. private 메서드로 만들거나, 클래스로 만들거나, 인터페이스로 만듭니다. 아주 쉽게 말하면 블락( { ... } )안으로 감싸는 것입니다.

만약 캡슐화를 하지 않으면 다음과 같은 모양이 나옵니다.

public boolean 소개팅() {
// 소개받는 방법을 구체적으로 기술
...(친구를 괴롭혀서 강제로 소개해달라고 함)

// 만나서 데이트 하는 방법을 구체적으로 기술
...(영화보고, 근사한 곳에서 저녁식사를 함)

// 헤어짐
...(집까지 바래다주고, 애프터 신청을 정중히 함)
}

두번째 예제가 더 좋아보일지도 모릅니다. 일련의 흐름이 하나의 메소드 안에 다 적혀있어서 그렇겠죠? 하지만 두번째 예제는 변경에 굉장히 취약한 구조를 가지고 있습니다. 소개받는 방법이 변경되어도, 또는 만나서 데이트하는 방법이 바뀌던지, 헤어지는 방법이 바뀌어도 소개팅()를 수정해야합니다. 그리고 수정해야 할 내용이 2개 이상만 되어도 소개받는 방법 때문에 소개팅()이 실패(false)하는지, 헤어지는 방법때문에 소개팅()이 실패하는지 알기 힘듭니다.

또한 소개팅()를 보는 사람은 [소개받음 -> 만나서 데이트 -> 헤어짐]으로 이어지는 큰 흐름을 파악하지 못할 가능성이 높아집니다. 이렇게 코드에 대한 가독성이 떨어지면 당연히 수정에 오래 걸리게 됩니다. 이해하는 시간이 그만큼 더 많이 필요하기 때문이죠.

단적인 예로 소개받음 부분이 50라인, 만나서 데이트하는 부분이 100라인, 헤어짐 부분이 50라인이라고 한다면 200라인을 한꺼번에 보시는 것이 이해하기 쉬우신가요? 아니면 3라인으로 흐름을 파악한 후 구체적인 각 절차를 따로 이해하시는 것이 이해하기 쉬우신가요?

선택은 여러분들의 몫입니다. ^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'패턴 > 객체지향' 카테고리의 다른 글

객체설계[4] - 객체지향 설계 원칙(기본) (0)	2011/11/13
객체설계[3] - 객체지향 설계 원칙을 따르는 이유 (0)	2011/11/06
객체설계[2] - 소프트웨어 프로젝트 (0)	2011/10/30
객체설계[1] - 소프트웨어의 목표 (4)	2011/10/24
속성 값의 종류가 정해지지 않았을 때 (0)	2009/03/09
집합 vs 구성 (0)	2009/03/09

객체설계[3] - 객체지향 설계 원칙을 따르는 이유

스쿨쥐 — Sun, 06 Nov 2011 17:40:45 +0900

"세상에서 변하지 않는 것은 변화 그 자체이다."라는 말이 있습니다. 마찬가지로 우리가 만드는 소프트웨어도 만드는 과정에서 변화의 과정을 거치게 됩니다. 프로젝트를 진행하면서 프로젝트를 구성하는 요소들, 즉, 범위, 비용, 시간, 품질 등은 항상 변화합니다. 그 중 가장 빈번하게 변화하는 것을 꼽으라면 범위(요구사항)가 아닐까 합니다.

범위가 변하는 이유는 여러가지가 있습니다.

1. 비즈니스 상황이 변하여 능동적으로 대처할 수 밖에 없는 경우.
- ex) 개인정보보호법처럼 법이 개정되어 소프트웨어에 영향을 주는 경우, 아이폰과 같은 스마트폰 도입으로 인한 새로운 요금제 도입 등
2. 고객이 비즈니스를 잘못 이해한 경우
3. 고객이 설명해준 비즈니스를 개발하는 입장에서 잘못 이해한 경우

이 외에도 많은 이유들이 존재할 수도 있습니다. 하지만 이럴 경우 소프트웨어를 만드는 입장에서 어떻게 대처를 해야할까요? 1번 또는 2번의 경우 고객이 제대로 하지 못했으니 불가능합니다라고 대답하면 될까요?

다시 한번 이번 연재의 처음글을 잠시 살펴보고 다음 질문에 대한 답을 생각해봅시다.
([패턴/객체지향] - 객체설계[1] - 소프트웨어의 목표)

우리가 만드는 소프트웨어의 목표가 무엇인가요?

네. 맞습니다. 고객이 원하는 가치를 만족시켜주는 것입니다. 범위에 대한 변화를 줘서 고객 가치가 증대된다면 그렇게 해야합니다. 그렇다면 무조건 고객이 원하는 대로 만드는가? 그것도 아닙니다. 다음과 같은 것을 해야합니다.

1. 목적의 이해
- 고객이 범위를 변경해서 얻는 가치가 무엇인가? 정말 필요한 것인가?
2. 방법의 타당성 검증
- 고객이 원하는 방법이 정말 고객이 원하는 가치를 만족시켜줄 수 있는 방법인가? 다른 방법은 없는가?
3. 영향도 및 비용 분석
- 고객이 원하는 방법으로 바꾸었을 경우 고객이 얻는 가치와 프로젝트 자원의 소모(비용, 시간 등)를 계산했을 때 범위를 수정하는 것이 이익인가? 손해인가?

앗! 이것을 개발자가 해야한다구요? 네. 맞습니다. 개발자가 해야합니다. 물론 고객이나 프로젝트 관리자, 분석가, 설계자 등 다른 프로젝트 구성원과 함께 해야 합니다. 다만, 개발자는 고객이나 관리자가 결정을 내릴 수 있도록 '참고자' 역할까지만 해주면 됩니다. 그렇게 하면 개발자가 정리한 내용으로 고객이 관리자와 함께 협의하여 결정을 내릴 것입니다. 최소한 이정도는 해주셔야 합니다.

그런데 아이러니하게도 과거의 비즈니스 결정사항이나 개발자의 코드 구현의 품질에 따라서 영향도나 수정 비용이 다르게 계산됩니다. 즉, 우리가 과거에 만들었던 코드의 설계구조가 소프트웨어를 통해 만족시킬 고객 가치에 대해서 영향을 줄 수 있다는 것입니다. 그렇기 때문에 우리가 만드는 소프트웨어의 설계가 어떻게 구성되어있는지가 중요하며, 객체지향 설계원칙을 따르면 이런 변화에 대해서 조금은 대처를 잘 할수 있는 구조를 가져갈 수 있기 때문입니다.

또한 개발자 입장에서 객체지향 설계원칙을 따르는 이유를 정리하면 다음과 같습니다.

1. 코드를 변경하기 쉬워집니다.
2. 코드를 이해하기 쉬워집니다.
3. 코드를 재사용하기 쉬워집니다.

앞에서 장황하게 설명한 이유는 제가 생각하기에도 다소 무리가 있을 수 있다고 생각합니다. 하지만 개발자 입장에서 객체지향 설계원칙을 따르는 이유에 대해서는 많은 분들이 공감을 하시리라 생각합니다. 그럼 다음 시간부터는 객체지향 설계의 원칙들이 어떤 것들이 있는지 하나하나 알아가보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'패턴 > 객체지향' 카테고리의 다른 글

객체설계[4] - 객체지향 설계 원칙(기본) (0)	2011/11/13
객체설계[3] - 객체지향 설계 원칙을 따르는 이유 (0)	2011/11/06
객체설계[2] - 소프트웨어 프로젝트 (0)	2011/10/30
객체설계[1] - 소프트웨어의 목표 (4)	2011/10/24
속성 값의 종류가 정해지지 않았을 때 (0)	2009/03/09
집합 vs 구성 (0)	2009/03/09

객체설계[2] - 소프트웨어 프로젝트

스쿨쥐 — Sun, 30 Oct 2011 23:38:08 +0900

우리는 지난글([패턴/객체지향] - 객체설계[1] - 소프트웨어의 목표)을 통해서 소프트웨어의 목표와 원칙에 대해서 알아보았습니다. 그렇다면 이러한 소프트웨어는 어떻게 만들어지는 것일까요? 바로 '프로젝트'라는 것을 통해서 만들게 됩니다.

프로젝트의 정의는 다음과 같습니다.

명사
1. 연구나 사업. 또는 그 계획. '연구과제', '일감'으로 순화.
2. <교육> [같은말] 프로젝트법(실제에 있어서 일의 계획과 수행 능력을 기르는 교육방법).
- 출처 : 네이버 국어사전(http://krdic.naver.com/detail.nhn?docid=41015800)

프로젝트라는 말은 비단 IT에서만 쓰이는 말이 아닙니다. 아폴로 계획(Project Apollo), 맨해튼 계획(Manhattan Project) 등 여러 분야에서 사용되고 있습니다. 즉, 프로젝트란 어떤 목표를 달성하기 위한 계획 또는 그 계획을 실현하기 위한 일련의 일의 진행과정을 모두 포함하는 의미입니다.

이런 의미를 확장한다면 소프트웨어 프로젝트란 소프트웨어가 가지는 목표를 달성하기 위해서 소프트웨어를 만들어가는 계획 및 일의 진행과정을 의미한다고 할 수 있습니다. (앞으로 나오는 프로젝트란 소프트웨어 프로젝트를 의미합니다.) 이런 프로젝트를 관리를 잘 해서 고객이 원하는 가치를 만족시켜주는 소프트웨어를 만들어내야 하는데 관리해야할 것들이 굉장히 많습니다. 그 중 중요한 것을 추려내면 다음과 같습니다.

이미지출처(http://en.wikipedia.org/wiki/File:The_triad_constraints.jpg)

1. scope(범위) : 기능을 얼마나 만들어 낼 것인가?
2. cost(비용) : 비용은 얼마나 들것인가?
3. schedule(시간) : 시간은 얼마나 들것인가?
4. quality(품질) : 얼마나 좋게 만들것인가?

이 네개의 요소를 어떻게 결정할 것인가가 바로 프로젝트 관리의 핵심입니다. 어라? 위에 나와있는 그림은 지난번 글에서 보던 소프트웨어의 목표를 달성하기 위한 원칙을 나타내는 그림과 비슷합니다. 비교해볼까요?

앗! 거의 똑같네요. 여기서 어떤 생각이 드시나요? 잠깐 생각해보고 글을 계속 읽어주세요.

제가 생각하는 프로젝트 관리란 소프트웨어를 통해서 얻을 수 있는 고객 가치를 최대화하기 위해서 고객 가치를 조절해나가는 계획과 그 계획을 실행해가는 과정을 의미합니다. 우리가 가지고 있는 자원(시간, 비용 등)은 제한되어 있고, 그 제한된 자원 속에서 최대치의 고객 가치를 만들어 내는 것이지요.

말은 쉽지만 실제로는 굉장히 어렵습니다. 그 이유는 자원(시간, 비용 등)이 제한되어 있고, 고객이 원하는 기능(범위, 요구사항 등)이 수시로 변하는 것입니다. 특히 개발하는 입장에서는 고객의 요구사항이 변경되는 것이 굉장히 부담스럽습니다. 그렇다고 변하는 요구사항을 마냥 무시할 수 없는 일입니다.

그럼 어떻게 해야할까요?

바로 다음 글에서 이어집니다.

참조 :
http://en.wikipedia.org/wiki/Project
http://en.wikipedia.org/wiki/Project_triangle
http://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'패턴 > 객체지향' 카테고리의 다른 글

객체설계[4] - 객체지향 설계 원칙(기본) (0)	2011/11/13
객체설계[3] - 객체지향 설계 원칙을 따르는 이유 (0)	2011/11/06
객체설계[2] - 소프트웨어 프로젝트 (0)	2011/10/30
객체설계[1] - 소프트웨어의 목표 (4)	2011/10/24
속성 값의 종류가 정해지지 않았을 때 (0)	2009/03/09
집합 vs 구성 (0)	2009/03/09

객체설계[1] - 소프트웨어의 목표

스쿨쥐 — Mon, 24 Oct 2011 23:16:04 +0900

우리가 만들고 있는 소프트웨어는 고객이 원하는 가치를 만들어내기 위한 것입니다.

고객이 원하는 가치는 다양합니다. 고객이 하고 싶은 일을 하기 위해서 소프트웨어를 사용할 수 있습니다. 또는 고객이 시간이 필요해서 다른 수단을 통해서 할 수 있지만 소프트웨어를 통해서 시간을 아끼고 싶을 수 있습니다. 아니면 소프트웨어를 이용하여 기존에 들었던 비용을 줄이는 것이 목적일 수도 있습니다.

예를 한번 들어보죠.

1. 지하철 앱 : 항상 지하철 노선도(종이)를 들고 다니기 힘들기 때문에 스마트폰에 있어서 항상 확인할 수 있었으면 한다. 지하철 환승의 경우 어느 칸에 가면 빠르게 환승할 수 있는지 궁금하다.
(하고 싶은 일을 하기 위한 경우)

2. 코레일 앱 : 기차를 자주 이용하는데, 역에서 줄을 서서 예매를 하거나, 자동발매기를 이용하려면 시간이 오래 걸린다. 인터넷으로도 가능하지만 컴퓨터를 접하지 않는 직업의 경우 컴퓨터를 사용하려면 시간을 따로 내야한다. 그냥 평소에 들고다니는 스마트폰에서 가능하다면 시간을 절약할 수 있을 것 같다.
(시간을 아낀 경우)

3. 인터넷뱅킹 : 기존 은행 창구에서 입출금에 대한 업무를 처리하는 것은 많은 비용(공간비용, 인건비 등)이 들었다. 인터넷뱅킹을 통하여, 은행고객에게 편의성을 제공하면서, 은행 창구에서의 입출금 업무가 줄어들어 비용(공간비용, 인건비 등)을 줄일 수 있었다.
(비용을 줄인 경우)

이처럼 우리가 만든 소프트웨어는 여러가지 형태로 고객이 원하는 가치를 만들어내고 있습니다. 이 때문에 고객은 소프트웨어를 필요로 하는 것입니다.

소프트웨어의 목표는 다음과 같은 원칙을 통해 고객이 원하는 가치를 만족시키는 것입니다.
1. 고객이 원하는 일을 할 수 있도록 기능을 제공한다.
2. 고객이 원하는 일을 하는데 드는 시간을 줄인다.
3. 고객이 원하는 일을 하는데 드는 비용을 줄인다.

이것 외에도 고객이 원하는 가치는 많습니다. 게임의 경우 즐거움이라는 가치를 주는 것이고, 어떤 경우에는 타임킬링(시간 때우기)을 위해서 하기도 합니다. 하지만 이런 것들도 큰 범주 내에서 본다면 위에서 언급한 3가지 원칙안에 포함된다고 할 수 있을 것입니다.

객체설계를 하는데 왜 갑자기 소프트웨어의 목표를 언급을 하느냐라고 궁금하실 수 있습니다. 이에 대해서는 차차 언급할 생각입니다. 글이 길면 읽기도 힘들고, 핵심을 놓치는 경우가 많습니다. 이번 글은 여기까지이며, 다음 글에서 계속 이어나가겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'패턴 > 객체지향' 카테고리의 다른 글

객체설계[3] - 객체지향 설계 원칙을 따르는 이유 (0)	2011/11/06
객체설계[2] - 소프트웨어 프로젝트 (0)	2011/10/30
객체설계[1] - 소프트웨어의 목표 (4)	2011/10/24
속성 값의 종류가 정해지지 않았을 때 (0)	2009/03/09
집합 vs 구성 (0)	2009/03/09
좋은 프로그램 만드는 원칙 (0)	2009/03/06

네비게이션과 운전자 그리고 아키텍트와 PM

스쿨쥐 — Thu, 11 Aug 2011 23:12:59 +0900

요즘 차량을 소유하신 분들은 대부분 차량용 네비게이션을 가지고 계십니다. 길을 잘 모르는 곳을 가거나 아는 길이라 하더라도 교통량 등을 분석해서 가까운 길 또는 요금이 적게 나오는 길을 안내해주기 때문에 자주 사용합니다.

많은 운전자분들이 네비게이션에 의지해 운전을 많이 하고 계시지만 갑자기 공사를 하거나 자연재해로 길이 막혔을 때와 같은 경우에 네비게이션의 말을 들으면 오히려 목적지에 더 늦게 도착하는 경우도 발생합니다. 이러한 이유로 운전자는 경험에 의거해서 네비게이션이 알려주지 않는 다른 길로 돌아서 목적지로 가기도 합니다.

이럴때 우리가 원하는 네비게이션의 동작은 어떤 것일까요? 아마도 내가 실수든 아니면 의도된 행위이든 관계없이 현재 위치로부터 목적지까지의 새로운 경로를 탐색해주길 바랄 것입니다. 만약 더이상 길이 없는 막다른 길로 들어섰을 경우에는 다시 돌아가는 경로를 탐색해주어야 할 것입니다.

운전자의 경우를 살펴봅시다. 정해진 시간에 목적지까지 물건을 배달해야 한다고 가정해보겠습니다. 이때 운전자가 선택할 수 있는 경우는 다양합니다.

1. 네비게이션의 도움없이 목적지까지 운전한다.
2. 네비게이션의 안내대로 목적지까지 운전한다.
3. 네비게이션의 도움을 받되 상황에 따라 경험에 의거해 운전한다.

이 외에도 여러가지 방식이 있을 것입니다. 하지만 어떠한 경우이든 중요한 것은 정해진 시간안으로 목적지에 물건을 배달해야 한다는 것입니다. 이를 지키지 못하면 책임이 발생하게 됩니다.

아키텍트의 역할

IEEE 1471에 따르면 미션을 목표로 하는 시스템이 존재하고, 이 시스템이 미션을 만족시킬 수 있는 하나의 아키텍처가 필요합니다. 이러한 아키텍처를 수립하는 것이 아키텍트의 가장 중요한 역할입니다.

즉, 목적지까지 최적의 경로를 찾아주는 네비게이션과 같습니다. 프로젝트 조직이 비록 잘못된 길에 들어서서 헤매고 있더라도 전부 갈아엎고, 다시 만들라고 하는 것이 아니라 현재 상태에서 요구사항을 만족시킬 가장 적합한 아키텍처를 수립을 해야합니다. 현재의 아키텍처 구조가 요구사항을 도저히 만족시킬 수 없는 경우 막다른 길에서 U턴을 지시하는 네비게이션처럼 새로운 아키텍처 구조를 도입을 해야합니다.

(이미지출처)

물론 성능이 나쁜 네비게이션을 운전자를 더 힘들게 하듯, 잘못된 방향을 제시하는 아키텍트는 프로젝트 조직을 힘들게 할 수도 있습니다. 그래서 아키텍트는 문제의 의도와 본질을 꽤뚫어볼 수 있는 통찰력과 뛰어난 기술력 등이 요구됩니다.

PM의 역할

PM의 가장 큰 역할은 프로젝트를 관리하는 것입니다. 프로젝트의 구성요소는 크게 범위(scope), 비용(cost), 일정(Time)입니다. (하나 더 하자면 품질요소도 있습니다.) 즉, 이러한 프로젝트 구성요소를 잘 관리하여 정해진 비용에 정해진 일정에 원하는 기능을 가진 (고객이 수용하는)적당한 품질의 시스템을 만들어낼 수 있도록 관리를 하는 것이죠.

PMBOK에 따르면 할 일이 참 많습니다.

1. 통합관리
2. 범위관리
3. 일정관리
4. 원가관리
5. 품질관리
6. 인적자원관리
7. 의사소통관리
8. 위험관리
9. 조달관리

헉헉... 나열하는 것만으로도 숨이 차네요. 이것만 하느냐? 아닙니다. 이것들을 전체적인 프로젝트 흐름에 따라 관리해야 합니다.

시작 -> 계획 -> 실행 -> 모니터링 및 컨트롤 -> 완료

(이미지출처)

비유하자면 위에서 말한 운전자와 같은 역할을 합니다. 정해진 시간(일정)안에 정해진 목적지까지 물건을 배달(범위)해야 합니다. 그렇게 하기 위해서는 목적지도 확인하고, 차량이 고장나지 않도록 점검도 하고, 기름도 충분히 있는지 확인하고, 물건도 잘 실었는지 확인해야 합니다.

만약 배달하지 하지 못하면 운전자는 '책임'을 져야합니다. 물론 운전자는 길이 막혀서 또는 네비게이션이 잘못된 경로를 알려줘서 배달하지 못했다고 말할 수 있습니다. 그렇다고 해서 네비게이션에게 책임이 돌아가는 것이 아니라 가장 큰 책임은 운전자에게 돌아갑니다.

책임 영역의 분리

관심사의 분리(Separation of Concerns)라는 것이 있습니다. 프로그래밍 설계나 아키텍처 설계를 할 때 지켜야할 원칙입니다. 이 원칙을 지키지 않으면 변경에 대처하기도 힘들고, 영향을 받는 부분도 많아집니다. 아주 작은 프로그램을 만든다면 이러한 원칙을 지키지 않는다 하더라도 어느정도 대처를 할 수 있을 것입니다. 하지만 현재의 프로젝트는 작다고 하더라도 과거의 그것과는 비교할 수 없을 정도로 커졌습니다.

지금 세상은 어떻습니까? 이제 세상은 넓어졌고, 운전자가 잘 알고 있는 길이라 하더라도 네비게이션의 도움을 받는 시대에 우리는 살고 있습니다. 이제 더이상 운전자가 모든 것을 다 알아서 하는 세상은 과거의 추억으로 남겨진 것이죠.

세상이 복잡해지고 커진만큼 고객이 요구하는 비즈니스 요구사항 또한 복잡해지고 커졌으며, 이제는 혼자서 모든 일을 처리할 수 없는 소프트웨어 프로젝트들이 우리 앞에 존재하고 있습니다. 프로젝트 안에서의 책임 영역을 명확하게 구분해야 프로젝트의 성공 확률을 높힐 수 있는 것이지요.

아키텍트와 PM... 그리고 팀

아키텍트와 PM은 분명히 다릅니다.(기사참조) 이를 인지하여 기술책임과 관리책임을 분리하고, 서로의 역할에 충실하며 힘을 합칠 때 소프트웨어 프로젝트는 지금보다도 좀 더 성공할 확률이 올라가지 않을까 생각합니다.

네비게이션이 현재 상태에서 최적의 경로를 잘 알려주고, 운전자는 이를 참고로 길을 결정합니다. 그리고 네비게이션이 알려주는 대로 무사히 길을 가기 위해서 차량정비, 기름, 물건 등을 신경써야 합니다. 유사시 네비게이션이 알려주는 길이 비록 틀린다 하더라도 경험에 의거해 다른 길을 찾거나 다른 사람에게 길을 물어보기도 해야합니다. 네비게이션의 입장에서는 최대한 운전자의 요구에 맞는 경로를 끊임없이 알려주고, 그 방향대로 가도록 안내방송으로 인도해야 합니다.

혼자가 아닌 아키텍트와 PM이 팀을 이루어 팀웍을 발휘할 때 우리의 프로젝트는 올바른 길로 갈 것입니다.

(이미지출처)

참고 URL :
1. IEEE1471 : http://en.wikipedia.org/wiki/IEEE_1471
2. 프로젝트관리 : http://en.wikipedia.org/wiki/Project_management
3. 프로젝트구성요소 : http://en.wikipedia.org/wiki/Project_management_triangle
4. PMBOK : http://en.wikipedia.org/wiki/A_Guide_to_the_Project_Management_Body_of_Knowledge

ps. 바쁜 와중에도 오늘 시간을 내주신 '신승환'님께 감사드립니다. ^^
(블로그주소 : http://www.talk-with-hani.com/)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'기타' 카테고리의 다른 글

네비게이션과 운전자 그리고 아키텍트와 PM (2)	2011/08/11
포지셔닝 (2)	2011/06/27
IT업계에서의 학습 튜토리얼 아이디어(1) (2)	2010/08/13
웹개발환경 (0)	2010/06/28
직장 예절, 잊지 말자! (0)	2010/04/11
프로젝트 진행하기 (2)	2009/12/22

테스트 시작하기

스쿨쥐 — Tue, 09 Aug 2011 00:11:03 +0900

[Test Start]

테스트의 세계로 오신 여러분을 환영합니다. ^^ 가벼운 마음으로 테스트에 대해서 알아볼 수 있도록 몇 개의 포스팅을 순서대로 추천해드립니다. 여기에 있는 포스팅을 모두 읽었을 때 제 블로그의 모든 글들을 쉽게 탐험하실 수 있을 것입니다.

이제 출발하시죠 ^^

Step1. [테스트기법/단위테스트] - 테스트, 정말 필요한가요?
Step2.
Step3.
Step4.

이미지 출처 : http://www.flickr.com/photos/twid/410697715/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'테스트시작하기' 카테고리의 다른 글

테스트 시작하기 (0)	2011/08/09

포지셔닝

스쿨쥐 — Mon, 27 Jun 2011 17:29:48 +0900

사회에서 나를 특별한 존재로 인식시키기란 쉬운 일이 아닙니다. 그렇기 때문에 남과 차별화된 무엇인가를 찾게되고, 그것을 통해 나를 드러내게 됩니다. 그렇다면 어떻게 나를 차별화할 수 있을까요? 아마도 다음과 같은 방법으로 가능하게 할 수 있을 것입니다.

1. 내가 좋아하는 것이 무엇인지 찾습니다.
2. 내가 최초인 것이 무엇인지 찾습니다.
3. 내가 최고인 것이 무엇인지 찾습니다.

사실 이러한 내용은 마케팅 분야의 고전 '포지셔닝'이라는 책을 읽고, 생각해본 것입니다. 기업의 포지셔닝처럼 개인의 경쟁력에 있어서도 이러한 원칙은 동일하게 적용되기 때문입니다.
(참조 : http://www.yes24.com/24/goods/2302353?scode=032&OzSrank=1)

현재 제가 포지셔닝을 하고 있는 기술 분야는 '소프트웨어 테스팅' 입니다. 부가적으로 '아키텍처'와 '클라우드'에 관심을 많이 두고 있기도 하죠.

업무 분야에 대한 포지셔닝은 '금융(은행, 증권, 보험)' 쪽을 생각하고 있습니다. 물론 '조선/해운'분야도 매력적인 분야임이 틀림없구요.

앞으로 10년... 위에 언급한 포지셔닝을 잘 해내서 나의 포지셔닝을 확고히 하고자 합니다. 포지셔닝 자체가 목표가 아니죠. 제 꿈을 이루기 위한 수단이 포지셔닝일 뿐입니다.

제가 우주를 정복하고자 하는 이유는 우주를 정복하면 세상을 바꿀 수 있기 때문입니다. 지금보다도 더 나은 세상을 위해서...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'기타' 카테고리의 다른 글

네비게이션과 운전자 그리고 아키텍트와 PM (2)	2011/08/11
포지셔닝 (2)	2011/06/27
IT업계에서의 학습 튜토리얼 아이디어(1) (2)	2010/08/13
웹개발환경 (0)	2010/06/28
직장 예절, 잊지 말자! (0)	2010/04/11
프로젝트 진행하기 (2)	2009/12/22

2011년 제 11회 JCO 자바 컨퍼런스 발표 제안을 위한 게시글

스쿨쥐 — Mon, 11 Apr 2011 13:22:20 +0900

레거시 시스템을 위한 테스트 자동화 환경구.pdf

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'JCO > 2011' 카테고리의 다른 글

2011년 제 11회 JCO 자바 컨퍼런스 발표 제안을 위한 게시글 (3)	2011/04/11

Hudson User 만들기

스쿨쥐 — Fri, 19 Nov 2010 20:07:41 +0900

Nexus를 설치할 때([Test/Test Bed] - Nexus 깔끔하게 운영하기(2) - 익명연결 제한)와 마찬가지로 Hudson을 설치한 직후에는 익명접근을 할 경우 모든 권한을 사용할 수 있습니다. 아에 Admin 권한을 사용하고 있는 것이죠. 그래서 관리자 계정을 만들어서 접근제한을 할 생각입니다.

여기서 잠시 살펴볼 문제가 있습니다. Nexus를 통한 Remote Repository의 경우 전사 차원에서 운영할 수 있습니다. 이유는 돌아가는 제품이야말로 회사의 자산이고, 이는 프로젝트별 관리가 아닌 통합 관리가 필요합니다. 또한 이미 빌드된 제품의 바이너리 소스가 올라오기 때문에 java의 특성상 개발환경의 영향도가 적습니다.

하지만 Hudson과 같은 CI의 경우는 빌드를 수행하기 때문에 개발환경의 영향을 많이 받으며, 이는 곧 프로젝트별로 따로 관리할 필요성이 있다는 것입니다.

따라서 여기서는 프로젝트별로 Hudson을 따로 설치한다는 가정하에 관리자는 모든 권한을 가지고, 익명 접근에서는 빌드상태를 볼 수만 있는 설정을 하도록 하겠습니다.

1. 설치 후 hudson을 web으로 접속하면(http://localhost:8080/) 다음과 같이 모든 기능을 사용할 수 있습니다.

2. 관리자를 만들기 위해서 왼쪽 "Hudson 관리" 메뉴를 클릭하고, 메인화면 가장 위쪽에 있는 "Configure System" 메뉴를 클릭합니다.

3. 위쪽에 있는 "Enable security" 항목을 체크하면 하단 설정이 나오게 되는데 화면과 같이 선택합니다.

4. save를 클릭하면 첫화면으로 이동하게 되고 처음과는 다르게 왼쪽 메뉴가 일부만 보입니다.

5. "가입" 링크를 클릭하면 새로운 계정을 하나 추가할 수 있습니다. 관리자로 사용할 계정을 등록합니다.

6. 등록하면 자동으로 로그인이 되며, 모든 권한을 사용할 수 있는 상태가 되었습니다.

7. "Hudson 관리 > Configure System > Enable security" 항목에서 다음과 같이 설정을 수정합니다.

- Authorization을 "Matrix-based security"로 선택합니다.

- User/group to add: 항목에서 현재 로그인한 계정을 입력하고 Add를 클릭합니다. (주의 : 이 때 엔터로 입력하지 마세요. 바로 저장되어서 관리자 권한이 사라져 다시 설치해야하는 경우가 발생할 수 있습니다.)

- 현재 로그인한 계정에 모든 권한을 부여하고(관리자 권한), Anonymous에는 read 권한만 부여합니다.

- save를 클릭하여 저장합니다.

8. 이제 관리자는 모든 권한을 가지고 있으며, 익명 권한에 대해서는 현재 상태를 볼 수만 있는 상태가 되었습니다.

참조 :
http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson
http://nsjokt.springnote.com/pages/5041125
http://ikinox.tistory.com/entry/Hudson%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9E%90%EB%8F%99%EB%B9%8C%EB%93%9C-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%951

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'테스트자동화환경 > Jenkins' 카테고리의 다른 글

Hudson User 만들기 (0)	2010/11/19
Hudson 설치하기 (0)	2010/11/19

Hudson 설치하기

스쿨쥐 — Fri, 19 Nov 2010 15:25:02 +0900

이번 시간에는 테스트 자동화를 해주고, 지속적인 통합을 위한 도구인 CI툴 중 Hudson을 설치해보도록 하겠습니다.

현재 시스템의 환경은 다음과 같습니다.

OS : Windows XP Pro Service Pack 3

Java : JDK 1.6.0_14

Maven : 2.2.1

Remote Repository : Nexus 1.8.0

1. hudson 웹페이지(http://hudson-ci.org/)로 접속하여 최신버전을 다운받습니다.

- ~~2010년 11월 19일 현재 최신버전은 1.385 버전입니다.~~

- 2010년 11월 22일 현재 최신버전은 1.386 버전입니다. (한국이 아닌 현지시간으로 11월 19일에 1.386버전이 release 되었습니다.)

2. 다운받은 hudson.war 파일을 hudson을 위한 디렉토리를 만들고 copy합니다.

3. hudson을 위한 환경변수를 입력합니다. (HUDSON_HOME) 변수값은 2번에서 만든 디렉토리 경로로 하면 됩니다.

- 환경변수를 등록하지 않으면 ~/.hudson 디렉토리에 데이터를 저장한다.

ex) C:\Documents and Settings\Administrator\.hudson

4. hudson을 실행합니다.

java -jar hudson.war

옵션에 대한 자세한 설명은 여기를 참조하세요.

추천하는 명령어는 다음과 같습니다.

windows :

java -jar hudson.war --httpPort=지정할포트(기본8080) > 로그파일명 2>&1

ex) java -jar hudson.war --httpPort=9090 > ./hudson.log 2>&1 unix :

nohup nice java -DHUDSON_HOME=hudson홈디렉토리 -jar hudson.war --httpPort=지정할포트(기본8080) > 로그파일명 2>&1

ex) nohup nice java -DHUDSON_HOME=/home/nextree/app/hudson/data -jar hudson.war --httpPort=9090

> ./hudson.log 2>&1

참조 : --prefix=/hudson 이렇게 옵션을 주시면 http://localhost:8080/hudson 으로 접근이 가능해집니다.

5. http://localhost:8080/ 로 접속해서 hudson이 실행되었는지 확인합니다.

- 종료하는 법은 다음과 같습니다.

공통 :
허드슨주소:포트/exit를 통해서 종료가 가능하고, 허드슨주소:포트/restart를 통해서 재시작이 가능합니다.
ex) http://localhost:8080/exit

windows :
실행시킨 콘솔창에서 Ctrl + C를 누르면 됩니다.

unix :

kill `ps -ef | grep hudson.war | grep -v grep | awk '{ print $2 }'`

이상으로 hudson 설치가 완료되었습니다.

참조 :
http://wiki.hudson-ci.org/display/HUDSON/Starting+and+Accessing+Hudson
http://wiki.hudson-ci.org/display/HUDSON/Administering+Hudson

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'테스트자동화환경 > Jenkins' 카테고리의 다른 글

Hudson User 만들기 (0)	2010/11/19
Hudson 설치하기 (0)	2010/11/19