Framer로 서비스 만들어서 가설 검증한 썰 푼다.
디자인 빼고 다 하는 디자이너
안녕하세요~! 오늘은 PoC를 위해 Framer라는 노코드툴을 사용해서 MVP를 만들고, 해당 MVP를 개선했던 사례를 전하려고 왔어요. 지금 돌이켜보니까 인턴 기간 동안 정말 많은 롤이 있었던 것 같네요ㅎㅎ
그래도 저는 재밌는 추억이라고 생각합니다.
"좋았다면 추억이고, 나빴다면 기억이다."
Whats Background - 절망 편
1️⃣ PoC를 위해 아이들이 먹고 싶은 메뉴에 투표하는 서비스 개발이 필요하지만, 개발 리소스가 부족한 상황
2️⃣ 비극의 시작: 버튼 2개 두고, 어떤 버튼 눌렀는지 저장만 하면 되는 것 같은데.. 이거 나도 할 수 있지 않을까..?
3️⃣ "제가 한 번 해보죠 뭐"
Research
레딧 글 찾아보면서 framer에서 이벤트를 걸어서 어딘가로 보낼 수 있다는 것을 알게 되었어요.
A에서 B로 무언가를 보내주는 역할을 하는 것을 webhook이라고 부른다는 것을 확인했어요.
webhook을 개발 없이 사용하게 해주는 SaaS가 이미 많이 있다는 사실을 알게 되었어요.
"DB가 없으니까 구글 시트에 기록해 볼까?"
“아.. 이거 되겠다.”
단순하게 그려본 PoC 서비스 도식화Whats Problem
투표 버튼에 webhook 이벤트를 걸기 위해 Framer에서 custom으로 코드를 작성해야 함.
즉, 커스텀 기능을 추가하려면 피그마에서 만드는 컴포넌트가 아니라 진짜 개발자의 컴포넌트가 필요하다는 것을 알게 됨..
How Solve?
당황하지 않고, chatGPT한테 부탁했음
� 당시 chatGPT 작성 예시 :
"나는 지금 Framer로 컴포넌트를 구현하고 있어. 먼저, Framer의 code component에서 버튼 두 개를 만들어서, figma의 autolayout - vertical처럼 묶어줘.
각 버튼 안에는 메뉴명이 들어갈 텍스트가 있고, 그 텍스트는 내가 쉽게 바꿀 수 있어야 해. 각 버튼을 누르면 해당 버튼명과 숫자 '+1'씩 웹훅 SaaS를 통해 구글 스프레드 시트에 1개의 row로 추가되는 기능을 코드로 작성해 줘."
Framer로 구현한 투표 버튼 컴포넌트flow는 매우 단순합니다. 짜장면과 짜장밥이라는 텍스트가 써진 버튼을 누르면 해당 버튼의 label과 누른 횟수를 Webhook을 통해 구글 시트로 보내서 자동으로 시트에 기록하는 것이죠.
구글시트에 자동으로 기록되는 투표 결과2시간 정도 삽질 후, 구글 시트에 적재되는 걸 확인하고, 본격적으로 서비스 플로우를 구체화할 수 있었습니다.
시간이 매우 부족했기 때문에, 별도의 스케치나 디자인 없이, framer에서 코드로 컴포넌트의 스타일을 조절하면서, 빠르게 화면을 구성했고, 그 결과는..! (두근두근)
그래요, 저는 디자이너 실격입니다.네, 뭐 ,, 좀 그렇죠? 욕심이야 당연히 있었지만, 촉박한 타임라인 안에서 혼자 코드까지 작성해야 하는 입장에서 정말 상대적으로 시각적 요소가 우선순위가 낮아질 수밖에 없었습니다. 정말 최소한의 마지노선 정도로만 스타일을 넣어주고, 다음을 기약하며 디자인을 놓아주었습니다.
사진을 따로 첨부하지 않았지만, 해당 페이지에서 학생들에게 선호 메뉴를 투표받으면, 구글 시트에 데이터를 기록 후, 해당 선호 데이터를 분석해서 영양교사에게 모바일로 제공하는 웹 화면도 비슷한 방식과 퀄리티(?)로 구현할 수 있었습니다.
So.. What?
PoC 이전에 가장 궁금했던 점은, "이거 실제로 잘 동작은 하나?!"였습니다. 제가 자체적으로 테스트하는 거야 그렇다 쳐도, 아예 다른 환경에서 수많은 변수에 있어서도 정말 고객이 느끼기에 하나의 서비스처럼 워킹하는지 알고 싶었고, 알아야만 했습니다.
PM님이 그동안 고객사와 쌓은 얇고 질긴 신뢰 덕분에, 어렵지 않게 모집할 수 있었고, 그렇게 MVP로 실제 테스트를 진행했습니다.
결과는 어땠을까요?
서비스를 사용하고 있는 XX 학교의 학생섣부른 판단일 수 있지만, 이렇게 낮은 완성도의 서비스로 매일 학생들이 투표에 임해주고, 귀찮을 수 있는 태블릿 운영을 영양교사님이 매일 해주신다는 점에서 정확히는 모르겠지만 이 서비스로 어떠한 가치를 제공할 수 있겠다고 생각했고, 기뻤습니다.
하지만, 동시에 큰 문제가 생기게 되었는데..
Whats Problem? - 희망 편
▶️ 매일 돈이 빠져나가고 있다 !
Framer의 결과 페이지에서 데이터를 받아와야 하는 상황에서 구글 시트에 적재된 데이터를 다시 보내기 위해서는 또 하나의 Webhook이 필요한데요,
문제는 제가 Webhook을 SaaS를 사용하고 있었기 때문에, 한 개의 기관을 기준으로 한 달을 사용했을 때의 금액과 기관이 기하급수적으로 늘어나는 상황을 고려했을 때, 언제까지나 계속 SaaS를 사용하는 것은 무리라고 판단했습니다. 물론 제 돈은 아니지만,.. 그래도..
▶️ 매일 귀찮은 일을 해야 한다 !
또 하나의 문제로는, 저에게는 가장 큰 문제이기도 했었는데.. 바로 수동 대응 문제입니다. Framer와 구글시트로 구현한 이 서비스는 결국, 결과를 저장한다에 머물러 있기 때문에,
매번 투표를 할 이미지와 메뉴명을 제가 Framer에서 해당 기관 프로젝트에 들어가서 타이핑으로 고치고, 다시 publish를 해줄 수밖에 없는 구조였습니다.
이 눈물 나는 프로세스를 정리하자면, 다음과 같아요.
1️⃣ 매일 기관별로 framer 프로젝트에 직접 메뉴명과 음식 사진 수기로 교체 (기관마다 5분씩 소요)
2️⃣ 매일 기관별로 적재되는 스프레드 시트에서 오늘 들어온 데이터 정리 (기관마다 5분씩 소요)
3️⃣ 다시 기관별로 framer 프로젝트에 직접 오늘의 결과(메뉴명, 숫자) 교체 (기관마다 5분씩 소요)
이 짓을 운영 기관별로 매일 해야 한다는 점은 실무자 입장에서 꽤 부담이 되었고, 어렵지 않게 개선할 수 있다는 것은 알았지만,
다른 프로덕트의 디자인 업무로 우선순위가 계속 낮아지다 보니 어쩔 수 없이 울면서 매일 수동으로 대응할 수밖에 없는 상황이었습니다.
How Solve?
울면서 기회를 계속 노리다가, 어느 정도 시간이 생긴 순간 바로 개선작업을 착수했습니다. 이전과 다른 점이 있었다면, 매일 이 서비스를 굴리고 있었기 때문에,
이제는 이 서비스의 우선순위가 상대적으로 높아졌고, 팀의 프론트 개발자분에게 적극적으로 물어볼 수 있었습니다. 천군만마를 얻은 셈이죠. 후훗
아무튼, 그래서 또 하나의 DB 역할을 맡아줄 친구를 찾다가 Airtable을 발견했고, 확장성을 고려했을 때도 충분히 워킹할 수 있겠다고 판단해서, 간단하게 아래의 도식화를 그려보았습니다.
서비스 도식화 2사실 UI 쪽은 개선하지 않아서, 겉으로 봤을 때는 이전과 다를 게 없지만, 메뉴명과 이미지를 날짜와 기관에 맞춰서 알아서 받아오는 것만으로도 개인이 느끼기에는 굉장히 큰 임팩트가 있었습니다.
결국, 수동으로 이미지와 메뉴명을 넣어줬던 예전과 비교했을 때, 현재는 휘파람만 불고 있어도, 자동으로 데이터를 Framer와 DB에서 주고 받고 있는 상태입니다.
그래요. 이제 저는 자유입니다.
잘은 모르지만 제가 이 코드를 보면서 크게 이해했던 방식특히 fetch 같은 경우는 정말 이해하고 싶어서, 팀 개발자분에게 몇 번씩이나 물어보면서, HTTP와 통신의 개념을 어렴풋하게 학습할 수 있었고,
제가 지금 하는 작업에 있어서 알아두면 좋을 것 같다고 판단해서, 아티클을 찾아보면서 활용도를 조금 더 높이는 시도를 할 수 있었어요.
아 글을 쓰는데, 문득 찐 개발자들은 어떤 표정으로 이 글을 읽고 있을까 궁금하네요.
흐름을 이해하고 싶어서 울면서 그렸던 서비스 도식화네, 아무튼 깔끔하게 정리하자면 이런 흐름으로 데이터가 자동으로 업데이트되고 있어요.
제 기준에 진짜 까다롭고 어려웠던 Validate 관련된 부분들.. 도 같이 적으려다가 이건 그냥 따로 빼는 게 나을 듯싶어서 일단은 절제했습니다.
예를 들면 이런 상황:
장난으로 한 사람이 하나의 버튼을 200번씩을 누르는 케이스는 어떻게 적재해야 하고, 어떻게 예방하지?
웹이다 보니까, 장난으로 다른 웹페이지로 이동하거나 태블릿을 아예 꺼버리면 어떻게 식별하고 어떻게 대응하지?
user_id가 없는 상황에서 결과 페이지에서 A라는 유저가 ㄱ초등학교 영양사라는 것을 어떻게 식별하지?
아무튼, 매우 간단한 서비스(?)지만, 처음부터 끝까지 백지에서 이렇게 직접 구현해 보니까, 신기하기도 하고 뿌듯하기도 했어요.
Lesson & Learn
▶️ Framer, 이 놈 봐라?
결론이 뭔가 ‘코딩을 배우자’처럼 보일까 봐 걱정이지만, 핵심은 결국 Framer는 디자인 툴이라는 점을 말씀드리고 싶어요.
주변 어떤 이해관계자보다 Framer를 잘 사용할 수 있는 사람은 디자이너라는 점은 꽤 많은 의미를 가지고 있다고 생각해요.
기존의 Framer가 갖고 있는 Design Based & Publishing이라는 메리트에서 약간의 고민 + 약간의 노력 + 매우 많은 시행착오를 더 한다면, front-back까지 대응할 수 있는 수준까지 프로토타입의 fidelity를 높일 수 있다!
▶️ 언제나 몇 번이라도, 효율은 개선할 수 있다 !
이번 자동화 작업을 통해 기존 수동 대응 방식 기준으로 기관당 10분씩 잡아도, 약 매일 100분 정도 절약하는 효과를 낼 수 있었어요.
기술을 활용하는 것도, 기술을 도입하는 것도 다 중요하지만, 결국 본질은 왜 이걸 이렇게 해야 하는지? 끊임없이 고민하는 것이 중요하다고 생각해요.
PoC는 어떻게 될 것 같나요?
늘 그렇듯, 잘 모르겠읍니다.
7월부터 15개교 정도 진행할 예정
좋은 결과가 있다면, 바로 공유드리겠습니다.
후, 대충 쓰려고 했는데 오늘도 몰입해 버렸네요. 재미없는 글 읽어주셔서 감사합니다.
다음에 보아요~
