[25.04.08] TIL - 내부 / 외부 API 구분하는 이유?

내부 API

조직 내 내부 시스템, 서비스 또는 애플리케이션 간의 통신을 위해 설계되었다

내부 사용자 및 시스템으로만 제한되며, 외부에 노출되지 않는다

특징

• 보안 : 외부에 노출되지 않아 상대적으로 보안이 강화된다
• 속도 : 내부 네트워크 환경에서 작동하므로 속도가 빠르다
• 변경 자유도 : 외부 의존성이 없기 때문에 자유롭게 수정 가능하다
• 예시 : MSA 아키텍처에서 서비스 간 통신 (예: 예약 서비스 ↔ 유저 서비스)

외부 API

외부 사용자(고객, 파트너 등)가 기능/데이터에 접근할 수 있도록 설계되었다

특징

• 보안 및 인증 필수: OAuth, API Key 등의 보안 조치가 필요하다
• 버전 관리 중요 : 외부에 영향을 주므로 신중하게 변경해야 한다
• 문서화 필수 : Swagger, Postman, OpenAPI 등으로 문서 제공한다
• 예시 : 카카오 로그인 API, 구글 맵 API, 결제 API 등

 

https://system-craft-newbie.tistory.com/22

 

 

 

-> 내부 API는 조직 내부의 효율성과 보안을 중심으로 구성되고, 외부 API는 확장성과 공개 보안을 고려하여 설계된다.

 

따라서, API는 목적에 따라 구분하고, 각 API에 맞는 인증 및 보안 관리 정책을 설계하여햐 한다.

이전에 프로젝트에서, FeignClient를 사용하여 외부 API로부터 데이터를 받아오는 방식을 구현했던 경험이 있다.

그러나 당시에는, 내부 API와 외부 API를 구분하지 않고 외부API를 그대로 내부 시스템에서 사용하는 구조로 설계되었다.

---

✅ 내부/외부 API를 분리해야되는 이유?

만약에 분리하지 않는다면 몇 가지 문제점이 발생

1. 외부 API가 변경 되면, 내부 도메인까지 영향을 받음
   • 외부 API의 응답 구조나 스펙이 변경이 되면, 이를 직접 사용하는 내부 서비스의 DTO나 로직에도 수정이 필요하게 된다
2. 비즈니스 로직과 외부 API가 강하게 결함되어 유지보수성과 변경 대응이 어려워짐
   • 외부 API 호출 로직이 내부 비즈니스 로직에 직접 포함되면, 해당 API에 대한 변경이나 장애가 비즈니스 로직 자체의 안정성을 해치게 된다 
   • 그리고 의존성과 결합도가 높아질수록, 하나의 API 문제로 전체 시스템에 장애가 발생할 수 있다
   • 이러한 구조는 대규모 MSA 구조에서 큰 문제가 될 수 있다
3. API 변경이 서비스 전체에 영향을 미침
   • 외부 API가 변경 되면, 이와 직접적으로 연결된 모든 내부 서비스에 영향을 미친다. 
   • 이는 서비스간 결합도를 높이고, 장애 전파 범위를 넓히는 결과를 초래한다.

-> 즉, 내부/외부 API를 분리하면 안정성, 확장성, 유지보수성 측면에서 큰 이점을 얻을 수 있다