차세대 프로젝트 딜레마에 대한 돌파구

안내: 이 글은 운영을 중단한 개인 블로그에 2015년 6월 18일 올렸던 글입니다. 다음에 기고할 글과 연관이 있어 옮겨 둡니다.

앞선 글에서 슬쩍 차세대 딜레마란 말을 썼다. 흔히 듣던 말도 아니고 엄밀한 정의 없이 쓴 말인데, 요즘 많은 곳에서 시스템 운영 비효율을 겪지만 섣불리 ‘차세대 (프로젝트)’ 즉, 시스템 전면 재구축을 시행하지 못하는 경우를 본다. 이를 ‘차세대 (프로젝트) 딜레마’라 지칭했는데, IT서비스 업계(어느 기사에서 이렇게 표현하던데 개발자들 사이에서는 흔히 SI업계란 말이 많이 쓰인다)에 몸담고 있는 사람이라면 이런 현상을 인식하는 분들이 있을 것이다. 재작년엔가 보통 소문으로만 도는 차세대 실패 사례가 기사로 나서  놀랐던 기억이 있다. 비슷한 시점에 김국현님이 이를 다룬 글에 크게 공감했는데, 당시엔 여유가 없어서 생각을 어딘가에 풀어 놓지는 못했고, 그때 배운 인사이트를 당시 수행하던 프로젝트 임원보고에 활용했던 일이 있다.

DevOps를 설명하는 이미지

위 그림은 데브옵스(devops) 관련 이미지인데, 당시 내가 고객사에 제안한 점진적인 시도를 설명하기 위해 차세대 프로젝트 실패 사례를 인용했다. 그리고, 비즈니스 환경이 급변하는 상황을 고려할 때 더 이상 장기간에 걸쳐 개발하고, 단 한번 릴리즈하는 프로젝트는 위험하다는 주장을 했다. 아무튼 당시는 대고객용 B2C 서비스이기 때문에 주기적인 시장 피드백이 중요하다는 맥락이어서 기업용 업무시스템(인트라넷) 비중이 큰 차세대 프로젝트의 맥락에는 다른 논리가 필요할지도 모르겠다.

내가 지난 번에 쓴 글에서 차세대를 언급한 이유는 레거시 시스템의 경직성(혹은 프로그램 수정이 어려워지는 일)을 (해결하기 이전에) 분석하는 일이 짐작보다 어려운 일이라는 점을 말하고 싶어서다. 그리고, 정보시스템을 활용한 이력이 길수록 역동적으로 비즈니스를 해왔을수록 기존 시스템이 갖고 있는 복잡도는 해가 갈수록 쌓여 왔을 것이다. 그래서, 어쩌면 단 한번의 프로젝트 즉, 현재와 같은 차세대 프로젝트의 릴리즈 방식으로는 처리하기 어려운 수준의 복잡한 차원이 되어 있는 것이 아닐까?

최근 2~3년에 걸쳐서 차세대 프로젝트 수행에 대해 꽤 깊이 고민하실 위치에 있는 두 지인에게 전화가 온 적이 있다. 두 분이 묻는 질문은 ‘차세대 프로젝트에 MDD(Model Driven Development) 제안을 받았는데 괜찮은 것인가?’였다. 2000년 초반에 CBD 방법론에 대한 오해(CBD 적용 자체가 요구사항의 정확한 구현을 보장해줄 것이라는 듯한)를 다시 겪는 듯해 더디게 발전하는 우리 업계를 확인하는 씁쓸함을 느꼈다. 어떤 획기적인 방법론을 기대하기 보다는 문제를 분할하여 해결하는 방법(Divide and conquer) 혹은 지혜를 활용하면 어떨까? 상식적인 얘기임에도 불구하고, 우리 삶을 관찰해보면 행동할 때는 그렇지 못한 경우가 많다.

어제 구독하는 블로그에 비슷한 문제를 다룬 글이 올라왔는데, 그 중에 인용하고 싶은 구절이 있다.

오랫동안 개발팀이나 기획팀과 소통에 실패하고 있고, 프로젝트가 여러 번 산으로 가고 있다면 잠깐 멈추어서 본질적인 문제가 무엇인지 짚어볼 필요가 있습니다. 그리고 그렇게 점검하고 방향을 수정하는 과정 자체가 그 회사의 IT 역량이라는 것을 알았으면 합니다

수년간 쌓여왔던 문제를 단번에 풀려고 하는 ‘차세대’라는 말에 묻어 있는 기대감(혹은 중압감)을 나누어 생각해볼 수 있다면 성공 가능성을 높일 수 있지 않을까? 만일, 과거 경험이나 주변 사례를 볼 때 실패사례가 많다면 수행 과정에서 점검하고 방향 수정을 할 수 있도록 계획을 수립하는 일은 너무나도 중요하다. 몇 년 전 꽤 명석한 인도 엔지니어가 나에게 엠파이어 스테이트 빌딩 구축 공정을 예로 한번 만들면 수정없이 반영하는 경직된 계획(Plan) 활용이 아닌 지속적으로 수정하는 계획(Planning)을 역설해서 꽤 흥미롭게 들은 일이 있다. 몇 번인가 IT기획이나 관리를 담당한 분들에게 같은 취지의 이야기를 꺼낸 일이 있다. 그때마다 내부 품의나 프로젝트 수발주 관행 등을 이유로 들며 현실성이 없다는 답을 들었다. 어쩌면 그런 장애물을 극복하지 못하는 것이 ‘그 회사의 IT역량’ 한계인지도 모르고, 어쩌면 그 한계가 프로젝트 실패의 주요 요인일 수도 있다.