개방형 API

왜 배우는가: 개방형 API는 외부 개발자와 기업이 데이터와 서비스를 표준 방식으로 연계하게 해 주는 기술이어서 공공·금융·플랫폼 분야 시스템 설계의 기본이 된다. 2개 회차에 걸쳐 SOAP와 REST의 구조 비교와 보안 대응이 함께 출제되어 정의와 비교를 같이 정리해야 한다.

출제 이력: 제134회 4교시 4번, 제122회 2교시 3번

1. 한 줄 정의와 핵심 키워드

개방형 API는 누구나 또는 인증된 외부 주체가 표준화된 인터페이스로 기능이나 데이터에 접근하도록 공개한 응용 프로그램 인터페이스이다.

• 개방형 API(Open API)
• API(Application Programming Interface)
• SOAP(Simple Object Access Protocol)
• REST(Representational State Transfer)
• 인증·인가
• API 게이트웨이

키워드는 답안 서두와 비교표에서 함께 쓰인다. 정의 문장은 공개 범위와 표준 인터페이스라는 두 조건을 모두 담아야 감점을 피한다.

2. 개념 풀이

쉽게 말하면 개방형 API는 외부에 문을 열어 둔 창구다. 날씨 앱이 기상청 서버의 데이터를 받아 보여 주는 것처럼, 자기 시스템의 데이터나 기능을 다른 시스템이 호출해 쓸 수 있게 공개한 것이다.

정식으로는 인증된 외부 개발자가 표준 방식의 요청과 응답으로 시스템 기능을 사용하도록 제공하는 인터페이스를 말한다. 일반 API가 조직 내부 또는 특정 파트너에게만 쓰이는 것과 달리, 개방형 API는 등록 절차를 거쳐 누구나 접근할 수 있도록 문서화되어 공개된다.

API는 소프트웨어 구성 요소가 서로 상호작용하도록 정한 규칙과 메커니즘의 집합이다. 추상화와 모듈화를 제공해 개발자가 내부 구현을 몰라도 기능을 쓰게 한다.

인증·인가는 호출하는 주체가 누구인지 확인하고(인증), 그 주체가 어떤 자원에 접근할 수 있는지 정하는(인가) 절차다. 개방형 API에서는 이 두 기능이 없으면 외부 공개 자체가 보안 사고로 이어진다.

SOAP는 HTTP 같은 전송 프로토콜 위에서 XML 메시지를 교환하는 프로토콜이고, REST는 HTTP 원리를 따라 자원(리소스)을 URI로 식별해 다루는 아키텍처 스타일이다. 두 방식은 같은 목적을 가지지만 규약의 무게가 다르다.

3. 등장 배경과 필요성

초기 웹은 학술 논문 교환과 문서 열람이 주된 용도였다. 웹의 용도가 다양해지면서 프로그램이 웹 자원을 자동으로 처리해야 하는 요구가 생겼고, 이를 위해 웹 서비스와 API가 발전했다.

2000년대 초에는 SOAP와 REST의 우열을 두고 논쟁이 이어졌다. 이 과정에서 SOAP는 WS-Security, WS-Transaction 등 부가 스펙이 난립해 복잡해졌고, Web 2.0과 함께 매시업(Mashup)에 유리한 REST가 점점 많이 쓰였다. 이 흐름에서 API 분야는 REST가 주류가 되었다. REST 이용 비율 80%은 그 자료 한 건에 근거한 수치이므로 답안에서 일반화하지 않는다.

필요성은 세 가지로 정리된다. 첫째, 기업 내부 자원을 외부와 연계해 데이터 공유와 서비스 확장을 가능하게 한다. 둘째, 모듈화와 재사용으로 개발 생산성을 높인다. 셋째, 이기종 시스템 사이의 상호운용성을 확보한다. 공공 데이터 개방과 금융 결제 연계가 대표적인 활용 예다.

개방은 곧 노출이므로 보안 설계가 함께 필요하다. 이 내용은 2026년 자료로, 최근 쟁점으로 다룬다.

4. 구성요소·원리·절차

개방형 API는 네 부분으로 나뉜다. 백엔드 시스템은 데이터와 업무 로직을 가진다. API 게이트웨이는 외부 호출이 들어오는 단일 진입점이다. 개발자 포털은 키 발급과 명세 공개를 맡고, 외부 애플리케이션은 호출 주체가 된다. 이 구성의 목적은 백엔드를 외부에 직접 노출하지 않고 공개 범위와 권한을 통제하는 데 있다.

게이트웨이를 중심에 두는 이유는 보안 정책을 한곳에서 적용하기 위해서다. 인증, 호출 제한, 로깅이 모두 여기서 처리되므로 백엔드마다 같은 기능을 중복 구현할 필요가 없다. 개발자 포털은 공개 명세와 발급 절차를 맡아 외부 개발자의 진입 장벽을 낮춘다.

API 게이트웨이는 외부 호출의 단일 진입점으로서 인증·제한·로깅을 한곳에서 적용한다.

자원 중심 설계와 무상태(Stateless)가 REST 방식의 핵심 원리다. 자원은 URI로 식별하고, 요청마다 인증 정보를 포함시키며, 서버는 이전 요청의 상태를 저장하지 않는다. 그 결과 게이트웨이를 여러 대로 늘려도 어느 서버가 요청을 받든 같은 결과를 낸다.

SOAP 방식은 원리가 다르다. SOAP 메시지는 Envelope, Header, Body를 기본으로 하며 Encoding Rule과 RPC Representation을 더한 5가지 요소로 구성된다. 서비스 계약은 WSDL로 기술한다. 메시지 단위의 보안과 트랜잭션 처리를 메시지 안에 담을 수 있다는 것이 장점이다. 반면 메시지가 무거워 공개 API에서는 REST가 더 많이 선택되었다.

인증 흐름은 다음과 같다. 외부 개발자는 인증 서버에서 액세스 토큰을 먼저 받는다. 이후 API 요청마다 토큰을 HTTP 헤더에 실어 보낸다. 게이트웨이는 토큰의 유효성과 권한 범위를 확인한 뒤에만 백엔드로 요청을 전달한다. 토큰 발급과 검증을 분리하면 백엔드는 인증 로직을 알 필요가 없다.

개방형 API의 처리 절차는 다음 순서다.

• 공급자가 제공할 자원과 기능을 정의하고 명세(OpenAPI 등)를 작성한다.
• 개발자 포털에 명세를 공개하고 외부 개발자 등록을 받는다.
• 개발자에게 인증 키 또는 OAuth 2.0 클라이언트를 발급한다.
• 게이트웨이가 토큰 검증, 호출량 제한, 입력값 검사를 수행한 뒤 백엔드로 전달한다.
• 백엔드 응답을 돌려주고 호출 로그를 남긴다.
• 호출 지표를 모니터링하고 버전을 관리하며, 폐기 시 예고 기간을 둔다.

절차 4번의 검사 단계가 보안 취약점 대응의 출발점이다. 취약점별 대응 방안은 다른 절에서 다룬다.

5. 관련 법령·기준·표준

개방형 API에 직접 적용되는 단일 기준은 없다. 인증, 전송, 메시지 형식, 데이터 개방 근거가 서로 다른 기준에 흩어져 있다. 설계와 점검에는 아래 기준을 함께 쓴다.

OAuth 2.0은 IETF RFC 6749로 정의된 인가 프레임워크다. 외부 개발자에게 자원 접근 권한을 위임하는 표준 방식이며, 개방형 API의 인증 기준으로 가장 많이 쓰인다.

SOAP 메시지의 최상위 구성은 Envelope, Header, Body로 보며, 여기에 Encoding Rule과 RPC Representation이 더해진 5가지 요소로 구성된다. SOAP 명세는 W3C 권고안으로 SOAP 1.1과 1.2가 있다. 두 판의 세부 차이는 설계 시 확인해야 한다.

HTTP 응답 코드는 2xx 성공, 4xx 클라이언트 오류, 5xx 서버 오류로 구분된다. 게이트웨이는 인증 실패와 호출 제한 초과를 4xx로 돌려주어 외부 개발자가 원인을 알 수 있게 한다.

「공공데이터의 제공 및 이용 활성화에 관한 법률」은 공공기관 데이터 개방의 근거 법률이다. 「개인정보 보호법」은 전송·저장 시 안전조치 의무를 규정한다. 공공 API는 두 법을 함께 검토해 공개 범위를 정한다. 기관별 지침이 추가로 적용될 수 있으므로 소관 기관 기준을 함께 확인한다.

연혁으로 보면 SOAP는 초기에 Simple Object Access Protocol로 불렸으나 이후 SOAP로 명칭이 정리되었다. 2000년 무렵 REST가 아키텍처 스타일로 정리된 뒤 SOAP와 REST의 논쟁이 이어졌고, 공개 API에서는 REST가 주류가 되었다.

6. 유형과 비교

개방형 API는 구조 방식에 따라 SOAP 기반과 REST 기반으로 나뉜다. 두 방식은 메시지 형식, 전송 방식, 상태 관리에서 차이가 크므로 답안에서는 항목별 비교표로 정리한다. 실무에서는 SOAP이 보안·트랜잭션 요구가 큰 금융·공공 연계에 쓰이고, REST가 모바일·웹 플랫폼의 기본 방식으로 쓰인다.