- 불씨
- 조회 수 8301
- 댓글 수 0
- 추천 수 0
저자연구
김익환
경기고, 서울대 공대 졸업후 미국 캘리포니아 주립대에서 전산학 학사, 스탠포드 대학교에서 전산학 석사를 취득하고, 미국 실리콘밸리의 유수의 회사에서 실무경력을 쌓았다. 세계 150여 개 기업에 인터넷 통합 메시지 솔루션을 제공하는 '스탠포드 소프트웨어(Stanford Software Corp, USA)'를 설립, 제품을 개발하고 회사를 운영했다. 2000년 한국으로 돌아와 소프트웨어 분야 컨설턴트로, '안철수연구소'의 부사장 및 최고기술경영자(CTO)로 근무했다. 현재 소프트웨어 컨설팅 회사인 ABC Tech의 대표이사이다. ABC Tech는 소프트웨어 회사의 조직, 프로세스, 기반시스템과 개발방법론, 그리고 소프트웨어조직문화를 컨설팅하는 회사로 국내 소프트웨어업계의 개발문화를 바꾸는 것을 비전으로 한다. KAIST 겸직교수로 <소프트웨어 전문가> 석사과정을 지도하였다. 저서로 『대한민국에는 소프트웨어가 없다』(2003, 미래의 창), 『소프트웨어 개발의 모든 것』(2008,페가수스), 역서로 『세상을 바꾼 32개의 통찰』(2007, 크리에디트)이 있다.
내 마음을 무찔러드는 글귀
추천의 글
성공한 임원일수록 자기의 성공경험에서 터득한 결정방식을 갖고 있었으며, 이는 소프트웨어 분야에 효과적인 결정을 내리는데 방해효소로 작용하는 것을 많이 봤다.
> 피터 드러커의 <프로페셔널의 조건> 에 나오는 이야기다.
중견/고급 개발자에게 의견을 구하기도 하지만 개발자의 좁은 관점과 부분적인 제안 때문에 오히려 우왕좌왕하며 헤매는 임원도 보았다.
프롤로그
개발문화는 소프트웨어의 본질
소프트웨어 공학은 개발문화에 기반을 둔 현실이다. 그런데 개발문화를 기술로 착각해 책이나 이론으로 가르치고 배우려는 생각이 국내 소프트웨어 업계를 혼란스럽게 만들고 오히려 성장을 방해했다
> 어쩌면 내가 개발문화라는 것에 대해 관심을 가지게 된 것도 이 한줄에서 시작되었는지도
1 . 소프트웨어 회사가 성공하기 위한 다섯 가지 조건
1 ) 혁신하든가 사라지든가
15
솔개나 회사나 위기에 처하지 않으면 개선에 대한 필요성을 느끼지 못한다. 결국 위기에 닥쳤을 때 마지막으로 혁신할 수 있는 기회가 온다.
2 ) 변하지 않으면 죽는다
18
하드웨어 마인드를 버려라
소프트웨어는 인류 역사상 지식적으로 가장 복잡한 산업이다. 밀어붙이면 풍선효과로 부작용만 일어난다
반면 하드웨어 마인드를 가져야 할 때도 있다. 소프트웨어를 변경하는 일은 하드웨어에 못지않은 비용이 든다. 비용측면에서 소프트웨어도 하드하다는 생각을 가져야 한다는 말이다
소프트웨어는 아무나 개발할 수 있다는 생각을 버려라. 개발자의 능력에 따라 결과는 28배나 차이가 난다고 파나스가 말했다.
다수 직원의 의견은 취향에 따른 의사 표현일 뿐 진실을 논할 때는 한 사람의 전문가보다 못한 경우가 많다
소프트웨어에서 빠른 것은 극약과 같으니 필요할 때만 잠깐 써야 한다. 사용이 과다하면 죽는다. 눈에 보이는 개발이 빨리 끝났다고 해서 모든 개발이 끝난 것은 아니다. 기쁨은 잠심 뿐, 유지보수의 늪에 빠져 죽을 수 있다.
19
일정은 협상의 대상이 아니다. 논리적인 근거로 일정이 세워질 때까지 일정을 정하지 말아야 한다. 그전까지 관리자가 잡은 일정은 희망사항일 뿐이라는 것을 기억하자.
2% 부족한 것을 간과하지 마라.
꼬리 날개만 없는 비행기는 위험하다. 차라리 하나의 온전한 비행기가 없는 편이 낫다. 아무것도 없으면 떨어질 것도 없는데 98%가 있으니까 구동하다가 떨어져 죽는다. 2%가 모자란 제품을 만드느니 시작하지 않는 것이 좋을지도 모른다
소프트웨어 회사의 문제는 대부분 장기적인 해결책을 필요로 한다.
3 ) 소프트웨어 회사는 두 번의 재건축이 필요하다
22
경영자는 스피드와 안전의 균형을 맞추기 위해 현명한 판단을 해야 한다.
어설픈 경영자는 변해야 한다는 생각에 매몰되어 세계적인 방법론을 맹신하는 우를 범한다.
23
개발자에게 소프트웨어 공학이나 방법론, 프로세스에 대한 회의를 느끼게 만드는 게 더 큰 문제다
개발도 스피드보다는 관리와 안전이 우선이다
4 ) 미국회사는 기본이 70점, 한국회사는 20점에서 시작한다
25
실리콘밸리의 이직문화를 가능하게 하는 것은 회사가 인력 이동에 대한 준비가 되어 있기 때문이다
26
통상적인 미국회사는 기본적으로 회사가 70%를 제공한다. 그러니까 사람이 아무리 망쳐도 기본적으로 70점은 얻는다. 그 70점 위에서 잘하면 80점도 얻고, 90점도 얻는 것이다. 반면에 대부분의 한국회사는 20점 정도를 제공할 뿐이다. 이는 사람이 해야 할 일이 엄청난게 많다는 것을 의미한다. 20점 위의 점수는 다 사람이 잘하느냐 못 하느냐에 달려 있다.
27
회사의 책임이기도 한 70%에는 기반시스템 설치, 프로세스 정립, 코딩의 표준화, 문서화 방법, 개발방법론, 공유 문화 정립 등의 많은 일이 있다
개발자에게 전문성 없는 테스트를 직접 하게 하는 것처럼 비효율적인 일도 없다. 스펙과 같은 핵심 문서가 없어 신입사원에게 제품을 이해시키려고 선배가 귀중한 시간을 내어 직접 가르쳐 주는 비효율성도 마찬가지다
5 ) 꼬여버린 프로세스, 코드, 기반 시스템
30
소스관리시스템과 이슈관리시스템은 통합되지 않으면 효과가 반감된다
> 실제로 통합해서 쓰려고 많이 노력해봤지만, 문화나 프로세스로 정착되지 않으면 결국 나중에 다 분리되는듯...
31
보다 위험한 경우는 어떤 상용도구도 자기 회사의 특수한 문제를 해결하지 못한다는 생각에 도구를 자체 개발하는 것이다. 자체 개발방법은 극약처방과 같기 때문에 되도록 사용하지 않는 것이 좋다
기본이 되어 있지 않은 회사에 거대한 프로세스를 갖다 놓아야 그 프로세스가 제대로 돌아갈 리가 없다. 깔아 놓은 것이 아까워 억지로라도 돌리면 절름발이 프로세스가 된다.
프로세스는 개발자가 문서를 어느 정도 작성할 자질을 갖췄다는 것을 전제로 한다. 따라서 개발자가 문서를 제대로 작성하는 능력이 부족한 상태라면 검증 자체가 의미가 없다. 문서를 검수하는 사람도 내용을 검토할 수 있을만큼 알지 못하는 경우가 태반이다.
32
당면한 문제를 해결하기 위해 하나씩 추가해가는 '증상치료방식'을 사용하는 회사에서 스파게티의 탄생은 필연적이다
6 ) 공유를 싫어하는 사람은 소프트웨어 회사에 적합하지 않다
33
문서 만들기도 싫고 문서가 어떤 효과를 발휘하는지도 모르기에 개발자는 경영자에게 그런 식으로 말하고, 잘 모르는 경영자도 그대로 믿는 것이다
비록 주먹구구식이라 할지라도 빨리 개발하는 개발자가 열심히 일하는 것처럼 보이고, 체계적으로 차근차근 일하는 사람은 눈의 뜨이지 않으니 열심히 일하는 것처럼 보이지 않는다.
> 프로는 성과로 말한다고 한다. 단기성과외에는 보지 못하는 대부분의 어줍잖은 프로들때문에 발생하는 현상이다.
34
대다수 개발자가 기법을 중시한다. 그들은 UML 사용법을 배우면 설계할 줄 안다고 생각하며, 진정한 설계가 무엇인지는 평생 깨닫지도 못하고 기법과 도구를 즐기며 산다.
이유가 어떻게 되었든 기법론자는 회사 돈으로 이것저것 사용해보면서 취미생활을 한다. 예를 들면, 소설을 쓰는 법은 모르는데 워드를 배워서 소설을 쓰다가 안되니 아래아 한글도 배워서 써보는 사람이다. 주로 대기업에서 서식하는 소위 '도구수집가'다.
35
진정으로 소프트웨어 회사에 중요한 인재는 정해진 프로세스, 개발원칙을 잘 지키면서 공유하고 협업하며 묵묵히 일하는 사람이다
7 ) 회사에 필수적인 소프트웨어 전문가
38
나이 들면 젊은 사람과 신기술에서 경쟁하기 어렵다는 착각도 관리자가 되어야 장기 생존할 수 있다는 생각에 일조한다
> 하지만 이는 어느정도 사실이다. 나이가 들면 뇌구조의 변화로 인해 신기술 체득이 더 어려워진다. 보수적으로 노화하는 인간의 특성과 무관하지 않다.
39
요소기술 아키텍트와 지휘자 아키텍트
> 요소기술 아키텍트라는 말 자체가 어불성설이다. 요소기술 전문가일 뿐이며, 아키텍트는 전체를 아우르는 지휘자 타입일수밖에 없다.
8 ) 소프트웨어 회사가 성공하기 위한 다섯 가지 조건
42
기반 시스템
43
조직 - 국내에는 슈퍼개발자가 많다. 개발자가 분석, 설계, 코딩, 빌드, 테스트, 기반시스템 관리 등 모든 업무를 다 한다. 그러나 그 말은 전문성이 없다는 말과 100% 일치한다.
> 작은 회사로 갈수록 많이 나타날수밖에 없는 현상이다. 사실 모든 업무를 다하는 것은 슈퍼개발자라기보다는 노동자에 가깝다. 진짜 슈퍼개발자는 모든 업무가 가능하지만, 전문적인 분야 하나는 확실히 가지고 있는 사람이다. 즉 T자형 인재다.
프로세스
기술
문화
45
다른 부분이 강화되면 프로세스가 효과를 발휘하기 시작할 것이다. 하지만 그때까지는 상당한 비용을 지불해야 할 것이다. 차라리 당분간 포기하는 것이 현명할 수도 있다.
2 . 이슈 관리 시스템을 보면 회사를 안다
9 ) 이슈관리시스템을 보면 회사를 안다
49
이슈관리시스템은 대시보드 형식으로 모든 직원이 항상 모니터에 띄워 놓고 모니터링한다. 개발자의 업무지시가 대부분 여기에서 온다. 물론 각자의 업무에 따라 대시보드에서 보고 싶은 정보를 화면에 적절히 설정한다
모든 직원이 사용한다. 이메일이나 전화를 사용한 이슈 전달을 최소화해야 한다. 각자 자발적으로 참여하는 것이 핵심이다. 특히 전화는 개발자의 생산성을 저하시키는 주범이다.
공식적인 요청은 모두 이슈 등록에서 시작된다
51
이슈 관리 시스템의 장점들
전사 커뮤니케이션의 효율성이 높아진다. 생산성이 올라간다
전사적으로 투명성을 제공한다. 관리와 개발 모두 위험요소가 줄어든다
이슈에 관한 다양한 통계를 제공한다. 미래 개선의 근거가 된다.
과거 이슈에 대한 데이터를 저장한다
모든 임직원의 평가를 할 수 있는 중요한 데이터를 제공한다
> <피플웨어>에서는 이슈 관리 시스템과 같은 누적된 정보로 직원 평가를 하지 않는 것이 좋다고 말한다
52
이슈를 등록할 때 각 필드에 입력하는 데이터의 정확성에 대한 강박관념을 없애는 것이 사용을 격려하는 핵심요소이다
53
이슈 등록으로 이슈에 대한 논의를 시작한다는 것을 이해하는 것이 중요하다
10 ) 소스 관리 시스템은 개발팀의 축소판이다
11 ) 문서를 적으면 개발시간이 단축된다는 것을 진정으로 믿어라
61
비효율성보다 더 큰 문제는 문서가 없이는 소프트웨어의 전체구조가 깨끗하게 만들어지지 않는다는 것이다. 10층짜리 건물을 설계 없이 쌓아 올리는 것과 비슷하다.
> 저자는 설계없이 짓는 건물의 예를 들었지만, SRS와 같은 문서는 설계가 아니라 소프트웨어의 전제조건으로 보는 것이 타당하다. 다시 말해, 건물을 짓는 목적과 전제 조건으로 비교할 수 있다. 아무리 설계를 잘 해놓았어도, 설계에 건물주의 중요한 요구사항이 빠져있다면 건물 다시 지어야 하고 설계 다시 해야 한다는 얘기다.
62
개발은 항상 바쁘기 마련인데 바쁘더라도 체계적으로 바쁜 것이 있고 아수라장 속에서 바쁜 것이 있다.
12 ) 스펙이란 무엇인가?
63
기능명세서는 SRS의 일부일 뿐이다
65
SRS는 좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서다
66
SRS를 적는 이유가 정보공유에 있다고 했다. 정보공유가 되려면 적어도 한 회사에서는 템플릿에 대한 표준이 필수적이다
목적을 만족시킨다면 어떤 형식이라도 괜찮다. 기법과 템플릿을 가르치는 것은 껍데기에 불과하다.
13 ) SRS를 작성하려고 노력하라. 그리고 그것은 항상 가능하다
68
그들의 주장은 코딩이 어렵다는 것이다. 그런데 이렇게 말하는 개발자가 있다면 그는 SRS와 설계문서 없이 개발하고 있는 것이다. (...) 코딩한다는 이름 아래 동시에 분석도 하고 설계도 하고 있는 것이다
69
비록 개발을 위해서 주어진 시간이 1시간에 불과하더라도 SRS 작성은 가능하며 또 해야 한다. 시간이 많고 적고와는 관계없는 문제다. 시간이 많으나 적으냐 하는 문제는 프로젝트가 근본적으로 시간 안에 가능하느냐 가능하지 않느냐의 이슈고, SRS를 작성하느냐 안 하느냐는 효율적으로 개발하느냐 안 하느냐의 문제다
14 ) SRS를 쓰는 법은 속성이 안 된다
73
IEEE에 모인 전 세계 소프트웨어 분야의 대가들은 "SRS가 소프트웨어 개발에서 가장 중요하고 가장 어려운 문서다"라는 결론을 내렸다. 그런 문서를 1,2년에 제대로 적을 수 있다면 자신이 천재라고 생각하면 된다. 아니면 착각이다. 인류역사상 가장 복잡한 지식산업인 소프트웨어에서 가장 어렵다는 SRS를 작성하는 것이 단순한 기법은 아닐 것이다.
15 ) 초가집과 기와집 어느 것이 더 잘 지었는가?
76
SRS의 핵심은 기능목록을 작성하는 것이 아니다. 제품의 목적을 확실히 이해하고 설계를 할 수 있게 충분한 정보를 주는 것이다. 그중의 일부분이 기능일뿐이다.
77
무엇을 만들까 보다 무엇을 결정하는 원인인 왜?가 더 중요하다
SRS는 고객이 원하는 품질 좋은 소프트웨어를 최소시간에 최소비용으로 개발하기 위해 필요한 모든 것을 '왜'라고 생각하며 적는 것이다.
SRS의 처음부터 끝까지 모든 문장에서 왜?란 질문을 던져보는 것이다. 그리고 '왜'에서 '무엇'으로 진행된 과정도 적는다.
목표에 적힌 문장에 따라서 기능 요구사항, 비기능 요구사항, 아키텍처, 구현 제한사항 등 SRS에 적히는 내용도 다르고 적어야 하는 양도 엄청나게 차이가 날 것이다. 당연히 개발방식도 달라진다. 잘 쓰여진 SRS는 그 목적에 따라서 적히는 양과 질에 엄청난 차이가 있다. 그래서 모든 경우에 모범이 될만한 SRS의 샘플은 없다는 것이다.
16 ) 장식용 방법론, 제출용 방법론, 실용적인 방법론
79
제안용으로 사용하는 경우 - 장식용 방법론
개발과 문서작성 모두 효율적인 경우 - 실용적인 방법론
개발은 효율적이나 문서작성에 비효욜적인 경우 - 천재 개발자의 방법론
개발은 비효율적인데 문서작성이 효율적인 경우 - 제출용 방법론
개발과 문서 작성 모두 비효율적인 경우 - 주먹구구식 방법론
17 ) 증상치료와 원인치료
18 ) 원인치료가 컨설팅의 핵심이다
89
버그 하나 수정하면 다른 문제가 생긴다는 것은 증상이다. 증상을 고치기 위해 인력을 대거 투입해 테스트를 강화해보겠다는 것은 어느 정도 도움이 되겠지만 너무 순진한 생각이다. 그 원인을 파 들어가 보면 소프트웨어 개발의 모든 문제가 종합적으로 들어 있다. 결국 초심으로 돌아가서 체질을 바꾸어야 진정한 해결이 되지만 시간과 비용문제로 받아들이기가 쉽지 않다.
3 . CTO의 역할은 아무도 대신하지 못한다
19 ) CTO의 역할은 아무나 대신하지 못한다
93
간혹 연구소장, 개발실장, R&D부사장 등의 직함이 CTO와 혼란을 일으킨다. 이들과 CTO를 구별 짓는 가장 중요한 기준은 CTO는 인사관리를 안한다는 것이다. 연구소장처럼 '장'자가 붙는 사람은 부서원을 관리해야 한다. '장'의 권위를 즐기는 대신에 사람관리를 위한 시간이 엄청나게 들어간다. 역시 CTO가 되기에는 시간상으로 모자란다.
96
CEO나 연구소장과 같은 관리자가 CTO의 결정을 좌지우지하지 않는 조직이 되어야 한다
> 마찬가지로 실무 개발 리더와 개발 관리자의 프로젝트 진행에 감나라 배나라 일정 관리 해대는 상급자는 프로젝트를 망치는 원흉이다
20 ) 관리자는 기술 전문가가 될 수 없다
21 ) 200의 능력을 가진 회사가 100에 만족하면 위험하다
22 ) 소프트웨어 회사의 종류
107
대부분의 소프트웨어 업계 사람이 오해하는 단어이기 때문에 조심스럽게 사용하는 소위 '소프트웨어 공학'적인 관점에서 모든 소프트웨어 회사는 동일하다
23 ) 임베디드 소프트웨어의 본질 - 컴포넌트와 인터페이스
111
분석 단계에서 나오는 결과물인 문서의 이름을 하드웨어와 소프트웨어가 조합된 시스템일 때는 SSS(System/Subsystem Spec)이라고 한다. SRS와 형식이 같다.
112
순수 소프트웨어 개발을 잘하는데 임베디드 소프트웨어 개발은 잘 못한다는 것은 소프트웨어의 문제가 아니고 그 분야의 도메인 지식의 문제다.
24 ) 영업팀과 개발팀의 다툼은 건전한 것이다
25 ) 깨진 유리창 법칙
117
소프트웨어 회사에서 프로세스를 만들기는 정말 어려워도 무너지는 것은 한순간이다. 유리창 한 조각만 깨놓으면 와르르 무너진다. 경찰이 교차로에서 잠깐만 사라져도 다시 아수라장이 되는 것과 같다. 그래서 프로세스는 잘 만드는 것만큼이나 지키는 것이 중요하다.
26 ) 시장은 창조하는 것이다
119
알랜 케이도 "미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다."라고 말했다.
4 . 신입사원은 문서(50%), 프로세스(5%), 선배(5%)로부터 배운다
27 ) 신입사원은 문서(50%), 프로세스(5%), 선배(5%)로부터 배운다
127
키워드는 기업문화에 있다. 문서작성, 프로세스의 효율성 증대는 서로가 다 같이 움직일 때 효과를 발휘할 수 있는 시스템이지 어느 한 사람만 열심히 해서는 효과를 거둘 수 없다. 오히려 열심히 한 사람만 손해 볼 수도 있다.
28 ) 프로세스의 힘, 마지막에 무리한 사양변경을 막는다
129
애초부터 잘못된 계약, 불충분한 초기 분석, 문서의 부재, 개발자의 풍부한 상상력, 프로세스의 부재, 그리고 제왕적이고 무지한 고객이나 경영자의 행태가 합작이 된 부작용이 종합적으로 마지막에 증상으로 나타나는 것이 바로 이 '사양변경'이다. 마지막 순간에 사양변경이라는 불행이 온 것은 앞에서 다 뿌린 씨가 있고 또 씨에서 싹튼 잡초가 자라도록 방치했기 때문이다.
29 ) 최소비용과 최소시간
134
소프트웨어 공학은 양날의 검과 같아서 잘 적용하면 좋은 약이 되지만 잘못 적용하면 극약과 같다. 주먹구구식으로 개발하면서 소프트웨어 공학에서 언급하는 문서를 추가로 만드는 방식이라면 이는 극약으로 쓰는 것이다. 그래서 CMMI와 같은 프로세스도 잘 쓰면 명약이지만 제대로 적용할 수 있는 환경이 안 된 곳에서는 극약과 같은 상황이 벌어진다. 그리고 애꿏은 CMMI만 탓한다.
136
검출되는 에러는 요구사항정의단계에서 56%, 설계단계에서 27%, 프로그래밍 단계에서 7%가 발견된다는 통계가 있다.
세계 최고 수준의 전산학과가 있는 U.C 버클리의 소프트웨어 공학 교재에도 "소프트웨어 공학은 가르칠 수 없다. 그러나 배울 수 있다"고 적혀 있다. 현실에서 시행착오를 거치면서 배울 수 있다는 뜻이다. 그리고 시행착오를 덜 겪는 유일한 방법이 선각자와 같이 일하면서 최소시간에 최소비용으로 개발하는 것을 배우는 것이다.
30 ) 간단한 것의 가치가 복잡한 것보다 크다
140
세계적 방법론, 애자일 방법론, CMMI 등 매력적으로 보이는 것을 강조하는 사람은 신기술 수집가에 불과하다. 그런 것보다는 누구나 알고 있는 몇 가지 핵심을 제대로 실행하는 것이 훨씬 더 중요하다.
31 ) 급한 것과 중요한 것
32 ) 찰떡같이 붙어 있는 분석, 설계, 코딩을 떼어내라
148
업무를 알아야 분석이 가능하다는 믿음이 오해라는 것을 모르기 때문이다
> 이 부분은 나도 오해라면 오해를 하고 있는 것 같은데, 도메인 지식이 없이 요구사양 정의 및 설계를 한다는 것은 어렵다고 본다
33 ) 서로 배우게 하라
151
단기적으로 자기희생이 요구되는 것이 협업의 본질이다
> 바로 그게 문화로 정착되어 있어야 한다는 거고.
능동적으로 나서서 미래에 생길 수 있는 문제를 발견하고 부서 간의 협업을 유도해서 해결책을 마련하려고 노력하는 사람처럼 회사에 중요한 사람은 없다
152
진정한 소프트웨어 전문가가 되기 위해서 어려운 세가지가 있다. 좋은 개발환경을 접하기가 어렵고, 좋은 스승을 만나기가 어렵고, 마지막으로 자기 자신이 깨닫기가 어렵다.
34 ) 동료 검토(Peer Review)는 권장하지 마라
155
소스코드를 검토하기 이전에 서로 정보 공유를 한 것이 없다면 검토할 수 있는 대상은 코딩 컨벤션이나 단순한 신택스 뿐이다. 그런 것들은 도구를 이용하는 것이 더 빠르고 정확하다. 결국 쓸데없는 시간낭비다.
156
미리 검토해야 하는 것은 하위 설계 동료 검토다.
분석 단계에서 나오는 SRS를 검토했으면 상위설계검토가 쉽고, 상위설계가 잘 되어 있으면 하위설계 검토가 쉽고, 결국 소스코드 검토가 쉬워진다는 결론에 이른다. 이런 선행된 행위 없이 마지막에 생뚱맞게 소스코드를 동료검토한다고 해봐야 시간만 낭비할 뿐이다.
157
동료검토의 대상은 소프트웨어의 개발단계인 제품기획, 요구사항분석, 설계, 코딩, 빌드, 테스트 등에서 나오는 모든 산출물들에 해당된다. 동료검토에서는 산출물의 내용만 검토하는 것이 아니라 어떤 산출물을 만들고자 하는 개발전략도 토의대상이 될 수 있다. 그만큼 동료검토의 범위는 넚다. 동료검토는 개발의 가장 앞 단계부터 수행되어서 정보 공유가 계속되어 왔어야 가치가 있다. 이런 선행조건이 없으면 동료검토를 권장하지 않는다
> 너무 범위를 넓게 잡으면 죽도 밥도 안 될 위험이 있다. 전략을 검토하는 회의는 따로 있는 법이고, 동료 검토는 프로세스에 의해 단계별로 이루어져야 한다
35 ) 조삼모사, 유지보수의 늪에 빠지다
159
시간이 없어서 제대로 제품을 만들 시간이 없는데 나중에 고칠 시간은 있는가?
160
영업부서를 거친 경영자에게서 공통적으로 보이는 현상이 있다. 단기적인 판매 전략에 최우선 순위를 둔다는 것이다.
161
여기에 문서 작성을 싫어하고 코딩은 좋아하는 프로그래머가 가세하면 그 회사의 미래가 어떨지 생각만 해도 암울하다
36 ) 머지 데이(Merge Day)를 정해서 할 이유가 없다
5 . 소프트웨어 개발은 기술이 아니라 예술이다
37 ) 건축가와 벽돌공, 누가 가치가 있는가?
38 ) 소프트웨어는 기법이 아니라 예술이며 정신세계다
39 ) 고기를 준다면 성황이지만 고기 잡는 방법을 가르쳐 주면 싫어한다
40 ) 배우려면 잔을 비워라
41 ) 백발이 성성한 프로그래머는 없다
181
많은 개발자가 무의식적으로 코딩이 개발의 핵심이라는 착각을 한다
42 ) 비싼 도구가 기술역량을 올려주지 않는다
184
도구를 사용하되 생각은 도구가 없는 환경에서처럼 하라고 권유하고 싶다
43 ) 표현법이 진보를 가져오지 않는다
187
UML과 설계의 관게는 소설 쓰는 것과 워드프로세서의 관계와 같다
진형준은 <성상파괴주의 상상옹호주의>에서 다음과 같은 말을 했다.
"우리가 공자나 예수보다 컴퓨터를 잘 할지는 모르지만 그렇다고 우리가 더 진화된 인간은 아니다. 기술은 진보는 인간은 진보를 가져오는 것이 아니라 인간 기본 욕망을 표현할 수 있는 수단의 다양화를 가져올 뿐이며 표현수단의 변화가 인간 자체를 바꾸지는 않는다."
44 ) 지식과 기법은 달콤한 사탕과 같다
190
개발자는 표현은 못하지만 실행할 줄 아는 암묵적 지식의 소유자다
192
문학으로 비교하면 워드프로세서를 잘 하는 사람은 문학 테크니션이다. 문학의 역사, 문학의 종류, 소설가의 생애와 업적 등을 잘 알고 있다면 문학 사이언티스트이다. 반면 실제 소설을 잘 쓴다면 문학 엔지니어다.
방법론을 가지고 얘기하면 사이언티스트의 독무대다.
도구에 대한 얘기를 하면 테크니션이 주도권을 잡는다
훌륭한 개발자를 보는 눈이 없는 회사에서는 진정한 개발자는 도태되고 사이언티스트와 테크니션이 활개를 친다
45 ) 비행기 산악자전거 그리고 소프트웨어
196
소프트웨어는 그 결과가 비행기나 산악자전거와 같이 즉시 나타나지 않는다는 것이다. 즉시 나타나지 않을 뿐만 아니라 잘못된 결과의 원인이 명확하게 규명되지도 않는다. 결국은 결과에 대한 판단도 불명확하고 원인도 애매모호한 상태에서 회사는 서서히 침몰한다
46 ) 스마트폰, 소프트웨어공학을 경험할 좋은 기회
47 ) 컨퍼런스에 보람있게 참가하는 방법
6 . 기업문화란 무엇인가
48 ) 기업문화란 무엇인가
212
기업문화라고 하면 간단히 말해 일을 할 때 내 의지와는 상관없이 의식적으로 혹은 무의식적으로 따라할 수 밖에 없는 환경이라고 할 수 있다.
215
한국의 소프트웨어 회사에 실리콘 밸리 출신의 CEO가 온다면 어떤 현상이 일어날까? 필자의 경험으로는 회사의 문화가 오래지 않아 바뀔 수 있다. (...) 반대로 한국의 CEO가 미국에 가서 회사를 만들고 미국 개발자를 고용한다면 어떨까? 아마 한국회사의 문화와 많이 다르지 않을 것이다
> 우리는 그 생생한 실례를 2002년 월드컵 한국대표팀과 히딩크 감독에게서 보았다.
불행히도 한국의 개발자는 이런 문화정립에 기여를 하고 싶어도 기회 자체가 없다
49 ) 법으로 좋은 세상을 만들지 못한다.
216
소프트웨어에서도 모든 프로세스와 방법론, 규칙을 법으로 명문화한다고 해서 위법한 행위를 모두 막을수는 없다. 위법한 행위를 막기 위해 필요한 것은 법이 아니라 윤리적이고 자발적인 문화다
동료검토를 꺼리는 이유는 시간도 없지만, 자기 자신에게도 자신이 없기 때문이다.
218
프로세스 위주로 KPI를 정하자
1 - 스펙은 적는가
2 - 동료검토는 하는가
3 - 문서 업데이트를 하는가
4 - 소스코드 체크인시 주석을 제대로 남기는가
5 - 이슈관리시스템을 제대로 활용하는가
50 ) 기업문화는 자선사업과 같다
51 ) 미신에 현혹되지 마라
224
요구사항을 나중에 정하면 된다는 생각은 재앙의 시작이다
불행히도 대부분의 고객은 전문성이 없다
> 책의 독자도 자기가 무엇을 읽고 싶어하는지 모른다
52 ) 잘 이해하고 사용하면 약, 글자에 집착하면 독
228
마크트웨인 - 건강 관련 책들은 조심해서 읽어야 한다. 그렇지 않으면 당신은 인쇄 오류로 죽을수도 있다
229
학문없는 경험은 경험 없는 학문보다 낫다 - 서양격언
52 ) 애자일 방법론 제대로 사용하기
234
회의를 짧게 끝내려면 다른 대전제가 필요하다. 바로 이슈관리시스템이다. 이슈관리시스템의 효율적인 사용 없이는 서서 하건 앉아서 하건 상관없이 회의가 일찍 끝날수 없다.
일일빌드가 애자일 방법론 때문에 생겨났다고 생각한다면 큰 오해다. 여기도 대전제가 필요하다. 인터페이스를 함수 수준까지 모두 정희한 하위 설계가 잘 되어 있어야 구현 시작 시점부터 일일빌드를 할 수 있다.
설계가 안 되어 있는데 애자일 방법론을 따라한다며 억지로 일일빌드를 하려고 노력한다면 임시방편으로 인터페이스를 억지로 맞추느라고 시간 낭비하는 것이다.
일일빌드의 핵심은 설계이고, 충실한 설계가 없이는 일일빌드의 혜택을 누리지 못 한다.
54 ) 지식과 경험의 차이는 점점 커진다
에필로그
248
개발자의 노력만으로는 한계가 있다. 문화를 바꾸려면 두가지가 필요한데 하나는 경영자의 의지이고, 두번째는 선각자에게서 배우는 것이다. 의지만으로 시작해서는 시행착오로 끝날 확률이 100%에 이른다
내가 저자라면
이 책만큼 우리나라의 소프트웨어 회사의 현실과 한계를 조리있게 이야기한 책은 없다고 본다. 그 해결책은 단순히 말하면 실리콘밸리 스타일인데, 대체로 맞는 이야기로 들리는기도 하지만 이상적인 원론이기도 하다. 사실 모든 솔루션은 기본으로 돌아가는 도덕적 원칙에 있는 것 아니겠는가. 저자는 화려한 학력과 경력으로 본인의 책에 일단 권위를 부여해놓았다. 독자는 그 권위에 의지해 고개를 끄덕이기 쉬워진다. 지명도 있는 저자가 가지는 장점이다.
목차는 6개의 장으로 구성된다. 첫장은 우리나라 소프트웨어 회사의 현실이다. 두번째장부터 세부적인 문제 진단에 들어간다. 첫번째는 이슈 관리 시스템, 두번째는 CTO의 역할, 세번째는 프로세스 관련이다. 그리고 다섯번째 장은 소프트웨어 개발의 본질을 다룬다. 마지막장은 소프트웨어 회사의 기업문화에 대한 것이다. 전형적인 공돌이식 구성이다. 각 장의 꼭지글들은 사실 모두가 일관성있게 이어지지 않는다. 세부 목차와 꼭지글들의 일관성이 그렇게 중요하지 않다는 또다른 실례일 것 같다. 책을 관통하는 메시지는 명확하다. 문서를 적어라. 그리고 그것은 SRS다. 이 뿐이다. 책을 읽고 나서 강렬하게 독자의 머리에 남는 핵심 메시지가 있느냐 없느냐가 책이 일관성 있는 내용을 가지느냐 아니냐를 결정한다. 이는 실제로 책의 내용이 논리적으로 일관성이 있고 없고와 별 관련이 없다.
컨셉은 매우 중요하다. 하지만 본질적으로 책의 알멩이가 훨씬 중요하다. 목차와 구성은 굉장히 중요하다. 하지만 이는 독자를 위해 중요한 것이 아니라 책을 써내려가는 저자를 위해 중요하다.
VR Left
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 5032 | 톨스토이, 도덕에 미치다 | 박혜홍 | 2019.03.24 | 9466 |
| 5031 | #51(최종) - 그대 스스로를 고용하라 | 불씨 | 2019.03.24 | 8326 |
| 5030 | 왜 도덕인가? | 박혜홍 | 2019.03.17 | 8229 |
| 5029 | #50 프로페셔널 소프트웨어 개발 外 | 불씨 | 2019.03.17 | 7900 |
| 5028 | 칼날 위의 역사 | 박혜홍 | 2019.03.10 | 8224 |
| 5027 | #49 소프트웨어공학의 사실과 오해 | 불씨 | 2019.03.10 | 8073 |
| 5026 | #48. 글로벌 소프트웨어를 말하다 - 지혜편 | 불씨 | 2019.03.03 | 8552 |
| 5025 | 서지문의 뉴스로 책읽기 | 박혜홍 | 2019.03.03 | 8555 |
| 5024 | 마음을 비추는 거울/ 신봉승 | 박혜홍 | 2019.02.24 | 8362 |
| » | #47 글로벌 소프트웨어를 꿈꾸다 | 불씨 | 2019.02.23 | 8301 |
| 5022 | 은밀한 세계관 | 박혜홍 | 2019.02.17 | 8084 |
| 5021 | #46. 피플웨어 | 불씨 | 2019.02.17 | 7829 |
| 5020 | 하버드의 생각수업 | 박혜홍 | 2019.02.10 | 7724 |
| 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 | 7346 |
