Extremely Agile/General2007.11.25 21:12
오늘 이런 글을 하나 봤습니다. 개발자 부족이 낳은 기이한 현상들이라는 제목의 글이더군요. 다른건 둘째치고 그 글에 달린 덧글들이 굉장히 인상적이었습니다. 현재 개발자로 일하고 계시는 분들이 원 글을 쓰신 분을 비난하는 듯한 덧글들이 굉장히 많았는데요. 저는 이분의 문제 제기 자체는 정당했다고 생각합니다. 다만 현재 개발자가 아닌 다른 위치에 계시는 분이니까, 같은 문제를 보는 시각이 개발자들 분과는 좀 다를 뿐입니다.

어쨌건 이 분이 지적한 문제는 대략 다음과 같습니다.

(1) 초급 개발자의 능력 문제
(2) 초급 개발자의 능력에 비해 과도한 보수
(3) 프로페셔널리즘의 부재


이중 (3)은 괜히 논란만 불러 일으킬 뿐이지 현재 상황을 생산적으로 극복하는데 별 도움은 안되는 것 같군요. 그러니 (3)은 이야기하지 않는 편이 더 나았을 겁니다. 개발자의 자존심 문제하고 관련이 있거든요.

그러면 (1)과 (2)의 문제를 생각해 보죠. 사실 (1)이나 (2) 모두 사람이 부족하니까 생기는 문제입니다. 개발자 층이 풍부하다면, 초급 개발자의 능력 문제를 따질 필요가 없습니다. 초급 개발자는 초급 개발자답게, 스스로의 역량을 키우는 데 집중하면 될 것이고, 프로젝트를 이끌어 가는 것은 중고급 개발자들이 하면 됩니다. 그럼 왜 이렇게 개발자들이 부족한 것일까요? 거기에는 여러가지 요인이 있습니다. 그 중 가장 뻔한 것 부터 살펴보죠.

A. 개발자들이 부족하기 때문이다.

네. 말장난같지만 개발자들이 부족하기 때문에 개발자들은 더 부족해지고 있습니다. 개발자들이 부족하다는 것은 프로젝트 인력 수급이 비정상적으로 될 수 밖에 없다는 것을 암시합니다. 이미 존재하는 팀이 프로젝트를 맡는 것이 아니라, 프로젝트 계약이 성사되면 그 시점에 프로그래머들을 구하기 시작합니다. (이렇게 해서 구해진 프로그래머들 대부분은 초급입니다. 중/고급 프로그래머들은 대부분 이미 다른 일이 있습니다.) 계약이 성사된 시점에 이미 데드라인은 받은 상태이고, 어떤 기능을 언제까지 내놓을지는 모호한 상태입니다. 구해온 프로그래머는 관리자 입장에서 보면 그야말로 '어디서 데려온 프로그래머들'이기 때문에, 프로젝트 관리자는 이들을 고객과 대면시킬 생각도 없고, 그럴 계획도 없습니다. (그런 경우가 대부분입니다.) 따라서 프로그래머들은 모든 지시를 프로젝트 관리자로부터 받는데, 문제는 관리자가 각각의 프로그래머의 능력을 정확하게 알지 못하므로, 이 관리자가 '누가 어떤 작업을 언제까지 마무리 지을 것이다'라는 추정을 할 경우, 그 추정은 백발백중 실패하게 되리라는 사실입니다[각주:1].

이렇게 될 경우, 결국 프로젝트 일정은 날이 갈수록 타이트해지고, 후반부로 갈 수록 빡빡해지며(원래는 일이 진척되어 갈 수록 일의 양이 줄어들어야 하잖아요?), 프로그래머에게 아무 예고 없이 요구사항 변경이 통보되는 빈도수도 증가합니다(고객과 대면할 기회가 없으니 당연하죠). 결국, 개발자들이 체감하는 삶의 질은 프로젝트가 진행될 수록 나아지고 예측 가능해 지는 것이 아니라, 프로젝트가 끝날 때 쯤 되면 완벽하게 피폐해지게 됩니다. 그러니, 개발자들이 이 바닥에서 오래 버틸 리가 있겠어요?

B. 질적인 성장을 담보하지 못한 양적인 팽창

한떄 대학교가 IT 관련 학과들의 정원을 무차별적으로 늘리면서, 업계에 몸담는 프로그래머의 수도 늘어났습니다. 한때 닷컴 열풍이 불면서, 이 때 쏟아져 나온 프로그래머들 대부분이 자연스럽게 업계로 이동했고, 프로그래머와 일자리 간의 수급 균형이 얼핏 맞는 것 같아 보이게 되었습니다.

하지만 닷컴 열풍은 오래가지 못했고, IMF가 찾아왔고, 대부분의 프로그래머들의 고용이 불안정한 지경에 놓이게 되었습니다. 어쩌면 프로그래머들이 프로그래밍으로부터 등을 돌리기 시작한 시점은 이때부터 일겁니다. 고용이 불안정한 일거리에 누가 붙어 있으려고 하나요?

하지만 그렇다고 IT 전반이 한꺼번에 죽어버린건 아닙니다. 아직도 많은 SW 프로젝트들이 만들어지고 있고, 한국 IT 인프라를 보는 많은 사람들은 아직도 긍정적인 전망을 내 놓고 있습니다. 그러다 보니 이제 프로그래머를 둘러싼 수요와 공급 간의 불균형이 두드러집니다. 아직도 프로그래머들을 원하는 새로운 일거리는 꾸준히 있는데, 소위 '쓸만한' 프로그래머는 많지 않습니다. 그러다보니 자연스럽게 중고급 프로그래머가 느끼는 일의 강도는 상승합니다. 일이 몰리는거죠. (반면에 보수는 그다지 높지 않죠.) 그러다보면 작업 결과의 질이 떨어져 '좀 쓸만해 보였던 프로그래머'가 일순간에 '생각보다는 쓸만하지 않은 프로그래머'로 전락하기도 합니다.

이런 상황에서 중고급 프로그래머가 초급 프로그래머에게 바람직한 역할 모델을 보여줄 기회는 많지 않습니다. 다들 자기 앞가림 하기에 바쁘죠. 실제로, 대부분의 중고급 프로그래머들은 자신이 몸담고 있는 IT 업계에서의 '프로그래머의 미래'를 그다지 낙관적으로 보고 있지 않습니다. 많은 사람들이 이야기하듯이, 35이 넘어가면 프로그래밍을 떠나 다른 일을 하게 될 가능성이 높지만 (정말로 이상한 현상 중의 하나입니다만) 그렇더라도 프로그래머에게 주어지는 그 '또다른 기회'의 질이 그다지 높은 것도 아니거든요.

그러다보니 이제 'IT 돌려막기'의 최전선으로 나서는 중고급 프로그래머들, 소위 이 바닥의 잘나간다는 IT 프로젝트를 왔다갔다 하면서 책임지는 새로운 프리렌서 집단이 나타나게 되었습니다. 이런 부류의 프로그래머 분들은 붙박이 직장이 주는 스트레스에서 한발 떨어져 있으면서, 자신이 가진 프로그래밍 노하우를 활용하여 더 많은 금전적 혜택을 얻고자 하는 분들입니다.

결국 업계 전반적으로 만연된 '쓸만한 프로그래머가 없다'는 푸념은 애초에 이 바닥이 양적으로 팽창했다가 차갑게 식어갈 무렵, 예정되어 있던 것이라고 보는 것이 맞겠어요. 그리고, 이런 인력 부족 현상은 초급 프로그래머에게 있어서 보다(초급 프로그래머는 어쨌던 계속해서 시장에 나오게 되어 있습니다. 많던 적던), 중고급 프로그래머들을 대상으로 훨씬 심하게 나타나고 있습니다. 이런 결과는 (1) 과도한 업무량 (2) 낮은 보수 (3) 불투명한 미래 (4) 불확실한 보장 등등이 맞불려 일어나는 현상이죠. 앞서 말씀드린 35세라는 나이 문제도 있구요. 35세 이전에 아키텍트가 되지 못하면 영원히 되지 못하는거죠 ㅎㅎ

그러니 초급 프로그래머에 대해서는 '보수' 문제가 불거지고(왜케 비싼거냐?), 회사에서는 '쓸만한 인재가 없다'는 투덜거림(쓸만한 놈들 다 어디갔어? 우리 회사에 있는 놈들은 다 왜이래?)이 나올 밖에요.

그러면 이런 문제는 어떻게 해결해야 하나요?

이런 문제를 해결하려면 IT 업체들이나 새로 이 바닥에 뛰어들려는 사람들이 개발자라는 사람이 원하는 것을 조금 더 이해하도록 노력해야 하고, IT SW 프로젝트의 라이프사이클에 대해서 좀 더 치밀한 연구를 해야 합니다. 프로그래머의 수를 늘리는 방법이 나오질 않아서 의아하시죠? 저는 지금 프로그래머의 수 자체는 적정 수준이라고 생각합니다. 중고급 프로그래머들이 적어서 문제죠. 피라미드는 피라미드인데, 밑이 너무 넓어요.

중고급 개발자의 수를 늘리려면 사실 '프로그래밍 언어를 가르치는 수준'에서 한발짝도 더 나아가지 못하는 IT 교육 과정의 문제점부터 사실 개선해야 합니다. 김창준님 같은 분에게 부탁해서 "프로그래머라면 반드시 읽어야 하는 추천 도서" 목록이라도 한번 배포하고 나면 문제가 어느 정도는 개선이 될지도 모르죠. 저는 중고급 프로그래머가 되려면 적어도 설계+구현+테스트에 필요한 잘 알려진 솔루션을 한가지씩은 섭렵하고 있어야 한다고 생각합니다. UML도 불편하지 않을 정도로 하고, 언어들 중 한두가지 정도는 불편하지 않을 정도는 쓸수 있고, 프로그램을 넘기기 전에 단위 테스트를 충실히 해야한다는 것 정도는 알고 있고, 알고리즘을 어떻게 만들고 개선해 나가면 되는지에 대한 기본적인 지식 정도는 있어야 하겠죠. (부분적인 예에 불과합니다. 이것보다 더 많은 것들이 '기본적인 지식'으로 꼽힐 수 있을겁니다.)

그런데 중고급 개발자의 층을 두텁게 하기 위해서는 사실 교육보다도 환경의 문제가 먼저 개선이 되어야 합니다. 그렇게 고된 삽질에 시달리다보면 스스로에게 지적 영감을 줄만한 깨달음을 얻기가 참 힘들죠. 만사 귀찮아지는 생활을 몇년 하다 보면 매너리즘에 젖어서 나중에는 (1) 개발에 넌덜머리가 나거나 (2) 스스로의 지식만이 최고라고 믿는 양극단 중 한쪽으로 가기가 쉽거든요. 그럼 환경의 문제는 어떻게 개선을 해야 하나요?

잘 알려진 이야기 몇 가지를 해 보죠.

  1. 여러가지 업무를 동시에 하는 프로그래머의 업무 효율은 한 가지 업무를 할 때보다 떨어진다
  2. 기능이 아닌 '활동' 기반의 프로젝트 Planning은 실패할 가능성이 높다
  3. 그러므로 Gantt Chart는 실제로는 아무 쓸모가 없다
  4. 야근을 한다고 업무 효율이 증가하는 것은 아니다
  5. 끊임없이 재검토되지 않은 요구사항은, 프로젝트 말미에 가면 아무도 원하지 않는 요구사항이 될 가능성이 높다
  6. 따라서 요구사항은 끊임없이 재검토 해야 한다
  7. 일정을 맞추기 위해 제품의 질을 희생하는 것은 좋은 생각이 아니다
  8. 일정을 맞추기 위해 새로운 프로그래머를 채용하는 것은 그다지 큰 효과가 없다
아마 이런 이야기들을 한귀로 흘려듣지 않고 좀 깊게 생각해 볼 화두로 받아들이기만 해도, IT 프로젝트가 실패하거나 프로그래머들에게 고통을 줄 가능성은 굉장히 줄어들 겁니다.

프로그래머와 프로젝트가 win-win할 수 있는 가장 좋은 방법은, 프로젝트를 planning할 때 프로그래머를 참여시키는 것입니다. (물론 그러려면 프로젝트가 요구사항을 검토하기 시작할 때 부터 이미 팀은 꾸려져 있어야 합니다.) 프로그래머가 추정한 일정이나 규모 추정치를 가장 현실적인 것으로 받아들이고, 야근과 같은 잔업을 프로젝트 일정 추정 과정에서 철저히 배재시켜야 프로그래머도 인간적인 환경에서 일을 할 수 있고, 프로젝트도 그 일정에 관한 한 보다 현실적인 추정을 할 수 있습니다. 현실적인 추정이 될 때, 그에 기반한 계획(Planning)이 가능하고, 그런 계획이 만들어질 때 프로그래머는 계획한 일을 하고 남는 시간을 자신을 위해 투자할 수 있습니다. 프로그래머는 프로젝트를 진행하는 사람이지 간트 차트에 그려진 일정을 맞추기 위한 기계나, 프로젝트의 소모품이 아닙니다. 프로그래머도 쉴때는 쉬어야 합니다. 일자리가 주는 삶의 질이나 기회가 높아질 때, 초급이 중급으로, 그리고 중급이 고급 프로그래머로 나아갈 수 있습니다. 그때가 되면 아마 "쓸만한 개발자가 없어"라는 말도 좀 덜 나올 수 있겠죠. "쓸만한 개발자"는 사실 "여러분 주변"에 있는 개발자입니다. 조직이 그 사람들에게 "쓸만한 개발자로 스스로를 갈고 닦을 시간"을 주지 않거나, "머리를 좀 굴려서 눈 앞의 석탄을 다이아몬드로 바꿀 방법을 고안해 낼 시간"을 주지 않기 때문에 쓸만한 개발자로 보이지 않을 뿐입니다.

그리고 중고급 프로그래머를 나이가 좀 들었다고 다른 업무로 돌리는 식의 인사 행태도 좀 달리 생각해봐야 합니다. 그런 분들이 프로젝트 초기 부터 SW 아키텍처 작업에 주도적으로 참여하고 Chief Programmer로서 일하게 되면, 최종적으로 나오게 될 프로그래밍 결과물은 굉장히 달라질 수 있습니다.

물론 이렇게 이야기하면 또 이런 질문이 나올겁니다.

A. 사람이 없는데 어떻게 인간적인 일자리를 만드나?
B. 일정이 빡빡한데 어떻게 그렇게 낭만적으로 일할 수 있나?

A에 대해서라면, 인간적인 근무환경을 보장하는 것으로 프로그래머들을 모을 수 있다는 사례 1 2가 있습니다. B에 대해서라면, 위에 언급한 '잘 알려진 이야기'들에 대한 연구 사례들을 조금 더 주의깊게 읽어 보셔야 할 것 같습니다. 이 '잘 알려진 이야기'들은 전부 지금의 IT 바닥에서 매일같이 일어나고 있는 일들에 대한 아주 '현실적인' 이야기들입니다. 프로그래머를 족친다고 문제가 해결되는게 아니라구요! ㅋㅋ

  1. 추정을 정확하게 하려면, 고객이 '자신이 원하는 기능'에 대한 명세를 개발자들에게 보여주고, 개발자들이 그 기능을 구현하는 데 소요될 시간을 추정하게 한 다음에, 그에 기반해서 최종 소프트웨어에 탑재할 기능을 취사선택하도록 해야 합니다. 개발자들이 정확한 추정을 할 지 못믿으시겠다구요? 그러면 본인의 추정치는 무슨 근거로 확신하세요? [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 늙은개발자

    정확히 합시다. 부족한게 아닙니다.
    전혀...

    다만 마구 양성했던 싼값에 진행했던 또는 그런데로 진행되고 있다고 느끼게 했던 그
    현상이 사라져서 느끼는게 부족하게 느끼는거죠...

    부족이란 말과 적정 및 과도하다는 말은 공급쪽 팩터에 뭔가 균형을 헤치는
    힘이 존재하기 때문인데.. 그런게 과도한 적은 있었지만.. ( 정부 지원 학원 난립시절 )
    현재를 보면 수요나 공급쪽에 전혀 인위적 개입이 없습니다. 수요가 크면
    공급은 일어납니다만.. 현재 전혀 공급이 늘어나지 않는것은 수요가 사실 없기 때문입니다.

    그냥 막연히 업계 시공사에서 하는 말은 무시하세요. 안되면 말마따나 인도쪽이나 배트남쪽을
    알아보겠죠.

    중요한건..... 부족이라고 판단하는것 자체가 어떤 근거가 있는게 아니라는 겁니다.
    게다가 초보가 월 300이라니? 란 말도 전혀 근거가 없는 그냥 감정상의 느낌일 뿐이라는 거죠...
    과거와 비교되기 때문에 느껴지는 그런 느낌.

    엔지니어이거나 과학자라면... 그냥 느낌으로 판단해서는 안되겠죠? 애초에 엔지니어 공급을
    양쩍으로 팽창시킨다고해서 산업이 건강해지는건 아닙니다. 생태계가 건강해야죠.... ^^

    또 한번 느낌으로 일을 저지르면 ( 학원에 돈 퍼주기 같은거 다시 하면..)
    이젠 영영 복구하기 힘든 지경이 될겁니다.

    2007.11.30 11:37 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 늙은개발자

    참고로 ...

    보통의 기업에서 경영기획이나 관리파트사람들은 판단을 느낌 + 읽었던 책에 나온말..
    로 하는 경향이 있습니다. 원글자 ( 기이하다고 했던.)
    도 MIS 관련일을 했을수는 있지만.

    실제 엔지니어는 아니었을거라고 짐작합니다. ( 학교에서 배웠다 하더라도
    실무를 직접했던 경험이 많지 않은 경우나 바로 PM 생활했거나..)

    2007.11.30 11:40 신고 [ ADDR : EDIT/ DEL : REPLY ]
  3. 늙은개발자

    님의 잘알려진 사항들 잘 읽어보시면..

    고객이 무지 좋아하는 걸로 이루어져 있지요?

    기이하다고 했던 분도 저같은 코더들에게는 다른

    고객과 별로 차이없는 어쩌면 더 난해한 고객입니다.

    2007.11.30 11:42 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그 '잘 알려진 사항'들은 고객이 좋아하는 사항은 아닙니다. 사실은 개발자가 몸담고 있는 조직에서 조차도 그닥 선호하는 이야기는 아니죠. '그분들'은 그렇게 기민하게 반응하면 애초에 계획했던 대로 프로젝트가 굴러갈 리 없다고 믿거든요.

      위의 '잘 알려진 사항'은 '비현실적 추정'으로 프로그래머들을 압사시키는 대신 '현실적인 추정'이 이루어져야 한다는 연구결과입니다. 고객에게 만족스러운 부분은 아마 고객이 프로젝트 진행 중에 요구사항을 바꾸는 것이 '당연한 현상'이라고 보는 부분 정도일거에요.

      하지만 그것을 '당연한 현상'이라고 보지 않으면, 프로젝트 말미에 '이미 완결된 아키텍처까지도 뒤엎어야 하는' 일이 발생할 가능성이 점점 더 높아집니다.

      요는, 그런 요구사항 변화에 기민하게 대응할 수 있으면서, 프로그래머에게 인간적인 근무 환경을 보장할 수 있으려면, 현실적인 추정과 그에 입각한 프로젝트 플래닝이 이루어져야 한다, 뭐 그런 겁니다. :-)

      와주셔셔 감사합니다. 좋은 의견 주신 점도 감사드립니다.

      2007.12.01 06:49 신고 [ ADDR : EDIT/ DEL ]
  4. 늙은개발자

    일이 몰리면 초급하나 더 밖아주고..
    일정이 반으로 줄거라고 생각하죠.. 머리들은..

    2007.12.18 13:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 분들에게는 "프로그래머의 수가 늘어난다고 프로젝트가 빨리 끝나지는 않는다"는 연구 결과를 보여드리는게 좋을 것 같습니다. agile.egloos.com 어딘가에서 읽었었는데 링크를 다시 찾아보려니 못찾겠네요.

      2007.12.18 13:29 신고 [ ADDR : EDIT/ DEL ]