웹개발로 제품 만들다 늙어 죽을수도 있어요.#2

이번에는 지난회 "웹개발로 제품 만들려면 늙어 죽을수도 있어요." 에 이어지는 내용입니다.

지난번에는 계속되는 소스코드의 브랜치가 어떤 문제가 있는 지를 알려드렸습니다.

오늘은 그 해결책들에 대해서 설명을 해보고자 합니다.

사업하는 입장에서는 참으로 이상한 것이 , 비슷한 일인데 하면 할 수록 더 잘해야 될 것인데 비용이 점점 더 들어가는 상황이라니 말입니다. 제품의 문제점 파악 및 대안을 위한 워크숍같은 것 한 번 해야겠습니다.

여기서 나올 수 있는 대안은 대체로 다음의 두가지 정도입니다.

첫번째는 이리저리 고쳐 주는 것이 문제이니까. 아얘 패키지 제품으로 재개발을 한다는 것이고 두번째는 고비용 문제는 유지보수 업무에 해당하는 것이므로 이 업무를 외부업체에 아웃소싱한다 정도입니다.

문제는 첫번째나 두번째를 어느것을 선택하더라도 더 풀기 어려운 또다른 문제가 발생하기 때문에 실제로는 좋은 안이 될 수 없다는 점입니다.

커스트마이징은 고객의 요구사항이라서 뿌리치기 어렵습니다. 그렇다고 예상되는 요구사항을 모두 반영한 패키지화 된 제품을 만들려면 엄청난 비용이 들어가고 굉장히 어렵습니다.

두번째는 회사의 기술유출과 기존 고객관리가 안되는 점이 있어 영업리스크가 너무 높기 때문에 채택하기 어려운 결정입니다.

이 문제는 처음부터 다시 살펴보면 해결의 실마리가 보이지 않을까요.

처음에 어떤 프로젝트를 수행하고 나서 나오게 되는 산출물 , 이 산출물이 어떤 것이냐에 대한 정의를 내리면서 문제를 풀어보고자 합니다.

이 산출물이 재활용이 가능한 제품일까요 ?

웹시스템을 예로 들어 보겠습니다.

웹시스템을 구성하는 주요 요소는 웹서버/애플리케이션서버/데이타베이스서버 입니다.

다시 웹서버는 아파치, IIS , 제우스 등등 많은 벤더별로 나뉩니다. 그리고 그 벤더별 웹서버 제품의 버전이 나뉩니다. 설명을 간단히 하기위해서 3가지 벤더에 버전이 5개 라고 가정하면 전부 15개의 조합이 됩니다. ( 3 * 5 입니다. ) 그리고 웹서버에서 지원이 되어야 하는 여러 라이브러리들이 있습니다. SSL , SOAP 등 각 모듈마다 버전이 있을 것입니다. 이 두가지 모듈만 있다고 하고 버전이 5개씩이록 하면 전체 150 개 (3 * 5 * 2 * 5) 개의 조합이 가능합니다.

여기에 애플리케이션서버 환경으로 넘어가게 되면 좀 더 복잡합니다. 먼저 애플리케이션서버가 동작하기 위한 OS 환경이 조합되어야 하고 거기에 이 서버가 동작하는 데 필요한 외부 모듈이 최소 10여가지가 됩니다.

( 로그처리 , 데이터베이스 연결 , XML처리 , 파일업로드 , 각종문서파싱모듈 , 각종차트 , 리포트지원툴 , ... ) OS를 제외하고 10가지의 조합이 가능하다고 가정하고 , 지금까지의 환경 조합을 계산해 보면 벌써 1,500 개 ( 150 * 10+ ) 가 됩니다.

여기까지만 놓고 계산 해보면 웹서버/애플리케이션서버/데이타베이스서버의 기본구성의 환경에서 프로젝트 결과물이 문제없이 동작하기 위해서는 1/1,500 의 확율입니다. ( 데이터베이스 변수는 제외 )

즉 1,500 분의 1의 확율로 수정없이 재활용이 가능합니다. 제품의 기본 특징이 수정없이 수백 수천을 팔 수 있는 것 이라고 한다면 1/1,500 의상황은 이를 제대로 만족하지 못하게 됩니다. 결국 시스템 전체로는 재활용이 안되는 제품입니다.

이런 모든 환경에서 동작하는 시스템을 만들려면 지난글에서 말씀드린 것처럼 늙어 죽어도 안될 시간이 걸릴 것입니다. 될 수 있으면 웹개발로 제품 만들지 마시기 바랍니다.

그러면 반제품인가요?

반제품이라는 것이 일정 수준까지는 커스트마이징과 포팅을 고려한 설계를 하고 나머지는 라이브러리 형태로 제작을 하면 반제품이라고 할 수 있지 않을까 합니다.

제가 보는 문제 해결의 실마리도 여기에 있습니다.

제품과 같이 시스템 전체를 소스관리를 해야하는 방식에서 벗어나서 특정 부분만 소스 관리를 하고 나머지 커스트마이징, 포팅 부분은 별도의 레이어를 두고 관리해야 하는 것이 좋을 것입니다. 이렇게 함으로써 소스코드의 브랜치를 피할 수 있고 그에 따르는 비용을 줄일 수 있습니다. 이렇게되면 관리가 되지 않는 부분 즉 커스트마이징, 포팅 부분은 고객 또는 건별로 라이프싸이클 기간만 관리를 하고 이후 개별 종료 처리하는 것으로 하면 될 것입니다.

그러면 소스코드가 관리가 되어야 하는 부분과 그렇지 않은 부분을 나누는 것이 중요해 지는데 , 이부분에서 특정 레이어의 수준을 어느 정도로 할 지는 조직내의 CTO , 기술위원회 등의 도움을 받아서 정하는 것이 좋을 것입니다.

이렇게 나눌 때의 방식은 경험상으로 보면 외부연동부와 UI 는 커스트마이징 레이어에 놓이고 프레임워크 등은 관리부분에 놓이게 됩니다.

이번글은 구체적인 내용이 별로 없었 던 것 같습니다. 전달하고자 하는 내용의 요지는 웹시스템 같은 경우는 시스템 전체를 제품화 하려고 하면 너무 어려운 일이 될 수 있으므로 일부 또는 프레임워크 정도만 제품화 하시라는 말씀입니다.

*제품개발에 대한 말씀을 드릴려고 하는데 계속 밀리네요...