상황

커머스 서비스를 개발하면서 프론트엔드와 백엔드 사이에 비즈니스 로직을 어디에 배치할지 반복적으로 논의가 발생했습니다. 팀 내에서도 "로직은 서버에 있어야 한다"는 의견과 "클라이언트가 이미 상태를 갖고 있으니 거기서 처리하는 게 낫다"는 의견이 공존했고, 기능마다 개인 성향에 따라 결정이 달라졌습니다. 특히 상품 필터링, 사용자 세션 갱신, 조건 기반 추천 등 FE/BE 어디서든 처리 가능한 영역에서 일관된 기준이 없었습니다.

문제

일관된 판단 기준 없이 로직을 배치하면 세 가지 문제가 발생합니다.

첫째, 동일한 종류의 로직이 어떤 기능에서는 서버에, 어떤 기능에서는 클라이언트에 있어서 유지보수 시 위치를 예측할 수 없습니다. 둘째, "이 로직은 왜 여기에 있는가?"라는 질문에 답할 수 없으면 리팩토링 시점에 올바른 결정을 내릴 수 없습니다. 셋째, 비효과적인 위치에 로직을 둘 경우 불필요한 네트워크 통신, 서버 자원 낭비, 사용자 경험 저하가 누적됩니다.

접근과 판단

"무조건 서버" 또는 "무조건 클라이언트"가 아닌, 비즈니스 특성에 따라 효과적인 쪽에서 처리한다는 원칙을 세웠습니다. 핵심은 세 가지 판단 기준입니다.

1:N

서버 제공자가 N개 소비자를 상대하면 BE

동일 로직을 여러 클라이언트가 중복 구현하는 것보다 서버 한 곳에서 처리

1:1

1:1 관계에서 FE가 상태를 보유하면 FE

서버가 클라이언트 세션 전체를 보유하는 것이 비효율적이면 클라이언트 처리

freq

변경 빈도가 높으면 서버

앱 배포 없이 즉시 반영해야 하는 로직은 서버에 배치

이 기준을 세 가지 실제 사례에 적용했습니다.

구현

사례 1: 상품 품절 필터링 — BE 배치

운영 도구에서 설정한 추천 상품 목록(30개 이상)을 화면에 노출할 때, 품절 상품을 제외해야 했습니다. 클라이언트에서 필터링하면 원본 30개 중 품절을 제거한 뒤 표시할 상품이 부족해지는 문제가 발생합니다. 서버는 전체 상품 풀에 접근할 수 있으므로, 품절 필터링 후에도 충분한 수의 상품을 채워서 내려줄 수 있습니다.

판단 근거: 운영 설정(1) 대 여러 사용자 화면(N)의 1:N 관계이며, 서버가 전체 재고 상태를 알고 있으므로 BE에서 처리하는 것이 효과적입니다.

사례 2: 체크인 서비스의 구매상품 갱신 — FE 배치

사용자가 체크인 플로우를 진행할 때, 보유 상품 목록을 실시간으로 갱신해야 했습니다. 서버가 모든 사용자의 세션 상태와 보유 구좌 정보를 실시간으로 추적하려면 막대한 상태 관리 비용이 발생합니다. 대신 클라이언트가 자신의 세션에서 실패한 건만 선별해 재조회하면 서버 부하 없이 정확한 상태를 유지할 수 있습니다.

판단 근거: 각 사용자와 서버 간 1:1 관계이고, 클라이언트가 이미 세션 상태를 보유하고 있으므로 FE에서 처리하는 것이 효과적입니다.

사례 3: 추천 위자드의 조건 분기 — FE 배치

사용자 입력 조건에 따라 다른 상품을 추천하는 위자드에서, 조건마다 별도 API를 호출하면 단계가 늘어날수록 네트워크 왕복이 선형 증가합니다. 대신 서버가 전체 추천 메타데이터를 한 번에 내려주고, 클라이언트가 사용자 입력에 따라 로컬에서 분기 처리하면 추가 API 호출 없이 즉각적인 응답이 가능합니다.

title: "추천 위자드 로직 배치 비교"
pros:
  - "메타데이터 일괄 전송 + FE 분기"
  - "API 호출 1회로 고정"
  - "사용자 입력 즉시 반영, 네트워크 대기 없음"
  - "오프라인 상태에서도 분기 동작 가능"
cons:
  - "조건별 개별 API 호출"
  - "단계 수에 비례해 API 호출 증가"
  - "매 단계 네트워크 왕복 대기"
  - "서버 부하 선형 증가"

판단 근거: 메타데이터 자체의 변경 빈도가 낮고, 클라이언트가 사용자 입력 상태를 직접 보유하고 있으므로 FE에서 분기 처리하는 것이 효과적입니다.

결과

세 가지 판단 기준을 팀 내 공유 원칙으로 정립한 뒤, 로직 배치에 대한 논의가 "어디가 맞는가"에서 "이 기능의 관계 특성은 무엇인가"로 전환되었습니다. 새로운 기능 설계 시 판단 기준을 적용하면 논의 시간이 줄고, 코드 리뷰에서도 배치 근거를 명확히 설명할 수 있게 되었습니다.

배운 것

  • 로직 배치는 기술적 정답이 아니라 비즈니스 맥락에 따른 효과성의 문제입니다. "서버가 원칙"이라는 도그마보다 관계 특성(1:N vs 1:1), 상태 소유자, 변경 빈도라는 구체적 기준이 팀 합의를 이끕니다.
  • 판단 프레임워크의 가치는 결정 자체보다 결정 근거의 일관성에 있습니다. 같은 기준을 적용하면 시간이 지나도 "왜 여기에 있는가"를 추적할 수 있고, 리팩토링 시 올바른 방향을 잡을 수 있습니다.
  • FE/BE 경계는 기술 레이어가 아니라 비즈니스-인프라-사용자 경험이 교차하는 의사결정 지점입니다. 단일 레이어 관점이 아닌 세 계층을 횡단하는 시야가 필요합니다.