비전공자 PM이 설명하는 API
비전공자 PM이 설명하는 개발
안녕하세요! "비전공자 PM이 설명하는 개발" 매거진의 첫 시간입니다. 이 매거진을 시작한 이유는 두 가지입니다:
개인의 공부: 비전공자로서 개발에 대해 더 깊이 이해하고 싶어서.
지식의 나눔: IT 산업에서 PM이나 개발에 관심 있는 사람들과 지식을 나누고 싶어서.
이 매거진은 제가 공부하고 이해한 내용을 기반으로 여러 소스와 점검한 이후 정리하여 올리고 있습니다. 혹시 제가 잘못 알고 있는 부분이 있거나, 공유해주고 싶은 부분이 있다면 댓글로 편하게 말씀해 주세요.
오늘 "비전공자 PM이 공부하는 개발"에서는 API에 대해 배워보려고 합니다.
IT업계에서 기획 일을 해보신 분이라면, 한번쯤은 API에 대해서 들어보셨으리라 생각합니다.
API란 무엇인가?
API는 "Application Programming Interface"의 약자입니다. 쉽게 설명하면, API는 일종의 약속입니다.
https://www.geeksforgeeks.org/what-is-an-api/API를 이해하기 위해서는 3개의 개념이 필요합니다: 유저, 클라이언트, 그리고 서버.
유저는 시스템을 사용하는 사람입니다. 이 글을 읽는 브런치 독자 분들은 브런치의 유저입니다.
클라이언트는 브런치를 작동하는 프로그램입니다. 혹시 브런치 앱을 통해 글을 읽고 계신가요? 그렇다면, 그 앱이 바로 클라이언트입니다.
서버는 클라이언트의 요청을 처리하고 응답하는 프로그램을 의미합니다. 즉, 데이터를 저장하고 관리하는 곳입니다.
API는 클라이언트와 서버 간의 상호 작용을 위한 사전에 정해진 규칙이나 방법입니다. 즉, 클라이언트가 특정 요청을 보낼 때 서버가 이를 어떻게 처리하고 응답할지 정해놓은 규칙입니다.
실생활 예시:
간단하게 예시를 들어보면, 브런치라는 앱을 실행하여 글을 클릭하면 앱은 작가가 작성해둔 글을 보여줍니다. 이는 브런치라는 앱(클라이언트)이 글을 선택(요청)하였을 때, 서버는 작가가 작성한 글(데이터)을 클라이언트에 보내 보여줍니다.
방금의 예시에서 클라이언트는 요청하고 서버는 보내 보여주었습니다. API는 이러한 상황에서 상호작용을 하기 위한 규칙입니다.
조금더 자세하게 들여다 보기 위해 클라이언트의 요청을 설명해보겠습니다.
클라이언트의 요청
클라이언트는 크게 4가지의 요청을 할 수 있습니다. 흔히 CRUD라고 불리는 이 요청은 다음과 같습니다:
Create: 생성하다
Read: 읽다
Update: 변경하다
Delete: 삭제하다
클라이언트는 API라는 약속을 통해 서버의 데이터를 CRUD합니다.
즉, 방금 예시에서 클라이언트는 서버에게 글을 Read (읽다) 하기 위해 요청했습니다.
우리는 이제 큰 개념에서의 API를 이해하였습니다.
조금은 심화과정으로 넘어가보겠습니다.
API를 진행하는 방법론에는 여러가지가 있지만 오늘은 크게 3가지를 들여다보려고합니다.
1) RCP (Remote Procedure Call)
RPC는 클라이언트가 서버의 함수를 호출하는 방법입니다. 여기서 함수란, 입력(Input)에 따라 출력(Output)을 발생시키는 코드의 모음입니다.
예시:
1. 입력(Input): 함수에 전달되는 값 (예: 숫자 2와 3)
2. 작업(Operation): 함수가 수행하는 일 (예: 두 숫자를 더하는 것)
3. 출력(Output): 함수가 반환하는 결과 (예: 2 + 3 = 5)
각각의 작업은 개별적으로 일어날 수 있지만, 함수라는 개념을 통해 이 작업들을 한 번에 실행할 수 있습니다. 즉, 여러 개의 작업을 함수로 묶어서 한 번의 요청으로 수행할 수 있습니다.
실생활 예시:
우리 핸드폰에 계산기 어플이 있다고 생각해보세요. 클라이언트(앱)에서 2와 + 그리고 3을 누르고 =을 누르면, =이라는 요청에 따라 서버는 더하기 기능을 통해 5라는 값을 반환해 클라이언트(앱)에 보내줍니다.
설명:
클라이언트(앱)가 2와 3을 더하는 요청을 서버에 보냅니다.
서버는 더하기 연산을 수행하고 결과를 클라이언트(앱)에 반환합니다.
RCP에 대해 설명은 이정도로 적합하겠지만, RCP에 대해 설명시 추가로 알아두면 좋은 부분이 있습니다.
그건 바로, Interface Description Language (IDL)
IDL은 클라이언트와 서버의 개발 언어가 다를 경우 서로를 이해시켜주는 매개체입니다. 클라이언트와 서버 간의 통신 인터페이스를 정의하여, 서로 다른 언어로 작성된 시스템 간의 상호 운용성을 가능하게 합니다.
2) RESTful API (Representational State Transfer)
RESTful API는 HTTP를 사용하여 URL를 통해 리소스를 요청하고 조작하는 행위입니다. 여기서 우리는 두 가지 단어만 기억하면 됩니다.
1) URL
2) 리소스
URL은 비전공자에게도 익숙한 단어라고 생각합니다. 한국어로는 웹 주소 등으로 불리는 Uniform Resource Locator입니다. 브런치를 예로 든다면 (https://brunch.co.kr/)가 URL입니다.
그렇다면 여기서 리소스는 무엇일까요?
리소스는 정보의 추상적 개념(Abstraction)입니다. 예를 들어, 학생, 반, 교사 등의 데이터를 리소스라고 할 수 있습니다.
즉, RESTful API는 서버에 있는 다양한 정보를 요청하고 조작할 수 있습니다.
앞서 말씀드리 RPC와 차이점을 들여다보면 다음과 같습니다.
실생활 예시:
RPC: 단일 정보 단위를 가져옵니다. 예를 들어, 학교 서버에서 특정 반(Class)을 불러올 수 있습니다.
RESTful API: 복합적인 정보를 가져옵니다. 예를 들어, 학교 서버에서 반과 학생들의 정보를 함께 불러올 수 있습니다.
3) GraphQL
GraphQL은 Facebook에서 개발한 API 쿼리 언어로, 클라이언트가 원하는 데이터만 요청할 수 있게 해줍니다.
클라이언트가 원하는 데이터는 과연 어떤 이야기일까요?
앞서 말씀드리 예시에서 GraphQL를 추가해보겠습니다.
실생활 예시:
RPC: 단일 정보 단위를 가져옵니다. 예를 들어, 학교 서버에서 특정 반(Class)을 불러올 수 있습니다.
RESTful API: 복합적인 정보를 가져옵니다. 예를 들어, 학교 서버에서 반과 학생들의 정보를 함께 불러올 수 있습니다.
GraphQL : 원하는 데이터를 가져옵니다. 예를 들어, 학교 서버에서 반과 학생들의 정보 중 김씨 성을 가진 학생들만 불러오고, 그들의 성적 정보만 요청할 수 있습니다.
즉, GraphQL은 더욱 디테일한 정보를 요청할수 있습니다.
GraphQL에서 3가지 개념은 매우 중요하니 짧게만 다뤄보겠습니다.
1) 쿼리 (Query) : 클라이언트가 원하는 데이터를 정확히 지정할 수 있는 요청입니다
2) 스키마 (Schema) : 데이터 구조와 타입을 정의합니다. 서버는 클라이언트가 요청할 수 있는 데이터와 그 형태를 스키마로 정의합니다.
3) 리졸버 (Resolver) : 특정 쿼리나 필드를 처리하는 함수입니다. 리졸버는 클라이언트가 요청한 데이터를 실제로 가져오고 반환하는 역할을 합니다.
API 관련해서는 더욱 다양한 개념이 있습니다. 다만, PM의 관점에서 API를 이해하는데 필요하다고 생각하는 부분에 대해서 우선적으로 가져왔습니다.
오늘도 긴글 읽어주셔서 감사합니다.
