http://www.yes24.com/24/goods/4224880
3월경에 '글로벌 소프트웨어를 꿈꾸다'를 읽고 크게 감명받았습니다.
개발자를 직업 삼은지 8년차입니다. 나름 최선을 다하고 그럼으로 인해 자부심도 있었는데 이 책을 읽으면서 느끼는 것은 아직 부족한게 많구나라는 걸 알게 되었습니다. 내가 목표로 해야될 게 무엇인지를 바로잡게 되었습니다. 한국의 소프트웨어 개발자라면 반드시 읽어보야할 도서 같습니다.
읽다가 너무 맘에 들어서 김익환 저자님의 다른 책을 구입해버렸습니다 ㅋ
....
회사에서 나오는 복지 포인트를 가지고 리디북스의 이북을 구매하였습니다. 아이패드에서 보면서 몇가지 의미심장한 글귀들을 스크랩해 보았습니다. 아래는 그러한 내용을 간추린 것입니다. '☞ ' 는 제 생각을 덧 붙였습니다.
소프트웨어 분야에는 많은 요소 기술이 있다. J2EE, 닷넷, 웹 서비스 등등. 이러한 요소 기술 전문가라는 뜻으로 아키텍트라는 명칭을 붙이기도 한다. 요소 기술 아키텍트는 상대적으로 양성하기가 쉽다. 경험보다는 지식적인 부분이 더 많기 때문에 교육으로도 쉽게 양성할 수 있다. 반면 이러한 요소 기술 아키텍트보다는 전체 개발 프로세스를 이해하고 어떠한 제품도 처음부터 끝까지 개발할 수 있는 체계와 정책을 수립할 수 있는 경험과 지식을 균형 있게 소유한 넓은 의미의 '지휘자 아키텍트'가 바로 최고의 개발자며 또 이들이 절실하게 필요한 것이 한국 소프트웨어 업계의 현실이다. |
☞ 제가 가야할 방향을 알려주셨습니다.
기술이야 말로 개발자의 고유 영역에 속한다. 아무리 지나쳐도 직접적인 해가 되지는 않는다. 하지만 기술은 시대에 따라 변한다. 수많은 기술이 생겨났다 없어진다. ... 기술은 단기적으로 필요한 만큼만 배우면서 사는 것이 효율적이다. 배고플 때 슈퍼에 가지 말라는 말이 있다. 슈퍼에 가서 먹거리를 왕창 사서 오면 결국은 안 먹고 썩어서 버리게 되는 데서 비롯된 말이다. 기술에 관한 한 당장 먹을 만큼만 사오는 것이 효율적이다. |
☞ 전 가끔 기술에 집착할 때가 있습니다. 좀더 유연해 질 필요가 있는 것 같습니다.
실제로 이슈를 정확하게 등록한다는 것은 매우 어렵고 초기에는 그럴 필요가 없다. 이슈를 정확히 판단해야 하는 문제는 이슈관리시스템과는 근본적으로 관계가 없는 문제다. 누군가가 해야 하는 문제인데 이슈관리 시스템을 대화의 도구로 사용하는 것이 효율적인 것이다. 이슈관리시스템은 각자 아는 정보만큼만 입력하고, 진행하면서 저절로 데이터가 추가되고 정리되고, 대화를 통해 모든 정보가 투명하게 기록에 남는 것이 핵심이다. |
☞ 이슈관리시스템이 꼭 필요해 보이지만 지금 회사에서는 보안이라는 이유로 메일링 서비스와 같은걸 제한하여 충분히 활용하지 못하도록 하고 있습니다. 안타깝습니다. 제발 제대로 된 소프트웨어 전문가가 임원이 되고 사장님이 되길 바랍니다.
"이슈 등록으로 이슈에 대한 논의를 시작한다" 는 것을 이해하는 것이 중요하다. |
미리 문서를 작성하고 설계를 하는 것인데 실제 전체 개발 기간이 줄어든다. 이것을 진정 믿어야 한다. 이 믿음이 없으면 문서를 작성하라는 말은 공허한 외침밖에는 안 된다. |
☞ 시간에 쫓기다 보면 항상 소홀하게 됩니다. 제 능력이 부족한 것이거나 게을러서겠지요.
코딩은 아르바이트생도 할 수 있다고 필자가 말하면 개발자를 무시한다고 반론을 제기하는 개발자가 많다. 코딩의 정의가 다르기 때문이다. 그들의 주장은 코딩이 어렵다는 것이다. 그런데 이렇게 말하는 개발자가 있다면 그는 SRS 와 설계문서 없이 개발하고 있는 것이다. 필자 경험상 거의 100%다. 코딩한다는 이름 아래 동시에 분석도 하고 설계도 하고 있는 것이다. 그것을 코딩이라고 한다면 그의 주장대로 그건 세상에서 가장 어려운 일일 것이다. IEEE가 SRS를 작성하는 것이 개발에서 가장 어려운 작업이라고 했으니 SRS도 없이 코딩하는 것은 얼마나 어렵겠는가? 어렵게 느껴지는 건 그것이 코딩이 아니기 때문이다. 코딩이라는 이름으로 포장된 분석, 설계가 어려운 것이다. |
| 행복해지는 두 가지 방법이 있다. 욕망을 버리거나 재산을 욕망보다 더 많이 갖는 것. |
| 티베트 속담에 "아무리 멀리 왔어도 잘못 온 길이라면 돌아가야 한다" |
☞ 리팩토링할 때마다 고객 또는 PM 에게 인용해야겠습니다.
간혹 연구소장, 개발실장, R&D 부사장 등의 직함이 CTO와 혼란을 일으킨다. 이들과 CTO를 구별 짓는 가장 중요한 기준은 CTO는 인사관리를 안 한다는 것이다. 연구소장처럼 '장'자가 붙는 사람은 부서원을 관리해야 한다. '장'의 권위를 즐기는 대신 사람관리를 위한 시간이 엄청나게 들어간다. 역시 CTO가 되기에는 시간상으로 모자란다. |
구글의 CEO인 에릭 슈미트도 필자가 썬마이크로시스템즈에 근무하고 있었을 때 CTO를 했었다. 그는 Unix의 유명한 구문분석기인 lex를 개발한 대단한 개발자다. 에릭 슈미트처럼 CTO가 비즈니스 감각을 배우고 CEO로 전향한 경우도 많다. 하지만 그 순간부터 CTO로부터는 멀어져 간다. 빌 게이츠나 에릭 슈미트처럼 소프트웨어를 이해하는 CEO 아래서 일을 한다는 것은 개발자에겐 행운이다. |
☞ http://weekly.donga.com/docs/magazine/weekly/2011/04/11/201104110500021/201104110500021_1.html
"과거를 자랑하지 마라. 자랑할 과거밖에 소유한 것이 없을 때 처량해 진다" 셰익스피어 |
CEO가 요청을 하지 않더라도 최종테스트에서 결함이 발견되어 고칠 것인지 말 것인지를 결정하는 프로세스도 같은 맥락이다. 통상적으로 그런 마지막 회의를 "Go-Live 회의"라고 하는데 결함이 있는 상태로 출시할 것인지 말 것인지를 결정하는 회의다. |
돈은 안 벌고 낚시만 하고 있는 사람을 옆에서 지켜보던 구경꾼이 불쌍하게 생각한 나머지 이렇게 물었다. "그렇게 낚시만 하지 말고 돈도 좀 벌어야 하지 않겠습니까?" 낚시꾼이 되묻는다. "왜 돈을 벌어야 하지요?" "나중에 하고 싶은 일을 하려면 돈이 있어야 하지 않을까요?" 구경꾼이 또 물었다. "나는 지금 바로 내가 하고 싶은 일을 하고 있습니다." 낚시꾼의 대답이다. |
| 세계 최고 수준의 전산학과가 있는 U.C. Berkeley 의 소프트웨어 공학의 교재에도 "소프트웨어 공학은 가르칠 수 없다. 그러나 배울 수는 있다"고 적혀 있다. |
분할발주는 분석이 끝난 후에 설계/구현 단계를 다른 사람이 하는 것이 통상적이다. 거기에는 심오한 이유가 있다. 한국에서는 분석/설계/구현을 통으로 발주한다. 발주를 하기 전에 RFP(제안요청서)와 Proposal(제안서)라는 단계를 거쳐서 나름대로 비용과 일정을 산정하고 계약한다. 그런데 계약을 하는 시점에서 일정과 비용을 산정한다는 것은 불가능하다. 그러니 나중에 얼마나 문제가 많을지 짐작이 간다. 사실은 이 문제가 국내 소프트웨어의 중소 하청업체가 고생하는 이유다. |
현재 개발하는 관행을 보면 분석단계에는 업무를 잘 아는 사람이 투입된다. 바로 업무전문가다. 이 단계에서는 전문적인 소프트웨어를 분석가라고 해도 그 사람이 업무를 모른다면 끼지도 못한다. 여기부터가 잘못됬다. 업무를 알아야 분석이 가능하다는 믿음이 오해라는 것을 모르기 때문이다. |
☞ 우리 회사에서도 고객들도 모두 착각하고 있는 것 같군요.
만약 시간이 없어서 스펙을 적지 않고 코딩하는 개발자라면 지금 당장 시간을 투자하여 악순환의 고리를 끊길 바란다. 지금 못하면 시간이 가면 갈수록 점점 더 어려워진다. |
☞ 노력해야겠습니다.
첫 번째 개발자가 "지금 코딩하고 있어요." |
☞ 저는 세 번째 마인드로 항상 일하려고 하지만 이런 마인드로 일하는 사람이 많지 않습니다... 더군다나 그걸 행동에 옮기는 사람은 더더욱 드물다고 봐야죠.
자신이 시도하기 전에 모든 것을 이해해야 한다고 하는 태도 역시 폐쇄적인 태도다. |
☞ 비슷하게 해봤다고 모든 것을 아는 것처럼 행동 하는 것 또한 경계해야겠습니다.
개발자 평가 1) 스펙은 적는가? 2) 동료검토는 자주 하는가? 3) 자기 관련 문서를 제대로 업데이트하는가? 4) 소스코드를 체크인할 때 주석을 제대로 남기는가? 5) 모든 버그나 기능 추가사항은 이슈관리시스템에 등록하고 일하는가? |
☞ 언젠가 이 KPI 를 고려해 보아야겠습니다.
인터넷 세상은 표면적인 전문가를 양산하여 역작용을 일으키기도 한다. 자기가 그 지식을 사용하여 혜택을 얻는 것은 어렵지만 남을 비판하는 데는 아주 쉽게 사용할 수 있기 때문이다. 결국 할 줄도 모르는 헛똑똑이가 아는 척하는 일이 과거에 비해 훨씬 더 많아졌기 때문에 지식과 경험의 차이가 점점 더 커지는 세상이 되었다. |
☞ 정확한 지적이십니다. 요즘엔 검색이 훌륭해서 샘플 코드를 쉽게 구할 수 있어서 원하는 기능을 빠르게 구현할 수는 있습니다. 가끔 이게 마치 자기 능력인 것처럼 우쭐해 하지만, 전체적인 소프트웨어를 보지 못한다면 그 정도 할 수 있는 사람은 얼마든지 구할 수 있습니다.
| 필자가 지금도 개발을 한다고 얘기하면 듣는 사람이 다들 깜짝 놀란다. 필자는 이들이 필자의 말에 놀라는 것이 더 놀랍다. 노숙한 피아니스트가 현재도 피아노를 친다는 말을 듣고 깜짝 놀라는 사람은 없을 것이다. 그들은 죽을 때 까지 연주활동을 하면서 피아노를 친다. 그런데 소프트웨어 전문가는 나이가 들어서도 개발을 한다는 것이 왜 이상하게 들릴까? |
☞ 전 이 분야를 뜰 때까지 개발을 손에 놓지 않겠다고 처음부터 맘 먹었더랬습니다.
| 여러분이 이 책을 읽고 난 후에 문서를 작성하는 것이 개발에 꼭 필요하다는 것만이라도 진정으로 믿게 되었다면 필자는 이 책을 집필한 것에 큰 보람을 느낄 것이다. |
☞ 정말 감명깊게 잘 읽었습니다. 감사합니다.
Rss Feed