[독서광] 글로벌 소프트웨어를 꿈꾸다

요즘 게을러졌더니 블로그 서평으로 올릴 책이 점점 쌓여가는 중이다. 오늘은 그 중에서 한 권을 골라 정리해보겠다.

바쁜 독자들을 위해 이 책을 한 문장으로 소개하자면, "글로벌 소프트웨어를 꿈꾸다"는 국내 소프트웨어 회사들이 글로벌 소프트웨어 회사로 도약하지 못하는(또는 않는) 이유를 나름대로 분석한 책이라고 보면 되겠다. 물론 이 책에는 성공 방법이 나오지는 않는다. 성공에 이르는 왕도도 없거니와 워낙 빠르게 급변하는 소프트웨어 분야에서 문화가 아닌 기술만으로 성공에 이르기가 지극히 어렵기 때문이다. 따라서 이 책은 현재 국내 소프트웨어 회사의 고질병을 한번 짚고 넘어간다는 의미에서 가치를 부여하면 틀림없겠다. 어느 정도 경력이 있는 독자라면 이미 너무나 잘 알고 있는 문제라는 생각도 들지만 물고기는 물을 보지 못하듯이 무신경 무감각하게 지나치는 상황을 제 3자가 이야기하고 있으므로 나름 의의가 있다는 생각이다.

구글을 검색해보니 서평이 많이 나오므로 굳이 여기에 내용 요약은 할 필요가 없어보인다. 하지만 이 책에서 주장하는 내용과 다른 생각을 한 가지 짚고 넘어갈 필요가 있다.

이 책에서 요구분석 - 설계 - 구현을 나눠야 한다고 여러 차례 강조를 하고 있는데, 솔직하게 말하자면 세 가지 활등은 칼로 두부 자르듯 싹뚝 자르기가 어렵다(역설적으로 이 책 본문에서도 요구분석과 설계/구현으로 나눠 분할 발주를 해야 한다는 이야기가 나온다. 저자도 어느 정도 문제점은 인식하고 있다는 이야기. ㅋㅋ). 특히 문제가 되는 부분이 바로 설계와 구현인데, 설계에 사용하는 언어(이게 장황한 텍스트가 되었든 플로 차트가 되었든 UML이 되었든 M-Spec이 되었든 무관하게)의 표현력이 프로그래밍 언어의 표현력에 미치지 못하기 때문에 건축이나 기계 공학처럼 설계도만 보고서 완성품을 만들기가 엄청나게 어렵다. 하지만 설계 구현을 나눠야 한다는 내용이 본문 중에 계속해서 나오니 어떻게 하면 설계와 코딩(!)의 구분이 가능한지 알고 싶어 거의 미칠 지경이다. 혹시 이 비밀을 아시는 분이 계시면 저녁 정말 근사하게 대접해드리고 한 수 가르침을 받고 싶다(절대로 농담이 아니다. 이런 비밀을 밝히는 논문이 나온다면 CACM이나 Computer 지의 표지를 장식할 수 있다. 아니 저커버그를 밀어내고 타임지에 올해의 인물로 나올지도 모르겠다.).

지금 반론하고 싶어 근질근질하신 분들께서는 잠시만 참아주시기 바란다. UML과 같은 강력한 모델링 언어와 디자인 패턴을 사용하면 해결 방안이 없지 않겠느냐는 생각이 들지도 모르겠는데, 그렇다면 리눅스 커널에서 사용 중인 입출력 스케줄러인 CFQ 스케줄러의 설계 도면을 한번 그려보시기 바란다(커널 전문가가 아니라서 힘들다고? 꿩 대신 닭이라고 선수용 스톱워치를 구현하기 위한 소프트웨어 설계 도면이라도 한번 제대로 그려보시라. 그리고 그 도면을 딴 사람에게 주고 추가 설명 없이 도면 그대로 구현해보라고 부탁하자. 뺨 안 맞으면 다행이다.). 음 무지무지 어렵다고? 그렇다면 구글에서 "Linux CFQ design"으로 설계 도면을 검색해봐라. 못 찾겠다고? 당연하지. (믿거나 말거나는 자유지만...) 리눅스 커널 코드 자체가 설계 도면이니까.

EOB