항해99를 시작하고 벌써 1주차가 지났다🥲
1주차에 무슨 일이 있었는지 회고하기 위해 WIL을 작성하기로 함
1주차에는 첫 번째 풀스텍 미니프로젝트가있었다
우리 6조가 만든 첫 작품이다
간단히 설명하자면 중고물품을 올려 사고 팔고 정보를 공유하는 그런 웹사이트다
한마디로 중고장터 플렛폼이다
사전지식 없이 웹개발 종합반 강의만 듣고 처음 만난 조원들과 웹페이지를 만드는게 과제였다
내가 조장이였지만 정말 아무것~~~도 몰라서 조원들에게 너무 죄송했던 프로젝트였다
조장이라면 뭔가 이끌고 중심을 잡아줘야한다고 생각하는데 아무것도 모르니 정말 난감했다(본인은 개발 경험 1도 없음, 비전공자)
아이디어 회의를 하고 기획에 먼저 들어갔다
먼저 회의를 통해 당첨?된 아이디어로 와이어프레임을 기획하고
두번 째로 API를 설계 했다
여기서 API(Application Programming Interface)에 대해 알아보자
출처 : 위시켓
그림으로 설명해보겠습니다!
여러분이 멋진 레스토랑에 있다고 가정해봅시다. 점원이 가져다준 메뉴판을 보면서 먹음직스러운 스테이크를 고르면, 점원이 주문을 받아 요리사에 요청을 할 텐데요. 그러면 요리사는 정성껏 스테이크를 만들어 점원에게 주고, 여러분은 점원이 가져다준 맛있는 음식을 먹을 수 있게 됩니다.
여기서 점원의 역할을 한 번 살펴보겠습니다. 점원은 손님에게 메뉴를 알려주고, 주방에 주문받은 요리를 요청합니다. 그다음 주방에서 완성된 요리를 손님께 다시 전달하지요. API는 점원과 같은 역할을 합니다.
API는 손님(프로그램)이 주문할 수 있게 메뉴(명령 목록)를 정리하고, 주문(명령)을 받으면 요리사(응용프로그램)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달합니다.
쉽게 말해, API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있습니다.
이렇게 API에대해 알아보았고
그다음 우리 조는 역할 분담을 하고 코딩을 시작했다
처음에는 Git Repo를 만들어서 협업을 했다
여기서 Git의 어려움을 느꼈고 많은 좌절을 느꼈다
명령어들도 굉장히 어려웠고(아직도 해깔린다)
왜 계속 충돌이 날까? 고민을 했다
구글링을 해보니 같은 app.py파일을 조원들이 작업을 하다가
한번에 main에 올리면 충돌이 잦다고 했다
그래서 각자 branch를 만들어 작업하고 확인 후
main에 병합을 하면 충돌을 최소화 할 수 있다고 들어서 그렇게 작업했지만!
그 전보다는 충돌이 적었지만 또! 충돌이 났다
Git은 계속 공부를 해야할 것 같다
내가 맡은 부분은 검색 기능인데 처음에 조원과 어떤 기능을 만들어야하는지 이야기할때
검색 창에 글을 적으면 팝업이 뜨는? 것을 만드는 줄 알고
나혼자 이상하게 이해했다가 거의 막바지에 검색을 하면 DB에 쌓여서 그걸 꺼내서
쓸 수 있는 검색창을 만드는 것이였는데 나는 alert를 사용해서 아무 기능 없는
팝업만 뜨는 검색창을 만들었던 것이였다
이렇게 소통의 중요성을 알게 되었고 다시 프로젝트를 한다면 이것이 맞는지 정확히 팀원과
소통해서 작업에 들어가야할 것 같다
소통에 대해 많이 배웠던 시간이였다
하지만 잘 못 만든 검색창도 정말 구글링을 얼마나 했는지.. 참 진짜 어렵게 구현했다
그렇게 시간이 흘러 제출 시간이 돌아왔고 우리 조는 발표까지 마쳤다
그렇게 프로젝트가 끝났다
프로젝트 중 JWT를 사용해서 웹사이트를 만드는 것이였는데
여기서 JWT를 알아보자
JWT는 JSON Web Token의 약자로 전자 서명된 URL-safe (URL로 이용할 수 있는 문자로 구성된)의 문자다.
JWT는 Server와 Client간 정보를 주고 받을 때, Http Request Header에 JSON 토큰을 넣은 후, 서버는 별도의 인증 과정 없이 헤더에 포함되어 있는 JWT 정보를 통해 인증을 한다.
JWT는 크게 3가지로 정보를 담고 있다.
이 정보는 각각 "." 으로 구분하며 각각 Base64로 인코딩 되어있다.
- Header
토큰 방식, 암호화 알고리즘 종류를 저장한다.
alg: 암호화 알고리즘 방식
typ: 토큰 타입
- Payload
여기서 나타나는 각각의 정보는 Claim으로 정의되며, Claim 종류는 3가지가 있다.
Registered Claim(등록된 Claim)
iss: 토큰 발급자(issuer)
sub: 토큰 제목(subject)
aud: 토큰 대상자(audience)
exp: 토큰 만료 시간(expiration), NumericDate 형식으로 되어 있어야 한다. 예) 1480849147370
nbf: 토큰 활성 날짜, 이 날이 지나기 전의 토큰은 활서오하 되어 있지 않다.
iat: 토큰 발급 시간(issued at), 오늘을 알면 토큰 발급 이후의 경과 시간을 알 수 있다.
jti: JWT 토큰 식별자(JWT ID), 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용된다.
Public Claim(공개 Claim)
사용자 정의 Claim으로, 공개용 정보를 위해 사용한다.
예) "name": "Nully" 등등
Private Claim(비공개 Claim)
사용자 정의 Claim으로 Server와 Client 사이에 임의로 지정한 정보를 저장한다.
- Signature
토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다.
Signature는 Header와 Payload의 값을 각각 Base64로 인코딩하고, 인코딩한 값과 비밀키(서버에서 지정한 고유한 암호키)를 이용해 Header에서 정의한 알고리즘으로 암호화한다.
JWT인증 방식을 설명하자면
- Server는 비밀키를 어딘가 저장하고 있다.
- Client가 로그인을 했을 경우, 위에 JWT 생성 과정을 거쳐 JWT 토큰을 한다.
- 인증된 Client에게 JWT를 반환한다.
- 다음부터 GET, POST, PUT 등 요청을 Server에게 Client가 보낼 경우 JWT를 Http Header에 같이 보낸다.
- JWT를 받은 Server는 인증된 Client인지 확인하기 위해 Server가 가지고 있는 비밀키로 Client에서 받은 JWT Header와 Payload를 이용해 Signature를 만든다.
- 만약 Client에서 전달 받은 JWT의 Signature, 그리고 Server에서 Client에게 받은 JWT Header와 Payload를 이용해 다시 생성한 Signature가 같으면 인증된 Client로 판단하고, 아니면 중간에 Header와 Payload를 누군가 강제로 수정을 했거나 Server에서 발급 받은 JWT가 아니기 때문에 Payload Private Claim에 정의된 사용자 권한을 주지 않는다.
- 추가: JWT Payload에 exp(Registered Claim) 만료 시간이 지났으면 해당 JWT는 사용할 수 없다.
이제 JWT의 장단점에 대해서 알아보자
장점
- 서버 메모리에 저장 공간을 확보할 필요가 없다 (로그인 세션 테이블 필요 X)
- 쿠키를 사용할 수 없는 서비스에게 최적이다.
단점
- 보내는 사이즈 용량이 크다.
- 유효기간 없을 경우, 장기간 방치시 해킹 위험이 있다.
이렇게 JWT에 대해서 알아 봤다 정말 어렵다... 더 공부해야겠다...
이렇게 1주차 회고가 끝났다
1주차에 같이 지냈던 조원들에게 너무 죄송하다...
정말 아무것도 한게 없는 것 같다
그렇다고 놀지도 않았다
계속 구글링하고 다시 강의보고 16시간씩 집중했다
그러나 뚜렷한 결과가 나오질 않아서 정말 답답했다
조원 중 한명은 나처럼 사전 지식 없이 스파르타에서 제공한 웹개발 종합반만 들으셨다고 했는데
끝까지 이게 왜? 안될까? 구글링하고 어떻게든 해결하시는 모습을 보고
많은 배움을 느꼈다 그분 때문에 무사히 프로젝트를 마칠 수 있었던 것 같다
나는 안되면 쉽게 포기를 했는데 그 분을 보고 많은 것을 느꼈다
이제 2주차가 시작이 되는데 또 한번 달려보겠다
회고 끝
