Slack 리포트가 너무 시끄러웠다
이날은 하루 종일 QA Agent만 파고 있었다.
딱 세 가지. Slack 리포트 다이어트, 캐싱 정책 짜기, 프리셋 기능 붙이기.
전부 같은 맥락에서 나온 작업이다.
QA 에이전트가 커지면서 눈에 띄기 시작한 비효율을 하나씩 잡아낸 날이었다.
그 전까지 QA Agent가 Slack에 뱉는 결과가 생각보다 장황했다.
케이스 결과도 길고 스크린샷이 올라와도 그게 어느 페이지인지 맥락이 없었다.
케이스 제목도 검증 관점을 잘 안 드러내서 결과를 받아보는 사람이 “이 케이스가 뭘 검증하려는 거지”부터 다시 생각해야 했다.
그래서 출력을 전부 간결하게 줄였다.
스크린샷에는 페이지 URL을 같이 넣어서 장면만 보고도 어디인지 알 수 있게 만들었다.
그리고 케이스 제목을 “검증 조건 우선”으로 바꿨다.
예를 들어 “로그인 화면 케이스”처럼 모호하게 짓던 걸, “비밀번호 틀렸을 때 에러 메시지 노출되는지”처럼 검증하려는 걸 제목부터 드러내게 바꿨다.
결과를 읽는 사람 입장에서는 그 제목만 봐도 이 케이스가 뭘 확인하려는 건지, 통과했는지 실패했는지 한눈에 들어온다.
매번 처음부터 계획하는 비용
근데 출력 정제보다 더 큰 문제는 실행 비용이었다.
QA Agent는 실행될 때마다 Planning 단계를 처음부터 다
돌린다.
시트에 있는 테스트 케이스를 분석하고 의존성 그래프를 짜고 실행 순서를 정하는 과정이다.
근데 같은 시트를 다시 실행할 때도 이걸 처음부터 반복하고 있었다.
케이스가 바뀌지 않았는데도 매번 다시 계획하는 거다.
토큰도 시간도 그냥 새고 있었다.
삼 일 전에 Fixture Knowledge를 JSON에서 SQLite로 바꾸면서 URL 단위로 실행 지식을 재사용할 수 있게 된 상태였다.
같은 URL을 다시 방문하면 이전에 알아낸 fixture 데이터를 그대로 가져다
쓸 수 있었다.
이걸 Planning에도 적용할 수 있겠다고 생각했다.
시트 단위 캐시
그래서 시트 단위 캐시 구조를 만들었다.
한 번 실행한 시트의 Planning 결과를 캐싱해두고 다음에 같은 시트를 실행할 때는 전체 플래닝을 생략한다.
여기서 핵심은 “변경된 케이스만 부분 재계획”이다.
시트 전체를 다시 계획하는 게 아니라, 바뀐 케이스만 다시 플래닝하고 나머지는 캐시된 계획을 그대로 쓴다.
이렇게 하니까 같은 시트를 반복 실행할 때 비용이 확 줄었다.
실행 지식을 스킬로 쌓기
캐싱만 한 게 아니라, 성공한 케이스에서 얻은 실행 지식을 스킬로 승격시키는 수명주기도 정의했다.
Executor가 케이스를 실행하면서 단계를 기록하고 실행이 끝나면 그 기록에서 패턴을 추출한다.
범용성이 있다고 판단된 패턴은 스킬 디렉토리로 올린다.
그러면 다음 실행 때 Planner가 관련 스킬을 조회해서 활용한다.
케이스 특화 지식은 SQLite에, 도메인 범용 패턴은 스킬 디렉토리로 분리했다.
무엇이 한 케이스에만 통하는 지식이고 무엇이 여러 케이스에 재사용할 수 있는 지식인지 경계를 명확히 한 게 핵심이다.
자가 학습 루프가 만들어진 셈이다.
모델 설정이 코드에 흩어져 있던 문제
마지막으로 모델 설정을 정리했다.
그 전까지는 모델 설정이 런타임에 인라인으로 흩어져 있었다.
어디서는 하드코딩, 어디서는 환경변수, 어디서는 설정 파일. 관리하기가 어려웠다.
그래서 provider별 preset 모듈로 모델 구성을 분리했다.
어떤 역할에 어떤 모델을 쓸지 preset에서 정의하고 런타임 인라인 설정은 다
빼버렸다.
Planner는 이 모델, Executor는 저 모델 하는 식으로 한곳에서 관리한다.
이 결정이 나중에 꽤 큰 역할을 했다.
설정이 한곳에 모여 있으니까, Executor가 첫 번째 모델에서 실패했을 때 완전히 다른 모델 패밀리로 넘어가는 크로스 프로바이더 재시도를 붙이기가 쉬웠다.
같은 벤더 안에서 승급하는 게 아니라, 모델 자체를 바꿔서 시스템적 실패를 회피하는 구조다.
마무리
내가 이날 배운 핵심은 다음과 같다.
하루 세 가지 작업이 전부 이어져 있었다.
Slack 리포트를 읽기 좋게 만들고 실행 비용을 캐싱으로 없애고 설정을 preset으로 정리했다.
따로 보면 각자 사소해 보이는데, 전부 “QA 에이전트가 커지면서 드러난 비효율”이라는 같은 뿌리에서 나온 작업이었다.
캐싱 정책은 특히 체감이 컸다.
같은 시트를 반복 실행할 일이 꽤 있는데, 매번 전체 플래닝을 생략하니까 실행 시간이 눈에 띄게 줄었다.
그리고 실행 지식이 스킬로 쌓이면서 돌릴수록 똑똑해지는 구조가 만들어졌다.