[SAVEAS]
XLSWideStrings=1

1. 뉴비 : 막 졸업했거나 학원수료. "취업좀.."

   • "이바닥은 학력보다는 실력이다" 라는 이상한 믿음. "어떤게 전망이 좋나요?"가 늘 궁금하다.
   • 자바는 Copy & Pastes 하니깐 쉽다. 자바스크립트는 어렵다.

2. 개초보 : 1년 정도 경험. 템플릿 주면 대충 알아서 만드는 단계. 프레임웍을 이해하고 다루는데는 미숙.

   • 중수랑 하는게 비슷한데 연봉은 적다고 불만임. 프리랜서 하고싶음. 도메인 업무보다는 코딩테크닉을 하고싶어함.
   • 내 꿈은 아키텍쳐. 현재 진로방향은 막연히 DBA.

3. 초수 : 프레임웍에 대한 의문과 회의가 들기 시작함. 간단한걸 왜 복잡하게 돌려 하는지 모르겠음. 디자인 패턴은 다 개소리임.

   • "이바닥 별거 없는데.. 거품이 너무 많다." , "웹은 SQL이 절반 이상이다." 현재 회사에 불만가득.
   • 고만고만한데서 실력있다는 소리를 자주 듣는다. (이때는 잘 모른다. 이게 작업용 멘트라는것을..)
   • SQL에는 자신있는 단계. 어떤 복잡한 SQL도 업무만 안다면 작성 및 튜닝 가능.

4. 중수1단계 : 고수/또는 체계화된 플젝의 도움을 받아 프레임웍의 진가를 알게됨. 오픈소스를 효율적으로 사용. 

   • 자신감이 넘침. 신기술 사용에 적극적. 프레임웍에 서툴거나 자신과 생각/사상이 다르면 까기 시작함. 적극적인 블로깅/자기PR
   • 현재의 프로세스에 문제가 있다고 판단 => 고칠 수 있고 고치려는 의지가 있음.
   • 익명 클래스와 command패턴, 클로저 등이 자연스러워지고 새로운 프레임웍이 나와도 금방 적응 가능.

5. 중수2단계 : 나는 팀의 리더.  아무리 잘나봐야 똑같은 대우라는걸 알게됨. 의욕상실. 기존 개발자들의 반발. 현실은 시궁창.

   • 드림팀을 꾸리고 싶음. PM을 해야할거같은 상부의 압박. 결국 사람이 가장 어렵다는걸 깨닳음.
   • 현재의 프로세스에 문제가 있다고 판단한지 오래지만 어쩔 수 없다고 생각. "기술 보다는 영어좀 해둘껄" 하는 생각이 간절함. 책 내고 싶음.
   • 코딩과 프로세스를 도와주는 각종 Tool에 관해 능숙함. 중/소규모 실제 프로젝트에 적용 가능한 아키텍쳐 구성 가능 및 가능한 지위

6. 중수3단계 : 프로젝트 내의 기술적 우위로 팀/회사에서의 확고한 지위.

   • 솔로플레이에 능함. 기술의 도입으로 내가 가지는 득실을 중요히 생각하게 됨. 손해보는 짓은 안함.
   • ORM에 익숙하고 거기에 따른 설계 가능. 그루비나 루비 같은 동적 객체지향 언어로 매니악한 코드 만드는것을 즐김.

7. 고수 : 프리랜서로 전환. 생산성에 치중함. 유지보스는 안드로메다.

   • 너무 잘하지도, 못하지도 않는 중용을 발휘함. 별로 하는거 없어보여도 절대로 뺄수 없는 그런 존재.
   • "만 라인의 코드를 작성하는 이와, 일의 공허함을 깨닫고 코딩 없이 성과를 얻는 이중에서 누가 보다 유닉스 같은가?" by 에릭 레이몬드.
   • 플젝을 떠돌며 모아놓은 jar와 모듈들이 가득함. 손수 짜는거 보다 import하는게 익숙함. 오픈소스를 수정/확장해서 사용하는데 능숙.

8. 신 : 다 무의미 하다는걸 깨달음. 따르는 자가 있지만 정치를 하기 싫어서 물좋은 SM자리 하나 얻어서 남은 여생을 운둔하며 보냄.

   • "마음이 가는데로 코딩을 했는데도 리팩토링할 곳이 없더라"

1. 출처 - okJsp
2. 첫째는 '열심히 하지만 결과를 쓸 수 었을 때'입니다. 2~3주 하루 12시간씩 작업한 결과물이 아무리 좋게 보아도 변수명 바꾼 것에 불과한 듯이 보이는 상황을 대하게 되면 화를 내야하는지 그냥 포기하고 혼자 끙끙거리며 모르게 다시 만들어야 하는지 간간 깊은 고민에 빠집니다. 불행하게도 저는 마음 크기가 종지만해 화를 내는 쪽이긴 합니다만, 그나마 화를 내어 놓고도 일정 때문에 제가 손을 보곤 합니다.
3. 둘째는 '자부심은 강하지만 결과과 이상할 때'입니다. 스킬에 대한 중요성, 관련 경험, 학습 내용 들에 대한 자긍심이 굉장한데 비하여, 내어놓은 결과물은 예를들면 1줄짜리 쿼리를 10줄로 만들어둔데다 원하는 결과도 도출되지 않는 상황인 경우입니다. 함부로 의사를 전하면 크게 상심할까봐 참 대응하기 곤란하더군요.
4. 셋째는 '하고 싶은 것만 한다'입니다. 박식한데다 경험도 풍부하지만, 하고 싶은 파트가 아니면 절대 하지 않으려는 경우로 몇명만이 단촐하게 일할 때는 여간 고로운게 아닙니다. 명확히 하자면 성격 또는 게으름의 문제이겠으나, 결과적으로는 능력을 보여주지를 못하니...
5. 넷째는 '논리 결여'입니다. 재미있는 것은 이런 부류의 이들이 상대적으로 사회성도 뛰어나고 자기 자신에 대한 투자에 게으르지 않다는 것입니다. 충분한 학력과 현장 경험에도 불구하고 C & P에만 능숙해져 있는 것을 보면 차라리 다른 쪽으로 방향을 돌려보는 것도 좋지 않은지 권해주고 싶습니다.
6. 다섯째는 '레퍼런스를 찾기 능력 결여'입니다. 농담반 진담반으로 '내 실력의 절반은 네이버와 구글이 키웠다'라고 말해도 허하게 들리지 않을 정도로 레퍼런스로 넘쳐나는 요즘임에도 불구하고 막히면 막히는 족족 포기해버리고 다른 이들의 도움을 찾는 경우로, 심하게 표현해 '귀찮다'라는 생각이 자꾸 떠오르게 됩니다.
7. 여섯번째로 '할 수 없다고 말하기 싫어하는 자존심'입니다. 무능함과 '할수 없음'은 다르다고 생각하고, 대부분의 이들이 순수하게 현황을 이야기하면 함께 고민해보고 격려함에도 불구하고, 아무리 급박한 상황이라도 '못한다'라는 말을 꺼내지 않은체 폭발 직전까지 끌고가는 경우를 대하곤 합니다.
8. 일곱번째로 '내일만 커보인다' 부류입니다. 남의 일은 쉬워보인다던가 하는 1차원적인 것이라면 차라리 귀여운데, 프로덕트 전체를 보지 않으려고 하며 오만해하는 경우에는 답이 없습니다. 특히나 아집이 강한 이들이 이러하다면... 전 '실력으로 눌러야한다'라는 생각으로(제가 실력이 있다는 말은 아닙니다. 허허~) 멀쩡한 척 하면서 밤세워 작업한 뒤 보여주며 '쉽던데~'라고 말하는 부류이지만, 결과적으로 이런 이들과 충돌하게 되면 나중에 다시 보지 않게 될 확률이 현재까지는 100% 더군요.
9. 마지막으로... 위의 일부 또는 전부를 갖춘데다 '시간 투자'로 모든 것을 판단하려는 부류입니다. 결과를 도출하였다는 사실이 아닌 아주 간단히 수치화할 수 있는 시간을 얼마나 소요했는가로 판단하는 부류이지요. 이런이들이 아래 사람이라면 '나만 일한다'는 불만을 들어야하고, 윗사람이라면 '너는 왜 노냐?'라는 지적을 감수해야하며, 중간 관리자라면 '잘 가르쳐봐'라는 업무와는 전혀 무관한 교관 노릇을 감수 해야합니다.

1. 출처 : http://erwins.springnote.com/pages/2880322
   

2. 처음 책 보고 썼을땐 멋있어 보였는데 나중에 보니까 이게 웬 헛소리.. ㅠㅠ

3. 개요

   1. 소프트웨어 공학에 무수한 개발 방법론이 있고 다양한 산출물이 있지만 이미 실제 개발자에게는 무시된 지 오래이다. 개발자에게 방법론을 거론해봐야 무시당하기 쉽다.
   2. 비단 한국에 국한된 일뿐만이 아니다.  소프트웨어로 가장 유명한 기업인 MS에서조차 예외는 아니다. 거대한 산출물을 쌓아서 창고에 처박아버리고 다시는 보지 않는 사태는 전 세계 에서 일어나고 있다.
   3. 혹시 당신의 회사가 "비주얼 어쩌구 아키텍트" 라고 불리는 거창한 소프트웨어 방법론 환경을 구상 한다 던지 UML과 XP사이에서 갈팡질팡 하고 있다면 이미 문제에 봉착해 있을 확률이 높다.
   4. 유명한 스타 개발자 조엘은 자신의 책에서 화성인 아키텍트를 이야기 한다. 화성인 아키텍트가 화성에서나 가능한 플랜을 지구로 가져오지 않는 것이 개발자를 돕는 것이다.
   5. 이 바닥에서 4년이면 자신이 알고 있는 지식의 50%를 갱신해야 한다고 한다. 이로 인해 소프트웨어 엔지니어링과 현실간의 갭은 점점 더 멀어져 다른 나라 이야기 인 듯 들린다.
   6. 왜 이런 현상이 일어나는 것일까?

4. 기초를 알자 : 2가지 개발 방법론의 종류

   1. 개발 방법론

      1. 방법론 자체가 이미 너무나 오래된 생각이다. 개발자들 사이에서 방법론은 조롱거리가 된지 오래이며 심지어 방법론 무용론을 주장하는 사람들도 있다.

      2. 특히나 SI시장의 대부분을 차지하는 웹 개발은 그 특수성 때문에 설계 자체가 필요 없다는 주장도 많다.

      3. 대부분의 개발 방법론은 박사 학위, 또는 논문을 위해 경험 없는 대학원생이나 교수에 의해서 만들어 진다.

      4. 방법론 공학 연구 커뮤니티에서 조사한 결과 방밥론을 그대로 실무에 적용하는 실무자는 거의 없음이 밝혀졌다. (By 소프트웨어 공학의 사실과 오해:인사이트).  그리고 지금도 방법론은 만들어지고  있다.

   2. 개발 방법론을 분류하는 것은 개인의 판단마다 다르다. 공신력을 위해서 가장 권위 있는 ant(By apache재단) committer의 말을 인용한다.

      ant자체가 XP와 밀접한 관계가 있는지라 약간의 편향된 의견일수도 있다.  XP와 RUP는 가장 널리 알려진 방법론으로 그 외의 방법론들은 이것의 변형이라 할 수 있다.

      또한 이 둘은 구체적인 방법과 도구를 제시한다. 따라서 이들 두 가지 방법론을 알아본다.

      1. Rational Unified Process(RUP)

         1. Rational Software Corporation에서 만들었다. Rational Rose의 제작사이다. (현재는 IBM에 합병)
         2. UP가 방법론이며 RUP는 그것을 상품화한 Rational사의 상품이다. 이것으로 1998년도에 난립해있던 컨설팅 회사들를 평정할 수 있었다.
         3. 핵심 키워드는 “설계”이다. 반복적이며 관점적(Perspective)이고 아키텍쳐 중심적인 프로세스 모델로서,
            이 모델에서 소스코드란 프로젝트의 이터레이션(iteration)을 통해 생성되는 산툴물의 하나에 불과하다.
         4. 아이러니 하게도 원 설계자는 그래디 부치는 패턴 도입에도 공한을 한 객체지향 공학의 권위자 이다. 그는 GOF의 디자인 패턴의 서문을 썼으며 애자일 연합체의 설립 멤버이기도 하다.
            (이는 RUP와는 대조적인 성격의 것으로 RUP의 근본적인 문제점을 공격했다.)
         5. 설계 기간을 길게 잡은 후 개발에 들어간다. 모토는 뼈대를 잡은 후 살을 붙이자는 것이다. 개념화->구체화->구축->전이 등의 이터레이션 반복으로 설계가 완료되면 신속한 개발이 가능하나 추후 수정 사항 발생시 대처가 곤란하다. 개발 완료시까지 배치기 지연된다.
         6. 핵심은 UML 등의 문서이다. 쉽 고, 표준화되고 언어에 상관없이 모든 개발 프로세스를 정형화할 수 있는 UML은 각 개발자와 사용자, 고객과의 통신 수단이 되며 중요한 산출물 중의 하나이다. UML을 이용해 개발을 모르는 관리자도 검수가 가능하며 개발자들 간의 의견 소통을 돕고 오해를 미연에 방지한다.
         7. 테일러링을 통해 프로젝트에 적합한 방법론을 구현할 수 있다. XP방법론도 이 입장에서 보면 RUP를 소규모 프로젝트에 적합하게 리테일러링 한 것에 불과하다.
         8. 소스코드는 이러한 UML을 특정 형태(자바, C#등)에 맞추어 서술한 것에 불과하다. UML은 객체 지향을 표현하는 표준 언어이기 때문에 이을 이용해 어느 언어로든지 단기간에 전이가 가능하다. 이상적이지 않은가? 더 이상 말 안듣는 프로그래머는 필요 없다. 코더와 설계자만 있으면 된다!
         9. XP는 산출믈을 만들기 싫어하는 개발자들의 핑계에 불과하다. 작인 Iteration으로 나누어 개발하는 애자일 기법은 나무만 보고 숲을 보지 못하는 우를 범할 가능성이 크다.

      2. eXtream Programing(XP) (1999 XP explained)

         1. XP란 eXtream Programing의 약자로 “가장 단순한 것이 가장 좋은 것이다.“를 모토로 한다.
         2. 창시자인 켄트벡은 짝프로그래밍, TDD(테스트주도개발), 디자인패턴, 리랙토링 등을 대중화 시킨 가장 유명한 프로그래머들 중 하나이다. (이미 열렬한 신봉자들의 교주가 되어버렸다.)
         3. 핵심 키워드는 “코드진화”이다. XP는 최초의 요구사항이 후반에 반드시 바뀔 것을 당연시한다. 이를 위해 변화에 따른 비용 그래프의 증가 곡선을 평평하게 프로그램을 유지한다. 즉 개발 후반부에 기능을 추가하는 것이 초반에 추가하는 것과 크게 다르지 않다.
         4. 전통적인 폭포수 개발형태를 접한 사람이라면 이런 것이 가능할지 의문이 들것이다. XP는 자체문서화, 리팩토링, 자동화 도구(Ant등), 단위테스트(JUnit) 등으로 이것을 가능하게 한다. 이는 모두 IDE와 프로그래밍 기술의 발달로 가능해진 것이다.
         5. 자체 문서화(따로 문서를 만들지 않고 소스 자체를 문서화한다), 프로그래밍 패턴을 통해 빠른 설계가 가능하다. 설계는 필요이상 하지 않는다. 이후 지속적인 리팩토링을 거치기 때문에  개발후반 수정사항이 생기더라도 개발 초반과 동일한 수정 기간만이 필요하다.
         6. 소스코드 차제가 문서이자 산출물이며 개발자의 개발 의도를 표현해준다.
         7. 개발자와 설계자가 달라서 생기는 엄청난 비극을 미연에 방지해준다. 즉 책임의 소재가 명백하다.
         8. 초기에 10인 이하의 프로젝트용으로 평가받았으나 기술의 발달로 RUP를 빠르게 대체해가고 있다.

5. 문서화 / UML의 문제점

   1. IDE 의 발달로 개발은 점차 자동화 되어가도 있지만 문서는 그렇지 않다. 즉 성과에 비해 시간이 너무 많이 걸린다. 이를 극복하기 위해 리버스 엔지니어링 이라는 편법이 동원된다. 물론 이 짓은 산출물을 위해 보여주기 위한 종이문서를 생산하기 위한 것으로 본래의 취지와는 안드로메다로 떨어지게 된다 무엇을 위한 산출물일까? 가능하다면 더 이상 책상위에 문서가 있어서는 안 된다. Trac, JIRA 등의 걸출한 이슈트래커가가 있음에도 엑셀을 사용하는 것은 왜일까? 답은 당신이 사용할 줄 몰라서 이다.

   2. 개발자가 보기에 문서보다는 IDE의 지원을 받는 소스가 이해하기 편하다.  개발자를 위한 문서란 대부분의 경우 있을 수 없다. 전달 매체가 책이라면 클래스 다이어그램의 압승이다. 하지만 PC를 사용 가능하다면 실제 코드를 이클립스로 보는 게 훨씬 쉽고 정확하다.

      MSDN을 생각하자. MS는 소스를 오픈하지 않았기 때문에 MSDN이라는 거대하고 복잡한 매뉴얼을 만들 수 밖에 없었다. 이렇게 거대한 매뉴얼을 만들었지만 아직도 개발자들의 불만은 끊이지 않고 있다. 소스 10장을 문서화하고 모든 예외상황을 기술하려면 100장도 모자란다.

   3. 실제 정상적인 작업에서는 refactoring작업이 빈번히 일어난다. 밥을 먹다가도 더 좋은 메소드 이름이 생각나면 하루에도 '몇 번씩 수정을 하는 일이 비일비재 하다. 사용자가 보기에 거창한 수정이라도 IDE 또는 프레임워크의 도움으로 간단히 끝나는 경우가 많다. 이들은 IDE가 자동으로 하지만 문서는 손으로 고쳐야 한다. 일이 일을 만든다. 소스 1시간 고치고 이를 위해 4개의 문서를 수정해야 한다면 당신은 하겠는가? 원시시대로 돌아갈 생각인가?
   4. 한번 에 좋은 설계를 하는 것은 불가능하다. UML 모델링으로 설계를 수정 하는 것 보다 refactoring으로 소스를 직접 수정 하는 것이 더 빠르고 쉽고 안전하다. IDE는 오타를 내지 않는다.
   5. 소스로 UML을 만들어 내는 것은 쉽지만 UML로 소스를 만드는 것은 매우 어렵다. (자동화 도구의 부재이다.) UML작성 후 소스코드 작성이라는 이중 작업을 수행해야 한다.

6. RUP의 문제점

   1. 최근의 대세는 XP이며 특히나 문서에 취약한 반면 툴 사용에 능숙한 개발자는 대부분 XP를 선호한다. (개발자가 아닌 사람은 대부분 RUP를 선호하는듯..) 나역시 XP를 선호하니 RUP의 약점을 공격해 보겠다.
   2. RUP의 중요 원리중 “문서 작업을 최소화 하라”, “유연하라” 등이 있다. 하지만 공룡과도 같은 이 기법은 이를 무색하게 만든다.
   3. 앞의 RUP태생을 말했던가? 이는 다분히 상업적인 전략이며 이 방법론의 주 임무는 다음과 같았다. 첫째 관련된 CASE툴의 판매, 둘째 컨설팅 시장을 장악하는것.
   4. 완벽한 요구사항 도출로 후반 수정사항을 없애겠다는 RUP의 시도는 실패로 끝났다. 이는 한국만의 문제점이 아니다. 갑에게는 완벽했던 요구사항을 한방에 뒤집기란 손바닥 뒤집듯 쉬운 일이다. 무수한 수정으로 문서의 존재 이유가 떨어진다. 문서의 업데이트에 너무 많은 시간이 소요된다. 문서의 정확도 역시 떨어진다. 이로 인해 만들어놓은 문서를 보지 않게 된다.
   5. refactoring의 발달로 설계의 중요성이 예전만큼 중요하지는 않다. 시간이야 좀 걸리겠지만 테스트만 잘 작성되어 있다면 개발 후반에도 얼마든지 수정이 가능하다. 썩은 기둥을 안고 가는 것 보다는 현명한 판단이 될 것이다.
   6. 산출물을 작성해도 그것을 읽을 줄 아는 고객은 전무하다. UML은 생각보다는 쉽지 않다. 간단하게 표현하는 데는 여전히 효율적이지만 조금만 세부적으로 들어간다면 다이어그램이 복잡해지고 알아보기 힘들게 된다.
   7. RUP에 의하면 소스는 단순히 개발 과정의 산출물일 뿐이다.  RUP를 기반으로 한 산출물(보통 UML)만 있다면 어떠한 개발언어로든지 변경이 가능하다. 즉 설계자가 설계만 잘하면 단순 코더들이 이 설계(산출물)를 토대로 소스를 뽑아낸다는 말이다. 여기서 박사급 설계자는 고급 인력이고 실제 개발자들은 단순 코더화 된다. 개발자들이 이러한 프로세스를 좋아할리 없다. ORM을 모르는 DBA와 개발을 많이 접해보지 못한, 2~3년 전의 옛날 책으로 공부한 고급 설계자들은 시대에 뒤떨어진 엉뚱한 설계를 내어놓는다. 팀내의 불화가 생기고 프로젝트는 위기로 향한다. 이 UML을 가지고 소스를 코딩하라고요? 농담이시겠죠?
   8. 설계자와 코더가 동일한 사람이 아니라면 이는 문제 발생의 소지가 커진다. 무책임한 셜계가 나오고 설계가 아무런 쓸모 없어질 가능성이 매우 크다.
   9. ORM 등의 각종 프레임워크와 미들웨어, JUnit, SVN, ANT등의 자동화된 도구를 사용할 줄 모르는 사람도 설계를 한다. 이들은 설계에 지대한 영항을 미치는 것들로 설계자가 이를 모른다면 엄청난 비극을 불러올 것이다. 물론 이 비극은 전세계에서 매일 일어나고 있다.

   10. 웹 중심 개발로 인한 설계의 모순  ?? 잘 모르겠음.

       1. 현재 대부분의 SI는 엔터프라이즈(클라이언트-서버-DB를 all-in-one으로 개발하는것) 개발이다. 그리고 엔터프라이즈의 대부분은 웹개발이다. 웹개발은 서버프로그램 , 클라이언트 프로그램으로 나뉜다. 리치 클라이언트와 Ajax등의 기술이 유행하면서 클라이언트 프로그램의 중요성이 점점 더 커지고 있다.

       2. 하지만 위에서 말한 개발방법론은 모두 객체지향 프로그래밍에 해당하는 것으로 클라이언트 프로그래밍에 사용되는 스크립트 언어에는 해당되지 않는다.

       3. 산출물에서 클라이언트 스크립트 언어에 관한 자료를 찾아 불 수 있는가? 즉 당신이 보는 문서는 반쪽짜리이다.

       4. 텍스트 기반인 스크립트 언어는 특성상 구조적으로 배치가 가능하면서도 설계가 자유롭고 변형이 쉽기 때문에 문서를 남기는 것이 매우 힘들다. 이 다이나믹한 언어들은 심지어 런타임으로 평션(자바로 따지자면 class)의 수정마저 가능하다. 이는 RUP에서는 받아들이기 힘든 체제이다. 소스 그 자체를 문서로 보고 지서속적인 리팩토링을 하는 것만이 대안일 것이다.

7. 한국에 특화된 문제점

   1. 완벽한 인원과 충분한 기간, 그리고 환상적인 고객과 개발 금액이 조화를 이룰 때 RUP방법론이 성공할 수 있다.

      1. 하지만 하도급이 보편화된 한국에서 그럴 일은 없다. 한국에서 실제 프로젝트 금액의 몇%가 실제 개발비로 사용될까? 한번 생각해 보라.

      2. 흔히 빅3로 불리는 대기업과 발주기업의 유착관계는 실제 투입비용을 절반 이하로 떨어트려서 SI산업의 하향평준화에 큰 공을 세웠다.

   2. RUP가 적용 가능한 대형 프로젝트의 경우 단일 업체에서 체계적인 프로젝트 진행이 가능한 경우는 없다. 대부분 끊임없는 하도로 이어져 을 업체마저 어디까지 하도가 되었는지 관리가 거의 불가능하다.

   3. 명확한 정의가 없다. 화려한 미사어구로 표현했지만 정작 읽어보면 애매모호하거나 다의성을 지닌다. 이는 공학에서 금기시해야 하는 원칙이지만 소프트웨어 공학에서 만큼은 당연하리만큼 통용된다. 공학이지만 코드도, 수학도, 과학도 없다. 단지 말뿐이다.  끔찍하다.

   4. 제안서 기술평가 항목에 방법론은 들어가지만 실제 소프트웨어의 질을 결정하는 사항들은 빠져있다. 방법론에 거창한 것이 들어가 있지 않으면 점수를 받기 힘들다. 한국에서 XP방법론은 요원한 것이다. 이것은 제도의 문제일 것이다.

8. 결론

   1. 이미 컴포넌트의 재사용, RUP, CBD식의 방법론 같은 것들은 실패한 것으로 대부분 판명되었으다. 시대에 뒤떨어진 이러한 문제를 생각하느라 시간을 허비하지 말자.

   2. 재사용에 관한 훌륭한 대안으로 “디자인 패턴”을 공부하라. 이는 유일하게 실무에서 나온 이론으로 개발자들의 열렬한 환호를 받고 있다.

   3. 당장 아무것도 도움이 안되는, 개 풀뜯어 먹는 소리만 해대는 소프트웨어 공학을 잊어라. 그리고 수십년 간의 프로그래밍 노하우와 연구들, 이론들이 집대성된 ANT, SVN, OSGi, Maven, Trac같은 도구들을 공부하고 사용하라. 앞서 고생한 선배들의 가르침이 담겨 있을 것이다.

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

우리가 가장 중요하게 여기는 것은

제 시간에, 지속적으로 가치 있는 소프트웨어를 인도함으로