개발자가 말하는 'API', 정확히 무슨 뜻일까? (개념 정리)

“이번 API 명세서 나왔으니 테스트 준비해 주세요.”

목차 숨기기

“이 기능은 API 호출이 너무 느리네요.”

개발팀과 협업하다 보면 ‘API’라는 단어를 하루에도 수십 번씩 듣게 됩니다. 어렴풋이 ‘서버와 통신하는 무언가’라고는 알고 있지만, 정확히 무엇인지 설명하기는 쉽지 않습니다.

QA가 API의 기본 개념을 명확히 이해하면, 개발자와의 소통이 원활해지고 테스트의 깊이가 달라집니다.

API는 ‘Application Programming Interface’의 약자입니다.

‘인터페이스(Interface)’는 ‘서로 다른 두 시스템이 만나고 소통하는 접점’을 의미합니다.

즉, API는 하나의 프로그램이 다른 프로그램의 기능이나 데이터를 요청하고 사용할 수 있도록, 미리 정해놓은 ‘소통 규칙(약속)’입니다.

비유:
- 레스토랑에 간 손님(클라이언트)은 주방(서버)에 직접 들어가 요리법을 보거나 재료를 가져올 수 없습니다.
- 대신, 손님은 ‘메뉴판’을 보고 ‘웨이터’에게 정해진 방식으로 주문을 합니다.
- 이때 ‘웨이터’와 ‘메뉴판’이 바로 API의 역할을 합니다. 손님과 주방 사이의 약속된 소통 창구인 셈이죠.

현대의 거의 모든 웹/앱 서비스는 ‘클라이언트(눈에 보이는 화면)’와 ‘서버(데이터와 로직)’가 분리되어 있기 때문입니다.

그리고 이 둘은 오직 API를 통해서만 대화합니다.

화면에서 버튼을 누르는 모든 행동의 이면에는, 서버에 특정 API를 호출하여 데이터를 요청하거나 변경하는 과정이 숨어있습니다.

따라서 눈에 보이는 화면뿐만 아니라, 그 뒤에서 일어나는 API 통신을 직접 테스트할 수 있어야 서비스의 진짜 품질을 검증할 수 있습니다.

‘REST API’는 현재 웹에서 API를 만드는 가장 널리 사용되는 ‘디자인 스타일’ 중 하나입니다.

‘REST’라는 아키텍처 스타일의 제약 조건을 잘 지켜서 만든 API를 의미합니다.

모든 웨이터의 행동 방식이 똑같지는 않듯이, API를 만드는 방식에도 여러 스타일이 있습니다.

그중 ‘REST’가 가장 보편적인 표준 스타일이라고 생각하면 쉽습니다.

‘REST API’는 보통 다음과 같은 특징을 가집니다.

자원(Resource) 중심:
- 모든 데이터를 ‘자원’으로 보고, 각 자원에 고유한 주소(URI)를 부여합니다.
- 예: https://example.com/users/123 (123번 사용자에 대한 정보)
행위(Verb)는 메서드로 표현:
- 자원에 대한 행동은 HTTP 메서드(GET, POST, PUT, DELETE)로 표현합니다.
- GET: 정보 조회
- POST: 정보 생성
- PUT/PATCH: 정보 수정
- DELETE: 정보 삭제
자기 서술적(Self-descriptive):
- API 요청 메시지 자체만으로도, 이것이 무엇을 하는 요청인지 쉽게 이해할 수 있습니다.

Postman과 같은 API 테스트 도구를 사용합니다.

이 도구들을 이용하면, 화면(UI)을 거치지 않고 직접 ‘웨이터(API)’에게 주문을 요청할 수 있습니다.

테스트 예시:
- ‘GET’ 메서드로 https://example.com/users/123 주소를 호출합니다.
- 서버로부터 123번 사용자의 정보가 JSON 형태로 정확하게 돌아오는지 확인합니다.
- 만약 존재하지 않는 users/999를 호출했을 때, ‘404 Not Found’와 같은 적절한 에러 응답을 주는지도 확인합니다.

QA가 API의 기본 원리를 이해한다는 것은, 서비스의 겉모습 너머에 있는 내부의 동작 방식을 이해하기 시작했다는 의미입니다.

이는 개발자와의 기술적인 소통 수준을 한 단계 높여주고, UI 테스트만으로는 발견할 수 없는 서버 로직의 결함을 찾아낼 수 있게 하는 강력한 무기가 됩니다.

개발자가 말하는 ‘API’, 정확히 무슨 뜻일까? (개념 정리)