프로젝트 소개
🐳 SAVIEW = SAVE + INTERVIEW
면접을 준비하는 개발자들을 위해 면접 질문과 답변을 모아 놓은 공간, 세이뷰 입니다!
팀원
- 인원: 프론트엔드 개발자 2명 + 백엔드 개발자 2명 (총 4명)
 |  |  |  |
|---|---|---|---|
| 박인후 | 박진혁 | 김경륜 | 김성연 |
| FE | FE | BE | BE |
주요 기능
- 각 카테고리별로 원하는 질문을 조회
- 각 질문을 조회수 기준으로 정렬하여 다수의 사람들이 조회한 질문 조회
- 특정 질문 카드를 클릭 시 답변을 최신순 또는 추천순으로 정렬하여 어떤 답변이 사람들로부터 많은 호응을 얻고 있는지 확인 가능
- 각 유저는 직접 면접 답변을 달고 댓글을 작성하는 것으로 피드백을 주고 받을 수 있음
- 원하는 질문을 검색해서 조회
- 이메일 발송: 이메일 인증, 비밀번호 분실
- 카테고리 관련 채용정보 자동 추천
프로젝트 관리
프로젝트는 노션과 깃허브 프로젝트 & 이슈를 통해 관리하였다.
각 팀원들의 진행할 일과 진행하고 있는 일을 한눈에 볼 수 있게 이슈 작성, 마일스톤, 프로젝트를 사용하였다.
처음에는 이게 편할까? 생각했었는데, 쓰다보니 너무 편해서 놀랐다.
PR과 이슈를 연결할 수 있고, 디스커션까지 가능해서 아주 편하고 좋았다!!
그리고 PR 템플릿과 이슈 템플릿을 사용해서 통일화된 양식으로 핵심적으로 변화된 내용과 리뷰어에게 전달할 내용 등을 적어서 관리가 잘 되었던 것 같다.
회의는 월, 수, 금 오전에 팀 전체 회의를 진행했다. 물론 정기 회의만 그렇고, 모든 팀원이 게더타운에 상주하면서 필요할 때 소통할 수 있도록 했다. 그래서 사실 상 작은 회의들도 고려하면.. 하루에 2번씩은 했던 것 같기도 하다.
회의할 때는 무조건 팀 노션에 회의록을 적도록 했다. 그리고 정기회의 이외의 시간에 회의를 하게되는 경우에 회의를 하고싶은 사람이 먼저 회의 주제를 적어서 회의 전에 공유하도록 했다. 덕분에 회의를 할 때 다들 내용을 이미 숙지하고 있어서 대부분 원활하게 진행할 수 있었다.
-
팀 규칙
-
쿠션어 사용과 명확한 의사 전달
-
커밋 메세지
-
깃 브랜치 전략
-
PR 규칙, 리뷰 규칙
-
- Github Project
- 팀 노션 회의록
프로젝트 과정
이번 프로젝트는 기획부터 설계, 그리고 개발과 배포까지 진행하였다.
사용자 요구사항 정의서
노션에 사용자 요구사항 정의서를 정리하였다. 여러가지 툴을 사용할 수 있었지만, 모든 팀원이 함께 수정하고 공유하기 위한 툴로 노션이 가장 좋은 것 같아서 선택하였다.
처음 작성할 땐 중요도까지만 구분했다가 프로젝트 기간 내에 필수적으로 구현해야할 기본 기능들이 한눈에 보이지 않아서 '구현 구분' 옵션을 추가했다. 구현 예정이라고 구분한 항목들을 우선 구현하도록 하였고, 기간 내에 모두 구현하였다.
그리고 하나더 추가한 부분이 있는데, 백엔드 & 프론트 & 최종 완료 여부를 체크박스로 표시하도록 하였다. 이슈로도 공유했지만 서로의 진행현황을 한눈에 볼 수 있게 하면 좋을 것 같아서 추가하였다. 이 부분을 추가해서 작업 우선순위도 그 때 그 때 서로의 상황을 고려해서 수정할 수 있어서 좋았던 것 같다.
ERD
처음 설계한 테이블에서 버전 4정도로 변경했다.
프로젝트 시작할 때 팀 목표 자체가 기본 기능 부터 구현한 다음 새로운 기능을 추가하자! 였어서, 기능이 추가될 때마다 테이블을 수정할 수 밖에 없었다. 그러다보니 버전 4까지 갔다.
보면 알겠지만 솔직히 우리 프로젝트의 테이블 구조가 꽤 단순하다.
일단 기본 기능을 잘해야 좋은 서비스라고 생각하기 때문에.. 만족하기로 했다.
API 명세서
api 명세서는 깃북을 이용해서 작성했다.
깃북 그룹 계정이 있는 것을 발견해서 아주 신나서 팀원들을 초대했는데, 무료 기간이 정해져있었다... 졸지에 api 명세 수정 권한 독점하게 되었다... 그래서 마지막에 좀 죄스러웠던..🥲
기술 스택 & 백엔드 인프라
초기에는 서버 배포를 Code Deploy 파이프라인으로 설정했다가 이후에 깃헙 액션즈로 변경했다.
그 이유는 서버를 2개 운용했기 때문인데, 프로젝트를 진행하면서 개발서버와 운영서버의 분리 필요성을 느껴서 main , test-server 로 브랜치를 나눠서 깃헙 액션을 통해 자동배포를 설정했다.
백엔드 개발자가 각각 서버를 1개씩 담당해서 RDS와 EC2 를 관리하는 경험을 각자 할 수 있어서 좋았고, 프론트엔드 개발자 분들도 테스트할 때 편하게 할 수 있어서 좋아하셨던 것 같다.
또 운영서버와 같은 환경을 하고 있는 개발서버를 사용해서 테스트하는 과정이 있어서 코드를 더 안정적으로 돌릴 수 있었던 것 같다.
(로컬에서 개발할 때는 h2, 배포 서버에서는 mySQL을 사용한 점을 고려하면 더 그런 것 같다)
프로젝트를 하면서
담당한 부분
pre-project에서는 시큐리티 부분을 담당해서 이번엔 경륜님과 서로 바꿔서 진행해보기로 했다.
그래서 아래와 같이 CRUD 구현과 JPA 매핑을 주로 작성하였고, 이외에 메일 발송 기능이나 데이터 정렬과 검색 기능 등을 구현하였다.
- question, answer, comment, user CRUD 구현 (+JPA 매핑)
- 데이터 검색 및 정렬 구현
- 메일 발송 기능 구현 (이메일 인증. 임시 비밀번호 발송)
- CI/CD
- 운영 서버 관리
배운 점
-
프로젝트 기본 환경 세팅의 중요성을 배웠다. 기본 환경을 조금이라도 잘못 설정하면 오류가 발생할 수 있고, 오류조차 발생해주지 않는.. 알 수 없는 문제가 발생할 수 있다는 사실을 배웠다.
-
이메일 발송 기능에 대해서 공부하게 되었다. 새롭게 공부하게 된 내용이라 블로그에 정리도 해보았다. 프로젝트로 인해 좋은 경험을 한 것 같다.
-
정말 많이 배운 프로젝트였다. 에러도 많이 만나고 인증서 적용, 깃헙 액션 설정, 알수없는 오류들.. 환경 세팅의 차이로 발견한 문제들.. 이러한 경험들을 통해 책과 강의에서 배울 수 없었던 문제들을 만나고 해결하는 경험을 얻게 된 것 같다.
아쉬운 점
-
아쉬운 점은 넘쳐난다.. 예외처리를 잘 못한 것 같다. 한다고 했지만 프로젝트 마지막까지 수정했다. 아마 아직 발견 못한 예외처리가 있을 수도 있을 것 같다..리팩터링하면서 잘 찾아봐야겠다.
-
테스트 코드 작성을 못한 것이 아쉽다. 경륜님과 해보자고 말은 했는데 나는 실패했다.. 이제 프로젝트도 끝났으니 테스트 코드 공부좀 해야할 것 같다.
-
프로젝트 기간 내에 리팩터링까지 하고 싶었는데 못했다. 생각보다 시간이 부족했다. 비록 공식 프로젝트 기간은 끝났지만, 앞으로 2주 정도 더 투자해서 리팩토링 하려고 한다.
마지막으로
짧다면 짧고, 길다면 긴 시간 동안 좋은 분들과 프로젝트를 진행할 수 있어서 정말 좋았다.
이론이 아닌 실제 프로젝트에 코드를 적용하는 것으로 많이 배운 것도 있지만, 팀원분들이 서로 배려하고 자주 소통하면서 프로젝트를 진행하는 모습을 통해 협업하는 부분에서도 크게 배운 것 같다.
여러 부분에서 뜻 깊은 시간이었고, 감사한 시간이었다.
