배경

클라이언트에서 여러 엔드 포인트를 바라보고 있는 상황입니다. (10개 서버, 2개 소켓 서버) 각 서버의 요청, 응답, 에러 등에 대한 포맷이 다를 수 있는 이슈, 에러 추적 이슈 등 여러 이슈로 이어질 수 있습니다.

클라이언트의 멀티 엔드포인트 구조를 해소하기 위해 BFF 역할을 하는 서버 구성이 필요하다고 판단됩니다.

%% BFF
graph LR
    %% __START
    Client --> |1.request| BFF_Server
    BFF_Server --> |2.request| A_Server
    BFF_Server --> |2.request| B_Server
    BFF_Server --> |2.request| C_Server
    BFF_Server <--> |3.process| BFF_Server
    BFF_Server --> |4.response| Client

    subgraph BFF
        Client
        BFF_Server
        A_Server
        B_Server
        C_Server
    end

    _Client --> |1.request| _A_Server
    _Client --> |2.request| _B_Server
    _Client --> |3.request| _C_Server
    _A_Server --> |1-1.response| _Client
    _B_Server --> |2-1.response| _Client
    _C_Server --> |3-1.response| _Client

    subgraph BFF_NO
        _Client
        _A_Server
        _B_Server
        _C_Server
    end
    %% __END

본인의 입장(BFF 도입)

[API 일관성 확보]

• 다양한 백엔드의 응답/에러 포맷을 BFF에서 통일
• 클라이언트는 일관된 방식으로만 처리하면 됨

[복잡성 감소]

• 클라이언트가 여러 엔드포인트를 직접 관리하지 않아도 됨
• 네트워크 요청, 인증, 에러 핸들링 등 공통 로직을 BFF에서 집중 관리

[에러 추적 및 로깅 용이]

• 모든 요청/응답/에러를 BFF에서 통합적으로 로깅 및 모니터링 가능

[보안 강화]

• 클라이언트에서 직접 접근하지 않아야 할 서버를 BFF가 대신 접근
• 인증/인가, 민감 정보 마스킹 등 보안 정책을 중앙에서 관리

[프론트엔드 최적화]

• 클라이언트에 맞는 데이터 집계, 변환, 조합(aggregation) 가능
• 불필요한 데이터 전송 최소화, 성능 최적화