수퍼히어로 개발자에 대한 관점 from Iguacu
MS의 Dev2006에서 소만사 김대환 사장의 "람보" 이야기(ZDNET 기사 참고) 이후 논의되는 글에 나도 참여해 볼까 한다.
람보프로그래머
"람보프로그래머"라 한다면 혼자서 수백만 라인의 코드를 생성하고 관리 가능한 개발자를 지칭할 것이다. 만약 이런 식으로 개발을 하겠다라고 한다면 당장 말려야 할 것이다. 람보가 영화속에서만 존재하는 인물이듯 이런 프로그래머는 이세상에 없다. 마치 m60을 양손에 한자루씩 쥐고 쏠 수 없는 것과 마찬가지이다.(물리시간에 많이 풀어봤을지 모른다. 사람이 그렇게 쏘면 어떤 일이 벌어지는지;;;) 또한 람보는 지상전투에는 전문가일지 모르나 전투기를 조정할 수 없고 절단부상자의 수술을 할 수도 없다. 한명이 전쟁 전체를 혼자서 수행할 수 없는 것이다. 아놀드 주연의 <트루라이즈>란 영화에서 주인공이 심지어 해리어까지 몰아대는 다재다능함을 보여주지만 그 뒤에 수많은 서포터들이 있음을 알아야 할 것이다.
많은 사람들이 지적하듯이 프로그램을 작성하는 것은 이제 팀 단위가 되었으며 개개인의 자질도 중요하겠지만 그 바탕에서 나오는 팀의 역량이 가장 중요할 것이다. 아무리 개개인의 능력이 중요하겠지만 그것이 어떻게 조화되는 가가 성공의 중요한 포인트일 것이다. 억대 연봉의 프로그래머 100명 대려온다고 해서 프로그램이 성공적으로 제작된다라는 보장은 없다. 람보가 아무리 베트남에서 혁혁한 전공을 세워도 미국은 베트남전에서 참패를 하였다.
프로그래머 한명 vs. 팀과 시스템
소만사 사장의 람보 주장에 대하여, 개개인의 역량을 키워야 한다라는 점에서 맞는 소리가 아닌가라고 하겠지만 전통적인 프로그래머 혹사형 접근법이라는 것이 문제라고 보인다. 5년동안 파서 그 분야의 전문가가 되어라고 하는데 5년이면 플랫폼과 언어와 패러다임이 바뀌는 세상에서 이 무슨 망설인가 싶다. 문제 하나를 해결하기 위해 일주일동안 골몰하는 것도 위험한 발상이다. 프로젝트 전체를 일주일 딜레이(정확히는 여파로 더욱더) 시킬 일이 있는가. 새로운 지식을 습득하라면서 모든 프로그램을 "업무와 상관없더라도" 테스트 해보라고 한다. 그시산에 운동을 하는 편이 더 좋을텐데;;;
사실 이런 이야기는 현재의 프로그래머 인력 시장의 특성과 매우 연관성이 있다. 3~5년차의 억지로 단독임무가 가능한 값싼 람보만을 찾는 구인시장만이 국내에는 존재한다. 이전에 본인이 백수가 되었을때 찾아간 회사들의 면접에 가서는 팀과 시스템을 빌딩해 줄 수 있다고 하였지만 대부분의 업체들은 연봉을 높게 해 줄테니 혼자서 만들어 달라고 하는 식이 많았다. 누구 죽으라는 소린가... 잘하는 프로그래머 개개인에만 관심이 있고 당면한 프로젝트 하나에만 집중하기 때문이다. 반대로 앞으로 무엇이 되었든 잘 개발해 낼 수 있는 팀과 시스템의 개발은 아예 관점도 없다.
본인의 경우 구인시 이력서를 볼때 단독작전 경력은 중요치 않게 본다. 사이즈가 작기도 하고 능력의 객관적인 입증이 어려울 뿐더러 앞으로의 개발에 별로 도움이 되는 경험이 아니기 때문이다. 팀플레이 경력이 없다면 나의 눈에는 신입이 되는 셈이다. 팀플에 있어서도 자신이 무엇을 해내었다는 점 보다는 어떻게 코웍을 했는지를 중요하게 본다. 어떤 사람들은 개개인의 람보화가 중요하다고 볼 지 모르지만 나의 경우엔 팀플을 잘 할 수 있음을 중요하게 본다. 회사의 경우에도 자사에 훌륭한 작전중대의 셋업을 중요시 해야 한다고 본다.
프로그래머는 그럼 어떻게 해야 하는가.
순전히 개인적인 생각이라 정답이라고는 할 수 없겠지만 현 시점에서 내가 가진 생각은 이렇다. 팀에 적응하고 환경에 적응할 수 있는 Capacity를 확보하라고 하고 싶다. C++을 매우 깊게 파고는 "아름다운 코드"를 생성해 낼 필요는 없다. 팀프로젝트에서는 부분 부분 코드의 아름다움성이 전혀 도움이 되지 않는다. 대신 새로운 언어라도 한달정도의 학습기간을 통해 적당한 수준의 생산이 가능하면 코더로서는 충분하다. 대신 중요한 것은 팀을 어떻게 사용하는가일 것이다. 코더의 위치에서 보면 위에는 매니저가 있을 것이고 옆에는 동료코더와 테스터, 테크니컬 라이터, 영업들이 있을 것이다.(물론 회사 대부분이 이런경우는 드물긴 하다. --;) 자신의 단독 플레이가 아닌 팀을 통해 프로젝트를 진행하는 방법을 터득해야 할 것이다. 그리고 개발환경이란 것이 프로젝트에 맞추어 변화하게 마련이므로 그 변화에 쉽게 적응할 수 있는 준비를 하기를 권장한다. PHP의 특정 함수 하나를 일부러 외우는 노력은 의미없다라고 본다. 진정한 코더는 어드바이저(팀에서 기술적인 조언을 담당하는 사람)가 준 책이나 헬프파일을 받고 주어진 기능성을 수행하는 코드를 제한시간내에 작성하는 사람이다.(물론 매니저의 기간 예측능력이 필요하기도 하다.) 한번에 완벽할 필요도 없다. 옆에는 테스터가 존재하니깐.
자신이 주로 하는 언어나 작업의 전문적인 지식은 물론 상당히 중요하고 깊을수록 가치가 있다. 그보다 더 중요한 것은 그 작업을 팀을 통해 이루어 나갈 수 있도록 하는 능력이다. 정확히는 효율적으로. 혼자서 작성하면 매우 아름다운 코드를 만들수 있을지 모르겠지만 10년이 걸리는 것 보다는 덜 아름답더라도 1년만에 완수하는것이 더 좋다.
사장이 직접 코딩을 하면서 밑의 코더들을 구박하는 케이스를 들을때 마다.. 그 사장이란 사람이 훌륭한 말단 코더일지는 모르겠지만 그 회사가 좋은 팀을 가지고 있다라고 보지는 않으며 그 회사의 제품에 대해서도 썩 믿음직 스럽지 못하다.
그럼 회사는?
팀이다. 정확히는 팀과 시스템이다. 개발 프로세스 자체도 제멋대로인 회사도 많은 상황이 아닌가. 잘하는 프로그래머 한두명만 있으면 훌륭한 프로그램이 나올거라고 생각할지 모르겠으나 그정도 사이즈면 벤처가 첫 스테이지에나 쓸만한 규모일 것이다. 버그가 많아도 비젼의 가능성을 테스트해 주는 정도. 그런 상황에서 다음 스테이지로 넘어갔거나 어느정도 규모가 되는 사업체라면 팀이 필요해 진다. 그리고 그 팀이 유지되는 시스템이 필요하다.
구인시장에서 3~5년차 프로그래머를 왜그리 찾게 되는가. 그 회사들이 그런 사람을 키우는 시스템이 없다 보니 회사에도, 시장에도 그런 사람이 절대적으로 부족하다. 3~5년차의 제대로 된 프로그래머는 신입이 제대로 된 교육과 경험을 토대로 만들어 질껀데 그럴 가능성이 매우 낮다. 프로젝트의 성공은 기원하면서 사원의 능력 향상에 신경을 쓰는 회사가 얼마나 될까. 대략적인 교육시스템을 가진 회사는 있지만 개개인을 대상으로 관리해 주는 경우는 매우 드물다. 맞춤식 교육을 어린애들은 받고 있지만 사원들은 받지 못하는 것이다. 연말에 인사고과 신나게 하고는 연봉에만 적용될 뿐 교육시스템에 적용해 본적이 있는가?
이지중대(Easy Company)
<band of brothers>라는 영화를 보면 2차세계대전 당시 훌륭한 작전 수행을 했던 이지중대 이야기가 나온다. 구성원중에 뛰어난 능력을 보여준 사람이 있긴 하지만 람보는 아니다. 대신 그들은 중대를 통해 훌륭한 역할을 수행했고 반대로 중대는 그런 사람들을 위한 시스템을 가지고 있었다.
한사람의 스타프로그래머(람보)를 중요시 생각하는 임원이나 개발자라면 생각을 재고해 보기 바란다. 많은 프로젝트가 스타프로그래머와 프로젝트 성공과의 연관성이 크지 않음을 입증하고 있고 반대로 팀과 시스템이 기존의 문제들을 얼마나 보완해 나가느냐가 중요한 것이다. 개인도 코웍 캐패시티가 매우 중요하다. 자신이 하는것과 당하는 것 모두!
MS의 Dev2006에서 소만사 김대환 사장의 "람보" 이야기(ZDNET 기사 참고) 이후 논의되는 글에 나도 참여해 볼까 한다.
람보프로그래머
"람보프로그래머"라 한다면 혼자서 수백만 라인의 코드를 생성하고 관리 가능한 개발자를 지칭할 것이다. 만약 이런 식으로 개발을 하겠다라고 한다면 당장 말려야 할 것이다. 람보가 영화속에서만 존재하는 인물이듯 이런 프로그래머는 이세상에 없다. 마치 m60을 양손에 한자루씩 쥐고 쏠 수 없는 것과 마찬가지이다.(물리시간에 많이 풀어봤을지 모른다. 사람이 그렇게 쏘면 어떤 일이 벌어지는지;;;) 또한 람보는 지상전투에는 전문가일지 모르나 전투기를 조정할 수 없고 절단부상자의 수술을 할 수도 없다. 한명이 전쟁 전체를 혼자서 수행할 수 없는 것이다. 아놀드 주연의 <트루라이즈>란 영화에서 주인공이 심지어 해리어까지 몰아대는 다재다능함을 보여주지만 그 뒤에 수많은 서포터들이 있음을 알아야 할 것이다.
많은 사람들이 지적하듯이 프로그램을 작성하는 것은 이제 팀 단위가 되었으며 개개인의 자질도 중요하겠지만 그 바탕에서 나오는 팀의 역량이 가장 중요할 것이다. 아무리 개개인의 능력이 중요하겠지만 그것이 어떻게 조화되는 가가 성공의 중요한 포인트일 것이다. 억대 연봉의 프로그래머 100명 대려온다고 해서 프로그램이 성공적으로 제작된다라는 보장은 없다. 람보가 아무리 베트남에서 혁혁한 전공을 세워도 미국은 베트남전에서 참패를 하였다.
프로그래머 한명 vs. 팀과 시스템
소만사 사장의 람보 주장에 대하여, 개개인의 역량을 키워야 한다라는 점에서 맞는 소리가 아닌가라고 하겠지만 전통적인 프로그래머 혹사형 접근법이라는 것이 문제라고 보인다. 5년동안 파서 그 분야의 전문가가 되어라고 하는데 5년이면 플랫폼과 언어와 패러다임이 바뀌는 세상에서 이 무슨 망설인가 싶다. 문제 하나를 해결하기 위해 일주일동안 골몰하는 것도 위험한 발상이다. 프로젝트 전체를 일주일 딜레이(정확히는 여파로 더욱더) 시킬 일이 있는가. 새로운 지식을 습득하라면서 모든 프로그램을 "업무와 상관없더라도" 테스트 해보라고 한다. 그시산에 운동을 하는 편이 더 좋을텐데;;;
사실 이런 이야기는 현재의 프로그래머 인력 시장의 특성과 매우 연관성이 있다. 3~5년차의 억지로 단독임무가 가능한 값싼 람보만을 찾는 구인시장만이 국내에는 존재한다. 이전에 본인이 백수가 되었을때 찾아간 회사들의 면접에 가서는 팀과 시스템을 빌딩해 줄 수 있다고 하였지만 대부분의 업체들은 연봉을 높게 해 줄테니 혼자서 만들어 달라고 하는 식이 많았다. 누구 죽으라는 소린가... 잘하는 프로그래머 개개인에만 관심이 있고 당면한 프로젝트 하나에만 집중하기 때문이다. 반대로 앞으로 무엇이 되었든 잘 개발해 낼 수 있는 팀과 시스템의 개발은 아예 관점도 없다.
본인의 경우 구인시 이력서를 볼때 단독작전 경력은 중요치 않게 본다. 사이즈가 작기도 하고 능력의 객관적인 입증이 어려울 뿐더러 앞으로의 개발에 별로 도움이 되는 경험이 아니기 때문이다. 팀플레이 경력이 없다면 나의 눈에는 신입이 되는 셈이다. 팀플에 있어서도 자신이 무엇을 해내었다는 점 보다는 어떻게 코웍을 했는지를 중요하게 본다. 어떤 사람들은 개개인의 람보화가 중요하다고 볼 지 모르지만 나의 경우엔 팀플을 잘 할 수 있음을 중요하게 본다. 회사의 경우에도 자사에 훌륭한 작전중대의 셋업을 중요시 해야 한다고 본다.
프로그래머는 그럼 어떻게 해야 하는가.
순전히 개인적인 생각이라 정답이라고는 할 수 없겠지만 현 시점에서 내가 가진 생각은 이렇다. 팀에 적응하고 환경에 적응할 수 있는 Capacity를 확보하라고 하고 싶다. C++을 매우 깊게 파고는 "아름다운 코드"를 생성해 낼 필요는 없다. 팀프로젝트에서는 부분 부분 코드의 아름다움성이 전혀 도움이 되지 않는다. 대신 새로운 언어라도 한달정도의 학습기간을 통해 적당한 수준의 생산이 가능하면 코더로서는 충분하다. 대신 중요한 것은 팀을 어떻게 사용하는가일 것이다. 코더의 위치에서 보면 위에는 매니저가 있을 것이고 옆에는 동료코더와 테스터, 테크니컬 라이터, 영업들이 있을 것이다.(물론 회사 대부분이 이런경우는 드물긴 하다. --;) 자신의 단독 플레이가 아닌 팀을 통해 프로젝트를 진행하는 방법을 터득해야 할 것이다. 그리고 개발환경이란 것이 프로젝트에 맞추어 변화하게 마련이므로 그 변화에 쉽게 적응할 수 있는 준비를 하기를 권장한다. PHP의 특정 함수 하나를 일부러 외우는 노력은 의미없다라고 본다. 진정한 코더는 어드바이저(팀에서 기술적인 조언을 담당하는 사람)가 준 책이나 헬프파일을 받고 주어진 기능성을 수행하는 코드를 제한시간내에 작성하는 사람이다.(물론 매니저의 기간 예측능력이 필요하기도 하다.) 한번에 완벽할 필요도 없다. 옆에는 테스터가 존재하니깐.
자신이 주로 하는 언어나 작업의 전문적인 지식은 물론 상당히 중요하고 깊을수록 가치가 있다. 그보다 더 중요한 것은 그 작업을 팀을 통해 이루어 나갈 수 있도록 하는 능력이다. 정확히는 효율적으로. 혼자서 작성하면 매우 아름다운 코드를 만들수 있을지 모르겠지만 10년이 걸리는 것 보다는 덜 아름답더라도 1년만에 완수하는것이 더 좋다.
사장이 직접 코딩을 하면서 밑의 코더들을 구박하는 케이스를 들을때 마다.. 그 사장이란 사람이 훌륭한 말단 코더일지는 모르겠지만 그 회사가 좋은 팀을 가지고 있다라고 보지는 않으며 그 회사의 제품에 대해서도 썩 믿음직 스럽지 못하다.
그럼 회사는?
팀이다. 정확히는 팀과 시스템이다. 개발 프로세스 자체도 제멋대로인 회사도 많은 상황이 아닌가. 잘하는 프로그래머 한두명만 있으면 훌륭한 프로그램이 나올거라고 생각할지 모르겠으나 그정도 사이즈면 벤처가 첫 스테이지에나 쓸만한 규모일 것이다. 버그가 많아도 비젼의 가능성을 테스트해 주는 정도. 그런 상황에서 다음 스테이지로 넘어갔거나 어느정도 규모가 되는 사업체라면 팀이 필요해 진다. 그리고 그 팀이 유지되는 시스템이 필요하다.
구인시장에서 3~5년차 프로그래머를 왜그리 찾게 되는가. 그 회사들이 그런 사람을 키우는 시스템이 없다 보니 회사에도, 시장에도 그런 사람이 절대적으로 부족하다. 3~5년차의 제대로 된 프로그래머는 신입이 제대로 된 교육과 경험을 토대로 만들어 질껀데 그럴 가능성이 매우 낮다. 프로젝트의 성공은 기원하면서 사원의 능력 향상에 신경을 쓰는 회사가 얼마나 될까. 대략적인 교육시스템을 가진 회사는 있지만 개개인을 대상으로 관리해 주는 경우는 매우 드물다. 맞춤식 교육을 어린애들은 받고 있지만 사원들은 받지 못하는 것이다. 연말에 인사고과 신나게 하고는 연봉에만 적용될 뿐 교육시스템에 적용해 본적이 있는가?
이지중대(Easy Company)
<band of brothers>라는 영화를 보면 2차세계대전 당시 훌륭한 작전 수행을 했던 이지중대 이야기가 나온다. 구성원중에 뛰어난 능력을 보여준 사람이 있긴 하지만 람보는 아니다. 대신 그들은 중대를 통해 훌륭한 역할을 수행했고 반대로 중대는 그런 사람들을 위한 시스템을 가지고 있었다.
한사람의 스타프로그래머(람보)를 중요시 생각하는 임원이나 개발자라면 생각을 재고해 보기 바란다. 많은 프로젝트가 스타프로그래머와 프로젝트 성공과의 연관성이 크지 않음을 입증하고 있고 반대로 팀과 시스템이 기존의 문제들을 얼마나 보완해 나가느냐가 중요한 것이다. 개인도 코웍 캐패시티가 매우 중요하다. 자신이 하는것과 당하는 것 모두!
'개발&Development > 개발방법론' 카테고리의 다른 글
The Art of Project (2) | 2006.07.18 |
---|---|
The Art of Project Management 번역 소식 (0) | 2006.05.22 |
Project VISION : 한마디로 표현하기. (0) | 2006.03.29 |
가장 취약한 코더가 시스템의 가장 취약한 코드를 만든다 (3) | 2005.11.02 |
SDL: Security Development Lifecycle (0) | 2005.03.22 |