[지디넷코리아]몇 주전 토요일 업계의 저명한 개발자들이 모여 ‘소프트웨어 개발자 대토론회’ 라는 행사를 했다. 토요일을 씁쓸하게 보내고 싶지 않아서(?) 다른 모임에 참석했지만, 이정환 닷컴의 지상 중계를 보면 좋은 이야기가 많이 나왔다고 한다. 토론의 결론이 말하는 대로 경력과 실력을 더 쌓으면 인정 받는 개발자가 될 것이라는 기대와 달리 현실의 벽은 여전히 높아 보인다.

실제로 소프트웨어진흥원 신임 원장의 취임 일성에도 ‘개발자 처우 개선’이 들어 있다. 그는 “4D 업종이라는 신조어가 탄생할 정도로 소프트웨어 개발자들이 어려움을 겪고 있는 것으로 안다"며 "노력한 만큼 대접을 받을 수 있도록 개발자 처우개선에 힘쓰겠다”고 했을 정도다. 이런 이야기가 나온 것이 어제 오늘의 일도 아니고 새삼스럽게 이런 글을 쓴다는 게 부담 되지만 이 글에서 평소 느끼던 개인적인 소회를 한 두 가지 이야기 해보고자 한다.

인간성이 상실되고 있는 소프트웨어 개발 현장
어떤 개발자가 나에게 소프트웨어 개발이 마치 건설 현장과 똑같이 되어 가고 있다고 이야기 했다. 한 때 일등 신랑감으로 각광 받던 소프트웨어 개발자가 일용 노동자와 같이 전락하고 있는 데에는 SI(시스템 통합)라는 무시무시한 괴물이 도사리고 있다. 스스로도 인터넷 사업 초기에 S모 대기업이 발주한 SI사업에 참여한 적이 있었다. 선정된 총괄 PM(개발 책임) 업체와 함께 제안서를 넣지 않아서 어렵게 경쟁을 통과해 개별 과제 업체로 선정된 후, 맨 처음 PM의 영업 담당자를 만났다. 그러나, 그는 취조실과 같은 담배 연기 자욱한 좁은 방에서 수주 금액 후려 치기부터 시작하는 것이 아닌가?

사실 Man-Month라는 비 인간적인 개념도 그때 처음 알았다. MM을 맞추기 위해 사람을 50%, 20%처럼 백분율로 자르기도 하고, 머릿수에 따라 돈을 계산하고 있었다. 요즘은 프로젝트 금액을 개발 명세서상의 기능(Function) 난이도와 개수를 토대로 한다지만, 이런 개념 자체가 소프트웨어 개발자를 단순 노동자로 전락 시키는 데 단초를 제공하고 있다. 도대체 소프트웨어 개발이 꿈꾸는 창의적이고 인간적인 방법론은 눈을 씻고 봐도 찾기가 어렵다.

다단계 하청 구조도 큰 문제지만 SI 업계에서 보편적으로 통용되는 프로젝트 관리 기법이 교과서인양 업계 전반으로 퍼지고 있는 것도 문제라는 것이다. 많은 사람들이 SI에서 적용하던 프로젝트 관리 방법을 공공연하게 일반 소프트웨어 개발에도 적용하려고 한다. 그러나, 뭔가 정석을 따라 효율적인 개발이 가능한 것처럼 포장되는 경우가 많이 있다. 현대적인 소프트웨어 개발 방법론은 우리 SI 업계가 가지고 있는 것과는 많이 다른데도 말이다.

프레드릭 브룩스는 ‘Man Month의 미신’에서 소프트웨어 프로젝트에서 지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다는 생각과 함께 가장 중요한(Mission Critical) 기능에 대한 프로토 타입을 통한 선행 실험이 필요하고, 욕심 없는 작고 견고한 시스템 및 개발자간 커뮤니케이션을 소프트웨어 개발의 가장 중요한 덕목으로 제시하였다.

소프트웨어 개발자의 처우가 나쁘다고 여기는 가장 큰 이유는 돈의 문제가 아니다. 바로 내가 도구라고 여겨지는 자괴감이다. 다람쥐 쳇바퀴 돌듯이 코딩을 하고 집에 돌아와 보면 허무하고 남는 것이 없다. 이런 현실은 전반적인 소프트웨어 개발자가 처해 있다. 따라서 제일 중요한 것은 현장에서 인간성을 회복하고 창의적으로 핵심 기능에 집중하는 개발 방법론을 채택 하는 것이다.

몇 년 사이에 우리 나라에서 익스트림 프로그래밍(XP), 페어(Pair) 프로그래밍, 애자일(Agile) 프로그래밍 이라고 불리는 기법이 유행처럼 번지고 있는데 이는 매우 바람직한 현상이라고 할 수 있다. 문제는 이걸 받아 들이고 적용 해서 우리 것으로 만드는 일이다. 물론 이것만이 해결법은 아니다. 중요한 건 너와 내가 소통할 수 있는 현장을 만드는 것이다.

롤 모델(Role Model)과 비전(Vision)의 부재
또 하나의 문제는 소프트웨어 개발을 계속했을 때 내가 앞으로 무엇이 될 수 있을까가 명확하게 보이지 않는다는 것이다. 외국은 업력(業歷)이 40년 가까이된 백발이 무성한 소프트웨어 개발자가 존재한다. 그러나, 국내는 30대 중반만 되어도 개발 관리자로 갈 것이냐 말 것이냐를 선택 받는다. 다른 선택의 여지가 별로 없다.

필자가 아는 어느 회사에 소프트웨어 개발만 15년을 해 온 사람이 있었다. 이 회사는 소프트웨어 개발자를 선택한 사람에게는 계속 그 직무를 수행하도록 해 주는 곳이었다. 국내에서도 그런 곳은 몇 안 된다. 하지만, 이 사람이 계속 소프트웨어 개발자로 남기에는 회사에서 너무 많은 유혹이 생겼다. 개발팀장이 더 대우 받고 업무 성과가 함께 공유되지 않는 상태에서 소프트웨어 개발자로 남는다는 게 무의미 해 보였기 때문이다. 결국 그는 다른 회사로 이직을 했고, 그를 자신들의 모델로 생각했던 많은 후배 개발자들이 실망했다. 이것은 하나의 사례이지만 시사해 주는 바가 크다.

왜 소프트웨어 개발자에게는 관리자 혹은 개발자 만을 생각하는 것일까? 정말 모델이 될 만한 사람이 없을까? 실상을 보면 그렇지는 않다. 우리 시대의 유명한 IT기업 CEO 및 CTO들은 80년대 이공학 계열 진흥 시절에 대학을 다녔던 분들이다. 어느 학교는 특성화 공대라는 미명하에 400명씩 입학 시켜 140학점의 전공 과목을 꽉 채워 듣도록 했다(현재 학부제 하에서 전공 이수 과목은 70학점이 채 안 된다.). 이들이 국내 IT 산업을 이끌었고 이 세대는 우리 경제에서 가장 중추적인 위치에 있다. 이들은 다양한 기업가 정신을 가진 우리들의 선배들이다.

90년대에 들어서서 인터넷의 등장과 닷컴 붐을 통해 이들 선배들과 후배들이 연결 되었다. 세대간 연결은 자연스럽게 롤 모델과 비전의 공유로 이어진다. 그러나, 최근에는 이들과 차세대 간의 단절 현상이 일어나고 있는 것처럼 보인다. IT 분야나 소프트웨어 개발 보다 더 좋고 장래가 유망한 직종이 인기가 있는 현상과도 맥락을 같이 하기도 하지만, 공유할 만한 공통 관심사가 세대간 연결이 부족한 것도 그 이유라고 할 수 있다. 90년대 중반에 소프트웨어 개발자들이 주축이 되었던 벤처 기업가 정신은 이제 보이지 않고 있는 것은 개인적으로 매우 유감스럽다.

소프트웨어 개발자의 처우나 비전에 대한 문제는 매우 복잡 다난 하다. 사람들이 제시하는 솔루션도 가지 각색이다. 이 컬럼에서 언급한 두 가지는 필자가 평소에 생각해 오던 것이다. 소프트웨어 개발 현장에서 인간미를 회복하자거나 세대간 공감을 통한 비전의 공유는 매우 이상적인 구호와 같은 것이라고 생각할 수 있다. 그러나 이러한 공감의 토대가 없다면 백약이 무효하다고 본다. 마지막으로 좀 더 많은 고민을 하시는 분들은 공감을 불러 일으키기에 충분한 피플웨어의 생각을 함께 공유해 보시기를 추천한다. @