코드보다 화면 먼저: 프로토타입이 앱 수정 비용을 줄이는 이유

핵심 요약

• 프로토타입은 동작하기 전의 실제 화면이에요. 보면서 고치는 게 목적이에요.
• 화면을 보고 "이게 아니네"를 알게 되는 순간을 개발 전으로 당기면, 고치는 비용이 화면 하나로 끝나요.
• 글로 합의한 기획도 화면으로 보면 다르게 보여요. 놓친 화면, 어색한 순서가 그때 드러나요.
• 핑거는 화면 기획을 고친 다음, 그 화면 그대로 실제 앱을 만들어요.

글로 정한 것과 화면으로 본 것은 달라요

"손님이 메뉴를 고르고 주문하면 사장님이 확인한다." 기획서에선 한 줄이에요. 그런데 화면으로 그려 보면 질문이 쏟아져요.

• 메뉴는 사진이 크게 나오나요, 목록으로 빽빽하게 나오나요?
• 옵션(사이즈, 추가 토핑)은 어디서 고르나요?
• 주문하고 나면 손님은 무슨 화면을 보나요?
• 사장님은 새 주문을 어디서 알게 되나요?

글로는 모두가 고개를 끄덕였는데, 화면을 보니 각자 상상한 게 달랐다는 걸 알게 되는 경우가 많아요. 이걸 개발 전에 알면 화면만 고치면 돼요. 개발 후에 알면 이미 만든 기능을 뜯어고쳐야 해요.

언제 알게 되느냐가 비용을 정해요

같은 변경도 언제 하느냐에 따라 드는 품이 달라요. "주문할 때 가입 대신 전화번호만 받자"는 변경으로 예를 들어 볼게요.

개발 후의 변경은 눈에 보이는 화면보다 보이지 않는 곳(데이터와 권한)을 더 많이 건드려요. 그래서 비싸요. 프로토타입은 이 변경을 가운데 줄로 끌어올리는 도구예요.

프로토타입에서 정해야 할 것

화면 목록과 이동

어떤 화면이 있고, 어디서 어디로 가는지. 손님 쪽 화면(첫 화면, 목록, 상세, 주문 · 예약, 내 기록)과 운영자 쪽 화면(새 주문, 손님 목록, 설정)을 나눠서 보면 빠진 화면이 잘 보여요.

각 화면의 정보와 버튼

첫 화면에 무엇을 가장 크게 보여 줄지, 버튼 문구는 무엇인지. "제출" 대신 "예약하기", "확인" 대신 "주문 받기"처럼 구체적인 문구가 손님을 덜 헷갈리게 해요.

색 · 글꼴 · 분위기

브랜드 색 하나와 글꼴 하나만 정해도 앱이 훨씬 우리 것처럼 보여요. 케이크 가게와 법률 사무소의 앱은 분위기가 달라야 해요.

휴대폰에서의 모습

손님 대부분은 휴대폰으로 들어와요. 휴대폰 화면에서 버튼이 엄지로 눌리는 크기인지, 글이 잘리지 않는지 확인하세요.

프로토타입은 누구에게 보여 줘야 할까요

화면이 그려졌다면 혼자 보지 말고 꼭 다른 사람에게 보여 주세요. 만든 사람은 어디를 눌러야 할지 이미 알아서, 헷갈리는 곳을 못 찾아요.

• 실제로 쓸 손님 두세 명: 휴대폰을 건네고 "예약해 보세요"라고만 말해 보세요. 손가락이 멈추는 곳이 고칠 곳이에요. 설명을 덧붙이고 싶어지면 그 화면이 불친절하다는 뜻이에요.
• 같이 운영할 직원: 손님 화면보다 운영자 화면을 보여 주세요. "새 예약은 어디서 봐요?", "취소는 누가 해요?" 같은 질문이 나오면 그 답을 화면에 담아야 해요.
• 함께 일하는 사람(동업자, 투자자, 외주 개발자): 글로 된 기획서보다 화면 몇 장이 훨씬 빨리 같은 그림을 그리게 해 줘요.

이때 나오는 의견은 "이 버튼이 안 보여요", "이 화면이 왜 필요해요?"처럼 아주 구체적이에요. 글로 된 기획서를 보여 줬을 땐 나오지 않던 의견들이에요. 그리고 이 의견을 반영하는 비용은 아직 화면 하나예요.

프로토타입의 함정 두 가지

1. 예쁜 그림에서 멈추는 것. 디자인 도구로 정성껏 그린 화면도 개발자에게 넘기는 순간 다시 해석돼요. 색이 미묘하게 다르고, 간격이 달라지고, 그 차이를 맞추느라 또 시간이 들어요. 프로토타입이 실제 앱으로 그대로 이어지는 게 가장 좋아요.

2. 프로토타입에서 모든 걸 정하려는 것. 프로토타입의 목적은 큰 방향과 화면 구성을 정하는 거예요. 버튼 색의 미세한 차이까지 붙잡고 있으면 출시가 늦어져요. 실제 앱이 나온 뒤에도 고칠 수 있어요.

핑거에서는: 화면 기획 → 그대로 실제 앱

핑거(fingr)는 이 단계를 앱 만드는 흐름 한가운데에 둬요.

1. 아이디어를 적고 질문에 답하면, 필요한 기능과 화면 목록을 제안해요. 어울리는 디자인 템플릿도 여러 스타일 중에서 골라요.
2. 실제 화면이 그려져요. 보면서 문구 · 배치 · 색 · 글꼴을 고치고, 필요한 화면을 더해요. 가입하지 않고도 여기까지 해 볼 수 있어요.
3. 마음에 들면 「이 디자인으로 실제 앱 만들기」를 눌러요. 핑거가 고친 화면 · 색 · 글꼴을 그대로 따라 가입 · 로그인 · 데이터 저장 · 결제가 되는 웹앱을 만들어요. 보통 몇 분이면 나오고, 화면에 없던 운영자(관리자) 화면도 첫 버전부터 들어 있어요.

화면을 다시 그려서 넘기는 과정이 없으니 "디자인과 결과가 다르다"는 문제가 줄어요. 사진이 필요한 자리(메뉴, 선생님, 매장 카드)에는 그림 대신 실제 같은 사진이 들어가요.

실제 앱이 나온 다음에도 바꿀 점을 글로 적으면 고칠 수 있어요. 고치기 전에 어느 정도 크레딧이 들지 최대치를 먼저 보여 주고(작은 수정 5 · 보통 10 · 기능 하나 30 · 큰 기능 40 크레딧), 다 만든 뒤 실제로 든 만큼만 빠져요. 그래도 큰 방향은 화면 기획 단계에서 정해 두는 게 가장 싸요.

이럴 땐 다른 방법이 나아요

• 디자이너가 픽셀 단위로 화면을 그리고 싶을 때: Figma 같은 전문 디자인 도구가 맞아요. 핑거의 화면 기획은 비개발자가 보면서 고치는 데 맞춰져 있어요.
• 화면을 몇 초 만에 수십 번 바꿔 보고 싶을 때: v0나 러버블처럼 즉시 바뀌는 도구가 편해요. 대신 그 화면을 데이터 · 로그인 · 운영자 화면까지 갖춘 서비스로 만드는 마지막 단계는 직접 챙겨야 해요. v0 vs 핑거 글에서 차이를 정리했어요.

화면 기획 전에 무엇을 만들지부터 정하고 싶다면 만들기 전에 시장 조사부터 글을 먼저 읽어 보세요.

시작해 보기

만들고 싶은 앱을 한두 문장으로 적으면, 몇 분 안에 화면이 그려지고 보면서 고칠 수 있어요. 마음에 드는 화면이 되면 그대로 실제 앱으로 만들어요. 무료 크레딧으로 앱 하나를 만들 수 있고 카드 등록도 필요 없어요. 화면부터 만들어 보기.