Inside Jinseok

[Protocol] 프로토콜에 대한 고찰

처음에는 단순히 RESTful API에 대해 아직 잘 모르기 때문에 이해하려는 목적이었지만, 해당 영상이 이론에 대해서 너무나 쉽고 재미있게 설명을 해서 RESTful API뿐만 아니라 시리즈로 구성이 되어있던 SOAP, GraphQL, gRPC를 소개하는 영상까지 시청을 하였고, 나는 이들이 프로토콜이라는 이름으로 불린다는것을 알게 되었다.

순간 “이제야 이걸 알게 되다니?” 라는 부끄러움과 동시에 과거 공부했던 프로토콜이란 단어가 떠올랐다. 그때 당시에는 프로토콜이란 단어 자체가 너무 딱딱해서 이거를 어떻게 이해해..? 하면서 거부감이 생겼었는데, 막상 영상을 보면서 하나하나 까보니 다 한번쯤은 사용해봤거나 어디선가 들어본 내용들이여서 오히려 친숙하게 느껴졌다.

그러면 이해하게 된 프로토콜이란 뭔데?

프로토콜은 컴퓨터 네트워크에서 데이터를 주고받을 때 사용하는 규칙과 약속의 집합이다. 사람들이 언어를 통해 의사소통하듯이, 네트워크 상의 시스템도 특정한 규칙을 따라야 서로 원활하게 통신할 수 있다.

API에서의 프로토콜은 클라이언트와 서버 간의 통신 방식을 정의하는 규칙이며, 특정한 데이터 형식과 요청 방식, 응답 처리 방식 등을 정리한 것이다.


1. RESTful API

RESTful API는 현시점 개발자가 가장 많이 접하는 API 방식 중 하나일것이다. 나 또한 개발 프로젝트를 6번을 접했지만 4번은 RESTful API로 개발을 한 경험이 있다. 이처럼 우리가 만들 서비스에서 데이터를 주고받을 수 있는 가장 기본적인 방법 중 하나이다.

왜 RESTful API가 가장 일반적인 방법 중의 하나일까? RESTful API는 JSON이라는 포맷 형식으로 데이터를 주고받는다.

// JSON 형식
{
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com"
}

누가봐도 이해하기 쉽지 않은가? 그렇기에 어떤 개발자든 쉽게 데이터를 운용할 수 있다는 장점이 있고,

또한 이해하기 쉬운 URL과 SQL의 DML 구문처럼 CRUD ( Create, Read, Update, Delete )를 바탕으로 요청을 보내고 받기 때문에 학습량이 적다는 장점이 있다.


예시

https://api.example.com/**/users**/1
동작 HTTP 메서드 API URL 형식 설명
Create (생성) POST /users 새로운 사용자 생성
Read (조회) GET /users 모든 사용자 목록 조회
Read (조회 - 특정 데이터) GET /users/{id} 특정 사용자의 정보 조회
Update (수정) PUT / PATCH /users/{id} 특정 사용자 정보 수정
Delete (삭제) DELETE /users/{id} 특정 사용자 삭제

🎥 얄코의 RESTful API 강의


2. SOAP (Simple Object Access Protocol)

SOAP는 보안과 데이터 무결성이 중요한 시스템에서 사용하는 API 방식이다. 특징으로는 보안이 매우 뛰어나 중요한 정보를 운용하는 환경에서 널리 사용된다고 한다.

SOAP은 어떻게 데이터를 보내고 받길래 보안에 용이할까? 바로 XML이라는 복잡한 방식을 통해 데이터 구조를 엄격하게 정의할 수 있기에 정합성과 보안성이 타 형식보다 높다고 볼 수 있다.

<response>
  <user>
    <id>1</id>
    <name>Alice</name>
    <email>alice@example.com</email>
  </user>
</response>


또한 다른 프로토콜과 다르게 캐싱에도 강점이 있는데,

바로 API들끼리 유기적으로 동작을 할때, 서버에서 데이터를 캐싱할 수 있어서 트랜잭션 동작을 수행을 지원해준다는 것이다. 이를 통해서 다른 프로토콜에서는 하기 어려운 방식으로 데이터 정합성을 유지하는 데 강점이 있다.

마지막으로 WS-Security 같은 강력한 보안 메커니즘을 지원해주는데 이는 XML 디지털 서명, XML 암호화, 보안 토큰 등을 사용하여 메시지의 무결성과 기밀성을 보호해주기 때문에 IBM과 같은 기업에서 보안성을 높이기 위해 많이 사용된다고 한다.

하지만, 무거운 XML 구조로 인해 속도가 느릴 수 있다는 단점이 있으며, RESTful API 처럼 직관적인 접근 방식이 아니기 때문에 사람을 대상으로 사용하기 보다는 컴퓨터나 프로그램을 대상으로 많이 사용한다고 한다.

🎥 얄코의 SOAP 강의


3. GraphQL

GraphQL은 최근 공고를 보면 굉장히 많은 기업에서 해당 기술의 역량을 요구하는 것을 확인 할 수 있었다.
이 기술을 볼때마다 저건 무슨 SQL일까..? 라며 아무 생각없이 그냥 지나쳤는데.. ㅎㅎ

암튼, 왜 GraphQL이 요즘 많이 활용이 되고있는지, 어떻게 사용할 수 있는지도 한번 알아보자.
GraphQL은 클라이언트가 원하는 데이터만 선택적으로 요청할 수 있는 API 방식이다. RESTful API가 미리 정해진 JSON형식의 데이터 구조를 반환하는 반면, GraphQL은 필요한 데이터만 요청하고 받아서 네트워크 성능 최적화가 가능하다는 장점이 있다.

즉, Overfetching을 방지하여 성능을 높일 수 있다는 강점이 있는것이다. 최근 기업들이 비용 절감과 필요 기능만을 구현하는 오픈 소스에 열광하는 흐름과도 비슷한 맥락으로 볼 수 있을 것이다.

GraphQL의 가장 큰 특징 중 하나는 쿼리 언어를 기반으로 한다는 점이다.
그렇기 때문에 DB와 같이 스키마를 작성하는 점이 아주 특이했다.

type User {
    id: ID!
    name: String!
    email: String!
    posts: [Post]
}

type Post {
    id: ID!
    title: String!
    content: String!
    comments: [Comment]
}

type Comment {
    id: ID!
    content: String!
    author: User
}


위와 같은 스키마를 설정하면, 해당 구조를 기반으로 요청을 보낼 수 있다.

// request
{
  user(id: 1) {
    name
    email
    posts {
      title
      comments {
        content
        author {
          name
        }
      }
    }
  }
}

// response
{
  "user": {
    "name": "Alice",
    "email": "alice@example.com",
    "posts": [
      {
        "title": "GraphQL의 장점",
        "comments": [
          {
            "content": "좋은 글이네요!",
            "author": {
              "name": "Bob"
            }
          }
        ]
      }
    ]
  }
}

그러면 이제 해당 스키마를 바탕으로 어떻게 코드를 작성해야 하는가?

해당 유튜브의 내용에 따르면 개발 환경에 따라서 많이 달라지는것 같다. 나중에 GraphQL을 사용할 수 있는 프로젝트를 기획해서 한번 사용을 해봐야 알 것 같다.

아래는 GraphQL 문법을 조금 더 쉽게 사용하도록 도와주는 커뮤니티 링크이다. 직접 만들기보다는 tailwind처럼 복사해서 사용하는 경우도 많은가보다.

GraphQL 활용 사이트


API의 요청과 응답에 관해서는,

RESTful API에서는 /users/1, /users/1/posts, /users/1/posts/{postId}/comments 등 여러 개의 API 요청을 보내야 하지만, GraphQL에서는 한 번의 요청으로 사용자의 기본 정보, 작성한 게시글, 해당 게시글의 댓글 및 작성자 정보까지 한꺼번에 받을 수 있다.

이처럼 GraphQL은 원하는 데이터만 선택해서 받을 수 있도록 해주며, RESTful API의 단점인 불필요한 데이터 요청과 응답을 줄이는 것에 최적화되어 있다. 하지만 클라이언트가 너무 많은 데이터를 한 번에 요청할 경우 서버 부담이 증가할 수 있으므로, 적절한 요청 설계가 필요하다.

🎥 얄코의 GraphQL 강의



이런식으로 프로토콜을 한번 정리하고 나니, 마치 작은 퍼즐 조각들이 하나 둘 맞춰지는 기분이었다.

아침부터 깨달음에 대한 도파민으로 현자와 같은 표정으로 출근을 했다.

그러나 곧 한 퍼즐조각이 없다는걸 깨닫게 되었다..


그때 사용했던 API는 무엇이었을까?

나는 1년 전에 JSP를 이용해서 API를 만들었던 경험이 있었다. 그런데 이상했다. 당시 API는 JSON을 반환하지도 않았고, XML은 더더욱 아니었다. 그렇다면 내가 만든 API는 대체 어떤 방식이었을까?

이 궁금증을 해결하기 위해 G 선생과 대화를하며 심도 깊은 내용을 주고 받았다.


내가 궁금했던 점

  1. JSP는 어떤 방식의 프로토콜을 통해 데이터를 받아오는가?
  2. HTTP API는 어떻게 데이터 HTML 형식을 주는가?
  3. HTTP의 장단점은 무엇인가?


JSP는 어떻게 동작할까?

Java Server Pages는 기본적으로 백엔드 서버에서 HTML을 동적으로 생성하여 반환하는 방식을 사용한다.

예를 들어, 사용자의 로그인 정보를 데이터베이스에서 가져와 HTML 코드 내에 삽입하고, 이렇게 생성된 HTML을 클라이언트( =웹 브라우저 )에게 전달하면, 브라우저는 이를 웹페이지로 렌더링한다.

이 방식에서는 백엔드 서버가 직접 웹페이지를 구성하며, 클라이언트는 단순히 해당 HTML을 표시하는 역할만 수행한다. 즉, JSP는 클라이언트가 데이터를 직접 가공하여 활용하기보다는, 완성된 화면을 받아 그대로 출력하는 구조라고 볼 수 있다.


JSP가 HTML을 반환할 수 있는 이유

JSP가 HTML을 반환할 수 있는 것은 HTTP의 동작 방식과 HTTP API의 특징 때문이다. HTTP는 단순히 데이터를 주고받는 전송 프로토콜이며, 서버가 어떤 형태의 데이터를 반환할지는 HTTP의 Content-Type 헤더에 따라 결정된다.

일반적으로 API는 JSON이나 XML을 반환한다고 생각할 수 있지만, 사실 HTTP API는 다음과 같은 다양한 형식의 데이터를 반환할 수 있다.


HTTP API가 반환할 수 있는 데이터 형식

  • HTML (Content-Type: text/html)
  • JSON (Content-Type: application/json)
  • XML (Content-Type: application/xml)
  • 파일 (이미지, PDF 등) (Content-Type: application/pdf 등)
  • 단순 텍스트 (Content-Type: text/plain)
  • 리디렉션 (HTTP 301 Moved Permanently, HTTP 302 Found)


즉, HTTP API는 특정한 데이터 형식에 제한되지 않으며, 서버가 어떤 형식을 반환하느냐에 따라 클라이언트의 동작 방식도 달라진다. → 서버사이드 렌더링, SSR의 개념이다.

그렇다면 HTTP API방식은 RESTful의 API나 SOAP의 장점들을 다 사용할 수 있다는것 아닌가..?
바로 보안과 유지보수에 필요한 작업 효율성이 중요한 금융권이 생각이 났다.

여태까지 금융권은 왜 이러한 레거시 시스템을 사용을 하면서 사람들의 불편함을 감내할까? 이런 생각을 자주 했었는데, 금융 시스템은 다양한 포맷을 다루는 일이 많고 또 안전하기까지하니 적절한 대체 방안이 없지않았나 하며 금융권을 조금 더 이해 할 수 있었다.


마무리…

이번 회고를 통해서 단순히 기술을 비교하고 이해하는 것뿐만 아니라, 과거에 이해하지 못했던 기술적인 선택들이 왜 이루어졌는지 깊이 고민해볼 수 있었다. 처음에는 단순히 ‘왜 금융권은 이런 방식을 고수하는 걸까?’라는 궁금증에서 시작했지만, 다양한 프로토콜을 분석하면서 당시의 환경과 요구사항 속에서 가장 효율적인 선택을 한 것임을 이해하고 공감할 수 있었다.

RESTful API, GraphQL, gRPC 등 최신 기술들이 더 편리하고 효율적이라고 하지만, 결국 중요한 것은 도메인에 적합한 기술을 선택하는 것이다. 금융권이 HTTP API와 JSP를 유지했던 이유도, 단순히 보수적이어서가 아니라 보안성, 데이터 정합성, 다양한 형식의 데이터 처리 등 실질적인 요구사항을 만족시킬 수 있었기 때문이다.

이제 앞으로 기술이 변화하고 마이그레이션이 진행되더라도, 단순히 새로운 기술을 도입하는 것이 중요한 것이 아니라, 어떤 부분을 중점적으로 고려해야 하는지에 대한 인사이트를 가지게 되었다. 기술을 선택할 때는 그저 유행을 좇는 것이 아니라, 요구사항과 기술적 타당성을 기반으로 한 최적의 해결책을 찾아야 한다는 점이 더욱 중요함을 깨달았다.

아침 출근길, 유튜브에서 시작된 작은 호기심이 예상보다 깊은 고민으로 이어졌다. 그리고 나는 오늘, 단순히 새로운 기술을 배우는 것이 아니라, 기술을 바라보는 시각 자체를 성장시킬 수 있었다. 앞으로도 이런 과정을 반복하며, 단순히 ‘잘 쓰는’ 개발자가 아닌, ‘왜 사용하는지 이해하고 선택할 줄 아는’ 개발자가 되어야겠다고 다짐하게 되었다.


Categories:

Updated:

Leave a comment

You may also enjoy