E-6: Shadcn 컴포넌트로 화면 만들기 — 남이 짠 코드를 열어서 읽는 날

안녕하세요, 홍순구입니다. 지난 시간에 우리는 라이브러리를 들여놓고 이름이 부딪히는 걸 정리하고 다크모드 스위치까지 우리 손으로 가져왔는데, 정작 컴포넌트는 하나도 안 썼어요. components/ui/ 폴더는 아직 비어 있는데, 설치만 하고 끝난 셈이죠.

오늘 드디어 가져다 씁니다. 명령 하나로 파일이 복사돼 오는 걸 보고, 그 파일을 열어서 읽습니다. 남이 짠 코드지만 이제 내 파일이니까요. 지난 시간 첫머리에서 꺼냈던 목록도 다시 꺼내는데, 모달 하나 제대로 만들려면 챙길 게 여섯 가지였죠. 그중 몇 개가 공짜로 딸려오는지 오늘 직접 세어봅니다.

 오늘의 여정

 Step 1     명령 하나에 파일 넷이 왔다
    │
 Step 2     large 와 small 을 어떻게 구분하나
    │
 Step 3     cn 이 무슨 일을 하는지 이제 말합니다
    │
 Step 4     붙어 있는 표시와 없는 함수
    │
 Step 5     피드를 갈아끼운다
    │
 Step 6     사진을 누르면 크게
    │
 Step 7     여섯 줄을 세어본다
    │
 Step 8     값을 매긴다
    ▼
 남이 짠 코드를 읽고, 고치고, 우리 것과 나란히 세운다

💡 오늘 수업의 핵심 — "가져다 쓴다는 것은 읽을 줄 안다는 뜻이다"

복사해 온 파일은 블랙박스가 아니라서, 열면 읽을 수 있고 읽으면 고칠 수 있어요. 읽을 줄 알아야 소유한 값을 합니다.

🎯 학습 목표

• 복사돼 온 컴포넌트를 열어 cva로 변형을 정의하는 방식과 cn이 클래스 충돌을 정리하는 방식을 설명할 수 있다
• data-slot 표시가 왜 붙어 있는지 설명하고, 우리 토큰과 들여온 토큰을 한 화면에서 함께 쓸 수 있다
• Dialog로 모달을 만들고, 접근성 동작 중 무엇이 딸려오고 무엇이 우리 몫인지 가려낼 수 있다

Step 1: "명령 하나에 파일 넷이 왔다"

바로 가져와 보기 전에, 한 번 물어볼 수 있어요.

npx shadcn@latest add dialog --dry-run

--dry-run은 "실제로 하지 말고 뭘 할 건지만 보여줘"라는 뜻입니다.

┌ shadcn add dialog (dry run)
│
├ Files (2) +2 new
│ + src/components/ui/button.tsx  create
│ + src/components/ui/dialog.tsx  create
│
│ 2 files
└ Run without --dry-run to apply.

dialog 하나만 불렀는데 button.tsx가 따라옵니다. 대화 상자 안에 닫기 버튼이 들어가거든요. 이렇게 딸려오는 것들이 있어서 미리 보는 습관이 도움이 됩니다.

이제 필요한 것들을 한 번에 가져올게요.

npx shadcn@latest add dialog avatar card

✔ Created 4 files:
  - src/components/ui/avatar.tsx
  - src/components/ui/card.tsx
  - src/components/ui/button.tsx
  - src/components/ui/dialog.tsx

설치했는데 package.json이 안 바뀌었습니다

여기서 이상한 걸 발견하게 됩니다. 보통 뭔가를 설치하면 package.json이 늘어나기 마련인데, 열어보면 한 줄도 안 바뀌어 있습니다.

지난 시간을 떠올려 보세요. init을 돌렸을 때 이미 여덟 개가 깔렸고 @base-ui/react도 그때 들어왔으니, 오늘 온 것은 컴포넌트 소스 파일뿐이에요.

 지난 시간 init          →  package.json 에 8개 추가 (동작 알맹이·cn 재료·아이콘…)
 오늘 add                →  파일 4개 복사. package.json 변화 없음

지난 시간에 말한 "생김새는 내가 소유하고, 동작은 빌려 쓴다"가 이렇게 눈에 보입니다.

이름이 전부 겹칩니다

새로 온 파일 이름을 우리 폴더와 나란히 놓아 보세요.

 src/components/
   Avatar.tsx      ← 우리가 B-3 에서 짠 것
   Button.tsx      ← 우리가 짠 것
   Card.tsx        ← 우리가 짠 것
   PostCard.tsx
   ...
   ui/
     avatar.tsx    ← 방금 온 것
     button.tsx    ← 방금 온 것
     card.tsx      ← 방금 온 것
     dialog.tsx    ← 방금 온 것

셋이나 겹치죠. 지난 시간 질문 토글에서 components/ui/ 폴더 규약을 이야기했는데, 그게 지금 진짜로 일을 합니다. 폴더가 다르니 파일은 안 부딪히고, 폴더 이름만 보고도 "이건 가져온 것"을 알 수 있어요.

열어보면 우리 스타일이 아닙니다

파일을 하나 열어보면 바로 눈에 띄는 게 있습니다.

// apps/web-spa/src/components/ui/card.tsx
import * as React from "react"

import { cn } from "@/lib/utils"

쌍따옴표를 쓰고 줄 끝에 세미콜론이 없는데, 우리는 작은따옴표에 세미콜론을 붙여 왔죠. 남의 집 규칙이 그대로 들어온 건데, 린트를 돌려보면 그래도 통과합니다. 우리 설정이 따옴표나 세미콜론까지는 강제하지 않기 때문이에요. 그대로 두셔도 되고, 팀 규칙이 엄격하면 포매터를 한 번 돌려 맞춰도 됩니다.

dialog.tsx는 첫 줄이 더 낯설어요.

// apps/web-spa/src/components/ui/dialog.tsx
"use client"

이건 Next.js를 위한 표시입니다. 우리는 지금 Vite로 만든 SPA라 아무 일도 하지 않아요. 나중에 D 카테고리에서 Next.js를 다룰 때 이 줄이 무슨 뜻인지 제대로 봅니다. 지금은 "무해한 줄이 하나 있구나" 정도로 넘어가세요.

💡 한 줄 정리

add는 컴포넌트 소스를 components/ui/로 복사해 옵니다. 딸린 것이 함께 오고, 이미 깔린 의존성은 다시 안 깔며, 우리가 짠 컴포넌트와 이름이 겹쳐도 폴더가 달라 부딪히지 않습니다.

import { Card } from './ui/card';
import { Card as LegacyCard } from './Card';

Step 2: "large와 small을 어떻게 구분하나"

이제 읽어봅시다. button.tsx부터요. 버튼은 생김새가 제일 여러 갈래라 읽을 게 많습니다.

// apps/web-spa/src/components/ui/button.tsx
import { cva, type VariantProps } from "class-variance-authority"

const buttonVariants = cva(
  "group/button inline-flex shrink-0 items-center justify-center rounded-lg …",
  {
    variants: {
      variant: {
        default: "bg-primary text-primary-foreground hover:bg-primary/80",
        outline: "border-border bg-background hover:bg-muted …",
        ghost: "hover:bg-muted hover:text-foreground …",
        destructive: "bg-destructive/10 text-destructive …",
        link: "text-primary underline-offset-4 hover:underline",
      },
      size: {
        default: "h-8 gap-1.5 px-2.5 …",
        sm: "h-7 gap-1 rounded-[min(var(--radius-md),12px)] px-2.5 …",
        lg: "h-9 gap-1.5 px-2.5 …",
        icon: "size-8",
      },
    },
    defaultVariants: {
      variant: "default",
      size: "default",
    },
  }
)

구조가 보이시나요. 세 덩어리입니다.

 cva(
   "언제나 붙는 클래스 한 뭉치",      ← 어떤 버튼이든 공통
   {
     variants: {
       variant: { default: "...", outline: "...", ghost: "..." },   ← 성격
       size:    { default: "...", sm: "...", lg: "...", icon: "..." }  ← 크기
     },
     defaultVariants: { ... }        ← 아무것도 안 고르면 이것
   }
 )

쓰는 쪽은 클래스를 몰라도 됩니다. 이름만 고르면 돼요.

<Button variant="outline" size="sm">취소</Button>

buttonVariants({ variant: 'outline', size: 'sm' })를 부르면 공통 뭉치 + outline 줄 + sm 줄이 이어 붙은 긴 문자열이 나옵니다. 그 문자열이 className으로 들어가는 거죠.

타입이 저절로 생깁니다

컴포넌트 선언부를 보면 재미있는 게 있어요.

function Button({
  className,
  variant = "default",
  size = "default",
  ...props
}: ButtonPrimitive.Props & VariantProps<typeof buttonVariants>) {

VariantProps<typeof buttonVariants> — A-6에서 배운 typeof로 값에서 타입을 뽑아내는 그 방식입니다. 위에서 정의한 variants 객체를 읽어서 variant는 여섯 개 중 하나, size는 여덟 개 중 하나라는 타입이 자동으로 만들어지니까, 오타를 내면 바로 잡힙니다. variant="outlien"이라고 쓰면 편집기가 그 자리에서 빨간 줄을 그어요. 변형 목록을 한 곳에 적었더니 타입까지 따라온 겁니다.

⚠️ 그런데 넷 중 셋은 cva를 안 씁니다

여기서 많이들 오해하는 지점이 있는데, "shadcn은 cva로 변형을 만든다"고 외우면 card.tsx를 열었을 때 당황해요. 거기엔 cva가 없거든요.

넷을 나란히 놓고 세어보면 이렇습니다.

 button.tsx    cva 씀      variant 6종 · size 8종
 card.tsx      cva 없음    data-size 속성으로 갈림
 avatar.tsx    cva 없음    data-size 속성으로 갈림
 dialog.tsx    cva 없음    변형 자체가 없음

card.tsx는 이렇게 되어 있어요.

// apps/web-spa/src/components/ui/card.tsx
<div
  data-slot="card"
  data-size={size}
  className={cn(
    "… py-(--card-spacing) [--card-spacing:--spacing(4)] " +
      "data-[size=sm]:[--card-spacing:--spacing(3)] …",
    className
  )}
/>

size를 클래스 묶음으로 바꾸는 대신 속성에 그대로 적어 두고, data-[size=sm]:이라는 조건부 클래스로 갈라요. E-3에서 배운 변형 문법이 여기 쓰인 겁니다.

두 방식이 갈리는 기준은 이렇게 이해하면 편합니다.

card.tsx가 두 번째인 이유는 카드 안의 제목도 크기를 따라가야 하기 때문이에요. 속성을 부모에 걸어두면 자식이 group-data-[size=sm]/card:로 그걸 읽습니다. 클래스 묶음으로는 그 연결이 안 되죠.

💡 한 줄 정리

cva는 변형을 이름으로 고르게 만들고 그 이름의 타입까지 함께 만들어 주지만, 모든 컴포넌트가 쓰는 건 아니에요. 크기 하나가 자식들에게까지 퍼져야 하는 곳은 data-* 속성으로 갑니다.

Step 3: "cn이 무슨 일을 하는지 이제 말합니다"

지난 시간에 lib/utils.ts를 보면서 미뤄둔 게 있죠. 이 여섯 줄이요.

// apps/web-spa/src/lib/utils.ts
import { clsx, type ClassValue } from "clsx"
import { twMerge } from "tailwind-merge"

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

방금 읽은 button.tsx의 마지막 줄에서 이게 쓰였습니다.

className={cn(buttonVariants({ variant, size, className }))}

무슨 일을 하는지 알려면, 이게 없을 때 무슨 일이 생기는지 보는 게 빠릅니다. 그리고 그 예가 우리 코드에 이미 있어요.

우리 Button이 갖고 있던 문제

B-3에서 만든 우리 Button은 이랬습니다.

// apps/web-spa/src/components/Button.tsx
export function Button({ children, className, ... }: ButtonProps) {
  return (
    <button className={className} ...>
      {children}
    </button>
  );
}

받은 className을 그대로 붙이다 보니, 안쪽에 기본 생김새가 없었어요. 쓰는 쪽이 전부 적어야 했습니다.

만약 우리 Button에도 기본 여백을 넣고 싶어서 이렇게 했다고 해봅시다.

<button className={"px-2.5 " + className} />

그리고 쓰는 쪽에서 className="px-6"을 넘기면요? 결과는 이렇게 됩니다.

 "px-2.5 px-6"

둘 다 살아남는데, 어느 쪽이 이길까요. E-3에서 배웠죠 — 클래스를 적은 순서는 아무 상관이 없고, CSS 파일에 나중에 나온 규칙이 이깁니다. 그런데 그 순서는 우리가 정하는 게 아니라 Tailwind가 정해요.

즉 px-6을 넘겼는데 px-2.5가 이길 수도 있어요. 우연에 기대는 코드가 되는 셈이죠.

cn은 겹치는 것을 지웁니다

같은 상황을 cn에 넣으면 이렇게 됩니다.

겹치는 것만 지우고 안 겹치는 건 그대로 두다 보니, 나중에 넘긴 것이 확실히 이겨요. 우연이 사라집니다.

이름 두 개가 각각 하는 일은 이렇게 나뉩니다.

 clsx        조건·배열·객체를 문자열 하나로 모은다
             cn('base', 조건 && 'on', { off: false }, ['arr'])  →  "base on arr"
             (겹치는 건 안 건드린다 — 모으기만 한다)

 tailwind-merge   그 문자열에서 서로 겹치는 클래스를 정리한다
             "px-2.5 px-6"  →  "px-6"

 cn          위 둘을 이어 붙인 것. 모으고 나서 정리한다.

⚠️ "뒤엣것이 이긴다"가 아닙니다

여기서 한 걸음 더 들어가 볼게요. 이 두 줄의 결과가 다릅니다.

 cn('px-6', 'p-4')   →  "p-4"           px-6 이 사라졌다
 cn('p-4', 'px-6')   →  "p-4 px-6"      둘 다 남았다

첫 줄은 p-4가 좌우 여백까지 전부 정하니까 앞의 px-6은 어차피 덮여요. 그래서 지웁니다.

둘째 줄은 px-6이 p-4의 좌우만 덮습니다. 위아래는 p-4가 계속 필요해서, 둘 다 남깁니다.

즉 규칙은 "뒤엣것이 이긴다"가 아니라 "뒤엣것이 앞엣것을 완전히 덮을 수 있을 때만 앞엣것을 지운다"입니다.

⚠️ 그리고 갈래가 다르면 아예 못 밉니다

이건 나중에 우리가 실제로 부딪히는 함정이라 미리 봐 둘게요.

 cn('ring-1 ring-foreground/10', 'border border-line')
   →  "ring-1 ring-foreground/10 border border-line"

하나도 안 지워졌죠. ring은 테두리처럼 보이지만 실은 그림자로 그리는 것이고, border는 진짜 테두리입니다. 서로 다른 갈래라 겹친다고 판단하지 않다 보니, 테두리가 두 겹으로 그려집니다.

이럴 땐 끄고 싶은 쪽을 직접 꺼야 해요.

 cn('ring-1 ring-foreground/10', 'border border-line ring-0')
   →  "ring-foreground/10 border border-line ring-0"

cn은 만능이 아니라서, 같은 종류끼리만 정리해 줘요.

💡 한 줄 정리

cn은 클래스를 모으고(clsx) 겹치는 것을 정리합니다(tailwind-merge). 덕분에 바깥에서 넘긴 클래스가 확실히 이겨요. 단 완전히 덮을 수 있을 때만 지우고, 갈래가 다르면 손대지 않습니다.

Step 4: "붙어 있는 표시와 없는 함수"

파일을 읽다 보면 눈에 걸리는 게 하나 더 있습니다. 모든 요소에 이게 붙어 있어요.

// apps/web-spa/src/components/ui/card.tsx
<div data-slot="card" ... />
<div data-slot="card-header" ... />
<div data-slot="card-content" ... />
<div data-slot="card-footer" ... />

우리가 가져온 파일 넷을 다 뒤지면 이런 이름표가 스물네 종류 나옵니다. avatar, avatar-image, avatar-fallback, dialog-trigger, dialog-content… 조각마다 하나씩 붙어 있어요.

이게 뭘까요. 클래스도 아니고 아이디도 아닌, 그냥 data-로 시작하는 우리끼리의 표시예요.

부모가 자식을 보고 자기를 바꿉니다

답은 card.tsx의 클래스 문자열 안에 있습니다.

 has-data-[slot=card-footer]:pb-0

풀어 읽으면 이렇습니다. "내 안에 data-slot="card-footer"를 단 자식이 있으면, 내 아래쪽 여백을 0으로 한다."

왜 이런 게 필요할까요. 카드에 꼬리 구역이 있을 때와 없을 때 여백이 달라야 하기 때문입니다.

 꼬리가 없는 카드                    꼬리가 있는 카드
 ┌──────────────┐                   ┌──────────────┐
 │  (위 여백)     │                   │  (위 여백)     │
 │   내용         │                   │   내용         │
 │  (아래 여백)   │                   ├──────────────┤
 └──────────────┘                   │   꼬리         │  ← 여백 없이 딱 붙는다
                                     └──────────────┘

꼬리는 배경색이 따로 있어서 카드 바닥까지 꽉 차야 예뻐요. 그런데 카드는 자기 자식이 뭘 넣을지 미리 알 수 없죠.

옛날에는 이걸 쓰는 쪽이 챙겼습니다. "꼬리를 넣을 거면 카드에 pb-0도 같이 붙이세요" 하는 식이었는데, 까먹으면 어긋나고요.

지금은 카드가 스스로 봅니다. 자식에 이름표가 붙어 있으니 그걸 조건으로 삼을 수 있어요.

이름표는 바깥에서 겨냥할 때도 씁니다. 여러 아바타를 겹쳐 놓는 곳은 이렇게 되어 있어요.

 *:data-[slot=avatar]:ring-2

"내 직계 자식 중 아바타인 것들에게 테두리를 둘러라." 자식 컴포넌트를 고치지 않고 부모가 조정하는 겁니다.

없는 것도 읽을 줄 알아야 합니다

이번엔 반대로, 있어야 할 것 같은데 없는 것을 찾아봅시다.

가져온 파일 넷을 통틀어 forwardRef라는 단어가 한 번도 안 나옵니다.

이 이름이 낯설다면 A-4를 떠올려 보세요. 부모가 자식 안쪽의 DOM 요소를 직접 만지고 싶을 때, 예전 React에서는 컴포넌트를 이 함수로 한 번 감싸야 했습니다. 감싸지 않으면 ref가 자식에게 전달되지 않았거든요.

React 19부터는 그냥 props로 받습니다.

// A-4 에서 배운 방식 — 감싸는 것 없이 받는다
function TextField({ ref, ...props }: TextFieldProps) {
  return <input ref={ref} {...props} />;
}

이 방식 덕분에 오늘 온 파일들에도 감싸는 코드가 없어요. 인터넷에서 shadcn 예제를 찾아보면 감싸는 코드가 있는 글이 아직 많습니다. 그건 오래된 글입니다. 지금 여러분 파일에는 없는 게 정상이에요.

이렇게 "없는 것"을 알아보는 것도 읽기의 일부입니다.

💡 한 줄 정리

data-slot은 조각마다 붙은 이름표입니다. 부모가 자식의 존재를 보고 자기 스타일을 정하거나, 바깥에서 특정 조각만 겨냥할 때 쓰이는데, React 19부터는 ref를 전달하려고 컴포넌트를 감쌀 필요가 없어서, 그 코드가 파일에 아예 없습니다.

Step 5: "피드를 갈아끼운다"

읽었으니 이제 씁니다. 피드 카드부터 갈아끼워 볼게요.

우리가 B-3에서 만든 Card는 이런 모양이었죠.

// apps/web-spa/src/components/Card.tsx
export function Card({ header, footer, children, className }: CardProps) {
  return (
    <article className={className}>
      {header}
      {children}
      {footer}
    </article>
  );
}

머리와 꼬리를 props 로 받습니다. header={<PostHeader ... />}처럼요.

들여온 Card는 다르게 생겼습니다.

// apps/web-spa/src/components/ui/card.tsx
export { Card, CardHeader, CardFooter, CardTitle, CardAction, CardDescription, CardContent }

머리와 꼬리가 각각 별도 컴포넌트예요. props가 아니라 자식으로 넣습니다.

 우리 방식 (자리를 props 로)          들여온 방식 (자리를 자식으로)

 <Card                               <Card>
   header={<PostHeader />}             <CardHeader><PostHeader /></CardHeader>
   footer={<CommentForm />}            <CardContent>...</CardContent>
 >                                     <CardFooter><CommentForm /></CardFooter>
   ...                               </Card>
 </Card>

둘 다 B-3에서 배운 합성입니다. 어느 쪽이 낫다기보다 성격이 달라요. props 방식은 자리가 고정돼서 실수할 여지가 적고, 자식 방식은 자리를 마음대로 늘리거나 뺄 수 있습니다.

들여온 쪽이 자식 방식을 고른 이유는 카드가 쓰이는 곳이 워낙 다양해서예요. 어떤 카드는 제목만, 어떤 카드는 설명과 버튼까지 필요하니까요.

카드를 바꿔 봅니다

// apps/web-spa/src/components/PostCard.tsx
import { Card, CardContent, CardFooter, CardHeader } from './ui/card';

export function PostCard({ id, username, profileImageUrl, imageUrl, ... }: PostCardViewProps) {
  const [comments, dispatch] = useReducer(commentReducer, initialCommentState);

  return (
    <Card className="mb-6 2col:mb-0">
      <CardHeader>
        <PostHeader username={username} profileImageUrl={profileImageUrl} />
      </CardHeader>
      <PostImage imageUrl={imageUrl} username={username} onLike={() => onToggleLike(id)} />
      <CardContent>
        <PostBody ... />
        <CommentList ... />
      </CardContent>
      <CardFooter>
        <CommentForm onSubmit={(text) => dispatch({ type: 'add', content: text })} />
      </CardFooter>
    </Card>
  );
}

className에 남긴 건 mb-6 2col:mb-0 둘뿐입니다. 카드 아래 여백은 두 열이 되는 순간 gap에게 넘긴다 — E-4에서 정한 그 규칙이죠. 나머지 생김새는 들여온 것에 맡깁니다.

사진을 CardContent 안에 안 넣고 밖에 둔 게 보이시나요. 인스타그램 사진은 카드 좌우에 딱 붙어야 하는데, CardContent는 좌우 여백을 갖고 있거든요. 형제로 두면 여백 없이 꽉 찹니다.

프로필도 바꿉니다

// apps/web-spa/src/components/PostHeader.tsx
import { Avatar, AvatarFallback, AvatarImage } from './ui/avatar';

export function PostHeader({ username, profileImageUrl }: PostHeaderProps) {
  return (
    <div className="flex items-center justify-between">
      <div className="flex items-center gap-2.5">
        <Avatar>
          <AvatarImage src={profileImageUrl} alt={`${username} 프로필 사진`} />
          {/* 사진이 아직 안 왔거나 실패했을 때 이 자리에 남는 것 */}
          <AvatarFallback>{username.slice(0, 1).toUpperCase()}</AvatarFallback>
        </Avatar>
        <span className="text-sm font-semibold">{username}</span>
      </div>
      <IconButton ...>⋯</IconButton>
    </div>
  );
}

우리 Avatar에는 없던 게 하나 생겼습니다. AvatarFallback이요.

우리 것은 <img> 하나였어요. 사진 주소가 깨져 있으면 브라우저가 그리는 회색 깨진 아이콘이 그대로 노출됐습니다. 들여온 것은 사진이 실제로 도착했는지 확인하고, 도착하기 전이나 실패했을 때는 대체 글자를 보여줘요. 사용자 이름 첫 글자를 넣어두면 그게 뜹니다.

작은 차이 같지만 목록에 카드가 수십 장 뜨는 화면에서는 크게 다릅니다. 깨진 아이콘 수십 개와 동그란 이니셜 수십 개는 인상이 완전히 달라요.

⚠️ 화면은 멀쩡한데 구조가 바뀌었습니다

바꾸고 나서 화면을 보면 별문제가 없어 보이는데, 카드가 잘 그려지고 사진도 뜨죠.

그런데 개발자 도구로 카드 요소를 눌러 보면 이렇게 나옵니다.

 우리가 짰을 때          <article class="...">

 들여온 것으로 바꾼 뒤    <div data-slot="card" data-size="default" class="...">

article이 div로 바뀌었어요.

이게 왜 문제냐면, article은 그냥 상자가 아니라 "여기부터 여기까지가 하나의 완결된 글"이라는 뜻이기 때문입니다. 화면 낭독기를 쓰는 사람은 이 표시 덕분에 게시물 단위로 건너뛸 수 있는데, div는 아무 뜻도 없는 상자라 그게 안 됩니다.

색이나 모서리가 바뀐 건 눈에 보이니 금방 알아채요. 뜻이 사라진 건 눈에 안 보입니다.

여기서 소유의 값을 합니다

Step 1에서 복사 방식은 파일이 내 것이라 마음에 안 들면 열어서 고칠 수 있다고 이야기했는데, 그 말을 지금 씁니다.

// apps/web-spa/src/components/ui/card.tsx
// 우리가 고친 곳: div → article.
// 이 프로젝트에서 카드는 전부 "게시물 한 장" 이라 문서 구조상 하나의 글이다.
function Card({
  className,
  size = "default",
  ...props
}: React.ComponentProps<"article"> & { size?: "default" | "sm" }) {
  return (
    <article
      data-slot="card"
      ...

두 줄 고쳤습니다. 태그 하나와 타입 하나요.

만약 패키지 방식이었다면 이 두 줄을 못 고칩니다. node_modules 안의 파일이니까요. 라이브러리가 as 같은 구멍을 열어줬기를 바라거나, 열어주지 않았으면 포기해야 해요.

⚠️ 대신 이 수정은 날아갈 수 있습니다

값을 치렀으니 비용도 봐야죠. 나중에 카드를 다시 가져오면 우리가 고친 게 덮입니다.

다행히 조용히 사라지지는 않고, 먼저 물어봅니다.

npx shadcn@latest add card --dry-run

├ Files (1) ~1 overwrite
│ ~ src/components/ui/card.tsx  overwrite
│
⚠ 1 file will be overwritten.

무엇이 덮이는지 궁금하면 차이까지 보여줍니다.

npx shadcn@latest add card --diff

│ │ -// 우리가 고친 곳: div → article.
│ │  function Card({
│ │ -}: React.ComponentProps<"article"> & { size?: "default" | "sm" }) {
│ │ +}: React.ComponentProps<"div"> & { size?: "default" | "sm" }) {
│ │ -    <article
│ │ +    <div

우리가 고친 자리가 그대로 나옵니다. 이걸 보고 다시 덮을지 말지 정하면 돼요.

그래서 실무에서는 고친 자리에 주석을 남깁니다. 위 코드에서 // 우리가 고친 곳이라고 적어둔 게 그것이에요. 몇 달 뒤에 이 파일을 다시 가져올 사람이 그 주석 덕분에 멈출 수 있습니다.

💡 한 줄 정리

들여온 카드는 자리를 자식으로 받고, 아바타는 사진이 실패했을 때 대체 글자를 보여줍니다. 다만 카드가 div로 바뀌면서 문서 구조상의 뜻이 사라졌고, 파일이 우리 것이라 두 줄을 고쳐 되돌렸습니다.

Step 6: "사진을 누르면 크게"

이제 오늘의 주인공입니다. 모달을 만들어요.

들여온 Dialog는 조각이 여러 개인데, 우리가 쓸 건 넷입니다.

 Dialog            전체를 감싸며 열림·닫힘 상태를 갖는다
   DialogTrigger   누르면 열리는 것
   DialogContent   실제로 뜨는 상자 (뒤 배경까지 함께 그린다)
     DialogTitle       상자의 제목
     DialogDescription 상자의 설명

우리가 상태를 만들 필요가 없어요. useState로 open을 들고 있지 않아도 Dialog가 알아서 합니다.

// apps/web-spa/src/components/PostModal.tsx
import { Dialog, DialogContent, DialogDescription, DialogTitle, DialogTrigger } from './ui/dialog';
import { Avatar, AvatarFallback, AvatarImage } from './ui/avatar';

export function PostModal({ username, profileImageUrl, imageUrl, content, likeCount, commentCount }: PostModalProps) {
  return (
    <Dialog>
      <DialogTrigger className="cursor-pointer px-3 pt-1 pb-3 text-left text-sm text-faint ...">
        댓글 {commentCount}개 모두 보기
      </DialogTrigger>
      <DialogContent className="max-w-[calc(100%-2rem)] gap-3 sm:max-w-lg">
        <DialogTitle className="flex items-center gap-2.5">
          <Avatar size="sm">
            <AvatarImage src={profileImageUrl} alt={`${username} 프로필 사진`} />
            <AvatarFallback>{username.slice(0, 1).toUpperCase()}</AvatarFallback>
          </Avatar>
          {username}
        </DialogTitle>
        <img className="w-full rounded-lg" src={imageUrl} alt={`${username} 의 게시물`} />
        <DialogDescription>{content}</DialogDescription>
        <p className="text-sm text-faint">
          좋아요 {likeCount}개 · 댓글 {commentCount}개
        </p>
      </DialogContent>
    </Dialog>
  );
}

Avatar에 size="sm"을 줬죠. Step 2에서 본 그 속성입니다. 이름만 골랐고 클래스는 한 글자도 안 적었어요.

여는 자리를 옮겼습니다

지난 시간 첫머리에서 저는 "사진을 누르면 크게 뜨는 그거"라고 말했는데, 막상 만들려니 문제가 있었어요.

우리 사진에는 이미 두 번 누르면 좋아요가 붙어 있습니다. A-4에서 붙였는데, 브라우저에서 두 번 누르기는 한 번 누르기가 두 번 일어난 다음에 일어나서 순서가 이렇게 됩니다.

 사용자가 사진을 빠르게 두 번 누름
    │
    ├─ 한 번 누르기 발생   →  모달이 열린다
    ├─ 한 번 누르기 발생   →  (이미 열려 있음)
    └─ 두 번 누르기 발생   →  좋아요를 누르려는데 화면이 이미 덮여 있다

좋아요를 누르려던 사람 앞에 모달이 뜹니다. 둘을 같은 자리에 놓으면 서로를 방해하다 보니, 여는 자리를 "댓글 N개 모두 보기"로 옮겼는데, 실제 인스타그램도 이렇게 동작해요. 피드에서 사진을 누르면 아무 일도 안 일어나고, 댓글 줄을 눌러야 게시물이 열립니다.

만들다 보면 이런 일을 자주 겪는데, 계획이 코드와 부딪히면 계획을 고치는 게 맞아요.

화면에 붙입니다

파일만 만들어 두면 아무 데도 안 나옵니다. 여는 버튼이 PostModal 안에 이미 들어 있으니, 댓글 줄을 이걸로 바꾸기만 하면 돼요.

댓글 줄을 그리던 PostBody에는 지금까지 이렇게 적혀 있었어요.

// apps/web-spa/src/components/PostBody.tsx
<p className="px-3 pt-1 pb-3 text-sm text-faint">댓글 {commentCount}개 모두 보기</p>

글자만 있고 아무 일도 안 하던 줄이라, 지우고 PostModal을 놓습니다.

// apps/web-spa/src/components/PostBody.tsx
import { PostModal } from './PostModal';

      <PostModal
        username={username}
        profileImageUrl={profileImageUrl}
        imageUrl={imageUrl}
        content={content}
        likeCount={likeCount}
        commentCount={commentCount}
      />

여기서 PostBody가 지금 안 갖고 있는 게 둘 있습니다. 모달은 사진과 프로필 사진을 크게 보여줘야 하는데, 본문 구역은 그동안 그 둘이 필요 없었거든요. props에 더해 줍니다.

interface PostBodyProps {
  username: string;
  profileImageUrl: string;
  imageUrl: string;
  content: string;
  liked: boolean;
  likeCount: number;
  commentCount: number;
  onToggle: () => void;
}

그다음은 PostCard에서 그 둘을 PostBody로 내려주기만 하면 됩니다. PostCard는 이미 갖고 있으니까요.

닫기 버튼은 안 만들었는데 있습니다

화면을 열어보면 오른쪽 위에 X 버튼이 있는데, 우리는 안 만들었어요. DialogContent가 기본으로 넣어줍니다.

배경도 마찬가지예요. 뒤쪽이 어둡게 깔리고 살짝 흐려지는데, 그것도 DialogContent 안에 들어 있습니다.

이런 게 몇 개나 딸려왔는지는 다음 Step에서 제대로 세어볼게요.

💡 한 줄 정리

Dialog는 여는 버튼과 뜨는 상자를 감싸기만 하면 열림 상태를 알아서 관리하지만, 여는 자리를 정할 때는 그 요소에 이미 붙어 있는 동작과 부딪히지 않는지 봐야 해요.

<DialogPrimitive.Close
  render={<Button variant="ghost" size="icon-sm" />}
>

Step 7: "여섯 줄을 세어본다"

지난 시간 첫머리의 그 목록입니다. 모달 하나 제대로 만들려면 챙길 것들이요.

 모달 하나를 제대로 만들려면

   포커스를 상자 안에 가둔다
   Esc 를 누르면 닫는다
   닫으면 원래 있던 곳으로 포커스를 되돌린다
   뒤쪽 배경은 스크롤을 잠근다
   화면 낭독기에 "지금 대화 상자가 열렸다" 고 알린다
   상자 바깥은 낭독기에서 숨긴다

우리는 이 중 한 줄도 안 짰습니다. 몇 개가 되고 있는지 하나씩 확인해 봅시다. 개발자 도구를 열어두고 모달을 띄운 채로 보면 됩니다.

하나 — 포커스가 상자 안에 갇히나

모달을 연 뒤에 Tab을 계속 눌러 보세요. 뒤쪽 회원가입 폼이나 테마 버튼으로 넘어가지 않고 상자 안에서만 돕니다. 지금 우리 상자 안에 누를 수 있는 건 닫기 버튼 하나뿐이라, 몇 번을 눌러도 거기 머물러요.

딸려옵니다.

둘 — Esc로 닫히나

눌러보면 닫힙니다. 딸려옵니다.

셋 — 닫으면 포커스가 돌아오나

이건 눈으로 보기 어려우니 개발자 도구 콘솔에서 확인해 보세요. 모달을 닫은 직후에 document.activeElement를 찍으면 우리가 눌렀던 "댓글 N개 모두 보기" 버튼이 나옵니다.

키보드로 쓰는 사람에게 이건 아주 중요해요. 안 돌아오면 페이지 맨 처음부터 다시 Tab을 눌러야 하거든요.

딸려옵니다.

넷 — 뒤쪽 스크롤이 잠기나

모달을 띄운 채로 마우스 휠을 굴려 보세요. 뒤쪽 피드가 안 움직입니다. body의 계산된 스타일을 보면 overflow가 hidden으로 바뀌어 있고, 닫으면 원래대로 돌아옵니다.

딸려옵니다.

다섯 — 낭독기에 대화 상자라고 알리나

상자 요소를 개발자 도구에서 보면 이렇게 되어 있습니다.

 role="dialog"
 aria-labelledby="…"     ← DialogTitle 이 연결돼 있다
 aria-describedby="…"    ← DialogDescription 이 연결돼 있다

여는 버튼 쪽에도 붙어 있어요.

 aria-haspopup="dialog"   ← 누르면 대화 상자가 열린다고 미리 알린다
 aria-expanded="false"    ← 열리면 true 로 바뀐다

딸려옵니다.

⚠️ 다만 제가 지난 시간에 적은 이름은 안 나옵니다

지난 시간 목록에 저는 aria-modal이라고 적어뒀습니다. 그런데 상자를 아무리 뒤져도 그 속성이 없어요.

빠뜨린 게 아니라 다른 방법을 쓰고 있는 건데, 그게 여섯 번째 줄이에요.

여섯 — 상자 바깥이 낭독기에서 숨겨지나

모달이 열린 상태에서 우리 앱 전체를 감싸는 요소를 보세요.

 <div id="root" aria-hidden="true">

앱 전체에 "낭독기는 여기 보지 마세요" 표시가 붙습니다. 닫으면 사라지고요.

aria-modal="true"는 "이 상자가 모달이니 바깥은 알아서 무시해줘"라고 부탁하는 방식이고, 지금 이 방식은 바깥을 직접 숨기는 방식입니다. 목표는 같은데 부탁 대신 직접 하는 쪽이에요. 낭독기마다 해석이 조금씩 달라서, 직접 숨기는 쪽이 더 확실하게 동작합니다.

딸려옵니다.

세어보면

 여섯 줄 중 딸려온 것 ── 여섯 개
 우리가 짠 줄        ── 없음

전부입니다. 우리가 쓴 코드는 <Dialog>로 감싸고 <DialogTrigger>와 <DialogContent>를 넣은 게 전부였어요.

⚠️ 그런데 공짜가 아닌 게 하나 있습니다

DialogTitle을 빼고 열어보면 어떻게 될까요. 한번 지워 보세요.

화면은 멀쩡하고, 에러도 안 나고 경고도 없어요. 그런데 상자 요소를 보면 aria-labelledby가 아예 없습니다.

이름 없는 대화 상자가 됩니다. 낭독기가 "대화 상자" 라고만 읽고 무슨 상자인지 말해주지 못해요. 눈으로 보는 사람은 사진과 이름이 다 보이니까 아무 문제를 못 느낍니다.

제목은 딸려오지 않습니다. 우리가 줘야 해요. 그리고 안 줘도 아무도 안 알려줍니다.

⚠️ 그리고 닫기 버튼이 영어였습니다

딸려온 닫기 버튼을 낭독기로 들어보면 "Close"라고 읽습니다. dialog.tsx 안에 그렇게 적혀 있거든요.

우리 화면은 전부 한국어인데 이 버튼만 영어로 읽히는 겁니다. 눈으로 보면 X 아이콘이라 아무 이상이 없어요.

파일이 우리 것이니 고칩니다.

// apps/web-spa/src/components/ui/dialog.tsx
<XIcon />
{/* 우리가 고친 곳: 낭독기가 읽는 이름을 우리말로 */}
<span className="sr-only">닫기</span>

sr-only는 E-1에서 봤던 그 클래스로, 화면에는 안 보이고 낭독기만 읽어요.

이런 건 라이브러리를 탓할 일이 아닙니다. 세계 여러 나라에서 쓰는 라이브러리가 한국어를 미리 넣어둘 수는 없으니까요. 가져다 쓰는 쪽이 자기 언어로 바꾸는 것까지가 도입입니다.

직접 만들었다면

여섯 줄을 우리가 다 짰다면 어땠을지 잠깐 그려볼게요.

하나하나는 어렵지 않습니다. 다만 전부 합치면 하루가 가고, 놓친 자리는 대개 키보드나 낭독기로 써보기 전까지 아무도 모릅니다. 그래서 이 영역은 가져다 쓰는 게 거의 항상 이득이에요.

💡 한 줄 정리

포커스 가두기·Esc·포커스 복귀·스크롤 잠금·역할 알림·바깥 숨김 여섯 가지가 전부 딸려옵니다. 다만 제목과 우리말 표기는 우리 몫이고, 빠뜨려도 아무도 알려주지 않아요.

Step 8: "값을 매긴다"

다 만들었으니 이제 비용과 여파를 봅니다. 오늘 무엇이 늘었고 무엇이 어긋났는지요.

놀고 있던 줄이 일을 시작했습니다

지난 시간에 이 줄을 넣어두고 "지금은 아무 일도 안 한다" 고 했죠.

/* apps/web-spa/src/styles/globals.css */
@custom-variant dark (&:is(.dark *));

우리 화면에 dark:로 시작하는 클래스가 하나도 없었기 때문입니다. 우리는 값만 갈아끼우는 방식을 썼으니까요.

오늘 들여온 파일을 열어보면 이런 게 보입니다.

 button.tsx    dark:hover:bg-muted/50 · dark:border-input · dark:bg-input/30 …   9곳
 avatar.tsx    dark:after:mix-blend-lighten                                       1곳

남의 코드가 그 문법을 쓰고 들어왔어요. 우리는 여전히 한 곳도 안 쓰는데, 우리 화면에는 이제 그 클래스가 있습니다. 지난 시간에 깔아둔 줄이 없었다면 저 클래스들이 아무 일도 못 했을 거예요.

미리 깔아둔 길로 남이 지나간 셈입니다.

⚠️ 밝은 화면에선 같고 어두운 화면에서만 갈립니다

이제 오늘의 진짜 함정입니다.

들여온 카드는 자기 토큰인 bg-card를 쓰고, 우리 회원가입 판은 우리 토큰인 bg-surface를 씁니다. 두 판이 같은 화면에 나란히 있어요.

밝은 화면에서 두 배경색을 재보면 이렇습니다.

 회원가입 판   oklch(1 0 0)
 게시물 카드   oklch(1 0 0)      ← 완전히 같다

둘 다 흰색이라 아무 문제가 없습니다.

어두운 화면으로 바꾸고 다시 재보세요.

 회원가입 판   oklch(0.182 …)    ← 우리가 E-4 에서 고른 값
 게시물 카드   oklch(0.205 …)    ← 들여온 쪽이 고른 값

갈립니다. 같은 화면에 놓인 두 판이 미묘하게 다른 회색이 돼요.

E-5에서 겪은 것과 같은 종류의 함정입니다. 그때는 자동 확인이 통과하는데 화면이 깨져 있었고, 오늘은 밝은 화면에서 멀쩡한데 어두운 화면에서만 어긋납니다. 한 조건에서만 확인하면 못 봅니다.

두 갈래 길

고치는 방법이 두 가지 있어요.

첫째, 카드마다 우리 토큰을 얹는 방법입니다. Step 3에서 배운 cn이 겹치는 걸 정리해주니 잘 됩니다.

<Card className="bg-surface">   {/* bg-card 가 지워지고 bg-surface 가 남는다 */}

되긴 하는데 문제가 있어요. 카드를 쓸 때마다 적어야 하고, 앞으로 들여올 상자·팝업마다 또 적어야 하는 데다가, Step 3에서 본 것처럼 ring과 border는 서로 못 미니까 테두리까지 맞추려면 ring-0도 따라붙어야 해요. 매번 적는 목록이 점점 길어집니다.

둘째, 값을 잇는 방법입니다. 들여온 쪽 토큰이 우리 토큰을 가리키게 하는 거예요.

/* apps/web-spa/src/styles/globals.css */
:root {
  /* 우리가 고친 곳 — 값을 박지 않고 우리 이름을 가리키게 했다.
     "판" 을 뜻하는 셋이 우리 surface 한 곳에서 갈린다. */
  --card: var(--color-surface);
  --card-foreground: var(--color-ink);
  --popover: var(--color-surface);
  --popover-foreground: var(--color-ink);
  --border: var(--color-line);
}

원래 거기에는 oklch(1 0 0) 같은 값이 그대로 적혀 있었는데, 그걸 우리 이름을 가리키는 참조로 바꾸면 재미있는 일이 생깁니다. 들여온 쪽에도 어두운 화면용 블록이 따로 있었는데, 그 다섯 줄이 필요 없어집니다.

.dark {
  --background: oklch(0.145 0 0);
  --foreground: oklch(0.985 0 0);
  /* --card · --card-foreground · --popover · --popover-foreground · --border 는
     여기 없다. 위에서 우리 이름을 가리키게 해뒀고 그 이름이 여기서 이미 갈린다. */
  ...
}

우리 --color-surface가 어두운 화면에서 이미 값을 바꾸니까, 그걸 가리키는 --card도 저절로 따라옵니다. 지워도 되는 거예요.

E-2에서 배운 그 이야기가 여기서 한 번 더 나옵니다. 값과 조건을 갈라 두면 조건은 한 곳에서만 관리하면 됩니다.

고치고 다시 재보면 이렇습니다.

 회원가입 판   oklch(0.182 …)
 게시물 카드   oklch(0.182 …)    ← 같아졌다
 카드 아래선   oklch(0.333 …)    ← 우리 --color-line 을 쓴다

크기는 이렇게 늘었습니다

마지막으로 비용을 보려고, 지난 시간 끝과 오늘 끝을 나란히 놓아 볼게요.

가운데 줄이 이상하죠. 아무 데서도 안 쓰는데 CSS가 두 배 넘게 늘었지만, JS는 한 바이트도 안 늘었어요.

실제로 쓰기 시작한 마지막 줄에서는 반대가 되는데, CSS는 그대로인데 JS가 십만 바이트 늘었어요.

이 엇갈림의 이유는 E-1에서 배운 데 있습니다. Tailwind는 소스 파일의 글자를 훑어서 필요한 CSS를 만들죠. 파일이 src/ 안에 놓이는 순간, 아무도 부르지 않아도 그 안의 클래스 이름이 전부 후보가 됩니다.

JS는 반대로 부르는 관계를 따라갑니다. 아무도 import 하지 않은 파일은 빌드 결과에 안 들어가서, 실제로 써야 늘어납니다.

 CSS   파일이 놓이는 순간 는다        (글자를 훑으니까)
 JS    실제로 불러 써야 는다          (부르는 관계를 따라가니까)

CSS가 마지막에 49 바이트 줄어든 것은 방금 들여온 쪽 어두운 화면 블록에서 다섯 줄을 지웠기 때문이에요.

💡 한 줄 정리

들여온 컴포넌트는 자기 토큰과 자기 다크모드 문법을 갖고 들어옵니다. 우리 토큰과 어긋나는 자리는 매번 덮기보다 값을 이어 한 곳에서 끝내는 게 낫고, 비용은 CSS와 JS가 서로 다른 시점에 늘어납니다.

@source not "../**/*.test.ts*";

마무리

오늘 한 일을 한 줄로 줄이면 이렇습니다. 남이 짠 파일을 열어서 읽고, 두 군데를 고치고, 우리 것과 나란히 세웠습니다.

지난 시간까지 components/ui/는 비어 있었죠. 오늘 그 폴더가 처음으로 일을 했습니다.

오늘 배운 핵심 세 가지

💡 하나 — 복사해 온 파일은 읽으라고 온 것입니다. cva가 변형을 이름으로 고르게 해주고, cn이 겹친 클래스를 정리하고, data-slot이 조각마다 신분을 달아 둡니다. 읽을 줄 알면 고칠 수 있고, 고칠 수 있어야 소유한 값을 해요.

💡 둘 — 눈에 보이는 것만 확인하면 놓칩니다. 카드가 div로 바뀐 것도, 닫기 버튼이 영어로 읽히는 것도, 제목이 빠져 이름 없는 상자가 된 것도 화면으로는 멀쩡했습니다. 색과 여백은 눈으로, 구조와 이름은 개발자 도구로 봐야 해요.

💡 셋 — 어려운 동작은 가져다 쓰는 게 거의 항상 이득입니다. 오늘 여섯 줄이 전부 딸려왔고 우리가 짠 줄은 없었습니다. 대신 내용은 우리 몫이에요. 라이브러리는 우리 화면이 무슨 화면인지 모릅니다.

시작할 때 남아 있던 것

지난 시간에 남겨둔 약속들이 어떻게 닫혔는지 봅시다.

다음 시간 예고

우리 인스타그램은 이제 기능이 다 있어서 좋아요도 되고 댓글도 달리고 모달도 뜨고 다크모드도 되지만, 아직 진짜 인스타그램처럼 보이지는 않습니다. 여백이 조금씩 어색하고, 아이콘 자리에 문자를 쓰고 있고, 좋아요를 눌러도 아무 반응이 없어요.

다음 시간에는 마감을 합니다. 카드가 자기 폭을 보고 스스로 배치를 바꾸는 방법을 배우고, 오늘 함께 딸려온 아이콘 꾸러미를 꺼내 쓰고, 누를 때 살짝 반응하는 움직임을 넣으면서, 오늘 두 군데서 배운 걸 화면 전체에 적용해요. 눈으로 안 보이는 것을 개발자 도구로 훑는 일을요.

과제

[구현] 버튼도 갈아끼우고 충돌을 직접 만들어보기

오늘 button.tsx를 읽기만 하고 안 썼습니다. 실제로 써보면서 Step 2·3에서 본 것을 확인해 보세요.

• 회원가입 폼의 가입 버튼을 들여온 Button으로 바꿔 보세요. 지금 붙어 있는 클래스를 지우고 variant와 size를 골라서요.
• 그 상태에서 className으로 좌우 여백을 넘겨 보세요. 개발자 도구에서 최종 클래스 문자열을 보고, 안쪽 기본값이 사라졌는지 확인해 주세요.
• 이번엔 cn을 거치지 않으면 어떻게 되는지 보고 싶습니다. button.tsx에서 cn(...)을 잠깐 벗겨내고 클래스 문자열이 어떻게 달라지는지, 화면의 여백은 어느 쪽을 따르는지 재 보세요. 확인한 뒤에는 되돌립니다.
• variant에 없는 이름을 적어보고 편집기가 언제 알려주는지도 확인해 주세요.

[구현] 이름 없는 대화 상자 만들어보기

Step 7에서 제목이 딸려오지 않는다고 했죠. 직접 겪어보면 오래 남습니다.

• 게시물 머리의 ⋯ 버튼에 대화 상자를 하나 새로 붙여 보세요. 안에는 "이 게시물 신고하기" 같은 항목 두어 개면 됩니다.
• 먼저 DialogTitle 없이 만들고 열어 보세요. 개발자 도구에서 상자 요소의 속성을 확인하고, 무엇이 없는지 적어 주세요.
• 그다음 제목을 넣고 다시 확인해 주세요. 무엇이 생겼나요.
• 제목을 화면에 보이고 싶지 않다면 어떻게 해야 할까요. 오늘 닫기 버튼을 고칠 때 쓴 클래스가 힌트입니다.
• 마지막으로 마우스를 치우고 키보드만으로 열고 닫아 보세요. Tab · Enter · Esc만 씁니다. 이상한 자리가 있었다면 적어 주세요.

[탐구] 덮어쓰기와 값 잇기

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

• npx shadcn@latest add avatar --diff를 실행해 보세요. 우리가 안 고친 파일입니다. 결과가 어떻게 나오는지 적고, CLI가 무엇을 기준으로 판단하는지 말해 보세요.
• card.tsx에 아무 주석이나 한 줄 넣고 다시 --diff를 보세요. 우리 수정이 어떻게 보이는지 확인해 주세요.
• Step 8에서 이어둔 --card를 원래 값 oklch(1 0 0)으로 되돌리고, 들여온 쪽 어두운 화면 블록에도 --card를 다시 적어 보세요. 두 판의 색을 다시 재서 어긋나는 걸 확인하고 되돌립니다.
• --input은 아직 안 이었습니다. 이 토큰이 우리 화면 어디에 쓰이고 있는지 찾아보고, 이어야 할지 그대로 둬도 될지 판단해 주세요.

생각해볼 주제

1. 남의 파일을 어디까지 고쳐도 될까요

오늘 우리는 들여온 파일 두 곳을 고쳤습니다. 태그 하나와 글자 하나요. 둘 다 이유가 분명했지만, 고치기 시작하면 끝이 잘 안 보입니다. 여백이 마음에 안 들고, 변수 이름이 우리 규칙과 다르고, 안 쓰는 변형이 여섯 개나 있고요. 하나씩 손대다 보면 어느새 원본과 완전히 다른 파일이 됩니다.

어디까지가 "고치는 것"이고 어디부터가 "다시 쓰는 것"인지, 그 선을 팀에서 어떻게 합의하고 남겨둘 수 있을지도 함께 생각해 보세요.

2. 눈에 안 보이는 것을 어떻게 지킬까요

오늘 카드가 div로 바뀐 것을 화면으로는 알 수 없었습니다. 닫기 버튼이 영어로 읽히는 것도, 제목이 없어 이름 없는 상자가 된 것도 그랬어요.

이런 것들은 대개 시간이 한참 지난 뒤에 발견됩니다. 발견되는 계기도 대개 누군가 불편을 겪은 다음이고요.

미리 알아채려면 무엇을 해야 할까요. 사람이 주기적으로 훑는 방법도 있고, 자동으로 검사하는 도구를 붙이는 방법도 있습니다. 각각 무엇을 잡을 수 있고 무엇을 못 잡을지, 그리고 우리 규모에서는 어디까지가 적당할지 생각해 보세요.

3. 딸려오는 것에 기대는 것은 어디까지 안전할까요

오늘 우리는 여섯 가지를 공짜로 얻었습니다. 우리가 짠 줄은 하나도 없었어요.

편했지만 한 가지 사실도 함께 생겼는데, 이제 우리 모달의 접근성은 우리가 이해하지 못한 코드가 책임지고 있어요. 그 라이브러리가 방향을 바꾸거나 관리가 멈추면 우리도 함께 멈춥니다.

이런 의존을 판단하는 기준은 무엇일지, 그리고 만약 그 라이브러리를 걷어내야 하는 날이 온다면 오늘의 선택 중 무엇이 그때 우리를 도와주고 무엇이 발목을 잡을지 생각해 보세요.