“BFF vs API Gateway”는 마이크로서비스 아키텍처에서 가장 혼동되는 대결 중 하나입니다. 두 패턴은 다이어그램상으로 비슷해 보입니다. 둘 다 서비스 앞에 위치합니다. 둘 다 클라이언트 요청을 받아 백엔드로 전달합니다. 따라서 팀들은 이 둘이 경쟁하는 선택지라고 가정하고, 하나를 선택한 후 잘못된 책임을 거기에 욱여넣게 됩니다.
이들은 경쟁자가 아닙니다. BFF(Backend for Frontend)와 API 게이트웨이는 다른 문제를 해결하고, 다른 팀이 소유하며, 동일한 시스템에서 함께 실행되는 경우가 많습니다. BFF는 게이트웨이 대신이 아니라 게이트웨이 뒤 또는 옆에 위치합니다.
이 가이드는 둘의 차이를 명확하게 설명합니다. 각 패턴이 실제로 무엇인지, 어디에서 중복되는지, 언제 하나 또는 둘 다 사용해야 하는지, 그리고 이들을 혼동할 때 발생하는 실수에 대해 배우게 될 것입니다. 이 과정에서 API 계약은 변함없는 상수입니다. 요청이 게이트웨이, BFF 또는 둘 다를 통해 흐르든 상관없이, 각 계층은 여전히 설계, 테스트, 모의(mock), 문서화해야 하는 API를 노출합니다.
API 게이트웨이란 무엇인가?
API 게이트웨이는 클라이언트와 백엔드 서비스 사이에 위치하는 중앙 집중식 진입점입니다. 모든 요청은 게이트웨이를 통해 들어오며, 게이트웨이는 호출을 라우팅하기 전에 일관된 교차 관심사 집합을 적용합니다.
이러한 관심사는 모든 클라이언트와 모든 서비스에 대해 동일합니다:
- 라우팅: 들어오는 경로를 올바른 업스트림 서비스에 일치시킵니다.
- 인증 및 권한 부여: 토큰을 검증하고, 승인되지 않은 호출자를 거부합니다.
- 요청 제한 및 스로틀링: 과부하 및 오용으로부터 백엔드를 보호합니다.
- 관측 가능성: 요청을 로깅하고, 메트릭을 내보내고, 서비스 전반의 호출을 추적합니다.
- TLS 종료, 캐싱, 요청 변환: 한 번에 한 곳에서 복잡한 부분을 처리합니다.
게이트웨이의 특징은 범용적이고 중앙에서 소유한다는 것입니다. 플랫폼 또는 인프라 팀이 운영하며, 모든 클라이언트에게 동등하게 서비스를 제공합니다. 호출자가 모바일 앱이든, 웹 SPA든, 파트너 통합이든 신경 쓰지 않으며, 모든 사람에게 동일한 정책을 적용합니다.
이로 인해 게이트웨이는 조직 전체의 규칙을 위한 자연스러운 보금자리가 됩니다. 모든 요청을 동일한 방식으로 인증하거나, 모든 API를 일관되게 요청 제한하고 싶다면, 각 서비스가 로직을 재구현할 필요 없이 게이트웨이가 이를 강제합니다. 이것이 더 넓은 플랫폼 도구와 어떻게 다른지는 API 관리 vs API 게이트웨이를 참조하세요.
BFF(Backend for Frontend)란 무엇인가?
Sam Newman이 소개한 Backend for Frontend는 방향을 바꿉니다. 모든 클라이언트에 서비스를 제공하는 하나의 범용 백엔드 대신, 사용자 경험별로 백엔드를 하나씩 구축합니다. 웹 앱은 웹 BFF를 얻고, 모바일 앱은 모바일 BFF를 얻습니다. 각 BFF는 정확히 하나의 프런트엔드에 맞춰져 있습니다. 이 패턴은 마이크로서비스 작업에서 발전했으며, 여러 클라이언트에 서비스를 제공하는 단일 공유 백엔드가 모놀리스와 같은 종류의 병목 현상이 되는 경우에 사용됩니다.
Newman의 경험 법칙은 "하나의 경험, 하나의 BFF"입니다. 상당히 다른 프런트엔드는 자체 BFF를 가지며, 유사한 것들(동일 팀이 관리하는 iOS 및 Android 앱)은 하나를 공유할 수 있습니다.
여기서의 특징은 소유권과 형태입니다. Newman의 말에 따르면, BFF는 "특정 사용자 경험과 밀접하게 연결되어 있으며, 일반적으로 사용자 인터페이스와 동일한 팀이 유지 관리할 것"입니다. 프런트엔드 팀은 자체 BFF를 소유합니다. 그들은 별도의 백엔드 팀이 모든 변경 사항을 승인하기를 기다릴 필요 없이 클라이언트와 백엔드를 함께 발전시킵니다.
BFF는 실제로 무엇을 할까요? 하나의 클라이언트를 위해 데이터를 형성합니다:
- 집계: 모바일 화면은 다섯 개의 마이크로서비스에서 데이터가 필요합니다. 모바일 BFF는 다섯 개 모두를 호출하고 하나의 통합된 응답을 반환하므로, 휴대폰은 다섯 번 대신 한 번의 왕복만 수행합니다.
- 잘라내기 및 재형성: 모바일 클라이언트는 40개 필드 중 세 개 필드만 필요합니다. BFF는 대역폭 절약을 위해 나머지를 제거합니다.
- 클라이언트별 형식 지정: 데스크톱 앱은 풍부한 보기를 위해 여러 페이지를 한 번에 가져오고, 모바일 앱은 가볍게 유지하기 위해 한 페이지를 가져옵니다. 각 BFF는 클라이언트의 패턴에 맞춰 서비스를 제공합니다.
BFF는 특정 개성을 가진 일종의 API 애그리게이터입니다. 하위 호출을 구성하지만, 중립적이고 공유된 계층으로서가 아니라 항상 하나의 특정 프런트엔드를 위해 봉사합니다.
BFF와 API 게이트웨이의 중첩 지점
두 패턴이 표면적인 동작을 공유하기 때문에 혼란은 이해할 만합니다. 둘 다 클라이언트 요청을 가로챕니다. 둘 다 백엔드로 라우팅할 수 있습니다. 둘 다 여러 서비스를 호출하고 결과를 결합할 수 있습니다. 어느 쪽이든 다이어그램은 클라이언트와 서비스 사이에 있는 상자처럼 보입니다.
중복은 실제로 존재하지만 얕습니다. 차이점은 의도와 소유권에 있습니다:
- API 게이트웨이는 정책을 중앙 집중화하기 위해 모든 클라이언트에 대해 범용적으로 집계하고 라우팅합니다.
- BFF는 클라이언트 경험을 최적화하기 위해 하나의 프런트엔드에 대해 구체적으로 집계하고 라우팅합니다.
Microsoft의 자체 지침은 어떤 작업이 어디에 속하는지에 대해 명확합니다. 모니터링, 권한 부여, 요청 제한과 같은 교차 기능은 BFF에서 추상화되어 게이트웨이 스타일 패턴으로 별도로 처리되어야 합니다. BFF는 클라이언트별 로직만 보유해야 합니다. 인증 및 스로틀링을 BFF에 넣으면 게이트웨이의 절반을 잘못 재구축한 것이 되며, 작성하는 모든 BFF에서 다시 해야 합니다.
따라서 실질적인 경계는 다음과 같습니다. 책임이 모든 클라이언트에 대해 동일하다면 게이트웨이에 속합니다. 프런트엔드별로 변경된다면 BFF에 속합니다.
BFF와 API 게이트웨이의 협업
실제 마이크로서비스 시스템에서는 하나만 선택하는 경우가 거의 없습니다. 둘 다 계층화하여 실행합니다. 게이트웨이는 엣지에 위치합니다. BFF는 그 뒤에 위치합니다.
일반적인 요청 흐름은 다음과 같습니다:
- 모바일 클라이언트는 인증 토큰과 함께 요청을 보냅니다.
- API 게이트웨이는 토큰을 검증하고, 요청 제한을 적용하며, 관측 가능성을 위해 요청을 로깅한 다음, 모바일 BFF로 라우팅합니다.
- 모바일 BFF는 제품 서비스, 재고 서비스, 가격 서비스에 호출하고, 결과를 집계하며, 모바일 화면에 필요한 페이로드로 잘라낸 다음, 하나의 응답을 반환합니다.
- 게이트웨이는 응답을 클라이언트로 다시 스트리밍합니다.
이 패턴에 대한 Microsoft의 참조 아키텍처는 정확히 그렇게 합니다. API 관리 게이트웨이가 인증, 모니터링, 캐싱 및 라우팅을 처리한 다음, 서버리스 함수로 실행되는 클라이언트별 BFF 서비스로 전달하고, 이 서비스는 기본 마이크로서비스를 호출합니다.
각 계층은 자신이 잘하는 일을 합니다. 게이트웨이는 균일해야 하는 정책을 소유합니다. BFF는 특정해야 하는 형태를 소유합니다. 프런트엔드 팀은 게이트웨이 구성을 건드리지 않고도 BFF에 변경 사항을 적용하고, 플랫폼 팀은 어떤 BFF도 재배포하지 않고 요청 제한을 강화합니다.
이러한 계층화 관계는 게이트웨이가 다른 인프라를 대체하지 않고 공존하는 방식과 유사합니다. 게이트웨이는 로드 밸런서(API 게이트웨이 vs 로드 밸런서)도 아니고 서비스 메시(서비스 메시 vs API 게이트웨이)도 아닙니다. 각각은 요청 경로의 고유한 계층을 처리하며, BFF는 단순히 또 하나의 고유한 계층일 뿐입니다. 이는 API 주도 연결의 배후에 있는 동일한 원칙입니다. 각 계층에 명확한 작업을 부여하고 그것만 수행하도록 합니다.
결정표: BFF vs API 게이트웨이
| 질문 | API 게이트웨이 | BFF |
|---|---|---|
| 소유자는 누구인가? | 플랫폼 / 인프라 팀 | 이를 사용하는 프런트엔드 팀 |
| 누구에게 서비스하는가? | 모든 클라이언트에게 균일하게 | 하나의 특정 프런트엔드 |
| 주요 업무 | 교차 관심사: 인증, 요청 제한, 라우팅, 관측 가능성 | 클라이언트별 집계 및 데이터 형태 조정 |
| 몇 개를 실행하는가? | 보통 한 개 (엣지당) | 각기 다른 사용자 경험당 한 개 |
| 결합도 | 느슨함, 클라이언트 불가지론적 | 설계상 긴밀함, 클라이언트 특정적 |
| 변경 주기 | 안정적, 플랫폼 통제 | 빠름, 프런트엔드의 로드맵을 따름 |
| 속하는 것 | 모든 클라이언트에 대해 동일한 모든 것 | 하나의 클라이언트에 고유한 모든 것 |
책임에 대한 라우팅 질문으로 읽으세요. 모두에게 동일한 것은 게이트웨이에 속합니다. 프런트엔드별로 다른 것은 BFF에 속합니다. 책임이 둘 다인 경우(중앙 인증을 원하지만 클라이언트별 페이로드 형태 조정도 원하는 경우), 이는 한쪽을 선택하는 것이 아니라 두 계층을 모두 실행해야 한다는 신호입니다.
언제 무엇을 사용해야 하는가
여러 서비스가 있고 인증, 요청 제한 및 라우팅을 적용할 수 있는 단일하고 일관된 장소가 필요한 경우 **API 게이트웨이를 사용하세요.** 거의 모든 마이크로서비스 시스템은 API 게이트웨이의 이점을 얻습니다. 클라이언트에 노출되는 서비스가 몇 개 이상 있다면, 다른 무엇보다 게이트웨이를 먼저 원할 것입니다.
다른 클라이언트가 동일한 백엔드에서 의미상으로 다른 요구 사항을 가지고 있고, 공유된 범용 API가 병목 현상이 되었을 때 **BFF를 사용하세요.** Microsoft의 지침에 따르면 일반적인 유발 요인은 다음과 같습니다:
- 경쟁하는 프런트엔드에 서비스를 제공하기 때문에 공유된 백엔드를 유지 관리하는 데 많은 노력이 필요합니다.
- 여러 인터페이스를 수용하기 위해 범용 백엔드를 계속 사용자 정의합니다.
- 모바일과 웹이 실제로 다른 데이터 및 성능 요구 사항을 가지고 있습니다.
모든 인터페이스가 동일하거나 유사한 요청을 하거나, 단 하나의 인터페이스만 백엔드와 통신하는 경우 **BFF를 건너뛰세요.** BFF는 네트워크 홉, 배포할 서비스 증가, 그리고 BFF 간의 코드 중복을 추가합니다. 단일 공유 API가 모든 클라이언트에 잘 서비스된다면, BFF는 필요 없는 오버헤드입니다. Microsoft는 프런트엔드별 리졸버가 있는 GraphQL 계층도 별도의 BFF 필요성을 없앨 수 있다고 언급하는데, 클라이언트가 원하는 필드만 정확히 요청하기 때문입니다.
마이크로서비스를 대규모로 운영하는 경우 **둘 다 사용하세요.** 엣지에서는 균일한 정책을 위해 게이트웨이를, 그 뒤에서는 클라이언트별 형태 조정을 위해 BFF를 사용합니다. 이것이 일반적인 최종 상태이며, 이국적인 것이 아닙니다.
흔한 실수
BFF에 인증 및 요청 제한을 넣는 것. 이것이 가장 큰 실수입니다. 교차 관심사는 게이트웨이에 속합니다. 이를 BFF 간에 중복하면 불일치가 발생합니다. 모바일 BFF는 한 정책을 적용하고 웹 BFF는 다른 정책을 적용하며, 보안 상태는 우연히 일관성을 잃게 됩니다.
BFF가 두 번째 모놀리스가 되도록 내버려두는 것. BFF는 작고 하나의 경험에 초점을 맞추도록 의도되었습니다. 팀이 공유 비즈니스 로직을 BFF에 쌓으면 다시 범용 백엔드가 되어 패턴이 제거해야 했던 정확한 병목 현상을 다시 도입하게 됩니다.
게이트웨이를 BFF로 사용하는 것. 일부 팀은 BFF 구축을 피하기 위해 게이트웨이 구성에 클라이언트별 요청 변환 규칙을 직접 추가합니다. 이는 소규모에서는 작동하지만, 게이트웨이는 중앙에서 소유되므로 이제 프런트엔드 팀은 클라이언트별 사소한 조정이 필요할 때마다 플랫폼 팀에 티켓을 제출하게 됩니다. 잘못된 팀을 결합한 것입니다.
클라이언트가 하나만 있을 때 BFF를 구축하는 것. 단일 웹 앱이 있고 다른 클라이언트가 보이지 않는 경우, BFF는 시기상조입니다. 공유 API를 출시하세요. 두 번째로 다른 클라이언트가 실제로 등장할 때 BFF를 추가하세요.
계약을 잊는 것. 모든 BFF와 모든 게이트웨이 경로는 API를 노출합니다. 각각은 다른 API와 마찬가지로 정의된 계약, 테스트 및 문서를 필요로 합니다. 이를 건너뛰면 "얇은" BFF 계층은 소유 팀 외부의 누구도 통합할 수 없는 문서화되지 않은 블랙박스가 됩니다. 이것이 왜 중요한지 이해하려면 API 계약이란 무엇인가를 참조하세요.
Apidog가 적합한 곳
요청이 API 게이트웨이, BFF 또는 둘 다를 통해 흐르든 상관없이, 각 계층은 API 계약을 노출합니다. Apidog는 이러한 계약을 설계, 테스트, 모의(mock), 문서화하는 곳입니다. 게이트웨이나 BFF를 구축하거나 호스팅하거나 대체하지 않으며, 이들이 노출하는 API 표면을 위한 단일 작업 공간을 제공합니다.
구체적으로:
- 설계: 시각적 디자이너에서 BFF의 집계된 응답 또는 게이트웨이의 라우팅된 엔드포인트 스키마를 먼저 모델링한 다음, 프런트엔드 및 백엔드 팀이 구축할 수 있도록 OpenAPI를 생성합니다.
- 모의: BFF의 스마트 모의 서버를 실행하여 모바일 팀이 BFF의 하위 서비스가 존재하기 전에 화면을 개발할 수 있도록 합니다. 이는 병렬 프런트엔드 및 백엔드 작업을 가능하게 하는 API 우선 워크플로입니다.
- 테스트: 실제 클라이언트가 하는 것처럼 게이트웨이 앞단의 엔드포인트를 호출하는 자동화된 테스트 시나리오를 구축하여 인증, 상태 코드, 집계된 페이로드 형태를 검증합니다.
- 문서화: 각 BFF 및 게이트웨이 경로에 대한 대화형 문서를 게시하여 모든 소비 팀이 구현을 읽지 않고도 계약을 알 수 있도록 합니다.
선택하는 패턴은 아키텍처 결정입니다. 각 계층이 노출하는 계약은 변함없는 상수입니다. Apidog는 상수를 처리하여, BFF와 게이트웨이를 어떻게 연결하든 관계없이 설계, 테스트, 모의, 문서화된 상태를 유지하도록 합니다.
백엔드 코드를 한 줄도 작성하기 전에 BFF 및 게이트웨이 계약을 설계하고 모의 테스트하기 위해 Apidog를 무료로 사용해 보세요.
자주 묻는 질문
BFF는 API 게이트웨이의 한 종류인가요? 아닙니다. 둘 다 라우팅 및 집계가 가능하다는 점에서 중복되지만, BFF는 프런트엔드 팀이 소유하고 하나의 클라이언트 경험에 맞춰지는 반면, API 게이트웨이는 중앙에서 소유되고 모든 클라이언트에게 균일하게 서비스를 제공합니다. BFF는 일반적으로 게이트웨이 뒤에 위치합니다.
API 게이트웨이 없이 BFF를 사용할 수 있나요? 예, 하지만 대규모에서는 보통 그렇게 해서는 안 됩니다. 게이트웨이가 없으면 각 BFF는 인증 및 요청 제한과 같은 교차 관심사를 재구현해야 하며, 이는 불일치로 이어집니다. 게이트웨이는 이러한 것들을 중앙 집중화하여 각 BFF가 클라이언트별 형태만 처리하도록 합니다.
BFF는 몇 개를 가져야 하나요? Sam Newman의 "하나의 경험, 하나의 BFF" 규칙을 따르세요. 상당히 다른 프런트엔드마다 별도의 BFF를 구축하세요. iOS 및 Android 앱과 같이 동일 팀이 유지 관리하는 유사한 클라이언트는 하나의 BFF를 공유할 수 있습니다.
BFF가 API 게이트웨이를 대체하나요? 아닙니다. 이들은 상호 보완적인 계층입니다. 게이트웨이는 엣지에서 균일한 정책을 시행하고, BFF는 그 뒤에서 특정 클라이언트를 위해 데이터를 형성합니다. 대부분의 실제 마이크로서비스 시스템은 둘 다 실행합니다.
언제 BFF를 구축하지 말아야 하나요? 모든 클라이언트가 유사한 요청을 할 때, 클라이언트가 하나만 존재할 때, 또는 프런트엔드별 리졸버가 있는 GraphQL 계층이 이미 클라이언트가 필요한 데이터를 정확히 가져올 수 있도록 할 때 건너뛰세요.
인증 및 요청 제한은 BFF와 게이트웨이 중 어디에 속하나요? 게이트웨이에 속합니다. 이들은 모든 클라이언트에 걸쳐 균일해야 하는 교차 관심사입니다. 이들을 BFF에 넣으면 모든 BFF에 로직이 중복되고 정책 불일치를 초래합니다.