☆ 거꾸로 배우는 소프트웨어 개발 / 이호종 / 로드북

 

* 개발자들도 하나 둘 바뀐다. 지친 사람은 떠난다. 새로운 사람이 들어온다. 구조와 기능을 배우며 적응해간다. 떠나간 개발자와 새로운 개발자, 남아있는 개발자, 서로 지식/경험은 제대로 전수되지 않는다. 아무리 설계 개발 문서를 체계적으로 생성/관리하더라도 개발자의 머릿속에 들어있는 지식과 손에 배어 있는 기술을 모두 뽑아낼 수는 없다. 떠난 개발자가 남긴 구멍은 아주 오랫동안 남는다. 기존 시스템에 대해 속속들이 알고 있던 사람들이 줄어든다. 그들만 알고 있던 암묵적 지식/경험도 사라진다. 남들이 짜놓은 기존 시스템 구조에 대한 비판자가 하나 둘 늘어난다. 조직 전체적으로 완전히 새로운 설계와 구조에 대한 갈망이 커진다.

 

* 70년대에는 정말 천재들만 개발했다. 프로그래밍 작업 자체도 천재급이 아니면 이해하기도 어려웠고 배우기도 힘들었다. 도구들도 원시적이었다. 그럼에도 그걸 사용하는 사람 자체가 천재들이었기 때문에 생산성은 높았다. 오류도 거의 없었다. 왜냐고? 그들은 천재들이었으니까.

* 소프트웨어는 80년대를 지나며 본격적으로 돈이 되는 산업이 되었다. 이 때에도, 개발 도구나 언어는 원시적이었다. 에디터도 불편했고, 컴파일러 또한 좋지 않았다. 디버깅 도구 역시 불편했다. 그럼에도 생산성이 높았고 오류도 적었다. 이유는? 뛰어난 사람들이 개발했기 때문이다. 그 당시에는 어셈블리어를 고급 언어 수준으로 잘 사용할 수 있는 정도의 막강 두뇌를 지닌 사람만이 개발할 수 있었기 때문이다.

* 90년대가 되면서 개발도구들이 진화했다. 이젠 천재가 아니어도 대략 영재급이면 프로그램을 만들 수 있게 됐다. 점점 더 프로그래밍하는 사람들이 많아졌다. 오류도 많아졌다. 생산성은 줄어갔다. 팀 단위 개발이 보편화되었다. 이때부터 소프트웨어 개발의 고유한 특성과 문제를 고찰하기 위한 공학적 탐색이 시작되었다. 이른바 '개발 방법론'에 대한 고민이 시작된 것이다.

* 2000년대가 되면서, 웹 프로그래밍이라는 분야가 새로 열렸다. 이젠, 책 한 권 달랑 읽고도 뭔가 돌아가는 프로그램을 짤수 있게 됐다. 학원에서 3개월, 6개월, 단기속성 과정을 졸업하면 누구나 프로그래머가 됐다. 데이터 구조론, 알고리즘, 이산수학, 운영체제론, 컴파일러 이론 등등 머리 아픈 전산학의 기초 과목 하나 몰라도, 뛰어난 프로그래머로 대접을 받았다. 개발도구 역시 눈부시게 진화했다. 프로그래머의 문턱 또한 사상 최대로 낮아졌다. 그러다 보니, 오류는 폭발적으로 증가했다. 도구가 진화한 만큼 문턱이 낮아져서, 프로그래밍하는 사람의 지적 수준과 능력이 그만큼 낮아졌기 때문이다.

 

* 결국 오류는 사람이 만든다. 도구가 그걸 막아줄 수는 없다. 품질 낮은 사람이 품질 낮은 소프트웨어를 만든다.
품질 낮은 조직이 품질 낮은 소프트웨어를 만든다.

* 천재급/영재급이 아니어도 평번한 인재가 작업해도 오류가 번성하지 않은 좋은 품질의 소프트웨어를 생산성 높게 잘 만들 방법은 없을까? 거의 모든 소프트웨어 개발 방법론의 기저에는 이런 고민이 깔려있다. 천재들은 그냥 잘 짠다. 영재들은 대략 잘 짠다. 우리 같은 보통 사람들은, 원래 잘 짜기 어렵다. 뭔가, 틀이 필요하다. 규칙이 필요하다. 뭔가, 도구가 필요하다. 도움이 필요하다.

* 사용자 요구가 폭증하고 그에 따라 소프트웨어의 복잡도가 폭발적으로 증가하면, 상황은 더 나빠진다.
천재들은 겨우 잘 짠다.
영재들은 헤매기 시작한다.
보통 사람들은, 늪에서 허우적거린다.
개발을 팀 단위로 모아 놓으면, 아주 가관이 된다.
천재고 영재고 간에 모두 다 함께 늪에서 허우적거린다.
이 때에는, 모두에게 잘 정리된 개발 방법론이 필요해진다.

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

* 야근/연장/휴일 개발을 해롭다. 개발자에게도 해롭고, 개발 결과물에도 해롭다. 그리고, 이 둘은 절대 분리되지 않는다.

* 반쪽짜리 제품을 만드느니 제품을 반만 만들어라

* 소프트웨어 개발에 대한 이해도가 높고 개발 과정에 대해 리딩과 코칭까지 가능한 관리자를 만나면, 개발자는 개발 내부적인 기술적 문제들에만 전념하면 된다. 하지만, 그냥 일정 압박과 닦달 기술만 가진 관리자를 만나면, 몸이 부서지게 일해도 성과는 미미하고 정말 개고생만 한다.

* 비전문적인 자가 전문적인 사람들을 데리고 융복합 전문적인 일을 하려니까 뭔가 꼬이고 뒤틀렸던 것이다.

* 심한 경우 개발자를 갈구고 괴롭히고 학대하는 일까지 서슴지 않는다. 그래 놓고, 프로젝트가 실패하면 모든 책임을 개발자들에게 뒤집어씌우는 것도 그들이다. 무능하고 게으르고 말 안 듣는 개발자들 때문에 실패했다고, 오히려 역정을 낸다. 프로젝트가 실패할 위험요소를 대부분 자기가 미리 확정해놓았으면서도, 자신은 아무 것도 한 게 없기 때문에 그 실패에 대해 책임이 없다고 우긴다. 한심한 일이다.

* 관리자 자신은 인터럽트에 너무 익숙해져 있는 존재라서 그렇다. 자기가 관리하는 개발 조직도 자신과 같다고 착각하는 게 가장 큰 문제다. 개발조직을 외부 인터럽트에 즉각적으로 반응하도록 만들어놓고 개발 생산성을 따지는 건 이상하다.
  
* 사실 스크럼은 개발에 대한 이해도가 몹시 떨어지는 사장님/팀장님의 횡포와 권력 남용과 변덕과 건망증과 무책임에 대항하기 위항 방법론이다. '개발 방법론' 이라는 후광을 빌려, 개발 과정에서 작동하는 권력 구조를 공정하고 건전하게 재편하는 게 주요 목표다.

* 이과적이고 논리적/수학적 두뇌만으로는 혼돈과 불활실성을 끌어안고 모순을 감당하며 이성과 비이성을 아우르는 시장과 마케팅의 세계를 헤쳐가기엔 부족했다. 소비자와 시장은 이성적이고 논리적이고 합리적이지 않다는 걸 알게 되는 데 그리 오래 걸리진 않았다. 이제껏 회사에서 전략기획/제품기획/서비스기획/마케팅을 담당했던 사람들의 고충을 이해할 수 있게 되었다. 기술의 불확실성은 시장의 불확실성에 비하면 차라리 예측가능하고 통제 가능한 범위에 들어있었다. 시장에서의 성공은 달리면서 움직이는 과녁에 맞추는 것과 비슷하다는 것도 알게 되었다. 모든 뛰어난 사업가/기획자들이 단 한 번의 실패도 없이 모두 성공한 제품만을 출시하는 것이 아니란 것도 알게 되었다. 기획/마케팅은 아무나 할 수 있는 것이 아니라는 것도 알게 되었다.

 

* 제품 기획부터, 프로젝트 진행, 개발과 디자인, 서비스에 이르기까지 많은 전문가들이 기여와 공헌이 절대적으로 필요하다. 협업이 가치를 만든다

 

* 체계적 협업 (Disciplined Collaboration)

  > 1단계 : 협업 기회를 평가하라

     - "협업은 목표에 도달하기 위한 수단이며, 목표는 뛰어난 성과"라는 점을 잊지 말라

  > 2단계 : 협업장벽을 파악하라, 4가지 장벽

     - NIH (Not Invented Here) 장벽 : 외부의 것을 수용하지 못하는 현상

     - 독점 (Hoarding) 장벽 : 도움 주기를 꺼리는 현상

     - 검색 (Searching) 장벽 : 사람들이 찾고자 하는 것을 찾지 못하는 현상

     - 이전 (Transfer) 장벽 : 잘 모르는 사람들과는 같이 일하기 어려운 현상

  > 3단계 : 맞춤형 해결책을 적용하라, 세 가지 수단

     - 통합 수단 (Unification Lever) : 강력한 공동의 목표/가치 제시, 동기 부여

     - 인재 수단 (People Lever) : 적합한 인재를 적재적소에 배치. T자형 경영

     - 네트워크 수단 (Network Lever) : 기민하고 비공식적인 인적 네트워크 형성 6가지 규칙 활용

 

* 시장은 크게 고급 명품과 중저가 공산품으로 양분된다. 장인적 기예를 마케팅하는 고급 명품은 상당한 비용과 시간을 들여서 마지막 1%의 품질에 몰두한다. 반면 중저가 공산품은 대량 생산/제조 시스템에 맞춰서 적절한 품질의 제품을 빠르고 싸게 많이 만드는 데 집중한다.

 

* 많은 기능을 빠르게 개발해서 출시하면, 당장은 생산성이 아주 높은 개발자로 평가 받을 수 있다. 그리고 대부분 초짜 개발 관리자들은 그런 개발자를 실력 있고 우수하다고 착각한다. 잠시 후, 오류가 밀려오고 팀의 업무가 추가 기능 개발 업무와 유지보수 업무로 뒤섞인다. 개발 속도는 빠른데, 유독 오류 발생률이 높은 개발자들이 있다. 얼핏 보면 아주 우수한 개발자로 착각하기 쉽다

 

* 테스트 활동은 개발자의 잘못된 프로그램 코딩을 교정할 수 있는 유일한 기회다

 

* 우리도 40년 이태리 장인처럼 한땀 한땀 정성 들여서 명품 소프트웨어를 만들 수 있으면 좋겠다. 아니, 최소한 사용자를 괴롭히는 나쁜 소프트웨어를 만들지는 않았으면 좋겠다.