축제 사이트 개발
19년도 입학 후 20년부터 코로나 때문에 학교 축제를 한 적이 없었다. 우리 학교 멋쟁이 사자처럼 뿐만이 아니라 다른 학교들도 각자 학교 축제 때 축제 사이트를 많이 만드는 것으로 아는데 나는 멋쟁이 사자처럼에 21년(9기)에 가입해서 활동을 시작했으므로 축제 사이트를 만들어볼 기회가 없었다.
시간이 지나며 올해 가을부터 축제를 다시 진행한다는 사실을 알았고 오랜만에 하는 축제인만큼 다시 축제 사이트를 만들자는 이야기가 나왔다. 멋쟁이 사자처럼에서 주로 사용하는 기술 스택은 Python Django지만 한국에서 가장 많이 쓰인다는 Java Spring을 사용해보고 싶은 마음이 있었기에 축제 사이트에서는 스프링으로 개발을 진행하기로 했다.
계획 및 기획
1️⃣ 개발 기간
- 2022.09.17(토) ~ 2022.09.27(화) : 11일
2️⃣ 운영 기간
- 2022.09.28 ~ 2022.09.30 : 3일
3️⃣ 팀 구성
총 12명 (여러 팀에 들어간 인원 존재)
- 기획/디자인: 4명
- FE: 5명
- BE 4명
4️⃣ 사용한 기술 스택(툴)
- 기획/디자인: Figma
- FE: React
- BE: Java Spring Boot
만들고 싶었던 사이트
학생들이 궁금증에 한번 들어왔다만 가는 사이트가 아닌 실제로 사용할 만한 가치가 있는 사이트를 만들고 싶었기에 "축제를 즐기고 싶은 학생에게 유용하려면 어떤 기능을 담아야 하는지"가 중요했다.
학교 축제를 즐기려는 사람들은 크게 "어떤 공연(연예인, 동아리 등등...)을 보는가?"와 "어떤 주점에서 놀까?" 이렇게 2가지가 관심사일 것이라 예상했다.
공연 같은 경우는 일정이 이미 정해져 있기에 사이트에서 쉽게 확인할 수 있는 정도만 하면 사람들에게 충분히 도움이 될 것이라 생각했다.
주점의 경우 무슨 요일에 학교의 어디에서 어떤 학과가 어느 콘셉트로 언제부터 언제까지 주점을 운영하는지가 가장 궁금해할 내용이라고 생각했다. 거기에 각 주점에서 파는 개성 있는 메뉴 정보와 사람들의 평가(좋아요, 방명록)를 확인할 수 있다면 학생들이 원하는 주점을 찾는데에 더 도움이 되지 않을까 예상했다. 또 회원가입/로그인 같은 기능은 학생들이 필요한 기능만 가볍게 쓰기에는 굳이 필요 없는(사실 많은 회원가입률을 보이지 않을 것 같은) 오히려 사이트 이용률을 떨어뜨릴 것이라 생각하여 도입하지 않았다.
기능 구성
API
| Entity | 구현된 API | (Method) URL |
|---|---|---|
| Notification | 공지 리스트(필터 가능) 공지 생성(관리자용) 공지 디테일 공지 수정(관리자용) 공지 삭제(관리자용) | (GET) /api/notifications?filter={enum} (POST) /api/notifications (GET) /api/notifications/{id} (PUT) /api/notifications/{id} (DELETE) /api/notifications/{id} |
| Booth | 부스 좋아요 top5 부스 검색 리스트 부스 생성(관리자용) 부스 디테일 부스 수정(관리자용) 부스 삭제(관리자용) 부스 날짜 위치 필터 | (GET) /api/booths/top5 (GET) /api/booths?filter={menu, title, location} (POST) /api/booths (GET) /api/booths/{id} (PUT) /api/booths/{id} (DELETE) /api/booths/{id} (GET) /api/booths?day={day}&location={location} |
| Comment | 부스 방명록 리스트 부스 방명록 생성 부스 방명록 삭제(유저용) 부스 방명록 삭제(관리자용) | (GET) /api/booths/{id}/comments (POST) /api/booths/{id}/comments (DELETE) /api/comments/{comment_id} (DELETE) /api/comments/{comment_id} |
| Menu | 부스 메뉴 리스트 부스 메뉴 생성(관리자용) 부스 메뉴 수정(관리자용) 부스 메뉴 삭제(관리자용) | (GET) /api/booths/{id}/menus (POST) /api/booths/{id}/menus (PUT) /api/menus/{id} (DELETE) /api/menus/{id} |
| Like | 부스 좋아요 부스 좋아요 삭제 | (POST) /api/booths/{booth_id}/likes (DELETE) /api/booths/{booth_id}/likes |
(관리자용)이라고 적힌 API들은 회원가입/로그인 기능을 따로 구현하지 않았기 때문에 특정 쿼리 파라미터를 붙였을 때만 정상적인 작동을 하게 구현한 것이다. 사실 급박하게 만들다보니 어쩔 수 없이 사용했던 꼼수이지만 그렇게 마음에 들지는 않았다.
좋아요 기능같은 경우에는 회원가입/로그인이 없으니 어떻게 구현할지 고민하다가 내가 쿠키를 통해 구현하자고 했다. 사용자가 좋아요를 눌렀을 경우 랜덤 string을 만들어 사용자에게 booth_id를 이름으로, 랜덤 string을 값으로 한 쿠키를 발급하고 해당 쿠키 여부로 좋아요 여부를 구분하게 했다. 좋아요를 취소할 때는 쿠키의 값을 찾아서 지우는 방식을 사용했다. 처음에는 ip를 받아서 저장할까 생각했는데 아무래도 학교 사이트라 학교 와이파이를 많이 이용할 것 같아서 그냥 랜덤 string 값을 발급하는 방식을 사용했다. 둘 다 사용하는 것은 굳이? 라는 생각이 들어서 진행하지 않았다.
부스 좋아요 top5 같은 경우는 사이트에 접속한 날 운영하는 부스 중 가장 좋아요가 많은 5개의 부스를 보여주는 기능이었다.
좋아요 기능과 top5 기능은 BE 작업 중에는 문제가 없었지만 실제 배포 후에 FE와 작동할 때는 문제가 생겼었는데 코드가 잘못된 것은 아니고 배포 설정에서 생각치 못한 부분이 있는 것이었다. 해당 내용들은 다음에 시행착오 글을 올릴 때 포함할 것이다.
특이사항이 있는 API에 대한 설명은 위에 한 것이고 전체적인 API 설계는 내가 주도하여 팀원들과 필요한 API가 뭐가 있을지 얘기하며 정한 것인데 지금 돌이켜보면 잘못 구현되거나 굳이 필요없는 기능들이 섞여있다고 생각한다.
예를 들자면
1. 부스 필터 기능을 굳이 저렇게 나눠놓을 필요가 없었을 것 같다
2. 부스 검색을 FE에서 input이 바뀔 때마다 API를 매번 쏘는 방식으로 구현하였는데 그럴거면 사실 FE에서 필터링을 하는 것이 나았다
추가적으로 이야기할 것이 더 많지만 해당 내용들은 시행착오와 함께 앞으로 글을 쓰려고 한다.
(https 미적용, 좋아요 기능에서 쿠키 이슈 등...)
결과물
|
|
|
실제 사이트 운영은 축제 기간인 2022.09.28-2022.09.30에만 진행됐다.
학교 홈페이지에서도 홍보해주었다. https://www.dongguk.edu/article/GENERALNOTICES/detail/26748090
별건 아니지만 학교 방송국에서 인터뷰도 짧게 했다.
현재는 BE 제외하고 FE만 배포된 사이트를 확인할 수 있다.
마무리
축제 사이트는 BE와 FE를 동시에 배포해서 처음부터 작업해본 내 첫 프로젝트이다. 그러다보니 모르는 것이 참 많았고 배울 점도 굉장히 많은 프로젝트였다.
사실 진행한지 시간이 꽤 지난 프로젝트이고 그동안 회고를 써야지 마음만 먹고 있다가 여러 일도 있고 바빠서 쓰지 못하고 있었다. 그러나 활동하게 될 줄 몰랐던 멋쟁이 사자처럼 11기 멘토를 또 하게 돼서 이번에 축제 사이트를 제작할 때는 더 완성도 높은 사이트를 제작하기 위해서 정리를 하고자 늦게나마 작성하게 되었다.
프로젝트 시점이 꽤 지난 상태이기에 회고로 적기에 어려운 것도 있는데 다음에는 어디에 정리해뒀다가 회고를 해야겠다고 생각하게되는 경험이었다.
