우리나라 IT는 망할 것이다.

글로벌 소프트웨어를 꿈꾸다 ㅣ 글로벌 소프트웨어를 꿈꾸다 시리즈
김익환 지음 / 한빛미디어 / 2010년 9월

제목이 꽤 도발적인가요?
그러나 할 수 없다. 이것이 나의 생각이다. 어째서 이런 생각을 하느냐고? 나만 이런 생각을 하는가? 아마도 대부분의 IT쪽 특히 개발자들 간에는 이런 생각을 하는 이가 많을 것이다. 그럼 왜 그런 생각을 하는가? 그것은 내 자신이 소위 IT노동자이기 떄문이다. 필자는 개발자가 아닌 기획, PM이다. 그래서 IT쪽 일을 하지만 약간은 뒤로 물러나 앉아 IT의 문제를 바라보기도 하고 내 스스로가 그 안에서 허우적 거리기도 한다. 


스스로 만든 수렁

저자가 책에서 언급했듯이 IT가 3D 업종이 된 것에는 IT업계와 소위 IT인력들 스스로 책임져야 할 부분이 많다. 필자의 생각으로 60-70%가 IT업계 내부에서 초래한 문제이고 스스로를 3D 업동의 노동자라 칭하는 것도 IT인력들 스스로이다. 내부 사정을 잘 모르는 분야에서 3D업종으로 까지 분류하지는 않는다.

이 분야에서 개발자등의 상태가 가장 힘들다. 이들을 묘사할 때 가장 많이 나오는 단어라면 '야근', 철야' 일 것이다. 올해 봄에 인터넷의 일부 매체에서만 떠들썩 했다 TV에도 잠깐 언급되었던 IT 개발자들의 근무 환경에 대해 소개되었다. 초과 근무수당을 안주고 초과 근무을 시키는 것이 관행이다. 초과 근무가 수당을 주지 않기 위해 초과근무를 인정하지 않는다... 이런 이야기 였다. 소개된 개발자는 페암에 합병증까지 앓고 있는데 병중에도 철야를 했다고 하는데 회사에는 인정하지 않고 있다. 이 사건은 현재 우리나라의 IT관련 종사자들의 상황을 단적으로 보여주는 일ㅎ이다.

개발자는 물론이고 기획자, 디자이너도 상황은 비슷하다. 다만 마지막 작업을 처리하는 개발자와 끝까지 프로젝트를 책임지는 PM과는 상황이 좀 다르다. 그런데 이런 문제들은 개발자들 스스로가 만들어 낸 상황이라는데 아이러니가 있다. 이런 악순환은 초창기에는 아주 작은 문제에서 발생했을 것이다. 작은 개발건을 하던 개발자에게 마케팅 부서에서 요청이 들어온다. 

 
'상무님이 보고자 하시니 내일 오전까지 이 부분을 이렇게 고쳐주세요!'
작업 내용을 보니 5시간 정도면 수정이 가능하다. 다만 작업 중에 소스를 백업하고 문서를 수정하여야 하는데 지금 시간이 6시~ 외근 중에 팀장의 승인을 받고 문서 수정하고 나면 9시 전에는 코드 수정을 시작하기 어렵다. 고민 끝에 백업이나 문서 수정없이 코드에 손을 대어서 수정을 완료했다. 12시 30분 쯤 퇴근하고 다음 날 좀 늦게 10시에 출근했다. 그런데 오전 9시에 앞의 그 상무가 수정을 변경하여 다른 요구 사항을 전달하고 그 것을 받은 팀장이 소스관리 툴에서 해당 페이지를 받아서 수정한 것이다. 팀장은 어제 다른 지시가 있다는 것은 누구에게도 듣지 못하고 아침에 떨어진 부분만 수정한 것이다. 아뿔사 어제 작업 후 소스관리 작업을 안하고 간 것이다. 

이렇게 누수가 시작된 것이다. 처음에 1-2건을 놓치고 났을 때는 관련자들이 협의하여 소스를 머지한다고 해도 그것이 누적이 되면 어느 순간 관리는 물건너 가고 그 때 부터는 관리가 너무 힘들어지고 요청은 급해지고 악순환이 일어난다.  현재 중소규모의 IT프로젝트가 소스관리는 물론 리스크 관리가 잘 안되고 있다. 그들은 그 이유를 항상 요청된 시간이 늘 부족하다고 한다. 그 말은 틀린말은 아니지만 그렇다고 해도 문서관리, 소스관리 없이 작업해서 일정을 맞추는 경우도 거의 없다. 특히나 규모가 더 작은 웹쪽 작업는 더 말 할 것도 없다.

 

근본적인 문제들

일련의 문제들은 이미 다 잘 알려져 있다. 우리나라는 인구대비 IT와 직 간접으로 연관된 인력이 많다. 그러다보니 거의 모든 기업에 규모나 빈도에 상관없이 IT 프로젝트에 연관이 되어 일생 동안 몇 번의 IT 프로젝트를 직 간접으로 경험할 수 있고 IT인력은 아니지만 이미 여러 IT 프로젝트를 경험한 사람도 꽤 된다. 즉 여러 분야의 사람이 이미 그 문제를 경험했다는 것인데 더 문제는 그 문제점을 알지만 매번 프로젝트에서 규모에 상관없이 같은 문제(일정, 비용, 품질) 발생한다는 것이다.

이렇다면 문제는 구조적인 문제라도 판단을 할 수 있다. 어떤 구조의 문제인가? 책에서 저자가 다각도로 이 문제를 이야기 하고 있다.  우리나라에서 IT에 대한 정책적인 오류는 아이폰이 우리에게 알려준 교훈, 수평적 구조와 수직적 구조의 문제, 바로 그것이다. 우리나라에서 프로젝트를 한다는 것은 야근과 철야를 생각케 한다. 새 프로젝트에 들어갔다고 하면 친구들은 한 동안 이 친구를 못 보겠구나 하고 가족들은 얼굴보기 힘들겠구나 생각한다. 아이들은 아빠을 잠시 잊어버려야 한다. 반대로 누가 보자고 하면 프로젝트 끝나고 보자고 한다.

프로젝트가 무엇이관대 시작하면 개인시간을 다 뺴앗고 끝나면 인간으로 돌려 놓은 것인가?

프로젝트가 이럴진대 누가 프로젝트를 하고 싶을까? 회사를 나오기 힘들고 전업하기 힘들기 때문에 억지로 하는 거지 즐겁게 하는 일일 수가 없다. 누가 가족과 얼굴보기도 힘들게 일하면서 즐겁게 일하겠는가? 누가 밤샘하면 일하는 것을 좋아하는 가?

우리나라 기업은 그들이 의뢰하는 곳이던 의뢰를 받아 개발을 하는 회사던 판에 박은 듯 착각에 빠져있다. 두 가지 정도로 그 심각한 오해를 정리하자면

가. 소프트웨어는 누구나 만들 수 있다.
나. 시간이 없으니 일단 시작하고 보자  

이렇다.
이 문제들을 각각 살펴 보면  

첫 번째, 소프트웨어는 누구나 할 수 있다? 실제로 누구나 만들 수는 없다. 개발자들이 만드는 것이다. ㅋㅋㅋ 그런데 개발자면 다 만들 수 있냐하면 그렇지 않다. 대부분의 개발자는 선임 개발자의 사전 작업과 기획자의 가이드가 없다면 작업을 시작할 수도 없다. 그런데 일반적은 시각은 개발자만 다 만들수 있다라는 생각이 퍼져있다. 개발자들과 늘 부비는 PM인 필자가 볼 때 개발자들은 작게는 5개에서 크게는 몇 십단계와 직능별 분류가 가능하다. 각 단계와 직능별로 할 수 있는 개발과 할 수 없는 개발이 있다. 따라서 실제 프로젝트에서는 개발자 구성이 완벽하지 않으면 프로젝트가 망하게 된다. 개발에 대해 살짝 아는 이들이 안면있는 개발자 몇명에서 부탁해서 책상에 앉혀 놓는다고 사업이 완수 되는 것이 아니라는 이야기이다.  그런데 실제 사이트에 가보면 그걸 왜 개발 못하냐?, 왜 그렇게 오래 걸리냐? 라는 말을 하는 의뢰인들이 있다. 오죽 답답하면 그런 말을 할까 만은(그건 충분히 이해하고 있다.) 하지만 그런 태도로는 원만한 프로젝트를 수행하지 못한다. 그런 의식으로는 프로젝트 기간 중에 여러 상황에서 걸림돌만 만든다.

두 번째, 이 건 개발자나 개발사에서 범하기 쉬운 오류인데 클라이언트의 요구가 촉박하니 문서나 준비작업 없이 바로 코딩을 하자. 이런 식을 발상은 스스로를 파탄의 길로 밀어 넣은 것이다. 시간만 많으면 문서작업등 절차대로 하겠다 하는데 이미 문서 작업을 회피하는 습관이 들었다면 시간이 많다고 제대로 할까? 절대 그렇지 않다. 클라이언트의 요구사항 변경과 촉박한시간은 늘 있어온 문제이다. 그런 리스크가 감지된다면 프로젝트를 수주하지 않아야 하는 것이지 시간이 촉박하다고, 요구사항이 변할 것이니 문서작업 무시하겠다 하는 것이 직무유기이다. 문서 작업을 하는 것이 전체 일정을 줄이는 역활을 한다. 초기에 일정은 이상적인 일정이다. 현실적으로 제안 당시의 일정은 당연스럽게 1.5, 2, 3배 늘어난다. 늘어나는 이유는 여러가지 이지만 이 중에 주먹구구식의 개발이 큰 역활을 한다. 클라이언트의 요구사항 변경도 체계적인 개발작업 중이라면 수정 시간을 줄일 수 있다.

개탄스러운 것은 우리나라의 IT 개발은 이 두 가지 장애를 숙명처럼 안고 있다는 것이다. 실무에 대한 이해가 없이 비용과 기간이 정해진 프로젝트, 의뢰인이나 개발사나 구체적인 업무 정의 없이 하는 Kick off, 모든 걸 개발사에 맞겨버리는 안이한 의뢰인, 일단 일하고 수주하고 보자는 영업팀, 환경탓만 하는 개발자, 엔지니어의 의견을 무시하는 독선적인 경영자... 이들이 살아 남아있고 변하지 않는 한 우리나라의 IT는 언제 내리막을 걸을지 모른다.

 

벽이 허물어진 우물

우리나라가 아직 우물 안에 있었다면 지금까지의 방식으로 살아 남을 수 있고 몇 년을 건디어 낼 수 있을지 모른다. 하지만 암울한 기운은 이미 우리 주변에 내려 앉기 시작했다. 작년에 우리나라에 아이폰이 보급되면서 피쳐폰 시절의 수직적인 생산구조에 익숙한 우리나라 모바일 분야 아니 사회전체가 놀랐던 것이 사실이다. 스마트폰에서 구동되는 APP들은  잘 아는 것 처럼 하드웨어나 모바일서비스 회사가 아닌 각 개발주체가 주도권을 가지고 있다. 이 사건으로 많은 관련 종사자들이 희망을 가지고 되었다. 수평적인 개발 구조가 되면 지금은 열악한 개발 환경도 개선이 될꺼란 희망을 가진 것이다.

하지만 상황은 희망적이지만은 않다. 이미 우물의 벽은 허물어지고 우물 밖의 강물이 범람하여 우물에 흘러들고 있다. 조만간 우물이 강물에 덮힐 수 있는 상황인데 우리는 이제 수직적 구조의 맛을 보았다.  

 

우물 벽에 깔리지 않으려면

저자는 책의 마지막에 희망적으로 우리의 자세를 이야기 했지만 대세는 그렇지 않아 보인다. 다만 우물벽이 허물어지는 상황에서 각개 전투원이 살아 남기 위해서 저자가 책에서 제기한 문제점을 회피할 필요는 있다.
아니 살아 남으려면 반드시 그래야 한다. 

 

필자는 이 책을 잡자 마자 하루도 안되어 읽어 버렸다.
이렇게 시원 할 수가 있을까 저자는 마치 나를 보고 있는 듯 나의 이야기를 하고 있다. 나의 생각을 읽은 듯 문제점을 나열하고 해결 책을 제시한다. 그 해결책이 현실적으로 해결하기 어려운 과제라고 해도 동감을 하는 것 만으로 필자에게는 위안이 되었다.