brunch

You can make anything
by writing

C.S.Lewis

by 깡지 Aug 20. 2022

기간이 짧은데 다 해야 해?

IT에세이

최근 프로젝트는 멀티 프로젝트 성격에 Phased open형태가 많다.

과거에는 새 술은 새 포대에 담는 형태로 H/W, S/W, 요구사항, 비전 등을 아예 새롭게 받아들이고 향후 10년, 20년을 갈 수 있는 시스템을 만들자는 취지로 모조리 다 갈아엎는 형태의 프로젝트였기 때문에, 오픈 방식도 같은 날 한꺼번에 오픈하는 Big bang 방식을 택했다.

이 시기 야근, 철야, 주말근무가 많은 이유도 당시 사회 분위기도 있었으나, 그것보다 처음부터 새롭게 만들어 가야 하니 사람들이 감당하기 힘들 정도로 일이 많았다.


IT 시장만큼 신기술, 신제품이 쏟아져 나오는 곳도 없다. 게다가 예상보다 빠르게 데이터는 늘고, 빠른 성능을 요구하다 보니 시스템 곳곳을 바꿀 일이 생긴다. 화면만 교체하는 경우, 하드웨어만 교체하는 경우, 시스템 다운사이징하는 경우, 특정 영역의 솔루션만 교체하는 경우 등 케이스도 다양하다.


이런 교체 작업이 퍼즐 조각을 갈아 끼우거나 책장의 낡은 책을 빼고 새 책을 꽂는 수준이면 얼마나 좋겠는가. 굳이 비교하자면 장기 이식 수술과 같아서 이식받을 장기가 잘 맞을지, 나의 건강이 수술 가능한 수준인지, 혈관이나 신경, 인근 장기와 영향을 주지는 않는지, 피부 봉합은 깨끗하게 되었는지, 이후 합병증은 생기지 않는지 등 오히려 신경 쓸 일이 많다. 진행과정에서 예상 못한 변수가 튀어나오기도 한다.  


그렇다 보니, 최근 IT 프로젝트에서는 새로운 수술법에 정통한 의사보다, 경험 있고 숙련된 의사가 자신의 수술방법에 새로운 수술법을 곁들여 수술하는 것이 성공률을 높이는 경우가 많다.  


과거 로봇의 기억만 옮겨 심는 전신 교체 프로젝트를 했고, 지금은 로봇의 오른팔, 왼쪽 허파, 양쪽 무릎 관절 교체를 하는 프로젝트를 한다고 가정하자.

이전에는 새 몸체가 만들어지는 동안 구 몸체로 로봇이 동작하다가 교체 작업이 이루어지는 날 기억만 이식하는 형태의 프로젝트를 했기 때문에, 새 몸체를 만드는 긴 기간 동안 온갖 테스트가 다 이루어졌다.

후자의 형태는 로봇이 동작하고 있는 동안 오른팔을 바꾸고 또 이렇게 동작하다가 허파를 바꾸고, 또 조금 지나서 양쪽 무릎을 바꾸다 보니, 전체 기간은 비슷하게 길지 몰라도 하나하나 교체 기간은 짧다.

(누가 보면 로봇 만드는 프로젝트 하는 줄 알겠다. 시스템 구축하는 IT 프로젝트다 ^^;)


그런데 많은 사람들이 '이전처럼 전체 다 새로 만드는 것도 아니고, 팔 하나 바꾸고, 허파 하나 바꾸는데 각각 다 구색 맞춰서 일을 해야 해야 하나'를 이야기한다.

이를 다시 표현하자면 " 선오픈 영역은 8개월밖에 되지 않고 화면 교체만 하는데, 모든 단계별로 Task와 산출물 다 정의해야 할까요? 테스트 계획서도 거창하게 쓸 필요 없을 거 같은데요. 테스트도 다 하면 좋지만 그렇게 할 인력도 여력도 없어요" 등이 예시다.


이때 중요한 것은 '기본'과 '원칙'에 충실한 것이다.

로봇이 아니라 인간으로 다시 돌아와 보자. 심장 이식 수술을 할 때 수술 과정에서 뭐 하나 생략한다면 큰 사고로 이어진다. 큰 수술만 소독하고 작은 수술은 소독을 안 해도 된다와 다를 바 없는 경우다.

시스템도 마찬가지다. 쉽게 생각하고 충분한 고려 없이 생략/단순화해서 일을 진행하면 오픈 시기가 다가올수록 문제는 눈덩이처럼 늘어나 있다. 무엇보다 문제 해결을 할 때 원인이 한두 가지가 아니라 복합적 요인이 되어 해결방안이 여간 골치 아픈 것이 아니다.


그래서 매번 꼰대처럼 외친다. "원칙에 충실하자"라고.

무조건 무식하게 FM대로 다 했다가는 일을 위한 일을 하게 되므로 어떤 일을 단순화할지는 전후 연결관계를 보고 충분히 고민해서 전략과 계획을 세워야 한다.

만약 어떤 일을 단순화했을 때는 이후 부작용이 없는지를 좀 더 집중해서 모니터링하고 점검을 해서 돌다리를 안전하게 두들기는 작업을 반드시 병행해야 한다.

그래서 IT컨설턴트는 프로젝트 수행을 위한 각종 방법론을 이론부터 공부해야 하고, 프로젝트마다 그 특징에 맞게 Customizing 해야 한다. 프로젝트 참여자 중 (혹여 그 사람이 고객이라도) 어떤 일을 생략하거나 축소하려고 할 때 그들의 역할이고 방식이라고 수용해서는 안되고 이를 끊임없이 시물레이션 해 보면서 정정해 주어야 한다.


* Phased open 방식 프로젝트가 늘면서, 영역별 프로젝트 수행 전략은 사라지고, Task와 산출물 간소화 부작용이 속출하여 적어 본 글이다. *

매거진의 이전글 IT컨설턴트의 소양
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari