우스게 소리

실제로 있었던 일은 아니지만 가끔 이런 우스게 스토리가 떠오른다.

[두 친구가 술잔을 기울인다. 한 친구가 절망스런 목소리로 이렇게 말한다.
"흑흑, 사장님이 날더러 '넌 너무 열심히 하지마..' 라고 말했어...흑흑"

다른 한 친구가, 어쩌냐 너 몸상하지 말라고 그러는 거겠지 힘내 힘내~
라고 말하지만 속으로는 웃음을 참지 못한다. ]

비트 컴퓨터라고 있다. 여기 사장이 조현정이라는 분인데 그 분의 인생관(?)
혹은 모토 같은 것이 있는데 바로

"부족한 사람이 너무 열심히 하면 나라를 망친다."
(얼마전 SBS의 시시비비에서 어떤 전 공직의 직원이 "누가 그걸 시켜서 했겠어요?
충정에 받혀서 알아서 오버한거지.." 라고 논쟁 중 던진말이 떠오른다. )

으로, 짧지만 어떤 이에게는 비수를 꽂는 말이다.

최근 기업의 성과 측정과 관련하여, 많은 이들이 좋은 결과를 (수치적으로)얻기 위해서 많은 일을 스스로 알아서 하려고 한다...(나서는 거지) 때론 경쟁적으로 남이 모르게 하기도 하고

문제는 이런 일들이 전략적인 차원에서 그다지 좋지 않다는 것이다. 일을 열심히 하는 것과 그 일의 목적이 기업이 나가고자 하는 방향과 맞냐는 별개의 문제으므로..

당장 XP에서는 이런 일이 존재할 수 없는데 ( 소프트웨어 업계의 전반적인 과로 경향으로 존재하라고 부추겨도 존재하기 힘들 것이다.) 비즈니스 부문으로 약간 범위를 넓히면 일어날 확률이 커진다. 여기서 부터는 BPM의 영역이므로 옆 BPM 링크를 따라가 보자.

XP와 CMMI 그리고 6-sigma와의 관계

# Process engineering with XP

CMMI나 6-sigma가 XP와 함께 사용되면 전자는 프레임워크를 후자는 개발에 대한 가이드를 제공하여 XP와의 시너지를 기대할 수 있다.

XP와 CMMI에 대한 7가지 미신

# Philosophy

• CMMI는 너무나 형식적이라 XP와 어울리지 못한다.

-> CMMI가 적절하게 배치된다면 XP와 매우 조화롭게 사용될 수 있다.

• CMMI는 소프트웨어 개발에 있어서 선형적인 방법을 취한다.

-> CMMI의 사용은 효과적인 주기적인 개발방법을 유도할 수 있다

• CMMI는 큰 기관이나 큰 프로젝트에만 적합하다

-> CMMI는 적절하게 구성이 되면 작은 기관이나 작은 프로젝트에도 효과적으로 적용이 가능하다.

• CMMI는 협업적 개발방식과는 어울리지 않는다.

-> CMMI는 근본적으로 통합된 개발 방식을 지원하므로 협업적 개발 방식을 당연히 지원한다.

• CMMI는 방법론 혹은 표준이다.

-> CMMI는 모델이다. 따라서 프레임워크로써 사용이 되어야 한다.

• XP는 문서가 필요없다.

-> XP는 작지만 정해진 형식의 문서가 존재하고 문서의 양도 조절가능하다.

• Agile 방법론은 창조적이고 효과적인 반면, 구조화 되어 있지 않다.

-> XP는 매우 구조적이고 체계적인 원리를 가지고 있다.

XP와 CMMI 매핑

#Process Engineering with XP



CMMI는 거시적인 관점에서는 개발의 종단간 프레임워크를 제공하고 있고미시적인 관점에서는 개발에 필요한 각종 best practices와 공정을 제어할 수 있는 방법을 가지고 있다.

반면 XP는 빠른 주기의 회전으로 효과적이고 능률적인 개발을 위한 원리를 가가지고 있으며 이 원리들은 개발과 매우 직접적인 관련이 있다.

아래 쓴 글 중에서 XP는 CMMI(SW-CMM)의 프레임워크안에서 적절하게 최적화 되어져서사용될수 있다고 했늗네 과연 XP가 CMMI에 어떻게 매핑이 되는지 한번 그림으로 살펴 보자

붉은색 글씨는 각 영역별 프로세스의 구분이고 아래 회색으로 표시한 박스들이 XP 원리들이다. 지속가능한 페이스와 고객의 상주가 Organization 영역에 포함이 되고 게임계획과 작은 릴리스 그리고 리펙토링이 Project 실제 영역에 그리고 나머지 원리들인 Engineering 영역에 포함이 될수 있다. 그러나 CM등과 흡사한 원리에 대해서는 XP가 정의하고 있지 않으므로(사실 상식에 맡기고 있는데 이를 필자는 매우 당연하다고 생각한다.) 특별이 할당하지 않고 있다.

구체적인 매핑은 다음과 같다. 흐리게 표시된 것은 직접적인 매핑은 힘들고 수정이 필요하다는 것이다.

이런식으로 SEPG같은 곳에서 프로세스를 다시 정의하고 실행하면 XP와 CMMI는 훌륭하게 조화되어그 시너지 효과를 기대할 수 있을 것이다.

6-sigma와 XP

이 시점에서 6-sigma이야기를 하지 않을 수가 없다.JPMorgan, GE, Johnson&Jonson, Motorola, Toshiba, Kodak, AIG, Dupont, Ford, Microsoft, Dell, Sony등 무수히 많은 세계적 기업들이 Six Sigma를 도입하고 있으며이를 통해 성공적인 ROI를 내고 있다는 보고가 있다.

6-sigma는 VOC(Voice of Customer), VOE(Voice of Employee), VOB(Voice of Business)와CTQ(Critical to Quality)들을 바탕으로 현재의 상태를 분석하고 결과를 검증하며
Define-> Assess -> Select-> Design->Implement->Control 순서로 디자인을 하고Define-> Measure-> Improve-> Implement->Control의 형태로 프로세스 개선을 한다.

JPMorgan의 경우 이러한 형식의 6-sigma를 바탕으로 소프트웨어를 개발하는데개발 공정의 Iteration에 XP를 도입하였다.

그 결과 아래와 같은 개선의 효과를 보았다. 이때 사용한 metrics는 6-sigma에서 사용하던defect metrics를 그대로 이용하였다.

프로젝트의 전체적인 골격과 측정 metrics를 6-sigma의 것을 그대로 따라가고 일부 Iteration에 XP를 적용하였다. XP가 적용된 iteration에서는 QA와 협의하여 기본 metrics만을 취하고 문서도 XP에 맞게 처리하였다.

XP를 통하여 전반적으로 개발자들의 work/lifer간의 균형을 맞출 수 있었고, 작업환경의 개선, 그리고 팀웍의 증진, 결과의 완성도 개선의 효과를 보았다고 한다. 덤으로 bus/tech 간의 관계 개선도 있었다고 한다.

그렇다면 Agile의 기본 사상은?

# XP and motto



만약 어떤 기업이 Agile로 가기로 했다면,
효과적인 적용을 위해서 모두가 머리속에 염두해 둬야할
모토 같은 것이 필요할 것이다. 모토로써의 Agile의 사상을 한번 보자

1. 도구나 프로세스 보다는, 개인과 개인과의 상호 협력
2. 문서보다는, 동작하는 프로그램
3. 고객과의 관계는 계약과 협상보다는, 함께 머리를 맞대고 협력
4. 계획을 따르는 것 보다는, 변화에 적극적으로 받아들이는 것

하나의 모토만 본다면 좀 이해가 안가는 것이 있을 지도 모르나
이 4가지가 함께 움직인다면 매우 실현가능한 형태가 된다.

What is Agile?

가끔 용어의 명확한 정의가 필요할 때가 있다.
의사 결정권자에세 설명할 때, 감리를 받을 때,
논쟁이 길이질 때... 등

Agile 이란 무엇인가?

이렇게 정의해 보면 어떨까

"기업이 직면한 비지니스 문제를 3C+1D의 사상을 가지고
적절하고 빠르게 처리하는 방식."

(3C + 1D : Communication, Collaboration, Change, Delivery)

각 국가에서 XP를 얼마나 도입하고 있나

옆의 도표는 Yahoo의 eXtreme Programming group에서 발췌한 것이다.

미국과 영국을 비롯한 유럽지역이 전체의 70%정도를 차지한다. 반면 일본이 조금 되고, 나머지 아시아에서 XP의 도입은 매우매우 미미한 실정임을 알 수 있다.

선진국에서의 XP 도입의 이유를 한번 고려해보고 우리의 나아갈 방향을 정해 봐야 할 때다..

CMM와 XP 과연 어떻게 해야하나.

XP와 SW-CMM(이하 CMM)

CMM을 도입하고 있는 회사의 관리자라면, XP를 접했을 때이 두가지를 어떻게 (취할 건지 말건지 수준이 아니라 정말)할 건지 고민하게 된다. 분명 Agile 방법론으로 XP는 다른 방법론이 따라올 수 없는 훌륭한 면이 있다. 그러나 프로세스 중심의 CMM과 동일선상에 놓고 생각해 보면 그럴싸한 그림이 금방 그려지지 않는다.

이에 관해서 Barry Boehm이나 Watts Humprey, Mark Paulk등과 같은 소프트웨어 공학의 대가라고 하는 사람들의 꽤 많은 견해가 있었다.내가 듣고 보고한 견해 중 대부분은 서로 같이 사용할 수 있으며 상호 보완 가능하다는 것인데 그중 Mark Paulk의 말을 인용하면 다음과 같다.

"적절한 환경에서 적합하게 디자인된 Agile 방법론은 SW-CMM의 2 혹은 3 레벨의많은 부분을 커버할 수 있다. 적절과 적합이라는 것은 Agile 방법론의 디자인 시, 기업의 비즈니스 환경이 충분히 고려되어야 한다는 것을 뜻한다."

그렇다면 왜 XP를 사용하는 많은 기업들이 당장 레벨 2혹은 레벨 3의 인증을받지 못하는 것일까? 왜 CMM 심사위원들은 XP이야기를 하면 그리 달가와 하지않는 것일까? 이것은 아마도 방법론 혹은 이를 이루는 프로세스의 개발에 대한사상의 차이 때문이 아닐까 한다. 즉 XP는 개발자 개인에게 많은 것을 맡기는 것에 반해 CMM의 프로세스들은 조직의 생리와 비즈니스 환경에 더 치중한다.

이런 사소하지만 근본적인 차이가 두 영역간의 채울 수 없는 차이가 존재하는 것 처럼 느껴지게 한다.

하지만 많은 전문가들은 프로젝트를 수행하거나 프로세스를 직접 실행하는 당사자(회사)가이 두 가지를 모두 받아들일 수 있는 미래 지향적(?)인 태도를 취하면, 충분히 그 둘은잘 어울릴 수 있으며 큰 시너지 효과를 볼 수 있다고 한다.

흔히 볼 수 있는 상황은,

이미 한 회사에 QA 프로세스나 유지보수를 위한 문서 작성 지침이 마련되어 있다면어떤 경우든 이를 지키지 않으면, 이를 지키기위해서 만들어진 조직의 견재를 받게 된다.

지키지 못할 어떤 경우는 아이러니컬하게도 이 회사의 비즈니스적인 요구에 의해서 무시할수 없을 정도로 자주 발생한다. 이를테면 Time-to-maket을 공략하기 위해서 최소한의 기간에 최대한 상용 제품에 가까운 완성도를 가진 소프트웨어를 만들어 내기위해서eXtreme programming을 사용하는 것이 그런 예이다. 일단 Agile 방법론으로 XP 조직이 만들어 지면, 삐걱거리는 소리는 이 조직과 기존의 프로세스 지킴이 조직(?)과 예외없이발생한다.


이 논쟁과 타툼으로 인한 삐걱거리는 소리를 어떻게 없앨 수 있을까?많은 조직에서 이런 문제를 고민해 왔고 이를 해결하기 위해서 전문가 들이 노력해 왔다.해결책은 이미 많은 논문에서 다루고 있는 것 처럼 이미 나와 있는 듯하다.

"바로 XP의 기본 원리들을 수용하는 프레임워크로써 SW-CMM을 사용하는 것이다."

이렇게 하는 것은 두가지 측면에서 권장이 되고 있다.

하나는, 기업이 지금까지 투자한 프로세스 인프라를 그대로 이용할 수 있어서 투자에 대한 손실을 최소화 할 수 있다. 여기서 말하는 프로세스 인프라는 CMM의프로세스를 말한다. 한 번 구축된 OSSP는 결코 무시할만한 것이 아니다. 이 OSSP를 이용하여 비교적 손쉽게 전사적으로 XP의 원리들을 퍼트릴 수가 있다.

두 번째는, 이 프로세스 프레임워크를 이용함으로써 XP에서 발생하는 프로젝트 규모와관련된 여러가지 문제들을 무리 없이 해결할 수 있다. 이에 관해서는 본 서적에서 간략하게 다루고 있다.큰 규모의 프로젝트라 하더라도 독립적으로 구분된 컴포넌트를 독자적인 팀에서 개발한다면모듈 아키텍처를 정의하고, 이 모듈에 대해서 XP를 적용하면 무리없이 큰 프로젝트에도 XP를 사용할 수 있다고 했는데, 이는 SW-CMM의 프로세스 프레임워크를 이용하면 더욱 자연스럽게 이루어 질 수 있다.

말은 쉽게 했는데 사실 막상 SW-CMM 아래에 XP를 자연스럽게 넣어서 사용하기에는 어려운 면들이 있다.현재 SEI에서는 TSP와 XP를 접목한 TXP라는 방법론의 가이드 라인 및 CMM과의 접목에 대한 다양한 가이드라인을 내놓고 있다. 이런 것을 참고하거나 컨설팅 서비스를 이용하면 성공적으로 두 영역을 접목하여 기대하는 효과를 볼 수 있을 것이다.

마틴의 말,

오늘 옆의 contributors 중에 woossini라는 분을 만났다. (한마디 써줘요~)
마틴의 말을 인용하면서 대화가 시작되었는데, 너무나 공감이 가서 블로그에 남기려 한다. 정통부의 소프트웨어 인력 단가를 보고 갑갑한 생각이 들었던 사람은 모두 비슷한 생각이 들지 않을까 한다.

"소프트웨어 개발 인력은 도매금으로 넘길 수 있는 단순 리소스가 아니다. 즉 프로젝트에 필요한 인원이 10명이라면, 이 10개의 역할을 위한 인력, 즉 단순 리소스가 다 모였다고 해서 프로젝트를 시작할 수 있는 것이 아니라는 것이다. 누가, 어떤 사람이 그 역할을 맡느냐에 따라서 프로젝트를 진행할 수도 있고 못할 수도 있다는 것이다.

소프트웨어 개발 인력은 Quantity base가 아니라, Quality base라야 한다는 뜻이다. men month로 인력을 계산하는 것은 말도 안되는 것이다."

woossini : XP는 아무래도 인본위 적인 것 같아요. RUP가 프로세스 중심이라면, XP는 사람중심..
나: 동감, 간략한 최소한의 프로세스만을 두고 나머진 모두 사람에게 맡기는 것...

woossini : RUP나 다른 일반 개발 방법론은 애초에 모든 것을 측정 가능하다고 생각하는 것이 무리가 많은 듯.. 프로세스를 정해두고 많은 것을 측정을 하는데 노력 들인 만큼의 가치가 있을까 싶네요. 100개중에 98개를 잘 측정해도 2개가 잘못 측정되면 그 때문에 전체 프로젝트 파악에 차질이 생기기 쉬운데 어찌 측정에 목을 그리 많이 매는지 모르겠어요

나: 역시 동감, 소프트웨어 개발이라는 것이 단순 벽돌 쌓기 방식의 웹 개발이 아니면, 문제의 발생과 그의 해결, 혹은 요구사항의 발견과 그의 구현씩으로 여러개의 산을 넘는 경우가 많은데, 이런 경우 불필요한 측정은 걸림돌과 다름이 없게 되는 거죠. 그래서 프로젝트의 성격을 구분하여 기술 집약적인 부분은 XP로, 그렇지 않는 부분은 일반 정형적 방법론을 이용하는 것이 적절하지 않나 해요. 그래서 필연적으로 사람을 단순이 개수를 채우는 리소스로 볼 수 없는 거고 마틴이 말한 것처럼 Quality base의 인력구성과 고려가 필요하게 되는 것 같아요.

책에, 이 인력 구성에 대한 부분을 많이 할애하지 못한 것에 대해서 좀 아쉬움이 남는다. 이것 역시 많이 할애하면 전체 주제에 벗어날까봐 한두장 정도로만 쓰고 말았는데, 인력의 qualification framework같은 것이 절실히 필요하다는 생각이 든다.

FT(Fault Tolerance) Architecture

# Technology to know doing XP

엔터프라이즈 아키텍처의 기본 중 하나가 장애극복 즉 FT 아키텍처에 관한 것이다. 솔루션에서 지원되는 FT 기능을 그대로 이용할 수도 있겠지만, 정말 원하는 FT를 솔루션에 구현된 기능만으로 얻기는 힘들다.

왜냐면 최근 솔루션 밖에서 지원되는 스위치등의 영향으로 솔루션들이 자체 FT기능을 가지기 보다는 외부의 도구를 이용하는 경우가 많고, FT에 들이는 노력을 다른 기능적인 면에 들이는 경향이 있다.

그러나 솔루션 밖에서 FT를 지원하는 방안은 무척이나 답답한 면이 있다. 원하는 방향으로의 FT 아키텍처를 구성하기가 힘든 것이다. Failover 시간을 얼마 이하로 낮추는 ( 이를 흔히 time bound ft 라고 한다.) 품질 요소를 넣고 싶을 때, 어찌 할 도리가 없는 것이다.

때로 Real Time FT라는 것을 해야할 때, 자신의 엔터프라이즈 프로그램을 직접 그런 품질 요소에 부합하게 만들지 않고는 요구사항을 만족시키기는 쉽지 않다.

아래 링크에, 책에 나와 있는 Priya 교수의 수업을 들으면서 구현했다는 미들웨어의 FT에 관한 내용을 연결해 놓았다. 이를 모두 책에 실으려 했으나, XP는 그 철학대로 간략해야한다는 것에 충실하려 한바... 주제에 벗어난 내용이 너무 많이 나오는 것이 아닌가 하는 우려로 빼었었다. FT에 대한 기술적 배경으로 이 링크를 참고하기 바란다.

이 프로젝트의 목표는 Failover시간을 어떻게 하면 최소한을 줄이면서 정합성을 유지 할 것인가 하는 것이다. 도중에 JDK에 포함된 ORB의 worker thread 개수를 response time 을 보고 추측하는 그래프가 나오는데, 사실 그것은 중요한 것이 아니다. 중요한 것은 어떻게 TCP/IP connection을 재설정하는데 behind connection을 만들도 이를 bind 하는거 뭐 이런 것들이다. 소스는 public 하게 공개하지는 않으려 한다. 참고로 이를 바탕으로 고가의 솔루선에서 주로 사용하는 Memory paging 기반의 FT도 생각해 볼 수 있을 것이다.

Implementation of Real Time Fault Tolerance

그렇다면 전체 아키텍처에서 ESB의 위치는 어디인가?위의 그림에서 보는 것 처럼 WAS, EP, EAI를 포함하는 BPM그리고 시스템 관리도구 등의 기술적인 요소들과, 비즈니스 영역의 여러가지 요소들을 모두 포함하고 있다. 그림 위쪽의 추상적인 레이어가 뜻하는 것은 일종의비유로, HR이나 CRM 시스템 혹은 활동이 ESB를 통하여EP나 WAS로의 정보교환을 할 수 있다는 것을 의미한다.

아키텍처를 구성하려면 XP의 두 게이머가 머리를 맞대고 주기를 돌면서 구현을 하는 것이 좋은개발 방법일 것이다.

일반 프로젝트에서 요구되는 신기술 ESB

프로젝트를 하다보면 최상의 아키텍처를 정하는데 ESB에 대해서 많이들 묻곧한다. 웹서비스를 적용하다보면 필연적으로 ESB에 귀결되어 제품을 선정하게 되는데, 이러 종류의 아키텍처를 정하여 설계를 할 때도, XP는 필수적이다. (XP를 위해서 ESB를 설명하는 것 처럼 보이긴하지만, 신기술을 적용하는데에는 XP가 적절하다는 관점에서 쓰도록 하겠다.)

XP에는 두명의 게이머가 있다고 했다. 한명은 비즈니스를 담당하는 사람이고 한명은 개발을 담당하는 사람이다. (이때의 한명이라는 것은 하나의 담당 혹은 영역이라고 하는 것이 맞겠다.) ESB는 그림에서 보는 것 처럼 비즈니스 요구사항을 하나의 요소로 한다. 따라서 두 게이머가 머리를 맞대야지만 제대로된 ESB설계가 나올 수 있다.

ESB를 한마로 설명하자면, 웹서비스 기반의 기업용 메시지 버스이다. 기존의 EAI의 endpoint 중심의 연결에서 message semantics 중심의 라우팅으로 transport의 구분에 상관없이 유동적으로 메시지를 주고 받는 방식을 취한다. 그래서 ESB 아키텍처를 정의할 때는 구체적인 메시지 흐름을 정하는 것 보다는 비즈니스 영역의 추상적인 요구사항을 반영하도록 정의를 먼저 해야한다. 그다음, 실제 메시지를 정의하고 라우팅 정보를 입력하면 된다.

Legacy를 포함하는 Composite Application 구축하기

- XP와 함께 최신 동향 기술 적용하기 -

신기술을 적용할 때, 몇몇의 사람만 그 개념을 알고 있다면
프로젝트 진행도 문제고, 프로젝트가 끝나서도 문제다.

XP를 적용한다면 일부만이 알고 있던 그 신기술도
프로젝트가 끝날 무렵은 모두의 기술이 될 것이다.

최신 기술을 적용하는 프로젝트에 이런 이유로 XP를 적용하는 것은
매우 바람직하며 안정된 프로젝트로 이끌 수 있는 길이다.

Legacy가 많이 있는 상태에서 SOA를 구현하는 것은 그리 간단치가 않다.
EAI 기반의 연동이 필연적으로 들어가야하고, 이 때 사용되는 EAI가 SOA
의 Interface를 가지고 있어야 하며, SOA의 Consumer의 입장에서 Usability
를 만족시켰을 때, Legacy들이 그에 합당하는 응답 속도 등의 품질 요소를
보장해야하기 때문이다.

따라서, 먼저 필요한 Bisiness Process Optimization을 먼저 수행해야하고
이에 따른 Software Architecture를 디자인 해야한다.

아래의 참고 문서를 한번 보자.

http://www.lingocafe.net/PDS/hipark/ZapForum-CompositeAppsLegacy-072005-ZTP0179-1.pdf

프로젝트 규모와 개발 방법론

매우 큰 프로젝트, 즉 수십명의 BA와 수백명의 개발자 그리고 수십명의 관리자가 참여하는 프로젝트는 당연히 복잡한 프로세스를 포함하고 있는 RUP나 기타 방법론이 사용되어야 한다.

그러나, 개발자가 20인 이하라면 ?

이론적으로 이런 프로젝트에서 RUP나 기타 기존의 폭포수(waterfall)방법론을 사용하는 것은 불가능하다. 이때의 불가능이라는 말은 적용을 할 수 있지만, 제대로 그 방법론을 지키면서 제대로된 소프트웨어를 만들어 내는 것이 불가능하다는 뜻이다. 즉 적용은 할 수 있다. 과거나 현재 많은 곳에서 그래왔던 것 처럼말이다. 이런 적절치 않은 방법론의 적용이 현재 많은 소프트웨어 프로젝트에서 개발자가 힘들어하는 이유 중에 하나일 것이다.

20인 이하 프로젝트에서는 그에 맞는 방법론이 사용되어야 한다.

그런 방법론이 바로 XP와 같은 Agile 방법론이다.

제대로된 프로젝트를 위해서 이제는 프로젝트 산출물 중에,
방법론의 선택에 대한 적절함을 표현하는 문서가 추가되어야 할 때이다.

Code Quality 높이기

성공한 (소프트웨어)프로젝트건 성공한 것처럼 보이는 프로젝트이건
독립적인 프로젝트는 없다. 이후의 프로젝트에서 이번의 프로젝트를
이용하거나 확장 하는 경우가 많고 이 프로젝트의 유지 보수차원에서 또하나의
프로젝트가 생기기도 한다. 1990년대 이후 유행한 컴포넌트 개념 때문에
재사용의 이슈는 항상 따라다닌다.

재사용에서 가장 중요한 것은 무엇인가? 바로 재사용할 코드의 품질이다.
재사용가능하도록 만들어진 코드를 이용하는 것과 아무렇게 만들어진
코드를 이용하는 것은 개발자들에게 있어서 그야말로 하늘과 땅 차이다.

Code Quality이 낮은 프로그램을 분석하고 그것을 재사용하는 것은
프로그램을 아예 처음부터 만드는 것보다 더 어려운 일이라는 것은 불변의
진리이다. 그러나 안타까운 것은 많은 프로젝트들이 관리의 측면에서
만 코드 재사용이 논의 될 뿐 개발자들의 수준에서는 거의 "무작정
재사용 하라"라는 강요에만 그친다는 것이다. 이 말은 코드 재사용의
여부가 프로그래머 수준에서 동의를 구하고 있지 못하다는 것이다.

현실적으로 다음 프로젝트의 발주를 할때 프로그래머에게 일일이
코드를 보여주며 이것은 재사용가능한가? 라는 질문을 던져 그 동의를
구하는 과정은 개입할 여지가 거의 없다. 더군다나, 관리 문서상에는
코드 재사용의 여부가 나타나지 않는다.

어떤 기관에서는 코드의 품질을 높이기 위해서 "peer inspection"이라는
프로세스를 두고 지키려고 하지만, 아쉽게도 코드를 직접 작성한
프로그래머가 관리자의 틈에 껴서 이런 프로세스를 수행하여 그 프로세스의
뜻한 바를 달성하기에는 시간적 여유도, 코드를 완벽하게 이해하지 못하는
관리자를 설득할 힘도 없다. 결국 이름만 peer inspection일 가능성이 많다는
것이다.

재사용 가능한 코드와 그렇지 못한 코드에 대한 가격의 차이가 있는가?
필자는 아직 그런 차이를 두고 있는 프로젝트를 본 적이 없다.
잘했다 못했다의 차이만 있을 뿐...

어떤 기관에서 제 2차 프로젝트를 기획하고 있는 관리자의 말이다.
"1차에서 나온 코드를 재사용 하면 되므로, 2차의 프로젝트 비용은
원래 책정된 데서 한 20%정고 깍으면 되겠네요?"

개발 회사 왈 "1차에서 나온 코드를 재사용하는 대신 프로젝트 비용을
20% 깍겠다구요? 어떻게 그런..."

관리자 왈 " 1차 프로젝트에서 사용한 방법론이 CBD 아니었던가요?
그럼 당연히 재사용 가능한거잖아요"

개발회사 "..."

개발회사는 이런 경우를 한두번 겪은 것이 아니다.
CBD를 썼다고 한 코드를 받아서 재사용하고자 코드를 들여다 보고
코드를 아예 다시만드는 것이 낫다는 생각을 한 것이 한두번이 아니었기 때문이다.
(그래서 요즘 framework이라는 것이 다시 이슈가 되나보다)

악순환의 반복이다.

어떻게 이를 해결 할 수 있을까?

정교한 문서작업과, peer inspection으로는 현실을 제대로 반영하여 해결할 수 없다.
인간의 본연의 하고자하는 의지를 반영하지 못하는 방법론에서
CBD아니라 CBD할아버지가 쓰였다고 하더라도
제대로된 코드가 나올 수 없다.

XP는 이러한 문제를 원천적으로 해결한다.
왜냐고?

기능테스트 통과만을 목적으로 대강만들어진 프로그래밍으로는
XP자체를 수행할 수 없기 때문에다. 즉 대강 대강이라는 자세로는
프로젝트 자체를 진행할 수 없기 때문이다.

peer inspection이니 CMMI이니 하는 비싼 정책을 도입하는 것 보다
Code Quality 향상을 위해서는 XP를 도입하는 것이 더 효과적일 것이다.