어쩌면 당연할지도 모릅니다...
팩키지 같은 경우는 우선 잘 만들어야 합니다. 그래야 제값 받고 팔 수 있으니까요. 그러나 si는 다릅니다. 금액이 애초에 책정이 되어있기 때문에 어떻해든 업체에서는 최저가(인원 줄이기, 기간 줄이기 등등)로 일을 마치려고 합니다. 그래야만 이익을 그만큼 남길 수 있기 때문인데 이미 하도급으로 깍여나간 프로젝트 비용을...업체들의 잇속 챙기기로 한번 더 후려치기 때문에 엉성하게 진행되게 되어 있습니다.

지금과 같은 si체계라면 어떤 좋은 도구가 주어진다 한들...neis와 같은 사태는 막을 수 없습니다.

당연하긴 하지만, 그래도 당연하지 않아야 하기 때문에 끊임없이 지적을 해야 하는 거지요. ^^

그런데, 도구의 차이는 분명히 조금 있습니다. 역설적으로 들릴 수도 있는데, 요즘 SI의 주류인 자바의 경우 지나치게 방법론 등을 강조하는 바람에 개발자의 가치가 더욱 격하되어 있습니다. 제 개인적인 생각일 수도 있겠지만, 오히려 솔루션 개발보다 SI 개발에서 프로젝트 팀 내의 인간적인 교류와 커뮤니케이션이 더욱 많이 필요하다고 봅니다. 그런데 제조업이나 건설업처럼 정형화된 공정, 즉 방법론으로 사람과 일정을 통제하려는 시도가 계속되어왔고, 자바라는 언어에서 꽃을 피웠습니다. 일견 성공한 것처럼 보인다는 것입니다.

사실 자바는 SI 공정을 위해서는 최선의 언어라는 사실에는 이론의 여지가 없습니다. 델파이나 C++ 등 네이티브 언어들, 그리고 다른스크립트 언어들에 비해서도 방법론의 적용이 가장 용이한 편이고, 코더들의 코딩 방법의 통제에 대한 기법들까지 체계적으로 마련되어 있습니다. 네이밍 룰 등의 기초적인 코딩 룰들은 물론이구요. 결과적으로 방법론 기반으로 잘 조직된 프로젝트 팀에서는, 외부 개발자A와 외부 개발자B가 코딩한 코드가 너무나 비슷해집니다. 바로 이렇게 개발자 사이의 차별성이 없어져 정격 부품화되는 것이 SI 프로젝트에서는 아주 유리합니다. 무엇보다도, 이런 '공정' 개발은 일정준수성에 최선의 선택이 됩니다.

그런데 개발자가 지나치게 부품화되고 과거 프로젝트의 주인공 롤에서 뒤치닥거리나 하는 코더 롤로 추락하게 되면서, 개발자의 만족도와 열의가 크게 떨어지는 결과가 되었습니다. 내가 아니라 나만큼 월급을 받는 다른 누구를 데려와도 나만큼 능력을 낼 수 있는 작업, 나의 창의성과 열의가 프로젝트에는 오히려 방해 요소가 되는 작업, 이런 일에 만족하고 열의를 다해 일할 개발자는 당연히 없습니다. 현재의 체계화되고 정형화된 SI 프로젝트들에서는 '영웅' 개발자는 기피 대상입니다.

물론 이게 SI 프로젝트가 가야할 옳은 길일 수도 있습니다. 그렇지만 현실적으로 보자면 그건 오직 SI 업체들의 입장에서입니다. SI 프로젝트의 다른 두 존재, 발주 업체와 개발자에게는 불행한 상황이 됩니다. 통상적인 얘기이지만, 개발자가 적극적으로 열의를 쏟지 못하고기계적으로 화면을 찍어냈을 때, 갑이 기대하는 동작을 제대로 하지 못거나 향후 기능 확장 등 유지보수 단계에서 문제를 일으킬 가능성은 아주 큽니다. 날고 기는 방법론을 도입해서 첨단의 프로젝트 관리 기법을 쓴다고 해도, '주요 생산 장비'인 개발자의 퍼포먼스가 크게 떨어지게 되어 품질과 일정 모두 손해를 보게 됩니다. 기계와 달리 개발자는 감정을 가지고 있는 사람이라 생산성과 품질에서 큰 차이를 가져오게 되니까요.

역설적인 얘기인데, 네이티브 언어들은 자바만큼의 프로젝트 정형성을 가질 수가 없습니다. 자바에 비해 너무 큰 유연성과 기능성을 가지고 있기 때문에 델파이나 C++ 언어를 썼을 때 자바만큼 강력하게 통제하는 것은 불가능합니다. 그래서 자바를 사용한 프로젝트에 비해 일정 지연이 자주 일어납니다. SI 업체의 입장에서는 끔찍하죠. 반면 갑 업체의 입장에서는 SI 업체보다는 큰 일이 아닐 뿐만 아니라 네이티브 언어의 특성상 다양한 선택과 높은 성능이 가능함으로 해서 더욱 회사에 적합한 시스템이 될 수 있는 가능성이 있습니다. 자동화된 공정에서는 불가능한 요구사항이 수작업 공정에선 얼마든지 가능한 거죠.

자동차를 만드는 방법에는 두가지가 있습니다. 먼저 잘 알다시피 현대자동차 같은 대형 공장에서 완전 자동화된 공정으로 찍어내는 방법이 있죠. 이런 완전 자동화된 공정에서는 대량으로, 그리고 초고속으로 자동차를 생산해낼 수 있습니다. 다른 한가지 방법은, 소규모 자동차 공장에서 수작업으로 자동차를 만드는 것입니다. 우리가 꿈으로 생각하는 람보르기니나 페라리가 이렇게 만들어집니다. 첫번째 방법은 자동차 회사의 매출과 이익을 극대화시켜줍니다. 반면 소비자가 갖게 되는 차는 누구나 갖고 있는 그저 그런 차입니다. 한대에 중요한 결함이 있다면 수천 수만대에 똑같은 문제가 있을 가능성도 높습니다. 이런 공장에 일하는 노동자는 감정적으로도 메마르고 자신이 겨우 나사 몇개 조이거나 도장 일만 반복하는 자동차에 애착을 가지고 적극적으로 일하기 어렵습니다. 반대로 소규모 수작업 공장에서 일하는 노동자들은 높은 대우를 받고 자부심도 대단합니다. 그 자동차를 구입하는 소비자의 만족도도 아주 높습니다.

물론 전세계에는 현대자동차와 같은 완전 자동화된 대형 자동차 회사에서 만든 차들이 압도적으로 많고, 대부분 그런 정도 수준에만족하고 구입합니다. 하지만 그런 보통의 차를 타는 소비자의 꿈은, 오랜 기간 자동차 공정에 세월을 바쳐온 숙련 기술자들이 매만져 만든 수작업 차입니다. 그리고 아마도 현대자동차에서 매일같이 나사만 조이는 노동자에게도, 수작업으로 한대 한대를 만들어나가는 자존심 높은 자동차 공장에 숙련 엔지니어로 일하는 것은 꿈만 같은 일일 것입니다.

아직 SI 프로젝트들의 사회적 관행에서는, 자동차에서 볼 수 있는 그런 인식은 정착되지 못했습니다. 아직 그러기엔 자동차 등의 제조업에 비해 IT 업계의 역사가 너무 짧죠. 하지만 최근의 SI 현장들에서 본 사례들을 감안하면 아주 먼 일만도 아닌 것 같고, 또 지금 현재만 해도 델파이나 C++ 개발자들의 업무 만족도는 자바나 닷넷 개발자들보다는 더 높아보입니다. 반면 자바와 닷넷은 그 언어의 특성상 대량생산 자동차 공장과 같은 방향으로 가는 것이 필연입니다. 바로 그런 자동화된 공정을 위해 SI 업체들이 밀어붙이고 있으니까요. 왜 컨베이어 벨트 위의 공정의 나사처럼 취급받느냐는 불만이 팽배하지만, 자바 자체가 바로 그런 목적을 최우선으로 해서 발전해온 컨베이어 벨트 자체입니다.