AI가 스스로 채점하게 하기 | 테스트 기반 검증

Overview

앞 레슨에서 What 방식으로 원하는 결과만 알려주면 AI가 코드를 알아서 작성한다고 배웠습니다. 그런데 그 코드가 의도한 대로 동작하는지는 여전히 브라우저를 열고 사람이 확인해야 했습니다. 자율 루프의 확인 단계가 비어 있었던 셈입니다.

수동 체크리스트를 테스트 코드로 바꿔, 확인 단계까지 AI에게 맡기는 방법을 배웁니다.

학습 목표

• 수동 체크리스트를 테스트 코드로 변환하는 과정을 체험합니다
• 테스트가 있을 때 AI 자율 루프가 어떻게 완성되는지 이해합니다
• 새 기능을 추가해도 기존 기능이 그대로 동작하는지 테스트로 자동 확인하는 흐름을 체험합니다

시작하기 전 확인사항

• Chapter 04 의 Todo 앱이 정상 동작하는 상태
• bun --version 으로 Bun 설치 확인

기능마다 반복되는 브라우저 클릭

Chapter 04 Lesson 03에서 Todo 앱을 만들고 브라우저에서 직접 검증했습니다. 입력 필드에 "장보기"를 쳐서 Enter, 체크박스 클릭으로 완료 표시, 삭제 버튼, 새로고침. 5개 항목을 하나씩 눌러 확인했습니다.

What vs How 레슨에서 본 What 방식으로 AI에게 기능 추가를 맡기면 자율 루프가 돌기 시작합니다. AI가 파일을 탐색하고, 기존 패턴을 읽고, 코드를 작성합니다. 그런데 이 루프에 아직 비어 있는 자리가 하나 있습니다. 확인 단계입니다.

기능 1개가 늘 때마다 체크리스트 5개를 다시 눌러야 합니다. 기능이 5개면 25번, 10개면 50번. 코드 작성 속도는 AI 덕에 빨라졌는데, 검증 속도는 그대로입니다. 작성과 검증이 따로 노는 셈입니다. 기능이 늘수록 이 격차는 더 벌어집니다.

이 체크리스트를 AI가 대신 확인할 수 있다면 어떨까요?

테스트: AI가 스스로 채점하는 정답지

택시 비유에서 기사님(AI)에게 "강남역 2번 출구"라고 목적지만 말해도 공사 구간을 만나면 알아서 우회한다고 했습니다. 그런데 기사님이 정말 도착했는지는 어떻게 알까요?

표지판이 있으면 기사님과 손님이 같은 기준을 봅니다. 기사님도 "여기 맞다"라고 판단할 수 있습니다. 표지판이 없다면 기사님은 목적지에 가까워졌는지 알 수 있어도, 최종적으로 맞는지는 손님에게 물어봐야 합니다.

테스트 코드는 이 표지판에 해당합니다. "이 입력을 넣으면 이 출력이 나와야 한다"가 코드로 적혀 있어서, AI가 작성한 코드를 실행해 그 결과가 기대치와 같은지 스스로 채점합니다. 사람이 매번 브라우저를 열지 않아도 됩니다.

표지판이 코드로는 이런 모양입니다. Todo 입력 검증 한 항목을 예로 들면 다음과 같습니다.

it('빈 입력으로 Enter 를 누르면 Todo 가 추가되지 않는다', () => {
  fireEvent.change(input, { target: { value: '' } });
  fireEvent.keyDown(input, { key: 'Enter' });
  expect(screen.queryByRole('listitem')).toBeNull();
});

it(...) 한 덩어리가 체크리스트 한 항목에 대응합니다. 입력을 흉내 내고(fireEvent), 기대 결과와 같은지 확인(expect) 하는 구조입니다. bun run test 한 번이 이런 함수를 모아 실행해 통과·실패를 출력합니다.

정답지가 완성하는 자율 루프

표지판(테스트)이 있을 때 AI는 다음 루프를 스스로 반복합니다.

1. 코드를 작성합니다
2. 테스트를 실행합니다 (bun run test)
3. 실패한 항목이 있으면 메시지를 읽고 코드를 수정합니다
4. 다시 테스트를 실행합니다
5. 전부 통과하면 완료를 보고합니다

테스트가 없으면 AI는 코드를 작성한 뒤에도 무엇이 맞고 틀린지 판단할 기준이 없습니다. 에러 없이 실행되는 것만으로는 원하는 동작을 보장할 수 없습니다. 테스트가 있어야 실패 메시지를 읽고, 고치고, 다시 실행하는 루프를 스스로 돌릴 수 있습니다.

[미션] 수동 체크리스트를 테스트로 변환하기

Chapter 04에서 브라우저로 확인하던 체크리스트를 테스트 코드로 바꿉니다.

ch05-02 브랜치가 이 미션의 시작점입니다.

git fetch origin
git checkout ch05-02

Step 1: 테스트 환경 셋업

Vitest는 빠른 JavaScript 테스트 러너이고, React Testing Library는 사용자 관점에서 컴포넌트를 테스트하는 도구입니다. 설치와 설정 파일 생성은 AI에게 맡깁니다.

이 Next.js 프로젝트에 Vitest 와 React Testing Library 테스트 환경을 셋업해줘.
샘플 테스트를 하나 작성해서 `bun run test` 로 동작을 검증해줘.

AI가 패키지 설치, 설정 파일 생성, 샘플 테스트 실행까지 한 번에 끝냅니다.

Step 2: AI에게 체크리스트 전달

Chapter 04 Lesson 03의 검증 체크리스트를 그대로 AI에게 건네고, 테스트 코드로 바꿔 달라고 합니다.

아래 검증 체크리스트를 테스트 코드로 만들어줘.

1. 입력 필드에 "장보기" 입력 후 Enter -> 목록에 추가됨
2. 빈 입력 상태에서 Enter -> Todo 가 추가되지 않음
3. 체크박스 클릭 -> 완료 표시 (취소선)
4. 삭제 버튼 클릭 -> 해당 항목 제거
5. 페이지 새로고침 -> 기존 목록 유지

Step 3: 생성된 테스트 확인

AI가 테스트 5개를 생성합니다. 각 테스트가 체크리스트의 어떤 항목에 대응하는지 한 번 훑어봅니다. 표현만 다를 뿐 "이 입력 → 이 기대 결과"라는 구조는 체크리스트 그대로입니다.

Step 4: 전 항목 통과 상태 확인

bun run test

5개 테스트가 모두 통과하면, 지금 앱이 우리가 적은 5가지 확인 항목을 모두 만족한다는 뜻입니다. 앞으로 기능을 더할 때마다 같은 검사를 다시 돌려서, 기존 행동이 그대로 유지되는지 확인합니다.

[미션] 기존 테스트를 안전망 삼아 기능 추가하기

테스트의 가치는 코드가 바뀔 때 비로소 체감됩니다. Todo 앱에 새 기능을 붙여 보면서 살펴봅니다.

Step 5: 우선순위 기능 추가 지시

Todo 항목에 우선순위(높음/보통/낮음)를 설정하는 기능을 추가합니다.

Todo 항목에 우선순위(높음/보통/낮음) 를 설정할 수 있게 해줘.
새 Todo 추가 시 우선순위를 선택할 수 있어야 하고, 목록에서 우선순위가 표시되어야 해.

AI가 관련 코드를 수정합니다.

Step 6: 자동 검증 과정 살펴보기

AI가 우선순위 기능을 추가한 뒤 bun run test 를 실행합니다. 두 가지 중 하나가 일어납니다.

• 테스트가 실패하는 경우: 기존 5개 테스트 중 일부가 실패합니다. 우선순위 기능을 붙이는 과정에서 기존 행동 중 하나가 예전처럼 동작하지 않는다는 신호입니다. 예를 들어 새 입력 UI를 추가하다가 Enter로 Todo가 추가되는 기능이 망가졌을 수 있습니다. AI는 실패 메시지를 보고 어떤 동작이 달라졌는지 확인한 뒤, 새 기능은 유지하면서 기존 동작을 되살립니다.
• 테스트가 전부 통과하는 경우: AI가 기존 테스트를 미리 읽고 호환을 맞춰 코드를 작성했기 때문입니다.

어떤 경우든, 기존 5개 확인 항목이 그대로 통과한다는 사실을 사람이 브라우저에서 한 번도 클릭하지 않고 확인했습니다. 이게 바로 안전망입니다. 새 코드를 더해도 기존 기능이 그대로 동작하는지 자동으로 점검합니다.

Step 7: 새 기능의 테스트도 추가

기존 5개 테스트가 기존 기능을 지켰으니, 이제 새로 추가한 우선순위 기능에도 같은 방식으로 테스트를 추가할 차례입니다.

우선순위 기능에 대한 테스트도 만들어줘.

AI가 우선순위 선택·목록 표시 등 관련 테스트를 추가합니다. bun run test 를 돌리면 기존 5개 + 새 테스트가 모두 통과합니다.

다음에 또 기능을 추가해도, 이제는 우선순위 기능까지 테스트가 자동으로 검증합니다. 테스트가 쌓일수록 자동 검증 범위가 넓어집니다.

기능을 먼저 만든 뒤 쓴 테스트의 한계

방금 Step 7에서 새 테스트가 한 번에 통과했습니다. 좋은 신호처럼 보이지만, 한 가지 짚을 점이 있습니다. 우선순위 코드와 그 테스트를 둘 다 AI가 만들었습니다.

이런 문제를 자기 점검 편향이라고 부릅니다. 자기가 만든 결과물을 자기가 다시 검사하면, 처음에 놓친 조건을 검사할 때도 똑같이 놓치기 쉽습니다. 예를 들어 AI가 "우선순위를 선택하지 않았을 때" 처리를 코드에서 빠뜨렸다면, 같은 AI가 만든 테스트도 그 조건을 빠뜨릴 수 있습니다. 테스트는 전부 통과하지만, 버그는 그대로 남습니다.

자세한 해법은 다음 레슨에서 살펴봅니다.

핵심 포인트 정리

1. 테스트 = 자동화된 체크리스트: 브라우저에서 수동 확인하던 항목 하나가 테스트 한 개에 대응합니다. AI에게 체크리스트를 주면 테스트 코드로 변환합니다.
2. 자율 루프의 완성: What 방식이 열어둔 자율 루프의 마지막 단계(확인)를 테스트가 채웁니다. AI는 "코드 작성 → 테스트 실행 → 실패 → 수정"을 사람 개입 없이 반복합니다.
3. 안전망: 새 기능을 추가해도 기존 동작이 망가지면 AI가 즉시 감지합니다. bun run test 한 번이 브라우저 5번 클릭을 대체합니다.
4. 자기 점검 편향: 자기 코드를 보고 쓴 테스트는 자기 코드의 빈틈을 덮기 쉽습니다. 이 허점이 다음 레슨의 출발점입니다.

FAQ

이어서 배울 내용

방금은 기능을 다 만든 뒤에 테스트를 붙였습니다. 다음 레슨에서는 순서를 뒤집어, 계획 단계에서 성공 기준을 적고 그걸 테스트로 먼저 쓰는 방식을 배웁니다. 이 순서 전환이 기능 뒤 테스트의 함정을 어떻게 해결하는지 체험합니다.

• 검증 가능한 성공 기준(Acceptance Criteria) 작성법
• 테스트를 먼저 쓰는 이유와 Red Green Refactor 사이클