[책] 글로벌 소프트웨어를 꿈꾸다 - 꼬장꼬장한 영감님의 일갈
개인적으로 이 책을 얻을 수 있어서 몇달 전에 읽게 되었다. 솔직히 돈 주고 사라했으면 안 샀을 거다.
SW 공학을 (오래전에)전공한 개인의 입장으로 공학론 책은 새로운 방식이 아니면 읽을 이유를
못느낀다. 특히 이런 에세이적인 책들은 더더욱...
먼저 언급하고 넘어가자면. 나는 sw공학을 전공하였지만 방법론에 대한 우상론자나 공학론의 필요성을 내세우는 편이 아니다. 오히려 sw개발은 art와 같아야 한다고 꿈꾸는 사람이다.
여하튼 오래전에 읽은 책에 대한 리뷰를 하고자 하는 것 보다는 이 책(? 물음표의 의미는 나를 아는 사람들이 알아서 해석하시길) 에 대해서 할말이 많다.
책 단편만을 몇가지 이야기 한다면
- 저자는 극도로 Waterfall 지향자이다. - 잘 설계된 시스템은 코딩량이 적다? 따라서 설계기간이 길어야 한다. waterfall의 단점은 긴 설계기간 동안 눈에 보이지 않고, 사용자 및 시장의 요구사항은 변하며, 아무리 잘 설계된 내용이라하더라도 코딩단계에서 변경 될 수 있다는 것에 대한 문제를 배척한다. 그것은 잘못된 설계라고.
- 에자일에 대해서는 저자는 극도로 싫어한다. -애자일이 싫어해야할 대상인지 의문이다.
- 미국은 한국처럼 안한다. waterfall방식만 사용한다 (?) - 그래야 잘 된 회사다.
- 슈퍼 개발자가 회사에 있는것은 문제가 많다. 아키텍트가 필요하다. 그래서 컨설팅 해야한다.
- 슈퍼 개발자와 슈퍼 아키텍트간의 차이가 모호하다.
뭐 이정도 이고, 세세한 부분도 집고 넣어갈 곳이 많다. 물론 개인적인 견해다.
문제는 저자 분께서 컨설턴트 이시고, 나보다 학식이 훨씬 높으시며, 엄청난 경험을 하신 분이라는 점에서 나랑 견줄 수 없다.
하지만 아쉬운점은 그런 분이 패러다임의 변화를 같이 공유 못한다는것이 가장 아쉽다.
개발 방법론
sw가 산업화 되면서 공학론이 상당히 중요하다. 하지만 모든 공학론의 개념이 그렇듯이 100% 프로젝트에 맞는 방법론은 없다.
결국 방법론은 내가 처한 프로젝트에 가장 적합한 방법론을 선택해서 적용하면 된다.
그리고 그 방법론 조차도 해당 프로젝트에 맞게 tailoring을 한다.
waterfall 방법론은 sw공학의 기본 근간이 된다. 하지만 문제점이 많아 계속 변형이 되고 있고 순수한 waterfall을 사용하는 곳은 드물것이다. 그 첫번째 변형이 점진적 개발이 될 것이다. 그리고 그것이 훗날까지(?) 발전 해서 xp/agile이 되지 않았을까 한다.
점진적 개발 모델이 나온 기본 배경은 waterfall이 한번 잘못된 요구분석/설계를 되돌릴수 없는 단점에 대한 보안이다.
잘못된 요구분석/설계의 핵심은 stakeholder의 심경변화, 잘못된 의사소통, 시장의 요구 변화, 설계자의 오류 등 수없이 많다.
그래서 하자는 것이
- 말과 글로만 명세서를 남기지 말고, 간단한 mock-up을 만든다든지
- 직접 프로그램을 작성해서 stakeholder 에게 보여주자 (잦은 릴리즈)
등의 방법으로 회피 해보자는 것이다.
사실 이것은 개발 방법론의 문제라기 보다는 어찌보면 sw에 대한 기대와 시대가 빠르게 변하고 있고
그 변화에 맞추려면 방법론을 변형해가자는 것이다.
개발에도 패러다임과 유행이 있다.
모든 세상 이치가 그렇듯이, 개발에서도 마찬가지 이다.
시대가 변화해 감에 따라 개발 방법론 뿐 아니라 개발 자체도 변하고 있고, 개발 언어도 변하고 있다.
많은 언어들이 있지만 주 대표가 되는 언어를 보면
- 기계어(ASM) -> 절차식 언어(BASIC류) -> 함수식 언어(PASCAL,C류) -> 객체지향 언어(C++/Java) ->객체지향적 스크립트 언어(파이썬, 루비, 그루비 류)
식의 변화가 있다. 많은 이유가 있겠지만 핵심은 빠른 개발이 아닐까 한다.
빨리 만들어서 보여주고, 확인하고, 수정하고 이러한 방식이 지금 시대에 맞는 개발 유행이 아닐까 싶다.
XP-Agile-TDD
나는 XP 추종론자 크게 보면 방법론에 대한 추종론자도 아니다. 하지만 개인적으로 개발자로 그리고 관리자로 회사에서 14년여 개발을 진행해본 개인적 결과로는 앞서 말한데로 먼저 개발해보고 보여주고 수정하는 식의 방법이 가장 효과적 (내가 정의한 xp범위 안에서는) 이었다.
수많은 설계서, 분석서 보다 계속해서 개발-릴리즈를 반복하는 것이 sw를 정말 soft적인 방법으로 주물러서 변형할 수 있는 방법이 아니었나 싶다.
물론 내가 항공이나, 국방, 의료, 사회기간시스템등 반드시 견고해야만 하는 프로젝트를 진행해본적이 없다. 이런경우까지 xp형식의 개발이 맞다고 장담하지 않는다. 앞서 말한데로 방법론은 해당 프로젝트에 맞는 것을 선택해야 하는것이라 생각한다.
저 세가지(?) 방법론의 조합은 제시하는 각각의 절차와 activity의 내용이 어찌되었건 전체적인 큰 그림으로 볼때에는 빠른 개발이 필요한 시대 정신에 그나마 가장 가깝게 부합하는 방법론이 아닐까 생각한다.
난 이 방법론은 100%로 전체 실천해야 한다고 보지 않는다. 이 세가지 방법론 뿐 아니라 모든 방법론이 100% 실천해야 하는 항목이 아니라 본다. 하지만 최소한 내가 해본 프로젝트나 현재의 개발 시류로 보았을때 다른 방법론들 보다 그나마 가장 교집합이 많은쪽이라 생각한다.
용기
XP정신에 있었던가? TDD에 있었던가... 내가 가장 인상 깊었던 내용이다. 여러가지 용기가 있었는데 그중에서도
'기존에 만든 코드를 과감히 버리고 다시 만들 용기'
얼마전 누군가가 나에게 말했다. '지금 제대로 설계에 집고 넘어가지 않으면 다시 다 갈아 엎어야 하는데요?'
나는 답하지 않았다.
공부를 하지 않음
xp/agile을 꺼려하는 사람들이 많다. 내 개인적인 느낌으로는 국내에서 가장 유명하다는 사람이 내가 들어도 모를 추상적인 얘기만 늘어놓고 무슨 방법론이 종교집단인양 만들어버린 이유가 가장 큰지도 모르겠다.
나는 그런사람들도 극도로 싫어하지만, 더 싫어하는 것은 공부해본적도 없으면서 제대로 이해해 보지도 않았으면서 무조건 비판하는 사람이다. 모든 것이 그렇듯이 얘기를 하다보면 그사람의 수준이 파악 되는데 한마디로 이런사람들이랑은 더이상 이야기를 안하는것이 옳다. 그들의 대부분이 말하는 얘기는
- 'xp 적용하신다면서요. 왜 이것은 빼나요?'
다시 말하지만 나는 xp를 하고 싶은것이 아니라 내가 하는 프로젝트를 잘 만들고 싶을 뿐이다.
실망감 또는 오해
다시 책으로 돌아와서 책의 저자를 직접 만날 기회가 있었고 지금도 만나고 있다.
엄청 훌륭하신 분이다. 경기고-서울대(집에 책이 없어져서 기억나는데까지만이다.) sun microsystem근무 등 뭐 나같은
허접과는 비교하실 수 없는 분이시다.
개인적으로 이분 뿐 아니라 교수님들, 사장님들, 사회지도층들, MB님 모든 훌륭하신 분들은 그분들이 갖고 계신 지식을 그 당시(당신들이 가장 왕성하실때)에 어렵게 얻으신 지식으로 지금 시대에 그대로 잣대를 들이 대신다.
변화는 감지 못하시고, 변화를 그분들의 잣대에 맞춰본다. 그리고 '잘못됐다. 혹은 애들이 어려서 그렇다'로 결론 지으신다.
가장 안타까운 대목이다. 훌륭하신 분들이 변화를 잘 이해하시고 과거 어렵게 얻으신 지식과 경험들을 후대인 우리에게
융합시켜서 좀더 최선의 길을 선택하도록 인도해주시면 좋을텐데...
책에 대해 깐죽대기
좀 주제 넘게 깐죽대보면 책을 읽은 소감은 한마디로
- 우리 어렸을때 도덕시간이 생각난다. '미국이나 일본같은 선진국에서는 한국같지 않다. 길거리에서 침도 안뱉는다'
그 생각이 가장 많이 났다.
막상 가보니?
거지도 많고, 쓰레기도 널부러져있고, 침도 뱉고, 껌도 붙어있고, 새치기도 많이하고, 무단횡단도 많이 하고....
트위터, 페이스북 엄청나게 몰리는 서비스/시스템 내가 알기로는 설계를 처음부터 잘한게 아니고 몇번 갈아 엎었다.
고래 아직도 보지 않는가...얼마전 시스템 갈아엎어서 덜 보게 될꺼라고는 하지만...
얼마전 본 '소셜네트워크'영화에 보면 잘나온다. 주크버그가 만든 'the facebook' 설계기간???
그리고 웹 2.0 개념이 주장하는 '영원한 베타'는 나오면 안되야 할 듯.
슈퍼 개발자의 문제와 같이 슈퍼 설계자를 만들자는 것은 아니었는지 고민 해볼만 하지 않을까 싶다.
최근 덧글