2년간 정체된 솔루션 개발 3개월만에 끝내드린 사례

개발사와 미팅을 하다 보면 자주 듣는 말이 있습니다. 비슷한 서비스를 이미 운영하고 있으니, 그걸 조금 고치면 금방 만들어 드릴 수 있다는 말입니다.

처음부터 만드는 것보다 기간도 짧고 비용도 적게 들 것 같습니다. 그래서 많은 의뢰자분들이 이 제안을 고르십니다. 저희가 넘겨받은 한 플랫폼도 출발은 같았습니다.

그 플랫폼은 뉴욕의 한 개발사가 2년 동안 고쳐 가며 만들었지만 완성되지 않았습니다. 저희는 이를 넘겨받아 처음부터 새로 만들었고, 3개월 만에 오픈했습니다.

이 글에서는 그 2년이 왜 길어졌는지, 그리고 3개월 안에 마칠 수 있었던 이유가 무엇이었는지 차례대로 정리해 드리겠습니다. 기존 솔루션을 고쳐 쓸지 고민하시는 분들께 판단 기준이 되실 겁니다.

 

비슷한 플랫폼이 있으니 금방 된다고 했습니다

의뢰하신 곳은 귀금속과 보석을 취급하는 회사였습니다. 세계 곳곳의 다이아몬드와 보석을 도매상과 이어 주는 중개 플랫폼이 필요하셨습니다.

먼저 일을 맡은 곳은 뉴욕의 개발사였습니다. 그곳은 이미 중개 플랫폼 하나를 운영하고 있었고, 그 플랫폼을 조금 튜닝하면 원하시는 모습이 나온다고 제안했습니다.

운영 중인 서비스가 있다는 것은 든든하게 들립니다. 기능 이름만 나란히 놓고 보면 거의 같아 보이니, 몇 가지만 손보면 끝날 일처럼 느껴지기 때문입니다.

하지만 일은 2년째 제자리였습니다. 요구사항을 전달하면 수정본이 오고, 열어 보면 기대와 다르고, 다시 설명을 써서 보내는 과정이 되풀이됐습니다.

 

기능 목록이 같아도 거래 흐름은 다릅니다

남의 솔루션을 고쳐 쓰는 방식은 색상이나 문구, 메뉴 이름을 바꾸는 정도라면 무리가 없습니다. 어려워지는 것은 일하는 순서 자체가 다를 때입니다.

이 플랫폼의 본업은 도매 거래였습니다. 도매상이 상품을 어떤 방식으로 등록하는지, 문의가 오면 어떤 단계를 거쳐 구매로 이어지는지가 사업의 중심이었습니다. 이런 흐름은 화면이 아니라 시스템의 기본 구조에 속합니다.

다른 회사가 만든 제품의 기본 구조는 쉽게 바꿀 수 없습니다. 같은 제품을 쓰는 다른 고객이 있기 때문입니다. 그래서 요청이 오면 구조는 건드리지 않고 바깥에서 돌아가는 방법으로 맞추는 경우가 많습니다.

돌아가는 방법이 하나둘 쌓이면 한 곳을 고칠 때마다 다른 곳이 틀어집니다. 2년은 누가 게을러서 생긴 시간이 아니었습니다. 그 구조 위에는 하려는 사업이 처음부터 들어갈 자리가 없었기 때문입니다.

 

코드보다 먼저, 거래 순서를 받아 적었습니다

프로젝트를 넘겨받은 뒤 저희가 처음 한 일은 개발이 아니었습니다. 도매상이 실제로 거래를 어떻게 하는지, 문의를 받으면 무엇부터 확인하는지, 가격은 어느 단계에서 정해지는지를 여쭤보는 일이었습니다.

들은 내용은 저희 표현으로 정리해 다시 보여 드렸습니다. 맞는지 확인을 받고, 다르다고 하시면 바로 고쳤습니다. 이렇게 하면 만들기 시작하기 전에 양쪽이 같은 그림을 보게 됩니다.

앞선 2년이 길어진 이유도 상당 부분 여기에 있었습니다. 요구사항이 문서로만 오가면, 쓴 사람과 읽은 사람이 서로 다른 모습을 떠올린 채로 몇 달이 흐르는 경우가 많습니다. 결과물을 받고 나서야 어긋났다는 걸 알게 됩니다.

그래서 저희는 개발 전에 확인하는 시간을 따로 잡습니다. 겉으로는 일정이 늘어나는 것처럼 보이지만, 전체 기간은 이 단계에서 가장 크게 줄어듭니다.

 

우회할 필요가 없으니 속도가 붙었습니다

확정된 거래 흐름을 그대로 담을 수 있게 처음부터 새로 개발했습니다. 다른 제품의 구조를 피해 돌아갈 일이 없으니 작업이 막히지 않았습니다.

만든 기능은 크게 네 가지입니다.

관리자 시스템 — 플랫폼 전체 운영을 한곳에서 관리합니다

중개 기능 — 제품 문의부터 구매까지 단계별로 관리합니다

전문 검색 — 도매상이 원하는 상품을 찾는 검색입니다

대량 등록 — 도매상마다 많은 상품을 한 번에 올립니다

이 가운데 검색과 대량 등록은 도매 거래에서 손이 가장 많이 가는 기능이라, 실제로 쓰는 방식을 기준으로 별도 설계했습니다. 다루는 상품이 많은 업종이라 이 두 기능이 불편하면 도매상이 플랫폼을 쓰지 않기 때문입니다.

개발 기간은 3개월이었습니다. 2년과 나란히 놓으면 크게 보이는 차이지만, 무리해서 서두른 결과는 아닙니다. 만들 내용이 확정된 상태에서 재하청 없이 직접 개발하면 나오는 기간입니다.

 

2022년에 연 뒤로 지금까지 함께 보고 있습니다

플랫폼은 2022년에 오픈했고, 그 뒤로 4년 넘게 저희가 계속 관리하고 있습니다. 새 기능을 붙이는 일도, 운영 중에 생기는 문제를 해결하는 일도 처음 만든 개발자가 이어서 맡고 있습니다.

오픈 당시 담당자분이 전해 주신 말씀은 한 문장이었습니다. 2년간 진행하고도 완성하지 못했는데 정말 빠르게 완성해 주셨다는 말씀이었습니다.

저희가 이 사례를 소개하는 이유는 3개월이라는 숫자 때문만은 아닙니다. 기술이 부족해서 실패하는 경우보다, 무엇을 만들어야 하는지 정확히 짚지 못해 엉뚱한 것을 만드는 경우가 훨씬 많다는 점이 이 사례에서 잘 드러나기 때문입니다.

 

커스터마이징이 맞는 경우와 아닌 경우

기존 솔루션을 고쳐 쓰는 편이 나은 경우도 분명히 있습니다. 하시려는 일이 그 제품이 원래 하는 일과 같고, 화면 구성이나 입력 항목 정도만 다를 때입니다. 이럴 때는 빠르고 저렴한 쪽을 고르시면 좋습니다.

반면 거래 방식이나 업무 순서가 그 제품과 다르다면 새로 만드는 쪽이 결국 더 빠릅니다. 기본 구조를 바꿔야 하는 요구는 커스터마이징으로 풀리지 않기 때문입니다.

어느 쪽인지 헷갈리실 때는 한 가지만 확인해 보시면 됩니다. 우리 사업에서 가장 중요한 흐름이 그 제품의 기본 구조와 같은지입니다. 같지 않다면 그 간격은 시간이 지나도 줄어들지 않습니다.

그리고 어떤 방식을 고르시든 개발 전에 요구사항을 확정하는 단계는 꼭 거치시는 것이 좋습니다. 이 단계를 함께 밟아 주는지에서 개발사에 대한 많은 것이 드러납니다.

 

마무리하며

정리하면 이렇습니다. 첫째, 기존 서비스를 조금 고치면 된다는 제안은 차이가 화면 수준일 때만 통합니다. 둘째, 사업의 흐름이 다르면 커스터마이징으로는 닿지 않고 기간만 늘어납니다. 셋째, 이 사례에서 기간을 줄인 것은 만들 것을 먼저 확정하고 직접 개발한 순서였습니다.

진행 중인 개발이 계속 늦어지고 있거나, 기존 솔루션을 고칠지 새로 만들지 결정하기 어려우시다면 지금 상황을 알려주십시오. 어느 쪽이 맞는지부터 함께 정리해 드리겠습니다. 앱이나 웹 개발이 필요하시면 토리토시스템에 편하게 문의해 주세요.

토리토시스템 공식 홈페이지 바로가기