- 불씨
- 조회 수 8551
- 댓글 수 0
- 추천 수 0
저자연구
김익환
경기고, 서울대 공대 졸업후 미국 캘리포니아 주립대에서 전산학 학사, 스탠포드 대학교에서 전산학 석사를 취득하고, 미국 실리콘밸리의 유수의 회사에서 실무경력을 쌓았다. 세계 150여 개 기업에 인터넷 통합 메시지 솔루션을 제공하는 '스탠포드 소프트웨어(Stanford Software Corp, USA)'를 설립, 제품을 개발하고 회사를 운영했다. 2000년 한국으로 돌아와 소프트웨어 분야 컨설턴트로, '안철수연구소'의 부사장 및 최고기술경영자(CTO)로 근무했다. 현재 소프트웨어 컨설팅 회사인 ABC Tech의 대표이사이다. ABC Tech는 소프트웨어 회사의 조직, 프로세스, 기반시스템과 개발방법론, 그리고 소프트웨어조직문화를 컨설팅하는 회사로 국내 소프트웨어업계의 개발문화를 바꾸는 것을 비전으로 한다. KAIST 겸직교수로 <소프트웨어 전문가> 석사과정을 지도하였다. 저서로 『대한민국에는 소프트웨어가 없다』(2003, 미래의 창), 『소프트웨어 개발의 모든 것』(2008,페가수스), 역서로 『세상을 바꾼 32개의 통찰』(2007, 크리에디트)이 있다.
내 마음을 무찔러드는 글귀
프롤로그
필자는 우리나라에서 컨설팅을 하면서 아무리 기법을 가르친들 효과가 없다는 것을 깨달았다
1 . 지혜란 무엇인가
01 . 제 1원인을 찾아라
14
소프트웨어 개발에서 첫 번째 단계인 '분석'단계가 잘되면 모든 것이 잘되고 분석이 잘못되면 모든 것이 잘못될 수밖에 없는 것이 엄연한 인과의 법칙이다.
제 1원인부터 시작해서 전반부에서 더 많은 노력을 들이는 게 실리콘밸리의 회사이고, 후반부에서 엄청나게 많은 노력을 들이는 것이 국내의 소프트웨어 회사이다.
02 . 소프트웨어는 지식 산업이다
15
소프트웨어는 인류 역사상 가장 어려운 지식 산업이다 - 소프트웨어 공학의 대가, 파나스(Parnas)
최상의 개발자는 최하의 개발자보다 28배 뛰어나다 - 자크만 프레임워크, 자크만
한 명의 뛰어난 개발자가 다른 직원 100명보다 낫다 - 페이스북 창업자 주커버그
16
비용평가과 가치평가는 노동집약 산업과 지식 산업의 대표적인 차이이다. 어떤 제품의 가치를 판단할 때 '누가 얼마 걸려 만들었는가?'라는 원가산출 방식으로 제품의 가치를 산정하는 것이 노동집약 산업의 특성이다. 반면에 '고객이 느끼는 가치가 제품의 가치'인 것이 지식 산업이다.
가치평가를 못 하니 노동의 원가로 비용을 평가할 수 밖에 없는 국내 소프트웨어 업계의 현실은 지식 산업으로서 갖추어야 할 근본 역량이 부족함을 보여준다. 그러니 개발자 등급이라는 것이 나오고 소프트웨어 업계에서는 천재 1명보다 바보 2명을 투입하는 것이 결과는 나쁘더라도 비용청구는 더 많이 할 수 있는 병폐가 생긴다.
19
모험은 잘 될수 있는 확률이라도 있지만 원칙이 잘못된 경우는 모험이 아니라 그냥 100% 오류다.
03 . 프로는 아름답다
22
소프트웨어에서 연주할 곡은 SRS라는 문서로 작성된다. 이 곡을 가지고 연주하는 것이 설계와 구현이다
23
국내 소프트웨어에서는 무엇을 만드는지도 잘 모르는 상태에서 만들기 시작하는 경우가 허다하다. 반쯤 작곡된 곡을 미리 연주하겠다는 것이다. 그 때 사용하는 만인의 변명은 똑같다
"코딩을 해보기 전에는 자세한 내용을 알 수 없다"
"되는지 안 되는지를 검증해봐야 한다"
"일정이 바빠서 빨리 시작해야 한다"
> 나역시 이런 변명을 많이 해왔던 것 같다. 돌이켜보건데, 그 원인은 잘 모르기 때문에, 다시 말해 역량 부족인 경우가 대부분이었다. 경험있는 아키텍트가 필요한 이유이기도 하다.
04 . 하드웨어와 소프트웨어는 같고 나서 다르다
29
건축공학에서 배울 것은 안 배우고 소위 공사판의 인부관리방법만 배워서 소프트웨어에서 사용하려고 한다
05 . 인과관계와 상관관계의 오류
36
소프트웨어 회사에서 지식관리시스템과 지식공유는 거의 관계가 없다. 지식관리시스템은 소프트웨어가 아닌 다른 산업에서는 효율적으로 사용될 수 있다. 이점은 하드웨어와 소프트웨어 산업이 다른 점이기도 하다. 이것을 깨달았다면 이미 최고 전문가라고 할 수 있다.
소프트웨어 회사에서는 지식을 공유하기 위해서 지식관리시스템을 사용할 필요가 없고 이슈관리시스템이나 위키등으로 해결한다. 그게 비용도 적게 들고 훨씬 더 효율적이다
06 . 손자병법을 읽고 손무가 되는 착각을 하다
39
자신은 감동을 받아서 공유하고 싶어 올리지만 표면적인 지식을 전하는 것 뿐이다
43
소프트웨어 공학 역시 극히 조심해서 사용해야 할 마약과 같다. 심지어는 전혀 해가 없을 것 같은 객체지향언어, 애자일 방법론, UML과 같은 설계도구에도 중독이 되어 폐해를 입는 사례를 너무 많이 보았다
지혜는 일을 하는 것을 피하면서 일을 완수하는 역량이다 - 리누스 토발즈
07 . Top-Down 방식은 왜 어려울 수밖에 없는가
47
Top-Down을 하기 위해서는 다음 네가지 역량이 필요하다
자연스러운 습관의 거부, 외로움을 이기는 강력한 의지, 예술적인 창조성, 방법적인 역량
08 . 갈라파고스 증후군
51
회사의 상태를 판단할 때 성공 임계치가 있고 실패 임계치가 있다. 일단 성공 임계치를 넘어가면 대충 일해도 크게 잘못하는 일만 하지 않으면 당분간은 그런대로 굴러간다. 마이크로소프트같은 경우이다. 그러나 실패 임계치를 넘어가면 아무리 노력해도 방법이 없다. 말기의 노키아같은 회사이다. 핵반응과 같이 일단 실패 임계치를 넘어가면 백약이 무효로 폭발하고 만다.
09 . 정의란 무엇인가
60
필자도 소프트웨어 컨설팅을 하면서 똑같은 질문을 많이 한다. "UML 배우기를 원하는지, 설계 잘하기를 원하는지, 아니면 훌륭한 개발자가 되기를 원하는지" 말이다. 이 세 가지 목표에 따라 방법이 달라진다.
61
직원들 교육에 투자했다가 그들이 퇴사하면 어쩌지? - 어느 회사의 CFO
그럼 투자 안했다가 모두 회사에 남아있으면 어쩌지? - 어느 회사의 CEO
63
국내 소프트웨어 회사에 가보면 개발자의 수많은 불만과 요구가 있다. 새 기술 교육, 새 도구 구매, 새 프로세스 정립, 새 방법론 도입 등 호기심으로 인한 요구다. 그러나 대부분은 진정한 목표와 합치되지 않는다
> 오래 개발자로 일하다보니, 불만과 요구 중 언급된 프로세스나 방법론 정립은 결코 호기심 때문이 아닌 꼭 필요한 경우가 있다고 본다. 다만 그것들이 진정한 목표 그 자체가 아닌 개선을 위한 도구일뿐이라는 것에는 저자와 의견을 같이 한다. 진정한 목표는 문화 자체, 그리고 경영진의 결단에 달려있다.
010 . 깨닫는데 걸리는 시간 10년
68
OOP의 깨달음은 프로그래밍 언어에서 얻는 것이 아니라 소프트웨어의 생명주기와 유지보수까지 다 포함해서 파생제품도 만들고 해봐야 OOP의 진정한 가치와 의미를 알 수가 있다.
Chapter 2. 좋은 고객 서비스가 글로벌 소프트웨어의 장애물이다
11 . 공감대의 병폐와 선각자의 외로움
72
수많은 사람의 의견보다 전문가 한명의 통찰이 중요하다
73
경영자의 역량 중의 하나는 공감대를 형성해야 하는 주제와 그렇지 않은 주제를 잘 분별하는 데 있다. 그런데 경험자가 아니면, 그런 분별을 할 수가 없다
75
감정적인 이슈를 논리적으로 해결하려 들고, 논리적인 이슈를 감정적으로 해결하려 들고, 공감대가 필요한 이슈를 독단으로 하고, 독단으로 결정할 이슈에서 공감대를 찾는 일은 이제 그만두어야 한다. 국내 소프트웨어 업계에서는 이런 일이 비일비재하게 일어난다.
76
나는 성공하는 비결을 알지 못한다. 그러나 실패하는 비결은 모든 사람을 만족시키려 하는 것이다. - 빌 코스비
12 . 개발자를 바보로 만드는 문화
80
자신이 한가하다고 개발자가 있는 곳을 배회하면서 "잘 되어가나"고 말 시키는 관리자는 개발자를 관리하는 관리자로서의 자격이 없다. 분위기를 파악하고 싶으면 멀리서 살펴보면 된다. 격려한다고 개발자를 방해하면 안된다.
13 . 죄수의 딜레마와 엘리트 카르텔
14 . 좋은 고객서비스가 글로벌 소프트웨어의 장애물이다
96
아키텍처가 좋다 나쁘다의 애기는 미래의 확장성 때문에 나온 것이다
15 . 패배로 이끄는 습관의 유혹
102
남의 코드 보고 "절대 일 못하겠다"고 하면서 자기 소스코드도 그렇게 짠다
16 . 악령이 출몰하는 소프트웨어 세상
103
소프트웨어 업계에도 누구에게나 접근 가능하고 그럴 듯하게 보이는 낮은 진입장벽 때문에 수많은 악령이 춤추고 있다. 많은 새로운 도구, 프로그래밍 언어, 프로세스, 소프트웨어 공학, 새로운 방법론, 컨설팅 등 악령이 여기 저기서 춤춘다. 미 국방부, 보잉, 구글, 페이스북과 같은 글로벌 회사나 실리콘 밸리의 예를 들먹이며 악령들이 나타난다
105
천재 물리학자인 스티븐 호킹은 "외계인은 존재한다. 외게인을 만나면 피하라"고 했다.
필자도 가끔 스티븐 호킹과 같은 말을 한다. "CMMI가 나타나면 되도록이면 피하세요. 식스시그마가 나타나면 되도록이면 피하세요. 평생 동안 피해다니는 게 몸에 좋습니다. 괜히 접촉했다가 피해 입지 마세요."라고 한다.
108
악령에서 탈출하는 가장 쉬운 방법은 본질에 대한 통찰력을 가지는 방법 밖에는 없다. 차선책으로는 어설픈 논리의 판단력보다는 차라리 상식으로 판단하는 것이 더 안전하다.
Chapter 3. 개발자의 가치는 도메인이 아니라 소프트웨어에 있다
17 . 모차르트, 호킹, 기타리스트, 훌륭한 개발자의 공통점
18 . 인재가 중요한가, 시스템이 중요한가
120
체크 리스트 기반의 시스템은 다 죄하 수준의 인력을 기준으로 만든 시스템이다.
> 최하 수준의 인력을 기준으로 프로세스 및 절차를 만들어야 안전하다.
19 . 베이비시팅과 훌륭한 코치의 역할 차이
127
가장 좋은 가르침은 고기를 왜 잡아야 하는가를 인식하도록 질문을 던지는 것이고, 두 번째는 고기를 잡는 방법을 가르쳐주는 것이고, 세 번째는 고기를 잡아서 주는 것이다. 소크라테스와 컨설턴트와 베이비시팅의 차이이다.
20 . 매트릭스 속의 개발자 깨어나야 한다
131
통상적으로 개발자가 진행하는 시나리오를 보자. 개발일정을 물어보면 "해봐야 알겠다"고 답한다
> 반성하자!!
21 . 코딩은 시작이 중요하다
138
소스코드를 예쁘게 고칠 수 있는 기회는 '최초에 코딩할 때"와 '회사가 잘 안 되어서 망하기 전 한가할 때'밖에 없다
22 . 책에 나온대로 코딩하면 초보자다
146
안되는 회사의 공통점을 보면 이쯤에서 관리자가 "왜 빨리 프로그램을 못 만드냐"고 재촉한다. "다른 개발자는 20분이면 한다고 하는데 너는 왜 이렇게 오래 걸리냐"고 타박한다. 이런 회사에서는 야단맞기 싫으니까 할 수 없이 주석도 없고, 에러처리도 안하고, 프로그램 4개 복사해서 "Hello Word", "Hello Word 2", "Hello Word 3", "Hello Word 4" 만들어 준다. 회사가 망하든 말든, 일단 내가 살아나야 하니까 실행만 되는 최악의 프로그램을 만든다. 이런 짓을 회사가 망할 때까지 하다가 다른 회사로 가면 된다. 근본 원인은 개발자가 아니라 무지한 경영자와 관리자에게 있다. 이런 식으로는 10년을 일해도 개발자의 역량은 향상되지 않는다. 불행히도 대부분의 국내 회사는 거의 이런 식으로 프로그램을 하게끔 환경이 만들어져 있다.
147
한 회사에서도 1년 경험자가 10년 경험자보다 잘할 수 있는 이유가 이렇게 생각하는 방법에 차이가 있기 때문이다
23 . 페르마의 마지막 정리보다 어려운 문제
149
국내 소프트웨어 개발자들이 남긴 소스코드를 보면 필자는 페르마의 마지막 정리가 생각난다. 설계도 없고 주석도 없어 소스코드를 이해하기 어려운 상황에서 "잘 돌아가는데요"라고 하면 할 말이 없다. 의심은 가지만 문제라는 것을 증명하기에는 너무 많은 노력이 든다. 결국은 나중에 문제가 생길때까지 예언하고 기다렸다가 세월이 증명해주는 방법을 사용하게 된다.
> 개발자의 소프트웨어 역량이 없는 것보다 더 큰 문제는 경영자와 관리자에게 소프트웨어 역량이라는 것 자체가 없는 것이다
151
국내 소프트웨어 회사에 컨설팅을 가보면 개발자가 수행하는 개발 업무의 80% 정도는 과거의 소스 코드를 해독하는 데 들어간다고 본다
153
농담삼아 늘 하는 얘기가 있다. 우리 소스코드가 외부로 유출되면 안 되는 이유가 '우리에게 비밀이 없다는 것을 남들이 알게 될까봐'이고 또 '너무 엉터리여서 곧 망할 거라는 것을 알게 될까봐'라는 것이다
> 아... 공감되는 이야기 ㅋ
25 . 오픈소스의 혜택은 무궁무진하다
26 . 개발자의 가치는 도메인이 아니라 소프트웨어에 있다
> 이 사실을 조금만 더 일찍 깨달았더라면 내 몸값도 달라졌겠지. 무엇보다 이직 범위도 유연해졌을테고. 아! 옛날이여.
167
소프트웨어 개발자는 그들의 전문 도메인 지식을 소프트웨어에 잘 적용하는 것이 실력이다
172
국내의 개발자는 예외 없이 진정한 CTO가 되지 못한다. 도메인 업무를 많이 알게 되면서 말로만 개발을 잘 아는 상황이 된다. 더 열악한 것은 프로젝트를 맡아 프로젝트 관리까지 한다는 것이다. 거기다가 조금 똑똑하다고 인정받으면 관리자로 승진되어 조직관리 업무까지 해야 한다
Chapter 4. 쉬운 일보다는 어려운 일을 먼저 해라
27 . 글로벌 소프트웨어 회사의 필요조건과 특징
글로벌 소프트웨어 회사가 될수 없는 조건
177
개발자가 재택근무를 할 수 없다
회의한다고 개발자를 계속 불러댄다
멘토가 가르쳐주지 않고는 신입사원이 일을 시작할 수 없다
기타 등등
28 . CTO와 CEO의 좋은 만남과 나쁜 만남
190
CTO와 CEO의 관계는 회사의 하부 구조로 내려오면 아키텍트와 관리자의 관계와 같다
29 . 회사의 잘못과 학교의 잘못
30 . 국내 소프트웨어 회사의 6가지 불치병
31 . 개발팀의 커뮤니케이션이란 무엇인가
205
개발자 커뮤니케이션의 목적은 무엇인가? 개방, 협업, 공유이다.
206
공유와 개방을 강제화하는 것이 바로 기반시스템과 프로세스다.
협업은 개인의 자발적인 노력이 받쳐주어야 한다
207
개발자는 말을 잘할 필요가 없다. 말을 잘하는 대신에 조용히 문서를 잘 만들면 된다
32 . 어려운 일과 쉬운 일, 왜 순서가 중요한가
214
머지 시 충돌을 피하기 위해서는 개발 시작부터 디렉토리 구조와 코딩 스타일까지 포함하여 심각하게 고려하는 장기적인 전략이 필요하다
33 . 존경의 대상인가, 해고의 대상인가?
218
문제를 해결하려는 팀은 당연히 이슈관리시스템에서 정보를 검색해 보았어야 했다
219
국내 소프트웨어 회사에는 많은 벙어리 개발자가 있다. 회의에서는 아무 소리도 안 하고 듣기만 하고 있다가 뒤에서 엉뚱한 일을 해놓고, 고치라고 하면 또 벙어리 모드로 들어가 망치는 최악의 개발자다.
Chapter 5. 우리는 인도에 개발 외주를 줄 수 있을까?
34 . 인도에 개발 외주를 주는 방법
223
계약 시에는 그렇게 자세한 내용을 알 수 없으니 진행하면서 정해가야 한다는 변명
시간이 없으니 대충 계약하고 일단 시작해야 한다는 논리
35 . 설계에 대한 자세
235
가장 효율적인 방법은 완벽한 컴포넌트와 인터페이스를 설계하는 것이다. 완벽하기 위해서는 단순해야 한다.
36 . 소프트웨어 공학, 프로세스, 문서화, 동료검토의 공통점
236
소프트웨어 공학 이론의 대가라고 할 수 있는 이바 야콥슨조차 그의 저서에서 소프트웨어 공학의 문제점에 대해 다음과 같이 언급했다
- 단기적인 유행과 패션에 의한 흥행
- 검증되지 않은 미숙한 이론에 근거
- 비교할 수도 없는 너무 많은 방법론
- 평가할 수 있는 실험 결과의 부재
- 학계의 연구와 산업계의 실용성의 차이
238
주위에서 CMMI를 제대로 적용하면서 개발역량이 향상된 성공사례는 들어본 적이 없다
240
그럼 이제 국내에서 느끼는 소프트웨어 공학, 프로세스, 문서화, 동료검토의 공통점을 나열해 보자
- 제대로 하기는 정말 어렵다
- 위험한 양날의 칼이다
- 짝퉁을 해봤다
- 나도 해봤는데 별것 아니다
241
당연히 해야 할 일로 생각한다면 바로 그때가 글로벌 역량이 생겼다는 증거이다
37 . 화면 100개 중 50개를 만들었다. 몇 % 완성되었는가?
245
국내 소프트웨어 업계에서의 개발은 순수 노동 산업인 짜장면을 만드는 것만도 못한 방식으로 일을 하고 있다
246
그들은 그래도 "쉬운 것부터 하겠다"고 했다. 어차피 일정이 지연되어 혼이 날 것인데 나중에 한 번만 혼나면 될 것을 처음부터 어려운 것을 하다가 늦어지면 실력도 의심받을 테니 나중에 한 번만 혼나겠다고 한 것이다. 결국 개발자를 이렇게 몰아 넣는 것은 경영자와 관리자의 무지다. 파레토의 법칙대로 마지막 20%를 완성하기 위해 전체 비용과 시간의 80%를 사용하는 시나리오로 간다
난이도를 파악하기 위해서는 분석, 설계능력이 필요하다
38 . 좋은 병행개발과 나쁜 병행개발
250
주먹구구식 방법이 역량의 한계를 넘어가는 순간 걷잡을 수 없이 망가지지 시작한다. 필자의 경험으로 보면 임계치가 열 명이다. 열 명이 넘어가면 죽음은 필연적이다.
회사는 죽는데 개발자는 죽지 않고 다른 회사 가서 큰 소리 치면서 똑같은 짓을 되풀이하는 것이다.
이런 현상은 제대로 된 CTO만 있으면 절대 벌어지지 않는다.
Chapter 6. 포기할 수 있는 단 한번의 기회가 중요하다
39 . 외주의 역설, 쉬운 것과 어려운 것
254
모르는 일을 외주를 주는 것은 엄청난 리스크이다
내가 하기 어렵다면 외주는 몇 배 더 어렵다
40 . 포기할 수 있는 단 한 번의 기회
261
투자가의 기본원칙은 "망할 회사는 조금이라도 빨리 망하는 것이 좋다"는 것이다
41 . 2년의 프로젝트가 하루의 오차도 없이 끝나다
42 . 귤화위지, 투명성이 주는 경쟁력
273
관리계층에 상관없이 투명성을 보장할 수 있는 방법은 바로 기반시스템이며, 소프트웨어 회사에는 이슈관리시스템이다
43 . 테스트는 소프트웨어 품질 향상에 도움이 안 된다
278
"지금 출시하지 않으면 큰 일 난다"고 협박하는 간신 영업팀의 모략에 빠져 버그가 있는데도 일단 출시하고 보는 하책으로 간다. 이런 시나리오로 평생을 살아가면서 '이런 것이 개발자의 인생인가 보다'고 하면서 유지보수의 늪에 빠져 '밤새워 급한 불끄기'가 국내 개발의 관행이 되어 왔다. 잘못된 관행 때문에 '이런 것이 개발자의 인생'이라고 포기하지 말자
내가 저자라면
이 책은 <글로벌 소프트웨어를 꿈꾸다>의 후속편으로, 전작에서의 분위기와 메시지를 그대로 이어가고 있다. '지혜편'이라는 부제에서 알 수 있듯이, 저자는 보다 근본적인 문제의 원인을 찾고, 그 해결책에 대해 이야기하려고 시도한다. 전작에서 어떻게 하면 물고기를 잡을수 있는지를 알려줬다면, 이번 책에서는 왜 물고기를 잡아야 하는지를 알려주고자 하는 것이다. 하지만 그런 야심찬 포부와 달리, 두 책의 내용은 매우 유사하다. 사실 근본적인 문제나 원인에 대해서는 전작에서도 많이 이야기했다. 다시 말해, 이 책과 전작이 두 파트로 구분되는 시리즈물이라기보다는, 이 책은 전작의 속편에 가깝다.
목차는 6개의 장에 각각의 장은 5~10개 내외의 꼭지글로 구성되어 있다. 각각의 꼭지글들은 개별적인 칼럼의 성격이 강하고, 비슷한 것들을 적절한 장에 배치한 듯 하다. 그렇기에 구성적으로 흐름은 자연스럽게 이어지지 않는다. 그냥 소프트웨어 개발의 지혜를 전하고자 한다는 신념(?) 아래 이것저것 저자가 하고 싶었던 말들을 모아놓은 느낌이다. 이 책을 몇번은 읽었지만, 전체를 관통하는 핵심메시지의 강도는 전작보다 덜했다. 전작에서는 책을 다 읽고 나서 SRS라는 강렬한 단어 하나가 남았는데, 이번에는 그런 것이 없다. 저자의 핵심 메시지는 고기를 잡는 방법보다 우선하는 고기를 왜 잡아야 하는지를 가르쳐 주겠다는 것인데, 그 가르침이 제대로 전달되었는지는 약간의 의문이 든다. 병폐와 문제의 원인을 늘어놓고, 근본적이고 도덕적이며 원론적인 해결책을 드는 것은 다소 뻔하고 진부하다. 저자는 첫 책을 쓰고 두번째 책을 그 속편으로 기획한 다음, 그간 써왔던 글들에 추가적인 글들을 더해 엮어 묶어낸 듯 하다.
개개의 꼭지글의 내용은 전작과 마찬가지로 수준 이상이다. 언급했다시피, 독자에게 더 어필하기 위해서는 전작의 SRS와 같은 핵심 단어를 부각시켰으면 좋았을 것 같다. 그것이 이 책에서는 그것은 '지혜'라는 단어인데, 실상 그 단어는 사死어다. 그보다는 소프트웨어 업계의 용어로 적절한 것으로 대치했으면 좋을 것 같다. 근본적인 가치인 지혜를 표방하고 있지만 이 책이 인문학적인 책이 아니기 때문에 꼭 필요한 부분이라고 본다. 이 책의 전체적인 내용을 볼때, 냉정하게 보자면 고기를 왜 잡느냐에 대한 지혜를 이야기하고자 했지만, 정작 보다 깊은 곳으로 들어가지 못하고 소프트웨어개발이라는 표층에서만 맴돌다가 끝난 것은 아닌가 하는 생각이 든다.
VR Left
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 5032 | 톨스토이, 도덕에 미치다 | 박혜홍 | 2019.03.24 | 9466 |
| 5031 | #51(최종) - 그대 스스로를 고용하라 | 불씨 | 2019.03.24 | 8326 |
| 5030 | 왜 도덕인가? | 박혜홍 | 2019.03.17 | 8229 |
| 5029 | #50 프로페셔널 소프트웨어 개발 外 | 불씨 | 2019.03.17 | 7899 |
| 5028 | 칼날 위의 역사 | 박혜홍 | 2019.03.10 | 8224 |
| 5027 | #49 소프트웨어공학의 사실과 오해 | 불씨 | 2019.03.10 | 8073 |
| » | #48. 글로벌 소프트웨어를 말하다 - 지혜편 | 불씨 | 2019.03.03 | 8551 |
| 5025 | 서지문의 뉴스로 책읽기 | 박혜홍 | 2019.03.03 | 8555 |
| 5024 | 마음을 비추는 거울/ 신봉승 | 박혜홍 | 2019.02.24 | 8361 |
| 5023 | #47 글로벌 소프트웨어를 꿈꾸다 | 불씨 | 2019.02.23 | 8301 |
| 5022 | 은밀한 세계관 | 박혜홍 | 2019.02.17 | 8084 |
| 5021 | #46. 피플웨어 | 불씨 | 2019.02.17 | 7829 |
| 5020 | 하버드의 생각수업 | 박혜홍 | 2019.02.10 | 7723 |
| 5019 | #45. 언어의 온도 & 회사어로 말하라 | 불씨 | 2019.02.09 | 7691 |
| 5018 | 구본형의 마지막 수업 | 박혜홍 | 2019.01.27 | 7220 |
| 5017 | #44 구본형의 마지막 수업 | 불씨 | 2019.01.27 | 7250 |
| 5016 | #43 뼛속까지 내려가서 써라 | 불씨 | 2019.01.20 | 7227 |
| 5015 | 뼛속까지 내려가서 써라 | 박혜홍 | 2019.01.20 | 7255 |
| 5014 | 나는 쓰는대로 이루어진다 | 박혜홍 | 2019.01.13 | 7369 |
| 5013 | #42 나는 쓰는대로 이루어진다 | 불씨 | 2019.01.12 | 7344 |
