AI 생성 코드에 테스트를 함께 작성하게 만드는 개발 워크플로우

AI 코딩 도구는 기능 코드를 빠르게 만들어주지만, 별도로 요청하지 않으면 테스트는 자연스럽게 빠지는 경우가 많다. 처음에는 기능이 정상적으로 동작하는 것처럼 보여도, 엣지 케이스나 회귀 문제는 시간이 지난 뒤에야 드러나곤 한다. 특히 기존 코드베이스에 AI가 작성한 코드가 계속 쌓이면, 어느 부분을 신뢰해도 되는지 사람이 판단하기가 점점 어려워진다.

테스트를 AI에게 함께 작성하게 하려면 단순히 테스트도 작성해달라고 요청하는 것보다, 요구사항 정리부터 검증까지 이어지는 워크플로우를 미리 정해두는 편이 효과적이다. 요구사항 확인, 테스트 관점 제시, 구현, 실행 검증, 리뷰를 하나의 흐름으로 묶어두면 AI가 기능 코드만 만들고 끝내는 상황을 줄일 수 있다.

테스트를 구현과 함께 다뤄야 하는 이유

테스트는 구현 뒤에 덧붙이는 문서가 아니다

테스트는 코드가 어떤 조건에서 어떤 결과를 내야 하는지 실행 가능한 형태로 표현한 기준이다. AI에게 구현보다 먼저 테스트 관점을 생각하게 하면, 요구사항에서 놓친 부분이 더 빨리 드러난다. 로그인 실패, 빈 입력, 권한 부족, 네트워크 오류처럼 사용자가 직접 언급하지 않은 조건을 테스트 후보로 정리하게 하는 것만으로도 구현 방향이 훨씬 명확해진다.

테스트 범위는 변경의 위험도에 맞춰야 한다

모든 변경에 대규모 통합 테스트를 붙일 필요는 없다. 간단한 유틸리티 함수 수정에는 단위 테스트만으로 충분한 경우가 많고, 여러 모듈이 함께 움직이는 기능에는 통합 테스트가 필요할 수 있다. 결제나 인증처럼 중요한 흐름이라면 종단 간 테스트까지 고려할 수 있지만, 비용이 크기 때문에 핵심 경로 위주로 범위를 잡는 편이 현실적이다. AI에게도 이번 변경의 위험도에 맞는 테스트 수준을 먼저 제안하게 하면 과도하거나 부족한 테스트를 줄일 수 있다.

실패하는 테스트를 먼저 보는 흐름의 가치

가능하다면 실패하는 테스트를 먼저 작성하고, 그 다음 구현으로 통과시키는 순서가 바람직하다. 엄격한 TDD를 그대로 적용하지 않더라도, AI가 만든 테스트가 실제로 한 번은 실패하는지 확인하면 그 테스트가 의미 있는 검증인지 아닌지 판단할 수 있다. 처음부터 통과하는 테스트만 추가하면, 기존 동작을 그대로 확인한 것인지 새로 추가된 요구사항을 검증한 것인지 구분하기 어려워진다.

실제로 적용하는 방법

요청 템플릿을 미리 정해두기

기능을 요청할 때 먼저 테스트 관점 서너 가지를 제안하고, 그중 필요한 테스트를 작성한 뒤 구현하라는 식의 템플릿을 사용한다. 팀의 규칙 파일에 이 문장을 미리 넣어두면 매번 같은 설명을 반복하지 않아도 된다.

엣지 케이스 목록을 구현 전에 받아두기

정상 케이스와 실패 케이스를 나눠서 먼저 정리하게 한다. 빈 값, 잘못된 형식, 권한 부족, 중복 요청, 외부 API 실패처럼 자주 빠지는 조건을 미리 확인해두면 이후 작성되는 테스트의 품질이 눈에 띄게 좋아진다. 이 목록은 리뷰어가 요구사항 누락 여부를 확인하는 데도 유용하게 쓰인다.

기존 테스트 스타일을 먼저 읽게 하기

새 테스트 파일을 작성하기 전에 AI가 기존 테스트 몇 개를 먼저 읽도록 하면, 프로젝트에서 쓰는 assertion 방식, mock 처리 방식, 파일 위치 규칙을 맞추기 쉬워진다. 새로운 테스트 프레임워크를 도입하기보다 기존 관례를 따르는 편이 장기적인 유지보수에 유리하다.

검증 명령을 명확히 고정해두기

테스트를 작성한 뒤 어떤 명령으로 실행해야 하는지 분명하게 정해둔다. 전체 테스트 실행에 시간이 오래 걸린다면, 변경 범위에 맞는 부분 테스트와 최종 확인용 전체 테스트를 구분해서 안내한다. AI에게 실행 결과를 요약하게 하면 실패 원인을 다음 수정 작업에 바로 연결하기 쉬워진다.

주의할 점

AI가 만든 테스트가 구현 내부를 그대로 따라 쓰는 경우가 종종 있다. 예를 들어 내부 함수의 호출 순서만 확인하고 실제 사용자가 보는 결과는 검증하지 않으면, 리팩터링만 해도 쉽게 깨지는 취약한 테스트가 된다. 가능하면 입력과 출력, 화면에 표시되는 결과, 저장된 상태처럼 외부에서 관찰 가능한 동작을 기준으로 테스트를 구성하는 편이 안전하다.

또 하나 흔한 문제는 mock을 과도하게 사용하는 것이다. 모든 의존성을 mock으로 대체하면 테스트 실행 속도는 빨라지지만, 실제 연결에서만 드러나는 문제를 놓칠 수 있다. 단위 테스트와 통합 테스트의 역할을 구분하고, 핵심 경로에는 실제에 가까운 검증을 일부 남겨두는 편이 균형 잡힌 접근이다.

정리

AI가 생성한 코드의 품질을 높이려면 테스트를 별도 단계로 미루지 말고 개발 흐름 안에 포함시켜야 한다. 테스트 관점 제안, 실패 케이스 정리, 기존 스타일 확인, 구현 후 검증 명령 실행까지 하나의 패턴으로 굳혀두면 기능 코드만 빠르게 쌓이는 상황을 줄일 수 있다. 중요한 것은 테스트의 개수가 아니라, 변경으로 인한 위험을 실제로 설명해줄 수 있는 테스트인지 여부다.