[개발] 프로그래머로 가는길

프로그래머, 개발자, 엔지니어, 코더, 아키텍트, 디자이너, 예술가… 전산학과, 컴퓨터 공학과, 6개월 마스터 과정 학원 교습까지… 과연 개발자의 세계는 어디까지일까. 개발자의 세계를 설명하는 수많은 용어의 홍수 속에, 지금의 시점에서 개발자로서 자신이 가야할 길이 어디인지 고민하는 이들을 위한 길잡이를 제시하고자 한다.

 

신승근 (데브 CEO 겸 수석 컨설턴트 )
   2001년 4월호

 

  "아무도 걸어가지 않은 길을 걷는다는 것은 쉬운 일은 아니지만, 가치있는 일입니다. 누군가가 내 뒤를 따라오기 때문입니다."
  개발자에 대해 나온 책들이 몇 권 있지만, 언어를 가르치거나 형식적인 면에 그치는 경우가 많아서 이번 기회에 개발자에 대한 글을 써보기로 했다. 개발자에 대한 분석이나 자료들이 거의 없어 자료를 찾는 일과 명상에 많은 시간을 투자했음을 밝힌다.
  모두가 잠든 새벽, 키보드 자판을 두드리는 한 명의 남자, 옆에는 식은 커피잔과 어질러진 서류들, 부시시한 머리에 이글거리는 눈동자. 나라를 위협하는 전자 장비나, 바이러스 소프트웨어를 몇 시간만에 만들기도 하고, CD롬에 저장된 정보를 몇 분만에 분석해 스파이를 찾아내고….
  앞에 묘사한 것은 영화에 나오는 해커나 소프트웨어 개발자의 모습이다. 실제 개발자의 모습과 비슷한 부분도 있지만, 사실과는 동떨어진 묘사도 있다. 그렇다면 실제 개발자의 모습은 어떤 것일까.
  개발자를 알기 전에 개발자가 만드는 소프트웨어(프로그램)에 대해 먼저 살펴봐야 한다. 소프트웨어를 모른다면 개발자도 알 수 없기 때문이다. 우선 프로그램이라는 단어에 대해 알아보자. 신문을 펼치면 'TV 프로그램 안내'를 쉽게 찾을 수 있다. TV 프로그램 안내는 TV 순서 안내와 같다. 즉 프로그램이란 '순서'를 뜻한다. 그러나 이 설명만으로는 뭔가 부족한 듯하다. 좀더 자세히 알아보자.
  소프트웨어를 알면 개발자가 보인다 우리는 연극의 3요소, 희곡의 3요소 등을 학교에서 배웠다. 소프트웨어를 알기 위해서는 그런 요소들을 살펴보는 것이 제일 빠른 방법이 아닐까. 소프트웨어(프로그램)의 3요소는 무엇일까. '소프트웨어의 3요소'란 정의는 없지만, 대신에 70년 이후 프로그램에 대한 묘사(?)를 정리하면서 끌어낼 수 있다.
  대부분의 소프트웨어 공학 책에 나와있는 프로그램의 원론적인 정의는 <그림 1>과 같다. 입력을 받고 처리해 결과를 내놓은 것이 프로그램이라는 표현은 명확하지만, 이 정의는 프로그램의 요소 중에서 프로세스(처리)만 강조를 하고 있는 정의라 할 수 있다. 70년대에 만들어진 프로그램은 대부분 이 정의에 입각해 입력과 출력, 처리에 관한 기술을 하고 있다. 당시의 프로그램들은 업무의 범위도 매우 작았고, 극히 작은 메모리와 매우 느린 CPU에서 실행되므로 이런 정의는 매우 정확했다.
  소프트웨어 공학에서는 프로그램에 대한 다른 의미로 '실세계를 컴퓨터에서 처리하기 위해 모델링(코드화)한 것'이라는 표현(<그림 2>)도 사용한다. 이것은 프로그램이라는 것은 실세계의 투영체에 불과하다는 개념에서 비롯된 것이다. 현재는 소프트웨어가 실세계의 반영를 넘어서고 있으므로 하나의 다른 세상을 보여주고 있다. 따라서 이런 정의는 부분적인 설명에 그치고 있다.
  한편, 파스칼을 설계한 스위스 쮜리히의 공과 대학 교수인 니클라우스 워스(Niklaus wirth)는 그의 저서(Algorithm + Data Structure = Program)에서 프로그램에 대해 다음과 같이 설명했다.

알고리즘 + 자료구조 = 프로그램

 

이런 정의는 70년대 초부터 80년대 말까지는 적절한 설명이었다. 당시 프로그램들은 구조적 설계에 의해 개발되고 있었으므로 구조적 설계에 의해 프로세스와 필요한 데이터 구조를 파악하고 이를 구현하는 것이 하나의 프로그램 개발 방법이었기 때문이다. 그래서 지금까지도 대학에서는 자료구조와 알고리즘을 가르치고 있는 것이다.
  90년대 초에 그래디 부치(Grady Booch)는 객체지향적인 시각에서는 프로그램을 구성하는 객체들의 합이라고 설명했다(Program are organized as cooperative collection of objets; Object Oriented Analysis and Design second edition, Benjamin Cummings Pub, Grady Booch, 1995). 그는 니클라우스 워스의 구조적 사고에서 일보전진한 객체적 사고에서 프로그램을 구성하는 최소 단위를 객체를 선택한 것이다.

데이터 + 메쏘드 = 객체

객체 + 객체 = 프로그램

 

  그렇다면 요즘 소프트웨어 불법 사용 단속이 한창인데, 저작권법 측면에서 보면 프로그램이란 무엇일까. 컴퓨터프로그램보호법 제2조 1항에 의하면 프로그램을 저작물로 인정해 다음과 같이 설명한다.
  '컴퓨터프로그램저작물'이라 함은 특정한 결과를 얻기 위해 컴퓨터 등 정보처리능력을 가진 장치(이하 '컴퓨터'라 한다)내에서 직접 또는 간접으로 사용되는 일련의 지시·명령으로 표현된 창작물을 말한다.
  저작권법에 의해 보호받는 범위까지 고려하면 프로그램 창작물의 범위는 문서까지 확잔된다. 프로그램 그 자체 뿐만 아니라 매뉴얼, 설명서도 프로그램 저작물이 되는 것이다.

알고리즘 + 자료구조 + 문서 = 프로그램

 

  6년 전부터 필자는 다음과 같은 주장을 강력히(?) 펼치고 있다. 앞으로 소프트웨어를 개발함에 있어 외부의 드러나는 사용자 인터페이스와 내부의 프로그래밍 인터페이스가 점차 중요하게 부각될 것이며, 또한 소프트웨어를 개발하는 방법론은 프로그램의 개발에서 가장 중요한 부분을 차지하게 되리라는 이야기다.

알고리즘 + 자료구조 + 인터페이스 + 문서 + 방법론 = 프로그램

 

  이제 소프트웨어가 무엇인지 이해되는가. 지금 살펴본 프로그램의 정의는 입장에 따라서 표현은 다르지만, '어떤 절차에 의해 기술된 코드로서 컴퓨터에서 실행될 수 있는 것'이라는 사실에는 변함이 없다.
그런데 절차라는 것이 프로그래머를 다소 융통성 없는 사람으로 만들어왔다. '절차적으로 매일 작업을 하는데, 삶 자체가 그렇지 않겠어'라는 생각에서, 프로그래머는 일반인으로부터 시간관념이 매우 명확하고 절차적으로 일을 처리하는 매우 답답한 사람으로 인식돼온 게 사실이다.
  앞의 글에서 프로그램과 소프트웨어라는 단어를 혼용해 사용하고 있는데, 프로그램과 소프트웨어의 차이점은 무엇일까. 프로그램은 절차적인 진행만을 강조하는 표현이고, 소프트웨어는 하드웨어의 반대적 입장에서 제품적인 성격을 표현한 것이라 할 수 있다. 그러나 결국은 동일한 것을 가리킨다.
  개발자 명칭에 이렇게 깊은 뜻이 개발자가 누구인지 알았지만, 우리는 개발자라는 직업에 대해 더 살펴볼 필요가 있다. 이를 통해 개발자에게 한 발자국 더 가까이 다가갈 수 있는 것이다. 소프트웨어를 개발하는 직업에 대한 명칭은 크게 코더, 프로그래머, 개발자로 구분을 한다. 각 용어마다 조금씩 차이가 있다. 이 구분은 누군가가 정해놓은 것이 아니라, 개발자의 세계에서 사용되는 경우를 좀더 세밀하게 구분해 본 것이다.

◆ 코더(Coder) : 약간은 개발자를 비하하는 용어이기도 하지만, 이미 정해진 루틴에 따라 프로그램을 입력하는 오퍼레이터로 보면 된다. 외국의 경우 파워빌더와 같은 개발툴을 사용할 때, 업무 컨설턴트가 분석한 내용에 따라서 주부들이 코더로 소프트웨어를 개발한다는 이야기도 들었다.
  아무래도 일정한 패턴을 따르는 분야에서는 인건비가 저렴한 코더를 많이 사용한다고 한다. 소프트웨어 분야의 개발 자동화 시스템의 발달로 난이도 있는 개발을 할 수 있는 프로그래머는 점점 사라지고, 단순한 개발을 맡을 수 있는 코더들이 할 수 있는 일이 늘어날 것이라는 전망도 나오고 있다. 한국에서는 '이 코더 수준 밖에 안되는 놈'이라는 표현에 자주 등장하면서 비하하는 의미로 생각하는 개발자도 있기 때문에 함부로 사용하기 어려운 용어다.

◆ 프로그래머(Programmer) : 개발자라는 명칭을 사용하기 전부터 사용해오던 명칭이다. 이전에는 소프트웨어라는 단어보다는 프로그램이라는 단어가 더 널리 사용됐고, 프로그램(Program)을 만드는 사람이라는 어미(er)가 붙어 프로그래머(Programmer)가 사용됐다. 까마득한 옛날에는 프로그래머의 주요 작업이 순서도를 만드는 것이었다. 따라서 세간에는 자에 잰 듯한 생활로 고리타분한 직업의 대명사이기도 했다.

◆ 개발자(Developer) : 프로그래머보다는 일보 진보된 개념으로서 연구를 해서 제품을 만드는 사람을 의미하는 단어인데, 최근 5년 전부터 많이 사용되기 시작했다. 널리 사용되는 제품을 만들기 위해서는 이전처럼 순서도에 입각한 작업보다 더 많은 지식과 이해가 필요하므로 단순 프로그래머가 아닌, 연구자로서의 자질과 승부근성까지도 필요하게 됐다. 따라서 유명한 소프트웨어 개발자들은 프로그래머 차원이 아닌 제품의 개발자로 표현되고 싶어한다.
  프로그래머와 개발자의 차이를 억지로 구분해본다면, 프로그래머란 이미 주어진 환경 속에서 일부 모듈을 코딩하는 자를 뜻하지만, 개발자란 새로운 것을 창조해낼 수 있는 능력까지도 갖고 있는 자를 의미한다. 일부 회사에서는 프로그래머는 순서도에 입각해 코딩하는 직원으로, 개발자는 새로운 제품을 만드는 직원으로 분류하기도 한다. 이런 분류와 관계없이 프로그래머와 개발자는 혼용해 사용되고 있으나, 실제로는 현재 개발자라는 명칭을 더 선호하는 듯 하다.
  개발자는 어떻게 만들어지는가 '어떻게 해야 개발자가 될 수 있을까요'라는 질문을 많이 받는다. 기고를 많이 하다보니, 어떤 학생들은 임금을 받지 않고 일을 배울테니, 1년간만 함께 있게 해달라는 경우도 있었다. 어떻게 하면 개발자가 될 수 있는지에 대한 궁금증이 많다는 사실에 놀라게 된다.
  대개의 경우, 학원에서 3∼6개월 과정을 마치고, 소규모의 개발회사에서 1∼2년쯤 지내면 충분히 소프트웨어 개발자로 자리잡을 수 있다고 생각을 한다. 그러나 아쉽게도 그런 방법으로 자리잡은 경우에 3∼5년 이내에 개발자보다는 시스템 관리나 다른 분야의 일을 하는 경우를 많이 봤다.
  프로그래밍이란 앞서 말했듯이 논리적인 순서의 나열이며, 데이터를 조작해 사용자가 원하는 처리를 하는 것이다. 10년 전까지만 해도 개발 규모가 매우 작았으나, 1995년을 넘어서면서 그 규모가 엄청나게 커지기 시작했다. 따라서 이제는 개발이란 개인의 단위가 아니라 최소한 팀 단위다.
  규모가 커졌기 때문에 팀 단위 프로젝트의 진행에 있어서나, 다음 버전의 개선을 위해서도 개발자는 거추장스런 방법론을 싫어한다는 것을 알아야 한다. 고객을 위한 품질 관리를 위해서는 최소한 ISO 9000과 ISO 12207이라는 규격 정도는 소프트웨어 개발사에서 인증받아야 한다. 특히 해외에 소프트웨어를 납품하기 위해서는 필수조건이다.
  또한 미국 국방성에 납품하려면 CMM 레벨 3 인증을 받아야 한다. 우리 나라의 업체 대부분이 레벨 1 정도이고 이제 겨우 3개 업체만 CMM 레벨 2를 받았다고 한다. 레벨 1을 올리는데 수십 개월 이상 소요됐다는 연구 결과를 접하면 국내 기업이 1년 내에 CMM 레벨 3을 받는 것도 매우 어려운 일이다.
  팀 단위, 개발도구, 그리고 지속적인 관심과 노력 개발도구 역시 이제는 만만한 일이 아니다. 비주얼 베이직의 경우를 예로 들어 살펴보더라도 객체지향적인 개발을 위해서는 OOP와 UML 정도는 익혀야 한다. 보통 OOP와 UML을 습득하는 데만 1년 이상이 소요된다는 점을 생각하면 이 역시 쉬운 일이 아니다.
  ADO와 액티브X 기술에 대한 것들, MTS(Microsoft Transaction Server), MMQ(Microsoft Message Queue) 등을 배우는 일도 개인적으로, 혼자하기에는 한계가 있는 것이다. 비주얼 베이직에 대한 도움말만 보더라도 그 분량이 매우 엄청나다. 보기만 해도 기가 질릴 정도이다.
  즉, 이제는 개발을 하기 위해서는 소규모가 하나의 완성된 제품을 내놓기 위한 다양한 요소가 필요하다. 이를 습득하기 위해서는 참으로 오랜 기간이 필요하다. 모든 것을 습득한 뒤에 개발을 하기 위해서는 2∼3년을 공부만 한다 해도 시간이 부족하다.
2∼3년 뒤에는 또 다른 것이 나올 것이다. 비주얼 베이직 닷넷(VB.NET)만 해도 비주얼 베이직 6.0과는 전혀 다른 완전 OOP의 구조를 하고 있다. 지금까지 비주얼 베이직 개발자들이 소홀히 하던 객체지향개념을 모두 배워야 하며 게다가 XML이나 SOAP 등도 이해를 해야 하니, 산너머 산이다.
  이처럼 지속적인 관심과 노력이 매우 필요한 직업이 개발자다. 물론 회사에서 주어지는 일들만을 처리하겠다는 마인드를 가지는 개발자도 있겠지만, 2년만 새로운 기술 습득에 게으름을 피우면 2년 뒤에는 어떤 프로젝트에도 참여하기 어렵게 될 것이다.
최소한 개발도구와 언어에 대해서는 전문가가 되자. 개발도구에 대해서 전문가가 되기 위해 필요한 시간은 6개월 정도면 충분하다. 다양한 원서와 외국 저널, 외국 컨퍼런스 자료들을 공부하기에 6개월은 충분한 시간이다. 필자가 자주 가는 VBITS에서 한국 사람은 거의 찾기 어렵다. 중국인이나 일본인은 상대적으로 많이 볼 수 있다. 넓게 보면 그만큼 국내의 IT 기술에 대한 투자가 미약하다고 할 수 있다.
  그리고 많은 프로그램을 작성해보기를 권하고 싶다. 필자만 하더라도 비주얼 베이직을 처음 배울 때 500개의 예제를 혼자 만들어 비주얼 베이직의 모든 것을 직접 손으로 눈으로 머리로 체험을 했다. 500개의 예제를 만들어 연구해보는데, 필요한 기간은 고작 3개월이었다.
  대학에서 C 언어와 C++을 공부할 때도 약 30여권의 C언어 책을 읽고, 1000개의 예제를 만들어봤다. 이때 약 6개월 정도가 소요됐다. 이런 노력들은 다른 것을 습득할 수 있는 기본적인 능력을 배양을 해준다. 이런 노력 없이 전산학원을 다니거나, 전산과 전공을 한다 해도 그것은 크게 도움되지 않을 것이다.
  이런 과정을 통해 개발도구나 언어에 익숙해지면 프로그램을 개발할 수 있는 기본기는 충분히 갖춘 셈이다. 이제는 개발하면서 효과적인 개발에 대해 관심을 가져야 한다. 대부분의 개발자들이 개발의 결과에만 집착한다. 소프트웨어는 그 특성상 성능과 기능 개선이 지속적으로 진행되지 않는다면 그 생명력을 잃는데, 개발한 소스가 체계적으로 개발돼 있지 않다면 다음 버전은 새로운 출발을 해야 한다.
  따라서 개발자가 좋은 소프트웨어 개발에 대해 관심을 갖게 되면 방법론과 소프트웨어 공학에 대해 새로운 시각을 가지게 되는 것이다. 소프트웨어 공학이나 방법론은 이론으로만 배운다면 적용하기도 어렵고 적용 자체가 피상적이므로 좋은 효과를 얻을 수가 없다.
  학원 교육과 자격증 취득의 허실 혼자 공부하기 어렵다면서 학원을 추천해달라고 필자를 찾는 경우가 많았다. 그러나 국내에서 프로그래밍을 제대로 가르칠 수 있는 학원은 거의 없다고 할 수 있다. 이렇게 단정짓는 이유는 학원의 교과과정이 개발도구에 치우쳐 있거나 기초적인 이론에만 치우쳐 있기 때문이다.
  이것은 학원이 상대적으로 많은 비용을 차지하는 강사 비용을 줄이기 위해 주당 강의 시간을 줄이기 때문이다. 또한 유능한 강사의 경우 그 비용이 만만치 않으므로 그보다는 다소 지도 능력이나 경험이 떨어지지만 강의료가 덜 비싼 강사들을 선호하므로 더욱더 강의의 내용이나 질은 떨어진다.
  그래서 필요한 과목별로 제대로 가르치는 강사들을 찾아다니면서 배우는 것이 다소 비용이 들더라도 효과적인 방법이 아닐까라는 생각도 해본다. 문제는 능력(?) 있는 강사를 찾아내는 것이긴 해도, 도전해볼만한 가치는 있다.
실제로 필자는 국내에서 유명한 S사의 M학원에서 오라클에 대한 교육을 받은 적이 있다. 단기간의 프로젝트를 진행하기 위해 오라클에 대한 지식을 단기간에 얻을 수 있는 좋은 방법이라고 생각해 교육을 받았는데, 강사는 유창한 영어발음으로 책만 내내 읽으며 질문을 해도 질문 자체를 이해하지 못하거나 매우 형식적인 답변으로만 일관했다. 굴지의 M학원에서 이 정도라면 다른 학원들은 말할 나위도 없다.
  또한 M학원의 소프트웨어 전문가 과정을 졸업하면 MCSE와 MCSD를 취득하는 놀라운 실적을 보여주고 있지만, 실제 자격증 취득자를 면접한 결과 가장 기초적인 프로그래밍 상식조차 없는 경우도 있었다. 페이퍼 자격증의 폐해를 그대로 보여주는 것이다. 외국에서는 경력 없는 자격증은 인정조차 안되므로 학생이나 무경력자가 자격증을 취득하는 일은 그리 많지 않다고 한다.
MCSE란 최소한 2∼3년의 경력을 보증하는데, MCSE를 취득하고도 NT 설치가 안되면 그 원인을 파악하지 못하니 자격증이 보증하는 것이 도대체 무엇인지 모르겠다. 특히 국내에서는 고등학생들도 MCSE 자격증을 가지고 있다고 하니 외화낭비라는 생각까지 든다.
  빌게이츠와 스티븐잡스를 생각하라 개발자라면 가장 기초적인 전산의 학문에 대해서도 소양을 갖춰야 한다. 예를 들어서 알고리즘이나 데이터구조, 데이터베이스, 객체지향프로그래밍, 소프트웨어공학, 컴파일러 이론 등에 대해서는 기초지식을 습득해야 한다.
  유명한 개발자들은 대부분 기초학문에 있어서는 상당한 이론가임을 알 수 있다. 그런 기초가 없다면 모래 위에 집을 짓는 것과 같다. 필자가 큐(Queue)를 작성하는데 걸리는 시간은 30분 정도다. 동일한 작업을 전산과 4학년에게 시켰더니 약 5일이 걸렸다.
그 간단한 프로그램을 디버깅하는데 그렇게 오랜 시간이 걸리다니! 기초 학문에 대한 몰이해와 프로그래밍에 대한 연습이 부족하다면 충분히 발생할 수 있는 일이다. 이런 수준으로는 전산과를 나왔다고 말하기가 창피한 수준이다.
  '개발자 동의보감'에서도 이야기했듯이 개발자가 되겠다고 교육을 받아도 일부만이 개발자로 성장하고, 대부분은 다른 직업을 찾는다. 실제로 프로그래밍을 해보니, 그 과정이 '생 노가다'나 '허드렛 일'이어서 금방 실증이 나고, 시간 낭비로 치부해 버린다.
그러나 잘 생각해보면 미술가는 붓질을 통해 예술품을 만들고 소설가는 펜대를 굴려 베스트 셀러를 만들어낸다. 소프트웨어 개발로 성공한 빌게이츠와 스티븐잡스를 생각해보라, 그들이 한 생 노가다가 이뤄낸 결과를 바라보라.
  앞으로 나의 길은 어디에 소프트웨어 개발에 대해 대학이나 학원에서 배우고 나면, 그 다음 행로는 어디인가. 개발자가 가야할 길은 소프트웨어 개발뿐인가, 아니면 다른 길들도 있단 말인가. 개발자들의 역할은 어디까지인가 이런 내용들을 설명하기 위해서 가상적으로 소프트웨어 개발 회사(부서)를 세우고, 이 개발 회사에 필요한 인력들의 배치도를 만들어 소프트웨어에 관련된 직업들을 찾아보겠다. 직업별로 업무 영역이 구분되므로 배워나가야 할 방향도 다르다.
  개발업체에 따른 분류 먼저 회사를 세우려면 회사의 특징을 명확히 세워야 한다. 개발자가 근무하게 되는 회사의 종류를 명확히 나누기는 어렵지만, 근무하는 부서는 크게 네 가지 유형으로 나눌 수 있다. 어떤 회사는 이런 유형의 부서를 모두 갖추고 있는 경우도 있다.

  전산실(업무 개발실)

  패키지 개발(제품 개발실)

  외주개발(시스템 통합)

  IT 컨설팅

  전산실 전산실은 일반적인 기업의 내부에 있다. 자사의 업무를 파악해 필요한 시스템을 개발한다. 기업의 전산실은 다소 안정적이지만, 기업의 활동에 초점이 맞춰있어 기존 시스템의 유지 보수에 치우친 일이 많다.
  따라서 중소기업의 전산실은 새로운 기술을 도입하거나 습득하기 어렵고, 기업의 전산화를 위해 경영진을 직접 설득해야 하는 어려움에 부딪혀 좌절하는 경우가 많다고 한다. 경험자의 증언(?)에 의하면 대기업의 전산실도 외주 관리를 주로 하거나, 주어진 업무만을 담당하므로 역시 새로운 기술 습득에는 어려움을 겪고 있었다.
  특히 전산실에서 가장 핵심적인 인력은 업무를 아는 전산인력이므로, 제조업의 전산실의 경우 정규 전산을 배운 사원보다는 3년 이상의 업무 경험자가 특정한 기회에 전산을 배워 전산실로 발령난 사람들이 많다고 한다.
  패키지 개발 패키지 개발 업체는 패키지 제품(박스 제품)을 만들고 그 매출로 운영을 한다. 따라서 충분한 자금이 없는 경우가 많고, 개발 기간이 상대적으로 오래 소요되므로 운영에 매우 큰 어려움을 겪는다.
  그러나 상대적으로 인력들 사이에 유대관계가 좋고, 패키지가 시장에서 좋은 반응을 얻게 되면 판매가의 20% 정도의 높은 수익을 올릴 수 있으므로 소프트웨어 개발에 자신의 모든 것을 바치는 경우가 많다. 급여는 가장 낮은 편이지만, 대개 일에 만족하는 경우가 높다. 통상 개발자라고 할 때 패키지 개발 업체의 프로그래머를 가리키기도 한다.
  패키지 개발 업체는 제품이 갖는 한정된 범위의 기술과 내용에만 관심을 가지므로 의사결정의 범위가 다소 좁은 경우가 많다. 이것은 관심 밖의 기술들은 시장이 원할 때만 습득하게 되는 원인이 될 수 있다. 따라서 신기술의 습득보다는 기존 제품의 기술을 그대로 유지하려는 성격이 강할 수 있다.
  외주개발 외주개발을 주로 하는 업체는 인력파견 업체 또는 시스템통합 업체라고도 한다. 대형 프로젝트는 대기업이 수주를 해 인력관리만을 맡고, 실제 개발은 인력파견업체의 개발자들이 작업을 한다.
  예를 들어 대기업에서 M/M 비용을 600만원에 프로젝트를 수주하면 브로커업체에게 400만원에 하청을 줘서 5개정도의 인력파견업체를 모으도록 한다. 브로커업체는 다시 인력파견업체에 200∼300만원을 주고 인력공급을 받는다.
  급여의 수준은 인력파견업체가 높은 편이다. 대형 프로젝트의 경우 유지보수, 후속 개발 등의 작업들이 많으므로 개발자의 투입율이 100%를 넘어서 150%(한 사람이 1.5개의 프로젝트에 참여)인 경우들이 많으므로 충분한 자금 회전이 가능하기 때문이다.
그러나 수주한 프로젝트가 새로운 기술 요구 사항이 많고 단기간에 종료돼야 하므로 개발자의 스트레스가 매우 심한 편이다. 그래서 인력파견업체의 개발자는 하나의 프로젝트가 종료되면 회사를 옮기거나 프로젝트 도중에 그만두는 경우가 많으므로 인력의 이동이 심한 편이다.
  IT 컨설팅 IT 컨설팅 업체는 기술 컨설팅, 업무 컨설팅, 감리 컨설팅으로 구분될 수 있다. 업무 컨설팅 분야는 해당 분야의 업무 경력(대개는 MBA, CPA등 요구)이 필요하므로 개발자가 쉽게 도전하기 어렵고 기술 컨설팅이나 감리 컨설팅 분야는 도전해볼만 하다. 컨설팅은 상담과 브리핑을 통해 고객에게 필요한 것을 파악해 리포트 형태로 제공하는 업종이다.
연봉은 일반 개발 회사에 비해 2∼3배를 받는다. 대부분의 개발자가 꿈꾸는 직업이기는 하지만, 이런 회사들은 정확한 발음, 다소 높은 학력을 요구하는 편이서 취업이 쉽지 않다.
  개발 분야에 따른 분류 회사나 부서별 특성을 대략 이렇게 파악할 수 있지만, 개발 분야는 다른 이야기가 될 수 있다. 패키지 개발 업체라고 하더라도 유틸리티를 만들 수도 있고, 개발도구를 만들 수도 있기 때문이다. 그래서 개발 분야에 대해서도 알아야 한다.
개발 분야는 크게 나누면 <표 1>처럼 7가지 정도로 나눠볼 수 있다. 프로그램의 예는 출시 연도나 구성요소에 따라 약간씩 변할 수 있다. 예를 들어 웹 브라우저의 경우 인터넷 익스플로러는 시스템 프로그래밍에 가깝지만, 동일한 성격이라도 오페라는 유틸리티의 성격에 가깝다.
  우리 나라는 90년대초 K-DOS 이후에 운영체제에 대한 연구가 거의 진행되지 않다가 최근 다시 리눅스를 대상으로 한 바람이 크게 불고 있다. 개발툴 분야도 몇몇 제품이 나오기는 했으나 세계적인 제품으로 성장하지는 못했다.
  나모 웹에디터가 세계 시장에서 좋은 반응을 얻고 있다고 하니 좋은 소식을 기대해본다. 유틸리티 분야는 거원의 제츠오디오가 외국에서 폭발적인 인기를 얻어 널리 사용되고 있다. 다른 분야에서는 이렇다할 제품이 나오지 못하고 있거나 이제 시작 단계다.
업무에 따른 분류 지금까지 회사와 개발제품에 대해 알아봤는데, 소프트웨어 개발 업체라 해서 무조건 개발자로 근무하는 것은 아니다. 그 안에도 여러 가지 업무가 있고, 업무에 따라 다양한 직업이 있다. 여기서는 국내 컴퓨터 분야의 직업 뿐만 아니라 외국의 예도 함께 넣었다. 다만, 명칭은 국내의 명칭으로 통일했다. 참고로 디자인 분야의 다양한 직업을 반영하면 훨씬 더 많은 직업이 있겠지만, 여기서는 웹 디자이너에 한정시켰다.

제품개발자 : 박스로 팔리거나 다운로드 형태로 팔리는 패키지 제품을 개발한다.

시스템통합개발자 : 외주 개발에 참여하는 개발업무를 담당한다.

시스템프로그래머 :드라이버나 운영체제 기능의 일부를 개발한다.

품질관리자 ː 최근 2∼3년 사이에 나타난 대형 SI 프로젝트의 소프트웨어 품질관리 책임자를 말한다. 세부 업무를 보면 형상관리,

 

위험관리 등의 업무를 맡고 있다. ISO 9000, ISO 12207에 대한 연구를 별도로 해야 한다.

업무분석가 ː 주로 기업의 회계나 운영 시스템에 대한 업무를 컨설팅해 해당 조직에 맞는 설계를 내놓는 역할을 한다. 업무능력과

IT 능력을 어느정도 겸비하면 상대적으로 많은 연봉을 받을 수 있기 때문에 경영, 회계, 산업공학을 전공자가 많이 지원을 하는 분야다. 국내에 있는 외국계 컨설턴트들은 대개 업무분석가 또는 업무 컨설턴트인 경우가 많다.

프로젝트관리자 ː 프로젝트 진행의 모든 책임을 맡고, 예산부터 최종 결과물을 일정에 맞춰 진행하도록 감독한다. 현재는 경력 5년 이상인 개발자가 맡는 경우가 많은데, 프로젝트 관리를 제대로 하려면 SPICE나 CMM에 대한 학습이 필요하다.

전문테스터 ː 전문테스터는 아직 국내에서는 정착되지 않은 직업이다. 보통 개발자로서는 능력이 부족하지만, 개발을 이해할 수 있는 자가 그 역할을 담당하거나 신입사원이 담당하는 경우가 많다. 외국에는 개발자 1명당 테스터가 2명이라는 말이 있을 정도로 프로그램의 테스터에 대한 중요성을 인식하고 있지만, 국내에서는 개발자가 테스트까지 전부 맡아하는 경우가 많다. 그러나 이 분야도 앞으로는 품질관리가 중요해지면서 전문화될 가능성이 크다.

시스템엔지니어 ː 개발된 소프트웨어의 설치와 설치시에 발생하는 문제점, 운영시에 발생하는 문제에 대한 대책을 기술 지원하는 역할을 맡고 있다. 대개는 시스템엔지니어링 교육을 받거나, 운영체제를 잘 다루는 개발자가 맡기도 한다.

웹 디자이너 ː 웹 디자이너는 웹에서 필요로 하는 이미지 제작 업무 외에 DHTML과 자바 스크립트를 사용해서 홈페이지를 구성할 수 있는 능력을 갖춰야 한다. 웹 디자이너를 보면 이미지 도구에 의존적인 경우와 스스로 이미지를 창조하는 능력을 가진 경우로 나뉘는데, 창조력이 없다면 이미지 제작은 한계에 부딪히게 된다.

아키텍처 ː 소프트웨어에 대한 비전과 미래, 방향을 제시하는 사람으로서 미국의 빌게이츠 회장이 마이크로소프트에서 이 역할을 맡고 있다. 일반적으로 CIO가 전산 정책 결정의 최고 의사결정자라면, 아키텍처는 소프트웨어의 개발 방향 결정자라는 점에서 조금 차이가 있다.

기술컨설턴트 ː IT 관련 기술에 대한 컨설팅을 주업무로 한다. 국내에서는 활동하는 컨설턴트가 몇 명 되지 않는다. 기술 컨설턴트는 이론과 실무를 겸비해야 하므로 30대 초반의 차장급이어야 하는데, 국내에서는 병역문제로 30대 초반에 개발경력 경력 7∼9년차인 차장급이 거의 없기 때문이다.

감리컨설턴트 ː 국내에서 활동하는 컨설턴트의 대부분이 이에 해당하는데, 개발 전에는 업체 평가업무를 개발 후에는 개발된 소프트웨어에 대해 평가하는 역할을 한다. 대개 40대 후반에서 50대 초반에서 많이 활동하는 분야다. 감리 컨설턴트는 ISO 9000 심사관 자격증을 하나 정도는 가지고 있다.

전문기고가 ː 전문기고가는 기술분야의 기고를 업으로 한다. 국내 여건상 기고료가 매우 낮은 편이고, 출판사에서 높은 인세를 꺼려하고 있다. 게다가 책이 많이 팔려야 1만부이고 대부분 2∼3천부 정도만 팔리므로 생계 유지가 어려워 대부분 강사를 겸하고 있다. 외국에서는 전문 기고가는 백만장자들도 많다는 점에서 우리 나라와는 많은 차이를 보인다.
이와 같이 회사, 부서에 따라 요구되는 개발자의 성향도 다르고 같은 회사에서 내에서도 역할에 따라 다양한 직업이 있다는 점을 생각해 진로를 정하기 전에 많은 고려를 할 필요가 있다. 한 번 발을 들이면 분야를 바꾼다는 것은 매우 힘들므로 최소한 5년 앞을 내보다고 진로를 결정해야 할 것이다.

  마지막으로 소프트웨어 분야가 여성적인 직업이라는 점에 주목을 하자. 섬세함과 정교함이 요구되는 분야가 바로 소프트웨어 분야다. 그런데 정작 여성들은 개발자로서의 능력을 인정받는 경우가 매우 드물다. 그보다는 여성스러운 남성, 섬세한 남성들이 더 두각을 나타내고 있다.
  이런 현상은 여성들이 밤낮없는 근무시간과 끝없는 변화의 요구를 수용하기 어렵기 때문으로 보인다. 또한 여성 개발자에 대한 경영자나 관리자의 기피현상도 들 수 있다. 여성 개발자는 프로젝트가 완료되기 전에 그만두는 경우가 왕왕 있고, 서약서를 쓰고서도 계약근무기간을 지키지 않거나, 남자보다는 사소한 이유로 회사를 그만두는 일이 많다는 것이 경영자의 불만이다.
소프트웨어 개발분야는 그 어떤 분야보다 여성이 진출하기 쉬운 분야인데, 몇 가지 장벽으로 그 능력을 제대로 발휘하지 못한다면 국가적인 손실이라고 할 수 있다. 여성이 필요한 곳에 여성이 기피된다는 것은 사회적인 편견도 있겠지만, 소프트웨어 개발사의 근무형태 개선 없이는 여성이 제대로 역할을 하기 어렵다.
  어떤 개발자가 될 것인가 요즘 IT 업계에 사람이 부족하다고 컴퓨터와 관련이 거의 없던 사람들도 프로그램 개발을 배우겠다고 마구잡이로 덤벼들고 있다. 배우는 것도 좋지만, 개발자로서의 가능성에 대해서는 한번쯤 생각해야 할 것이다. 다음과 같이 개발자가 갖춰야 할 다섯 가지 능력을 기준화했다.

  협동심 : 함께 일할 때 얼마나 동료애를 발휘하며 조직 친화적인지를 나타낸다.

  기술력 : 작업의 기술적 능력으로 개발능력을 나타낸다.

  학습력 : 최소한 영어능력과 지속적인 학습이 가능한지를 나타낸다.

  인간성 : 사람됨됨이를 나타내는 것으로 측정하기 가장 어려운 항목이다.

  인내력 : 실증내지 않고, 얼마나 오랫동안 작업할 수 있는가를 나태낸다.

  이 다섯 가지 능력을 5단계로 나누고, 이 단계를 점수화해 선을 연결하면 자신의 개발자로서의 성향을 알 수 있다. 가장 높은 점수가 5이고, 가장 낮은 점수가 1이다. 여기서는 점수별로 해당하는 예시가 없어 점수화가 다소 어렵지만, 대략적으로 3을 평균으로 생각해 상대적으로 값을 매긴다.
  이 방법은 주로 약점을 분석하기 위해 사용되는 방법인데, 개발자의 유형을 파악하는 데에 적용을 해본 것이다. 아마 <그림 3>처럼 거의 정오각형의 유형이 완전한 개발자의 모습일 것이다. 그러나 이 모두를 다 갖춘 사람은 거의 찾기 힘들다. 실제적으로는 <그림 4, 5, 6>과 같은 형태가 나타나게 된다.
  <그림 4>와 같이 마름모가 나타나는 경우에는 개발자보다는 프로젝트 관리자쪽으로 눈을 돌려보는 것도 좋을 것이다. 기술은 다소 떨어져도 사람을 관리하고 작업에 대한 추진력이 높기 때문에 프로젝트 관리쪽으로 매진하면 좋은 결과를 얻을 수도 있다.
<그림 5>와 같이 우측지시자형은 기술력이나 학습력에 강하나 인간성 부분이 부족해 대인관계에는 어려움이 많다는 것을 뜻하므로 IT 컨설팅에 매진하는 것이 좋다. IT 컨설팅의 경우 단체 작업보다는 업체와 컨설턴트가 단독으로 작업하는 것이 많고 컨설팅을 위한 학습력이 매우 많이 요구되므로 우측지시자형에 적합하다.
  <그림 6>과 같은 사다리꼴형은 인내력이나 협동력이 상대적으로 매우 부족하므로 이런 경우에는 개발에 있어 코어라이브러리를 만드는 작업을 할당받는 것이 좋다. 라이브러리는 특성상 작업량은 적으나 꽤 많은 기술력을 요구하므로 누운 사다리꼴의 경우에 적합하다.
  이와 같이 자신을 판단할 수 있는 좋은 척도가 되므로 직접 스스로의 유형을 테스트해보기를 권한다. 나는 개발자로서 어떤 특성을 갖고 있는지 알 수 있다면 업무를 선택하거나 회사를 선택할 때도 도움이 되리라 생각한다.
  개발자란 예술가와 공학도의 야누스 어느 벤처기업의 이야기는 좋은 개발자의 필요성을 온몸으로 느끼게 해준다. K 기업은 지난해에 S대의 재학생에게 음성합성프로그램 개발을 용역을 줬는데, 개발된 프로그램의 성능이 외국에 비해 세 배 이상이었다.
  그러나 프로그램은 더 이상 개선되지 못하고 제품화에도 실패를 했다. 그 이유는 뛰어난 성능의 프로그램임은 분명한데 개발한 학생 외에는 아무도 수정할 수 없었기 때문이다. 학생은 개인적인 이유로 유학을 떠났고, 남은 개발자들이 제품화를 맡았는데, 여기를 수정하면 저기가 에러가 저기를 수정하면 여기에서 에러가 발생하니, 아무도 그 소스를 수정하지 못했다고 한다. 결국 그 기업은 2년간 투자한 사업을 접어야 했다.
 

 뛰어난 개발자들이 많지만, 좋은 개발자가 적은 이유는 무엇일까. 뛰어난 개발자와 좋은 개발자의 차이는 무엇일까. 그것은 단순한 능력 이상의 것이 요구된다는 것이다. 좋은 개발자가 되기 위해서는 최소 3∼5년 이상의 경력을 가지면서도 스스로 제품을 만들기 위한 정열과 제품을 만드는 능력을 갖는 것은 기본이다. 그 능력 외에 품질을 유지하기 위한 마인드가 필요하다. 그런 마인드가 없다면 좋은 소프트웨어를 만들 수 있는 좋은 개발자란 없다.
  국내는 IT 벤처의 열풍으로 수만명의 학생이 전공과는 관계없이 전산을 배운다고 한다. 지난 1년간에 정부에서 전산관련 취업교육에 사용한 비용만 수천억원에 이른다. 학원은 여기저기서 강사 구하기에 바쁘다고 한다. 그러나 속지 말라. 한줌의 지식보다 더 중요한 것은 마인드라는 것을!

  개발자란 예술가적인 정렬과 예리함, 감각을 지녀야할 뿐 아니라 평가하고 측정하고 품질을 유지하는 능력 또한 지녀야 한다. 왜 우리는 전세계적으로 팔리는 소프트웨어가 거의 없느냐의 문제에 대한 답이 아닐까 한다.
  바로 좋은 개발자가 없기 때문이다. 좋은 개발자의 능력을 가진 자가 한국에 있다고 해도 사회적 문화적 환경이 뒷받침되지 못한다면 개발자는 그 빛을 발하기 힘들다. 바로 여러분이 좋은 개발자이길 바란다. 오늘도 '개발의 득도'를 위해 전진해보자.

  정리 : 이종림 nowhere@sbmedia.co.kr