시트 품질이 낮으니까 통과율도 낮다
이날은 smoke 테스트 통과율을 18%에서 60%로 끌어올린 날이었다.
13번 반복하면서 7개 파일을 수정했다.
근데 통과율이 오른 건 한 가지 변화 때문이 아니었다.
세 가지 변화가 합쳐진 결과였다.
첫 번째 원인은 시트 자체의 품질이었다.
QA 에이전트는 노션이나 구글 시트에서 테스트 케이스를 자동 생성한다.
근데 이 시트가 정리가 안 되어 있었다.
memo 필드에 잡음이 많았다.
자동 테스트를 건너뛰는 케이스도 사유 없이 그냥 건너뛰었다.
그러니까 입력 자체가 부실한데 통과율이 높게 나올 리가 없다.
그래서 memo 필드를 정비했다.
진짜 planner에 도움이 되는 정보만 남기고 자동 테스트 건너뛰기에는 반드시 사유를 붙이게 만들었다.
사유 없이 건너뛰는 걸 막으니까 커버리지에 구멍이 생기는 걸 막을 수 있었다.
비전 파이프라인
그리고 노션 기획서에 이미지가 있을 때 그 이미지를 이해하지 못하는 문제도 있었다.
기획서에 UI 목업이나 예상 결과 스크린샷이 있으면 시트 작성 에이전트가 그걸 해석하지 못했다.
그래서 비전 파이프라인을 만들었다.
노션 이미지 블록을 S3에서 내려받아서 비전 에이전트한테 넘겨서 분석한다.
시각적 의도가 실행 가능한 테스트 컨텍스트가 된다.
기획자가 그린 목업을 에이전트가 이해할 수 있게 된 거다.
에이전트 모델 분산
두 번째 원인은 모델 집중이었다.
그 전까지는 5개 에이전트가 2개 모델만 공유해서 쓰고 있었다.
한 모델에 여러 에이전트가 의존하니까 한 모델이 고장 나면 여러 에이전트가 같이 죽는다.
시스템 실패가 연관되어 있는 거다.
그래서 에이전트를 4개 모델로 분산했다.
Inspector랑 Cleaner는 한 모델, Skill-creator랑 Sheet-writer는 다른 모델. 한 모델의 실패 패턴이 전체로 퍼지는 걸 막는 거다.
이 결정은 이후에 더 성숙해진다. 약 두 달 뒤에는 Executor 재시도를 아예 다른 프로바이더 모델로 넘기는 크로스 프로바이더 재시도를 도입했다.
첫 번째 모델에서 실패하면 같은 벤더 안에서 올리는 게 아니라 모델 패밀리 자체를 바꾼다.
한 모델을 신뢰의 단일 지점으로 두지 않겠다는 원칙이 점점 단단해진 거다.
탐색 에이전트 통합
세 번째는 에이전트한테 소스 코드를 읽을 수 있는 길을 열어준 거다.
QA 에이전트가 실행 중에 소스 코드를 봐야 할 때가 있다.
근데 그 전까지는 코드를 읽는 게 까다로웠다.
그래서 탐색 에이전트를 task 도구에서 부를 수 있게 한 줄을 추가했다.
탐색 에이전트는 읽기 전용 서브에이전트다.
다른 QA 에이전트가 소스 코드를 읽어야 할 때 부른다.
자기 자신을 부르지 못하고 테스트를 돌리지도 않고 판정도 내리지 않는다.
오직 코드를 읽어주는 역할만 한다.
Serena 도구는 거절
같은 맥락에서 Serena라는 심볼 기반 코드 편집 도구도 평가했다.
근데 안 쓰기로 했다.
이유가 세 가지 있었다.
타겟 앱이 레일즈인데 레일즈를 지원하지 않았다.
시작이 30초에서 120초 걸렸다.
메모리 오버헤드가 500메가바이트 넘게 들었다.
무거운 도구를 들이는 비용이 이득보다 컸다.
그래서 기존에 쓰던 도구 조합을 유지했다.
무거운 도구를 도입하는 게 항상 정답은 아니다.
가벼운 조합이 더 나을 때가 있다.
13번 반복, 7개 파일 수정
세 가지 변화를 합치니까 smoke 통과율이 올라갔다.
33개 케이스에서 통과율이 18.2%에서 60.6%로 세 배 뛰었다.
13번 반복하면서 7개 파일을 수정했다.
하나의 마법 같은 해결책이 있었던 게 아니다.
시트 품질을 올리고 모델을 분산하고 탐색 에이전트를 붙인 세 가지가 합쳐진 결과였다.
마무리
통과율이 낮을 때 원인은 보통 한 곳에 있지 않다.
이날도 그랬다.
시트 품질, 모델 집중, 도구 부족이 전부 얽혀 있었다.
하나만 고쳤으면 통과율이 크게 오르지 않았을 거다.
세 가지를 다
잡으니까 18%에서 60%로 뛰었다.
그리고 “한 모델에 의존하지 마라”는 원칙이 이때 처음 나왔다.
이 원칙은 이후에 더 단단해져서 크로스 프로바이더 재시도까지 이어진다.
한 모델을 신뢰의 단일 지점으로 두는 건 위험하다.
분산해야 한다.