9/1

👣 개요

오늘 오전엔 Lv 2 과제를 끝마치기 위해 팀원과 코드 병합을 진행하고
4시까지 API 명세서, 각종 문서화를 진행했다. 
그리고 그 이후에는 부족한 Spring Security 관련 공부를 진행했다.

 

👣 Lv 2 코드 병합

Lv 2부터 본격적으로 팀을 이뤄서 과제를 수행하는 활동을 진행했다.
본격적인 항해 99과정을 진행하기 전에 웹 종합반에서 협업을 경험하긴 했으나 
이번 협업도 너무 서툴렀다.

아무래도 기술 파악이 확실히 되지 않은 채로 계획을 짜니 
빗나가는 것도 많고 놓치는 부분이 많았다.
아직 API 명세서와 DB 스키마 명세서를 구체적으로 적어야 하는 이유에 대해 
공감할 수 있는 단계가 아니다보니 작업을 할당하는 것이 불가능했다.

작업을 잘게 쪼개기 위해선 위와 같은 규칙을 세심하게 정해야 하는데
그렇지 못한 것이 너무 아쉬웠다.

할 수만 있다면 팀원에게 API 명세서와 DB 스키마 명세서의 중요성을 
알려줄 수 있으면 좋겠지만 나의 실력이 미치지 못해서 할 수 없었다.

심지어 사용해야 하는 기술 스택에 대해서 구체화를 시키지도 못했다.
인증 인가에서 Spring Security를 적용하고 싶어도 해당 기술에 대한 
이해도가 낮아 그것에 대한 정당성을 주장하기 어려웠다.

결국엔 Spring Security를 사용하긴 했지만 기술 도입에 대한 당위성도
강의에 사용되었고 그것으로 코드를 구성한 레퍼런스가 있기 때문이라는 것이어서
사실상 기술의 이점을 보고 기술을 선택한 것이 아니었다.

아쉬움이 가득한 협업이었다.
결국 코드 병합도 서로의 장점을 취하며 수행한 것이 아니라
한 사람의 코드를 줄기삼고 버그를 교정하는 방식으로 이뤄졌다.

다음 협업에서는 줄기가 되는 코드를 같이 정한 다음에 분업을 해나가는 방법을 적용해보고자 한다.
그러기 위해선 서로가 명세서의 중요성에 대한 이해가 선행되어야 하고
기술에 대한 이야기를 깊게 해야 한다고 생각한다.

물론 이런 다짐만으론 다음 협업이 성숙해질 것이라곤 생각하진 않는다.
하루 빨리 이런 대책에 대해 강구해야 할 것이다.

 

👣 Spring Security 공부

협업이 마냥 아쉬웠던 것은 아니다.
나는 Login 기능을 구현할 때, Filter를 사용하지 않고 다른 API와 같이 Service Layer에서 진행했다.
하지만 팀원분께서는 Filter로 인증과 인가를 모두 구현하고 사용했다.

나의 생각에 로그인은 하나의 API를 위해서 존재하는 것인데 굳이 모든 Controller 앞에서
진행할 필요가 있냐는 생각에 의해 Service에서 구현했던 것이다.
때문에 Filter에서 로그인을 구현할 생각을 하지 않았다.

하지만 팀원분의 코드를 보니 Spring Security를 이용해서 기능을 구현하니 생각보다 
빠르게 코드를 작성할 수 있었고 더 강건한 코드를 만들 수 있었다.

Service에서 구현을 진행하면 인증 가능성 판단부, SecurityContextHolder에 Principal 부여 부분,
인증 오류 처리 부분 등등을 하나의 클래스에서 처리하게 된다.

하지만 Spring Security는 이 모든 부분을 추상화해 쉽게 커스터마이징할 수 있게 구성했다.
이런 부분에서 있어 Filter에서 로그인을 진행하는 것도 합리적이란 생각을 하게 되었다.

이러 공부를 진행하며 작성한 게시물은 아래와 같다.

인증 관련 Architecture 분석