ATDD: “맞다”의 기준을 먼저 정하는 개발

코드를 먼저 작성하고, 맞는지는 나중에 확인합니다. 많은 팀이 이렇게 일합니다.

기능을 만들고 나서 “이거 맞아?”라고 묻습니다. 맞는지 판단할 기준이 없으니 감으로 판단합니다. “되는 것 같은데요”가 완료의 기준이 됩니다.

AI가 코드를 빠르게 만들어 주면서 이 문제가 더 커졌습니다.¹ 기준 없이 빠르게 만들면, 기준 없이 빠르게 쌓입니다. 확인해야 할 것은 많아지는데 확인할 기준은 여전히 없습니다.

ATDD는 이 순서를 뒤집습니다.

ATDD는 Acceptance Test-Driven Development, 인수 테스트 주도 개발입니다. 핵심은 하나입니다. “맞다”의 기준을 코드보다 먼저 정하는 것이죠.

스펙을 먼저 쓰는 것과 같은 방향입니다.² 스펙이 “무엇을 만들 것인가”를 정의한다면, 인수 테스트는 “어떻게 되면 맞는 것인가”를 정의합니다. 스펙이 계약서라면, 인수 테스트는 검수 기준입니다.

구체적으로 이렇습니다.

사용자가 로그인하면 대시보드로 이동한다.

이것은 스펙입니다.

올바른 이메일과 비밀번호를 입력하면 대시보드 화면이 보인다.
잘못된 비밀번호를 입력하면 에러 메시지가 보인다.
세 번 실패하면 계정이 잠긴다.

이것이 인수 테스트입니다.

스펙은 동작을 서술합니다. 인수 테스트는 성공과 실패를 구분합니다. 이 구분이 있어야 “맞다”를 판단할 수 있습니다.

인수 테스트를 먼저 정하면 세 가지가 달라집니다.

첫째, 모호함이 사라집니다. “잘 동작해야 한다”는 기준이 아닙니다. “이 입력에 이 결과가 나와야 한다”가 기준입니다. 개발자도, 기획자도, AI도 같은 문장을 봅니다.

둘째, 검증이 자동화됩니다. 인수 테스트를 코드로 옮기면 구현 후 실행만 하면 됩니다. 통과하면 됐고, 실패하면 안 된 겁니다. 눈으로 하나하나 확인할 필요가 없습니다.

셋째, AI를 더 잘 쓸 수 있습니다. 기준이 있으면 AI에게 구현을 맡기고 테스트로 결과를 확인합니다. 기준이 없으면 AI가 만든 것을 사람이 하나하나 확인해야 합니다. AI가 빠를수록 확인할 것이 많아집니다.³

절차는 단순합니다.

사용자 관점에서 시나리오를 씁니다. 성공 조건을 테스트 케이스로 변환합니다. 구현 전에 테스트를 실행합니다. 실패합니다. 구현합니다. 테스트를 다시 실행합니다. 통과하면 완료입니다.

핵심은 두 가지입니다. 구현 전에 실패하는 테스트가 있다는 것. 구현 후에 통과 여부로 완료를 판단한다는 것. 이것이 감으로 판단하는 것과 기준으로 판단하는 것의 차이입니다.

이 방식은 새로운 게 아닙니다.⁴ 오래전부터 좋은 방법이라고 알려져 있었습니다. 현실의 제약 때문에 제대로 하기 어려웠을 뿐입니다. 인수 테스트를 먼저 쓰는 데 시간이 들었고, 시나리오를 구체화하는 것도 번거로웠습니다. 그래서 생략했습니다.

AI가 이 부담을 줄여줬습니다.

시나리오를 AI와 함께 쓸 수 있습니다. 인수 테스트를 AI가 코드로 변환해 줍니다. 스펙대로 구현하는 것도 AI가 합니다. 기준을 정의하는 비용이 낮아졌습니다. 기준 없이 개발할 핑계가 없어졌습니다.

다음 기능을 개발할 때, 코드를 작성하기 전에 질문해 보세요. “이 기능이 올바르게 동작한다는 건 무슨 뜻인가?”

그 답을 테스트 문장 세 개로 적어 보세요. 그것이 ATDD의 시작입니다.