[Project] pre-project 회고

pre-project를 하기 전

프로젝트를 시작하기 전에는 어느 정도의 설렘과, 지금까지 배웠던 기능들을 구현한다는 생각에 설렘을 가지고 있었다. 그리고 프론트엔드 동기들과 협업을 한다는 것도 설렘으로 다가왔다. 그리고 또 한편으로는 두려움도 있었다. 제대로 프로젝트를 수행하지 못한다면 어쩌지, 같이 팀원이 된 동기들과의 갈등이 있으면 어떡하지라는 막연한 두려움을 가지고 있었다. 또한 스스로 기술적으로도 부족한 부분이 많아, 공부가 필요한 걸 알았지만 그러한 시간적 여유가 없이 pre-project를 시작하게되었다.

팀원들과 만남

처음 팀원과 만남은 솔직히 어색했다. 그리고 경계 반, 설렘 반으로 팀원들을 대하고 있었다. 팀 안에서 팀장을 세우고 팀 규칙을 세운 후, 프로젝트를 진행하기 전 클론 프로젝트를 할 스택오버플로우를 조사하며 요구사항 분석을 시작했다.

pre-project 주제

pre-project의 주제는 stackoverflow의 홈페이지를 클론 코딩을 하는 것이였다. 처음 팀원이 모여서 요구사항을 분석했다. 간단하게 기능을 분류하고 요구사항 정의서를 작성했다. 지금에 와서 생각해보면 말도 안되는 요구사항정의서였다. 그걸 보고 홈페이지를 제작한다면 100명이 같은 주제로 개발을 할 때, 1개의 웹이 아닌 100개의 다른 웹이 나올 것이다. 음, 아예 못 만들 수도 있을 것이다. 그러한 요구사항 정의서를 작성을 한 후, 우리는 바로 개발을 하기 위해 프론트엔드와 백엔드끼리 나뉘어 회의를 시작했다.

백엔드 회의

원래 같이 하던 스터디원과 친분이 있는 분이었다. 개발에 관해서 성향이 너무 잘 맞았다. 그래서 더 의지가 생겼다. 새로운 기술들을 적용을 해보자는 생각을 했었고, 개발을 하면서 서로 더 발전을 할 수 있는 분을 만나서 기분이 좋았다. 물론 지금도 그 생각은 변함이 없다. 기능에 대한 회의를 하면서 어느 것까지 적용을 할 것인지, 버전은 어느 것으로, 서버는 어떻게 배포를 할 것인가 이야기를 했고, 초기 환경 설정에 대한 이야기를 마무리 했다. 물론 여기서 간과했던, 아니 이때는 아직 알지 못했던 사실이 있었다. 우리가 그 기능을 배우는 것과 구현하는 것에는 굉장한 차이가 있다는 것, 그리고 프론트와 합치는 과정에서의 오류들을 생각하지 못했다는 것 이 두 가지가 마지막에 우리의 발목을 잡게 되었다.

개발 과정(error handling)

처음에 요구사항 정의서를 토대로 개발을 하려고 했지만, 처음에 정의서를 제작할 때, 너무 놓친 부분이 많았다. 기능적인 부분 뿐만 아니라 비기능 적인 부분도 너무 많이 놓치고 있었다. 그래서 요구사항 정의서 보다는 계속 stackoverflow 페이지를 보며 참고하면서 개발을 진행했었다. 모든 기능을 구현하기에는 프론트엔드도 백엔드도 시간이 부족하였고, 시간이 남으면 기능을 하나씩 추가하는 것으로 했다. 여기서의 문제점은 pre-project를 하면서 일정 조율이 없었다는 점이다. 일정을 서로 맞춰가면서 어느정도 개발이 진행되었는지 확인을 할 수 있어야했는데 채팅으로 한번씩 물어보는 것 밖에 하지 못했다. 그래서 어쩔 때는 일정이 굉장히 루즈해지기도 했고, 마지막에는 하는 과정이 촉박해져서 며칠 밤을 지새기도 했다. 이 부분은 정말 잘못했다고 생각한다. 반드시 고쳐야 할 부분이고, 서로 소통하는데 큰 개선을 이루어줄 것이라 생각한다.

 

기능별로 개발을 시작할 때, 나는 회원 부분, 그리고 태그 부분을 맡았다. 이 부분을 시작하면서 처음 막혔던 부분은 태그의 매핑에서 문제가 생겼다. 태그는 N:N의 관계를 형성하게 되는데, mapstruct를 사용하여 mapping을 진행했다. 회원과 태그는 N:N 관계를 가졌고 중간테이블을 만들어 1:N, N:1의 관계로 바꾸어 주고 N:N관계를 없앴다. 하지만 내가 mapstruct를 사용했을 때는 중간 테이블이 없는 1:N,N:1 관계여서 자연스럽게 mapping이 되었는데, 중간 테이블이 있어 2번의 mapping이 진행되어야 해서 원래 사용하던 방법으로는 mapstruct를 사용할 수 없었다. 그래서 다시 mapstruct 공부를 시작했다. 그래서 공부를 하면서 두 가지 선택지를 찾아냈다. 첫 번째는 default 메소드를 만들어 mapping을 진행하는 것, 두 번째는 추가적인 메소드와 dto를 생성하여 2번 mapping을 진행하게 하는 것이였다. 그래서 우선은 첫 번째 방법을 사용하기로 결정을하고 default 메소드를 사용하여 직접 mapping을 진행했고 성공적으로 N:N 관계에 대해서 mapping을 할 수 있었다. 물론 mapstruct를 제대로 사용했다고 생각할 수는 없었다. 그래서 다음에 main-project때는 default메소드를 만들지 않고 진행하는 두 번째 방법을 이용해야겠다는 생각을 하게 되었다.

 

 그리고 두 번째로 막혔던 부분은 프론트 단과 요청 응답 과정에서 문제가 생겼다. cors에러가 생겼다. 처음 통신을 하는데 생긴 문제라 구글링을 바로 시작했다. 결국에는 백엔드 쪽에서 요청에 대한 허락이 필요했다. 또 한가지 방법으로는 같은 로컬에서 프론트 단 proxy를 하는 방법이었지만, 백엔드 서버에서 허락하는 방식으로 처리를 했다. 컨트롤러마다 CrossOrigin설정을 해주었고 cors에러를 해결할 수 있었다. 이 부분은 나중에 Spring Security를 넣으면서 Security config로 통합 설정을 하는 방법으로 바꾸어주었다.

 

 그리고 세 번째는 Security 적용 시 발생하는 문제점들을 처리하는 과정이었다. JWT를 사용하여 토큰 로그인을 구현을 하기 위해 Security를 사용하기로 결정했다. 처음에 아직 User에 대한 권한 설정을 하기 전이라 getAuthorities를 사용하지 않고 UsernamePasswordAuthenticationToken을 생성하면서 오류가 발생했다. 제대로 Authentication이 생성이 되어서 authenticated로 설정된 mapping 주소에 접근이 가능할거라 생각을 했지만, 되지 않았던 것이다. 이유는 UsernamePasswordAuthenticationToken에 getAuthorities를 사용하지 않고 생성자로 생성을 하게되면 authenticated의 값이 false로 들어가 인증되지 않은 상태로 토큰이 생성이 되기 때문이었다. 이거 때문에... AuthenticationEntrypoint와 AccessDeniedHandler를 재정의하여 접근을 하게 해줬는데, 결국에는 getAuthorities 즉, Role만 제대로 설정을 해주면 될 문제였는데 너무 돌아왔다는 생각이 들었다.

그리고 원래 Security 전에는 로그인을 하게 되면 ResponseBody에 유저에 대한 정보를 넘겨줬었는지 filter에서 처리가 되어 Controller로 접근이 되지 않아 ResponseBody를 줄 수 없었다. 마지막 구현까지 ResponseBody를 통하여 정보를 줄 수 없었는데, 방법은 찾았지만 그냥 jwt에 정보를 추가해서 전달하는 것으로 마무리 하였다. 다음 main-project 때는 ResponseBody에 유저의 정보를 줄 수 있도록 해봐야겠다.

 

팀원들과의 협업

 팀원들과의 협업과정은 소통은 아주 원활하게 이루어졌다. 우선은 문제가 있을 시, 지속적으로 공유하도록 했는데 개발하는 과정에 있어서 빠른 피드백을 들을 수 있어서 좋았다. 그리고 한 분도 포기하거나 너무 제한을 두는 사람이 없고 구현하는 것에 긍정적으로 생각하는 분들이여서 더욱 적극적으로 프로젝트에 임할 수 있었다. 각자 필요한 부분을 찾아 공부하고 문제가 생길 시 도움을 받아 함께 빠르게 처리할 수 있어서 좋았다. 

 아쉬웠던 점은 처음에 요구사항 정의서로부터 시작된 거 같다. 정의서가 제대로 작성되지 않았어서, 어떤 기능을 만들고 있는지 물어보지 않고서는 알 수 없었다. 그리고 언제까지 이 기능을 만들거라는 일정이 없었다 보니, 한 쪽이 빠르게 완성을 하면 다른 한 쪽은 기다리고 그 다음 구현을 테스트 할 수 없을 때가 종종 있었다.

 

Main-project에 들어가기 앞서

 우선은 pre-project를 통하여 팀 그리고 나에 대하여 개선할 점을 적고 main-project 때는 개선 사항을 이루는 것을 목표로 해야겠다.

 

 1) 일정 관리 - 각 기능개발이나 문서 작성에 deadline(due date)를 설정하여 서로의 일정을 공유하여 실시간으로 파악할 수 있어야 할 것 같다.

 2) 문서 작성 - 여러가지 문서를 작성하게 되겠지만, 첫 단추를 잘 끼워야 겠다고 생각이 든다. 설계 단계에서 요구사항 정의서를 자세하게 작성할 것, 그리고 수정사항이 있을 시 요구사항 정의서도 수정하면서 개발을 진행할 것, 이것이 이루어져야 개발을 잘 진행할 수 있을 것 같다. 그리고 디테일하게 작성하는 것도 필요하지만 사람들이 보기 좋도록 문서를 만드는 것도 필요하다고 생각이 든다. 현재 우리가 작성하고 있는 문서의 form은 한 눈에 보기 어렵고 적은 정보만을 적도록 만들어져 있다. 그래서 문서 자체를 바꿀 필요성을 느낀다.

 3) TDD - 개발을 진행할 때, 테스트 코드를 꼭 작성하자. 현재 Controller 테스트만 진행을 했었고, QueryTest, ServiceTest는 진행하지 못했다. 테스트도 진행하지 않고 개발을 하는 건 너무 많은 오류를 직면하게 되는 것 같다. Test코드를 작성하고 하나의 Test마다 성공 실패 사항을 문서로 작성할 필요를 느낀다.

 4) 서버, 배포, 배포 자동화 - 개발을 시작하기에 앞서 어떤 서버들이 필요한지 조사를 먼저 해야할 것 같다. 요구사항에 맞는 서버를 사용해야하고 배포단계에서 문제가 없어야 하기 때문이다. 그리고 처음부터 배포를 실시하여 dev브런치에 배포 자동화를 설정하고 중간테스트를 계속 거치는 과정이 필요할 것 같다.

 5) 새로운 기능 - 요구사항에 필요한 기능들을 먼저 공부해야 한다. 지금 추석이라는 아주 좋은 시기가 있다. 이 때 부족한 부분을 채우고 아직 공부하지 못한 부분들 그리고 다시 공부해야 할 부분들을 공부하는 시간으로 가져야겠다.

 

마지막으로

 포기하지 말고, 게을러지지 말고, 목표를 흐리지 말자