API 서버

클라이언트 어플리케이션이 데이터베이스에 직접 접근하지 않고, 규격화된 프로토콜을 통해 안전하게 데이터를 교환할 수 있도록 중계하는 비즈니스 로직 서버.

— 로이 필딩의 REST 가이드 아키텍처 논문

"프론트엔드가 요구하는 온갖 포맷의 가공 데이터를 만들어 바치는 노예 기계. 가끔 DB가 터지면 독박을 뒤집어쓴다." ~~REST API 규격대로 이쁘게 짜놨더니 프론트엔드가 귀찮다며 쿼리 하나로 다 달라고 떼를 쓴다.(...)~~

1. 개요

프론트엔드(클라이언트)가 데이터베이스(Database)에 직접 접속해 데이터를 변조하는 보안 대참사를 막고, 중간에서 비즈니스 로직 검증, 인증/인가, 데이터 가공 등을 전담하는 백엔드 코어 시스템이다. 주로 REST API 규격이나 GraphQL 규격을 채택하여 JSON 형태로 데이터를 소통한다.(...)

2. 로이 필딩의 통곡과 가짜 REST API의 범람

현대 백엔드 생태계에서 대부분의 API 서버는 '우리는 RESTful한 API를 제공합니다'라고 이력서와 도큐먼트에 대대적으로 자랑질을 해댄다. 하지만 REST 아키텍처의 창시자인 로이 필딩이 정립한 하이퍼미디어 조건(HATEOAS)을 완벽히 충족하는 진짜 REST API 서버는 지구상에 거의 존재하지 않는다.(...) 실상은 그저 URI 주소창에 대충 명사 몇 개 던져놓고, 데이터 조회·수정·삭제를 모조리 HTTP POST 메서드 하나로 통일해 찔러넣는 '무늬만 REST인 JSON 셔틀 서버'가 대다수다. 정작 규격을 깐깐하게 지키자니 프론트와 백엔드 둘 다 코딩 노가다가 심해져서 적당히 타협하고 살고 있는 것이 업계의 공공연한 비밀이다.¹

3. 관련 밈 및 드립

3.1. Internal Server Error

API 서버 개발자의 자존심을 무참히 짓밟고 프론트 개발자의 한숨을 자아내는 최악의 에러 코드다. 서버 내부에서 코드가 돌다가 예외 처리(NullPointerException)를 안 해서 터졌는데, 에러 원인을 클라이언트에게 친절히 알려주기 싫거나 개발자 본인도 왜 터졌는지 모를 때 무조건 이 500번 코드로 퉁쳐서 뱉어버린다. 프론트엔드가 '서버 터졌는데요'라고 제보하면 백엔드는 허겁지겁 리눅스 터미널을 열고 로그를 긁어내는 똥쇼를 시작해야 한다.

3.2. 스웨거(Swagger)가 문서인데요

API 명세서 쓰기 귀찮아하는 백엔드 개발자들의 마법의 방패다. '여기 API 주소랑 스펙 정리된 문서 어딨나요?'라고 물어보면 코드에 어노테이션 몇 개 달아놓고 자동 생성된 Swagger 주소 딸랑 던져준 뒤 '여깄는데요' 하고 도망치는 현상을 말한다. 가끔 코드가 바뀌었는데 Swagger 갱신이 안 되어 프론트엔드가 엉뚱한 필드 명으로 요청을 날리다 삽질하는 해프닝이 흔하다.

4. 여담

CORS 지옥: API 서버를 처음 만들고 프론트엔드와 연결할 때 백퍼센트 확률로 마주하는 거대한 벽이다. 브라우저의 보안 정책 때문에 도메인이 다르면 요청을 막아버리는데, 백엔드 설정 파일에 허용 도메인을 와일드카드(*)로 박아두었다가 보안 심사 때 시니어에게 털린다.
익스프레스(Express) 대 스프링(Spring): 가볍게 뚝딱 자바스크립트로 짜는 Node.js 기반 Express 계열과, 장엄한 객체지향 디자인 패턴과 아키텍처의 끝판왕인 Java 기반 Spring Boot가 시장에서 끊임없이 대립한다. 물론 엔터프라이즈 거대 시장은 압도적으로 스프링의 영토다.
서버리스(Serverless)의 역습: 2026년 현대에는 서버 24시간 켜놓고 월세(호스팅) 내는 대신, 요청이 올 때만 잠깐 가상 함수를 실행해 주는 AWS Lambda 같은 서버리스 API 아키텍처로 넘어가 비용을 극한으로 아끼는 빌드가 활성화되었다.

5. 관련 문서

실제로 이 묵시적 합의 하에 돌아가는 API 서버는, 프론트엔드 화면의 컴포넌트 구조가 조금만 바뀌어도 그에 맞춰 JSON 데이터 필드 명을 또 수정해 줘야 하는 무한 수정 뫼비우스의 띠에 빠진다.(...) ↩