편하게 쓰겠습니다.
어떻게 하면 인정받는 개발자가 될 수 있는가?
비즈니스와 개발의 경계는 무얼까?
SOA, WEB2.0등등....
이 용어들은 개발자들에게 맞는 용어일까? 비즈니스 전문가에게 맞는 용어일까?
주위의 대다수 사람들이 개발자이다보니 위의 용어들을 이야기하는 사람들이 거의 다 개발자이긴 하지만, 이야기를 나누다 보면 너무 개발자측면으로 이야기하는 것 같아서 조금 씁쓸하다. 물론 본인도 개발자 출신이고, 현재도 마음속으로는 개발자라고 생각하지만, 위의 용어들을 바라보는 시각은 약간은 다른 것 같다.
SOA를 개인적으로 바라보기에는 '날개발'을 예쁘게 치장한 이름 그 이상 이하로도 안 보이며 WEB2.0은 닷컴버블에서 살아나 수익을 올리고 있는 인터넷기반 기업들의 수익모델을 분석해서 그 특징들을 정리해 붙인 용어이지 어떤 특정한 기술요소를 말하는 것은 아니라 생각한다.
그런데, 주위의 개발자들과 이야기해보면, 'WEB2.0은 UCC 등으로 대표되는 양방향성', 'SOA는 웹서비스', 이런 식으로 이야기하곤 한다. 이런 생각은 하루빨리 바꾸고, 고객에게든 같은 개발자그룹내에서든 "WEB2.0은 웹 기반에서 이야기하는 비즈니스 수익 모델을 말하는 것이며, 새로운
기술이 아니라 우리회사와 같이 일하면, 이렇게 이렇게 해서 WEB2.0을 사용해서 소비자에게 더 어필하기 좋게 해드리겠습니다"라거나 "우리회사와 같이 일하시면 이렇게 저렇게 만들어서 (혹은 제공해서) SOA 사상에 걸맞게 사용하실 수 있으며, SOA로 '플젝'을 했기에 소비자에게 '당사는 소비자의 needs를 즉시 반영할 수 있게 됩니다'라고 말할 수 있게 해드리겠습니다"라는 식으로 말하는 사람이 좀 더 많아졌으면 하는 바램이다.
SOA와 WEB2.0이야기는 이쯤하고(다음에 다시하고...), 실제로 쓰고 싶은 이야기를 해보겠다.
개발자라는 직종에서 일하고 있으면, 어떤 강약점을 가지고 있을까? 개발자는 장수하기 위해서 어떻게 해야할까? 혹은 어떻게 성장해야할까?
개인적으로 느낀 점들을 하나씩 풀어보겠다.
1. 개발자는 프로세스에 강하다.
개발이라는 일은 많은 사람들이 말하듯이 '노가다'를 하는 일이 전부가 아니다. 노가다적인 일도 있지만, 개인적으로 생각하는 개발은 그 노가다가 시작되기 전, 즉 설계를 할 때 더 어울리는 말인 것 같다. 그 이후의 노가다는 일이지 개발이 아니다. 하지만, 경험하지 않았다면 노가다는 반드시 겪어야 할 일이라 생각되며 그러면서 게을러짐에 대한 많은 고민을 해야한다. 그런 고민들이 일련의 일들에서 규칙을 찾아내는 힘을 길러주며, 나중에 설계를 하게 될 때 많은 도움을 준다. 그렇게 일련의 과정을 겪은 개발자가 프로세스를 찾아내고, 정규화하고, 정교하게 하는 능력이 약할리 없다고 생각한다. 이런 점은 이 직종에 종사하면서 얻는 아주 좋은 경험이라 생각된다.
2. 개발자는 적어도 하나의 프로그램언어를 다룰 수 있다.
적어도 하나의 언어로 프로젝트에서 주어진 상황을 해결할 수 없다면 단언하건데 당신은 개발자가 아니다. 언젠가 생각해보니, 하나의 언어를 적당한 수준으로 구사하는 것은 그리 큰 일이 아닌 듯 했다. 기본 구문, 파일처리, DB처리, 소켓처리, Thread처리, GUI의 경우 이벤트 처리, WEB의 경우 Cookie/Session처리 정도만 가능하면 프로젝트마다 다르겠지만, 다른 사람의 짐이 되는 것은 어느정도 피할 수 있다. 그리고 이런 처리조차 못한다면, 공부가 부족한 것이다. 불평을 하기전에 공부부터 하시라.
3. 개발자에게 부족한 능력 - 처세(정치력)/마케팅
주위에서 심심치않게 보는 사람들... 10을 일하고, 2정도만 인정받는 사람들...
전에 지인들과의 대화중에 이런 이야기가 있었다.
"XX씨는 10을 일하고 2정도밖에 인정받지 못한다. 그래도 우리처럼 8은 인정받아야지. 만약 15를 인정받는다면 그 사람은 컨설턴트지"라는 이야기에, 씁쓸하게 웃었던 기억이 난다. 이 부분은 포장에 대한 이야기이다.프로젝트 기반으로 살아가는 개발자에게 처세와 포장에 대한 이야기는 꽤나 와닿는 이야기이며, 이 부분에 대해서 마케팅에 관한 책들은 많은 참조거리를 제공해 준다. 마케팅의 컨셉들을 차용해서 프로젝트하는데에 활용한다면 많은 도움이 될것이다. (자세한 이야기는 추후에 하겠다.)
4. 개발자가 관리해야 하는 것 - 경력!!!!
비즈니스 전문가나 컨설턴트들에게도 굉장히 중요한 것이긴 하지만, 개발자에게도 경력관리란 거의 본인의 생명줄이나 다름없다고 생각해야 한다. 우리(개발자)는 발명가가 아니다. 우리가 일하는 이 분야는 이직이 잦으며 연봉은 이직하는 순간에 가장 많이 오른다. 이직할 때 가장 속썩이는 부분이 무엇일까? 영어? 아니다. 바로 경력이다.
가장 쉬운이야기로 어떤 개발자 이모씨가 있다고 했을 때, 그 사람의 이력서를 보면, 언어는 Java와 SQL이지만, Industry가 제조(자동차) + 회계 + 카드 이렇게 구성되어 있다. 다음 이직할 때 일단 은행권 or 보험권 개발자를 구하는 곳에는 들어가기 힘들 뿐 아니라, 들어간다고 해도 원하는 만큼의 연봉상승은 어렵게 된다. 반면, 어떤 개발자 김모씨의 경우 이력서가 줄기차게 유통으로 되어 있다고 하면 김모씨는 유통관련 회사를 계속 다닐생각이 있다면, 적어도 이직에 대한 고민은 거의 없다. 심한 경우 프리랜서도 못할 정도로 꼬셔갈 수도 있다.
중/소기업의 경우 경력관리가 특히나 힘든데, 과감히 이야기하겠다. Industry를 하나 정해서 그것이 흔들리는 회사라면 과감히 다른 회사로 가시라. 사장님께는 죄송하겠지만, 자신을 위해서는 그것이 더 낫다고 생각한다. 차라리 더 좋은데로 빨리 올라가서 그 사장님의 회사와 같이 일을 하시라.
현재 개발과 비즈니스 중간에 걸쳐서 사는 사람이면서 글을 다소 길게 쓴듯 하지만, 올해 초에 JCO 컨퍼런스에 토론 발제했던 것처럼, 개발자라는 직종을 좋아하는 사람 중의 하나로서 사회적으로 인정받는 개발자가 많아졌으면 하는 바람으로 오늘도 고민한다.
감사합니다.
