워터폴, 애자일의 가치
"저번에 쓰던 프로그램에는 있던 기능인데요."
"이건 당연히 되야하는 기능 아니에요?"
밤 10시. 나는 감기는 눈을 억지로 부비며 가지고온 메모장에 요청사항을 써내려갔다.
몇개월간 고생해가며 만든 포스(POS) 프로그램을 마트에 실제로 설치해보니 다양한 문제가 발견된것이다.
다음날 사무실에 출근해서 요청한 사항들을 수정하는 프로그램 패치를 만들어야한다. 그리고 오후 6시 이후에는 마트에 출근해서 캐셔 옆에서 모니터링하면서 개선사항을 적는 일을 했다. 하루에 잠은 6시간도 잘 수 없었다.
몇개월간 그렇게 보냈더니 점점 체력이 고갈되어가는게 느껴졌다.
실제로 치명적인 문제도 있었지만 대다수는 기능 추가와 사용성 개선이었다.
다른 회사의 십년이 넘는 노하우를 개발자라는 죄로 욕먹어가면서 한두달만에 다 따라잡아야 하는 웃긴 상황을 감내해야했다.
이때 근무하던 회사는 포스 기기 임대 및 카드 수수료를 중간마진으로 받는 회사였다.
포스 프로그램과 기계를 다른곳에서 사서 식당, 마트 등의 소상공인들이 카드 계산 및 매출관리를 할 수 있게끔 환경을 만들어주고 수수료를 챙기는 구조다. 하지만 내가 근무하던 회사는 포스 프로그램을 직접 만드려고 했다. 전임자가 있을때부터 온갖 포스 프로그램을 소스코드채로 사와서 개선을 시도했지만 잘 안되었고, 내가 입사하면서 그냥 포스 프로그램 전체를 새로 만들었다. 대기업 ERP를 연동해서 도소매, 수발주, 인사급여, 미수금 관리 업무까지 연계되는 지금까지 없던 프로그램이다.
마트에서 기존에 구입해서 넣어두었던 중소형마트 전문 포스 프로그램이 있었다. 이 프로그램으로 계속 유지를 하려면 영업해서 세팅해놓은 매장마다 매달 사용료를 지불해야했다. 이 사용료를 줄이려고 개발한게 내가 만든 포스 프로그램이다. 캐셔 입장에서는 잘 사용하던 익숙한 프로그램을 빼고 불편한 프로그램을 넣었다고 불평하는것이었다.
기존의 포스 프로그램을 참고해서 만들지 않은것은 아니다. 다만 개발이 완료되고 나서야 캐셔가 중요하다고 이야기하는 모든것을 기획 단계에서 알수는 없었을뿐이다. 지금 생각해보면 기획자 역할을 했어야할 경력 많은 실무자들이 뒷짐지고 있었던게 내 고생의 원인이었다. 현장의 실무를 모르는 개발자가 기획부터 개발까지 전부 혼자서 했으니 일이 효율적으로 흘러갈리가 없었다. 기획부터 마트에 설치하기까지 6개월을 고생했고, 마트에 설치하고도 3개월을 더 고생해서 겨우 안정화를 시킬 수 있었다. 장인정신으로 일한다고 생각하며 인생을 갈아넣듯이 일을 했지만, 건강이 상하니 아무것도 남지않았다. 지금도 그 때 당시를 회상하면 정말 아찔하다. 대체 이런일이 왜 생긴것일까?
일반적으로 IT 시스템을 구축하기 위해서는 긴 시간과 비용이 든다.
사람의 문제를 컴퓨터 자료구조로 옮겨 사람의 일을 해결하는 기능을 만드는것이 쉽지만은 않은 탓이다.
최소한 하나의 제품이 나오기 위해서는 기획, 설계, 개발의 각 단계를 거쳐야하고 고객에게 제품이 전달되기까지 짧게는 몇개월, 길게는 일년이 넘는 시간이 훌쩍 지나간다.
한번에 고객이 원하는 결과물이 나오면 다행이지만, 그렇지 않았을 경우 많은 문제가 시작된다.
회사 입장에서는 이미 소프트웨어 개발을 하느라 많은 시간과 자본을 사용한 상태다. 그런데 이미 많은 부분이 개발이 진행된 소프트웨어를 상당 부분을 뜯어고쳐야하는 피드백이 오면 상당히 난감해진다. 지금까지 투자한 시간과 비용이 무의미해지는것이다. 이런 상황에 고객이 이 소프트웨어가 필요하지 않다고 모든걸 폐기하고 다시 개발할수는 없는 노릇이다. 결국 고객의 요청사항을 최대한 반영하여 소프트웨어를 개선하는데 추가적인 비용을 쓰게 된다.
많은 IT 프로젝트가 이렇게 실패한다. 건물의 조경이 마음에 들지 않는다고 10cm 오른쪽으로 옮겨달라는 요청은 말이 되지 않는다는걸 모두가 알지만, 소프트웨어는 당연하게 생각하는 경향이 있기 때문에 최초에 예상한 개발 비용만으로 프로젝트가 끝나지 않는 경우가 많기 때문이다. 추가적인 비용과 시간을 들여서 프로젝트는 마무리 했어도 결과적으로 회사에 이익이 없을수도 있다.
건설과 IT의 프로젝트 진행 방법은 폭포수 모델, 이른바 워터폴(Waterfall)이라고 한다.
최초 목표로한 제품을 체계적으로 완성하는 제조업의 생산 방식이다. 정확한 설계와 오차없는 시공이 따르면 이론적으로는 완전무결한 제품이 나올 수 있다. 문제는 똑같은 컨베이어 벨트를 태우는 표준화된 생산공정을 거치는 자동화된 공산품도 불량률이 있는데, 전문적인 작업이 필요한 결과물에 오차는 따라오기 마련이라는것이다.
설계가 항상 완벽할수도 없고 시공이 완벽하기를 기대하는것도 어렵다. 결국 현장에서 큰 그림에 맞게 최대한 문제없게 전문성을 발휘한 결과가 현대사회의 모든 결과물들이다. 문제는 소프트웨어의 경우 목표점이 수시로 바뀔 수 있다는것이다.
소프트웨어는 앞서 이야기했듯이 고객의 선택에 의해 가치를 잃어버릴 수 있다.
고객의 필요를 아예 무시하고 만드는 소프트웨어는 없겠지만 최초 고객 미팅으로 부터 소프트웨어가 고객에게 전달되기 까지 걸리는 시간이 길면 길수록 시한폭탄을 안고 가는것과 다르지 않다. 대화를 하지 않은 시간만큼 고객의 기대와 결과물은 멀어지고 만다.
이러한 문제를 해소하기 위해 나온 개발 방법론이 애자일(Agile)이다.
애자일은 공정과 도구보다 '개인과 상호작용'을, 포괄적인 문서보다 '작동하는 소프트웨어'를, 계약 협상보다 '고객과의 협력'을, 계획을 따르기 보다 '변화에 대응'하는것을 원칙으로 다양한 프로젝트 관리 방법으로 파생될 수 있다.
이것은 단순히 소프트웨어를 빠르게 개발하기 위해 절차를 무시하는것과는 다르다. 같은 상황에 무엇을 우선순위로 둘것인지에 대한 가이드라인으로, 한정된 자원을 어떻게 효율적으로 쓸것인지에 대해 생각하는 방법에 가깝다.
몇년전 수목관리 의뢰자와 나무병원 매칭 및 EMR 기능을 가진 시스템을 구축하는 일을 했었다.
완료 시한이 다 되어서 급하게 넘어온 일이고 혼자서 개발해야했다. 그나마 다행인건 정부지원사업으로 PoC(개념증명)를 목적으로 한 개발이라서 최종 제품인 웹서비스와 모바일앱의 서비스 활성화가 목적이 아니라는 점이었다.
만족시켜야하는 고객이 일을 의뢰한 고객으로 끝나는것은 큰 장점이다.
이 프로젝트를 수행할때는 철저히 애자일의 가치를 실천하기 위해 노력했다.
고객사와 개발사 양측에 주기적으로 커뮤니케이션할 기획자를 둬서 실시간으로 소통했으며, 서비스 기획안을 부분적으로 보완할때마다 피드백을 받고, 프로젝트 초기부터 개발 진행중인 제품에 접속할 수 있도록 환경을 마련하고 짧으면 일주일 길어도 2주에 한번은 업데이트를 해서 실제 소프트웨어를 바탕으로 발전 방향성을 논의 할 수 있었다. 이렇게 3개월간 프로젝트를 진행한 끝에 별다른 이견없이 프로젝트를 잘 마무리 했고, 고객사는 PoC를 잘 마치고 정부지원 검수를 마칠 수 있었다.
빠르게 진행해야하는 작은 프로젝트라서 애자일을 통한 접근방법이 성공할 수 있었던것일지도 모른다.
하지만 최소한 주기적인 고객과의 소통과 검증을 통해서 나중에 있을 불필요한 오해와 자원낭비를 막을 수 있다는 좋은 사례가 될것으로 생각된다.
SI 구축사업에서는 어떨까? 애자일은 SI에서 도입 할 수 있는 가치인가? 결론부터 이야기하자면 'NO'다.
애자일을 도입하기 위해서는 고객사와 개발사가 완전하지 않은 가치를 점진적으로 발전시켜나가도 좋다는 합의가 되어야한다. 아파트를 짓듯이 명확한 목표를 세우고 한번에 거대한 자본과 시간을 쏟아붓는 사업형태에 애자일은 적합하지 않다. 애자일을 한다고 이야기하지만 준비되지 않은 개발 조직이 하는 애자일은 전혀 민첩하지도, 생산적이지도 않으므로 차라리 철저하게 워터폴을 잘 수행할 수 있도록 하는게 낫다.
SI 구축사업을 통해 소프트웨어를 발주하는 고객은 큰 규모의 조직이다. 그래서 사업의 담당자가 소프트웨어에 담을 업무 도메인을 모두 이해하고 있지 않으며, 심지어 결정권자가 아닌 경우도 많다. 이러한 소프트웨어에 필요한 요구사항을 정리하기 위해서는 다양한 부서를 찾아다니며 인터뷰를 해야하며, 부서간의 다양한 이해관계가 얽혀있다. 목표에 따라서 소프트웨어를 만들어 나가는것보다 이러한 관계를 풀어나가는 일이 더 힘들 수 있다. 점진적인 발전은 다른세상에 있는 이야기다.
거기다 고객이 시스템 개발에 적극적으로 참여하는 경우는 드물다. 그래서 개발사에서 비즈니스 분석가, 기획자를 붙여서 업무 요구사항을 분석하고 고객이 무엇을 원하는지 스무고개를 하고 추리를 해야하지만, 고객이 SI 구축사업의 목표를 명확하게 알지 못하니 목표 지점을 제시할 수 없다. 거기다 제3자 입장에서 이 사업이 원활하게 진행되고 있는지 확인을 위해서 소프트웨어 감리 업체가 별도로 들어와서 사업의 형태만이라도 정형화된 형태로 잘 구성되어 있는지, 제안요청서(RFP)상의 목표에 근접하게 설계나 구현되어 있는지 확인하는 작업을 한다. 여기에 대응하느라 개발 진척은 제자리를 맴돌고 시간만 보내게 된다. 상황이 이렇다보니 시간이 지날수록 소프트웨어 결과물은 고객의 기대와 멀어진다.
어느정도 개발이 진행되어서 시연을 하면 그때부터 진짜 일이 시작되는데, 이때는 이미 프로젝트 일정의 절반 이상을 쓴 상태다. 어쩔 수 없이 개발사에서는 워터폴에 애자일을 섞은 이상한 개발 방법론을 쓰게 된다.
워터폴 방법론에 의한 절차에 들어가는 시간적 비용은 모두 지불하면서 개발은 빠르게(Agile) 해야한다는 논리다. 애자일의 가치를 실행하고 지속할 수 있는 숙련도가 떨어지는 상태로 스크럼을 실행하는데, 무한 스프린트의 반복일 뿐이다. 스크럼 절차를 반복하면서 개선하는 프로세스가 존재하지 않은것이다. 이른바 K-애자일(Korean Style Agile)이다.
이후에 어떤일이 벌어질지는 상상에 맡기겠다. 문제는 '이런 상황에 대한 해결책이 있는가?'이다.
현실적으로 국내 공공, 금융, 의료 등 대형 SI 프로젝트에서 정부 주도의 행정지도가 있지 않는한 워터폴을 걷어내는것은 쉽지 않은 일이다. 결국 이런일이 일어나지 않으려면 충분한 자원을 각 프로젝트 단계마다 투입해서 단계별로 완벽하게 일을 해나갈 수 밖에 없다. 워터폴로 일을 빠르게 하기 위해서는 인력 등 많은 자원들 투입하는 방법밖에 없는것이다. 하지만 사업의 예산이나 개발사가 수용할 수 있는 비용에는 한계가 있다.
문제의 핵심은 고객에게 소프트웨어가 최초로 전달되기까지의 시간이 너무 오래걸린다는것이다.
이 시간을 최대한 줄이고 피드백을 통해 개선하는 사이클을 빠르게 만드는것만이 유일한 해답이다.
승부를 볼 지점은 기획분석 단계다. 이 기간에 사업을 이루는 모든 설계와 합의가 완료 되어야한다.
배포할 시스템과 동일한 환경을 갖춰 고객이 항상 확인 할 수 있는 체계를 갖춰야하며, 피그마(Figma) 등의 목업(Mockup) 도구를 적극적으로 활용하여 가시적으로 UI/UX를 협의 할 수 있도록 해야한다. 외부 연계 등 기술적, 정책적으로 협의하고 확인해야할 사항은 테스트를 포함한 단위 컴포넌트를 빠르게 개발하여 이 기능들을 모았을 경우 시스템을 완성 할 수 있다는 증거를 쌓아야한다. 중요한것은 이 단계만큼은 애자일의 가치를 실천함으로서 고객 만족을 최대한 이끌어내야한다는점이다.
정리하자면 개발 단계에서 애자일을 실행하는것이 아니라 기획분석 단계에서 실행해야한다.
완성된 소프트웨어가 아니라 UI/UX 스토리보드 등의 목업과 단위 컴포넌트들의 동작 증거를 담은 보고서 등을 바탕으로 고객을 만족시킬 수 있어야한다.
일반적인 프로젝트 수행방법으로는 개발 단계에 자원을 가장 많이 투입시키지만, 위와 같은 방식으로 하려면 기획분석 단계에 가장 많은 자원을 할당하게 된다. 분석설계와 단위기능 개발이 동시에 이루어져야하며, 고객과 가장 많은 커뮤니케이션을 해야하기 때문에 한사람이 여러 역할을 담당하는것이 불가능하기때문이다.
고객에게 제한된 시간내에 바른 가치를 전달하려면 애자일 도입은 필수다. 하지만 애자일을 통한 생산성 개선과 고객만족은 개발사에서만 노력한다고 이루어 지지 않는다.
고객의 비즈니스가 성공하기 위해서는 열린 마음으로 하나의 목표를 이루기 위해 서로를 파트너로 받아일 수 있어야할것이다.
눈 앞에 있는 코딩에 시간을 쏟는것이 반드시 일을 성공으로 이끌지 않는다.
잊지말자. 고객 눈앞에 선보여야, 진짜 일이 시작된다.