리눅스 모바일(LINUX Mobile)의 약자로 휴대폰 및 스마트폰에 필요한 임베디드 리눅스 기반 SW 및 관련 플랫폼을 통칭하는 세계적인 상징 단어다. 2007년초 삼성전자·모토로라·NEC·파나소닉 등 4개 단말기 제조업체와 NTT도코모·보다폰 등 2개 통신사업자가 LiMo재단을 설립해 세계 조류를 선도하고 있다. 삼성전자·LG전자·SK텔레콤이 이사회 멤버로 참여했으며, KT·삼성SDS·이노에이스·아로마소프트·ETRI가 협력 회원사로 가입됐다. 모토로라는 휴대폰사업의 퇴조로 올해 LiMo 이사회 멤버에서 탈퇴했다.
[지디넷코리아]IT조직에서는 기존에 존재하지 않는 ‘어플리케이션’이나, ‘인프라’ 또는 이들의 복합체인 ‘시스템’이 새로 도입되는 경우를 ‘프로젝트’라고 부른다. 또는 금융권에서 수년 전부터 진행해 오고 있는 ‘차세대 전환’과 같이, 기존에 존재하는 어플리케이션, 인프라 또는 시스템이지만, 대규모 ‘개편’이 일어나는 것들도 ‘프로젝트’라고 부른다.
이러한 ‘프로젝트’의 대척점에는, 기존에 존재하는 어플리케이션, 인프라 또는 시스템의 가벼운 변경을 의미하는 ‘유지보수’가 존재한다.
하지만 IT조직들을 관찰하다보면, 프로젝트와 유지보수를 구분하는 기준이 모호하거나, 기준이 있다고 하더라도, IT품질이나 IT보안 관점에서는 치명적인 누락을 감수하고서라도 굳이 유지보수로 분류하고 있는 이상한 상황들을 자주 맞닥뜨리게 된다.
이번 칼럼에서는 IT조직내부의 이해관계에 따라 혼용되고 있는 프로젝트와 유지보수 아야기를 해 보겠다.
* 혼동을 방지하기 위해 IT인프라보다는 주로 어플리케이션 개발에 초점을 맞추어 이야기를 풀어보겠다.
■‘투자’ 유무에 따라 프로젝트?
새로운 비용이 추가되는 경우에만 프로젝트로 다루는 IT조직들이 있다.
‘기존’의 개발인력만으로는 사용자의 추가 개발 요구를 만족하지 못할 경우에는 외부의 IT자원을 투입해서 개발하게 된다. 이 경우에는 추가 투자가 발생하게 되므로, 내부적으로 기획부서와 재무부서를 통과하게 되는 투자품의 과정을 거치게 된다.
개발 부서 입장에서는 자체 부서내에서 진행하지 못하고 전사 부서의 결재 라인을 거쳐야 하므로, 이러한 개발을 ‘공식’적인 프로젝트의 형태로 진행할 수 밖에 없다.
반면에, 개발 요구에 대해 추가 투자 없이 내부 개발 인력만으로 진행이 가능하다고 한다면, 프로젝트가 아닌 ‘유지보수’로 대부분 처리하게 된다. 전사 부서의 결재 라인을 거치지 않기 때문에 이러한 개발건에 대해서는 IT조직 자체의 ‘관리하’에 둘 수 있게 된다.
아웃소싱을 자주 사용하는 IT조직에서 이러한 경향을 볼 수 있는데, 여기에서의 프로젝트와 유지보수의 정의는 결국 이렇다.
“프로젝트: 추가 투자가 발생하는 개발요청건, 유지보수: 자체 자원으로 처리가능한 개발요청건”
■물리적인 ‘규모’에 따라 프로젝트?
개발 요청건을 처리하기 위해 소요되는 물리적인 규모를 기준으로, 프로젝트를 결정하는 IT조직들도 많이 있다.
개발자 1명이 한 달 내내 해당 개발 요청건을 처리하게 된다면, 이를 1M/M(Man/Month)라고 부르고, 특정 M/M 규모 이상(예를 들면, 2M/M, 또는 3M/M)의 자원이 소요되는 개발 요청건을 프로젝트라고 정의하고 있다.
이 IT조직들은 개발요청건이 신규 어플리케이션인지 아닌지의 여부보다는, 자원 투입 규모에 따라 프로젝트 유무를 결정하게 된다. 이들의 용어정의는 다음과 같다.
“프로젝트: n M/M 이상의 자원이 소요되는 개발요청건, 유지보수: n M/M 이하의 자원이 소요되는 개발요청건”
■프로젝트의 존재이유
IT조직들내에서 조차 혼란스러운 프로젝트와 유지보수의 기준을 맞닥트릴 때마다, 프로젝트의 존재 이유를 생각하게 한다.
프로젝트는 왜 유지보수와 구분되어야 하는가? 누가 어떤 필요에 의해서 이처럼 다른 이름을 불러 주는 것일까? IT분야가 아닌 곳에서도 프로젝트라는 이름을 자주 사용한다. 건설 분야의 **단지 개발 프로젝트, 연구분야에서는 AA제품 개발 프로젝트 등이 그 예다.
이들 분야에서의 프로젝트들은 시작과 끝이 명료하다. 프로젝트의 자원을 투입한 결과로 새로운 단지가 조성되거나, AA제품의 시제품이 완성되는 것이다. 기존에 없던 것이 새로 생기거나, 기존에 있더라도 전폭적으로 바뀌게 되는 결과를 얻을 수 있다.
IT분야에서의 프로젝트를 동일한 관점으로 본다면, 프로젝트는 새로운 어플리케이션을 창조하게 하거나, 기존의 어플리케이션을 대폭적으로 변경하게 만드는 활동이라고 할 수 있다. IT분야의 ‘프로젝트’는 결국, 큰 변화를 성공적으로 운영하고 당초의 개발목적을 달성할 수 있도록 도와주는 유용한 도구라고 볼 수 있다.
여기에는 외부자원이 투입될 수도 있고 아닐수도 있으며, 또 규모가 클 수도 있고 상대적으로 작을 수도 있는 것이다.
■IT조직의 기피대상, 프로젝트
IT조직에서 근무해본 경험이 있는 사람들은 IT조직이 프로젝트를 기피하는 경향을 보인다는 것을 안다.
일단 개발건이 프로젝트로 결정되면, 해당 프로젝트에 포함된 사람들은 프로젝트의 까다로운 절차, 내외부 감리 및 많은 양의 산출물 등을 우선적으로 떠올리며 괴로워한다.
안그래도 프로젝트의 일정을 맞추려면, 밤을 세워도 모자랄 판에, 절차도 지켜야 하고, 내외부 감리도 신경써야 하며, 활동들의 대부분을 기록으로 남겨야 하니 프로젝트에 참여하는 개발 인력들은 개발건이 프로젝트로 선정되는 것을 좋아할리가 없다.
그러다보니 IT조직내에서 유지보수와 프로젝트를 ‘주체적’으로 수행하는 부서에서는 가능한한 개발건들이 프로젝트보다는 유지보수로 처리되기를 ‘희망’하는 것이다.
■유지보수에 숨겨진 프로젝트들
프로젝트가 없이 유지보수활동으로만 개발이 일어나고 있다고 주장하는 IT조직들에는 숨겨진 프로젝트들이 존재한다. 외부자원이 투입되는 경우에만 프로젝트로 결정하는 IT조직의 경우, ‘내부자원’이 투입되는 새로운 어플리케이션이나 대폭적인 변경건이 발생하는 경우가 있다.
특히 요즘처럼, IT경기가 어려운 시점에는 IT조직이나 사용자 조직에서 신규 투자가 동결되거나 긴축 모드로 운영되는 경우가 많다. 이런 경우 내부자원을 최대한 활용하라는 재무 지침에 따라, 모든 개발건들을 내부 개발 인력으로 처리하게 된다. 이때 추가 비용이 발생하지 않으므로, 모든 개발건들은 ‘유지보수’로 처리가 된다.
새로운 어플리케이션을 창조하거나 기존의 어플리케이션을 대폭적으로 변경하게 하는 개발건이라하더라도 추가 비용이 발생하지 않기 때문에 일상적인 유지보수로 다루어 지게 되는 것이다.
물리적인 규모로 프로젝트를 결정하는 IT조직의 경우도, 규모는 작지만 새로운 어플리케이션을 만드는 경우도 있으며, 큰 규모의 프로젝트를 쪼개서 여러개의 유지보수건으로 위장하는 경우도 있다.
■숨겨진 프로젝트의 문제점들
신규 어플리케이션의 도입이나 기존 어플리케이션의 대규모 변경을 반드시 프로젝트로 수행해야 하는가에는 여러가지 의견이 있을 수 있다. 만약 이러한 개발건들을 ‘유지보수’를 통해서도 성공적으로 완료할 수 있다면, 프로젝트로 수행하지 않는 것에 대한 비난에서 자유롭지 않을까?
하지만 현실은 그렇지않다. 유지보수로 완료된 숨겨진 프로젝트들의 ‘진행과정과 결과’들을 살펴보면, 부실 투성이인 경우가 대부분이다.
어플리케이션을 하나의 ‘제품’으로 본다면, 숨겨진 프로젝트로 만들어진 제품들은 불량률이 높다. 또 소비자 보호를 위해 필요한, 제품의 ‘안전기능’에 해당하는 어플리케이션의 ‘보안기능’도 고려가 되지않았거나, 고려되었다 하더라도 제대로 작동하지 않는 경우가 많다. 이것은 IT조직의 유지보수 활동이 프로젝트 활동을 대신하기에는 무리가 있다는 반증이며, 숨겨진 프로젝트가 많이 존재하는 IT조직일 수록 이러한 경향이 더 크다는 것을 경험으로 느끼고 있다.
■유연한 프로젝트의 도입 필요
개발과 관련하여 ‘무겁고 유일한’ 프로젝트방법론을 가지고 있는 IT조직들의 공통점은 스스로 약속한 방법론의 덫에 걸려 있다. 모든 프로젝트에 대해서 높은 수준의 성숙도 모델을 적용하기로 천명한 IT조직들이, 유연성 없는 유일의 방법론을 무거운 방법으로 고수하겠다고 약속하게 된다면, 숨겨진 프로젝트의 함정은 언제나 존재하게 되어 있다.
프로젝트의 개별 산출물에 집중하기 보다는, 프로젝트를 통해서 달성해야 하는 ‘원칙과 목적’을 이해하고 이를 중요시하게 된다면, 프로젝트의 성격과 크기에 맞는 유연한 프로젝트 방법론을 창조해낼 수 있을 것이라고 본다.
형을 형이라 부르지 못하는 ‘호형호부의 한’은, 프로젝트를 프로젝트라고 부르지 못하는 IT조직들에게도 존재하고 있다. 프로젝트는 프로젝트로 부르는 것을 이제 그만 허락하도록 하자.
[지디넷코리아]한국 IT의 부조리. 그 원인은 의외로 깊은 곳, 우리 사회가 안고 있는 관성에 있었다. 제조업과 건설업 중심의 산업 구조는 하드웨어와 SI 중심의 IT 트렌드로 이어진다. 대기업과 그 계열에 줄 선 IT 서비스만이 서바이벌 가능한 대기업 편중화 현상도 한국 경제의 축도 그대로다. 중소 소프트웨어 하우스는 화석이 되어 버렸고, 벤처 성공 스토리는 10년 전의 추억이 되어 가고 있다.
이 빙하기를 타개할 근본적 변화란 문제의 원인을 이해하고 그 것이 해소될 수 있는 시스템을 모색하는 과정에서 도모되는 무엇일 것이다. 그것은 20세기의 대한민국을 견인해 왔지만 더 이상 기능하지 않는 성장 패러다임을 과감히 버리는 일에서 시작한다. 대마불사적 기업구조의 가부장주의와 사회주의적 관료주의의 모성애에 의한 성장 드라이브는 상부로부터의 정보가 신속 정확하게 집행되어야 하는 제조업이나 건설업에서는 어느 정도 기능해 온 것도 사실이다.
한국을 있게 한 것은 소프트웨어적이라기보다 하드웨어적 견인력이었다. 자유 방만한 창조성과 돌연변이적 혁신보다는 일사분란한 집중경영과 동양적 장인정신에 근거한 점진적 개선 그리고 무모하리만큼 도전적인 ‘하면 된다’의 집행력은 한국의 차별화 요소였고 이에 근거한 영역에서 나름의 입지를 구축할 수 있었다.
국내 유수의 전자 기업들이 지금의 위치에 설 수 있었던 점은 그 차별화 요소를 무기 삼아 글로벌한 태풍에 맞서는 것을 두려워하지 않고 국내시장에 온존하려 하지 않았다는 일종의 열정에 있다. 좋은 물건을 만들면 통할 것이라 우직하게 믿으며 재벌 전체의 응원 속에서 선택과 집중을 할 수 있었던 결단력은 타국의 산업체를 분명 능가했다.
그러나 아이러니컬하게도 이 결단력과 집행력은 이미 정해진 숙제를 고도화하는 카테고리에서는 성공적일지 모르나, 뜬금없이 솟아나 순식간에 하늘을 뒤덮을 정도로 성장할 수도 있는 말 그대로 '벤처'의 영역에서는 그다지 효과적이지 않다.
지금 우리에게 필요한 것은 철두철미한 정부주도의 전략집행이 아니라 계획경제에 의해 성장일로를 달릴 것이라는 근거 없는 낙관을 버리고, 자유로운 발상이 허락되고 장려되는 살만한 공간을 어떻게 빚어낼지, 또 이 땅에서 가능이나 한 일인지 걱정하는 일에 있다. 즉 독립적 개인으로 투명하게 살아 나가며, 스스로의 구체적 아이디어를 추상화할 용기를 보장 받는 일. 이 권리를 지키는 것이다.
대등한 개인. 기회의 평등. 그러한 시도가 현실에서 신속하고 폭발적으로 일어난 사회랄까 대표적 커뮤니티는 바로 실리콘밸리였다. 2차 산업을 넘어선 정보산업의 혁신성이 어떻게 산업 국가의 체질을 극적으로 바꾸는지 드러낸 베스트 프랙티스였다.
이러한 환경적 문화적 토양이 자연발생적으로 이루어진다면 오죽 좋으련만, 이는 그 곳에 모인 구성원의 성숙도, 사회적 자본의 충실함 등 모든 조건이 맞아 떨어져야 하는 어찌 보면 원시 스프(primordial soup)의 기적에 가까운 일.
그러나 이 야생의 기적을 목격할 수 있었던 이상 이를 온실에서 재현이 가능할 터, 그 혜택을 입지 못한 후발 국가의 정부가 해야 할 역할이란 바로 이 재연의 환경을 갖추는데 있다. 밸리란 조성하기만 하면 되는 전제 조건이 아니라 자유로운 문화가 빚어낸 결과이기 때문이다. 그러나 안타깝게도 이러한 토양이 기능하고 있는 곳은 현재로서는 실리콘밸리와 스캔디나비안 스쿨의 전통이 살아 있는 유럽 정도일 것이다.
실리콘밸리나 스캔디나비안 문화에서 21세기를 대표할만한 창의적이고 기업과 프로젝트와 인재가 끊임없이 샘솟는 이유는 개인적으로 좋아하는 것이 크레이지한 아이디어로 실현되고 그 아이디어를 낸 사람을 믿고 밀어주는 '사회적 자본으로서의 지식 산업 네트워크'가 형성되었기 때문이다. '어텐션 이코노미'와 평판 경제에 입각한 느슨하지만 낭만적인 시스템이야 말로 어떠한 국가 전략보다 더 애국적인 성과를 내버린 것이다.
만약 정부가 해야할 일이 있다면 그 것은 계획주의가 부흥할 수 있는 것과 그럴 수 없는 것을 구분할 줄 아는 상식을 잊지 않는 일이다. 귀중한 사회적 자원이 제조업과 건설업과 같은 선형적 성장 패러다임에 과도하게 흘러 들어가는 것을 막는 것, 그리고 동시에 미래가 요구하는 사회적 자본이 기능할 자유로운 플랫폼을 보장하는 일이다. 미래를 위한 파괴적 혁신이 일어날 수 있는 풍토가 발생할 수 있도록 하는 것이 정부의 몫이다. 규제완화, 교육정책 등 일견 관계 없어 보이는 것들의 결과인 것이다. 그러나 현정부도 지난 정부도 안타깝게 역방향 전진만 하고 있었다.
예컨대 정부 정책의 한계와 폐단은 오픈소스에 대한 몰이해에서도 드러난다. 지금도 여전히 오픈소스 진흥을 위한 여러 활동이 진행중이지만, 한국의 오픈소스 진흥책의 근본적 문제는 오픈소스를 이용하려는 자의 시선만 있고, 그 기저에 깔린 '그냥 재미로'의 생산력이 어떻게 발휘되는지 그 경제성을 이해하지 못하는데 있다.
나의 작은 코드 한 줄이 세계적 혁신을 일으킨다는 꿈. 이를 잃은 현장에서 오픈소스는 SI를 위한 염가의 원자재 공급원으로 인식되어, 소프트웨어는 공짜라는 왜곡된 인식만 낳는다. 그리고 더 절망적으로 사실상 오픈소스를 약취하여 포장만하고 자신들의 소프트웨어인양 파는 행태까지 만연하게 되고, 그러한 기업이 대표적 소프트웨어 기업이 되기도 한다.
언제부터인가 한국의 오픈소스는 사회적 이익 대신 사적 이익만을 추구한 나머지 사회적 폐해마저 야기할 수 있다는 기이한 실증사례를 세계에 남기고 만 셈이다. ‘제조 건설 입국’의 생리하에서는 오픈소스라는 창조적 운동마저 하도급 자재 수급의 방편으로 이해되고 있는 것이다.
정부가 아무리 나름의 전략적 정책을 내놓는다고 하더라도 더 이상 일개 산업 정책으로 해결될 수 있는 범주는 뻔하다. 전체적 성장률을 올리기 위해서는 실질적 경제 효율을 올리기 위해 장벽을 없애는 규제 개혁과 세이프티넷을 강화하여 개개인 깊은 곳에 아직 남아 있을 만용에 가까운 패기를 끌어내는 편이 낫다.
우리가 우리의 존재와 커리어를 걸고 부린 만용들이 성공한다면 어떤 일이 벌어질까?
- 지금보다 훨씬 많은 소프트웨어 하우스, 웹 기업이 생겨나고 이 분야의 고용은 배로 늘어날 것이다. 예컨대 한국의 웹 성장률은 배증하여 인터넷 상에서 한글은 현재 세계 7위에서 5위의 문화 컨텐츠로 등극할 것이다.
- 오픈소스란 유통이 촉진되어야 할 소비재이기에 앞서 개인의 생산을 장려하는 인센티브임이 이해되고, 전세계적으로 '거대한 글로벌 팬 커뮤니티를 거느리는' 오픈소스 성과가 우리 주위에서 생겨날 것이다. 벨기에(Drupal), 덴마크(Ruby On Rails, Umbraco) 등에서와 같이 세계인의 마음으로부터 서포트받는 진정한 오픈소스 운동이 생겨날 것이다.
- 대형 SI사 들의 계열사 물량 비중은 10% 선으로 줄어들 것이다. SI사 들은 종합건설사풍의 턴키 제공업자가 아닌 비트의 무역업, 즉 매시업을 지향하는 종합상사로 거듭난다.
- 소프트웨어 서비스 산업 전체로 현재보다 배 이상의 고용을 창출할 것이다. IBM 글로벌 서비스나 인도 타타 컨설턴시와 같은 글로벌 서비스업의 예를 볼 때 타당한 수준이다.
- 현실의 절망을 딛고 일어나 무언가 맨손으로 시작할 수 있는 대안 공간으로서의 소프트웨어와 인터넷 산업은 그 본연의 모습을 찾게 될 것이다.
칫 이럴 리가 없잖아, 라고 이 백일몽들을 질타할지도 모르겠다. 그러나 우리가 맞이하게 될 미래란 모두 우리가 앞으로 내리게 될 적잖은 개인적 사회적 선택의 결과물일 뿐이다. 한가지 분명한 것은 지금 우리는 이 사회와 경제가 과거의 마음가짐을 가지고 미래의 문턱을 넘으려는 순간을 목격하고 있다는 점이다.
* Pecha Kucha란?
‘재잘재잘 이야기하다’라는 뜻의 일본어로, 일본의 건축가들이 처음 채용한 발표 형식.
원래 형식은 20장의 슬라이드를 장당 20초씩 총 400초(약 6.7분) 동안 발표.
참고: http://en.wikipedia.org/wiki/Pecha_Kucha
Google Web Toolkit과 Eclipse Galileo를 이용한 고성능 웹 개발 Michael Galpin, Software architect, eBay
Michael Galpin은 1990년대 말부터 웹 애플리케이션을 개발하고 있으며 California Institute of Technology에서 수학과를 졸업하고 현재는 캘리포니아 산호세에 있는 eBay에서 아키텍트로 근무하고 있다.
요약: GWT(Google Web Toolkit)에 대한 이야기를 들어보았을 것입니다. 그리고 GWT를 사용하면 Java™ 프로그래밍 언어로 웹 애플리케이션을 작성한 후 컴파일하여 JavaScript로 만든 다음 웹 브라우저에서 이 JavaScript를 실행하게 된다는 것도 알고 있을 것입니다. 또한 GWT를 사용하면 Java의 정적 형식 지정 기능과 Eclipse 등의 우수한 도구를 활용하여 생산성을 높일 수 있습니다. 아마도 GWT 기반의 유용하고 깔끔한 위젯은 여러 번 보았겠지만 GWT를 사용하여 고성능 웹 애플리케이션도 작성할 수 있다는 사실은 모르고 있었을 것입니다. 이 기사에서는 Google Plug-in과 Eclipse Galileo를 함께 사용하여 컴파일러 최적화, 지연된 바인딩 및 Ajax 최적화와 같은 GWT의 성능 기능을 활용하는 방법에 대해 설명합니다. 개발자 성능은 GWT의 중요한 부분이므로 Google Plug-in for Eclipse를 통해 생산성을 높이는 방법에 대해서도 살펴봅니다.
