첫주 WIL

김민재·2022년 9월 25일
0

WIL

목록 보기
1/2

느낀점

항해 99의 첫주가 지났다.
조원을 만나고 미니프로젝트했던 이번 주는 나의 부족한 점과 끊임없이 마주해야 했었다. 나의 힘겨웠던 시간이 고스란히 느껴지는 첫날의 일기를 인용해 본다.

항해 1일차
개같이 힘들다.
허리가 나갈 것 같고 눈이 멀 것 같다.
팀원들은 계속해서 의견을 내고 나는 따라가기 바쁘다.
오늘은 하루종일 광활한 정보더미 속에서 길을 잃고 헤매인 느낌이다.
그곳에서 방향을 찾아도 나아갈 엄두가 나지않았다.

하다보면 나아질 것이란 생각을 가지고 일주일을 버텨냈다. 그랬지만 프로젝트를 제출했을때 뿌듯함과 안도감은 없었다. 시간에 쫓겨 완성도 낮은 프로젝트를 제출하고 기쁠리가 없었다. 일주일간 느낀 부족함을 채워나가야 한다는 생각에 안도감보단 조급했다. 스트레스를 많이 받았지만 내가 스트레스를 받는 이 상황이 좋다고 하면 이상한 걸까. 스트레스를 받은 이유는 내가 잘해내고 싶은 것들이 생겼고 무언가에 노력하고 있기 때문이 아닌가. 살면서 그랬던 일들이 극히 드물었기 때문에 내가 스트레스를 받는 다는 사실을 상기시킬때면 더나은 미래에서 오는 희망감이 들었다. 아마 항해를 하면서 나는 성장을 갈구하는 것에서 오는 스트레스와 희망과 함께할 것이다. 물론 즐거움을 느꼈던 순간도 있었다. 에러가 떴을때 문제를 파악하고 해결하는 것이 너무 즐거워서 손뼉을 짝짝쳤다.

배운점

이번주는 배운것이 참많다. 첫째, 팀의 중요성과 팀의 구성원으로서의 태도를 배웠다. 힘든 순간에 서로를 공감해주고 의지를 북돋아주어서 버틸 수 있었기 때문에 감정적인 지지로서의 중요함을 느꼈고 팀원과의 적극적인 소통이 프로젝트의 완성도와 직결된다는 것을 몸소 체험했다. 또 내가 맡은 부분이 잘 안풀렸을때 나의 문제니까 내힘으로 잘 해보고 싶어서 혼자 머리싸매고 고군분투를 하다가 팀원과 공유하여 해결했을때 내가 맡은 일도 결국 우리 팀의 프로젝트중 일부분이니까 서로 같이 해결해 나가도 결국 모두의 이익이라는 것을 느꼈다. 둘째, 나의 부족한 점들을 배웠다. 기본적으로 코딩 실력과 지식. 이게 젤 크다. 그리고 유연하게 팀원들과 상호작용하지 못한다는 점, 15시간중 몰입하는 시간의 비중이 적다는 점이다. 셋째, 프로젝트를 기획하며 API와 로그인과 로그아웃기능을 구현하며 JWT를 배웠다.

API(Application Programming Interface)

컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다. 이러한 연결이나 인터페이스를 빌드하거나 사용하는 방법을 기술하는 문서나 표준은 API 사양으로 부른다.
쉽게 말해서 프로그램 사이에 요청을 보내고 응답을 받기 위해 열려있는 은행창구와 같은 역할을 한다.

JWT(JSON Web Token) 인증 방식

JSON 객체를 이용해 인증에 필요한 정보들을 암호화시킨 토큰에 담아 암호화시켜 정보를 안정성있게 전달하는 하나의 인터넷 표준 방식이다.

JWT 구성요소

  • Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어간다. (agl:HS256, type:jwt)
  • payload : 서버에 보내질 데이터. 유저 아이디, 유효기간등이 들어간다.
  • Verify Signature : Base64로 인코딩한 Header와 Payload, SECRET KEY

장점

  • 간편하다. 기존의 세션/쿠키는 별도의 저장소의 관리가 필요하지만 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없기때문이다.

  • 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다.

단점

  • 이미 발급된 JWT를 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 되비만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능해서 악의적인 사용자가 유효기간이 지나기 전까지 정보를 탈취할 수 있다.

  • Payload 정보가 제한적이다. Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.

  • 세션/쿠키 방식에 비해 JWT의 길이가 길다. 따라서 인증이 필요한 요청이 많아질 수록 네트워크에 부하를 줄 수 있다.

로그인 시스템

ID, PW를 서버에 전당한다 -> 서버가 매칭되는 유저를 확인한다 -> 토큰을 클라이언트에 전달한다 -> 클라이언트는 토큰을 쿠키에 저장한다

로그아웃 시스템

저장된 토큰을 클라이언트에서 지운다.

0개의 댓글