9월 3일에 진행한 AI 바이브톤에서 팀원과 함께 레시피 재료 금액 비교 서비스 ‘레시비’를 기획하고 만들며 느낀 점을 정리한 글입니다.
기획의 시작은 내 니즈에서 시작되었다. 최근 일을 쉬면서 요리를 자주 해먹었는데, 유튜브에서 3-4만원대의 한 끼 레시피를 보고 따라 해보려고 했을 때 필요한 재료를 대형마트에서 사면 10만원이 넘는 경우가 생겼다. 물론 유제품 같이 한 번 사두고 여러 번 쓸 수 있는 재료도 있지만, 양파 반 개를 사기 위해 3개입을 사야 하거나 고기 한 점을 넣기 위해 500g 단위로 구매해야 하는 상황이 반복되었다. 이럴 때 1만원짜리 배달 음식을 사먹는 게 오히려 낫지 않을까 생각하면서도, 막상 직접 장을 보고 요리를 하면 어느 정도 가격 절감이 되는 경우도 많았다.
초기 문제 정의와 기획은 내가 먼저 시작했다.
평소 레시피를 보고 요리하려고 할 때, 필요한 양만큼의 가격과 실제로 장을 볼 때 드는 비용이 다르다는 점이 불편하게 느껴졌다. 직접 만들면 무조건 저렴할 것 같지만, 재료를 판매 단위로 구매해야 한다는 현실적인 비용까지 고려하면 꼭 그렇지만은 않았다.
프로젝트에서는 초기 기획을 시작으로 디자인 AI를 활용한 UI 방향 설정, 프론트엔드 구현, UI 검수, 그리고 팀원이 같은 기준으로 작업할 수 있도록 MD 문서와 작업 환경을 정리·공유하는 일을 맡았다.
짧은 시간 안에 MVP를 완성해야 했기 때문에 모든 기능을 완벽하게 구현하기보다는, 사용자가 서비스의 핵심 가치를 빠르게 이해하고 실제로 사용할 수 있는 흐름을 만드는 데 집중했다.
결과적으로 8개 팀 중 2위를 했고 최우수상을 받았다.
결과도 기뻤지만, 아이디어를 기획으로 구체화하고 실제로 동작하는 서비스로 연결해 본 경험이 더 크게 남았다.
프로젝트 정보
- 프로젝트: 레시비(Recibi) — 레시피 재료 금액 비교 서비스
- 기간: 2026.09.03
- 기술 스택: Next.js, React, TypeScript, Supabase, Vercel
- 주요 역할: 초기 기획, UI 방향 설정, 프론트엔드 구현, UI 검수, 개발 문서화 및 공유
- 결과: AI 바이브톤 8개 팀 중 2위 · 최우수상
문제를 정의하는 일부터 시작했다
레시피 서비스는 대부분 만드는 법과 필요한 재료를 알려 준다.
하지만 사용자가 요리를 시작하기 전에 궁금한 것은 조리법만은 아니라고 생각했다.
배달이나 외식 비용이 부담돼 직접 요리해 보려고 해도, 실제로 얼마가 드는지 알기 어렵다.
고춧가루 한 스푼만 필요해도 한 봉지를 사야 하고, 채소나 고기 역시 필요한 양보다 더 많이 구매하게 되는 경우가 많다.
그래서 레시비는 단순히 “직접 만들면 얼마입니다”를 보여 주는 서비스가 아니라, 다음 두 비용을 함께 보여 주는 서비스로 기획했다.
- 요리에 실제로 사용하는 양만큼의 재료 원가
- 처음 장을 볼 때 필요한 전체 장바구니 금액
그리고 이 금액을 사 먹는 가격과 나란히 보여 주어, 사용자가 직접 요리할지 외식이나 배달을 선택할지 조금 더 현실적으로 판단할 수 있게 하고 싶었다.
처음 기획을 시작할 때는 레시피 추천, 재료 관리, 북마크, 가격 비교 등 여러 기능을 생각했다.
하지만 해커톤에서는 기능의 개수보다 사용자가 처음 서비스를 봤을 때 핵심을 이해하는지가 더 중요하다고 생각했다.
결국 가장 중요한 흐름은 아래 세 단계로 정리됐다.
- 유튜브 링크나 레시피 텍스트를 입력한다.
- 레시피에 필요한 재료와 비용을 확인한다.
- 직접 만들 때와 사 먹을 때의 금액을 비교한다.
이 기준이 생기고 나니, 어떤 기능을 먼저 만들고 어떤 기능을 서브로 둘지 조금 더 명확해졌다.
디자인 시안을 제안하고 개발로 연결했다
초기 UI 디자인 단계에서는 디자이너와 내가 각각 시안을 만들어 팀에 제안했다.
나는 Claude Design을 활용해 시안을 만들었고, 팀원들의 다수결 투표를 통해 내가 제안한 시안을 바탕으로 개발을 진행하게 됐다.
시안을 만드는 과정과 함께 고민한 것은 디자인 결과를 프론트엔드 구현에 어떻게 활용할지였다.
이전에 다른 서비스에서 디자이너와 협업했던 경험을 바탕으로, Claude Design으로 만든 시안의 HTML이나 MD 파일, 컴포넌트 구조를 프론트엔드 작업에 활용하는 방식을 제안했다. 그리고 팀원들도 같은 방식으로 작업할 수 있도록 활용 방법을 문서로 정리해 공유했다.
시안과 함께 화면 구조를 참고할 수 있는 자료가 있으니 프론트엔드 구현을 시작하기가 수월했다.
하루 안에 개발해야 하는 상황에서 이 방식은 작업 속도를 높이는 데 도움이 됐다. 나에게도 UI 시안을 직접 제안하는 것에서 한 걸음 더 나아가, 디자인 결과를 팀의 개발 과정으로 연결해 본 경험이었다.
화면보다 사용 흐름을 더 많이 고민했다
프론트엔드 구현에서 가장 신경 쓴 부분은 화면 하나하나보다 사용자가 서비스를 이용하는 전체 흐름이었다.
레시피를 분석하고 가격을 조회하는 동안에는 단순한 스피너 대신 스켈레톤 UI를 보여 주도록 구성했다.
사용자가 기다리는 동안에도 결과 화면에서 어떤 정보를 확인할 수 있을지 예상할 수 있게 하기 위해서였다.
또 재료 가격을 찾지 못한 경우에는 해당 재료를 조용히 제외하지 않도록 했다.
가격이 없는 재료는 사용자가 직접 값을 입력할 수 있게 했고, 주재료 가격이 누락된 경우에는 결과가 부정확할 수 있다는 점을 확인할 수 있도록 구성했다.
처음에는 계산 결과를 빠르게 보여 주는 것이 더 중요하다고 생각했다.
하지만 가격 정보가 불완전한 상황에서 낮은 금액만 보여 주면 사용자는 잘못된 결과를 믿을 수 있다.
그래서 이번 프로젝트에서는 완벽하지 않은 정보를 숨기기보다, 사용자가 어떤 값이 자동으로 계산됐고 어떤 값이 비어 있는지 확인할 수 있게 하는 데 집중했다.
이 경험을 통해 좋은 UI는 보기 좋은 화면만을 의미하지 않는다는 점을 다시 느꼈다.
사용자가 결과를 이해하고, 필요하다면 직접 보완할 수 있도록 만드는 것도 중요한 사용자 경험이었다.
문서화는 팀의 작업 기준을 맞추는 일이었다
이번 프로젝트에서 개인적으로 가장 신경 쓴 부분 중 하나는 문서화였다.
여러 사람이 제한된 시간 안에 함께 작업하면, 같은 기능도 서로 다르게 해석할 수 있다.
특히 디자인, 프론트엔드, 백엔드 작업이 동시에 진행되는 상황에서는 화면의 상태와 기능 기준이 명확하지 않으면 구현 방향이 쉽게 달라질 수 있다.
앞서 공유한 Claude Design 결과물의 활용 방법에 더해, 화면별 동작 방식과 작업 기준도 MD 문서로 정리했다.
링크 입력과 직접 입력의 전환 방식, 재료 추출 실패 시 복구 흐름, 가격이 없는 재료의 처리 방식, 북마크 동작 기준처럼 해석이 달라질 수 있는 내용을 가능한 한 문서로 남기려고 했다.
짧은 프로젝트에서는 문서화가 느린 방식처럼 느껴질 수도 있다.
하지만 기준이 남아 있으니 팀원이 작업을 이어받거나 수정할 때 맥락을 다시 설명하는 시간이 줄어들었다.
이번 경험을 통해 문서화는 결과물을 정리하는 일이 아니라, 팀이 같은 방향으로 빠르게 움직이게 만드는 일이라는 생각이 들었다.
아쉬웠던 점
심사 결과를 보면서, 서비스를 동작하게 만드는 것과 사용자가 이 서비스를 필요로 하는 이유를 설득하는 것은 다른 일이라는 생각이 들었다.
서비스 완성도는 평균 26.7점/30점이었지만, 문제 정의 및 아이디어는 14.7점/25점, 실현 가능성 및 확장성은 6점/10점이었다. 구현에 집중했던 만큼 문제를 검증하고 이후의 방향을 구체화하는 데에도 시간을 썼다면 좋았을 것 같다.
또한 비용적인 문제로 저렴한 AI를 사용하다보니 정확도가 떨어지는 것이 무척 아쉬웠다.
내가 느낀 불편함을 사용자의 문제로 충분히 검증하지 못했다
가장 돌아보게 된 피드백은 사람들이 배달을 고민하는 이유가 가격 때문인지, 직접 요리하는 번거로움 때문인지 더 고민해 봐야 한다는 의견이었다.
나는 직접 장을 보면서 느꼈던 비용 차이에서 기획을 시작했기 때문에, 두 가격을 비교해 주면 선택에 도움이 될 것이라고 생각했다.
하지만 요리할 시간이나 여유가 없어서 배달을 선택하는 사람에게는 직접 만드는 편이 저렴하다는 정보만으로 행동이 달라지지 않을 수 있다. 가격을 몰라서 망설이는 상황과 요리 자체가 부담스러운 상황을 충분히 구분하지 못했던 것 같다.
처음부터 모든 배달 이용자를 대상으로 생각하기보다, 요리할 의향은 있지만 실제 장보기 비용을 몰라 고민하는 사람처럼 대상과 상황을 더 좁혀 봤으면 좋았을 것 같다. 이후에는 실제 사용자에게 어떤 순간에 비용 비교가 필요한지, 비교 결과를 보고 선택을 바꿀 의향이 있는지부터 확인해 보고 싶다.
링크를 준비해야 시작할 수 있는 흐름이었다
심사에서는 링크를 입력하는 방식 외에, 카테고리로 나뉜 음식 중에서 선택하게 하면 좋겠다는 의견도 있었다.
유튜브에서 이미 만들고 싶은 레시피를 찾은 사람에게는 링크 입력이 자연스럽다.
반면 아직 무엇을 먹을지 정하지 못한 사람은 서비스를 사용하기 위해 먼저 다른 곳에서 레시피를 찾아야 한다. 입력 이후의 화면과 예외 처리는 많이 고민했지만, 사용자가 입력할 내용을 준비하는 과정까지는 충분히 고려하지 못했다.
음식 종류나 대표 메뉴를 선택해서 바로 비교해 볼 수 있는 흐름이 있었다면 처음 사용하는 사람도 서비스의 가치를 더 쉽게 확인할 수 있었을 것 같다. 링크 입력은 유지하되, 레시피가 없는 상태에서도 시작할 수 있는 방법을 함께 고민할 필요가 있다.
AI가 처리할 수 있는 범위와 사용자의 기대 사이에 차이가 있었다
AI로 레시피를 추출하는 방식은 긍정적인 평가를 받았지만, 영상 속 내용을 직접 추출하는 것이 아니라 댓글이나 고정 링크, 블로그 등에 레시피 정보가 있어야 한다는 한계도 지적받았다.
사용자는 유튜브 링크를 넣으면 영상만 있어도 재료와 조리법을 알아낼 것이라고 기대할 수 있다.
하지만 실제로는 별도의 텍스트 정보가 있는지에 따라 결과가 달라지기 때문에, 링크를 입력할 수 있다는 것과 그 링크에서 레시피를 추출할 수 있다는 것은 다른 문제였다.
추출에 실패했을 때 복구할 수 있는 흐름을 만드는 것에 더해, 어떤 정보를 분석할 수 있고 어떤 경우에는 직접 입력이 필요한지를 처음부터 명확하게 안내했어야 했다. 앞으로 추출 범위를 넓히더라도, 어떤 자료를 근거로 재료를 추출했는지와 사용자가 확인해야 할 부분을 함께 보여 주는 것이 중요하다고 느꼈다.
가격 데이터와 예외 상황 검증이 부족했다
구현 과정에서 아쉬웠던 부분은 가격 데이터의 정확성과 범위였다.
재료명은 같은 의미라도 다양한 방식으로 작성될 수 있고, 실제 판매 단위도 상품마다 다르다.
예를 들어 레시피에 적힌 ‘통삼겹’, ‘삼겹살’, ‘돼지고기’처럼 서로 다른 표현을 하나의 가격 데이터와 자연스럽게 연결하는 일은 생각보다 단순하지 않았다.
짧은 시간 안에는 모든 재료를 완벽하게 자동 매칭하기 어려웠다.
가격이 없는 재료를 직접 입력할 수 있도록 처리했지만, 이후에는 자주 등장하는 재료부터 데이터를 보완하고 표기 차이를 더 안정적으로 처리할 필요가 있다.
또한 다양한 레시피 형식과 예외 상황을 충분히 테스트하지 못한 점도 아쉽다.
기능이 동작하는지 확인하는 것을 넘어, 어떤 입력에서 어떤 결과가 나오는지 더 체계적으로 검증했다면 서비스의 신뢰도를 높일 수 있었을 것 같다.
확장 방향을 핵심 문제와 더 구체적으로 연결할 필요가 있었다
가지고 있는 재료로 만들 수 있는 음식을 추천해 주면 좋겠다는 제안도 받았다.
이 의견은 처음 기획할 때 느꼈던, 필요한 양보다 많은 재료를 구매하게 되는 문제와도 연결되어 있었다. 이미 있는 재료를 활용하면 추가로 사야 할 재료와 비용을 줄일 수 있기 때문이다.
다만 추천 기능을 추가하는 것만으로 서비스의 방향이 명확해지는 것은 아니라고 생각한다. 먼저 보유 재료를 반영해 추가 장보기 비용을 보여 주는 것이 필요한지, 남은 재료로 다른 요리를 찾는 것이 필요한지 확인하고 우선순위를 정해야 한다. MVP 이후에 무엇을 검증하고 어떤 순서로 개선할지까지 구체적으로 설명하지 못한 점이 아쉽다.
팀 안팎의 다양한 관점을 충분히 반영하지 못했다
협업 과정에서는 의견을 내는 사람이 일부에 집중된 점도 아쉬웠다.
나와 다른 팀원 한 명이 비교적 의견을 많이 냈고, 서비스 방향에도 두 사람의 생각이 주로 반영됐다. 여러 관점에서 아이디어와 사용 흐름을 검토하기보다는, 우리가 느낀 불편함을 중심으로 기획하고 구현한 것은 아닌지 돌아보게 됐다.
실제 배달 이용자들의 상황을 더 고려해 개발했으면 좋겠다는 피드백도 받았다.
앞서 문제 정의에서 받은 피드백과 함께 생각해 보면, 우리에게 필요하다고 느껴지는 기능이 배달 이용자에게도 필요한지 충분히 확인하는 과정이 부족했던 것 같다. 사람들이 어떤 상황에서 배달을 주문하고, 비용과 편의성 중 무엇을 더 중요하게 생각하는지 조금 더 살펴봤다면 서비스 방향을 정하는 데 도움이 됐을 것이다.
다음에는 주요 결정을 내리기 전에 각자 짧게 의견을 정리하고 공유하는 시간을 마련해 보고 싶다. 말로 바로 의견을 내기 어렵다면 문서에 먼저 적어 보는 방식도 좋을 것 같다. 여기에 실제 배달 이용자의 경험과 선택 이유를 확인하는 과정을 더해, 팀의 생각과 사용자의 필요를 함께 살피며 기획과 개발에 반영하고 싶다.
앞으로의 방향
이번 프로젝트를 통해 AI를 활용하면 디자인과 개발의 시작 속도를 높일 수 있다는 것을 느꼈다.
다만 AI가 만든 결과를 그대로 사용하는 것보다, 그 결과를 서비스의 목적과 사용자 흐름에 맞게 판단하고 다듬는 능력이 더 중요하다고 생각하게 됐다.
앞으로는 디자인 AI나 개발 AI를 사용할 때도 결과물을 빠르게 받는 데서 끝나지 않고, 다음 질문을 더 자주 해보려고 한다.
- 이 화면에서 사용자는 다음에 무엇을 해야 하는가?
- 실패하거나 정보가 부족한 상황에서도 흐름이 이어지는가?
- 이 구조를 다른 팀원이 이해하고 수정하기 쉬운가?
- 자동으로 계산된 결과를 사용자가 신뢰할 수 있는가?
프론트엔드 개발자로서 화면 구현 역량을 계속 키우는 동시에, 서비스 전체의 흐름을 보고 팀이 작업하기 좋은 기준을 만드는 역할도 할 수 있는 개발자가 되고 싶다.
마무리
이번 AI 바이브톤은 하나의 아이디어를 기획으로 구체화하고, 실제로 동작하는 서비스로 완성해 본 경험이었다.
디자인 AI를 통해 빠르게 UI 방향을 잡고, 프론트엔드 구현을 통해 사용자가 직접 사용할 수 있는 화면으로 만들었다.
그 과정에서 화면 구현만큼이나 예외 상황을 고려하고, 작업 기준을 문서화하며, 팀의 흐름을 맞추는 일이 중요하다는 것을 배웠다.
8개 팀 중 2위와 최우수상이라는 결과도 의미 있었지만, 이번 프로젝트를 통해 AI를 어떤 방식으로 활용할지와 프론트엔드 개발자로서 어떤 역할을 해나가고 싶은지를 조금 더 분명하게 생각해볼 수 있었다.
26.10.28 추가
바이브톤이 끝난 뒤에도 팀원들과 추가 개발을 이어가기로 했지만, 예정했던 시점이 지나도 진행 상황이나 다음 일정에 대한 이야기가 이어지지 않았다. 함께하겠다는 의사가 실제 작업으로 연결되지 않는 상황이 답답했고, 계속 기다리기보다는 일단 혼자서라도 리팩토링과 추가 개발을 진행하기로 했다.
아쉬움은 있지만, 이번 프로젝트를 해커톤 결과물로만 남겨 두고 싶지는 않았다. 먼저 짧은 시간 안에 구현했던 코드를 돌아보고, 심사에서 받은 피드백을 바탕으로 개선할 부분을 정리하려고 한다.
특히 실제 배달 이용자에게 어떤 정보와 기능이 필요한지 다시 확인해 보고 싶다. 혼자 진행하는 만큼 범위를 작게 잡고, 필요한 부분부터 하나씩 개선해 나갈 생각이다.