적응형과 반응형: 디자이너가 넘기는 것이 달라진다

디자이너: “이번 개편은 반응형으로 갈까요, 적응형으로 갈까요?”

개발자: “브레이크포인트 몇 개로 할지만 정해주시면 돼요.”

30초 만에 끝나는 대화지만 여기서 정해진 건 하나도 없다. 브레이크포인트 개수는 둘 중 무엇을 고르든 나오는 숫자다. 적응형으로 가도 폭이 갈리는 지점은 있고, 반응형으로 가도 구조를 갈아엎는 지점은 남는다. 그 개수만 합의하고 헤어지면 정작 무엇이 갈리는지는 손도 안 댄 채 다음 주에 시안을 그리기 시작한다.

디자이너가 두 낱말을 두고 아는 건 대개 여기까지다. 반응형은 화면이 줄면 레이아웃이 알아서 바뀌는 것, 적응형은 기기별로 따로 만드는 것. 그런데 실무에서 적응형이라는 말은 서로 다른 세 가지를 가리킨다. 같은 회의에서 이 말을 주고받은 두 사람이 서로 다른 것을 정하고 헤어지는 이유가 여기 있다.

적응형과 반응형은 레이아웃 값을 누가 언제 확정하느냐에서 갈리고, 그 차이가 디자이너가 실제로 하는 일까지 바꾼다. 다시 고쳐 쓸 제품 화면이라면 폭을 확정해 넘기는 쪽보다 규칙을 적어 넘기는 쪽이 낫다. 둘이 무엇을 다르게 정하는지, 시안과 명세를 어떻게 다르게 넘기는지, 무엇을 어느 축에서 확인하는지가 차례로 달라진다.

적응형은 폭을 미리 확정하고, 반응형은 브라우저가 그때 계산한다

두 방식이 실제로 다른 건 화면이 몇 번 바뀌느냐가 아니라 레이아웃 값이 확정되는 시점이다. 적응형은 사람이 폭을 몇 개 정해두고 그 폭에서 쓸 값을 미리 확정한다. 반응형은 값이 따라야 할 규칙만 정해두고, 실제 폭이 정해지는 순간 브라우저가 계산하게 둔다. 앞쪽은 결정이 사람 손에서 끝나고, 뒤쪽은 결정이 독자의 브라우저에서 끝난다.

반응형이라는 말을 처음 쓴 글부터 그렇게 되어 있다. Ethan Marcotte가 2010년 A List Apart에 쓴 글은 재료 셋을 든다. 유동 그리드, 유연한 이미지, 미디어 쿼리.Ethan Marcotte, Responsive Web Design, A List Apart, 2010-05-25. 원문은 Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design이다. 셋 중 미디어 쿼리는 하나뿐이고, 나머지 둘이 값을 미리 확정하지 않는 쪽을 맡는다. 그리드는 픽셀이 아니라 비율로 짜고, 이미지는 담긴 자리에 맞춰 줄어든다. 브레이크포인트를 몇 개 쓰느냐로 반응형을 정의할 수 없는 근거가 여기 있다. 브레이크포인트는 재료 셋 중 하나의 일부일 뿐이다.

덧붙이면 Marcotte 자신은 같은 글에서 adaptive를 자기 방식을 설명하는 형용사로 썼다. 화면을 그려내는 매체에 더 유연하고 더 적응적이라는 뜻이었으니, 두 낱말이 처음부터 서로 맞선 이름이었던 게 아니다.같은 글. make them not only more flexible, but more adaptive to the media that renders them.

그럼 지금 적응형이라 불리는 셋은 각각 어디서 값을 확정할까. 확정 시점으로 갈라 놓으면 이렇게 된다.

첫 줄은 Google이 dynamic serving이라 부르는 구성이다. 주소는 하나인데 서버가 접속한 기기를 보고 다른 HTML을 내려보낸다.Google Search Central, Mobile site and mobile-first indexing best practices. dynamic serving은 Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices로 적혀 있고, 같은 문서가 Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain이라고 밝힌다. NN/g가 adaptive design을 정의할 때 가리키는 것도 이쪽이다. 서버가 기기의 능력을 판별해서 그 기기가 감당할 수 있는 내용과 기능만 보낸다는 것이다.Raluca Budiu, Mobile Websites: Mobile-Dedicated, Responsive, Adaptive, or Desktop Site?, NN/g, 2016-02-14. 정의는 Adaptive design is a version of responsive design in which the server detects the capabilities of a client device and only sends content and features that can be appropriately displayed on that device이다.

둘째 줄은 Aaron Gustafson이 쓴 책 제목의 adaptive다. 이건 레이아웃을 짜는 방식이 아니라 단계적 향상(progressive enhancement)을 가리킨다. 기술 사정과 상관없이 내용에 닿게 해주자는 태도에 가깝고, 폭이나 브레이크포인트 얘기가 아니다.Aaron Gustafson, Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement, 1판(2011)의 1장 무료 공개본. 정의는 a philosophy aimed at crafting experiences that serve your users by giving them access to content without technological restrictions이고, 1장 안에 고정폭이나 브레이크포인트를 다루는 대목은 없었다. 내가 확인한 범위는 1장까지다.

셋째 줄이 회의에서 제일 자주 쓰이는 뜻이다. 폭을 몇 개 정해 그 수만큼 시안을 그리고, 각 시안 안의 값은 사람이 그 자리에서 확정한다. 앞의 둘과 결정 주체가 아예 다른데 이름이 같다.

그래서 회의에서 적응형이라는 말이 나오면 셋 중 어느 뜻인지부터 확인한다. 물어볼 것은 하나다. 그 결정을 누가 언제 내리나요, 하고 물으면 된다. 서버라고 답하면 첫째, 브라우저라고 답하면 둘째, 우리가 시안에서라고 답하면 셋째다. 이 질문 하나에 답하면 회의에서 남은 얘기가 갈린다.

확정 시점이 다르면 그 결정을 준비하는 사람의 일도 달라진다. 먼저 시안이고, 그다음이 검수다.

적응형은 폭을 정한 근거를, 반응형은 무엇이 늘어나고 어디서 멈추는지를 넘긴다

반응형으로 가기로 하면 디자이너가 넘기는 것이 화면 장수에서 값이 변하는 규칙으로 바뀐다. 폭을 여섯 개 잡아 여섯 장을 그려 넘기는 대신, 요소마다 늘어날 것, 고정할 것, 최소와 최대를 적어 넘긴다. 화면을 덜 그리는 게 아니라 다른 것을 그린다.

규칙을 적는 칸은 이미 도구 안에 있다. Figma 오토 레이아웃의 크기 조절이 셋이다. Fixed는 주변이 바뀌어도 크기가 그대로고, Hug contents는 자식 크기에 맞춰 줄어들고, Fill container는 남는 공간을 채운다.Figma Help Center, Guide to auto layout. 크기 조절 속성 표에 Hug contents는 Object resizes based on its child objects, Fill container는 Object fills all available space, Fixed width / height는 Object size stays fixed로 적혀 있다. 최소 폭과 최대 폭은 따로 Minimum and maximum dimensions is an additional setting that can be used at the same time as other resizing properties라고 밝힌다. 이 셋이 그대로 명세다. 이건 고정, 이건 내용만큼, 이건 늘어남. 여기에 최소 폭과 최대 폭을 얹으면 늘어나는 범위의 양 끝까지 시안 안에서 말할 수 있다. 이미 그렇게 만들어 두고 정작 넘길 때는 스크린샷 여섯 장을 넘기는 경우가 흔하다.

그래서 개발자에게 넘기는 문서는 요소 이름 옆에 세 칸이면 된다. 폭 규칙, 그 규칙이 움직일 수 있는 범위, 정보 구조가 바뀌는 지점이다. 카드 목록 하나를 예로 채우면 이렇게 된다.

숫자는 이 예시에서 정한 값이고 표준이 아니다. 중요한 건 어느 칸에 무엇을 적느냐다. 재배치 칸에 크기가 줄어든다고 적지 마라. 카드가 320px에서 300px으로 좁아지는 건 폭 규칙에 이미 적혀 있다. 여기 적을 건 두 열이 한 열이 되는 곳, 사이드바가 접히는 곳, 보조 정보가 사라지는 곳처럼 정보가 재배치되는 지점뿐이다. 이 구분을 안 하면 넘긴 문서가 다시 폭 나열이 되고, 규칙으로 넘긴 이유가 사라진다.

가운데 칸을 왜 채워야 하는지는 남의 화면을 재보면 바로 나온다. 2026년 7월 26일에 이 블로그와 기술블로그 세 곳의 글 페이지를 브라우저로 열어, 창 폭만 바꿔가며 본문 문단이 화면에 그려진 폭을 쟀다. 네 곳 다 어느 지점부터 본문 폭이 딱 멈췄고, 거기서 창을 1600px까지 넓혀도 그대로였다. 멈추는 폭은 곳마다 달랐다. 값이 흐른다고 끝없이 늘어나지는 않는다는 뜻이다. 잰 표와 자세한 방법은 뒤에 있다. 여기서 가져갈 것만 먼저 적으면, 시안에 최대 폭을 안 적어 넘길 때 그 숫자를 정하는 사람은 개발자가 된다.

표를 채우는 순서도 정해두면 빠르다. 시안을 열고 바깥 프레임에서 안쪽으로 내려가면서, 요소를 고를 때마다 오른쪽 패널에 이미 잡혀 있는 크기 조절 값을 그대로 폭 규칙 칸에 옮겨 적는다. 여기까지 하면 대부분 채워지고 아직 안 정한 칸만 남는다. 남는 건 대개 셋 중 하나다. 오토 레이아웃을 안 쓴 요소, 최소나 최대를 안 정한 요소, 좁은 시안과 넓은 시안에서 서로 다르게 그려 놓고 그 사이를 안 정한 요소.

개발자가 제일 자주 되묻는 것이 세 번째다. 좁은 쪽에서는 세로로 쌓아 놓고 넓은 쪽에서는 가로로 눕혀 놨는데, 그 사이 어느 폭에서 눕는지는 시안 어디에도 없기 때문이다. 이 값을 정하는 요령은 폭을 고르는 게 아니라 조건을 고르는 것이다. 몇 픽셀에서 눕느냐가 아니라 무엇이 안 들어가면 눕느냐로 적는다. 카드가 240px보다 좁아지면 눕는다고 적으면 개발자가 그 조건을 그대로 옮길 수 있고, 나중에 같은 카드를 좁은 곳에 재사용해도 조건이 그대로 통한다. 900px에서 눕는다고 적으면 그 숫자는 지금 이 화면에서만 맞는다.

적응형으로 가기로 하면 산출물의 순서가 바뀐다. 이때는 폭을 몇 개로 정할지가 그 자체로 산출물이고, 그 숫자의 근거를 대는 게 디자이너 몫이 된다. 기기 이름을 늘어놓는 것은 근거가 아니다. NN/g의 Kelley Gordon은 브레이크포인트 값을 정하는 출발점으로 우리 사이트에 들어오는 사람들이 실제로 쓰는 기기의 화면 범위를 분석하고 흔한 크기에 맞추라고 쓴다.Kelley Gordon, Breakpoints in Responsive Design, NN/g, 2024-04-05. 원문은 A starting point for determining the exact values for these breakpoints would be to analyze the range of devices that your audience uses when accessing your site and then establish the breakpoints so you optimally accommodate the more common display sizes이다. 같은 글이 예시로 든 구간이 있지만 그 값은 customizable이라고 밝혔으므로 표준으로 옮겨 쓰면 안 된다. 그러니 적응형을 고르면 첫 산출물은 시안이 아니다. 우리 방문자의 화면 폭 분포 한 장이다. 그걸 못 뽑으면 폭을 정할 근거가 없고, 근거 없이 정한 숫자는 왜 하필 그 폭이냐는 질문에 답하지 못한다.

어느 쪽으로 가든 시안 옆에 확정 시점을 적어 둔다. 적응형이면 이 폭에서 이 값이라고 적고, 반응형이면 이 규칙으로 브라우저가 계산한다고 적는다. 한 줄이면 되는데 이게 없으면 받는 쪽은 시안에 적힌 숫자를 전부 확정된 값으로 읽는다. 왜 마음대로 늘어나게 짰냐고 개발자를 탓하는 말은 대개 여기서 나온다.

넘기는 것이 달라지면 받아본 결과를 확인하는 방법도 달라진다.

적응형은 정해둔 폭에서, 반응형은 폭 구간 전체와 입력 방식까지 확인한다

반응형에서는 검수 대상이 점 몇 개에서 구간 전체로 넓어지고, 확인해야 할 축도 폭 하나가 아니게 된다. 폭을 여섯 개 정해두면 검수도 여섯 번이라는 계산이 설 것 같지만, 실제로는 그 계산이 두 군데서 어긋난다.

먼저 바닥 폭은 취향이 아니라 기준이 정해준다. WCAG 2.2의 리플로 항목(SC 1.4.10, AA)은 320 CSS 픽셀(320px) 폭에서 가로세로 두 방향으로 스크롤하지 않고 내용이 다 보여야 한다고 적는다. 이 숫자는 아무 데서나 나온 게 아니라 1280px 화면을 400퍼센트로 확대한 것과 같다. 단 지도나 다이어그램처럼 두 방향 배치가 있어야 뜻이 서는 내용은 기준에서 빼준다.W3C, WCAG 2.2 Understanding SC 1.4.10 Reflow (Level AA). 원문은 Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: Vertical scrolling content at a width equivalent to 320 CSS pixels이고, 뒤에 Except for parts of the content which require two-dimensional layout for usage or meaning이라는 단서가 붙는다. 같은 문서가 그 예로 images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells)를 든다. 320px의 근거는 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom이다. 그래서 정해둔 폭 목록으로는 이 기준을 통과하기 어렵다. 목록에 320px이 없으면 확대해서 보는 사용자에게 가로 스크롤이 생기고, 넣어도 끝나지 않는다. 확대 배율은 사용자가 아무 값으로나 잡으므로 목록 사이의 폭이 실제로 생긴다. 유한하다고 믿었던 검수가 실은 유한하지 않다.

그러면 구간 전체는 어떻게 보나. 브라우저 창을 잡고 끌면서 본문 폭이 어떻게 변하는지 본다. 앞에서 잰 네 곳의 값을 그대로 펴면 이렇게 된다.Playwright로 Chromium을 띄우고 창 폭만 바꿔가며 같은 글 페이지를 다시 열었다. 이 환경에서는 Chromium이 바깥 네트워크에 직접 붙지 못해, 요청을 scripts/lib/curl_routing.mjs로 curl에 넘기고 받은 응답을 브라우저에 채워 넣었다. 재는 값은 Chromium이 실제로 잡은 레이아웃 폭이지만 무엇이 로드됐는지는 보통의 방문과 다를 수 있다. 각 폭에서 글자 수 60자 이상인 문단의 렌더 폭 중앙값을 적었다. 서비스마다 본문 컨테이너의 클래스 이름이 달라 선택자를 맞출 수 없어 긴 글이 실제로 놓인 상자를 공통 기준으로 삼았다(이 블로그 값은 .markdown 기준이다). 원자료와 매 측정의 후보 문단 수는 저장소의 .harness/research/adaptive-responsive-widths-2026-07-26.json에 있다. 재려다 뺀 곳이 두 군데 더 있다. 한 곳은 문단이 하나도 안 잡혔고 다른 한 곳은 페이지가 열리지 않았는데, curl로 같은 주소를 다시 받아 보니 각각 403과 302였다. 본문에 문단이 없는 게 아니라 페이지를 못 받은 것이라 값이 아니라 이름을 뺐다. 표본은 네 곳뿐이므로 웹 전체의 경향으로 읽으면 안 된다.

표를 한 줄로 줄이면 이렇다. 네 곳 다 멈추는 최대 폭에 닿기 전까지는 창을 끄는 대로 본문 폭이 따라 움직였고, 그러면서도 넷 다 어딘가에는 사람이 값을 잡아 둔 지점이 있었다. 그러니 검수할 화면은 반응형이냐 적응형이냐로 고르는 문제가 아니라, 어느 값을 규칙에 맡기고 어느 지점만 사람이 잡을지를 정하는 문제다. 구간은 끌어서 보고 지점은 앞뒤 1px로 본다. 재기 전에 기대한 것과 실제로 나온 것을 차례로 적는다.

첫 그림의 왼쪽 점선 같은 화면을 하나 보여주려고 재기 시작했는데, 잰 네 곳에서는 안 나왔다. 넷뿐이라 여기서 더 나가지는 않는다.

화면 전체가 그런 곳은 없었지만 값이 안 변한 구간은 표 안에 여러 군데 있고, 그중 하나가 여기서 하려던 얘기다. 카카오는 창 폭 320과 360에서 본문 폭이 둘 다 320px이다. 폭이 따라 줄어서 같은 게 아니라 안 줄어서 같다. 창이 320px일 때 페이지가 그려진 폭은 360px이라 가로 스크롤이 생겼다. 320px에서 페이지가 창보다 넓게 그려진 곳은 잰 네 곳 중 카카오뿐이다. 무엇이 넘쳤는지까지는 안 봤으니 리플로 기준을 어겼다고 단정하지는 않는다. 다만 320px에서 볼 것이 본문 폭이 아니라 가로 스크롤이라는 건 카카오의 이 두 줄이 그대로 보여준다. 표만 훑으면 그냥 값이 안 변한 줄로 지나친다.

한 번에 값이 바뀌는 지점도 남아 있다. 이 블로그와 토스는 768과 776 사이에서 본문 폭이 한 번에 떨어진다. 떨어지는 폭은 이 블로그가 8px, 토스가 26px다. 8px 간격으로 다시 재보니 두 곳 다 그 사이에서 한 번 떨어지고 끝났다. 완전 유동으로 짠 화면이 아니라 유동 규칙과 재배치 지점이 섞인 화면이라는 뜻이고, 앞에서 갈라 보라고 한 구간과 지점이 실제로 한 페이지 안에 같이 있다.

둘째로, 확인할 축이 폭 하나가 아니다. 여기서 나오는 실무 지침은 한 줄이다. 터치 타깃 크기를 뷰포트 폭으로 정하지 마라. 폭이 넓어도 손가락으로 쓰는 화면이 있고 좁아도 마우스로 쓰는 화면이 있다. 미디어 쿼리에는 그 조건을 따로 묻는 기능이 있고 이름은 pointer다. 값이 coarse면 정확도가 낮은 포인팅 장치, 곧 손가락이다.W3C, Media Queries Level 4, 7. Interaction Media Features. pointer는 used to query the presence and accuracy of a pointing device such as a mouse로 정의되고, 값은 none, coarse, fine 셋이다. coarse는 a pointing device of limited accuracy다. 같은 묶음에 hover와 any-pointer가 있다. 사용자 선호를 묻는 prefers-reduced-motion, prefers-color-scheme, prefers-contrast는 Level 4가 아니라 그다음 판인 Level 5에 들어 있다. 확인하는 법도 어렵지 않다. 브라우저 개발자 도구에서 기기 모드로 바꾸고 휴대폰을 하나 고르면 coarse로 잡힌 화면을 볼 수 있다.

그래서 개발자에게 넘기는 확인 절차도 폭을 늘어놓은 것이 아니다. 네 줄이면 된다.

1. 320px에서 열어 가로로 스크롤이 생기는지 본다.
2. 재배치 지점 앞뒤로 각각 1px씩 본다. 767과 768을 나란히 놓고 무엇이 바뀌는지 확인한다.
3. 창을 잡고 최소 폭에서 최대 폭까지 한 번 끝까지 끈다.
4. 기기 모드로 바꿔 pointer: coarse 상태에서 한 번 본다.

폭을 정해두면 검수가 유한해진다는 반론

여기까지 읽고도 반대할 수 있고, 그 반대는 약하지 않다. 반응형은 확인해야 할 폭이 사실상 무한이라 어디서 깨지는지 알 수 없다는 것이다. 폭을 여섯 개로 확정하면 시안도 여섯 장, 검수도 여섯 번, 승인도 여섯 번으로 끝난다. 결과가 픽셀 단위로 예측되고, 승인받은 그림과 실제로 나온 화면이 같다. 그림과 결과가 같다는 건 협업에서 생각보다 큰 값어치다. 수명이 짧고 비주얼이 정확해야 하는 캠페인 페이지에서는 이쪽이 실제로 더 빠르고 더 안전하다.

맞는 말이다. 값이 구간 내내 흐르면 어느 폭에서 제목이 두 줄로 접히는지, 어느 폭에서 카드가 어색하게 늘어지는지 미리 알기 어렵고, 이건 반응형이 실제로 치르는 값이다. 이 트레이드오프는 앞 글에서 한 번 다뤘다.

그래도 세 가지가 남는다. 첫째, 앞에서 본 320px 리플로 기준은 폭을 정해둔다고 피할 수 없다. 확대 배율에 정해진 눈금이 없으니 목록에 없는 폭이 실제로 생기고, 그 계산 자체가 성립하지 않는다. 반대로 확인할 폭이 무한이라는 말도 실제보다 크게 들린다. 앞에서 잰 네 곳은 저마다 멈추는 최대 폭이 있었고, 두 곳에는 한 번에 바뀌는 지점도 있었다. 한 번 끌어보면 무한이라던 것이 끝과 마디가 있는 선으로 잡힌다.

둘째, 정해둔 폭에는 수명이 있다. 그 숫자를 정한 근거는 그때 방문자가 쓰던 화면이다. 분포가 바뀌면 숫자를 다시 정해야 하고, 그때 여섯 장을 전부 다시 그린다. 규칙으로 넘긴 쪽은 최소와 최대 두 숫자만 고치면 된다. 여섯 장을 다시 그리는 비용은 처음 여섯 장을 그릴 때는 안 보이고 2년 뒤에 온다.

셋째, 같은 컴포넌트가 넓은 본문과 좁은 사이드바에 동시에 놓이면 뷰포트 폭이 답을 못 준다. 이건 앞 글이 컨테이너 쿼리로 다룬 내용이라 여기서는 짚고 넘어간다.

그래서 반론이 옳은 경우를 좁혀서 인정한다. 수명이 짧고 화면이 하나뿐이고 다시 안 고칠 캠페인 페이지라면 폭을 정해두는 쪽이 낫다. 제품 화면과 여러 곳에서 재사용하는 컴포넌트에는 그 계산이 성립하지 않는다.

정리: 시안 장수에서 규칙으로

두 방식을 가르는 건 화면을 몇 장 준비하느냐가 아니라 값이 언제 정해지느냐다. 그 결정이 디자인 단계에서 끝나면 시안이 산출물이 되고, 브라우저에서 끝나면 규칙이 산출물이 된다.

적응형이라는 말이 가리키던 셋은 서버, 브라우저 능력, 시안으로 갈렸고, 가르는 기준은 결정이 언제 끝나느냐 하나였다. 규칙을 적어 넘길 칸은 새로 만들 것 없이 오토 레이아웃 안에 이미 있었다. 바닥 폭은 내가 고른 값이 아니라 접근성 기준이 준 값이었고, 재본 네 곳은 값이 흐르면서도 저마다 사람이 잡은 지점이 있었다. 그래서 확인할 것은 폭 목록이 아니라 그 구간과 지점이고, 손가락으로 쓰는 화면인지도 따로 봐야 했다.

다음 개편에서 시안 여섯 장을 그리기 전에 위 네 칸짜리 표부터 채워 봐라. 다 채우고 나면 그려야 할 시안은 양 끝 두 장으로 줄어 있다. 넘기기 전에 320px에서 한 번 열어 봐라.