시스템 대 전환 프로젝트 01
서비스기획, 데이터, 개발까지 아우르는 험난한 여정
재직 중인 회사에서 엄청난 프로젝트를 진행하고 있다.
장장 10년을 쓰던 노후된(아직도 윈도우10, 익스플로러 기반 *2024년이다.) 시스템을 쓰던 자사의 모든 시스템을 새로운 시스템으로 전환하는 프로젝트다.
처음엔 마냥 신났다. 내가 이 프로젝트에 참석하는 것만으로도 영광이라 생각했었다. POS, Back office, CRM system, 신규 앱 출시를 한 번에 하는 프로젝트라고? 아뿔싸! 뒤에 닥칠 후폭풍은 전혀 모르고 있었다.
그간 수많은 서비스들의 웹과 앱을 쓰고 얕잡아보며 왜 UX설계를 이렇게 했을까, UI디자인을 이따위로 했지? 하려면 애플처럼 해야지! 토스처럼 해야지! 했던 내 마인드가 이제는 와! 어떻게 이렇게 하셨지? "정말 대단한 사람들이었군!"이라고 바뀌는 계기가 되기도 했다.
내 이야기가 실제 IT업계 전체를 꿰뚫지는 못한다. 이 모든 업계는 각각의 스토리가 있고 또, 정해진 룰이 없다. 어느 누군가는 인하우스 개발을 할 것이고 어느 누군가는 SI회사에서 시스템을 개발하기도 하니까 말이다.
이미 10년을 쓰며 고도화가 될 만큼 된 시스템을 타사의 SAAS로 바꾼다는 것이 얼마나 잘못된 결정이었는지도 몰랐다. 다만, 앞서 말했듯 정해진 룰이 없는 IT업계이기 때문에 비용절감이라는 이유로 이러한 결정이 불가항력이라는 점은 알고 있었지만, 이 정도로 어려운 프로젝트가 될 줄은 몰랐다.
프로젝트의 시작은 입찰 공고를 만드는 것으로 시작된다. 우리는 이러한~ 기능이 필요해, A, B, C, D... 이러한 요구사항을 넣고 SI사에 입찰 공고를 보내고 경쟁입찰을 시작한다. 우리 회사의 경우 총 세 개의 업체가 입찰 제안서를 만들어 입찰했으며 프레젠테이션을 시작했다. 모든 회사의 제안서의 퀄리티는 말도 안 되게 높았고, 금액, 그리고 발표실력이 프로젝트 입찰의 모든 것을 좌우했다. 이제와 돌이켜보면 업체선정은 프로젝트 내에서 차지하는 비중이 크지 않다고 생각 중이다.
모든 프로젝트는 수행사와 발주사가 원활한 협업이 기본이 되어야 하지만 시작부터 삐꺽이기 시작했다. 프로젝트매니저의 기술스택은 오로지 POS개발자 출신이라는 거밖에 없었기 때문이다. 기우이길 바랐지만 역시나 프로젝트 초기 POS시스템 외 기타 시스템들에 관해서 대응을 못해주었고 우리는 수행사로 PM교체를 요청했었고, 수행사 측에서는 전체를 아우르겠다며 수행 PM이 아닌 일정 관리 PM으로 PM을 교체해 주었다.
10년간 쓴 프로그램을 모두 한 번에 바꾸기 위해 무려 수천줄의 요구사항이 도출되었고, 각 분야의 파트리더들과 함께 수천 가지의 요구사항을 기존 SAAS에 욱여넣기 위해 몇 달간 피비린내 나는 전투를 치렀었다.
돌이켜보면, 수행사도 발주사도 현재 있는 인력을 기반으로 범위를 한정해야 했으나, 여기는 위대한 대한민국이 아니던가. 우리는 다가올 후폭풍은 전혀 고려하지 않은 채 수천 가지의 요구사항을 모두 안고 개발이 시작되었다.
요구사항이 수천가지라면 그 수천가지의 요구사항을 뒷받침하는 회사 내 정책은 각 요구사항당 n개씩 있다고 가정하면 수만가지의 정책이 있다고 보면 된다. 하나하나 요구사항 정의서 그리고 회의록을 작성하고 수정 또 수정해가며 장장 1년을 보냈다.
지금은 모든 시스템이 출시되었지만, 그에 따른 후폭풍을 맞이하고 있다. 고객들의 VOC와 직원들의 건의 사항이 끊임없이 이어지고 있다. 처음에는 이러한 피드백들이 부담스럽게 느껴졌지만, 이제는 시스템을 더욱 완벽하게 만들어 나가는 소중한 자료로 받아들이고 있다. 하나하나의 의견을 꼼꼼히 검토하고 반영하면서, 시스템은 점점 더 사용자 친화적으로 변할것이라 믿는다.
이번글은 어디까지 쓸지 모르겠지만 프로젝트 초기부터 중장기 그리고 마무리까지 연재를 할 계획이다.
