F-1: 왜 테스트인가 — 이미 있었고, 재봅니다

안녕하세요, 홍순구입니다.

상황 하나만 그려볼게요.

여러분이 좋아요 버튼의 숫자 계산을 한 줄 살짝 고쳤다고 해봅시다. 저장하고 브라우저를 열어 하트를 눌러보니 잘 됩니다. 그래서 그대로 배포했어요.

다음 날 문의가 들어옵니다. 댓글이 안 지워진다고요.

좋아요를 고쳤는데 댓글 삭제가 망가졌는데, 둘이 무슨 상관인가 싶겠지만 우리 앱에서 그 둘은 같은 목록 도구인 A-6에서 만든 removeById를 쓰고 있어서, 좋아요 쪽에서 그 함수의 동작을 조금 바꾸니 댓글 쪽이 같이 물린 거예요.

이걸 배포 전에 잡으려면 어떻게 해야 할까요. 한 줄을 고칠 때마다 화면을 열고 좋아요를 누르고 댓글을 지우고 팔로우를 하고 로그인을 다시 하고... 지난 시간에 우리가 컨테이너를 띄워놓고 curl 다섯 줄을 손으로 확인했던 것 기억하시죠. 그게 다섯 줄이라 가능했던 거지, 앱 전체는 그렇게 못 하니 오늘부터 그 확인을 코드로 적어볼게요.

오늘 우리가 처음 할 일은 그런 코드를 쓰는 게 아니라, 이 저장소를 열어서 그런 코드가 이미 몇 개나 있는지 세어보는 것부터 시작하는 거예요. 세어보면 아마 좀 놀라실 거예요.

오늘의 여정

  손으로 확인하던 것        ──  왜 안 되는가
  테스팅 트로피             ──  맨 아래 층은 이미 우리 것이었다
  저장소를 열어본다         ──  몇 개가 있나
  설정 파일을 읽는다        ──  세 줄
  그 세 줄을 끊어본다       ──  무엇이 무너지나
  커버리지를 켠다           ──  첫 숫자
  그 숫자를 의심한다        ──  셋 다 거짓말할 수 있다

💡 오늘 수업의 핵심 — "숫자를 만들기 전에, 그 숫자가 무엇을 세고 있는지부터 안다"

🎯 학습 목표

• 손으로 하는 확인이 왜 앱 크기와 함께 무너지는지 설명하고, 테스팅 트로피의 네 층을 우리 저장소에 그대로 짚을 수 있다.
• Vitest가 "설정이 거의 없다" 고 말하는 근거가 무엇인지 알고, 그 재사용을 끊었을 때 실제로 무엇이 무너지는지 확인할 수 있다.
• 커버리지 숫자를 뽑고, 그 숫자가 세는 범위와 재는 환경에 따라 어떻게 달라지는지 설명할 수 있다.

Step 1: "손으로 확인하던 것"

지금까지 우리가 무언가를 고칠 때마다 한 일을 떠올려봅시다.

D-2에서는 <Link>로 옮겨 다니며 요청이 몇 건 나가는지 개발자 도구를 열어 셌고, D-4에서는 첫 바이트가 몇 ms인지 쟀죠. 그리고 D-7에서는 팔로우 버튼을 누르고 서버 로그를 봤고, D-10에서는 컨테이너를 띄우고 curl을 다섯 번 날렸습니다.

전부 손으로, 그때 한 번만 한 거였죠.

여기서 중요한 건 "귀찮다"가 아닙니다. 진짜 문제는 이겁니다.

확인은 고친 곳에만 하게 된다

사람은 자기가 방금 고친 곳을 확인하니까, 좋아요를 고쳤으면 좋아요를 눌러보지만 아무도 좋아요를 고치고 나서 댓글 삭제까지 눌러보지는 않아요. 그럴 이유가 없다고 생각하니까요.

코드는 그렇게 안 나뉘어 있습니다. 그런데 우리 앱에서 좋아요와 댓글 삭제는 이렇게 이어져 있어요.

  LikeButton ──┐
               ├──> removeById  (A-6 에서 만든 목록 도구)
  CommentList ─┘

  한쪽을 보고 고치면 다른 쪽이 조용히 물린다

이렇게 "고친 곳 말고 다른 데가 망가지는 것"을 회귀라고 부르는데, 되돌아간다는 뜻으로 잘 되던 게 다시 안 되게 된 거니까요.

회귀는 손으로 못 잡습니다. 잡으려면 고칠 때마다 앱 전체를 다시 확인해야 하는데, 그게 사람이 할 수 있는 양이 아니거든요.

그래서 확인을 코드로 적습니다

한 번 적어두면, 그 뒤로는 명령 한 줄에 전부 다시 확인됩니다. 좋아요를 고치든 댓글을 고치든 상관없이 매번 전부요.

우리가 오늘 세어볼 게 바로 그 코드입니다.

💡 한 줄 정리

손으로 하는 확인의 진짜 한계는 느린 게 아니라 고친 곳만 보게 된다는 것이고, 회귀는 정확히 그 바깥에서 생긴다.

Step 2: "트로피의 맨 아래는 이미 우리 것이었다"

테스트를 어떤 비율로 섞어야 하는가에 대한 그림이 있는데, 예전에는 아래가 넓고 위가 좁은 삼각형인 피라미드를 그려서 단위 테스트는 아주 많이, 통합 테스트는 조금, 화면 전체 테스트는 아주 조금만 두는 식이었어요.

요즘은 트로피 모양으로 그립니다. 피라미드와 다른 점은 가운데가 가장 넓다는 거예요.

        ┌────────────┐
        │    E2E     │   느리고 비싸다. 핵심 흐름만 얇게
        ├────────────┤
        │Integration │   여기가 가장 넓다
        ├────────────┤
        │   Unit     │   함수 하나씩
        ├────────────┤
        │   Static   │   실행하지 않고 잡는 것
        └────────────┘

왜 가운데가 넓어졌을까요. 함수를 하나하나 다 검사해도 그것들이 이어졌을 때 제대로 도는지는 여전히 모르기 때문인데, Step 1의 좋아요와 댓글 문제가 정확히 그 예예요. removeById도 잘 돌고 LikeButton도 잘 도는데, 둘이 만나는 지점이 망가진 겁니다.

맨 아래 층은 이미 깔려 있습니다

여기서 오늘 첫 번째로 놀라실 부분이 나옵니다. 그런데 트로피의 맨 아래 Static은 실행하지 않고 잡는 것이에요. 코드를 돌리지 않고 읽기만 해서 문제를 찾는 층이죠.

우리가 지금까지 매 모듈 끝에 무엇을 돌렸는지 기억하시나요.

npx tsc --noEmit
npx eslint .

이 두 개가 트로피의 맨 아래 층입니다. A-6에서 tsc --noEmit을 별도로 돌려야 하는 이유를 배웠고, B-1부터 eslint를 켜뒀죠. C-8에서는 그 eslint 규칙이 사실은 React Compiler의 판정과 같은 것이라는 걸 봤고요.

여러분은 이미 트로피의 한 층을 쌓고 있었는데, 이름을 안 붙였을 뿐이에요.

이 층은 공짜에 가깝습니다. 실행을 안 하니까 빠르고 앱을 띄울 필요도 없어서, 그래서 트로피에서도 맨 아래 넓은 받침으로 그리는 거예요.

오늘 우리가 얹을 것은 그 위층입니다.

💡 한 줄 정리

트로피는 피라미드와 달리 가운데(통합)가 가장 넓고, 맨 아래 정적 층은 우리가 A-6부터 이미 돌리고 있던 tsc와 eslint 다.

Step 3: "저장소를 열어봅니다"

이제 세어봅시다. 저장소 뿌리에서요.

npm test

 Test Files  135 passed (135)
      Tests  954 passed (954)
   Duration  19.54s

135개 파일에 954개의 확인이 이미 들어 있습니다.

여러분이 A-1에서 타입을 선언하던 때부터, B-2에서 좋아요 토글을 만들 때도, C-6에서 서버를 붙일 때도, D-8에서 문지기를 세울 때도 이 숫자는 계속 자라고 있었어요.

어디에 있는지 볼까요.

find src -name "*.test.ts" -o -name "*.test.tsx" | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn

  61 src/components
  32 src/routes
  12 src/lib
   7 src/hooks
   6 src/queries
   5 src/realtime
   3 src/types
   3 src/api
   2 src/contexts

두 가지가 눈에 띕니다.

하나, 테스트 파일이 소스 파일 바로 옆에 있습니다. tests/ 같은 폴더를 따로 두지 않았어요. PostCard.tsx를 고치러 들어가면 그 옆에 확인 코드가 같이 보입니다. 고칠 때 같이 고치게 되고, 지울 때 같이 지워지고요.

둘, 파일 이름 앞에 모듈 번호가 붙어 있습니다. a6-collections.test.ts, c4-store-basics.test.tsx처럼 붙어 있어서, 어느 시점에 무엇을 확인하려고 만든 것인지가 이름만 봐도 남아요.

하나만 열어봅시다

src/lib/a6-collections.test.ts를 열어볼게요. 사실 A-6에서 만든 제네릭 목록 도구를 확인하는 코드입니다.

// apps/web-spa/src/lib/a6-collections.test.ts
import { describe, it, expect } from 'vitest';
import { findById, removeById } from './collections';
import { feedPosts } from '../data/feed';

const comments = [
  { id: 1, content: '첫째' },
  { id: 2, content: '둘째' },
];

describe('findById — 어떤 목록에서든 번호로 하나를 찾는다', () => {
  it('게시물에서 찾으면 게시물이 나온다', () => {
    const found = findById(feedPosts, 2);

    expect(found?.username).toBe('minji');
  });

  it('없으면 undefined', () => {
    expect(findById(comments, 999)).toBeUndefined();
  });
});

지금은 읽기만 합니다. 직접 쓰는 건 다음 시간이지만, 모양은 눈에 들어오시죠. describe로 묶고, it으로 하나씩 적고, expect로 기대한 값과 비교하는데, 영어로 읽으면 "it 게시물에서 찾으면 게시물이 나온다"처럼 문장이 돼요.

그리고 Step 1의 그 함수도 여기 있는데, removeById요. 같은 파일 아래쪽에 이런 확인이 있어요.

  it('원본을 건드리지 않는다', () => {
    removeById(comments, 1);

    expect(comments).toHaveLength(2);
  });

만약 누군가 removeById를 원본을 직접 지우는 방식으로 바꾸면, 좋아요를 고치다 그랬든 뭘 하다 그랬든 이 줄이 즉시 빨개집니다. 댓글 화면을 열어보지 않아도요.

Step 1에서 그린 그 사고가 이 저장소에서는 이미 막혀 있었던 거예요.

💡 한 줄 정리

이 저장소에는 135개 파일 / 954개의 확인이 A-1부터 쌓여 있었고, 소스 옆에 붙어 있어서 고칠 때 같이 눈에 들어온다.

Step 4: "설정은 세 줄입니다"

Vitest를 소개할 때 거의 항상 따라오는 말이 있습니다. "설정이 거의 없다"는 말이요.

보통 이런 말은 반쯤 믿고 들어야 하는데, 이번엔 파일을 직접 열어서 확인할 수 있습니다.

// apps/web-spa/vitest.config.ts
// 상호작용(클릭·입력)을 검증하려면 브라우저 DOM 이 필요해서 jsdom 환경을 얹는다.
// vite.config.ts 는 그대로 두고 여기서 병합만 한다.
import { defineConfig, mergeConfig } from 'vitest/config';
import viteConfig from './vite.config';

export default mergeConfig(
  viteConfig,
  defineConfig({
    test: {
      environment: 'jsdom',
      globals: true,
      setupFiles: ['./src/test-setup.ts'],
    },
  }),
);

954개의 확인을 굴리는 설정 전부입니다. 진짜 설정이라고 부를 만한 줄은 셋이에요.

• environment: 'jsdom' — 테스트를 돌릴 때 브라우저 흉내를 켭니다. document 나 window를 쓸 수 있게요. jsdom은 진짜 브라우저가 아니라 Node 안에서 도는 흉내인데, 클릭하고 글자를 읽는 정도는 충분히 됩니다.
• globals: true — describe 나 expect를 매번 import 하지 않아도 쓸 수 있게 합니다. 우리 파일들은 대부분 그래도 import를 적어뒀는데, 적어두면 편집기가 무엇인지 바로 알려주거든요.
• setupFiles — 판을 돌리기 전에 먼저 실행할 파일입니다. 우리 것에는 jsdom에 없는 기능을 메우는 코드가 들어 있어요.

진짜 중요한 줄은 따로 있습니다

위 셋이 아니라 mergeConfig(viteConfig, ...)입니다.

이 한 줄이 vite.config.ts를 통째로 가져옵니다. 앱을 빌드할 때 쓰는 그 설정을요.

  vite.config.ts  ─────┐
    @  →  src/         │
    react()            ├──> vitest.config.ts 가 그대로 물려받는다
    React Compiler     │      + environment: jsdom
    tailwindcss()  ────┘      + globals: true
                              + setupFiles

이게 왜 중요하냐면, 앱이 도는 방식과 테스트가 도는 방식이 갈리지 않기 때문입니다.

앱에서 @/lib/utils라고 쓰면 src/lib/utils를 가리키는데, 테스트에서도 따로 안 알려줬는데 똑같이 가리켜요. 앱이 React Compiler로 자동 메모이제이션되면, 테스트에서 도는 컴포넌트도 똑같이 됩니다.

"설정이 거의 없다"는 말의 정확한 뜻은 설정이 없다가 아니라 한 번 쓴 설정을 두 곳이 나눠 쓴다는 겁니다.

말로만 들으면 당연해 보이죠. 다음 Step에서 그 한 줄을 끊어보겠습니다.

💡 한 줄 정리

Vitest 설정의 본체는 environment·globals·setupFiles 세 줄이 아니라, vite.config.ts를 통째로 물려받는 mergeConfig 한 줄이다.

git log --oneline --follow -- apps/web-spa/vitest.config.ts

03f54b6 test: jsdom + Testing Library 내부 검증 환경 (B2)

Step 5: "그 한 줄을 끊어봅니다"

말로 하는 대신 직접 끊어보겠습니다. mergeConfig를 걷어내고, 나머지 세 줄은 그대로 두는 거예요.

// apps/web-spa/vitest.config.ts  (일부러 망가뜨린 판)
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: ['./src/test-setup.ts'],
  },
});

jsdom도 켜져 있고, globals도 켜져 있고, setupFiles도 그대로입니다. 겉보기엔 멀쩡해 보이죠.

돌려봅시다.

 Test Files  72 failed | 63 passed (135)
      Tests  5 failed | 417 passed (422)

135개 중 63개만 살아남았습니다. 그런데 더 눈여겨볼 숫자가 있어요. 원래 954개였던 확인이 422개만 실행됐고, 532개는 아예 시작조차 못 했어요.

왜 시작을 못 했나

실패한 72개 중 70개는 이런 메시지를 냅니다. 사실 원인은 단순합니다.

Error: Failed to resolve import "@/lib/utils" from "src/components/ui/button.tsx".
Does the file exist?

@가 무엇인지 모르게 된 겁니다. 그 별칭은 vite.config.ts에 적혀 있었고, 우리가 방금 그 연결을 끊었으니까요.

E-5에서 Shadcn 컴포넌트를 들여왔을 때 그 파일들이 @/lib/utils로 cn을 가져온다고 했던 것 기억하시죠. 그 파일 하나를 못 읽으면 그걸 쓰는 카드가 안 열리고, 카드를 못 열면 피드가 안 열리고, 그래서 70개가 줄줄이 무너집니다.

진짜 흥미로운 건 나머지 5개입니다

70개는 아예 못 열린 거고, 5개는 열려서 실행됐는데 결과가 틀렸습니다. 그리고 후자가 더 무서운 종류예요.

 FAIL  src/contexts/c3-rerender-scope.test.tsx   (2건)
 FAIL  src/hooks/a5-identity-probe.test.tsx      (3건)

이 다섯 개의 공통점이 뭘까요. 전부 React Compiler가 일하고 있다는 것을 확인하는 판입니다.

C-3에서 우리는 통설 두 개를 실측으로 뒤집었어요. "Context 값이 바뀌면 아래가 전부 다시 그려진다"와 "객체를 value로 주면 리렌더 폭풍이 난다" 요. 둘 다 React Compiler가 켜져 있으면 그렇지 않다는 걸 숫자로 봤죠.

그 판의 코드에 이런 주석이 그때부터 적혀 있습니다.

// apps/web-spa/src/contexts/c3-rerender-scope.test.tsx
    // props 가 그대로인 자식 엘리먼트를 컴파일러가 붙들고 있기 때문이다.
    // (같은 판을 컴파일러 없이 돌리면 셋 다 1 -> 2 가 된다)
    expect(counts.reader).toBe(before.reader);

지금, 컴파일러 없이 돌리니 정확히 그 주석대로 1이 2로 나왔습니다.

C-3 때 적어둔 예측이 지금 재현된 거예요.

정리하면

                      재사용 O    재사용 X
  통과한 파일           135          63
  아예 못 연 파일         0          70     ← @ 별칭이 사라져서
  실행됐는데 틀린 판      0           5     ← React Compiler 가 빠져서
  실행된 확인 수        954         422

mergeConfig 한 줄이 별칭과 컴파일러를 동시에 물어오고 있었던 겁니다. 그게 없으면 테스트는 "앱과 다른 조건"에서 돌게 되고, 그러면 통과하든 실패하든 앱에 대해 아무 말도 못 해요.

테스트가 앱과 같은 조건에서 돌아야 한다는 게 이 Step의 전부입니다. Vitest가 파는 것도 문법이 아니라 이거예요.

그럼 Jest는요

여러분이 회사에 가면 Jest로 된 저장소를 만날 가능성이 높습니다. 오랫동안 표준이었고 지금도 아주 많이 쓰여요. 문법은 거의 같아서 describe·it·expect를 그대로 씁니다. 다른 점은 방금 본 그 지점인데, Jest는 번들러와 별개로 도는 도구라 앱이 쓰는 별칭·TypeScript 변환·JSX 처리 같은 것을 테스트 쪽에도 따로 적어줘야 합니다. 그러다 보니 앱 설정을 고칠 때 테스트 설정도 같이 고쳐야 하고, 둘이 어긋나면 오늘 본 것과 같은 종류의 일이 벌어져요. 옛 저장소에서 만나면 그렇게 이해하시면 되고, 새로 시작하는 Vite 기반 프로젝트에서 굳이 Jest를 고를 이유는 이제 거의 없습니다.

💡 한 줄 정리

mergeConfig를 끊으면 135개 중 63개만 살아남고, 못 연 70개는 @ 별칭 때문에, 틀린 5개는 React Compiler가 빠졌기 때문이다.

Step 6: "커버리지를 켭니다"

954개가 있다는 건 알았습니다. 그럼 이 954개가 앱을 얼마나 덮고 있는지 볼까요.

이걸 재주는 도구를 커버리지라고 부릅니다. 테스트를 돌리는 동안 어느 줄이 실제로 실행됐는지 세는 거예요. 실행된 적 없는 줄은 아무도 확인한 적이 없는 줄이겠죠.

Vitest는 이 기능을 따로 떼어놨습니다. 설치부터 할게요.

npm install -D -w web-spa @vitest/coverage-v8@4.1.10

버전을 Vitest와 맞춰서 깝니다. 러너 내부를 들여다보는 도구라 짝이 맞아야 해서, 명령도 하나 만들어둘게요.

// apps/web-spa/package.json
  "scripts": {
    "test": "vitest run",
    "test:coverage": "vitest run --coverage"
  }

돌려봅시다.

npm run test:coverage --workspace web-spa

 Test Files  135 passed (135)
      Tests  954 passed (954)

 % Coverage report from v8
-------------------|---------|----------|---------|---------|
File               | % Stmts | % Branch | % Funcs | % Lines |
-------------------|---------|----------|---------|---------|
All files          |   87.24 |    76.22 |   91.19 |   95.25 |

첫 숫자가 나왔습니다. 그런데 이 숫자, 그대로 믿어도 될까요.

숫자가 왜 네 개인가요

여기서 바로 걸리는 게 있죠. "커버리지 87% 다"라고 할 때 어느 숫자를 말하는 걸까요.

네 개가 세는 게 다 다릅니다.

• Lines (95.25%) — 실행된 줄의 비율입니다.
• Stmts (87.24%) — 문장 단위예요. 한 줄에 문장이 여러 개일 수 있어서 줄과 다릅니다.
• Funcs (91.19%) — 한 번이라도 불린 함수의 비율입니다.
• Branch (76.22%) — 갈림길입니다. if의 참 쪽과 거짓 쪽, ?:의 양쪽, ??의 양쪽을 각각 셉니다.

줄은 95% 인데 갈래는 76% 입니다. 19 포인트 차이예요.

이게 왜 벌어지냐면, 이런 코드 때문입니다.

const label = post.liked ? '좋아요 취소' : '좋아요';

한 줄이죠. 테스트가 좋아요를 한 번 눌러보면 이 줄은 실행됐습니다. 줄 기준으로는 100% 예요. 그런데 liked가 참인 경우만 지나갔다면 거짓 쪽은 아무도 안 가본 겁니다. 갈래 기준으로는 50% 고요.

버그는 대부분 안 가본 갈래에 숨어 있습니다. 그래서 일반적으로는 네 숫자 중에 Branch를 가장 믿을 만한 것으로 칩니다.

누가 "커버리지 95% 입니다"라고 하면, 같은 코드를 두고 "76% 입니다"라고 말할 수도 있다는 뜻입니다. 어느 숫자인지 정하지 않으면 그 말은 아무 말도 아닙니다.

Branch도 우리 저장소에서는 한 번 더 의심해봐야 하는데, 왜 그런지는 다음 Step에서 직접 재보겠습니다.

💡 한 줄 정리

커버리지는 한 숫자가 아니라 넷이고, 우리 앱은 줄 95.25% 인데 갈래 76.22%로 19 포인트가 벌어진다.

Step 7: "그 숫자를 의심합니다"

숫자가 나왔으니 이제 믿으면 될까요. 세 가지를 확인하고 나서 정하겠습니다.

하나 — 무엇을 세고 있는지 봅니다

표를 위에서부터 읽어보면 이런 줄들이 보입니다.

 scratch           |   85.13 |    70.89 |   88.15 |    95.5 |
  ...snapshots.tsx |   83.76 |    55.69 |     100 |   98.48 |
  ...ry-answer.tsx |   85.41 |    59.37 |     100 |     100 |

scratch는 뭘까요. 우리가 지난 모듈들에서 예전 판을 보관해둔 곳입니다. C-7에서 "박제"라고 부르며 옮겨둔 FeedSectionBeforeServer 같은 것들, 과제 예시답안, 측정용 도우미가 들어 있어요.

세어보면 이렇습니다.

  커버리지가 세고 있는 파일   148개
    그중 scratch/            45개  (30%)
    그중 src/               103개

세 개 중 하나가 앱이 아닙니다. 보관해둔 옛날 코드와 과제 답안이 앱의 성적표에 섞여 들어가 있는 거예요.

빼봅시다.

// apps/web-spa/vitest.config.ts
    test: {
      environment: 'jsdom',
      globals: true,
      setupFiles: ['./src/test-setup.ts'],
      coverage: {
        // scratch/ 는 앱이 아니라 보관해 둔 예전 판과 과제 답안이다.
        // 세는 대상에 두면 앱의 숫자를 가린다 — 148개 중 45개가 여기였다.
        exclude: ['scratch/**'],
      },
    },

다시 재면 이렇게 바뀝니다.

갈래가 76.22에서 82.83으로 6.6 포인트 올랐습니다. 테스트는 한 줄도 안 썼는데요.

한 줄도 안 쓰고 숫자를 6 포인트 올렸다는 게 이 표의 요점입니다. 커버리지는 코드의 성질이 아니라 우리가 "무엇을 셀지" 정한 결과예요. 세는 범위를 바꾸면 숫자가 바뀝니다.

하나는 반대로 갔는데, Lines는 95.25에서 94.97로 내려갔습니다. scratch 안의 보관 파일들이 줄 기준으로는 앱보다 잘 덮여 있었던 거고, 네 숫자가 늘 같은 방향으로 움직이지 않는다는 것도 여기서 보이는 거예요.

그런데 앱만 남겨도 우리가 쓴 코드가 아닙니다

scratch를 뺐으니 이제 103개 파일 전부가 우리 앱입니다. 그럼 이 숫자는 우리 코드에 대한 숫자일까요.

src/components/Avatar.tsx를 열어봅시다. 커버리지 표에서 갈래가 50% 로 나오는 파일이에요.

// apps/web-spa/src/components/Avatar.tsx
export function Avatar({ username, profileImageUrl }: AvatarProps) {
  return (
    <div className="flex items-center gap-2.5 p-3">
      <img
        className="size-8 rounded-full object-cover"
        src={profileImageUrl}
        alt={`${username} 프로필 사진`}
      />
      <span className="text-sm font-semibold">{username}</span>
    </div>
  );
}

if가 없습니다. 삼항 연산자도, &&도 없어요. 갈림길이 하나도 없는데 "갈래 50%"가 나옵니다. 절반을 안 지나갔다는 그 갈래는 대체 어디 있는 걸까요.

Step 5를 떠올려보세요. mergeConfig가 vite.config.ts에서 React Compiler를 물어온다고 했죠. 컴파일러는 빌드할 때 자동으로 메모이제이션을 넣습니다. C-8에서 캐시 칸을 세어봤던 것 기억하시죠.

그 캐시는 이렇게 생긴 코드로 들어갑니다. "지난번 값과 같은가? 같으면 재사용하고, 다르면 새로 만든다." 그게 갈림길입니다. 우리가 안 썼지만 실제로 실행되는 코드고, 커버리지는 실행되는 코드를 셉니다.

한 번만 그리는 테스트는 늘 "캐시에 없다" 쪽만 지나가고 "있다" 쪽은 안 지나가는데, 그게 50% 의 정체예요.

얼마나 되는지 재봤습니다. 컴파일러를 껐다 켜고 src의 갈래 총 개수를 세는 방식으로요.

1,410개 중 1,023개, 그러니까 73% 가 우리가 쓰지 않은 갈래입니다.

이게 Step 6에서 "Branch를 가장 믿을 만한 것으로 친다" 고 해놓고 한 번 더 의심해보자고 한 이유예요. 일반적으로는 맞는 말인데, 컴파일러가 코드를 바꾸는 저장소에서는 그 숫자의 대부분이 우리 것이 아닙니다.

그렇다고 컴파일러를 끄는 게 답은 아닙니다. C-8에서 봤듯이 그것 때문에 앱이 빨라졌으니까요. 답은 숫자를 볼 때 그 안에 무엇이 섞여 있는지 알고 보는 것입니다.

둘 — 누가 실행했는지에 따라 화면이 달라집니다

이건 제가 이 수업을 준비하면서 실제로 걸려 넘어진 부분이라 그대로 보여드릴게요.

방금 그 표에는 파일이 몇 줄이나 나올까요. 103개 파일을 셌으니 103줄이 나와야 할 것 같죠. 그런데 아니었습니다.

제 화면에는 45줄이 나왔습니다. 여러분 화면에는 103줄이 나올 거예요.

같은 코드, 같은 명령인데요.

원인은 Vitest 안에 있습니다. 설치된 러너의 코드를 열어보면 이런 부분이 있어요.

// node_modules/vitest/dist/chunks/coverage.DM_a_rWm.js
	if (isAgent) {
		// default to `skipFull` and add `text-summary` reporter when `text` reporter is used on agents
		const text = resolved.coverage.reporter.find(([name]) => name === "text");
		if (text) {
			text[1] = { skipFull: true, ...text[1] };

isAgent 일 때 skipFull을 켭니다. 네 지표가 전부 100% 인 파일을 표에서 빼버리는 설정이에요.

isAgent는 AI 코딩 도구 안에서 돌고 있는지를 봅니다. AI_AGENT, CLAUDECODE, CURSOR_AGENT 같은 환경 변수가 있는지 확인해요. 제가 이 수업 자료를 준비한 환경에 그게 켜져 있었던 겁니다.

직접 확인해보면 이렇습니다.

  이 환경 그대로                45줄   + 요약 블록이 따로 붙음
  환경 변수를 걷어내고         103줄   + 요약 블록 없음

제외 전 숫자로도 똑같습니다. 148개 중 81줄만 보였고, 그 81개는 "네 지표 중 하나라도 100% 미만인 파일"의 개수와 정확히 일치했어요. 100% 인 67개가 통째로 안 보였던 겁니다.

여러분 중에도 Cursor 나 비슷한 도구 안에서 터미널을 여는 분이 있을 텐데, 그러면 옆자리 동료와 같은 명령을 돌렸는데 표가 다르게 나옵니다. 코드가 다른 게 아니라 재는 쪽이 다른 거예요.

⚠️ 한 가지 더. 이걸 --coverage.skipFull=false로 되돌리려고 하면 안 됩니다. 그 옵션은 다른 곳으로 가요. 위 코드가 건드리는 건 표 출력기의 옵션이라, 굳이 되돌리려면 출력기를 직접 지정해야 합니다.

셋 — 재는 행위가 재는 대상을 바꿉니다

커버리지를 켜면 코드에 계측이 붙습니다. 어느 줄이 실행됐는지 세야 하니까요. 당연히 조금 느려집니다.

  커버리지 끔    19.54s
  커버리지 켬    21.32s

1.8초, 9% 정도예요. 별것 아닌 것 같지만, 우리 판 중에 시간에 기대는 것이 하나 있습니다. C-7에서 만든 낙관적 업데이트 판이요. 서버가 답하기 전에 화면이 먼저 바뀌는지를 확인하려면, 답이 아직 안 온 그 짧은 순간에 화면을 봐야 하거든요.

이 판이 커버리지를 켜면 가끔 깨집니다. 판 135개가 CPU를 나눠 쓰는 전체 실행에서만요. 그 파일만 따로 돌리면 열두 번 돌려도 멀쩡합니다.

여기서 제가 처음에 틀린 이야기를 하나 하겠습니다. 저는 처음에 이걸 "커버리지가 실행 시간을 2.2배로 만든다"로 봤는데, 47초가 나왔거든요. 그건 제가 다른 작업을 같이 돌리고 있어서였고, 단독으로 재니 21초였습니다.

C-6에서 똑같은 실수를 기록해뒀는데도 제가 다시 밟았습니다. 재는 동안엔 다른 걸 돌리지 않는다. 이건 여러분도 나중에 성능을 잴 때 그대로 쓰게 될 거예요.

그래서 숫자를 어떻게 쓰나

세 가지를 다 보고 나면 이렇게 정리됩니다.

커버리지는 낮은 곳을 찾는 데는 아주 좋습니다. 82% 인데 어떤 파일이 50% 라면, 거기는 확실히 안 보고 있는 겁니다. 지도로는 훌륭해요.

반대로 높은 숫자는 아무것도 보증하지 않습니다. 세는 범위를 좁히면 오르고, 아무것도 비교하지 않는 테스트로도 오르니까, 팀에서 쓸 때는 "몇 % 이상"보다 "이번 변경으로 내려가지 않았는가"를 봅니다. 절대값보다 방향이요.

💡 한 줄 정리

커버리지 숫자는 세는 범위(scratch를 빼니 갈래가 6.6 포인트 오르고, 남은 갈래의 73% 는 컴파일러가 만든 것이었다)와 재는 환경(같은 명령에 45줄과 103줄)에 따라 달라지므로, 낮은 곳을 찾는 지도로 쓰고 높은 값을 성적으로 쓰지 않는다.

마무리

오늘 배운 핵심 세 가지

💡 하나 — 확인을 코드로 적는 이유는 속도가 아니라 범위입니다. 손으로 하면 방금 고친 곳만 보게 되는데, 회귀는 정확히 그 바깥에서 생깁니다. 좋아요를 고쳤는데 댓글 삭제가 망가지는 일이요. 그 사고는 이 저장소에서 이미 막혀 있었는데, removeById가 원본을 안 건드리는지 보는 줄이 A-6 때부터 있었으니까요.

💡 둘 — 테스트는 앱과 같은 조건에서 돌아야 합니다. Vitest 설정의 본체는 세 줄짜리 설정이 아니라 vite.config.ts를 물려받는 한 줄이었어요. 그 한 줄을 끊었더니 135개 중 63개만 살아남았고, 못 열린 70개보다 멀쩡히 돌면서 틀린 답을 낸 5개가 더 무서웠습니다.

💡 셋 — 숫자를 만들었으면 그 숫자가 무엇을 세는지부터 봅니다. 네 지표가 19 포인트나 벌어져 있었고, 보관 파일을 빼자 테스트를 한 줄도 안 쓰고 6.6 포인트가 올랐고, 남은 갈래의 73% 는 우리가 아니라 React Compiler가 만든 것이었고, 재는 환경에 따라 같은 명령이 45줄과 103줄을 냈습니다. 커버리지는 낮은 곳을 찾는 지도이지 성적표가 아닙니다.

다음 시간 예고

오늘은 이미 있는 것을 마주하고 재기만 했습니다. 한 줄도 직접 안 썼어요.

다음 시간엔 쓰는데, 어디에 쓸지를 우리가 고르지 않을 거예요. 오늘 만든 그 지도가 가리키는 곳으로 갑니다.

지도를 읽어보면 세 종류가 나옵니다. 하나는 아무도 안 부르는 함수예요. 954개의 확인은 물론이고 앱 코드 어디에서도 안 부르는 게 하나 있어서, 여기서 할 일은 테스트를 쓰는 게 아니라 다른 일입니다. 다른 하나는 원리적으로 못 덮는 갈래고요. A-2의 그 never 장치가 여기 걸립니다. 마지막 하나가 진짜 구멍입니다.

그 진짜 구멍에 describe·it·expect로 첫 판을 직접 쓰고, 확인하려는 대상이 혼자 안 돌고 다른 것을 불러야 할 때 어떻게 하는지도 다룹니다.

과제

[탐구] 여러분 화면에는 몇 줄이 나오는지 확인하세요

Step 7에서 제 화면은 45줄, 여러분 화면은 103줄이라고 했습니다. 직접 확인해보세요.

npm run test:coverage --workspace web-spa

1. 표에 나온 파일 줄이 몇 개인가요. (앞이 두 칸 들여쓰기 된 줄들입니다. 한 칸짜리는 폴더 줄이에요.)
2. 표 아래에 Coverage summary라는 요약 블록이 붙어 있나요.
3. 만약 여러분이 AI 코딩 도구 안의 터미널을 쓰고 있다면, 그 도구 밖에서 같은 명령을 한 번 더 돌려서 두 결과를 비교해보세요.

이어서 답해보세요. 표에 안 보이는 파일들은 커버리지가 낮은 파일일까요, 높은 파일일까요. 그렇게 숨기는 것이 왜 대체로는 편하고, 언제 위험할까요.

[탐구] 갈래가 가장 낮은 곳을 셋 찾고, 그 갈래를 눈으로 확인하세요

커버리지 표에서 % Branch가 낮은 파일 세 개를 골라 적고, 각각에 대해 답해보세요.

1. 그 파일을 열어서 if·삼항 연산자(? :)·&&·??가 몇 개나 있는지 세어보세요.
2. 커버리지가 말하는 갈래 개수와 1번의 개수가 맞나요.
3. 안 맞는다면, 그 차이는 어디서 온 걸까요. Step 7에서 본 것을 떠올려보세요.

세 파일 중 최소 하나는 1번의 답이 0개일 겁니다. 갈림길이 하나도 없는데 갈래 커버리지가 50% 로 나오는 파일이요.

마지막 질문입니다. 그런 파일의 갈래 커버리지를 100% 로 만들려면 무엇을 해야 할까요. 그렇게 하는 것이 이 앱에 무슨 도움이 될까요.

[구현] 보관 파일을 도로 넣어보세요

vitest.config.ts의 exclude: ['scratch/**']를 잠시 지우고 다시 재세요.

1. 네 숫자가 각각 어떻게 바뀌나요.
2. 넷 중 셋은 내려가고 하나는 올라갑니다. 올라가는 게 어느 것이고, 왜 그럴까요.
3. 세는 파일 수는 몇 개에서 몇 개가 되나요.

확인한 뒤 되돌려놓고 나서, 생각해보세요. 만약 우리가 scratch를 빼지 않은 채로 "커버리지 87% 달성"이라고 팀에 보고했다면, 그 보고는 거짓말일까요 아닐까요. 무엇을 같이 말해야 거짓이 아니게 될까요.

[구현] 물려받기를 끊고 직접 확인하세요

Step 5를 여러분 손으로 재현하는 과제입니다.

vitest.config.ts에서 mergeConfig(viteConfig, ...)를 걷어내고 defineConfig만 남기세요. 나머지 세 줄은 그대로 둔 채로 npm test를 돌립니다.

1. 몇 개 파일이 통과하고 몇 개가 실패하나요.
2. 실행된 확인의 총 개수가 954에서 몇으로 줄었나요. 왜 줄었을까요.
3. 실패한 것 중에 "파일을 못 열어서"인 것과 "돌았는데 결과가 틀려서"인 것을 갈라보세요. 후자는 몇 개고 어느 파일인가요.
4. 후자의 파일을 열어서 그 판이 무엇을 확인하려는 것이었는지 읽어보세요. 주석에 답이 적혀 있습니다.

확인한 뒤 반드시 되돌려놓으세요. 되돌린 뒤 npm test가 다시 135 파일 954 통과로 돌아오는 것까지 보고 마칩니다.

생각해볼 주제

1. 커버리지를 팀 규칙으로 만든다면

어떤 팀이 이런 규칙을 세웠습니다. "커버리지 80% 미만이면 병합할 수 없다."

의도는 좋아 보이지만, 오늘 우리가 본 것들을 떠올려보세요. 세는 범위를 바꾸면 숫자가 6 포인트 움직였고, 아무것도 비교하지 않는 테스트로도 숫자는 오릅니다.

이 규칙이 팀에서 실제로 어떤 행동을 만들어낼까요. 만약 여러분이 이 규칙을 고쳐 쓴다면 어떻게 바꾸시겠어요.

2. 이미 있는 954개를 우리가 믿어도 될까

오늘 우리는 954개가 통과하는 것을 봤지만, 통과한다는 것이 그 954개가 제대로 된 확인이라는 뜻은 아닙니다.

실제로 이 저장소에서도 그런 일이 있었어요. C-1에서는 이미 없어진 것을 지우고 없다고 확인하던 판이 발견됐고, C-7에서는 아무 일도 안 일어나는데 기대값이 우연히 맞아서 통과하던 판이 두 개 있었습니다.

이렇게 초록불인데 아무것도 안 지키고 있는 테스트를 어떻게 찾아낼 수 있을까요. 커버리지로는 왜 못 찾을까요.

3. 도구가 우리를 보고 있다는 것

Step 7에서 본 isAgent를 다시 생각해봅시다. Vitest는 AI 도구 안에서 돌고 있다는 걸 알아채고 출력을 바꿨습니다. 100% 인 파일을 숨기고 요약을 덧붙였죠.

이건 친절한 기능입니다. 긴 표를 다 읽을 필요 없게 해주니까요. 실제로 그런 의도로 넣은 것이고요.

오늘은 그 친절이 저를 틀리게 만들 뻔했는데, 제가 본 화면을 그대로 여러분에게 옮겼다면 여러분은 전혀 다른 화면을 보고 "내 것만 이상한가" 했을 거예요.

도구가 실행 환경을 감지해서 동작을 바꾸는 일은 앞으로 더 늘어날 겁니다. 이런 종류의 어긋남을 미리 알아채려면 무엇을 습관으로 만들어두어야 할까요.