Extremely Agile:

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

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

(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 바닥에서 매일같이 일어나고 있는 일들에 대한 아주 '현실적인' 이야기들입니다. 프로그래머를 족친다고 문제가 해결되는게 아니라구요! ㅋㅋ

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.