좋은 개발은 좋은 제안에서 시작된다
첫 단추부터 제대로 끼우자
"정말이지 상도(商道)가 없네요."
사업에 대해 아무것도 모르는채로 참석한 첫 고객미팅에서 들은 말이다.
이 미팅에 참석해야할 시니어 개발자가 다른 업무로 빠져서 대타로 참석한 자리였다.
내가 아는한 사업 수주이후 공식적인 첫 고객미팅 자리였다.
이런 자리는 고객과 안면을 트고 이제부터 해나가야할 프로젝트의 개요와 진행방향을 논하는 자리다.
나의 역할은 이 자리에서 나온 이야기를 정리해서 분석설계할 개발자에게 일을 넘겨주는 것이었다.
그런데 이런 반응이라니, 정말 당황스러웠다.
2020, 2021년은 내게 있어 고통스러운 기억이 많은 해이다.
DDoS 탐지 및 대응 시스템을 단시간내에 개발하느라 안그래도 좋지않은 건강이 상했고, 여기저기서 터지는 유지보수 이슈를 해결하기 위해 동분서주 하던 시기였다.
회사가, 전임자가 저질러 놓은 업보를 청산하느라 정말 많은 고생을 했다.
그러던중 회사가 인공지능을 활용한 시스템 개발 사업을 수주했다.
한창 다른일 하느라 정신이 팔려있던 내게 이 사업에 대한 기억은 제안서를 쓸때 몇장 참여한 정도다.
사실상 사업 내용 자체는 별 관심 없이 제안요청서(RFP)의 기능 요구사항에 맞는 장표를 기계적으로 썼다.
애초에 나는 당시 머신러닝이니 딥러닝이니 하는것은 머리가 아파 보고싶지도 않았고 아무것도 몰랐다.
내가 이 사업에 관여할거라고 전혀 생각하지 않았고, 대충 무리수라도 인터넷 찾아보고 말이 되게끔 썼다.
그랬더니 결과가 이 모양이다.
시작부터 고객의 신뢰를 잃었다. 제안 발표때 무슨 이야기가 오갔는지는 알지 못한다.
다만 내가 고객과의 짧은 면담에서 느낀것은 고객의 기대와 회사의 대응이 맞지 않았던것이다.
지금까지 회사 레퍼런스에 인공지능 관련 연구나 사업을 해본 경험은 없었다.
당연히 관련 지식이나 경험이 있는 인력도 없다.
그래서 인공지능 관련 권위가 있는 대학, 업체와 컨소시엄(Consortium)해서 사업을 제안했다.
회사는 제안요청서가 나오기전 사전정보요청(RFI) 단계에서 사업내용을 청취하고 기존 운영시스템(AS-IS)을 견학하기는 했다.
하지만 그것은 사용자 시스템에 대한 내용이고, 인공지능 모델에 대한 고민은 한적이 없었다.
모든 SI 구축사업이 분석설계 단계에서 고객이 진짜 필요한것이 무엇인지 확인해서 개발을 시작한다.
제안을 하는 단계에서 설계가 완료되었다는 이야기는 작업 방향성을 알고있다는것 그 이상도 그 이하도 아니다.
당시에는 트랜스포머(Transformer) 모델도 국내에 알려지지 않았고, 당연히 대형언어모델(LLM)도 없었다.
그래서 자연어 처리(NLP)를 활용한 딥러닝 신경망(CNN) 학습 모델을 제안했다.
모든 전문가들은 자신의 분야에 대해 문의가 들어오면 경험과 지식을 기반으로 컨설팅을 해 줄 수 있을것이다.
컴퓨터 하드웨어 전문가는 목적이나 사양에 따른 견적, 인테리어 전문가는 공간을 개선하는 방법 등이다.
하지만 그 어떤 전문가도 구성요소나 현장을 보지 않고 결과물을 만들어서 납품할 수는 없다.
인공지능 모델 구축이라고 해서 다를바는 없다. 실제 데이터를 수집하고, 분석해봐야 이 데이터를 기반으로 학습한 모델이 원하는 기능을 수행할지 알 수 있다.
그런점에서 봤을때 첫 미팅에서 격한 반응을 하는 고객의 대응은 뭔가 석연치 않았다.
이미 완성되어 있는 인공지능 모델의 결과를 넘겨주기를 원했고 그것은 불가능했다.
처음부터 고객의 신뢰를 잃은 프로젝트는 정말 힘들게 돌아갔다.
코로나 사태로 인한 사회적 어려움도 프로젝트를 수행하는데 적지않게 걸림돌이 되었다.
해당 미팅 이후 나는 참여하지 않았지만, 회사는 많은 어려움끝에 프로젝트를 성공적으로 완수했다.
당해연도 NIA 사업 우수사례로 선정될 정도로 실용도가 높고 성공적인 사업이었다.
그러나 결국 고객과 관계는 좋지않게 끝난것으로 보인다.
일반적으로 정보시스템을 구축하면 향후 유지관리를 할수있도록 관련 사업을 발주하며, 대부분 정보시스템을 처음 구축한 개발사가 유지보수를 수주한다.
실무에서 쓰기 위해서는 개선해야할것도 많을것이고, 미처 발견하지못한 오류도 많을것이기 때문이다.
하지만 그러한 후속조치 없이 구축사업 이후 철수하게 되었다는것은 고객에게 신뢰를 주지 못했다는것이다.
다른 사업으로도 해당 고객사를 찾는 경우는 없었다.
제안서라는건 고객과의 약속이다.
눈앞에 제품을 내놓기 전까지는 제안서가 고객에게 있어 보상받을 가치 그 자체다.
만약 보험을 들었는데 막상 보상을 받을때가 되었을때 보험회사가 다른 이야기를 한다면 어떨까?
세상을 살다보면 많은 일이 계획대로 되지 않는다.
그래서 현실과 이상 사이를 조율하고 맞춰나간다. SI 구축사업도 마찬가지다.
제안요청서에 적혀있는대로 사업이 흘러가지 못할수도있다.
법과 규제를 간과했거나, 불가능한 일을 요청했거나, 비용 책정이 잘못되었거나 이유는 여러가지다.
제안요청서를 쓸 당시 충분히 알아보거나 고려하지 못한 문제가 실제로 현실에 놓고 봤을때 확인되는것이다.
주로 사업의 당사자인 수요자 고객이 IT를 잘 모르고, 해당 조직의 IT 시스템팀이 있어도 기획에 참여하지 않기 때문에 생기는 문제다.
IT 아웃소싱의 맹점이 이것이다.
고객이 필요한 소프트웨어를 만들기 위해서는 고객이 정보시스템에 대해서 상세하게 기획해야한다.
사업에 투입된 기획자가 아무리 날고 기어봐야 고객단에서 이야기가 정리되지 않으면 진행이 불가능한 사안은 얼마든이 존재한다.
제안요청서 내용 자체가 허무맹랑하다면, 누군가는 피해를 봐야하고 그것은 대체로 사업을 수주한 기업이 될것이다.
정보시스템을 발주하는 고객도 요구공학에 대한 충분한 이해가 수반되어야 원하는 바를 정확히 표현할 수 있다.
사무행정직에서 사용하는 언어와 IT 종사자가 사용하는 언어는 다르다.
애매하게 적혀있는 요청사항이 거대한 암초가 되어 심한 경우 사업이 망망대해에서 좌초될수도 있다.
상황이 이렇다보니 제안서를 쓰는 SI 개발사에서도 죽을맛이다.
어차피 요구사항대로 사업은 흘러가지 않는다.
그래서 모든 요구사항에 대해서 '하겠습니다!'하고 기계적으로 공수표를 날린다.
마치 내놓아야 하는 답은 하나뿐인 서약서를 쓰는 기분이다.
이렇게 작성된 제안서 내용은 여러 업체가 입찰에 참여했지만 서로 비슷하게 된다.
제안 내용이 볼게 없다면 무엇이 사업의 당락을 결정 지을까? 회사의 규모와 제안 가격이다. 심지어 회사가 어디에 있는지도 본다. 제안서가 예쁘게 디자인 되어있는지도 채점 요소이며, 제안 발표를 얼마나 잘했는지도 채점요소다.
사업의 당락을 심사하는 심사위원과 제안사 그 누구도 사업의 내용을 신경쓰지 않는다.
심한 경우는 사업에 해당하는 내용은 하나도 없이 두루뭉술하게 회사의 규모를 강조하는 제안서를 쓴다.
고객에게 필요한 소프트웨어를 제안 단계부터 진지하게 고민하고 솔루션을 제시할 필요가 없어진다.
고객의 필요를 무시하는 제안을 하는것은 자충수가 아닐까? 그런데 그렇지 않다.
고객도 제안요청서를 두루뭉술하게 쓴다. 조직내 필요한 여러 정보시스템들을 모아서 한번에 터뜨린다.
이렇게 크게 키운 사업을 수주하여 쪼개고, 중소 SI개발사로 던지거나 프리랜서를 끌어모아 투입시킨다.
이렇게 사업단이 투입될때쯤이면 제안 발표를 할때 심사위원, 고객 앞에서 한 약속은 온데간데 없어진지 오래다.
SI 바닥의 안좋은 관습중 하나다.
결국 프로젝트의 목적과 품질은 망망대해에 휘몰아치는 폭풍우 사이로 사라질뿐이다.
정보시스템은 현장에 투입된 사업단과 개발자의 임기응변으로 점차 완성되어간다.
처음 계획과 목적지가 다르더라도 어쩔수 없다. 어쩌면 사업을 낸 소기의 목적도 달성하지 못했을 수도 있다.
그리고 사업이 끝나면 이미 좌초된 배를 어떻게든 보수를 해야하는데 기술지원이 이뤄지지 않는다.
최악의 경우 구축한지 몇년 되지도 않았는데 폐기하고 새롭게 구축사업을 발주하게된다.
고객 입장에서는 정말 좋지않다. A/S 안되는 비싼 가전제품이다.
왜 이런일이 발생하는 것일까?
소프트웨어 구축사업을 제안하고 수주하는 주체와 소프트웨어를 만드는 주체가 다르기 때문이다.
고객이 믿고 있는 제안서는 홍길동한테 받은 약정서인데, 보증은 약정서 내용을 모르는 임꺽정이 하고있다.
물론 일을 대행하는 임꺽정의 잘못이라고도 할 수 있겠다.
제대로 알아보지 않고 일을 시작했으니 말이다.
그러나 그가 이런 산업 구조의 피해자로 보이는것은 단지 기분탓일까?
과거에는 사업을 만드는데 참여한 기업이 수주하는것이 당연한 상식이었다.
제안요청서에 온갖 독소조항이 덕지덕지 끼어있어 경쟁력있는 다른 기업은 참여할 수 없기 때문이다.
특정한 솔루션을 구입해서 해당 솔루션을 기반으로 구축해야 하는 등이다.
심지어 고객에게 정말 필요하고 중요한 요구사항이나 리스크는 꽁꽁 숨겨놓았다.
이런 방식의 사업 발주 및 수주가 안좋은것은 공정한 경쟁에 의한 산업 발전이 저해되는것은 둘째치고, 소프트웨어 감리 등 체계적인 사업 성과를 측정할 수 있는 모든 시스템을 무력화 한다는데 있다.
데이터에 의한 경영 혁신을 첨단 산업이라고도 볼 수 있는 소프트웨어 산업에서 부정하는 웃긴 일이 일어나고 있는것이다.
이는 결국 소프트웨어가 필요한 모든 고객에게 악영향을 미친다.
요즘은 공공에서도 단위 부서에서 각자 필요한 업무 시스템을 기획하여 분리발주하는 기관이 늘고 있다.
완전히 숨은 암초가 없는건 아니지만 최소한 사업의 내용이 충실하게 제안요청서에 표현되어 있는것이다.
이를 통해서 공정하게 제안을 할 수 있는것은 감사한 일이다.
준비만 잘 한다면 생존을 위해서라도 고객을 만족시켜야하는 중소 SI개발사에게 기회가 돌아오기도 한다.
주사업자로서 기업의 전문성을 쌓을 수 있고, 자금흐름을 스스로 관리할 수 있는 등 장점이 많다.
하지만 수년간 SI 바닥의 생태에 적응한 중소 SI 개발사도 나쁜 습관이 들어 있을수 있다.
SI로 먹고사는 회사가 SI를 수행하는 품질을 높일 생각을 하지 못하는것이다.
스스로 반성하고 고쳐야할 점이다.
대부분의 소프트웨어는 처음 구축된 형상 그대로 몇년이고 쭉 운영되는 경우는 드물다.
그래서 자동차를 오래쓰기 위해 기름치고, 조이듯 소프트웨어도 유지보수를 한다.
구축 당시와는 달라진 환경에 대응하거나, 개인정보보호 등 법이 바뀌어서 대응해야 하는 등이다.
어쩌면 처음 소프트웨어를 구축하는것보다 소프트웨어 납품 이후의 대응이 더 중요할 수 있다.
규모가 큰 기업에 비교하더라도 일의 품질이 떨어지지 않는다는것을 표현할 부분이 이런점이다.
제안하고, 구축한 소프트웨어에 오너십(Ownership)을 가지고 제조사로서 책임을 다할 수 있음을 보여야한다.
앞서 이야기 했듯이 제안서는 고객에게 있어 보험 약관과도 같다.
그러니 고객이 실제로 제공받을 가치에 가깝게 결과를 표현해야한다.
단지 제안요청서의 문답 형식의 제안서는 경쟁사와 비교에서 경쟁력이 떨어질 수 밖에 없다.
당신의 회사가 그냥 서 있는것 만으로도 경쟁 회사들을 압도하는게 아니라면 말이다.
진정성 없는 약속만큼 허무한것도 없다.
반대로 이야기하면 진심은 언젠가는 통할것이다.
우리는 고객의 문제를 해결함으로서 가치를 전달하는 전문가라는걸 잊지말자.
좋은 개발은 좋은 제안에서 시작된다.
