프런트 엔드 패턴의 백 엔드

2025-05-15

이 패턴은 백 엔드 서비스를 프런트 엔드 구현에서 분리하여 다양한 클라이언트 인터페이스에 맞게 환경을 조정하는 방법을 설명합니다. 이 패턴은 여러 인터페이스를 제공하는 백 엔드를 사용자 지정하지 않으려는 경우에 유용합니다. 이 패턴은 Sam Newman의 프런트 엔드에 대한 백 엔드 패턴을 기반으로 합니다.

컨텍스트 및 문제

처음에 데스크톱 웹 UI 및 해당 백 엔드 서비스를 사용하여 디자인된 애플리케이션을 고려합니다. 비즈니스 요구 사항이 시간이 지남에 따라 변경되면 모바일 인터페이스가 추가됩니다. 두 인터페이스는 동일한 백 엔드 서비스와 상호 작용합니다. 그러나 모바일 디바이스의 기능은 화면 크기, 성능 및 표시 제한 측면에서 데스크톱 브라우저와 크게 다릅니다.

백 엔드 서비스는 여러 프런트 엔드 시스템의 경쟁 요구가 자주 발생합니다. 이러한 요구로 인해 자주 업데이트되고 잠재적인 개발 병목 현상이 발생합니다. 업데이트가 충돌하고 호환성을 유지해야 하는 경우 배포 가능한 단일 리소스에 대한 과도한 수요가 발생합니다.

별도의 팀이 백 엔드 서비스를 관리하면 프런트 엔드와 백 엔드 팀 간의 연결이 끊어지게 될 수 있습니다. 이러한 연결 끊김으로 인해 합의 및 균형 조정 요구 사항이 지연될 수 있습니다. 예를 들어 한 프런트 엔드 팀에서 요청한 변경 내용은 통합하기 전에 다른 프런트 엔드 팀과 함께 유효성을 검사해야 합니다.

해결 방법

인터페이스와 관련된 요구 사항만 처리하는 새 계층을 소개합니다. BFF(백 엔드-for-frontend) 서비스라고 하는 이 계층은 프런트 엔드 클라이언트와 백 엔드 서비스 사이에 있습니다. 애플리케이션이 웹 인터페이스 및 모바일 앱과 같은 여러 인터페이스를 지원하는 경우 각 인터페이스에 대한 BFF 서비스를 만듭니다.

이 패턴은 다른 인터페이스에 영향을 주지 않고 특정 인터페이스에 대한 클라이언트 환경을 사용자 지정합니다. 또한 프런트 엔드 환경의 요구 사항을 충족하도록 성능을 최적화합니다. 각 BFF 서비스는 공유 백 엔드 서비스보다 작고 덜 복잡하기 때문에 애플리케이션을 더 쉽게 관리할 수 있습니다.

프런트 엔드 팀은 자체 BFF 서비스를 독립적으로 관리하므로 언어 선택, 릴리스 주기, 워크로드 우선 순위 지정 및 기능 통합을 제어할 수 있습니다. 이러한 자율성을 통해 중앙 집중식 백 엔드 개발 팀에 의존하지 않고 효율적으로 작동할 수 있습니다.

많은 BFF 서비스는 일반적으로 REST API에 의존했지만 GraphQL 구현이 대안으로 떠오르고 있습니다. GraphQL을 사용하면 클라이언트가 미리 정의된 엔드포인트에 의존하지 않고 필요한 데이터를 요청할 수 있으므로 쿼리 메커니즘을 사용하면 별도의 BFF 계층이 필요하지 않습니다.

자세한 내용은 Sam Newman의 프런트 엔드 패턴에 대한 백 엔드를 참조하세요.

문제 및 고려 사항

관련 비용에 따라 최적의 서비스 수를 평가합니다. 더 많은 서비스를 유지 관리하고 배포하면 운영 오버헤드가 증가합니다. 각 개별 서비스에는 고유한 수명 주기, 배포 및 유지 관리 요구 사항 및 보안 요구 사항이 있습니다.
새 서비스를 추가할 때 서비스 수준 목표를 검토합니다. 클라이언트가 서비스에 직접 연결하지 않고 새 서비스에서 추가 네트워크 홉을 도입하므로 대기 시간이 증가할 수 있습니다.
다른 인터페이스가 동일한 요청을 수행할 때 요청을 단일 BFF 서비스로 통합할 수 있는지 여부를 평가합니다. 여러 인터페이스 간에 단일 BFF 서비스를 공유하면 각 클라이언트에 대해 서로 다른 요구 사항이 발생할 수 있으므로 BFF 서비스의 성장과 지원이 복잡해질 수 있습니다.

코드 중복은 이 패턴의 가능한 결과입니다. 코드 중복과 각 클라이언트에 대한 보다 나은 맞춤형 환경 간의 장차를 평가합니다.
BFF 서비스는 특정 사용자 환경과 관련된 클라이언트별 논리만 처리해야 합니다. 효율성을 유지하려면 모니터링 및 권한 부여와 같은 교차 절단 기능을 추상화해야 합니다. BFF 서비스에 표시될 수 있는 일반적인 기능은 게이트키핑, 속도 제한 및 라우팅 패턴으로 별도로 처리됩니다.
이 패턴을 학습하고 구현하는 것이 개발 팀에 미치는 영향을 고려합니다. 새로운 백 엔드 시스템을 개발하려면 시간과 노력이 필요하며 이로 인해 기술적 부채가 발생할 수 있습니다. 기존 백 엔드 서비스를 유지 관리하면 이 문제가 추가됩니다.
이 패턴이 필요한지 여부를 평가합니다. 예를 들어 조직에서 프런트 엔드 특정 확인자와 함께 GraphQL을 사용하는 경우 BFF 서비스는 애플리케이션에 값을 추가하지 않을 수 있습니다.

또 다른 시나리오는 API 게이트웨이 와 마이크로 서비스를 결합하는 애플리케이션입니다. 이 방법은 BFF 서비스가 일반적으로 권장되는 일부 시나리오에 충분할 수 있습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

공유 또는 범용 백 엔드 서비스를 유지 관리하려면 상당한 개발 오버헤드가 필요합니다.
특정 클라이언트 인터페이스의 요구 사항에 맞게 백 엔드를 최적화하려고 합니다.
여러 인터페이스를 수용하기 위해 범용 백 엔드를 사용자 지정합니다.
프로그래밍 언어는 특정 사용자 인터페이스의 백 엔드에 더 적합하지만 일부 사용자 인터페이스에는 적합하지 않습니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

인터페이스는 백 엔드에 대해 동일하거나 유사한 요청을 합니다.
하나의 인터페이스만 백 엔드와 상호 작용합니다.

워크로드 디자인

워크로드 디자인에서 프런트 엔드용 백 엔드 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

기둥	이 패턴으로 핵심 목표를 지원하는 방법
안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다.	서비스를 특정 프런트 엔드 인터페이스로 격리하는 경우 오작동이 포함됩니다. 한 클라이언트의 가용성은 다른 클라이언트의 액세스 가용성에 영향을 주지 않습니다. 다양한 클라이언트를 다르게 처리하는 경우 예상 클라이언트 액세스 패턴에 따라 안정성 작업의 우선 순위를 지정할 수 있습니다. - RE:02 중요 흐름 - RE:07 자기 보존
보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다.	이 패턴에 도입된 서비스 분리를 통해 각 클라이언트의 특정 요구 사항에 맞게 서비스 계층의 보안 및 권한 부여를 사용자 지정할 수 있습니다. 이 방법은 API의 노출 영역을 줄이고 다른 기능을 노출할 수 있는 백 엔드 간의 횡적 이동을 제한할 수 있습니다. - SE:04 구분 - SE:08 강화 리소스
성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다.	백 엔드 분리를 사용하면 공유 서비스 계층에서 불가능할 수 있는 방식으로 최적화할 수 있습니다. 개별 클라이언트를 다르게 처리하는 경우 특정 클라이언트의 제약 조건 및 기능에 대한 성능을 최적화할 수 있습니다. - PE:02 용량 계획 - PE:09 중요 흐름

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

예시

이 예제에서는 모바일 앱과 데스크톱 애플리케이션이라는 두 개의 고유한 클라이언트 애플리케이션이 Azure API Management(데이터 평면 게이트웨이)와 상호 작용하는 패턴에 대한 사용 사례를 보여 줍니다. 이 게이트웨이는 추상화 계층으로 작용하며 다음과 같은 일반적인 횡단 관심사를 관리합니다.

권한 부여 적절한 액세스 토큰이 있는 확인된 ID만 Microsoft Entra ID와 함께 API Management를 사용하여 보호된 리소스를 호출할 수 있는지 확인합니다.
모니터링. 준수를 위해 Azure Monitor에 요청 및 응답 세부 정보를 캡처하고 보냅니다.
요청 캐싱. API Management의 기본 제공 기능으로 캐시의 응답을 제공하여 반복되는 요청을 최적화합니다.
라우팅 및 집계. 들어오는 요청을 적절한 BFF 서비스로 전달합니다.

각 클라이언트에는 게이트웨이와 기본 마이크로 서비스 간의 중개자 역할을 하는 Azure 함수로 실행되는 전용 BFF 서비스가 있습니다. 이러한 클라이언트별 BFF 서비스는 페이지 매김 및 기타 기능에 맞게 조정된 환경을 보장합니다. 모바일 앱은 대역폭 효율성의 우선 순위를 지정하고 캐싱을 활용하여 성능을 향상시킵니다. 반면 데스크톱 애플리케이션은 단일 요청에서 여러 페이지를 검색하여 보다 몰입형 사용자 환경을 만듭니다.

첫 번째 페이지 요청에 대한 Flow A, 모바일 클라이언트용

모바일 클라이언트는 페이지 GET에 대한 1 요청을 보내고, 권한 부여 헤더에 OAuth 2.0 토큰을 포함합니다.
요청이 API Management 게이트웨이에 도달하여 이를 가로채고 다음을 수행합니다.
1. 권한 부여 상태를 확인합니다. API Management는 심층 방어를 구현하므로 액세스 토큰의 유효성을 확인합니다.
2. 요청 활동을 Azure Monitor에 로그로 스트리밍합니다. 요청의 세부 정보는 감사 및 모니터링을 위해 기록됩니다.
정책이 적용된 다음, API Management는 요청을 Azure 함수 모바일 BFF 서비스로 라우팅합니다.
그런 다음 Azure 함수 모바일 BFF 서비스는 필요한 마이크로 서비스와 상호 작용하여 단일 페이지를 가져오고 요청된 데이터를 처리하여 간단한 환경을 제공합니다.
응답이 클라이언트에 반환됩니다.

모바일 클라이언트에서 캐시된 첫 번째 페이지 요청에 대한 흐름 B

모바일 클라이언트는 권한 부여 헤더에 OAuth 2.0 토큰을 포함하여 페이지에 GET 대해 동일한 1 요청을 다시 보냅니다.
API Management 게이트웨이는 이 요청이 이전에 수행되었음을 인식합니다.
1. 정책이 적용됩니다. 그런 다음 게이트웨이는 요청 매개 변수와 일치하는 캐시된 응답을 식별합니다.
2. 캐시된 응답을 즉시 반환합니다. 이 빠른 응답은 Azure 함수 모바일 BFF 서비스로 요청을 전달할 필요가 없습니다.

데스크톱 클라이언트의 첫 번째 요청에 대한 흐름 C

데스크톱 클라이언트는 GET 권한 부여 헤더에 OAuth 2.0 토큰을 포함하여 처음으로 요청을 보냅니다.
요청은 공통적인 문제가 처리되는 API 관리 게이트웨이에 도달합니다.
1. 권한 부여: 토큰 유효성 검사는 항상 필요합니다.
2. 요청 작업을 스트리밍합니다. 요청 세부 정보는 관찰 가능성을 위해 기록됩니다.
모든 정책이 적용된 후 API Management는 데이터를 많이 사용하는 애플리케이션 처리를 처리하는 Azure 함수 데스크톱 BFF 서비스로 요청을 라우팅합니다. 데스크톱 BFF 서비스는 여러 페이지 응답으로 클라이언트에 응답하기 전에 기본 마이크로 서비스 호출을 사용하여 여러 요청을 집계합니다.

디자인

Microsoft Entra ID 는 클라우드 기반 ID 공급자 역할을 합니다. 모바일 및 데스크톱 클라이언트 모두에 맞게 조정된 대상 그룹 클레임을 제공합니다. 이러한 클레임은 권한 부여에 사용됩니다.
API Management 는 경계를 설정하는 클라이언트와 해당 BFF 서비스 간의 프록시 역할을 합니다. API Management는 JSON 웹 토큰의 유효성을 검사 하는 정책으로 구성되며 토큰이 없거나 대상 BFF 서비스에 대한 잘못된 클레임을 포함하는 요청을 거부합니다. 또한 모든 활동 로그를 Azure Monitor로 스트리밍합니다.
Azure Monitor 는 중앙 집중식 모니터링 솔루션으로 작동합니다. 모든 활동 로그를 집계하여 포괄적인 엔드 투 엔드 관찰 가능성을 보장합니다.
Azure Functions 는 여러 엔드포인트에서 BFF 서비스 논리를 효율적으로 노출하여 개발을 간소화하는 서버리스 솔루션입니다. 또한 Azure Functions는 인프라 오버헤드를 최소화하고 운영 비용을 낮출 수 있습니다.