🧑🏻💻 Ep.11 | AI에게 테스트를 맡기기 전에 알아야 할 것
테스트 커버리지 80%. 숫자만 보면 꽤 괜찮습니다. 그런데 장애가 터졌습니다. 커버리지가 높았는데 왜 못 잡았을까. 테스트를 열어보면 답이 보입니다. 전부 해피 패스만 검증하고 있었습니다.
AI는 테스트 코드를 빠르게 만들어줍니다. 하지만 "무엇을 테스트할지"는 알려주지 않습니다.
1. 테스트가 있는데 불안한 이유
테스트가 많다고 안심이 되지 않는 경우가 있습니다. "테스트 있으니까 괜찮겠지"라는 전제로 배포했는데 프로덕션에서 터지는 경험. 한 번 겪으면 테스트 자체를 의심하게 됩니다.
대부분의 경우 원인은 같습니다. 테스트가 있느냐가 아니라, 무엇을 테스트하고 있느냐의 문제입니다.
AI에게 "이 서비스의 테스트를 작성해줘"라고 말하면 빠르게 만들어줍니다. 메서드마다 테스트를 붙이고, 커버리지 숫자도 올려줍니다. 하지만 그 테스트가 실제 장애 시나리오를 검증하고 있는지는 별개의 문제입니다.
2. AI가 잘 만드는 테스트, 못 만드는 테스트
AI가 잘하는 테스트가 있습니다.
✔️ 단일 함수의 입출력 검증
✔️ 정상 흐름(해피 패스) 테스트
✔️ DTO 변환, 유틸리티 함수 같은 순수 로직
반면 이런 테스트는 잘 못 만듭니다.
✔️ 동시에 두 사용자가 같은 쿠폰을 사용할 때 어떻게 되는지
✔️ 외부 API가 타임아웃 나면 재시도 정책이 제대로 동작하는지
✔️ 트랜잭션이 롤백될 때 이벤트가 발행되지 않아야 하는지
차이가 뭘까. 앞의 것은 코드만 보면 됩니다. 뒤의 것은 시스템의 맥락을 알아야 합니다. AI는 코드 구조를 읽을 수 있지만 운영 환경에서 어떤 일이 일어나는지는 모릅니다.
3. 테스트 피라미드를 다시 생각하기
유닛 테스트를 많이, 통합 테스트를 적당히, E2E 테스트를 적게. 전통적인 테스트 피라미드입니다. AI 시대에도 구조 자체는 유효합니다.
달라지는 건 각 층의 역할 분담입니다.
유닛 테스트는 AI가 빠르게 만들 수 있습니다. 양을 늘리는 건 AI에게 맡겨도 됩니다. 통합 테스트와 E2E 테스트는 사람이 시나리오를 설계해야 합니다.
"결제 완료 후 재고가 차감되고, 알림이 발송되는 흐름"을 테스트로 만들려면 시스템 전체 흐름을 이해해야 합니다. 이건 코드 자동 분석으로 나오지 않습니다.
4. 테스트 설계는 사람이, 구현은 AI가
순서를 바꿔야 합니다. AI에게 "테스트 만들어줘"가 아니라, 먼저 무엇을 검증할지 정리하는 것이 먼저입니다.
1️⃣ 이 기능의 핵심 시나리오는 무엇인가
2️⃣ 실패하면 안 되는 경계값은 어디인가
3️⃣ 어떤 외부 의존성이 깨질 수 있는가
이 목록이 정리되면 AI에게 "이 시나리오를 테스트 코드로 작성해줘"라고 구체적으로 시킬 수 있습니다. 설계는 사람이, 구현은 AI가. 코드 작성과 같은 원리입니다.
5. TDD와 AI는 의외로 잘 맞는다
TDD를 한다고 하면 "테스트 먼저 작성하는 거 귀찮지 않아?"라는 반응이 나옵니다. AI가 이 귀찮음을 줄여줍니다.
실패하는 테스트를 먼저 작성하고, AI에게 "이 테스트를 통과시켜줘"라고 말하는 방식입니다. 테스트가 스펙 문서 역할을 하니까 AI도 의도를 명확하게 파악합니다.
"테스트를 만들어줘"보다 "이 테스트를 통과시켜줘"가 훨씬 좋은 결과를 만듭니다.
테스트가 명확하면 AI의 구현도 명확해집니다. 테스트가 모호하면 AI의 구현도 모호해집니다. 입력의 품질이 출력의 품질을 결정합니다.
6. 죽은 테스트를 구분하는 법
시간이 지나면 테스트도 낡습니다. 비즈니스 로직이 바뀌었는데 테스트는 그대로인 경우. 테스트가 통과하지만 실제로는 아무것도 검증하지 않는 경우.
이런 테스트는 있으면 오히려 해롭습니다. 잘못된 안심을 줍니다.
죽은 테스트를 가려내는 기준이 있습니다.
✔️ 테스트를 삭제해도 배포에 영향이 없다면 그 테스트는 가치가 없습니다.
✔️ mock이 실제 구현과 다르게 설정되어 있다면 그 테스트는 현실을 반영하지 않습니다.
✔️ 테스트 이름과 검증 내용이 일치하지 않는다면 혼란만 줍니다.
AI에게 "이 테스트가 실제로 무엇을 검증하고 있는지 분석해줘"라고 시키면 꽤 유용합니다. 코드를 읽는 작업은 AI가 잘하니까요.
7. 테스트 전략은 설계 감각이다
테스트를 잘 작성하는 건 코딩 기술이 아닙니다. "이 시스템에서 무엇이 깨지면 안 되는가"를 판단하는 능력입니다.
이 판단은 장애를 겪어보고, 운영을 해보고, 사용자의 행동을 관찰해본 사람에게서 나옵니다. AI는 이걸 모릅니다. 당연합니다. 운영 경험이 없으니까요.
테스트 코드를 작성하는 건 AI가 빠릅니다. 하지만 무엇을 테스트할지 결정하는 건, 시스템을 이해하는 사람의 몫입니다.
🌱 테스트와 설계 감각을 함께 키우는 곳, 루퍼스
TDD, 테스트 전략, 실전에서의 장애 대응. 혼자 익히기엔 시간이 걸리는 것들입니다. 루퍼스 Loop:PAK에서는 실전 기반의 TDD와 시스템 설계를 함께 경험할 수 있습니다.
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 650+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article