반응형
나의 평점 : 5.0 / 5.0
요즘은 책을 읽다가 감동의 눈물을 흘리는 경우가 유독 많아졌다.
무언인가가 절실하기 때문인가?
이 책은 글로벌 소프트웨어 회사를 만들어내려면 어떤 조건들이 필요한지를 설명하고 있다. 미국 회사들은 기본이 70점이고 우리나라 회사들은 20점이라는 말이 나오는데 그만큼 우리의 현실은 척박하기 그지없는 상태다.
개발 프로세스, 기업문화 등의 문제도 지적하지만 가장 큰 문제는 경영자와 개발자 자신에게 있다는 사실이 나를 더욱 서글프게 만들었다. 하지만 우리나라 소프트웨어 회사의 모든 경영자와 개발자가 이 책에 나오는 내용을 숙지하고 문제를 해결하려는 의지를 가진다면 우리의 미래는 밝을 것이라는 희망을 조금이나마 가져본다.
대표적으로 나에게 도움을 줬던 부분은 CTO의 정의에 대한 부분이었다. 인사관리를 하는 연구소장과 달리 CTO는 인사관리는 하지 않아야 하고 회사의 모든 기술을 섭렵하고 있어야 한다고 한다. 결과적으로 개발자, 엔지니어가 성장해야 할 경로는 회사 내부의 모든 프로젝트를 아우르는 것이 아니라 회사 내부의 모든 기술을 아우르는 것이었다.
듣고 보니 눈이 번쩍 뜨이는 말이었지만 동시에 무지하게 무시무시한 말이기도 했다. 지금 자기 분야에서 개발하는 것들만으로도 허덕이고 있는 판에 전사적인 기술을 다 꿰차고 있어야 한다니... 엄청난 수퍼맨이 아니면 할 수 없는 것이 아닌가... CTO가 인사관리를 하면 기술이외의 업무에 시간을 빼앗기게 되고 신기술을 따라갈 수 없는 것은 당연해 진다는 것이다.
기본적인 개발 프로세스에 대한 제시도 나오고 소프트웨어 설계란 어떤 것인지도 나오고 우리가 기본적으로 알고 있어야 하지만 여전히 알고 있지 못하는 부분 혹은 실행하고 있지 못하는 부분이 잘 정리되어 있다. 마지막 부분에 이를 함축적으로 평가할 수 있는 다음과 같은 항목들이 나온다.
1) 스펙은 적는가?
2) 동료검토는 자주 하는가?
3) 자기 관련 문서를 제대로 업데이트하는가?
4) 소스코드를 체크인할 때 주석을 제대로 남기는가?
5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가?
핵심중의 핵심이다. 책의 모든 내용이 이 질문들에 함축되어 있다고 생각한다. 하지만 문제는 이와 같은 프로세스를 문자 그대로 알아 들었다고 해서 그대로 실천할 수 있는 것이 아니라는 점이다. 저자는 말한다. 책으로 이런 것을 배우려 하지 말고 경험있는 자들로부터 제대로 배우고 오랜 기간을 반복해야 한다고...
가장 적나라하게 이 점을 지적한 부분을 인용하며 개발자 스스로에 대한 반성을 하며 마무리하려 한다.
"동료검토를 꺼리는 가장 큰 이유 중의 하나가 시간이 없다는 점도 있지만 자기 자신한테도 자신이 없기 때문이다. 자신이 있으면 내보이고 싶어 하는 것이 인간의 본능이다. 자랑스러운 것을 숨기는 사람이 있다면 성인의 반열에 오를 사람이다. 그런 사람이라면 소프트웨어보다는 정신적 지도자가 되는 것이 사회에 훨씬 도움이 된다."
요즘은 책을 읽다가 감동의 눈물을 흘리는 경우가 유독 많아졌다.
무언인가가 절실하기 때문인가?
이 책은 글로벌 소프트웨어 회사를 만들어내려면 어떤 조건들이 필요한지를 설명하고 있다. 미국 회사들은 기본이 70점이고 우리나라 회사들은 20점이라는 말이 나오는데 그만큼 우리의 현실은 척박하기 그지없는 상태다.
개발 프로세스, 기업문화 등의 문제도 지적하지만 가장 큰 문제는 경영자와 개발자 자신에게 있다는 사실이 나를 더욱 서글프게 만들었다. 하지만 우리나라 소프트웨어 회사의 모든 경영자와 개발자가 이 책에 나오는 내용을 숙지하고 문제를 해결하려는 의지를 가진다면 우리의 미래는 밝을 것이라는 희망을 조금이나마 가져본다.
대표적으로 나에게 도움을 줬던 부분은 CTO의 정의에 대한 부분이었다. 인사관리를 하는 연구소장과 달리 CTO는 인사관리는 하지 않아야 하고 회사의 모든 기술을 섭렵하고 있어야 한다고 한다. 결과적으로 개발자, 엔지니어가 성장해야 할 경로는 회사 내부의 모든 프로젝트를 아우르는 것이 아니라 회사 내부의 모든 기술을 아우르는 것이었다.
듣고 보니 눈이 번쩍 뜨이는 말이었지만 동시에 무지하게 무시무시한 말이기도 했다. 지금 자기 분야에서 개발하는 것들만으로도 허덕이고 있는 판에 전사적인 기술을 다 꿰차고 있어야 한다니... 엄청난 수퍼맨이 아니면 할 수 없는 것이 아닌가... CTO가 인사관리를 하면 기술이외의 업무에 시간을 빼앗기게 되고 신기술을 따라갈 수 없는 것은 당연해 진다는 것이다.
기본적인 개발 프로세스에 대한 제시도 나오고 소프트웨어 설계란 어떤 것인지도 나오고 우리가 기본적으로 알고 있어야 하지만 여전히 알고 있지 못하는 부분 혹은 실행하고 있지 못하는 부분이 잘 정리되어 있다. 마지막 부분에 이를 함축적으로 평가할 수 있는 다음과 같은 항목들이 나온다.
1) 스펙은 적는가?
2) 동료검토는 자주 하는가?
3) 자기 관련 문서를 제대로 업데이트하는가?
4) 소스코드를 체크인할 때 주석을 제대로 남기는가?
5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가?
핵심중의 핵심이다. 책의 모든 내용이 이 질문들에 함축되어 있다고 생각한다. 하지만 문제는 이와 같은 프로세스를 문자 그대로 알아 들었다고 해서 그대로 실천할 수 있는 것이 아니라는 점이다. 저자는 말한다. 책으로 이런 것을 배우려 하지 말고 경험있는 자들로부터 제대로 배우고 오랜 기간을 반복해야 한다고...
가장 적나라하게 이 점을 지적한 부분을 인용하며 개발자 스스로에 대한 반성을 하며 마무리하려 한다.
"동료검토를 꺼리는 가장 큰 이유 중의 하나가 시간이 없다는 점도 있지만 자기 자신한테도 자신이 없기 때문이다. 자신이 있으면 내보이고 싶어 하는 것이 인간의 본능이다. 자랑스러운 것을 숨기는 사람이 있다면 성인의 반열에 오를 사람이다. 그런 사람이라면 소프트웨어보다는 정신적 지도자가 되는 것이 사회에 훨씬 도움이 된다."
반응형
