Festino는 한국공학대학교 대동제 정보 제공을 목적으로 개발한 웹 사이트이며,
약 한 달 반의 기간 동안 신규 기능 회의, 개발 및 테스트를 통해 성공적으로 프로젝트를 마무리하였습니다😎
👨💻Festino 개요
[축제기간]
2025. 05. 26. (월). ~ 2025. 05. 28. (수).
[프로젝트 기간]
2025. 04. ~ 2025. 05. (약 한 달 반 / 신규 기능 기획 ~ 최종배포)
[정기회의]
매주 일요일 18시
[팀원]
총괄리더 1명, FE 4명, BE 4명 (총 9명)
[기술스택]
FE: React, TypeScript, tailwind, zustand(상태관리), Vite
BE: Spring Boot
DB: MySQL
IDE: IntelliJ IDEA Ultimate 2024, Postman, Visual Studio Code
[Github] https://github.com/DEV-TINO/Festino
👨💻개발에 앞서...
개발 배경
대학교 3학년이 되어 새 학기가 시작된 2025년 3월, 개발 소모임 Dev-Tino에 속한 친구로부터 한 가지 제안을 받았다.
“올해도 2025 대동제에서 사용할 Festino를 개발할 건데, 프론트엔드 파트 개발 해볼 생각 있어?”
Festino는 이미 2024 한국공학대학교 대동제에서 사용되어 성공적으로 운영된 바가 있어서, 처음에는 “이미 다 만들어졌는데, 뭘 더 개발한다는 거지...?”라는 의문이 들기도 했다.
하지만 이번에는 단순 유지보수가 아닌, 기술 스택 전환과 기능 확장이라는 목표가 있었다.
기존 Vue.js 기반으로 구현되어 있던 Festino를 React + TypeScript 기반으로 전체 마이그레이션을 진행하는 것이 첫 번째 목표였고, 로그인/회원가입 등 유저 관련 기능, 사용자 참여형 이벤트 기능, 부스에서 친구와 함께 메뉴를 고를 수 있는 함께주문하기 기능, 테이블 별 주문 상황을 시각적으로 보여주는 테이블 시각화 기능 등의 추가 기능 개발을 통한 기능 확장이 두 번째 목표로 해당 프로젝트의 개발이 시작되었다.
프로젝트 팀 조직
이번 프로젝트는 이미 개발을 진행해 왔던 Dev-Tino의 구성원들과 함께하는 프로젝트였다.
2024 대동제에서 사용된 Festino 개발에 참여했던 총괄 팀장님과 프론트엔드 2명, 백엔드 4명으로 구성되어 있던 팀에, 나와 프론트엔드 팀원 한 명을 추가하여 최종적으로 총괄 팀장, 프론트엔드 4명, 백엔드 4명으로 총 9명의 인원이 투입되었다.
신규 기능 회의
Festino의 공지사항, 타임테이블, 부스 관련 기능, 예약하기, 주문하기 등의 기능은 React기반으로 마이그레이션만 진행하면 될 정도로 개발이 되어있었기 때문에 기존 기능의 개선보다는 신규 기능을 추가하는 방향으로 프로젝트를 진행하기로 하였다.
신규 기능 회의의 경우 약 3주간 진행되었다.
유저 관련 기능을 로그인/회원가입 외에 어디까지 구현할 것인지, 함께 주문하기 기능을 어떻게 구현할 것인지, 테이블 시각화 진행 시 어떠한 정보를 어떻게 보여줄 것인지 등 각 기능 설계에 필요한 내용을 같이 이야기하며 신규 기능 기획을 진행하였다.
이벤트 기능의 경우, 경영학과 소속 학생들과 협업을 진행하면서 이벤트 종류, 운영 방식, 경품 지급 대상 및 경품 종류 등을 포함한 이벤트 기획안을 구성하고, 이에 대한 구체적인 개발 방향을 개발팀과 논의하는 방향으로 회의를 진행하여 현실적으로 구현 가능한 이벤트 기능 기획을 진행하였다.
신규 기능 와이어프레임 작성
신규 기능 회의에서 나온 내용을 가지고 개발을 하기에 앞서, 각각의 기능이 웹사이트 상에서 어떠한 형태의 UI로 구성되어야 하는지를 나타내는 와이어프레임을 제작하였다.
와이어프레임을 작성함으로써, 백엔드 담당자들은 보다 직관적으로 API 명세서를 작성할 수 있었고, 프론트엔드 담당자들은 요구사항 명세서를 기반으로 추가적인 UI 디자인을 명확히 요청하고 전달받을 수 있었다.
진행 과정
| 진행 기간 | 진행 내용 |
| 1~3주차 | 신규 기능 회의 및 와이어프레임 제작 & API 명세 작성 |
| 4~6주차 | 신규 기능 API 개발, 기존 Vue.js 코드 React기반으로 마이그레이션 진행, 신규 기능 관련 퍼블리싱 |
| 7~8주차 | 신규 기능 구현, 버그 픽스 |
| ~ 5월 25일 | 테스트 진행 및 버그 픽스 |
사실 초기 계획은 대동제 일주일 전에 Festino 베타 서비스를 배포하여, Festino를 사용할 각 학과들이 미리 기능을 체험하고 피드백을 줄 수 있도록 하는 것이었다.
하.지.만,
프론트엔드 작업의 반복적인 지연으로 인해 예정된 일정에 맞춰 배포를 진행할 수 없었고, 결국 기능 구현에만 집중한 채 급하게 마무리하는 상황에 이르렀다.
학과별로 피드백을 받아 기능을 개선하거나 추가할 계획이었지만, 실제 학과들이 Festino를 사용해 볼 여유조차 없었고, 개발팀 내에서도 테스트 시간을 충분히 확보하지 못했다.
그 결과, 막바지에는 코드 컨벤션이나 구조적인 완성도까지 신경 쓸 여유도 없이 아슬아슬하게 개발을 마무리하게 되었다.
👨💻개발 결과
Mobil Main WebApp
공지사항
Festino 웹 서비스와 관련한 공지사항들을 전달하는 기능을 제공
타임테이블
대동제에서 진행하는 동아리 공연, 연예인 공연 시간 대한 정보를 제공
공연에 참가하는 동아리 정보와 공연자 정보 및 공연 내용에 대한 정보 확인 가능
부스
메인 부스 페이지에서 부스 지도를 통해 전체적인 부스 위치 및 부스 목록 확인 가능
부스 상세 페이지를 통해 해당 부스의 운영 시간, 활동, 메뉴에 대한 정보를 제공
admin 페이지의 기능을 통해 부스 상세 페이지에 노출될 정보 수정 기능 제공
테이블링
야간부스 입장 웨이팅을 등록할 수 있는 기능을 제공
이름, 전화번호, 일행의 수를 입력하여 야간부스 입장 웨이팅 등록 가능
해당 기능은 야간부스 운영진들이 admin 페이지를 통해 사용 여부 관리 가능
주문하기
각 테이블 별로 제공되는 주문 url이 담긴 QR코드를 인식하면 주문하기 페이지로 이동되어 메뉴 주문을 진행할 수 있도록 '주문하기' 기능 제공
동일한 QR을 여러 명이서 접속하여 함께 주문할 수 있도록 '함께주문기능' 추가 제공
작년에 진행된 Festino는 계좌 이체를 통한 입금뿐만 아니라 '토스페이를 통한 결제' 기능 제공
주문 완료 시 야간부스 관리자가 입금 대기, 입금 완료여부를 확인하여 주문 내역을 관리할 수 있도록 admin 페이지를 통해 주문관리기능 제공
사용자의 이름과 전화번호를 입력하여 주문 내역을 확인할 수 있는 '주문조회' 기능 제공
이벤트 (리뷰, 사진, 실시간 퀴즈)
Festino 사용 후기 작성을 통해 참여 가능한 '리뷰 이벤트',
대동제 현장을 담은 사진 업로드 기능 및 Festino 사용자들이 투표할 수 있는 좋아요 기능을 제공하는 '사진 업로드 이벤트',
특정 시간대에 실시간 퀴즈 이벤트에 참여할 수 있도록 출력되는 모달을 통해 대동제와 관련된 퀴즈를 풀어서 참여할 수 있는 '실시간 퀴즈 이벤트' 진행
Web Admin
부스 관리
1) 부스 정보 수정
Admin 페이지를 통해 부스 운영진들은 부스 정보 및 메뉴 정보 등의 상세 내용 변경 가능
야간 부스의 경우 예약 및 주문 기능 사용 여부 또한 Admin 페이지를 통해 관리 가능
2) 테이블 관리
야간부스는 테이블을 원하는 만큼 생성하고, 테이블 번호를 마음대로 커스텀 가능
등록된 테이블에 맞는 주문 QR이 생성되며, 이를 통해 손님들이 '주문하기' 기능 사용 가능
테이블링 관리
1) 예약자 목록 관리(예약자 확인, 입장, 취소, 대기 문자 전송)
야간부스 운영진에게 예약자 명단 확인과 입장 및 취소 관리 기능 제공
예약 대기 문자를 자유롭게 커스텀해서 전송할 수 있도록 커스텀 기능 제공
2) 문자 커스텀(예약 확인, 입장 완료, 예약 취소 시 자동 전송 문자 커스텀)
자동으로 전송되는 예약 확인 문자, 입장 확인 문자, 예약 취소 문자를 자유롭게 커스텀 가능
주문 관리
1) 입금 확인
운영자가 계좌로 송금된 내역을 보고 입금 확인을 처리
2) 테이블 주문 현황
테이블 별 주문 현황 및 주문자 정보를 확인
3) 주문 추가
서비스로 들어온 주문 또는 누락된 주문을 추가
4) 주문 통계
일자별 주문 통계를 전체, 서비스, 일반 주문 별로 그래프와 표로 확인
👨💻개발 중 발생한 이슈
사진 업로드 이벤트 개발 중 사진 업로드 API 응답 반환 문제
두 번째 사진을 보면 알 수 있듯이...
사진 업로드 이벤트에서 사용된 '사진 업로드 API' 호출 시, 요청에 성공하더라도 응답 결과로 성공과 실패 응답이 같이 반환되는 상황이 발생했다.
일단 프론트엔드 관점에서 바라보았을 때,
'응답이 2개라고? 그럼 요청을 잘못 보낸 거 아닌가?'라는 의문이 가장 먼저 들었다.
하.지.만. 이것 또한 첫 번째 사진을 보면 요청이 한 개임을 볼 수 있다.
그럼... 백엔드 측에서 문제가 생긴 게 아닐까...?
가장 먼저 백엔드 측에서 발견된 문제는 S3 저장소 용량의 문제였다.
개발에 사용하고 있던 S3 저장소에 저장되는 파일 크기에 대한 제한 때문에 파일은 전송됐지만 저장이 안 되는 상황이 발견되었어서 이를 가장 먼저 수정해 보았다.
하.지.만.
용량을 늘렸음에도 불구하고 동일한 오류가 계속해서 발생했다.
유저 토큰 관리 방식에 대한 이해의 늪
백엔드의 유저 관련 API는 로그인 요청 성공 시 AccessToken과 RefreshToken을 Axios 응답 헤더에 담아서 프론트엔드에게 넘겨주는 방식으로 개발이 되어있었다.
토큰 관리 방식에 대한 지식이 부족했던 나는 다음과 같은 사고방식을 통해 코드 개발을 시작했다.
1. Axios 요청 헤더에만 있으면, 해당 토큰을 쓰기 위해서는 프론트엔드에서 값을 저장하고 써야겠네!
2. 그럼 로컬 스토리지에 저장해서 쓰면 되겠다!
그렇다. 지금 생각해 보면 매우... 바보 같은 행동이었다.
로컬 스토리지에 저장해서 사용할 경우, 자바스크립트를 통한 외부 공격(XSS, CSRF)에 매-우 취약하다는 점을 간과한 채로 개발을 진행하였고... 이를 본 팀장님에게 토큰에 관한 강의를 받게 되었다.
팀장님의 따끔한 한 마디를 듣고... AccessToken과 RefreshToken 웹 쿠키에 저장해서 사용하는 방식으로 코드를 수정하였다.
유저의 로그인 토큰을 웹 쿠키에서 저장하고 사용할 수 있도록 사진처럼 쿠키를 관리하는 util 함수들을 만들어서 사용하였다.
그리고 인증이 필요한 API 요청에 해당 토큰 값들을 담아서 보내는 방식을 통해 로그인 인증이 필요한 기능 사용을 관리하는 방식으로 토큰 관리를 진행하였다.
👨💻배포 이후 발생한 이슈
테이블 번호 생성 오류
Admin 페이지에 테이블 시각화 기능을 추가하면서 테이블 번호 생성 로직을 수정하는 과정에서 문제가 발생하여 테이블 번호가 제대로 매핑되지 않는 오류가 발생했었다.
테이블을 생성할 경우, 각 학과마다 설정해 둔 테이블 번호를 볼 수 있도록 하는 것이 초기 설정이었는데 테이블 번호가 나타나지 않는 것이다...
이런 상황을 마주한 각 학과들은...
'테이블 생성이 제대로 안 됐나...?'라는 생각에 계속해서 새로운 테이블을 생성했다.
하.지.만.
이로 인해 DB에 저장되어 있던 기존 테이블 정보가 새롭게 테이블을 생성하는 순간 정보가 덮어 씌워지는 이슈가 발생했다.
이렇게 해서 새로운 테이블의 QR코드를 사용하였으면 문제가 없었지만...
이미 설정해 둔 테이블 번호로 QR을 뽑은 학과들이 상당수 있었고, 이로 인해 QR로 생성된 테이블 번호와 DB에 저장되어 있는 테이블 번호가 달라서 주문이 잘못 들어가는 이슈가 발생했다.
👨💻Festino 홍보
에브리타임 및 인스타그램 게시글 작성
개발을 아~~~~무리 열심히 해서 좋은 서비스를 만들어냈다고 하더라도, 이 서비스가 존재한다는 것을 모르면 의미 없는 개발이 되어버린다.
우리는 의미없는 개발이 되는 것을 막기 위해서 자체적으로 홍보를 진행했다😎
일단 한국공학대학교 학생들이 가장 쉽게 접할 수 있는 에브리타임을 통해 홍보를 진행하고, Festino 인스타그램 계정으로 Festino 사용법 등의 카드뉴스를 제작하여 업로드하였다.
Festino는 2024 대동제에서 서비스를 진행했었기 때문에 초면이 아닌 사람들에게도 많은 관심을 받았고, Festino를 처음 보는 사람들에게도 많은 관심을 받을 수 있었다😁
학교 내부 포스터 부착
SNS 홍보의 가장 치명적인 단점은 바로.
'SNS를 하지 않는 사람은 정보를 알 수 없다.'라고 생각한다...
그.래.서.
포스터를 제작하여 교내에 부착하는 방식으로도 홍보를 진행했다.
부착 전에 학교에 직접 문의를 하여 포스터 부착을 허락받았고, 축제가 끝난 후에는 모두 제거하였다.
포스터 내부에는 Festino로 연결되는 QR코드를 첨부하여 학생들이 간편하게 Festino에 접속할 수 있도록 편의성도 챙겨보았다😉
주간부스 운영
사실 SNS홍보와 포스터 부착을 통한 홍보 방식은 2024 대동제에서도 동일하게 사용한 방식이었다.
이 두 방식 말고도 다른 홍보 방식이 무엇이 있을까를 고민하다가 대동제 기간 동안 주간부스를 운영하여 직접적으로 대면하는 방식을 사용하여 홍보를 진행하였다.
Festino 사용 후기를 남기면 룰렛 이벤트를 통해 소정의 상품을 제공하는 방식으로 부스를 운영하였다.
이러한 방식은 학생들이 Festino를 보다 자연스럽게 체험하고, 거부감 없이 사용할 수 있도록 유도할 수 있었다.
또한, 홍보 효과뿐만 아니라, 실제 사용자들의 후기를 통해 Festino의 장단점을 파악하고, 향후 어떤 방향으로 개선해 나가야 할지에 대한 실질적인 인사이트를 얻을 수 있었다.
👨💻Festino 성과
2025 한국공학대학교 대동제에서 사용된 Festino는 2025.05.26. ~ 2025.05.28. 3일 동안 5056명의 유저와 48,630회의 조회수를 기록하였다.
2024년 Festino 성과
| 1일차 (2024.09.11.) | 2일차(2024.09.12.) | 3일차(2024.09.13.) | |
| 활성 사용자 수 | 1467명 | 676명 | 418명 |
| 누적 사용자 수 | 2475명 | 2873명 | 3091명 |
| 전체 조회 수 | 29009회 | 11620회 | 5201회 |
| 누적 전체 조회 수 | 64776회 | 75156회 | 80357회 |
| 전체 예약 건수 | 33건 | 28건 | 11건 |
| 누적 전체 예약 건수 | 33건 | 61건 | 72건 |
| 전체 주문 건수 | 445건 | 490건 | 373건 |
| 누적 전체 주문 건수 | 445건 | 935건 | 1308건 |
2025년 Festino 성과
| 1일차 (2025.05.26.) | 2일차(2025.05.27.) | 3일차(2025.05.28.) | |
| 활성 사용자 수 | 2204명 | 1567명 | 1285명 |
| 누적 사용자 수 | 2204명 | 3771명 | 5056명 |
| 전체 조회 수 | 22032회 | 15441회 | 11157회 |
| 누적 전체 조회 수 | 22032회 | 37473회 | 48630회 |
| 전체 예약 건수 | 427건 | 218건 | 201건 |
| 누적 전체 예약 건수 | 427건 | 645건 | 846건 |
| 전체 주문 건수 | 830건 | 1126건 | 1181건 |
| 누적 전체 주문 건수 | 830건 | 1956건 | 3137건 |
2024 대동제, 2025 대동제에서의 성과를 비교해 보았을 때,
누적 사용자 수는 2024 대비 약 1.6배 증가하였고,
누적 조회 수는 2024 대비 약 1.7배 감소하였으며,
누적 전체 예약 건수는 2024 대비 약 12배 증가하였고,
누적 전체 주문 건수는 2024 대비 약 2.4배 증가한 결과를 볼 수 있었다.
결 과 적 으 로
2024 대동제에 비해 더 많은 사용자와 더 많은 사용률을 뽑아내었다😎
2024 대동제에 비해 딱 하나 아쉬운 부분이 있다면...
바로 감소한 누적 조회 수이다...
다양한 이유가 있을 수 있지만, 2024 대동제에 비해 짧아진 '서비스 운영 기간'을 가장 큰 이유라고 생각한다.
2024 대동제에서는 약 7일간 베타 서비스 및 정식 서비스가 이루어졌는데, 이번 2025 대동제에서는 축제 기간 3일만 서비스가 이루어졌다고 해도 과언이 아닌 상황이었다.
짧아진 서비스 운영 기간만큼 누적 조회수가 감소하는 건 당연한 수순이라고 생각하지만, '조금만 더 열심히 개발했더라면 여유로운 베타 서비스 기간을 가질 수 있었을 텐데...'라는 아쉬움은 남았다.
하지만 성공적으로 프로젝트가 마무리되었기 때문에 그동안 Festino를 위해 노력해 왔던 나의 모습이 헛되지는 않았음을 매우 크게 느낄 수 있었다😎
👨💻Festino를 마무리하며...
아쉬웠던 부분...
Chat GPT 의존 개발
개발 초기에는 'Chat GPT를 사용하지 않고 개발을 해보자!'라는 당찬 포부로 개발을 시작했다.
초반에는 퍼블리싱, Vue.js 기반 코드 마이그레이션 작업 위주였기 때문에 확실히 Chat GPT의 도움을 많이 받지 않고 개발을 진행할 수 있었다.
하.지.만 신규 기능 개발을 진행하면서부터 Chat GPT에게 매우 의존하는 나 자신의 모습을 볼 수 있었다.
다양한 이유로 인해... 신규 기능 개발이 많이 지연된 상태였고 해당 기능을 스스로의 힘으로만 개발을 진행하기엔 시간이 너무 부족했기 때문에 모르거나 막히는 부분은 바로바로 Chat GPT를 통해 해결하였고, 이로 인해 코드 컨벤션이나 Store, Type, Util 관리도 매우 미흡할 수밖에 없었다.
이번 개발 프로젝트에 참여하면서 가장 아쉬웠던 부분이 무엇이었냐고 물어보면 이 부분이었다고 말할 것 같다...
Chat GPT를 아예 안 쓰는 게 좋은 개발이라고는 할 수 없겠지만, 개발 실력을 늘리면서 적절히 사용하는 중간점을 찾는 게 중요하다고 생각하였다.
Hook 관리의 부재
개발 중반쯔음부터 팀장님이 하신 말이 하나 있었는데...
너네는 왜 Hook을 안 만들어?
그렇다. 개발 중반까지도. 심지어 현재 프로젝트가 끝난 시점에도 Hook은 총 2개밖에 없었다.
사실 Hook을 만들지 않아도 개발하고 서비스를 진행하는 데에 문제는 없다.
하지만, 코드 가독성 향상 및 유지보수, 성능 개선을 위해서라면 중복되는 기능은 hook으로 분리하여 사용하는 것이 좋다는 것을 알기 때문에 개발 중 아쉬웠던 부분 하나를 꼽으라고 하면 이 부분을 말할 수 있을 것 같다.
댓글