본문 바로가기
그외에도

파이널 프로젝트를 마치며

by joeun 2022. 3. 22.

서비스 메인 화면

 

약 4주간의 팀프로젝트가 끝났다.
세미 프로젝트에 이어서 진행한 두 번째 팀프로젝트였다. 

 

프로젝트에서 백엔드를 담당하여

헬퍼 신청, 관리자쪽 헬퍼 승인, 리뷰 조회 API를 맡았다.

 


세미 프로젝트와 마찬가지로 스프링 부트를 사용하였기에 수월하게 진행될 거란 생각과 달리
MyBatis 대신 JPA를 사용하면서 초반에 조금 헤맸던 것 같다. 
사실 조금이 아니라 많이 헤맸지만...


책도 빌리고 강의도 결제해서 들었다.
그나마 강의를 듣고난 뒤에 감을 좀 잡았던 것 같다.

맡은 부분은 최대한 해보려고 노력했다. 

 


프로젝트의 기억이 희미해지기 전,

이번 프로젝트를 통해 깨달은 점과 얻은 점을 정리해보고자 한다.

 

 

 


 아쉬움을 통해 깨달은 점 

 


1. 필요한 기능이 무엇인지 따져보고 구현할 것 (우선순위 고려하기)


내가 맡았던 헬퍼 신청과 승인은 구현할 기능이 딱 정해져 있었다.
이후에 추가로 맡게된 리뷰 조회 부분을 구현할 때는 단건 조회와 함께 리뷰 리스트 조회 API까지 만들었었다. 개인적으로 리뷰를 한꺼번에 리스트로 조회하면 좋을 것 같다고 생각하기도 했고, JPA의 PAGE 처리를 통해서 리스트로 값을 받아오는 코드를 짜 보고 싶었다.


하지만 리뷰 리스트 조회 API는 실제로 서비스에 올라가지 못했다. 
프론트를 구현할 시간도 없었고 결정적으로 필수 기능도 아니었으며 매리트가 있는 기능도 아니었기 때문이다.

리뷰는 단건 조회 API면 충분했다. 

 

백엔드 프론트엔드 연동 전, 팀 회의를 하면서 다른 팀원이 맡았던 부분 중에 다 구현되지 못한 부분이 있다는 것을 알게 되었다. 일단 필수 기능을 빨리 구현하고 팀원들에게 도울 부분이 있는지 물어봤다면... 하는 아쉬움이 남는다. 

 

기능을 구현하면서 우선순위를 세우고, 개인적으로 생각하는 필요 기능이 아니라 요구사항과 계획단계에서 정해진 기능을 우선적으로 해야 함을 다시금 깨달은 시간이었다. 

 


2. 다양한 경우의 수(예외)를 생각하자


헬퍼 신청 시에 스프링 시큐리티의 Authentication에서 Id 값을 받아오기 때문에 신청하는 사람의 아이디는 당연히 그 사람의 것이라고 생각했는데 앞으로는 다양한 경우의 수를 생각하는 것이 좋을 것 같다.

팀원이 이것과 관련해서 예외처리가 되었냐고 물어봤을 때 '아, 그런 예외가 있을 수도 있겠구나'하고 처음으로 생각해보았다... 물론 다른 Id를 받아오는 테스트 케이스는 없었지만 Id는 개인정보와 관련된 중요한 부분이니 본인 확인과 같이 보안과 관련된 부분은 신경 써서 다양한 경우의 예외를 생각해 볼 것...! 


돌아보면 일단 값이 나오는데에만 집중하고 기본적인 예외 처리만 한 것 같아 아쉽다. 

 


3. 모르면 물어보자


다른 팀원들도 바쁘게 작업을 하고 있기 때문에 질문을 하는 것이 좀 미안했다.
특히 온라인으로 소통하다보니 현재 팀원이 무엇을 하고 있는지 많이 바쁜지 파악이 안 됐다.
그래서 괜히 방해하는 것 같아 질문하는 걸 아끼고 아끼며 혼자서 해보려고 했었다.
하지만 질문을 하니 길이 금방 보였다. 팀원이 방법을 알 수도 모를 수도 있지만 적어도 방법을 찾으려는 머리가 둘 이상이 된다. 모르면 물어볼 것. 


특히 신분증 사진과 관련한 멀티파트 처리는 물어보지 않고 혼자 했다면 비효율적으로 구현해놨을 것이다. 
나는 DB에 저장하는 걸 생각했는데 혹시나 하는 마음에 팀원에게 물어봤더니 멀티파트로 처리하는 게 빠르다고 했다.

이전에 구현한 코드까지 공유해주며 알려주셔서 훨씬 효율적인 방법으로 잘 처리할 수 있었다. 

 


4. 소통하자


위와 비슷한 맥락이지만 3번이 기술적인 부분이라면 여긴 소통에 관한 이야기다. 


간단한 메인 페이지 프로토타입만 나온 상태에서 작업을 하다보니 프론트 단에서 필요한 데이터가 아직 명확하지 않아서 일단 내가 필요하다고 생각하는 대로 했다가 이후에 수정하는 일이 몇 번 있었다. 
헬퍼 신청 시에 핀테크 번호, 주소와 신분증 사진만 필요한데 이름과 다른 개인 정보를 더 받아온다던지.  
리뷰 조회시에 평점과 리뷰 내용만 필요한데 작성 일시부터 상대방 아이디까지 여러 정보를 더 보낸다던지.

  
프론트 쪽에서 아직 프로토타입은 없어도 생각한 부분이 있었을 텐데 물어보고 하지 않았던 게 조금 아쉽다. 

 



5. 자주 Commit & Push 하자


작업 초반에는 아직 기능이 완전히 구현되지 않으면 커밋 자체를 안 했었는데 팀장님이 그러면 서로 뭘 작업하는지 파악도 안 되고 진행상황을 알 수 없으니 완전히 구현이 되지 않았더라도 중간중간 푸시를 하라고 했다. 아직 깃이 어색해서 사실 그 이후에도 자주 커밋을 하진 않았는데 이후에 팀원과 겹치는 부분을 작업하는 일이 있었다. (핀테크 번호 받아오기)


거의 같은 기능이라 한 쪽이 작성한 코드를 재활용하면 되었을 텐데 서로 어디를 작업하는지 공유가 안된 상태라 일어난 일이었다. 그 이후로는 완전한 기능이 아니라 수정한 단위로 커밋과 푸시를 했다. 

 

꼭 공유만을 위해서가 아니더라도 본인의 소스를 기록하고 관리할 수 있는 것이니 Commit과 Push는 습관화하자.

 

 

 


 그럼에도 얻은 것 

 


1. 분업과 협업 with Git


일단 Git, GitLab와 함께 GUI Client로 fork를 사용한 것이 가장 큰 자산으로 남을 듯하다. 
이전 세미 프로젝트에서는 정말 놀랍게도 수작업으로 코드를 합쳤었다. 코드 합치는 것만 해도 시간이 꽤 걸리고 서로 뭘 작업하는지 파악이 안 됐는데 이번 프로젝트를 하면서 깃으로 형상관리와 협업하는 법을 알 수 있었다. 

 

아직 한쪽에서 구현이 마무리가 안되었어도 구현되어있다고 치고 계속 작업을 할 수 있는 게 개발의 매력인 것 같다. 

 



2. 팀의 코드를 확인하고 익히는 법 


작업에 들어가기에 앞서 팀장님이 이전에 진행한 프로젝트 코드를 공유해주셨다. 
팀장님도 이전에 했던 코드를 많이 재활용하고 참고하다보니 나 역시도 해당 코드를 많이 참고하였다.  
특히 예외 처리나 스프링 시큐리티는 이전 작업물에서 많이 참고를 했다.

참고하기 위해서는 어떤 흐름으로 코드가 작성된 것인지 분석하고 파악해야 했다. 

 

또, 기존에 람다와 스트림은 이론으로만 접해보고 사용해본적이 없었는데 팀원 코드에 등장한 것을 보고

나도 코드에 적용시키며 람다와 스트림에 대해 공부하는 시간을 가질 수 있었다.


뿐만 아니라 다른 팀원들이 패키지 구조는 어떻게 설정했는지,  
API 주소는 어떻게 매핑하고 있는지 (ex. /api/user) 등을 살피고 나의 코드에서 적용시키며 협업하는 법을 배웠다.

 


 
3. REST API


이전 프로젝트에서는 JSP를 사용하여 작업했기 때문에 프론트 단과 백엔드 단이 분리되지 않았다. 또, 팀원별로 각자 맡은 기능의 백과 프론트를 모두 담당하는 식으로 작업을 했기 때문에 담당 API에서는 내가 보내는 데이터를 통제하고 직접 프론트 단에서 확인까지 할 수 있었다. Ajax로는 검색기능 정도만 간단히 구현했었기 때문에 굳이 @RestController를 사용하지 않고 @ResponseBody로만 처리 했었다. 그런데 이번에는 프론트가 리액트로 진행되어 분리되다 보니@RestController를 처음으로 사용해 보았다. 


Postman을 사용하여 어떤 데이터가 전송되는지 살펴보아야 했고, 기능 명세서를 작성하여 해당 URI에 어떤 파라미터가 필요하고 어떤 데이터가 전송되는지 명시하여 분리된 프론트와 협업 작업을 해볼 수 있었다. 

 

또, 프로젝트를 진행하며 김영한 님의 TCP/IP 강의를 복습했는데 진행 중인 프로젝트와 연결하며 들으니 눈에 들어오는 내용이 더 많아졌다. 강의 내용을 참고하여 최대한 리소스 위주로 URI를 설계해보려고 했고, 역시나 리소스로만 설계하는 것은 어려운 것을 실감했다. 명사로 구현이 어려운 URI는 동사를 이용한 '컨트롤 URI'로 설계해보며 그냥이 아닌 이유 있는 URI를 설계해보는 경험을 했다.     

 

 


4. Test 작성


세미 프로젝트 때는 테스트 코드를 짜보지 못했는데 이번 프로젝트에서는 JUnit4를 이용하여 테스트를 돌려봤다. 

다양한 케이스로 돌려보지는 못했지만 앞으로 어떻게 테스트 코드를 잘 짤 수 있는지 더 알아봐야겠다. 

 

 

 


 앞으로의 계획 (수정 중) 

 

1. 스프링 공부 

스프링의 정석으로 진행 중 

 

 

2. 개인 프로젝트 진행 

현재 기획 단계 

 

 

3. 포트폴리오 정리 

노션으로 정리 중