추가 적립 안내

이 책은 소프트웨어 개발 분야의 창의력에 관한 책이다. 저자는 소프트웨어 개발이 근본적으로 복잡한 문제를 해결하는 활동이며, 복잡한 문제를 해결하려면 창의력이 필요하다는 생각을 바탕으로 소프트웨어 창의력을 얘기한다.

체계를 중시하는 관리자와 학계, 그리고 자유로움을 중시하는 실무자 측면에서 바라보는 소프트웨어 개발을 창의력이라는 주제로 탐구해보고 정의한다. 또, 창의력이 조직과 소프트웨어 분야에서 차지하는 비중과 역할을 살펴보고, 다른 분야에서 배우는 창의력과 창의력을 기르는 방법도 소개한다.

- 출판사 제공 책소개

<소개>

이 책은 소프트웨어 개발 분야의 창의력에 관한 책이다. 저자는 소프트웨어 개발이 근본적으로 복잡한 문제를 해결하는 활동이며, 복잡한 문제를 해결하려면 창의력이 필요하다는 생각을 바탕으로 소프트웨어 창의력을 얘기한다.

체계를 중시하는 관리자와 학계, 그리고 자유로움을 중시하는 실무자 측면에서 바라보는 소프트웨어 개발을 창의력이라는 주제로 탐구해보고 정의한다. 또, 창의력이 조직과 소프트웨어 분야에서 차지하는 비중과 역할을 살펴보고, 다른 분야에서 배우는 창의력과 창의력을 기르는 방법도 소개한다.


<리뷰>

이 책은 다음과 같은 저자의 개인적인 절실한 느낌과 신념을 담고 있다.
- 소프트웨어 개발이 근본적으로 문제를 해결하는 활동이라 믿는다.
- 어떤 문제든 해결하려면 창의력이 필요하다고 믿는다.
- 소프트웨어 문제를 해결하는 활동은 어떤 활동보다도 아주 복잡하다고 믿는다.
- 그러므로 소프트웨어 문제 해결에 있어 창의력은 절대적이라고 믿는다.
- 서문에서

‘소프트웨어 크리에이티비티 2.0’에서, 인기 있는 저자인 로버트 L. 글래스는 중요하지만 이상하게도 외면받는 질문을 하나 던진다. 도대체 소프트웨어 공학과 컴퓨터 프로그래밍에서 창의력이 차지하는 역할은 무엇일까? 글래스는 자신의 전매특허인 평이한 문체와 연구와 개인 경험에 기반한 실질적인 접근 방법을 사용해서 함축적이면서도 광범위한 연구 주제를 다룬다. 몇 가지 예는 다음과 같다.
- 체계나 정형화는 유연성이나 애자일과 조화를 이루지 못할까?
- 소프트웨어 제작 과정에서 통제 방식과 실험 방식이 어떤 때 가장 효과적일까?
- 소프트웨어 조직에서 창의력을 발현할 수 있을까?
- 프로세스와 제품 중 무엇이 더 중요할까?
- 소프트웨어 분야에서 이론과 실제가 어떻게 상호 작용할까? 실무자와 학자가 좀 더 효과적으로 서로를 보완할 수 없을까?
- 창의력과 소프트웨어 설계 사이에 끊어진 연결 고리가 있을까?
- 소프트웨어 작업에서 ‘지적인’ 작업과 ‘사무적인’ 작업 사이에 균형은 무엇일까?
- 요즘에도 옛날에 느꼈던 즐거움을 찾을 수 있을까?

‘소프트웨어 크리에이티비티 2.0’에서는 ‘피플웨어’와 ‘소프트웨어 프로젝트에서의 리스크 관리’를 공동 집필한 톰 드마르코가 쓴 추천글과 로버트 L. 글래스가 새로 쓴 서문도 포함한다.


<추천 서평>

*피플웨어나 맨먼스 미신에 버금가는 기념비적인 책
- Rapid Development와 Code Complete 저자 스티브 맥코넬 (별 다섯)

소프트웨어 분야에서 창의력은 자주 언급되는 주제다. 하지만 대개는 진정한 창의력에 기여하는 요소를 거의 모르면서 그리고 소프트웨어 개발에서 창의력이 차지하는 중요성을 피상적으로 이해하면서 창의력을 거론한다.

여기저기서 제대로 이해하지 못하고 거론할지라도 한 가지 사실은 분명하다. 소프트웨어 개발에서 창의력은 아주 중요한 주제라는 점이다. 그리고 이 독창적인 책은 창의력이 중요한 이유와 창의력을 높이는 방법을 분명하게 설명한다.

이 책은 체계 대 유연성, 정성 대 정량, 프로세스 대 제품, 이론 대 실무 등 서로 상충하는 개념을 비교하고 분석한다. 깔끔하라고 일부러 짜맞춘 구조가 아니다. 각 개념 쌍은 소프트웨어 분야에서 오랫동안 지속되었으며 앞으로도 지속될 ‘본질적인 긴장’을 표현한다. 이런 ‘본질적인 긴장’에서 야기되는 지적인 활력은 연구를 자극하고 논쟁을 불붙여서, 장기적으로 소프트웨어 업계를 발전시키는 동력이 되어 왔다. 글래스는 서로 상충하는 견해를 탐험하면서 양쪽 진영이 소프트웨어 분야에 기여하는 가치를 (보기 드물게) 인정한다.

글래스는 글 쓰는 스타일이 가볍다. 그래서 때로는 독자가 사안의 중요성을 인식하지 못하고 넘어갈 위험이 다분하다. 이장저장 뒤적이며 재미있게 읽고 나서 (심각하게 생각하지 않고) 던져버리기 십상이다. 나중에 (애자일 광신도와 프로세스 광신도가 토론하는 모습을 보거나 학계 연구자가 실무 실정을 한탄하는 논문을 읽으면서) “아무도 진짜 문제를 이해하지 못하는군”이라는 생각이 들 때야 비로소 이 책에서 흔치 않은 강력한 통찰력을 얻었다는 사실을 자각하리라.

물론 완벽한 책은 없다. 이 책은 지난 40여 년에 걸쳐 글래스가 쓴 글을 모았다는 사실이, 그리고 일부는 거의 혹은 전혀 수정하지 않았다는 사실이, 가장 큰 단점이다. 개인적으로는 글래스가 더 많은 수필을 손봤으면 좋았으리라 생각하지만, 그럼에도 불구하고 '오래된' 수필 대다수는 오늘날 독자들도 충분히 공감할 사안을 다룬다. 글래스의 논지가 시류를 타지 않는다는, 즉 소프트웨어 개발의 본질을 꿰뚫는다는 사실을 다시 한 번 보여주는 예라 하겠다.

글래스는 아주 개인적인 시각으로 글을 쓴다. 그래서 일부 독자들은 글이 너무 자의적이라 느낄지도 모르겠다. 주제를 다루는 깊이도 다소 일관적이지 못하다. 좀 더 깊이 다뤄주면 좋았겠다는 부분이 있는 반면, 너무 깊이 다루었다 여겨지는 부분도 있다.

하지만 몇 가지 단점에도 불구하고 이 책이 제기하는 사안과 글래스가 보여주는 통찰력이 우리 분야에 시사하는 가치는 전혀 달라지지 않는다.

1995년에 나온 소프트웨어 크리에이티비티 1판은 지금까지도 내가 가장 좋아하는 책 10권 안에 든다. 소프트웨어 크리에이티비티 2.0은 더욱 세련되고, 더욱 읽기 좋고, 첫 판 이후로 저자가 10년 동안 쌓은 경험과 지혜가 묻어난다. 소프트웨어 크리에이티비티는 피플웨어나 맨먼스 미신처럼 소프트웨어 개발의 핵심을 정확하게 꿰뚫는다.

소프트웨어 분야에 몸담은 50여 년 동안 로버트 글래스는 우리에게 많은 선물을 안겨줬다. 이 책은 그가 우리에게 안겨준 가장 기념비적인 선물 중 하나다. 강력히 추천하는 바이다.


*죄책감을 버려라!
- irotas(미국 메사추세스) (별 다섯)

이 책은 별 10개도 부족하다.

이 책에 대해서 할 말은 아주 많지만, 개인적으로 가장 큰 소득을 꼽으라면, 엄격한 소프트웨어 프로세스를 따르지 않는 죄의식에서 해방되었다는 점이라고 하겠다. 마음 한구석에서는 내가 배운 소프트웨어 프로세스가 실용적이지 않다는 사실을, 그리고 많은 경우 현실성도 없다는 사실을 진작에 알았다. 하지만 학교에서 유일한 방법이라 배운 탓에 프로세스를 정확히 따르지 못한다는 죄책감에 항상 시달렸다.

글래스는 실무자 입장에서 엄격한 소프트웨어 프로세스와 창의력을 죽이는 관리 스타일이 어째서 문제인지 단호하게 밝힌다. 또한 그는 소프트웨어 프로세스 발전사를 돌아보며 우리가 만족스러운 해법에 도달하려면 아직 멀었다고 말한다.

글래스의 주장에 귀를 기울일 이유가 무엇이냐고? 우선 그는 현재 대다수 소프트웨어 개발자가 세상에 태어나기 전부터 소프트웨어 업계에서 일했다. 또한 학계에서도 오랜 시간을 보낸 덕택에 양 진영을 바라보는 시각이 공평하고 진위를 가리는 통찰력이 뛰어나다. 하지만 무엇보다 그가 하는 말이 옳다. 아주 드물지만 너무나 공감을 일으켜서 진실이 아니라 부인하기 어려운 글을 만나는데, 현실에 낙담한 소프트웨어 개발자라면 이 책이 그 중 하나다.

소프트웨어 프로세스와 관리에서 창의력의 역할을 정직하게 평가한 글래스의 용기에 박수를 보낸다. 그 와중에 적도 생겼겠지만, 덕분에 우리 분야는 한 걸음 발전할 기회가 생겼다.

요약하자면, 소프트웨어 분야에 종사하면서 우리 분야 미래를 걱정한다면 이 책을 구입해서 처음부터 끝까지 꼼꼼하게 읽으라고 권한다. 여러분의 내공과 우리 분야의 수준이 한 단계 올라가리라.


*소프트웨어에서 실용적인 사고
- McKenna(미국 캘리포니아) (별 다섯)

우리 소프트웨어 분야에서는 실용적인 개념이 광신도 실무자 무리에게 희생당하는 사례가 너무도 흔하다. 그들은 클릭 몇 번으로 프로그램이 만들어진다는 만병통치약을 신봉하며, 좋은 프로세스만 있으면 개발자가 무능해도 좋은 제품이 나온다는 이상을 추종한다. 너무도 많은 사람들이 자신들의 아이디어와 방법론을 만병통치약이라 선전한다. 그들은 소프트웨어를 공장 프렌차이즈 정도로 여긴다. 생산 라인에서 부품을 교체하고 조립하면 소프트웨어가 뚝딱 만들어지리라 생각한다. 많은 사람들이 소프트웨어가 창의적인 노력이라는 생각을 배척해왔다. 하지만 우리 분야에서 날카롭기로 정평 난 로버트 글래스는 이 멋진 책에서 소프트웨어 개발에 창의력이 필수불가결하다는 주장을 펼친다. 이 책은 1995년에 나왔던 '소프트웨어 크리에이티비티' 첫 판을 개정한 책이다. 첫 판은 오랫동안 (저렴한 가격으로) 구하기 어려웠다.

이 책은 4부로 나누어진다. (내가 가장 중요하다고 생각하는) 1부는 소프트웨어 창의력을 탐험한다. 여기서 그는 (체계 대 유연성, 정형 기법 대 경험 기법, 최적화 대 만족화, 정성 대 정량, 프로세스 대 제품, 지적인 업무 대 사무적인 업무, 업계 대 학계, 재미 대 진지라는) 9가지 상반되는 개념을 다루면서 양쪽 입장을 살펴보고 답을 찾으려고 애쓴다(때로는 더 많은 질문을 제기한다).

정량 대 정성, 업계 대 학계 등 여러 장은 소프트웨어만이 아니라 다른 분야에도 통한다는 사실이 매우 흥미롭다. 비즈니스 분야에서 MBA가 정량적인 추론을 시도하다가 실패하는 사례가 어디 한두 번이던가? (법학 박사 학위와 실제 법정 경험이 다르듯이) 학계와 실무는 어떻게 다를까? 각 장은 짧다면 짧고 길다면 긴 재미난 주제로 가득 차 있다.

2부는 창의력을 끌어내는 방법을 소개한다. 대기업은 사고 방식 자체가 달라지므로 창의력을 발휘하기가 어렵다. 하지만 작은 기업은 창의력이 필수적이다. 3부는 다른 분야에서 발견한 창의력을 소개하며, 4부는 결론을 내린다. 결론을 귀띔하자면 글래스는 자신의 생각을 한 마디로 이렇게 요약한다. “프리사이즈 접근 방식은 틀렸다. 아니, 그냥 틀린 정도가 아니다. 확실히 틀렸다!” 이제 남은 질문은 하나다. 이미 답을 모두 안다고 생각하는 실무자의 마음을 어떻게 바꿀까?

나는 1판을 읽지 않았다. 최근 글래스가 쓴 ‘소프트웨어 공학의 사실과 오해’를 선물로 받고서야 그의 글을 처음으로 접했다. 그리고 그가 보여주는 실용적인 관점에 푹 빠져버렸다. 간결하면서도 함축적인 글쓰기 스타일이 마음에 들어서 d.*가 책을 출간하자마자 바로 구매했다. 소프트웨어 크리에이티비티는 프레드릭 브룩스의 ‘맨먼스 미신’이나 에드워드 요돈의 ‘죽음의 행진’(과 기타 작품)만큼 널리 알려지진 않았지만, 소프트웨어 분야에 몸담은 사람이라면 반드시 읽어볼 책이라고 생각한다. 물론 나는 공정한 입장이 아니다. 오랜 시간 소프트웨어를 개발하면서 구조적인 창의력이 매우 어렵고도 보람된 노력이라는 사실을 깨달았으므로. 로버트 글래스도 나와 같은 생각임에 분명하다.

1 규율 대 유연성

1.1 소프트웨어 분야의 진정한 헨리 포드를 찾습니다!
1.2 소프트웨어 자동화, 가능할까 사기일까?
1.3 프로그래머는 정말로 ‘통제불능’일까?
1.4 체계는 나쁜 말일까? 소프트웨어 생명주기 이야기
1.5 소프트웨어 설계 위조하기
1.6 애자일 프로그래밍, 유연성이 무르익다
1.7 교정원 연필에 얽힌 황당한 사건
1.8 파루틴 지수
1.9 체계와 창의력이라는 기묘한 단짝

2 정형 기법 대 경험 기법

2.1 논쟁을 명백히 밝혀보자
2.2 죄책감 없이 소프트웨어 개발하기
2.3 정형 기법: 극적인 (성공, 실패) 이야기 하나
2.4 정형 기법을 넘어서
2.5 정형 기법에 대해서 독자들이 보낸 의견

3 최적화와 만족화

3.1 BIEGE 원칙으로 문제를 해결하라
3.2 충분한 소프트웨어
3.3 땜빵을 옹호하며
3.4 미하일 고르바초프와 소프트웨어 생산성 (!?)

4 정량 추론 대 정성 추론

4.1 측정하지 못하면 관리하지 못한다. 정말?
4.2 수학과 전산학자
4.3 의사결정에서 직관의 역할
4.4 숫자도 숫자 나름이다

5 프로세스 대 제품

5.1 좋은 프로세스가 좋은 제품을 내놓을까?
5.2 좋은 프로세스가 좋은 제품을 내놓을까? 두 번째 의견
5.3 위대할 뻔한 이야기
5.4 소프트웨어 프로세스, 잡다한 생각 몇 가지
5.5 프로세스 대 사람, 좋은 제품 만들기
5.6 CMM을 적용한 결과 둘러보기
5.7 제품 대 프로세스, 언제 무엇에 집중할까?

6 지적인 업무 대 사무적인 업무

6.1 소프트웨어 만들기, 쉬울까? 어려울까?
6.2 소프트웨어 업무, 지적일까 사무적일까...... 아니면 창의적일까?
6.3 아주 그릇된 이유로 혁신 개념 사들이기

7 이론 대 실무

7.1 이론이 먼저일까? 실무가 먼저일까?
7.2 다시 생각하는 이론 대 실무
7.3 이론과 실무, 심난한 예제
7.4 뒝벌의 비상
7.5 이론 대 실무, 다양한 유감
7.6 소프트웨어 실무가 소프트웨어 이론을 앞서는 부문 정리

8 업계 대 학계

8.1 흥미 대 유용성
8.2 개인 대 팀
8.3 유행어 둘
8.4 이해와 인정과……정형 기법
8.5 구조적 연구라고?
8.6 말하기 대 듣기
8.7 미적미적 위원회
8.8 엄밀성 대 실용성

9 재미 대 진지

9.1 재미와 권태
9.2 오픈소스, 돌아온 재미
9.3 특이한 프로젝트
9.4 잃어버린 재미를 찾습니다

10 소프트웨어 조직과 창의력

10.1 그리스 대 로마, 판이한 소프트웨어 문화
10.2 통제와 기업 문화
10.3 혁신과 관리
10.4 창의력과 전략 정보 시스템
10.5 창의력 대 법

11 창의력과 소프트웨어 기술

11.1 정보 시스템을 구현하는 창의적인 기법
11.2 창의력과 소프트웨어 설계, 빠진 고리
11.3 사례 연구, 창의력이 현실을 만나다

12 소프트웨어 역사와 기념비적인 사건

12.1 첫 번째 기념비적인 사건
12.2 이후 ‘은총알’ 사건
12.3 창의력 대 절차화

13 조직적인 창의력
14 창의적인 사람
15 컴퓨터와 창의력
16 창의력 모순
17 항상 그랬다
18 상승적 결론
19 기타 결론

A 특별 부록(로버트 L. 글래스 대담 기사)
B 특별 부록(성공/실패 조건)
C 베타리더 한마디

무엇을 상상하든 그 이상을 보게 될 것이다

형만한 아우가 없다는 속담이 있다. ‘소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁’이 2007년 초반에 나와서 독자 여러분의 많은 사랑을 받았기에, 어떻게 보면 후속 작품인 ‘소프트웨어 크리에이티비티 2.0’은 아무래도 형의 그늘에 묻힐까 부담스럽다. 하지만 매트릭스 2편에 사용했던 “무엇을 상상하든 그 이상을 보게 될 것이다”라는 광고 문구는 바로 이 책에 딱 맞는 듯이 보인다. 여러분들이 소프트웨어 창의력과 관련해서 무엇을 상상하거나 이 책은 여러분의 상상력을 확실히 뛰어넘는 창의력을 보여준다.

이 책 초판은 아마존에서 아주 흥미로운 기록을 세웠었다. 판매 부수와 판매 순위가 아니라, 절판 후 중고로 올라온 책 가격이 바로 주인공이다. 해커들 사이에서 이 책은 권장 도서가 아닌 필독서라는 소문이 퍼져나가면서 1000불 넘게 호가가 올라갔다(2판이 나오고 나서도 한동안 999불을 유지했다). 소프트웨어 분야 서적은 시간이 지남에 따라 점점 가치가 떨어져서 나중에는 종잇값도 제대로 받지 못하는 상황에서 이렇게 옛날 책이 인기를 끈 이유는 소프트웨어 창의력을 다루는 책이 사실상 없었기 때문이다. 우리 분야에서 해당 주제를 다루는 유일한 책이니 당연히 가치가 높을 수밖에.

하루하루 철야에 특근에 개발하기도 바쁜 상황에서 소프트웨어 창의력이라는 주제가 도대체 우리에게 무슨 의미인지 냉소적인 시선을 던지는 사람도 틀림없이 있을 것이다. 하지만 나를 알고 적을 알면 백전 백승이라는 말이 있듯이, 소프트웨어 본질을 알아야 제대로 된 개발이 가능하다. 역자는 여러 해 동안 소프트웨어를 개발하는 과정에서 업계, 학계, 정부 기관에 속한 그야말로 다양한 사람들을 만나보았다. 개발 작업이 진행되는 도중에 “모두 소프트웨어에 대해 정말로 다른 생각을 품고있는 이유가 도대체 무엇일까?”라는 궁금증이 들 때마다 이를 속 시원하게 풀어주는 사람이 없어 답답한 적이 한두 번이 아니었다. 그렇지만 바로 이 책을 읽고 나서 그 동안 물음표 기호로 남겨 놓았던 많은 의문이 풀려버렸다. 이제는 생각이 다른 사람을 만나서 이야기를 하는 도중에 답답하고 화가 나는 대신 속으로 크게 웃으며 표정을 관리하느라 정말 바쁘다. 스티브 맥코넬이 아마존에 올린 장문의 서평에서 밝히듯이 흔치 않은 강력한 통찰력을 얻었기 때문일까? 아니면 나도 나이를 먹어서 둥글둥글하게 사람이 변했기 때문일까? 어찌 되었거나 다른 사람들이 소프트웨어를 바라보는 시각을 이해한다면 당연히 소프트웨어 개발을 둘러싸고 갈등이 일어나는 근본 원인도 찾아낼 수 있으리라.

역자 혼자서 읽고 즐기기에는 너무나도 좋은 내용이 많이 담겨 있기에, 소프트웨어 개발의 본질이 무엇인가를 고민하고 있는 사람이라면 누구나 이 책을 꼼꼼하게 들여다보기 바란다. 소프트웨어 본질을 탐험할 기회는 절대로 흔하지 않으며 앞으로도 접하지 못할 가능성이 더 크다는 현실이 서글프지만 이런 답답한 상황을 한방에 해소하도록 2판에 이어 번역서까지 나온 상황이므로 업계와 학계에서 오랫동안 산전수전 공중전을 다 겪은 글래스 할아버지가 여러분에게 특별히 선사하는, 살아 숨쉬는 교훈을 절대로 놓치지 말자.
- 옮긴이글에서