구본형 변화경영연구소

연구원

북

연구원들이

  • 불씨
  • 조회 수 2631
  • 댓글 수 0
  • 추천 수 0
2019년 3월 17일 12시 28분 등록
이번 북리뷰로 두권의 도서를 선정했다. 스티브 멕코넬의 <프로페셔널 소프트웨어 개발>과 국내 소프트웨어 개발자인 유석문씨가 쓴 <프로그래머 철학을 만나다> 두권이다. 두권의 도서에서 발췌할 만한 좋은 문장들이 부족했던 것도 두권의 북리류를 선정하게 된 하나의 이유지만, 당초 유명 외국인 소프트웨어 개발자가 쓴 책과 국내 소프트웨어 개발자가 쓴 책을 리뷰해보고 각각을 비교해보고 싶은 생각이 있었다.  

프로페셔널 소프트웨어 개발  

저자연구

스티브 맥코넬 (STEVE MCCONNEL)

마이크로소프트의 빌게이츠, 리눅스의 창시자 리누스 토발즈에 이어 전세계에서 세번째로 영향력이 있는 소프트웨어 업계의 구루로 평가받는 스티브 멕코넬은 현재 컨스트럭스 소프트웨어 사의 수석 소프트웨어 엔지니어다. 담당하고 있는 업무는 컨스트럭스 사의 소프트웨어 공학 실천법 총괄이며 SWEBOK(SOFTWARE ENGINEERING BODY OF KNOWLEDGE, 소프트웨어 공학 지식 체계) 프로젝트 중 구축 분야를 이끌었다. 그는 마이크로소프트와 보잉 및 시애틀 지역의 다른 회사에서 소프트웨어 프로젝트에 참여했다. SPC ESTIMATE PROFESSIONAL의 수석 개발자로 근무할 당시에는 소프트웨어 개발 생산성 상을 수상하기도 했다.휘트먼 대학교에서 학사 학위와 시애틀 대학교에서 소프트웨어 공학 석사 학위를 취득했으며, 현재 현재 워싱턴 주 벨뷰에 거주하고 있다.

저서로는 《프로젝트 쾌속 개발 전략》(한빛미디어, 2003), 《소프트웨어 프로젝트 생존 전략》(인사이트, 2011), 《PROFESSIONAL 소프트웨어 개발》(인사이트, 2003) 등이 있다.의 저자다. 또한 그의 저서는 올해 최고의 소프트웨어 개발 도서로 두 번 선정된 바 있다. 


감명깊은 글귀들

23
업계 연구원들은 같은 업계에서 경쟁하는 조직들 사이의 생산성에 10대 1의 차이가 발생하는 것을 발견했다. 최근 조사에 의해 600대 1의 차이까지도 발생한다는 것을 알수 있다.

> 또다른 연구에 따르면 개발자들간에는 28배까지 생산성의 차이가 나는 것으로 밝혀졌다. 물론 이 범주를 벗어나는 초천재들이 있기는 하다.

소프트웨어 업계에 있어서 가장 큰 위험은 변하지 않으면서도, 오래 전에 효과적이라고 판명된 기법들은 사용하지 않고 터무니없는 개발 기법에 머무르는 것이다.

30
1969년으로 돌아가보면, 로버트 프로쉬는 "시스템이 글자 그대로의 스펙을 모두 만족하더라도, 클라이언트들은 썩 흡족해 하지 않을 수 있다"라고 그때 이미 말했다.

31
문제 정의를 자동화하는 것은 불가능하다. 문제를 정의하기 위해 필요한 것이 바로 프로그래밍이고, 이런 관점에서 본다면 프로그래밍은 절대로 사라지지 않을 것이다.

39
바위를 옮기는 것과 소스코드를 만드는 것은 유사점이 많다.

결국 소프트웨어 프로젝트 초기에는 거의 긴박감을 느끼지 못한 채로 시간을 낭비하다가 프로젝트를 완성해야 하는 기한이 다가오면 절망적 상태가 되는 '마지막 순간 증후군'에 걸리기 쉽다

소스코드를 바위에 비유한다면 마지막 순간 전력 질주함으로써 프로젝트를 성공으로 이끌어 낼 수 있다는 헛된 희망 따위는 갖지 않을 것이다.

40
전체 소프트웨어 개발 팀 중 75%는 무작정 바위를 밀면서 프로젝트를 시작한다. 이것을 일단 작성하고 고쳐보는 개발(코드 앤드 픽스 디벨롭먼트)라 한다

44
일단 작성하고 고쳐보는 식의 접근은 바보들의 황금과 유사하다. 첫눈에는 더할 나위없이 좋아 보이지만, 숙련된 개발자들은 그것이 얼마나 가치없는 것인지 안다

45
터무니없이 생산성을 높일 수 있다고 자랑하는 새로운 기술들과 몇몇 방법론들을 은빛 총알(Silver Bullet)이라 부른다.

소프트웨어는 소프트하지 않다!

56
프로세스 기반 개발은 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간 사용, 오랜 경험을 통해 좋다고 판명된 소프트웨어 공학 기법들을 적용해 프로젝트를 성공시키는 것이다

책임기반 개발은 "영웅 중심 개발", "개별 권한 부여" 등의 이름으로 불리운다

57
프로세스를 중시한다고 사칭하는 조직의 경우 조직이 아닌 프로세스 자체를 위한 프로세스에 투자하는데, 이 과정에서 여러 가지 잘못된 기법들을 만드는 경우가 많다.

우리는 프로세스 사칭 조직을 관료 조직이라 부른다

책임을 중시한다고 사칭하는 조직의 경우 직원들을 어떻게 하면 좀더 밤늦게까지 일하게 할 수 있는가에 골몰한다

> 많은 한국회사들이 책임 중시 사칭 조직들이다

58
'책임 사칭 조직'은 결과(긴 근무시간)와 원인(높은 동기부여)를 혼동한다. 우리는 이러한 책임 사칭 조직을 '착취 조직'이라 부른다

59
프로세스도 좋고, 그만큼 개인 권한 부여도 좋다. 이 둘은 동시에 공존할 수 있다.

65
적절한 질문은 "무엇이 소프트웨어 개발인가?"가 아니라 "전문적인 소프트웨어 개발은 어떤 모습이어야 하는가?"여야 한다. 위 질문에 대한 나의 의견은 다음과 같다.
"진정한 소프트웨어 개발은 반드시 공학이어야 한다"

69
소프트웨어를 만드는 것을 공학으로 간주하면 모든 문제는 명확해진다. 각각의 프로젝트에 적절한 개발 방법론을 적용하면 된다.

73
진실은 혼란보다 실수를 통해 더 빨리 다가올 것이다 - 프란시스 베이컨

75
브룩스는 코딩과 테스팅은 소프트웨어 개발에서 단지 우유적 속성일 뿐이고, 소프트웨어 개발의 본질은 서로 맞물려 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장했다.

또 브룩스는 소프트웨어가 어려운 이유가 그 본질적인 복잡성, 일치성, 변화 가능성, 비가시성 때문이라고 했다

80
과거 몇 백년동안 사람들은 수학, 물리학, 심리학, 철학을 구분하지 않았다. 수학은 서기 300년경에 철학에서 분리되기 시작했고, 물리학은 약 1600년경부터 별도로 취급되었다. 심리학과 철학을 구분하기 시작한 것은 겨우 1900년 이후다.

108
아인슈타인이 말했듯이, 어떤 문제든 간에 더 간단해질수 없을 때까지 간단하게 만들어야 한다. 생텍쥐베리는 "완벽한 설계는 더 추가할게 없을 때가 아니라, 더 뺄 것이 없을 때 이루어진다"고 지적했다

112
일반적인 프로젝트는 결함들을 고치는데 전체 시간의 40~80퍼센트를 소비한다

147
단순 사상가가 책이나, 기사 같은 것을 통해 삶을 간접적으로 경험하는 데 비해, 생각하는 인간은 어떤 직업을 가지면서 현실에서 역동적이고 가끔은 자기 반성을 위해 멈춰서기도 하는 사람을 의미한다.

에머슨은 생각하는 인간의 직접 경험이 천재성을 이루는 결정적인 요소고, 이 천재성은 단순 사상가가 아닌, 생각하는 인간에게서만 나오는 것이라고 주장했다

184
콘웨이 법칙은 "프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다"는 것이다. 혼란스러운 회사는 혼란스러운 소프트웨어만 만들어낸다.

197
인간 요소와 인간 관계 활동이 소프트웨어 생산성을 향상하는 데 가장 큰 역할을 한다 - 베리 보엠

200
마이너스 생산성 프로그래머 - 전문 프로그래머들의 10%가 이러한 부류다

212
개인의 지식과 경험 레벨이 서로 일치하지 않다면, 개인의 최종 능력은 일반적으로 경험과 지식 중 더 낮은 쪽에 가까워진다

238
카네기 멜론대학의 메리 셔 - 단순 기술이 제품을 만들고 상업화된 제품이 생겨나면서 과학이 개입되고, 그 결과 전문적인 공학이 탄생한다

275
하랜 밀즈 - 비효율적인 회사일수록 평균 이하의 개발자가, 효과적인 회사일수록 평균 이상의 개발자가 몰린다


내가 저자라면

소프트웨어 공학 관련 책 좀 읽었다고 자부하는 소프트웨어 개발자들중 스티브 맥코넬을 모르는 사람은 없을 것이다. 그만큼 그의 책에 있는 내용들은 소프트웨어 업계에서 수없이 인용되고 있다. 책은 4개의 파트로 구성되어 있다. 첫번째 파트는 "소프트웨어 늪지대"로 현실을 진단한다. 두번째 파트는 "개인의 프로정신"으로 소프트웨어의 개인적인 부분에 대해 다룬다. 세번째는 "조직의 프로정신"이다. 네번째 파트는 "업계의 프로정신"으로 일반론과 소프트웨어 공학 원론에 대한 이야기가 많다. 지극히 공돌이스러운 구성으로, 나역시 첫책의 구성을 이와 같은 방식으로 고려한 적이 있었다. 하지만 책의 구성은 저자에게나 중요할뿐 독자에게는 실질적으로 그다지 중요하지 않다는 것을 다시 느끼게 된 독서였다. 다른 여느 책과 마찬가지로 책의 뒷부분으로 가면서 일반론과 당위적 이야기로 흐르는 부분은 다소 식상한 구석이 있다. 저자는 보통 웅장하고 당위적인 결론을 원하지만, 독자의 관점에서 볼때 매우 경계해야 할 부분이다.


프로그래머, 철학을 만나다

저자연구

유석문

1972년 서울 출생으로 현재 라이엇게임즈코리아의 기술감독을 맡고 있다. NHN 지도지역서비스개발랩 랩장과 NTS부장, 서비스부분 이사를 지냈으며 2011년에 제12회 SW산업인의 날 지식경제부장관상을 수상하였다.
저서로는 <사람과 프로그래머>, <프로그래머로 산다는 것>, <프로그래머 철학을 만나다>, <NHN은 이렇게 한다 - 소프트웨어 품질관리>등이 있다.


좋은 글귀들

3
기술과 달리 매번 필자를 어려움에 빠뜨렸던 부분은 일정한 입력에 응답을 제공하지 않는 사람이었다

> 내가 썼던 칼럼의 내용이기도 하고, 기술쟁이들이 어느정도 경험이 쌓이면 할수밖에 없는 사람에 대한 고민이다.

4
상대방이 합의된 사항을 무시하고 자신에게 맞추라고 우기는 상황의 해결책은 기술서적에 없었다

> 스펙에 의존하는 공돌이들의 한계다

5
심리학을 통해 알게 된 것은 "사람은 합리적인 존재가 아니다"와 "사람은 모두 같은 어려움을 겪고 있다"뿐이었다

19
그들이 간과한 사실은 팀장의 문제 제기 덕에 프로젝트의 문제점이 초기에 가시화 되어 그에 대한 대비책을 준비할 수 있었던 점이다. 문제 제기가 없었다면 아무런 대책 없이 프로젝트가 수행됐을 것이고 실패는 당연한 일이었다

24
만일 누군가가 너의 몸을 우연히 마주친 사람에게 떠넘기다면 너는 화가 날 것이다. 그런데 너는 너 자신의 정신을 우연히 만나는 사람에게 떠넘겨서, 그래서 결과적으로 그 사람이 너를 욕보인다면 너의 정신은 교란되고 혼란스럽게 되는데, 너는 이것에 대해 부끄러워하지 않겠는가?

27
미 육군의 리더십 매뉴얼에는 "리더는 스트레스 상황에서도 평정심을 유지하고 자신이 긍정적으로 영향을 줄 수 있는 일들에 에너지를 쏟으며, 자신이 영향을 끼칠 수 없는 일을 걱정하지 않는 것이 무척 중요하다"는 항목이 있다

> 스트레스 상황에서 평정심을 유지한다는 항목이 중요하다. 다른 진술은 리더건 아니건 동일하게 중요하지만, 평정심의 유지는 특히 리더에게는 중요하다. 리더이기에 더 많은 스트레스가 있을수밖에 없고, 스트레스 상황에서의 태도를 어떻게 가져가느냐에 따라 팀의 운명이 결정될 수도 있다

28
자존감은 '무엇인가 해낼 수 있다'는 자기 능력감과 '자신이 사랑받을 가치가 있다'는 자기 가치감으로 구성된다.

자부심과 자존심은 경쟁을 통해 얻는다는 차이가 있다

37
자동화 배포 환경을 갖추는데 소요되는 며칠의 시간을 아끼겠다뎌 결국 배포할 때마다 하루가 꼬박 걸리는 작업을 수시로 반복하며 밤샘을 한다

> 가끔은 나도, 그리고 뒤떨어지는 개발자들이 아무 생각없이 일하다보면 발생하는 어리석음과 귀차니즘의 결합

47
지금 당장 할 수 있는 일에 통제력을 발휘하기 바란다

> 스고자 프로젝트의 핵심!

55
여우를 훔친 사실을 들키지 않으려고 외투 밑에 숨긴 여우가 자신의 심장을 파먹는 상황에서도 내색하지 않고 죽은 스파르타 소년의 이야기와 같은 무용담

> 21세기 회사에서 이런 무용담이 아직도 회자되는 이유는 무엇인가

66
뛰어난 의사소통 능력이란 용어엔 오해하기 쉬운 요소가 있다,. 자신의 의견을 타인에게 정확하게 전달하고 조율하는 과정이 아니라 타인을 자신의 의견에 동의하도록 만들기 위해 협상능력을 악용할 때가 많다

> 용어가 완전히 다른데 오해하는 것들은 그들의 뇌구조의 문제이겠지

82
회고의 목적은 회고를 수행하는 대상의 내적 가치를 높이는 것이다

94
효과적인 소프트웨어 개발을 위해 협업이 강조되는 이유는 역설적이게도 그만큼 협업이 어렵기 때문이다

95
레온 페스팅거의 말처럼 "인간은 합리적인 존재가 아니라 합리화하는 존재"이기 때문이다

104
만일 화가 이성의 말에 귀를 기울이고 이성이 이끄는대로 따른다면, 그것은 더 이상 화가 아니다. 만일 화가 이성에게 반항하고 이성이 명령을 해도 수그러들지 않고 사나운 욕망에 이끌려간다면, 화는 마치 퇴각 신호를 무시하는 병사처럼 마음에게 아무런 도움이 되지 않는 부하일 것이다 - 세네카

113
막연한 기대는 프로젝트 기간이 중반을 넘어갈 무렵 완료할 수 없으리라는 두려움으로 변질되고, 프로젝트 후반에는 근거없는 낙관론의 다른 얼굴인 절망이 모습을 드러낸다. 이 시점에는 모두가 프로젝트의 실패를 확신하며 실패의 원인을 상대방에게 전가하기 위해 절망 속의 허우적거린다. 이것이 소프트웨어 개발 프로젝트에 만연한 근거없는 낙관론의 실체이며 소프트웨어 개발을 분노의 지옥으로 바꾸는 원흉이다

> 명쾌하게 짚었다

124
누군가는 미래의 공포와 싸우며 다른 누군가는 미래의 낙관론에 빠져 현재를 희생한 것이다

127
불확실한 미래는 인간에게 두려움과 불안감을 제공하지만 역설적이게도 인간은 불확실성을 해소하고자 끊임없이 미래를 상상한다

150
많은 경험, 높은 지식, 뛰어난 협업 능력을 갖춘 관리자가 잘하는 일은 '문제의 해결'이지 '미래 문제의 예측'이 아니다

> 다소 편협한 주장이 아닐까. '미래 문제의 예측'은 '문제 해결'의 범주에 포함된다.

160
잘못된 인센티브 사례로 '창과 방패의 인센티브'도 있다. 

165
추정의 정확성을 저해하는 요소 중에서 닻내림 효과가 있다. 닻내림 효과란 누군가 기준을 제시하면 그 범위 내에서 답을 찾게 되는 경향의 말한다.

221
프로세스를 선호하는 이유는 그것이 제일 쉬운 해결책이라는 오해와 책임을 면하려는 의도가 결합된 결과

222
프로세스가 시키는 대로 했기에 저는 무죄입니다. 와 같은 합리화의 수단으로 전락


내가 저자라면

이 책은 저자가 읽었던 스토아철학과 심리학의 내용을 개발 업무환경에 접목시켜보려는 시도의 결과라고 할 수 있다. 개발자라고 한정했지만 직장인에 해당되는 이야기들, 다시 말해 보편적인 이야기들이다. 내가 쓰고자 하는 책의 컨셉과도 흡사하다고 말할수 있다. 막무가내식 뜬금없는 결론과 그 결론에 도달하려고 애쓰는 공돌이 특유의 억지스러운 흐름이 다소 거슬리기도 했다. 책의 마지막 부분의 내용을 이루고 있는 오류를 다루는 챕터는 왜 이 책에 들어가야 하는지 맥락을 알수 없었다. 
저자가 책을 많이 읽고, 현업과 인간에 대해 많이 고민한 흔적이 보인다. 나름대로의 프로그래머로서의 철학도 가지고 있다. 다만 그 깊이가 그리 깊지 못해서 몇몇 주장들은 개똥철학처럼 느껴지기도 한다. 점점 내공이 쌓이다보면 좋아질수 있는 부분이라 생각된다. 프로그래머로서의 철학을 얘기하지만, 결국 고대 그리스의 권위에 많이 기대고 있다. 스토아철학 아리스토텔레스, 에픽테토스, 세네카의 권위를 빌려 저자의 주장에 당위성을 부여하려는 시도가 이어진다. 참신했지만, 한계가 보였다.


IP *.121.156.75

덧글 입력박스
유동형 덧글모듈