'아키텍트'에 해당되는 글 2

  1. 2009.12.08 소프트웨어 개발 단가 산정이 한심한 이유 (30)
  2. 2009.12.07 '그 까짓 소프트웨어 왜 못만드냐'는 착각 (28)

소프트웨어 개발 단가 산정이 한심한 이유

IT와 세상 2009.12.08 23:00

소프트웨어는 투입한 시간과 비례하는 것일까?

 

미국의 과학 고등학교에서 있었던 일이다. 이 학교 교과목에는 C 프로그래밍 실습이 있다. 이 수업 시간에는 매주 새로운 숙제를 주고, 학기말이 되면 그 숙제의 결과를 합해서 최종 점수가 정해졌다. 그런데, 러시아에서 이민을 온 어떤 학생이 수업 시간을 지루해하면서 평상시 숙제를 내지 않는 것이었다.

그 친구가 학교 수업보다 컴퓨터에 빠져 사는 것을 본 선생이나 친구들은 의아해했다. 그런데, 학기말 1주일을 앞두고 이 친구는 한 학기 동안의 숙제를 한꺼번에 해치우는 게 아닌가? 더욱이 선생이 준비한 답안보다 훨씬 성능이 좋고 적은 코드로 컴팩트(compact)하게 구성한 결과에 선생이나 학생들은 모두 혀를 내둘렀다.
 
러시아 출신 학생이 일주일만에 한 학기 끝낸 비법은?

 

이 친구는 머리 속으로 가장 효과적인 알고리즘을 창의적으로 만든 것이다. 물론 고교 과정 실습에 나오는 과제가 기껏해야 얼마나 대단하냐고 할 수 있다. 그러나, 과학 고등학교에 선발될 정도면 일반인보다 컴퓨터에 일가견이 있는 청소년들이다. 그런 그들이 매주 일정 시간씩 공들여 한 숙제를 합한 것보다 뛰어난 기량을 단 일주일 내에 발휘한 것이다. 바로 이것이 소프트웨어 개발 현장에서 빈번히 벌어지는 현상이다. 투입된 시간의 양과 결과물은 상관 관계가 적다.

 

만일 이 러시아 친구의 프로젝트를 한국에서 소프트웨어 개발 단가로 산정한다면? 일주일의 작업이나 인력투입(MM, Man/Month)으로는 최저 비용에도 못 미친다. 오래 전 어떤 유명 대학의 컴퓨터공학 교수가 소프트웨어 심사를 하면서, 코드가 몇 줄이지?”를 기준으로 삼으려는 것을 보고 기가 찼다. 컴퓨터를 전공하는 교수가 저런 마인드를 가질 정도라니! 그 분이 공부한 학문은 소프트웨어가 공학적 측면에서 자리 잡기 전이었던가? 아무리 그렇게 생각하려고 해도 상식적으로 이해가 가지 않았다.
 
현행 소프트웨어 개발 단가 산정의 문제점은?

 

그런데, 아직도 우리 사회에서 대부분의 소프트웨어 개발 프로젝트는 이런 식으로 산정한다. 개선해야 한다고 소리쳐 외치면, ‘뚜렷한 대안이 없다는 것이 대답이다. 누가 뛰어난지 판정하기 힘드니 공평하게라도 하는 게 맞다는 취지다. 그러니, 소프트웨어 개발자로 고급 연봉자가 나올 수가 없다. 프로젝트를 할 때도 뛰어난 개발자에 몇몇 인원을 끼워넣기 해서 돈을 받아내는 풍토가 사라지지 않는 이유이기도 하다.

 

우리가 소프트웨어 강국이라고 부러워하는 인도를 보자. 인도에서는 대학 졸업 5년 차 월급이 2만불 정도라면, 소프트웨어를 설계할 수 있는 아키텍트(architect)는 최소 10만 불을 넘어선다. 인도에서 10만불 연봉이면 최고급 생활을 영위할 수 있다. 실력에 따라 얼마나 더 액수가 올라갈지 예측하기 어렵다. 그만큼 역량의 차이가 월등하게 나는 게 소프트웨어 인력의 실상이다.

 

인도는 소프트웨어 개발 강국으로 재탄생했다. 사진은 10달러 노트북.


소프트웨어 개발자들에게 돈을 벌 수 있다는 꿈을 주어야

 

소프트웨어 개발자의 꿈은 고급 설계자인 아키텍트(architect)가 되는 것이다. 투입한 시간과 일정에 따라 돈을 버는 세상이라면 이런 고소득 전문가가 되는 것은 애당초 불가능하다. 공공 기관, 대기업을 막론하고 소프트웨어 단가는 모두 예전에 만들어 놓은, 소위 과기부, 정통부 단가에 따라 비용을 산정한다. 설상가상인 것은 용역 프로젝트라며 지적 재산권까지 내놓으라고 한다.


우리 나라에는 세계적 기업이 된 대기업들이 많다. 그런데, 이런 기업들도 소프트웨어에 관해서는 '라이센스'라는 상식적 개념도 적용하기를 거부한다. 용역으로 하는 것에 대해 감지덕지하라는 태도로 까다로운 법률 계약서를 통해 지적재산권을 다 가져간다. 단가는 국내 정부 기준에 맞추면서 품질(quality)에 대한 요구는 글로벌 스탠다드다. 이런 환경에서 양질의 소프트웨어 인력이 양성되겠는가?
 

젊은 친구들이 너무 돈만 밝힌다. 나이가 들면서 경륜이 생기는 건데… ”라는 말을 하는 어른들도 있다. 그러면, 운동 선수는 어떠한가? 그들은 체력이 한계가 있어서 더 뛰고 싶어도 못한다. 어린 시절에 잠재력을 보이다가 30세에 가까우면 완숙미를 보이고, 30대 중반을 넘어서면 은퇴를 하게 된다. 그 이후로는 지도자의 길을 걷게 되고

 

소프트웨어 개발자는 그나마 체력으로 하는 게 아니라서 운동 선수보다는 프로 생명이 더 길지만, 그래도 나이가 들수록 실전 능력은 크게 떨어진다. 뛰어난 개발자들은 20대에 백만장자가 나올 수 있어야 한다. 더 나아가 완숙기에 이르면 최고의 연봉을 받고 경영자, 지도자의 길을 걸을 수 있어야 한다. 그런 라이프 사이클이 형성되어야 좋은 인력들이 소프트웨어 개발자의 길로 들어설 것이다.

 

고급 아키텍트(architect)가 되겠다는 꿈을 키울 수 없다면, 그래서 풍성한 삶을 살 수 없다면, 소프트웨어 개발을 누가 하려고 하겠는가? 소프트웨어를 해서 실력만 갖춘다면 돈을 벌 수 있도록 하는 것이 근본 대책이다. 이를 외면한다면 어떤 지원 프로그램을 동원하더라도 소프트웨어 강국이나 IT 강국은 공염불에 그칠 수밖에 없다.

                                        (아이뉴스24 컬럼 기고를 보완한 글입니다)

 

 
신고

'그 까짓 소프트웨어 왜 못만드냐'는 착각

IT와 세상 2009.12.07 12:53

소프트웨어 개발이 단순한 프로그래밍이란 착각

누구나 컴퓨터를 접하게 되면 작은 프로그램을 직접 만들어 보는 경험을 하게 된다
. 어린 나이에도 베이직(BASIC) 같은 언어는 쉽게 깨우칠 수 있다. 재미있는 표도 만들어 보고 그림을 화면에 그려 보기도 한다. 처음에 이런 것이 신기해서 소프트웨어에 빠져든 개발자도 많다.

 

BASIC 프로그래밍

이공계 전공자라면 컴퓨터 공학을 전공하지 않더라도 크고 작은 프로그래밍을 할 줄 알아야 한다. 전자공학의 경우 자신이 만든 하드웨어를 동작시키고 제어할 수 있는 소프트웨어를 만들어야 한다.

IT
가 아닌 과학이나 공학을 전공하더라도 수치 해석이나 통계 프로그램을 이용해서 분석을 해야 하는 경우가 허다하다. 하드웨어에 밀접한 소프트웨어는 어셈블리 언어로 직접 만들기도 하지만, 대부분의 경우 고급 언어를 사용한다. 프로그래밍하는 원리는 대체로 비슷하다.

이 정도의 단순한 소프트웨어를 만들 경우 소프트웨어 공학을 제대로 배울 필요까지는 없다. 프로그래밍 과목에서 몇 가지 실습을 하는 정도로 충분하다. 필요하면 패키지 소프트웨어의 라이브러리(library) 기능을 잘 활용해서 프로그램의 전개 과정(procedure)을 논리적으로 구성하면 된다. 혹 잘 안 풀리더라도 몇 개 명령어(instruction)와 규칙을 책에서 확인하고, 잘 아는 친구들의 도움을 받아 과제를 마무리하곤 한다.

 
"그 소프트웨어 몇 줄 짜면 되는 거 아니야?"

물론 복잡한 수준까지 발전하는 경우도 있지만, 작은 규모의 프로그램 개발을 주위에서 여러 형태로 접하다 보면 자신이 프로그래밍한 경험을 소프트웨어 개발이라고 확대 해석해서 별게 아니라고 착각하는 경향이 있다. “그거 몇 줄 짜면 되는 거 아니야?” 이런 생각이 자신도 모르게 의식 속에 스며드는 것이다.

 

물론 단순한 모듈을 구동하거나 라이브러리(library) 함수를 불러내어 필요한 데이터를 얻는 행위는 프로그래밍 수준에서 해결된다. 그러나, 전체의 구조를 구성해서 논리적으로 작동하는 프레임워크를 만드는 것은 전혀 다른 차원의 문제다. 프레임워크를 만들려면 데이터 구조(Data Structure), 프로세스(Process)를 정립하고 여러 환경적 변수에 따라 치밀하게 동작하도록 설계해야 한다.

 

이런 소프트웨어는 단순하게 규정된 단계대로 일방향으로 진행되는 것이 아니다. 어떤 상황이 벌어지느냐에 따라 역동적으로 상호 작용을 하는 살아있는 엔진이다. 때로는 수학이 필요하고, 최적의 알고리즘을 고안하고 적용해야 할 때도 있다. 구글(Google)의 검색 엔진이 뛰어난 이유는 고급 수학과 소프트웨어 공학이 절묘하게 결합했기 때문이다. 여기에 창업자들이 열정을 바친 결과가 세계 최고의 검색 엔진이다.

프로그래밍과 아키텍처 소프트웨어 공학의 차이

 

따라서, 단순 프로그래밍과 창의적인 아키텍처(architecture)를 만드는 소프트웨어 공학은 구별해야 한다. 고급 빌딩을 건설하는 현장을 생각해 보자. 건설 노동자가 작업을 마무리하기 위해 자신의 노하우를 적용하는 업무와, 그 빌딩의 전체 구조를 치밀하게 설계하는 업무는 엄연히 다르다. 건축 설계는 주어진 디자인과 지반 여건을 토대로 안전하고 효율적인 구조를 만들어 내는 전형적인 지식 노동이다. 동일한 건설 업종에 종사하지만, 초점은 완전히 다르지 않은가? 똑같이 컴퓨터를 두드리고 있다고 해서, 같은 언어를 사용한다고 해서, 한 통속으로 소프트웨어 개발이라고 간주해서는 안 된다.

 

이런 착각이 소프트웨어 개발이라면 나도 해 봤는데…” 하는 인식을 가지게 되는 요인 중 하나다. 그러다 보니 소프트웨어 개발을 만만하게 보는 분위기가 있다. 고급 소프트웨어 개발을 해도 존경 받지 않는 이유가 여기에 있다. 그까짓것 왜 제대로 못 만들어? 그리고, 만드는 데 뭐 그리 비싸? 다 사람 장사 아니야?”하는 심리를 느끼는 것은 지나친 컴플렉스일까? 소프트웨어가 허드렛일, 3D 업종으로 추락한 배경에는 그런 인식이 한 몫 한다고 생각한다.

(아이뉴스 칼럼 기고문을 보완한 것임)
제 블로그가 마음에 들면 구독+해 주세요
신고


티스토리 툴바