프로그래밍이나 웹사이트를 공부하다 보면 ‘서버’와 ‘API’라는 말을 정말 자주 보게 된다. 그런데 초보자일수록 이 둘을 비슷한 것으로 착각하기 쉽다. 특히 “API 서버”, “서버에서 API를 만든다” 같은 표현을 보면 더 헷갈린다.
나도 처음에는 API가 서버의 다른 이름인 줄 알았다. 그런데 직접 웹사이트를 만들고, 로그인 기능이나 날씨 정보를 가져오는 기능을 만들어보면서 서버와 API는 완전히 다른 개념이라는 것을 알게 됐다.
결론부터 말하면, 서버는 데이터를 저장하고 기능을 처리하는 컴퓨터이고, API는 그 서버와 대화하기 위한 방법이다.
쉽게 말하면 서버는 식당의 주방이고, API는 주문을 받는 직원과 메뉴판이다. 주방이 실제로 음식을 만들고 처리한다면, 직원은 손님의 요청을 주방에 전달하고 결과를 다시 가져다준다.
서버는 실제로 일을 하는 컴퓨터다
서버는 데이터를 저장하고, 요청을 처리하고, 결과를 보내주는 컴퓨터다.
예를 들어 쇼핑몰 사이트를 생각해보자. 사용자가 로그인 버튼을 누르면, 서버는 아래와 같은 일을 한다.
- 아이디와 비밀번호 확인하기
- 회원 정보를 데이터베이스에서 찾기
- 로그인 성공 여부 판단하기
- 결과를 다시 화면으로 보내기
즉, 서버는 실제로 일을 하는 공간이다.
서버 안에는 보통 아래와 같은 것들이 있다.
- 웹사이트 파일
- 회원 정보
- 데이터베이스
- 프로그램 코드
예를 들어 유튜브 서버는 영상 데이터를 저장하고, 인스타그램 서버는 사진과 댓글을 저장한다. 그리고 사용자가 요청하면 그 데이터를 찾아서 보내준다.
나도 처음에는 서버를 그냥 “큰 컴퓨터” 정도로만 생각했다. 하지만 직접 Apache를 설치하고, 내 서버 안에 HTML 파일을 넣어보니, 서버는 실제로 무언가를 저장하고 처리하는 역할이라는 것을 더 쉽게 이해할 수 있었다.
API는 서버에게 요청하는 방법이다
API는 서버 그 자체가 아니라, 서버와 대화하는 규칙이나 창구다.
예를 들어 날씨 앱을 만든다고 해보자. 내 앱에는 실제 날씨 정보가 없다. 대신 기상청이나 다른 회사의 서버에게 “오늘 서울 날씨 알려줘”라고 요청해야 한다.
이때 사용하는 것이 API다.
예를 들어 아래처럼 요청할 수 있다.
https://weather.example.com/api/today?city=Seoul
그러면 서버는 아래처럼 결과를 보내준다.
{ "temperature": 18, "weather": "맑음" }
즉, API는 “서울 날씨를 알려줘”라고 요청하는 방법이고, 서버는 실제로 날씨 정보를 가지고 있다가 답을 보내주는 존재다.
쉽게 비유하면 API는 식당의 메뉴판과 주문 방식이다. 손님은 메뉴판을 보고 “김치찌개 주세요”라고 말한다. 그러면 직원이 주방에 전달하고, 주방이 음식을 만든다.
여기서:
- 주방 = 서버
- 메뉴판과 주문 방식 = API
즉, API는 서버와 연결해주는 통로다.
왜 서버와 API를 자꾸 헷갈릴까
초보자가 서버와 API를 헷갈리는 가장 큰 이유는, API가 보통 서버 안에 있기 때문이다.
예를 들어 아래처럼 말하는 경우가 많다.
내 서버에 API를 만들었다
이 말은 서버 안에 “사용자가 요청할 수 있는 창구”를 만들었다는 뜻이다.
예를 들어 쇼핑몰 서버 안에 아래 같은 API가 있을 수 있다.
- /login → 로그인 요청
- /product → 상품 목록 요청
- /order → 주문 요청
즉, API는 서버 안에 존재하는 여러 “입구” 같은 것이다.
그래서 사람들은 API와 서버를 비슷하게 느끼지만, 정확히 말하면 API는 서버가 아니라 서버를 사용하는 방법이다.
실제로는 서버 하나에 API가 여러 개 있다
하나의 서버 안에는 보통 여러 API가 있다.
예를 들어 인스타그램 서버에는 아래와 같은 API가 있을 수 있다.
- 로그인 API
- 게시물 불러오기 API
- 댓글 작성 API
- 좋아요 API
사용자가 앱에서 버튼을 누를 때마다, 앱은 서버의 특정 API를 호출한다.
예를 들어 좋아요 버튼을 누르면:
POST /like
그리고 댓글을 불러올 때는:
GET /comments
즉, 서버는 하나지만, 그 안에는 역할별로 여러 API가 있는 것이다.
나도 처음에는 API가 하나의 프로그램인 줄 알았다. 그런데 실제로는 서버 안에 로그인용, 회원가입용, 상품조회용 API가 따로 있다는 것을 보고 훨씬 이해가 쉬워졌다.
서버가 없으면 API도 존재할 수 없다
API는 서버 없이 혼자 존재할 수 없다. 왜냐하면 API는 결국 서버에게 요청하는 방법이기 때문이다.
예를 들어 아래처럼 날씨 API 주소가 있다고 해보자.
https://weather.example.com/api/today
그런데 만약 뒤에 있는 서버가 꺼져 있다면, API도 작동하지 않는다.
즉, API는 결국 서버에 연결되어 있어야 한다.
그래서 “API 서버가 다운됐다”는 말은, 정확히는 API를 제공하는 서버가 꺼졌다는 뜻이다.
반대로 서버는 API 없이도 존재할 수 있다. 예를 들어 단순히 파일만 저장하는 서버나, 웹사이트 화면만 보여주는 서버도 있다.
프론트엔드와 API는 어떻게 연결될까
프론트엔드는 보통 API를 통해 서버와 연결된다.
예를 들어 로그인 버튼을 누르면:
- 프론트엔드가 아이디와 비밀번호를 받는다.
- API를 통해 서버에 전달한다.
- 서버가 확인한다.
- 결과를 다시 API로 보내준다.
- 프론트엔드가 “로그인 성공”을 화면에 보여준다.
즉, 프론트엔드는 서버와 직접 대화하는 것이 아니라, API라는 창구를 통해 대화한다.
실제로는 아래와 같은 흐름이다.
사용자 → 프론트엔드 → API → 서버 → 데이터베이스
그리고 다시:
데이터베이스 → 서버 → API → 프론트엔드 → 사용자
그래서 프론트엔드 개발자도 API를 자주 사용하고, 백엔드 개발자는 API를 직접 만드는 경우가 많다.
서버와 API 차이를 가장 쉽게 정리하면
| 구분 | 서버 | API |
|---|---|---|
| 무엇인가? | 실제로 일을 하는 컴퓨터 | 서버와 대화하는 방법 |
| 역할 | 데이터 저장, 처리 | 요청과 응답 전달 |
| 쉽게 비유하면 | 식당의 주방 | 메뉴판과 주문 방식 |
| 예시 | 유튜브 서버, 쇼핑몰 서버 | /login, /weather, /product |
즉, 서버는 실제로 일을 하는 곳이고, API는 그 서버를 사용하는 방법이다.
처음에는 서버와 API가 비슷하게 느껴질 수 있다. 하지만 “서버는 주방, API는 주문 방법”이라고 생각하면 훨씬 이해하기 쉽다.
그리고 앞으로 “API를 만든다”, “API 서버를 연결한다” 같은 말을 들으면, “아, 서버 안에 있는 특정 기능과 연결하는구나”라고 생각하면 된다.