작년 12월 29일 토요일에 스마트플레이스에서 주최한 제5회 난상토론회가 있었다. 날짜한번 너무 도발적이어서 과연 얼마나 참가할까 생각했는데 가보니 꽤 많이 참석했다. 누구 이야기로 할일없는 블로거들이 죄다 모였다고 할 정도였으니(^^). 그날은 날씨도 무지 추웠는데 말이다(참고로 집으로 돌아갈 때 꽤나 고생했다. 추워서).


이번에는 문화관광부가 후원을 한거 같다. 그 외에도 많은 기업에서 스폰서를 받은듯 싶다. 난상토론회는 이런게 되는듯 싶다(역시 규모가 크니).


4회때는 아이스브레이크때 너무 시간을 많이 잡아먹어서 토론을 한번만 했는데 이번에는 두번으로 나눠서 했다. 1부때 토론과 2부때 토론이 다르며 토론 참가자들도 다르게 정해지는 방식이다. 덕분에 2가지 주제로 토론할 수 있어서 좋았다.

1부때의 토론 주제는 웹2.0과 수익모델에 대한 내용이다. 블로그를 비롯한 웹2.0 서비스들의 수익모델에 대한 이야기와 한국에서 웹2.0 수익모델을 적용할 수 있는가에 대한 내용에 대해서 토론을 했다. 토론 참가자들은 현재 일주일이 지난 상태인지라 기억이 나지 않는다(-.-).

웹2.0 서비스들의 주요 수익모델이 온라인 광고라는 인식은 모두들 비슷한 듯 싶다. 구글 애드센스나 다음 애드클릭스 등과 같은 수익모델 프로그램을 이용한다던지 아니면 자체적인 광고 프로그램을 이용해서 수익을 올린다던지 어떤 방식을 사용하던간에 웹2.0 서비스들의 대부분의 수익구조는 온라인 광고 프로그램이라는 것에는 대부분 다 동감을 했다. 그리고 그와 동시에 최근 구글이 애드센스 적용범위 축소로 인해 수익이 많이 줄어들었다는 얘기도 했고 광고 이외에 기본 서비스 이외에 프리미엄 서비스를 이용한 수익모델에 대한 이야기도 나눴다. 플리커 등에서 적용하고 있는 프리미엄 계정 구입 등의 방법 말이다. 국내 서비스 중에서 잡코리아 등이 이력서에 대한 자세한 내용을 노출시키기 위해 프리미엄 계정을 사용하는 얘기도 했다. 이렇게 웹2.0에 대한 수익모델이 주로 온라인 광고와 서비스의 차별화로 양분되고 있는 상황이다.

그런데 국내에서는 이러한 웹2.0 수익모델을 제대로 적용하기 어렵다고 한다. 아니 수익모델이 아닌 웹2.0 서비스 자체를 내놓기가 겁난다고 한다. 바로 포탈사이트들 때문이라고 한다. 새로운 서비스를 내놓고 수익모델을 적용하고자 할때 포탈사이트들이 비슷한 컨셉의 서비스를 만들어서 무료로 제공하니 경쟁이 될 수 없다는 것이다. 사용자 입장에서는 비슷한 서비스라면 유료보다는 무료 서비스를 이용하기 때문이다. 이러한 문제 때문에 신규 서비스를 만들어서 내놓기가 어렵다고 말한다. 국내 인터넷 사용환경이 포탈사이트 중심적이 되다보니 나타나는 안좋은 현상인 것이다.

그래서 이런 이야기들이 오갔다. 새 서비스를 만들어서 시장을 형성하고 그 서비스를 포탈사이트 업체가 인수하도록 하는 것이다. M&A를 통해서 기업이 돈을 버는 방법을 취하자는 것이다. 미국의 많은 웹서비스 회사들이 구글이나 야후에 인수되기 위해 서비스를 만들어서 시장을 형성하고 PR하는 경우가 많다. 구글에 인수되기 위해 서비스를 만드는 회사들도 존재한다. 그것을 한국에 적용하자는 이야기다. 그런데 그것도 쉽지는 않은게 포탈사이트에서 그 회사의 서비스를 인수하지 않고 돈을 들여서 개발한다면 의미가 없어진다는 얘기도 나왔다.

구글 애드센스나 다음 애드클릭스와 같은 수익모델 프로그램에 대한 이야기도 나왔다. 국내에서 애드센스와 애드클릭스의 성장이 더딘 이유는 구글과 다음의 인지도가 네이버에 비해 턱없이 낮기 때문이다. 광고주 입장에서는 네이버에 광고하는 것이 훨씬 유리하지 구글이나 다음에 광고하는 것은 투자대비 수익이 잘 나타나지 않는다고 생각하는 것 같다. 그렇다면 반대로 네이버가 직접 애드센스나 애드클릭스와 같은 수익모델 프로그램을 만드는 것은 어떨까 하는 생각도 해봤다. 이에 대해서는 나중에 좀 자세히 써볼까 한다.

이렇게 1부가 끝나고 바로 2부 토론으로 옮겨졌다. 2부 토론의 주제는 한국에서의 프로그래밍이 즐거운가에 대한 것이다.

좀 암울한 이야기가 될듯 했고 역시나 그렇게 이야기가 진행되었다. 국내 IT 개발환경이 상당히 열악하다는 것은 대부분의 개발자들은 다 아는 사실이다. 한국 IT의 기반이 SI라는 사실은 국내 IT 환경이 상당히 기업 중심으로 되어있다는 얘기며 그 SI의 현실이 어떤가에 대해서는 참으로 우울하기 짝이 없다는 얘기가 나왔다(물론 절반 이상을 내가 얘기한거지만).

국내 SI 환경이 현재의 모습이 갖춰지기까지는 7~80년대 한국경제성장을 주도했던 세력들이 건설업 계열이었고 그때 시행되었던 관행들이 지금의 IT 환경, 특히 SI쪽에 흡수되었기 때문에 하도급 형식으로 SI가 진행되고 있다는 것이다. 갑, 을, 병, 정 등으로 등급이 나뉘며 내려갈수록 받는 금액도 차이가 나고 또 돈줄을 쥐고 있는 갑의 횡포와 그 갑에 맞출려는 을의 무리한 일정조정 등의 이야기가 나왔다. 그리고 프로젝트 진행중에 자주 바뀌는 갑의 요구사항과 그에 대한 미흡한 후속조치에 대한 이야기도 나왔다. 프로젝트가 진행되는 도중에 설계가 바뀌게 된다면 앞서 진행했던 시간만큼 더 추가를 해야하며 그에 맞는 금액도 지불해야 하는데 중간에 바뀌더라도 예정했던 기간안에 끝내야 하는 국내 SI 현실 때문에 개발자들은 죽어난다는 이야기도 했다. 갑의 비위를 맞출려는 을의 무리한 프로젝트 진행때문에 그 밑의 병, 정에 해당하는 업체들만 죽어난다는 것이다. 나 역시 SI에서 대략 3년가까이 했었기 때문에 그 상황을 잘 안다. 솔루션 개발업체에 있는 사람들이 부럽게 느껴진다고나 할까. 현재는 솔루션 개발쪽이라(그래도 절반은 SI지만) 좀 사정이 낫지만 솔루션 개발도 그리 SI에 비해서 나은 것은 많지 않다.

같이 토론한 사람들 중에는 개발자를 꿈꾸는 사람도 있었는데 괜히 겁만 잔뜩 준거 같아서 아쉽기는 했다. 하지만 현실이 그러하니 알고 결정하는 것이 좋겠다 싶었다. 여하튼 암울한 이야기로 2부 토론도 끝냈다.

토론이 끝난 후 토론 결과 발표의 시간이 있었다.


다른 토론 조들은 재미난 토론주제로 토론을 했나보다. 나는 두 토론주제 모두 좀 암울해서 그랬지만 말이다.

난상토론회가 끝난 후 저녁식사를 했는데 출장뷔폐를 부른듯 싶었다. 자리가 좀 불편했지만 먹는것은 나쁘지 않았다.

4회때도 그랬지만 블로거들의 토론은 정말 재미난거 같다. 다양한 주제로 다양한 사람들과 만난다는 것은 늘 즐거운 일이다. 블로그로 자기 명성을 쌓아서 제법 성공한 사람들도 존재한다. 나 역시 그렇게 되기를 바라지만 너무 욕심은 내지 않고 싶다. 다음 6회때를 기대한다.

* 관련글 *
2007/12/03 - [IT Story/웹 2.0] - 제4회 스마트플레이스 IT 난상토론회 후기
2008/01/02 - [개인] - 2008년을 시작하면서

 내가 회사에서 메인으로 사용하고 있는 컴퓨터 언어는 C언어다. 가끔 C++을 사용하기도 하고 윈도 프로그래밍을 할려면 MFC나 Win32 API를 이용한 프로그래밍도 한다. 그렇다 하더라도 내 메인 컴퓨터 언어는 C언어다. 이게 내 밥줄이며 내 기술이다. 이것 덕분에 지금까지 그나마 회사에서 잘 써먹고 있는 것이라 생각이 든다.

요즘들어 웹2.0에 관심이 많아져서 관련 글들도 블로그에 쓰고 관련 자료들도 인터넷을 통해서 이리저리 찾아보기도 하고 포럼이나 세미나에도 가끔 참석해서 주변 지식을 넓히고 있는 상황이다. 그런데 계속적으로 웹2.0에 대해서 공부하면서 느끼는 점은 지금 내가 하고있는 일과는 전혀 매치가 안되고 있다는 것이다.

웹2.0은 말 그대로 웹이다. 인터넷의 한 종류인 웹은 이제는 아예 인터넷을 대표하는 기술이 되어버렸다. 그만큼 웹이 크게 성장했다는 뜻이다. 이 웹이라는 녀석을 다루다보면 자주 등장하는 것이 웹 페이지, 웹 사이트며 이 웹 사이트를 구성하고 있는 웹 언어들이 존재한다. HTML이라 불리는 웹 페이지 문서 언어와 ASP, PHP, JSP라 불리는 웹 스크립트 언어가 그것이다. 그리고 요즘은 웹2.0이 뜨면서 XML과 AJAX가 웹 언어의 대세를 이끌고 있다고 본다.

그리고 웹2.0의 중심에는 Java(자바)라는 언어가 있다. 이 자바는 1990년대 중반에 선마이크로시스템(이하 Sun)에서 만든 오브젝트 중심의 언어(이하 OOP)다. C++이라는 OOP의 연장선상에 있다고 봐도 좋을 것이다. JVM이라 불리는 자바 가상 머신 위에서 동작을 하며 어떤 플랫폼(OS, Computer 모두)에서도 JVM만 있으면 다 돌아가겠끔 만든 것이 바로 자바다. 지금으로부터 대략 10여년전에 만들어진 언어니 10년정도의 역사를 지니고 있다고 본다.

자바는 2000년대초에 한번 크게 붐을 이뤘다. 닷컴 열풍이 몰아친 그 때에 자바 애플릿과 자바스크립트라 불리는 자바 언어(솔직히 애플릿은 자바라고 말하기 좀 그렇다고 생각한다. 그래도 구성 자체는 자바로 되어있으니 자바의 한 종류라고 하자)가 웹 페이지의 디자인 부분을 맡으면서 자바를 이용한 많은 웹 서비스 프로젝트들이 붐을 이뤘다. 그래서 한때 확 떴다가 2002년 이후로 좀 세력이 떨어진다. 닷컴버블이 사라진 이후 웹에 대한 환상이 깨지고 그와 동시에 자바에 대한 환상도 깨진 것이다. 그래서 풀죽어있는채로 있다가 2004년 하반기부터 다시 자바가 뜨기 시작했다. 그것은 MS가 C#이라는 자바와 비슷한 성질의 언어를 발표했을 때와 비슷하다. MS는 .NET이라는 자바의 JVM과 비슷한 플랫폼을 만들고 그 위에 C#이라는 언어를 사용해서 어떤 플랫폼에서도 사용할 수 있는 언어를 발표했다(그렇다 치더라도 MS OS군에서만 돌아가는 C#은 자바에 비할바가 못된다). 그때와 동시에 자바도 다시 부활했다고 본다.

웹2.0이 붐을타고 일어나서 전세계를 강타했고 그 중심에는 XML과 더불어 AJAX라는 기술이 있었다. AJAX는 Asynchronous JavaScript and XML의 약자로 비동기형 자바스크립트와 XML이라는 뜻인데(그냥 직역이다) 역시 자바로 구성되어있는 것이 특징이다. AJAX의 확산으로 인해 자바는 다시 부활하게 된다. 즉, 내가 요즘 관심을 갖고있는 웹2.0의 중심에는 자바가 있었다는 얘기다. XML도 자바와는 잘 붙는다고 한다.

왜 이런 이야기를 하는가 하면, 내가 사용하고 있는 C, C++ 언어는 말 그대로 시스템 언어들이다. C언어는 서버 프로그래밍을 할때나 아니면 임베디드 프로그래밍(휴대폰이나 PMP, PDA 등의 기기의 펌웨어 프로그래밍 등)에서 많이 쓰이고 있다. C언어가 고급 언어이면서도 어셈블러와 같은 저급 언어의 성질도 같이 갖고 있어서 임베디드 프로그래밍을 할 때 유리하기 때문이다. 서버 프로그래밍도 마찬가지다. C++과 같은 OOP 계열 언어를 쓰면 아무래도 퍼포먼스에 있어서 좀 떨어지기 때문에 C언어를 많이 쓴다. 그러나 C, C++로는 웹2.0 시대에서 제대로 밥 벌어먹기 힘들다는 얘기를 많이 듣는다. C, C++언어는 웹 언어가 아닌 철저하기 플랫폼에 의존적인 언어이기 때문이다. 그 얘기는 윈도에서만 돌아가는 프로그램이라던지, Linux에서만 돌아가는 프로그램이라던지, 이런식으로 OS에 철저하게 의존적인 프로그램만 만들 수 있다는 얘기다. 여러 플랫폼에서 돌아가게 할려면 각 플랫폼 별로 컴파일을 새로 해야하는 불편함이 있다. 웹 언어들은 플랫폼에 상관없이 웹 브라우저만 존재하면 어디서든 구동되는 프로그램을 만들 수 있다. 웹 사이트가 그 대표적인 예다. 물론 ActiveX 등의 기술을 사용하면 윈도에 Internet Explorer에서만 돌아가겠지만 그런거 안쓰고 순수하게 웹 스크립트 언어를 사용하면 어떤 플랫폼에도 관계없이 구동되는 웹 프로그램을 만들 수 있다. 그리고 나는 그 중심에 자바가 있다는 사실을 깨달았다.

요즘 자바 프로그래머들을 많이 찾고 있다. 한때 자바가 선풍적으로 인기가 있었을 때 자바 프로그래머들이 많았는데 닷컴버블 이후 자바의 인기가 뚝 떨어지자 자바 프로그래머가 많이 윈도 프로그래머로 돌아섰다. 그 얘기인즉 자바 대신에 MFC, WIn32 API등의 윈도 프로그래밍을 선택했다는 얘기다. 혹은 웹 프로그래머로 돌아섰다. 진정한 자바 엔지니어가 아닌 그저 자바 스크립트 정도만 만들 수 있는, 애플릿 정도만 만들 수 있는 그런 수준의 프로그래머로 돌아간 것이다. 물론 자바 스크립트나 자바 애플릿을 만드는 것이 하찮은 일은 아니다. 그것도 나름대로의 영역을 가지고 있으며 웹 사이트에 있어서 중요한 요소라고 생각한다. 하지만 좀더 깊은 수준까지는 못가는 것이 안타까울 뿐이다. 자바 프로그래머들은 자바 애플릿이나 자바 스크립트를 만들 수는 있지만 자바 애플릿이나 자바 스크립트만을 만들 수 있는 웹 프로그래머는 자바를 이용한 다른 응용 프로그램을 만들 수는 없다. 그래서 지금에 와서 자바 프로그래머들을 많이 찾는데 그러한 자바 프로그래머가 많이 부족한 상태다. 그만큼 단가도 많이 올라갔다.
나도 내가 갖고있는 C, C++ 기술로 어느정도 인정은 받고 있지만 솔직히 내 값을 제대로 평가받지 못하고 있다고 생각하고 있다. 그리고 내가 원하는 프로그래밍을 못하고 있다는 생각이 든다. 향후에 IT를 이끌것은 웹이라고 생각한다. 닷컴버블때와 같은 그러한 웹이 아닌 실제로 웹2.0에서 얘기하는 그러한 기술들이 접목된 웹이 IT를 주도할 것이라고 생각한다. 웹2.0의 선두주자인 구글은 자바를 가장 잘 이용하는 서비스중 하나다. 구글의 모든 서비스는 AJAX로 이루어져 있다고 한다. 그리고 IBM과 같은 회사는 아예 정책적으로 자바를 밀어주고 있다. Sun은 자기네들이 만든 언어니 말할것도 없다. 웹을 다루는 모든 서비스에는 지금 자바가 그 중심에 있다고 본다. 그리고 결정적으로 금융권에서는 모든 서버단은 다 자바로 이루어져 있다. 모든 웹 스크립트 언어중 JSP가 가장 보안성이 뛰어나기 때문이다. JVM 위에서 돌아가는 JSP는 JVM이 외부와의 연결을 제어해주기 때문에 보안성이 뛰어나다고 알려져있다. JSP 역시 자바로 구성되어 있음은 말할것도 없다. 이렇듯 자바는 지금 여러분야에서 중추적인 역할을 하고 있다.

내가 이 글을 쓰는 이유 중 하나는 내가 처음부터 C를 선택하지 않고 자바를 선택했으면 지금의 이 길이 아닌 어쩌면 웹2.0의 중심에 있었을지도 모른다는 생각과 지금보다는 좀 더 나은 생활을 하고있지 않을까 하는 생각이 들었기 때문이다. 나는 메인이 C, C++이기 때문에 내가 선택할 수 있는 직업의 범위가 제약이 있다고 본다. 자바도 물론 그렇다. 하지만 자바는 C, C++보다는 그 선택의 폭이 더 넓다. 그리고 좀 더 비싼 가격으로 채택될 수 있다는 점이 나를 가슴 아프게 한다.

물론 C, C++을 이용해서 시스템 프로그래밍을 하는 것과 요즘 인기를 끌고 있는 임베디드 프로그래밍을 하는 것도 매력있고 재미난 일이다. 하지만 시스템 프로그래밍과 임베디드 프로그래밍은 그 수효가 적다. 응용 프로그램쪽이 더 많은 사람을 필요로 하기 때문이다. 희귀성은 있을지 몰라도 다양성이 없는 것이 아쉽다. 윈도 프로그래밍도 마찬가지라 본다. 요즘 모든 엔터프라이즈 서비스들이 응용 프로그램 분야에서 웹 프로그램으로 돌아가고 있고 그 중심에는 자바가 있다는 것이 나를 갈등하게 만든다.

현재 회사에 자바 책을 갖다놓고 조금씩은 보고있다. 예전에 잠깐 공부한 적도 있고 그래도 C, C++을 다룬지가 벌써 10년정도 되었기 때문에 자바를 습득하는 것은 그다지 어렵지 않다고 본다. 다만 아쉬운 점은 자바로 프로젝트를 한 경험이 전무한 나로서는 실전에서 자바를 제대로 잘 쓸수가 있을까 하는 두려움을 갖는 것이다. 친구녀석이 일단 소규모 프로젝트를 같이 진행해보자고 해서 나름 생각하고 있다.

지금에서 주종목을 바꾼다고 해도 의미는 없을 것이다. 그래도 무기를 하나 갖고 있을 필요는 있다고 생각한다. C와 C++을 이용해서 언제까지나 계속 프로그래밍을 하기에는 한국이라는 시장은 너무 많은 것을 요구하기 때문이다. 열심히 노력하는 수 밖에 없다는 생각이 든다.

ps) 오래전에 쓴 글인데 스프링노트에 저장해뒀다가 이제야 마무리한다. 그런데 그때 생각했던 내용과는 좀 틀리게 쓰인거 같다. 전체적으로 다시 정리할 필요가 있을 듯.

ps2) 그렇다고 해서 내가 C나 C++을 폄하하는 것은 아니다. 지금 내가 사용하고 있는 주요 언어가 바로 C고 C++이다. 리눅스에서건 윈도에서건 말이다. 다만 자바도 C나 C++처럼 잘 다뤘으면 하는 생각에서 써봤다.

ZDNet Korea에서 본 류한석씨가 쓴 칼럼이다. 일단 내 마가린에 북마크 해뒀고 IT 개발자라면 정말 공감할만한 내용이라 생각이 든다. 이 글을 바탕으로 뭔가 쓸려고 했는데 워낙 글이 깔끔해서 따로 쓸 내용이 없다. ZDNet Korea 서버가 또 언제 죽을지 몰라서 내 블로그에 그냥 옮겨본다. ZDNet Korea 홈페이지에 저작권 이야기는 없는 것으로 봐서 퍼와도 괜찮을듯 하다. 나중에 문제가 생기면 지워야겠지만.

한국에서 SW 개발자가 성공하지 못하는 세가지 이유 (ZDNet Korea)

소프트웨어 개발자 직종에 대한 회의론적인 얘기가 여기저기에서 들린다. 한때 IT 붐이 일었을 때는 많은 사람들이 개발자를 지망하기도 했다. 하지만 최근 상황을 보면, 신규 유입되는 인력이 아주 적은 편이다. 요즘 젊은이들은 영악해서 이 직종에 비전이 없다는 것을 너무나 잘 알고 있다.

신참 인력뿐만 아니라 고급 인력도 많이 부족하다. 현재의 사회 풍토에서 고급 인력으로 성장하는 것은 결코 쉬운 일이 아니기 때문이다. 그저 사회가 제시하는 길을 따라가다가는 고급 인력이 되는 것이 아니라 퇴출된다.

필자의 경우를 보면, 필자는 정말 프로그래밍이 좋아서 시작한 8비트 키드이다. 중학교 1학년 때 처음으로 컴퓨터를 알게 된 이후로 한시도 컴퓨터와 떨어진 적이 없는 소위 컴퓨터광(geek)이다. 하지만 대학 졸업 후 사회에 나와 첫 직장인 SI 업체에서 일하면서 몇 번이나 눈물을 흘렸다. 이후 프리랜서, 개인회사 창업, 벤처기업, 중소기업, 대기업, 외국계 기업을 두루 걸치면서 현재까지 겨우 살아남을 수 있었다.

만일 그런 인생의 순간순간에서 이를 악물고 분발하지 못한 채 끈을 놓아버렸다면 어땠을까? 정말 아찔한 생각이 든다. 특유의 헝그리 정신으로 인해 겨우 버텼으며 성격도 많이 변했다. 그간 필자 자신 그리고 선배, 동료, 후배들을 보면서 느꼈던 생각을 정리해서 개발자가 성공할 수 없는 이유 세 가지를 꼽아 보았다.

SI 중심의 왜곡된 업계 구조
첫째, 업계 구조가 SI 중심으로 왜곡되어 있다. 국내의 소프트웨어 산업은 패키지나 솔루션 비즈니스가 제대로 작동되지 않는 상태에서, 대기업 중심의 SI 업체들이 시장을 차지하고 있다. 그 과정에서 산업의 혈액 순환이 잘 되지 않아, 대기업만 돈을 벌뿐 중소기업들은 협력 업체라는 미명 하에 근근이 먹고 살고 있는 형편이다. 통계에 따르면 전체 매출의 80% 이상을, 그리고 영업 이익의 90% 이상을 대기업 계열 SI 업체 상위 3개사가 가져가고 있다.

SI는 소프트웨어 산업을 구성하는 한 가지 요소일 뿐이지만 국내에서는 거의 SI 밖에 없는 수준이다. 그런 상태에서 빅3업체가 모든 것을 가져가고 있으며, 산업 전반에 하청 및 재하청에 따른 죽음의 순환 고리를 형성하고 있다. 그런 생태 구조에서 개발자는 단지 머리 수에 불과할 따름이다. 또한 전문적인 지식에 대한 가치 판단이 제대로 이루어지지 않고 있기 때문에, 소프트웨어 아키텍처까지도 비전문가에게 맡겨지는 경우가 많다.

SI 중심의 산업 구조, 그리고 전문가에 대한 평가 체계가 없고 단지 머리 수에 의해 개발자에 대한 판단이 이루어지는 상황에서 개발자의 성공 사례는 나올 수 없다. 대기업의 협력 업체에서 일하는 많은 개발자들이 과중한 업무로 인해 참다못해 전업을 하거나 건강이 나빠져서 자의반 타의반 일을 더 이상 할 수 없게 되곤 한다. 그러한 이유 때문에 많은 개발자들이 스스로를 막장 인생이라고 표현하고 있다.

엉성한 개발자 관리
둘째, 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고 있다. 소프트웨어 개발은 멘탈(mental) 작업이다. 인간의 정신에 의해 결과물이 만들어지고 그것이 성공과 실패를 좌우한다. 하지만 국내 대부분의 소프트웨어 업체들은 그러한 멘탈 작업에 적합한 업무 환경을 제공하지 못하고 있다. 또한 커리어 관리도 이루어지지 않고 있다. 물론 실적에 대한 보상도 미비하다.

개발자들에 대해 출퇴근 시간을 정확하게 체크하고(아니, 출근시간을 지키는지 체크하고 퇴근시간은 얼마나 늦는지 체크한다), 집중할 수 없는 시끄러운 환경을 제공하고, 업무 실적의 가치를 제대로 평가하지도 못한다. 심지어 복장 점검을 하기도 한다. 또한 요즘 개발자들은 전문적인 교육은 고사하고 일일 세미나에 참석하는 것도 어려운 형편이다. 많은 기업들이 최소한의 투자조차 기피하고 있기 때문이다.

그것은 중소기업은 말할 것도 없고 소위 초일류 기업을 지향한다는 대기업도 마찬가지이다. 열악한 업무 환경을 제공하면서 성과에 있어서는 최고의 아웃풋을 강요한다. 개발 환경만 제대로 제공되지 못하는 것이 아니라 관리도 제대로 안되고 있다. 부적절한 관리자들이 개발자를 정신적으로 학대하고 있다. 소프트웨어 개발자로서 생존하기 위해서는 사회 구조적 환경, 그리고 기업문화와 싸워야 한다. 많은 선배 개발자들이 그런 생존을 위한 싸움에서 졌고 결국 사라져 갔다.

개발자들의 스킬 부족과 닫혀진 태도
셋째, 끝으로 개발자들의 커뮤니케이션 스킬 부족과 태도 문제를 지적하지 않을 수 없다. 이 문제는 한국적 기업문화(상명하복)와 결합하여 더욱 복잡한 문제를 야기하고 있다. 개발자들은 특히 다른 직종에 비해 성격이 까칠한 경우가 많다. 자신만의 지식과 세계가 있기 때문에 그것이 전부라고 우쭐한 채로, 다른 개발자나 다른 직종을 존중하지 못하는 사람들이 꽤 많다.

하지만 “타인이 원하는 것에 대해 관심을 갖지 않는 사람”은 인생의 가시밭길을 걷게 된다. 그런 태도는 타인과의 협업을 어렵게 하고 결국 자기 자신이 원하는 것도 얻지 못하게 한다. 젊은 시절에는 그런 태도에도 불구하고 큰 문제가 없을 수 있겠지만, 30대 중반이 넘을 때까지도 태도를 변화시키지 못할 경우 이후에 많은 고난을 겪게 된다. 그것은 이미 인간의 역사에서 증명된 삶의 법칙이다.

똑똑하고 샤프한 개발자들은 종종 있다. 하지만 타인의 관심사에 진정으로 주의를 기울이고 타인에게 친절한 마음을 가진 개발자를 만나기란 참으로 힘들다. 이것은 다른 직종도 마찬가지이겠지만 (개발자 출신인 필자가 볼 때에는) 개발자들의 세계에 유독 이런 까칠함과 폐쇄성이 심하다.

물론 그런 독불장군적 태도가 단지 개발자들의 탓만은 아닐 것이다. 많은 개발자들이 피해 의식을 갖고 있으며 그것이 타인에 대한 공격적 태도로 나타나기도 한다. 사회적 환경의 미비, 그리고 커뮤니케이션 스킬이 부족한 개발자들. 이 조합이 더욱 안타까운 결과를 만들어낸다.

추가적으로 언급할 점은, 혁신해야 할 여러 가지 네가티브한 요인에도 불구하고 개발자들끼리 잘 뭉치지 못한다는 사실이다. 외국과 달리 개발자 커뮤니티의 활동이 많지 않다. 물론 JCO(자바 개발자 커뮤니티), SCA(소프트웨어 커뮤니티 연합) 등 개발자들의 모임이 없는 것은 아니지만 가끔 오프라인 모임이나 컨퍼런스를 개최할 뿐, 별다른 ‘사회 변혁적 활동’을 구현하지는 못하고 있다. 개발자들의 실상을 알리고 대안을 마련하고 정부나 기업들과 접촉을 하고 해외에 진출하고 창업을 하는 등의 좀 더 적극적으로 행동하는 것이 필요하다.

아마도 필자의 이런 글에 대해 그저 현실에 대한 비판에 불과하다고 얘기하는 이도 있을 것이다. 하지만 대응 방안을 마련하기 위해서는 먼저 냉정하게 현실을 정리하지 않을 수 없다.

요약해보자. 대기업 계열사들이 장악한 SI 위주의 산업 구조에서 개발자들은 성장하지 못하고 성공하지 못한다. 이런 사회 풍토에서 과연 존경 받거나 성공한 개발자들이 얼마나 되는가? 또한 많은 소프트웨어 업체들의 기업 문화가 후진적이다. 제대로 된 업무 환경을 제공하지도 못하면서 프로젝트 관리도 안 된다. 그러면서 성과에 대해서는 초일류를 원한다. 이율배반적이다.

개발자들의 태도 문제도 있다. 환경을 바꾸지 못하면 자기 자신을 바꾸어야 한다. 개발자 스스로 그런 인식을 가져야 한다. 피해의식에 사로잡혀 있는 것만으로는 삶이 억울하지 않은가? 개인적으로 커뮤니케이션 스킬을 향상시키고 타인에 대해 친절한 태도를 갖추는 인간 수양이 필요하다. 그리고 동료 개발자들과 함께 변혁을 위해 협업하고 개척해나갈 부분이 있다는 것을 알고서 행동해야 한다.

왜곡된 업계 구조 속에서 가만히 있으면 퇴출될 뿐이다. 우리에게는 행동이 필요하다. 이후의 컬럼에서 하나씩 대응 방안을 다루어보도록 하겠다.

세상에는 많은 프로그래밍 언어가 있으며 또 많은 개발 툴들이 있다. 그런 프로그래밍 언어나 개발 툴로 윈도용 프로그램, 혹은 리눅스, 유닉스용 프로그램을 만든다. 또는 웹용 프로그램을 만들기도 한다. 나 같은 프로그래머는 어떤 언어를 선택하느냐, 아니면 어떤 툴을 선택하느냐에 따라서 직업의 성질이 결정되곤 한다. 과연 어떤 언어와 툴을 선택해야 내가 이 세계(IT, 프로그래밍 세계)에서 오랫동안 지낼 수 있을까?

일단 현재 가장 잘 알려진 언어들을 쭉 나열해보자.

C, C++, JAVA, FORTRAN, COBOL, Pascal, BASIC …

여기에 개발 툴 언어라는 것들이 있다.

Delphi, Power Builder …

또 웹 스크립트 언어들도 있다.

ASP, PHP, JSP, CGI, Python, Ruby …

맨 먼저 언급했던 언어들이 우리가 흔히들 프로그래밍 언어라 불리는 것들이다. UNIX 운영체제의 기본이 되었던 C와 C를 베이스로 해서 OOP 개념을 접목시켜 만든 C++, C++을 베이스로 해서 가상머신의 개념을 접목시켜 만든 JAVA, 최초의 컴파일 언어인 FORTRAN, 사무언어에 가장 적합하다고 얘기했던 COBOL, 초보자용 언어인 BASIC. 아마도 모든 컴퓨터 언어 책의 역사에 한번씩 다 언급이 되었던 언어들이다. 앞으로 얘기할 개발 툴 언어나 웹 스크립트 언어도 모두 위에서 언급한 프로그래밍 언어를 베이스로 만들어지게 된다.

Delphi나 Power Builder는 엄밀히 얘기해서 프로그래밍 언어는 아니다. 그렇지만 현재는 프로그래밍 언어의 한 축을 이루고 있는 상황이다(프로그래밍 언어로 편입되었다고 봐도 좋겠다). Delphi는 Pascal을 베이스로 윈도에서 돌아가는 프로그램을 만들기 위한 툴이다. Power Builder는 C를 베이스로 만들어졌다. 그렇다고 순수하게 Pascal이나 C가 아닌 그 툴에 맞게 수정된 언어다. 결국 별개의 언어라고 봐도 무방할 것이다. MS에서는 윈도에서 개발할 수 있도록 Visual C++, Visual Basic 등 Visual Studio 패키지를 제공한다. 그런데 Visual C++은 C++을 베이스로 만들어졌지만 순수한 C++은 아니다. MS가 윈도용 프로그램 개발을 쉽게 하기 위해 표준 라이브러리 이외의 MFC나 Win32 API등의 라이브러리를 더 제공하고 표준 라이브러리도 제공하지만 자기들이 제공하는 라이브러리에 더 우선권을 줘서 개발하도록 유도한다. 그래서 개발자들은 Visual C++은 C++로 보지 않고 또 다른 언어로 취급한다. Visual Basic도 마찬가지다. 아니, 더 심하다. 우리가 알고 있는 표준 Basic을 무시한 체 자기들만의 Basic을 만들어서 배포하고 있다. 즉, 완전히 다른 언어다. Delphi나 Power Builder도 마찬가지다. Boland에서 제공하는 윈도용 프로그램 개발 툴인 Delphi는 Pascal을 베이스로 만들어졌다. 엄밀히 얘기하면 Boland의 Turbo Pascal의 윈도 버전이라고 할 수 있다. DOS 환경에서 윈도로 넘어가면서 역시나 MS처럼 표준 라이브러리 이외에 Boland만의 라이브러리를 제공하고 표준 라이브러리보다 우선권을 더 줘서 개발하도록 유도한다. 게다가 Pascal의 문법에서 약간 더 변형을 취다. 그렇기 때문에 Delphi는 Pascal 형식을 취하고는 있지만 정상적인 Pascal이 아닌 변형 Pascal, 아예 다른 언어라고 할 수도 있을 것이다. Sybase에서 제공하는 Power Builder도 마찬가지다. C언어를 기준으로 만들어졌지만 형식만 C언어를 취했을 뿐 표준 C 라이브러리는 사용하지 않고 Sybase에서 만든 라이브러리를 사용하도록 하고 있다. 즉, Delphi, Visual C++과 같이 Power Builder도 완전 다른 언어라고 볼 수 있다.

그런데 이런 것이 중요한 것이 아니다. 회사 입장에서는 어찌되었던 빠른 시간에 빠른 결과물을 보이기를 원하며 그것은 어떤 툴(솔직히 Visual C++이나 Delphi나 Power Builder는 프로그래밍 언어가 아니라 개발 툴이다)을 사용해서던지 기간 안에 만들면 되는 것이다. 그래서 어떤 개발 툴을 이용해야 빠른 시간 안에 퍼포먼스를 최상으로 유지하며 개발할 수 있는가에 대해 많은 논의가 이루어졌다. 알다시피 윈도라는 운영체제가 나오면서 MS는 Visual C++, Visual Basic을 선보인다. 그런데 생각보다 개발이 어렵고 퍼포먼스가 안나왔다. 그래서 더 괜찮은 윈도용 개발 툴을 찾기 시작했고 서드파티 프로그램인 Delphi와 Power Builder가 각광을 받기 시작했다. 원래 Delphi는 윈도에서 프로그램과 데이터베이스의 연동을 원활하게 하기 위해 만든 툴이다. 즉, DB처리 쪽에 더 특화된 개발 툴인 것이다. 거기에 UI 처리 부분이 더 추가되면서 지금의 모습을 갖추게 되었다. Power Builder 역시 DB처리 쪽으로 특화된 개발 툴이다. Visual C++이나 Visual Basic이 DB처리 부분이 약하고 Oracle과 같은 MS에서 만든 DB가 아닌 타 DB에는 잘 연동이 안되는 단점을 커버하고자 나온 개발 툴들이 Delphi, Power Builder다. 그런데 요즘은 윈도용 프로그램을 만드는데 Visual C++이나 Visual Basic보다 Delphi, Power Builder를 더 많이 사용하고 있는 상황이다. 그래서 지금은 Visual Basic은 사장되다시피 되고 Visual C++은 윈도용 시스템 프로그래밍쪽에 활용되고 윈도용 어플리케이션에는 주로 Delphi나 Power Builder를 사용하는 추세다. 아무래도 시스템쪽은 윈도를 만든 MS에서 제공하는 Visual C++이 더 접근하기 용이해서 그런게 아닐까 싶다. 여하튼 많은 윈도용 프로그램 개발자들은 어플리케이션 개발자들은 Delphi나 Power Builder를, 윈도 서비스 등을 만드는 시스템 프로그램 개발자들은 Visual C++을 사용하고 있다.

일단 윈도에서 사용하고 있는 툴들에 대해서 좀 적어봤다. 각 개발 툴들은 C, C++, Pascal이라는 프로그램 언어를 베이스로 윈도라는 운영체제에 맞춰서 변형되어 개발되었다. 어떤 툴을 사용하던지 윈도용 프로그램을 개발하는 데에는 문제는 없겠다만 어떤 용도의 프로그램을 만드느냐에 따라서 사용하는 툴이 달라질 것이다. 아니면 어떤 회사에 들어가서 일하느냐에 따라서 어떤 개발 툴을 사용할 것인지가 결정될 듯 하다.

그런데. 내가 뭐 때문에 이 글을 쓴거지? 원래는 어떤 언어를 선택해야 오랫동안 프로그래머 생활을 할 수 있을까 생각할려고 한건데 엉뚱한 글이 나왔다. 뭐 그냥 이대로 결론짓고 내가 원래 생각했던 글은 추후에 다시 정리해서 써야겠다(뭐야~).

ps) 앞에 있었던 나와 A라는 사람의 대화는 이 글의 성격상 너무 안맞아서 삭제했다. 내 생각을 좀 더 정리해서 다시 써볼까 한다.