IT 업계 종사한지 12년된 엔지니어이다. 결론부터 말하면 저자의 이야기에 40% 정도만 공감한다.

결국 저자가 이야기하고 싶은 내용을 아주 간단하게 나름대로 요약해 보면 아래와 같다.

1. 우리나라에서 소프트웨어를 제대로 개발하는 곳은 아무데도 없다.

2. 제대로 된 소프트웨어를 개발하려면 분석과 설계가 제대로 되어야 한다.

3. 개발 역량을 키울려면 깨달음이 필요하다. 그러려면, 좋은 스승과 멘토가 필요하다.

물론 이 외에도 많은 꼭지들이 있다. 하지만 주로 이야기하는 흐름을 요약해 보면 대충 저 3가지가 될 것이다. 차근차근 생각해 보자.

1. 우리나라에서 소프트웨어를 제대로 개발하는 곳은 아무데도 없다.

거의 대부분 공감한다. 우리나라 소프트웨어 개발의 현실, 특히 SI는 너무나 왜곡된 부분이 많다. 모든 분들이 대부분 공감하는 내용이니 가볍게 패스.

2. 제대로 된 소프트웨어를 개발하려면 분석과 설계가 제대로 되어야 한다.

30% 공감한다. 분석과 설계 능력이 중요한 것은 맞다. 하지만 저자는 전통적인 Waterfall 방법론에 근거하여 분석과 설계의 중요성을 강조하고 있다. 항공모함을 만들듯이, 우주 정거장을 만들듯이 미래를 예측하여 요구사항을 SRS로 완벽히 도출해내야 한다. 이를 기반으로 완벽하고 세심한 설계를 하고 코딩은 코더가 하면 된다. 그런데 SRS를 제대로 적을 수 있는 사람이 없으니 우리나라 소프트웨어 현실이 요모양 요꼴이다. 이게 저자의 사상의 핵심이다.

그런데 정말 그럴까? 항공모함에 들어가는 소프트웨어, 우주 정거장에 들어가는 소프트웨어를 만든다면 저자의 말대로 하는 것이 맞다. 그런데 대부분의 소프트웨어는 비즈니스 환경에서 돌아간다. 급변하는 환경 속에서 정확하게 미래를 예측하고 기획해서 완벽한 설계를 하는 것이 가능할까? 난 불가능하다고 생각한다. Waterfall 방법론이 공격을 받는 주된 이유이다. Waterfall 방법론이 효율적이고 성공적이었다면 2000년대 들어 애자일 방법론이 열풍을 일으키지는 않았을 것이다. 저자는 이를 완전히 간과하고 있다. (왜  Waterfall 방법론이 까이는지는 Martin Fowler가 새로운 애자일 방법론에서 자세히 설명하고 있다)

저자의 사상이 위험한 또 한 가지 이유는 자신의 주장에 대한 근거로 비유를 너무나 많이 사용하고 있다는 점이다. 설계를 예술, 건축과 비교하면서 논지를 펼쳐나가고 있다. 설계는 예술성과 창조성의 결과물이기 때문에 평가하기 어렵다고 말한다. 물론 설계는 평가하기 어렵다. 그런데 설계가 꼭 예술적이고 창조적이어야 할까? 그렇다고 생각한다면 그 근거는 무엇인가? 

마틴 파울러는 비유나 은유를 통해 자신의 주장을 합리화하는 것을 무척이나 경계한다. 나도 그에 동의한다. 비유는 비유일 뿐이다. 어떤 주장을 좀 더 이해하기 쉽도록 하는 역할을 한다. 그런데, 비유가 어떤 주장을 정당화하는데 쓰인다면 이는 상대방을 현혹시키는 사기일 뿐이다.

마틴 파울러가 애자일에 대해 쓴 글들, 그리고 많은 애자일 서적들을 보면 자신의 주장에 대해 합리적인 논거를 들어가면서 하나하나 설명한다. 그리고 저자들이 했던 풍부한 경험도 이야기해 준다. 어떤 프로젝트에서 어떤 문제가 있었는데 이렇게 하니까 해결이 되더라는 식으로 이야기한다. 적어도 뜬구름만 잡고 있는 저자보다는 훨씬 더 합리적이고 이성적이다.

3. 개발 역량을 키울려면 깨달음이 필요하다. 그러려면, 좋은 스승과 멘토가 필요하다.

10% 공감한다. 좋은 스승과 멘토가 있으면 개발 역량을 빠르게 키울 수 있는 것은 맞다. 그런데 뜬금없이 깨달음 이야기를 자주 한다. 우리나라 소프트웨어 현실을 신랄하게 비판하면서 깨달아야 이 현실을 바꿀 수 있다고 이야기한다. 그런데 웃기는 게 깨달음이란 개인이 알아서 해야 하는 것이라고 한다. 이건 뭥미?라는 질문이 나오는 대목이다. 앞에서 실컷 분석과 설계가 중요하다고 한다. 그래서 사람들이 분석과 설계 능력을 좀 키워보겠다고 SRS 샘플과 설계 샘플을 달라고 한단다. 그런데 본인들이 직접 깨달아야 하기 때문에 샘플을 주는 건 아무 의미 없다고 한다. 이게 도대체 무슨 논리인지 모르겠다. 면벽 수련을 하다 보면 SRS와 설계를 잘 할 수 있는 깨달음을 갑자기 얻게 되는 건가?

그리고 내 개인적인 느낌으로는 위의 세 가지를 이야기하면서 은근히 자신은 훌륭한 선각자, 스승, 멘토라는 나르시시즘을 표출한다. 물론 이는 전적으로 주관적인 느낌이다. 그리고 우리나라 소프트웨어 산업을 필요 이상으로 폄하하는 느낌도 받는다.

그런데 내가 보기엔 저자도 별반 다르지 않아 보인다. 문제해결 역량이 중요하다고 했다. 맞다. 중요하다. 그런데 저자 역시 우리나라 소프트웨어 산업의 문제를 신랄하게 비판하고는 있지만 정작 그가 제시하는 해결방법은 구체적이지도 않고, 전략적이지도 않다. 뜬구름 잡는 얘기에 공감 안가는 것들이 대부분이다. 내게는 그냥 사람들을 현혹시키는 전형적인 사기꾼 컨설턴트로 밖에 보이지 않는다.

글로벌 소프트웨어를 말하다 [지혜]

저자 : 김익환

출판사 : 한빛미디어

한국의 소프트웨어 산업이 위태롭다고 소리 높여 말한다. 어디서 문제인지 여기 저기서 원인 및 대책이 쏟아져 나오고 정부에서도 소프트웨어 인력을 양성해야 한다는 명목으로 다양한 정책과 지원을 내 놓는다. 그럼에도 불구하고 전 세계적으로 성공을 거두었다는 소프트웨어를 찾아 볼 수는 없다. 도대체 무엇 때문일까?

화제를 바꿔보자. 이상하게도 한국의 건축 산업은 전 세계적으로 제법 인기가 있다. 규모가 있는 건축물을 공기도 상당히 단축 시키면서 화려하고 멋있게 지어낸다. 그런데 IT 산업의 많은 부분이 건축에서 차용되었다는 사실에도 불구하고 한국의 소프트웨어 산업은 고전을 치르고 있다. 아니 상당히 비슷한 프로세스를 가졌음에도 불구하고 왜 한 분야에서는 세계적으로 인정을 받으면서 다른 분야에서는 거의 존재감 조차 발휘하지 못하는 것일까… 개인적으로 한국인의 문화에 기인한다는 생각을 했다. 가시적이고 보이는 것이 우선인 한국의 문화는 건축과 같이 공정이 눈에 보이는 분야에서는 두각을 나타낼 지도 모르지만 소프트웨어와 같이 무형의 산업에서는 힘을 쓰지 못하는 것은 아닐까 하고 말이다. 그러다 보니 한국의 소프트웨어 산업은 음성적으로 다양한 문제를 내면에 지니고 있다. 문제는 많은 사람들이 그 문제를 알고 있으나 결코 개선될 기미가 보이지 않는 다는 점이다.

개인적으로 IT 프로젝트를 관리하는 입장에서 구조적으로 문제가 되고 있는 부분에 대해 고민할 기회가 많았는데 이 책은 마치 선배의 독설과 같이 가감 없이 한국 사회가 안고 있는 소프트웨어 산업의 문제를 풀어낸다. 결코 순화된 언어가 아니고 직격탄을 날리기에 책을 읽는 내내 통쾌하기도 했다. 그러나 한편으로는 IT 강국이라는 보이는 외면에 비해 일본의 강점기와 6.25 전쟁을 거치면서 무조건 열심히, 질보다는 양과 같은 뿌리 깊은 내면의 상처를 치유하지 못한 상태에서는 그 어떤 처방도 효과가 있지는 못할 것이라는 생각도 든다. 특히 IT를 체계적으로 이해하지 못한 상태에서 CIO, CTO의 반열에 올라 IT역량 보다는 다른 비즈니스 역량을 통해 IT 산업을 이끌어 가려는 선배들을 볼 때면 안타깝기도 하다. 이 책은 어쩌면 그런 선배들에게 또 그런 선배들과 맞짱 뜨지 못하는 안타까운 후배들에게 던지는 소중한 충고처럼 느껴진다.

책은 3가지 정도의 핵심 메시지를 던진다. 첫째로 한국이라는 좁은 갈라파고스에서 벗어나야 한다는 것이다. 저자는 한국에서 만들어지는 소프트웨어는 다분히 한국에서만 소화할 수 있다고 말한다. 그것은 한국이 품질이 아닌 서비스로 승부하기 때문이라고 했는데 크게 공감을 했다. 무엇을 공급하는 사람의 첫 번째 마인드는 품질의 완벽성이다. 품질이 완벽하지 못한 채 사후 서비스로 모든 문제를 해결하려는 사고방식은 한국에서나 통하지 글로벌 환경에서는 결코 먹히지 않는다는 것이다. 또 그렇게 된 데는 한국 개발자들이 마치 독립된 섬 처럼 단독적으로 일하는 문화와 개발 효율이 아닌 유행 따라 툴을 쫒아다니는 것과 같은 현상을 들 수 있다. 대세가 자바이니 자바로 개발해야 한다가 아니라 우리가 완벽한 품질을 맞출 수 있는 개발 툴이 있다면 그것으로 개발하는 것이 정답이라는 말이다.

둘째로 개발자가 개발에 충실하게 임하지 못하는 문화를 꼬집는다. 나도 많이 봐 왔지만 한국에서 소프트웨어를 개발하기 위해 요구사항을 분석하려고 하면 현업에서 돌아오는 말은 대부분 비슷하다. “저희보다 잘 아시니까 그냥 아시는데로 해주시면 됩니다.” 또는 “어떻게 방향을 잡아야 될 지 모르니 일단 개발해 놓고 보시죠.” 이런 환경에서 무슨 품질 좋은 프로그램이 개발 되겠는가? 이렇게 도메인 지식도 익혀야 하고 현업과도 커뮤니케이션 해야 하는 환경에서 한국의 개발자들은 점점 지쳐가고 3D 업종이라는 낙인 속에서 사회적으로도 무시를 당하게 되는 문화가 안타깝게만 느껴진다.

마지막으로 설계보다는 개발에 치중하는 문화다. 건축은 기본적으로 설계와 시공이 분리되어 있다. 설계가 완벽하면 그대로 건축물을 올리는 것은 크게 문제가 되지 않기 때문이다. 그래서 설계는 아름다워야 한다. 그러나 한국의 IT에서 설계는 그저 형식에 불과하다. 형식적으로 설계라는 단계를 놓고 개발에 많은 자원을 투입하는 경우가 대부분이다. 그래서 설계가 아름다운 경우를 찾기 힘든 것이다. 책에서 설계 단계가 필요한 경우를 다음과 같이 말한다.

설계 단계가 있는 이유는 잘못된 설계를 버리거나 변경하는 것을 반복할 수 있는 기회를 주기 위해서이다. 코딩 단계에서는 버리기보다는 고치는 경우가 많지만 설계 단계에서는 고치는 것이 아니라 버리는 것이다. 화가는 그림을 그리다가 잘못되면 처음부터 다시 그린다. 그리다 말고 고치거나 하지 않는다. – p235

남들이 다 그렇게 하니까 우리도 그렇게 해야 한다는 사고로는 최고가 될 수 없다는 것은 이제 분명하다. 한국의 문화가 그러니까 우리도 어쩔 수 없이 쫒아가야 한다는 생각이 위험한 이유다. 소프트웨어 산업이 진정으로 발전하기 위해 이런 책을 통해 이 분야에서 종사하는 사람들의 의식이 바뀔 수 있는 기회가 되길 희망한다.

음악에서는 연주할 곡이 완성되지도 않은 상태에서 연주할 수 있는 방법이 없다. 그런데 국내 소프트웨어에서는 무엇을 만드는지도 잘 모르는 상태에서 만들기 시작하는 경우가 허다하다. 반쯤 작곡된 곡을 미리 연주하겠다는 것이다. – p23

노래하는 멘토르

책은 280 페이지 정도 분량이다. 

이전 글로벌 소프트웨어를 말하다.  

책보다 국내의 부분에 대해서 많은 부분을 다루고 있는 듯 하다. 

책의 내용은 국내의 현실에 대해서는 

많은 부분 공감이 가는 부분도 있고 

개인적으로는 공감하지 못하는 부분들도 있었다. 

그거야 개인적인 생각이 다 틀리니 당연할듯 하다. 

1장은 분석,설계의 중요성에 대해서 얘기를 하고 있는듯 하다. 

우리나라의 IT 는 지식산업보다는 노동산업이 라고 볼 수 있다는 거에 동감한다. 

실제로 개발자의 직업코드도 그렇게 분류가 되어있다. 

분석,설계의 중요성은 충분히 공감하지만 개발에 대한 낮은 중요도는 

조금 이해가 가지는 않았다. 

특히나 건축의 벽돌공에 대한 예는 그 의도는 안그렇겠지만

비하하는것처럼 느껴질수도 있어 읽는데 불편함이 있었다. 

자신은 감동을 받아서 공유하고 싶어 올리는 글이 

스스로 그렇지 못하다는걸 증명하는 거라는것도 조금은 의아했다.

같은 예로 기부를 늘 해온 사람들은 아름다운 기부얘기를 들어도 

별로 감동이 없다는 얘기도 공감이 가지는 않았다.

나도 사실 다달이 약간의 후원을 하고 있지만 그게 참 쉽지 않은 

일이기에 그런 얘기를 들으면 참 대단하다고 생각하고 감동을 한다. 

원래 전달하려는 의도는 그렇지 않겠지만 ..

2장, 3장은 주로 개발자에 대한 내용인듯 하다. 

국내의 개발문화(?) 와 실리콘밸리의 개발문화(?) 에 대한 차이와 

그에 대한 국내 개발자들에 대한 한계(?) 에 대한 내용인듯 하다. 

내용의 요점은 글로벌 로 가기 위해서 

국내 개발자들에게 필요한 부분에 대한 내용을 다루고 있는 듯 하다. 

좋은 내용이 많았지만 국내 개발자에게 얘기했을때 환경때문에 힘들다 

는 얘기를 많이 한다는 내용에 개인적으로도 많이 공감한다. 

일예로 한 대기업의 경우 자기 위 상사가 후임의 승진에 

지대한 영향을 끼친다. 

잘못된 명령을 내렸을때 그 개발자가 추후 영향도를

최소화 하는 방향으로 개발을 하기 위해 상사가 제시하는 일정에 반론을 핀다면 

그 개발자는 승진을 하기 힘들다. 

아직도 상하간에 권위적인 부분이 많은 우리나라 기업문화에서는 참 힘들다.

사실은 그 상사도 어찌할 수 없는 부분이 있기도 하다. 

우리나라의 IT 는 지식산업이 아니라 노동산업 이라고 봐도 거의 무방하다. 

그렇게 생각하는건 IT 회사들뿐만이 아닌 발주한 발주업체들의 사고방식도 마찬가지이다. 

하나의 화면이 몇달에 걸쳐서 개발이 되어야 하는 경우도 많은데

그러한 부분을 이해를 하지 못한다. 

단순히 본수로 체크를 한다. 

복잡한 화면도 1본 , 단순한 화면도 1본 

그러한 부분에 대해서 고객사들에게 충분히 이해를 시키는 부분도 중요한데

그러한 부분이 부족함이 많은게 현실이다. 

엉성한 계약에 대한 내용도 많이 공감을 했다. 

수주를 위한 제대로 된 업무량 파악도 없이 뛰어든 저가수주에 

중간에 고객이 요구사항을 바꿔서 발생하는 비용에 대한 부분도 

그 비용에 대한 정확한 언급도 없는 두리뭉실한 계약

저가 수주에 따른 인력의 최소화에 고객사의 수도없이 바뀌는 요구사항들..

분석,설계에 많은 시간을 투자해야 하지만 결국은 저가 수주에 따른 

비용문제로 인력의 최소화와 고객사가 제대로 된 요구사항을 내놓지 않아도 

그에 대한 명확한 책임이 없는 

경험이 쌓이면 들어온 일에 대해서 어느정도 시간이 소요될지 산출을 할 수 있다. 

개발자가 그 일정을 제시를 못한다는건 

그 모듈에 대한 정확한 요건이 나오지 않았다는 반증이기도 할 것이다. 

비단 이런 부분은 국내에서만의 문제는 아닌듯 하다. 

예전 중국 개발자들을 고용한 프로젝트가 있었는데 

국내에서 분석,설계하여 그 문서를 중국의 중개자 에게 전달하면 

그 중개자가 중국 개발자에게 그 문서를 전달하여 개발을 하는 구조였다. 

그렇게 중개자를 거쳐 개발하는거에 부담을 느껴 

처음에는 내가 그냥 개발하겠다 했으나 중국업체와의 계약때문에 그렇게 

할수없다고 하여 어쩔수 없이 설계서를 작성해서 보낸 적이 있다. 

설계서를 보다 완벽하게 만들어서 보내려고 

아예 설계서에 90% 정도 구현을 한 의사코드 형태를 같이 보냈었다. 

개발이 완료되었다고 하여 받은 개발물을 보고 깜짝 놀란적이 있다. 

실행을 시키면 정상인데 결과가 떨어지지 않는다. 

소스를 열어보니 개발한 코드들이 예외문에 들어가 있었다. 

에러가 떨어져야 결과물이 나오는 구조인것이다. 

알고보니 중국에서 계약한 그 형태가 일반직종의 2배정도의 급여라 

상당히 괜찮은 계약이었다고 한다. 

중국의 인력이 많다보니 하루라도 일정을 지키지 못하면 바로 대체 

그러다보니 일정을 지키기 위해 무조건 정상으로 결과가 떨어지게 만드는것이다. 

그 뒤로는 중개자에게 한번 만들어진 결과물은 내쪽에서 수정하겠다고 양해를 구하고 

그냥 결과물이 오는대로 내가 다시 개발한 기억이 있다. 

한가지 배운점은 그때까지 나는 자바 1.3 버전의 API 를 사용했는데 

최신 API 를 사용해서 구현이 되어있어 최신 API 사용부분에 대해서는

배운점이 있었다. 

해당 부분도 IT 를 노동산업으로 보고 1본에 대해서 일정한 

개발일정을 잡아놓은 상황이라 생긴 일이라고 생각한다. 

어차피 그 일정도 국내에서 요구한 것일테니 마찬가지인가.. 

아직까지 국내의 IT 는 책에서 얘기하듯 노동산업으로 보고 있는게 참 불편한 현실인듯하다. 

상황이 점차 나아지겠지 하는 생각을 많이 했지만 

아직까지는 경기가 어려워지면서 더욱 나빠지기만 하는 듯 하다. 

내가 일하는 IT분야에서는 백발의 개발자는 기대하기 힘들다. 

40대 중반이 넘어가면 개발자로 있기가 힘들다.

정말 소수의 개발자만이 50대 초반까지 있는 경우가 있다. 

그것도 개발자라기보단 해당 업무를 수십년동안 해서 업무에 대해서 인정받는 경우...

국내 IT 를 생각하다보니 글이 길어진듯 하다. 

책에서 얘기하는것처럼 우리나라 IT 도 지식산업으로 인식이 빨리 되기를 기원한다.  

책은  재미있게 읽었다. 

IT 실무자들이 읽어보면 공감가는 부분들이 있어서 좋을거 같고 [다만 씁쓸함이 클 수 있다.]

IT 를 시작하는 분들이 읽어보면 좀더 넓게 볼 수 있어 좋을듯 하다. 

가장 근본적으로 한국에서 SW 가 안되는 원인은...

우리들끼리만의 세상에서 살고 있기 때문입니다.

터무니 없는 고객의 요구, 그 요구를 그대로 들고 오는 영업,

몇번 방어하다 체념하듯 받아 들이는 개발팀, 당장의 매출이 늘어서 좋은 CEO,

터무니 없는 요구가 쉽게 받아져서 좋은 고객사... (언제든지 수정사항을 말해도 추가 비용없이 그대로 OK)

일단은 돌아가는 SW/시스템, 매출은 증가하는 개발 회사, 일단은 한순간의 영업/메니저 압박을 피한 개발팀...

그러나 예측할 수 없는 시기와 형태들로 터져나오는 버그, 그 버그를 수정하기 위해 회사의 Core 개발자를 투입하는 회사, 버그를 양산하는 제품을 Base로 수많은 파생 과제를 물고 오는 영업 부서, 앞으로 벌고 뒤로 깨지는 줄 모르고 매출만 챙기는 CEO

결국 개발 회사는 망하거나... 고객사의 피를 빨면서 연명하거나... 둘중의 하나의 운명.

그나마 임베디드 SW는 좀 사정이 나은 편이지만,

결국은 선진국에서 ROI가 나오지 않는 것들의 뒤치닥 거리

(그렇게 단가를 싸게 후려치면서 코드 품질 요구는 또 왜 그렇게 많은지...)

이 분야도 결국은 중국에 조만간 넘어갈 듯...

이제 IT에 있은지도 10여년이 넘었지만 가장 확실한 개선책은...

개발자 스스로가 이러한 환경을 벗어나기 위한 개인적인 노력밖에는 없다고 생각됩니다.

(전체적인, 근본적인 개선은 힘들다고 봅니다.)

개발자들이 본 도서의 개발 프로세스를 실행은 하지 못하고 있으나 그렇게 할 만한 가능성도 많고,

그러한 환경이 주어지면 외국 개발자 만큼의 능력도 보임을 외국에 나가 있는 국내 개발자들을 통해 가늠이 됩니다.

개발자들이 더이상 이 좁은, 우리끼리만의 세상에서 벗어나 정당한 대우와 환경을 받을수 있도록...

프로그램밍 언어뿐만 아니라, 좀더 나이가 더 들기 전에 (매일 의미 없는 야근으로 인생을 갉아 먹지 말고) 외국어에 투자하여 과감히 해외로 진출하였으면 합니다.

그렇게 개발자들이 글로벌한 영역으로 진출하게 되어야(정확하게는 비싼 몸값의 SW의 개발자만 구할수 있어야), 그제서야 우리끼리만의 세상에 기생하는 SW 상태계가 근본적으로 없어질 것으로 생각됩니다.

(PS: 오픈소스 프로젝트 싸이트에서 정말로 너무나 기본적인 질문들을 반복적으로 대담하게 하는 인도, 중국인들을 보고 좀 심하다 싶었는데... 다시 생각해 보면 그런 질문도 없는 한국개발자들은 외국대학에서 질문 한마디도 못하는 한국학생과 비슷하다는 생각도 듭니다. 우리가 너무 소극적입니다.)

[글로벌 소프트 웨어를 말하다,지혜]

IT업계의 종사자, IT계통에서 일하고자하는 사람은 읽어보기를 추천한다.

현재 한국 소프트웨어 산업의 문제점

Top-down방식

한국의 개발자(혹은 회사)가 프로그램을 만들 때 간과하고 있는 점은

간단한 코딩으로 예를 들어서

알기 쉽게 설명한 점이 좋았다

그 외에는

너무 유행에 횝쓸려간다면 시간낭비가 되는 이유 등

한국IT업계가 가지는 문제점과 해결책 등을  적고 있다

나는 프로그래밍을 배운지 얼마 안된 초보이다

읽어보고 개안했다 이 정도는 아니었지만

IT업계가 이렇게 돌아가고 있구나라는 것을 알게되었다

리뷰테스터로 당첨되어 받은 책이다.

소프트웨어 시장에 대한 이렇고 저런 이야기들이 담겨있다.

실리콘 밸리와 우리나라를 비교하며 적은 내용들이 초반에 많이 보인다.

책을 계속 읽다보면 유익한 내용도 있지만 거슬리는 내용도 몇 몇 부분 들어온다.

내가 아는 것이 없어서 용감한 것인지는 모르겠지만...

한번쯤 읽어보면 도움이 될만한 책인 것은 분명하다.