의존성 판단이 흐릿했다
며칠간 이어오던 QA Agent 안정화 스프린트의 마지막 날이었다.
Planner가 케이스 의존성을 판단하는 방식을 두 질문으로 줄였다.
그리고 실패가 하위 케이스로 연쇄 차단되는 기능을 복구했다.
통과율이 60%에서 73%로 올랐다.
문제는 Planner가 의존성을 판단하는 기준이 흐릿했다는 거다.
그 전까지는 여러 의존성 타입이 있었다.
필수 선행 관계, 도움이 되는 선행 관계, 부드러운 의존성. Planner는 이 여러 관계를 다
추론해야 했다.
근데 LLM한테 이런 흐릿한 어휘로 추론을 맡기니까, 판단이 일관되지 않았다.
실행 순서가 unreliable했고 디버깅도 어려웠다.
그래서 의존성 판단을 아예 두 질문으로 줄였다.
두 질문으로 줄이기
Planner는 이제 케이스 쌍마다 딱 두 질문에 답한다.
첫 번째 질문: UI 상태
이 케이스가 선행 케이스가 만든 UI 상태를 필요로 하는가. 예를 들어 선행 케이스가 모달을 열어뒀거나, 목록을 필터링해뒀거나, 폼을 채워놓은 상태.
이런 UI 상태가 필요하면 의존성이 있다.
두 번째 질문: 런타임 상태
이 케이스가 선행 케이스가 만든 런타임 상태를 필요로 하는가. 예를 들어 로그인 세션이 열려 있거나, 데이터베이스에 엔티티가 생성되어 있거나, 레코드가 존재해야 하는 상태.
이런 서버 상태가 필요하면 의존성이 있다.
이 두 질문에 모두 아니오면, 독립적인 케이스다.
병렬로 돌려도 된다.
하나라도 예면, 선행 케이스가 성공해야 이 케이스를 돌릴 수 있다.
이때만 DAG에 간선이 생긴다.
왜 두 질문이 나은가
이렇게 하니까 판단이 일관되고 재현 가능해졌다.
흐릿한 어휘로 추론하는 게 아니라, 명확한 이진 질문 두 개에 답하는 거다.
LLM이 답하기도 쉽고 결과도 안정적이다.
그리고 디버깅이 쉬워졌다.
의존성 그래프가 왜 이렇게 만들어졌는지 추적할 때, “이 케이스는 UI 상태가 필요해서 의존성이 있다”라고 명확히 알 수 있다.
흐릿한 관계 타입으로는 이 추적이 안 됐다.
실패 연쇄 차단 복구
두 번째 작업은 하위 단계 차단 설정 동작을 복구한 거다.
선행 케이스가 실패하면, 그 케이스에 의존하는 하위 케이스를 자동으로 막아야 한다.
선행이 실패했는데 하위를 돌리면 무조건 실패하니까. 그러니까
실패가 감지되면 하위는 재시도하지 않고 바로 차단 표시를 한다.
근데 이 연쇄 차단이 깨져 있었다.
실패한 케이스의 하위가 제대로 막히지 않았다.
그러니까 하위 케이스들이 돌아가다가 실패했다.
실행 시간이랑 토큰을 날리고 통과율 측정도 왜곡됐다.
이 동작을 복구하니까, 실패한 케이스의 하위가 깔끔하게 차단됐다.
차단된 케이스는 2단계 재시도에서만 다시 돌아간다.
불필요한 실행이 사라진 거다.
통과율 73% 달성
두 가지 변화를 합치니까 통과율이 올라갔다.
30개 케이스 중 22개 통과. 73.3%.
의존성이 정확해지니까, 올바른 순서로 케이스가 돌아갔다.
진짜 의존성이 있는 케이스만 선행을 기다리고 독립적인 케이스는 병렬로 돌았다.
그리고 실패 연쇄 차단이 복구되니까, 실패한 케이스의 하위가 가짜 실패로 측정되지 않았다.
차단으로 깔끔하게 표시되니까, 통과율이 정확해졌다.
이날로 며칠간의 안정화 스프린트가 마무리됐다. 며칠 전 통과율이 18%였다.
시트 품질 개선, 모델 분산, 탐색 에이전트 통합을 거쳐 60%까지 올렸고 이날 의존성 단순화로 73%까지 올랐다.
일주일 만에 통과율이 네 배 뛴 거다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날 핵심은 “복잡함을 빼는 게 더 나은 설계”라는 걸 다시 확인한 거다.
의존성 타입이 여러 개일 때보다, 두 질문으로 줄였을 때 결과가 더 좋았다.
흐릿한 관계를 추론하는 것보다, 명확한 이진 질문에 답하는 게 더 정확했다.
복잡도를 빼니까 성능도 올라가고 디버깅도 쉬워졌다.
소프트 의존성을 없애고, 도구를 걷어내고, 질문을 줄이는 결정들이 전부 같은 방향이었다.
“있으면 좋을 것 같은” 기능을 빼는 게 더 나은 결과를 만든다.
이 원칙이 이 스프린트 내내 증명됐다.