[독서광] 글로벌 소프트웨어를 말하다 (지혜)

한빛미디어에서 선물로 주셨기에 이 책을 열심히 읽었으나... 읽다가 다소 난감한 느낌이 든 책이라고 솔직히 말해야겠다. 바쁜 독자를 위해 아주 간단하게 이 책을 요약하자면, "착한 개발자들은 SRS(Software Requirement Specification)를 열심히 쓰고 소스 코드 관리(특히 merge)를 잘하고 이슈 추적 시스템을 꼼꼼하게 활용한다"로 정리할 수 있겠다. 하지만 책에 how가 없다는 점이 함정.

책에서 충격 요법을 위해 국내 개발자들을 디스하고(166페이지: "대부분의 국내 개발자들은 코딩 습관상 오픈소스 커뮤니티에서 불량배로 취급받을 확률이 크니 오픈소스에 참여하더라도 주의해야 한다.") 실리콘벨리를 추켜세우는 내용까지는 손발이 오그라들어도 그려려니 하지만(본문에서 강조하는 국내 소프트웨어 시장이 진흙탕인 사실은 충분히 이해하고 인정한다!), 코딩 작업을 아르바이트생에게 시킬 수 있다는 표현(146페이지: "모든 method를 정의하고 나면 이제는 아르바이트생에게 코딩을 맡겨도 된다. 귀중한 시간을 쉬운 코딩에 소비할 수 없다.")은 정말 아니라는 생각이다. 세상에 코딩이 쉽다니! SRS와 비교해 상대적으로 코딩이 중요하지 않다고 말하려 했을지는 몰라도 이미 물은 엎질러졌고...

이쯤에서 코딩 호러 블로그의 Dysfunctional Specifications에 나오는 리누스 토발즈 큰 형님의 명세 관련 이야기를 잠시 들어보는 편이 균형 감각 배양에 도움이 될 것 같다. 애독자 여러분을 위해 잽싸게 번역해보았다.

"명세"(spec)는 무용지물에 가깝다. 유용하면서도 정확한 명세를 본 적이 없다. 하지만 명세에 기반해 완전히 헛발질한 작업은 많이 목격했다. 명세는 소프트웨어를 작성하는 최악의 방법이다. 정의만으로 현실이 아니라 이론과 일치하기 위해 소프트웨어를 작성했음을 의미하기 때문이다. 명세를 피해야 하는 두 가지 이유는 다음과 같다:

1. 명세는 위험할 정도로 잘못되었다. 현실은 다르다. 그리고 명세가 현실을 심사숙고한다고 생각하는 사람은 누구나 커널 프로그램에서 _지금 당장_ 손을 때야 마땅하다. 현실과 명세가 충돌할 때, 명세는 아무 의미도 없다. 0. 전무. 전혀 없음. 뭐라고 할까? 과학과 비슷하다. 실험과 일치하지 않는 이론이 있다면, 당신이 해당 이론을 얼마나 좋아하는지는 중요하지 않다. 이론이 잘못되었을 뿐이다. 명세를 근사치로 사용할 수는 있지만, 어디까지나 근사치라는 사실을 _명심_해야 한다.

2. 명세는 필연적으로 글로 쓴 명세에 의미가 있는 추상화 수준과 단어 선택과 문서 정책을 수반한다. 명세에서 실제 코드를 구현하려 시도하면, 코드가 형편없는 듯이 보인다. 이런 현상의 고전적인 예는 OSI 네트워크 모델 프로토콜이다. 실제 세상과 완전히 무관한 전통적인 명세 설계말이다. 여전히 사람들은 7 계층 모델에 대해 이야기하고 있지만 대화에 편리한 모델이라서 그렇지 실제 소프트웨어 공학과는 아무 관련이 없다. 다시 말해, 명세는 사물에 대해 이야기하는 방법이지 사물을 구현하는 방법은 아니다. 그리고 이런 사실이 중요하다. 명세는 사물에 대해 이야기하는 기반이다. 하지만 소프트웨어 구현을 위한 기반은 아니다.

따라서 남들이 명세에 대해 뭐라 하든 신경쓰지 마라. 명세 때문이 아니라 명세에도 불구하고 진짜 표준은 성장하기 마련이니까.

오늘의 희한한 결론: 위대한 SRS도 작성하지 않고 만들어진 리눅스는 글로벌 소프트웨어가 아닌 모양이다.

뱀다리: 선물 받은 책임에도 불구하고 호의적인 서평을 쓰지 않은 이유는 간단하다. 열심히 일하는 개발자들을 오도할 가능성이 높은 내용이 여기저기 들어있기 때문이다. [B급 프로그래머] "‘한국의 저커버그’가 양성되기 위한 조건"에 대한 불만에서 알맹이 있는 책을 출간해 달라고 요청했지만 돌아오는 대답(아시는 분은 아시겠지만 ‘한국의 저커버그’ 글과 '글로벌 소프트웨어를 말하다' 책을 쓴 분들은 같은 컨설팅 회사 소속...)이 이 정도라면 실망이다.

EOB