머릿속으로 px-rem 계산을 멈추세요 (당신의 몰입을 방해하는 이유)

컴포넌트 하나를 만드는 데 40분이 지났습니다. Figma에는 font-size: 24px라고 적혀 있습니다. 계산기를 켜서 24 / 16을 입력하고, 1.5라는 결과값을 얻습니다. 다시 VS Code로 돌아가 1.5rem을 입력하고 계산기를 닫습니다.

3분 뒤, 36px가 필요해졌습니다. 다시 계산기를 켭니다. 36 / 16... 이게 2.25였나? 다시 확인해 봐야겠어...

익숙한 상황인가요? 저도 셀 수 없이 많이 겪어본 일입니다. 솔직히 말해서, 이건 한 세션 동안 20번 정도 반복했다는 사실을 깨닫기 전까지는 별일 아닌 것처럼 느껴지는 아주 작은 마찰(friction) 중 하나입니다.

왜 우리는 여전히 이 작업을 수동으로 하는가

공식은 아주 단순합니다:

rem = px ÷ base font size (기본 글꼴 크기)
px  = rem × base font size (기본 글꼴 크기)

16px 기본값(브라우저 기본값)을 기준으로 하면:

24px ÷ 16 = 1.5rem   ✓
36px ÷ 16 = 2.25rem  ✓
14px ÷ 16 = 0.875rem ✓

네, 수학 자체가 어렵지는 않습니다. 문제는 **문맥 전환 (context switching)**입니다. 무언가를 계산하기 위해 에디터를 떠날 때마다, 당신은 정신적 오버헤드(mental overhead) 비용을 지불하고 있습니다. 세션당 15~20번씩 이를 반복하면, 딥 워크 (deep work) 시간의 상당 부분을 잃게 됩니다.

당신에게 실제로 필요한 빠른 참조표

표준 16px 기준, 제가 끊임없이 찾아보는 값들입니다:

px	rem
10px	0.625rem
...	...

이 섹션을 북마크해 두세요. 진심입니다.

잠깐 — 왜 굳이 rem을 사용하는가?

CSS가 처음이라면, 애초에 왜 번거롭게 rem을 사용하는지 궁금할 수 있습니다. 픽셀(px)도 잘 작동하잖아요, 그렇죠?

핵심은 이것입니다: px는 절대 단위 (absolute unit)입니다. font-size: 16px라고 작성하면, 사용자가 브라우저 설정에서 무엇을 선택했든 관계없이 항상 16픽셀로 나타납니다.

rem은 루트 <html> 요소의 글꼴 크기에 상대적입니다. 브라우저의 기본값은 16px이지만, 사용자는 이를 변경할 수 있습니다. 이 작은 차이가 접근성 (accessibility) 측면에서는 매우 중요합니다.

/* 사용자가 브라우저 글꼴을 

WCAG 2.2 기준 1.4.4 (텍스트 크기 조절, Resize Text)는 사용자가 레이아웃을 깨뜨리거나 콘텐츠를 잃지 않고 텍스트를 최대 200%까지 조절할 수 있어야 한다고 규정합니다. `rem`은 이를 자동으로 처리하지만, `px`는 그렇지 못합니다.

접근성(accessibility)을 넘어, `rem`은 간격 시스템(spacing system)을 예측 가능하게 만듭니다. 루트 글꼴 크기(root font size)를 한 번만 변경하면 모든 요소가 비례하여 조정됩니다.

## `html { font-size: 62.5% }` 트릭 (그리고 이것이 구식인 이유)

아마 오래된 코드베이스에서 다음과 같은 패턴을 본 적이 있을 것입니다:

html {
font-size: 62.5%; /* 1rem = 10px로 만듦 */
}
...


매력적인 점은 딱 떨어지는 숫자라는 것입니다. `36px = 3.6rem`은 `2.25rem`보다 더 깔끔하게 느껴집니다.

문제는 `html`에 `font-size: 62.5%`를 설정하면, 다른 어떤 요소가 반응하기도 전에 사용자의 브라우저 설정(browser preference)을 덮어써 버린다는 점입니다. 이는 본질적으로 루트 레벨에서 접근성을 포기하는 행위입니다.

현대적인 베스트 프랙티스(best practice)는 `html` 글꼴 크기를 그대로 두거나(`100%` 사용) `1rem = 사용자의 설정값`이 되도록 두는 것입니다. 그 다음, 베이스 사이즈를 해킹하는 대신 변환 도구를 사용하여 계산을 수행하세요.

## 프로젝트에서 표준이 아닌 베이스를 다루는 법

모든 프로젝트가 `16px`를 사용하는 것은 아닙니다. 다음과 같은 코드베이스를 물려받을 수도 있습니다:

html { font-size: 10px; }
/* 또는 */
html { font-size: 18px; }


이런 경우 표준 변환표는 틀리게 됩니다. 베이스가 `10px`라면 `24px`는 `1.5rem`이 아니라 `2.4rem`입니다.

이것이 제가 기억력이나 하드코딩된 표에 의존하는 대신, 설정 가능한 베이스를 가진 제대로 된 px → rem 변환기를 항상 사용하는 이유 중 하나입니다. 커스텀 루트 글꼴 크기를 사용하는 프로젝트에서 작업할 때, 저는 베이스 필드만 업데이트하면 모든 값이 올바르게 재계산됩니다.

→ [**무료 PX to REM 변환기 — 양방향, 커스텀 베이스, 일괄 변환**](https://www.webtoolshub.online/tools/px-to-rem-converter)

## 실제 나의 워크플로우: 전체 타이포그래피 스케일(Type Scale) 변환하기

새로운 디자인 시스템(design system)을 시작하거나 타이포그래피 토큰(typography tokens)을 설정할 때, 저는 값을 하나씩 계산하는 대신 일괄 변환기(bulk converter)를 사용합니다.

디자이너가 Figma에서 다음과 같은 타이포그래피 스케일(모두 픽셀 단위)을 제공했다고 가정해 봅시다:

12 / 14 / 16 / 18 / 20 / 24 / 30 / 36 / 48 / 60 / 72


11개의 값을 모두 일괄 변환기 (bulk converter)에 넣고 "Copy All"을 누르면 다음과 같이 얻을 수 있습니다:

12px = 0.75rem
14px = 0.875rem
16px = 1rem
...


이를 CSS 사용자 정의 속성 (custom properties) 또는 Tailwind 설정 (config)에 직접 붙여넣으세요. 5분 대신 30초 만에 끝납니다.

```css
:root {
  --text-xs:   0.75rem;   /* 12px */
  --text-sm:   0.875rem;  /* 14px */
...

미디어 쿼리 (Media Queries)에서의 rem (아무도 말하지 않는 부분)

사람들이 자주 실수하는 부분이 있습니다. 미디어 쿼리 (media queries) 또한 rem을 허용하며, 실제로 이것이 더 나은 선택입니다.

/* 작동은 하지만, 사용자의 글꼴 설정에 따라 크기가 조절되지 않음 */
@media (min-width: 768px) { ... }

...

px 중단점 (breakpoints)을 사용할 경우: 사용자가 글꼴 크기를 20px로 키우더라도, 사용자의 설정과 관계없이 레이아웃은 여전히 기기 픽셀(device pixels) 기준인 768px에서 깨지게 됩니다.

rem 중단점을 사용할 경우: 중단점 자체가 확장됩니다. 루트(root)가 20px일 때, 48rem = 960px가 되어 레이아웃이 적응합니다. 사용자의 설정이 반응형 디자인 (responsive design) 전체에 전달되는 것입니다.

표준 중단점에 대한 빠른 변환 값은 다음과 같습니다:

480px  = 30rem
640px  = 40rem
768px  = 48rem
...

Tailwind 사용자: 임의 값 (Arbitrary Values) + rem

Tailwind의 사전 설정 스케일 (preset scale)은 이미 내부적으로 rem을 사용하고 있습니다. 예를 들어 text-base는 1rem, text-xl은 1.25rem 등입니다. 하지만 디자인 명세서(design spec)에서 사전 설정 스케일을 벗어나는 값을 요구할 때는 임의 값 (arbitrary values)이 필요합니다:

<h1 class="text-[2.25rem] leading-[2.75rem]">Heading</h1>
<div class="mt-[1.875rem] px-[1.5rem]">Content</div>

제가 언급한 변환기는 표준 CSS와 함께 Tailwind 임의 값 문자열을 자동으로 생성해주므로, 수동으로 형식을 맞출 필요가 없습니다.

Tailwind v4를 사용 중이고 커스텀 @theme 블록을 구축하고 있다면, 해당 토큰들도 rem 값으로 들어갑니다:

@theme {
  --font-size-display: 3rem;      /* 48px */
  --font-size-heading: 2.25rem;   /* 36px */
...

PostCSS 자동화 (대규모 코드베이스용)

수천 개의 px 선언이 포함된 레거시 코드베이스 (legacy codebase)를 마이그레이션하고 있다면, 이를 수동으로 작업하는 것은 현실적이지 않습니다. 빌드 타임 (build time)에 px를 rem으로 변환해 주는 PostCSS 플러그인인 postcss-pxtorem이 있습니다.

npm install postcss-pxtorem --save-dev

// postcss.config.js
module.exports = {
  plugins: {
...

개발 시에는 font-size: 24px라고 작성하면, 프로덕션 (production) 환경에서는 font-size: 1.5rem으로 출력됩니다. 이 도구가 사용하는 공식은 동일하며, 단지 자동화되었을 뿐입니다.

propList 설정 시 주의하세요. _모든 것_을 무작정 rem으로 변환해서는 안 됩니다. 테두리 (borders), 아이콘 크기, 그리고 절대 크기가 변해서는 안 되는 요소들은 보통 px로 유지되어야 합니다.

요약 (TL;DR)

폰트 크기와 간격(spacing)에는 rem을 사용하세요. 이는 사용자의 브라우저 설정을 존중하며 WCAG(웹 콘텐츠 접근성 지침)를 준수합니다.
테두리 (borders), 그림자 (shadows), 그리고 실제로 크기가 조절되면 안 되는 요소에는 px를 사용하세요.
rem = px ÷ 기본 폰트 크기 (기본값 = 16px)
새로운 프로젝트에서 62.5% html 트릭을 사용하지 마세요. 이는 접근성 측면에서 안티 패턴 (anti-pattern)입니다.
rem은 미디어 쿼리 (media queries)에서도 작동하며, 접근성에 더 좋습니다.
대량 변환이나 표준이 아닌 기본값을 사용하는 경우, 적절한 도구를 사용하세요.

→ WebToolsHub — PX to REM Converter (무료, 양방향, 대량 변환)

디자인 토큰 (design tokens)을 위해 CSS 사용자 정의 속성 (CSS custom properties)을 사용한다면, 저희의 CSS Variables & Dark Mode 가이드에서 Next.js에 전체 토큰 시스템을 연결하는 방법을 다룹니다. 만약 픽셀 중심의 코드베이스에서 Tailwind로 마이그레이션 중이라면, CSS to Tailwind converter가 클래스 매핑 (class-mapping) 레이어를 처리해 줍니다.

태그: css webdev frontend beginners