brunch

You can make anything
by writing

C.S.Lewis

by Ain Oct 25. 2022

이제는 정말 서비스를 만들어보려 합니다

서비스를 기획한다는 것은 정말 고려해야 할 것이 많구나

이전 에피소드 보기



2개의 정부지원사업과 민간 지원사업을 받았고, 2번의 Pivot 끝에 서비스를 발견하기는 했지만 우리의 상황은 나아지는 것은 없었다. 더욱 어려운 난관들만이 앞에 있었지만, 못할 수준은 아니었다.



그나마 나아진 것이 있다면 코워킹 스페이스로 사무실을 조금 이동했다. 정부지원사업을 받기 위해 새로운 업무용 공간이 필요했고, 팀원들이 광주, 인천, 분당, 강남에 거주하고 있었기에, 그나마 교통적으로 편안한 강남에 다시 터를 잡았다. 내가 제일 멀었지만, 그래도 새롭게 우리의 사무실이 생겼다는 것에 대한 굉장한 뿌듯함이 있었다.


그러나 아직 매출이나, 자금이 충분하지 못했기에, 다들 급여에 대해서는 많이 맞춰서 가져가지는 못하는 상황이었으나, 우리는 성공의 경험을 통해서 더 열심히 노력하고자 했다.




서비스 개발 측면의 노력 : 이제부터 우리가 해야 할 것들은 본격적으로 APP 서비스를 만들기 위한 노력이었다.


그동안 사업계획서에 썼던 내용들은 서비스에 대한 Core 프로세스에 대한 내용을 넣은 것이었고, 이제는 UX를 입혀서, 더 많은 UI와 요구사항들을 만들어야 했다.



(출처 : 요구사항을 기획하기 위한 고뇌의 현장)


회원가입에 대해서도 더 디테일하게 요구사항들을 추가해야 했다. 예를 들어, 우리가 금융 서비스를 운영하기 위해서 기본적으로 사용자들에게 입력을 시켜야 할 정보들을 회원가입 시 받아야 하기에, 이에 대해서도 추가를 하고, 더 나아가 서비스 자체의 고객 분석을 위해서 필수적으로 입력을 요청드려야 하는 요구사항들은 무엇이 있을까 등을 고민하여, 요구사항들을 넣어야 했다.


또 다른 예시로는 고객이 회원 탈퇴를 한다고 했을 때, 어디까지 데이터를 삭제해야 하고, 남길 수 있는 것인지, 이러한 기준선을 만들기 위해서 일명 '개망신법(지금은 개선이 되었다)'을 공부하며, 개인정보에 대한 내용을 학습해가며, 요구사항들의 디테일을 다져갔다.


이러한 작업을 하다 보니, 기존 사업계획서에서 만들었던 서비스에 대한 내용은 정말 겉핥기 수준으로 기획을 했다는 생각이 들었다.


(출처 : 초기 UI를 만들 때 사용했던 Adobe XD의 UI 개발 내용, 지금은 피그마 사용중)


이 뿐만 아니라, 본격적으로 UI도 만들면서도, 우리가 중요하게 생각했던 화면들만을 중심으로 생각했었지, 더 나아가 Target 고객이 해당 화면으로 넘어오기 위한 이전, 이후의 UI 화면이나, 우리의 중요 기능으로 전환을 시키기 위한 팝업, UX writing 등에 대해서, 전혀 깊은 고민이 없었다는 사실을 깨달았다. 


그렇기에 사용자의 입장에서의 UI와 UX를 위해서는 3명의 사업팀과 함께 고민해보고, 실제로 서비스를 개발하기 위한 시스템이나 설계 부문에서는 개발자님과 더 이야기하면서 부족한 부분을 조금조금씩 맞춰가기 시작했다. 


정말 진행하면 할수록 아직 부족한 부분이 많구나 라는 생각만을 하게 되었다. 



(그러나 너무나 모든 것을 완벽하게 안 했으면 좋겠다. 기획은 완벽할 수가 없었고, 앞으로도 그럴 것이다. 정답은 언제나 사용자들에게 있기에, "부족한 게 뭐가 있지?"를 고민하는 시간을 오래 가져가지 않았으면 좋겠다)


이렇게 우리가 부족한 부분을 하나하나 맞춰가기 시작했고, 이제 실질적인 개발이 가능한 모습으로 나아가고 있었다. 이제 개발을 진행할 때, 서버와 DB 등을 다루는 Back-end 개발의 경우, 내부의 전문 개발자분께서 전담하여 진행하였지만, 화면을 개발하는 Front-end 개발자의 경우, 금융서비스를 본격적으로 만들 수 있는 사람이 필요했기에, 내부의 인력으로는 어려움이 있었다.



또한 우리는 Lean 한 방법론이 필요하여 빠르게 MVP(최소가치제품)를 출시하기 위해 내부 개발자 채용을 위한 Delay를 선택하기보다는 Front-end의 경우, 외주 개발을 진행하였고, 우리는 추후에 이 선택을 통해 6개월의 사업 딜레이와 소송을 진행하게 된다.




사업 전략을 만들기 위한 노력 : 금융과 법을 뚫는 것은 이리도 어려운 일이었나


위의 내용이 서비스를 개발하기 위해서 겪어왔던 내용이라고 한다면, 이제는 개발을 할 예정인 이 서비스가 실제로 산업에 나오기 위해 해결해야 할 부분들도 있었다.


우리가 만들 서비스가 금융 서비스를 만들려고 하기에 다른 산업군보다 더 고려할 것이 많았던 것 같다. 그리고 나는 그 당시 "다시는 핀테크 서비스를 만들지 않겠다"라고 선언하고 다녔었다.

(그러나 막상 지나고 나니, 훌륭한 경험이었고 지금도 핀테크 서비스들을 만들려고 LMF(Language-Market Fit 테스트를 하고 있다.)


(출처 : 금융권 시스템을 공부하고, 이 중 어떤 것을 선택할지 비교 분석하고 고민한 내용)


예를 들어, 우리는 저축 서비스를 만들 예정이었기에, 어떠한 시스템을 사용할 예정이고, 입/출금의 순서를 갖는지에 따라 "유사수신행위"에 포함이 되는지 확인이 필요했다. 이 뿐만 아니라, 입/출금의 시스템을 갖추기 위해서, 더 나아가 저축할 돈을 어디에다가 둘 것인지에 따라서 "전자금융업" 라이선스가 필요한지에 대해서도 고려를 해야 했다.


그리고 이러한 문제점들을 미리 발견하기 위해
다양한 지원사업을 통해서 서포트를 받았었다.
우리는 창업 초보이기 때문에 큰 도움을 받았다.


이전까지는 그냥 우리랑 관계없다고 생각하고, 공간, 투자만 보았는데, 세상에는 정말 창업을 도와주는 지원사업들이 많았다. 특히 법률, 금융사업 등에 대한 멘토링을 많이 받으며, 우리가 바라보지 못했던 부분을 확인하려고 노력했다.


그리고 이렇게 발생한 이슈들에 대해서도 내부에서 의사결정이 필요했고, 기존 멘토링을 받았던 내용과 우리의 장기적인 관점에서 현재 필요한 우선순위를 기반으로, 어떠한 시스템을 이용할 것인지에 대한 의사결정을 마무리하게 되었다.



이를 위해서 우리는 제품도 없는 채로 금융사를 뚫어내기 위해 노력을 하게 된다.



(이때, 기존에 지원사업을 들어가면 심사위원들이 현업에 계신 분들을 더 선호하는지를 조금은 깨닫게 되었다. 이러한 시스템에 대해서 직접적인 공부가 필요했고, 이러한 이슈가 있다는 것을 알기가 어렵다. 공부하는 데에도 시간이 많이 필요했고, 서비스 런칭 이후 이슈를 확인하면 해결하는 데에 딜레이가 발생하기에 이러한 시간 리소스를 줄이는 게 필요했다)




지금 돌이켜 생각해보면 또 더 잘할 수 있던 방법들이 있었던 것 같다. 


서비스 개발적인 측면에서는 이때 우리는 이미 사업계획서를 만들 때, Target 사용자들에게 이미 요구사항을 다 들었다고 생각했었다. 그러나 더 나아가 프로토타입을 만들어서, 이를 기반으로 사용자들에게 더 테스트를 해보면서, UI에서 수정할 부분은 무엇이 있는지를 더욱 확인하고, 요구사항 측면에서도 필요한 내용을 인터뷰를 통해서 수집해서, 추후 개발 이후 서비스를 수정하는 일을 조금을 줄일 수 있지 않았을까 싶다.


사업 전략 측면에서는 "보다 Lean 하게 사업 전략을 개발"할 수 있었으나, 금융업을 만든다는 측면에서 보다 안정적인 선택을 하였었고, 요구사항의 디테일을 살려가면서 진행했다. 이로 인해 서비스 출시까지 시간이 조금 더 걸리게 된다. 


앞에서도 계속 말씀드린 것처럼 다시 돌아간다고 하더라도, 해당 선택을 할 수밖에 없을 것이다. 내가 그 당시에 알고 있던 수준에서는 최선의 선택이었다고 생각한다. 그렇기에 후회는 하지 않으며, 개선점은 이런 것이 있다는 것을 공유드리고 싶었다.



저자에 대해 궁금하시다면?

이전 05화 실패를 반복하더라도 사업 아이템을 찾아내자
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari