INBIZWARE :: [eLancer/ IT정보광장] 실패하지 않는 IT 프로젝트 매니지먼트 - 제3회 "약간의 앞을 내다보는 것"이 아키텍쳐 선정의 요령

제3회 약간의 앞을 내다보는 것"이 아키텍쳐 선정의 요령

1. IT 프로젝트 현장에서 자주 볼 수 있는 모습

전 회 "유저기업측 프로젝트 매니저의 착각"에서는 "사람"에 기인하는 프로젝트의 리스크 팩터와 그 대처법에 대해 이야기했다. 이번에는 "사물"에 기인하는 프로젝트의 리스크 팩터로서 시스템 아키텍쳐와 프로젝트 리스크 팩터의 관계에 대해 이야기하고자 한다.

IT 프로젝트 현장에서 자주 볼 수 있는 모습

개발기업측 PM : "이번 시스템에 대한 제한입니다만 꼭 LAMP(Linux와 Apache, MySQL, PHP/Perl/Python 을 조합한 오픈소스의 어플리케이션 구축 스택)를 채용하고 싶습니다."

유저기업측 PM : "그 아키텍쳐의 장점은 뭐죠?"

개발기업측 PM : "우선 모두 무상이기 때문에 저비용으로 시스템을 도입할 수 있습니다. 또 개발의 생산성도 매우 높습니다."

유저기업측 시스템 관리 책임자 : 하지만 저희 시스템은 이미 Windows 기반의 시스템이 들어와 있습니다만 Linux가 가능한 엔지니어가 없기 때문에 유지관리가 불가능 합니다."

유저기업측 PM : "그러면 시스템 운용보수는 귀사에서 해주실 수 있지 않습니까?"

개발기업측 PM : "......."

프로젝트 리스크를 줄이기 위한 아키텍쳐 선정

현재 웹 어플리케이션을 중심으로 많은 기술이 범람하고 있다. 데이타베이스만 해도 Oracle, SQLSever, MySQL, Postgres 등 수많은 데이터베이스 제품이 lease 되고 있다. 그러나 그러한 성능을 비교, 검토하여 채용하는 프로젝트는 얼마나 있을까? 상용 데이터베이스와 오픈소스 데이터베이스는 기능에 대해 꾸준히 그 차이가 확대되고 있으며, 또한 상용 데이터베이스의 차이, 특히 퍼포먼스 등 이라는 단면에서는 시스템의 체감 레벨이 거의 없이 동일하다고 볼 수 있다.

Java, PHP, C# 등 객체지향 언어만 해도 수 많은 프로그램 언어가 있지만 각 언어의 우위성 등은 각각 장단점이 있으며, 또 어떤 언어가 최고라는 등의 논의는 시스템 구축 상에서는 거의 의미가 없다. 이러한 많은 기술이 범람하는 가운데 프로젝트의 리스크 팩터를 집어내려면 어떠한 것에 관심을 가져야 할까?