[API] API의 정의와 원리

 

API, 어디까지 가능한 걸까?

업무를 진행하다보면 종종 이런 질문을 듣습니다.

"API로 연결하면 다 되는거 아닌가요?"

 

처음에는 저도 고개를 끄덕였는데, 생각해보면 어디까지 연결되는지, 그 연결이 어떤 방식으로 진행되는지 잘 모르겠더라고요. 그래서 오늘은 API가 뭔지, 그리고 어디까지 가능한지를 정리해서 공유드리려고 합니다.

 

 

---

 

 

API, 사실은 어렵지 않다

IT 업계에 종사하시는 분들이 아니라면, API(Application Programming Interface)라는 단어 자체가 생소할 수 있습니다. 이름은 길지만, 사실 일상적인 비유로 풀면 생각보다 간단하게 이해할 수 있어요.

 

예시를 들어보겠습니다. 레스토랑에 갔을 때 우리는 직접 주방에 들어가 요리하지 않습니다. 당연히 메뉴판을 보고 주문을 하죠. API도 똑같습니다. 시스템 안에 무슨 일이 일어나는지 몰라도, 메뉴판(API 문서)에 적힌 대로 요청만 하면 결과를 받을 수 있습니다.

 

또 하나의 비유는 콘센트와 플러그입니다. 전기는 보이지 않지만, 규격이 맞으면 플러그를 꽂아 전기를 쓸 수 있습니다. API도 마찬가지입니다. 정해진 규격을 통해 데이터를 주고받을 수 있죠.

 

---

 

 

그럼, 어떻게 작동할까?

앱에서 "서울 날씨" 버튼을 눌렀다고 가정해봅시다. 우리 눈에는 그냥 결과만 바뀌는 것 처럼 보이지만, 그 안에서는 이런 일이 벌어집니다.

 

1. Request(요청)

앱이 서버로 "서울 날씨를 알려줘!"라는 메세지를 보냅니다.

이 메세지는 인터넷을 타고, HTTP/HTTPS라는 약속된 언어를 통해 전달됩니다.

• HTTP : 웹에서 주고받는 기본 규칙
• HTTPS : HTTP에 보안을 더한 것(자물쇠가 채워진 통신)

2. Processing(처리)

서버가 데이터베이스를 확인합니다. "서울의 오늘 날씨는 27도, 맑음이구나."

 

3. Response(응답)

서버가 앱으로 결과를 돌려주면, 앱은 이 데이터를 화면에 보여줍니다.

결국 우리가 보는 건 단순한 "화면 변화"이지만, 사실은 그 속에 요청-응답의 대화가 숨어 있는 겁니다.

 

---

 

GET과 POST, 대화 방식의 차이

여기서 조금 더 깊이 들어가보겠습니다. HTTP라는 규칙 안에는 여러 동사(Verb)가 있습니다. 그중에서도 가장 많이 쓰이는 게 GET과 POST에요. 둘 다 서버에 무언가를 요청하는 방식이지만, 쓰임새가 다릅니다.

 

GET - 정보를 가져올 때

GET은 조회용입니다. 이미 서버에 있는 데이터를 그냥 "읽어오기"만 하죠. 즉, 서버의 상태를 바꾸지 않고, 그냥 "지금 가지고 있는 정보"를 요청하는 것입니다. 예를 들어, 서울 날씨를 보고 싶다고 해봅시다. 이럴 때는 GET 요청을 보냅니다.

# Request(요청)

GET /weather?city=seoul HTTP/1.1
Host: api.example.com

# Response(응답)

{
  "city": "Seoul",
  "temp": 27,
  "condition": "sunny"
}

해당 요청을 받으면 서버는 날씨 데이터베이스에서 서울 정보를 찾아서 응답을 줍니다. 여기서 중요한 건, 내가 단순히 날씨 정보를 조회했을 뿐 서버의 데이터는 바뀌지 않았다는 점입니다.

 

POST - 새로운 걸 생성하거나 처리할 때

POST는 단순 조회가 아니라, 무언가를 새로 등록하거나 행동을 요청할 때 씁니다. 즉, 서버의 상태를 바꾸는 요청이죠. 예를 들어, 오늘 점심 도시락 주문을 넣는 상황을 생각해봅시다. 이때는 POST 요청으로 주문 데이터를 서버에 보냅니다.

POST /order HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "menu": "김치찌개",
  "count": 2
}

{
  "orderId": 1234,
  "status": "confirmed"
}

서버는 이 요청을 처리하고, 새로운 주문을 만들어서 응답을 줍니다. 이 경우는 단순 조회가 아니라, 실제로 서버에 새로운 데이터(주문)가 추가된 겁니다.

 

개인적으로는 HTTP 메서드(GET/POST)가 DB의 CRUD와 상당히 유사하다고 생각했는데요, 추가적인 사항을 표로 정리했습니다.

SQL (DB)	의미	HTTP 메서드 (API)	설명
CREATE	데이터 생성	POST	새로운 데이터를 등록할 때
READ (SELECT)	데이터 조회	GET	데이터를 불러올 때
UPDATE	데이터 수정	PUT (전체 교체) / PATCH (부분 수정)	기존 데이터를 변경할 때
DELETE	데이터 삭제	DELETE	데이터를 제거할 때

* CRUD(Create, Read, Update, Delete)는 데이터베이스에서 데이터를 다루는 4가지 기본 동작을 뜻합니다.

 

원리는 비슷하지만, DB에서의 CRUD는 "데이터와 직접 대화"라면, HTTP의 메서드는 "서버와 메뉴판을 통해 대화"하는 방식인거죠.

 

---

 

HTTPS는 어떻게 안전할까?

두괄식으로 먼저 말씀드리자면, HTTP와 달리 HTTPS가 안전한 이유는 단순한 암호화 때문이 아니라 인증서와 CA 덕분에 "진짜 서버와 대화하고 있다"라는 것을 보장받기 때문입니다. HTTP는 편지 엽서라고 생각하시면 되는데요, 우리가 "서울 날씨 알려줘" 요청을 보내면 이 요청이 인터넷을 타고 여러 서버와 라우터를 거져 전달됩니다. 문제는 이 내용이 암호화되지 않은 평문이라는 거예요. 즉, 중간에 누가 훔쳐보면 "GET/weather?city=seoul" 같은 내용이 그대로 노출됩니다.

 

날씨 요청은 개인 정보가 아니지만, 만약 로그인/비밀번호/카드번호 같은 민감한 정보인 경우 문제가 발생할 수 있죠. 심지어 중간에서 내용을 바꿔치기 하는 것도 가능합니다. 내가 서울 날씨를 요청했는데, 누군가 부산 날씨로 바꿔치기 할 수도 있죠. 이게 HTTP의 치명적인 단점입니다.

 

---

HTTPS의 원리 : TLS

이러한 단점을 해결하기 위해, HTTP에 보안(SSL/TLS)을 입힌 버전(HTTPS)를 활용합니다.

작동 원리는 HTTP와 똑같이 GET/POST 같은 요청/응답이지만, 그 내용이 전부 암호화돼서 오갑니다.

 

핵심은 TLS Handshake라는 과정이에요.

 

1. 클라이언트(브라우저)가 서버에게 "너 진짜 맞아?" 하고 신분을 확인합니다.
2. 서버는 인증서(SSL 인증서)를 내밀고, 브라우저는 공인된 기관(CA)을 통해 신뢰성을 확인합니다.
3. 둘은 어떤 암호화 방식을 쓸지 합의합니다.
4. 이후에는 두 쪽만 아는 비밀키(대칭키)를 공유합니다.
5. 이제부터 주고받는 모든 GET/POST 요청은 암호화되어, 중간에서 엿보더라도 의미 없는 암호문으로만 보입니다.

 

갑자기 알 수 없는 용어들이 굉장히 많이 나왔는데요, 하나씩 같이 살펴볼까요?

 

---

SSL 인증서란?

SSL 인증서는 쉽게 말해 서버의 신분증이에요. 우리가 브라우저로 https://www.naver.com에 접속했을 때, 네이버 서버는 "나는 진짜 네이버야!"라는 증명서를 제시합니다. 이 증명서에는 서버 도메인 이름, 발급자, 만료일, 공개키(public key) 등이 들어 있습니다. 브라우저는 이 인증서를 확인하고, 신뢰할 만한 기관이 발급한 것인지 검증합니다.

 

즉, 인증서가 있으면 중간에 가짜 서버가 끼어들어도 쉽게 속지 않습니다. 내가 보낸 비밀번호가 진짜 네이버로 가는지, 아니면 가짜 서버로 새어나가는지를 확인하는 역할이죠. 

 

 

---

TLS?

원래는 SSL(Secure Sockets Layer)라는 이름으로 시작했는데, 취약점이 발견되면서 개선된 버전이 TLS(Transport Layer Security)에요. 현재 우리가 쓰는 건 사실상 TLS 인증서입니다. 다만, 사람들이 습관적으로 아직도 SSL 인증서라고 부르는 거에요. 즉, 둘다 보안 프로토콜의 일종이지만 TLS가 SSL의 개선된 버전이라고 생각하시면 됩니다.

 

---

CA?

CA는 말 그대로 공인된 증명서 발급기관이에요. 서버가 자기 스스로 "나는 진짜 네이버다" 라고 주장하면 아무도 못 믿겠죠? 그래서 제 3자인 CA가 서버의 신원을 확인한 뒤 인증서를 발급합니다. 브라우저와 운영체제(OS)는 이미 신뢰할 수 있는 CA 목록을 내장하고 있습니다. 따라서 서버가 제시한 인증서가 해당 목록에 있는 CA가 발급한 것이라면 신뢰하는 프로세스에요.

 

---

TLS는 TCP 3-Way Handshake와 유사한 개념 아닌가요?

Handshake라는 용어를 보니 TCP에서 활용되는 3-Way Handshake와 유사한 개념인가? 라는 생각이 들더라고요. 하지만 관련된 사항을 찾아보니, 전혀 다른 프로세스였습니다. 정보통신 관련 사항은 포스팅의 메인 주제는 아니니, 가볍게 정리하고 넘어가도록 하겠습니다.

 

TCP 3-Way Handshake

• 네트워크 연결을 맺는 과정
• 전화기가 서로 연결됐는지 확인하는 단계
• 보안과는 전혀 무관

TLS Handshake(HTTPS)

• 이미 연결된 통로 위에서, 우리끼리 암호 언어를 정하자는 협상
• 서버 신분 확인(인증서), 암호화 방식 결정, 대칭키 공유
• 이후 모든 HTTP 요청/응답이 암호화

 

이번 포스팅에서는 API의 정의 및 원리에 대해서 알아보았습니다. 글이 너무 길어져서, 다음 포스팅에서 API의 종류 및 적용 가능 범위에 대해서 소개드릴 수 있도록 하겠습니다. 오늘도 방문해주셔서 감사합니다 :)