들어가기 앞서
이번 7주차 클론코딩을 진행하면서 느낀 것들을 주차 회고로 기록을 남겨볼 생각이다.
주제는 내가 가장 신경 쓴 부분과 기술에 대한 정리로 진행할 것이다.
회고
내가 가장 신경 쓴 부분
security
Security(시큐리티라고 적겠음)를 맡아, 코드를 작성하게 됐는데 시큐리티는 어떻게 보면 완전히 이해하고 커스텀을 진행하는 방식으로 코드를 작성하다보니 어려움이 많았고 공부할 양도 많았다...
그래서 제일 먼저, 시큐리티 FilterChain에 대한 흐름을 이해하기 위해 시간을 많이 쏟았던 것 같다.
뭐.. 예를 들면, 시큐리티 필터체인을 빈으로 등록하면, 서블릿 필터체인의 프록시 필터가 인식해서 실행하게 해준다니.. 등등
또한, 로그인 인증 구조에 대한 흐름도 이해하려고 많이 노력했다. 사진으로 설명을 덧붙이자면,
위와 같은 구조로 작동된다. 요 녀석의 흐름 순서도 또한 아래와 같이 적으면서 이해했다.
- 요청
- 요청이 들어오면,
AuthenticationFilter가HttpServletRequest에서Intercept하게 된다. - 인증을 담당할
AuthenticationManager<<interface>>에게UsernamePasswordAuthenticationToken을 생성해서 위임하게 된다. - 실제로 인증할
AuthenticationProvider(s)에게Authentication객체를 전달한다. UserDetailsService에서 해당 Authentication 객체를 가지고, DB에 존재하는 User임을 알게된다면, UserDetails 라는 객체를 꺼내서 UserSession 을 생성하게 된다.- 이런 UserDetails를 SpringSecurity의 In-momery 저장 방식인 SecurityContext에 저장 후, UserSession ID 와 함께 응답을 보낸다.
- 이후 요청 쿠키에 Session ID 를 검증 후, 유효하다면 인증하게 된다.
이 외에도 공부했던 것이 많았다..
또한, config 설정 시 다양한 내장 메서드를 아래와 같이 만나볼 수 있었다.
antMatcher(): 경로를 뚫어줄 수 있다.antMatchers(): 여러 개를 담아줄 수 있음.authorizeRequets(): 로그인 인증 설정 → 해당 uri로 오면, 인증 설정하지 않겠다.anyRequest().permitAll(): 어떤 요청이 들어오든, 로그인을 허락하겠다.anyRequest().authenticated(): 어떤 요청이 들어오든, 무조건 인증하겠다.
등등..
CodeDeploy
사실 코드 디플로이를 내가 작성한 건 아니지만, 그 외에 서버 구축을 내가 했기 때문에 작성하게 됐다.
적은 이유는 코드 디플로이가 실행될 때마다, EC2가 터졌다. ssh로 접속되지 않는 문제가 계속 발생하는 것이였다. 알고 보니, EC2 용량이 작아서 그랬던 것이었다. AWS 과금에 대해 두려움으로 t2.micro 타입을 설정했었는데, 이는 CPU 용량이 약 100퍼에 도달하게 만드는 장본인이였던 것...
그래서 t3.medium 으로 바꾸면,,, 깔끔하게 해결할 수 있다! (AWS 결제대시보드는 욺..)
기술에 대한 정리
서비스 로직을 구현하는데 있어, Entity를 생성하는 방식에 대해 고민을 가져볼 수 있는 시간이 됐다. 반 사람들이 mapper 클래스를 사용해 dto 와 entity 를 변환해주는 방식을 사용했었는데, 왜 사용하는 지 개인적으로 이해가 되지 않았기 때문이다. (잘 모르기도 했고)
때문에 mapper는 사용해야만 하는 이유를 깨닫게 되고, 써야할 때가 온다면 그때 써볼 예정이다.
그래서 개인적으로 엔터티 생성 패턴을 공부해서 mapper 대신 실전 프로젝트에 적용해볼 생각이다.
예를 들어, Builder, 정적 팩토리 메서드 요녀석들은 공부해서 따로 포스팅해보는 것도 좋을 것 같다는 생각이 든다.
아쉬운 점
프로젝트 주차를 거듭하면서, 힘들다는 핑계로 TIL을 자꾸 작성하지 않는다. 새해도 밝았고 실전 프로젝트도 돌입했으니, 이제는 다시 항해 초~중반때 처럼 TIL을 작성하면서 일일회고를 잘 했으면 좋겠다는 생각이 든다.
