내부 API
조직 내 내부 시스템, 서비스 또는 애플리케이션 간의 통신을 위해 설계되었다
내부 사용자 및 시스템으로만 제한되며, 외부에 노출되지 않는다
특징
- 보안 : 외부에 노출되지 않아 상대적으로 보안이 강화된다
- 속도 : 내부 네트워크 환경에서 작동하므로 속도가 빠르다
- 변경 자유도 : 외부 의존성이 없기 때문에 자유롭게 수정 가능하다
- 예시 : MSA 아키텍처에서 서비스 간 통신 (예: 예약 서비스 ↔ 유저 서비스)
외부 API
외부 사용자(고객, 파트너 등)가 기능/데이터에 접근할 수 있도록 설계되었다
특징
- 보안 및 인증 필수: OAuth, API Key 등의 보안 조치가 필요하다
- 버전 관리 중요 : 외부에 영향을 주므로 신중하게 변경해야 한다
- 문서화 필수 : Swagger, Postman, OpenAPI 등으로 문서 제공한다
- 예시 : 카카오 로그인 API, 구글 맵 API, 결제 API 등

-> 내부 API는 조직 내부의 효율성과 보안을 중심으로 구성되고, 외부 API는 확장성과 공개 보안을 고려하여 설계된다.
따라서, API는 목적에 따라 구분하고, 각 API에 맞는 인증 및 보안 관리 정책을 설계하여햐 한다.
이전에 프로젝트에서, FeignClient를 사용하여 외부 API로부터 데이터를 받아오는 방식을 구현했던 경험이 있다.
그러나 당시에는, 내부 API와 외부 API를 구분하지 않고 외부API를 그대로 내부 시스템에서 사용하는 구조로 설계되었다.
✅ 내부/외부 API를 분리해야되는 이유?
만약에 분리하지 않는다면 몇 가지 문제점이 발생
- 외부 API가 변경 되면, 내부 도메인까지 영향을 받음
- 외부 API의 응답 구조나 스펙이 변경이 되면, 이를 직접 사용하는 내부 서비스의 DTO나 로직에도 수정이 필요하게 된다
- 비즈니스 로직과 외부 API가 강하게 결함되어 유지보수성과 변경 대응이 어려워짐
- 외부 API 호출 로직이 내부 비즈니스 로직에 직접 포함되면, 해당 API에 대한 변경이나 장애가 비즈니스 로직 자체의 안정성을 해치게 된다
- 그리고 의존성과 결합도가 높아질수록, 하나의 API 문제로 전체 시스템에 장애가 발생할 수 있다
- 이러한 구조는 대규모 MSA 구조에서 큰 문제가 될 수 있다
- API 변경이 서비스 전체에 영향을 미침
- 외부 API가 변경 되면, 이와 직접적으로 연결된 모든 내부 서비스에 영향을 미친다.
- 이는 서비스간 결합도를 높이고, 장애 전파 범위를 넓히는 결과를 초래한다.
-> 즉, 내부/외부 API를 분리하면 안정성, 확장성, 유지보수성 측면에서 큰 이점을 얻을 수 있다
'TIL' 카테고리의 다른 글
| [25.04.22] TIL - Docker 로 DB 연결시 발생한 오류(FATAL: role "..." does not exist) (0) | 2025.04.23 |
|---|---|
| [25.04.11] TIL - 깃허브 default 브랜치 바꾸는 방법, 이유 (0) | 2025.04.11 |
| [25.04.06] TIL - Building a Scalable Notification Service(확장 가능한 알림 서비스 만들기) (0) | 2025.04.06 |
| [25.04.02] TIL - 웹 서버와 웹 어플리케이션 서버의 차이? (0) | 2025.04.03 |
| [25.03.30] TIL - 변수 네이밍 (0) | 2025.03.30 |