바로 이전 포스팅에서 Man-Month를 설명하다가 히어로 개발자를 언급했는데요,
(관련 포스팅, http://storycompiler.tistory.com/142)
이번 포스팅에서는 히어로 개발자라면 응당 받아야할 대접에 대해 써볼까 합니다.
물론, 히어로 개발자의 출몰을 경계하는 의견도 있습니다.
히어로 개발자도 엄연히 사람인지라 후진적인 정치활동으로 조직을 퇴화시킬 수 있습니다.
그렇기 때문에 오히려 히어로 개발자의 등장을 막아야 한다는 의견도 있습니다.
- 독단적인 결정에 따른 그릇된 방향설정
- 의사결정권자 부재에 따른 위험부담 증가
- 의사결정 소요시간의 증가
언뜻 생각해봐도 줄줄이 떠오르는 위와 같은 폐단을 막기 위해,
제 2의 잡스가 출현하는 것을 철저히 막고 있는 것인지도 모릅니다.
하지만, 위의 부정적인 요소는 '히어로' 개발자로 인해 발생하는 것은 아닙니다.
조직에 부여된 권한이 개별 구성원에게 알맞게 부여되지 않았기 때문입니다.
히어로 개발자가 한 명만 살아남은 조직은 결코 건강한 조직처럼 보이지 않습니다.
히어로 개발자 다수가 각각의 하부조직을 견실하게 떠받들고 있어야
조직 전체가 기민하게 움직이며 큰 그림을 함께 그릴 수 있습니다.
그렇게 하기 위해서는 다수의 히어로 개발자가 자랄 수 있는 자양분이 필요합니다.
이 글은 히어로 개발자가 무럭무럭 성장할 수 있는 환경에 대해
아주 편협한 일개 개발자의 시각으로 언급하고 있습니다.
무식하면 깡패라고 편협한 시각에서 오는 무지가 글 곳곳에 듬뿍 담겨 있습니다.
그 점 미리 양해 부탁드립니다.
조직 곳곳에서 자생하고 있는 히어로 개발자 분들은 어떤 대접을 받고 있을까요?
연봉이나 승진에 대한 보장은 이 글의 관심사가 아닙니다.
대신 히어로 개발자에게 주어지는 권한과 의무에 초점을 맞출 생각입니다.
결론부터 말하자면,
히어로 개발자에 대한 처우는 아티스트에 대한 대접과 비슷해야합니다.
다각적인 면에서 오랜 고찰을 통해 히어로 개발자의 생태를 연구한 끝에 내린 결론입니다.
아티스트가 예술작품으로 천문학적인 부가가치를 창출해내듯,
히어로 개발자도 소프트웨어를 예술작품으로 승화시켜 부가가치를 창출합니다.
수많은 국경없는 사용자들이 소프트웨어에 빠져들게 만들지요.
아티스트에 따라 피조물이 완전히 다르듯,
히어로 개발자에 따라 최종결과물도 천차만별입니다.
잘 키운 히어로 개발자는 먼훗날 박물관에 전시해도 손색이 없는 대중문화재를 만들겠죠.
그렇게 하기 위해서는,
히어로 개발자가 작품에 몰입할 수 있는 환경을 제공해주어야 합니다.
프로젝트 선택권
개발자들에게 특히 히어로 개발자에게 자신이 참여할 프로젝트를 선택하게 해야 합니다.
사실, 얼마전에 스타트업 회사에 방문한 기억이 있습니다.
그 회사는 사내게시판에서 신규 프로젝트에 참여할 사람을 공개적으로 모집하고 있었습니다.
프로젝트가 충분히 '될 성 부른 나무'라면 파티인원을 금새 모을 수 있습니다.
하지만, 장애가 많은 프로젝트라면 파티원을 구성하는데도 어려움이 생기겠죠.
다수가 프로젝트에 대해 고민할 수 있는 환경 자체가 시너지가 될 겁니다.
특정 사람들의 이권에 따라 현실성없거나 부질없이 생성되는 프로젝트는 사라질 겁니다.
단기실적이 아닌 장기적인 시각으로 접근하는 프로젝트에는,
파티원이 섣불리 참여하기가 힘들 수도 있습니다.
프로젝트간 적절한 보상장치는 따로 고민해봐야하겠지만,
이 경우 프로젝트 리더의 역량이 파티원에게는 중요한 판단근거가 될 수 있습니다.
훌륭한 리더 밑에는 우수한 파티원이 모일겁니다.
그렇지 않은 보스는 파티원을 모으기조차 힘들어지겠죠.
백로그 결정권
백로그는 우선순위가 명시된 작업열람표입니다.
애자일 개발방법론에서는 백로그 리스트로 작업사이클마다 다뤄야할 일을 확정합니다.
프로젝트를 위해 반드시 해야할 일은 백로그에 추가합니다.
그리고 할 필요가 없는 일은 백로그에서 제외합니다.
해야할 일과 그렇지 않은 일을 나누는 것에 대한 결정을 누가 해야할까요?
그리고 해야할 일에 우선순위를 부여하는 것은 누구일까요?
기획, 디사인, 개발, 검증, 영업?
프로젝트에 관여하는 모두가 프로젝트에 대해 자유롭게 의견을 낼 수 있습니다.
다양한 시각에서 다양한 이유를 들어 다양한 항목을 백로그에 추가하려 시도할 수 있습니다.
하지만, 최종결정은 프로젝트에 참여하고 있는 개발자의 손에서 이뤄져야 합니다.
Product owner, Team leader, Project leader...
어떤 이름이건 실제 개발에 참여하고 있는 개발자가 해야합니다.
개발자 중 가장 탁월한 히어로 개발자가 '합리적으로' 최종의사결정을 내리게 되겠지요.
아키텍쳐 결정권
프로젝트를 위해 해야할 일이 결정되면,
요구사항에 따라 아키텍쳐를 설계해야합니다.
새로운 요구사항이 기존 아키텍쳐에서 수용하기 힘든 경우가 있습니다.
그럴 경우에는 아키텍쳐를 완전히 뜯어고치더라도 요구사항을 개발해야 합니다.
어떤 경우든 아키텍쳐는 프로젝트를 담당하고 있는 히어로 개발자가 선택할 수 있어야 합니다.
더 나은 길이 존재하는 경우라면 그 길을 선택하면 됩니다.
하지만, 가치나 정책의 충돌에서는 프로젝트의 철학을 꿰뚫고 있는 개발자가 나서야 합니다.
그리고 그게 대부분은 히어로 개발자가 되겠군요.
정예개발자 육성
히어로 개발자도 처음에는 루키였습니다.
처음부터 히어로인 개발자는 거의 없을 겁니다.
따라서 개발자를 히어로 개발자로 성장시키기 위한 고민을 언제나 해야합니다.
어제는 형편없다고 생각했던 개발자가 내일은 우수한 개발자로 성장할 수 있습니다.
히어로 개발자가 오만에 빠지지 않도록 유의하며,
자신과 함께 일하는 개발자들의 성장에도 관심을 기울여야 합니다.
그리고 개발자 교육을 위해 필요한 수단을 결정할 수 있는 권한이 있어야 합니다.
필요하다면 몇 주간 교육을 보낼 수도 있고,
책 몇 권을 사다주며 세미나를 부탁할 수도 있겠죠.
자유 도서구입권 & 컨퍼런스 자유이용권
히어로 개발자도 끊임없이 공부해야합니다.
개발자 세계에서 영원한 진리는 없습니다.
그렇기 때문에 개발자 자신은,
매일의 트렌드를 익히고,
새로운 기술을 익히고,
참신한 이론을 엿보고,
신선한 발상에 끊임없이 노출되어야 합니다.
그렇게 하기 위해서는 개발자 성장에 적극 투자해야합니다.
읽고 싶은 책은 마음껏 구매하게 합니다.
참석하고 싶은 컨퍼런스에는 마음껏 참석하게 합니다.
개발자 성장을 위한 비료가 투자아닌 비용으로만 여겨진다면,
개발자 문화나 조직문화에 문제가 있는게 아닐까요?
개발을 위한 개인공간
히어로 개발자는 예술가에 가까운 존재라고 언급했습니다.
매일같이 고도의 집중력을 요하는 작업을 수행하고 있습니다.
그러나 열린 공간을 지향하다 보니,
집중할 수 있는 시간 5분을 마련하기 힘듭니다.
다른 부서의 히어로 개발자들 의견을 들어보면,
새벽이나 밤이 되서야 비로소 자기 일을 할 수 있다고 합니다.
낮시간에는 주로 다른 개발자나 다른 부서의 의문이나 요청을 처리한다고 합니다.
이런 식으로 개발이 진행되면,
히어로 개발자의 업무효율을 바닥을 치게 됩니다.
일과시간에도 집중하여 자신의 업무를 처리할 수 있는 시간이 필요합니다.
하루 종일 폐쇄된 공간에서 활동할 필요는 없습니다.
그렇지만, 개인업무에 필요한 시간 만큼은,
개인공간을 보장해주어야 합니다.
최상의 도구 제공
히어로 개발자 뿐만 아니라 모든 개발자는 최고의 도구를 갖고 있어야 합니다.
목수는 연장 탓을 하지 않지만,
개발자는 철저히 연장 탓을 해야 합니다.
컴퓨터 성능에 따라 개발자의 업무 효율을 극단적으로 바뀝니다.
빌드가 10초내로 되느냐에 따라 개발자의 집중도에 차이가 납니다.
모니터의 크기나 개수에 따라 개발효율이 달라집니다.
한 눈에 필요한 정보를 얻을 수 있게 뒷받침해줘야 합니다.
키보드, 마우스, 의자는 개발자의 건강생활과도 직결되어 있습니다.
건강한 개발자가 건강한 코드를 작성하는 법입니다.
이 글은 제 주위에 있는 히어로 개발자들을 보며 쓰게 되었습니다.
임원급, 간부급, 사원급 모두에 히어로 개발자가 있더군요.
히어로 개발자에게는 더 좋은 소프트웨어를 만드려는 순수한 열정이 넘칩니다.
그런 사람들과 함께 일하는 것만으로도 충분히 동기부여가 됩니다. :)
더 많은 히어로 개발자가 한국에 출몰하여,
한국의 소프트웨어 경쟁력을 몇단계 올릴 날을 기대해봅니다.
'IT' 카테고리의 다른 글
[SCSA] SCSA 면접에서는 어떤 질문이 오갈까요? (4) | 2015.11.01 |
---|---|
[SOSCON/EFL Forum] 소스콘 EFL 포럼 후기 (30) | 2015.10.31 |
[Smart Health] 구글 / 애플 / 타이젠 헬스플랫폼 전략 (0) | 2015.10.30 |
[KLF] Korea Linux Forum 2015 행사 (0) | 2015.10.20 |
[대회] SCPC 삼성 대학생 프로그래밍 경진대회 (4) | 2015.10.13 |
[SCSA] Samsung Convergence Software Academy를 말하다 (12) | 2015.10.07 |
[소프트웨어 개발] Man-Month 허상과 히어로 개발자 (4) | 2015.09.29 |
[Agile] 애자일 적용 우선순위 (0) | 2015.09.22 |
[Agile] 대규모 집단에서의 애지일개발방식 적용에 대한 고민 (0) | 2015.09.21 |
[agile] 일개 개발자가 본 스크럼 개발방법론 (60) | 2015.09.09 |