거꾸로 배우는 소프트웨어 개발 by 이 호종

[ 밑줄/연결 ]

 

"가치를 만드는 건 엔지니어, 과학자, 예술가들이다. 다른 사람들은 단지 그걸 이리저리 옮길 뿐이다."

- 로버트 노이스 (Robert Noyce), 인텔 창립자 -

 

---> 책으로 나와 있다.

결국 오류는 사람이 만든다. 도구가 그걸 막아줄 수는 없다. 품질 낮은 사람이 품질 낮은 소프트웨어를 만든다. 품질 낮은 조직이 품질 낮은 소프트웨어를 만든다. 동어반복처럼 보이겠지만, 명백한 사실이다. 생생한 진실이기도 하다.

 

거의 모든 소프트웨어 개발 방법론의 기저에는 이런 고민이 깔려 있다. 천재들은 그냥 잘 짠다. 영재들은 대략 잘 짠다. 우리 같은 보통 사람들은, 원래 잘 짜기 어렵다. 틀이 필요하다. 규칙이 필요하다. 뭔가, 도구가 필요하다. 도움이 필요하다. 

 

천재/영재들은 개인적 능력에서만 천재/영재일 뿐이다. 집단적 능력은 또 다른 영역이다. 팀이 집단적 차원에서 천재/영재급이 되려면, 절차/도구를 표준화하고 의사소통 프로토콜을 서로 맞춰야만 한다.

 

부가기능 수십개를 빼더라도 핵심기능 하나가 충실한 게 더 낫다. 제한된 인력과 일정으로 작업할 때에는 '더하기'보다 '빼기'를 더 잘해야 한다. '반쪽짜리 제품을 만드느니 제품을 반만 만들어라"는 충고를 새겨두자.

 

Guru:  전문가 가운데 극히 소수만이 도달할 수 있는 최고이 단계. 전문가에서 구루가 되려면 연속적이고 지속적인 노력보다는 도약이 필요하다.

 

"창조성의 비밀은, 바로 '외부를 사유하는 힘'에 있다."

 

제대로 된 개발 방법론이 개발 조직 내에 안착하기 위해서는 개발 방법론 자체에 대한 높은 이해도를 가진 관리자가 필수적이기 때문이다.

 

개발 관리자 역시 개발을 지휘하는 지휘자다. 지휘자로서의 전문성은 다른 부문 전문가들이 대신해 줄 수가 없다.

 

먼저, 회의를 확 줄여야 한다. 관리자는 회의를 해야만 일을 하고 있다고 착각한다.

 

즉흥적으로 회의를 소집하는 일, 이건 관리자가 무능하다는 결정적 증거다. 

 

사람들을 회의실로 소집할 수 있는 권력을 즐기다 보면 그 맛에 중독된다. 일단 한 번 중독되면 증세가 심각해진다. 마약하고 비슷하다. 당신만 황홀할 뿐, 당신 조직은 피폐해진다.

 

개발은 몰입을 먹고 자란다. 개발 업무는 집중과 몰입에 전적으로 의존한다. 

 

책임추궁은 매니저가 피애햐 할 항목이다. 책임소재를 밝혀내고 엄중히 문책하겠다고 결심하는 순간 협업은 깨진다.....공포와 불안에 떠는 양들이 협업을 잘할 순 없다.

 

개발 방법/방식을 바꿔야 한다. 거듭 말하지만, 단위 테스트와 통합 테스트가 거의 유일한 공학적 해법이다.

 

소프트웨어 제품은 개발 조직을 그대로 반영해준다. 개발 조직은 자신을 뛰어넘는 소프트웨어를 결코 개발할 수 없다.  소프트웨어 제품을 업그레이드하고 싶다면, 조직을 업그레이드해야 한다. 

 

[ 자평 ] 일부 개발방법론 등의 outdate 되었지만....다시 봐도 역시 배울점이 한 가득....

 

글 재주가 뛰어난 개발자로 가장 유명한 사람은 조엘 스폴스키일 것이다.

국내는 2003년 <행복한 프로그래밍>을  출간하기 시작한 임백준씨 정도가 초기 인물이 아닐까 싶다. 

이 책이 나온 2011년  저자는 15년 넘게 통신 및 하드웨어와 소프트웨어 설계 분야에서 개발하고 있다고 했다. 10년 지난 지금은 25년 즈음 내공이 쌓이셔서 어디서 개발을 하고 계실까? 

 

개발자가 쓴 책에서 니체를 볼 수 있었던 점이 매우 놀라왔고 호감이 갔다.