아직 한 주가 완전히 끝난 것은 아니나, 오늘이 미니 프로젝트 마지막 날이기에 항해 일지를 작성한다.
팀원
우리 조는 다른 조에 비해 팀원 한 명이 부족한 상태로 프로젝트를 해야 했다. 그러던 중 내가 벙원에 입원하게 되면서 진료 및 절차 처리 시간에 팀원들과 함께 하지 못했고, 그 만큼 팀원들이 더 많은 역할을 맡아야만 했다. (한 팀원은 밤을 새서 작업을 하기도 했다. 누적 학습시간은 체크아웃을 기준으로 하는데 해당 팀원은 밤을 새서 체크아웃을 안한 상태)
프로젝트
프로젝트 주제는 자유롭게 정할 수 있었으나, 반드시 두 가지 기능을 포함해야 했다.
- Jinja2 템플릿 엔진을 이용한 서버사이드 렌더링
(CSR과 비교하여 어떤 장점이 있을지) - JWT 인증 방식으로 로그인 구현하기 (세션/쿠키 방식에 비해 어떤 장점이 있을지)
나는 회원가입, 로그인, 로그아웃을 맡게 되었고, 결과적으로 작동이 가능한 코드를 완성했다.
회원가입과 로그인은 단순한 DB 연결까지는 할 줄 알았기에 큰 어려움을 겪지 않았다. hashlib을 사용해서 사용자 패스워드를 현실적으로 역추적하기 매우 어려운 암호로 DB에 저장할 수 있다는 것을 알게 되었을 때, 굉장히 신기하기도 했다.
(한 15년 전? 정도 전까지만 해도 비밀번호 찾기를 하면 이메일 등으로 내가 설정한 패스워드를 알려주곤 했는데, 어느순간부터 이런 방식이 아닌 무조건 비밀번호를 변경하는 방식으로 바뀐 것 같다. 이런 방식이 보안상 더 훌륭하기 때문이라고만 생각했었는데, 어쩌면 DB를 가진 쪽에서도 사용자 패스워드를 암호화 해서 보관하고 있기에 사용자가 실제로는 어떤 값을 작성했는지 모르기 때문이 아닐까 생각한다.)
프로젝트를 하면서 많은 것을 배웠지만 가장 뿌듯했던 부분이 있다. JWT 토큰을 쿠키에 저장해서 로그인 증명을 하게되면, 로그아웃을 구현하기 위해서는 쿠키를 지워야 한다. 해당 부분은 강의를 보지 않았기에 그냥 검색을 통해서 해결할 수 있다고 생각했고, 실제로 작동하는 코드를 만들어냈다. 그런데 문제가 생겼다.
특정 페이지에서 쿠키가 사라졌다가 금세 다시 복구되면서 로그아웃이 작동하지 않는 문제였다. 이를 위해 쿠키자체에 대해 찾아봐야 했다.
document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:01 GMT;';처음 시도한 쿠키 삭제 코드 메인페이지에서 제대로 작동했으나 마이페이지에서는 작동하지 않는다.
원인은 해당 코드로 쿠키 삭제 펑션을 만드면 도메인 내부의 쿠키를 삭제할 수 있으나 Path값 으로 설정된 쿠키는 삭제하지 않는 것이고, Path값으로 설정한 쿠키를 삭제하기 위해서는 코드를 수정해야 했다.
document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/;이번 문제를 해결하면서 쿠키의 작동원리를 조금이나마 찾아보게 되었고, path값이 무엇인지도 알 수 있었으며 모든 경로를 의미하는 path=/도 따로 코드에 반영해야 한다는 것을 알게되었다. (다른 블로그에선 도메인도 반영해야 한다고 하는데 해당 문제는 로컬호스트 내에서는 발생하지 않았기에 기억해 두기로만 하는걸로)
git
다른 조의 질문을 보면 깃 충돌 문제로 많이 힘들어 하는 것이 보인다. 나도 깃을 개인 프로젝트를 올리는 데에만 사용했었기 때문에 팀플을 하면서 어떻게 충돌을 최소화하고 해결할 수 있는지 걱정이 앞섰다. 다행히 팀프로젝트 경험이 있는 팀원이 포크부터 리퀘스트 등의 깃 관리 방법을 알고 있었고, 팀원의 도움을 받아 프로젝트를 보다 쉽게 할 수 있었다. 아무래도 첫 팀플인 만큼 깃을 관리하고 사용하는 것에도 비중이 있고, 깃 문제 해결을 위한 시간소모로 부터 비교적 자유로울 수 있었으니, 밤을 새시면서까지 팀프로젝트에 더 큰 희생을 한 팀원에게 감사함을 전한다...
포크 방식으로 깃을 사용하면 깃 명령어가 약간 달라지게 된다. 기존 깃에서 사용하던 origin 명령어 부분이 팀장을 의미하게 됐을 때 pmorigin으로 바뀌기 때문이다. 그래서 풀을 땡겨올 때 git pull pmorigin main으로 땡겨와야 한다.
문제는 여기서 push의 경우 바로 팀장의 레포에 보내게 되면 기존 레포를 덮어씌우게 된다는 것이다. 그래서 기존 명령어대로 개인 포크에 먼저 푸쉬를 보낸 후 팀장에게 리퀘스트를 신청해야 한다. 팀장은 리퀘스트 받은 파일을 머지 할 경우 치명적인 문제가 생기지 않는지를 팀원들과 논의한 후 최종적으로 반영하게 된다.
그런데 내가 푸쉬를 pmorigin으로 보내버렸다. 이럴 경우 기존의 작업물이 덮어씌워지게 되는데 아직 코드 리뷰를 진행하지 않았기에 심각한 충돌이 생길 수도 있는 문제였다. 다행이 큰 문제는 없었지만, 솔직히 나는 그 때 origin과 pmorigin이 어떤 것인지, 어떻게 작동하는지 제대로 생각하거나 고민하지 않고 그냥 코드를 따라 쓴 것이었다.
개발을 하다보면 웹서핑이 필수다. 방대한 정보들을 보고 있으면 어떨 때는 충분히 고민하거나 생각하지 않고 또한 어떻게 작동하는지 생각하지 않고 코드를 그대로 가져다 쓸 때가 있다. 사실 이럴 경우 제대로 작동하는 것보다 의도한 대로 작동하지 않는 것이 다행일지도 모른다. 정규식을 쓸 때나, 쿠키를 삭제할 때나, 깃헙에 푸쉬를 할 때 내가 의도한대로 되지 않았기 때문에 코드를 다시 보면서 어떤 방식으로 작동하는지 찾아보게 되었고, 그렇게 내 지식이 되었다.
hi