간단한 개발 프로세스의 디자인

소프트웨어 프로젝트 개발관리에 너무 많은 형식이 존재하여 그것 자체가 개발의 발목을 잡지는 않는가?

소프트웨어 시장의 왜곡

기업대 기업이 관련한 일은 항상 수주를 하는 측, 소위 말하는 을과 발주는 하는 측, 즉 갑이 존재한다. 기업과 기업이 거래하는 일임에도 불구하고 눈에 띌 정도로 드러나는 주종의 관계가 드러난다. 종종이라고 썼지만 IT 산업계에서의 이론 관계는 종종이 아니라 늘, 항상이라는 표현이 더 적절할 것 같다.

많은 엔지니어들이 이런 관계때문에 본연의 일보다 부가적인 스트레스를 받는다. 직업의 좋고 나쁨이 이 관계에서 주종을 어떻게 차지하느냐로 결정되기도 할 정도이니, 그 정도는 가히 심하다 하겠다.

약 3달간의 컨설팅업 20여분, 전자 분야의 약 10여분, 그리고 소프트웨어 분야의 20여분을 통해 질의를 해본 결과 소프트웨어에서의 이런관계가 전자, 다른 컨설팅보다도 더 심하게 나타나는 것 같다. 왜일까? 복잡 다단한 이유로 풀어쓸 수 있겠지만...

단 하나 가장 큰 이유는 엔지니어, human power의 quality인 것 같다. (이게 아니라고 생각 하시는 분은 다양한 다른 의견 환영한다.)human power의 quality는 replaceability에서 기인 한것 같고..

즉 아무나 이일을 할 수 있다는 그런 생각 때문에 "너(회사)가 아니라도 이일을 할 데는 많이 있다." 뭐 이런 생각이 발주는 하는 회사의 마음속에 깔려 있는 것이다. 이런 발주사에 대응을 하려다 보니 수주사는 cost를 줄일 방도를 생각할 수 밖에 없고, 이는 곧 고급 인력보다는 싸고 말 잘 듣는 인력을 쓰게끔 하게되는 것이다. 주구장창 고객과 싸우고, 주말도 없으며, 세븐투 일레븐(아침 일곱시에 출근 저녁 11시에 퇴근)으로 일하며, 복지 따위는 상상도 할 수 없는 분야에 남아 있을 고급인력은 있을리 만무하다.

결국에는 replaceability가 극도로 높은 사람들을 낮은 가격에 부리는 다수의 회사들이 서비스를 제공하게 되고 이를 이용하는 고객사는 이런 사람들이야 갑질을 해야 제대로 결과가 나온다는 굳은 신념을 가지게 된 것 같다.

안타까운 것은 이런 와중에 정말 중요한 소프트웨어의 산업 부분이 왜곡되고 전부 하향 평준화되어 갑싸고 별 가치없는 쓰레기 소프트웨어로 넘쳐나는 것이다. 돈을 주고 소프트웨어를 사용한다는 개념따윈 물건너간지 오래다. 서로가 멋진 상승 작용을 일으켜 전세계 소프트웨어 시장에 단 1%의 시장도 가지지 못하는 한국의 소프트웨어 산업은 이런식으로 지속적으로 아래로아래로 추락하고 있는 것이다.

, 이것 봐라 아무나 하지 않느냐고 반증이라도 하듯이 경제, 경영, 미술, 체육, ... 수없이 많은 비진공자들이 소프트웨어를 만들고 있으며, 이것의 위험함, 잘못만든 소프트웨어를 비판할 세력 조차 잃어 버린 체로 표류하고 있다. 아무나 하는 소프트웨어 시장의 많은 UNUQALIFIED humman power는 이제 너무도 많이 누워서 침뱉기를 많이 한 탓에 더이상 침을 뱉을 데도 없다. (replaceability는 이러한 누워서 침뱉기 식의 행동 양태로 인해 더욱 가속을 받고 있다.)

감리에 대한 단상

프로젝트 진행에
가장 많은 지식을 가지고 있느 사람은
그 어느 누구도 아닌 바로 프로젝트를 진행하는 당사자 입니다.

감리의 가장 기본 원칙은 상식선에서 첨부터 감사하는 것이 아니라
하기로 정의한 것을 제대로 했냐라는 것을 감사하는 것입니다.

이런 감리를 위해서 조언을 하기로 했다면 이 선에서 조언을 해주시는 것이
맞다고 봅니다. 어느 프로젝트에나 불합리성은 존재합니다.
개발 자체도 그런 것이 있을 수 있습니다만, 소위 말하는 이바닥의 생리상
불합리가 생기는 것이 다반사일 듯합니다.

더군다나 소프트웨어 공학에 대한 학문이 뿌리가 거의 없는 덕에
우리나라에는 공학적 원리를 제대로 가지고 접근하는 사람이 없습니다.
공학적 원리를 제대로 가지고 말을 할려면 이론적 근거를 대고 말을 시작해야할 것입니다.

그렇게 말을 하지 못할 것이면,

프로젝트에서 하기로 한것을 최대한 존중하면서
그 테두리 안에서 되어 있나 되어있지 않나를 검사해야 할 것입니다.

자신의 지식과 프로젝트 에서 하기로 한 것이 맞지 않은 부분은
왜 라고 하는 물음을 먼저 던져야 할 것입니다.

왜라는 것에 제대로된 답을 얻지 못했다면
자신의 지식에 비추어서 이렇게 하라고 할 것이 아니라
프로젝트 전반을 모두 파악한 다음에 그 바탕으로 이렇게 하라고 해야할 것입니다.

하루종일 우리의 목소리가 아니라 제 3자의 목소리가 낭자한 오피스텔에서
프로젝트 참가자들이 스트레스를 안 받을 수 없습니다.

OCP 등..

XP를 효과적으로 수행하고자 한다면..
" Robert C. Martin"디자인 패턴 책을 꼭 보길 권한다. ( 굳이 " Robert C. Martin"의 책을 언급한 이유는 제일 재밌어서)

둘이서 머리를 맞댄다면, 무엇에 대해서 머리를 맞댈 것인가? 단순이 타입이 정확이 써졌나, 캐스팅이 제대로 되고 있나. 어사인이 어떤가 뭐 이런 거면 사실 혼자 하는 것이 좀더 효율적일지도 모르겠다.

둘이서 머리를 맞대고 할만한 것은 좀더 복잡 다단하고 둘의 머리를 모으면 그로테스크한 결과물이 나올 듯한 거리이면 그 효과가 더욱 커질 것이다.

객체 모델링이 그런 것이 아닐까 한다. 특히 처음부터 모든 것을 개발하는 (COTS를 사용하지 않는 ..)곳에서는 고객의 말, 즉 Use case속의 시나리오를 보고 객체를 도출하고
(ICONIX 프로세스를 아는 분은 이런 과정의 지리함과 논리적이지 못한 순간의 실수가 가져오는 엄청난 번거로움을 잘 알 것이다.)그 객체간의 관계 (cardinality 등을 포함하여)를 지은다음에 패턴을 적용하고 클래스 다이어그램, 혹은 시퀀스 다이어그램으로 모델링을 하는 과정을 힘들게 거쳐야 한다.

이런 경우, 어떻게 모델링을 하느냐에 따라서 프로그램 산출물의 품질 요소는 매우 큰 편차를 보일 수 있다. 비록 같은 기능을 보이고 있다고 하더라도 말이다. 그리고 본 책에 나오는 리팩토링의 여지도 케이스마다 매우 달라진다.

다시말해 처음에 어떻게 객체를 정의하고 디자인 패턴을 대입하느냐에 따라서 잘만든 코드와 그렇지 않는 코드의 격차가 커진다는 것이다. 모델링이 잘못 된 코드는 수정이 힘든 것을 물론이겠거니와, 디버깅시에 트레이싱하는 것도 그다지 쉽지 않다. ..

예르 들자면 마틴의 책에는 OCP 원리를 비롯하여 다양한 원리들을 실전에 적용할 수 있는 형식으로 설명을 하고 있다. (OCP 원리란 Open to add, Close to modification로 기능 추가는 쉽게 할 수 있으나 수정을 배재하는 원리를 말한다..)

코드화 하는데 매우 많은 경로가 있는 객체 모델링 그리고 그에 따른 코드 패턴의 적용, 그리고 베스트 프렉티스와 원리들.. 이런 것을 모두 고려한 코딩을 하는 것은 큰 정신 노동이 아닐 수 없다. 둘이서 하는 페어 프로그래밍은 이러한 정신 노동의 부담을 덜어주며 관련된 XP의 원리들은 최적화된 산출물을 얻을 수 있도록 해준다. (이런 의미에서 XP 참가자들은 원숙미를 자랑하는.. 적어도 객체 모델링으로 대화를 할 수 있는 사람이어야 하지 않을까 한다.)

웹서비스와 재사용

XP에서 Refactoring을 지속적으로 하는 이유중 하나가재사용 극대화이다. Refactoring은 시중에 많은 서적도 있고...

독자중 한 분이 웹서비스로 재사용을 하는 경우에 대해서 물어 왔다... 예전에 기사로 작성한 글이 있어서 올려본다.이 글을 XP와는 아무런 관련이 없다. 다만 XP를 적용하는 많은 분들이 최신 기술을 적용하는 기술에 대한 early adapter인 경우가 많으므로 참고삼아 한번 올려 본다.

웹서비스를 이용한 소프트웨어의 재사용
open password : "park"

현명하지 못한 짓

가장 어리석은 것 중에 하나가 당장에 의미가 없는 원리에 얽매이는 것이다.아무리 좋은 원리가 있다고 하더라도 그것이 시공을 초월하여모든 경우에 적용될 수는 없다. 따라서 왜(?)라는 것에 정확한 답을가지고 있지 못하면서 무턱대고 따라하는 것은 그다지 현명한 짓(!)이 못되지 않을까 싶다.



방법론과 같이 원리들과 프로세스가 모여있는 이론을 적용할 때에,방법론에 따른 단순한 행동 패턴보다 그 내면에 존재하는 사상과 원리가 더 중요한 것은이러한 이유에서이다.

사상과 원리를 이해하면 최소한 무턱대고 따라하는 것과, 무턱대고 경우에 맞지 않는데도 그 원리를 적용하려고 부질없는 애를 쓰지 않아도 된다.

개발 방법론은 기본적으로 매 프로젝트의 성격에 맞게 수정이 된다.

(개발 프로젝트마다 프로세스 핸드북이 있는 것은 좋은 반증이다. 없는가? 없는 것은 정상이 아니다. 10개의 프로젝트를 보았는데 10개 다 프로세스 핸드북과 같은 것이 없어도? 적어도 10개 다 정상이 아니라고 본다. 명칭이 프로세스 핸드북이 아닐지라도 그와 비슷한 내용을 담고 있는 문서가 있으리라 본다. 그와 비슷한 내용을 담고 있는 문서가 없다면 정말 정상이 아니라고 본다.)


이 수정의 기본은 방법론에 존재하는 사상과 원리의 이해이다.그것을 바탕으로 지켜야할 원리 그리고 버려야할 원리를 프로젝트의 성격에 맞게발라내고 적용시켜야 하는 것이다. (여기서 그러면 매번 새로운 방법론을 만들지?라고 반문하는 사람이 있을지도 모르겠다. 그러나 있는 것을 수정하는 것과 새로운 것을만들어 내는 것은 하늘과 땅차이이며 feasibility 검증에 대한 이슈도 존재하므로 논의의 대상이 안될 것이다.)그리고 모든 개발자들에게 기본 사상과 이론을 알기쉬운 언어로 설명되는 것도 바로 이 수정의 단계에서 이루어진다.

이쯤에서 XP의 페어 프로그래밍에 대해서 좀 논의를 해보자.다른 방법론과 구별되는 독특한 원리이고, XP의 대표적인 원리이기도 하다.또한 불행인지 다행인지 모르겠지만 인터뷰한 대부분의 개발자들이 XP하면 이 페어 프로그래밍의 원리를 먼저 언급하였다.

이렇게 튀는 덕에 XP 중 가장 많은 논란의 대상이 되는 원리가 되었다.

반대에 서는 나름대로의 큰 목소리중의 하나는 혼자서 해도 되는 것을 왜 굳이 둘이서 하느냐는 것이다. 인건비의 손해요 시간과 노력의 손해가 아니냐는 것이다.

그리고 여기에 나오는 반론이 책에서 쓴 것처럼, 둘이서 하나의 코드를 만들게 되면에러를 줄일 수 있고 높은 품질의 디자인을 생산할 수 있으므로, 한명의 n만큼의 일을 할 수 있다면 2n + alpha의 효과를 볼 수 있다는 것이다.

나는 여기에 큰 모순이 있다고 생각한다.

코드를 생성하는 데에는 정말 혼자서 해도 되는 일이 있고, 둘이서 하면 시너지를 매우 볼수 있는 일이 있다. 즉 코드의 종류와 목적 등에 따라서 그때 그때 달라진다는 의견을 나는 가지고 있다.

1999년도 부터 불어닥친 IT 열풍으로 (누가 그랬던가 2003년까지 소프트웨어 개발 인력이5만명이상이 부족해질 것이라고..) 개발자 양성 학원이 강남에 우후죽순처럼 생겨났다.수없이 많은 비전공자들이 3개월에서 6개월 정도만 교육을 받고 소위말하는 프로그래머로 활동을 하게 되었다. 그로부터 지금까지 그 프로그래머들에게 무슨일을 해왔는지 묻고 싶다.(세계 시장 점유율 측면에서 한국에 제대로된 소프트웨어 개발을 하는 회사는 그리 많지 않아 보인다.)

안타깝게도 인터뷰에 응한 개발자 중 반 이상이, 자신이 하는 일은 아무나 할 수 있는 일이라고생각한다고 답했다. 즉 전문가로서의 특별한 자질이 없어도 누구나 한 3개월 정도의 직업 교육훈련만 받으면 할 수 있는 일이라고 답했다. 누구나, 그리고 아무나 할 수 있는 일이라서 자신이 오늘 밤을 새는 것이며, 고객의 높은 언성을 참고 있는 것이라는 대답을 하는 사람도 있었다.물론 자신만이 이 일을 제대로 할 수 있으며 자신보다 잘하는 사람을 보지 못했다는 개발자도 있었다.

이런 조사의 결과에서도 볼 수 있듯이, 자신도 아무나할 수 있고 누구나 알수 있다고 생각하는데 (주위 사람들도 모두 그렇게 생각하는데) 이런일을 둘이서 앉아서 개발할 필요는 없을 것이다.이런 경우에 XP를 적용한다고 무턱대고 둘이서 앉아서 개발을 한다고 들면 그리 좋은 결과를 기대하기는힘들 것이다. 당장 고객이나 상급 관리자로부터 질책을 말을 먼저 들을 것이다.

어떤 코드들이 이런 것인지에 대해서 여전히 논란이 많은 것이다. 구분이 매우 모호하기 때문이다.이때의 모호하다는 의미는 같은 종류의 코드라고 상황에 따라 페어 프로그래밍을 적용해야 할 때도 있고그럴필요가 없을 때도 혹은 적용하지 말아야 할 때가 있다는 것이다.

예를 들어보자. 최근 몇 년간 가장 많은 소프트웨어 개발자가 참여한 소프트웨어 개발은 아마도 SI소위 말하는 기업 환경에서 소프트웨어 통합 구축프로젝트일 것이다. 이 일에서도 가장 많은 비중을 차지 했던 것은 웹기반 개발이다. 웹기반 개발을 하나만 보더라도 매우 많은 종류의 코드들이 존재한다.

이중에서도 가장 많이 보는 두가지 예를 들면 웹개발 전체를 위한 framework의 개발이고 또하나는 이를이용한 웹페이지와 이 그면의 로직 개발이다. 많은 경우 전자는 페어 그래밍의 필요한 부분이고 후자는적용하지 않아도 되거나 공수가 모자라고 기간이 짧은 경우에는 적용하면 안되는 그러한 경우라고 할 수 있다.

시스템 소프트웨어의 코드, 재사용이 많이 필요한 기간 코드 등은 페어프로그래밍이 꼭 필요하다고 할 수 있다.반면, 화면 디자인과 관련된 코드, 일회성 하드웨어 드라이버 제작 등은 페어 프로그램이 필요 없다고 할 수 있다.

일회성이라고 하더라도 매우 중요한 하드웨어 제어 코드 (hard real time)등은 알고리즘이나 기본 수치분석 등이중요하므로 객제 지향 패턴(책에서 강조한)과 상관없이 페어 프로그래밍의 효과를 크게 볼 수 있다고 할 수 있다.

모든 것에는 trade-offs가 존재한다. 그때 그때 다른 것에 대해서 어찌할 지는 이 trade-off들을 고려하여 결정하는것이 좋다. 그러기 위해서는 페어 프로그래밍의 경우 그 사상과 그것을 통해 얻고자 하는 바, 다른 원리들과의관계등을 명확히 이해하여 trade-off를 분석하고 그에 따라 결정해야 할 것이다.

우스게 소리

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

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

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

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

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

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

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

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

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