[Antigravity #6] 테스트 주도 개발(TDD)의 민주화
Editor’s Note
“테스트 코드 짜야 하는 건 아는데… 시간이 없어요.”
이제 핑계는 그만! Antigravity와 함께라면 본 코드(Implementation)보다 테스트 코드를 먼저 짜는 것이 더 쉬워집니다.
진정한 TDD의 세계로 여러분을 초대합니다.
1. 왜 테스트 코드를 안 짤까요?
- 귀찮아서: 기능 구현하기도 바쁜데 똑같은 로직을 또 짜야 함.
- 어려워서: Mocking하고 Stubbing하고 설정할 게 너무 많음.
하지만 테스트가 없으면? “밤새 고친 버그가 다음 날 또 터지는” 악순환에 빠집니다. 이제 AI에게 이 ‘귀찮고 어려운’ 일을 넘깁시다.
다만 테스트를 “AI가 알아서 만들어주는 파일”로만 보면 위험합니다. 테스트의 진짜 가치는 요구사항을 실행 가능한 문서로 바꾸는 데 있습니다. 에이전트에게 테스트를 맡기더라도, 어떤 동작이 맞는지 판단하는 기준은 사람이 먼저 줘야 합니다.
좋은 요청에는 아래 세 가지가 들어갑니다.
- 정상 동작
- 실패해야 하는 입력
- 경계 조건
2. “나 대신 테스트 짜줘” (Generate Tests)
이미 짜둔 코드가 있다면, 테스트를 붙이는 건 식은 죽 먹기입니다.
1
2
"이 `UserAuth` 클래스에 대한 테스트 코드를 Jest로 작성해줘.
특히 로그인 실패, 비밀번호 불일치, 네트워크 에러 상황을 꼼꼼하게 테스트해."
에이전트는 10초 만에 완벽한 userAuth.test.js 파일을 만들어냅니다. 여러분은 npm test를 돌리고 초록색 통과 메시지(PASS)를 감상하기만 하면 됩니다.
여기서 “완벽한”이라는 말은 그대로 믿으면 안 됩니다. 에이전트가 만든 테스트도 리뷰해야 합니다.
확인할 것:
| 항목 | 질문 |
|---|---|
| 의미 있는 검증 | 단순히 함수가 호출됐는지만 보는가, 결과를 검증하는가 |
| 실패 케이스 | 잘못된 입력과 권한 문제를 다루는가 |
| Mock 범위 | 실제로 테스트해야 할 로직까지 가짜로 바꾸지 않았는가 |
| 실행 가능성 | npm test에서 실제로 통과하는가 |
테스트 파일도 제품 코드와 똑같이 리뷰 대상입니다.
3. 진짜 TDD: 테스트부터 짜기 (Red-Green-Refactor)
고수들은 코드를 짜기 전에 테스트부터 짭니다. Antigravity와 함께라면 초보도 고수가 됩니다.
Step 1: 요구사항 던지기
1
2
3
4
5
6
"나 이제부터 '포인트 적립 기능' 만들 거야.
1. 결제 금액의 1% 적립
2. VIP는 2% 적립
3. 적립금이 1000원 넘어야 사용 가능
이 규칙을 검증하는 테스트 코드부터 먼저 짜줘. (구현 코드는 아직 없으니까 당연히 실패해야 함)"
Step 2: 실패 확인 (Red) 🔴
에이전트가 테스트를 돌립니다. 당연히 다 실패하겠죠. (구현체가 없으니)
이 단계에서 중요한 것은 “정말 원하는 이유로 실패했는가”입니다. import 경로가 틀려서 실패했는지, 아직 구현이 없어서 실패했는지, 테스트 기대값이 잘못돼서 실패했는지를 구분해야 합니다.
Step 3: 구현 및 성공 (Green) 🟢
1
"좋아, 이제 이 테스트들이 모두 통과하도록 비즈니스 로직을 구현해."
에이전트가 드디어 코드를 짭니다. 그리고 테스트를 통과시킵니다.
이것이 바로 완벽한 TDD 사이클입니다. 여러분은 ‘감독관’처럼 테스트 통과 여부만 체크하면 됩니다.
마지막에는 Refactor 단계가 남습니다. 테스트가 통과한 뒤 중복을 줄이고 이름을 정리하되, 테스트가 계속 통과하는지 다시 확인합니다.
1
2
이제 테스트는 유지한 채 구현 코드를 더 읽기 좋게 정리해줘.
리팩터링 후 같은 테스트 명령을 다시 실행해줘.
4. 엣지 케이스(Edge Case) 찾기
인간은 늘 ‘행복 회로(Happy Path)’만 돌립니다. “사용자가 당연히 숫자를 넣겠지?” 하지만 사용자는 숫자에 문자를 넣고, 빈칸을 넣고, 특수문자를 넣습니다.
AI는 이런 “예외 상황의 천재”입니다.
“이 코드에서 내가 놓친 엣지 케이스가 있을까? 찾아서 테스트 케이스에 추가해줘.”
라고 물어보세요.
Agent: “금액이 음수(-)일 때, 포인트가 소수점으로 떨어질 때, DB 연결이 끊겼을 때 처리가 안 되어 있습니다. 추가할까요?”
소름 돋을 정도로 꼼꼼하게 잡아냅니다.
엣지 케이스를 물어볼 때도 범위를 주면 더 좋습니다.
1
2
3
입력값, 권한, 시간대, 네트워크 실패, 동시 요청 관점에서
빠진 테스트 케이스를 표로 정리해줘.
바로 코드를 쓰지 말고 우선순위를 먼저 제안해줘.
모든 엣지 케이스를 한 번에 테스트하려고 하면 테스트가 과해질 수 있습니다. 실패 비용이 큰 조건부터 넣고, 단순한 구현 세부사항은 테스트하지 않는 균형이 필요합니다.
5. AI와 함께하는 테스트 루틴
실무에서는 아래 루틴이 가장 안정적입니다.
- 사람이 요구사항과 성공 기준을 쓴다.
- 에이전트가 테스트 초안을 만든다.
- 사람이 테스트 이름과 기대값을 리뷰한다.
- 에이전트가 구현한다.
- 테스트, lint, build를 실행한다.
- 실패하면 원인과 수정 범위를 보고받는다.
이 흐름을 지키면 AI가 빠르게 움직이면서도, 테스트가 엉뚱한 방향으로 굳어지는 일을 줄일 수 있습니다.
6. 오늘의 요약
- 테스트 코드는 AI에게 초안을 맡기되, 기대값과 우선순위는 사람이 정한다.
- “먼저 테스트 짜줘 -> 실패 이유 확인 -> 통과하게 구현해줘” 순서로 일하면 안정성이 올라간다.
- AI에게 “내가 뭐 놓쳤어?”라고 물어보면 경계 조건을 찾는 데 도움이 된다.
테스트까지 완벽해졌습니다. 그런데 매번 “테스트 돌려줘”, “변수명 확인해” 라고 말하기 귀찮지 않나요? 다음 편 [Antigravity #7] 에서는 나만의 규칙을 파일 하나에 적어두고 AI가 일관된 기준을 참고하도록 만드는 Rules 시스템을 배웁니다.