R&D, SI, SM의 비교

모든 개발자들은 R&D, SI, SM으로 나눌 수 있다. 이것은 마치 그림이 그려지는 과정과도 비슷하다.
R&D에서 캔버스를 만들고, 붓과 물감을 만들면 SI에서는 이것들을 가져다가 고객이 요청한 그림을 그린다. 이를 SM에서는 액자를 바꾸고, 덧칠도 하게 된다.

이 러한 이유로 R&D는 전산을 위한 전산을 하게 된다. R&D가 제공하는 재료들은 또다른 R&D 개발자에 의해 보다 발전된 재료로 재탄생하기도 하지만, 결국 SI 개발자들에게 제공되는 목적이 분명하다. R&D에 속하는 조직은 Microsoft나 Oracle과 같은 Major 업체에서 부터 SI를 병행하는 일반 기업의 R&D 조직도 SI를 위한, 즉 전산을 위한 전산을 하고 있는 조직이다.

그들의 주된 관심사는 새로운 기술이며, 그러한 기술이 널리 사용되기를 바라는 것이다. 자신들의 조직이 아닌 다른 전산 조직을 주 고객으로 하는 R&D는 .Net이 Java와 경쟁하듯 수많은 3rd Party 제품들의 경쟁이 치열하다. Borland와 같은 기업들은 이러한 경쟁에서 뒤쳐졌다 할 수 있으며, 수많은 3rd Party 업체들은 경쟁에서 뒤쳐져도 개발자들에게 기억조차 되지 않는다.

R&D는 새로운 기술을 접목 하는 것을 숙명으로 받아들이고, SI에서 쉽게 접근 할 수 있도록 객체기반으로 구현하게 된다. 모든 객체는 재사용이 가능하지만, 일단 캡슐화 되어 있고, 가능한 한 SI에서 추가적인 객체를 정의해서 사용하는 일을 최소화 하는 것이 그들의 제품에 대한 평가로 이어지게 된다. 그리하지 않아 SI에게 선택받지 못하는 R&D는 결국 시장에서 사라지게 되며, Borland에 비해 규모가 작은 조직은 누구에게도 기억되지 못한다.
R&D에서 구성된 제품의 모듈을 가져다가 SI에서는 Process를 구현한다. 추가적인 객체를 정의하지는 않는다. 이미 있는 객체를 수도 없이 재사용해서 구조적인 개발을 진행하게 된다. R&D에서 정의되었어야 할 내용이 정의되지 않아 SI에서 이를 추진하는 경우가 있는데, 이러한 경우를 Field Test라 할 수 있다. R&D가 SI에서 요구되는 부분을 정확히 숙지하지 못해 SI에서 부족한 부분을 감안하고 진행하게 되는 경우이다.
이러한 경우로는 많은 Major 기업들이 사용하는 Beta Version 공개가 있고, 자체 SI조직이 있는 경우는 고객사와의 공동 개발이 있다. 심한 경우는 완성된 제품으로 판매하고 있으면서 고객들의 불만을 수시로 제품에 반영하는 Alpha Testing이 있다. 현명한 SI조직은 이러한 Alpha Testing에 참여하지 않지만, 현명한 R&D 조직은 이러한 Alpha Testing에 참여하게 된다.
R&D의 조직원과 SI의 조직원이 새로운 기술에 대해서 언급하는 것은 사실상 R&D에서 SI로의 기술이 공유되는 차원이다.

새로운 기술을 성급히 실무에 적용해서 혼란을 주거나 전산을 위한 현업의 업무 중단이 발생하도록 하는 것은 SI가 선택해서는 안되는 것이다.

이렇듯 R&D가 객체지향 기술을 지향하고, SI가 구조적 프로그래밍을 지향하는 이유는 각각, 쉽게 사용될 수 있도록 하려는 노력과 하나의 커다란 시스템을 구축하기 위한 노력에 맞는 선택이다.
하지만, SM은 이와는 다른 현실에 직면하게 된다. 기존 모듈은 기존 프로세스로 남기고, 새로운 모듈을 추가하는 기능이다. 하지만, 기존 코드에는 영향을 주지 말아야 한다. 이러한 경우에 가장 안전한 방법은 기존 모듈과 신규 모듈을 완전하게 구분하는 부분에서 분기를 시키고 90% 이상 동일한 두개의 코드가 만들어지게 된다.
해당 시스템과 Process와 요구사항을 충분히 이해하고 있는 개발자라면 위와 같은 방식으로 업무를 처리하지는 않는다. 하지만, 담당자가 교체되고, 시스템이 일관성 있게 유지보수 되지 않게 되는 시점이 한번 벌어지기 시작하면 위와 같은 작업행태가 진행된다. 이후로는 그 어떤 개발자가 유지보수를 하더라도, 이를 원복할 방법이 없다. 이러한 코드를 순차 프로그램이라 한다. 이제 추가적인 요구 사항은 분기문으로 처리하고, 기존 모듈에 대한 변경 요구 사항은 이렇게 분기된 모든 코드들을 찾아 수정해 주어야 하는 상황이 된다. 그렇게 순차 프로그래밍이 계속되면 유지보수가 불가능한 상황이 된다.
새로운 요구사항이 반영되지 않고, 반영되더라도, 시간과 비용이 만만치 않게 되는 시점에 시스템은 재개발에 들어가게 된다. 이 때 해당 시스템 개발 건이 SI 시장에 매물로 나오게 되는 것이다.

R&D는 SI가 자신을 선택해 주지 않는다고 탓을 한다. 자신들의 제품이 새로운 기술들을 적용 했고, 생산성이 높고, 보다 안정적이고, 코드 분량을 줄일 수 있으며 복잡한 디자인 요구사항을 쉽게 충족시킬 수 있다고 말한다.
"그러냐? 어떻게 하면 되냐?"고 SI가 R&D에게 물으면,
"그것도 모르냐?"고 묻는다. 그러면 SI는 해당 제품이나 기능을 사용하지 않는다. 그런데, 사용하지 말아야 할 상황에서도 계속 사용하게 되는 경우가 있다.
제 품에 대한 메뉴얼이 빈약하고, 서비스가 신속하게 이루어지지 않고, 끊임 없이 심각한 문제의 이슈가 발견되어도 해당 제품을 사용하게 되는 경우가 많이 있다. 버려야 할 것을 버리지 못하고 진행되는 SI프로젝트는 개발자들의 무덤이 되기 쉽다.

R&D 와 SI 사이에서 벌어지는 문제는 SI와 SM 사이에서도 유사하게 벌어진다. 하지만, SM은 SI를 절대 버리지 않는다. 물론 프로젝트가 Drop 되는 경우는 있지만, 그것이 SM에 의해 결정되는 경우는 결코 없다. 하지만, SM에 의해 SI의 결과물이 거부될수도 있는 것이 SI가 R&D를 거부 할 때의 논리로 거부 될 수 있어야 한다.

아키텍쳐의 부재, 일관성 없는 코드 패턴, 의미 없는 코드의 난발, 유지보수를 위해 충분하지 못한 메뉴얼, 정규화되지 않은 데이터베이스, 시도때도 없이 다운 되는 시스템이지만 SM은 그러한 결과물을 군말 없이 받아들인다. 인공위성이 처음 쏘아 올릴 때 궤도를 잡기 위해 지나치게 많은 연로를 사용하면 수명이 단축되기 마련이다. 이럴 경우를 대비해 보험을 들고, 보험회사에 손해에 대한 비용을 청구하고 인공위성을 버리게 된다. SI프로젝트도 이쯤되면 결과물이 버려져야 하지만, 버려지는 경우는 거의 없다. 미국의 SI프로젝트 성공률은 16%라고 한다. 물론 이 수치는 모든 계획된 일정이 원활하게 수행되었고 고객의 만족도를 포함한 수치로 보아야 할 것이다. 하지만, 그 수치에는 SM의 결과물 검수 및 거부가 포함된 수치라고 보아야 한다.

"이것은 유지보수가 불가능하다."는 것을 말할 수 있는 SM이 존재해야만 한다. 프로젝트 전반에 걸쳐 SM은 자신이 유지보수 하게 될 시스템의 이해를 높히기 위해 검수를 진행해야 한다. 그리고, 필요하다면, 결과물에 대한 거부의 의사도 표현할 수 있어야 한다.

R&D는 SI에게 제품을 제공하고, SI는 SM에게 시스템을 제공한다. 제공받는 쪽에서는 자신이 넘겨받은 결과물이 부족하다면 넘겨받지 말아야 한다.

R&D 는 사람을 상대하는 것보다 전산에 빠지고 싶어하는 사람에게 적합하고, SI는 사람을 만나는 것을 즐기는 사람들에게 적합하고, SM은 일상을 즐기는 사람들에게 적합하다. R&D 개발자는 SI개발자를 보며 "사람을 상대하는 것이 지치지 않을까?"라는 의문을 종종 갖는다. SI개발자는 SM개발자을 보며 "똑같은 일상에 지치지도 않을까?"라는 의문을 갖기도 한다.
처음부터 개발자의 성향에 맞는 전산 분야는 이렇듯 구분되어 있다. 자신에게 맞는 전산 분야가 R&D인지, SI인지, SM인지를 알고 나아갈 방향을 찾아야 한다. 자신에게 맞는 업무분야에서 개발 업무를 한다면 그리 힘들지도 않은데, R&D성향의 개발자가 SI프로젝트에 참여하며 프로젝트를 흔드는 경우가 상당히 많다. SM성향의 개발자가 SI를 하면서도 스스로의 일상에 힘겨워 하는 모습을 보이기도 한다. 업무분야를 잘못 잡았을 뿐 그들의 실력이 부족한 경우는 거의 드믈다고 보면 맞다.

자신에게 맞는 업무분야를 찾는 것이 개발자로서의 즐거움을 만끽하는 또 하나의 방법이라는 것을 기억하자.

("오래 보아야 아름답다. 너도 그렇다.")