Day 7
점심에 멘토링 선생님과의 시간을 보내면서 스트레스 받는 상황을 이야기 나누며 해결책을 모색해보고, 백엔드 로드맵을 보며 앞으로 나가야할 방향을 짚어보며 동기부여를 받았다.
현재 시큐리티에서 어려움을 느끼고 있는데 멘토님은 시큐리티를 어떻게 공부하셨는지 여쭈었더니 백기선선생님의 인프런 시큐리티 강의를 추천해주셔서 바로 결제했고, 2일만에 8시간강의를 다 들었다. 시큐리티의 흐름에 관해서 전반적으로 알고있었는데 강의에서는 필터들을 디버거로 동작과정을 살펴보며 더 자세히 흐름을 파악할 수 있게 도움을 주었고, 디버거를 활용하며 공부하는 방법을 조금 익힐 수 있었다.
Day 8
시큐리티를 적용시키고나서 로그인하면 토큰값은 잘 받아오지만, 로그인 후 거래내역을 다룰때 토큰값을 잘 넣어도 409 Conflict 에러가 나오는 상황이 3일째 지속되고 있어서 다른 결과를 테스트할 수가 없어서 속이 타는 기분이였는데 스터디원이 일요일인데도 시간을 내주어서 같이 오류핸들링을 해주었다.
디버거를 해보니 requestContextFilter에서 Invocation Target Exception이 발생하고있었다. Bearer로 시작하는 Authorization 토큰값을 헤더에 넣어도 null로 받아와져서, 컨트롤러에 principal객체가 아닌 @RequestHeader("Authorization") String tokenHeader로 받아와서 서비스에서 memberId를 구하는 방식으로 변경하였고, 레디스도 재설치하니 임시방편으로 값을 추가할 수 있게 되었다. 하지만 기쁨도 잠시 get요청에는 409에러가 여전히 나오고 있다.
컨트롤러에서 어썰티케이션 헤더값에서 memberId를 구하지않고 인터셉터에서 처리하고 쓰레드로컬에 저장하게끔 리펙토링이 필요한 상황이 되었고, 블로그 검색으로 HandlerInterceptor를 구현했지만 제대로 동작하지 않았다. 쓰레드 로컬이 뭔지 안다고해서 바로 잘 쓸 수 있는건 아니지만 힌트를 알고 있으니까 조금씩 앞으로 나아가면 된다. 문제를 해결하면서 잘해지는거니까 프로젝트진행속도가 느려서 걱정되는 마음을 내려놓고 오류에 집중해보자로 마음먹었다.
나는 언제쯤 오류를 빠른시간내에 척척 해결할 수 있는 실력이 될까. 더 성장하고 싶다.
Day 9
아침 6시부터 오류생각에 눈이 번쩍 떠진 월요일이였다.
일어나서부터 잠들때까지 하루종일 오류해결에 온 정신이 빠져있어서 시간감각도 무뎌질 정도인데
공들인 시간에 비해 제자리걸음처럼 보여서 프론트엔드팀원들에게 미안한 마음이 크다.
빨리 API를 사용하여 작업할 수 있게 해주고 싶다.
에러메세지를 더 잘 볼 수 있게 "--stacktrace" 도 추가하고 yml에 로깅을 추가했다.
logging:
file:
name: logs/logging.log
level:
root: DEBUG
spring:
root: DEBUG
com:
server:
auth: DEBUG그래도 오류가 보이질 않아서 예외처리 메소드를 찾아보다가 ExceptionHandler에서 409에러를 캐치하는 코드를 발견하여 log.error("# handle Exception: {}", e);를 추가하여 로그를 분석해보니 원인이 순환참조라는 사실을 알아냈다.
회원이 거래를 참조하고, 거래가 회원을 참조하여 무한의 데이터가 만들어지고, 이를 가공하려다보니 409에러가 뜨는 것이였다. 그래서 양방향매핑을 끊어내고 단방향매핑으로 바꿔보았지만 쉽게 고쳐지지않아서 매핑을 끊고 회원id를 필드로 가지고있게끔 수정해서 해결했다.
jpa를 사용하면 편리하지만 n+1이나 순환참조와 같은 에러를 마주칠 수 있다는 사실을 다시 배웠고, 앞으로는 설계를 할때 이런부분을 미리 고려해야겠다.
