A-6: 제네릭 컴포넌트와 타입 설정 — 꺾쇠를 직접 만들고, 검사를 켠다

안녕하세요, 홍순구입니다. 지난 시간 마무리에서 제가 이런 말을 했죠. 여러분이 지금까지 쓴 꺾쇠는 전부 남이 만들어둔 것에 타입을 넣은 것이었다고요.

Pick<Post, 'id' | 'imageUrl' | 'mediaKind'> 도, useState<string | null> 도 그랬습니다. 누군가 꺾쇠 자리를 만들어뒀고 우리는 거기 타입을 넣기만 했어요. 오늘은 그 자리를 직접 만듭니다.

만들고 나면 바로 쓸 데가 있습니다. CommentList 와 Feed 를 열어놓고 나란히 보세요. 목록을 받아서, 하나씩 그리고, key 를 붙입니다. 똑같은 일을 두 번 적어놨어요. 담기는 것이 댓글이냐 게시물이냐만 다릅니다.

그리고 수업 후반에는 조금 서늘한 이야기를 합니다. 지금까지 여러분이 돌린 npm run dev 는 타입을 한 번도 검사한 적이 없습니다. 에디터에 빨간 줄이 그어져 있어도 화면은 멀쩡히 떴어요. 왜 그런지, 그럼 검사는 누가 언제 하는지 오늘 확인합니다.

 오늘의 여정

 Step 1   타입 매개변수를 직접 만든다 · 아무거나 받지 않게 제약을 건다
    │
 Step 2   제네릭 컴포넌트 List<T> · 댓글 목록과 피드를 하나로
    │
 Step 3   남이 만든 컴포넌트의 props 를 물려받는다
    │
 Step 4   tsconfig.json 을 한 줄씩 읽는다
    │
 Step 5   번들러는 타입을 검사하지 않는다
    ▼
 중복이 걷히고 검사가 켜진 인스타 피드

💡 오늘 수업의 핵심 — "타입을 재료로 받으면 코드가 하나로 합쳐진다"

값을 매개변수로 받으면 함수 하나로 여러 값을 다루죠. 타입도 똑같이 매개변수로 받을 수 있습니다. 그러면 하는 일이 같고 타입만 다른 코드가 하나로 합쳐집니다.

🎯 학습 목표

• 타입 매개변수를 직접 선언하고, extends 로 받을 수 있는 타입을 제한할 수 있다
• 어떤 타입의 목록이든 그리는 제네릭 컴포넌트를 만들고, .tsx 에서 주의할 곳을 안다
• tsconfig.json 의 핵심 옵션을 읽고, 타입 검사가 언제 누구에 의해 도는지 설명할 수 있다

Step 1: "타입도 매개변수로 받을 수 있습니다"

지난 시간에 만든 리듀서 두 개를 나란히 놓고 보겠습니다. 각각에서 한 줄씩만 뽑았어요.

// 피드 리듀서 — 번호로 게시물 하나 찾기
const target = state.posts.find((post) => post.id === action.id);

// 댓글 리듀서 — 번호로 댓글 하나 빼기
items: state.items.filter((item) => item.id !== action.id),

하는 일이 똑같습니다. 번호를 받아서 그 번호를 가진 항목을 찾거나 뺍니다. 다른 건 담긴 것이 게시물이냐 댓글이냐 뿐이에요.

값 매개변수는 이미 알고 있습니다

함수를 만드는 이유를 떠올려보면 답이 보입니다.

 이렇게 두 번 적는 대신                     이렇게 한 번 적고

   1240 * 2                                function double(n: number) {
   8500 * 2                                  return n * 2;
                                            }

   → 달라지는 값을 매개변수로 뽑는다        → double(1240) · double(8500)

달라지는 것이 값이면 값 매개변수로 뽑습니다. 그런데 지금 우리 경우엔 달라지는 것이 값이 아니라 타입이에요. 그러면 타입을 매개변수로 뽑으면 됩니다.

타입 매개변수 만들기

이름 옆에 꺾쇠를 열고 이름을 하나 적으면 그게 타입 매개변수입니다.

// apps/web-spa/src/lib/collections.ts
export function findById<T extends { id: number }>(items: T[], id: number): T | undefined {
  return items.find((item) => item.id === id);
}

<T> 부분이 새로 생긴 것이고 나머지는 평범한 함수입니다. 읽는 법은 이래요.

 findById <T extends { id: number }> (items: T[], id: number): T | undefined
           └──────┬──────┘  └───┬───┘        └┬┘             └────┬────┘
                  │             │             │                   │
           타입 매개변수      받을 수 있는    T 가 담긴 배열     찾으면 T,
           이름은 T          타입의 조건                        없으면 undefined

T 는 그냥 이름입니다. Item 이라고 해도 되고 Post 라고 해도 돼요. 관습적으로 짧게 T 를 씁니다. 값 매개변수에 n 이나 x 를 쓰는 것과 같습니다.

중요한 건 부르는 쪽이 T 를 안 적어도 된다는 겁니다.

findById(feedPosts, 2)   // T 가 Post 로 정해진다 — 돌려주는 것도 Post | undefined
findById(comments, 1)    // T 가 DraftComment 로 정해진다

넘긴 배열을 보고 TypeScript 가 알아서 정합니다. 지난 시간에 배운 추론이 여기서도 그대로 도는 거예요.

왜 extends { id: number } 를 붙였을까

제약을 빼고 그냥 <T> 로만 써보면 알 수 있습니다.

export function findByIdUnconstrained<T>(items: T[], id: number): T | undefined {
  return items.find((item) => item.id === id);
}

Property 'id' does not exist on type 'T'.

당연한 말입니다. T 는 "나중에 정해질 무언가" 인데, 아직 뭔지 모르니 id 가 있는지도 알 수 없어요. 모르는 것의 속을 들여다보려 하면 막힙니다.

extends { id: number } 는 여기에 대한 약속입니다. "아무거나 다 받지는 않겠다. id 를 가진 것만 받겠다" 는 뜻이에요. 조건을 걸었으니 그 안에서는 id 를 꺼내 써도 됩니다.

약속을 어긴 걸 넘기면 부르는 쪽에서 걸립니다.

const tags = [{ name: '한강' }, { name: '노을' }];

findById(tags, 1);

Argument of type '{ name: string; }[]' is not assignable to parameter of type '{ id: number; }[]'.
  Property 'id' is missing in type '{ name: string; }' but required in type '{ id: number; }'

무엇이 모자란지 정확히 말해줍니다.

any 와 무엇이 다른가

"그냥 any[] 로 받으면 되지 않나요?" 하는 생각이 들 수 있습니다. 실제로 에러는 안 나요.

 any 로 받으면                          제네릭으로 받으면

 findById(feedPosts, 2)                 findById(feedPosts, 2)
     → any                                  → Post | undefined
        │                                       │
   .usernme 오타도 통과                   .usernme 는 곧바로 막힘
   .liked 자동완성 없음                   .liked 자동완성 나옴

any 는 검사를 끄는 것이고 제네릭은 검사를 미루는 것입니다. any 를 쓰면 그 뒤로 타입이 사라지지만, 제네릭은 부르는 순간 구체적인 타입으로 되살아나요. 넣은 것이 게시물이면 나오는 것도 게시물입니다.

두 리듀서에 적용하기

이제 지난 시간 코드에서 중복이 걷힙니다.

// apps/web-spa/src/lib/feed-state.ts
      const target = findById(state.posts, action.id);

// apps/web-spa/src/lib/comments.ts
        items: removeById(state.items, action.id),

각자 다른 타입을 다루는데 같은 함수를 씁니다. 그리고 target 은 여전히 Post 라서 target.username 을 그대로 꺼낼 수 있어요.

💡 한 줄 정리

달라지는 것이 값이면 값 매개변수로, 타입이면 타입 매개변수로 뽑습니다. extends 로 조건을 걸면 그 안에서는 조건에 적힌 것을 꺼내 쓸 수 있고, any 와 달리 부르는 쪽의 타입이 그대로 살아 돌아옵니다.

Step 2: "어떤 타입의 목록이든 그리는 컴포넌트"

함수에 타입 매개변수를 붙였으니 컴포넌트에도 붙일 수 있습니다. 컴포넌트도 결국 함수니까요.

먼저 우리가 없애려는 중복을 정확히 보겠습니다.

 CommentList 가 하는 일              Feed 가 하는 일

 댓글 배열을 받는다                  게시물 배열을 받는다
 하나씩 돈다                         하나씩 돈다
 key 를 붙인다                       key 를 붙인다
 한 줄을 그린다                      카드 하나를 그린다
       │                                   │
       └───────── 다른 건 딱 두 가지 ──────┘
                  담기는 타입 · 한 줄을 그리는 방법

두 가지가 다르니, 그 두 가지를 밖에서 받으면 됩니다. 타입은 타입 매개변수로, 그리는 방법은 함수 props 로.

List 만들기

// apps/web-spa/src/components/List.tsx

// 담기는 것의 타입은 쓰는 쪽이 정한다 — 여기서는 T 라는 이름으로만 비워둔다.
// 다만 아무것이나 받지는 않는다. key 로 쓸 id 가 있어야 한다.
interface ListProps<T extends { id: number }> {
  items: T[];
  // 한 줄을 어떻게 그릴지는 쓰는 쪽이 알려준다
  renderItem: (item: T) => React.ReactNode;
  className?: string;
  // 화면 읽어주는 도구에 이 목록이 무엇인지 알려준다
  'aria-label'?: string;
}

export function List<T extends { id: number }>({
  items,
  renderItem,
  className,
  'aria-label': ariaLabel,
}: ListProps<T>) {
  return (
    <ul className={className} aria-label={ariaLabel}>
      {items.map((item) => (
        <li key={item.id}>{renderItem(item)}</li>
      ))}
    </ul>
  );
}

interface ListProps<T ...> 처럼 인터페이스에도 타입 매개변수를 붙일 수 있습니다. A-3 에서 쓰던 Pick<...> 이 이런 식으로 만들어진 거예요. 이제 그 안쪽이 어떻게 생겼는지 보이시죠.

renderItem: (item: T) => React.ReactNode 이 오늘의 요령입니다. 한 줄을 어떻게 그릴지는 List 가 모릅니다. 몰라도 되고요. 그건 쓰는 쪽이 넘겨줍니다.

extends { id: number } 를 여기도 건 이유는 key={item.id} 때문입니다. B-2 에서 key 에 index 를 썼다가 항목을 지웠을 때 상태가 옆줄로 옮겨간 것 기억하시죠. 그래서 id 를 요구하고, 요구했으니 안심하고 꺼내 씁니다.

댓글 목록에 적용하기

// apps/web-spa/src/components/CommentList.tsx
export function CommentList({ comments, onRemove }: CommentListProps) {
  return (
    <List
      items={comments}
      className="comment-list"
      renderItem={(comment) => (
        <>
          <strong>me</strong> {comment.content}
          {onRemove && (
            <IconButton
              className="comment-remove"
              aria-label="댓글 삭제"
              onClick={() => onRemove(comment.id)}
            >
              ×
            </IconButton>
          )}
        </>
      )}
    />
  );
}

<ul> 과 <li> 와 key 가 사라졌습니다. 그건 List 가 하니까요. CommentList 에는 한 줄이 어떻게 생겼는지만 남았습니다.

여기서 눈여겨볼 곳이 있어요. renderItem={(comment) => ...} 의 comment 에 타입을 안 적었는데 comment.content 가 통합니다. items={comments} 에서 T 가 DraftComment 로 정해졌고, 그게 renderItem 까지 흘러온 거예요.

없는 필드를 꺼내보면 확인됩니다.

Property 'username' does not exist on type 'DraftComment'.

comment 가 진짜로 DraftComment 라는 걸 TypeScript 가 알고 있습니다.

피드에도 그대로

// apps/web-spa/src/components/Feed.tsx
export function Feed({ posts, onToggleLike }: FeedProps) {
  return (
    <List
      items={posts}
      className="feed-list"
      aria-label="피드 목록"
      renderItem={(post) => <PostCard {...post} onToggleLike={onToggleLike} />}
    />
  );
}

같은 List 인데 이번엔 게시물이 담깁니다. 지난 시간까지 두 파일에 나뉘어 있던 "줄줄이 그리기" 가 한 곳으로 모였어요.

덤도 하나 생겼습니다. 피드가 이제 진짜 목록(<ul>)이 되어서, 화면을 읽어주는 도구가 "목록, 항목 2개" 라고 알려줍니다. 예전엔 카드가 그냥 나열돼 있어서 그런 안내가 없었어요.

⚠️ .tsx 에서 딱 한 곳 조심할 것

제네릭을 화살표 함수로 쓸 때, 그것도 제약을 안 걸었을 때 함정이 있습니다.

const List = <T>({ items }: ListProps<T>) => {

JSX element 'T' has no corresponding closing tag.

.tsx 파일에서 <T> 는 파서 입장에서 <div> 와 구별이 안 됩니다. 그래서 JSX 태그로 읽고 "닫는 태그가 없다" 고 하는 거예요.

해결은 쉼표 하나입니다. <T,> 라고 쓰면 태그일 수 없는 모양이 되니 타입 매개변수로 읽힙니다.

const List = <T,>({ items }: ListProps<T>) => {

그런데 여기서 한 걸음 더 들어가면 재밌는 게 있습니다. 제약을 걸면 쉼표가 필요 없어요.

const List = <T extends { id: number }>({ items }: ListProps<T>) => {

이건 그냥 통과합니다. <T extends 까지 읽는 순간 파서가 "JSX 태그에는 extends 가 올 수 없다" 는 걸 알거든요. 헷갈릴 여지가 사라지는 겁니다.

정리하면 이렇습니다.

 .tsx 에서 제네릭을 쓸 때

 function List<T>(...)                    안전 — function 뒤는 태그일 수 없다
 function List<T extends {...}>(...)      안전

 const List = <T>(...) =>                 ⚠️ TS17008 — 태그로 읽힌다
 const List = <T,>(...) =>                안전 — 쉼표가 태그 가능성을 없앤다
 const List = <T extends {...}>(...) =>   안전 — extends 가 태그 가능성을 없앤다

우리 코드는 위 두 줄 다 해당합니다. function 선언이고 제약도 걸었으니 애초에 걸릴 일이 없어요.

다른 사람 코드에서 <T,> 라는 어색한 쉼표를 보면 "아, 화살표로 쓰면서 제약을 안 걸었구나" 하고 알아보시면 됩니다.

💡 한 줄 정리

컴포넌트도 함수라 타입 매개변수를 붙일 수 있습니다. 타입은 <T> 로, 달라지는 동작은 함수 props 로 받으면 하는 일이 같은 목록 컴포넌트가 하나로 합쳐집니다.

Step 3: "남이 만든 컴포넌트의 props 를 물려받기"

우리 화면에 글자 없이 기호만 있는 버튼이 두 개 있습니다. 게시물 머리의 ⋯ 와 댓글 옆의 × 요.

이런 버튼은 화면을 읽어주는 도구에 문제가 됩니다. ⋯ 를 읽어봐야 사용자는 무슨 버튼인지 모르니까요. 그래서 B-3 에서 Button 에 aria-label 을 넣어뒀습니다.

// apps/web-spa/src/components/Button.tsx (B-3 시절)
  // 글자 대신 기호만 보이는 버튼은 읽어줄 이름을 따로 준다
  'aria-label'?: string;

물음표가 붙어 있죠. 안 넘겨도 됩니다. 글자가 있는 버튼은 필요 없으니까요.

문제는 기호만 있는 버튼에서도 안 넘겨도 통과한다는 겁니다. 깜빡하면 그대로 나갑니다. 화면에는 아무 문제가 없어 보여서 눈으로는 못 잡아요.

물려받아서 좁히기

aria-label 이 필수인 버튼을 따로 만들면 됩니다. 그런데 Button 의 props 를 전부 다시 적어야 할까요?

// 이렇게 베껴 적으면?
interface IconButtonProps {
  children: React.ReactNode;
  onClick?: () => void;
  disabled?: boolean;
  type?: 'button' | 'submit';
  className?: string;
  'aria-label': string;
}

동작은 합니다. 그런데 나중에 Button 에 props 를 하나 더하면 여기도 더해야 해요. 안 더하면 두 개가 조용히 어긋납니다. A-3 에서 배운 그 문제예요. 같은 것을 두 곳에 적으면 반드시 갈라집니다.

그래서 베끼는 대신 물려받습니다.

// apps/web-spa/src/components/IconButton.tsx
import type { ComponentProps } from 'react';
import { Button } from './Button';

// Button 이 받는 props 를 그대로 물려받는다. 여기에 다시 적지 않는다.
// 다만 글자 대신 기호만 보이는 버튼이라, 읽어줄 이름은 있으면 좋은 게 아니라 필수다.
type IconButtonProps = ComponentProps<typeof Button> & {
  'aria-label': string;
};

// 하는 일이 거의 없다. 타입 한 곳을 좁히는 것이 이 컴포넌트의 존재 이유다.
export function IconButton(props: IconButtonProps) {
  return <Button {...props} />;
}

ComponentProps<typeof Button> 을 읽어봅시다. "Button 이라는 컴포넌트가 받는 props 의 타입" 이에요.

typeof 가 또 나왔습니다. A-3 에서 ReturnType<typeof toCardView> 를 쓸 때 설명했죠. 꺾쇠 안은 타입을 적는 칸인데 Button 은 값이라서, typeof 로 "이 값의 타입" 이라고 바꿔주는 겁니다.

그다음 & { 'aria-label': string } 로 물음표 없는 버전을 덮어씁니다. 원래 있던 옵셔널 자리를 필수로 바꾸는 거예요.

정말 좁혀졌는지 확인

aria-label 을 빼고 써보면 걸립니다.

Property ''aria-label'' is missing in type '{ children: string; }' but required in type '{ 'aria-label': string; }'.

같은 자리에서 Button 을 썼다면 그냥 통과했을 겁니다. 깜빡할 수 있던 것이 깜빡할 수 없는 것으로 바뀌었어요.

물려받은 것도 그대로 살아 있는지 볼까요. Button 에 없는 props 를 넣어보면요.

<IconButton aria-label="닫기" href="/home">×</IconButton>

Property 'href' does not exist on type 'IntrinsicAttributes & ButtonProps & { 'aria-label': string; }'.

에러 메시지에 ButtonProps 라는 이름이 그대로 보입니다. 우리가 베껴 적지 않았는데도 TypeScript 는 이게 Button 의 props 라는 걸 알고 있어요. ComponentProps 가 진짜로 물려받은 거죠.

이제 두 버튼을 갈아끼웁니다.

// apps/web-spa/src/components/PostHeader.tsx
      <IconButton className="post-more" aria-label="게시물 메뉴">
        ⋯
      </IconButton>

💡 한 줄 정리

ComponentProps<typeof X> 로 다른 컴포넌트의 props 타입을 꺼내 쓸 수 있습니다. 베껴 적지 않으니 원본이 바뀌어도 따라오고, 교차 타입으로 일부만 좁혀 "깜빡할 수 없게" 만들 수 있습니다.

Step 4: "tsconfig.json 을 읽어봅시다"

A-1 에서 프로젝트를 시작할 때 tsconfig.json 을 만들었습니다. 그때는 "일단 이렇게 두세요" 하고 넘어갔죠. 이제 읽을 준비가 됐습니다.

// apps/web-spa/tsconfig.json
{
  "compilerOptions": {
    "target": "es2025",
    "lib": ["es2025", "dom", "dom.iterable"],
    "module": "esnext",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "strict": true,
    "noEmit": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    "types": ["vitest/globals", "vite/client"]
  },
  "include": ["src", "vite.config.ts", "vitest.config.ts"]
}

한꺼번에 보면 많아 보이는데, 성격별로 묶으면 네 덩어리입니다.

 ① 어떤 자바스크립트를 쓸 건가      target · lib

 ② 모듈을 어떻게 찾을 건가          module · moduleResolution · esModuleInterop
                                    resolveJsonModule

 ③ 얼마나 엄격하게 볼 건가          strict · skipLibCheck

 ④ 번들러와 어떻게 손발을 맞출 건가  jsx · noEmit · isolatedModules
                                    verbatimModuleSyntax · types

① 어떤 자바스크립트를 쓸 건가

target: "es2025" 는 "우리는 2025년 문법까지 쓴다" 는 선언입니다. 옛날 브라우저를 신경 쓰던 시절엔 이걸 낮춰 잡았는데, 지금은 그럴 일이 거의 없어요.

lib 은 어떤 기능이 이미 있다고 칠 것인가입니다. dom 을 넣었으니 document 나 window 를 아는 거예요. 지난 시간 useScrollRestore 에서 window.scrollY 를 썼는데 아무 설정 없이 통했죠. lib 에 dom 이 있어서였습니다.

② 모듈을 어떻게 찾을 건가

moduleResolution: "bundler" 가 요즘 방식입니다. 예전에는 Node.js 가 파일을 찾는 규칙을 그대로 흉내 냈는데, 그러면 import { Button } from './Button' 처럼 확장자를 뺀 import 를 쓸 수 없었어요. 번들러는 확장자를 알아서 찾아주니 그 사실을 TypeScript 에도 알려주는 설정입니다.

③ 얼마나 엄격하게 볼 건가

strict: true 가 오늘까지 배운 거의 모든 검사의 스위치입니다. 지난 시간의 possibly 'null' 도, A-4 의 implicitly has an 'any' type 도 전부 이게 켜져 있어서 나왔어요.

여기서 알아둘 게 있습니다. 요즘 TypeScript 는 이걸 안 적어도 켜져 있습니다. 버전별로 재보면 이렇게 갈려요.

 빈 설정 { } 로 같은 파일을 검사하면

 TypeScript 5.9      에러 0 건      ← 아무것도 안 잡아준다
 TypeScript 6.0      에러 2 건      ← 여기서 기본값이 바뀌었다
 TypeScript 7.0      에러 2 건

6.0 부터 기본이 됐습니다. 그러니 우리 설정의 "strict": true 는 지금 버전에선 없어도 그만이에요.

그래도 적어두는 편이 낫습니다. 읽는 사람이 설정만 보고 "이 프로젝트는 엄격하다" 를 알 수 있고, 누가 실수로 끄면 눈에 띄니까요.

옛날 프로젝트를 열었을 때 tsconfig.json 에 strict: true 가 큼직하게 적혀 있다면, 그건 그 시절엔 기본이 아니었기 때문입니다.

④ 번들러와 손발 맞추기

noEmit: true 는 "자바스크립트 파일을 만들지 마라" 는 뜻입니다. 이상하게 들리죠. TypeScript 컴파일러인데 결과물을 만들지 말라니요.

실제로 파일을 만드는 건 Vite 입니다. TypeScript 는 검사만 맡아요. 역할이 나뉜 겁니다.

isolatedModules 와 verbatimModuleSyntax 는 그 분업에서 나온 규칙입니다. A-3 에서 import type 을 쓰라고 했던 이유가 verbatimModuleSyntax 였어요. 번들러는 파일을 하나씩 따로 변환하기 때문에, 그 파일만 보고 "이 import 는 타입이라 지워도 된다" 를 알 수 있어야 합니다. 그래서 우리가 type 이라고 직접 표시해주는 거예요.

그러니까 이 네 번째 묶음은 전부 "우리는 번들러와 함께 쓴다" 는 사실에서 나옵니다.

그런데 방금 한 말에 이상한 데가 있습니다. TypeScript 는 검사만 하고 Vite 가 파일을 만든다고 했는데, 그럼 Vite 는 검사를 안 한다는 뜻일까요?

💡 한 줄 정리

tsconfig.json 은 어떤 자바스크립트를 쓸지, 모듈을 어떻게 찾을지, 얼마나 엄격할지, 번들러와 어떻게 나눠 일할지 네 가지를 정합니다. strict 는 6.0 부터 기본으로 켜져 있습니다.

Step 5: "번들러는 타입을 검사하지 않습니다"

Step 4 끝의 질문으로 돌아옵니다. 직접 해보는 게 빠릅니다.

Toast 컴포넌트에 말이 안 되는 줄을 하나 넣어보세요. 문자열을 숫자에 담는 겁니다.

// apps/web-spa/src/components/Toast.tsx (확인용으로 잠깐 넣는 줄 — 곧 지웁니다)
export function Toast({ message }: ToastProps) {
  const wrong: number = message;

에디터에 빨간 줄이 그어집니다. 명백한 타입 오류예요. 이 상태로 빌드해봅시다.

npx vite build

dist/assets/index-Cex0Dy17.js   202.37 kB │ gzip: 64.29 kB

✓ built in 266ms

성공했습니다. 빨간 줄이 그어진 코드가 아무 일 없이 빌드돼서 나왔어요.

같은 코드에 타입 검사를 돌려보면요.

npx tsc --noEmit

src/components/Toast.tsx(10,9): error TS2322: Type 'string' is not assignable to type 'number'.

이쪽은 잡습니다. 같은 코드인데 한쪽은 통과하고 한쪽은 막았어요.

왜 이렇게 되나

번들러가 타입을 다루는 방식이 원인입니다.

 번들러가 .tsx 파일을 만났을 때

   const wrong: number = message;
                └──┬──┘
                   │
            타입 표기를 그냥 지운다
                   │
                   ▼
   const wrong = message;          → 문법적으로 멀쩡한 자바스크립트
                                      브라우저는 잘 돌린다

번들러는 타입 표기를 지우기만 합니다. 맞는지 따지지 않아요. 지우고 나면 평범한 자바스크립트고, 그건 실행에 아무 문제가 없습니다.

왜 안 따질까요. 빠르려고요. 타입 검사는 프로젝트 전체를 훑어야 합니다. 파일 하나를 고칠 때마다 그걸 다 하면 개발 서버가 느려터집니다. 그래서 번들러는 지우기만 하고, 검사는 따로 떼어냈어요.

 npm run dev      → Vite 만 돈다             → 타입 검사 없음. 빠르다
 npx tsc --noEmit → TypeScript 만 돈다        → 검사만. 파일은 안 만든다

noEmit: true 의 정체가 이겁니다. 검사 전담이라는 뜻이었어요.

그럼 언제 검사하나

우리 package.json 을 보면 답이 있습니다.

// apps/web-spa/package.json
  "scripts": {
    "dev": "vite",
    "build": "tsc --noEmit && vite build",
    "preview": "vite preview",
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run"
  }

build 를 보세요. tsc --noEmit && vite build 입니다. && 는 앞이 성공해야 뒤가 돈다는 뜻이에요. 타입 검사를 통과 못 하면 빌드가 아예 시작되지 않습니다.

그러니까 실무에서 타입 검사는 이렇게 세 겹으로 돕니다.

 ① 코드 쓰는 동안   에디터가 실시간으로     → 빨간 줄
 ② 빌드할 때        tsc --noEmit &&        → 통과 못 하면 배포 못 함
 ③ 팀에 올릴 때     CI 에서 같은 명령       → 남의 실수도 막힘

①은 눈으로 보는 것이라 끌 수 있습니다. 급하면 무시하고 넘어가지죠. 그래서 ②·③이 필요합니다. 사람이 안 보고 지나쳐도 기계가 막아줘요.

여기서 오늘 수업이 한 바퀴 돌아 만납니다. Step 1~3 에서 우리가 공들여 붙인 타입들, 제네릭 제약이며 필수 aria-label 이며 — 그게 실제로 사람을 막아주려면 검사가 어딘가에서 돌아야 합니다. 에디터의 빨간 줄만으로는 부족해요.

확인이 끝났으면 Toast 에 넣은 줄은 지워주세요.

💡 한 줄 정리

번들러는 타입 표기를 지우기만 하고 맞는지 따지지 않습니다. 빠르기 위한 분업이라, 검사는 tsc --noEmit 으로 따로 돌려야 하고 그래서 build 스크립트가 두 단계로 되어 있습니다.

마무리

오늘 배운 것을 한 줄로 줄이면 이렇습니다. 타입은 재료로도 쓰이고, 켜둬야 일한다.

앞의 세 Step 은 타입을 재료로 넘기는 법이었습니다. 값 대신 타입을 매개변수로 받으니 중복이 걷혔죠. 뒤의 두 Step 은 그렇게 붙인 타입이 실제로 일하게 만드는 설정 이야기였고요.

오늘 배운 핵심 세 가지

💡 하나 — 달라지는 것이 타입이면 타입을 매개변수로 뽑습니다. extends 로 조건을 걸면 그 안에서 조건에 적힌 것을 꺼내 쓸 수 있어요. any 는 검사를 끄지만 제네릭은 검사를 미룰 뿐이라, 부르는 순간 구체적인 타입이 되살아납니다.

💡 둘 — 컴포넌트도 함수라 타입 매개변수를 붙일 수 있습니다. 타입은 <T> 로, 달라지는 동작은 함수 props 로 받으면 CommentList 와 Feed 처럼 하는 일이 같은 것들이 하나로 합쳐집니다. 다른 컴포넌트의 props 는 ComponentProps<typeof X> 로 물려받고요.

💡 셋 — 번들러는 타입을 검사하지 않습니다. 타입 표기를 지우기만 해요. 그래서 tsc --noEmit 을 빌드 앞에 세워둡니다. 우리가 붙인 타입은 검사가 돌아야 비로소 사람을 막아줍니다.

다음 시간 예고

오늘로 TypeScript 카테고리가 끝났습니다. A-1 에서 타입을 처음 선언한 것부터 오늘 설정까지, 여섯 번에 걸쳐 가드레일을 붙였어요.

다음 시간에는 다시 화면으로 돌아갑니다. 폼을 다뤄요.

사실 우리는 이미 폼을 하나 만들었습니다. 댓글 입력창이요. 그런데 그 폼이 하는 검증이 뭐였는지 떠올려보세요. content.trim() === '' 로 빈 값만 막았습니다. 그게 전부예요.

회원가입 폼이라면 어떨까요. 이메일 모양이 맞는지, 비밀번호가 여덟 자를 넘는지, 비밀번호 확인이 일치하는지. 필드마다 규칙이 있고, 틀리면 그 필드 밑에 메시지가 떠야 하고, 사용자가 고치면 메시지가 사라져야 합니다. 이걸 useState 로 하나씩 만들면 어떻게 될지 상상해보세요.

그리고 오늘 이야기와 이어지는 문제가 하나 더 있습니다. 타입은 검사가 개발 중에만 돕니다. 배포된 앱에는 타입이 남아 있지 않아요. 그런데 서버가 이상한 응답을 보내면 그건 실행 중에 벌어지는 일이죠. 실행 중에도 확인하려면 어떻게 해야 할까요.

이 두 문제는 다음 두 번의 수업에 걸쳐 풉니다. 먼저 폼을 제대로 다루는 도구를 만나고, 그다음 시간에 실행 중에도 도는 검사를 붙일 거예요.

과제

[구현] 해시태그 목록을 제네릭 List 로

게시물마다 해시태그가 달려 있는데 지금은 화면에 안 보입니다. 오늘 만든 List 를 써서 붙여봅시다.

• Post 타입에 이미 hashtagNames: string[] 이 있습니다. A-1 에서 선언해뒀어요. 값은 feedPosts 에 들어 있습니다.
• apps/web-spa/src/components/HashtagList.tsx 를 만들고, List 를 써서 해시태그를 줄줄이 그려 주세요. 각 태그는 #한강 처럼 앞에 # 을 붙입니다.
• 여기서 문제가 하나 생깁니다. hashtagNames 는 문자열 배열인데 List 는 id 가 있는 것만 받죠. 곧바로 넘기면 에러가 납니다. 그 에러 메시지를 먼저 적어 두세요.
• 해결 방법은 여러 가지입니다. 하나 골라서 구현하고, 왜 그걸 골랐는지 두세 줄로 적어 주세요. 다른 방법을 안 고른 이유도 함께요.
• PostBody 의 캡션 아래에 해시태그 목록을 넣어 주세요. 태그가 없는 게시물도 있을 수 있으니 그때는 목록 자체를 안 그리는 편이 낫습니다.
• 스타일은 자유입니다. 가로로 나열되게 하고 싶으면 .hashtag-list 에 display: flex 를 주면 됩니다.

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

[탐구] 검사가 언제 도는지 직접 확인하기

Step 5 에서 본 것을 손으로 확인해 봅시다. 각 단계에서 무슨 일이 일어났는지 한두 줄씩 적어 주세요. 확인이 끝나면 전부 원래대로 되돌립니다.

• Avatar 컴포넌트의 username 을 쓰는 곳에서 오타를 내보세요. usernme 처럼요. 에디터가 뭐라고 하나요?
• 그 상태로 npm run dev 를 띄우고 브라우저를 열어 보세요. 화면이 어떻게 되나요? 개발자 도구 콘솔도 함께 확인해 주세요. 빌드는 막지 않았는데 왜 이런 일이 생겼는지 Step 5 로 설명해 보세요.
• 이번엔 npm run build 를 돌려 보세요. 어디서 멈추나요? package.json 의 build 스크립트와 견줘서 이유를 적어 주세요.
• 오타를 고치고, 이번엔 List 에 items={[{ name: '한강' }]} 을 넘겨 보세요. 에러가 몇 개 나나요? 하나가 아닐 겁니다. 두 번째 에러가 왜 따라 나오는지 생각해 보세요.
• IconButton 을 쓰는 곳에서 aria-label 을 지워 보세요. 그다음 같은 자리를 Button 으로 바꿔 보세요. 한쪽만 걸리는 이유를 한 줄로 정리해 주세요.
• 마지막은 두 단계입니다. 먼저 useCommentInput 의 inputRef.current?.focus() 에서 물음표를 지우고 npm run typecheck 를 돌려 에러를 확인하세요. 그 상태 그대로 tsconfig.json 의 "strict": true 를 false 로 바꾸고 다시 돌려 보세요. 에러가 어떻게 되나요? strict 가 무엇을 막아주고 있었는지 한 줄로 정리해 주세요. (확인이 끝나면 둘 다 되돌립니다.)

생각해볼 주제

1. 중복을 없애는 것이 늘 이득일까

오늘 CommentList 와 Feed 를 List 하나로 합쳤습니다. 같은 코드를 두 번 적지 않게 됐죠.

그런데 합치기 전에는 각각을 마음대로 고칠 수 있었습니다. 지금은 List 를 고치면 두 곳이 함께 움직여요. 그게 이득일 때도 있고 발목을 잡을 때도 있습니다.

"우연히 닮은 코드" 와 "정말 같은 코드" 를 어떻게 구분하시겠어요. 합치기 전에 무엇을 확인해야 나중에 후회하지 않을까요.

2. IconButton 같은 얇은 컴포넌트

IconButton 은 Button 을 그대로 돌려주기만 합니다. 렌더 결과도 똑같아요. 하는 일이라곤 타입 하나를 좁히는 것뿐입니다.

이런 컴포넌트를 두고 팀에서 의견이 갈릴 수 있습니다. "규칙을 타입으로 박아두니 좋다" 는 쪽과 "파일만 늘고 한 번 더 거쳐 가서 헷갈린다" 는 쪽으로요.

여러분은 어느 쪽인가요. 그리고 이런 규칙을 강제하는 다른 방법에는 무엇이 있을까요. 그 방법들과 견줘서 타입으로 막는 것의 장단점은 무엇일까요.

3. 검사를 어디에 세울 것인가

Step 5 에서 타입 검사가 세 겹으로 돈다고 했습니다. 에디터, 빌드, 그리고 CI 요.

그런데 팀에서 이런 제안이 나올 수 있습니다. "빌드가 느리니까 build 에서 tsc --noEmit 을 빼고 CI 에만 두자" 고요. 실제로 그렇게 하는 팀도 있습니다.

어떻게 답하시겠어요. 검사를 앞에 세울수록 좋은 걸까요, 아니면 적당한 자리가 따로 있을까요. 판단이 갈릴 만한 조건은 무엇일까요.