팀 프로젝트 7~8일차

그렇게 이야기가 끝났다고 여겼지만 프로젝트를 진행하면서도

토큰 "만료"에 대해 계속 생각하다보니 Collection  타입에 적으면 되지 않나 하는 생각이 들었다

또 생각을 해보니 과제를 위한 일시적인 거니까 그리 큰 부담은 안 될 것이긴 할 것이다

탈퇴할 때는 로그아웃시키는 그 과정에서 Collection 에 토큰을 담아야 겠다

라고 생각하고 실행에 옮기려던 순간

token Table을 하나 만들어서 creadtedAt 으로 시간계산을 거쳐

token의 상태를 ABLE 에서 ENABLE 로 바꾸는 방법이 떠올랐다

어쨌든 이것도 DB에 저장하는 거니까 서버에 부담주는 건 매한가지이긴 한데,

브라우저에 널려있는 방식보다 참신한 방식이었기에 해보고 싶었다

 

그런데 요구사항이 refresh 토큰만 만료하는 것이기 때문에 refresh토큰의 Table 을 만들기로 했다

팀원에게 말해봤는데 잘 모르니 예전 팀들이 한 걸 참고하라고 하면서 링크를 줬다

그런데 신기하게도 그 팀도 Table을 이용하고 있었다

 

Status 설정처럼 enum으로 할까 했는데,

하면 할수록 이렇게까지 만료시켜야 하는 건가? 이게 맞나? 다른 방법이 있는데 내가 못 찾은 건가?

하는 의문이 들었다

 

과제 발제를 맡으셨던 튜터님께 가서 여쭤봤더니

"할 수 있는 방법은 많기 때문에 어떤 방식으로 해도 상관은 없다"고 하셨다

 

그런데 서버에 부담을 주는 건 나는 하기 싫었고 만약 셋 중에 고르는 거라면 Table을 이용하고 싶었다

하지만 내가 선택한 방식은 데이터가 계속 쌓여가기만 하는 거라 괜찮은 방식이 맞는 건지 알고 싶었다

혹시나 주기적으로 테이블에서 비워내는 방법이라도 있는지도 알고 싶었다

 

튜터님이 간단한 답을 주셨다

 

'초기화'

 

어이가 없었다

내가 그 방식을 떠올리지 못한 원인을 짚어보았다

제일 큰 원인은 '만료' 라는 단어와 '무효화' 라는 단어였다

만료는 기한이 끝나도록 하는 것이고

무효화는 기간이 남아있지만 마치 남아있지 않은 것 처럼 하는 것

그렇기에 기한이 기록되어 있어야 한다고 생각했던 것이다

 

사람 언어로 컴퓨터 언어를 대한다는 건 우리가 정한 정의도 조금은 달라질 수 있다는 걸 깨달았다

다음에 잘 안 풀릴 때는 컴퓨터적 관점으로 바라보도록 해봐야 겠다

 

---

 

저녁 7시가 넘어서야 Git이  슬슬 채워지기 시작했다

물론 그 전에 채운 사람도 있긴 하지만, 본격적으로 테스트도 진행할 수 있는 상황이 되어갔다

postman 을 다루는 것은 아직 익숙치 않아서 두려웠는데, 

팀원 한 분이 친절히 알려주셨다

물론 테스트 초반에 토큰을 빼먹는 실수를 하긴 했지만

 

생각보다 에러에서 벗어나는 게 쉽지 않았다

400, 403, 404, 405 정말 다양한 에러를 만났다

Controller 에서 Service로 진입한다 싶더니

이리저리 수정하니 다시 Controller로 돌아가버렸다

후에는 Controller도 들어가지 못했다

아마 아직 기본이어야 하는 어떤 지식이 내게 덜 축적되어 있기 때문이리라

 

추후 나를 대신해 팀원분이 해결해 주셨는데

그나마 다행인 것이 작성해 두었던 코드가 그다지 많이 수정되지 않았다는 점이다

필터에 대해 더 공부를 했다면 더 나은 코드를 초장부터 작성할 수 있지 않았나 하는 아쉬움이 든다

---

에러를 처리하다가 지쳐서 refresh 토큰에 힘을 쏟았는데

로그인 할때 생성되는 refresh 토큰이 테이블에 들어가지지가 않았다

별의 별 메서드를 다 써봤는데 되지가 않았다

도대체 원인을 잡을 수 없었다

 

그렇게 새벽 3시반쯤 되었고, 팀원들은 하나 둘씩 디스코드에서 떠나갔다

나도 잠깐 눈을 붙인다는게 자다깨다 하면서 3시간쯤 흘려보냈다

 

그리고 다시 접속했더니 팀원 한 분이 4시반쯤 부르고 있었다

늦었지만 대답을 하니 반응하셨고, 그렇게 둘이 하고 있는데

한 분이 더 들어오셨고 그렇게 셋이서 진행했다

 

간만에 팀프로젝트 다운 느낌으로 진행되어 너무 기뻤다

내 실력만 뒷받침 해줬다면 에러를 해결할 때 한 곳에 고여있지 않고

그만큼 생성되는 결과물들에 더 시너지를 얻어

더 많이 진행하고 밤을 완전히 샐 수도 있을 것만 같았다

---

이번 프로젝트를 진행하면서

팀원이 참고할 코드를 만들어 놓거나

security 같은 만들어지기까지 오래 걸리는 코드가 포함되어 있을 때에는

임시 class 또는 임시 변수를 설정해 놓고 진행하는 것이 좋겠다고 절실히 느꼈다

특히 논의가 안 된 상태에서 임의로 진행할 때는 (클래스명)2 라는 식으로 진행했던 것이 정말 잘 한 일이라고 생각한다

 

그런데 문제는 security 가 걸려있고, 회원가입과 로그인도 구현되지 않았고, 또 SQL을 잘 몰라서

DB에 접근하며 테스트하는 걸 할 수가 없었다는 점이었다

그만큼 결과물에 신용도가 떨어지니까 참고용으로 건네줬을 때 신빙성도 그만큼 낮아지고..

아, 회상하며 적고 있는 지금에야 떠올랐는데 방법은 하나 있었다

Intellij 프로젝트를 하나 더 파서 security 제외하고 테스트 하는 것..

좀 번거롭긴 하겠지만 다음에는 그렇게 진행해 봐야겠다

그러기 위해서는 폴더 정리가 필요하겠지만.

---

아무튼 그렇게 막판에 스퍼트가 올라갔지만 제출시간 내에 오류를 잡지 못했고,

그 때문에 발표를 진행할 수 없었다

마감기한을 엄수하는 게 기본 중의 기본이기 때문이다

 

하루만이라도 더 일찍  어제오늘처럼 팀원끼리의 소통이 진행되었다면 좋았을텐데,

하루만이라도 더 일찍 디스코드 회의실에서 제발 나가지 말고 접속한 채로 계셔달라고

말씀드리는 용기를 냈으면 좋았을 텐데..

하는 아쉬움이 남았다

 

그래도 팀원 분들도 깨달은 게 많은 것 같았다

신기하리만큼 단지 하루만이라도 제대로 단결해 준 팀원 분들 덕에,

더 일찍 이런식으로 시작할 걸, 공통부분은 처음부터 개발하고,

약속도 하고, 소통도 하고, 그렇게 할 걸.. 등등

진작에 말씀드렸지만 받아들여지지 않았던 부분들을 깨달았다고하는 그 분들의 말씀 덕에

그 동안 갑갑했던 마음이 눈 녹듯 사라졌다

 

아마 그 분들이 이제사 깨달으신 그것들을

내가 진작에 말했지만 차단되었던 것이라는 사실을 절대 기억하지 못 할 것이다

하지만 아무래도 좋다고 생각한다

이미 내 마음은 풀렸으니까

실상은 악의가 없었던 거였으니까

 

정말 역대급으로 고민들이 끊이지 않는 일주일이었고, 계속 회상될 만한 사건이었다