The Art of Project Management

[공지사항] 소프트웨어 크리에이티비티 2.0 정보

2007-11-25T20:27:00.000+09:00

이 블로그를 RSS로 구독하고 계신 많은 독자 여러분의 성원에 보답하기 위해 소프트웨어 컨플릭트 2.0의 후속편인 소프트웨어 크리에이티비티 2.0을 준비하고 있습니다. 해커라면 반드시 읽고 넘어갈 필독서 10선에 들어가기도 했던 소프트웨어 크리에이티비티는 1판이 절판되고 나서 한 때 아마존에서 999불까지 중고 서적 가격이 책정되기도 하는 등 여러 가지 흥미로운 이야기거리를 불러 일으켰습니다. 독자들의 열화와 같은 성원에 힘입어 로버트 L. 글래스가 새롭게 글을 추가한 버전 2.0이 작년 이 무렵에 출간되었는데, 출판사인 developer.*의 사정으로 인해 라이선스를 해결하지 못해 차일피일 번역 작업이 미뤄지다가 로버트 L. 글래스와 직접 계약을 맺고 d.*와도 다시 연락이 재게되면서 한국어판으로 여러분 앞에 선을 보일 수 있게 되었습니다.

번역 작업이 진행되는 동안 이 블로그는 한시적으로 운영이 중지됩니다. 번역 작업이 끝나고 책이 출간될 무렵에 여러분을 찾아뵐 계획입니다. 다시 한번 독자 여러분의 성원에 감사드리며, "I'll be back!"

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 공동 역자 박재호 이해영 올림

[6부 3번 수필] 소프트웨어 실패: 왜 실패할까?

2007-11-06T06:31:00.000+09:00

이번에 '초난감 기업의 조건'을 번역하면서 느낀 바지만, 소프트웨어 쪽 실패를 탐구해서 교훈을 찾으려는 시도는 무척 중요하다. 실수하지 않고서는 성장할 수 없듯이, 소프트웨어 분야에서도 실패를 하지 않고서는 제대로 커나가지 못하지만 요즘 세상에서 실패는 댓가가 너무나 혹독하기 때문이다.

로버트 L. 글래스 큰 형님은 소프트웨어가 실패하는 원인을 크게 다음과 같은 세 가지로 나눈다.

예측에 대한 무능: 걸음마 단계에 불과한 소프트웨어 분야를 아직 제대로 이해하지 못하기 때문에 생기는 현상으로, 어디에 얼마를 투입하고 어느 정도 기간이 걸리는지 소프트웨어 프로세스를 파악해야 해결이 가능하다. 예측을 '관리'하려는 노력 자체도 무척 가상한데, 서서히 '예산을 초과하고 일정보다 늦어진 프로젝트'는 버그 제거에 반드시 필요한 테스트 프로세스를 건너 뛰면서 '예산을 초과하고 일정보다 늦어진데다 불안정하기까지 한 프로젝트'로 변한다. 요구 사항 수집 단계 직전이나 도중에 예측을 한 다음에 이를 100% 고수하는 행위는 문제를 제대로 파악하지 못한 상황에서 어림짐작으로 값을 뽑아내어 여기에 목을 매달기 때문에 상황을 더욱 악화시킨다.
불안정한 요구 사항: 좋은 사람이 되려다보니 고객이나 사용자가 원하는 변경 사항을 거절하지 못하고 받아들인 결과 설계 프로세스를 빗나가게 만들고 일정을 엉망 진창으로 만들어버린다. 문제 본질이 계속 바뀌는 상황에서 문제를 해결할 수 없는 사람은 없지만, 우리들은 소프트웨어가 부드럽다는 사실을 증명하기 위해 오늘도 부나비가 되어 불에 뛰어든다. 로버트 L. 글래스 큰형님은 이런 현실을 한탄하는 대신에 결국 소프트웨어 유지 보수 기간동안에 벌인 변경 작업을 통해 최고의 돈벌이를 해야 한다고 주장한다.
일시적 유행과 오해: 은총알 논문이 나온 이후에도 여전히 소프트웨어 위기를 극복할 획기적인 기술이 있다고 떠들어대는 사람이 있기 마련이다. 로버트 L. 글래스 큰형님 이야기에 따르면 전산 분야처럼 급변하는 환경에서 현실을 말하는 사람보다 비현실적이더라도 최신 기술을 떠벌이고 다니는 사람에게 좀더 큰 보상이 돌아가는 듯이 보이기 때문에 이런 사이비 약장수들이 설칠 수 있다고 한다. '일시적 유행과 오해'를 부추기는 사람들은 연구원들, 장사꾼들, 유행에 목매는 관리자들이 있으며, 새로운 기술에 흥미를 보인다는 사실을 제외하고 공통점은 없다.

그리고 다음과 같은 해법을 제시한다.

향후 예측을 개선할 자료 수집
예측 프로세서를 분석해서 점진적인 예측이 다른 분야에서 사용하는 접근 방식과 유사하게 현실을 더욱 제대로 반영하는지 확인
고객은 자신이 바라는 요구 사항 변화에 현실적인 비용을 지불한다
연구자들과 장사꾼들이 내건 약속을 믿다가 뜨거운 맛을 보았던 관리자에게 더 나은 지혜가 있다고 설득
실무자들이 유행과 오해를 무작정 쫓아서 협곡으로 빠지기 전에 이를 실험적으로 검증할 국립 소프트웨어 실험 연구소 설립

역시 최종적인 결론은 '은총알은 없다'로 판명이 난다. 가장 심각한 문제가 무엇인지 알기만 해도 이런 함정에 빠지지 않을텐데...

'소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 역자 박재호 올림

[6부 2번 수필] '문제 해결'에 대한 당연한/기발한 생각

2007-10-19T06:20:00.000+09:00

소프트웨어 개발의 본질은 무엇일까? 자료 처리? 전자 계산? 기술 집약적인 첨단 산업? 3D 업종? 로버트 L. 글래스 큰 형님은 소프트웨어 개발의 본질은 '문제 해결'이라고 주장한다. 너무나도 당연한 이야기이다. 그렇다면 문제를 해결하기 위해 어떤 과정을 밟을까?

문제를 정의한다
해결책을 구현한다
해결책을 점검한다
필요하다면 해결책을 지속해서 동작하게 만든다

그런데 상기 문제 해결 방식에 데자뷰가 느껴지지 않는가? 바로 우리가 악의 축(?)으로 생각하고 있던 (폭포수형) '소프트웨어 생명 주기'와 정확하게 일치한다. 그다지 놀랍지도 않는 이유는 '생명 주기'가 문제 해결에 일반적인 접근 방법이기 때문이다.

로버트 L 글래스 큰 형님은 소프트웨어 생명 주기와 관련해서 두 가지 문제점을 지적한다.

소프트웨어 업계 종사자들은 어느 생명 주기를 사용할지를 놓고 논쟁하느라 상당한 시간을 낭비한다. 여기서 모순은 생명 주기가 일반화한 방법이며 소프트웨어 개발 부문의 독창적인 개념이 아니라는 사실이다. 오랜 기간 동안 쌓여온 일반적인 문제 해결 방법을 거부하는 배짱도 종종 볼 수 있는데, 소프트웨어 분야에서는 용감한(?) 사람이 종종 눈에 띄는 모양이다.
스펙트럼의 반대쪽에 있는 또 다른 일부 용감한(?) 소프트웨어 업계 종사자는 생명 주기 개념을 전혀 이해하지 못한다. 생명 주기는 일단 '발견하고' 나면 절대불변의 신성 불가침의 규칙 집합이자, 소프트웨어 제작 과정에서 반드시 사용해야 하는 공정이자 한치도 어김없이 순서와 방법을 따라야 하는 신성 불가침한 무엇으로 신봉한다. 요구 사항을 확정하기 전에는 설계를 시작하지 못하며, 설계를 끝내기 전에는 구현을 시작하지 못하며, 구현을 끝내기 전에는 테스트를 시작하지 못한다.

생명 주기를 맹신하는 경직된 관점을 버려야 한다. 어느 누구도 문제 해결 단계를 특정 순서에 맞춰 따라해야 한다고 주장하지 않았지만, 소프트웨어 업계 종사자들은 이런 황당한 생각을 어디선가 접한 모양이다. 결론: '소프트웨어 개발'은 결국 '문제 해결'이므로 문제를 푸는 방법론에서 좀더 자유로워지자.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 공동 역자 박재호 올림

[6부 1번 수필] 전산학이 진짜 과학이 되며, 소프트웨어 공학이 진짜 공학이 되려면

2007-10-03T06:30:00.000+09:00

전산학과 소프트웨어 공학이 일반 과학과 공학 부문에 비해 미묘한 차이점이 있다는 사실은 전산학도나 소프트웨어 공학도라면 누구나 한번씩 생각을 해보았을 것이다. 어떤 사람은 전산학과 소프트웨어 공학의 연륜이 짧기 때문에 아직 미성숙한 결과라고 이야기하고, 어떤 사람은 전산학과 소프트웨어 공학이 사람 생각을 잡아서 이를 강력한 논리적 도구인 컴퓨터를 사용해서 구현해야 하기 때문에 복잡성이 높기 때문이라고도 설명한다.

그렇다면 로버트 L. 글래스 큰 형님께서는 여기에 대해 어떻게 생각하고 있을까? 다음과 같은 의견을 피력한다.

전산학이라는 과학과 소프트웨어 공학이라는 공학에는 탄탄한 실험에 기반하는 성향이 결여되어 있다.

사람 목숨이 달린 새로운 의약품, 신형 항공기, 차 세대 원자력 발전소 플랫폼에 들어가는 새로운 기술이 개발되었을 때 적용에 앞서 충분한 실험과 검토를 거치지만 소프트웨어 신기술이 등장하면 개발자들이 벌떼처럼 달려들어서 오래된 지식을 몰아내고 새 지식을 여과없이 현업에 적용하니 글래스 큰 형님가 지적한 '실험 부족'이 만연해있다고 보면 틀림없겠다. 심지어 데이비드 파나스는 전산학 수준을 '민간 신앙'에 빗대어 비아냥거릴 정도니 사태는 훨씬 더 심각하다.

그렇다면 글래스 큰 형님의 해법은? 필요한 자원을 확보한 누군가 소프트웨어 구매자 보고서(Software Consumer Report)와 같은 자료를 내놓아 실험에 기반해서 신 기술을 평가하여 생산성 향상이 어느 정도 높아지는지 객관적인 증거를 내놓으면 된다고 말한다. 여기서 문제는? 필요한 자원을 확보한 누군가(?)는 다른 엉뚱한 사고만 치고 있다는 사실이다. 전산학이 진짜 과학이 되며, 소프트웨어 공학이 진짜 공학이 되려면 여전히 목적지가 한참 남았다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 공동 역자 박재호 올림

[4부 3번 수필] 생산성과 G 이론

2007-09-19T08:45:00.000+09:00

소프트웨어 부문에서 생산성을 놓고 이런저런 말이 정말 많다. SI 업체의 횡포부터 시작해서 야근에 이르기까지 여러 가지 이야기가 나오고 있는데, 로버트 L. 글래스 큰 형님은 여기에 대해 어떻게 생각하고 있을까? G 이론이라는 아주 흥미로운 이론을 소개할테니 읽고 즐기기 바란다.

이론 G는 다음 세 가지 요소로 이뤄진다.

하위 이론 G11: 대립 관계를 기반으로 하는 시스템은 커다란 타협이 거의 불가능하다.
하위 이론 G12: 미국 노동 시스템은 노동-관리라는 대립 관계를 기반으로 한다.
하위 이론 G13: 괄목할만한 생산성 향상은 커다란 타협을 전제로 한다.

여기에 따른 결론:

이론 G1: 현 미국 노동 시스템에서 괄목할만한 생산성 향상은 거의 불가능하다
이론 G1 증명: 영국 시스템을 보라. 노동과 관리가 거의 교착 상태이다. 영국의 생산성은 침체되어 있다. 증명 끝.
이론 G21: 노동-관리 대립이 명확하게 정의되지 않은 시스템에서는 생산성 향상이 아직 가능하다
하위 이론 G22: 전산은 새로운 분야라서 아직 노동-관리 대립 관계가 제대로 형성되지 않았다

다시 이에 대한 결론:

이론 G2: 컴퓨터 개발 또는 컴퓨터 사용과 관련된 생산성이 향상될 가능성이 아직 있다
이론 G2 증명: 나는 조합원이 아니다. 여러분도 조합원이 아닐 것이다. 내 관리층은 아직 내 말에 귀 기울인다. 가끔이긴 하지만. 아마 여러분의 관리층도 마찬가지이리라. 우리 분야에서는 노동-관리 대립 구도보다 노동-관리 협조 체계가 좀더 일반적이다
하위 이론 G31: 동기부여는 생산성 향상의 중요한 요인이다
하위 이론 G32: 전산 관리에서 동기부여보다 통제를 채택하는 경우가 더 잦다.

이에 대한 결론:

이론 G3: 전산 관리는 아직 존재하는 생산성 향상의 가능성을 파괴하는 방향으로 움직이고 있다
이론 G3 증명: 5년 전만큼 일을 즐기는가? 그렇지 않다고 본다.
G 이론 전체: 미국 시스템은 생산성을 크게 향상하기에 너무 늦었을지도 모르겠다. 전산 분야는 아직 희망이 있다. 하지만 전산 관리가 그 희망을 파괴할지도 모르겠다.

옮긴이 생각: 바로 이렇기 때문에 과학자나 공학자를 관리(?)하려는 시도는 무의미하다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[5부 8번 수필] 전산학과 교수에게 보내는 공개 편지

2007-09-09T20:01:00.000+09:00

로버트 L. 글래스 큰 형님 의견에 따르면 전체 전산학이라는 범주에서 빠진 연결 고리 중 가장 중요한 요소는 바로 '소프트웨어 유지 보수'라고 한다. 실제로 대한민국 소재 4년재 대학교 전산학과나 컴퓨터 공학과에서 유지 보수를 정식 과목으로 택했다는 말은 아직 들어보지 못했다(혹시 누가 사례를 알고 있다면, 이 과목에서 배우는 내용과 과제를 보내주기 바란다).

대학교 때부터 유지 보수를 배워야 하는 이유는 소프트웨어 컨플릭트 2.0을 읽은 독자라면 이미 알고 있듯이

유지 보수 업무는 소프트웨어 비용 중 40~80%를 차지한다.
유지 보수 담당자는 자기 시간 중 75%를 제품 개선에 쏟으며, 15%만 버그 수정에 투입한다.(리처드 K. 불 "남들이 만든 버그를 수정하는 일은 소프트웨어 유지 보수 담당자 역할이 아니다. 우리(유지 보수 담당자)는 예의상 버그를 고쳐줄 뿐이다.

로 요약할 수 있다. 이렇게 중요한 유지 보수를 학교에서 다루지 않고 있다는 사실이 신기하지 않은가?

자, 그렇다면 말이 나온 김에 신기한 사실 하나를 더 짚고 넘어가자. 이 책을 번역한 역자가 생각하는 전산학 분야에서 가장 등한시되는 요소는 무엇일까? 바로 '디버깅과 성능튜닝'이다. 개발자 중 디버깅과 성능 튜닝을 하지 않는 행운아가 있을까? 하지만 '유지 보수' 과목이 개설되지 않았듯이 '디버깅 101'이라는 과목 역시 개설된 경우는 보지 못했다. 유지 보수 업무 중에 자기가 만든 코드 디버깅에 쏟아붓는 비율을 한번 따져보면 끔찍한 기분이 들 것이다. (개인 차원이 아니라) 학교나 회사에서 제대로 된 '디버깅'에 대해 별반 신경쓰지 않는 이유를 알고 있다면 바로 댓글 부탁드리겠다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[4부 9번 수필] 실패한 소프트웨어 프로젝트에 관한 전설

2007-09-03T06:21:00.000+09:00

4부 9번 수필은 짧지만 너무나도 재미있어서(그리고 가슴 찡하기에) 전체를 소개한다. 흥미가 당기신 분들은 소프트웨어 컨플릭트 2.0 책을 구입해서 다른 글도 읽어보시길... ;) 자, 시작한다!

옛날 옛적에 아주 거대한 난관에 봉착한 소프트웨어 실무자가 있었다. 이 실무자가 처한 곤경을 얘기하자면, 소프트웨어는 예산을 초과했고 일정을 놓쳤으며 불안정했다.

소위 소프트웨어 위기에 관한 글을 읽어보았다면 ‘별로 대단한 일이 아니잖소?’라고 말할지도 모르겠다.

하지만 이 사람에게는 대단한 일이었다. 덧붙이자면, 여러분이 생각하는 정도보다 훨씬 심각했다. 이 소프트웨어 실무자는 전산 분야에서 둘째가라면 서러울 대학을 졸업했다. 졸업 후에는 여러 해 동안 탄탄한 프로그래밍 경력을 쌓았다. 심지어는 수년 동안 실무에서 배운 지식과 학교에서 배운 지식의 정수를 조화시키는 방법까지 익혔다.

다시 말하면, 이 소프트웨어 실무자는 우수한 소프트웨어 실무자가 갖출 조건을 모두 갖춘 셈이다. 그렇다면 무엇이 잘못되었을까?

모든 문제는 맨 처음, 해결할 문제가 처음으로 등장했던 때로 거슬러 올라간다. 회사에 큰 돈을 벌어줄, 아주 중대한 문제였다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 특별한 문제로 취급해야 한다는 사실에는 의심의 여지가 거의 없었다.

첫번째로 특별히 취급해야 할 사항은 특정 날짜까지 끝내야 한다는 점이었다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 담당할 소프트웨어 실무자가 그 날짜까지 불가능하다고 생각해도 소용이 없었다. 무조건 날짜를 맞춰야 했다.

협조적인 태도를 보이느라, 실무자는 우려에도 불구하고 일을 시작했다. 관리층이 그의 우려에 귀를 기울이기는 했다. 실무자가 소프트웨어를 개발하는 동안, 관리층은 원하는 답이 나올 때까지 비용 예측 모델링 프로그램을 돌렸다. 그리고는 회심의 미소를 띄우며 이렇게 말했다. “봤죠? 시간 내에 소프트웨어를 개발할 수 있다니까요.”

시간이 흐르고 기한이 다가오면서, 우리의 실무자는 점점 더 초조해졌다. 처음에는 자신의 품질 기준에 맞춰서 소프트웨어를 개발했다. 요구사항을 주의 깊게 검토하고, 철저히 설계한 다음에, 프로그램을 실행하기 전에 코드 행 한줄한줄을 신중하게 검토 desk-checkin했다.

그러나 기한이 코앞에 닥치면서, 그는 우수한 기법을 생략하기 시작했다. 요행을 바라면서 테스트를 대충 해버렸다. 어떤 모듈은 테스트하지 않은 채로 통합하기도 했다. 제품은 자체 표준 테스트도 통과하지 못한 상태에서 베타 테스트로 돌입했다. 그러나 기한은 꿈쩍할 가능성이 없어 보였고, 결국 압박감을 견디다 못해 덜 중요해 보이는 사항을 희생하게 되었다.

결국 우리의 실무자는 기한을 맞추지 못했다. 프로젝트는 그가 처음 예측했던 날짜대로 그만큼 늦어졌다. 당연히 비용은 예상보다 많이 들었다. 낙관적인 일정에 맞추어 비용을 예측했으니까. 안정성? 실무자가 기한을 맞추려고 이것저것 건너뛰는 바람에 안정성도 역시 문제였다. 사람들이 말하는 소프트웨어 위기 그대로였다. 일정을 놓치고 예산을 초과하고 불안정한 소프트웨어 프로젝트가 하나 더 생겨났을 뿐이었다.

요약하자면, 옛날 옛적에 우수한 소프트웨어 실무자가 실패한 소프트웨어 프로젝트를 내놓았다. 마음 속으로는 대충 건너뛰면 안 된다는 사실을 알았다. 하지만 동시에 마음속으로는 개발 과정에서 저지른 실수가 하나뿐이라는 사실도 알았다.

그가 저지른 실수는 소프트웨어를 제작한 방식이 아니었다. 처음부터 잘못된 일정에 맞추려는 시도 자체가 실수였다.

소프트웨어 실무자가 관리층으로부터 성과 평가를 받았을 때, 그는 실패한 프로젝트로 인해 자신의 업무 평가가 낮아졌음을 발견했다.

그는 궁금했다. 나와 같은 입장에서 괴로워하는 사람들이 얼마나 많을까? 순전히 잘못된 예측이나 대충 꾸며댄 예측 탓으로 생기는 소프트웨어 위기가 얼마나 많을까?

아직도 그는 궁금해한다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[4부 8번 수필] 소프트웨어 제품에서 '품질'을 관리할 수 있을까?

2007-08-19T21:26:00.000+09:00

소프트웨어 업계에서 입에 익은 관용구처럼 사용하고 있는 단어 중 하나가 바로 '품질 보증'이다. 일단 여느 업계와 마찬가지로 '품질'에 '보증'이 붙게 되면 '품질'은 관리 문제로 바뀌고 만다. 하지만 '품질'에서 '보증'을 떼내고 싶어 안달이 난 로버트 L. 글래스 큰 형님은 품질이 관리 문제가 아니라고 강조한다.

소프트웨어 개발 과정에서 관리층은 품질 프로세스를 도입하면 품질을 관리할 수 있다고 착각하지만 실제로는 품질은 테스트는 고사하고 관리조차 못한다는 중요한 사실을 모르고 있다. 로버트 L. 글래스 큰형님에 따르면 품질은 내밀한 소프트웨어 특성이며, 이해 용이성과 수정 용이성이라는 특성을 포함하고 있다. 품질 프로세스를 도입하면 이해 용이성과 수정 용이성이 덩달아 좋아지면 얼마나 좋겠느냐만은 사실상 관리층은 이해 용이성과 수정 용이성을 판단하는 데 필요한 기술적 업무에 익숙하지도 않으며 익숙해서도 안 된다. 또 한가지 품질 속성에 들어가는 요소는 신뢰성과 이식성인데, 역시 관리 관점이 아니라 기술적인 관점에서 살펴봐야 할 요소이다.

결국 21세기 소프트웨어 관리자에게 맞는 소프트웨어 공식은

소프트웨어 제품 = 일정 + 예산

이 아니라

소프트웨어 제품 = 품질 + 일정 + 예산

이 되어야 한다고 강력하게 주장하며, 품질이라는 문제는 관리적으로 고려할 사항이라기 보다는 기술적으로 고려할 사항이 훨씬 더 복잡하다고 결론 내린다.

로버트 L. 글래스 큰 형님이 품질보증에 쐬기를 박는 마지막 말을 한번 들어볼까?

간단한 연습을 해보자. 내가 '품질'이라고 말할테니, 관습적인 추가어인 '보증'을 붙이지 않고 꾹 참아본다.
품질
잘했다. 별로 어렵지 않은 일이다. 그렇지 않은가?

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[4부 2번 수필] 소프트웨어 생산성을 바라보는 새로운 방법

2007-08-06T14:10:00.000+09:00

소프트웨어 생산성을 높이기 위해 여러 가지 이론과 기법과 제품이 등장했다. 물론 이런 여러 가지 방법을 동원해서 생산성을 수십, 수백 배로 높인 경우도 있을지 모르겠지만(혹시 이런 환상적인 경우를 아는 사람이 있다면, 알려주기 바란다), 대부분 몇 % 상승에 그치고 만다. 베리 뵘이 말하듯이 생산성에 관한 한 방법론, 언어, 기타 기술적인 방법은 사소한 향상밖에 가져오지 못한다.

자 그렇다면, 생산성 향상을 위해 무엇을 해야 하나? 로버트 L. 글래스 큰 형님은 _사람_에 주목한다. 소프트웨어 제작 인력이 우수하면 생산성이 높아진다는 말이다. 결국 소프트웨어 분야에서 기술 사회학에 주목해야 생산성 향상을 달성한다. 그렇다면 우수한/숙련된/전문 인력과 덜 우수한/미숙한/초보 인력의 차이점은 무엇인가? 사람과 관련하여 어떤 요소가 생산성에 강력한 영향을 미쳤는지 정리한 내용을 여기에 요약해보겠다.

목표와 하위 목표를 더 많이 설정했고, 목표로부터 하향식으로 일했다.
과거에 풀었던 문제와 유사성을 밝혔고, 밝혀낸 유사성을 기반으로 모델을 만들었다.
더욱 체계적이었다. 더 많은 전략을 말로 표현했으며, 가정과 제약과 기대치를 기록했다. 최종 제품을 더 구체적으로 묘사했다(즉, 시스템 분석가는 요구사항을 더 많이 작성했다)
더 많은 가설을 세우고, 시도하고, 포기했다. 더 많은 전략을 수정했다.
여러 방면에서 좀더 사람을 고려하는 성향을 보였다. 시스템 분석가는 사용자 관계를 더욱 효율적으로 관리했다. 유지보수 담당자는 원래 코드를 짠 개발자의 구현 방식과 성격을 분석하며 사람과 코드를 연관지었다.

요즘 나오는 여러 가지 소프트웨어 공학 책을 읽다보면 위에서 제시한 각종 요소를 알기 쉽게 풀어서 설명하는 내용을 접하곤 한다. 구체적이고, 반복적이고, 체계적인 접근 방법을 고려하면 소프트웨어 생산성을 높일 수 있으리라는 희망이 보인다. :)

'소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 역자 박재호 올림

[3부 4번 수필] 표준과 표준 준수: 정말 소프트웨어 품질을 높이는 데 도움이 되나?

2007-07-05T10:55:00.000+09:00

사람들은 흔히 소프트웨어 표준만 있으면 제품 품질이 저절로 올라간다는 착각을 한다. 물론 제품 품질 향상을 위해 소프트웨어 표준이 있으면 좋긴 하겠지만, 표준만으로 제품 품질을 올리기는 무척 어렵다.

무엇이 문제일까? 바로 표준 정립과 표준 준수가 따로 놀기 때문이다. 표준 정립 자체가 표준 준수를 의미하면 좋겠지만, 대부분 표준을 만드는 사람과 이행하는 사람은 동일하지 않기 때문에 삐걱거리기 마련이다.

로버트 L. 글래스 큰 형님은 표준 정립과 관련한 잘못된 관례에 대해 일침을 가한다.

대다수 소프트웨어 회사에서는 적어도 100페이지는 족히 되는 멋진 소프트웨어 제작 규칙을 빽빽하게 기술한 표준 메뉴얼이 존재한다. 아마도 (1) 동료들에 비해 재능이 떨어져서 소프트웨어 개발팀에서 밀려났거나 (2) 자신이 '최고' 소프트웨어 제작 방법을 발견했다고 생각해서 모두가 그대로 따라야 한다고 믿는 사람들이 작성한 메뉴얼이다.

우와. 그렇다면 어떤 관례가 올바를까? 다음과 같은 세 가지를 생각해보자.

표준은 간결하고 핵심적이어야 한다. 길게 만든 문서는 표준이 아니라 지침으로 남기자.
표준은 회사에서 프로그래밍 기량이 가장 뛰어난 사람이 작성하고 검토해야 하며, 시간이 남는다고 아무에게나 맡겨서는 안 된다. 모두에게 강조하고 준수하도록 만들 규약이므로 마땅히 최고 두뇌에게 맡겨야 한다.
표준 준수는 의무적이어야 하며, 시간이 남으면 따른 선택이 되어서는 안 된다.

과연 여러분이 몸담고 있는 회사에서는 표준을 누가 만드는지 생각해보자. 그리고 표준을 따르지 않는 이유도 함께 고민해보기 바란다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 6번 수필 추가] 소프트웨어 유지보수는 해결책이지 골칫거리가 아니다

2007-06-14T09:30:00.000+09:00

네, 이미 박재호님께서 짚고 넘어간 글, 또 뒷북입니다. :-)

저자는 유지보수에 인력을 투입하는 방식이 변해야 한다며, 구체적인 해결 방안 네 가지를 제안합니다. 그런데 개인적으로는 그 네 가지도 여전히 조금 추상적이라 여겨집니다. 그래서 오늘은 원론적인 이야기보다 제 경험을 이야기하겠습니다.

제가 처음 일했던 소프트웨어 회사는 거의 천만줄이 되는 소스 코드를 매일 밤마다 빌드할 정도로 소프트웨어 규모가 컸습니다. 몇 백명이나 되는 개발자들이 소프트웨어 하나에 매달려 일했었죠.

첫 서너 달 동안 제가 한 일은 고객이 요청한 버그 수정, 즉 유지보수 작업이었습니다.

먼저 기술 수석이 각자 짠밥에 맞게 버그를 할당합니다. 그럼 할당받은 버그를 들고 가장 먼저 기술 수석을 찾아가죠. 처음에는 문제가 도데체 무슨 말인지부터, 어떻게 재현하는지, 어떻게 디버깅하는지, 어디를 어떻게 고쳐야하는지, 일일이 기술 수석을 찾아가 꼬치꼬치 물어야만 합니다. 하나도 모르니까요. ^^;;

여차저차 코드를 고친 다음에는 기술 수석에게 코드 검토를 받고, 기술 수석이 승인하면, 고친 코드와 관련되는 테스트 케이스를 돌립니다. 여기까지 다 통과하면 소스 코드 관리 시스템에다 넣습니다.

점차 익숙해질수록 할당 받는 버그도 복잡해집니다. 이제는 기술 수석만이 아니라 여기저기 '핵심' 개발자들을 찾아서 회사 안을 헤맵니다. '이 부분은 누구한테 가봐라' 혹은 '지금은 회의있으니까 30분 후에 보자' 이런 소리도 많이 듣죠. 부끄럽다고 대충 넘어가면 문제를 해결 못하니까, 납득할 때까지 캐물어야 합니다. 질문하는 만큼 배우니까요.

그러다보면 점차 다른 개발자를 찾아가는 횟수도, 엉뚱한 개발자를 찾아다니며 헛걸음하는 횟수도, 전혀 상관 없는 질문을 던지는 횟수도, 함께 문제를 의논하는 시간도 줄어듭니다.

반면 혼자서 해결하는 문제 수가 늘어납니다. 전체 아키텍처도 조금씩 머리 속에 들어옵니다. 코드를 열심히 뒤지다 보니 회사에서 사용하는 구현 관례에 익숙해집니다. 생판 처음보는 남의 코드를 빨리 이해하는 눈도 생깁니다. 우리 팀과 관련 있는 '핵심' 개발자들과도 친해집니다. 그렇게 저는 신참 때깔을 조금씩 벗었습니다. 지겨웠다기 보다는 재미나고 신선한 시간이었습니다. :-)

아, 그렇다고 유지보수 업무에서 완전히 손을 떼지는 않습니다. 프로젝트 일정에 따라 수위를 조절할 뿐 유지보수 업무는 개발 업무와 마찬가지로 모든 팀원이 기본적으로 '해야할 일'이었습니다. 신참이었을 때 가장 많은 시간을 투자했죠.

참고로, 회사 내 모든 고참 개발자는 자기 시간에서 10-30%를 멘토링/컨설팅 시간으로 할당했습니다. 전체 아키텍처를 잘 아는 사람일수록 (어쩔 수 없이) 많은 시간을 컨설팅에 쏟았습니다.

신참이 유지보수 업무를 수행할 경우 장점이 많습니다. "신참에게 유지보수 업무를 맡긴다"에서 문제점은 "신참"이 아니라 "맡긴다"에 있다고 생각합니다. 유지보수 업무는 아키텍처를 잘 아는 고참이 "책임"져야 합니다. 신참이 코드를 구현하더라도, 책임자가 전체 아키텍처에 어긋나지 않도록 방향을 잡아주고 코드를 검토해야 합니다. 그러다 보면 고참은 자연히 신참을 이끄는 멘토 역할도 하게 됩니다. 경력 있고 실력 있는 개발자에게 멘토 역할은 참 보람된 일이죠. 경력 있고 실력 있는 개발자로부터 지식과 기술을 전수받는 경험도 참으로 즐겁죠.

유지보수 업무, 어차피 해야할 일이라면 잘 활용해서 여러 마리 토끼를 한꺼번에 잡으면 어떨까요?

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 이해영 올림

[3부 1번 수필] 재사용: 소프트웨어 부품 - 노스텔지어와 데자뷰

2007-06-04T05:47:00.000+09:00

소프트웨어 공장, 소프트웨어 재사용, 컴포넌트 기반 소프트웨어라는 용어를 전산 업계에 몸 담고 있는 사람들은 누구나 한번쯤 들어보았을 테다. 주기적으로 꼭 찾아오는 이런 유행이 어디서 시작되었는지를 알려주는 흥미로운 수필 한 편이 소프트웨어 컨플릭트 2.0에 실려있기에 무척 즐겁게 읽은 기억이 새롭다.

1950년대 IBM 컴퓨터를 다루던 개발자들은 난감한 상황에 직면했다. 요즘과 같은 막강한 프로그래밍 환경(다양한 잡지/책/논문, 소프트웨어 분리판매/끼워팔기)이 없었기에 프로그램 작성에 필요한 자료를 구할 길이 막막했기 때문이다. 이런 어려운 상황을 극복하기 위해 상부상조하는 정신에 입각해서 각 프로그래머들이 자신이 만든 소프트웨어 코드를 기부하고 문서화시켰는데... 바로 SHARE의 시작이었다.

SHARE는 당시 IBM 컴퓨터 사용자(프로그래머)들이 자발적으로 만든 사용자 그룹이다. SHARE에 속한 사람들은 자발적으로 소프트웨어 루틴을 기부해서 이를 라이브러리화시킨 다음에 원하는 사람이면 누구나 라이브러리에 들어있는 코드를 재사용하도록 환경을 조성해주었다. SHARE에서 가장 흥미로운 사실은 SHARE 라이브러리 명세를 보면 항상 만든 개발자 이름과 소속이 나와있다는 점이다. 가상 인터뷰에서 소개하는 대화 일부를 볼까?

로버트 글래스: "소프트웨어 부품이 도움이 되나요?"(코드에 책임을 지지 못한다는 면책 조항이 마음에 걸려서 근처에 있는 프로그래머에게 물어본다.) 프로그래머: "그럼요, 거의 항상. 정말 인정하기 싫지만, 코드를 읽어보면 제 실력보다 훨씬 뛰어납니다. 졸작을 SHARE에 기부하는 사람들은 거의 없습니다. 너무 위험하거든요. 누군지 금방 들통나죠."

잡지도 논문도 책도 없는 상황에서 그 당시 소프트웨어 개발자로 우뚝 솟으려면 SHARE 참여만이 명성과 특권을 누리는 지름길이었다. 한마디로 SHARE에서 명성을 쌓기 위해 개인적인 이기심을 최대로 발휘한 결과 이타적인 결과를 얻은 셈이다.

하지만 왜 SHARE라는 좋은 시스템이 죽어버렸을까? 바로 소프트웨어 제작이 복잡해졌기 때문이다. I/O나 수학 라이브러리 같은 루틴이야 SHARE로 충분히 버틸 수 있었지만, 운영체제와 같이 너무나도 복잡한 시스템은 SHARE와 같이 자발적인 참여만으로 진행하기에는 너무 덩치가 큰 소프트웨어였다. 결국 개발자들은 회사에 소프트웨어를 만들어달라는 압력을 넣었고, 여기에 굴복한 회사가 소프트웨어를 제공하기 시작하면서부터 SHARE는 서서히 와해되기 시작했다. 결국 수학 라이브러리와 같은 몇 가지를 제외하고는 소프트웨어 부품이라는 개념이 자취를 감추게 되었다. 오호통제라!

하지만 현대판 SHARE 프로젝트가 다시 한번 등장하기 시작했다. 바로 오픈소스 운동이다. 앞서 운영체제와 같은 복잡한 소프트웨어를 기업에 의존하기 시작하면서 SHARE라는 공동체가 붕괴되기 시작했다고 말했는데, 역설적으로 오픈소스 운동은 리눅스라는 운영체제가 갖춰지기 시작하면서부터 급속도로 팽창하기 시작했다. 전 세계에 흩어져 있는 개발자들이 자신의 이름이 리눅스 운영체제에 등장하기를 갈망하면서 자발적으로 각종 코드를 기부하기 시작했고, 운영체제를 넘어서 웹 브라우저와 같은 엄청나게 복잡한 응용 프로그램 개발도 이런 흐름에 동참함으로써 제 2의 SHARE 프로젝트 전성 시대가 열린 상황이다. 결국 문명의 발전은 자아 실현이라는 개인의 동기에 의해 움직인다는 사실을 다시 한번 확인해주었다.

로버트 L. 글래스는 이 수필을 다음과 같이 말하며 끝낸다.

1950년대에 일어났던 상황의 데자뷰이다. 과거에도 일어났으니 지금도 가능하다. 단지 그렇게 하기만 하면 된다.

정말 놀라운 통찰력이 아닌가?

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 7번 수필] 단일 지점 제어

2007-05-20T07:21:00.000+09:00

실용주의 프로그래머에서 앤드류 헌터와 데이비드 토머스는 '중복의 해악'이라는 제목으로 DRY(Don't Repeat Yourself)라는 규칙을 강조한다.

모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다.

헌터와 토머스에 따르면 DRY 원칙은 코딩은 물론이고 코딩과는 전혀 상관없는 여러 문맥(예: 문서화)에서도 나오며, '실용주의 프로그래머' 도구 상자에서 가장 중요한 도구라고 말한다.

'실용주의 프로그래머'를 읽고나서 DRY에 대해 감탄한 분들도 많으셨을텐데... 사실 로버트 L. 글래스 큰형님이 한 걸음 빨랐다. 글래스는 보잉 밀리터리 에어크래프트 사에서 일하는 친구 리 맥로렌의 말을 빌어 '단일 지점 제어'를 강조한다.

단일 지점 제어는 여러 곳에서 해야할 일을 한 곳에서 해결한 후 필요한 곳에서 참조하는 방법이다.

그리고 '단일 지점 제어' 원칙이 소프트웨어 공학의 기본 원리 후보로 추천하고, 프로그래밍 개념을 넘어서 문서와 데이터베이스 설계에도 적용된다는 사실을 언급한다.

때로 '소프트웨어 컨플릭트 2.0이 진부하고 시대에 뒤떨어진 내용을 담고 있다고 말하는 사람을 보게 되는데, 생각이 진부한지 표현이 진부한지 예가 진부한지 너무나도 궁금하다. 핵심은 생각이므로 표현이나 예에 휘둘리지 말자.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 6번 수필] 소프트웨어 유지보수는 해결책이지 골칫거리가 아니다

2007-05-06T13:34:00.000+09:00

소프트웨어 컨플릭트 2.0에서 가장 공감이 와닫는 수필을 하나 골라보라고 하면 이번에 소개하는 2부 6번 수필을 결코 빼놓을 수 없다. 대다수 높으신 분들이 매일 역정을 내며 소프트웨어 유지보수에 들어가는 비용을 아까워하는 현실에 비춰볼 때 _해결책_이라는 시각으로 소프트웨어 유지보수를 바라보는 로버트 L 글래스 큰 형님은 보통 사람이 아니다.

로버트 L 글래스 큰 형님께서 바라본 유지보수 특성은 다음과 같다.

지적으로 복잡하다. 유지보수 담당자에게 극심한 제약이 가해지는 가운데에서도 창조력 발휘가 필요한 작업이다.
기술적으로 어렵다. 유지보수 담당자는 개념, 설계, 코드를 동시에 다룰 줄 알아야 한다.
불공평하다. 유지보수 담당자는 항상 무언가 부족하다. 예를 들어 우수한 유지보수 문서가 없다.
성공이 없다. 유지보수 담당자는 항상 문제가 있는 사람을 만난다.
지저분하다. 유지보수 담당자는 세세한 구현까지 지저분한 수준에서 일해야 한다.
과거에 산다. 분명 코드는 누군가 구현에 능숙해지기 전에 작성했다.
보수적이다. "긁어 부스럼 만들지 말자"라는 좌우명을 따른다.

그리고 페이지 존스 큰 형님에 따르면 소프트웨어 유지보수는 전체 소프트웨어 개발 생명주기 비용에서 2/3을 차지하는 어마어마한 작업이라고 한다.

상황이 이러하니, 유지보수를 대부분 어리버리한 신참이나 개발에 능숙하지 않은 사람에게 맡긴다. 대다수 사람들이 창의력을 발휘하기 어려운 유지보수보다 개발을 선호하기 때문이다. 결국 가장 능력이 떨어지고 가장 수요가 낮은 인력이 유지보수를 담당하니 소프트웨어 유지보수가 아직도 이 모양 이 꼴을 못벗어난다. 하지만 유지보수가 오류 수정(17%)보다는 개선(60%) 작업 비중이 훨씬 높기 때문에 제대로 된 유지보수 없이는 제대로 된 소프트웨어 개발도 없으며, 유지보수가 소프트웨어 부문에서 가장 어려운 작업이므로 상식에 반하게 최고 인력을 투입해야 한다.

결국 유지보수, 아니 소프트웨어 개발을 제대로 하기 위해서는 유지보수를 바라보는 시각을 바꿔야 한다. 누군가 유지보수에 대해 색안경을 끼고 있다면 벗긴 다음에 인정사정 보지말고 망가뜨려 버려라.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 2번 수필] 버그, 오류, 결함

2007-04-25T09:54:00.000+09:00

SC2.0을 읽다보면 이런저런 '잡스러운' 생각을 많이 하게 됩니다. 2장 2번 수필을 읽다가 메모해 둔 질문 중 하나입니다.

버그(bug)와 오류(error)와 결함(defect)의 차이는 무엇일까요?

대충 많이 쓰는 말이고 대충 느낌으로 이해하는 단어이고, 많이 섞어쓰는 뜻이기도 합니다. 하지만 정확히 구분해서 정의한다면?

여러분들이 재밌게 여길 질문이다 싶어서 올려봅니다. 답은 안올려도 되겠죠? 찾고 생각하는 과정이 더 재밌으니까요.

"소프트웨어 컨플릭트 2.0" 역자 이해영 올림.

@ In Search of Stupidity 2nd Ed. 번역을 한창 진행 중입니다. 너무너무 재미있어서 빨리 읽혀드리고 싶네요.

[2부 5번 수필] 소프트웨어 품질과 소프트웨어 유지보수 사이의 관계

2007-04-15T19:37:00.000+09:00

로버트 L. 글래스 큰 형님에 따르면 소프트웨어 품질이 우수하기 위한 속성이 일곱 가지있다고 한다.

신뢰성(reliability)
효율성(efficiency)
인간공학(human engineering)
이해 용이성(understandability)
수정 용이성(modifiability)
테스트 용이성(testability)
이식성(portability)

여기서 제시한 일곱 가지 속성 중에 소프트웨어 유지 보수와 관련이 있는 항목이 대부분이다. 이해 용이성, 수정 용이성은 당연히 유지 보수와 직접적인 관련이 있는 항목이며, 소프트웨어가 실패하지 않고 제 기능을 수행해야 한다는 신뢰성과 소프트웨어가 시간/공간 자원을 최소로 사용해서 동작해야 한다는 효율성, 소프트웨어 테스트가 쉬워야 한다는 테스트 용이성, 소프트웨어를 쉽게 사용하도록 만들어주는 능력인 인간 공학, 다른 컴퓨터나 환경에서 소프트웨어를 사용하게끔 만드는 이식성 모두 유지 보수 담당자가 머리를 싸매는 항목이다.

자, 그렇다면 소프트웨어 품질을 높이려면 가장 좋은 방법은 무엇일까? 상기 일곱 가지 항목을 생각해보면 대답이 바로 나오지 않는가? 바로 '유지 보수'를 제대로하는 방법이다. 유지 보수가 3D 중의 3D로 계속 남아있으며, 애물단지로 취급되는 현 상황에서는 절대로 소프트웨어 품질을 높이지 못한다. 따라서, 소프트웨어 품질 운운하면서 유지 보수에 형편없는 인력을 투입하는 관리자를 항상 경계하기 바란다. 실제로는 소프트웨어 품질을 높이고 싶은 생각이 전혀 없음을 에둘러서 표현했을 뿐일테니까.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 3번 수필] 소프트웨어 오류 제거에 대한 실험적 관점

2007-04-07T20:36:00.000+09:00

소프트웨어 오류를 제거하는 가장 효율적인 방법과 가장 저렴한 방법은 무엇일까? 프로젝트를 진행함에 있어 이 두 가지 질문은 항상 가슴 속에 품고 다녀야 하지만, 공론화가 되지 않는 희한한 속성이이 있다. 이미 널리 알려진 바와 같이 오류 제거에 드는 비용은 시스템 분석과 설계와 구현에 드는 비용 각각에 비해 거의 두 배가 넘든다고 한다. 그렇다면 왜 이렇게 비싼 댓가를 치루면서도 계속 소프트웨어 오류에 무관심할까?

가장 큰 이유는 소프트웨어 오류에 대한 연구가 상당히 뒤쳐저 있기 때문이다. 최신 프로그램 언어, 최신 라이브러리, 프레임워크에 대한 책이나 기사는 넘쳐나지만, 소프트웨어 오류에 대한 책을 한번 찾아보기 바란다. 책장 한 칸이면 다 채우고도 남을 정도다. 결국 '~카더라'라는 주관적인 견해가 판을 치다보니 믿을만한 정보가 부족해지고, 믿을만한 정보가 부족하다 보니 모두 자기 머리만 믿는다. 그리고... 후반부에 가서 완전히 함정에 빠진 사실을 알아차린다. T_T

로버트 L. 글래스 큰 형님은 테스트와 관련한 여러 연구를 종합해서 다음과 같은 결론을 내린다.

반드시 검토를 수행하여 테스트를 보완한다
기능적 테스트를 강조하되 구조적 테스트도 수행한다
설계 검토와 코드 검토를 모두 수행해야 한다

여기서 기능적 테스트는 프로그램 요구사항 명세서를 기반으로 범위를 결정한 테스트이고, 구조적 테스트는 프로그램 내부 동작 방식에 맞춰 범위를 결정한 테스트이다. 코드 검토는 소프트웨어를 실행하지 않고 정적으로 소스 코드 자체를 살펴서 오류를 찾는 방법이다.

코드 검토 과정에서 사용하는 단계적 추상화(stepwise abstraction)는 소프트웨어에서 핵심적인 하위 프로그램을 찾아 기능을 파악한 후 이들 개별 기능으로부터 소프트웨어 전체 그림을 파악하는 방법이다. 워크스루와 인스펙션은 검토 회의 전에 코드를 읽고 마음속으로 소프트웨어 논리를 따라서 테스트 케이스를 실행하는 방법이다.

흥미롭게도 코드 검토 과정에서 사용하는 방법이나 소프트웨어 설계 과정에서 사용하는 방법이 너무나도 유사하다. 한쪽에서는 마음 속으로 설계도를 그리고, 다른 한쪽에서는 마음속으로 설계도면을 돌려본다. 결국 설계와 코드 검토는 마음으로 행하는 작업이며, 유기적으로 수행해야 효과를 높인다는 결론에 이른다. 물론 예나 지금이나 테스트는 반드시 수행해야할 작업이긴 하지만, 마음의 눈으로 수행하는 코드 검토를 절대 간과하지 말지어다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[2부 2번 수필] 소프트웨어 오류에 대한 단상

2007-03-31T22:32:00.000+09:00

아키텍처 - 설계 - 구현에 이르기까지 한치의 실수도 없이 한 달음에 끝내야 한다고 주장하는 사람들을 종종 만나곤 한다. 주로 하드웨어 부문에 있는 사람들이 이런 방식의 일처리에 익숙한데, 심지어 소프트웨어 개발에 6시그마와 같은 방법을 사용하려는 욕망을 드러내기도 한다.

소프트웨어 오류에 대해 우리가 과연 어떤 식으로 대응해야 할까? 로버트 L 글래스 큰 형님께서는 다음과 같은 주장을 통해 사람의 중요성을 강조한다.

소프트웨어 오류 제거에서 가장 중요한 요소는 제품 특성이나 프로세스 특성이 아니라 올바른 사람의 선택이다.

200% 동감이 가는 말이다. 방법론이 아무리 뛰어나고 지원 도구가 아무리 우수하면 뭐하나? 결국 오류를 찾아내는 사람이 가장 중요한 말이다.

여기까지야 너무나 많이 떠들어온 이야기라서 식상하기 일보직전일테다. 그렇다면 여기서 말하는 올바른 사람들의 특성이 무엇일까? 로버트 L. 글래스 큰형님에 따르면 다음과 같은 놀라운 사실이 밝혀진다.

우수한 사람들이 '나쁜'사람들 보다 잘못 시작하는 경우가 많다는 사실을 발견했다. 즉, 좋은 소프트웨어를 만들려면 적어도 생명 주기 포반에는 시행착오를 거치면서 불가피하게 '오류'가 생긴다는 뜻이다. 그러므로 모든 오류가 무조건 나쁘지만은 않다.

자전거를 처음 배울 때 넘어지지 않고 배울 수 있다면 얼마나 좋겠느냐만, 세상에 공짜 점심은 없다. 제대로 훈련받은 공학도라면 초반에 저지른 오류를 후반에 다시 저지르지는 않을테니, 차라리 출시 직전에 대박(?!)을 터트려 제품 전체를 위험하게 만드느니 초반에 이런저런 온갖 실수를 다 저지르도록 정책적으로 배려해줄 필요가 있다. 개발자를 믿고 신뢰하면 그 만큼 돌아오는 몫이 크다.

요즘 들어와서 초반부터 꽉 짜여진 틀에 따라 정확하게 소프트웨어를 만들어야 한다고 윽박지르는 관리자를 볼 때마다 화가 나기 보다는 연민의 정이 느껴진다. 소프트웨어 제작을 공장 컨베이어 벨트에서 진행하려는 이런 시도 때문에 소프트웨어 산업이 3D화 되고 있지 않은지 반성해볼지어다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호

[2부 1번 수필] 인지적 견해: 소프트웨어 설계를 보는 다른 시각

2007-03-18T09:53:00.000+09:00

설계 부문의 고전인 'Design Methods'를 지은 존 크리스토퍼 존스 큰 형님 사진

소프트웨어 분야에서 소프트웨어 설계만큼 신기하면서도 어려운 공정이 없다는 생각이다. 로버트 L 글래스 큰 형님 말처럼 30여년이 넘게(지금은 45여년이 넘게) 소프트웨어를 설계해왔고, 상식적으로 필요하다 싶은 설계 방법론과 설계 언어를 모두 갖추고 있지만, '설계'에 대해 명쾌하고 가슴이 와 닿는 정의를 내리기는 무척 어렵다.

이런 상황에서도 대가들은 뭔가 달라도 다르다. 오늘은 존 크리스토퍼 존스 큰 형님이 설계에 대해 정의한 문구를 소개하고 싶다. 개인적으로 아주 좋아하는 설계 관련 이야기이기도 하다.

근본적인 문제는 예측이 올바르지 않을 경우 현실화되지 못하는 _미래_ 상태를 예측하기 위해 설계자가 _현재_ 주어진 정보를 사용해야 한다는 사실이다. 설계의 마지막 결과물은 결과물을 만드는 수단을 펼치기 앞서 미리 가정해놓아야 한다. 설계자는 영향을 미치는 사건 연쇄가 시작되는 초기에 세상에 영향을 미칠 시점을 기준으로 시간을 거슬러 올라가면서 작업해야 한다.

쉽게 설명해서, 설계자는 설계의 결과가 어떻게 동작할지 모두 알기에, 속된 말로 짜고치는 고스톱을 친다는 말이다. 심심풀이로 주변에 프로그램을 잘 짜는 친구들을 대상으로 인터뷰를 해보면 한결같은 대답이 나온다.

질문: 개발 과정 중에서 언제부터 프로그램 구현을 시작합니까? 대답: 내가 짠 프로그램이 제대로 돌거라는 확신이 설 때부터.

서투른 개발자는 프로그램 구현에 있어 부딪히는 모든 함정에 따 빠지면서 가까스로 목표를 향해 전진하지만, 뛰어난 개발자는 마치 매트릭스에서 네오가 총알을 부드럽게 피하듯 주변에 함정이 어디있었냐는 듯(실제로 함정에 빠지긴 하지만 워낙 회복 속도가 빨라서 주변 사람들에게는 함정을 피한 듯이 보일 뿐이다. :))이 목표를 향해 그대로 돌진하다.

크리스토퍼 존스 큰 형님에 이어 로버트 L. 글래스 큰 형님도 한마디 거든다.

연구 결과를 이해하려면 먼저 짧은 소프트웨어 역사 속에서 전통이 되어버린 사고에 대한 집착을 버려야 한다. 설계의 외적인 표현에 연연하지 말고 사고의 흐름에 초점을 맞춰야 한다. 설계의 비밀은 _마음_속에 있다.

이런 평범하다면 지극히 평범한 진리를 이해하지 못하기 때문에 제대로 된 프로그램을 만들기 위해서는 객체지향형 언어인 C++나 자바나 파이썬이나 루비타 기타 등등의 언어를 사용해야_만_한다고 교조주의적인 주장(예: "아직도 C를 쓰세요? 설계에 대해 X도 잘 모르시는군요.")이 나온다. 설계의 비밀은 프로그램 언어에 있지 않고 방법론에도 있지 않다. 여러분 _마음_속에 있다.

로버트 L. 글래스 큰형님은 설계의 본질을 딱 네 줄로 설명한다.

마음 속으로 모델을 만들어본다.
마음 속으로 모델을 실행한다. 즉, 시물레이션을 통해 모델이 문제를 해결하는지 확인한다.
(대게 모델이 너무 단순해서) 문제를 해결하지 못하면, 불충분한 모델에서 실패하는 부분을 찾아서 개선한다.
모델이 문제를 해결할 때까지 1-3단계를 반복한다.

즉, 설계는 정신적이고, 아주 빠르고, 반복적이며, 사실상 시행착오를 거듭하는 과정이며, 마음이 문제 해결책을 구상한다. 즉 설계의 본질은 신속한 모델링, 시물레이션이며, 설계의 핵심 요소는 해결책을 제안하고 실패하는 능력과 실패를 극복하는 능력이다.

로버트 L. 글래스 큰형님의 마지막 아름다운 말씀을 전하면서 마무리 하겠다.

설계는 마음 속에서 번개처럼 떠오르는 무언가임을. 그리고 어떤 사람의 번개는 다른 사람의 번개보다 훨씬 빠르다는 사실을.

"소프트웨어 컨플릭트 2.0" 역자 박재호 올림

[1부 4번 수필] '가장 뛰어나고 명석한 두뇌들이 내놓은 보고서'

2007-03-04T16:53:00.000+09:00

'Rapid Development: 프로젝트 쾌속 개발 전략'을 읽다보면 '10대 위험 목록'에 대한 설명이 나온다. 스티브 맥코넬은 이런 환상적인 쾌속 개발 기법의 기원을 빼놓았는데, 알고보면 미국방성(DoD) 국방과학부 특별 위원회가 발간한 보고서로 거슬러올라간다.

국방성에서 발간한 보고서는 DoD에서 소프트웨어를 개발하는 과정에서 발생하는 문제점과 이에 대한 해결 방안을 조목조목 담고 있는데, 다른 내용도 흥미롭지만 위험 관리 부문을 절대로 그냥 넘겨서는 안된다는 생각이다. 사실상 10대 위험 목록 유지는 어떤 개발 방법론도 따라오지 못하는 강력한 상황 파악 능력을 프로젝트 관리자에게 선사하므로 원시 코드 이력 관리와 일일 빌드와 함께 관리자 도구 목록에 포함시켜야 한다.

보고서에는 뭐라고 적혀 있었을까? 소프트웨어 컨플릭트 2.0 26페이지에서 잠깐 몇 글자 따와보겠다.

추천 25: ... 소프트웨어 획득 과정에서 위험 관리 기술을 필수로 만들어라.

프로젝트에서 최고 위험 10가지를 밝힌다.
각 위험별로 대처 방안을 세운다.
매달 최고 위험, 대처 방안, 결과를 수정한다.
월간 프로젝트 검토 회의에서 위험 상태를 점검한다.
적절한 조치를 취한다.

무척 간단하지 않은가? 최고 위험 10가지를 항상 유지해야 하는 결정적인 이유는 바로 이 최고 위험 10가지가 현실화 되는 순간 여러분 프로젝트가 꼼짝없이 실패하기 때문이다. 장기를 두면서 자기 왕이 외통수로 몰려서 꼼짝 달짝 못하는 상황에 이르고 싶어하는 사람이 있을까? 프로젝트 진행도 마찬가지다. 외통수로 몰릴 가능성이 있는 수를 미리 검토해서 프로젝트를 진행하는 사람들에게 경종을 울리는 깃발이 바로 최고 위험 10가지 목록이다.

어떤 사안이 최고 위험 10가지 목록에 계속해서 올라가 있고 내려올 생각을 하지 않는다면 프로젝트 진행 과정에서 다른 기능 추가 작업에 앞서 위험 요소를 줄이거나 없애거나 회피하도록 노력해야 한다. 위험 목록 자체에 우선 순위와 미치는 영향을 포함시켜 둘 경우 상부에서 자원 투입을 어떻게 해야 할지 쉽게 결정할 수 있기 때문에 위험을 줄이는 과정에서 우왕좌왕 결정을 못내리고 모두 발만 동동 구르는 경우도 줄어든다.

하지만 최고 위험 10가지 목록이 주는 가장 큰 효과는 모든 사람이 위험을 자기 머리나 가슴 속에 품어 꽁꽁 감추는 대신 공론화시켜 해법을 찾으려고 노력하는 분위기 개선이다. 프로젝트를 가로 막는 위험을 이야기한 사람에게 책임을 떠넘기는 대신 모두가 위험을 제압하기 위해 노력하는 모습은 생각만해도 아름답다. 팀이나 프로젝트 단위로 힘들다고? 그렇다면 매주 개인 별 최고 위험 10가지 목록을 정리해보고 변화 추이를 살펴봐라. 프로젝트 통제 과정에서 깜짝 놀랄만한 효과가 있을 것이다.

'소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 역자 박재호 올림

[공지사항] 소프트웨어 컨플릭트 2.0 본문 서체

2007-03-01T13:54:00.000+09:00

많은 분들께서 소프트웨어 컨플릭트 2.0 본문에 사용한 서체에 대해 질문을 해주셨습니다. 여러분의 궁금증을 풀어드리기 위해 몇 가지 질문과 대답을 정리해보았습니다.

Q: 본문 서체가 보통 책에서 찾아 보기 어려운데 무엇입니까? A: 한겨례 신문사에서 만든 한결체입니다. 한겨레 신문 독자 여러분께서는 지금 신문 글꼴과 책 글꼴을 비교해보시기 바랍니다.
Q: 왜 서체가 어색하게 보입니까? A: 기존 다른 책에서 사용하는 네모글이 아니라 탈네모꼴이기 때문입니다.
Q: 하필 탈네모꼴 서체를 사용한 이유는 무엇입니까? A: 처음에는 어색하지만 적응되고 나면 가독성이 높고 눈이 덜 피로하기 때문입니다. 또한 소프트웨어 컨플릭트 2.0과 같은 수필 종류와 잘 어울린다는 생각도 들었기 때문입니다.
Q: 앞으로도 계속해서 이 서체를 활용하실 계획이십니까? A: 출판사와 협의해서 되도록 수필 성격이 짙은 책에는 계속해서 적용해볼 생각입니다.

궁금증이 풀리셨나요? 책과 관련해서 다른 궁금증이 있으면 언제든지 역자에게 질문을 해주시면 블로그에 답변을 올려드리겠습니다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림

[공지사항] SC2.0 정오표

2007-02-28T19:10:00.000+09:00

역시 이번 소프트웨어 컨플릭트 2.0에도 오탈자가 상당히 많다는 사실을 깨닫고 급히 수선 작업에 들어갑니다. SC2.0 정오표를 정리해보았느니 확인해서 잘못핸 부분을 수정해서 읽어주시면 감사하겠습니다. 1차 오류 보고를 해주신 kks님과 2차 오류 보고를 해주신 고양이님께 감사드립니다. 소프트웨어 공학의 사실과 오해를 번역하신 '윤성준'님께도 오탈자 확인 감사 말씀 드립니다.

xix 각주 바로 위: 이 모든 사항을 고려하건데 --> 이 모든 사항을 고려하건대
xviii 역자 주 2번을 다음과 같이 수정해야 합니다: 노스 아메리칸 에비에이션은 한국전에서 미그 전투기 킬러로 맹활약했던 F-86 세이버 전투기 제작사이며, 아폴로 프로그램에서 사령선과 서비스 모듈을 개발한 회사이다. 1996년 보잉에 합병되었다.
xxi 저자는 미네소타 대학교(University of Minnesota) 대학교 철학 교수이자... --> 저자는 미내소타 대학교(University of Minnesota) 철학 교수이자
xxii 니콜라스 즈베진트조프에서: 컨설팅의 진짜 비밀' --> '컨설팅의 진짜 비밀'
xxiii 길레스 후버에서: opreydesign --> ospreydesign
5페이지 4문단 중간: 전문 영역로 --> 전문 영역으로
11쪽 6문단 3줄: 알고리즘 자체를 입력하는 경우라 아니라면, --> 알고리즘 자체를 입력하는 경우 가 아니라면,
16페이지 2문단 첫 줄: 논문 을 --> 논문을
19페이지 가장 아래 문단: 위 문구는 1980년대 후반 --> 1980년대 후반('위 문구' 삭제)
24페이지 중간: 점진적 개발과 프로토타이핑 --> 문단 들여쓰기를 앞으로
26페이지 첫 문단: 초점을 맞추는 새로운 관리 방식을 제안한다. --> 초점을 맞추는 다음과 같은 관리 방식을 제안한다.
33페이지 3문단: 그럼에도 이 시점에서 --> 이 시점에서('그럼에도' 삭제)
35페이지 중간: (예전 예일의) 미시건 대학의 --> 미시건 대학의 (예전 예일의)
38페이지 중간: 시물레이션해야 한다(중간 점 세개). --> 시물레이션해야 한다(중간 점 세개)
44쪽 중간: 결함 포용 소프트웨어 <--> 결함 허용
49페이지 첫째 줄: 현실보다 더 안좋은 이유는 소프트웨어 공학 업계에 옹호자가 넘쳐 나기 때문이다. --> 현실보다 더 나쁜 상황은 소프트웨어 공학 업계에 옹호자가 넘쳐 나는 넘쳐 나는 현실 이다.
49페이지 2문단: 하지만 의견과 옹호를 --> 그런데 의견과 옹호를
54페이지 표 1에서 비용 효율 항목에서 콜로펠로/우드필드: 3.테스트(가장 덜 비쌈) --> 3. 테스트(가장 비용 효율이 낮음)
94페이지 1문단: 전무가 --> 전문가
99페이지 3문단: 시장성 있는 제품 위에 얹어야 했다. --> 시장성 높은 제품이 되도록 제대로 만들어야 했다.
109페이지 2문단: selfware -> shelfware
125페이지 2문단: 포커스가 전자에 실패했다고 말한다. --> 포커스가 후자에 실패했다고 말한다.
131페이지 3문단: 사용자 자신이 문제 해결에 --> 사용자 스스로가 문제 해결에
132페이지 첫줄: 올해 기술자들이 --> 1989년 올 한해 기술자들이
136페이지 마지막 줄: 자료 처리 공동체라는 주제를 의도적으로 --> 자료 처리 공동체가 관심을 기울이는 주제를 의도적으로
167페이지 1문단: 우수성 표준 개발 --> 우수한 표준 개발
174페이지 3문단: 여러 구성요소를 분해할 수 있고 --> 여러 구성요소로 분해할 수 있고
178페이지 첫줄: 소프트웨어 제품에서 품질을 관리하기란 --> 나는 소프트웨어 제품에서 품질을 관리하기란
189페이지 옮긴이 주 15번: 장본인 --> 주인공
190페이지 4문단: 자료 처리 그룹이 단계를 거친다고 --> 자료 처리 그룹이 단계를 밟아 성숙해진다고(옮긴이 주: 성장 단계 모델은 http://en.wikipedia.org/wiki/Stages_of_growth_model를 참조하기 바란다)
190페이지 옮긴이 주 19번: 장본인 --> 주인공
199페이지 1문단: 어머나 - 숙어와 은어가 --> 어머나, 숙어와 은어가
202페이지 세째줄: BROM70] --> [BROM70]
212페이지 2문단: SLOP(Source Line of Published research Paper) --> SLOP(Source Line of published research Paper)
217페이지 4문단 끝: 판단하기이다. --> 판단하기다.
223페이지: 기술 이전 --> "기술 전파"
232페이지 첫줄: IEE --> IEEE
233페이지 마지막 문단: 소프트웨어 안전 --> (목숨이 걸린) 소프트웨어 안전
240페이지 마지막 직전 줄 : 마이크로소프 사 -> 마이크로소프트 사
250페이지 1문단: 사실을 사실을 --> 사실을
250페이지 1문단: 116퍼센트 향상했다. --> 116퍼센트 향상되었다.
254페이지 4문단: 고안했다고 --> 고안되었다고
256페이지 2문단: 고안한 다음에 --> 고안한 다음에도
256페이지 2문단: 오해하라는 뜻이리라 --> 오해하리라는 뜻이리라
259페이지 마지막 문단: 예측을 위한 알고리즘이 --> 예측을 위한 알고리즘도
259페이지 마지막 문단: 사람이 수행하는 예측이 낙관적인 만큼 --> 사람이 수행하는 낙관적인 예측만큼
260페이지 1문단: 검증했을지라도 --> 검증했을지라도,
263페이지 2문단: 소프트웨어와 늑대인간이 유사점이 많다고 본다. --> 소프트웨어를 늑대인간에 비유해서 설명한다.
265페이지 아래쪽 2번: 시판에 앞서 기다리는 중이라고 관리층이 --> 시판에 앞서 기다리는 중이라고, 관리층이
267페이지 마지막에서 2문단: 무작정 쫓아서 --> 무작정 좇아서
270쪽 8번: '칵테일 파티 미신' 8) 끝: 의미없는 'ㄴ' 제거
270쪽 중간: 하지만 한가지 고백하자면, --> 하지만 한 가지 고백하자면,
270쪽 중간 아래쪽: 구조적 접근 방법으로 개발자에게 가르치고 있다. --> 구조적 접근 방법으로 개발자를 가르치고 있다.
270쪽 하단: 개발 자동화에 대한 기대에 들떠서 자동화 도구를 --> 개발 자동화에 대한 기대에 들떠서, 자동화 도구를
271쪽 2문단: 실제가 이론을 앞서는 분야로 --> 실제가 이론을 앞서는 분야가 있으며,
272페이지 중간: 예측은 물론 오묘하다. --> 예측은 물론 희한한 사업이다.
281페이지 첫줄: 13 --> 13)
282페이지 중간: 즐거움이 한풀 꺽인 --> 즐거움이 한풀 더 꺽인
282페이지 마지막 문단: 14 --> 14)
에필로그 2문단: 영양가가 있는지이다. --> 영양가가 있는지다.
290페이지 1문단: 내용이 포함되어 있을 --> 내용도 포함되어 있을
300페이지 하단: paewang.net) --> 큰 폰트로 변경해야 함
301페이지 마지막 줄: 문제를 풀릴 --> 문제는 풀릴
306페이지 2문단: 제 4세대 프로그래밍 언어는 4세대에서 --> 제 4세대 프로그래밍 언어는 당대에서
308페이지 1문단: 프로그램을 작성을 위한 --> 프로그램 작성을 위한
308페이지 1문단: 이끌어내는 과정에서 --> 이끌어내는 과정에
308페이지 2문단: 들어가는 출구를 마련했다는 --> 들어가는 입구를 마련했다는
313페이지 마지막 문단: 어렵다는 사실을 --> 어렵다는 사실인
313페이지 마지막 문단: 누설한 탁월한 --> 누설한, 탁월한

혹시 다른 애독자 여러분께서도 오탈자를 찾으시면 저에게 편지를 보내주시면 검토 후에 올려드리겠습니다. 미리 감사 말씀 드립니다.

"소프트웨어 컨플릭트 2.0" 역자 박재호 올림

[1부 3번 수필] '은총알은 없다'

2007-02-24T22:03:00.000+09:00

컴퓨터 서적을 처음부터 끝까지 두 번 이상 완독하는 경우는 무척 드물다. 강압이 아니라 자발적으로 완독하는 경우는 더욱 드물다고 보면 틀림없다. 하지만 믿거나 말거나(!) '소프트웨어 컨플릭트 2.0'을 번역한 공역자 두 명 모두 프레드 브룩스가 지은 The Mythical Man-Month를 즐겁게 어러 번 읽었다. 이 훌륭한 책(1975년에 지은 책이다!)이 나온 다음에 20년이 흐른 다음 프레드 브룩스가 과거를 돌아보면서 현재 상황을 다시 분석한 논문이 바로 3번 수필에서 소개하는 은총알 논문이다(No Silver Bullet).

은총알 논문의 핵심은 바로

향후 10년동안 프로그래머 생산성을 10배로 향상시킬 은총알로 취급할만한 기술이나 방법은 존재하지 않을 것이다.

라는 도발적인 일갈이다.

프레드 브룩스는 부수적인 복잡성(accidental complexity)와 본질적인 복잡성(essential complexity) 중에서 부수적인 복잡성은 어떻게든 해결할 수 있지만 본질적인 복잡성은 해결하기가 무척 어렵다고 주장한다. 여기서 부수적인 복잡성은 우리 스스로가 만들어서 고칠 수 있는 문제에 대한 복잡성이고, 근본적인 복잡성은 문제 해결 자체에 내재했기에 근본적으로 제거하지 못하는 복잡성을 말한다. 어셈블리 언어에서 포트란 언어로 변화할 때 부수적인 복잡성을 상당한 범위까지 줄여버렸지만, 그 이후 C, C++, 자바 등이 나왔을 때는 포트란이 등장했을 때만큼 복잡성을 줄이지 못했기 때문에 부수적인 복잡성 관점에서 과거 비약적인 생산성 향상을 요즘 세대에서 기대하기는 어려워진 셈이다. 설상가상으로 본질적인 복잡성은 전혀 줄어들지 않았다. 오히려 날이 갈수록 본질적인 복잡성이 더욱 더 크지고 있기 때문에 결국 부수적인 복잡성과 본질적인 복잡성의 불균형으로 인해 은총알을 발견할 가능성이 점점 희박해지는 상황이다.

이런 눈물겨운 현실을 극복하기 위해 브룩스가 주장한 내용은 놀랍게도 개발자에게 용기를 복돋우도록 하는 '점진적인' 개발을 통한 유기적으로 "자라나는" 소프트웨어 개념이다. XP라는 최신 유행을 만든 멋쟁이들이 찾아냈다고 믿었던 바로 그 개념 말이다. 이래서 세상만사 돌고 도는 모양이다.

소프트웨어 컨플릭트 2.0 역자 박재호 올림

소프트웨어 컨플릭트 2.0에 관한 블로그 글

2007-02-09T05:17:00.000+09:00

소프트웨어 컨플릭트 2.0에 관한 블로그 글을 소개합니다.

Software Conflict(소프트웨어 컨플릭트) 2.0 베타리더 감상문 from fribirdz.net

소프트웨어 컨플릭트 2.0 : 시대를 뛰어넘는 즐거운 논쟁 from antilove.egloos.com

서평 - 소프트웨어 컨플릭트 2.0 from cosmochaos.blogspot.com

소프트웨어 컨플릭트 2.0 베타리딩 후기 from kaistizen.net

소프트웨어라는 열린 질문 from humbleprogrammer.net

Software Conflict 2.0 from tzara.wordpress.com

[예약 판매] 소프트웨어 컨플릭트 2.0 from blog.paewang.net

유지보수, 악순환의 고리? from Talk about Software with hani

교육과 훈련 from Blogging for nothing

도구와 목적 from 하느리 블로그

[책] 소프트웨어 컨플릭트2.0 from Core Error Pattern™

뛰어난 설계는 마음으로 하는 것 from 류한석의 피플웨어

좋은 글이 많아서 한군데 모아두고 싶었습니다. 각 분들 블로그에다가 여기에 링크 올렸습니다라고 일일이 답글 드리지 못해서 죄송합니다. 그리고 소개하고 싶은 글이나 자신의 글을 보내주시면 링크 걸겠습니다.

소프트웨어 컨플릭스 2.0 역자 이해영 올림

뱀다리) 요즘 In Search of Stupidity라는 책을 작업 중이라 한참 정신이 없습니다. 기장님께 책 난이도를 조정해 가면서 번역하자고 건의했건만...우리 기장님께서 욕심이 많으셔서 (퍽~! 기밀 누설!)... 계속 어려운 책만 작업하는 바람에 주름이 늘었습니다. ^^;;

[1부 2번 수필] 위험하며 오도하다

2007-02-05T06:46:00.000+09:00

16대 대통령 에이브러햄 링컨은 다음과 같이 말했다.

모든 사람을 잠시 속일 수도 있고, 일부를 영원히 속일 수도 있지만 모든 사람을 영원히 속일 수는 없다.

비슷하게 모든 부문에서 모든 사람에게 통하는 소프트웨어 생산성을 극대화시킬 수 있는 방법이 있다고 주장하는 말을 들을 수 있다. 유감스럽지만 일부 부문에서 특수한 사람들에게만 소프트웨어 생산성을 극대화할 수 있는 방법이 존재할 뿐이다. 이유는 무엇일까?

사람마다 각자 그럴듯한 이유를 내 놓았지만, 모듈화 개념을 처음으로 주창함으로써 소프트웨어 개발 수준을 한 단계 높인 데이비드 파나스 교수는 다음과 같이 날카롭게 소프트웨어 생산성에 특효약이 없다는 주장을 펼친다.

소프트웨어 생산성을 비약적으로 향상시킬 계기, 몇 배로 껑충 끌어올릴 방법은 무엇일까?

언어나 도구가 아니다.
자동 프로그래밍 방법론도 아니다.
소프트웨어 정형 검증도 아니다.
인공 지능도 아니다.
요즘 인기 있는 소프트웨어 연구 주제 어느 것도 아니다.

구닥다리 고민 같다구? 그렇다면 ruby on rails가 20분만에 블로그만들면 1주일 또는 1개월안에 프로젝트를 끝내게 할 수 있는가에 나오는 논쟁을 한번 살펴보기 바란다. 데자뷰가 느껴지지 않는가?

소프트웨어 컨플릭트 2.0 역자 박재호 올림