적응형과 반응형: 원래 반대말이 아니었다

개발자: “이건 적응형으로 가는 게 낫겠는데요.”

디자이너: “적응형이요? 반응형이랑 뭐가 다른데요?”

개발자: “적응형은 화면 크기별로 레이아웃을 따로 만드는 거고, 반응형은 하나로 다 대응하는 거죠.”

디자이너: “그럼 지금 우리가 만들고 있는 건 어느 쪽이에요?”

여기서 대화가 멈춘다. 나도 이 자리에 여러 번 있었고, 매번 대충 넘겼다. 부끄러운 얘기지만 지금도 방심하면 헷갈린다.

그런데 헷갈릴 만하다. 뒤에서 원문을 하나씩 열어 보겠지만, 이 두 말은 애초에 반대말로 만들어진 게 아니다. 서로 반대라는 구도는 한참 뒤에 업계가 붙인 것이다. 원래 없던 대립을 놓고 다투는 셈이니 결론이 안 나는 게 당연하다.

조금씩 바뀌면 반응형, 한 번에 바뀌면 적응형이라는 판별법

말로 가르기 전에 눈으로 보는 게 빠르다. 브라우저 창의 오른쪽 끝을 잡고 아주 천천히 왼쪽으로 끌어보자. 1600px쯤에서 시작해서 320px까지, 한 번에 확 줄이지 말고 손끝으로 밀듯이.

사이트에 따라 두 가지 중 하나가 보인다.

하나는 줄이는 내내 조금씩 같이 바뀐다. 본문 폭이 창을 따라 계속 좁아지고, 여백도 같이 줄고, 이미지도 따라 작아진다. 어느 한 순간에 확 바뀌는 게 아니라, 창을 미는 만큼 화면도 그만큼 따라온다.

다른 하나는 한참 아무 일도 안 일어난다. 창을 200px 줄여도 화면이 그대로다. 그러다 어느 폭에 닿는 순간 배치가 통째로 다른 모양이 된다. 그리고 또 한참 아무 일도 안 일어난다.

여기서 누구나 같은 결론을 내린다. 조금씩 바뀌면 반응형, 한 번에 바뀌면 적응형. 실제로 이렇게 설명하는 글이 아주 많다.

그리고 이 결론은 틀렸다.

조금씩이냐 한 번에냐로 재면 Bootstrap도 이 블로그도 적응형이다

먼저 흔한 오해 하나를 치우자. 미디어 쿼리(media query)를 쓰면 반응형이라는 설명이 있는데, 정작 Marcotte가 쓴 원문과는 안 맞는다. 그가 2010년에 반응형 웹 디자인이라는 이름을 붙이면서 꼽은 재료는 셋이었다. 유동 그리드, 유연한 이미지, 그리고 미디어 쿼리. 유동 그리드는 칸 폭을 px가 아니라 %로 잡아 창을 따라 늘고 주는 격자를 말한다.Marcotte, E. (2010), “Responsive Web Design,” A List Apart 306. 원문: Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. 미디어 쿼리는 셋 중 하나일 뿐이다. 있다고 반응형이 되지 않는다.

그럼 앞 절의 테스트는 어떤가. 이건 더 나쁘다. 셋을 확인해 보자.

먼저 Bootstrap이다. 세상에서 가장 많이 쓰는 반응형 프레임워크다. 그 기본 컨테이너는 브레이크포인트마다 폭이 정해져 있고, 그 사이에서는 전혀 안 움직인다. 앞의 테스트를 그대로 대면 기본 Bootstrap은 적응형이 된다. 그런데 Bootstrap 공식 문서는 이 컨테이너를 반응형 고정폭 컨테이너라고 부른다.Bootstrap 5.3 Layout/Containers. 원문: Our default .container class is a responsive, fixed-width container, meaning its max-width changes at each breakpoint. 우리가 서로 반대라고 놓은 두 말이 한 문장 안에 나란히 붙어 있다.

다음은 repeat(auto-fit, minmax(240px, 1fr))이다. 미디어 쿼리가 한 줄도 없는 선언인데, 창을 줄이면 열 수가 3열에서 2열로 한 번에 뛴다. 열 개수는 정수라 반쯤 있을 수가 없기 때문이다. 그런데 열 하나하나의 폭은 1fr이라 그 사이에서 계속 변한다. 선언 한 줄 안에서 한 번에 뛰는 것과 조금씩 변하는 것이 같이 일어난다. 앞 글에서 이걸 반응형의 최신형으로 소개했는데, 앞 절의 테스트로 재면 적응형이 된다.

마지막은 이 블로그다. 본문 컨테이너가 max-width: 1200px이라 창이 1600px에서 1220px로 줄 때까지 아무것도 안 움직인다. 내 블로그도 그 테스트로는 적응형이다.

셋 다 드문 경우가 아니다. max-width 상한은 거의 모든 사이트가 본문에 건다. 그러니 이 테스트로는 사이트에 이름표를 못 붙인다. 지금 보고 있는 폭 구간에서 무슨 일이 벌어지는지 확인할 수 있을 뿐이다.

브레이크포인트를 사람이 골랐나, 브라우저가 쟀나

그래서 기준을 바꿔야 한다. 화면이 한 번에 바뀌느냐를 볼 게 아니라, 바뀌는 그 지점을 누가 정했느냐를 봐야 한다.

사람이 기기 목록을 펼쳐놓고 375, 768, 1440을 골라 미리 박았다면 적응형 쪽이다. 반대로 사람은 최소치만 알려주고 브라우저가 정했다면 반응형 쪽이다. 이 글이 읽히려면 최소 몇 픽셀은 필요하다고만 일러두고, 지금 이 자리가 몇 픽셀인지는 브라우저가 재게 두는 식이다. 화면이 한 번에 바뀌는 건 둘 다에서 일어난다. 다른 건 그 지점의 출처다.

이 기준으로 보면 auto-fit은 반응형이다. 열이 한 번에 뛰긴 하지만 그 지점을 사람이 정하지 않았다. 240px이라는 최소치만 알려줬고 몇 열로 접을지는 브라우저가 폭을 재서 정했다. Bootstrap의 기본 컨테이너는 반대다. 폭이 안 변하는 구간이 있어서가 아니라, 그 폭 목록을 사람이 미리 골라 박았기 때문에 적응형 쪽에 가깝다.

가르는 대상도 사이트 전체가 아니다. 폭 구간 하나, 컴포넌트 하나를 놓고 따져야 한다. 같은 페이지가 720px 아래에서는 창을 따라 흐르고 1200px 위에서는 멈춰 있을 수 있다. 이 사이트는 반응형입니다라는 문장은 그래서 대체로 부정확하다. 글 첫머리에서 디자이너가 우리가 만드는 건 어느 쪽이냐고 물었을 때 대화가 멈춘 이유가 여기 있다. 사이트 하나에 이름표 하나를 붙일 수가 없어서다.

Allsopp이 먼저 적응을 말했고 Marcotte는 그걸 목표로 삼았다

여기까지 오면 이상하다. 기준을 이렇게까지 손봐야 겨우 나뉜다면, 애초에 이 둘이 정말 반대되는 말이 맞나.

원문을 열어보면 답이 나온다. 아니다.

시작은 2010년 Marcotte가 아니라 2000년 John Allsopp이다. 그는 A Dao of Web Design이라는 글에서 이렇게 지적했다. 종이에서 하던 대로 웹에서도 화면을 마음대로 통제하려 든다는 것이다. 그런데 웹은 원래 그렇게 통제되는 물건이 아니라고 그는 썼다. 그리고 자기 글 전체를 한 줄로 줄인다. 지금까지 말한 유연함을 나는 적응성이라고 부른다고, 결국 하려던 말은 적응하는 페이지를 만들라는 것이라고.Allsopp, J. (2000-04-07), “A Dao of Web Design,” A List Apart. 5절 제목이 Adaptability is accessibility다. The flexibility I’ve talked about so far I think of as “adaptability.” Everything I’ve said so far could be summarized as: make pages which are adaptable.

2000년이다. Gustafson의 책보다 11년, Marcotte의 글보다 10년 앞선다. 웹 디자인에서 적응이라는 말을 정면으로 내세운 이른 사례가 이것인데, 그가 말한 적응에는 레이아웃도 들어 있다. 다만 폭을 몇 개 정해 박는 게 아니라 퍼센트로 잡아 창을 따라 늘고 줄게 하는 쪽이다. 창이 넓어지고 좁아지는 대로 요소가 비율을 유지하며 따라가면 그게 적응하는 페이지라고 그는 썼다.Allsopp (2000), 8절 Layouts. Using percentages (or other relative values) to specify page layout in CSS automatically creates adaptive pages. As browser windows widen and narrow, the layout of an element adapts to maintain the same proportions, and so the whole page layout adapts. 지금 우리가 반응형이라 부르는 쪽에 오히려 가깝다.

10년 뒤 Marcotte가 반응형 웹 디자인이라는 이름을 붙일 때, 그는 바로 이 Allsopp의 문장을 자기 글 맨 앞에 인용구로 걸었다. 그리고 본문에서 자기가 제안하는 것을 이렇게 설명한다. 표준 기술을 설계에 넣어서 화면을 더 유연하게 만들고, 그걸 띄우는 기기에도 더 잘 적응하게 만들자. 그게 반응형 웹 디자인이다.Marcotte (2010), 3절. …embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.

이 문장을 다시 읽어보자. 반응형을 만든 그 문서에서 적응은 반응형의 반대말이 아니다. 반응형이 도달하려는 성질이다.

이듬해 Aaron Gustafson이 Adaptive Web Design이라는 책을 낸다. 지금 도는 적응형 대 반응형 구도는 이 제목에서 나왔다고 흔히 이야기되는데, 정작 책의 내용은 그 구도와 무관하다. 이 책이 다루는 건 점진적 향상이다. 되는 것부터 먼저 깔고, 브라우저가 더 할 수 있으면 그때 얹는 방식이다. 저자 본인이 나중에 이 책을 돌아보며 이렇게 쓴다. 이 책은 무엇보다 철학책이고, 반응형 웹 디자인은 아예 다루지 않았으며 모바일도 조금 건드렸을 뿐이다.Gustafson, A. (2015-01-05), “Revisiting (and Releasing) Adaptive Web Design.” at its core, Adaptive Web Design is a philosophy book… I didn’t even address Responsive Web Design and only touched a little on mobile. 책은 2011년 출간, 집필은 2010년이다.

2000년에 Allsopp이 적응을 웹의 원래 성질이라고 말했다. 2010년에 Marcotte가 그 성질에 이르는 방법에 반응형이라는 이름을 붙였다. 2011년에 적응형이라는 제목을 단 책이 나왔지만 그 책은 반응형을 다루지 않았다. 셋 어디에도 대립은 없다. 그 뒤에 업계가 두 제목을 마주 세운 것이다.

적응형이라는 한 낱말이 태도, 배치, 서버 구성 셋을 가리킨다

지금 적응형이라는 말은 서로 층이 다른 세 가지를 한꺼번에 가리킨다. 아래 셋으로 나눈 건 내가 설명하려고 임의로 가른 것이지 표준 분류가 아니다.

하나는 적응하는 태도다. Allsopp과 Gustafson의 적응이 여기다. 기기가 무엇이든, 브라우저가 무엇을 지원하든 쓸 수 있게 만든다는 자세다. 레이아웃 기법만을 가리키는 말이 아니다.

다음은 폭 박기다. 정해둔 폭 몇 개에 각각 다른 배치를 준비해 두는 방식이다. 지금 실무에서 적응형이라고 하면 대개 이걸 가리킨다.

마지막은 기기별로 갈라 보내기다. 서버가 접속한 기기를 보고 아예 다른 HTML을 내려보내는 방식이고, 끝까지 가면 주소를 따로 두는 모바일 사이트가 된다. 이름이 특히 안 맞는 자리이기도 하다. Google의 검색 문서는 이 구성을 동적 게재와 별도 URL이라고 부를 뿐 적응형이라는 이름을 쓰지 않는데, 같은 회사의 web.dev 학습 문서는 폭 박기 쪽을 adaptive design이라고 부른다.Google Search Central, “Mobile-first Indexing Best Practices”(developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)는 세 구성을 Responsive design, Dynamic serving, Separate URLs로 나누고 이 문서 본문에 adaptive는 없다. 반면 web.dev “Learn Responsive Design”(web.dev/learn/design/intro)은 Some people call this an adaptive design이라며 고정 폭 몇 개를 오가는 방식을 그렇게 부른다. 한 회사 안에서도 갈리니, 적응형은 업계에서 그렇게 불러온 이름이지 합의된 용어가 아니다.

태도와 배치 방법과 서버 구성은 애초에 같은 자리에서 다툴 수가 없다. 반응형과 맞붙을 수 있는 건 폭 박기뿐인데, 정작 논쟁에서는 셋이 뒤섞여 나온다. 개발자는 기기별로 갈라 보내는 얘기를 하고 디자이너는 폭 박는 얘기를 들었는데, 옆에서 누가 적응하는 태도 얘기를 꺼내는 식이다.

증거는 내 글에도 남아 있다. 이 블로그의 오래된 글에서 나는 rem을 쓰는 이유를 설명하며 적응형 디자인을 더 쉽게 만들기 위해서라고 적었고, 나중에 상세히 쓰겠다고 미뤄뒀다. 그때 나는 브라우저 기본 글자 크기를 키운 사용자에게 맞추는 얘기와 적응형 디자인을 나란히 적어놓고, 정작 적응형이 무엇인지는 설명하지 않았다. 지금 다시 보면 그때의 적응형은 폭 박기가 아니라 적응하는 태도 쪽이었다. 나도 같은 단어를 다른 층에서 쓰고 있었던 것이다. 그때 나중에 쓰겠다고 미뤄둔 설명을 이 글에서 한다.

폭을 박으면 통제를 얻고 그 사이 구간을 잃는다

앞의 세 층 중 반응형과 실제로 견줄 수 있는 건 폭 박기다. 이제부터 적응형이라고 하면 이걸 가리킨다.

이 방식을 고르면 화면을 내 손으로 정확히 통제할 수 있다. 375px에서 이 화면이 어떻게 생겼는지 시안 그대로 못 박을 수 있다. 카드가 몇 개 보이는지, 제목이 몇 줄에서 끊기는지, 여백이 몇 픽셀인지가 그 폭에서는 정확히 정해진다. 디자이너가 검수할 대상이 명확하고, 개발자가 구현할 목표도 명확하다.

대신 잃는 게 있다. 잡아둔 폭 말고 나머지 폭에서 화면이 어떻게 보이는지를 못 보게 된다. 375, 768, 1440 세 폭을 잡았다면 확인한 것도 딱 세 폭이다. 그 사이의 폭에서 무슨 일이 벌어지는지는 아무도 안 봤고, 세 폭 바깥은 더 그렇다. 실제 방문자의 창 폭은 이 셋 중 하나로 떨어지지 않는다.

비용도 폭 수만큼 붙는다. 화면 하나를 고치면 세 벌을 고쳐야 하고, 새 컴포넌트가 들어오면 세 벌을 그려야 한다. Luke Wroblewski는 2011년에 서버에서 기기별로 갈라 내려보내는 방식의 대가를 이렇게 적었다. 기기 종류마다 자기 템플릿 세트가 필요하고, 그 템플릿들에는 결국 모든 기기에 똑같이 적용되는 코드가 중복으로 들어간다.Wroblewski, L. (2011-09-12), “RESS: Responsive Design + Server Side Components.” 원문: server-side solutions generally rely on user agent redirects to device-specific code templates. Each device class that warrants adaptation needs its own set of templates and these templates may ultimately contain duplicative code that actually applies to every class of device. 층은 다르지만 대가의 모양은 같다. 갈래마다 자기 벌을 갖고, 그 벌들에 결국 같은 내용이 중복으로 들어간다. 서버 템플릿에서 벌어지는 일이 시안과 CSS에서도 그대로 벌어진다. 세 벌 중 두 벌은 사실상 같은 화면인데 폭만 다르다.

성능 때문에 갈라 만들던 이유는 이제 없다

성능 이야기도 짚어야 한다. 적응형을 고르는 가장 큰 이유는 오랫동안 통제가 아니라 성능이었다. 모바일에는 작은 이미지와 가벼운 스크립트만 내려보내면 되니까. 이건 2013년쯤에는 설득력이 있었지만 지금은 아니다. 그 일들을 반응형 안에서 하는 도구가 다 생겼기 때문이다. 이미지는 srcset과 sizes로 브라우저가 화면에 맞는 후보를 고르고, 화면 밖 이미지는 loading="lazy"로 미룬다. 둘 다 주요 브라우저에 다 들어와 있다.srcset은 Chrome 34, Firefox 38, Safari 8, sizes는 Safari 9.1, loading="lazy"는 Safari 15.4(2022-03)부터다. 이미지 쪽 둘 중 지연 로딩이 비교적 늦게 합류했다(MDN browser-compat-data). 스크립트를 필요할 때만 가져오는 코드 분할은 브라우저 기능이 아니라 번들러가 하는 일이라, 애초에 브라우저를 가리지 않는다.

여기에 더 큰 변화가 하나 있다. 서버가 기기를 알아낼 방법 자체가 사라지는 중이다. Chrome은 2022년부터 사용자 에이전트 문자열을 동결하고 정보를 줄였다. 대체재로 나온 User-Agent Client Hints는 Chromium 계열에만 있고 다른 엔진은 구현하지 않았다.Chromium 프로젝트의 User-Agent Reduction 문서(chromium.org/updates/ua-reduction)는 2022년 5~6월에 Chrome 101로 롤아웃을 시작했다고 기록한다. Sec-CH-UA는 MDN 호환성 데이터 기준 Chrome 89부터이고 Firefox와 Safari는 미구현이며, WebKit의 standards-positions는 User-Agent Client Hints를 blocked로 적어뒀다. 그러니 2026년 지금은 어느 브라우저에서나 믿고 쓸 만한 서버 쪽 기기 감지가 없다고 보는 편이 안전하다.

갈라 만들지는 화면 크기가 아니라 사용자가 하려는 일이 정한다

그럼 갈라 만드는 게 항상 틀렸느냐 하면 그건 아니다. 판단 기준은 반응형을 만든 사람이 이미 적어뒀다.

Marcotte는 그 글 마지막 절에서 단서를 하나 단다. 기기별로 사이트를 나누는 게 사업적으로 맞는 경우도 있다는 것이다. 그러면서 조건을 하나로 좁힌다. 모바일에서 사용자가 하려는 일의 범위가 데스크톱보다 좁다면, 각각에 다른 콘텐츠를 내주는 게 나을 수 있다. 그리고 바로 못을 박는다. 다만 그런 사고방식이 기본값일 필요는 없다.Marcotte (2010), 7절. 원문: That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach. (원문에서는 여기서 문단이 갈린다) But that kind of design thinking doesn’t need to be our default.

기준이 화면 크기가 아니라는 데 주목하자. 사용자가 하려는 일의 범위다. 이걸 실무 질문 하나로 바꾸면 이렇게 된다.

좁은 화면에서 하려는 일이 넓은 화면에서 하려는 일 중 일부인가, 아니면 아예 다른 일인가. 쇼핑몰이라면 모바일에서도 결국 상품을 보고 사는 일이니 일부에 해당한다.

일부라면 화면 하나로 간다. 배치만 접히면 되는 문제이고, 이건 반응형이 푸는 문제다. 아예 다른 일이면 그건 반응형과 적응형의 문제가 아니라 제품 결정이다. 두 개의 다른 화면을 만들기로 정한 것이고, 그 결정은 레이아웃 회의가 아니라 기획 단계에서 내려야 한다.

여기서 원칙 하나가 따라 나온다. 기기로 가르지 말고 상황으로 갈라라.

기기를 보면 사용자가 어떤 상황인지 짐작할 수 있을 것 같지만, 그 짐작은 자주 틀린다. 모바일에서 할 일이 좁아지는 진짜 이유는 화면이 작아서가 아니라 이동 중이고, 급하고, 한 손이고, 회선이 불안정해서다. 그런데 그 조건들은 기기와 깔끔하게 안 맞는다. 데스크톱 앞에서 급하게 처리하는 사람도 있고, 태블릿으로 하루 종일 진득하게 일하는 사람도 있다. 기기만 보고 기능을 빼면, 데스크톱에서 급하게 처리하는 사람도 태블릿으로 오래 일하는 사람도 필요한 기능을 못 쓰게 된다.

그래도 갈라 만들어야 하는 자리는 아직 있다. HTML 이메일, 하려는 일 자체가 다른 제품, 그리고 브라우저에 닿기 전 단계다.

먼저 HTML 이메일이다. 윈도우용 클래식 Outlook은 워드의 렌더링 엔진을 쓴다.Microsoft 문서 “Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007”: Microsoft Office Outlook 2007 uses the HTML parsing and rendering engine from Microsoft Office Word 2007 to display HTML message bodies. 미디어 쿼리 미지원은 caniemail의 css-at-media 항목에서 outlook.windows 2007~2019가 모두 미지원으로 기록돼 있다. 그래서 미디어 쿼리를 아예 못 읽는다. 그래서 이메일 업계가 쓰는 해법이 사실상 적응형에 해당한다. Outlook 전용 조건부 주석 안에 고정폭 표를 하나 깔고, 나머지 클라이언트에는 유동 레이아웃을 보낸다. 컨테이너 쿼리는 아예 못 쓴다. 미디어 쿼리도 안 읽는 엔진이 그걸 읽을 리 없다.

다음은 방금 말한 대로 하려는 일 자체가 다를 때다. 매장 직원용 재고 조회와 본사용 재고 분석은 같은 화면의 좁은 판과 넓은 판이 아니라 서로 다른 제품이다.

마지막은 브라우저에 닿기 전 단계다. 앞에서 srcset이 성능 문제를 반응형 안에서 푼다고 했는데, 브라우저가 고르는 그 후보 목록을 만드는 일은 여전히 서버가 한다. 번들을 어디서 자를지, 이미지를 어떤 크기들로 구울지는 여전히 서버와 엣지의 몫이다. 이 층에서 하는 최적화는 반응형과 대립하지 않는다. 오히려 반응형이 잘 돌아가게 받쳐준다.

적응형으로 일하면 시안 세 장, 반응형으로 일하면 세 장에 규칙표

여기까지가 개념이고, 디자이너가 이 논쟁을 실제로 만나는 자리는 따로 있다. 시안을 몇 장 그리느냐, 그리고 핸드오프 문서에 무엇을 적느냐다.

적응형 사고로 일하면 화면 세 장을 그려 넘긴다. 375, 768, 1440. 각 장은 완결돼 있고, 개발자는 그 세 장을 목표로 삼는다.

반응형 사고로 일하면 세 장에 더해 그 사이를 채우는 규칙을 같이 넘긴다. 세 장은 여전히 필요하다. 사람은 그림 없이 레이아웃을 논의하지 못한다. 다만 그 세 장은 목표가 아니라 표본이고, 진짜 명세는 그 사이를 채우는 규칙이다. 각 요소가 최소 몇 픽셀까지 견디고 최대 몇 픽셀까지 커지는지, 폭이 남을 때 무엇이 늘어나고 무엇이 그대로인지, 자리가 모자랄 때 무엇부터 접히는지를 적어준다. 최소 폭과 최대 폭과 접히는 순서를 적어주지 않으면 개발자는 표본 사이를 자기 감으로 메운다.

그래서 개발자가 이렇게 물어올 때,

개발자: “이건 적응형으로 갈까요?”

되물을 질문은 브레이크포인트를 몇 개 잡을지가 아니다.

디자이너: “모바일에서 하려는 일이 데스크톱에서 하려는 일의 부분집합인가요? 그리고 이 카드가 견뎌야 하는 최소 폭은 몇 픽셀인가요?”

앞 질문이 갈라 만들지 말지를 정하고, 뒤 질문이 규칙표의 첫 줄을 채운다. 둘 다 폭 목록보다 먼저 나와야 하는 질문이다.

이제 물을 건 무엇에 반응하게 만들었나, 그 기준을 누가 골랐나

한 바퀴 돌아 처음으로 돌아가자. 2000년에 Allsopp이 적응이라는 말로 가리킨 건 화면 크기만이 아니었다. 무엇으로 보든, 어떤 환경에 있든 쓸 수 있게 만들라는 얘기였다.

나는 그 뜻이 지금 다시 쓸모가 생겼다고 본다. 이건 Allsopp이나 Gustafson이 한 말이 아니라 내 해석이다. 요즘 우리가 화면 폭 말고 읽는 신호들을 보면 그렇다. 어두운 화면을 선호하는지, 움직임을 줄이고 싶은지, 대비를 높이고 싶은지, 마우스를 쓰는지 손가락을 쓰는지. 이 신호들은 화면이 몇 픽셀인지와 아무 상관이 없다. 대신 사용자가 지금 어떤 상태인지를 묻는다. 2000년의 적응성이 묻던 바로 그 질문이다.

그래서 지금 쓸모 있는 질문은 적응형이냐 반응형이냐가 아니라고 본다. 이 컴포넌트는 무엇에 반응하게 만들었나, 그 기준은 누가 골랐나다.

기법은 앞 글에서 코드로 다뤘다. 이 글은 그 앞에 놓이는 질문을 맡았다.

3분 실습: 지금 화면의 지점들을 누가 정했는지 적어보자

지금 만들고 있는 화면을 열고 창을 1600px에서 320px까지 천천히 줄이면서 세 가지를 적어보자. 본문 폭이 멈추는 지점, 열 수가 바뀌는 지점, 글자 크기가 바뀌는 지점. 그리고 각 지점마다 이걸 누가 정했는지 묻는다. 내가 골라 박은 숫자인지, 콘텐츠의 최소치를 알려주고 브라우저가 계산한 것인지. 이렇게 적어둔 지점과 그 출처가 그 화면이 실제로 무엇에 반응하는지를 적은 명세다. 적응형과 반응형이라는 두 말이 실무에서 뜻하는 것도 딱 여기까지다.