API (응용 프로그래밍 인터페이스)
쉽게 풀면
식당에서 손님은 주방에 직접 들어가지 않고 메뉴판을 보고 종업원에게 주문합니다. 종업원은 정해진 방식으로 주문을 받아 주방에 전달하고, 완성된 음식을 다시 손님에게 가져다줍니다. API는 바로 이 "종업원"과 같습니다.
프로그램 A가 프로그램 B의 내부 코드를 몰라도, API가 정한 형식대로 요청을 보내면 B가 처리한 결과를 돌려받을 수 있습니다. 그래서 개발자들은 남이 만든 복잡한 기능을 처음부터 다시 만들지 않고도 API를 통해 빌려 쓸 수 있습니다.
왜 중요한가
API는 여러 시스템을 연결해 재사용 가능한 연구·서비스 파이프라인을 구성하는 기본 단위이기 때문에, 컴퓨터과학뿐 아니라 실험을 자동화하는 거의 모든 분야의 논문에서 다뤄집니다.
특히 대규모 언어 모델처럼 직접 학습·구동하기 어려운 자원을 API 호출만으로 활용할 수 있게 되면서, 연구 재현성과 비교 실험의 표준적인 방법론으로 자리 잡았습니다. 또한 여러 기관이 만든 데이터셋이나 도구를 API로 연결하는 방식은 대규모 협업 연구와 실무 시스템 통합 모두에서 핵심적인 역할을 합니다.
핵심 정리
- API(응용 프로그래밍 인터페이스)는 한 소프트웨어가 다른 소프트웨어에 내놓는 기능과 데이터의 호출 규칙입니다. 무엇을, 어떤 형식으로 요청하고, 어떤 형식의 응답을 받는지가 약속의 내용이며, 내부 구현은 감춰 둡니다. 모듈 내부를 숨기고 약속된 접점만 드러내는 생각은 Parnas(1972)의 정보 은닉에서 이어집니다.
- 웹 API의 약속은 보통 다섯 가지로 정리됩니다: 요청을 보내는 주소(엔드포인트), 요청 방식(HTTP 메서드), 조건을 담는 매개변수, 사용 권한을 확인하는 인증(API 키·토큰), 돌려받는 응답 형식(주로 JSON)과 상태 코드입니다. 상태 코드는 HTTP 표준(Fielding 등, 2022)에 정의되어 있고, 예를 들어 404는 요청한 자원이 없음을 뜻합니다. 429는 표준을 보완하는 별도 규격(Nottingham & Fielding, 2012)에 정의된 코드로, 짧은 시간에 요청이 너무 많다는 뜻으로 쓰입니다.
- API는 두 층위에서 말합니다. 라이브러리·운영체제 API는 같은 컴퓨터 안의 함수 호출 규칙이고, 웹 API는 네트워크 너머의 서버와 주고받는 규칙입니다. 웹 API 설계 방식 중에는 REST API와 GraphQL이 자주 거론됩니다.
- 좋은 API의 조건으로는 배우기 쉽고, 잘못 쓰기 어렵고, 한번 공개하면 바꾸기 어려우므로 신중히 설계해야 한다는 점이 꼽힙니다(Bloch, 2006).
- 연구에서는 공공 데이터 수집, 외부 분석 서비스 호출, 서로 다른 시스템 연동에 쓰이며, 재현성을 위해 API 버전, 호출 날짜, 요청 매개변수를 기록합니다.
예시로 보기
가상의 기상 관측 서비스(주소는 예시용)를 호출하는 장면입니다.
| 구분 | 내용(가상의 예) | 설명 |
|---|---|---|
| 요청 | GET https://api.example.org/v1/stations?date=2024-05-01 | “관측소 목록을 2024-05-01 기준으로 달라”는 요청입니다. GET은 조회, 뒤의 date는 매개변수입니다. |
| 인증 | 요청 머리말에 발급받은 키를 첨부 | 키가 없거나 틀리면 접근이 거부됩니다. 키는 공개 저장소에 올리지 않는 것이 일반적인 관례입니다. |
| 응답 | 200 상태 코드와 JSON 본문(관측소 이름, 좌표, 기온 등) | 연구자는 JSON을 표로 바꿔 전처리합니다. |
| 오류 | 429(요청 한도 초과) | 한도가 있는 API는 호출 간격을 두거나 재시도 규칙을 정해야 하며, 이를 방법론에 적습니다. |
이 예에서 연구자는 서버 내부의 데이터베이스 구조를 몰라도 되고, 약속된 요청과 응답만 알면 됩니다. 반대로 서버가 응답 형식을 바꾸면 수집 코드가 깨질 수 있어서 버전 번호(v1)가 중요해집니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| API는 REST를 뜻한다. | REST는 웹 API를 설계하는 한 방식입니다. GraphQL 같은 다른 방식도 있고, 웹과 무관한 라이브러리 API도 API입니다. |
| API는 프로그래밍 언어나 제품 이름이다. | API는 “규칙의 묶음”이며, 같은 규칙을 여러 언어로 구현하거나 호출할 수 있습니다. |
| API에 접속하면 상대 시스템의 내부 구조를 알 수 있다. | API는 오히려 내부를 감추기 위한 접점입니다. 공개된 기능과 데이터만 얻을 수 있습니다. |
| 같은 요청에는 늘 같은 응답이 온다. | 데이터가 갱신되거나 모델·버전이 바뀌면 응답이 달라집니다. 그래서 호출 시점과 버전을 기록합니다. |
| API로 얻은 데이터는 자유롭게 써도 된다. | API마다 이용 약관, 호출 한도, 재배포 조건이 다릅니다. 연구에 쓰기 전에 약관을 확인해야 합니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
국내 학술지 논문에서 이 용어가 쓰인 문장을 그대로 옮겼습니다. 제목·학술지·연도와 원문 링크를 함께 적었습니다.
“구체적으로 데이터는 정부 오픈 API를 통해 수집하였으며, 분석의 용이성을 위해 전처리 과정을 진행하였다.”
머신러닝과 회귀분석 기반의 사회서비스 취약지구 추출을 위한 연구방법론 탐색연구, 한국콘텐츠학회 논문지, 2024 · KCI 한국학술지인용색인 · 원문 보기 ↗
“이를 위해 뉴스 데이터를 크롤링하였고 Naver Clova API와 KR-FinBERT-SC를 활용하여 감정분석을 수행하였으며, 예측의 정확도를 높이기 위해 산출된 감정 점수와 주가지수를 결합하여 딥러닝 모델에 각각 적용하였다.”
감정분석과 GRU 모델 기반의 주가지수 예측 및 분석: 코스피 200 에너지/화학을 중심으로, 한국정보기술학회논문지, 2024 · KCI 한국학술지인용색인 · 원문 보기 ↗
“이에 따라, 빅데이터와 혁신적인 기술의 도입을 반영한 교육 방식의 혁신이 필요하며, 본 연구에서 제안하는 Open API와 데이터 분석 도구를 활용하 는 방법은 회계 교육 관련자들에게 참여형 수업 방식의 새로운 옵션을 제공할 수 있을 것으로 기대된다.”
Open API를 이용한 재무제표분석 교육, 회계저널, 2025 · KCI 한국학술지인용색인 · 원문 보기 ↗
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 연구자가 모델을 직접 설치하지 않고, 정해진 요청 형식으로 서버에 데이터를 보내고 결과를 받아오는 방식으로 실험을 진행했다는 뜻입니다.
생물·지구과학 분야 연구에서는 직접 측정 장비를 설치하는 대신, 정부나 기관이 제공하는 API를 통해 관측 데이터를 자동으로 받아오는 방식이 흔히 쓰입니다. 이 문장은 데이터 수집 단계에서 API가 반복적인 자료 확보를 자동화하는 통로로 사용되었음을 보여줍니다.
의료 정보시스템 연구에서는 서로 다른 기관의 시스템이 데이터를 안전하게 주고받아야 하는데, 이때도 API가 그 연결 규칙 역할을 합니다. 이 예문은 API가 단순 데이터 조회를 넘어 서로 다른 조직 간 시스템 통합에도 쓰인다는 점을 보여줍니다.
조금 더 깊게 보면
논문에서 API를 언급할 때는 흔히 REST API 형식이 함께 등장하는데, 이는 HTTP 요청(GET, POST 등)을 이용해 자원을 주고받는 설계 방식을 뜻합니다.
최근에는 대규모 언어 모델 API처럼 요청 횟수나 처리량에 제한(rate limit)을 두는 경우가 많아, 실험 설계 시 이 제약을 고려했다는 언급이 방법론 절에 자주 등장합니다.
또한 API 응답의 일관성을 확인하기 위해 동일 요청을 여러 번 반복하거나, API 버전 변경으로 인한 결과 재현성 문제를 별도로 논의하는 연구도 있습니다.
주의할 점
API는 특정 프로그래밍 언어나 기술이 아니라 "규칙(인터페이스)" 자체를 가리키는 개념입니다. 웹에서 흔히 쓰이는 방식은 REST라는 설계 원칙을 따르는 경우가 많지만, API 자체는 그보다 훨씬 넓은 개념이며 버전 관리 시스템이나 운영체제 기능 호출에도 API라는 말이 쓰입니다.
헷갈리기 쉬운 용어
API 주변에는 이름이 비슷하거나 함께 쓰이는 용어가 많습니다.
| 용어 | 한 줄 설명 | API와의 관계 |
|---|---|---|
| REST API | 자원을 주소로 나타내고 HTTP 메서드로 다루는 웹 API 설계 방식 | API의 한 종류(설계 방식) |
| GraphQL | 클라이언트가 필요한 데이터 구조를 질의로 명시하는 API용 질의 언어 | API의 한 종류 |
| API 게이트웨이 | 여러 서비스로 가는 요청을 한곳에서 받아 인증·분배하는 중간 서버 | API 앞에 놓이는 관문 |
| 웹훅 | 사건이 일어나면 서버가 미리 등록된 주소로 알림을 보내는 방식 | 요청–응답과 반대로 서버가 먼저 호출하는 형태 |
| SDK | 특정 서비스의 API를 쉽게 쓰도록 만든 도구 모음(라이브러리와 문서) | API를 감싸는 편의 도구 |
참고 문헌
- Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058.
- Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures (doctoral dissertation). University of California, Irvine.
- Bloch, J. (2006). How to design a good API and why it matters. In Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). ACM.
- Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly Media.
- Nottingham, M., & Fielding, R. (2012). Additional HTTP Status Codes (RFC 6585). Internet Engineering Task Force.
- Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP Semantics (RFC 9110). Internet Engineering Task Force.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.