|
물론 지역적이거나 개별기업의 특수성에 따르는 문제이겠지만, IT 그중에서도 SI 나 웹호스팅,웹에이젼시, 데이터서비스업종의 한가지 사례에 국한시킨다는 전제하에 이야기를 해본다면 모든 기업이 시스템 통합이나 전산화를 구축할때 시스템 엔지니어링이나 개발방법론에 충실한 것은 아니다. 아직은(?) 그 효용성이나 필요성이 절감되지 않고 있기 때문이기도 하고 예산상의 제약이나 인식부족에 기인하기도 한다. 대체적으로 대기업은 나름으로 이미 오래전에 정형화된 독자적 개발방법론(쉽게 말하면 프로세스나 관행)을 보유하고 있다. 그렇기 때문에 IT개발자들이 대기업에서 일하기를 선호하는 것일지도 모른다.
예전엔 그렇지 않았다. 전산인은 그저 열심히 밤을 세워가며 업무량이 2배가 되든, 3배가 되든 우직하게 코딩만 하면 그만인줄 알았던 시절도 있었다. 즉 개발=코딩이란 인식이 지배적이었던 때 말이다. 지금은 대형서점에 가면 온갖 개발방법론 서적에 파묻힐 정도지만 2000년대초까지만 하더라도 대학교재를 제외한다면 그런 서적(번역서)을 찾아보기 힘들었다.
Y2K문제가 불거지기도 전이었던, COBOL로 업무용 어플리케이션을 작성하던 때의 보편적 인식에 젖어있었을때 누군가의 글에서 전체 프로젝트기간에서 설계 대 코딩의 비율이 8:2라는 단정을 처음 접했을때는 굉장히 의아스러웠던 기억이 남아있다. '이거 거꾸로 된거 아냐...?'
실제 개발현장에선 개발기간은 곧 코딩기간이던 시절이었기 때문에 현실적으론 결코 그렇지 못했다.업무정의, 사용자요구사항분석 이런건 개발하면서 해도 된다고 생각하던 시절이 있었다. 고치고 또 고치고... 결국 완성된 프로그램은 만신창이가 되어서 작성한 사람을 제외하면 아무도 건드리고 싶어하지 않는 소스가 되어버렸다. 아마도 그 8:2라는 이야기에는 테스트부분이 빠져 있었을 것이다. 일반소비자를 상대로 한 패키지는 베타버젼이란 과정을 거쳐 전세계 수십만 베타테스터들의 리포트를 취합하고, 기업의 전산화과정에 있는 어플리케이션 또한 기나긴 UAT 기간을 밟기 때문이다.
그런데 이제 하나씩 둘씩 차근차근 시스템 엔지니어링이나 개발방법론이 주창(?)하거나 권고한대로 프로젝트기간에서의 단계별배분이 이뤄져 나가고 있는 도상에 있다고 보여진다.
실례를 들자면, 과거 미 대통령 선거에 무소속 후보로 나섰던 기업가가 세웠던 거대 SI업체가 있었다. (물론 일치하는 것도 있고 아닌 것도 있지만 그 기업과 잠시 일해본 경험을 주로 삼아 예를 들어본다면) 그들은 절대 서두르지 않으면서 모든 부분에 대한 정의와 합의가 있기 전까지는 코딩관련 개발은 시작되지 않았다. 또 그것이 시작되고 나서도 개발자간 공통코드나 변경관리를 관장하는 서버를 지정해서 공지하고 각 개발부서별 업무프로세스를 지정하는데 오랜 공을 들였다. 또 각 개발자의 소스코드이력을 관련하는 source safe 서버 정의를 했으며 코딩단계에 들어가서도 공통코드, 전역변수 지정등에 심혈을 기울이다보니 도대체 코딩은 언제 하냐는 불안감이 개발자들 사이에서 불거져 나왔다. 전체 기간중에 개발외적(사실 개발외적인 것이 아닌데)인 부분에 대부분을 할애하고 끝에 가서 매일 밤샘해야 되는거 아닌가 싶은 우려. 그러나 개발자들은, 특히 그런 방법론에 입각해서 개발해보지 못했던 개발자들의 경우엔 일견 놀라운 경험을 하게 되었는지도 모르겠다. 그러니까 코딩과정은 quick & simple이었다. 그리고 중간에 발생하는 예외적 사항들이나 변경관리가 없었다면 그것은 거의 8:2에 근접하고 있었던 것이다. 이미 모든 파트에 대한 정의가 완벽했고 현업부서와의 합의가 도출된 상태이기 때문에 혼선이 최소화되고 변경관리나 리스크가 적었기 때문에 쾌속항진이 가능했던 것이다. 만약 개발기간이 12 개월이라고 가정했을때 설계(사용자요구분석, 합의도출, DB설계, 프로그램 개발 지원 업무 프로세스, 개발자와 현업부서간 커뮤니케이션 방법 구축)에 들어간 기간이 약 10개월이고, 실제 개발툴을 써서 소스코드를 작성하는 것은 2개월이 된다는 이야기다.
개발방법론을 다룬 책들이 설명하는 것은 각종 차트와 플로우만이 아니다. 성공적인 개발을 위한 환경적 요소도 큰 비중을 차지하고 있다. 전장에서의 군인들과 마찬가지로 IT분야의 개발자들 역시 인간적 요소가 지배하는 사기라는 것에 막대한 영향을 받는다. 개별기업이 이러한 이해를 보유하고 있다면 그 프로젝트의 성공가능성은 배가된다. 그렇지 못하다면 환경은 열악해지고 사기는 저하되며 프로젝트 매니저는 설계가 채 끝나기도 전에 황금알을 회랑에 전시해야된다는 압력에 시달린다. 사실 이것은 얘기하고자 하는 바를 단적으로 설명하기 위한 단순화시킨 실예에 불과하기 때문에 개발성격에 따라 수많은 차이가 존재하겠지만 시스템엔지니어링이나 개발방법론, 프로젝트관리론이 지향하는 바를 설명하기 위한 예로써 그리 틀린 바는 없을 것이다.
이번 월간 군사세계에 실린 3편의 M&S관련글을 읽으면서 그런 기억을 떠올려 봤던 것이다. 디테일한 부분에 있어선 문외한일뿐더러 국방관련 M&S의 경우라면 더더욱 그러할 것이다. 다만 M&S가 어떤 분야에 적용되던, 그것을 효율적으로 기능케 하는 기술적 제요소의 앞길은 매우 많은 난관을 내포하고 있으리란 짐작은 해볼수 있었다. 하지만 사용자가 끊임없이 시도하고 모색하고 방법을 제시한다면 그 사이 기술적 이슈들은 모두 해결될 것이란 예상도 해보게 된다.
실세계를 그리드나 지도위에 특정요소로써 모사하고 그것을 바탕으로 올바른 예측을 도출해낸다는 것은 매우 어려운 작업일 것이다. 앞으로 사회 및 산업 전반에서 점점 빈번해질 M&S와 그 개별 프로젝트들에서 과연 그것을 원활하게 수행할 수 있는 기술적 난점들은 적기에 해결될 수 있을까? 앞서 SI개발시의 시스템 엔지니어링 사례가 역설하고 있다시피 정의가 충분하고 다양한 활용가능성이 선연구된다면 기술적 난점들은 장애가 될 수 없을 것으로 보여진다. 적당한 비유가 되었을런지는 모르겠지만 글을 읽다 연상된 바를 그 자리에서 바로 적은 것이기 때문에 누군가 이 글을 읽는 이가 있다면 그런 면에서 넓은 이해를 바래본다.
난삽한 잡문을 뒤로 하고 결국 하고 싶었던 얘기를 요약해본다면... 어떤 기술적 요소나 환경이 포함된 시스템(그것이 어떤 성격의 시스템이건)을 만든다면 그것을 가장 많이 연구해야 될 사람은 바로 그 시스템을 사용할 당사자라는 것이다. 현명한 사용자, 클라이언트, 엔드유저는 기술을 유도하는 것이지 그것에 함몰되는 것이 아니다. 그러기 위해선 누구보다도 더 많은 투자와 연구가 투입되어야지만 성과를 낼 수 있다.
동일한 성격, 동일한 기술적 난이도를 지닌 두 가지 SI프로젝트가 동일한 개발팀에 의해 전개되었다. 그런데 하나의 프로젝트는 성공적이란 평가를 받고 시스템활용도가 극히 높은데 반해 다른 프로젝트는 엉망이 되어 버렸다. 이것의 원인이 개발팀에게 있겠는가? 한쪽 현업부서는 현명했고 다른쪽 현업부서는 무성의하고 무지했으며 아무것도 투입하지 않았기 때문이었다.
|
