항해99 1주차 WIL (API , JWT) & 회고록

Seong Hyeon Kim·2022년 5월 15일
WIL항해99회고록
0

WIL

목록 보기
2/6

* API

* API 의 개념과 장점

#1

Application Programming Interface
응용 프로그램 프로그래밍 인터페이스

프로그래밍에서, 프로그램을 작성하기 위한 일련의 부(Sub) 프로그램, 
프로토콜 등을 정의하여 상호 작용을 하기 위한 인터페이스 사양을 말한다.

나무위키의 설명은 이렇게 되어있지만 뭔가 좀 어려우니 좀더 쉬운 설명을 찾아보았다.

#2

흔히 API를 레스토랑에 빗대어 표현하기도 한다. 손님(내가 만드는 프로그램)이 자리에 앉아 웨이터(API)에게 주문을 한다.

그럼 웨이터는 내 주문 내역을 주방(API 제공자. 기상청, 공공포탈 등)에 갖다준다. 주방에서 요리를 해 웨이터에게 주면 웨이터가 다시 나에게 음식을 가져다준다. 웨이터가 손님의 주문을 주방으로 전달하는 매개체 역할을 하는 것이다.

여기서 손님은 주방에서 무슨 일이 일어나는지 잘 모른다. 대개는 관심도 없으며 관심을 가질
필요도 딱히 없다. 이것이 API의 장점이다. 내가 가져다쓰려는 API의 기능을 어떻게 구현하는지 몰라도 되고 난 그저 API가 갖다주는 걸 사용만 하면 된다(식사한다)는 것이다.

시간과 노력을 동시에 아낄 수 있다. 이처럼 API는 처음부터 개발하거나 유지 보수할 필요가 없는 외부 데이터와 기능에 접속할 수 있게 해준다.

#2
예를 들어 내가 동대문에서 옷을 떼다 온라인으로 팔려고 한다.

그런데 내가 결제 시스템을 알 필요가 있을까? 물론 결제 시스템을 직접 만들 수도 있겠지만 시간도 오래 걸리고 정작 옷을 파는 본업에 집중하지 못할 수도 있다. 게다가 내가 만든 결제 시스템에 오류라도 난다면 당장 고쳐야 한다. 점점 옷을 팔아 매출을 내는 사업가라는 일과는 멀어지고 개발자화되어가는 모습이다. 이런 상황이라면 결제 시스템 API를 제공자에게서 받아서 내 사이트에 넣는 것이 훨씬 현명한 일일 것이다.

* API의 역활

API의 역할은?

    1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
      : 데이터베이스에는 소중한 정보들이 저장되는데요. 모든 사람들이 이 데이터베이스에 접근할 수 있으면 안 되겠지요. API는 이를 방지하기 위해 여러분이 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해줍니다.

    1. API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
      : 여기서 애플리케이션이란 우리가 흔히 알고 있는 스마트폰 어플이나 프로그램을 말합니다. API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 합니다.

    1. API는 모든 접속을 표준화한다.
      API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있습니다. 쉽게 말해, API는 범용 플러그처럼 작동한다고 볼 수 있습니다.

* API의 유형

1) private API

: private API는 내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행합니다. 따라서 제 3자에게 노출되지 않습니다.

2) public API

: public API는 개방형 API로, 모두에게 공개됩니다. 누구나 제한 없이 API를 사용할 수 있는 게 특징입니다.

3) partner API

:partner API는 기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있습니다. 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용됩니다.

3) 복합 API

복합 API는 두 개 이상의 서로 다른 API를 결합하여 복잡한 시스템 요구 사항이나 동작을 처리합니다.

* API 사용하면 뭐가 좋을까?

API를 사용하면 많은 이점들이 있는데요. Private API를 이용할 경우, 개발자들이 애플리케이션 코드를 작성하는 방법을 표준화함으로써, 간소화되고 빠른 프로세스 처리를 가능하게 합니다. 또한, 소프트 웨어를 통합하고자 할 때는 개발자들 간의 협업을 용이하게 만들어줄 수 있죠.
public API와 partner API 를 사용하면, 기업은 타사 데이터를 활용하여 브랜드 인지도를 높일 수 있습니다. 뿐만 아니라 고객 데이터베이스를 확장하여 전환율까지 높일 수 있지요.

* JWT

Cookie & Session

JWT 토큰을 배우기 앞서 쿠키와 세션에 대한 개념이 있으면,
토큰이 왜 사용이 되는지 ..등 보다 명확히 이해가 될수 있을 것이다.

JWT를 배우기 앞서 우선 쿠키와 세션의 통신 방식을 복습해보는 시간을 가져보자.

쿠키는 Key-Value 형식의 문자열 이다.

* 쿠키는 Key-Value 형식의 문자열 이다. 쿠키란 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 일컫는다.

  • 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.

  • 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.

  • 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별할 수 있게 된다.

쿠키 단점

  • 보안에 취약하다.
  • 요청 시 쿠키의 값을 그대로 보낸다.
  • 유출 및 조작 당할 위험이 존재한다.
  • 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
  • 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.
  • 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

* Session

쿠키의 보안적인 이슈 때문에,

세션은 비밀번호 등 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다.

  • 유저가 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다. 이때, 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
  • 브라우저에 쿠키로 Session Id가 저장된다.
  • 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 * 쿠키에 담아 전송한다.
  • 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.

* 세션 단점

  • 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않는다.
    그러나 해커가 이를 중간에 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다. (이는 서버에서 IP특정을 통해 해결 할 수 있긴 하다)
  • 각 사용자마다 고유한 세션 ID가 발급되기 때문에, 요청이 들어올 때마다 회원정보를 확인할 필요가 없어졌지만, 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

* JWT

* JWT의 정의

JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다.
JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

토큰 기반 인증 시스템은 세션을 사용하는 서버 기반 인증 시스템과 달리,
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다.

이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다.
그럼 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

기존의 세션기반 인증은 서버가 파일이나 데이터베이스에 세션정보를 가지고 있어야 하고 이를 조회하는 과정이 필요하기 때문에 많은 오버헤드가 발생한다.
그렇지만 JWT토큰은 서버가 인코딩한 정보를 클라이언트에게 던져주고 나면 이를 저장할 필요가 없다.

[간단요약]

JWT는 로그인 할 경우 로그인한 사용자를 위한 토큰을 발급 해 주고, 유저가 회원정보 변경 같은 요청을 할 경우 토큰이 일치한지 검증만 하면 된다. 토큰은 사용자의 정보가 담겨있기 때문에 굳이 DB를 조회하지 않아도 누가 요청하는지 알 수 있다.

JWT의 구조

* 헤더는 두가지 정보를 지니고있다.

typ : 토큰의 타입을 지정한다.

alg : 해싱 알고리즘을 지정한다. 주로 사용되는 알고리즘으로는 HMAC SHA256 혹은 RSA이며, 토큰을 검증할 때 사용되는 signature부분에서 사용된다.

내용(Payloda)

Payload 부분에는 토큰에 담을 정보가 들어있다. Payload에 담는 정보의 한 조각을 Claim이라고 부르고, name/value 한 쌍으로 이루어져있다. 이 클레임에는 3가지 부류로 나뉜다.

등록된 클레임(registered Claim)
공개 클레임(public )
비공개 클레임(private )

등록된 클레임
iss : 토큰 발급자
sub : 토큰 제목
aud : 토큰 대상자
exp : 토큰의 만료시간,(NumericDate 형식으로 되어있음)
nbf : Not before를 뜻하며, 토큰의 활성 날짜와 비슷한 개념
iat : 토큰이 발급된 시간
jti : JWT의 고유 식별자로, 주로 중복적인 처리를 방지하기 위해 사용됨(일회성)

* 공개 클레임

공개 클레임은 충돌이 방지된 이름을 가지고 있어야하며, 충돌을 방지하기 위해선 클레임 이름을 URI형식으로 짓는다.

{
 "https://velog.io/@pixelstudio": true; 
}

* 비공개 클레임

등록되거나 공개된 클레임이 아니며, 양 측(서버와 클라이언트)간의 협의하에 사용되는 클레임 이름들이다. 이름이 중복되어 충돌될 수 있으니 주의해야한다.

  
const payload = {
    "iss": "velog.io/@pixelstudio",
    "exp": "1485270000000",
    "https://velog.io/@pixelstudio": true,
    "userId": "1123123123131",
    "username": "Elitebook"
};

* 서명

JSON Web Token의 마지막 부분으로 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해싱을 통해 생성된다. 기존 진행중인 프로젝트에서 가져온 토큰을 Decoded 한 결과를 가져와보면 아래와같이 나온다.

항해99 7기 1주차 미니프로젝트를 마치며

결과물 깃허브 https://github.com/rtg1014/hanghae7-8

Chapter 1에서 스스로 가장 많이 성장했다고 느낀 부분이 있다면 자유롭게 적어주세요.

6기를 지원했다가 입학시험을 떨어지고 7기를 준비하던 중 스스로 알게 된 사실은 6기지원준비때의 나는 "내가 왜 틀리고 뭘 모르는지 모르는 바보" 였다는 사실이였고, 7기를 준비중이던 저는 "내가 틀리기는 했지만 뭘 틀리는지를 알게된 바보" 였다는 것입니다.

이번 Chapter 1 에서도 이와 비슷하게 내가 무엇을 부족한지 알게 되었다라는게 가장 성장한 부분인 것 같습니다. 처음 프로젝트 당시 와이어 프레임을 구상 후 어떤기능을 구현할지 그러기 위해서는 어떻게 코드를 짜야하는지 등의 이해도에 대해서는 확실히 이해했다고 생각했습니다.

물론 그것을 알았다고 해도 여전히 막막하다는것은 비슷했지만 그래도 무엇을 해야 할지를 아니깐 적어도 '어떤식으로 코드를 짜야겠구나' '내가 배운것들 중 이러이러한 것들을 사용하면 되겠구나' 라는것을 알고 있다는 것만으로도 가장 많이 성장한 부분이라고 생각합니다.

기능구현을 위해서 고민하면서 내가 몰랐던 내 스스로를 알아가게 된 기분이라서 좋았고
전체적인 흐름과 문제가 될만한요소를 찾아내고 해결하려는 의지까지는 괜찮았다고 생각합니다.

조금 아쉬운 부분이 있다면 결과적으로 해결방안을 찾는것에는 크게 기여하지 못한 부분이었습니다.

문제점을 발굴할 능력까지는 있다고 보지만, 문제해결을 위한 초점을 어디에 두는지 혹은 해결해 나가는 과정은 다른 팀원들에 비해 많이 미흡하다는 것을 알게된 미니프로젝트 였던것 같습니다.

하지만 그래도 나에 대한 장 단점을 알게되어서 어떻게 해야되는지를 알아가는 기분이라서 속도는 좀 느려도 방향은 확실히 가고 있다는 생각이 들어 그 부분에 대해서는 성장했다고 생각합니다.

Chapter 1에서 스스로 더 많이 성장하기 위해, 어떤 노력을 더 할 수 있었을까요?

문제 해결방법에 대해서 좀더 다른 시선으로 보았더라면 더 성장하지 않았을가 하는 생각이 들었습니다.

현재 프로젝트에서 해결 못했던 부분인 별점 기능과 이미지파일 넣는 기능등을 해결하기 위해서 서버쪽과 클라이언트쪽을 보면서 하나씩하나씩 고쳐가면서 수정을 했으나 결과적으로는

서버쪽의 get 방식쪽만을 보는게 아니라 자바스크립트 부분까지도 봤더라면 어쩌면 문제해결 을 좀더 빠르게 할 수 있었을텐데 라는 후견지명 적인 느낌이 프로젝트까 끝난후 강하게 들었습니다. 나도 모르게 한가지쪽만을 보면서 다양한 방면으로 문제를 해결할 생각을 하지 않은채 집요하게 한부분만 보면서 해서 어쩌면 좀더 늦어지지 않았나 하는 생각이 많이 들었습니다.

Chapter 1에서 성장하기 위해, 도움이 되었던 부분과 보완이 되면 좋았을 부분이 있다면, 자유롭게 적어주세요.

성장의 도움이 된 부분은 저의 팀원들이였습니다. 비전공자 4명이라도 서로 각각의 재량이 다르고 생각하는게 다르다보니 혼자서 해결해야 했더라면 제대로 답을 찾지 못할 문제들을 팀원들과 함께하는 시너지 효과는 혼자서는 절대 이룰 수 없는 일을 이루게 된거 같습니다.

또한 서로 다르지만 함께한다는 그 사실만으로도 스스로에게 더욱 동기부여가 된다는 것을 깨닫게 되었습니다.

보완이 되면 좋았을 부분은 완성이라는 목표를 위해서 너무 타협한게 조금은 아쉬웠습니다. 처음하는 프로젝트기에 우선은 필수적인 기능구현을 목표로 하자라는 취지로 가능할 것 같은 결과물을 목표로 하다보니 조금 더 좋은 결과물이 나올수 있엇을텐데 하는 아쉬움이 조금 남았습니다.
물론 그당시의 나에게 이런 말을 했더라면 완성도 못할판에 무슨 그런걸 신경쓰냐며 화를 냈을 것입니다. 지나고나니 좀더 퀄리티에 치중하지 못한게 아쉬울 따름이였습니다.

profile
Seong Hyeon Kim
삽질도 100번 하면 요령이 생긴다. 부족한 건 경험으로 채우는 백엔드 개발자
이전 포스트

22.05.19 WIL - 항해99 2주차를 마치며

다음 포스트

2022.06.16 - WIL [미니 프로젝트를 마치며]

0개의 댓글