Claude Code로 테스트 코드 자동 생성하기 — 명령 한 줄로 감시자 만드는 법

'언젠간 짜야지' 하고 미뤄두던 테스트 코드, Claude Code에 파일 하나 던지면 30초 만에 생긴다. 레거시 코드에 테스트가 없어서 손 못 대던 개발자, 테스트 자체가 낯선 입문자 모두를 위한 실전 가이드다.

---

테스트 코드가 왜 필요한가

코드를 짜고 나면 "잘 돌아가겠지"라는 감으로 배포하는 경우가 많다. 그런데 함수 하나를 고쳤더니 전혀 다른 곳이 터지는 상황, 다들 한 번씩 겪어봤을 거다. 테스트 코드는 그 불안을 없애주는 자동화된 검증 절차다.

문제는 그 검증 코드를 짜는 게 또 하나의 일이라는 점이다. 실제 로직을 다 만들고 나서 테스트까지 작성하려면 의욕이 이미 바닥이다. 그래서 대부분의 개발자가 "나중에"를 반복하다 버그가 터진 뒤에야 후회한다.

Claude Code는 이 귀찮은 작업을 통째로 가져간다.

---

명령 한 줄로 테스트 파일 만들기

파일을 열고 아래 명령 하나면 된다.

claude "이 파일의 모든 함수에 대해 Jest 테스트 코드를 작성해줘. 정상 케이스와 예외 케이스 모두 포함해서."

n8n 자동화 환경에서 실측해봤더니 50줄짜리 유틸 파일 기준으로 30초 안에 테스트 파일이 만들어졌다. 생성된 테스트의 95% 정도가 수정 없이 그대로 통과했다. 30분 걸릴 작업이 30초로 줄어든 거다.

생성된 결과물은 대략 이런 구조다.

// calculator.test.js (Claude가 자동 생성한 예시)
const { add, divide } = require('./calculator');

describe('add 함수', () => {
  test('양수 두 개를 더한다', () => {
    expect(add(2, 3)).toBe(5);
  });

  test('음수를 포함한 덧셈', () => {
    expect(add(-1, 1)).toBe(0);
  });

  test('0을 더하면 원래 값이 나온다', () => {
    expect(add(5, 0)).toBe(5);
  });
});

describe('divide 함수', () => {
  test('정상 나눗셈', () => {
    expect(divide(10, 2)).toBe(5);
  });

  test('0으로 나누면 에러를 던진다', () => {
    expect(() => divide(10, 0)).toThrow('0으로 나눌 수 없습니다');
  });
});

---

Claude가 잡아내는 엣지 케이스

일반적인 케이스만 테스트하면 의미가 반쪽이다. 실제 버그는 대부분 경계에서 터진다. null이 들어왔을 때, 빈 배열이 넘어왔을 때, 음수가 입력됐을 때 — 이런 경우를 사람이 하나하나 떠올리는 건 번거롭다.

Claude에게 엣지 케이스를 명시적으로 요청하면 된다.

claude "엣지 케이스 위주로 테스트를 보강해줘. null, undefined, 빈 배열, 음수, 경계값 케이스를 반드시 포함해서."

Claude가 커버하는 케이스 유형을 정리하면 아래와 같다.

케이스 분류	예시
빈 값	null, undefined, ""
경계값	0, -1, Number.MAX_SAFE_INTEGER
잘못된 타입	숫자 자리에 문자열 전달
예외 흐름	에러를 던져야 하는 상황
비동기 실패	Promise.reject, 타임아웃

---

기존 레거시 코드에 붙이는 법

이미 돌아가고 있는 코드가 있어도 상관없다. 파일 경로만 던져주면 Claude가 구조를 파악하고 테스트 파일을 새로 만들어준다.

claude "utils/calculator.js 파일 분석해서 테스트 파일 calculator.test.js 새로 만들어줘"

테스트가 없어서 손 못 대던 레거시 코드, 바로 여기서 돌파구가 생긴다. 테스트가 붙는 순간 "이거 고쳤다가 다른 데 터지면 어떡하지"라는 불안이 사라진다.

전체 디렉토리 단위로 일괄 생성도 된다.

claude "utils/ 폴더 아래 모든 .js 파일에 대해 테스트 파일을 각각 생성해줘. __tests__ 폴더에 넣어줘."

생성 후 바로 실행해서 확인한다.

npm test
# 또는
npx jest --coverage

---

운영 팁과 주의할 점

Claude가 생성한 테스트가 100% 완벽하지는 않다. 비즈니스 로직의 의도까지 파악하지 못하는 경우가 있다. 예를 들어 "이 함수는 음수를 허용하지 않는다"는 규칙이 코드에 명시되지 않았다면 Claude는 그 케이스를 정상으로 처리할 수 있다.

그래서 생성 후 두 가지만 확인한다.

1. expect 값이 실제 비즈니스 의도와 맞는지 눈으로 훑기
2. 실패한 테스트가 있으면 소스 코드 버그인지, 테스트 기댓값 오류인지 구분하기

Mac과 Linux 환경에서는 차이가 없다. Docker 컨테이너 안에서 돌리는 경우라면 node_modules가 마운트됐는지 먼저 확인해야 한다.

---

테스트 코드를 모른다는 건 더 이상 핑계가 아니다. 파일 하나 던지고 명령 한 줄이면 감시자가 생긴다. 테스트 없이 달리던 자전거에 브레이크가 생기는 순간이다.

다음 글에서는 Claude Code로 생성한 테스트를 CI/CD 파이프라인에 연결해서 배포 전 자동 검증하는 흐름을 다룬다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: Code 입문
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독