1.31 ~ 2.18 진행된 공통프로젝트를 회고해본다.
0. 총평
나의 첫 프로젝트
1학기 마지막 2명이서 진행한 프로젝트 이후로, 처음 진행하는 프로젝트였다.
누가 떠먹여주지도, 참고할 강의코드도 없는 말그대로 맨땅 헤딩의 상태로 시작해야 했다.
나는 프론트엔드보다 백엔드단에 마음이 가는 상황이어서, 마침 프론트엔드 3명이 다 있고, 백엔드 2명은 자바 전공자여서 백엔드 한 자리가 빈 상황이었다. 내가 자바와 스프링을 배우면서 진행하겠다고 했다.
결론은? 진짜 죽는 줄 알았다.
내가 차근차근 천천히 배우는 스타일임에도 불구하고, 빠르게 습득을 위해 미친듯이 (내 기준에서 빠른 속도로) 자바와 스프링을 공부했다. 자바는 자바의 정석을 여기저기 뒤져가며 공부하고, 전공자 반 수업 다시듣기까지 했다. 스프링은 인터넷강의와 전공자 반 수업을 활용하되, 최대한 바로 개발로 뛰어들려고 나름의 노력을 다했다.
왜 이렇게 어려웠냐고?
기존에 자바와 스프링을 사용해 프로젝트를 진행했던 전공자 친구들도 WebRTC, JPA는 처음이었을 뿐 아니라, 우리팀의 경우 프로젝트 경험이 (아마 전부)없어서, 기획부터 마지막 시연 순간까지 매일 새로운 상황에 부딪혀야 했던 것이다.
그리고.. 소통..
소통이 중요하다, 중요하다 했지만 정말 중요했다.
자기가 할 일을 정하면 가져가서 하고 했다고 표시하고, 예정일보다 많이 늦어질 것 같면 늦어질 것 같다고 하고, 힘든점이 있다면 이래서 어렵다고 이야기해야 할 것 아닌가?
서로 좀 더 적극적으로 소통했다면, 백엔드와 프론트엔드가 마아악판이 아닌 중간중간마다 함께 작업했다면 좋았을 것 같다는 아쉬움이 남는다.
고통...눙물...진짜..힘들었다..
자바 걸음마를 막 떼기 시작한 내가 스프링부트, JPA의 개념을 이해하고 컨트롤러를 만들고, 쿼리를 짜고, 데이터베이스를 설계하고..결국 배포까지 했다. 모든 과정이 하루하루 고통이었다면 고통이었다. 내가 팀에 바로 기여할 수 없다는 스트레스. 숨을 쉬기 어려웠고 매일매일 눈을 뜨는게 두려웠다. 내가 모르면 다른 사람이라도 알아야 하는데, 딱 맞는 답도 나오지 않았다. 아마 나만큼이다 다른 팀원들도 많이 힘들었을 것이다.
그런데...
그래도...
어찌되었던 해내지 않았나.
성공적으로 발표하지 않았나.
미완된 기능도 있고, 보안적으로 손봐야 할 것도 있지만
그래도 최선을 다했다...
팀원 전원이 프로젝트가 처음이어서.. 어쩔 수 없는 부분이 있었다..
너무너무 힘들었지만 그래도 많이 성장했다...라고 말하고 싶고, 사실일 것이다.
그래서 나는 뭘 했나
- OpenAPI 2개를 활용하여 파싱을 통해 repository 에 데이터 저장(builder 활용)
- 해당 데이터 기반으로 다른 테이블과 관계지어 repository - serive - controller 활용하여 API 개발 (JPA)
- CORS 처리(SpringSecurity 에 적용할 수 있는 전역 CORS 처리 구현)
- Validation (회원가입시 데이터 validation 구현, annotation 활용)
- Lombok 을 활용하여 코드 효율화
- Slf4j 로깅을 활용
- EC2 Nginx 배포
- HTTPS 적용 및 프록싱
1. 소개
어떤 프로젝트였나?
- 코로나 블루 극복을 위한 화상 독서모임 서비스
- WebRTC 기술을 활용한 프로젝트
2. 기획
왜 이 프로젝트를 기획했나?
- 도서 데이터와 WebRTC 기술을 연동하여 도서별로 회의를 만들면 1회성으로 온라인 독서모임을 열 수 있어 보다 쉽게 누구나 독서모임에 참여할 수 있을 것 같았다.
- 웹기술보다도 첫 프로젝트인 만큼 기획과 개발 전반에 대한 이해를 쌓을 수 있을 것 같았다.(웹기술에 집중하지 않았다 보니, 명세와는 거리가 있었던게 사실이다.)
기획 단계에서 새로 배운 것
- 거의 모든 것
- zira 사용법
- 깃 플로우 관리법
- 데이터베이스 설계방법
- API 명세 구축 방법
기획 단계에서 잘했다고 느낀 점
- 사용자 입장에서 불편한 점들을 모아 기능으로 전환하였다.
ex. 독서모임에 모임의 목적과 다른 의도로 접속하는 사람을 막기 위해 회의 입장시
질문지와 비밀번호를 설정하여, 책을 읽은 사람만 회의에 접속하게 하였다.
ex. 독서모임에 지각하는 문제를 막기 위해 회의 북마크시 회의 시작 1시간 전에
미리 이메일로 알람이 가게 하였다.
기획 단계에서 아쉬웠던 점
- 데이터베이스를 설계할 때 컬럼명, 데이터타입을 통일했어야 했는데 그러지 못했다.
- MySQL 과 스프링부트 JPA 의 경우 코드스타일이 다른데 이점을 미처 몰랐다.(스네이크 케이스, 카멜케이스 등)
- API 명세에서 url을 통일하고 개발을 시작했어야 했는데, 그러지 못했다.
- HTTP 에러코드에 대한 이해가 부족했다.
3. 개발
개발 단계에서 새로 배운 것
- 거의 모든 것
- Spring
- Springboot
- JPA
- MySQL
개발 단계에서 잘했다고 느낀 점
- print() 대신에 log() 를 사용하려고 노력했다.
- Spring 문서를 뒤적거리면서 SpringSecurity에 CORS 를 적용했을 때 뿌듯했다! (스택오버플로우에나 블로그에는 정확한 정보가 나와있지 않았다.)
개발 단계에서 아쉬웠던 점
- 프로젝트 많은 시간을 스프링-스프링부트 적응하는데 할애해서 그 점이 아쉬웠다.
- Java 기본기를 잘 다져야겠다는 생각을 했다.
- 오류처리를 어떻게 하면 좋을까, 무조건 try-catch 잡아서 e.printStracktrace() 하면 되는걸까..? 고민이 들었다.
- status code 에 대한 이해가 부족해서, 어떤때 404를 날리고 어떤때 200을 날려야하는지 등등, 헷갈리는 부분이 많았다.
- JPA 와 데이터베이스의 관계 파악이 프로젝트 끝날 때 되어서야 조금씩 되었다. 처음 디비는 mySQL 로 구축하고 Spring 설정에서 mySQL 이 JPA 에 의해 자동 업데이트되지 '않도록'한다.. Entity는 디비에 맞게 만들어 적용한다.
4. 배포
배포 단계에서 새로 배운 것
- 거의 모든 것
- EC2 SSL 을 닫으면 너의 미래도 살짝 닫힌다.
- Nginx로 손배포 하는 법
- 리눅스 명령어를 이것저것 쳐보았다.
배포 단계에서 잘했다고 느낀 점
- 잘 모르겠다. 고군분투하고 쌩 난리를 치고, 블로그를 찾고 공식문서를 봐도... 어려웠다.
배포 단계에서 아쉬웠던 점
- root 권한으로 실행했다. 사용자를 분리하여 나누어 실행해야 보안상 안전하다 한다.
- docker 를 사용해보지 못했다.
- jenkins 로 자동배포를 구현하고 싶었는데 이미 너무 늦은 뒤였다. 프로젝트 초반에 구축해둬야 한다.
5. 유지보수
생각해볼 것
- 프로젝트의 크기를 줄이고, 보다 빨리 개발해서 실 사용자를 받았다면 더 좋지 않았을까?
- 1회성 프로젝트로 끝나지 않기 위해 무엇을 해야 할까?
6. 보완하고 싶은 것
- 자동배포 구현하기
- Spring security 사용해서 회원가입 및 로그인 구현해보기
- 이메일 인증 구현해보기
- 이메일 가입시 이메일 암호화하기
- 서버시간 - 디비시간 - EC2 배포시간 맞추기
- DB 설계 간단하고 명확하게 하기 (MySQL workbench로 설계할 것)
7. 결론 : 매일 공부하고 배우고 코드를 치자. 프로젝트는 함께 하지만 혼자 하는 것이다. 도전하고, 부딪히고 성장하자. 9-6 집중할 때는 집중하고 쉴때는 쉬자.
