AI와 테스트

생산성

이제 AI 덕분에 코드를 딸깍으로 생성할 수 있는 시대가 왔다. 생산성은 분명히 올라갔지만, 그만큼 사람이 읽고 검토해야 할 코드의 양도 같이 늘어났다. 매일같이 쏟아지는 코드를 사람이 전부 꼼꼼히 리뷰할 수 있을까? 불가능에 가깝다.

그래서 요즘은 관점을 조금 바꿔보고 있다. 코드를 한 줄씩 리뷰하기보다는, 올바르게 동작한다면 코드도 올바르게 작성된 것 아닐까? 그럼 올바르게 동작한다는 건 또 어떻게 검증할까? 결국 테스트를 통과하면 되는 것 아닐까? 요즘 이런 생각들을 하고 있다. 코드를 읽는 비용은 그대로인데 생성되는 속도만 빨라졌다면, 검증의 무게중심을 사람의 눈에서 테스트로 옮기는 게 자연스럽지 않을까.

테스트를 위한 환경 구성

다행히 테스트를 작성하는 비용도 0에 수렴하고 있다. 이제 제일 중요한 건 에이전트가 테스트를 잘 작성할 수 있는 환경을 만들어주는 일인 것 같다. 테스트에는 여러 종류가 있지만, 그중 e2e 테스트가 실제 환경과 가장 유사하기 때문에 신뢰할 수 있다. 구현 세부사항에 덜 결합되어 있어서 내부 코드가 어떻게 바뀌든 사용자 입장에서 동작이 같으면 통과한다는 점도, AI가 생성한 코드를 검증하기에 잘 맞는다.

e2e 테스트는 Playwright를 사용한다. 에이전트가 Playwright를 잘 활용할 수 있도록 playwright cli와 공식 skills를 붙여줬다. 덕분에 에이전트가 직접 브라우저를 띄워 화면을 확인하고, 셀렉터를 탐색해가며 테스트를 작성할 수 있다. 그리고 AGENTS.md에 e2e 테스트 컨벤션을 정리해서, 에이전트가 매번 일관된 방식으로 테스트를 작성하게 했다. 컨벤션에는 대략 이런 것들을 담았다.

• 인증(auth): 매 테스트마다 반복되는 로그인을 어떻게 준비하고 반복을 줄이는지
• 모킹(msw): API 응답을 어떻게 가로채고 고정하는지
• 테스트 시나리오(cookies): 쿠키로 시나리오별 상태를 어떻게 세팅하는지

이런 규칙이 문서로 명시되어 있으면, 에이전트마다 제각각인 테스트가 아니라 마치 한 사람이 작성한 것처럼 일관된 테스트가 쌓인다.

피드백 루프

마지막으로 에이전트가 스스로 개선할 수 있는 작업의 루프가 필요하다.

에이전트가 코드를 작성할 때는 테스트도 함께 작성하도록 가이드한다. 여기에는 superpowers의 TDD 스킬과, 매일 테스트 커버리지를 채워나가는 루틴을 활용했다. 코드보다 테스트를 먼저 쓰게 하면, 에이전트가 무엇이 올바른 동작인지를 먼저 정의하고 거기에 맞춰 구현하게 된다.

그리고 PR을 만들면 CI에서 테스트가 자동으로 수행된다. 테스트가 실패하면 에이전트가 그 결과를 피드백으로 받아서 코드를 다시 고친다. 사람이 일일이 지적하지 않아도, 테스트라는 명확한 신호가 에이전트를 올바른 방향으로 끌고 가는 셈이다.

맺으며

물론 테스트가 모든 걸 보장해주지는 않는다. 하지만 한 번 잡은 버그가 회귀하지 않도록 막아주듯, 에이전트가 같은 실수를 반복하지 않도록 해주는 역할은 충분히 한다.