WIL - 8/28 ~ 9/3

👣 개요

이번주는 주특기[Spring] 2주차로서 2인 1조로 페어를 맺어 Spring 관련 과제를 수행하는 주간이었다.
주제는 Spring Security와 Spring Data JPA를 이용해서 블로그 웹 사이트의 API 서버를 만드는 것이었다.

구체적으로 말하자면
회원 가입, 로그인과 같은 인증, 인가 API를 설계하는 것과
게시글을 단일 조회, 일괄 조회, 생성, 수정, 삭제를 수행하는 API를 설계하는 것이다.

이전의 프로젝트들에서는 Spring Security를 이용하기만 했지 Spring Security의 이론적 배경과 라이브러리의 코드들을 자세하게 살펴본적은 없었다. 하지만 이번 주차에 체계적으로 이론들을 다지고 인증, 인가에 관한 코드들을 천천히 뜯어봤다.

그에 대한 결과들은 다음과 같다.

인증 관련 Architecture 분석

사실 이전까지는 도표를 보고 공부를 해도 왜 그림에서 이렇게 표현하는지 감이 잡히지 않았다.

특히나 AuthenticationProvider가 굳이 많아야 하는 이유를 알지 못했고 AuthenticationProvider를 선택하는 기준도 궁금했었다. 이러한 의문점을 직접 코드를 뜯어보면서 살펴보니 위 그림이 이렇게 그려질 수 밖에 없었다는 것을 깨달았다.

Spring Security 뿐만 아니라 Spring Data JPA도 더 깊게 공부하게 되는 계기가 되었다.
'자바 ORM 표준 JPA 프로그래밍'이라는 책을 읽으면서 이전에 모르고 사용했던
어노테이션들의 속성을 더 깊게 이해할 수 있었다.

예를 들어, 정말 부끄럽게도 @JoinColumn의 어노테이션을 단순히 연관관계를 매핑하기 위해 
사용하는 것 인줄 알았으나 알고 보니 FK에 해당하는 필드에 매핑한다라던지
프록시가 정확히 어떤 원리로 작동해서 로딩을 지연시킬 수 있었는지 등등을 깨달았다.

5장 연관관계 매핑 기초

8장 프록시와 연관관계 관리

 

이렇게 만족스러운 부분도 있었지만 아쉬운 점도 있었다.
협업 관련한 부분이 아쉬움이 많았다.

차라리 프론트엔드 개발자와 백엔드 개발자 사이의 협업이었다면 
명확하게 분업이 이뤄졌을테지만 백엔드 개발자 사이의 협업을 어찌 수행해야 하는지 감이 오지 않았다.

일전의 '웹 종합반 온보딩 프로젝트'에서 경험한 바에 의하면 우선 API 서버를 수행하기 위해 
작업들을 나열하고 각 작업의 의존성을 계산하고 의존성에 맞춰서 업무를 할당하는 과정을 거쳐야 했다.

즉, 이미 어떤 작업을 수행해야 하는지 계산이 되어야 할 정도를 가져야 한다.
그러기 위해선 목표를 명확히 하기 위한 API 명세서와 DB 스키마 명세서를 작성해야 한다.
그래야 코드를 작성할 때, 엔티티명칭, 필드명, 기술 스택 등등을 공유할 수 있기 때문이다.

하지만 실제론 그저 branch를 main, 팀원1, 팀원2 와 같이 3개로 나누고 각자 코드를 짤 수 밖에 없었다.
왜냐하면 서로 기술에 대한 이해가 깊지 못하니 미리 작업을 계산하지도 못하고 
기술이 어떤 방식으로 동작하는 지를 이해하지 못해 이렇게 작업을 나누지도 못했다.
그리고 API 명세서와 DB 스키마 명세서의 필요성을 알지만 이것을 팀원에게 설명할 만한 역량이 없었기에
필드명을 통일하지도 못하고 작업할 수 밖에 없었다.

이러한 부분이 너무 아쉬웠고 어떻게 해야 할지에 대해 고민해봤지만 그러한 고민들이 유효할지를 
알 수 없었다. 우선 이런 경험을 기반으로 다음 팀원에게 왜 그러한 작업들을 수행해야 하는지
설득시켜야 한다는 생각과 상대가 기술에 대한 이해도가 낮다면 이것을 이해할 때까지 설명하고
작업을 나누는 것이 우선이라 생각했다. 이러한 부분을 다음 협업 때, 이런 전략을 실험해보고 또
피드백을 해야 할 것이다.