WIL | 항해99 1주차

항해를 시작하다 🌊🚣‍♀️🌊

22년 3월7일 개발자의 꿈을 갖고 항해를 시작했다.
설레는 마음으로 출항 하였으나 시작하자마자 넘을 수 없을 것만 같은 큰 파도를 만나버렸습니다,,,😂

이번 포스팅에서는 1주차 를 보내면서 JWT와 API, 항해 1주차를 보낸 나의 느낀점을 포스팅해보려고합니다.

조가 편성이 되고 웹사이트를 만들어야하는 미니프로젝트를 시작하게 되었다
프로젝트를 하면서 필수 조건으로 Jinja2 템플릿을 이용하여 서버 사이드 렌더링방식과, JWT 방식으로 로그인을 구현해야했다.
이번 프로젝트를 통해 협업이라는 것은 자연스럽게 해보게 되었고 Github 또한 자연스럽게 사용해보았다
Github를 이용하는것이 협업에선 필수라고 하던데 이번 프로젝트를 진행해보면서 그 이유를 확실히 알게된 것 같다.

1. JWT

JWT토큰이란, Json web token 의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다.
JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.
JWT 방식으로 로그인을 했다면 해당 브라우저에 나의 토큰 정보가 남아 있어서 브라우저를 종료하거나 토근만료시간이 지날때 까지 남아있는다.

JWT 장점

• Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요없다.
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
• 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 된다.
• 확장성이 우수하다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. (쿠키와 차이)
• OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
• 모바일 어플리케이션 환경에서도 잘 동작한다. (모바일은 세션 사용 불가능)

JWT 단점

• 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
• 토큰을 탈취당하면 대처하기 어렵다.

간단 정리

	장점	단점
Cookie & Session	Cookie만 사용하는 방식보다 보안 향상 서버쪽에서 Session 통제 가능, 네트워크 부하낮음	세션 저장소 사용으로 인한 서버 부하
JWT	인증을 위한 별도의 저장소가 필요 없음, 별도의 I/O 작업 없는 빠른 인증 처리 확장성이 우수함	토큰의 길이가 늘어날수록 네트워크 부하, 특정 토큰을 강제로 만료시키기 어려움

좀 더 자세한 내용은 아래 링크에서 확인 가능합니다.
자세히 보러가기 클릭 !

2. API

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

위 내용은 사전에 등록되어있는 내용으로 이해하기 어려울 수 있다.
좀 더 이해하기 쉽게 설명하자면 클라이언트와 서버를 연결해주는 중개역할이라 생각하면 된다.

• Ex1)
  일상생활중으로 비교를 해서 설명한다면 은행으로 예시를 들어보겠다.
  은행에가서 출금을 하려는 사람(클라이언트)이 은행창구(API)에가서 나의 통장에 있는 돈(서버)을 출금요청한다. 이 과정에서 은행창구가 없다면 나는 은행에 돈을 맡길수도 찾아올수도 없으며 대출을 비롯한 은행업무를 보기 힘들기에 이때문에 은행창구가 있는 것이고 이 은행창구가 API가 되는것이다.

• Ex2)
  다른 예시로는 흔히 API를 레스토랑에 빗대어 표현하기도 한다. 손님(내가 만드는 프로그램)이 자리에 앉아 웨이터(API)에게 주문을 한다. 그럼 웨이터는 내 주문 내역을 주방(API 제공자. 기상청, 공공포탈 등)에 갖다준다. 주방에서 요리를 해 웨이터에게 주면 웨이터가 다시 나에게 음식을 가져다준다. 웨이터가 손님의 주문을 주방으로 전달하는 매개체 역할을 하는 것이다.
  여기서 손님은 주방에서 무슨 일이 일어나는지 잘 모른다. 대개는 관심도 없으며 관심을 가질 필요도 딱히 없다. 이것이 API의 장점이다. 내가 가져다쓰려는 API의 기능을 어떻게 구현하는지 몰라도 되고 난 그저 API가 갖다주는 걸 사용만 하면 된다(식사한다)는 것이다. 시간과 노력을 동시에 아낄 수 있다. 이처럼 API는 처음부터 개발하거나 유지 보수할 필요가 없는 외부 데이터와 기능에 접속할 수 있게 해준다.

API의 유형

API의 유형에는 뭐가 있을까?

• private API - API 내부에서만 사용할 수 있으며, API를 최대한으로 제어할 수 있다.
• public API - 모두에게 API가 제공되며, API와 상호 작용하는 애플리케이션을 개발할 수 있다.
• partner API - 특정 비즈니스 파트너와 공유하며, 제휴업체와 협의 후 제작하여 한다.

API의 방식

API의 방식으로는 대표적으로 2가지가 있다.

• REST API
• SOAP API

위 두가지의 자세한 내용이 저로써는 아직 이해하기 어렵기에 아래 링크를 첨부드리니 참고 부탁드립니다.
API 방식 확인하러 가기

3. 항해 1주차를 보내며

이렇게 항해를 시작하게 되어 첫 주차를 보내며 배우게되고 알게된점을 간단하게 정리해 보았다.
프로젝트를 진행하면서 문제를 해결하는 방식중 트러블슈팅방식의 해결방법을 알게 되었는데 이 방법을 앞으로는 적극적으로 활용해야겠다는 생각이 들었다. 이 방식이 시간적으로도 효율적이고 문제해결 후 기억에도 오래 남아 있는것 같다. 코딩이라는 것이 정말 어렵다는것을 다시한번 느끼게 되었고 응용력이 부족한 나로써 남들보다 몇배는 더 열심히 해야겠다는 마음가짐이 생겼다. 항해를 하면서 내가 느끼고 생각하는 것을 다른분들도 다 똑같은 생각을 하고있다는걸 알게 되었을때 안심이 되면서도 의지가 됐다. 또 다음 한주를 보낼 생각을하니 어떤 파도가 칠까 무섭지만 같이 항해하는 사람들을 보며 힘내서 끝까지 항해 해보려한다.👍