잘 써진 지라 티켓에서 시작되는 AI-Driven QA 문화

Pleos Fleet(FMS)

안녕하세요. Pleos Fleet(FMS)을 담당하는 QA팀 장영재입니다.

티켓만 잘 써도, QA 문서화와 리스크 분석까지 자동으로 이어질 수 있습니다.

스프린트마다 다시 시작되는 술래잡기

저희는 하나의 QA 조직의 각 담당자가 하나의 플랫폼을 담당합니다. 스프린트는 짧은 주기(2주)로 돌아가고, 그 안에서 기획은 계속 다듬어지고 개발은 기획을 따라 움직이며 디자인은 또 그 사이 어딘가에서 갱신됩니다. 문제는 이 세 가지가 같은 속도로 바뀌지 않는다는 데 있습니다.

QA 입장에서는 "지금 이 스프린트에서 무엇을 테스트해야 하는가"라는 가장 기본적인 질문에 답하는 것부터 쉽지 않습니다. 티켓은 계속 쌓이고, 그중 일부는 QA 검증이 필요하고 일부는 필요 없습니다. 어제는 기획 검토 중이던 티켓이 오늘은 개발 완료로 넘어가 있고, 디자인 링크는 스프린트 중간에야 달리기도 합니다. 이 변화를 사람이 매일 손으로 추적하는 방식은, 맡은 업무가 늘어날수록 확실히 한계에 부딪힙니다.

"잘 쓰인 티켓 = AI가 읽을 수 있는 스펙"

저희가 택한 방향은 QA를 위한 새 문서 체계를 또 만드는 게 아니라, 이미 있는 것을 다시 보는 것이었습니다. Jira 티켓에는 원래도 현재 상황, 목적, 기대 효과, Definition of Done, 작업 범위, 그리고 디자인·저장소·기획 문서 링크까지 상당히 충실하게 들어가 있습니다. PM과 기획자, 개발자가 업무 내용 및 이력관리를 위해 채워 온 정보입니다.

즉 "QA를 위해 뭔가를 더 쓰게 하자"가 아니라 "이미 쓰여 있는 것을 AI가 대신 추적하고 정리하게 하자"는 게 출발점이었습니다. 잘 쓰인 티켓 한 장이면, AI가 그 안에서 QA에 필요한 정보를 뽑아낼 수 있다는 전제입니다.

실제로 어떻게 동작하는가

1) QA 대상을 미리 가른다

모든 티켓에 QA 검증이 필요한 건 아닙니다. Jira에 QA 검증 필요 여부를 나타내는 필드를 두고, 이 값을 기준으로 "QA 대상 / 제외 / 미지정" 세 갈래로 나눕니다. 처음에는 티켓의 진행 상태값으로 이걸 판단하려 했는데, 뒤에서 다룰 이유로 방향을 바꿨습니다.

2) 스프린트 단위로 한 번만 조회한다

매일 아침 9시 30분, 클로드가 스킬셋을 통해 진행 중인 스프린트를 조회합니다. 이 과정에서 핫픽스 버전은 별도로 걸러내고 "지금 릴리스가 몇 버전인지"를 규칙 기반으로 판별합니다. 사람이 매번 "이번 릴리스가 뭐였죠?"라고 확인할 필요가 없어집니다.

3) "무엇이 바뀌었는가"를 코드에서 직접 확인한다

QA 대상으로 분류된 티켓에 대해서는, 실제로 연결된 커밋과 변경 내용을 열어서 diff를 확인합니다. 이때 자유롭게 해석하지 않고, 미리 정해둔 파일 경로 → 기능 영역 매핑 규칙을 그대로 적용해서 "이 변경이 프론트인지 백엔드인지, 신규 기능인지 리팩터인지, 어느 기능 영역에 해당하는지"를 뽑아냅니다. 매번 같은 기준으로 판단하게 하려고, AI가 그때그때 다르게 해석하지 않도록 규칙을 고정해둔 부분입니다.

4) 리스크는 초안일 뿐, 결정은 사람 몫

발생 가능성과 영향도를 곱해 리스크 등급 초안을 만듭니다. 다만 이건 어디까지나 초안입니다. QA가 한 번 조정한 등급은 다음 날 자동 갱신에서도 덮어쓰지 않습니다. 자동화가 "제안"은 하되 "결정"은 하지 않는다는 원칙을 지키려는 부분입니다.

5) 두 개의 문서, 하나의 목적

결과물은 두 종류입니다. 하나는 QA 엔지니어가 스프린트 전체 흐름을 보는 문서이고, 다른 하나는 그 아래 자식 문서로 딸린 Test Plan입니다. Test Plan에는 테스트 범위, 테스트 베이시스(디자인 자료 확보 여부), 리스크만 간결하게 정리해서 테스트를 실제로 수행하는 외주사로 전달합니다.

6) 기획이 끝나는 순간을 자동으로 알아챈다

Test Plan의 "테스트 베이시스" 표에서 어떤 티켓이 "디자인 완료" 상태로 바뀌면, 이를 "이제 테스트케이스를 써도 되는 시점"의 신호로 인식하여 문서에 반영해줍니다. 다만 테스트케이스를 자동으로 쓰지는 않습니다. 문서를 받은 사람이 관리 시스템을 직접 확인하고, 필요하다고 판단하면 그때 작성을 합니다.

실제 사례로 보면

최근 스프린트의 한 사례가 이 시스템이 실제로 어떻게 도움이 되는지 잘 보여줍니다. (보안상 내용은 다른 예시로 표시합니다.)

회원 정보 관리 구조를 바꾸는 작업이었습니다. 데이터 구조 자체가 바뀌는 일회성 프로덕션 마이그레이션이었습니다. 이 부분은 기존에 멤버, 삭제 로직 등 영향이 있을 수 있었습니다.

시스템은 이걸 자동으로 "구조 변경으로 인한 회귀 위험 등급 높음"으로 표시해주었습니다. 이후 내용을 파악해 개발자에게 영향받을 것 같은 부분을 짚어 확인을 요청했고, 그렇게 영향 범위를 추리고 나니 테스트를 어디서부터 어디까지 봐야 하는지 파악하는 시간이 크게 줄었습니다.

예상대로 흘러가지 않았던 것들

모든 게 처음부터 매끄럽게 돌아간 건 아닙니다. 두 가지 시행착오를 공유합니다.

티켓 상태값을 믿을 수 없었습니다

이유는 각 담당자 분들이 상태값을 변경하지 않을 때도 있고, 갑자기 된 걸로 처리했다가 바꾸는 케이스도 있기 때문입니다.

그렇기 때문에 매일 업데이트할 때 해당 내용을 변경 사항으로 기록하게 처리하였습니다. 이에 따라 변경사항이 있으면 확인하고, 지라의 변경사항을 보면서 이전과 어떻게 바뀌었는지 확인하여, 기획, 개발, PMO와 일하는 프로세스를 진행하고 있습니다. 즉 이미 데이터는 쌓이니, 그 안에서 저희가 뭘 해야 할지 결정을 바로 할 수 있는 단계가 되었습니다.

스프린트가 종료되지 않은 상태

지라에서 스프린트 단위로 조회를 하다 보니, 스프린트가 닫히지 않는 경우 기존 문서에 업데이트하는 문제가 있었습니다.

이유는 스프린트 종료일이 지나도 담당자가 실제 "스프린트 종료" 처리를 하지 않아, 이전 스프린트와 새 스프린트가 동시에 "활성" 상태로 잡히는 경우가 있었기 때문입니다.

그래서 활성 스프린트가 2개 이상 잡히면 자동으로 아무 쪽이나 골라 진행하지 않고, 그 자리에서 멈춰 사람에게 확인을 요청하도록 했습니다. 스프린트 종료와 릴리스 버전 전환도 서로 다른 신호로 분리해서, 한쪽이 늦어져도 다른 쪽 판단에는 영향을 주지 않게 만들었습니다.

그래서, 이 방식이 남긴 것

결국 이 모든 자동화의 시작점은 새로운 도구가 아니라 "잘 쓰인 티켓"이었습니다. AI는 QA의 판단을 대신하지 않습니다. 대신 사람이 반복적으로 해오던 추적과 정리, 오늘 뭐가 바뀌었는지 확인하고, 어디를 봐야 할지 목록을 만들고, 문서를 최신 상태로 유지하는 일을 대신 맡아줍니다.

그렇게 아낀 시간만큼 QA는 이번 스프린트의 리스크를 판단하고, QA 전 리뷰해야 할 내용을 정리하여 리스크와 테스트 범위를 관리하면서 다음 스프린트와 다른 업무에도 집중할 수 있게 됐습니다.