수동 검증에서 벗어나기 | 테스트 기반 검증

Ch04의 수동 체크리스트를 테스트 코드로 변환하고, 코드 변경 시 AI가 기존 기능이 안 깨졌는지 자동으로 확인하는 과정을 체험합니다

Overview

이전 레슨에서 What 방식으로 AI의 자율 루프가 작동한다는 것을 확인했습니다. 그런데 AI는 코드가 에러 없이 실행되는지만 판단할 수 있고, 그 결과가 실제로 원하는 동작인지는 판단하지 못합니다. 이번 레슨에서는 수동 체크리스트를 테스트 코드로 변환하고, AI가 스스로 채점할 수 있는 정답지를 만드는 방법을 배웁니다.

학습 목표

수동 검증 체크리스트를 테스트 코드로 변환하는 과정을 체험합니다
테스트가 AI의 자율 루프(코드 작성 -> 실행 -> 실패 -> 수정)를 가능하게 하는 원리를 이해합니다
코드 변경 후에도 기존 기능이 정상인지 테스트가 자동으로 확인하는 것을 체험합니다

시작하기 전 확인사항

Chapter 04에서 만든 Todo 앱이 정상 동작하는 상태
bun run test 명령이 실행 가능한 상태 (bun --version)
실습 프로젝트의 시작 브랜치로 전환합니다 (git checkout ch05-02)

ch05-02 브랜치는 이 레슨의 시작점입니다. Chapter 04에서 만든 Todo 앱이 동작하는 상태입니다.

브라우저를 그만 클릭하고 싶다

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

그리고 이런 질문을 남겼습니다. "기능이 하나 추가될 때마다, 체크리스트 전체를 반복해야 한다. 코드는 AI가 작성하는데, 검증은 사람이 브라우저에서 하나씩 클릭하고 있다."

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

테스트 = AI가 읽을 수 있는 정답지

lesson-02-test-answer-sheet

시험을 생각해 봅니다. 정답지가 있으면 채점자는 답안을 하나씩 대조해서 맞고 틀림을 판단할 수 있습니다. 정답지가 없으면 채점자가 직접 문제를 풀어봐야 합니다.

테스트 코드는 이 정답지에 해당합니다. "이 입력을 넣으면 이 출력이 나와야 한다"가 코드로 적혀 있습니다. AI는 이 정답지를 읽고, 자신이 작성한 코드가 맞는지 스스로 채점할 수 있습니다.

정답지가 있으면 AI는 다음 루프를 자율적으로 반복합니다.

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

정답지 없이는 이 루프가 불가능합니다. AI가 코드를 작성해도, "이게 맞는지"를 판단할 기준이 없기 때문입니다.

[데모] 체크리스트를 테스트로 변환하기

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

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

Chapter 04 Lesson 03의 검증 체크리스트를 AI에게 전달하고, 테스트 코드로 변환을 요청합니다.

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

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

Step 3: 생성된 테스트 코드 확인

AI가 테스트 코드를 생성합니다. 각 테스트가 체크리스트의 어느 항목에 대응하는지 확인합니다.

Step 4: 테스트 실행

bun run test

bun test가 아닙니다

bun test는 Bun 내장 테스트 러너를 실행합니다. bun run test는 package.json의 test 스크립트를 실행합니다. 이 레슨에서는 Vitest를 사용하므로 bun run test가 맞습니다.

모든 테스트가 통과합니다. 이것이 기준선입니다. 현재 코드가 체크리스트의 모든 항목을 만족한다는 증거입니다.

[데모] 기능을 추가해도 기존 기능이 안 깨지는지 자동 확인

테스트의 진짜 가치는 코드가 바뀔 때 드러납니다. 직접 체험해 봅니다.

Step 6: 테스트가 자동으로 검증하는 과정 관찰

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

테스트가 실패하는 경우: 기존 5개 테스트 중 일부가 실패합니다. AI는 실패 메시지를 읽고 원인을 파악합니다. 코드를 수정한 뒤 다시 bun run test를 실행하면 5개 테스트가 전부 통과합니다.

테스트가 모두 통과하는 경우: AI가 테스트 코드를 읽고, 기존 기능과의 호환성을 미리 처리한 것입니다.

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

기존 5개 테스트가 기존 기능을 보호했습니다. 이제 새로 추가한 우선순위 기능도 보호해야 합니다.

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

AI가 우선순위 관련 테스트를 추가합니다. 우선순위 선택, 목록에서 표시 확인 등입니다. bun run test를 실행하면 기존 5개 + 새 테스트가 모두 통과합니다.

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

테스트만이 전부가 아니다

방금 우선순위 기능의 테스트는 기능을 만든 뒤에 추가했습니다. 순서를 바꾸면 어떨까요?

테스트를 먼저 작성하고 기능을 만들면, AI가 처음부터 정답지를 보고 코드를 작성할 수 있습니다. 요구사항을 정리할 때 "이 입력이면 이 결과"라고 구체적으로 적어두면, 그 문장이 곧 테스트 코드의 원본이 됩니다.

가드레일: 테스트만이 유일한 검증 수단은 아닙니다

AI는 제약이 없으면 가장 빠른 경로를 택합니다. 동작하는 것처럼 보이는 코드를 생성하고, 엣지 케이스를 건너뜁니다. 테스트, 타입 체커(TypeScript), 린터 -- 이 세 가지가 AI의 가드레일입니다. 공통점은 텍스트로 피드백한다는 것입니다. "Property 'name' does not exist" 같은 에러 메시지를 AI가 읽고 스스로 수정합니다. 가드레일이 많을수록 AI가 빠른 길로 빠지지 않습니다. 타입 체커와 린터는 이후 Chapter에서 배웁니다.

핵심 포인트 정리

테스트 = 자동화된 체크리스트: 브라우저에서 수동으로 확인하던 각 항목이 테스트 코드 하나에 대응합니다. AI에게 체크리스트를 주면 테스트 코드로 변환할 수 있습니다
AI 자율 루프: 테스트(정답지)가 있으면 AI는 "코드 작성 -> 테스트 실행 -> 실패 -> 수정"을 스스로 반복합니다. 정답지 없이는 이 루프가 불가능합니다
기존 기능 보호: 새 기능을 추가해도 기존 테스트가 깨지면 AI가 즉시 감지하고 수정합니다. bun run test 한 번이 브라우저에서 5개 항목을 수동 확인하는 것을 대체합니다

FAQ

Q: 테스트 코드를 직접 작성해야 하나요?
- A: AI에게 수동 체크리스트를 주고 변환을 시킬 수 있습니다. 다만 생성된 테스트가 체크리스트의 의도를 정확히 반영하는지는 개발자가 확인합니다
Q: 모든 기능에 테스트가 필요한가요?
- A: 반복 검증이 필요한 핵심 기능 위주로 작성합니다. 스타일 변경 같은 시각적 요소는 테스트로 검증하기 어렵습니다. "이 기능이 깨지면 사용자에게 바로 영향이 가는가?"를 기준으로 판단합니다

이어서 배울 내용

테스트로 기존 기능의 검증을 자동화했습니다. 하지만 새 기능을 만들 때는 계획 단계에서부터 "이게 되면 완료"라는 기준을 포함시켜야 합니다. 다음 레슨에서는 성공 기준 작성부터 테스트 변환, Red Green Refactor 실행까지 전체 흐름을 배웁니다.

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