2026 비전공자의 첫 바이브 코딩 MVP 만들기: 페스티봄 핵심 기능과 범위 정하기

첫 MVP 제작기 feat 바이브 코딩

페스티벌 하나를 알아보려면 생각보다 손이 많이 갑니다. 일정은 공식 홈페이지에서 확인하고 출연진은 인스타그램에서 다시 찾으며, 티켓 정보는 예매 사이트로 넘어가야 하죠. 행사가 끝난 뒤의 기록도 사진첩과 SNS 여기저기에 흩어집니다.

페스티봄은 이런 불편을 한곳에서 해결해보자는 생각으로 구상하고 만들어본 첫 바이브코딩 MVP입니다. 앞으로 열릴 페스티벌을 쉽게 찾는 것, 좋아하는 아티스트가 어떤 무대에 나왔는지 살펴보는 것, 직접 다녀온 날의 기억을 남기는 것. 처음부터 목표는 이 세 가지였죠.

이번 글에서는 제가 도전한 ‘바이브코딩으로 첫 MVP 만들기’ 과정에서 페스티봄의 주제를 고른 이유와 처음 정한 핵심 기능, 첫 MVP의 범위를 어디까지 잡았는지 정리해보겠습니다.

첫 바이브코딩 MVP로 페스티봄을 만들게 된 이유

페스티벌 정보는 보통 한 번에 공개되지 않습니다. 개최 소식이 먼저 올라오고 출연진과 티켓 일정은 며칠 또는 몇 주 뒤에 따로 발표되죠. 관심 있는 행사가 늘어날수록 공식 채널을 하나씩 확인하는 일도 번거로워졌습니다.

그래서 가장 먼저 떠올린 화면이 월별 달력이었죠. 같은 달에 열리는 행사를 한눈에 비교하고 관심 있는 페스티벌을 누르면 장소와 출연진, 티켓 정보까지 이어서 확인하는 방식입니다. 여러 사이트를 오가며 같은 내용을 다시 찾는 시간을 줄이고 싶었습니다.

일정을 모아 보여주는 것만으로는 부족했습니다. 페스티벌에 다녀오고 나면 기억에 남는 무대와 사진이 생기지만 시간이 지나면 언제 누구를 봤는지 찾기 어려워집니다. 쉽게 찾은 페스티벌을 실제로 다녀온 기록까지 이어서 남기고 싶었던 이유입니다.

첫 바이브코딩 MVP 주제는 익숙한 불편에서 골랐다

첫 MVP를 만들 때는 아무 주제나 고르기보다 내가 관심을 가지고 있고 어느 정도 알고 있는 분야에서 시작하는 편이 좋았습니다. 익숙한 분야일수록 어떤 점이 불편한지 구체적으로 설명할 수 있고 무엇부터 바꿔야 하는지도 떠올리기 쉬웠기 때문입니다.

페스티봄을 선택한 이유도 같았습니다. 평소 페스티벌에 관심이 많아 관련 정보를 자주 찾아봤고 일정과 출연진, 티켓 정보가 여러 곳에 흩어진 불편을 직접 알고 있었죠. 누군가에게 들은 문제가 아니라 제가 반복해서 겪었던 문제였습니다.

MVP는 거창한 아이디어보다 직접 사용하면서 불편했고 개선해보고 싶었던 문제에서 출발하는 것이 접근하기 쉬웠습니다. 이미 알고 있는 흐름을 바탕으로 필요한 기능을 정하고 결과가 실제로 편해졌는지도 스스로 확인할 수 있는 셈입니다.

그래서 첫 주제는 새로운 분야를 억지로 찾기보다 관심과 경험이 있는 영역에서 작은 불편을 고르는 데 집중했습니다. 페스티봄에서는 여러 사이트를 오가며 정보를 찾는 과정을 줄이는 것이 시작점이었습니다.

처음 정한 핵심 기능과 MVP 범위

넣고 싶은 기능을 처음부터 전부 만들기 시작하면 끝이 보이지 않습니다. 첫 MVP에서는 페스티벌을 찾고 필요한 정보를 확인한 뒤 관람 기록을 남기는 흐름이 제대로 이어지는지만 보기로 했죠. 화면을 많이 만드는 것보다 사용 목적이 분명한 기능부터 완성하는 쪽을 택했습니다.

월별 페스티벌 일정을 달력에서 확인하기

메인 화면의 중심에는 월별 페스티벌 달력을 뒀습니다. 같은 달에 열리는 행사가 한눈에 들어오고, 여러 날 이어지는 페스티벌은 시작일과 종료일까지 함께 볼 수 있게 짰습니다.

달력에서 행사를 고르면 상세 페이지가 열립니다. 날짜와 장소뿐 아니라 출연진과 티켓 정보도 한 화면에 모았습니다. 페스티벌을 발견한 뒤 필요한 내용을 다시 검색하지 않아도 되는 구조가 핵심이었죠.

아티스트를 기준으로 출연 페스티벌 확인하기

페스티벌을 날짜로만 찾는 것은 아닙니다. 좋아하는 아티스트의 출연 소식을 보고 처음 알게 되는 행사도 많죠. 그래서 아티스트 페이지에서 이전에 출연했거나 앞으로 출연할 페스티벌을 함께 보여주려 했습니다.

여기서 아티스트 중복 문제가 생깁니다. 같은 아티스트가 표기 차이 때문에 여러 명으로 등록되면 출연 이력도 서로 나뉩니다. 이를 막으려고 아티스트 이름을 하나의 기준으로 관리하고 같은 이름이 중복 등록되지 않도록 초기 데이터 구조에 반영했습니다.

구체적인 테이블 구성과 연결 방식은 데이터 구조를 다루는 편에서 정리할 내용입니다. 이번 글에서 중요한 부분은 아티스트를 단순한 글자가 아니라 여러 페스티벌을 연결하는 정보로 잡았다는 점입니다.

다녀온 페스티벌의 기억 남기기

행사에 다녀온 뒤에는 관람 기록을 남길 수 있도록 구상했습니다. 어느 페스티벌에 갔는지 저장한 다음, 관람한 아티스트와 기억에 남는 내용, 사진을 한곳에서 다시 확인하는 기능입니다.

이 기록은 다른 사람에게 보여주기 위한 후기와 조금 다릅니다. 내가 언제 어떤 무대를 봤는지 차곡차곡 모으는 개인 기록에 가깝죠. 페스티봄을 한 번 보고 닫는 일정표가 아니라 시간이 지나도 다시 찾는 서비스로 만들고 싶었습니다.

서비스를 계속 운영하려면 관리자 시스템이 필요했다

정보를 보기 좋게 보여줘도 내용이 갱신되지 않으면 오래 쓰기 어렵습니다. 페스티벌 일정과 출연진, 티켓 정보는 서로 다른 시점에 공개되고 발표 뒤에 바뀌기도 하죠.

서비스를 계속 운영하려면 정보를 모으고 새로운 페스티벌을 쉽게 올릴 수 있는 관리자 시스템이 필요했습니다. 출연진이나 티켓 정보가 추가로 발표되면 기존 내용을 바로 수정하고, 잘못 들어간 정보도 다시 고칠 수 있어야 했습니다.

처음에는 방문자에게 보이는 달력과 상세 화면을 만드는 일이 더 중요해 보였습니다. 실제로는 페스티벌과 아티스트, 출연진과 티켓 정보를 연결하고 쉽게 등록·수정하는 관리자 시스템에 더 많은 시간이 걸렸죠. 겉으로 보이는 화면보다 그 안의 정보를 계속 채우고 관리하는 구조가 서비스를 유지하는 핵심이었기 때문입니다.

그래서 모든 기능을 한꺼번에 넣기보다 달력과 상세 화면, 관리자 시스템이라는 뼈대를 먼저 만들었습니다. 그 뼈대가 제대로 이어지는지 확인한 뒤 필요한 기능을 하나씩 추가했죠. 작은 기능을 계속 더하더라도 중심 구조가 흔들리지 않게 만드는 것이 페스티봄의 첫 MVP에서 가장 중요했습니다.

첫 바이브 코딩 MVP는 내가 잘 아는 문제에서 시작했다

바이브 코딩으로 무언가 만들어보겠다고 마음먹어도 막상 주제를 정하려면 막막합니다. ‘무엇을 만들어야 하지?’라는 생각에서 시작이 멈추기도 하죠.

첫 MVP는 거창하거나 새로워 보이는 아이디어보다 내가 관심을 가지고 잘 아는 분야에서 찾는 편이 좋았습니다. 그래야 문제를 구체적으로 설명하고 필요한 기능도 정하기 쉬웠기 때문입니다.

직접 사용하면서 반복해서 불편했던 문제를 고르고, 가장 먼저 해결하고 싶은 핵심만 작은 범위로 정하면 결과도 판단하기 쉽습니다. 처음부터 많은 기능을 넣기보다 기본 흐름이 이어지는 뼈대를 만든 뒤 필요한 기능을 하나씩 더하는 것. 이것이 페스티봄을 만들며 배운 MVP 범위 설정 방법입니다.

다음 글에서는 페스티봄을 만들면서 공부한 코드의 뼈대와 프로젝트 구조를 이야기해보겠습니다. 제가 만든 첫 바이브 코딩 MVP 페스티봄에도 많은 관심 부탁드립니다.

\n\n