왜 테스트가 여전히 망가진 느낌일까 (AI와 MCP 도구를 사용해도)

Source: Dev.to

🚨 실제 문제

우리는 테스트가 만들어지는 방식은 개선했지만 테스트가 이해되는 방식은 개선하지 못했습니다.

오늘날, AI가 있더라도:

• 도구가 스크립트를 생성한다
• 도구가 테스트를 실행한다
• 도구가 로그를 제공한다

테스트가 실패하면 우리는 다시 같은 루프로 돌아갑니다:

1. 로그 열기
2. 스크린샷 확인
3. 비디오 재생
4. 재현 시도
5. 추측

😤 AI가 해결하지 못한 것

AI 덕분에 테스트를 더 빨리 작성할 수 있게 되었지만, “왜 테스트가 실패했는가?” 라는 질문은 여전히 가장 많은 시간을 잡아먹습니다.

⏱️ 숨겨진 비용

실패한 테스트는 단순히 실패가 아닙니다. 그것은:

• 디버깅에 15~30분
• 여러 도구가 관여
• 개발과 QA 사이의 컨텍스트 전환

그리고 때로는 실제 문제가 아닌 (그냥 불안정한) 행동일 수도 있습니다.

💡 실제로 부족한 것

우리는 더 많은 테스트 생성이 필요하지 않습니다. 테스트 인텔리전스가 필요합니다 – 다음을 할 수 있는 시스템:

• 실패를 일상적인 영어로 설명
• 실행 간에 불안정한 패턴 감지
• 실패를 코드 변경과 연결
• 다음에 무엇을 테스트할지 추천

🔄 테스트에 대한 다른 사고 방식

다음과 같이:

Generate → Run → Debug manually

만약 이렇게 된다면 어떨까요:

Generate → Run → Understand instantly

⚙️ 예시

일반적인 “Element not found” 대신에 다음과 같은 메시지를 상상해 보세요:

“최근 CSS 변경 후 헤더 컴포넌트에서 레이아웃 이동으로 로그인 버튼이 이동했습니다”

이는 다음 사이의 차이입니다:

• ❌ 데이터
• ✅ 이해

🛠️ 실질적인 의미

오늘날 최신 테스트 스택을 사용하고 있다면:

• 이제 테스트 작성에 더 이상 고생하지 않습니다.
• 실패를 이해하는 데 고생하고 있습니다.

대부분의 디버깅은 메인 워크플로우 밖에서 이루어지며, 바로 그곳이 대부분의 팀이 시간을 잃는 지점입니다 – 실행이 아니라 조사 때문입니다.

🧠 핵심 인사이트

테스트가 깨진 이유는 자동화가 부족해서가 아니라 인사이트가 부족해서입니다.

🚀 앞으로의 방향

다음 단계의 테스트는 다음과 같지 않을 것입니다:

• 더 많은 프레임워크
• 더 많은 스크립트
• 더 많은 AI‑생성 코드

대신에:

• 설명하는 시스템
• 실패에서 학습하는 시스템
• 테스트 결정을 안내하는 시스템

아직 초기 단계이며, 진심으로 피드백을 받고 싶습니다.

💬 여러분의 의견을 듣고 싶어요

워크플로우에서 더 많은 시간을 차지하는 것은 무엇인가요 – 테스트 작성인가요, 아니면 디버깅인가요?