[모아톤] 프로젝트 회고
금융 목표 달성을 돕는 '모아톤' 프로젝트의 최종 회고록입니다. Django Signals를 활용한 뱃지 시스템, GSAP 트랙 애니메이션 구현 등 기술적 성취와 협업 프로세스, 그리고 프론트엔드와 백엔드 역할에 대한 인사이트를 담았습니다.
모아톤 프로젝트를 마치며
한 달 만에 해커톤을 또 하게 되다니… ~사실 해커톤은 아니었지만, 발표 전 날 밤을 꼬박 새웠기 때문에 해커톤과 다름 없었다.~
시작은 막막했다. 기획 단계에서 주제가 계속 바뀌고 돌고 돌아 4번째 만에 ‘모아톤(Moathon)’이라는 주제가 확정되었다. 하지만 결과적으로 이 과정 덕분에 더 단단하고 만족스러운 결과물을 만들 수 있었다.
이번 프로젝트의 핵심 목표는 두 가지였다.
- GitHub 알차게 사용하기
- 완성도 높은 프로젝트 만들기
마감 일주일 전, 필수 요구사항이 쏟아지며 기획했던 기능들이 일부 밀려나기도 했지만, 팀원과 함께 CRUD를 넘어 배포와 애니메이션까지 거의 모든 기능을 구현해냈다.
기술적 도전과 성취
1. 게이미피케이션(Gamification) 시스템 구축
단순한 저축 기록 혹은 금융 상품 추천 앱이 아닌, 사용자가 즐겁게 목표를 달성하도록 돕는 것에 초점을 맞춰 기획했다.
- Django Signals 활용: 회원가입이나 특정 조건(팔로우, 댓글 등) 달성 시,
signals.py를 통해 결합도를 낮추면서 자동으로 프로필 설정과 뱃지가 지급되도록 백엔드 로직을 설계했다. - 시각적 보상: 획득하지 못한 뱃지는 흑백(Grayscale) 처리하고, 중복 획득 시 카운트를 표시하여 수집 욕구를 자극했다.
2. 역동적인 UI: GSAP 트랙 애니메이션
디자인적으로 가장 욕심냈던 부분이다. ‘마라톤’이라는 컨셉을 살리기 위해 GSAP(GreenSock Animation Platform)와 SVG를 도입했다.
- 단순한 막대바 대신, 타원형 달리기 트랙 위를 사용자의 프로필 이미지가 달리는 애니메이션을 구현했다.
MotionPathPlugin을 사용하여 SVG 경로를 따라 부드럽게 움직이는 모션을 만들었고, 반응형 디자인(aspect-ratio)까지 챙겼다.
3. 협업 프로세스의 표준화
개발 효율을 높이기 위해 GitHub 초기 세팅에 공을 들였다.
- 이슈 및 PR 템플릿 도입:
Bug,Feat,Refactor등 템플릿을 세분화하여 커뮤니케이션 비용을 줄였다. - Git 전략:
Cherry-pick을 활용해 꼬인 커밋을 풀어내거나,Stacked PR전략으로 승인 대기 시간을 효율적으로 사용하는 등 Git 활용 능력이 한층 성장했다.
PR이 꼬였을 때: Cherry-pick으로 커밋 분리하고 브랜치 복구하기
승인 대기 중인 브랜치에서 이어서 작업하기 (Stacked PR 전략)
인사이트
이번 프로젝트를 통해 프론트엔드와 백엔드가 데이터를 주고받는 흐름을 확실하게 익혔다. 특히 프로젝트 규모에 따른 역할의 무게감에 대해 깊이 고찰하게 되었다.
“규모가 작은 프로젝트에서는 프론트엔드의 역할과 책임이 훨씬 무겁다.”
프론트엔드는 프로젝트의 규모와 상관없이 비슷한 역할을 하게 된다고 생각한다. 기능 단위가 가벼울 때는 백엔드에서 데이터를 조립하는 과정보다, API로 받은 데이터를 화면에 어떻게 효과적으로 구현하고 오류를 처리하느냐가 훨씬 까다로웠다. 반면, 프로젝트 규모가 커진다면 백엔드의 비즈니스 로직 복잡도가 기하급수적으로 늘어날 것이고, 상대적으로 백엔드의 역할과 책임이 커질 것이다.
이번 프로젝트를 예로 들면, 백엔드에서 모아톤 게시글 CRUD API를 위한 serializers, view 함수 등을 설정하는 것까지가 주된 역할이었다. 프론트엔드의 경우 초기 화면 구성을 위한 와이어프레임을 설정하고 동시에 화면 전환이나 유저 플로우, 컴포넌트 분리까지 고려해야 한다. 백엔드 API 설계가 끝나면 그때부터 본격 개발에 들어가게 되는데, 화면에 필요한 필드와 API의 필드가 다르면 2차 가공 과정을 거치거나 API를 수정해야 했다. 화면에 필요한 데이터를 필요한 형태로 정제했다면, 이를 사용해서 디자인 하는 것도 프론트의 역할이었다.
“프론트엔드와 백엔드, 서로를 이해하는 협업”
가장 이상적인 협업은 기획 단계에서 와이어프레임, 유저 플로우, 요구사항, 컴포넌트 설계 및 API 설계까지 모두 정해놓고 시작하는 것이다. 하지만 실제 협업 과정이 그렇게 아름답지만은 않고 변동도 많기 때문에 유연하게 상황에 대처하는 것이 중요하다고 느꼈다. 프로젝트 진행 과정에서의 변경이 불가피하다면, 백엔드와 프론트엔드의 소통이 무척 중요하다. 그래서 더욱 서로의 역할과 개발 과정을 이해하는 것이 필요하다고 느꼈다.
이번에 내가 프론트엔드를 통으로 담당했지만, 백엔드 프레임워크인 Django도 잘 알고 있었기 때문에 API에서 어떠한 필드가 누락되었을 때, django serializer를 수정하는 것과 브라우저 단에서 수정하는 것 중 어떤 게 더 편리할 지 판단하고 작업 분담하는 데 도움이 되었다.
아쉬움과 다음 도전
1. 배포
개발 기간 부족으로 발표는 로컬 환경에서 마무리했다. 하지만 발표 이후 끝내 AWS EC2와 S3를 활용한 배포에 성공했다.
- Backend: EC2(Ubuntu)에 Nginx와 Gunicorn을 연동하여 Django 서버를 구축했다.
- Frontend: S3 정적 호스팅을 통해 Vue.js 빌드 파일을 배포하고, CORS 문제를 해결하며 클라이언트-서버 통신을 완성했다.
2. 실시간 알림
가장 아쉬운 점은 ‘실시간 뱃지 획득 알림’이다.
- 현상: Django에서는 뱃지가 즉시 지급되지만, Vue 클라이언트에서는 새로고침이나 페이지 이동(API 호출) 전까지 이를 알 수 없다.
- 원인: HTTP 프로토콜의 비연결성(Connectionless) 때문.
- 해결 방안: 이를 해결하기 위해 WebSocket이나 Polling 기법 도입이 필요하다. 다음 프로젝트에서는 Django Channels를 활용해 실시간 양방향 통신을 꼭 구현해보고 싶다.
마치며
3주라는 짧은 시간 동안 기획-개발-테스트-배포의 전 과정을 경험했다는 사실이 무척 뿌듯하다. 물론 마이데이터(MyData) 연동 같은 현실적인 제약으로 구현하지 못한 기능들도 있지만, 대신 사용자가 직접 참여하는 재미(게이미피케이션)와 시각적 즐거움(GSAP)으로 그 빈자리를 채웠다.
이번 프로젝트는 “개발은 단순히 기능을 만드는 것이 아니라, 사용자의 경험을 설계하고 기술적 문제를 해결해 나가는 과정”임을 배우는 소중한 시간이었다.