새로운 기능이나 수정 사항이 나올 때마다, 어떤 사람들은 똑같은 행동을 합니다. 그들은 좋아하는 AI 채팅창을 열고, 요구사항이나 PR 설명을 복사하여 붙여넣은 다음, "이 기능에 대한 테스트 케이스를 생성해 줘"라고 요청합니다. 그런 다음 출력된 내용을 다시 테스트 관리 도구나 메모장에 붙여넣습니다.

이렇게 AI를 사용하는 것 자체는 문제가 없습니다. 작동하니까요. 하지만 이 주변에 수동적인 흐름(manual flow)을 만드는 것은 뭔가 잘못되었다고 생각합니다. 매번 그것을 수행해야 한다는 것을 기억해야 하고, 매번 컨텍스트를 복사하고 붙여넣어야 하며, AI는 당신이 붙여넣기로 결정한 것만 알게 됩니다. 만약 세부 사항을 잊거나, 기능이 언급하지 않은 무언가와 관련된다면, AI도 알지 못합니다.

매번 수동으로 AI 채팅창에 가는 대신, 동일한 LLM을 워크플로우에 통합하여 자동으로 실행되도록 하고 필요한 컨텍스트를 이미 갖게 할 수 있습니다.

제가 최근 직장에서 구축했던 한 예는 PR 레벨에서 실행되는 GitHub workflow입니다.

개발자가 기능 구현이나 수정 사항을 적용하는 PR을 열 때마다, 저희는 "ai:generate-test-cases"라는 레이블을 사용합니다. 누군가 이 레이블을 추가하면, LLM을 호출하는 스크립트를 실행하는 GitHub workflow가 트리거됩니다. 이 스크립트는 전체 PR diff, 댓글, 그리고 MCP를 사용하여 외부 링크까지 읽어 최대한 많은 컨텍스트를 수집합니다. 그런 다음 PR에 가능한 테스트 시나리오 목록, 해당 변경 사항의 위험 수준(risk level), 그리고 개발자가 이미 자동화된 테스트를 추가했는지 여부를 담은 댓글을 남깁니다. 이렇게 하면 우리는 가장 중요한 영역에 집중할 수 있습니다.

전통적인 워크플로우
요구사항
    ↓
...

테스트 케이스 제안은 이것의 단지 하나의 출력물일 뿐입니다. 동일한 컨텍스트, diff, 댓글, 연결된 문서는 위험을 플래그 지정하거나 중요한 것이 누락되었는지 확인하는 데 훨씬 쉽게 사용될 수 있습니다. 테스트 케이스를 생성하는 것은 제가 그것으로 구축한 첫 번째 것일 뿐입니다.

이것은 설계상 선택적(opt-in)입니다. 인프라 관련 PR이나 라벨이 추가되지 않은 모든 PR에서는 아무것도 생성하지 않습니다. 어떤 PR에 테스트 케이스 제안이 필요한지 사용자가 직접 선택합니다. 이는 QA뿐만 아니라, 주요 시나리오를 모두 다루었는지 확인하고 싶어 하는 개발자에게도 유용하며, 생각하지 못했던 결과나 엣지 케이스(edge case)를 발견할 수 있게 해줍니다.

물론 이것이 인간의 판단을 대체하는 것은 아닙니다. 모든 숨겨진 경로가 테스트되었음을 보장하는 것이 아니라, 시나리오를 정리하고 우선순위를 정하는 데 도움을 주는 도구일 뿐입니다. 모든 것을 테스트하는 것은 불가능하기 때문에, 무엇을 테스트할 가치가 있고 무엇이 아닌지는 항상 우리 자신의 경험으로 결정해야 합니다.

AI는 또 하나의 브라우저 탭이 되는 것보다 엔지니어링 워크플로우의 일부가 될 때 훨씬 더 가치 있습니다. 테스트 케이스 생성은 그중 단지 한 가지 예시일 뿐입니다.

만약 이것을 사용해 보거나 자신의 워크플로우에 맞게 조정하고 싶다면, 저장소(repo)는 공개되어 있으며 작동 방식에 대해 기꺼이 이야기 나누겠습니다.