훌륭한 프로그래머의 딜레마 다시...

[하늘이]

이전에 "훌륭한 프로그래머의 딜레마"라는 글을 퍼오신 분이 계신데 아래주소에 원문이 있군요.

http://no-smok.net/nsmk/_c8_c7_b8_a2_c7_d1_c7_c1_b7_ce_b1_d7_b7_a1_b8_d3_c0_c7_b5_f4_b7_b9_b8_b6

이 글을 아직 이해를 못하시는 분도 계실것 같아서 제가 이에 대해 약간의 보충설명을 하겠습니다. 우선 이 글을 쓰신 김창준씨가 XPER(XP를 sw개발 방법론으로 삼는 사람)라는것을 지적해야겠습니다. 이때 XP는 윈도XP가 아니라 eXtreme Programming의 약자로 기본 모토는 RUP(Rational Unified Process)같은 무거운 개발방법론과 거의 정반대의 sw개발 방법을 지향하는것입니다. 제가 이 둘을 모르시는 분들을 위해 아주 간단하게만 설명하겠습니다.

공통점 : 둘다 sw개발 기법(방법론)에 속함. "sw를 어떻게 개발해야 하느냐?"에 대한 질문에 대해 학계의 전문가와 노련한 개발자들의 공동 노력의 산물로 나온것.

차이점 :

1. RUP : 래쇼날 소프트웨어라는 단일 회사에서 객체지향 방법론에 대한 학계의 최고 전문가들을 끌어모아 "통합된 소프트웨어 개발 방법론"을 만들어보자는 취지로 나오게 된것. 이론적으로는 매우 거대한 SW개발 조직부터 작은 조직에 이르기까지 RUP를 적용할 수 있는것으로 되어있으나, 실제적으로는 거대 규모의 조직에서 더 잘 사용되고 있으며 유효성면에서도 조직의 규모가 클수록 RUP의 효과가 더 크다는것이 입증되고 있음. RUP가 제시하는 방법은 개발자들의 역할이 매우 세분화되어 있을것을 요구하고, 각 개발자 역할별로 해야 하는 일들을 정확하게 할당하여 지정된 시점에 끝마칠것을 요구함. 기본적으로 모든 개발은 문서작업(오프라인, 온라인 모두) 위주로 진행되며 코딩은 이러한 설계서에 의해서만 부수적으로 진행됨. 설계가 매우 중요하고, 이 때문에 초기의 아키텍트 역할이 무엇보다 중요함. 개인보다는 조직으로 SW개발을 진행. 형식적 개발 절차를 잘 따르는것이 중요.

2. XP : RUP와 거의 모든 면에서 반대라고 생각하면 됨. 학계에 있는 사람들보다는 창조적인 해커들이 자신의 경험에서 자연스럽게 도출시켜 나오게된 sw개발 방법론임. 워드 커닝햄, 켄트벡, 론제프리같은 사람들이 그 대표적인 인물들. 일반적으로 고객의 요구사항이 매우 빠르게 변하는 프로젝트나 작은 규모의 SW개발팀에서 그 유효성이 입증되고 있음. 설계란것은 아예 없음. 코드자체를 설계로 놓고 프로그래밍이 SW개발의 전부라고 생각함.(그래서 extreme programming) 문서작업도 요구하지 않음. XP에서 단순성(코드를 될 수 있으면 단순하게 유지하는것)은 아주 중요한 요소임. 조직보다는 개개인의 역량에 의해 SW개발을 진행.

서론이 지나치게 길었군요. -_-; 어쨋든 이런 두 방법론의 차이점을 인식한다면.. 김창준씨가 왜 "훌륭한 프로그래머..."라는 글을 썼는지 그 배경을 약간은 이해할 수 있을겁니다. 위에서 설명했듯이 김창준씨는 한국에서 대표적인 XP 프로그래머로 인정되고 있으며, 그가 단순성(Simple Design)을 강조하는것은 XP의 기본 교리에 의해 당연한 일이 됩니다. (김창준씨는 XP라는 방법론과 위키시스템을 한국에 최초로 도입한 장본인입니다.)

물론 여기서 오해하지 말아야 할것은 XP가 단순함을 지향했으니 이와 반대편에 있는 RUP가 "복잡한 설계"를 지향한다고 생각할 수 있는데 이것은 사실이 아니라는 점입니다. 일반적으로 동일한 요구사항에 의해 개발하더라도 RUP를 따라 개발한 프로그램이 XP를 따라 개발한 프로그램보다 더 복잡해지는것은 사실입니다. 그것은 RUP가 복잡함을 지향했기 때문이 아니라 XP와는 기본 노선이 다르고, 그런 노선을 따르다보니 복잡해질 수 밖에 없는 측면이 있기 때문이죠. 단적으로 말하자면 RUP는 "미래"에 촛점을 맞춥니다. "고객이 앞으로 어떻게 요구할것이다"라는 부분까지 다 고려해서 될 수 있으면 완벽한 설계를 하기 위해 미래에 나올법한 요구사항들을 미리 다 설계에 고려해 넣는것입니다. 반면에 XP는 미래를 예측하는것은 전적으로 불가능하다라고 선언을 해버리고 "고객이 현재 요구하는것"만을 프로그램한다는 기본 철학을 갖고 있습니다. 이렇게 보면 RUP는 주어진 환경에서 최적 설계를 이뤄야 한다는 공학(Engineering)의 기본정신을 충실히 따르고 있고, XP는 단지 현재 주어진 요구사항만 충족시키면 된다는 적응성(Adaptedness)을 충실히 따르고 있는것이죠.(적응성은 생물체의 진화와 그대로 연결됩니다. 인간의 눈은 독수리의 눈보다 성능이 떨어집니다. 공학적인면에서 봤을때 인간의 눈은 썩 좋은 설계를 갖고 있지 않습니다. 하지만 이 정도의 성능을 가진 눈만으로도 우리가 정상적으로 사는데 아무 지장이 없습니다. 우리의 눈은 딱 우리에게 필요한만큼만 진화했다는겁니다. 다른 신체기관도 마찬가지이고, 인간뿐 아니라 모든 생명체가 다 그렇습니다.)

어쨋든 XP는 단순성을 지향하며, 기본적인 철학을 따지자면 RUP도 마찬가지입니다. 그러나, 현실속의 상당수 멍청한 관리자들과 바보같은 개발자들은 왜 코드가 단순해야 하는지를 이해하지 못합니다. 코드가 복잡할수록 그리고 그것이 차지하는 라인수가 더 많을수록 "뭔가 있어보인다" 혹은 "일을 더 많이 했다"라는것으로 인정되기 때문에 코드가 복잡하고 더 많은 부피를 차지할수록 더 좋은것으로 생각하는 경향이 있습니다. 제가 볼때 김창준씨는 이런 현실상의 한심한 현상을 "훌륭한 프로그래머.."라는 글을 통해 비꼬고있는것으로 보입니다. 그리고 이에 대해선 그냥 이정도라고 생각해두면 될일이지, 김창준씨가 쓴 글에 대해 크게 의미 부여를 하고, 뭐 그럴것까지는 없을듯합니다. (그렇지만 제가 쓰는 이 글은 지나치게 길어지는군요)

다만...초점을 김창준씨의 글보다 단순성(Simplicity)자체에 집중한다면 이것은 아주 중요한 주제가 될 수 있다는것을 기억하셔야 합니다. 위에서도 멍청한 관리자들은 "프로그램이 왜 단순해야 하는가?"에 대한 의미를 제대로 이해하지 못하고 있는데 이것은 단순성이라는것이 컴퓨터 프로그래밍의 범위 자체를 벗어나서 매우 광범위한 분야에서 아주 중요한 성질을 갖고 있다는것을 그들이 이해하지 못하기 때문입니다.

단순성은 과학, 수학, 예술에서 공통적으로 심도있게 다뤄지고 있는데 일반인들은 이 사항을 제대로 알지 못하고 있습니다. 그리고 프로그래밍 역시 과학 혹은 수학의 부류에 속한다고 할 수 있기 때문에 이러한 단순성의 성질을 중요하게 생각할 수 밖에 없다는것 역시 눈치채지 못하고 있습니다. 프로그래밍 분야에서 단순성을 강조하는 얘기는 참으로 많습니다. 다음 글을 보시기 바랍니다.

KISS 원칙

KISS는 Keep it small and simple., Keep it short and simple 또는 Keep it simple, stupid의 첫글자만 따서 만든 약어로, KISS 원칙이란 디자인에 있어서 간단하고 알기 쉽게 만드는 편이 좋다는 원리를 말한다.

이 표현은 아마도 프로그래밍 언어 포스(Forth)를 발명한 척 무어가 쓰기 시작한 것으로 보이며, 프로그래머들 사이에 많이 동용되는 격언이다. 이 디자인 원리는 될 수 있는 한 간단하고, 나중에도 쉽게 이해되는 해결방법을 최적의 해결책으로 생각한다.

KISS는 과학이론에 있어서, 있으나 없으나 차이가 없는 불필요한 가정은 잘라내야 한다는 오캄의 면도날 원칙과도 맞닿아 있다.

자...여기서 오캄의 면도날 얘기가 나옵니다. 아실분도 계시겠지만 모르시는 분들을 위해 어딘가에서 발췌한 내용을 여기 제시해봅니다.

오캄의 면도날(Occam's Razor)

기본적인 과학원리 중 하나인 Occam's Razor 에 따르면 모든 것이 똑같은 조건일 때, 가장 쉬운 설명이 가장 옳은 것이라고 한다.

'불필요하게 복잡한 언명 (言明) 을 제시해서는 안된다 (plurality should not be posited without necessity).' 이것은 중세 영국의 철학자이자 프란체스코 수도원의 수도사였던, 윌리엄 오브 오캄(William of Ockham, ca.1285-1349)의 말이다.
(중략)
오캄의 면도칼은, 절약의 원리 (principle of parsimony )라고도 불려진다. 최근에는 '설명은 단순한 것일수록 뛰어나다', '불필요한 가정을 늘이지 마라' 등의 의미로 해석되고 있다. 어쨌든, 오캄의 면도칼은 존재론의 밖에서도 빈번하게 쓰이고 있다. 예를 들어, 과학철학자는 비슷한 정도로 정확해 보이는 가설이 여러개 있을 경우, 가장 적합한 가설을 골라 내는데 오캄의 면도날을 사용한다. 무언가를 설명하기 위해 가정을 할 경우, 불필요하게 복잡한 가정을 세워서는 안된다 ........ . Von Daniken 이 옳을지도 모른다. 즉, 지구밖의 생명체가 고대 지구인에게 예술이나 기술을 가르쳐 주었을 지도 모른다. 그러나, 고대인의 기술이나 예술에 대해서 설명하는데, 우주인의 방문을 가정할 필요는 없는 것이다. 왜 불필요한 복잡한 가정을 만드는가? 또, 많은 사람이 하는 것처럼, 꼭 필요한 가정만 만들어야 된다. 먼 곳에서 일어나는 일을 설명하는데 에테르를 가정하는 것은 가능하지만, 굳이 에테르가 필요하지는 않다. 그럼, 왜 근거가 희박한 에테르를 일부러 가정하는 것인가?

그리고 그 유명한 패러다임이론을 만들어냈던 토마스쿤은 단순성을 과학이론을 선택할때 매우 중요한 기준으로 설명하고 있습니다. 다음 설명을 보시기 바랍니다.

과학 혁명에 대한 논의에서 쿤은 과학 변동의 단절적이고 불연속적 측면을 극적으로 부각한다. '과학 혁명'은 패러다임이 교체되는 과정이다. 여기서 패러다임 선택의 문제가 등장한다. 그런데 쿤은 패러다임 교체를 형태 전환(gestalt switch) 또는 종교적 개종에 비유한다. 이러한 비유는 경쟁하는 패러다임들을 평가하는 데 사용될 수 있는 초패러다임적 규칙들이 존재하지 않는다는 그의 주장과 함께 과학자들의 패러다임 선택을 비합리적이 되게 한다는 의심을 불러일으켰다. 이에 대해 쿤은 자신도 패러다임 선택에는 나름대로 이유들' 이 존재한다고 믿지만, 그 이유들은 연산법적규칙 적용이 아니라 과학자들이 폭넓게 공유하는 과학적 가치－예를 들어 정확성, 일관성, 단순성 등－ 적용에서 비롯한다고 대응했다.

자 이쯤되면 단순성(simplicity)가 단순히 프로그래밍에만 적용되는 사항이 아니라는 사실과 함께 "이것에 뭔가가 있군..."하고 생각할것입니다. 네 맞습니다. 그렇게 생각해야 정상입니다. 단순성은 과학의 기본 교리인 환원주의와 그대로 연결이 되어 있기 때문입니다.

환원주의(reductionism)
존재하는 모든 다양한 현상을 최하위 계층의 법칙과 개념으로 설명하려는 입장. 가장 기본적으로는 자연에서의 계층성이 인정될 때, 상위계층에서 성립하는 기본법칙과 거기에 사용되는 기본개념(복잡한것)이 반드시 그보다 한 층 아래의 계층에서 성립하는 기본법칙 및 기본개념(단순한것)에 의하여 번역 또는 치환이 가능하다는 입장을 가리키며, 이 과정을 반복하면 결국엔 가장 기본적인 법칙·개념에 도달할 수 있다는 것이다. 따라서 개념 및 법칙의 다양성을 ＜줄인다＞는 의미로 ＜reductionism＞이란 말이 생겨났다.

그리고 이러한 단순성이 예술로 흡수되어 나타난 사조가 바로 미니멀리즘입니다.

미니멀리즘(Minimalism)
예술적 가치를 관객이 자각하도록 유도한 '최소한'의 미술. 미니멀리즘은 1960년대 중반 미국에서 태동한 새로운 미술 경향으로서 형식상의 대칭, 전통적 의미에서 구성의 결여, 무채색 등을 특징으로 하는 단순하고 텅 빈 기하학적 오브제들을 총칭한다. 애초 이 용어는 미국의 철학자이자 미학자인 리처드 월하임이 명명했다. 미니멀리즘은 칼 안드레, 래리 벨, 댄 플래빈, 도널드 저드, 솔 르윗, 로버트 모리스, 리처드 세라 등에 의해 주도되었다. 이들은 최소한의 표현수단으로 작품을 만들어냈고, 이 새로운 미술은 아무것도 모사하지 않는 비대상 회화를 생각했던 말레비치의 전위적 사고와, 대량생산된 공업제품을 그대로 제시한 마르셀 뒤샹의 반미학적 발상으로까지 그 아이디어가 거슬러 올라간다.

애초의 김창준씨의 글은 프로그래밍에서 단순성을 강조하는것이 그 기본 취지이고, 또한 단순성을 현실의 멍청한 이들이 제대로 이해를 못하고 있기 때문에 훌륭한 프로그래머가 질낮은 프로그래머로 생각되는 아주 이상한 현실을 비꼬는것이었지만, 제가 이 글에서 강조하려는것은.. 단순성이 프로그래밍 분야에만 제한적으로 적용되는 사항이 아니라 훨씬 광범위한 분야에서 철학적으로 무게가 있는 중대한 주제로 여겨지고 있으며 프로그래밍 분야는 단지 과학의 하위분류에 속해 있기 때문에 단순성을 중요하게 받아들이는것 뿐이라는 사실입니다. 단순성 자체에 대해서는 그렇게 단순하게 생각할것이 아니라는거죠. 끝으로 단순성을 찬양하는 다음과 같은 명언을 덧붙이면서 이 글을 마치죠.

완벽함은 더 이상 추가할것이 없을때가 아니라 더 이상 버릴것이 없을때 달성된다. -생텍쥐 페리

"Everything should be made as simple as possible, but not simpler." -아인슈타인

[westship]

좋은 글 올려주셔서 감사합니다. 그런데 불현듯 생각나는 질문 한가지. 프로그래머가 정말 할만한 직업인가요? 하늘이님은 왜 프로그래머를 접고 학문을 하려고 하시는지 궁금합니다. 프로그램 공부 정말 열심히 한 것 같은데...또 계속 이 분야에 종사해도 좋을 것 같은데 왜 진로를 바꿔서 사서 고생을 하려고 하시죠?

[하늘이]

깊게 공부하면 관련되어 있는 어느분야든 다 통하게 되어 있습니다. 프로그래밍은 논리를 만들어내고, 개념의 세계를 창조해내는 분야중에 대표적인 하나일뿐입니다. 그리고 저는 그런 특성을 갖는 다른 분야에 관심을 갖고 공부를 하려는것이죠. 그래서 그런 학문을 공부한다고 해서

[하늘이]

특별히 프로그래밍이라는 세계를 떠난다고 생각하지 않습니다. 코끼리 연구하는 사람은 코끼리만 연구한다고 생각하겠지만 코끼리가 포유류에 속한다는것을 생각해보면 포유류에 대한 공부도 알게 모르게 하게 되는것입니다. 저는 시야를 좀 더 넓혀 포유류 전체를 더 적극적으로 공부하려고 할뿐입니다. 전혀별개가아니죠

[하늘이]

그리고 고생을 더 하고 아니고를 떠나서 저는 공부하는것 자체가 좋고, 스스로 그런 부분을 타고난 부분이 있다고 생각합니다. 또 프로그래머는 "해볼만한 사람"으로선 할만한 직업이라고 봅니다.

[westship]

세상은 천부적인 소질을 가지고 태어난 소수의 사람들이 이끌어간다고 생각합니다. 그 동안 하늘이님이 걸어왔고 또 앞으로 어떤 길을 택해 걸어갈지 기대가 됩니다. 이를 통해 얻는 지식과 경험을 여러 사람들과 나눠 가지시기를 바랍니다. 지금 이 카페에서 하고 있는 것처럼 말이지요

[하늘이]

참고로..저는 위에 설명된 XP보다는 RUP를 지지하는 입장입니다. (물론 프로젝트마다 달리 적용해야 하는것이 기본이지만) XP를 지지하는 사람들은 개인의 경험과 창조성에 지나치게 얽매이고 있으며 인간의 추상능력을 거의 인정하지 않고 있습니다. 프로그래밍 학습을 위한 좋은 방법은 되겠지만, 개발을 위한 좋은

[하늘이]

방법은 아니라고 생각합니다.

[정준호]

다 맞는 말이고 좋은 말들이지만...특히 XP는 상당히 좋은 방법론이지요. RUP또한 마찬가지구요.다 좋습니다만... 우리나라 현실은 이런 방법론들을 따라가도록 놔두지 않습니다. 대부분의 개발자들은 (최소한 공부를 게을리 하지 않는 사람이라면 ) 이런 방법론들을 압니다.

[정준호]

하지만 현실은 그렇지 못합니다. 특히 우리나라의 경우 말이지요. 고객의 요구사항은 하루가 멀다하고 바뀝니다. 하룻밤 사이에 마케팅이나 영업부에서 있지도 않은 기능 있다고 구라를 쳐서 만들어야 합니다. 설계는 매일매일 바뀌고, 구현은 점점 복잡해집니다.

[정준호]

리펙토링을 하고 싶어도 리펙토링할 시간이 주어지지 않죠. 현실에서는.... 아무리 좋은 방법론이 있어도 무용지물이 되는군요. 저도 XP를 좋아라 합니다. 저 또한 Simplicity is powerful 라고 생각하는 사람이니까요. 하지만...그렇게 하고 싶어도 못하지요.

[정준호]

소프트웨어 공학의 소자도 공부하지 않은 아니 수업은 들었을 지언정 머리속에 남아있지 않은 관리자들은 문서들을 요구해댑니다. ERD, Class list, Use case, class diagram, help document, API까지.. 도대체 저 많은 문서들이 왜 필효한지... 알지도 못한채 요구합니다.

[정준호]

그렇다고해서 프로젝트가 RUP방법론에 의거해서 흘러가느냐. 천만에 만만에 말씀이지요. 문서는 문서대로 요구하고, 설계는 끝나지도 않았고 검증도 하지 않았는데 개발을 시작합니다. 3개월의 기간중 설계에 투자된 시간은 2주나 될까요?

[정준호]

RUP도 XP도 아닌 어중간한 방법이 실제 프로젝트에서는 사용되고 있습니다. 누구나 ( 최소한 제대로된 개발자 라면 ) 하늘이님이 말씀하시는걸 알고 있습니다. 하지만... 아무리 알고있다고 해도 적용할 수가 없죠. 그게 우리나라 현실입니다. 뭐..앞으로도 크게 변하지 않을듯 하군요.

[정준호]

전 설계나 구현을 할 때 최대한 flexible 하게 만듭니다. 손이 조금 더 가고, 조금 더 복잡해지더라도 말이지요. 중간 중간 설계를 바꾸더라도 최대한 손을 덜 대기 위해서 말이지요. 단점도 많습니다. 엔진단은 flexible하고 가볍기도 하지만.. UI단이 상당히 복잡해지지요.

[정준호]

하지만 정말 하루하루 다른 사용자요구와 마케팅엽엉부의 개구라를 감당하기에는 저 방법밖에 없더군요. 자바의 property를 이용해서 많은 처리를 합니다. property를 수정하는 대신 코드를 수정하지 않도록이요. simple하지는 않습니다. property를 다루기 위해서 많은 처리를 해야하고.

[정준호]

일부 class들은 property에 따라서 로드 되는 클래스가 틀리기 떄문에, 명시적으로 선언하지 못하고 class.forname 등을 이용해야하고, 몇몇 클래스들은 정해진 방법대로 만들어야 하고... 간단하지는 않지만... 현실에서 써먹기는 좋더군요.

[정준호]

참고로..하늘이님 전 RUP보다는 XP를 좋아합니다. 하늘이님과는 약간 생각이 다르네요. RUP는... 너무 딱딱하다고나 할까요. 자유가 없습니다. 딱딱한 분위기속에서는 딱딱한 프러덕트밖에 안나옵니다. 자유로움속에서 모든것이 다 나올수 있지만요. 개인의 취향이겠죠....^^;

[westship]

모든 것을 부정적으로만 볼 필요는 없다고 생각합니다. 정준호 님 설명을 들어보니 우리나라 개발자들의 현실적응 능력이 뛰어난 것 같습니다. 당연히 실력도 세계 최고일 것이라고 미루어 짐작이 됩니다. 이들이 해외 시장에서 다양한 마케팅 경험을 갖고 있는 경영자와 한 팀을 이룬다면 세계 시장을 주도할 수 있을 것

[westship]

입니다. 나는 하늘이 정준호님 토론을 들으면서 우리나라 SW업계에 에너지가 넘치고 있음을 느낌니다. 여기에 정교한 개발기법을 도입하면 우리나라에서 개발된 SW의 경쟁력은 세계 최고가 될 것으로 기대합니다.

[겨울느낌]

저의 딜레마는 젊어서 공부 하느냐 일하냐 입니다.ㅡㅜ.

[쭈끄미좋아]

저두 XP하지만 저두 정준호님처럼 property 처리를 하기는 하는데.. 그 property조차 바꿔야 되는 상황이 발생하면 대략 난감하져...

[쭈끄미좋아]

참고로 저는 회사웹만 관리하는데 회사웹사이트 한번 리뉴얼하면 보통 5개월에서 6개월은 걸리네여.. 넘 느리져?

[하늘이]

XP는 요구사항이 지속적으로 변경될때 적합한 방법론입니다. 때문에 요구사항이 변경되기 때문에 XP를 사용하지 못하겠다고 하는건 핑계에 불과합니다. TDD+리팩토링은 언제 시간을 내서 따로 하는게 아니라 그냥 개발을 그렇게 진행하는겁니다.

[하늘이]

다만 현실상의 문제라면 XP를 제대로 이해하고 있는 사람이 별로 없다는것 또 XP와 같은것을 도입할 의지가 없다는것과 회사에서 요구하는것은 문서위주의 결과물일때가 많다는점이죠.