팀프로젝트 ‘붕어빵을 부탁해’ 회고

2023.10 ~ 2023.12

프로젝트를 시작하며

사이드 프로젝트 주제를 고민하다가, 곧 크리스마스인데 내 트리를 꾸며줘 같은 롤링페이퍼 서비스를 만들면 어떨까? 하는 의견이 있었다. 큰 규모도 아니고, 귀엽게 만들어서 지인들과 사용하면 좋겠다는 생각이 들어 프론트엔드 2명과 백엔드 1명이 모여 진행하게 되었다. 셋이서 기획, 디자인, 개발을 진행했고, 12월 전까지 서비스 오픈을 목표로 하였기 때문에 꽤나 촉박하게 진행되었다.

 

기획

피그잼을 사용하여 필요한 화면과 각 화면의 기능을 논의했고, 최종적인 내용은 간단하게 표현해두었다. 다행히 기획 단계에서 논의한 로직에서 거의 바뀌지 않고 구현했다.

이후에 노션에 아래처럼 각 페이지별 기능에 대한 명세를 해두었다. 이렇게 정리해두니 어느 부분에서 API가 필요한지 같은 협업할 때 유용했다.

서비스 컨셉

기획 당시에는 컨셉을 정하지 못해서 트리를 그려두었지만, 고민 끝에 붕어빵 가게를 컨셉으로 확정했다.

내가 붕어빵 포장마차를 꾸며두면, 링크를 접속한 친구가 나 대신 붕어빵을 구워주면서 거기다 편지를 남겨주는 상황이다. 꽤나 귀여운 컨셉이 된 것 같은,,후후,,

당신은 붕어빵 포장마차의 사장님입니다. 지금 바로 영업을 시작하고, 붕어빵처럼 따뜻한 편지를 나누어보세요!

🎨 포장마차 꾸미기: 다양한 장식으로 포장마차를 꾸며, 자신만의 붕어빵 포장마차로 영업을 시작하세요.

🍞 친구에게 붕어빵 부탁하기: 당신은 갑자기 급한 볼일이 생겼습니다! 친구들에게 링크를 공유하여 포장마차를 잠시 맡아달라고 부탁해보세요. 당신의 친구들은 당신을 위해 특별한 붕어빵을 만들고, 사랑과 따뜻한 마음을 담은 메시지를 남겨 줄거에요. 붕어빵은 ‘12월 24일’까지 만들 수 있어요.

🎁 따뜻한 메세지 확인하기: 친구들이 붕어빵을 만들면, ‘12월 25일’부터 모든 메시지를 확인할 수 있습니다. 두근거리는 마음을 참고 기다리면 더 큰 행복을 얻을 수 있을 거에요.

 

디자인

백엔드 팀원이 디자인은 프론트엔드팀에 전권을 위임해줘서, 프론트엔드 팀원 둘이서 작업을 했다. 귀엽게 손으로 그린 그림처럼 이미지들을 넣으면 좋을 것 같아서 직접 그려보기로 했다. 나보다 프론트엔드 팀원이 훨~씬 잘 그리는 관계로,, 그림은 대부분 팀원이 담당하고 나는 그 외에 프레임들을 디자인 했다.

이 사이트는 보통 카톡이나 SNS로 공유된 링크를 통해 모바일로 들어올 것이라고 생각되었다. 우선 모바일을 기준으로 디자인을 했고, 이후에 테블릿과 데스크탑용을 디자인 했다. 세로가 긴 포장마차 배경화면을 유지하기 위해서, 우리가 정의한 최대 크기 이후로는 옆에 여백이 늘어나도록 진행했다.

 

개발

다른 프론트엔드 팀원은 첫 프로젝트였고, 나는 1년 반 전쯤 웹프로젝트를 해본 뒤 너무 오랜만이라,, 이 프로젝트를 포트폴리오에 첫 프로젝트로 둘 생각하고 시작한 초보들이었다. 부족한 상태라는 건 알지만, 목표한 기한이 있기 때문에 React 이론은 코드를 작성할 정도만 익힌 후 개발을 시작하기로 했다.

기술 스택

Javascript 기반 React

Typescript는 JS 보다 이론 학습에 시간이 더 들어갈 것이고, JS를 먼저 프로젝트에 사용해본 후 이후에 TS를 쓰면 좀 더 쉽지 않을까? 싶어서 Javascript 기반 React를 사용했다.

Tailwind CSS

Tailwind CSS는 지인분께 추천받아 사용했는데, Tailwind 공식페이지를 자주 들락거리며 속성을 찾아봐야 해서 번거롭기는 했지만, vscode의 Tailwind CSS IntelliSense 확장 프로그램을 사용하고, Tailwind에 익숙해지니 점점 찾아보는 횟수가 줄어들게 되었다.

Recoil

Recoil을 최근에 많이 사용하는 것 같아 선택했다. Recoil로 전역에서 필요한 상태 관리는 물론이고, 모달의 열림/닫힘을 제어했다. 규모가 크지 않기도 하고, Selector의 필요성이나 사용법은 잘 모르겠어서 Atom으로만 사용했다. Recoil을 굉장히 편하게 잘 사용했어서, 다음엔 Selector도 사용해보고 싶다.

Vite

Vite를 최근에 많이 사용하는 것 같아 선택했다. Vite는 환경변수 가져오는 방법이 다른 걸 모르고 한참 삽질했었다. (참고로 아래처럼 사용한다.) 그 외에는 쉽고 편하게 사용했던 것 같다. 한번 ‘바이트’라고 말했더니, ‘비트’라고 말하는 걸 알게된 후에도 버릇 바꾸기가 쉽지 않다.. 다들 나처럼 ‘비트’라는 걸 잊어버리지 말길

import.meta.env.환경변수명

 

맡은 역할

메인 페이지와 링크 접속 페이지를 구현했다.

 

협업

Git 전략

main → develop → 작업할 브랜치

작업해야할 내용을 이슈에 등록한 뒤, 작업할 브랜치를 만들어 각자 작업하고, 한 기능이 완성되면 PR을 올려 develop 브랜치로 merge한다. main에 push 되면 배포가 진행되도록 github action을 세팅해두어, 배포가 필요할 때 main으로 머지했다.

회의

정기적으로 일주일에 두번씩 회의를 진행했다. 회의에서는 각자 목표한 분량을 달성했는지(개발 진행 상황 체크), 공유하거나 함께 고민할 이슈가 있는지, 다음 회의 때까지 개발할 목표 분량을 정했다. 회의 외에도 이슈나 문의할 내용이 있다면 대면이나 슬랙으로 바로바로 소통했다.

Postman

백엔드 팀원이 API 명세를 굉장히 깔끔하게 케이스별로 Postman에 정리해주어, 편리하게 API 연동을 할 수 있었다.

 

발생한 이슈

에러가 나면 해결하기 바빠서 정리를 많이 해두지 않았다🥲 기록을 잘 해뒀어야 했는데 반성한다..

Github Actions 에서 환경변수 관리

.env 파일에 저장해둔 환경변수들을 배포할 때는 어떻게 가져올 수 있는지 의문이 생겨 알아보다가, Github Actions에 환경변수를 관리하는 방법을 공부하였고, 배포 시에도 문제 없이 환경변수를 적용시킬 수 있었다.

정리한 블로그

Recoil 새로고침 시에도 데이터 유지

Recoil을 활용하여 Access Token과 로그인 상태를 관리하고 있었는데, 새로고침 시에는 Recoil로 저장해둔 데이터도 초기화 되더라.. 그래서 새로고침을 하면 로그인을 다시 해야하는 상황이 되어버려서, Recoil-Persist를 사용해서 로그인 정보를 storage에 저장해 문제를 해결했다. Refresh Token을 도입했다면 좀 더 안전하게 token을 관리할 수 있었을텐데 하는 아쉬움이 있었다.

정리한 블로그

배포

개발이 거의 완료된 내용을 배포했더니, 갤럭시는 대부분 화면이 구현한 대로 나왔는데 아이폰과 아이패드에서는 CSS가 달라져 있는 부분이 있었다. 이래서 사람들이 배포한 뒤 다시 시작이라고 했구나 알게 되었다. 개발할 때와 배포되었을 때가 다르다보니, 어떤 문제로 저런 상황인거고 뭘 고쳐야하는지 파악하기가 쉽지 않았다. 거의 찍어서 맞춘 것 같다.. 첫 배포는 목표 일정보다 여유롭게 해봐야 한다는 걸 알게 되었다.

이미지 최적화

직접 그림을 그린 파일을 프로젝트에 넣어 사용하다보니, 총 이미지 폴더 용량이 25,780,159 바이트로 이미지 크기가 굉장히 컸다. 사이트에서 최대 크기로 쓰는 이미지보다 몇 배는 큰 크기였는데, 이 이미지 용량으로 인해 화면이 로딩되며 이미지가 하나 둘 뜨는게 너무 잘 보였다. 구글링 해보니 최대로 사용할 크기에서 조금의 여유분을 둔 정도의 이미지 크기면 된다고 했다. 모든 이미지 파일의 크기를 줄였고, 용량이 4,060,824 바이트로 감소되었다! 로딩되는 속도는 정확하게 비교해보지 못했지만 체감되는 속도도 훨씬 빠르고, gpt한테 물어보니 약 80% 정도 단축시킨 것이라고 했다.

 

느낀점

Tailwind CSS

h-[980px] 처럼 커스텀한 값을 사용하다보니 코드가 더 지저분해진 것 같다. tailwind의 속성값의 단위와 우리가 디자인한 값이 달라서 발생한 일이다. tailwind의 속성값의 단위는 디자이너가 디자인할 때의 표준화된 단위라고 들었는데, 다음에 디자인해볼 일이 있다면 표준화된 단위로 디자인을 해야겠다.

태그의 class에 속성들이 많이 나열될 수록 복작복작 해지는게 확인하기도 어렵고 지저분해 보이기도 했다. 이 점은 Tailwind CSS 속성 정렬을 위한 Prettier plugin이 있다는 걸 나중에 알게 되었는데, 이 플러그인을 사용하면 태그에 어떤 속성들이 적용되어 있는지 확인하기 수월하고, 협업할 때도 좋을 것 같다. 다음 번엔 이 조합으로 사용해볼 예정!

초보 개발자들

초보 프론트엔드 두명이서 개발을 진행하다보니, 이게 맞나? 싶은 점이 많았다. 막히는 부분은 열심히 구글링하고 팀원과 함께 고민하여 해결했지만, 나중에 보니 이건 왜 이렇게 했지(민망) 싶은 부분이 많다. 느려서 거슬렸던 로딩 부분은 나중에 폰트 최적화와 이미지 최적화를 적용해서 조금 개선했지만, 리팩토링 욕심도 생긴다! 2024년에도 서비스를 오픈하게 된다면, 그 땐 좀 더 완전한 서비스로 오픈하고 싶다.

80명의 사용자

2023년 크리스마스 시즌 동안 80명의 사용자와 350건의 편지가 생성되었다! 내가 만든 사이트가 80명의 사용자를 받았다니,, 누군가는 적은 사용자수라고 생각할 수도 있지만, 내가 만든 서비스를 통해 좋은 내용의 편지를 주고 받았을 것이라 생각하니 굉장히 뿌듯했다.

 

결과물

Github

https://github.com/boongObbang-plz/boongObbang

웹사이트

https://boongobbang.site/