BuySell
https://www.notion.so/40-Four-T-46a46435ffb44c168c20e25ad82f7da7
40 (Four T) | Notion
‼ 회의 요약 💬 &피드백 모음💜
band-wavelength-b24.notion.site
목차
프로젝트 소개
중고 거래 플랫폼으로 개인 간의 중고 거래를 더욱 쉽게 접근할 수 있게 매칭해주는 게시판 형태의 서비스입니다.
중고 물품을 판매하는 글을 작성할 수 있고 구매자가 구매 요청을 하면 판매자와 구매자가 매칭 됩니다.
팀소개
| 팀장 | 부팀장 | 팀원 | 팀원 |
| 김성현 | 황승현 | 김민주 | 김현주 |
| lazzykim | HwangSeungHyeon | codekmj1 | hyunzoo123123 |
| 게시글, 리뷰, 결제 | 댓글, 검색, 배포, 위시리스트 | 인증, 인가, 소셜 로그인 | 프로필, 프론트 |
프로젝트 계기
최근에는 미니멀 라이프가 유행하면서 많은 사람들이 소유물을 정리하고 불필요한 물건을 줄이는 추세에 있습니다.
이러한 환경 변화 속에서 중고 거래 플랫폼은 판매자와 구매자가 함께 이익을 얻을 수 있는 효율적인 방법으로 부상하고 있습니다.
중고 거래는 더 이상 사용하지 않는 물건을 버리는 것이 아니라 재활용하고 다시 이용함으로써 자원을 절약하고 환경을 보호하는데 기여합니다.
이 서비스를 통해 개인 및 비즈니스적인 부분에서도 긍정적인 영향을 끼칠 것으로 생각되어 프로젝트를 선정하게 되었습니다.
주요기능
- 이메일과 비밀번호를 이용한 로그인
- 소셜 로그인: 카카오, 네이버, 구글
- 자기 프로필 수정
- 회원 탈퇴
- 판매 게시글 등록, 수정, 삭제
- 댓글 등록, 수정, 삭제
- 모의계좌에 입금 및 출금
- 자신이 등록한 게시글 목록 확인
- 다른 사람의 판매 제품 구매
- 구매 물품에 대한 리뷰와 평점 작성
- 판매자 평점 확인 및 판매자에 대한 리뷰 목록 확인
- 판매자 게시글 목록 확인
개발기간
- 2024.02.26(월) ~ 2024.04.04(목)
기술스택
✔️ Language
✔️ Version Control
)
✔️ IDE
✔️ Framework
)
✔️ Deploy
✔️ Local DBMS
)
✔️ Cloud DBMS
서비스 구조
와이어프레임
API 명세서
멤버 API 명세서
프로필 API 명세서
계좌 API 명세서
게시글 API 명세서
댓글 API 명세서
리뷰 API 명세서
ERD
프로젝트 파일 구조
buysell
├─domain
│ ├─comment
│ │ ├─controller
│ │ ├─dto
│ │ │ ├─request
│ │ │ └─response
│ │ ├─model
│ │ ├─repository
│ │ └─service
│ ├─common
│ │ └─dto
│ ├─exception
│ │ └─dto
│ ├─member
│ │ ├─controller
│ │ ├─dto
│ │ │ ├─request
│ │ │ └─response
│ │ ├─model
│ │ ├─repository
│ │ └─service
│ ├─order
│ │ ├─controller
│ │ ├─dto
│ │ │ └─request
│ │ ├─model
│ │ ├─repository
│ │ └─service
│ ├─post
│ │ ├─controller
│ │ ├─dto
│ │ │ ├─request
│ │ │ └─response
│ │ ├─model
│ │ ├─repository
│ │ └─service
│ └─review
│ ├─controller
│ ├─dto
│ │ ├─request
│ │ └─response
│ ├─model
│ ├─repository
│ └─service
└─infra
├─auditing
├─querydsl
├─redis
├─security
│ └─jwt
├─social
│ └─jwt
└─swagger기술적 의사결정
EC2
- [도입 이유] - [문제상황] - [해결방안] - [의사 결정]
RDS
- [도입 이유] - 비교적 빠르게 인스턴트를 생성하고 구성할 수 있음
- 필요에 따라 스토리지 용량을 확장할 수 있어 확장성이 높음
- IAM으로 접근권한을 세밀하게 관리할 수 있음 - 다양한 DB엔진 지원
- [문제상황] - AWS 서비스에 대한 사용법을 익히는데 시간이 필요함
- 다양한 옵션들의 과금정책이 복잡해 현재 상황에서 예상 비용을 계산하기 어려움
- [해결방안] - AWS 관련 자료는 다른 Cloud DB에 비해 방대한 양의 참고자료가 있기에 대부분의 문제는 검색으로 해결 가능
- AWS 비용 계산기를 사용해 사전에 예상비용을 계산하고 필요에 따라 리소스를 조정해야함
- [의사 결정] - AWS 강의와 자료검색들을 통해 학습시간을 최대한 단축
- 비용계산기로 대략적인 금액 계산 후 배포기간과 정해진 예산 이내로 리소스 조정
- 검색 시 제공되는 자료의 양이 많은 Amazon RDS 채택
ElastiCache
- [도입 이유] - 회원 가입 시 실제로 존재하는 이메일인지 확인 하기 위함 - [문제상황] - 이메일 인증 번호 저장 위치에 대한 결정 필요 - [해결방안] - Redis와 AWS RDS를 후보로 삼아 비교하고 평가하기로 함 - [의사 결정] - 인증 번호는 DB에 자주 접근하기 때문에, 사용자가 늘어날 경우 DB에 부담을 줄 수 있음 - 이메일 인증코드는 임시 데이터이기 때문에 임시데이터를 관리하는 측면에서 Redis를 사용하는것이 유리 - 빠른 속도와 자동 만료기능, 확장성에서 Redis가 우수하다고 판단해 채택
Security
- [도입 이유] - 온라인 플랫폼을 운영하는데 있어서 사용자 관리의 정교함이 중요하다 판단됨
- 필요한 데이터에 안전하고 빠르게 접근하도록 지원, 동시에 고객 데이터를 효율적으로 관리하는데 도움이 된다고 판단하여 도입함
- [문제상황] - 다양한 보안 위험에 노출되어 있기 때문에 공격으로부터 웹 애플리케이션을 보호해야 될 필요가 있음
- 사용자 인증 및 세밀한 권한 관리는 구현하기 복잡하여 이를 위한 효율적인 솔루션이 필요함
- [해결방안] - Spring Security를 도입하여 포괄적인 보안 솔루션을 제공 받아 보안 강화
- Spring Security의 다양한 보안 설정으로 애플리케이션의 특정 요구 사항에 맞게 보안 정책을 조정
- [의사 결정] - 보안 정책과 관련하여 팀 내에서 충분한 논의를 거치면서 Spring Security의 도입이 애플리케이션에 미치는 영향과 이점을 공유할 수 있어서 spring security 채택
CI/CD
- [도입 이유] - 코드 오류를 초기에 찾고 배포에 걸리는 시간을 줄이기 위함
- [문제상황] - CI를 적용하지 않고 수동으로 테스트를 했더니 시간이 많이 소요됨
- CD 미적용 시, 서버에 직접 JAR 파일 배포되는 시간이 지연 되어 검토도 지연 됨
- [해결방안] - Github Actions를 이용 - Jenkins를 이용
- [의사 결정] - CI/CD 서버가 내장되어 있어서 CI/CD 서버를 구축할 필요가 없음
- Github에 내장되어 있기 때문에 Github와 통합이 쉬움
- GitHub와의 자연스러운 연동으로 향상된 생산성을 제공하는 Github Actions를 사용
회고
2월 26일부터 4월 5일까지의 최종 프로젝트를 마쳤다.
홀가분하면서 아쉬움이 정말 많은 프로젝트인 것 같다.
팀의 리더를 맡았으나, 리더 역할을 충분히 수행했는지에 대한 후회가 남아있다.
우리는 공부하러 온 사람들이기 때문에 스스로 알아서 해야지 라는 안일한 생각을 가지고 있었던 것 같다.
국비교육 특성상 무료이기때문에, 모두가 같은 마음일거라고 생각하면 안됐는데..
스스로 잘 하고 있겠지 하면서 팀원들의 일정관리를 너무 러프하게 가져가서 막판에 조금 힘에 부치지 않았나라는 생각을 했다.
한 사람으로 인해 팀원의 불만이 쌓인 상황을 해소하기 위해, (나도 불만이 쌓이긴 했다) 모두가 보는 앞에서 꾸짖는 상황이 되었는데
돌이켜보면 너무 감정적으로 행동한게 아닌가라는 후회가 됐다. 그분과 이야기를 나누고 사과를 해야했던 부분이 있다면 팀원들에게
사과를 하게하는 방식이 맞지 않았나 싶다. 난 평소 인간관계에 대해 자신이 있던 사람이었는데 이러한 일들로
조금 돌이켜 보게 된 계기가 되지않았나 싶다.
마무리 후 KPT회고를 할 까 했지만 시간이 늦었고 수료 이후 각자 일정들이 있었기에 KPT는 생략하는 쪽으로 정했다.
그 전에 간단하게 자체평가를 진행했던 내용이다.
아쉬웠던 점
코드리뷰 방식에 대해
- PR이후 다같이 모여서 PR 작성자가 추가, 수정에 대한 내용을 발표하는 방식으로 진행을 했다.
취지는 좋았으나 팀원들의 기능을 구현했던 경험의 차이가 있어 그 내용에 대해 전부 이해하지 못하고 시간관계상 넘어가게 된 점이 아쉬웠다.
발표자가 발표를 하는데, 이해가 안되는 사람은 어떤 부분에서 질문을 해야할 지 조차 포인트를 못잡을 때가 있었다. (나도 그랬다)
이 부분은 아직 정답을 찾진 못했다. 데드라인이 없고, 자유롭게 학습하는 과정이었다면 좀 더 긴 시간을 투자할 수 있었을 텐데,
5주동안 완성 후 배포까지 해야되는 상황이었기에 이 부분에 집중을 하지 못했다.
첫 취지는 다른사람이 구현한 기능, 코드를 모두가 이해하자는 것이었지만 이 부분이 정말 어려운 것 같다.
팀 컨벤션
- 아무래도 약 4개월간 여러 프로젝트를 진행했지만, 팀 컨벤션을 정하고 개발을 했던 적은 거의 없었다. 전에 개발을 하다 오신 분과
팀을 했었던 나는 한번이라도 경험이 있었지만, 아무것도 모르는 사람끼리 편성이 된다면 이 부분을 꼼꼼히 챙기지 못했을 것이다.
현업에서도 1인개발을 하는 환경이 아니기 때문에, 이 부분에 대한 중요성을 모두가 간과했던 것 같다.
컨벤션을 지키지 못하고, 각자 다른 양식의 커밋내용을 작성하는 일들이 많이 생겼다. 내꺼 하느라 바쁘다는 핑계로
다른사람의 커밋 메세지를 확인하지 못하고, 사실 봤다하더라도 그냥 넘어가는 일이 있었는데 잘 확인했어야 됬는데 라는 후회가 있다.
그래도 이번에 또 한번 경험을 해봤기 때문에 다음엔 전 보다 나아질 것이다.
기획
- 커리큘럼에 프론트에 대한 내용도 없었고, 프론트가 어떤 일을 하는지 모르는 상태에서 앞단까지 구현해야하는 프로젝트였다.
약 5주간의 기간동안 백과 프론트를 둘 다 해야하는데, 프론트를 너무 간과해 4주차에 접어들면서 모두가 프론트로 빠지게 되었다.
백엔드 커리큘럼에서 프론트때문에 서버쪽에 신경을 많이 못 썼다. 이건 개인적으로 커리큘럼에 대한 불만이지만, 뭐 어쩌겠나..
프론트를 구현하면서 자바스크립트 코드를 처음 써봤다. 팀원 모두가 처음이라 에러가 났을때 어떻게 에러를 해결해야할지도 모르고
최악의 최악상황이었다.. 그래도 4명에서 달라붙으니 완성은 하긴 했으나, 사실 만족스럽지 못하다. 기간을 조금 정확히 분배했으면
막판에 새벽 4시 5시까지 할 일은 없었을텐데.. 아쉬움 뿐이다.
좋았던 점
기록하는 습관
- 팀 노션에 회의내용과 튜터님들의 피드백을 모두 기록했다. 회의록을 작성하니 어느부분에서 지연이 되고 있는지 파악이 쉬워
일정관리에 도움이 됐다. 또 튜터님들 피드백을 정리해서 기록해두니 이부분도 사실 트러블슈팅에 관한 내용이 될 수 있어
에러를 관리하는데 편했다.
이제 앞으론 튜터가 없지만 내가 에러가 났을 때, 이런식으로 정리해두면 에러해결하는데 큰 도움이 될 것 같다. 괜히 트러블슈팅을
기록하라는게 아니었다. 정말정말 도움이 많이 되는듯 하다.
문제 해결 방식
- 오류가 발생했을 때 모두가 다같이 모여서 왜 에러가 났는지, 해결방법에 대해 의견제시를 했던 부분이다. 사실 이 방법이 괜찮은 방법
인지는 잘 모르겠다. 에러를 해결하려고 모든 팀원들의 개발이 스탑되는거니까.. 하지만 공부하는 입장에서 다같이 생각을 하고, 고민을
하는 과정이 썩 나쁘지 않았다. 그리고 다른 사람이 같은 에러가 발생했을 땐 모두가 그 내용이 공유되어있는 상황이기에 보다 빠르게
해결을 할 수 있었다. 다음에 또 팀프로젝트를 하게 된다면 이슈에 버그에 대한 부분을 작성하고, 모두가 확인하게끔 해 서로 개발을
하면서 버그를 인지하는 방법이 좋지 않을까라는 생각을 했다.
의사소통
- 다행히 팀원들 중 모난사람 없이 상대방을 배려할 줄 아는분들이었다. 물론 서로 예민할 때도 있었지만, 잘 돌려 말하는 모습이
눈에 보였다. 팀끼리 큰 트러블이 생겨 팀이 터지지 않은 이유 중 하나가 이 부분이 아닐까 생각된다. 말을 이쁘게 하는 습관은
언제 어디서든 써먹을 수 있으니.. 중요하게 생각해야겠다.
추후 개발 및 도전계획
- 채팅, 쿠폰을 구현할 때 동시성처리, 결제기능 고도화, 게시글 캐싱 등 도전해볼 내용은 정리를 해두었으나, 모두가 같은 마음이
아니고, 사실 나는 학습이 부족하다고 생각해 프로젝트가 끝나면 개인공부를 하러 가려고 한다.
프로젝트가 끝나도 추가적인 성능개선을 하게되면 면접때나 이력서에도 쓸 말이 생기겠지만,
현재 나에겐 개발자로써 기초적인 능력이 부족하다고 판단해 언어 기초부터 프레임워크까지 다시 공부하려한다.
취업이 목표이지만, 기본적인 능력이 부족하면 안되니까!
힘들기도 했고 재밌는 경험이었다.
최종 프로젝트를 하면서 나의 밑천이 드러나는게 눈에 보여서 사실 견디기 힘들었던 것 같다.
더 확실하게 준비해서 보람있는 기간을 만들어봐야겠다.
'내일배움캠프 프로젝트' 카테고리의 다른 글
| BuySell - 주문 조회 (0) | 2024.04.03 |
|---|---|
| BuySell - S3 이미지업로드 (2) (1) | 2024.03.29 |
| BuySell - S3 이미지 업로드 (0) | 2024.03.28 |
| BuySell - 선착순 쿠폰 발급기능 (3) (0) | 2024.03.24 |
| BuySell - 선착순 쿠폰발급 (2) (0) | 2024.03.20 |