사람은 품질을 판단하고, 시스템은 반복·증적·Gate를 담당하게 합니다.

1. 재현과 최초 문제 정의

아이템 리스트는 애플리케이션 첫 실행 시 UIA 트리에 정상적으로 나타났습니다. 갱신 버튼을 누른 뒤 화면에는 항목이 다시 표시됐지만, 자동화 트리에서는 컨테이너 하위 객체의 연결이 끊겼습니다.

따라서 최초 결함을 “컨테이너가 동작하지 않는다”가 아니라 “동적 객체 재생성 뒤 접근성 객체 생명주기가 복원되지 않는다”로 정의했습니다. 첫 제품에서는 연결 복구와 동적 버튼의 Name 부여만으로 해결했고, 최초 실행·갱신·반복 갱신·Name 기반 탐색을 확인했습니다.

2. 실패한 가설

패밀리 제품의 UI와 기능이 비슷하므로 같은 수정이 작은 회귀 범위로 적용될 것이라 가정했습니다. 하지만 다른 제품은 컨테이너 구성, 하위 객체 생성 순서, 바인딩과 이벤트 연결 방식이 달랐습니다.

실패는 “AI가 코드를 못 만들었다”가 아니라, 제품 간 구조가 같다는 가설을 검증하기 전에 수정부터 확장한 데 있었습니다.

3. Diff에서 발견한 품질 위험

AI Agent는 UIA 결과를 맞추기 위해 컨테이너 내부 구현을 넓게 변경하기 시작했습니다. 이 시점부터 검증 대상은 접근성 트리만이 아니었습니다.

• 갱신 전후 데이터와 선택 상태가 유지되는가
• 바인딩 갱신 순서와 이벤트 중복 호출이 달라지지 않는가
• 기존 클릭·선택·스크롤·필터 동작이 유지되는가
• 반복 갱신 시 객체 누수나 성능 저하가 생기지 않는가
• 같은 컨테이너를 공유하는 다른 화면에 영향이 없는가

UIA 자동화 한 항목을 통과시키기 위해 제품 컨테이너 전체를 재검증해야 하는 상태가 됐습니다. 수정의 효과보다 재검증 비용과 미탐 회귀 위험이 커졌습니다.

4. Reject 기준

코드가 컴파일되고 UIA 객체가 다시 보일 가능성만으로 승인하지 않았습니다. 원래 결함의 책임 범위와 실제 수정 책임 범위를 비교했습니다.

• 원래 책임 범위: 갱신 후 하위 객체의 UIA 연결과 식별자
• 확대된 책임 범위: 컨테이너 생성, 상태, 데이터 바인딩, 이벤트 생명주기

테스트 대상이 수정 목적보다 훨씬 커지는 순간, 그것은 작은 버그 수정이 아니라 별도 리팩터링 프로젝트입니다. 같은 티켓과 같은 승인 기준으로 진행하면 안 됩니다.

작업을 긴급 취소하고 확장 Diff를 폐기했습니다. 최초 제품의 국소 수정은 유지하되, 패밀리 제품은 제품별 구조와 테스트 범위를 다시 정의하기 전까지 보류했습니다.

5. 다음 재시도에 필요한 QA Gate

• UIA Tree Baseline: 최초 실행·갱신·반복 갱신의 하위 객체 수, Name, 탐색 경로를 비교합니다.
• 기능 회귀: 선택·클릭·스크롤·필터·데이터 갱신을 UIA 결과와 별도로 검증합니다.
• 변경 범위 검토: 접근성 수정이 바인딩·이벤트·데이터 모델을 건드리면 별도 승인으로 분리합니다.
• 단일 컨테이너 Canary: 제품군 일괄 적용 전에 한 화면과 한 갱신 경로에서 반복 검증합니다.
• 장시간 검증: 반복 갱신에 따른 메모리, 객체 수, 응답시간 변화를 확인합니다.

6. 이 실패가 보여주는 QA 역량

QA의 역할은 결함을 재현하거나 수정 결과가 한 번 동작하는지 확인하는 데서 끝나지 않습니다. 수정 목적, 변경 폭, 회귀 표면, 검증 가능성을 함께 보고 “이 해결책을 제품에 받아들여도 되는가”를 판정해야 합니다. 이번 사례에서는 미완료를 인정하고 Reject하는 것이 품질 측면의 성공이었습니다.