소프트웨어 공학에 관심이 많은 나는 스티브맥코넬, 조엘 등 안읽은 책이 없이 다 읽어보았다. 이들 책도 모두 좋은 내용들로 가득차 있어서 읽을 때는 고객을 끄덕이게 하지만, 다 읽고나면 실무에 적용하기에는 항상 뭔가 부족했었다.

실제로 공유문화, 리뷰문화에 대한 내용을 접하고 실무에 코드리뷰를 적용해서 아무리 애를 써도 성공적인 성과를 거두지 못했었다. 이 뿐만이 아니고 대부분의 내용이 국내 현실을 제대로 반영하지 못해서 좋은 내용이라 하더라도 먼나라 얘기처럼 느껴졌었다.

하지만 "글로벌 소프트웨어를 꿈꾸다"는 마치 우리 회사에 와서 몇달 분석을 한 것과 같이 우리 회사 얘기가 자세히 적혀있었다. 코드리뷰만 하더라도 이 책에서는 "코드리뷰를 하지마라"라고 강조를 한다. 즉, 우리나라 대부분의 소프트웨어 회사에서 왜 코드리뷰가 실패하는지 자세히 나와있다. 이부분을 읽으면 "아하!"하고 무릎을 치게 된다.

스티브맥코넬이나 조엘스폴스키는 절대 모르는 우리나라의 현실적인 얘기가 적혀있고, 어떻게 해결해야 하는지 제대로 된 가이드가 적혀있다.

왜 진작에 이런 책이 안나왔나 아쉽다. 몇년전에 이 책을 읽었으면 지금과 같은 시행착오는 안했었을 것이다. 저자의 이력을 보니 미국에서 16년, 한국에서 10년의 소프트웨어 업계 경력을 가지고 있다. 그렇기 때문에 이와 같이 명쾌한 답을 제시하는 것이 아닌가 생각한다.

저자는 우리나라 소프트웨어 회사들이 글로벌 회사로 발돋움 하기 위한 방법을 제시할 수 있는 유일한 사람이 아닌가 생각된다. 책상 앞에 놓고 여러번 읽을 가치가 있는 책이다. 

먼저 책의 진입장벽 부터 말하려 한다.

  이 책은 교양 서적이 아니다. "에자일(Agile), UML, SRS,

임베디드 시스템"의 단어를 모른다면 그냥 넘어가길 바란다. 가르침이

목적인 책도 아니다. 시대에 흐름을 말하고 정확한 소프트웨어 개발

방법과 방향을 소개하는 책이다. 책을 읽는것도 중요하지만 책을 읽은 후에

노력이 더 중요하다.

  컷트라인을 말하자면, 학부생 컴퓨터 공학 전공 2학년 수준이면 제대로

읽을 수 있다고 생각한다. 그리고 정말 추천한다.

2010년과 시의 적절함

  아이폰의 상륙으로 오만 방자하던 우리나라 휴대폰 업계가 발칵 뒤집혔다.

하드웨어 중심의 휴대폰 산업이 정신없이 흔들리고 소프트웨어, 즉

콘텐츠의 중요성을 깨닫기 시작했다. 대기업은 소프트웨어 인력을 모조리

흡수하려고 하고 있으며, 톡톡 튀는 아이디어로 창업을 하는 1인 기업도

있다. 이럴 때 누구나 한번쯤 생각해 볼 법한 질문! 

  "우리나라는 왜 구글이나 페이스북 같은 글로벌 기업이 없을까?"

그 해답이 바로 ＜글로벌 소프트웨어를 꿈꾸다＞에 있었다.

학생의 입장으로 새로운 길이 열리다.

  전공관련 서적이라곤 개념과 기술적 내용이 있는 책만 보던 내가 얼마나

한심했는지를 깨달았다. 가장 변화가 빠르게 진행되고 있는 분야인 만큼 시대의

흐름을 적절하게 읽을수 있는 ＜글로벌 소프트웨어를 꿈꾸다＞와 같은 책이

필요했다. 목적지가 정확이 있어야 조금 돌아가더라도, 언덕을 만나더라도

원하는 곳에 갈수 있는 것이다. 공부하기 전에 어떻게 공부할 것인가에 대한

고민을 먼저 했었어야 했다. 늦은감이 있지만, 소중한 고민의 시간을 가졌다.

  학교 교수님이라고 모든것을 알려줄 수는 없다. 죄송한 말이지만, 나이든

교수님은 어쩌면 학생보다도 현재 흐름을 바라보고 대처할 수 있는 유연성이

떨어질 수 있다. 교수님의 수업이 틀리진 않지만, 시대 흐름은 놓칠 수 있다.

특히 작은 부분일 수록 교수님의 손길이 닿지 않기 나름이다. 아무생각 없이

주어먹기에 열중하는 대학생활에 대한 반성을 해본다.

  4학년을 바라보고 있는데 이제야 이런게 보이다니 절로 욕설이 튀어 나온다.

그나마 지금에서야 이런 책을 접하게 되어 고맙고 다행이란 생각이 든다.

누가 공대인 아니랄 까봐...

  내가 나중에 머리가 더 커서 글을 쓴다면 이 책의 저자처럼 글을 쓰지

않을까?란 생각을 어렴풋이 한다. 이성적인 접근에서 감성적인 공감을 이끌고

근거가 부족한 부분은 직접 표를 만들어서 독자를 이해시키려는 노력을 했다.

여러가지로 많은 공감대가 형성되었던 책이다. 오랫동안 기억에 남을 것이다.

  책 내용중 가장 마음에 들었던 것은 컨설팅 회사에서의 경험담 이었다.

개념서나 이론책에선

"좋은게 있으니 이런데 써봐라"가 전부였다면, 여기서는

"좋은 것이 있는데 현지 개발자들이 이렇게 사용하고 있다.

이것을 적용하지 않는 우리 기업은 경쟁력이 떨어질 수 밖에 없다.

하나씩 따져 보자면 다음과 같다.

이것은 실제 우리 소프트웨어 기업의 문제점이다." 이렇게 되어있다.

이책을 받자마자 미친듯한 속도로 읽어내려갔다. 첫 느낌은 한국의 소프트웨어 회사와 업계의 발전을 위해서 열변을 토하는 느낌이다. 한국의 잘못된 개발방식, 개발환경, 그리고 기업문화 그것에 대해서 전반적으로 꼬집고 있다. 그래서 책장을 닫았을 때는 너무나 속이 시원했다. 

먼저 이책의 저자는 미국의 GE, Sun등에서 16년간 실무경험을 한 후에 소프트웨어 회사를 설립/운영하고, 이후에 소프트웨어 회사에 관한 컨설팅과 안철수연구소의 CTO를 지냈다. 정말 실무경험이 없이 소프트웨어공학만 한 사람이 말하는 그런 겉핥기가 아니라 경험과 현장에서 우러나오는 잔소리를 해대고 있는데 거기에 반박할 만한 것은 찾아볼 수가 없다. 지금도 안드로이드를 직접개발 한다는 점에서 놀라움을 금치 못한다.

프로세스를 강조하면서 미국은 70점에서 시작하고 한국은 20점에서 개발을 시작한다고 한다. 그것이 한국에서는 핵심 개발자가 퇴사하면 프로젝트가 망하는 비결이라고 한다. 개발자가 들어오면은 70점의 토대위에 프로세스대로 개발을 하면, 퇴사를 하더라도 그 모든 기록들이 남아 있어서 업무에 전혀 무리가 없고, 이후에도 관리가 쉽다고 지적한다. 반면, 한국의 20점짜리 개발사들은 20점에서 출발해서 잘해야 70점을 올라가고 못하면 30~40점에 머문다. 이것이 프로세스의 차이이다.

또한 여느 소프트웨어 공학 책과 마찬가지로 소스관리 시스템과, 이슈 관리(추적)시스템을 갖추라고 강력히 주장 한다. 그리고 스펙 설계 문서의 중요성을 강조 또 강조하고 있다. 시간이 없어서 문서를 쓰지 못한다는 것에 강력한 비판을 한다. 그리고 공유를 싫어하는 문화를 비판하고 있다. 소프트웨어는 기본적으로 공유가 생명인 정신적인 업무 분야라서 공유하지 않으면 망한다.

그리고 CTO의 역랑과 최근의 스마트폰의 열풍에 힘입어서 멀티플랫폼, 그리고 멀티랭귀지 프로젝트의 중요성을 열변한다. 스마트폰은 작지만 글로벌 소프트웨어의 모든 요소가 들어가 있다. 대부분의 한국의 소프트웨어들이 멀티랭귀지로 전환하는데 있어서 많은 어려움을 겪어 왔다. 그래서 소프트웨어 공학을 적용하는데 더없이 중요한 사업분야이다. CTO는 발전하는 소프트웨어 회사에서 중심을 잡아주는데 역할이 있다. 현재 한국에서는 백발이 성성한 프로그래머는 없고, 관리자로 가는 커리어 패스만 존재하는데 엔지니어로서의 패스도 만들어야 한다고 말하고 있다.

이렇듯 이 책은 기대했던 것 이상의 한국 소프트웨어 산업계의 모든 문제점과 해결방향을 제시하고 있다. 한국의 소프트웨어 회사 CEO와 CTO들이 읽어보았으면 좋겠다. 결국 글로벌 소프트웨어를 꿈을 꾸려면 먼저 글로벌 소프트웨어 회사가 되어야 한다는 것을 말해주고 있다.

제목이 꽤 도발적인가요?

그러나 할 수 없다. 이것이 나의 생각이다. 어째서 이런 생각을 하느냐고? 나만 이런 생각을 하는가? 아마도 대부분의 IT쪽 특히 개발자들 간에는 이런 생각을 하는 이가 많을 것이다. 그럼 왜 그런 생각을 하는가? 그것은 내 자신이 소위 IT노동자이기 떄문이다. 필자는 개발자가 아닌 기획, PM이다. 그래서 IT쪽 일을 하지만 약간은 뒤로 물러나 앉아 IT의 문제를 바라보기도 하고 내 스스로가 그 안에서 허우적 거리기도 한다.

스스로 만든 수렁

저자가 책에서 언급했듯이 IT가 3D 업종이 된 것에는 IT업계와 소위 IT인력들 스스로 책임져야 할 부분이 많다. 필자의 생각으로 60-70%가 IT업계 내부에서 초래한 문제이고 스스로를 3D 업동의 노동자라 칭하는 것도 IT인력들 스스로이다. 내부 사정을 잘 모르는 분야에서 3D업종으로 까지 분류하지는 않는다.

이 분야에서 개발자등의 상태가 가장 힘들다. 이들을 묘사할 때 가장 많이 나오는 단어라면 '야근', 철야' 일 것이다. 올해 봄에 인터넷의 일부 매체에서만 떠들썩 했다 TV에도 잠깐 언급되었던 IT 개발자들의 근무 환경에 대해 소개되었다. 초과 근무수당을 안주고 초과 근무을 시키는 것이 관행이다. 초과 근무가 수당을 주지 않기 위해 초과근무를 인정하지 않는다... 이런 이야기 였다. 소개된 개발자는 페암에 합병증까지 앓고 있는데 병중에도 철야를 했다고 하는데 회사에는 인정하지 않고 있다. 이 사건은 현재 우리나라의 IT관련 종사자들의 상황을 단적으로 보여주는 일화이다.

개발자는 물론이고 기획자, 디자이너도 상황은 비슷하다. 다만 마지막 작업을 처리하는 개발자와 끝까지 프로젝트를 책임지는 PM과는 상황이 좀 다르다.

그런데 이런 문제들은 개발자들 스스로가 만들어 낸 상황이라는데 아이러니가 있다. 이런 악순환은 초창기에는 아주 작은 문제에서 발생했을 것이다. 작은 개발건을 하던 개발자에게 마케팅 부서에서 요청이 들어온다.

'상무님이 보고자 하시니 내일 오전까지 이 부분을 이렇게 고쳐주세요!'

작업 내용을 보니 5시간 정도면 수정이 가능하다. 다만 작업 중에 소스를 백업하고 문서를 수정하여야 하는데 지금 시간이 6시~ 외근 중에 팀장의 승인을 받고 문서 수정하고 나면 9시 전에는 코드 수정을 시작하기 어렵다. 고민 끝에 백업이나 문서 수정없이 코드에 손을 대어서 수정을 완료했다.

12시 30분 쯤 퇴근하고 다음 날 좀 늦게 10시에 출근했다. 그런데 오전 9시에 앞의 그 상무가 수정을 변경하여 다른 요구 사항을 전달하고 그 것을 받은 팀장이 소스관리 툴에서 해당 페이지를 받아서 수정한 것이다. 팀장은 어제 다른 지시가 있다는 것은 누구에게도 듣지 못하고 아침에 떨어진 부분만 수정한 것이다. 아뿔사 어제 작업 후 소스관리 작업을 안하고 간 것이다.

이렇게 누수가 시작된 것이다. 처음에 1-2건을 놓치고 났을 때는 관련자들이 협의하여 소스를 머지한다고 해도 그것이 누적이 되면 어느 순간 관리는 물건너 가고 그 때 부터는 관리가 너무 힘들어지고 요청은 급해지고 악순환이 일어난다.  현재 중소규모의 IT프로젝트가 소스관리는 물론 리스크 관리가 잘 안되고 있다. 그들은 그 이유를 항상 요청된 시간이 늘 부족하다고 한다. 그 말은 틀린말은 아니지만 그렇다고 해도 문서관리, 소스관리 없이 작업해서 일정을 맞추는 경우도 거의 없다. 특히나 규모가 더 작은 웹쪽 작업는 더 말 할 것도 없다.

근본적인 문제들

일련의 문제들은 이미 다 잘 알려져 있다. 우리나라는 인구대비 IT와 직 간접으로 연관된 인력이 많다. 그러다보니 거의 모든 기업에 규모나 빈도에 상관없이 IT 프로젝트에 연관이 되어 일생 동안 몇 번의 IT 프로젝트를 직 간접으로 경험할 수 있고 IT인력은 아니지만 이미 여러 IT 프로젝트를 경험한 사람도 꽤 된다.

즉 여러 분야의 사람이 이미 그 문제를 경험했다는 것인데 더 문제는 그 문제점을 알지만 매번 프로젝트에서 규모에 상관없이 같은 문제(일정, 비용, 품질) 발생한다는 것이다.

이렇다면 문제는 구조적인 문제라도 판단을 할 수 있다.

어떤 구조의 문제인가? 책에서 저자가 다각도로 이 문제를 이야기 하고 있다.

우리나라에서 IT에 대한 정책적인 오류는 아이폰이 우리에게 알려준 교훈, 수평적 구조와 수직적 구조의 문제, 바로 그것이다.

우리나라에서 프로젝트를 한다는 것은 야근과 철야를 생각케 한다. 새 프로젝트에 들어갔다고 하면 친구들은 한 동안 이 친구를 못 보겠구나 하고 가족들은 얼굴보기 힘들겠구나 생각한다. 아이들은 아빠을 잠시 잊어버려야 한다. 반대로 누가 보자고 하면 프로젝트 끝나고 보자고 한다.

프로젝트가 무엇이관대 시작하면 개인시간을 다 뺴앗고 끝나면 인간으로 돌려 놓은 것인가?

프로젝트가 이럴진대 누가 프로젝트를 하고 싶을까? 회사를 나오기 힘들고 전업하기 힘들기 때문에 억지로 하는 거지 즐겁게 하는 일일 수가 없다. 누가 가족과 얼굴보기도 힘들게 일하면서 즐겁게 일하겠는가? 누가 밤샘하면 일하는 것을 좋아하는 가?

우리나라 기업은 그들이 의뢰하는 곳이던 의뢰를 받아 개발을 하는 회사던 판에 박은 듯 착각에 빠져있다. 두 가지 정도로 그 심각한 오해를 정리하자면

가. 소프트웨어는 누구나 만들 수 있다.

나. 시간이 없으니 일단 시작하고 보자

이렇다.

이 문제들을 각각 살펴 보면

첫 번째, 소프트웨어는 누구나 할 수 있다? 실제로 누구나 만들 수는 없다. 개발자들이 만드는 것이다. ㅋㅋㅋ 그런데 개발자면 다 만들 수 있자하면 그렇지 않다. 대부분의 개발자는 선임 개발자의 사전 작업과 기획자의 가이드가 없다면 작업을 시작할 수도 없다. 그런데 일반적은 시각은 개발자만 다 만들수 있다라는 생각이 퍼죠 있다. 개발자들과 부비는 PM인 필자가 볼 때 개발자들은 작게는 5개에서 크게는 몇 십단계와 직능별 분류가 가능하다. 각 단계와 직능별로 할 수 있는 개발과 할 수 없는 개발이 있다. 따라서 실제 프로젝트에서는 개발자 구성이 완벽하지 않으면 프로젝트가 망하게 된다.

개발에 대해 살짝 아는 이들이 안면 있는 개발자 몇명에서 부탁해서 책상에 앉혀 놓는다고 사업이 완수 되는 것이 아니라는 이야기이다.  그런데 실제 사이트에 가보면 그걸 왜 개발 못하냐?, 왜 그렇게 오래 걸리냐? 라는 말을 하는 의뢰인들이 있다. 오직 답답하면 그런 말을 할까 만은(그건 충분히 이해하고 있다.) 하지만 그런 태도로는 원만한 프로젝트를 수행하지 못한다. 그런 의식으로는 프로젝트 기간 중에 여러 상황에서 걸림돌만 만든다.

두 번째, 이 건 개발자나 개발사에서 범하기 쉬운 오류인데 클라이언트의 요구가 촉박하니 문서나 준비작업 없이 바로 코딩을 하자. 이런 식을 발상은 스스로를 파탄의 길로 밀어 넣은 것이다. 시간 만 많으면 문서작업등 절차대로 하겠다 하는데 이미 문서 작업을 회피하는 습관이 들었다면 시간이 많다고 제대로 할까? 절대 그렇지 않다. 클라이언트의 요구사항 변경과 촉박한 시간은 늘 있는 일이다. 그런 리스크가 감지된다면 프로젝트를 수주하지 않아야 하는 것이지 시간이 촉박하다고 요구사항이 변할 것이니 문서작업 무시하겠다 하는 것이 직무유기이다. 문서 작업을 하는 것이 전체 일정을 줄이는 역활을 한다. 초기에 일정은 이상적인 일정이다. 현실적으로 제안 당시의 일정은 당연스럽게 1.5, 2, 3배 늘어난다. 늘어나는 이유는 여러가지 이지만 이 중에 주먹구구식의 개발이 큰 역활을 한다. 클라이언트의 요구사항 변경도 체계적인 개발작업 중이라면 수정 시간을 줄일 수 있다.

개탄스러운 것은 우리나라의 IT 개발은 이 두 가지 장애를 숙명처럼 안고 있다는 것이다.

실무에 대한 이해가 없이 비용과 기간이 정해진 프로젝트, 의뢰인이나 개발사나 구체적인 업무 정의 없이 하는 Kick off, 모든 걸 개발사에 맞겨버리는 안이한 의뢰인, 일단 일하고 수주하고 보자는 영업팀, 환경탓만 하는 개발자, 엔지니어의 의견을 무시하는 독선적인 경영자... 이들이 살아 남아있고 변하지 않는 한 우리나라의 IT는 언제 내리막을 걸을지 모른다.

벽이 허물어진 우물

우리나라가 아직 우물 안에 있었다면 지금까지의 방식으로 살아 남을 수 있고 몇 년을 건디어 낼 수 있을지 모른다. 하지만 암울한 기운은 이미 우리 주변에 내려 앉기 시작했다. 작년에 우리나라에 아이폰이 보급되면서 피쳐폰 시절의 수직적인 생산구조에 익숙한 우리나라 모바일 분야 아니 사회전체가 놀랐던 것이 사실이다. 스마트폰에서 구동되는 APP들은  잘 아는 것 처럼 하드웨어나 모바일서비스 회사가 아닌 각 개발주체가 주도권을 가지고 있다. 이 사건으로 많은 관련 종사자들이 희망을 가지고 되었다. 수평적인 개발 구조가 되면 지금은 열악한 개발 환경도 개선이 될꺼란 희망을 가진 것이다.

하지만 상황은 희망적이지만은 않다.

이미 우물의 벽은 허물어지고 우물 밖의 강물이 범람하여 우물에 흘러들고 있다. 조만간 우물이 강물에 덮힐 수 있는 상황인데 우리는 이제 수직적 구조의 맛을 보았다.

우물 벽에 깔리지 않으려면

저자는 책의 마지막에 희망적으로 우리의 자세를 이야기 했지만

대세는 그렇지 않아 보인다. 다만 우물벽이 허물어지는 상황에서 각개 전투원이 살아 남기 위해서 저자가 책에서 제기한 문제점을 회피할 필요는 있다.

아니 살아 남으려면 반드시 그래야 한다.

필자는 이 책을 잡자 마자 하루도 안되어 읽어 버렸다.

이렇게 시원 할 수가 있을까 저자는 마치 나를 보고 있는 듯 나의 이야기를 하고 있다. 나의 생각을 읽은 듯 문제점을 나열하고 해결 책을 제시한다.

그 해결책이 현실적으로 해결하기 어려운 과제라고 해도 동감을 하는 것 만으로 필자에게는 위안이 되었다.

글로벌 소프트웨어를 꿈꾸다. 저자 : 김익환, 한빛미디어

아이폰, 안드로이드폰으로 촉발된 스마트폰의 영향으로, 소프트웨어 업계가 중대한 변혁기를 맞고 있다. 국내의 소프트웨어 업계도 이런 좋은 기회를 활용하기 위하여 그에 걸 맞는 경쟁력을 키우고 글로벌 소프트웨어로 탄생하기 위해서는 어떻게 해야 하는가? 가 화두이다.

소프트웨어가 성공하기 위한 조건.

첫째, 혁신을 해야 하는데, 죽을 만큼의 고통이 따르기 때문에 이 핑계,

       저 핑계 혁신을 기피하면서 오늘에 이르고 있다. 월스트리트가 선정한

       가장 영향력 있는 경영사상가인 '게리 헤멜'은 "생존하기 위해서는

       변해야 한다.

        변하는 회사는  70%가 살아 남는다"고 했다.

        변하는 대상은 먼저 경영자가 변해야 하고, 다시 개발자도 변하는

        것이다.

        물론 개발자의 역량이 따라야 하는 것은 물론이다.

        미국의 소프트웨어 회사들은 프로세스가 70%이지만

        우리나라는 20%이하다. 개발자가 집중해서 일할 수 있는 분위기는

        우리나라에는 아직 요원한 이야기라는 것이다.

        소프트웨어가 성공하기 위해서는 기반시스템, 조직, 프로세스, 기술,

        문화등이 잘 정립되어야 한다.

둘째, 이슈관리시스템을 보면 회사를 안다. 회사의 역량을 파악하기 위한

       시스템이지만, 전제조건은 누가 앞에서 필터링을 하면 안된다는 것이다.

       쓰레기 정보라도 다 귀중하며, 그런 정보조차 허용되는 전략시스템이어

       야 노하우를 얻을 수 있다. 이슈관리시스템이 전사적인 것이라면 개발팀

       의 상황을 볼 수 있는 것은 소스관리시스템이다.

       문서를 잘 관리해야한다.

       20세기 시대처럼 1인의 영웅개발자에 의존하면 이미 퇴화해버리고,

       시스템이 엉망이되어버린다. 또한 SRS를 수십년에 걸쳐서라도

       작성해야 한다. 왜냐하면 SRS는 예술적인 문서와 같기 때문에 영혼이

       깃들어야 하기 때문이다.

       "티베트 속담에 아무리 먼 길을 왔어도 잘못 온 길이라면 돌아가야 한다"

        라는 말이 있다. 나중에 고치려면 10배, 100배의 비용이 들기

        때문이다.

       가장 효과적인 컨설팅은 원인치료를 하는 것이다.

       그러나 증상과 원인이

       연결되어 있다는 통찰력을 가지는 것이 중요하다.

셋째, CTO의 역할은 아무나 대신하지 못한다. CEO는 회사의 비젼과 돈을

       챙기지만 CTO는 기술에 관한 모든 것을 책임진다. 나이 때문이

       아니라 실력으로 최고인 사람이 되어야 한다.

       어떤 기술적인 질문이 나와도 100%응답할수 있는 능력이 있어야 한다.

       "과거를 자랑하지 말라. 자랑할 과거 밖에 없을 때 처량해진다"는

       셰익스피어의 말처럼, 과거의 추억은 아름답지만 자랑

       거리가 아니다. 당신이 관리자라면, 개발자만큼의 기술을 쌓으려

       하지 말고,

       개발자가 Garbage를 가져오지 않도록 조직을 관리하는 것이 당신의

       몫이다

       모든 소프트웨어회사는 스펙을 작성해야 하고, 변화무쌍한 고객과

       스펙을조율하며, 어려운 프로젝트를 수행해야 하는데. 잘 정비된 조직, 

       적절한 프로세스, 유연한 문서작성법, 개발을 도와주는 기반 시스템,

       이런 것들을 수용하는 문화등이 정립되는 회사가 되도록, 경영진이

       책임을 지어야 한다. 영화 매트릭스에서 나오는 이야기 하나가 있다.

        "지구의 모든 생명체중에서

       환경을 파괴하면서 살아가는 존재는 인간과 바이러스 뿐이다.

       그래서 기계가 인간을 콘트롤 해야 한다."

넷째. 신입사원은 문서 50%, 프로세스 45%, 선배 5%로부터 배운다.

       이것은 실리콘 밸리의 원칙이다.

       그러나 한국에서는 사수-조수 시스템인 가내수공업 시대의 시스템을

       갖고 있다. 경영자와 관리자는 당장, 문서화와 프로세스

       시스템을 구축해야 한다. 소프트웨어 공학의 목적은 "최소한의 비용으로

       최소의 시간에 좋은 품질의 소프트웨어를 만드는 것이다.

        "소프트웨어 공학은 가르칠 수는 없지만 배울 수는 있다고 한다.

        " 중요한 일과 급한일을 잘 구별하면서 일을 해야 한다.

       또한 좋은 개발 환경을 접하고, 좋은 스승

       을 만나고, 자기 자신이 깨달을 수 있을 때 "좋은 개발자"가 될 수 있다.

       스펙과 설계, 코딩에 적절한 분배를 할 때 최대의 효과가 발생한다.

       프로세스는 미래 성장을 결정하는 핵심요소이다.

다섯째, 소프트웨어 개발은 기술이 아니라 예술이다.

          벽돌공 이야기를 한번 들어본다. 3명의 벽돌공에게 "당신은 지금 무슨

          일을 하고 있습니까?"

          첫 번째 벽돌공이 "보시다시피 벽돌을 쌓고 있어요"라고 말했다.

          두 번째 벽돌공이 "시간당 9달러짜리 일을 하고 있소"라고 말했다.

          세 번째 벽돌공은 "세계 최고의 성당을 짓고 있소."

          코딩이 바로 벽돌 쌓기와 같다.

          사람들은 고기를 주면 좋아하지만 고기잡는 법을 가르켜 주면

          싫어한다.

          휼룡한 멘토가 있어도 싫어한다.

          된장찌개의 맛을 어떻게 말로 설명해서 맛있다는 것을 확신시켜

          줄 수  있는가? 소프트웨어는 숫자가 아니고 깨달음이기 때문에

          깨달음으로 얻는 혜택을 숫자로 생각하는 것은 버려야 한다.

많은 한국회사가 외국에 진출하는 것을 꿈꾼다. 또한 많은 소프트웨어 엔지니어들은 성공하는 소프트웨어 회사에서 일하고 싶어 한다. 그러나 경영진과 개발자들이 서로 조화롭게 살기는 아직 시기상조인가? 자기의 역량을 깨우고 서로를 이해해야 되는 시점이다.

전공은 다르고, 용어는 생소하지만 의료생명공학도(Human science engineer)의 길을 가고 있는 한 사람으로서 공감대가 많이 가는 책이었다.

책의 저자분이 미국의 실리콘 벨리에 오래 있어서인지 책의 내용들이 그쪽의 소프트웨어 개발 환경과 문화를 한국에 맞게 소개하고 설명하는 듯한 내용이었습니다.

여러 회사들의 예를 들면서 지금 현재의 우리나라 소프트웨어 업계의 문제와 앞으로 나아갈 방향에 대해서 제시를 하고 어떻게 해야 할지를 말해주는 책이었습니다.

거의 대부분의 내용이 개발자들 보다는 소프트웨어 회사를 경영하는 사람들과 기획자들이 봐야할 내용이었던 걸로 기억이 나지만 개발자들도 이런부분을 알고 개발에 참고해야 한다고 생각하는 부분도 상당수 있어서

기획자, 개발자 양쪽 모두 읽어 봐야 할 책이라고 생각됩니다.

이책의
제목을 보면
글로벌 소프트웨어를 만드는 방법을 제시해주는
책 이라고 오해를 할 수도 있을거 같다.
마치 무슨 방법론 같은...

이 책은
그러한 방법론적인 내용이 아니라

국내와 국제 의 IT 문화의 차이와
국내의 잘못 인식되어 있는 사상들.
국제적으로 경쟁력있는 회사가 되기 위해서
회사의 CEO 나 개발자, 기업문화와 같은
여러가지 요소들의 나아가야할 방향등을
제시하고 있다고 생각된다.

아마 그러한 부분은
현실적으로 개발자들이 가장 많이 느끼는 부분이
아닌가 싶다.

이 책을
읽으면서 많은 부분에 공감을 하면서도
여러가지 면에서는 씁쓸해하기도 했다.

내가 아는 개발자분이
항상 이런말을 했었다.

우리나라 IT 는 우리가 이렇게 해놓은거다.

똑같은 말을 이 책에서 다시 보게 될줄은...

책의 내용은

참 재밌고
읽어볼만한 책인거 같다.

 
특히나 CEO 같은 분들이 좀 읽었으면 좋겠는데..