노코드 툴로 MVP 프로토타입 만들어보기

 

MVP 범위를 줄이고 나면 다음 고민은 "그럼 이걸 뭘로 만들지"입니다.
저는 개발을 직업으로 하는 사람이 아니라서, 아이디어를 직접 손에 잡히는 형태로 만들어보려면 노코드 도구가 가장 현실적인 선택지로 보였어요.
쉬는 동안 몇 가지 종류의 도구로 작은 프로토타입을 직접 만들어봤고, 그 과정에서 느낀 점을 정리합니다.
특정 제품을 추천하는 글은 아니고, 도구의 종류와 고르는 기준에 대한 기록입니다.

 

처음에는 도구 이름을 비교하느라 시간을 많이 썼는데, 나중에 보니 이름보다 종류가 중요했습니다.
제가 이해한 대로는 크게 세 갈래입니다.

 

첫째는 페이지 빌더형입니다.
블록을 끌어다 놓아 소개 페이지나 신청 페이지를 만드는 도구입니다.
고객이 처음 보는 화면을 빨리 만들 수 있고, 수요를 확인하는 용도로 좋습니다.

둘째는 데이터베이스형입니다.
스프레드시트와 데이터베이스의 중간쯤 되는 표 형태의 도구로, 데이터를 쌓고 보기 방식(표, 달력, 카드)을 바꿔서 볼 수 있습니다.
화면 모양을 얹을 수 있는 기능이 붙은 것도 있습니다.
예약 같은 "데이터가 쌓이는 서비스"의 뼈대를 시험하기에 적합했어요.

셋째는 자동화형입니다.
"이런 일이 생기면 저런 일을 하라"는 규칙으로 서로 다른 도구를 연결하는 방식입니다.
폼에 응답이 들어오면 표에 기록하고, 알림을 보내는 흐름 같은 것이죠.

 

실제 프로토타입은 이 세 종류를 섞어서 만들었습니다.
소개 페이지는 페이지 빌더로, 예약 접수 폼과 데이터 보관은 데이터베이스형으로, 확인 알림은 자동화형으로 이어붙이는 식이에요.

 

도구를 고를 때 저는 기능 목록보다 이런 질문을 먼저 봤습니다.

내가 확인하고 싶은 가설이 무엇인가.
그 가설을 확인하는 데 꼭 필요한 기능만 되는가.
데이터를 나중에 내보낼 수 있는가.
무료 범위나 시작 비용이 부담되지 않는가.
도구가 사라지거나 정책이 바뀌어도 크게 곤란하지 않은가.

특히 "데이터를 꺼낼 수 있는가"는 의외로 중요했습니다.
프로토타입이 잘 되어서 다음 단계로 넘어갈 때, 데이터가 도구 안에 갇혀 있으면 곤란하니까요.

 

가정이 섞인 예시이지만, 과정은 이런 식이었어요.
소규모 업장이 예약을 받는 흐름을 최소한으로 만든다고 해보겠습니다.

먼저 업장 소개와 예약하기 버튼이 있는 한 페이지를 만듭니다.
버튼을 누르면 날짜, 시간, 이름, 연락처를 입력하는 폼이 열립니다.
제출된 내용은 표에 한 줄씩 쌓이고, 업장 분은 이 표를 달력 보기로 바꿔서 하루 일정을 확인합니다.
접수가 들어오면 확인 메시지를 보내도록 자동화 규칙 하나를 붙입니다.

여기까지 만드는 데 며칠이 걸리지 않았다는 점이 놀라웠어요.
개발자와 협업하면 몇 주가 걸릴 수 있는 "대략의 흐름"을 직접 눈으로 확인할 수 있었습니다.

 

물론 잘 풀린 것만은 아닙니다.

가장 먼저 막힌 곳은 같은 시간에 중복 예약이 들어오는 경우를 막는 일이었습니다.
폼은 받는 것만 할 뿐, "이미 찬 시간은 선택하지 못하게" 하는 로직은 기본으로 없었어요.
이 부분은 규칙을 억지로 만들어 붙여야 했고, 그마저 완벽하지 않았습니다.

두 번째는 권한이었습니다.
업장 분이 자기 예약만 보고, 다른 업장의 예약은 못 보게 하려면 데이터를 나누는 방식을 고민해야 하는데, 도구가 지원하는 방식에 제약이 컸습니다.

세 번째는 규모였습니다.
데이터가 조금만 늘어도 느려지거나, 자동화 실행 횟수에 제한이 걸릴 수 있다는 점을 알게 됐습니다.

이런 막힌 곳은 오히려 소중한 정보였어요.
"이 부분은 코드로 직접 만들어야 하는 영역"이라는 신호이기 때문입니다.
나중에 개발자와 이야기할 때, 도구로는 안 되는 부분이 어디인지 구체적으로 말할 수 있게 됩니다.

 

좋았던 점부터 말하면, 우선 설명이 아니라 시연으로 소통할 수 있다는 점입니다.
문서로 아무리 설명해도 안 와닿던 흐름이 작동하는 화면 하나로 바로 이해되더라고요.

또 하나는 기획서의 빈틈을 스스로 발견한다는 점입니다.
직접 만들다 보면 "이 경우는 어떻게 되지?" 하는 예외가 계속 튀어나옵니다.
문서만 쓸 때는 지나쳤을 부분들이에요.

한계도 분명합니다.
노코드로 만든 프로토타입은 실제 서비스의 성능, 보안, 권한, 규모를 대신 증명해주지 않습니다.
잘 돌아간다고 해서 그대로 서비스가 될 수 있다고 착각하면 위험합니다.
또 도구의 틀에 맞춰 아이디어를 구부리게 되는 순간도 있어서, "도구가 되는 것"이 아니라 "고객이 원하는 것"을 기준으로 삼으려고 계속 의식해야 했어요.

프로토타입을 만든 뒤 가장 큰 변화는 인터뷰의 질이었습니다.
말로만 설명할 때는 "이런 서비스가 있으면 쓰시겠어요?"라는 막연한 질문이 되기 쉬운데, 화면을 보여주면 반응이 구체적으로 바뀝니다.
"여기에 직원 이름도 같이 보이면 좋겠다", "이 알림은 너무 이르다" 같은 말이 나오거든요.

다만 조심할 점도 있었습니다.
화면이 그럴듯하면 상대가 예의상 좋다고 말하는 경우가 있어서, 좋다는 말보다 "지금 쓰는 방법 대신 이걸 써보시겠어요?" 같은 행동 질문을 같이 던지려고 합니다.
프로토타입은 대화를 끌어내는 도구일 뿐, 그 자체가 증거는 아니라는 점을 계속 되새기고 있어요.

 

노코드는 만드는 도구이기 전에 질문을 빨리 던지는 도구라고 생각하게 되었습니다.
프로토타입은 완성품이 아니라 "고객에게 보여줄 수 있는 질문"이에요.

남은 질문은 이것입니다.

프로토타입으로 반응을 확인한 뒤, 어느 시점에서 도구를 갈아타고 직접 만드는 방식으로 가야 하는가.
데이터 이전이 부담스러워지기 전에 그 시점을 정하는 기준을 계속 고민해보려고 합니다.