E-3: Tailwind 변형 — 유틸리티 앞에 조건을 붙인다

안녕하세요, 홍순구입니다. 지난 시간에 우리 색 아홉 개에 이름을 주고 피드와 댓글과 폼을 그 이름으로 전부 다시 그렸는데, 딱 두 군데는 아직 마무리를 못 지어서 globals.css를 열면 손으로 쓴 규칙이 딱 두 줄 남아 있어요.

/* apps/web-spa/src/styles/globals.css */
.comment-submit:disabled {
  color: #b2dffc;
  cursor: default;
}

.comment-remove:hover {
  color: #262626;
}

이 둘만 못 옮긴 이유가 있었는데, 유틸리티는 "이 요소는 파란 글자다"라고 말할 수는 있어도 "잠겼을 때만 흐린 파랑이다" 라고는 말할 방법이 없었거든요. 조건을 붙일 문법을 아직 안 배웠으니까요.

오늘 그 문법을 배우는데, 조건은 상태만이 아니라 화면 크기도 조건이 됩니다.

 오늘의 여정

 Step 1     "잠겼을 때만" 을 어떻게 말할까
    │
 Step 2     마우스를 올렸을 때, 그리고 마우스가 없는 기기
    │
 Step 3     키보드로 쓰는 사람에게만 보이는 것
    │
 Step 4     화면 크기도 조건이 된다
    │
 Step 5     피드를 두 열로
    ▼
 피드와 댓글에서 손 이름이 사라지고, 화면 크기에 따라 배치가 달라진다

💡 오늘 수업의 핵심 — "유틸리티 앞에 조건을 붙이면, 그 조건일 때만 걸리는 규칙이 생긴다"

text-brand는 항상 걸리지만 disabled:text-brand는 잠겼을 때만 걸려요. 유틸리티 이름 앞에 조건:을 붙이면 Tailwind가 그 조건이 담긴 CSS 규칙을 대신 만들어 줍니다.

🎯 학습 목표

• 상태 변형(disabled:·hover:·focus-visible:)으로 의사클래스 규칙을 유틸리티로 옮길 수 있다
• 변형이 만드는 CSS 규칙의 모양을 빌드된 파일에서 찾아, 왜 그 규칙이 이기고 지는지 설명할 수 있다
• 반응형 변형이 왜 "그 크기 이상"을 뜻하는지 알고, 좁은 화면을 기준으로 먼저 쓸 수 있다
• 자바스크립트 없이 화면 크기에 따라 배치를 바꿀 수 있다

Step 1: "잠겼을 때만"을 어떻게 말할까

남은 두 줄 중 첫 줄부터 봅시다. 댓글 입력칸이 비어 있으면 게시 버튼이 잠기는데, 그때 글자색이 흐려집니다.

지금은 이렇게 되어 있습니다

버튼은 손으로 지은 이름을 아직 달고 있어요.

// apps/web-spa/src/components/CommentForm.tsx
<Button
  className="comment-submit cursor-pointer text-sm font-semibold text-brand"
  type="submit"
  disabled={isEmpty}
>
  게시
</Button>

comment-submit이 유틸리티 사이에 끼어 있죠. 지난 시간에 다른 이름은 전부 걷어냈는데 이것만 남겼습니다. .comment-submit:disabled 규칙이 붙을 데가 필요했거든요.

유틸리티 앞에 조건을 붙입니다

문법은 아주 짧은데, 콜론 하나예요.

disabled:cursor-default
└──┬───┘ └─────┬──────┘
  조건       유틸리티

"잠겼을 때 커서를 기본값으로"라는 뜻입니다. cursor-default는 원래 있던 유틸리티고, 앞에 disabled:를 붙인 것뿐이에요.

색도 같은 방식으로 갑니다. 그런데 여기서 잠깐 멈춰야 해요.

#b2dffc를 무엇으로 옮길까

손 규칙에 적힌 색은 #b2dffc이지만 우리 토큰 아홉 개 중에는 이런 색이 없어요.

이 색이 어디서 왔는지 생각해 봅시다. 잠긴 버튼은 원래 파랑(#0095f6)을 흐리게 만든 것이니까, 누군가 파랑을 흰 배경 위에 얇게 얹은 결과를 눈으로 골라 hex로 적어둔 거고, 우리도 흐리게 만들면 됩니다. Tailwind는 색 유틸리티 뒤에 슬래시로 진하기를 적을 수 있어요.

text-brand/30
         └┬┘
        30% 만 얹는다

정말 같은 색이 되는지 재봤습니다. 흰 배경 위에 칠하고 화면에 찍힌 픽셀을 읽어봤어요.

⚠️ 빨강이 1 다릅니다. 눈으로는 절대 구분 못 하지만, "완전히 같다" 고 말하면 거짓입니다. 파랑을 30% 얹으면 빨강 값이 178.5가 나오는데 브라우저가 올림하기 때문이에요.

1 픽셀보다 중요한 차이

진짜 차이는 다른 데 있는데, 두 색을 어두운 배경 위에 얹어 보면 이렇게 갈려요.

#b2dffc는 흰 배경을 전제로 고른 값이라 배경이 어두워져도 그대로 밝게 뜨지만, 알파로 적으면 뒤에 무엇이 오든 그것에 섞여요.

지금은 배경이 항상 흰색이라 둘 다 맞아 보입니다. 언제 갈리는지는 다음 시간에 확인합니다.

옮기고 손 규칙을 지웁니다

// apps/web-spa/src/components/CommentForm.tsx
<Button
  className="cursor-pointer text-sm font-semibold text-brand disabled:cursor-default disabled:text-brand/30"
  type="submit"
  disabled={isEmpty}
>
  게시
</Button>

comment-submit이 사라졌습니다. 이제 globals.css에서 .comment-submit:disabled 블록을 지워도 됩니다.

무엇이 만들어졌나

빌드된 CSS를 열어 보면 이렇게 들어가 있어요.

.disabled\:cursor-default:disabled { cursor: default }

클래스 이름 안에 콜론이 그대로 들어가고(백슬래시는 CSS가 콜론을 글자로 읽게 하는 표시입니다), 뒤에 :disabled가 붙었습니다. 우리가 손으로 쓰던 것과 똑같이 생겼는데, 다만 우리가 이름을 짓지 않았을 뿐이에요.

잠기면 정말 커서가 바뀌나

여기서 한 가지 걸리는 게 있는데, 버튼에는 cursor-pointer도 붙어 있어요. 잠기면 disabled:cursor-default가 붙지만, cursor-pointer도 여전히 붙어 있습니다. 둘 중 뭐가 이길까요.

실제로 재보니 잠긴 상태에서 커서는 default였는데, 변형 쪽이 이겼어요.

이유는 두 규칙의 무게가 다르기 때문입니다. 나란히 놓고 보면 분명해요.

 .cursor-pointer                          클래스 하나
 .disabled\:cursor-default:disabled       클래스 하나 + 조건 하나

CSS는 조건을 하나 더 단 쪽을 더 구체적인 규칙으로 보는데, 더 구체적인 쪽이 이겨요. 파일 안에서 누가 먼저 나오는지는 상관이 없습니다.

일부러 순서를 뒤집어 확인해 볼 수도 있는데, 조건이 붙은 규칙을 먼저 쓰고 조건 없는 규칙을 나중에 써도 여전히 조건이 붙은 쪽이 이깁니다.

⚠️ 이 이야기는 상태 변형에만 해당합니다. 화면 크기 조건은 무게를 더하지 않아서 사정이 다른데, 그건 Step 4에서 봅니다.

지난 시간에도 비슷한 걸 봤죠. 그때는 손으로 쓴 .comment-submit:disabled가 text-brand 유틸리티를 이겼는데, 이긴 이유는 또 달라요. 그때는 손 CSS가 유틸리티 묶음 바깥에 있어서였어요. 묶음 밖에 있는 스타일은 무게를 따지기도 전에 이깁니다.

💡 한 줄 정리

유틸리티 앞에 disabled:를 붙이면 Tailwind가 :disabled가 달린 규칙을 대신 만들어 줍니다. 조건이 하나 더 달린 만큼 규칙이 더 구체적이라, 같은 속성을 다투면 순서와 관계없이 변형 쪽이 이깁니다.

Step 2: 마우스를 올렸을 때, 그리고 마우스가 없는 기기

남은 한 줄을 마저 옮깁시다. 댓글 옆 × 버튼에 마우스를 올리면 글자가 진해지는 규칙이에요.

이번엔 색이 정확히 맞습니다

.comment-remove:hover {
  color: #262626;
}

#262626은 지난 시간에 --color-ink라는 이름을 준 바로 그 값이라서, 옮기기가 간단해요.

// apps/web-spa/src/components/CommentList.tsx
<IconButton
  className="cursor-pointer px-1 text-sm leading-none text-muted hover:text-ink"
  aria-label="댓글 삭제"
  onClick={() => onRemove(comment.id)}
>
  ×
</IconButton>

실제로 마우스를 올려서 재봤습니다.

Step 1과 달리 여기는 어긋남이 없는데, 토큰이 그 값을 정확히 옮겨둔 덕분이에요.

피드와 댓글에서 손 이름이 사라졌습니다

comment-remove도 className에서 사라져서 이제 globals.css에서 두 번째 블록도 지웁니다.

지난 시간 끝과 견줘 보면 이렇습니다.

지지난 시간을 떠올려 보세요. Avatar 하나를 옮기면서 시작했죠. 게시물 카드와 댓글 구역에서는 그 일이 여기서 닫힙니다.

⚠️ 다만 20개가 남았다는 걸 흘려보내지 마세요. 대부분은 화면에 안 나오는 교습용 데모지만, 네 개는 지금 화면에 있습니다. 회원가입 폼 맨 위 "프로필 사진 고르기" 버튼이 아직 손 클래스를 달고 있는데, 지난 시간 과제로 넘긴 것이라 오늘도 그대로 둡니다. 이 버튼은 Step 3에서 다시 만납니다.

⚠️ 그런데 hover:는 그냥 :hover가 아닙니다

빌드된 CSS에서 방금 만든 규칙을 찾아보면 예상과 다르게 생겼습니다.

@media (hover:hover) {
  .hover\:text-ink:hover { color: var(--color-ink) }
}

:hover만 붙은 게 아니라 미디어 쿼리로 한 겹 감싸져 있어요. Step 1의 disabled:에는 이런 게 없었습니다.

(hover: hover)는 "이 기기에 마우스처럼 올려둘 수 있는 입력 장치가 있는가"를 묻는 조건입니다. 데스크톱은 참이고, 손가락만 쓰는 기기는 거짓이에요.

왜 감쌌을까

터치 화면에서 손가락으로 버튼을 누르면 브라우저가 :hover를 잠깐 켰다가 손을 떼도 그대로 남겨두는 일이 있는데, 다른 데를 눌러야 풀려요. 눌렀던 버튼이 계속 진하게 남아 있는 화면, 한 번쯤 보셨을 겁니다.

Tailwind는 hover:를 아예 마우스가 있는 기기에서만 걸리게 해서 이 문제를 피합니다.

조건이 어긋난 미디어 규칙이 정말 죽는지 직접 확인해 볼 수 있어요. 개발자 도구 콘솔에서 규칙 두 개를 심어 보면 됩니다.

#probe { color: rgb(1, 2, 3) }
@media (hover: hover) { #probe { color: rgb(11, 22, 33) } }
@media (hover: none)  { #probe { color: rgb(99, 88, 77) } }

마우스가 있는 컴퓨터에서 재보면 rgb(11, 22, 33)이 나옵니다. (hover: none) 쪽은 조건이 어긋나서 아예 안 걸리고, 기본값 rgb(1, 2, 3)이 그대로 남아요.

여기서 중요한 결론이 하나 나옵니다. 마우스를 올려야만 알 수 있는 정보는 터치 기기에서 영영 안 보입니다. 색이 조금 진해지는 정도는 괜찮지만, "여기를 누를 수 있어요"를 hover로만 알려주면 휴대폰 사용자는 그걸 알 방법이 없습니다.

💡 한 줄 정리

hover:는 :hover 규칙을 만들면서 @media (hover: hover)로 감쌉니다. 마우스가 없는 기기에서는 통째로 걸리지 않으니, hover로만 전달되는 정보를 만들면 안 됩니다.

Step 3: 키보드로 쓰는 사람에게만 보이는 것

상태 변형을 하나 더 봅시다. 이번엔 우리가 아직 안 쓰고 있던 것이에요.

먼저 지금 상태를 확인합시다

키보드 Tab 키를 눌러 화면 요소 사이를 옮겨 다녀 보세요. 지금 어디에 있는지 파란 테두리로 표시됩니다.

이건 우리가 만든 게 아닙니다. 브라우저가 원래 그려주는 거예요. 재보면 이렇게 나옵니다.

outline: rgb(0, 95, 204) auto

⚠️ 한 가지 짚고 갑시다. Tailwind의 기본 정리(Preflight)는 버튼의 테두리와 배경을 지우지만 이 테두리는 건드리지 않습니다. Preflight가 버튼의 배경과 테두리를 지웠던 것과는 다른 이야기예요. 우리가 뺏은 게 아니라 원래 있는 겁니다.

그런데 많은 사람이 이걸 지웁니다

파란 테두리가 디자인과 안 어울린다는 말이 나오면, 개발자가 흔히 이렇게 씁니다.

button { outline: none }

이 한 줄로 마우스 쓰는 사람의 불만은 사라지지만, 키보드만 쓰는 사람은 자기가 어디 있는지 영영 알 수 없게 됩니다. 화면을 못 보는 분만 키보드를 쓰는 게 아니에요. 손을 다쳐서, 마우스가 고장 나서, 그냥 빠르니까 쓰는 사람도 많습니다.

focus:는 왜 답이 아닐까

"그럼 지우지 말고 우리 색으로 바꾸면 되겠네요"가 자연스러운 다음 생각이지만, 조건을 focus:로 쓰면 문제가 그대로 남아요.

같은 버튼에 조건만 바꿔가며 세 번 재봤습니다.

focus:는 마우스로 눌러도 테두리를 띄웁니다. 버튼을 누를 때마다 테두리가 남으니 결국 또 지우고 싶어져요. 이게 outline: none이 그렇게 흔한 이유입니다.

focus-visible:은 브라우저가 조작 방식을 보고 갈라줍니다. 마우스로 눌렀으면 안 띄우고, 키보드로 왔으면 띄웁니다.

⚠️ 다만 "키보드일 때만"이라고 외우면 틀립니다

댓글 입력칸을 마우스로 클릭하고 재보면 테두리가 뜹니다. 버튼과 반대예요.

이유를 생각해 보면 당연합니다. 글자를 입력받는 칸은 커서를 어디에 뒀는지 보여야 하니까요. 마우스로 눌렀다고 표시를 감추면 어디에 타이핑되는지 알 수 없습니다.

그래서 focus-visible:의 뜻은 "키보드일 때"가 아니라 "이 사용자에게 지금 표시가 필요한가를 브라우저가 판단했을 때"입니다.

우리 색으로 바꿔 답니다

세 개를 함께 씁니다. 두께, 요소에서 띄울 간격, 색이에요.

// apps/web-spa/src/components/CommentInput.tsx
<input
  className="flex-1 text-sm focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand"
  ref={ref}
  value={value}
  onChange={onChange}
  placeholder="댓글 달기..."
  aria-label="댓글 입력"
/>

같은 문자열을 여덟 곳에 똑같이 붙였습니다.

재보면 테두리가 2px 굵기에 2px 간격, 색은 브랜드 파랑(0, 149, 246)으로 정확히 나옵니다.

⚠️ 한 곳을 빠뜨리면 어떻게 되는지 지금 볼 수 있습니다

여덟 곳이라고 했는데, 이 화면에서 Tab은 아홉 번 멈춥니다. Step 2에서 말한 그 버튼이 빠졌어요.

페이지 맨 위에서 Tab을 한 번 눌러 보세요. 제일 먼저 걸리는 "프로필 사진 고르기" 버튼만 브라우저 기본 파란 테두리로 뜹니다. 나머지 여덟 곳은 우리 브랜드 색이고요.

표시가 사라진 게 아니라 혼자 다른 모양인 겁니다. 지난 시간 과제로 남겨둔 컴포넌트라 오늘 손대지 않지만, 한 곳을 빠뜨리면 화면이 어떻게 되는지 직접 보여주는 셈이 됐어요.

⚠️ 한 곳은 아슬아슬합니다

가입하기 버튼만 사정이 다릅니다. 배경이 브랜드 파랑인데 테두리도 브랜드 파랑이라 둘이 같은 색이거든요.

그래도 화면에서 보이기는 합니다. outline-offset-2가 버튼과 테두리 사이에 2px 흰 틈을 만들어 주거든요. 테두리는 그 틈 바깥에 그려지니 양옆이 모두 흰색이고, 그래서 눈에는 들어옵니다.

문제는 틈 하나에 통째로 기대고 있다는 겁니다. 간격을 0으로 되돌리면 테두리가 버튼과 붙어 같은 색끼리 만나고, 그 순간 사라져요. 이 버튼을 다른 배경 위로 옮겨도 마찬가지입니다.

색을 잘 골랐으면 틈이 있든 없든 보입니다. 이건 과제로 남겨둘게요.

💡 한 줄 정리

브라우저는 원래 포커스 테두리를 그려줍니다. 그걸 지우지 말고 focus-visible:로 바꿔 다세요. focus:로 쓰면 마우스 클릭에도 떠서 결국 지우고 싶어집니다.

Step 4: 화면 크기도 조건이 된다

여기까지가 상태였습니다. 이제 조건의 다른 종류를 봅시다.

미뤄뒀던 숙제

지지난 시간 과제에서 이런 실험을 하셨죠. 아무 컴포넌트에 const container = 1;이라고 변수를 하나 만들고 빌드했더니, 쓰지도 않은 .container 클래스가 CSS에 생겼습니다.

그때 개수가 이상했어요. .p-4는 하나 나왔는데 .container는 여섯 개 였습니다. 왜 여섯인지 오늘 답이 나옵니다. 빌드된 CSS에서 전부 뽑아 보면 이렇습니다.

.container { width: 100% }
@media (width>=40rem) { .container { max-width: 40rem } }
@media (width>=48rem) { .container { max-width: 48rem } }
@media (width>=64rem) { .container { max-width: 64rem } }
@media (width>=80rem) { .container { max-width: 80rem } }
@media (width>=96rem) { .container { max-width: 96rem } }

기본 규칙 하나에 화면 크기별 규칙 다섯 개. 합쳐서 여섯입니다. 유틸리티 하나가 규칙 하나라는 보장이 없다는 게 이런 뜻이었어요.

다섯 개의 기준 크기

여기 나온 다섯 개가 Tailwind가 미리 정해둔 기준 크기입니다. 각각 이름이 있어요.

쓰는 법은 상태 변형과 똑같습니다. 앞에 붙이면 돼요.

sm:px-4
└┬┘ └─┬─┘
조건  유틸리티

⚠️ sm:은 "작은 화면"이 아닙니다

이름 때문에 가장 많이 헷갈리는 부분입니다. sm:px-4는 "작은 화면에서 좌우 여백"이 아니라 "640px 이상에서 좌우 여백"입니다.

위 CSS를 다시 보세요. @media (width>=40rem) 이죠. 크거나 같을 때예요.

그래서 순서가 이렇게 됩니다.

 조건 없는 유틸리티        모든 화면에 걸린다  (= 제일 좁은 화면 기준)
        │
        ├── sm:  640px 이상에서 덮어쓴다
        │
        ├── md:  768px 이상에서 덮어쓴다
        │
        └── lg: 1024px 이상에서 덮어쓴다

좁은 화면을 기본으로 쓰고, 넓어질수록 조건을 붙여 덮어쓰는 겁니다. 이 순서를 좁은 쪽부터 쓴다고 해서 mobile-first라고 불러요.

반대 방향도 있습니다. max-sm:은 "640px 미만에서만"을 뜻해요. 다만 기본으로는 mobile-first를 쓰고, 좁은 화면에서만 예외를 둘 때 max-를 꺼내는 편이 규칙 수가 적습니다.

⚠️ 쓴 순서는 아무 상관이 없습니다

여기서 학생분들이 자주 하는 착각이 하나 있어요. className에 적은 순서가 우선순위를 정한다고 생각하는 겁니다.

확인해 봤습니다. 일부러 뒤집어서 넓은 조건을 먼저 적고 좁은 조건을 나중에 적어도, 빌드된 CSS에서는 항상 같은 순서로 나옵니다.

 CSS 파일에 나오는 순서 (앞에서부터)

 조건 없는 유틸리티
    │
 상태 변형 (hover: focus-visible: disabled: 등)
    │
 max-sm: 처럼 위쪽을 자르는 조건
    │
 sm: → md: → lg: → xl: → 2xl:   (좁은 것부터 넓은 것 순)
    │
 (하나 더 있는데 다음 시간에 만납니다)

여기서 Step 1과 갈리는데, 상태 변형은 조건이 규칙을 더 구체적으로 만들어서 무게로 이겼지만 화면 크기 조건은 무게를 더하지 않습니다. sm:p-2와 p-2는 무게가 똑같아요.

무게가 같으면 반응형끼리는 순서가 유일한 기준이 되어, 뒤에 나온 것이 이깁니다. lg:는 항상 sm:을 이기고, className을 어떻게 늘어놓든 결과가 같습니다.

⚠️ 다만 대괄호로 직접 적은 기준 크기는 이 줄에 안 섭니다. min-[900px]:은 900px 이라 sm:(640px)보다 넓은데도 CSS에서는 sm:보다 앞에 나와서, 둘이 부딪히면 sm:이 이깁니다. 크기 순서대로일 거라 믿으면 틀리는 부분입니다.

💡 한 줄 정리

반응형 변형은 "그 크기 이상"을 뜻합니다. 조건 없는 유틸리티가 가장 좁은 화면을 맡고, 넓어질 때마다 조건을 붙여 덮어씁니다. 화면 크기 조건은 무게를 안 더하므로, 우선순위는 className에 쓴 순서가 아니라 Tailwind가 정한 출력 순서로 갈립니다.

Step 5: 피드를 두 열로

배운 걸 실제 화면에 적용해 봅시다. 지금 우리 앱은 화면이 아무리 넓어도 470px 짜리 한 줄입니다.

지금 무엇이 아쉬운가

두 가지가 걸립니다.

휴대폰에서는 카드 양옆에 16px 여백이 있어서 사진이 화면을 꽉 못 채웁니다. 인스타그램 앱을 열어 보면 사진이 가장자리까지 닿죠.

큰 모니터에서는 반대입니다. 화면이 1900px 인데 470px 만 쓰고 양옆이 텅 빕니다.

두 문제의 방향이 반대예요. 좁을 때는 더 넓게, 넓을 때는 더 많이. 조건 없이는 둘 다 만족시킬 수 없습니다.

좁은 화면부터 씁니다

mobile-first 니까 조건 없는 쪽이 가장 좁은 화면을 맡습니다.

// apps/web-spa/src/App.tsx
<main className="mx-auto max-w-[470px] py-4 sm:px-4 lg:max-w-[964px]">

세 덩어리로 읽으면 됩니다.

• py-4 — 위아래 여백은 항상. 좌우는 안 줍니다
• sm:px-4 — 640px 이상에서만 좌우 여백을 줍니다
• lg:max-w-[964px] — 1024px 이상에서 폭 상한을 470px 에서 964px 로 올립니다

원래 p-4 였던 걸 py-4 sm:px-4로 갈랐습니다. 좁은 화면에서 좌우 여백이 사라지니 사진이 가장자리까지 닿아요.

넓어지면 두 열로

폭만 넓히면 카드 하나가 964px 로 커집니다. 그건 원하는 게 아니에요. 목록을 두 열로 만들어야 합니다.

// apps/web-spa/src/components/Feed.tsx
<List
  items={posts}
  className="lg:grid lg:grid-cols-2 lg:gap-6"
  aria-label="피드 목록"
  renderItem={(post) => <PostCard {...post} onToggleLike={onToggleLike} />}
/>

조건 없는 상태에서는 그냥 목록이라 카드가 세로로 쌓입니다. 1024px 이상에서만 격자가 되고 두 열로 갈라져요.

여백의 책임이 옮겨갑니다

여기서 손볼 게 하나 생깁니다. 카드에는 원래 mb-6이 붙어 있어요. 세로로 쌓일 때 카드 사이를 벌리는 여백이지만, 격자가 되면 lg:gap-6이 그 일을 합니다. 둘 다 두면 아래쪽만 두 배로 벌어져요.

// apps/web-spa/src/components/PostCard.tsx
<Card
  className="mb-6 overflow-hidden rounded-lg border border-line bg-surface lg:mb-0"

lg:mb-0으로 넘깁니다. 좁을 때는 카드가 자기 여백을 챙기고, 넓어지면 격자가 대신 챙기는 겁니다.

⚠️ 넓히니 엉뚱한 게 딸려왔습니다

여기까지 하고 큰 화면에서 열어봤더니 문제가 하나 보였습니다. 피드는 두 열로 잘 갈라졌는데 회원가입 폼이 964px 로 늘어나 버렸어요. 입력칸이 화면을 가로지릅니다.

당연한 일입니다. 우리가 넓힌 건 main이고, 회원가입 폼은 그 안에 있는 형제 요소니까요. 컨테이너를 넓히면 그 안의 모든 것이 함께 넓어집니다.

폼에 따로 상한을 걸어 잡았습니다.

// apps/web-spa/src/components/SignUpForm.tsx
<form
  className="flex flex-col gap-3 rounded-lg border border-line bg-surface p-4 lg:max-w-[470px]"

세 폭에서 재봅시다

브라우저 창을 줄였다 늘렸다 하면서 확인해 보세요. 재보면 이렇게 나옵니다.

경계가 640과 1024에서 정확히 갈립니다. 그 값 자체는 이미 조건에 들어가요. 크거나 같을 때니까요.

숫자도 맞춰볼 수 있습니다. 438은 470에서 좌우 16씩 뺀 값이고, 454는 964에서 좌우 여백 32와 열 사이 간격 24를 빼고 둘로 나눈 값입니다.

자바스크립트가 한 줄도 없습니다

B-4 과제에서 창 너비를 재는 useWindowWidth 훅을 만드셨죠. 그때 제가 CSS로 되는 일을 굳이 자바스크립트로 하고 있지 않은지 먼저 따져보자고 했습니다. 오늘이 그 이야기를 회수하는 시간이에요.

같은 화면을 그 훅으로 만들 수도 있었습니다. 너비를 상태로 들고, 리사이즈를 구독하고, 숫자를 비교해서 열 수를 정하는 식인데, 그러면 두 가지가 따라와요.

창을 끌어서 늘리는 동안 리렌더가 계속 도는데, 나중에 서버가 HTML을 먼저 그려 보내는 방식을 배우게 되면 그때는 서버가 창 크기를 알 수 없어서 열 수를 정할 방법이 없습니다.

CSS로 하면 둘 다 없습니다. 브라우저가 화면을 그리기 전에 이미 어떤 규칙이 걸릴지 정해지거든요.

💡 한 줄 정리

좁은 화면을 조건 없이 쓰고, 넓어질 때 sm:·lg:로 덮어씁니다. 배치를 바꾸면 여백의 책임도 함께 옮겨가고, 컨테이너를 넓히면 그 안의 형제 요소까지 따라 넓어진다는 걸 잊으면 안 됩니다.

마무리

오늘 한 일을 한 줄로 줄이면 이렇습니다. 유틸리티에 조건을 붙였습니다.

지난 시간까지는 유틸리티가 항상 걸리는 것만 표현할 수 있었어요. 오늘 앞에 콜론 하나를 붙이면서, 언제 걸릴지를 함께 말할 수 있게 됐습니다.

오늘 배운 핵심 세 가지

💡 하나 — 같은 속성을 다툴 때 누가 이기는지는 조건의 종류마다 다릅니다. 상태 조건은 규칙을 더 구체적으로 만들어 순서와 관계없이 이기고, 화면 크기 조건은 무게를 안 더해서 순서로만 갈립니다. 둘을 하나로 외우면 언젠가 틀립니다.

💡 둘 — 조건은 화면 안쪽에만 있는 게 아닙니다. disabled:는 요소의 상태를 보고, hover:는 기기에 마우스가 있는지까지 봅니다. sm:은 창 크기를 보고요. 같은 문법인데 보는 대상이 다릅니다.

💡 셋 — 반응형은 좁은 화면부터 씁니다. 조건 없는 유틸리티가 가장 좁은 화면을 맡고, 넓어질 때마다 덮어써요. sm:이 "작은 화면"이 아니라 "그 이상"이라는 것만 잡으면 나머지는 따라옵니다.

시작할 때 남아 있던 두 줄

오프닝에서 손으로 쓴 규칙 두 줄을 보여드렸죠. 어떻게 닫혔는지 봅시다.

두 컴포넌트의 className에서 손으로 지은 이름도 함께 사라졌습니다. 지지난 시간에 Avatar 하나로 시작한 일이 여기서 끝났어요.

다음 시간 예고

Step 4에서 기준 크기 다섯 개를 봤죠. 그런데 그건 Tailwind가 정해준 값입니다. 우리 화면에 맞는 선을 우리가 정하려면 어떻게 할까요.

지난 시간에 색에 이름을 줬던 방법을 그대로 쓰면 되는데, 기준 크기도 토큰이거든요. 다만 이 토큰은 지난 시간에 배운 것과 달라서 아무리 써도 :root에 안 나타나요. 왜 그런지가 다음 시간의 첫 이야기입니다.

그리고 Step 4의 순서 그림에서 제가 하나를 비워뒀습니다. 모든 조건보다 뒤에 오는 게 하나 더 있어요. 다크모드입니다.

Step 1에서 잠긴 버튼 색을 text-brand/30으로 옮기면서, 어두운 배경 위에서는 값이 갈린다고 했죠. 그때 미뤄둔 확인도 다음 시간에 합니다. 지난 시간에 이름만 지어두고 안 갈라놓은 canvas와 surface도 마침내 갈라집니다.

마지막으로 오늘 우리는 창 크기를 보고 배치를 바꿨는데, 컴포넌트가 어디에 놓였느냐에 따라 다르게 보이고 싶을 때도 있어요. 같은 카드가 넓은 칸에 놓이면 가로로, 좁은 칸에 놓이면 세로로 그려지는 식으로요. 창이 아니라 담긴 칸을 보는 방법도 Tailwind에 들어 있습니다. 이름은 컨테이너 쿼리이고, 실제로 써보는 건 조금 더 뒤예요.

과제

[구현] 틈 하나에 기대고 있는 링 고치기

Step 3에서 가입하기 버튼만 테두리 색과 배경색이 같다고 했죠. 지금은 2px 틈 덕분에 보이지만, 그 틈이 사라지면 함께 사라집니다. 이걸 고쳐 주세요.

• 먼저 문제를 눈으로 확인하세요. 그 버튼의 focus-visible:outline-offset-2를 잠깐 빼고 Tab으로 밟아 보면 테두리가 어떻게 되나요?
• 간격을 되돌린 뒤, 그 버튼에만 다른 색 테두리를 주세요. 우리 토큰 중에서 고르면 됩니다.
• 고른 색으로 다시 간격을 빼봤을 때도 테두리가 보이는지 확인하세요. 보인다면 제대로 고른 겁니다.
• 개발자 도구에서 그 버튼의 outline-color와 background-color를 나란히 확인하고, 두 값을 적어 주세요.
• 왜 그 색을 골랐는지 한 줄로 설명해 주세요. 버튼 위에서도 보이고 페이지 배경 위에서도 보여야 합니다.

[구현] 좁은 화면에서 덜 보여주기

지금 게시물 카드에는 "댓글 32개 모두 보기" 줄이 있습니다. 좁은 화면에서는 이 줄을 감춰 보세요.

• PostBody의 그 문단이 대상입니다.
• 640px 미만에서만 감기게 하세요. Step 4에서 이야기한 max- 방향을 쓰면 됩니다.
• 같은 결과를 mobile-first 방향으로도 만들어 보세요. 조건 없는 쪽에 감추기를 두고 sm:으로 되살리는 식입니다.
• 두 방법 모두 화면 결과는 같습니다. 어느 쪽이 읽기 좋았는지 한 줄로 적어 주세요.

다 하고 나면 npm run typecheck -w web-spa와 npm run lint -w web-spa를 돌려 둘 다 통과하는지 확인해 주세요.

[탐구] 변형의 경계를 건드려 보기

각 실험 결과를 한두 줄씩 적어 주세요. 확인이 끝나면 전부 되돌립니다.

• 아무 버튼에 sm:text-danger lg:text-brand를 함께 붙이고, 창을 좁혔다 넓히며 글자색을 보세요. 그다음 className에서 두 개의 순서를 바꿔 다시 확인해 보세요. 결과가 달라지나요? Step 4의 순서 이야기와 맞는지 견줘 보세요.
• 같은 버튼에 min-[900px]:text-danger sm:text-brand를 붙이고 창을 1000px 쯤으로 맞춰 보세요. 두 조건이 모두 참인데 어느 쪽이 이기나요? 크기 순서대로 나오나요?
• 댓글 삭제 버튼의 hover:text-ink를 active:text-ink로 바꾸고, 마우스를 올릴 때와 누르고 있을 때를 각각 확인해 보세요. 개발자 도구의 기기 모드로 터치 기기를 흉내 내면 무엇이 달라지나요?
• 아무 요소에 disabled:text-danger를 붙여 보세요. 그 요소가 <div> 라면 어떻게 되나요? 빌드된 CSS에 규칙이 생기는지, 화면이 바뀌는지 나눠서 확인해 보세요.

생각해볼 주제

1. 여덟 곳에 같은 문자열을 적는 것이 맞을까

Step 3에서 우리는 세 개짜리 문자열을 여덟 곳에 똑같이 붙였습니다. 새 버튼을 만들 때마다 아홉 번째, 열 번째로 또 붙여야 하고요.

이미 한 곳을 빠뜨린 상태이기도 한데, 프로필 사진 고르기 버튼만 혼자 브라우저 기본 테두리로 뜹니다. 표시가 사라지는 건 아니지만 화면마다 다른 테두리가 섞이고, 나중에 누가 outline: none을 한 줄 쓰는 순간 그 버튼만 아무 표시가 없어져요. 그리고 빠뜨렸다는 걸 알아차리기가 어렵습니다. 마우스로 쓰면 아무 문제가 없으니까요.

방법이 없지는 않습니다. 포커스 표시를 CSS 파일에 한 번만 써두고 모든 버튼에 걸리게 할 수도 있는데, 그러면 우리가 세 시간에 걸쳐 걷어낸 손 CSS가 다시 생겨요.

Button 컴포넌트 안에 넣는 방법도 있습니다. 다만 B-3에서 우리는 "생김새는 쓰는 쪽이 정한다"는 규칙으로 그 컴포넌트를 만들었어요. 그 규칙을 깨는 셈입니다.

여러분이라면 어떻게 하시겠어요. 이 판단을 할 때는 포커스 표시가 "생김새"인지, 아니면 버튼이라면 당연히 갖춰야 할 기능인지도 함께 생각해 보세요.

2. 조건을 화면 크기로 나누는 것의 한계

오늘 우리는 1024px 을 기준으로 한 열과 두 열을 갈랐습니다. 창이 1024px 보다 넓으면 두 열이지만, 창 크기가 정말 우리가 알고 싶은 것일까요.

사용자가 브라우저 옆에 다른 창을 띄워두고 우리 화면을 절반만 보고 있다면, 창은 좁지만 화면은 넓습니다. 태블릿을 세로로 들면 창은 좁은데 손가락으로 조작하고요.

반대 경우도 있습니다. 화면은 좁은데 마우스를 쓰는 사람, 화면은 넓은데 터치로만 쓰는 사람도 있어서, 화면 크기 하나로 "이 사람이 어떤 환경인가"를 다 알 수는 없습니다. 오늘 hover:가 크기가 아니라 입력 장치를 봤던 것도 같은 이유예요.

우리가 배치를 바꾸고 싶을 때 진짜로 알아야 하는 게 무엇인지 정리해 보고, 그중 화면 크기로 알 수 있는 게 얼마나 되는지도 생각해 보세요.

3. 아무도 안 보는 상태를 어떻게 관리할까

오늘 우리가 만든 규칙 중에는 평소에 화면에 안 보이는 게 많습니다. 잠긴 버튼 색, 마우스를 올렸을 때 색, 키보드로 왔을 때 테두리 모두 특정 조건에서만 나타나요.

문제는 이런 상태가 평소에 확인되지 않는다는 겁니다. 개발자가 화면을 열어봐도 안 보이고, 디자인 시안에도 대개 기본 상태만 그려져 있습니다. 잠긴 버튼 색이 잘못돼도 몇 달 동안 아무도 모를 수 있어요.

오늘 우리도 가입하기 버튼의 테두리가 배경과 같은 색인 걸 뒤늦게 발견했죠. 그것도 일부러 Tab 키를 눌러가며 확인했기 때문에 찾은 겁니다.

조건이 붙은 스타일이 늘어날수록 이런 사각지대도 늘어납니다. 팀이 이걸 놓치지 않으려면 무엇을 정해두어야 할까요. 그리고 그 방법이 새 팀원이 들어와도 지켜질 만한 것인지도 생각해 보세요.