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

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

 

추천사

톰 디마르코

소프트웨어 업계는 오랫동안 권위주의와 자유주의라는 두 진영으로 분열되어 논쟁을 벌여왔다. 한쪽은 “규율”과 “체계”와 “통제”를 떠받들고, 다른 한쪽은 “기민함”을 숭배한다. 이러한 정신분열증은 소프트웨어 프로세스라는 주제를 너무도 복잡하게 만들었다. 사람들은 상대편과 대화를 나누기보다 상대에게 자기 의견을 주장하느라 바빴다. 보수와 진보로 양분된 정치판과 마찬가지로, 극단주의자들이 목소리를 드높이는 바람에 중용적인 입장은 별로 주목 받지 못했다. 하지만 실제로 소프트웨어 세상에서 멋진 성과를 내놓은 사람들은 권위주의자와 자유주의자 사이에 선 중용주의자였다.

밥 글래스는 중용주의자를 대변하는 입장에서 우리에게 커다란 교훈을 가르친다. 소프트웨어 창의력 2.0을 통해 그는 양 극단으로부터 장점을 취하는 합리적인 접근 방식을 소개한다. 또한 목소리 큰 극단주의자가 고집하는 방향이 아니라 프로젝트 특성에 맞는 방향으로 개발에 접근하라는 윤리도 일깨운다.

언젠가 내 친구이자 동료이며 90년대 애플 사에서 OS 개발 프로젝트를 주도했던 쉘라 브래디와 저녁을 먹었는데, 그녀는 여성이 관리층에 진입하기 위해서 넘어야 할 장벽을 열 내서 설명했다. “관리는 기본적으로 아버지가 모델이죠.”라고 그녀는 말했다. 우리가 가장 처음으로 경험하는 관리는 가족 내에서 이뤄지는 관리, 즉 아버지가 대빵인 환경이라고, 그래서 우리는 관리자를 아버지처럼 여긴다고 그녀는 덧붙였다. 부모-자식 관계가 권위적인 경향이 다분하므로 관리자도 자연스럽게 권위적인 성향을 보인다는 뜻이었다. 이런 배경에서 전형적인 알파 남성 관리자가 탄생하며, 여성도 우수한 관리자가 될 가능성이 있지만 결코 알파 남성 같은 관리자가 되기는 어려우리라고 쉘라는 말했다.

오늘날 소프트웨어 조직을 관리하는 우리 중 많은 수가 한 세대 전에 관리자로 일했던 아버지 밑에서 자랐다. 그러니까 우리에게 처음으로 관리라는 개념을 심어준 사람은 가장으로서 아버지였고, 이를 좀더 성숙한 개념으로 키워준 사람은 관리자로서 아버지였다. 옛날 아버지가 해주셨던 사무실 이야기나 공장 이야기가 오늘날까지 우리 마음 속에 남아서 기회가 닿을 때마다 우리 업무에 교훈을 들이민다. 상황에 맞든 맞지 않든 말이다.

예를 들어, 우리 아버지는 주물 공장 관리자로 일하셨는데, 그의 영웅은 (과학적 관리론을 주장한) 테일러와 (동작 시간 관리론을 주장한) 길브레드였다. 그래서 아버지와 내가 관리를 논하면 두 사람 의견은 남북한만큼이나 뚜렷하게 갈렸다. 예를 들어, 우리 아버지는 “교체가 불가능한 직원”이라는 개념을 극도로 혐오했다. “나한테 교체가 불가능한 직원이 있다면 당장에 해고할거다!” 우리 아버지는 산업화 시대를 거치며 잔뼈가 굵었고, 나는 정보화 시대를 거치며 머리가 굵었다. 시대가 다른 만큼 관리라는 개념도 판이하게 달랐다.

하지만 정보화 시대 관리가 산업화 시대 관리를 단순히 대체했다고 생각하면 금물이다. 산업화 시대를 풍미했던 관리 개념은 현대 조직에 깊숙이 각인되어 아직도 남아 있다. 그 탓에 우리는 공장식 관리론을 성배처럼 추구한다. 조직에 변화를 주려고 수행하는 체계적인 활동 그 자체를 체계화하겠다고 나선다. 무엇보다 그 탓에 우리 스스로 충돌하고 분쟁한다. 합리적인 토론은 경멸과 비방에 묻혀서 사라진다.

당신은 무법자야!”

“그러는 당신은 간섭꾼이야!”

“해커!”

“독재자!”

설상가상으로 학계는 양비론을 펼치며 상황을 악화시켰다. 한편에서 경험주의자들과 인지심리학계는 재능이 방법론보다 중요하다는 사실을 재차 밝혀냈다. 그들에 따르면, 아주 뛰어난 소프트웨어 개발자가 있는 반면, 뛰어난 동료가 사용하는 방법론을 아무리 모방해도 뒤쳐지는 개발자가 있었다. 다른 한편에서 정형주의자들은 소프트웨어를 개발하는 최선의 방법 하나가 존재한다고 단언했다. 너무도 체계적이어서 단정적으로 입증이 가능한 방법, 너무도 체계적이어서 그대로 공장을 세워도 좋은 방법이 존재한다고 주장했다.

그런데 진짜 세상은 따로 있었다. 그리고 밥 글래스는 이런 진짜 세상에서 빛을 발한다. 소프트웨어 창의력에 담긴 그의 생각은 사려 깊고, 체계적이며, 설득력 있다. 게다가 자신이 주창하는 아이디어를 집필 자체에다 적용한 탓에 책 곳곳에서 창의력이 번득인다. 예를 들어, “사다리꼴”이라는 단어가 처음 나오는 장을 눈 여겨 살피기 바란다. 자유주의자 진영에서 매섭게 날아와 매혹적이고 풍미로운 느낌을 안겨주고 스쳐가는 사고(思考)의 향기를 맡으리라.

21세기는 세계화, 극적인 변화, 치열한 경쟁으로 대변되는 시대다. 그래서 우리 모두는 창의력이 그 어느 때보다 중요하다는 사실을 안다. 그러다 보니 창의력을 거론하는 입바른 사람이 부쩍 늘어났다. 다들 말은 번지르르하다. 요즘 회사치고 관리층이 창의력과 그 중요성을 침 튀기며 역설하지 않는 회사는 드물다. 하지만 대개가 그뿐이다. 이 책을 계기로 나는 우리 업계가 창의력을 조금이라도 행동으로 실천하게 되기를 바란다.

 

서평

"피플웨어나 맨먼스 미신에 버금가는 기념비적인 책"

-- Rapid Development와 Code Complete 저자 스티브 맥코넬(미국 워싱턴) (별 다섯)

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

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

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

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

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

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

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

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

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

 

"죄책감을 버려라"

-- irotas(미국 메사추세스) (별 다섯)

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

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

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

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

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

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

 

"소프트웨어에서 실용적인 사고"

-- Shawn McKenna (미국 캘리포니아) (별 다섯)

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

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

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

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

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

 

배타리더 서평

CLT 김형준

전작인 '소프트웨어 컨플릭트 2.0'이 다년간의 학계 또는 현장 경험 없이는 모든 내용을 공감하며 읽기 어려웠던 데 비해 이 책은 일단 그런 제약치가 거의 없습니다. 또한 소프트웨어 전반의 다양한 논쟁을 들쑤셔놓던 것에 비해 '창의성'이라는 한 놈만 잡아 둘러치고 메어치니 주제를 접하는 맘 부담도 훨씬 적지요. 그래도 전작의 장점은 여전히 생생히 살아 있습니다. 형이상학적(?)인 주제가 되기 쉬움에도 불구하고 여전히 생동감 있게 펼쳐지는 내용은 그의 고민과 애정이 여전히 현장에 있음을 알 수 있게 하죠. 게다가 주제 자체가 '창의성'이다 보니 앤드류 헌트가 이전 책 추천사에서 언급했던 '사고를 키워주는 양식'이란 면이 이 책에 와서 더더욱 돋보입니다.

아... 그런데 그의 딴 책 안 본 이들도 많을 테니 이 책 자체의 가치도 잠깐 따로 말하지 않으면 안되겠군요. '창의성'에 대한 글래스의 생각을 알고 싶다면 톰 디마르코가 꼽은 '사다리꼴' 문제만 찾아보셔도 됩니다. 하지만 정말 이 책에서 놓치지 말아야 할 점은 책 전체를 관통하는 올바른 질문 던지는 법과 결과에만 집착하지 않고 (논쟁의) 과정을 추적하는 속에서 논제 자체를, 결국은 자신의 사고 틀 자체를 확장해 나가는 그 흐름이지 않나 싶네요.

끝으로 책의 가치 확인할 수 있게끔 끝까지 읽게 지긋이 이끌어주신 두 역자분의 배려에 대한 감사 인사 전합니다(베타리더 소임 다 못해 손발이 계속 오그라들거 같은 미안함, 이 인사로 대신합니다 ^^;)

 

강호관

역사에 무관심했을 때, 100년 전의 사람들은 정말 무식했을 것이라 생각했다. 아니, 미개했을 것이라고 생각하기도 했다. 하물며 500년 전의 사람들이야... 불문가지다. 요즘 IT 업계에서, 인터넷이라는 용어가 아직은 생소했던 1990년대 초반의 이야기를 한다면, 당연히 아주아주 원시적인 시기의 이야기로 받아 들일 것이다. 그들에게 1950년대 이야기를 한다면... 그 때도 컴퓨터가 있었냐는 반응이 안 나오면 다행일 것이다. 하지만, 교양 수준으로라도 500년 전의 문화에 대해 알게 된다면, 지금과 당시가 삶의 많은 부분에 있어서 그리 많이 다르지 않음을 알게 된다. 마찬가지로 컴퓨터라는 것에 얽힌 이들의 삶은, 어떤 측면에서는 50년 전이나 지금이나 크게 다르지 않다. 때문에 50년도 넘는 연륜을 가진 선배의 이야기는 충분히 마음과 귀를 열고 들을 가치가 있다. 게다가 고리타분하고 쉰내 나는 훈시가 아니라, 잘 곰삭아서 시원하기까지 한 위트가 있는 이야기는 듣는 이의 눈과 귀를 환하게 해줄 것이다.

 

심보형

"창의력을 찾아서.."

파랑새를 찾아 나섰던 남매의 이야기를 안다. 최근 우리 한국 IT에도 이런 파랑새가 등장했다. 바로 창의력이다. IT 기업에서 첫 번째로 꼽히는 인재상이 '창의'이고, 매시업과 소셜 네트워크, 오픈마켓 등 IT 추세에 따라 창의력은 큰 무기가 되고 있다. 하지만 우리는 창의력을 잘 모른다. 하나 예를 들어보자. 굴지의 IT 기업에서 취업 인터뷰를 진행하고 있다.

"당신은 창의적인 엔지니어인가요?" "네" "어떤 점이?" "...."

미안하지만 대다수가 쉽게 대답할 수 없다. 우리는 창의력을 잘 모르기 때문에...

일전에, 창의력에 대해 수다를 나눈 적이 있다. 우리는 이야기를 나눌수록 질문의 늪에 빠졌다. IT 분야에서도 창의력이 필요할까? 나의 업무 중 반복 업무를 단축시키도록 하는 게 창의적일까? 경험이 창의력 발휘에 도움이 되나? 어느 경우에 창의력이 발휘되지? 나의 업무 중 창의적인 업무 비율은?

해답은 <소프트웨어 크리에이티브 2.0>에서 찾을 수 있을 것이다. <소프트웨어 크리에이티브 2.0>을 읽고, 다시 한 번 수다를 나누고 싶다.

 

늘벗

학교에서 10년 가까이 소프트웨어 공학을 공부하면서 ‘정형 기법’에 익숙해 있던 제게, 실전에 바탕을 둔 글래스 할아버지의 ‘경험 기법’ 이야기는 새로운 자극이었습니다. 특히, 이해(understanding)와 인정(acceptance)을 구분하여, 학계에서 야심 차게 제안한 개념을 업계에서 받아들이지 않는 이유는, 실무자가 이해하지 못해서가 아니라 인정하지 못해서라는 설명이 무척 마음에 와 닿았습니다. 소프트웨어 공학을 적용함에 있어서, 개념을 설명하여 이해를 시키는 것으로 끝나지 말고, 근거를 제시하여 인정을 받는 노력을 함께 해야겠다고 다짐해 봅니다.

 

권일경

소프트웨어 창작을 업으로 하고 계시는 많은 분들과, 저처럼 그걸로 돈을 벌 실력은 되지 않지만 관심이 많고 틈틈이 코드를 만지작거리는 사람들에게 '창의적인 소프트웨어를 만드는 일'은 상당히 솔깃한 주제입니다. 내 자식이 다른 아이들보다 더 뛰어나길 바라는 일반적인 부모의 마음과 다르지 않다고 생각합니다. 하지만, '어떻게 창의적인 소프트웨어를 만들 것인가?' 하는 건 여전히 실마리가 잡히지 않는 물음입니다.

이 책은 이에 대한 해답을 주는 책은 아닙니다. '소프트웨어 창의성, 일주일만 하면 XXX만큼 한다' 거나 '창의적 소프트웨어 무조건 따라하기' 하는 식의 방법론을 통하여 처음 소프트웨어라는 것을 만들기 시작하다 어느 순간 '뭐 좀 쌈박한 걸 만들어 보고 싶다'거나 '내 실력이 제자리걸음하는 이유가 뭘까?'하는 고민을 시작하신 분들이 읽으면서, 나름 경험을 통하여 확고하게 가지고 있던 자신만의 방법론을 다른 관점에서 고민하고 평가해 볼 수 있는 기회를 주는 책이라고 생각합니다.

하지만, 글래스가 쓴 책은 어렵습니다. 경험과 직관이라는 도구를 이용하여 잠깐 보고 지나쳐 버릴 일들도 아주 다양한 관점에서 이리저리 굴려 보기 때문인 것 같습니다. 현업과 학계 경험이 풍부하다고는 하지만, '자상하지만 통찰력 있는 교수팀이 가르쳐 주심에도 불구하고 어려운 과목의 수업을 듣고 있는 듯'한 저자의 글쓰기 스타일도 한몫 한다고 생각합니다. 계속해서 질문을 던지기 때문에 제게는 흔들리는 버스 안에서 읽기는 쉽지 않은 책이었습니다. 이 책을 손에 드신 분들은 주말이나 휴가 등 자신만의 시간을 확보하신 후에 천천히 되새김질 하며 읽으시길 추천합니다. 출퇴근 길에 읽다가 정류장을 놓칠 수도, 자기 전에 읽다가 머리가 복잡해져서 잠을 설치실지도 모르겠습니다. :-)

 

임현수/프리버즈

당신이 만약 관리자에게 "개발자를 관리하고 통제하려고 하지 마세요. 소프트웨어 개발은 창의적인 작업이란 말이예요!" 라고 말하고 싶었지만 논리적 근거가 부족했던 개발자였다면, 이 책을 읽고 전투력을 높이길 바랍니다. 아, 농담입니다. 하지만, 이 책에서 이야기하는 (고리타분하지만 여전히 논쟁거리인) 정형기법과 귀납법, 최적화와 만족화, 정량추론과 정성추론, 프로세스와 제품, 이론과 실무와 같은 논쟁거리에 대한 글래스의 견해를 읽어보세요. 때론 공감하고 때론 의문을 품으며 곰곰이 생각해본다면 좀 더 창의적이면서 덜 실패하는 소프트웨어 개발에 다가설 수 있으리라 생각합니다.

이 책은 다음과 같은 저자의 개인적인 절실한 느낌과 신념을 담고 있다.

  • 소프트웨어 개발이 근본적으로 문제를 해결하는 활동이라 믿는다.
  • 어떤 문제든 해결하려면 창의력이 필요하다고 믿는다.
  • 소프트웨어 문제를 해결하는 활동은 어떤 활동보다도 아주 복잡하다고 믿는다.
  • 그러므로 소프트웨어 문제 해결에 있어 창의력은 절대적이라고 믿는다.

-- 서문에서

소프트웨어 크리에이티비티 2.0에서, 인기 있는 저자인 로버트 L. 글래스는 중요하지만 이상하게도 외면받는 질문을 하나 던진다. 도대체 소프트웨어 공학과 컴퓨터 프로그래밍에서 창의력이 차지하는 역할은 무엇일까? 글래스는 자신의 전매특허인 평이한 문체와 연구와 개인 경험에 기반한 실질적인 접근 방법을 사용해서 함축적이면서도 광범위한 연구 주제를 다룬다. 몇 가지 예는 다음과 같다.

  • 체계나 정형화는 유연성이나 애자일과 조화를 이루지 못할까?
  • 소프트웨어 제작 과정에서 통제 방식과 실험 방식이 어떤 때 가장 효과적일까?
  • 소프트웨어 조직에서 창의력을 발현할 수 있을까?
  • 프로세스와 제품 중 무엇이 더 중요할까?
  • 소프트웨어 분야에서 이론과 실제가 어떻게 상호 작용할까? 실무자와 학자가 좀 더 효과적으로 서로를 보완할 수 없을까?
  • 창의력과 소프트웨어 설계 사이에 끊어진 연결 고리가 있을까?
  • 소프트웨어 작업에서 ‘지적인’ 작업과 ‘사무적인’ 작업 사이에 균형은 무엇일까?
  • 요즘에도 옛날에 느꼈던 즐거움을 찾을 수 있을까?

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

로버트 L 글래스(Robert L. Glass)

로버트 L 글래스(밥)은 지금까지 50여 년 동안 전산 분야에서 파란만장한 경험을 쌓아왔으며, 1954년에서 1957년 사이 항공우주 업계(노스 아메리칸 에비에이션(옮긴이 주: 한국전에서 미그 전투기 킬러로 맹활약했던 F-86 세이버 전투기 제작사이며, 아폴로 프로그램에서 사령선과 서비스 모듈을 개발한 회사이다. 1996년 보잉에 합병되었다.))에서 3년 동안 일한 경험을 시작으로 밥은 소프트웨어 부문에서 진정한 선구자 중 한 명으로 거듭났다.

노스 아메리칸 사에서 근무한 경험이 계기가 되어 에어로젯-제네랄(1957에서 1965년)과 보잉(1965년에서 1970년, 1972년에서 1982년)과 같은 우주항공 회사에서 계속 일하게 되었다. 밥이 맡은 임무는 주로 응용 프로그램 전문가가 사용하는 소프트웨어 도구 개발이었다. 우주 탐사로 들떠 있던 1960년대와 1970년대는 우주항공 업계의 일원으로서 정말 흥미진진한 시기였으며, 전산 분야 일원으로서도 더할 나위 없이 짜릿한 시기였다. 두 분야 모두 급속히 성장하고 있었으며, 전망은 하늘을 찌를 정도였다!

항공우주 업계에서 몸담은 동안 밥이 배운 교훈은 자신이 소프트웨어 기술은 좋아하지만 관리자는 하기 싫어한다는 사실이었다. 밥은 주의 깊게 기술 전문가라는 자신의 위치를 계발해왔으며, 밥의 경력에 두 가지 측면에서 핵심적인 영향을 미쳤다. (a) 기술적인 지식은 항상 최신이고 유용했다 (b) 상대적으로 절차적(earning) 권력(!)과 관리 지식은 그만큼 감소했다.

기술적으로 더는 승진하기 어려운 직위에 이르자, 밥은 학계로 눈을 돌렸다. 밥은 (1982년에서 1987년 사이에) 시애틀 대학교의 소프트웨어 공학 대학원에서 교편을 잡았으며, (역시 너무나 학문적인!) 소프트웨어 공학 연구소(SEI, Software Engineering Institute)에서 1년을 보냈다. 초창기 밥은 워싱턴 대학교에서 도구에 초점을 맞춘 연구를 몇 년 정도(1970년 – 1972년) 진행했었다.

학계에서 몸담고 있던 시절에 밥이 깨달은 교훈은 머리는 소프트웨어 공학 이론을 즐길지 몰라도 마음은 실무에 있다는 사실이었다. 확실히 업계에서 사람을 빼낼 수는 있었으나, 사람에서 업계를 빼낼 수는 없다. 새로이 깨달은 교훈을 바탕으로 밥은 오랫동안 느껴왔던 전산 이론과 실무 사이에 존재하는 “대화 단절”을 해소할 방법을 찾기 시작한다.

밥은 (25권이 넘는) 다양한 서적과 (90편이 넘는) 전문 논문을 작성하는 방법으로 전산 학계가 내놓은 발견을 평가하고 이를 실무에 실질적인 가치가 있도록 만드는 전환 작업에 초점을 맞추기 위한 여러 가지 시도를 해왔다. (이런 작업은 확실히 어려우며, 밥의 글과 신념에서 개척자 기질이 배어나는 이유가 바로 여기에 있다.) 소프트웨어 공학 강의와 세미나는 현업 개발자에게 이론적인 측면과 우수 사례에 초점을 맞춘다. 밥이 발행하는 소식지인 “The Software Practitioner”는 역시 같은 맥락이다. (밥이 지금 명예 편집자로 있는) 엘스비어(Elsevier)에서 여러 해 동안 편집을 맡은 (좀더 학술적인) “Journal of Systems and Software”에서도 마찬가지 냄새가 난다. 밥이 “CACM(Communication of the ACM)”과 “IEEE Software”에 주기적으로 기고하는 칼럼도 비슷한 분위기이다. 비록 밥의 저술은 심각하면서도 반골적인 성향이 다분하지만, 전산 분야에 통용되는 해학이 상당수 담겨(아니 해학으로 이뤄져!)있다.

이 모든 사항을 고려하건대, 밥이 컴퓨팅 분야에서 가장 자랑스럽게 생각하는 순간이 언제일까? 1995년에 스웨덴 린코핑 대학교가 수여한 명예 박사 학위를 받았을 때와 1999년에 ACM 전문가 학회의 특별 회원으로 임명되었을 때이다.

사적인 이야기를 하자면, 로버트 L 글래스는 친자 두 명과 양자 두 명의 아버지이며, 정보 시스템 관련 학계에서 활약하는 아이리스 베세이와 결혼했다.

박재호 jrogue@gmail.com

포항공과대학교 컴퓨터공학과 학부와 컴퓨터공학과 대학원을 졸업했다. 운 좋게 한 번도 다른 길로 빠지지 않고 12년째 소프트웨어를 개발했으며, 올해도 역시 재미난 소프트웨어를 개발하고 있다. 옮긴 책으로는 『소프트웨어 컨플릭트 2.0』, 『조엘 온 소프트웨어』, 『초난감 기업의 조건』, 『The Art of Project Management: 마음을 움직이는 프로젝트 관리』 등이 있다.

이해영 hylsteely@gmail.com

포항공과대학교 컴퓨터공학과 학부와 퍼듀대학교 전자계산학과 대학원을 졸업했다. 오랫동안 소프트웨어 개발에 종사하다가 2009년 현재 미국에서 소프트웨어 지역화 전문가로 일한다. 옮긴 책으로는 『소프트웨어 컨플릭트 2.0』, 『조엘 온 소프트웨어』, 『초난감 기업의 조건』, 『The Art of Project Management: 마음을 움직이는 프로젝트 관리』 등이 있다.

 

옮긴이 글

무엇을 상상하든 그 이상을 보게 될 것이다_박재호

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

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

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

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

감사하는 말

이 책을 번역하는 과정에서 일등 공신은 단연 공역자인 이해영님이다. 아마 이해영님이 없었다면 이 책 번역 자체가 불가능한 작업이라는 생각이다. 다음으로 여느 소프트웨어 프로젝트와 마찬가지로 일정이 밀리고 또 밀리는 바람에 마음 고생을 많이 하셨을 위키북스 출판사 담당자 여러분께 감사한다. 그리고 미리 책을 읽어주시느라 아주 고생하신 베타리더 여러분께도 감사한다. 마지막으로 이 책 번역이 언제 끝날지 기다리다 기린 목이 되어버린 가족들에게 정말 감사한다.

명불허전(名不虛傳)_이해영

사실 길게 쓸 말이 없다. 한 마디면 족하다. 명불허전(名不虛傳)

쉽지 않은 책이다. 번역하기도 어려웠지만 읽기도 쉽지 않았으리라 생각한다. 가능하면 여러 차례 반복해서 읽으라고 권한다. 읽으면서 저자가 말하려는 요지를 되새기면 좋겠다. 그리고 저자가 펼치는 주장에 내 생각은 어떤지 따져보면 더욱 좋겠다. 생각하는 만큼 사고가 넓어지는 책이다.

감사하는 말 오랫동안 함께 일하면서 프로젝트를 끌어주는 공역자 박재호씨에게 감사한다. 개인적인 문제로 본의 아니게 두어 달이나 일정이 늦어졌음에도 너그럽게 감싸주신 위키북스에도 감사한다. 어려운 책이지만 꼼꼼하게 살펴주신 베타리더 분들에게 손이라도 한번씩 잡아드리고 싶다.

  • 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 베타리더 한마디