[TIL] 06/16 항해99 39일차 - 여러가지 정리

 

들어가며

2주차 과제를 제출하기 위해 Readme를 작성하면서 여러가지 개념들을 간단하게 정리하는 시간이 있었다.

항해99 e반 공식 TIL 망령으로서 대충 정리한 내용을 블로그에 올리고 싶지 않았지만 조금씩 내려놓지 않으면 이도저도 안될 것 같으므로

 

 

오늘의 TIL은 여러가지 정리한 내용들을 종합해서 작성해보고자 한다.

---

프레임워크와 라이브러리의 차이점

프레임워크와 라이브러리의 차이점은 막연하게 알고 있었지만 막상 설명해보라고 한다면 명확하게 대답하기가 어렵다. 둘다 개발자가 필요한 기능들을 사용하기 편하게 구현해둔 집합체이지만 그 차이점은 존재한다.

 

둘의 차이점을 알기 위해서는 라이브러리와 프레임워크의 개념을 먼저 알고 있어야한다.

 

라이브러리(Library)

라이브러리는 단순 활용이 가능한 도구들의 집합이다.

개발자가 만든 클래스에서 호출해서 사용하는 방식을 취하고 있다.

 

프레임워크(Framework)

프레임워크는 소프트웨어의 특정 문제를 해결하기 위해서 상호협력하는 클래스와 인터페이스의 집합이다.

 

어플리케이션 개발 시 필수적인 코드, 알고리즘, 데이터베이스 연동과 같은 기능을 위해 어느정도 뼈대를 제공해주면, 그 뼈대를 기반으로 개발자가 코드를 작성하여 어플리케이션을 완성해야한다.

 

프레임워크와 라이브러리의 차이

프레임워크와 라이브러리의 차이는 제어의 흐름에 대한 주도성이 누구 / 어디에 있는가로 구분할 수 있다.

즉, 어플리케이션의 흐름(flow)를 누가 쥐고 있느냐가 둘을 구분하는 가장 큰 특징이다.

 

프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 그 안에서 필요한 코드를 짜 넣는 반면, 라이브러리는 사용자가 전체적인 흐름을 만들면서 라이브러리를 가져다 쓰는 것이라고 할 수 있다.

 

다시 말해, 라이브러리는 라이브러리를 호출하고 사용하는 개발자에게 주도성이 있으며, 프레임워크는 그 틀 안에 이미 제어 흐름에 대한 주도성이 내재되어있다.

 

 

개발을 할 때 프레임워크로 개발을 하며 그 안에러 라이브러리를 사용한다는 느낌으로 접근하면 이해하기 쉽다.

 

 

 

GraphQL

최근 REST API를 대안으로 급부상하고 있는 GraphQL은 Server API를 구성하기 위해 Facebook에서 만든 쿼리 언어이다. 

 

GraphQL vs REST

GraphQL이 REST와 비교해서 가지는 차이점은 크게 다음과 같다.

 

• GraphQL API는 보통 하나의 엔드포인트를 가진다.
• GraphQL API는 요청할 때 사용하는 쿼리에 따라 다른 응답을 받을 수 있다.

 

하나의 엔드포인트

REST API는 보통 여러 엔드포인트를 가지며 각각의 엔드포인트가 동일한 응답을 반환한다. 하지만 GraphQL은 보통 하나의 엔드포인트만을 사용하며 요청하는 쿼리에 따라 다른 응답을 반환하는 방식이다.

 

 

예시

REST API
→ example.com/hanghae99
→ example.com/hanghae99/(반 id)
→ example.com/class/(반 index)/students
→ example.com/hanghae99/(반 id)/students/(수강생 id)

GraphQL
→ example.com
    (하나의 엔드포인트에 다른 쿼리를 사용해 요청)

 

 

원하는 응답값만 받을 수 있음

엔드포인트에 따라 정해진 응답 값만 받아올 수 있는 REST API와 달리 GraphQL은 쿼리 작성을 통해 필요한 데이터만 골라 받아올 수 있다.

 

 

예시

 

REST API 요청

Copycopy code to clipboard1GET, <https://swapi.dev/api/people/1>

 

결과

{
    "name": "진유진",
    "height": "160",
    "birthday": "1997-04-15",
    "gender": "female",
    "homeworld": "<http://swapi.dev/api/planets/1/>",
    "films": ["<http://swapi.dev/api/films/1/>", "<http://swapi.dev/api/films/2/>", "<http://swapi.dev/api/films/3/>", "<http://swapi.dev/api/films/6/>"],
    "vehicles": ["<http://swapi.dev/api/vehicles/14/>", "<http://swapi.dev/api/vehicles/30/>"],
    "starships": ["<http://swapi.dev/api/starships/12/>", "<http://swapi.dev/api/starships/22/>"],
    "created": "2022-06-16T15:50:51.644000Z",
    "edited": "2022-06-16T16:17:56.891000Z",
    "url": "<http://swapi.dev/api/people/1/>"
}

 

REST API를 통해서 인물의 정보를 받아오면 필요한 정보 이외에도 너무나 많은 정보까지 함께 받아야 한다.

 

 

여기서 이름, 키 , 생일의 데이터만 필요하다고 할 때 GraphQL API를 사용하면 다음과 같이 요청 할 수 있다.

 

GraphQL 요청

query {
    person(personID: 1) {
        name
        height
        birthday
    }
}

 

 

결과

{
    "data": {
        "person": {
            "name": "Luke Skywalker",
            "height": 172,
            "birthday": "1997-04-15"
        }
    }
}

 

REST API로는 3개의 데이터를 가져오기 위해 13개의 불필요한 데이터까지 함께 가져와야 했지만, GraphQL은 클라이언트에서 필요한대로 쿼리를 작성해 원하는 데이터만을 가져올 수 있다.

 

 

 

Token과 Session 중 어느 방식을 사용할까?

일단 결론적으로 Token 방식을 채택하였다.

 

개인적인 이유로는 Session 방식은 사용해보았지만 Token 방식은 사용해보지 않았기 때문에 이 방식을 공부해보고 싶었기 때문이다.

하지만 이는 적합한 이유가 되지 않는다. 좋은 개발자가 되려면 내가 이 기술을 사용하는 ‘개발자 다운' 이유가 필요하다.

 

 

그렇다면 Token과 Session의 차이점을 알아보고 어떤 방식을 채택하는게 보다 적합할 지 알아보자.

 

 

세션(Session)

세션은 사용자가 로그인을 했을 때 사용자의 정보에 고유한 ID를 부여하여 서버의 세션 저장소에 저장하고 관리하는 방식이다. 클라이언트는 서버에서 해당 세션 ID를 부여받아 쿠키(Cookie)에 저장한 후 사용하게 된다.

 

세션의 가장 큰 장점은 세션 정보를 서버 측에서 관리하기 때문에 상대적으로 안전하다는 점이다.

따라서 클라이언트의 변조나 데이터의 손상 우려가 없다. 쿠키가 담긴 HTTP 요청이 노출되더라도 중요한 정보는 서버 세션 저장소에 존재하기 때문에 쿠키는 유의미한 값을 가지고 있지 않기 때문이다.

 

하지만 별도의 세션 저장소를 사용하므로 잦은 요청이 들어오면 서버에 부담이 갈 수 있다는 단점이 있다.

 

 

이를 해결하기 위해 서버를 여러대 둔다면 HTTP의 stateless 특징 때문에 서로 다른 서버는 세션에 대해 알지 못하므로 다른 서버에 접속할 때마다 새롭게 로그인해줘야하는 단점 또한 존재한다.

 

 

토큰(Token)

토큰은 사용자가 로그인을 했을 때 별도의 저장소에 정보를 저장하는 대신 해당 정보가 담겨있는 토큰을 발급한다.

클라이언트는 이 토큰을 가지고 있다가 요청 시 Header에 담아 보내고, 서버는 이 토큰 정보를 확인 한 후 해당 유저에게 권한을 부여한다.

 

토큰의 가장 큰 장점은 클라이언트에 저장되기 때문에 서버의 메모리에 부담이 되지 않는다는 점이다. 따라서 서버를 늘리거나 조취를 취할 필요가 없다.

또, 확장성이 용이하다. 세션과 달리 서버에 정보를 토큰에 담기 때문에 토큰을 기반으로 하는 다른 인증 시스템에 접근이 가능하다.

 

 

하지만 토큰은 클라이언트 측에서 관리되기 때문에 노출되기 쉽다는 단점이 있다.

이런 경우를 대비해 토큰에 민감한 정보를 담지 않고, 유효기간을 짧게 설정하는 등의 조치를 취할 수는 있지만 짧은 주기로 토큰이 무효화되면 사용자는 계속 로그인을 해줘야하기 때문에 불편함을 겪을 수 있다. (물론 이 부분에 대한 해결 방법도 존재한다)

 

또 하나의 단점은 토큰의 길이가 세션 ID보다 훨씬 길기 때문에 요청이 잦으면 세션과 마찬가지로 서버에 부담을 줄 수도 있다.

 

 

어떤걸 선택해야할까?

토큰과 세션을 공부하면서 대규모 서비스를 목표로 하고 있고, 다양한 인증 시스템을 사용하려고 한다면 토큰을, 서버의 부담을 감수하더라도 보안이 중요한 서비스를 운영한다면 세션을 사용하는게 좋을 것 같다고 결론을 짓기로 했다.

 

 

---

마치며

과제도 거의 마무리가 됐다. 기간을 지키지는 못했지만 그래도 요구사항을 얼추 다 맞추기는 했다. 처음 배우는 기술을 배우는게 아니라 스스로 공부하고 적용시켜야한다는 부분 때문에 스트레스를 많이 받았다. 이런게 자기주도학습인건가...

 

결국 지난 주 WIL에서 다짐했던 페이스 조절하기를 실패하고 말았다! 개발도 개발대로 어렵지만 멘탈관리가 더 어렵다고 느끼는 요즘이다

 

---

출처 및 참고

 

GraphQL 개념잡기