IT 동아리 COW에서 진행했던 학기말 프로젝트에 대해 고민했던 점을 기록해보려합니다. 첫 프로젝트이자 로그인부터 배포까지 진행했던 프로젝트이기에 저에게 뜻깊은 이야기라고 생각합니다! 재밌게 봐주세요🥹
사용했던 기술 스택
우선 저는 이번 프로젝트에서 백엔드를 맡아서 프로젝트를 진행했습니다. 클라이언트는 React.js를 사용했고 아래는 제가 사용했던 기술 스택입니다.
- Spring Boot 3.1.4
- Spring Data JPA
- Spring Security
- Spring OAuth2
- Java 17
- MySQL 8.0
- EC2
- CodeDeploy
- Github Actions
- S3
- RDS
- Postman
- Figma
- Notion
기획 및 설계
저는 COW라는 IT 동아리의 동아
리원이자 교내 사진 동아리 '포토랩'이라는 곳의 운영진을 함께 하고 있는 학생이었습니다.
사진 자랑도 총총..
돌아와서, COW에서는 Spring에 대해 함께 공부한 후 마지막 세션으로 클라이언트 + 서버 팀이 함께 프로젝트를 진행하게 됩니다.
프로젝트 팀이 정해지고 저희는 2023년 2학기 동안 약 2개월이라는 시간에 어떤 프로젝트를 하면 좋을지 고민을 하다가 아래와 같은 프로젝트를 진행하게 됩니다.
기획 의도
- 포토랩에서 매달 하는 전시에 대해 온라인으로 포토랩 회원 및 외부 사람들에게 공유할 수 있는 홈페이지를 만들고자 한다.
- 오프라인 전시는 비용이 많이들어 하고자하는 전시가 있어도 큰 제약이 생기기 때문에 온라인으로 포토랩의 사진들을 공유할 수 있으면 좋겠다는 의견이있었다.
- 활동을 정리하고 어떤 동아리인지 홍보하기에도 좋다.
- 가장 중요한 이유는 상품이 걸려있는 공모전을 인스타의 좋아요로 투표하는데 이는 외부 사람들의 개입이 가능하고, '인기투표'로 변질될 수 있다는 우려가 많았던 상황이었다. 때문에 포토랩의 회원만 투표에 기여할 수 있도록 하면 좋겠다는 생각이들었다.
어떤 서비스인지 설명
- 포토랩에서 운영하는 전시(명예의 전당(매월), 계절 전시회(계절마다), 출사지 사진 공유(월 2회))를 등록하여 전시한다.
- 공모전을 등록하고, 공모전이 끝나게 되면 게시자가 정한 수상 작품 수 만큼 전시회에 등록할 수 있도록 한다.
- 일반 사용자들은 전시를 보고 공감 버튼을 누를 수 있다. (공모전에서는 이 기능을 투표로 사용할 것이기에 중복 불가능)
- 관리자(운영진)은 전시 및 공모전을 등록, 수정, 삭제할 수 있어야 한다.(각 사진도 마찬가지)
- 관리자(운영진)은 회원의 정보를 관리할 수 있다.
- 타겟 이용자
- 주사용자 : 포토랩 동아리원
- 부사용자 : 포토랩 이벤트 참여자, 포토랩 사진 보고싶은 일반 사용자
유저 시나리오 및 스토리 작성
일반유저
- 로그인 및 회원가입
- 공모전 작품 또는 자신이 마음에 들어한 작품에 공감버튼을 누른다.
- 자신의 작품 중 전시회에 등록된 작품을 모아볼 수 있다.
- 자신의 정보를 수정할 수 있다.
관리자
- 공모전에서 수상한 작품을 전시의 형태로 올린다.
- 각 공모전, 전시와 각 등록된 사진 모아서 관리(등록, 삭제, 수정)한다.
- 포토랩의 회원을 관리할 수 있다.
우리 팀은 시험기간이 껴있는 2개월이라는 시간동안 기획 및 개발을 진행해야했기에 이번 프로젝트에서 다룰 정도를 나누기로 했다.
Must Have
- 전시, 공모전 CRUD
- 공모전에 게시물 업로드(관리자 권한)
- 게시물 수정, 삭제(관리자 권한)
- 공모전 기간이 끝나면 전시회로 바로 저장하도록 한다.
- 게시물에 공감 기능 (중복 불가, 일반 사용자 권한)
- 로그인/회원가입
- 일반 유저로 로그인/회원가입
- 마이페이지에서 공감한 사진 조회
- 어드민 페이지
- 유저 관리자 권한 관리
- 공모전, 전시
Should Have
- 번개 출사 기능
- 로그인 한 모든 유저가 번개 출사를 등록할 수 있다.
- 자신이 등록한 번개출사만 수정할 수 있다.
- 관리자는 모두 수정할 수 있다.
Could Have
- 사람들이 예쁜 곳에서 사진 찍는 것을 좋아하기 때문에 사진 동아리 특성을 이용하여 각 장소의 베스트 컷들을 지도에 표시한다.
Won't Have
- 달력에 출사 일정 입력
- 출사 일정 등록, 삭제 폼
ERD 및 배포 구성
프로젝트에서 사용한 ERD입니다.
Should Have에 들어있던 번개 출사는 시간 문제로 팀원들과의 협의 끝에 다음 기회에 추가해볼 기능으로 남겨두었습니다.
배포 자동화를 위한 흐름입니다.
- https://velog.io/@bluewind8791/Github-Actions
- https://velog.io/@donghokim1998/SpringMySQL-github-action-AWSS3-EC2-CodeDeploy-사용하여-CICD-구축하기
- https://jinmay.github.io/2020/05/13/git/github-action-syntax/
위 블로그 및 여러 분들께 많이 여쭤보며 작업했었는데 이 내용들도 블로그에 정리해볼까 합니다!
개발 Github 및 Postman API document
https://github.com/mju-photoLab/photoLab-BE
GitHub - mju-photoLab/photoLab-BE
Contribute to mju-photoLab/photoLab-BE development by creating an account on GitHub.
github.com
https://documenter.getpostman.com/view/31107830/2s9YXnzeN9
v1
The Postman Documenter generates and maintains beautiful, live documentation for your collections. Never worry about maintaining API documentation again.
documenter.getpostman.com
변명이지만, 마감기한을 지키면서 개발을 한다는건 트레이드 오프가 굉장히 심한 일이더군요..
여기서 가장 부끄러운 점은 매우 중요한.. 테스트 코드를 작성하지 않았다..는 것입니다. 또한 Swagger나 Spring Rest Docs 등을 이용해 API 문서화를 하지 못 했다는 것도 아쉬운 상황이었습니다.
물론 초기 계획은 테스트 코드와 함께 안정성있는 개발을 목표로 했으나, 러프하게 짰던 계획도 여러가지 이슈로 미뤄지게 되는 상황이 많았습니다.
때문에 가장 1순위로 생각했던 "작동하는 코드를 만들자!" 라는 생각으로 작업했던 것 같습니다.
안정적인 운영이 가능한 코드 하지만 완성 되지 않은(배포 및 기능 미흡) VS 최소한의 확인을 통해 정해진 목표를 완료하고 배포까지 성공한 코드
면접에 다녀온 선배분들이 몇 번씩 고민해보라던 주제였는데요. 저에게 이렇게 빨리 고민할 순간이 올지는 몰랐습니다.. 사실 저는 백엔드가 든든한 탱커(?) 역할이어야 한다고 생각하는 사람이었고, 이에 매력을 느껴 백엔드 개발자가 된 케이스였습니다.
백엔드란 자고로 어떤 오류든 예상치 못한 오류는 없어야하고, 테스트까지 완료되어 문서화된 API를 클라이언트에게 제공하는 것이 필수적이라고 생각했었어요. 물론 이 생각에는 아직도 변함이 없습니다.
그런데, 현실적으로 생각했을 때 이번 프로젝트에서 저를 포함한 함께 진행한 백엔드 분들이 Spring에 대한 이해도가 부족한 상황이었고, 백엔드 팀장이자 PM을 맡은 저로서는 이 프로젝트를 어설프더라도 완료해야한다는 책임감이 있는 상황이었습니다.
현실 서비스라면 분명 마감기한을 미루면서 더 높은 완성도를 보여준다는 이점이 있겠지만, 이 프로젝트는 방학이 되기 전에 동아리원 전체 앞에서 마무리를 지어야하는 상황이었기 때문에 더욱 이런 선택을 했던 것 같습니다.
이런 고민들뿐만 아니라 기술적인 고민들을 최대한 블로그에 작성하고자 합니다. 많관부😆
이후에 진행한 프로젝트들
핀구(Fingoo) - 경제 분석, 시각화, 공유할 수 있는 금융 투자 분석 플랫폼
백엔드 개발
23.12 ~ 24.06(6개월)
Links
- Service: https://fingoo-web-beta.vercel.app
- Github: https://github.com/Fingoo-org/Fingoo
- 텀블벅(투자): https://tumblbug.com/fingoo
---------------------------------------------------------------------------
MARU-EGG - RAG기반 입학 문의 및 상담 챗봇
백엔드 개발
24.06 ~ 운영중
Links
- Service: https://maru-egg-fe.vercel.app
- 입학처 페이지: https://iphak.mju.ac.kr/main/index.php
- Github: https://github.com/MARU-EGG/MARU_EGG_BE
---------------------------------------------------------------------------
핀디(Findy) - 유튜브 영상 속 장소 추출 및 즐겨찾기 통합 서비스
백엔드 개발
24.09 ~ 개발중
Links
- Github: https://github.com/Findy-org/FINDY_BE
이 때의 마음을 잊지 않고, Test 코드에 대해 공부를 진행했고, 진행했던 모든 프로젝트에서 Test 코드를 작성하며 프로젝트를 진행하고 있습니다!
특히 창업을 목표로 했던 Fingoo에서 Test코드 없는 코드는 지속적으로 변경되는 요구사항에 무너질 수 밖에 없음을 절실히 깨달았습니다.
결론: Test 코드는 필수이다.(특히 비지니스 적으로 중요한 로직)
느낀점
네.. 저는 이번 프로젝트에서 PM 겸 백엔드를 맡아서 진행했습니다. 사실 처음하는 프로젝트라 PM이라는 말이 웃기기도 하지만 기획에 대한 아이디어가 저에게서 나왔기에 당연한 일이었던거 같아요.
때문에 당연하게도 대부분의 코드와 작업들이 저에게 쏟아졌습니다.
제가 이번 프로젝트에서 작업한 부분은
- 기획 및 설계
- 프론트와 디자이너 연결
- ERD 및 API 문서 작업
- Spring Security를 사용해 JWT를 통한 로그인 + OAuth 카카오 로그인
- 유저, 공모전, 전시회, 사진, 공감에 대한 프로덕트 코드
- CI/CD
이정도인 것 같습니다. 너무나 뿌듯하네요!! 결론적으로 백엔드에서 EC2에 배포한 API를 클라이언트에서 요청하고 응답되는 과정이 성공했기 때문에 더 뿌듯한거 같습니다.
이 작업들을 하면서 기술적으로 느낀점은 추후에 블로그에 하나씩 정리해서 올려보겠습니다.
저는 개인적으로 디자이너의 부재는 생각보다 프로젝트에 많은 영향을 준다고 생각했습니다. 일반인 즉, 이 서비스를 사용하는 사람들은 눈에 보이는게 중요할 수 밖에 없으니까요.
저희 팀에게는 지정된 디자이너가 없었기 때문에, 팀원들과 운영진들에게 상의한 후 모두가 만족한다는 의견을 들었고, 저는 저의 지인에게 디자이너를 부탁하게 되었습니다.
덕분에 더 완성도 있는 작업물이 나오게 되었고, 프론트를 맡은 분도 만족하며 작업을 하셨습니다.(디자이너와 백엔드 사이에서 소통하는 방법에 대해 직접 경험해보셔서 좋았다고 하셨어요!)
Figma
Created with Figma
www.figma.com
백엔드 작업을 함께한 한 분은 저학년에 아직 Java나 Spring에 대해 조금씩 알아가는 중이었지만, 너무나 열정적으로 하시는 분이기에 제가 아는 부분을 최대한 설명해드리고, 공부해오시면서 코드에 적용해보는 방식으로 진행했습니다. 처음 작성해오신 코드에서는 이유 없이 긁어오는 코드도 있었지만, 후반에 갈 수록 눈에 띄게 성장하시는게 보여서 같이 프로젝트하는 것이 보람찼던거 같습니다.
다른 한 분은 코드보다는 시스템이나 어떤 설정에 대해 조작하는 것을 좋아하는 분이었기에 배포 및 S3 bucket에 이미지를 저장하는데 필요한 설정을 맡기게 되었습니다. 이때 각자가 관심있는 분야에서 역할을 조금 더 확실하게 나눠 프로젝트를 진행하면 더 재밌게 프로젝트를 진행하고 완성도가 높을거 같다는 생각이 들었어요.(그래서 현재는 경제시스템, 경영지원, 총괄, IT 개발로 팀을 꾸려서 프로젝트 중입니다! 이것도 나중에 회고해볼게요!!)
팀원간의 갈등과 고민들도 분명 있었습니다. 처음에는 프로젝트에 대한 관심도 차이에서 오는 문제 때문에 꽤나 애를 먹었던거 같아요. 어떤 팀프로젝트이든 저는 이 부분이 가장 근본적으로 문제가 발생한다고 생각했습니다. 사람마다 우선순위가 다른거니까요. 저는 이를 최대한 활용해보려 했습니다. 제가 예상보다 많은 부분을 맡게 되었더라도 다 경험이라고 생각했고, 그 사이에서 잘 조정하는 것이 저의 역할이라고 생각했습니다!
정말 많이 부족하지만 최선을 다했던 프로젝트였습니다..!