[개발/컬럼] 소프트웨어는 누가 개발해야 하는가?

[개발/컬럼] 소프트웨어는 누가 개발해야 하는가?

소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
     



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다. 

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다. 

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다. 

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다. 

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다. 

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다. 

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다. 

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼. 

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다. 

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다. 

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다. 

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷