QA 에이전트가 잘못 통과시켰다
이날은 며칠간의 변경사항을 하나로 묶어서 푸시한 날이다.
근데 그 안에 세 가지 교훈이 들어 있었다.
QA 에이전트가 요약을 받아서 잘못 통과시킨 일. 같은 모델인데 프로바이더에 따라 60배 느린 것.
프롬프트가 애매해서 한국어가 새어나간 것. 교육 플랫폼에서 화상감독 기능을 만들고 있었다.
검증 메시지가 기획이랑 안 맞았다.
코드에는 “당일 날짜로”라고 돼 있었는데, 기획에는 “오늘 또는 이전 날짜로”라고 돼 있었다.
이걸 QA 에이전트가 통과시켰다.
왜냐면 QA 에이전트한테 기획 원본을 안 주고 요약된 값만 줬기 때문이다.
요약에는 “당일 불가”라고만 돼 있었다.
정확한 문구가 빠져 있으니까, QA 에이전트가 비교를 못 한 거다.
규칙을 네 번 다듬었다
이 일로 QA 에이전트 규칙을 네 번 고쳤다.
첫째, 기획 URL이 있어야 검증을 시작한다.
없으면 멈추고 요청한다.
둘째, 없으면 부분 결과도 내지 않는다.
완전히 멈추고 다시 요청한다.
셋째, 중복 규칙을 합쳤다.
여러 곳에 흩어진 전제 조건을 하나로 모았다.
넷째, 디자인 QA뿐 아니라 모든 작업에 기획 URL 게이트를 적용했다.
그리고 커밋 기록을 스캔해서 스타일 변경이 있으면 기획 URL이 있는지 확인한다.
핵심은 “요약을 주면 안 된다”는 거다.
원본을 줘야 한다.
요약은 정보를 잃는다.
“오늘 또는 이전”이 “당일”로 요약되면, 검증이 의미가 없어진다.
원본 문구를 직접 비교해야 정확한 검증이 된다.
같은 모델인데 60배 느리다
모델을 GLM-5.2로 바꾸면서 프로바이더별 속도 차이를 발견했다.
같은 GLM-5.2인데, 한 프로바이더에서는 1.1초에 응답한다.
다른 프로바이더에서는 60초에서 100초가 걸린다.
60배 차이다.
모델이 같은데 프로바이더가 다르면 속도가 이렇게 차이 난다.
그래서 라우팅 규칙을 만들었다.
GLM 계열은 빠른 프로바이더로만 보낸다.
느린 프로바이더는 GLM이 아닌 모델만 처리한다.
프로바이더가 같아도 경로가 다르다
이건 중요한 발견이다.
“모델이 같으니까 속도도 같겠지”라고 가정하면 안 된다.
프로바이더의 인프라, 라우팅, 캐싱이 다르면 같은 모델도 응답 속도가 달라진다.
모델을 선택할 때 모델 이름만 보면 안 된다.
어느 프로바이더를 통하느냐까지 봐야 한다.
같은 모델이라도 프로바이더에 따라 60배 차이가 난다.
프롬프트가 애매하면 한국어가 새어나간다
프롬프트 언어 규칙이 애매했다.
“한국어로만 응답하라. 설명과 대화 응답은 한국어로”라고 돼 있었다.
근데 “설명”이라는 단어가 애매했다.
서브에이전트 프롬프트도 “설명”으로 읽힐 수 있다.
그래서 서브에이전트 프롬프트에도 한국어가 들어갔다.
한 줄로 줄였다
복잡한 규칙을 한 줄로 줄였다.
“최종 사용자 응답은 한국어로.” 코드랑 식별자는 어차피 영어로 나온다.
그러니까 “코드는 영어로”라고 명시할 필요가 없다.
“한국어로만”이라는 범위도 애매하니까, “최종 사용자 응답”으로 범위를 좁혔다.
프롬프트 규칙은 구체적일수록 좋다.
“설명” “대화 응답” 같은 애매한 단어는 해석이 갈린다.
“최종 사용자 응답”은 해석의 여지가 없다.
마무리
내가 이날 배운 핵심은 다음과 같다.
한 커밋에 세 가지 교훈이 담겼다.
첫째, 요약을 주면 안 된다.
QA 에이전트한테 원본을 줘야 한다.
요약은 정보를 잃는다.
잃은 정보로는 정확한 검증을 못 한다.
둘째, 모델 이름만 보면 안 된다.
프로바이더까지 봐야 한다.
같은 모델이라도 프로바이더에 따라 60배 차이가 난다.
셋째, 프롬프트 규칙은 구체적이어야 한다.
애매한 단어는 해석이 갈린다.
해석이 갈리면 의도와 다르게 동작한다.
이 세 가지는 전부 “정보가 정확하게 전달되는가”에 대한 것이다.
요약이 아닌 원본. 모델 이름이 아닌 전체 경로.
애매한 단어가 아닌 구체적인 지시. 정확한 정보가 정확하게 전달되어야 정확한 결과가 나온다.