팀플을 마무리! 기본적으로 우리가 처음 기획했던 기능들은 모두 완료했다. 추가로 기능이 구현 된 것은 3개다.
[백오피스]
1. 건우님이 구현하신 백오피스. 관리자 권한을 갖는 user는 막강한 권력을 휘두룰 수 있도록 했다. 게시글 수정/삭제 등 인증 정보가 필요한 api 요청을 할 수 있도록 구현이 됐다. 여기서 좀 더 디벨롭을 할 수 있다면 api 요청을 /api/admin으로 하면 더 예쁜 그림이 나올 것 같긴한데 아직 그부분까지는 다듬지는 못했다.
[동적 쿼리]
2. 성훈님이 구현하신 쿼리/파람을 이용해 동적 쿼리 생성
솔직히 말해서 이거 그냥 툭 던진 거였다.. 이거 안어려울 줄 알았으니까!!! 동적 쿼리를 던지는게 생각보다 너무 어려웠다. 우리의 프로젝트는 mbti별 게시판 조회를 기획했다. i가 작성한 게시판, p가 작성한 게시판과 같이. 시작은 이 쿼리를 날리기 위해 쿼리/파람을 이용하자!였다. 그렇게 디벨롭이 되다가 어 그렇다면 i*t*가 작성한 게시물을 모두 보는 방법은?
i*tp가 작성한 게시물을 모두 보는 방법은?? 을 까지 나갔다.
내 생각에는 우리가 db에 직접 쿼리를 날릴 때 where mbti=i*tp 하면 되듯이 간단할 줄 알았다. 근데 그게 아니었다. 이것을 스프링에서 구현하기 위해선? dsl을 사용해야했다. 아직 디테일한 설명은 듣지 못했지만, dsl을 이용해 커스텀 해서 쿼리를 작성할 수 있게 된다. 아무튼 이를 통해 위의 게시물 조회를 구현했다.(사실 아직 고쳐야 할 것이 있다. && 조건을 걸어줘야 더 정확한 조회를 할 듯)
성훈님이 이것 때문에 정말 고생을 많이하셨는데 다행히 잘 구현이 됐다.
[리프래쉬 토큰과 레디스 환경]
내가 인증/인가 파트를 맡았기에 리프래쉬 토큰과 레디스 환경을 추가 구현중이다. 어제 밤에 이슈를 확인했고, 오늘 하루종일 구현을 했지만 제대로 작동하지 않는다. 아니 레디스 연결부터 안된다... 대충 기능은 구현을 했는데 레디스가 연결이 안되니 테스트를 할 수가 없다. 임베디드 레디스를 사용하고 싶었는데 공식 문서를 봐도 연결이 잘 되지 않기에 어려움이 있다. 이번 주말을 빌려 레디스 환경을 이용하는 공부를 해봐야겠다.
오늘은 이준호 튜터님과 면담을 했다. 저번에도 정말 좋은 얘기를 나눴던 튜터님이기에 꽤 기대를 하고 갔다. 첫 대화 주제는 이번 팀프로젝트에서 뭘 맡았고 지금 진행상황에 대해 얘기를 나눴다.
[로그아웃을 백앤드에서 구현해야할까?]
어제 나는 트레이드 오프로서 레디스 환경을 구축하고, jwt 값을 서버에 저장하는 것이 주는 이득이 무상태성을 깨는 불이익보다 크다고 생각해서 레디스 환경을 구축해서 사용하고자 했다. 그런데 나는 진짜 아무것도 몰랐다. 기본적으로 로그아웃은 프론트에서 헤더값을 지우거나? 쿠키값을 삭제 해주면 되는 거였다. 어제의 쟁점은 백앤드 서버에서는 더이상 발급한 토큰에 대한 통제권이 없다. 인데 그 통제권은 프론트 앤드에서는 정말 가볍게 처리할 수 있다는 것!이렇게 간단한 로그아웃 방법이 있다면 백앤드는 사실 로그아웃을 구현할 필요가 없어진다. 백엔드에서 로그아웃을 처리하려면 서버에 인증토큰을 저장해야 하고, 요청이 올 때마다 서버에 쿼리를 날려야 하는 등 서버에 부하가 더 생긴다. 근데 이걸 굳이 감안하면서 만들필요는? 없다.
그렇다면 레디스 환경을 통해 리프래쉬 토큰을 발급하는건 별로일까?
[레디스 환경을 조성해 refresh 토큰을 발급하는 것은 나쁘진 않다]
바로 보안. 어제도 말했듯 토큰이 탈취 됐을 때를 대비 하기 위해 리프레쉬 토큰을 사용하는것은 좋다. Access 토큰의 만료기한을 짧게 주고? Refresh 토큰의 만료기한을 길게 주면? Refresh 토큰에는 인증 정보를 갖고 있지 않기 때문에 해커는 인증 정보를 사용할수 없게 된다. 하지만 여기서 내가 가졌던 의문이다. 리프레쉬 토큰에는 사용자 정보가 없는데 그럼 이 리픠레쉬 토큰을 갖는 유저는 해커인지 실제 유저인지는 어떻게 판단하느냐? 이다. 튜터님도 같은 설명을 해주셨고 이를 보안하기 위해서는 정말 많은 로직이 들어가야 한다고 하셨다. 예를들어 네이버에서 중국에서 로그인 됐는데 맞냐?, 구글에서 새로운 기기로 로그인 인증이 왔ㄴ느데 너 맞어? 하는것처럼 백앤드단에서 할 수 없는 새로운 요청들이 더 있어야 된다. 그런데 뭐 내가봤을때 그래도 리프래쉬 토큰을 사용하는것은 그래도 보안강화를 하는것이 확실하다고 생각한다. 코드의 복잡도가 상승하기 때문에 무조건 이득이라고는 생각하진 않지만.
[레디스를 활용하는 건 학습에 좋다]
레디스는 NoSql으로서 메모리를 이용한 서버기 때문에 빠르고 가벼운 특징을 갖는다. 따라서 자주 데이터가 바뀌어야 하고, 요청/응답이 빈번해서 빠른 속도를 필요로 하는 서비스에 이용된다고 한다. 예를 들어 장바구니를 담는 DB를 레디스로 넣는다던지? 사용자의 검색 기록을 레디스로 저장한다던지! 따라서 레디스 환경을 공부하는것은 학습에 무조건 좋다는 말씀을 하셨다. 시작은 엉뚱한 시작을 했지만? 결과적으로는 내게 도움이 되는 방향이 된 것 같다. 주말간에 레디스 환경에 대해서 공부를 많이 해보자.
[테스트 코드의 의미]
스프링 mvc에서 슬라이스 테스트 코드를 작성할 때 들었던 의문들이 있다. 이번 마치 오픈북도 아니다. 정답을 적어놓고 문제를 푼다고 생각이 들었다. 이런 인식이 든 이유는 바로 Mock때문. Mock 객체는 내가 어떤 값을 가질지 가정을 하고 사용한다. 이게 무슨 의민가? 싶은 생각이 들었고, 이걸 작성하는 것은 오히려 시간만 잡아먹을 것이라고 생각했다. 두번째는 컨트롤러 레이어를 테스트 할 때의 의문이다. 컨트롤러를 테스트 할 때의 핵심은 (내생각에) 인증이 잘 작동하는지?(필터단에서 바로 다음으로 넘어가는 파트가 mvc에서는 컨트롤러이기 때문) 클라이언트로부터 요청이 유효한지?인데 이건 슬라이스 테스트를 하면.... 의미가 없잖아? 서비스단의 반환값이 적절한지는 컨트롤 레이어 테스트에 작성할 것은 아니다. 그런데 튜터님이 정말 가려운 곳을 잘 긁어줬다.
1. 우리(로컬 호스트에서만 서비스를 진행하고, 서버를 한대만 운용하는)는 사실 테스트 코드가 크게 의미가 없다는 것. 위에서 말한 Mock객체를 보자. 우리는 서버를 한개만 운용하기에 내가 모든 로직을 다 파악하고 다 알 수 있다. 하지만 서버와 서버간의 통신에서는? 우리 서비스가 카카오톡의 서버와 통신을 하면 우리는 카카오톡의 서비스의 응답값을 가정할 수 밖에 없다! 이게 바로 Mock의 역할이다. 우리는 그동안 service단을 테스트 할 때 Repository를 Mock객체로 만들었다. 이때 이 둘의 연관관계를 끊고 테스트 하는 개념이 어려웠는데, 저렇게 다른 서버와 통신을 할때의 테스트 환경에서 Mock을 만들어서 테스트 하는 것은 너무 와닿았다. 카카오톡에서 오는 응답은 가정하지 않고서는 테스트를 할 수가 없기 때문!
2. 테스트 코드를 작성을 해놓으면 어느 파트에서 문제가 생겼는지 확실히 알 수 있다. 위에서 말했듯 서버간의 통신에서의 테스트 코드를 작성해두면 우리 서버가 아닌 다른 서버에서 오류가 생겼을 때 대응 할 수 있다. 왜냐하면 테스트 코드에선 상대 코드가 정상 작동한다고 가정하고 테스트를 하기 때문에 우리 코드는 정상 작동한다는 것을 알 수 있다.
만약 이 테스트 코드가 없다면 우리 코드와 상대 코드가 연관되어 생기는 오류인지? 아니면 사실 우리 코드에 문제가 있는지 파악하기 어렵다. 하지만 상대 응답이 멀쩡할 때 우리 코드가 잘 작동하고, 상대 응답이 망가졌을 때 우리 코드가 망가진다면 문제는 상대에게 있다는 것을 알 수 있다. 이는 다음 대응 시간을 단축 시켜준다. 카카오톡이 오류가 나서 일주일간 통신이 안됏을 때 만약 테스트 코드가 있었다면 우린 라인으로 통신을 변경할 수 있었겠지? 하지만 테스트 코드가 없다면 라인으로 변경하기 전에 라인과 연결이 잘 되는지 테스트를 많이 해봐야 한다! 이렇게 말하면서 느끼는건데 테스트코드 이거 좀 심상치 않긴 하다.
3. 코드 리팩토링에 좋다.
테스트 코드가 있다면 코드 리펙토링을 할 때 어느 부분에서 오류가 발생하는지 파악하는 시간을 줄일 수 있다. 잠깐만. 이거는..... 좀 .... 사실 테스트 코드 작성하는 시간과 .... 리펙토링하면서 오류를 잡는 시간이.... 비슷하지... 않을까...?
마치 운동하면 오래 살아요 -> 오래사는 시간만큼 운동했어요. 와 같은..? 이건 잘 모르겠따 ㅎㅎ
튜터님께서 말씀하신 건 리펙토링시 오류가 발생하면 미리 작성해놨던 테스트 코드를 돌려서 어느 부분이 오류를 발생시키는지 알 수 있다고 했다.
오늘 아침 6시 반부터 공부를 해서 지금 10시 43분. 진짜 나 오늘 개열심히했다. 잠깐 딴짓한 시간을 다 합쳐도 2시간이 남짓. 정말 풀로 집중을 했따. 정말 너무 피곤하고 눈이 너무 감긴다. 오늘도 고생했고 역시 TIL을 작성하면 머리에 한번더 정리해서 남는다. 마치 SORT를 하고 SAVE를 한달까? 하하
