[3일간 3천 명의 유저, 8만 회 조회수] 2024 한국공학대 대동제 웹사이트 개발 후기

Project 2024. 9. 28. 20:56

Festino는 한국공학대학교 대동제 정보 제공을 목적으로한 웹사이트로,

약 두 달 반의 기간동안 수많은 회의와 수많은 테스트 및 개발을 통해 성공적으로 프로젝트를 마무리했습니다! 🎉🎉🎉

📌 Festino 개요 📌

[축제기간]
2024. 09. 11. WEB. ~ 2024. 09. 13. FRI.

[프로젝트 기간]
2024. 06. ~ 2024. 09. (약 두 달 반 / 기획 ~ 최종배포까지)

[정기회의]
매주 일요일 15시

[팀원]
총괄리더 1명, FE 3명, BE 5명, DESIGN 3명 (총 12명)

[기술스택]
FE: JavaScript, Vue.js, tailwind, pinia(상태관리), Vite
BE: Spring Boot
DB: MySQL
IDE: IntelliJ IDEA Ultimate 2024, Postman, Visual Studio Code

[Github] https://github.com/DEV-TINO/Festino

📌 새로운 팀 멤버와의 프로젝트 📌

이전 프로젝트였던 Play-Tino 제작을 끝냄과 동시에, 개발 소모임 DEV-TINO에서 새로운 프로젝트를 진행하게 되었다.

새로운 프로젝트를 시작하기에 앞서, 새로운 멤버들을 영입하게 되었다.

프로젝트 배경

이전에 진행했던 프로젝트 Play-Tino 개발이 끝나갈 쯤, 개발 소모임 DEV-TINO 팀장님이 <동국대학교 2024 봄 대동제 웹사이트> 레퍼런스를 들고 오셨다. 9월에 축제도 하고 하니, 다음 프로젝트는 이런 축제 웹사이트를 만드는 것도 좋을 거 같다는 의견을 들고 오셨다.

12명이서 함께하는 Festino

개발 소모임 DEV-TINO 팀장님이 제시하신 아이디어를 듣고 참여 희망자가 생겨, 새로운 팀원이 추가되었다.

거기에 디자이너 3명까지 더 뽑아, 최종적으로 디자이너 3명과 프론트엔드 4명, 백엔드 5명으로 총 12명의 인원이 투입되었다.

디자이너까지 투입해서 진행하니, 개발자들은 기획을 하면서 필요하다고 생각되는 기능과 레이아웃 정도만 정리해서 틀을 잡고, 그 틀을 기반으로 UI/UX를 모두 디자이너가 완성해 줘서 일관성 있는 디자인으로 사용자 친화적인 서비스를 만들 수 있었다.

🎊 Festino! 5일간 3천 명의 유저와 조회수 8만회 달성 🎊

💡 개발에 앞서, 기획 단계💡

레퍼런스 조사

프로젝트 기획 전, 팀장님이 보여주신 <동국대학교 2024 봄 대동제 웹사이트> 외에도 다양한 레퍼런스를 조사 하였다.

처음 기획 단계에서는 타학교들의 대동제 웹사이트와 비슷하게 제작하는 방향으로 가, 레퍼런스를 통해서 필수로 들어가야할 정보가 무엇일지 생각해보며, 기본 틀을 잡았다.

기능 회의

초기 기능회의는 약 3주간 진행이 되었다.

기획에 많은 기간을 투자하게 되면서 브레인스토밍 중 “이런 것도 좋을 거 같은데?”하며 나온 의견들을 모았고, 실질적으로 사용자가 원하는 서비스라고 생각하는 <공지사항, 공연 정보, 부스 정보, 테이블링, 주문> 기능을 기획하게 되었다.

초기 기능 기획을 할 땐 총학생회와의 협업을 고려한 상태로 진행하게 되었는데, 총학생회와의 협업이 무산이 되면서 총학생회와 관련된 기능들은 제거되기도 했다. 그리고 중간 중간 다른 재학생들의 의견 및 학과 미팅을 진행하면서도 추가되거나 수정되는 기능들이 정말 많았기에 개발 기간 또한 늘어나게 되었다.

와이어프레임 및 API 명세 작성

기능 회의에서 나온 내용을 가지고 개발을 하기에 앞서, 웹사이트의 골격이나 애플리케이션의 UI 및 핵심 기능들을 나타내는 와이어프레임을 제작하였다.

이 작업은 디자이너와의 소통을 원활하게 만들어주기도 하지만, API 명세서를 작성할 때도 편하다.

와이어프레임을 제작한 후에는 프론트엔드와 백엔드 각각에서 작업을 분류하고 담당을 정했다.

API 명세서 작성을 할 때는 main 페이지의 기능과 admin 페이지의 기능을 팀으로 나눠서 작성하였다.

와이어프레임을 기반으로 API 명세서를 작성하니, 어디에 어떤 정보가 필수로 필요한지 직관적으로 나타나 있어서 API 명세서를 작성하는 데 더 효율적이었다.

요구사항 명세서 작성

기능 확정이 되고 와이어프레임도 어느 정도 나왔으니, 이것들을 기반으로 요구사항 명세서를 작성했다.

개발팀에서 기능 회의를 한 후에 와이어프레임까지 짠 것이니 디자인팀에서는 와이어프레임만 보고 어떤 걸 클릭했을지 모를 수 있으니, 와이어프레임에 나타나 있는 동작들을 최대한 자세하게 적어서 디자인팀에 전달했고, 디자인팀도 이 내용을 기반으로 UI/UX를 뽑아낼 수 있었다.

진행 과정

일정	내용
1 ~ 3주차	팀 빌딩, 기능 회의, 와이어프레임 제작 및 API 설계, 디자인 작업
4 ~ 6주차	기능 개발
7 ~ 9주차	추가 기능 구현 및 DB 분리, 버그 픽스
~ 9월 10일	테스트 진행 및 버그 픽스

기획 당시 생각했던 개발 기간은 8월 초까지였다.

디자인이 나오면 6월 말까지 퍼블리싱을 완료하고, 7월 중순까지는 개발을 모두 완료한 후 테스트와 버그 픽스까지 하여 8월 개강 전까지 완성을 목표로 하였는데 디자인팀의 졸업작품 일정으로 디자인팀 일정이 지연되어 그에 따라 개발팀의 일정도 지연되었다.

디자인이 나오는 대로 시안 피드백을 한 후에, 퍼블리싱 할 수 있는 부분을 7월 초까지 모두 완료해냈고, 그동안 백엔드 팀에서 작성한 Wiki의 API 명세서를 보고 API 연동에 들어갔다.

원래 개발 진행이 폭포수 방식으로 이루어졌다. 하지만, 학과가 사용하게 되는 기능들이 추가되고 각 부스 운영진 컨텍이 필요한 상황에서 애자일 방법론으로 변경할 수 밖에 없었다.

1차 프로토타입이 완성된 후에, 시안을 보여주면서 각 과 회장들과 미팅을 진행하여 사용자 입장에서의 피드백을 받아 수정 작업을 진행하였다. 이 과정에서 추가되는 테이블 커스텀, 문자 커스텀, 주문 추가 등의 기능이 추가가 되었다. UI/UX도 수정 사항이 많아지고 추가 사항이 많아지게 되면서 일정이 지연되었다.

일정이 늦어진 만큼 서로가 담당한 부분이 아니더라도 함께하는 프로젝트이기에 서로의 작업을 도왔고, 그 덕에 프로젝트를 일정 안에 잘 마무리할 수 있었다.

특히나, 프로젝트 제작 막바지에는 시나리오를 작성하여 E2E 테스트를 진행하여, 사용자의 입장에서 테스트를 해보고 발생하는 오류나 결함이 없는지 재배포를 할 때마다 테스트함으로써 결함을 빠르게 발견하고, 수정할 수 있다.

⚒️ 기능 확정 및 실제 개발 화면 ⚒️

Mobile Main Webapp (공지사항, 타임테이블, 부스, 테이블링, 주문)

1. 공지사항

Festino 개발팀의 웹사이트에 관한 올린 공지사항을 전달하는 기능을 제공한다.

2. 타임테이블

축제 기간 진행되는 교내 동아리의 공연 타임테이블을 제공한다.
공연에 참가하는 동아리의 정보 및 공연 순서, 공연자 정보를 볼 수 있다.

3. 부스

메인 부스 페이지에서는 부스 지도를 통해 전체 부스의 위치와 전체 부스 목록을 조회할 수 있다.
각 부스 상세 페이지에서는 해당 부스에 대한 부스 정보와 운영 시간, 활동 및 메뉴 정보 등을 제공한다.

각 부스 상세 페이지의 부스 정보는 운영자가 직접 등록 및 수정할 수 있도록 admin 기능을 함께 기획했다.

4. 테이블링

야간부스 입장 웨이팅을 등록할 수 있는 기능을 제공했다.
원하는 학과 사용이 가능하며, 원할 때만 사용도 가능하다.

야간부스 운영진이 예약자를 확인하고 입장 문자 및 예약자 관리를 할 수 있도록 admin 기능도 함께 기획했다.

5. 주문하기

야간부스에서 주문하기 및 조리 현황을 확인할 수 있는 기능을 제공하였다.
각 학과의 테이블 별로 제공된 주문 QR 코드에 접속하면 주문 페이지로 이동되고, 원하는 메뉴를 주문할 수 있다.
운영진에서 "입금 확인"을 한 후에, 조리 중으로 넘어가고, 조리 완료 처리까지 할 수 있어 조리 현황을 조회할 수 있다.
각 야간부스 운영진들은 언제든지 원할 때 사용할 수 있다.

이 주문 현황 관리 및 메뉴 판매 정보를 관리할 수 있는 admin 기능도 함께 기획했다.

Web Admin(부스, 테이블링, 주문 관리)

1. 부스 관리

1.1. 부스 정보 수정

운영진은 계정에 해당하는 학과의 부스 상세 내용을 변경할 수 있다.
부스 운영진은 부스 정보 및 메뉴 정보 관리가 가능하다.
추가로 야간부스는 예약 및 주문 사용 여부까지 관리 가능하다.

1.2. 테이블 관리

야간부스는 테이블을 원하는 만큼 생성하고, 테이블 번호를 마음대로 커스텀할 수 있다.
등록된 테이블에 맞는 주문 QR이 생성되며, 이를 통해 손님들이 주문을 할 수 있다.

2. 테이블링 관리

2.1. 예약자 목록 관리(예약자 확인, 입장, 취소, 대기 문자 전송)

야간부스 운영진은 예약자 명단을 확인 가능하고 입장 및 취소 관리가 가능하다.
대기 문자를 자유롭게 커스텀해서 전송할 수 있다.

2.2. 문자 커스텀(예약 확인, 입장 완료, 예약 취소 시 자동 전송 문자 커스텀)

자동으로 전송되는 예약 확인 문자, 입장 확인 문자, 예약 취소 문자를 자유롭게 커스텀할 수 있다.

3. 주문 관리

3.1. 입금 확인

운영자가 계좌로 송금된 내역을 보고 입금 확인을 처리할 수 있다.

3.2. 테이블 주문 현황

테이블 별 주문 현황 및 주문자 정보를 확인할 수 있다.

3.3. 주문 추가

서비스로 들어온 주문 또는 누락된 주문을 추가할 수 있다.

3.4. 주문 통계

일자별 주문 통계를 전체, 서비스, 일반 주문 별로 그래프와 표로 확인이 가능하다.

Mobile Admin(부스, 테이블링 관리)

Mobile admin 페이지의 경우, 주로 사용되는 부스 정보 수정과 테이블링 기능만 사용할 수 있도록 하였다.
전체적인 구성은 Web admin과 동일한데 정렬 방식만 다르게 하여 UI를 구성하였다.

사실 이 mobile admin에는 비하인드가 있다.

원래는 admin은 web으로만 제작할 예정이었다.

하지만 디자이너와의 소통 이슈로 인해, 모바일 시안도 같이 제작이 됐다.

생각하지 못한 사항이었지만, 시안을 보고 꽤 괜찮다고 생각하여 제작을 하게 된 부분이었다.

web과의 기능적 차이는 없지만, 부스 사진의 경우 web에서는 click event로 하여 drag and drop을 구현하였다.

모바일의 경우, 이걸 touch event로 drag and drop을 구현했다.

테이블링에서도 큰 차이는 없지만, UI 부분에서 기존의 web에선 입장 버튼과 취소 버튼을 따로 두었다.

모바일에서는 이를 빼고 오른쪽처럼 관리라는 버튼을 추가하였다.

그리고 관리를 클릭하면 이렇게 모달이 떠서 입장 또는 취소를 할 수 있도록 하였다.

🔥 개발 중 직면했던 모든 것 🔥

🚨 개발 중 발생했던 이슈 🚨

계속되는 기능추가로 늦어지는 일정

처음 기획은 main만 제작을 목적으로 했기에, 폭포수 방법론으로 개발을 진행할 수 있었다.

하지만, admin이 추가되면서 학과의 컨텍이 필수적이게 되었고, 이를 위해서는 애자일 방법론으로 개발을 진행할 수 밖에 없었다.

MVP를 7월 28일까지 완성했고, 완성한 내용을 가지고 학과 미팅을 진행했다.

미팅을 통해, 테이블 커스텀, 문자 커스텀, 주문 추가 등의 새로운 기능이 추가 되었다.

그 이후에도 학과에서 테스트를 거치면서 요구사항들이 계속 들어오게 되었고, 무한 수정이 이루어지게 되었다.

기간은 촉박한데, 기능이 끊임없이 추가되면서 프로젝트 완성이 늦어지게 되자 우리는 다음과 같은 방법을 썼다.

없던 디자인을 급하게 프론트엔드에서 임의로 제작 및 디자인 요청 👉🏻 API 완성 👉🏻 API 연동 👉🏻 디자인 완성 👉🏻 UI 수정

이 방법을 통해, 효율적으로 개발을 하였다.

익숙하지 않은 협업

처음에는 작업을 분업해서 했기에, 서로 간의 작업 파일을 건드릴 일이 적고, 공동 작업 파일도 한 명이 수정이나 추가를 했다면 먼저 push를 하고 merge가 된 것을 확인한 후에 pull을 받아서 작업하는 형식으로 잘 진행됐다.

하지만, 개발이 지연되면서 누가 담당인지에 관계없이 도와야 하는 상황이 왔다.

이 과정에서 하나의 파일을 동시에 작업하게 되어 충돌이 일어난다던가, 누군가 브랜치를 새로 생성하지 않은 상태에서 pull을 안 받은 후에 올려서 심각한 경우엔 코드가 날라가는 등의 이슈도 발생하였다.

사실 소통의 문제도 크다. 그리하여, 파일 수정 여부를 먼저 파악한 후에 작업을 한다던가, 동시에 작업한 파일의 경우 push를 하기 전에 공동 작업자와 소통을 하고 push를 하는 등의 작업으로 방지할 수 있었다.

이것의 연장선으로 Docker 사용에 익숙하지 않은 것도 문제가 되었다.

admin을 개발할 때는 Docker를 사용했는데, errorr가 발생해서 보니, 백엔드 코드를 pull 받지 않았다던가, 시크릿키를 입력하지 않은 등의 이슈가 있었는데, 점차 익숙해지면서 이슈 발생률이 줄었다.

보안

admin 페이지가 생기면서, 각 부스 별로 user가 추가되게 되었다.

자신의 학과만 접근할 수 있도록 설정하기 위해서 로그인 시, JWT 토큰을 사용하여 사용자 인증 절차를 거쳤다.

이런 서비스들을 제작하고 배포하고 나면 CSRF/XSS/Dos/DDos 공격들이 빈번하게 일어난다.

CSRF를 막기 위해서 JWT 토큰을 CSRF 처럼 사용했고, Dos/DDos 공격을 막기 위해서 rate limit를 걸어 보안을 강화했다.

익숙하지 않은 예외 처리

단순히 기능 구현만을 신경 쓰다보니, 예외 처리를 하지 못한 부분들이 생겼다.

예를 들어, API 호출이 제대로 이루어지지 않아서 데이터를 불러오지 못했을 때 아무 데이터도 띄워주지 않는다는 점이나, 404 같은 에러가 떴을 때 뜨는 에러 페이지가 없는 점들이었다.

그래서 네트워크 속도나, 데이터 없음으로 인해 데이터가 렌더링 되지 않은 상태가 보여지면 사용자 입장에서는 오류 발생으로 인식이 될 수 있다. 그리하여 정보가 없을 경우나, 아직 정보가 불러와지지 않았을 때 보여지는 이미지를 추가하여 사용자 경험을 개선하였다.

😢 여러 시도를 하게 만들었던 구현 중 어려웠던 점 😢

부스 지도

막상 해보니, 해보자마자 이유를 알게 되었다.

“가장 어렵고 힘들었던 작업이 무엇이었나?”를 질문으로 받는다면, 지도라고 한 번에 외칠 수 있다.

처음 하기 전에는 왜 그렇게 어렵다고 할까라는 생각이 있었기도 하고, 내가 하게 될 거라고 생각을 딱히 안 해서 별 걱정이 없었던 거 같기도 하다. 내가 생각하지 못했던 변수들이 너무 많았고, 반응형도 신경 써야 하고, 그냥 이미지 확대/축소와 더불어 핀지줌까지 구현하다 보니 마커들은 이리저리 이동하는 현상들이 발생했다.

지도에 마커를 직접 찍고 active 되었을 때 애니메이션과 해당 마커가 지도의 중앙에 오도록 스크롤 조정하는 것, 부스 데이터를 가져와 부스 정보 말풍선을 연결하는 것, 각 탭 별로 최상단 부스가 처음 활성화되게 하는 기능까지 여러 신경 쓸 점들이 넘쳤던 작업이었다.

조금 이제 된 거 같다고 생각하면 다른 문제점이 발생해서 어떻게 지도를 구현해야 할지 감을 잡을 때 4일이라는 시간이 소요가 되었다. 여러 시행착오를 통해서 지도 같이 보이도록 구현을 해낸 후에 정말 행복했다.

지도 수정사항과 추가사항이 발생할 때마다 절망에 빠질 뻔 했지만, 감을 잡고 완성하니 다른 것을 수정하거나 변경해야 할 때 큰 문제점은 발생하지 않았다.

기획 단계에서 각 직군 별 기능 이해의 차이

그게 가장 컸다고 생각한 것은 주문이었다. 아무래도 주문이 API도 많고, 기능도 많고, 생각할 것도 많다 보니 발생한 문제라고 생각을 한다.

FE에서 통계를 작업할 때, 메뉴 이름이 변경되면 변경되기 전 데이터도 보여야 하고, 주문 완료를 기준으로 통계가 들어와야 한다고 생각을 했는데 BE에서는 입금대기에 따라 처리되어야 한다고 생각했던 점도 있고, 메뉴명이 바뀌기 전 데이터는 제외하고 통계를 보여주는 등 기능에 대한 생각의 차이로 발생한 문제가 있던 거 같다.

이런 문제들이 발생할 때마다, 깃허브 이슈를 사용하여 의견을 나누고 더 좋은 방향으로 변경을 하게 되어 잘 해결할 수는 있었지만, 처음에 문제가 아니었다고 생각했던 부분이 중간에 문제로 발생할 경우, 어떤 것이 옳은 것인지 판단하기 어려움도 있었다.

회의를 여러 번 진행하고, 여러 수정사항이 생기면서 기능별로 BE와 FE의 이해 차이가 발생하는 경우가 있었다.

🔥 배포 후,, 🔥

📣 개발자가 직접 발로 뛰는 홍보 📣

SNS(에브리타임, 인스타그램)

개발을 아무리 열심히 해서 퀄리티 높은 서비스를 제작한다고 한들, 마케팅이 잘 되지 않으면 의미없는 일이다.

개발 만큼이나 중요한 마케팅 ! 프로젝트에 많은 투자를 한 만큼 높은 유저수도 기대가 되었다.

에브리타임과 인스타그램을 통해서 홍보 게시글을 업로드하고 저희 학과에 홍보하는 등 !

많은 관심을 받았지만, 이외에도 더 많은 관심과 유입 경로가 필요했다.

포스터

SNS 홍보 다음으로는 포스터를 제작하여 교내에 부착을 했다.

부착 전에 학교에 직접 문의를 하여 포스터 부착을 허락 받았고, 우리 학교 마스코트인 티노에 대한 사용 여부도 확답을 받았다.

교내 부착 위치를 선정해서 개발팀이 직접 다 붙이고 다니고, 축제가 끝난 후에 완벽하게 모두 제거했다.

QR도 넣어서 바로 확인할 수 있도로 유입 경로를 추가했다.

🫢 개발 중 발견하지 못했던 문제점을 발견하다 ! 🫢

중복 주문

입금 완료 버튼을 API 요청 완료 전에 어려 번 눌러, 주문 등록된 결과를 보면 2-3개씩 들어오는 경우가 발생한 것이다.
중복 주문이 들어오는 문제는 입금 완료를 누른 후 요청이 완료되기 전까지 클릭을 막는 것으로 해결했다.

입금 대기에서 입금 취소로 넘겼다면 상관이 없었지만, 입금 대기에서 입금 확인으로 모두 처리해 버린 경우에도 조리 중으로 이미 넘어가서 어떻게 처리해야 할지 고민한 순간이 있다.

일단은 조리하는 사람 입장에서 혼돈이 발생할 수 있어서 조리 완료된 것으로 넘겨 처리하기는 했지만, 이럴 경우 통계에 문제가 생긴다는 것이 문제였던 거 같다.

하지만, 조리 중으로 넘어간 건 취소할 일이 없다고 생각하여 제거했던 부분이었는데, 이 경우를 경험하고 나니, 입금 대기 후에도 주문을 취소할 방법이 필요하다고 생각했다.

주문 완료의 최신순 정렬

FE 자체에서 주문 완료의 “최신순”이 주문이 들어온 시간순으로 이해하여 만들었는데, 직접 사용하다 보니 사용자 입장에서는 주문완료의 “최신순”이 주문 완료 기준이라고 생각될 거라고 느꼈다.

그리하여, 문제점을 발견한 후 바로 주문 완료 기준 최신순으로 수정하여 2일 차부터는 제대로 사용할 수 있게 되었다.

타임테이블 날짜 active

축제 기간에 해당하는 날짜는 접속하게 되면 자동으로 해당 날짜가 active 되어야 하는데, 그러지 않았다.

단순 if문 조건 문제였던 것을 확인하고 수정하여 정상 작동 되도록 하였다.

브라우저 번역

크롬 브라우저 사용시, 주문 조회에서 번역을 누르게 되면, 일부 단어가 이상하게 번역되는 경우가 발생했다.

보통 삼성 유저의 브라우저에서 일어났는데, 개발팀에 애플 유저가 대부분이었어서 체크하지 못했던 사항이었다.

번역에 대해서는 전혀 생각하지 못했던 부분이라, 더 세세한 테스트가 필요하다는 것을 느꼈다.

메모리로 인한 오류

많은 양의 데이터가 입력되고 나니, 많은 양의 정보를 띄우는 부스 탭에 접속하게 되면 새로고침이 되거나 지도의 마커가 제대로 뜨지 않는 등의 문제가 발생했다.

내용이 많아질 수록 메모리를 많이 사용하게 됐고, 그로 인해 발생한 문제였다.

그리하여, 브라우저에서 캐싱을 안 하도록 수정하고, 이미지를 webp로 변경하는 등의 방법으로 수정하니 제대로 동작하였다.

😧 개인적으로 이런 게 아쉬웠던 거 같다 😧

제대로 이루어지지 않은 분업화

정확히 어떤 부분을 맡아서 할 것인지를 확실하게 정하는 것이 중요하고, 담당 파트를 정하기 전에, 각 기능 별로 연관성이 있는 건 무엇인지 분류를 한 후에 이것을 모두 정하는 게 낫다고 생각이 들었다. 그렇지 않다 보니, 나눠서 해도 될 거 같다고 생각했던 부분이 그렇지 않아, 한 명이 더 몰아서 많은 양을 작업을 하게 되기도 하는 일이 발생한 거 같다.

기능이 많은 만큼 분업화가 중요하다고 생각했다. 개인적인 시각으로 봤을 때는 분업화가 처음에는 잘 이루어졌지만, 갈수록 그러지 못했던 거 같아서 아쉬웠다.

난잡한 컨벤션

여러 사람과 협업을 할 때 지켜야 하는 것 중 하나가 컨벤션이다.

처음 개발을 시작하고 코드가 올라오기 전까지는 서로의 코드 스타일을 알 수 없었다.

가장 난잡했던 컨벤션은 함수명이었다.

이번 협업을 하면서 우리가 사용했던 컨벤션은 다음과 같다.

[변수 또는 함수 네이밍]

변수나 함수의 이름은 camelCase로 작성을 한다.

ex) userName, userPwd

상수는 UPPER_CASE로 작성한다.

ex) CATEGORY_NAME

함수명은 이름만 보고도 어떤 기능을 하는지 알 수 있도록 작성한다.

get...: 값 반환 함수
create...: 어떤 것을 생성하는 함수
handle...: 어떠한 이벤트를 처리하기 위한 함수

[브랜치명]

브랜치는 "라벨/기능" 형식으로 이름을 붙인다.

라벨은 다음과 같다.

feat: 기능 개발
style: 코드 스타일 수정(기능 영향을 주지 않는 코드 수정)
design: UI 작업
fix: 버그 픽스

[커밋 메세지]

메세지 태그	내용	비고
feat	새로운 기능 추가
fix	버그 수정
refactor	리팩토링	코드 구조 수정
style	코드 형식, 세미콜론	디자인 가이드
docs	문서 추가, 수정, 삭제
test	테스트 코드 추가, 수정, 삭제
chore	기타 변경사항, 세팅 관련
design	CSS 등 사용자 UI 디자인 변경

당일에 발로 뛰어 정보 수집

총학생회와 협업을 했다면 정보 수집을 좀 더 수월하게 할 수 있었을 거지만, 협업이 이루어지지 않아 직접 주간부스 운영진과 컨텍을 시도했다.

에브리타임에 올라온 일반 학우가 진행하는 부스 홍보글을 보고 직접 연락을 취한다던가, 동아리 인스타그램으로 직접 DM을 보내고, 지인을 통해 운영진과 연락을 하는 등의 방법을 통해 주간부스 정보를 수집했다.

푸드트럭은 팀원이 당일에 직접 사진을 찍고 정보를 직접 다 등록했다.

푸드트럭 정보도 총학과 협업이 됐다면, 사전에 정보를 얻을 수 있었지 않을까 생각한다.

좋지 않은 코드

이 프로젝트를 진행하던 중, 2-3개의 프로젝트를 다른 사람들과 진행했었다.

여러 프로젝트를 진행하던 중, 여러 사람의 코드를 읽을 기회가 생겼는데, 이렇게 코드를 작성해야 좋은 코드구나를 깨달았다.

처음 개발을 할 때부터 좀 더 가독성과 유지보수를 신경 쓰면서 개발했다면 더 좋았을 거 같다고 생각했다.

이 생각을 한 뒤로부터는 조금 씩 주석을 사용하기도 하고, 컨벤션 등을 신경 써서 작성하려고 노력했다.

리팩토링을 진행한다면, 나만 보기 좋은 코드가 아닌 타인의 눈에서도 보기 좋은 코드를 작성하려고 노력하고 싶다.

💡 다음은 이렇게 해볼까? 💡

총학생회와의 협업

이번에는 시간이 촉박한 것도 있었다. 그리고 총학생회도 서비스를 처음 도입하게 될 경우 우려되는 사항도 많기 때문에 협업을 진행하지 않았지만, 이번 프로젝트가 성공적으로 이루어졌기에 다음에는 협업을 진행하여 더 퀄리티 높은 서비스를 제공할 수 있지 않을까 하는 기대가 있다.

총학생회와 협업을 통해, 원래의 기획대로 연예인 정보도 추가되고, 관련 이벤트들도 추가가 된다면 더 많은 사용자와 조회 수를 기록할 수 있을 거라고 생각한다.

자체 이벤트 진행

홍보 방식 중 하나라고 생각을 하는데, Festino 자체에서 이벤트를 소소하게 진행했어도 홍보에 도움이 됐을 거 같다.

다음에는 리뷰를 달아준 사람이나, 피드백 참여자를 위한 경품 추첨도 소소하게 들어가는 것도 좋을 거 같다.

🎉 성공적으로 끝난 프로젝트 🎉

Festino는 2024. 09. 11. ~ 09. 13. 3일 동안 3천 명의 유저, 8만 회 조회수를 기록하였다.

인스타그램 계정도 8월 말 ~ 9월까지 조회수 7200회, 도달한 계정 1500개의 기록을 세웠다.

	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건

지금까지 했던 프로젝트 중에서 가장 큰 성과를 보인 프로젝트라고 생각한다.

많은 사용자가 있었음에도 큰 이슈 발생없이 프로젝트를 끝낼 수 있었다는 점과 내가 직접 개발한 서비스를 사용자가 만족하는 것을 보니, 그동안의 노력이 헛되지 않았다는 걸 느끼게 해줬다.

⭐️ 소감 ⭐️

여러 개를 같이할 때, 데드라인을 지켜서 하는 것은 생각보다 시간 분배를 잘해서 진행을 해야 한다는 것!

내가 생각한 개발 시간과 실질적인 개발 소요 기간이 엄청 달랐다는 점!

내가 너무 나를 과대평가했던 점도 있었고 과소평가했던 점도 있었다고 생각한다.

공부를 하고 단순히 코드를 적용하는 것보다 이런 경험을 통해서 얻는 것들이 중요하다는 것도 알았고, 내가 앞으로 어떤 걸 더 공부하고 싶은지와 어떤 걸 알아두는 게 더 좋았겠다 하는 점들이 많았다.

특히 BE를 너무 공부해서 코드를 읽고 싶다는 생각이 요즘 많이 들어서 어떤 것부터 시작을 해야 할까 많이 고민을 하고 있고, 앞으로 내가 하고 싶은 게 무엇일지도 계속 생각 중이다.

ABOUT ME