적응형(Adaptive) vs 반응형(Responsive)과 React 반응형 컴포넌트 패턴

이 글은 React로 반응형 웹 구성하기 시리즈 8편(마지막)입니다.

• 6편: JS로 반응형 다루기: matchMedia, useMediaQuery, ResizeObserver와 SSR 하이드레이션 함정
• 7편: 반응형 이미지와 타이포그래피: srcset, next/image, 유동 타이포그래피

지금까지 다룬 기법들은 모두 하나의 큰 전제를 공유했습니다. 하나의 코드가 화면 크기에 따라 유동적으로 대응한다는 것, 즉 반응형(Responsive)입니다. 그런데 이와 대비되는 접근이 하나 더 있습니다. 화면을 몇 개의 정해진 유형으로 나누고, 유형마다 미리 만든 별개의 레이아웃을 내려주는 적응형(Adaptive)입니다.

이 둘의 차이를 이해하면, "서버에서 모바일/데스크톱을 판단해 다른 걸 내려줄까?" 같은 실무 질문에 근거 있게 답할 수 있습니다. 시리즈의 마지막 글에서는 적응형과 반응형을 비교하고, React에서 반응형 컴포넌트를 구성하는 패턴과 테스트까지 정리하며 마무리합니다.

한눈에 보면

• 반응형: 하나의 유동 레이아웃이 모든 폭에 대응. 적응형: 정해진 몇 개 유형별로 별개 레이아웃을 제공.
• 적응형은 서버에서 기기를 감지해 다른 HTML을 내려주기도 하는데, 서버는 화면 폭을 정확히 알 수 없어(UA 추정뿐) 한계가 분명합니다.
• 오늘날 기본값은 반응형이고, 적응형은 "특정 기기에 완전히 다른 경험"이 필요한 예외적 상황에서 부분적으로 씁니다.
• React 반응형 컴포넌트 패턴의 우선순위: 하나가 유동 대응 → CSS로 보이기/숨기기 → 정말 다르면 조건부 렌더.
• "둘 다 렌더하고 CSS로 감추기"는 간단하지만 중복 비용이 있고, "JS로 하나만 렌더"는 SSR 깜빡임 위험이 있습니다. 상황에 맞게 고릅니다.
• 반응형은 만들고 끝이 아니라 여러 뷰포트에서 검증해야 완성됩니다.

적응형 vs 반응형

두 접근의 근본 차이는 "하나의 유동 레이아웃이냐, 여러 개의 고정 레이아웃이냐"입니다.

flowchart TD
    user["사용자 요청"]
 
    subgraph R["반응형 (Responsive)"]
        r1["하나의 코드/레이아웃"] --> r2["폭에 따라 유동적으로 변형"]
    end
 
    subgraph A["적응형 (Adaptive)"]
        a1{"기기 유형 판단"}
        a1 -->|모바일| a2["모바일 전용 레이아웃"]
        a1 -->|데스크톱| a3["데스크톱 전용 레이아웃"]
    end
 
    user --> r1
    user --> a1
 
    style R fill:#dcfce7,stroke:#22c55e,color:#111
    style A fill:#dbeafe,stroke:#3b82f6,color:#111

서버 기기 감지의 한계

적응형의 한 형태로, 서버가 요청의 User-Agent를 보고 "모바일이면 모바일용 HTML"을 내려주는 방식이 있습니다. 6편에서 본 하이드레이션 깜빡임을 서버에서 미리 갈라 피할 수 있다는 게 매력입니다. 하지만 한계가 큽니다.

• UA는 부정확합니다. 태블릿, 폴더블, 데스크톱 모드 브라우저 등은 깔끔하게 분류되지 않습니다.
• UA는 폭을 알려주지 않습니다. "모바일"이라도 실제 폭은 320px부터 다양하고, 창 크기 조절이나 화면 회전도 반영 못 합니다.
• 캐싱이 복잡해집니다. 같은 URL이 UA에 따라 다른 HTML을 내려주면 CDN 캐시 전략이 까다로워집니다.

Next.js에서도 요청 헤더의 UA를 읽을 수는 있지만(예: 미들웨어), 이는 "정밀한 폭 판단"이 아니라 "대략적인 힌트"로만 쓰는 게 안전합니다. 정확한 폭 대응은 결국 클라이언트의 CSS가 담당합니다.

정리: 레이아웃의 정확한 폭 대응은 CSS(반응형)에 맡기고, 서버 UA 판단은 보조적 힌트로만 씁니다.

React 반응형 컴포넌트 패턴

이제 실전입니다. "모바일과 데스크톱에서 다르게 보여야 하는" 컴포넌트를 React에서 구성하는 방법은 여러 가지인데, 우선순위가 있습니다.

패턴 1. 하나의 컴포넌트가 유동 대응 (가장 우선)

가능하면 두 개로 나누지 말고, 하나가 CSS(3편의 Grid, 4편의 컨테이너 쿼리)로 스스로 변형되게 만드는 게 가장 깔끔합니다.

// 구조는 하나, 배치만 CSS로 바뀜 (컨테이너 쿼리/Grid 활용)
export function ProfileCard({ user }: { user: User }) {
  return (
    <article className="profile-card">
      <img src={user.avatar} alt="" />
      <div>
        <h3>{user.name}</h3>
        <p>{user.bio}</p>
      </div>
    </article>
  );
}

DOM이 하나뿐이라 중복도 깜빡임도 없습니다. 대부분의 경우 이 패턴을 가장 먼저 시도해야 합니다.

패턴 2. CSS로 보이기/숨기기

구조가 근본적으로 달라 하나로 합치기 어렵지만, 양쪽을 모두 렌더해도 될 만큼 가벼울 때 씁니다. 두 마크업을 모두 렌더하되 CSS로 하나만 보이게 하는 방식으로, 단순하고 SSR에 안전합니다.

export function Nav() {
  return (
    <>
      <DesktopNav className="hidden md:block" />
      <MobileNav className="block md:hidden" />
    </>
  );
}

• 장점: 서버·클라이언트 결과가 같아 깜빡임이 없고, 두 마크업 모두 HTML에 있어 SEO에도 유리합니다.
• 단점: 두 컴포넌트를 모두 렌더하므로, 무거운 컴포넌트라면 중복 비용이 생깁니다.

패턴 3. 정말 다르면 조건부 렌더 (최후의 수단)

DOM 구조가 근본적으로 다르고 무거워서 둘 다 렌더할 수 없다면, 6편의 useMediaQuery로 하나만 렌더합니다. 대신 SSR 깜빡임을 감수하거나 스켈레톤으로 감춰야 합니다.

'use client';
export function HeavyWidget() {
  const isDesktop = useMediaQuery('(min-width: 768px)');
  const mounted = useMounted(); // 6편의 방식
 
  if (!mounted) return <WidgetSkeleton />; // 첫 렌더 깜빡임 방지
  return isDesktop ? <DesktopWidget /> : <MobileWidget />;
}

패턴 선택 흐름

flowchart TD
    q["모바일/데스크톱에서 다르게 보여야 함"]
    q --> same{"하나의 구조가<br/>CSS로 변형 가능한가?"}
    same -->|"예"| p1["패턴 1: 유동 대응<br/>(가장 우선)"]
    same -->|"아니오"| heavy{"양쪽을 모두<br/>렌더해도 될 만큼 가벼운가?"}
    heavy -->|"예"| p2["패턴 2: CSS로 show/hide"]
    heavy -->|"아니오"| p3["패턴 3: 조건부 렌더<br/>(+스켈레톤)"]
 
    style p1 fill:#dcfce7,stroke:#22c55e,color:#111
    style p2 fill:#dbeafe,stroke:#3b82f6,color:#111
    style p3 fill:#fef9c3,stroke:#eab308,color:#111

반응형은 검증까지가 완성

반응형은 코드를 짠 순간이 아니라 여러 폭에서 확인했을 때 완성됩니다. 최소한 이 정도는 점검합니다.

• 브라우저 개발자 도구의 반응형 모드로 대표 폭(360 / 768 / 1024 / 1440)과 그 사이 구간을 확인합니다. 계단 사이(예: 800px, 1000px)에서 어색함이 없는지 봅니다.
• 폰트 확대(브라우저 200%)와 가로/세로 회전에서 레이아웃이 견디는지 봅니다.
• 자동화가 필요하면 Playwright 등으로 여러 뷰포트에서 스크린샷을 찍어 회귀를 잡습니다.

// Playwright: 여러 뷰포트에서 스냅샷
import { test, expect } from '@playwright/test';
 
const viewports = [
  { name: 'mobile', width: 360, height: 800 },
  { name: 'tablet', width: 768, height: 1024 },
  { name: 'desktop', width: 1440, height: 900 },
];
 
for (const vp of viewports) {
  test(`홈 레이아웃 - ${vp.name}`, async ({ page }) => {
    await page.setViewportSize({ width: vp.width, height: vp.height });
    await page.goto('/');
    await expect(page).toHaveScreenshot(`home-${vp.name}.png`);
  });
}

정리하면

시리즈를 마무리하며, 반응형 웹을 구성하는 핵심을 한 번에 정리합니다.

• 적응형은 유형별 고정 레이아웃, 반응형은 하나의 유동 레이아웃 — 오늘날 기본값은 반응형이고, 서버 UA 감지는 보조 힌트로만 씁니다.
• 컴포넌트 패턴 우선순위: 하나가 유동 대응(패턴 1) → CSS show/hide(패턴 2) → 조건부 렌더(패턴 3).
• 반응형은 검증까지가 완성 — 브레이크포인트뿐 아니라 그 사이 구간, 폰트 확대, 회전까지 확인합니다.

시리즈 전체 요약

1편부터 여기까지의 흐름을 한 문장씩으로 요약하면 이렇습니다.

• 1편: 뷰포트·미디어 쿼리·모바일 퍼스트로 토대를 잡는다.
• 2편: clamp()와 유동 단위로 브레이크포인트 사이를 잇는다.
• 3편: Flexbox·Grid의 auto-fit으로 미디어 쿼리를 줄인다.
• 4편: 컨테이너 쿼리로 컴포넌트가 자기 자리에 맞게 반응한다.
• 5편: 그 규칙들을 Tailwind·CSS-in-JS·CSS Modules 중 팀에 맞는 도구로 표현한다.
• 6편: CSS로 안 될 때만 JS로 분기하되 SSR 함정을 안전하게 처리한다.
• 7편: 이미지·타이포그래피까지 맞춰 성능과 가독성을 완성한다.
• 8편: 적응형과 비교해 접근을 정하고, 패턴과 테스트로 마무리한다.

관통하는 원칙은 하나입니다. 되도록 CSS에게 맡기고, 큰 전환은 계단(미디어 쿼리)으로, 그 사이는 경사로(유동 단위)로, 컴포넌트는 자기 컨테이너 기준으로 반응하게 만든다. JavaScript는 정말 필요할 때만 최후의 수단으로 씁니다.

같이 보면 좋은 글

• 1편: 반응형 웹의 기본: 뷰포트, 미디어 쿼리, 모바일 퍼스트
• 6편: JS로 반응형 다루기: matchMedia, useMediaQuery, ResizeObserver와 SSR 하이드레이션 함정