본 글은 개발에 대한 저의 무지했던 2004년도 의견을 주관적인 관점에서 적었던 글입니다.
Written by ienvyou - 최지웅(놀새~)
근간의 프로젝트들을 접하면서 느낀점을 간략하게나마 적어보도록 하려 합니다.
매일같이 쉴새없이 회의와 프로그래밍의 골치아픈 현실속에서 나름대로 어떤 것이 프로젝트에 있어서 옳은 방향이고 어떤 것이 나쁜 방향이라 단정을 할 수는 없습니다.
처음으로 프로젝트에 투입되던 때의 설레임이 가끔씩은 생각이 나곤 합니다.
"내가 과연 개발을 잘 할수 있을까?", "밤을 샌 날은 며칠이나 될까?" 라는 생각을 하며 설레였던적도 있었습니다.
완전히 바닥의 프로젝트 팀원부터 중규모이상의 프로젝트의 관리해 본 시점의 지금은 무언가 이루었다는 느낌이 아니라 점점 더 분발을 해야 한다는 느낌이 더 지배적이라고 해야 맞을 것 같습니다.
▶ 개인의 역할(The roles of The individual)
일반적으로 프로젝트가 시작이 되고 나면 팀이 구성이 되어집니다. PM이 선정되며, 업무를 추진할 수 있는 PL등등의 각자의 역할이 구성되어집니다. 이글을 읽는 여러분들의 대부분이 개발자일 것입니다. 각각 프로젝트 팀원으로서의 역할을 시작하게 되는데, 개인은 서로 다른 개성을 가지고 있으며 다른 삶, 다른 기술적 능력을 가지고 있을 것입니다.
자, 이런 개발자의 입장에서 당신이 PM을 뽑는다면 대체 어떤 사람을 뽑을까요? 아마도 90%이상의 사람들은 자신들의 요구를 쉽게 받아들여줄 수 있는 관리자 아니면 성격좋은 관리자를 택하는 것이 대부분일 것입니다. 그렇게 뽑힌 PM이 있다고 가정을 했다고 했을 때, 프로젝트를 성공리에 끝낼수 있을까요?
제가 작성한 아티클 중 하나를 보면 콕번이 이런말을 했다라고 썼습니다.
"제대로된 사람만 있다면 가만히 두어도 프로젝트는 성공하기 마련이다" - 콕번
여러분께서는 스스로 콕번이 말한 제대로 된 사람이라고 자부할 수 있을까요? 스스로 발전하기 위해서 최선을 다했다고 생각하나요? 많은 책들을 읽고 자신만의 스타일을 구축하도록 했나요?
대부분이 하루하루를 힘겹게 프로그램과 씨름하다보면 그럴만한 시간이 없다는 것도 알고 있습니다. 하지만 최소한의 노력이라도 기울였는지 되돌아봐야 할 수도 있습니다.
1. 관리자
대부분의 관리자들은 현역에서 여전히 개발중이거나 개발에서 떠나 업무전문가의 위치에 와있는 사람일 수도 있습니다. 해당분야 업무에 대한 상당한 스킬을 지닌 사람이 보통 이 역할을 하게 되는데 문제는
얼마나 고객과 자기가 관리하는 개발자들 사이의 장벽을 줄여주는냐 하는 것입니다.
고객의 쓸데없는 요구를 잘라낼수 있어야 하며, 개발자들이 어떤 것을 원하는 지, 전반적인 스케쥴에 있어서 일정내에 프로젝트를 완료할 수 있는 갭을 조절한다든지 하는 것입니다. 즉 수위조절이란 말로 표현할 수 있겠는데 말그대로 강물을 막아놓은 댐이라고 생각해도 될 것 같습니다.
고객의 요구가 밀려드는 물이라고 생각했을 경우에 너무 넘친다면 일정부분을 흘려보낼 수 있어야하고 아예 말라버리지 않도록 어느 정도 물을 담아 놓을 수도 있어야 할 것입니다. 항상 진행상황을 체크하며 기술적인 문제는 PL,TL과 논의하고 "짜고 치는 고스톱"등의 정치적인 문제에 관여도 잘해야 할 것입니다.
eXtreme Programming Intalled책에서 관리자와 고객의 권리, 프로그래머의 권리에 대하여 아래와 같이 적고 있습니다.
http://www.amazon.com/exec/obidos/tg/detail/-/0201708426/qid=1049380201
☞ 관리자와 고객의 권리
1. 프로그램 작성 기간을 통한 최상의 가치를 얻을 권리
2. 진행중인 프로젝트를 검증된 시스템에서 진척된 사항을 볼권리
3. 기능을 바꿀 권리, 우선순위를 바꿀 권리
4. 일정계획의 변경을 알 권리(개발범위의 축소 및 취소등의)
☞ 개발자의 권리
1. 필요사항과 작업의 우선순위를 명확하게 알 권리
2. 높은 품질의 결과를 도출해낼 권리
3. 동료, 선배, 고객에게 도움을 받을 수 있는 권리
4. 자신의 역할에 대한 작업추정을 만들 수 있는 권리
5. 자신이 할 책임을 선택할 수 있는 권리
위의 내용에서 보게 되면 관리자는 프로젝트에 대한 내용중 무엇이 중요하고 아닌지에 따라 결정을 내리도록 하고 있습니다. 그것이 얼마나 개발자들에게 큰 영향을 미치는지 여러분도 알 수 있을 것입니다.
예전 프로젝트에 이런 경우가 있었습니다. PM의 위치에서 고객에게 너무 휘둘린 나머지 고객의 변덕(?)에 모두 "Yes~, Yes!"로 일관하는 사람이 있었습니다. 그러한 일이 자꾸만 반복될 수록 팀원인 개발자들은 점점 그 관리자의 역할을 이해하지 못했고 추후 프로젝트에 그 관리자와 다시는 일을 안하겠다는 사람이 대부분이었습니다.
개발자들은 사실 위의 경우처럼 유약한 관리자를 원하지 않겠지요. 제대로 된 개발자라면 관리자가 하는 일에 대하여 가치를 부여할 수 있는 능력을 가지고 있습니다. 관리자는 그들이 자신의 일에 가치를 부여한 만큼의 개발자에 대한 믿음으로 개발에 대한 순수성을 보장해줘야 한다고 생각합니다. 다른 외부로부터 개발자들에 대한 간섭을 하지 못하도록 방어막이 되어야 하고, 프로젝트에서 발생할 수 있는 잡음을 없애줘야 하며, 용기를 북돋워(회식에 소주라도 곁들이면 더 좋겠죠) 줄 수 있는 사람이라면 오케이입니다.
관리자 풀(Manager Pool)이라는 것이 만약 존재한다고 하였을 때 개발자들에 의하여 선택되어질 수 있는 그런 관리자가 되어야 할 것 같습니다.
2. 개발자
누구나 한번쯤은 겪는 과정이라 생각합니다. 앞서 말했듯이 놀새 또한 경험하며 지금도 그 역할에 충실하기 위하여 노력할 때도 있는 것이기 때문입니다. 개발자들 대부분은 자신만의 스타일을 가지고 있습니다. 코딩스타일, naming rule, 객체 작성, 메소드작성 등에 있어서 자신들만의 스타일을 고집합니다.
제 경우 보통 짧은 기간에 문제가 발생하는 프로젝트에 애플리케이션 검증, 성능 검증 등의 단기(보통 3~5개월) 프로젝트를 수행하므로 여러 상황을 접하고 있었습니다. 같이 일하는 개발자들에도 여러가지 부류가 있는데, 첫번째로 자신이 전혀 접해보지 못한 환경을 새로운 도전으로 받아들이고 열심히 노력하는 부류가 있었으며, 두번째로 자신만의 울타리안에 갇혀 새로운 도전에 대한 용기가
부족해 "왜 ~ 이렇게 해야 하느냐~!" 라는 반문을 던지는 사람, 세번째로 "그래~ 그냥 시키니깐 이렇게 한다" 라는 부류들이 있었습니다.
가장 위험한 부류는 어떤 사람들일까요? 개인적으로 두번째의 부류가 제일 위험하다고 생각합니다. 세번째의 사람들이야 시키면 하겠지만 자신도 모르게 어느새 새로운 방법에 대한 지식을 터득하고 있는 것이나 다름없습니다. 더할 나위없이 첫번째의 사람들이 발전을 제일 많이 하겠지만 말이죠.
하지만 위의 것보다도 더 중요한 것은 무엇일까요? 의사소통이 아닐까 싶습니다. 같은 프로젝트팀원과도 의사소통이 잘 이루어져야 하며, 조화를 이룰수 있어야 합니다. 소위 왕따라는 것이 이러한 프로젝트 개발에 있어서도 있어서는 안될 것입니다.(결국 PM이 찾아내겠지만...ㅡ.ㅡ)
의사소통이 비단 팀개발자들과의 관계만은 아닙니다. 관리자와의 의사소통(자신이 맡은 범위와 작업에 대한 협의)과 고객과의 의사소통(자신의 업무를 정확하게 설명해줄 수 있는 사람은 오직 고객)이 원활하게 이루어져야 정확하고 높은 품질의 코드를 생산해낼 수 있을 것입니다.
가끔 내성적인 개발자들을 많이 봅니다. 어떤 경우냐면 고객에게 가서 자신이 궁금해 하는 것을 물어보는 것이 죄짓는 사람인 것 마냥 행동합니다. 궁금하면 자꾸 질문하고 결과를 얻어내야 하는데 시간은 점점 흘러가고 업무지연이 발생하게 되는 것 같습니다. 이렇게 되지는 말아야죠. 개인적인 의견으로 개발자는 얼굴에 철판을 깔아야 합니다. 자신이 담당한 업무분야에 대해서는 확실하게 숙지하고 개발해야 할테니까요.
또 개발자로서의 역할로는 항상 탐구하고 비교하고 실험해봐야 한다는 것입니다.(업무시간이외에도 말이죠) 보통 업무를 하는데 있어서 일과시간이후가 되면 개인적인 생각으로 생산성이 굉장히 떨어지는 것을 느끼는데 개발자는 자신이 그날 어느정도의 일을 할 수 있는지의 추정을 할 수 있어야 합니다. 놀새~같은 경우는 아침에 출근을 하기 위해 운전을 하거나 버스, 지하철을 타고 그날의 할일을 계속 생각한 후 회사에 도착하게 되면 다이어리를 꺼내어 메모를 합니다.
보통 2주정도의 스케쥴을 먼저 잡고 매일 할일의 우선 순위를 정하는 것입니다. 대략 오후 6시에서 7시까지의 일을 적정수준으로 마칠수 있도록 우선순위를 조율합니다. 위에서 "항상 탐구하고 비교하고 실험해봐야 한다는 것이다"라고 하는 것과 무슨 연관이 있을까요?
아래에 일본에서 근무하는 친구가 보낸 메일을 잠깐 소개하도록 합니다.
"일본에서는 거의 한국인 중국인 인도인들이 컴퓨터 업종에서 일하고 있다. 가만히 일본인들하고 이야기 하다보면 다들 위 3국의 사람들과 다들 일해본 경험들을 갖고 있는
사람들이 많다. 각국의 사람들의 일하는 습성을 다 파악하고 있다는데서 놀라움을 금할수 없을 때가 종종 있다.
대충정리하자면 아래와 같다.
인도인- 머리는 좋은데 대가리만큼 몸이 따라가지 않는다.
중국인- 머리는 나쁜데 일은 열심히 한다. (납기일 초과)
한국인- 기술력은 있는데 머리에서는 딴자리로 옮길 생각만 한다.
잘 들어보면 맞는말이다.
나역시 딴자리로 옮길생각을 하니까...(후후)
그런데 중요한것은 이중에서 인도인의 인기가 가장 높다. 그 이유는 아직 분석 중이다.
내가 일하는 곳에도 인도인이 있다. 그 놈 카레냄새 난다고 하면 나에게서는 김치냄새가 난다고 한다.
하하 나 김치 못먹은지 3개월 째인데.. 죽을라구!!! 하여간 그러면서도 친구가 된다.
중국인들과는 일해 본 경험은 없는데 다른 사람의 말을 빌리자면 정말 변명이 많다고 한다. 자기탓으로 절대 돌리지 않느다고 한다.
잘못했으면 자신의 실수를 인정하지 않는다는 것이다. 그래서 언제나 납기일을 초과하는 아주 무서운 놈들이다.
인도인에게는 그만큼 가능성이 있으므로 인기가 좋을 것 같습니다. 사실 미국에서도 언어와 기술이 되는 사람들이니까요.
중국인의 경우 납기일초과. 결국에 해당업무에 대한 기한 초과라고 합니다. 어째서 일을 열심히 하는데 기한이 초과될까요? 결국 기술 부족으로 밖에는 설명이 되지 않을 것입니다. 남이 보면 10분이면 해결할 문제를 하루밤을 꼬박 지새고, 다음날은 전날 밤샘의 후유증으로 코딩 몇 줄 못하고 이게 소위말해 라이프사이클을 타게 될 확률이 상당히 높습니다.
원인은 시간날 때 이것저것 테스트를 하면서 자신의 것으로 만드는 것이 중요합니다. 어려운 것은 알고 있습니다. 이미 그것을 알 때쯤엔 앞선 사람들은 자신이 생각지도 못한 것을 보고 있을 것입니다.
기초에 충실해야 하고, 공부해야 합니다. 사람이란 편한 것에 아주 금방 익숙해지니까요.