JWT(Json Web Token)은 서버가 어떤 클라이언트에게, 어떤 정보를 제공할 수 있을지 서버가 판단할 수 있도록 만들기 위한 고안의 결과물중 하나이다. 서버는 많은 정보를 다룰 수 있지만, 어떤 정보는 모두에게 공개될 수 있는 반면 어떤 정보는 어떤 누군가에게만 제공되어야 하고, 다른 누군가에게 제공되어선 안된다. 가령 특정성있는 정보가 외부에 노출되면 곤란할 것이다. 때문에 서버는 클라이언트 요청이 정당한 요청인지 판단해야 하고, 미리 정해진 정보만 제공할 수 있어야 한다. 클라이언트 Cookie에 인증 정보 일부를, 서버에 그 다른 한 쪽 부절인 Session을 저장하고 클라이언트 요청이 들어올 때마다 비교할 수도 있지만, JWT를 사용하는 방식은 서버에 클라이언트를 위한 session 공간을 유지할 필요가 없고, session 내부에 클라이언트 정보를 유지할 필요도 없다. 이런 특성은 RESTful API에 가까운 구현에 유리할 뿐 아니라 서버 리소스도 덜 잡아먹는다는 잇점이 있다. 다만 access token 노출시, 토큰이 유효한 시간동안 정보 유출의 여지가 있다는 점에서, access token과 refresh token의 유효기간을 정하기 위해 클라이언트의 편의와 정보 유출의 위험 사이에서 적절한 선택을 필요로 한다는 점이 한계일 수 있다. 또한 서버사이드에서 클라이언트의 인증 상태에 개입하기 어렵다는 단점이 있다. 이는 Session & Cookies를 사용한 방식과 마치 거울 관계에 있다고 볼 수 있을 것이다.
(웹상의)API(Aplication Programming Interface)는 주로 서버와 상호작용하기 위한 인터페이스를 가리킨다. API와 라이브러리, 프레임워크, 그리고 SDK는 때로 유사한 개념처럼 말해지기도 한다. 엄밀한 개념정의가 아닌 필요한 경우가 아닌 한, 이들을 구분하는 데서 오는 실익은 크지 않을 수 있다는 생각이 든다(둘로 구분하자면 API와, API를 기반으로 만들어지는 라이브러리 등일 수 있을 것이다). 1주차 과정에서 카카오맵 API를 사용하여 주변 헬스장 정보를 받아와 보여주는 코드를 짜는 경험을 했었는데, 단순히 몇줄의 코드만 추가하면 유용한 정보를 받아와 내 코드에 구현할 수 있다는 것에 그 유용성을 크게 느낄 수 있었다. 회사 입장에서는 서버 내부 정보를 공개하고 API를 제공함으로서 부수적인 수입을 노릴 수 있을 것이고, 사용자는 적은 시간 투자로 개발자 개인이 얻을 수 없는 대용량의 (비)가공된 정보를 얻을 수 있는 것이다. 다만 API 서비스 제공자가 정한 방식으로만 서버 정보를 사용할 수 있어서 API 사용자가 개발가능한 서비스의 범주가 한정적일 수 있다는 점이 유일한 아쉬운 점이었다. 구글, 메타, 테슬라등 거대 기업의 광대한 사용자 경험 데이터의 축적은 막대한 자산이며 (그것이 공개되기만 한다면) 개발 범주의 폭이 매우 넓어지게 될 것이다(공개되기만 한다면!). 이것을 앞으로 어떻게 내가 활용할 수 있을지, 너무너무 기대된다. :)
