프론트엔드 맥시멀리즘(Front-end maximalism)

okorion·2025년 11월 14일
front end

📝 Document 요약 및 번역

목록 보기
34/90

“백엔드가 데이터를 얼마나 가공해서 프론트엔드에 넘겨야 할까?”
→ 답: 가능한 한 최소한만.

이 글은 Nate Meyvis가 주장하는 프론트엔드 맥시멀리즘(front-end maximalism) 개념을 정리한 것이다. 핵심은 단순하다.

  • 전통적인 웹 앱 구조: “데이터 처리와 필터링은 백엔드가, 화면 렌더링은 프론트가”
  • 프론트엔드 맥시멀리즘: “조건만 맞는다면 데이터는 가능한 한 통째로 프론트로 가져오고, 필터링·조회·상호작용을 프론트에서 최대한 처리하자”

아래에서 원문의 논지를 세부적으로 정리한다.

1. 문제 제기: 프론트 vs 백엔드, 어디까지 나눌 것인가?

자주 나오는 질문:

Q. 프론트엔드가 백엔드를 호출해서 뭔가를 한다.
지금도 이런 일을 하고 있고, 앞으로 더 많은 일을 하게 될 수도 있다.
이때, 백엔드는 데이터를 얼마나 필터링·전처리해서 프론트로 넘겨야 할까?

전통적인 감각:

  • 리스트/목록은 백엔드에서 필터링·페이지네이션해서 넘겨주고
  • 특정 조건이 바뀔 때마다 API를 다시 호출
  • “쿼리, 필터링, 페이지네이션 = 백엔드 일” 이라는 고정 관념

이에 대한 답변으로 제시되는 게 프론트엔드 맥시멀리즘이다.

2. 프론트엔드 맥시멀리즘이란 무엇인가?

정의적으로 한 줄로 정리하면:

현대 환경과 일반적인 웹 애플리케이션에서는, 가능한 많은 일을 프론트에서 하고, 백엔드는 최소한만 하도록 설계하는 관점.

기준은 추상적인 “감”이 아니라, 일반적으로 다들 동의하는 원칙들이다. 예를 들어:

  • 시스템(네트워크 포함) 어느 부분도 감당 못할 만큼 많은 데이터를 보내지 않는다.
  • 코드 복잡도를 최소화한다.
  • 사용자 플로우를 단순하게 유지한다.
  • 캡슐화를 가능한 한 유지한다.
  • 보안 취약점을 만들지 않는다.

Nate의 주장:
이 기준들을 “요즘 환경”에 맞춰 냉정하게 적용해 보면, 생각보다 훨씬 많은 일을 프론트에서 하는 게 더 낫다는 경우가 많다.

3. 프론트엔드 맥시멀리즘 예시 3가지

3-1. 상품 상세 페이지

상황:

  • 긴 상품 리스트
  • 사용자가 하나를 선택하면 상세 정보를 보여주는 UI

전통적인 설계:

  1. 첫 API: 상품 목록만 가져옴 (요약 정보)
  2. 두 번째 API: 특정 상품을 클릭할 때마다 상세 정보를 별도 요청

프론트엔드 맥시멀리즘 접근:

  • 처음부터 “해당 페이지에서 필요할 수 있는 상품 상세 정보를 전부 가져온다”
  • 프론트 로컬 상태(예: React state, Zustand, Redux 등)에서
    • “어떤 상품을 보여줄지”만 바꿔주면 됨
  • API 호출 패턴:
    • “목록 요청 + 상세 요청 N번” → “한 번에 전체 상세 데이터 요청 1번”

3-2. 코치용 선수 통계 대시보드

상황:

  • 코치가 선수 목록과 필터를 입력하고 통계를 보는 대시보드

전통적 방식:

  • 매번 필터를 백엔드에 보내서, 필터링된 결과만 받는다.

프론트엔드 맥시멀리즘:

  • “해당 코치에게 관련된 선수 데이터 전체”를 페이지 로드 시점에 한 번에 가져온다.
  • 필터링·검색·정렬은 전부 프론트에서 수행
  • 코치가 필터를 바꿀 때마다 API 호출 대신 프론트의 in-memory 데이터만 재사용

3-3. 플래시카드 사이트

상황:

  • 유저가 학습할 카드 서브셋을 선택해서 공부

전통적 방식:

  • 선택한 서브셋 정보를 백엔드로 보내서, 그때그때 필요한 카드만 가져오기

프론트엔드 맥시멀리즘:

  • 유저가 사용할 법한 대부분의 카드 세트를 미리 받아두고
  • 프론트에서 카드 선택, 순서, 필터링을 처리
  • 정말 특이한 조합/요청에만 추가 API 호출

4. 왜 많은 엔지니어는 이렇게 설계하지 않는가?

Nate의 추측:

  • 심리적·사회적 이유가 크다.
    • “쿼리/필터는 원래 백엔드에서 하는 것”
    • “프론트로 데이터를 몰아주는 건 뭔가 조악하고 비전문적”이라는 문화적 인식
  • 그러나 시험 문제로 내고 원칙만 보게 하면, 많은 엔지니어들이 대략 이런 답을 쓸 것이다:
    • 데이터량을 감당할 수 있게 보낸다.
    • 코드 복잡도 최소화.
    • 사용자 플로우 단순화.
    • 캡슐화 유지.
    • 보안 유지.
  • 문제는 “관행”과 “원칙”이 실제로는 서로 충돌하는 경우가 많다는 것
    → 관행대로 하면 오히려 복잡성이 증가하고, 테스트·유지보수가 더 어려워지는 경우가 많다.

5. 프론트엔드 맥시멀리즘을 쓰면 안 되는 두 가지 큰 이유

프론트엔드 맥시멀리즘은 “항상”이 아니라 “상당히 자주” 좋은 선택이라는 주장이다.
쓰면 안 되는 대표적 이유는 두 가지.

5-1. 진짜로 데이터가 너무 많은 경우

  • 대놓고 한 번에 프론트로 보낼 수 없을 정도로 데이터가 많은 경우:
    • 백엔드는 필터링/페이지네이션/잘라내기/throttling 등을 해야 한다.
  • 다만, 여기서 중요한 포인트:
    • “이 정도면 너무 많을 것 같은데?”라는 감으로 막지 말고, 실제 데이터 크기를 계산해 보라는 것.
    • 실제로는 일반적인 .jpg 한 장보다도 작은 총 데이터량인 경우가 수없이 많았다고 언급.
  • “지금은 괜찮지만, 나중에 스케일이 커지면 못 쓸 수 있지 않아?”라는 반론에 대해:
    • 많은 시스템에서 “해당 사용자에게 실제로 필요한 데이터 상한”이 명확하게 존재:
      • 예: 선수 통계 대시보드 → “선수 수 × 선수당 데이터량” 같은 현실적인 상한
      • 이 상한이 네트워크·브라우저가 감당 가능한 범위인 경우가 훨씬 많다.

Gall’s Law와의 연결

Gall’s Law:

작동하는 복잡한 시스템은 예외 없이
작동하는 단순한 시스템으로부터 진화해 왔다.
처음부터 설계된 복잡한 시스템은 절대 작동하지 않으며,
작동하도록 고칠 수 없다.
오직 작동하는 단순한 시스템으로 다시 시작하는 수밖에 없다.

Nate의 주장:

  • 지금은 프론트엔드 맥시멀리즘이 충분히 통하는데, 미래의 스케일을 이유로 지금부터 복잡한 구조를 설계하는 건 Gall’s Law에 정면으로 반한다.
  • 결국:
    • 지금은 단순하고 잘 작동하는 구조(프론트 맥시멀)로 시작
    • 나중에 진짜로 스케일 문제가 생길 때, 그때 백엔드 구조를 복잡하게 가져가도 늦지 않다.

5-2. 보안

명확한 원칙:

  • 사용자가 가지면 안 되는 데이터는 절대 프론트로 보내면 안 된다.
  • “보내긴 하지만 화면에는 안 보여주겠다”는 건 잘못된 타협:
    • 어차피 네트워크로 내려보냈다면, 공격자는 얼마든지 볼 수 있다는 전제를 둬야 한다.

하지만 이 이야기는 “항상 백엔드가 더 안전하다”와 동치가 아니다.

Nate가 지적하는 보안 측면:

  • 백엔드가 복잡해질수록, 공격 표면(attack surface)은 커진다.
  • 예를 들어:
    • 프론트에서 로컬 데이터만 필터링한다면,
      • 악의적인 필터를 줘도, 어차피 자기 데이터 서브셋만 보게 된다.
    • 반면 같은 필터가 백엔드에 간다면:
      • 쿼리 인젝션, 권한 우회, 이상한 조합으로 데이터 노출 가능성 등 더 많은 위험이 생길 수 있다.
  • 즉:
    • 백엔드는 필연적으로 보안 책임과 리스크를 떠안는다.
    • 프론트에서 할 수 있는 일을 프론트로 밀어낼수록, 백엔드의 복잡도와 리스크도 줄일 수 있다.

6. 프론트엔드 맥시멀리즘이 가능할 때 얻는 이점

조건이 허용해서 프론트엔드 맥시멀 패턴을 쓸 수 있을 때, 다음과 같은 실질적인 장점이 생긴다.

  1. 사용자 경험(UX) 속도 향상
    • 초기 로딩에서 한 번 크게 당기고 나면,
    • 이후 상호작용(필터 변경, 정렬, 상세 보기 등)은 전부 로컬에서 즉각 반응.
  2. 페이지네이션/쿼리 버그 제거
    • “페이지 1과 2에서 중복/누락”, “필터 조합에 따라 데이터 꼬임” 같은 전형적인 API 레벨 버그가 아예 구조적으로 제거된다.
    • 데이터는 이미 프론트에 있고, 화면에서 보여주는 조각만 갈아 끼우면 됨.
  3. 새 기능 추가 비용 감소(미래 확장성)
    • 프론트에서 이미 “다양한 데이터를 한 번에 쥐고 있다”는 전제가 깔려 있으면,
    • 기획자가 새로운 뷰/필터/차트/통계를 요구해도:
      • “API부터 다시 설계 → 백엔드 구현 → 배포” 없이
      • 프론트 코드를 조금만 바꿔서 빠르게 대응 가능.
  4. API 호출 수 감소
    • API 호출/응답은 항상 장애 포인트가 된다.
    • 호출 횟수를 줄이면:
      • 네트워크 불안정 환경에서 더 강인해지고
      • 백엔드도 부담이 줄고
      • 전체 시스템이 단순해진다.
  5. 프라이버시 개선 혹은 최소화
    • 필터링/검색 동작을 프론트에서 한다면:
      • “사용자가 어떤 필터/조합을 시도했는지”가 백엔드 로그에 남지 않는다.
    • 즉, 사용자의 행동 로그를 백엔드에 쌓지 않아도 되는 영역이 늘어난다.

7. 흔한 반론과 이에 대한 답변

7-1. “이렇게 많은 사람들이 다 틀렸다고?”

가장 많이 듣는 반론:

“실무에서 이렇게 안 하는데, 그런 업계 관행이 다 틀렸다는 말인가?”

핵심 반박:

  1. 기존 관행이 스스로 세운 원칙과 모순되는 경우가 많다.
    • 예: “단순함, 테스트 용이성”을 중시한다고 말하면서,
    • 실제 설계에서는 쿼리/페이지네이션/필터 조합으로 백엔드를 매우 복잡하게 만든다.
  2. 툴링의 발전 속도가 ‘소프트웨어 설계 관행’의 업데이트 속도를 초과했다.
    • 소프트웨어 설계에 큰 영향을 준 책/작품들:
      • 1994: Design Patterns
      • 1999: The Pragmatic Programmer
      • 2003: Domain-Driven Design
      • 2006: Joel on Software (영향력 정점)
      • 2008: Clean Code
      • 2018: A Philosophy of Software Design
    • 프론트엔드 맥시멀리즘을 현실적으로 뒷받침하는 기술들:
      • 2000: Python 2.0
      • 2009: pytest(당시 py 1.0.0)
      • 2011: React 첫 도입
      • 2012: TypeScript 초판
      • 2014: Jest 오픈소스화
      • 2014: Swift 1.0
      • 2024: DuckDB 1.0.0
    • 즉, 설계 철학은 90~00년대 기준에 고정된 채로, 프론트·클라이언트 측 기술은 기하급수적으로 발전해 왔다.
    • 이 격차 때문에, 예전 감각으로는 상상하기 어려운 “프론트 엔진에 데이터를 많이 싣는 패턴”들이 이제는 충분히 현실적이다.

7-2. “느린/불안정한 네트워크 사용자는 어떻게 할 건가? 그들을 데이터로 ‘때려버리는’ 거 아닌가?”

원칙은 간단하다:

  • 프론트엔드 맥시멀리즘 때문에 정말로 데이터량이 감당 불가능해지면, 쓰면 안 된다.

하지만 그 전 단계에서 고려해야 할 점:

  1. 느린 네트워크는 보통 “느리고 불안정” 둘 다 문제다.
    • 프론트엔드 맥시멀리즘은:
      • 초기에는 2~10배 정도 더 큰 페이로드를 보낼 수 있지만
      • 그 대신 API 호출 횟수를 크게 줄인다.
    • 불안정한 네트워크 환경에서는
      • 작은 요청 여러 번 실패하는 것보다
      • 조금 큰 요청 한 번 성공하는 쪽이 더 안정적일 때가 많다.
  2. 페이로드가 커졌다면, 다른 방식으로 줄일 수도 있다.
    • 사용하지 않는 필드 제거
    • 지나치게 긴 문자열/포맷 최적화
    • UUID 같은 식별자 축약 등
    • 즉, “프론트엔드 맥시멀리즘 = 무조건 데이터 폭탄”이라는 단순 도식이 아니라,
      • 데이터 구조 자체를 다이어트하면서도 여전히 프론트에 많이 싣는 설계가 가능하다.

8. 기억해야 할 핵심 요약

원문의 마지막 부분을 요약하면 다음 네 줄로 정리된다.

  1. 관성대로 프론트/백엔드 책임을 나누지 말 것.
    • “원래 그렇게 해왔으니까”가 설계 기준이 되어선 안 된다.
  2. 프론트에서 거의 모든 일을 처리하는 방식은 과소평가되어 있다.
    • 현대 브라우저·프레임워크·언어·런타임 환경에서는 가능한 선택지인 경우가 많다.
  3. 프론트엔드 맥시멀리즘을 “진지하게 고려해 보는 것”만으로도 더 나은 설계로 이어질 수 있다.
    • 실제로 채택하지 않더라도,
    • “최대한 프론트로 밀어넣었을 때 구조가 어떻게 단순해지는지”를 생각해 보면,
    • 현재 설계의 불필요한 복잡성과 API 설계 오류를 더 잘 볼 수 있다.
  4. 모듈성(modularity)은 코드 구조로도 충분히 확보할 수 있다.
    • “모듈성과 책임 분리를 위해서”라는 명분으로
      • 굳이 프론트/백엔드 사이를 자잘하게 찢어놓을 필요는 없다.
    • 모든 코드가 프론트에 있더라도,
      • 적절한 계층 분리·모듈화만 잘 하면 충분히 깔끔한 설계가 가능하다.

9. 정리: 언제, 어떻게 이 관점을 적용할 것인가?

실무 관점에서 이 글이 주는 시사점:

  1. 새로운 화면/기능을 설계할 때, 먼저 이렇게 자문해 볼 수 있다.
    • “이 화면에서 사용자가 볼 수 있는 ‘모든 데이터’를 한 번에 다 가져와도 문제가 되지 않는가?”
    • 문제 없다면:
      • 필터/페이지네이션/검색을 백엔드로 넘기기 전에
      • 프론트에서 전부 처리하는 설계를 우선 고려
  2. 프론트에 실어보려다가 걸리는 제약이 있다면, 구체적으로 수치화한다.
    • 총 데이터 용량(평균, 최악의 경우)
    • 네트워크 지연·성능 테스트 결과
    • 실제 유저가 사용하는 필터/조합 패턴
    • 보안/권한 모델
  3. Gall’s Law 관점에서:
    • MVP/초기 버전에서는 프론트엔드 맥시멀리즘이 “기본 옵션”에 가깝다.
    • 스케일 문제나 보안 요구사항이 실제로 생기기 전까지는,
      • 굳이 복잡한 백엔드 쿼리·API 설계를 도입할 필요가 없다.
  4. 장기적으로:
    • 데이터량·보안·조직 구조·팀 역량 등의 이유로
      • 백엔드가 더 많은 책임을 가져가야 하는 시점이 올 수 있다.
    • 그때는
      • 프론트엔드 맥시멀리즘에서 출발한 “단순하고 잘 작동하는 시스템”을
      • 점진적으로 복잡하게 만들어 가면 된다.
profile
okorion
Tech Blog
이전 포스트

AI 에이전트 핸드북 ("The AI agent handbook" 정리)

다음 포스트

npm 의존성 줄이기: 최신 Node.js 기능 15가지 정리

0개의 댓글