LetMeLove 의 세상보기

2006년 12월 28일 한국소프트웨어산업협회는 SW산업진흥법에 따라 SW사업 대가기준으로 활용하는 'SW기술자 공인 노임단가'를 2007에는 2006년에 비해 평균 4.66% 인상토록 한다고 공표했다. 인상된 기준에 따르면 초급개발자는 월 740만원, 중급개발자는 월 930만원, 고급개발자는 월 1,170만원을 받도록 되어 있다. 국내에는 1,200개 소프트웨어 기업들이 존재하고 42,800명의 소프트웨어 기술자가 근무하고 있다고 한다. 그러나 IT 업계에 종사하는 사람들이라면 이 허무맹랑한 수치에 당황하지 않을 수가 없을 것이다. 이 수치가 어디에 실제로 적용되는 수치이며, 현실적으로 이 비용을 지급하거나, 받는 업체가 어디인지 궁금해하지 않을 수 없을 것이다.

2005년부터 시작된 개발자 구인난은 2007년에도 계속될 전망이다. 일부 기업들은 프로젝트를 수주하고도 개발자를 구하지 못해서 프로젝트를 진행하지 못하는 기업들까지 생기고 있다. IT 업계에 종사하지 않는 사람들이라면, 일단 이 엄청난 개발 단가에 놀랄 것이고 두 번째는 이런 비용을 받고도 왜 소프트웨어 기업들이 열악한 환경에서 일한다고 말하는지 이해하지 못할 것이다. 물론 가정은 이 비용이 현실 속에서 실제로 지급되는 비용이라면 그렇게 말할 수 있을 것이다.

소프트웨어 개발자 인력난
분야에 따라 차이는 있겠지만 실제로 중소 SI 업계에서 얘기하는 개발단가는 초급 350~450만원 중급 400~550만원 정도라고 본다면, 소프트웨어 노임단가와 얼마나 큰 차이가 있는지 알 수 있을 것이다. 물론 이 비용도 기업이 소위 말하는 ‘갑’이란 업체와 계약을 할 때 받는 비용이다. 문제는 소프트웨어 기업이 이 비용을 받고 프로젝트를 진행하기 위해서는 소위 말하는 영업비, 제경비 등이 추가로 발생하기 때문에 실제로 소프트웨어 개발자가 받는 비용은 이 비용의 6~70% 정도라고 봐야 할 것이다. 대충 계산해 보면 일반 사무직 직원들과 별반 차이가 없다. 하지만 소프트웨어 개발자들의 열악한 환경은 10년 전이나 지금이나 크게 개선된 부분이 없다는 것이다. 여전히 말도 안 되는 고객의 요구사항을 반영한다고 개발한 모듈 뜯어고치고, 밤을 새고, 주말에도 일해야 하는 구시대의 악습은 지금도 지속되고 있는 것이 현실이다.

젊을 때 고생은 사서도 한다고 한다. 그 이유는 미래를 위한 비전 때문이다. 그런데 고생만 하고 비전이 없다면 그 고생을 왜 해야 하는지 의문이 들 수 밖에 없다. 최근 몇 년 동안 소프트웨어 개발자의 타 업종으로 전직이 점차 늘어나고 있다. 그리고 매니저 급인 중급개발자들은 경력에 비해서 충분한 대우를 받지 못하고 혹사당하는 현실 때문에 일본이나 중국으로 대거 이동하고 있다. 특히 한국의 주변 국가들은 한국 개발자들을 선호한다. 실력도 뛰어나고 경험도 많고 책임감도 강하기 때문이다. 한국에서 받는 비용보다 더 많은 비용을 주고도 데려간다. 몇 년간 계속된 이탈로 인하여 현재 대한민국은 개발자 공동화가 가속화 되고 있다.

프리랜서만이 살길
더 큰 문제는 기업에 속해 있는 많은 개발자들이 프리랜서를 선언하고 있다. IT 업종의 특성상 열악한 환경을 개선할 수 없다면 돈이라도 많이 벌자는 생각에 속해 있는 기업을 퇴사하고 프리랜서로 직접 계약을 선호한다. 당연히 회사에 다닐 때는 월급 200만원 정도 받던 2~3년 차 개발자들이 최소한 350만원 이상을 받고 일한다. 5년 차 이상이 되면 450만원 정도를 줘야 구할 수 있다. 그나마 구할 수 있으면 다행이다. 450만원이면 연봉 5,400만원이다. 웬만한 대기업에서 10년 이상 근무한 과-차장급 수준이다. 프리를 선언한 사람들의 공통적인 생각은 어차피 비전 없는 직종에서 회사에 있는다고 비전이 생길 것도 아니고 열심히 프리랜서로 돈이나 많이 벌어서 나이 차면 장사나 하던지 타 직종으로 전직을 하자라는 생각을 한다.

모든 프리랜서들이 이런 생각을 하는 것이 아니겠지만 필자가 만나 본 나름대로 실력이 있다고 생각되는 프리랜서 개발자들에게 물어보면 이런 얘기들을 많이 한다. 프리랜서들의 가치관에 대해서 논하고자 하는 생각은 없다. 하지만 이런 비용으로 개발자들을 직원으로 채용할 수 있는 회사는 국내에 많지 않다. 더군다나 급여가 아닌 다른 확실한 비전을 제시할 수 있는 기업들도 많지 않다는 것이 더 큰 문제다. 그럼에도 불구하고 개발자를 구할 수가 없기 때문에 개발 수준은 해가 갈수록 떨어지고 개발 단가는 해가 갈수록 높아지고 있다. 소프트웨어 기업들 조차도 이제는 업종 전환을 준비하고 있다.

소프트웨어 기업은 없다
해가 갈수록 기업들의 IT 투자 비중은 높아지고 있다. 그러나 갈수록 소프트웨어 개발자는 줄어들고 있다. 이제는 그것도 모자라서 소프트웨어 기업들이 줄고 있다. 이런 악순환은 더 악화될 것으로 보인다. 기업들은 더 많은 IT 예산을 편성해야 하고 하지만 예전보다 더 수준 낮은 결과물에 만족해야 한다. 그나마 결과물이 나오기라도 하면 다행이다. 6개월 프로젝트가 9개월 12개월이 되기가 십상이다. 국내 개발자가 부족해서 베트남, 인도 등에서 개발자를 수입해와야 하는 실정이다. 대규모 프로젝트는 아예 외국 기업에 거액을 주고 맡겨야 한다. 그렇다면 과연 문제의 원인은 무엇인가?

필자의 경우 2005년 10월에도 유사한 내용으로 IT 업계를 떠나는 개발자에 대해서 컬럼을 쓴 적이 있다. 그러나 그 이후 이러한 현상은 더 악화되었고 앞으로도 큰 희망이 보이지는 않는다. 외환위기 이후에 정부정책에 따라서 수많은 소프트웨어 벤처기업이 생겨나고, 수많은 개발자들이 양성되었다. 당연히 출혈경쟁을 통해서 기업들은 보다 싼 기업들을 찾았고, 덤핑이 난무하게 되었다. 마치 70년대 건설업계의 악몽이 되살아나는 듯하다. 당시에는 수많은 건설업체들이 생겨나고 덤핑을 통해서 수주를 하다 보니 부실공사가 한 두 곳이 아니었다. 결국 수많은 중소건설업체들이 망하고 많은 건설업계 종사들이 업계를 떠나게 되었다. 이후 10년이란 암흑기를 지나서야 다시 건설업이 살아나게 되었다. 지금의 소프트웨어 업계가 암흑기를 맞고 있는 듯하다. 저렴한 비용에 IT 프로젝트를 발주했다고 좋아했던 대기업들은 지금 그 후유증으로 2차 3차 고도화를 1차 비용의 몇 배를 주고서 다시 하고 있다. 잘 못 끼워진 단추를 다시 끼우는 데는 앞으로도 수년의 시간이 더 소모 될 것이다.

지금부터 다시 시작하자
가장 시급한 문제는 잘못된 관행을 바로 잡는 일부터 시작해야 한다. 특히 ‘갑’과 을의 관계에서 기술이나 능력을 무시한 채 무조건 싼 곳을 선택하는 기존 입찰 제도부터 변경해야 한다. 결국 기술과 능력을 정확하게 볼 수 있는 눈과 귀가 열려 있어야 하는데, 역시나 이 부분에 대한 기준이 명확하지 않다는 것이 문제일 것이다. 특히 기업들이 자신의 회사의 이해타산에 맞춰서 개발업체를 선정하겠다는데 정부나 기관에서 간섭할 수 있는 부분도 아니다. 결국 기업 스스로가 그러한 기준을 만들어 갈 수 있도록 마인드가 바뀌어야 하며, 정통부 같은 정부기관에서는 이러한 기준에 대한 가이드를 제시해 줄 필요가 있다.

그 동안 관행이었던 덤핑 입찰에 대한 개발업체의 영업관련 대표들의 마인드도 바뀌어야 한다. 무조건 수주하고 보자 라는 생각은 결국 자신의 회사의 수명을 단축할 뿐이다. 아무리 배고파도 내년에 농사지어야 할 씨앗까지 먹어버려서는 안 된다. 결국 막무가내 식 영업이 아니라 개발 회사 스스로가 특화되어야 한다. 특화된 분야에서 전문성을 가지고 영업을 해야지만 제대로 된 비용을 받고 일할 수 있다. 개발자는 건설현장에서 그 때 그 때 구할 수 있는 일용직이 아니라 해당 분야에 전문가 임을 잊어서는 안 된다.

프리랜서로 전향하는 개발자를 탓하기 이전에 우리나라 IT 환경이 개발자들에게 안정된 직업이라는 인식을 심어주지 못한 부분을 탓해야 한다. 환경이 바뀌지 않으면 그 안에 속해 있는 멤버들의 마인드도 바뀌지 않는다. 제대로 된 발주업체와 수주업체와의 관계만이 이러한 환경을 개선 할 수 있으며, 그래야만 상생을 할 수 있다. 지금의 환경은 서로가 서로를 좀 먹고 있을 뿐이다. 소프트웨어 업체와 개발자들이 제대로 인정받고 살 수 있는 시대가 언제쯤 올 지 요원하기만 하다. 대한민국은 더 이상 IT 강국이 아니다. 개발자가 전문직 종사자로 인정받는 시점이 될 때 우리나라 IT는 다시 시작할 수 있을 것이다.@

[박민우(디아이지커뮤니케이션 이사) ]

요즈음 ActiveX, 정확히는 'ActiveX 컨트롤'이란 기술이 시끄럽다. 브라우저 밑으로 손을 뻗어 그 밑에 깔린 시스템의 기능을 만지작거릴 수 있게 하는 요물. 웹은 웹이로되 PC가 할 수 있는 모든 일을 하게끔 하는, 웹을 웹 이상으로 조작하기 위한 '만능 컨트롤' 도구, ActiveX. 90년대의 프로그래머들은 ActiveX가 포함된 COM이라는 테크놀로지 조합으로 PC 전성기를 풍미했다.

그런데 새 버전의 인터넷 익스플로러와 새 OS 윈도우 비스타는 자신들의 기술 ActiveX를 유리 상자 안에 가둬 버리고 만다. ActiveX란 뭐든지 만들 수 있지만, 뭐든지 망칠 수도 있는 양날의 검이었다. 새 플랫폼이 ActiveX에 거리를 두는 이유는 '시스템의 기능을 만지작거리는 일'이 악인에 의해서도 자행될 수 있다는 자각 때문이다. ActiveX는 모두가 순박했던 목가적 시절에나 어울리는 기술이었던 것이다.

게다가 이미 업계는 웹을 임의로 '컨트롤'하여 변경하는 일이 그리 바람직한 일도 아님을 공감하고 있다. 웹 표준 운동도 그 일환이다. ActiveX같은 로우레벨 아키텍처에 의존한 플랫폼을 만드는 일이란 플래시 수준의 입지를 지닌 플랫폼 제공자가 아니라면 비즈니스적으로도 별 의미가 없다는 것을 깨달았다. 마치 고급 언어를 배운 이래 어셈블리어를 만질 필요가 없듯, 굳이 웹을 개선한다는 목적만으로는 ActiveX라는 위험한 칼을 만질 이유가 없는 것이다.

물론 아이디어란 표준으로 묶어 놓기에는 너무나 자유분방한 것이기에, 올해도 내년에도 웹의 확장은 일어날 것이다. 그렇기에 웹을 초월한 무언가를 덧붙이려는 확장 욕구는 건전한 것이다. 브라우저로 하지 못하는 일을 새로운 아이디어로 '확장'하려는 욕망은 멈추기 힘들고, 이 점을 강조하기 위해서 일까? 파이어폭스가 ActiveX '컨트롤(Controls)'을 금지하고 대신 파이어폭스 '확장(Extension)'이란 개념을 도입한 의도는 그 용어에 잘 나타나 있다. 마이크로소프트도 이미 닷넷을 중심으로 기술 구조를 재편한지 오래다. ActiveX를 위시한 Win32의 리거시 기술들은 배후로 밀려나고, 웹의 확장 기능도 ActiveX라는 칼을 직접 만지지 않도록 유도하고 있다. 더 편하고 더 쉬운 확장을 할 수 있는 방안과 로드맵이 따로 있는 것이다.

그러나 우리는 유난히 ActiveX라는 날카로운 칼을 좋아했다. 그리고 무척이나 잘 드는 이 칼로 웹을 확장한 것이 아니라 오히려 웹의 여기저기를 도려내며 우리만의 아키텍처를 만들었다. 대한민국의 웹을 서핑하다 만나게 되는 수 없는 경고창들, 칼을 조심하라는 시스템의 경고지만 개의치 않는다. 수저가 필요한 곳에 칼이 놓이고 있다. 손잡이가 필요한 곳에 날이 서 있다.

칼날이 난무한다. 특히 은행 일이라도 한번 보려면 여러 개의 컨트롤을 일단 깔아댄다. 뭐가 뭔지 도무지 모르겠지만, 여하튼 설치하지 않으면 아무 것도 못하니 방법이 없다. 게다가 왜 이렇게 회사마다 종류가 골고루인지. 그렇게 내 PC를 유린하듯 설치되는 컨트롤의 면모는 살펴 보니 하나 같이 '보안 모듈'.

여기에서 의문이 생긴다. 왜 보안을 웹의 외부 기능에 의존해야 하는 것인가? 사실을 말하자면, 한국 수준의 보안은 모르겠으나 적어도 세계 수준의 보안은 브라우저 만으로도 얼마든지 확보할 수 있다. 외국 굴지의 은행들은 브라우저만으로 인터넷 뱅킹을 무리 없이 수행하고 있다. IE와 파이어폭스 모두 필요 충분한 수준의 암호화 기능은 물론 인증서 관리 기능도 들어 있다.


그런데 한국은 세계에서 통용되는 이러한 표준 기능은 활용하지 않은 채, 보안을 웹의 외부 기능으로 빼내어 독자적으로 처리하고 있다. 놀라운 기술 독립이다. 마이크로소프트도 모질라 재단도 놀라고 있는 일이다. 그들은 이해를 못하는 일이다.

왜? 도대체 왜 이 상황이 된 것일까?

여러 가지 도시 전설이 횡행하지만, ① 당시 미국의 128비트 암호화 수출 금지 조항에 맞선 독자 기술(SEED)의 개발과 적용 지도, ② 한국의 특수 상황이 발생시킨 정보 기관의 지침(보안 적합성 검증), ③ 독자적 최상위 인증 기관 운영 욕구, ④ 해킹 피해 발생 보도에 대한 과민 반응. 등이 복합적으로 작용했다는 설이다. 인터넷이 너무 일찍 퍼진 한국은 너무 급했고 너무 불안했던 것이다.

이 과정에서 얻은 일도 있을 것이다. 내수 보안 산업이 자생적 생태계를 꾸릴 수 있었다. 척박한 국내 IT 시장에서 나름대로 고용을 창출하고 기술을 연마해 온 그들에게 과연 “당신들의 존재 자체가 틀렸어!”라고 감히 말할 수 있을까? 누구도 그럴 용기가 없다. 완전한 기술 쇄국을 이끈 정부도 금융권도 IT 업계도 국민도 어느 누구도.

그러나 잠시 스스로를 돌아 볼 때다. 우리는 정말 세계 어느 나라보다 안전할까? 인증서 파일을 PC에서 PC로 옮겨 들고 다니는 일이 과연 최고의 보안 솔루션일까? 다른 나라처럼 암호 발생 카드나 암호 발생 열쇠고리를 사용하는 것이 차라리 안전하지 않을까? 전세계적으로 테스트되고 사용되고 있는 브라우저 들의 내부 보안 기능보다, 버그가 있을 수 있는 개별 기업의 외부 보안 솔루션이 더 안전하다고 우리는 진정 믿을 수 있을까? 우리에게는 잠시 쉬어가며 백지에서 다시 생각해 볼 여유가 필요한 것이다.

ActiveX의 문제란 결국 독자 기술의 꿈이 불러 온 기술 쇄국의 딜레마였던 것이다.

사실 아무 일도 아닐 수도 있다. 쇄국의 아키텍처를 끝까지 고수하며 업체를 압박한다면 어떻게든 솔루션은 생길지 모른다. 그러나 언제까지 그렇게 아슬아슬한 아키텍처를 우리는 가져갈 수 있을까? 새로운 OS가 등장할 때마다, 새로운 브라우저가 등장할 때마다 우리는 '우리의 실정'을 부르짖어야 할 테니까.

기술은 도구인 이상, 양날의 검이다. 잘 쓰면 유용한 도구이지만 목적을 잊은 채 수없이 주머니에 품고 있기에는 거북한 존재인 것이다. 잘못 들어가 있는 칼은 서서히 걷어내야 한다. 그리고 그 칼의 사용은, 그리고 더군다나 민생에 직결되는 서비스에서의 사용은 더 신중히 논의되어야 하는 것이다.

칼을 드는 순간, 내 스스로 누군가를 소외시키지는 않는지, 그리고 그 칼을 드는 순간 내가 세상으로부터 소외되지는 않은지 생각해 봐야 한다. 도구의 의미를 생각하지 않은 채, 용도를 숙고하지 않은 채, 도구의 방향을 관찰하지 않은 채, 도구를 본래의 취지와 맞지 않게 남용하는 것이 얼마나 무모한지 우리 사회는 그리고 업계는 어쩌면 매우 비싼 값을 치르며 배우고 있는 것인지도 모른다.

김국현(IT평론가)