AI 기반 QA 시스템에서 결정의 재현성과 검증 가능성

요약

스킬을 작은 결정 노드로 쪼개고 각 결정을 규칙이나 데이터에 연결하자 결과가 더 일관되게 나왔다. 스토리 B에서 실행 간 시나리오 겹침은 QABuddy가 0.71, 후속작이 0.93에서 1.00이었다.
비용이 낮다. Haiku 러너를 사용하면 스토리당 평균 $0.61이 들고, QABuddy는 $1.51이다.
모든 결정은 그 결과를 만든 규칙이나 데이터까지 따라가 확인할 수 있다.
더 빠르지는 않다. 우선순위와 테스트 레이어의 일치율도 Opus 5.5를 사용한 QABuddy와 비슷하다.

옛 스킬이 답하지 못한 질문

QABuddy의 /qa-test-cases에 이 시나리오가 왜 P0인지 물으면, 정직한 답은 "모델이 그렇게 판단했다"였다.

기존 스킬은 긴 프롬프트 하나로 동작한다. 티켓과 레퍼런스, 학습 자료를 읽고 시나리오, 테스트 레이어, 심각도, 우선순위를 한 번에 작성한다. 그 과정 어딘가에서 판단이 내려진다. 하지만 어떤 규칙이 그 판단을 만들었는지, 애초에 규칙이 있었는지 디스크에는 아무 기록도 없다.

9월의 평가 작업에서 이 문제가 드러났다. 루브릭 심판은 출력에 점수를 매길 수 있었지만, 그 출력이 왜 맞거나 틀렸는지는 설명하지 못했다. 스킬 자체가 무엇을, 왜 결정했는지 기록하지 않았기 때문이다. 같은 스토리를 두 번 실행하면 서로 다른 계획이 나오는 문제도 있었다.

그래서 후속작은 질문을 바꾸는 데서 시작했다.

"더 좋은 프롬프트를 어떻게 쓸까?"가 아니라, "이 스킬 안에는 어떤 결정들이 있고, 각 결정은 무엇을 근거로 내려져야 하나?"

그리고 질문 하나를 더했다.

결정을 이렇게 분해하면 품질을 잃지 않고 비용을 줄일 수 있을까?

1단계: 스킬을 결정 단위로 쪼갠다

후속작의 모든 스킬은 실행 모드 /breakdown에서 출발한다. 스킬을 작은 결정 노드로 분해하는 과정이다.

노드 하나는 답의 범위가 정해진 질문 하나를 담당한다. 각 노드는 근거의 종류도 정확히 하나만 사용한다.

데이터: 실제로 존재하는 정보에서 답을 읽는다. AC의 문장, 기능 목록, 저장소의 테스트 어노테이션, AUTOMATION.md 등이 여기에 해당한다.
플레이북: ID가 붙은 규칙에서 답을 찾는다. 예를 들면 REF-automatability#automatability-conditions다.
판단(담당: QA): 데이터와 규칙만으로 답할 수 없다면 체크포인트에서 사람이 결정한다.

/test-cases는 아홉 개의 노드로 나뉘었다.

N3: AC 하나에 필요한 시나리오를 작성한다.
N3R: AC에 적히지 않은 리스크를 제안한다.
N4: 해당 시나리오를 다루는 기존 테스트가 있는지 확인한다.
N5: 자동화할 수 있는지 판단한다.
N6: 시나리오를 테스트할 수 있는 가장 낮은 테스트 레이어를 고른다.
N7: 시나리오가 실패하면 무엇이 깨지는지 분류한다. 심각도는 이 분류를 바탕으로 코드가 계산한다.
N8: 사전 조건을 갖출 수 있는지 확인한다.

그 사이에 QA가 검토하는 체크포인트가 세 번 있다. 리스크 제안, 자동화 갭, 최종 계획이다.

노드마다 실행자도 정한다.

계산할 수 있는 것은 모두 코드가 맡는다. 범위가 좁은 질문은 도구도 이력도 없는 Haiku급 모델이 맡는다. 프롬프트 하나, 입력 하나, 플레이북 조각 하나만 전달한다. 문장을 작성해야 하는 곳에서만 Sonnet을 사용한다. 현재는 N3와 리스크 제안 노드인 N3R이다.

메인 모델은 러너 역할만 한다. 헬퍼 CLI를 호출하고, 노드 실행을 내보내고, 체크포인트에서 멈춘다.

2단계: 규칙은 체크리스트, 저울질은 없다

플레이북에는 상시 규칙이 두 개 있다.

첫째, 규칙은 체크리스트로 만든다.

결정에 고려할 사항이 여러 개라면, 각 항목을 서로 독립적인 예/아니오 조건으로 나열하고 하나라도 실패했을 때의 기본값을 정한다.

자동화 가능성이 그 예다. 조건은 C1부터 C5까지 다섯 개다.

결과가 테스트의 동작으로 나타나는가?
기계가 읽을 수 있는가?
품질 기준이 아니라 동작에 대한 것인가?
사전 조건을 테스트가 직접 만들 수 있는가?
외부 시스템에 모두 접근할 수 있는가?

모델은 각 조건에 따로 답한다. 조건을 합치는 것은 코드가 맡는다. 모두 예라면 자동화로 분류하고, 처음 나온 아니오가 수동 분류의 근거가 된다.

둘째, 기본 모델은 Haiku로 사용한다.

Haiku가 특정 규칙에 안정적으로 답하지 못한다면 더 큰 모델을 찾지 않는다. 규칙이 지나치게 모호하다고 보고 기존 규칙을 더 잘게 나눈다.

심각도 판단이 이 원칙이 필요한 이유를 보여 준다.

처음에는 모델에게 심각도를 바로 물었다. QA가 라벨을 붙인 시나리오 11개와 비교했을 때 정확도는 약 20%였다.

다시 설계한 노드는 질문을 바꿨다.

"이 시나리오가 실패하면 무슨 일이 생기는가?"

답은 네 가지 중 하나다.

잘못된 입력이 받아들여진다.
기존 데이터가 바뀐다.
기능의 주요 결과가 발생하지 않는다.
부수 효과만 실패한다.

코드는 이 분류를 기능의 등급과 함께 미리 정한 표에 대입해 심각도를 읽는다.

같은 라벨을 기준으로 정확도는 95%까지 올라갔고, 반복 실행 간 자기 일치율도 95%였다.

모델이 심각도를 직접 저울질하는 대신, 발생 결과를 네 가지 중 하나로 분류하도록 바꾼 것이다.

이제 시나리오마다 심각도와 함께 판단 근거도 기록된다.

예를 들어 core/no × side, 3/3 votes는 네 가지 정보를 담고 있다.

core: 해당 기능의 등급은 핵심이다.
no: 기능이 실패하면 우회 경로가 없다.
side: 해당 시나리오가 실패하면 부수 효과만 깨진다.
3/3 votes: 세 번의 투표가 모두 같은 답을 냈다.

코드는 앞의 세 값을 심각도 표에 대입해 행 하나를 찾는다. 따라서 최종 심각도뿐 아니라 그 심각도를 만든 표의 행까지 가리킬 수 있다.

3단계: 엔진이 모델을 정직하게 붙든다

8월에 QABuddy에서 분리한 컨텍스트 엔진 Akela는 플레이북을 스킬 단위가 아니라 노드 단위로 컴파일한다.

각 노드는 자신이 결정하는 데 필요한 규칙만 전달받는다. 답변에는 규칙 ID를 인용해야 하고, 러너는 해당 ID가 노드에 전달된 규칙 조각 안에 있는지 확인한다. 만들어 낸 ID는 거부된다. 한 시뮬레이션에서 이 장치가 실제로 잘못된 ID를 잡아냈다.

작은 결정 노드는 토큰 비용도 적다.

도구 없는 전용 에이전트로 노드 하나를 호출하면 약 2.1k 토큰이 든다. 같은 호출을 범용 에이전트로 처리하면 시스템 프롬프트만 약 52k 토큰을 사용했다.

QA의 수정도 기록에 남는다.

QA가 체크포인트에서 심각도를 바꾸면 Akela는 모델의 원래 답을 함께 보존하면서 수정된 판단을 결정 사례로 기록한다.

/learn은 같은 방향의 결정 사례가 두 개 이상 있을 때만 프로젝트 규칙 초안을 작성한다. 기록된 모든 결정과 초안이 충돌하지 않는지 확인한 뒤 QA의 승인을 받는다.

플레이북은 모델이 무언가를 알아챘다는 이유로 바뀌지 않는다. 결정 사례가 쌓이고, 기존 기록과의 충돌 여부를 확인하고, QA가 승인한 뒤에야 바뀐다.

4단계: QABuddy와 qa-skills-x를 비교한다

일관성 테스트를 진행했다.

하나의 에픽에서 스토리 세 개를 골랐다. 각 도구를 독립적으로 세 번 실행하고, Opus 심판을 사용해 같은 동작을 테스트하는 시나리오끼리 묶었다.

기준선은 QABuddy의 /qa-test-cases였다. 각 실행은 저장소를 새로 복사한 상태에서 시작했다. 따라서 같은 스토리의 실행은 모두 동일한 저장소 상태에서 출발했다.

시나리오 집합 겹침은 세 실행을 두 개씩 짝지은 세 쌍의 Jaccard 유사도 평균이다. Jaccard 유사도는 두 실행에 공통으로 나온 시나리오 묶음 수를 둘 중 하나라도 나온 시나리오 묶음 수로 나눈 값이다. 1.00이면 세 쌍 모두 같은 목록이었다는 뜻이다.

스토리	내용	시작할 때 저장소에 있던 테스트	결과가 보여 주는 것
A	객실 상세와 손님 예약	14개	기존 테스트가 각 도구의 결과를 어떻게 바꾸는지
B	관리자 로그인	없음	두 도구의 직접 비교. 셋 중 가장 작은 스토리이기도 하다
C	관리자 객실 관리	3개	기존 테스트가 조금 있는 스토리

기존 테스트에는 옛 TC 번호만 붙어 있다. QABuddy는 해당 테스트를 읽고 기존 커버리지로 분류한다. 반면 후속작은 시나리오 ID 어노테이션이 붙은 테스트만 인식한다.

따라서 초기 실험에서는 스토리 A와 C에서 두 도구가 서로 다른 초기 상태를 가졌다. 최종 비교에서는 기존 테스트에 시나리오 ID를 붙여 초기 상태를 맞췄다.

첫 결과는 기대에 미치지 못했다.

후속작의 시나리오 집합은 비교적 잘 겹쳤지만, 우선순위 레벨의 실행 간 일치율은 QABuddy보다 나을 게 없었다. 분류만 담당하는 심각도 노드가 그렇게 흔들릴 리 없다고 생각했다.

N7만 고정 입력으로 다시 실행해 보니 원인이 드러났다. 같은 입력에서 세 번의 반복 모두 동일한 우선순위 레벨을 반환한 비율은 86%뿐이었다. 우선순위가 Haiku의 불안정한 판단에 영향을 받고 있었다.

N7은 시나리오가 실패하면 무엇이 깨지는지 네 가지 중 하나로 분류한다. 코드는 그 분류를 바탕으로 표에서 심각도를 읽는다.

세 가지를 수정했고, 각각의 효과를 확인한 뒤 반영했다.

첫째, 세 번 투표한다.

N7은 Haiku에게 세 번 질문한다. 코드는 다수결로 심각도를 고른다. 투표 결과가 갈리면 추측하지 않고 QA에게 질문을 넘긴다.

둘째, 모델이 아니라 시나리오의 형태를 수정한다.

남아 있던 불일치 중 일부는 같은 검증을 실행마다 다른 형태로 작성한 데서 생겼다.

한 실행에서는 "Firstname 3자 허용"이라고 쓰고, 다른 실행에서는 "Firstname 길이 제한 3과 18"이라고 썼다. 그러자 N7이 두 시나리오를 다르게 분류했다.

이제 시나리오 규칙은 바운더리 시나리오가 무엇을 확인하는지 정한다. 바운더리 값은 허용되고 그 바로 바깥 값은 거부된다.

심각도 규칙에는 반복적으로 판단이 뒤집히던 형태를 정리한 짧은 표도 추가했다. 거부된 필드 아래 표시되는 오류, 확인 메시지, 자기 목록에 보이는 레코드 같은 사례다.

셋째, 반영 전에 다른 스토리로 검증한다.

플레이북의 모든 변경은 다른 스토리의 QA 승인 계획에 대고 다시 실행했다.

처음 작성한 "두 번째 페이지에 보이는 변경은 부수 효과"라는 문구는 브랜딩 변경을 Normal로 잘못 분류했다. 한 단어를 바꾸자 문제가 해결됐다.

"그 레코드의 변경이 다른 페이지에도 보인다."

최종 문구는 홀드아웃 시나리오 30개 중 30개에서 승인된 계획과 같았다. 변경 전에는 29개였다.

각 수정 사항을 반영할 때마다 같은 스토리 세 개를 새로 세 번씩 실행했다.

측정 항목	QABuddy (Opus 5)	후속작 초기	N7 투표 추가	시나리오 형태 규칙 추가	테스트 레이어 결합 수정
시나리오 집합 겹침 (A / B / C)	0.75 / 0.70 / 0.59	0.68 / 0.73 / 0.87	0.79 / 0.77 / 0.84	0.86 / 0.81 / 0.92	0.85 / 0.73 / 0.92
같은 시나리오의 우선순위 레벨 일치	73%	69%	79%	93%	93%
같은 시나리오의 테스트 레이어 일치	80%	93%	93%	80%	93%

넷째 열에서 테스트 레이어 일치율이 80%로 떨어졌다.

처음에는 N6가 흔들린다고 보고 세 번 투표하도록 했지만, 일치율은 그대로였다.

원인은 저장된 답을 코드가 결합하는 방식에 있었다. 브라우저에서 실행되는 시나리오인데, 투표 하나가 "저장된 뒤에야 결과를 확인할 수 있는가?"라는 조건에 "판단 불가"라고 답했다. 코드는 그 답 하나로 시나리오 전체를 "판단 불가"로 만들었다.

하지만 규칙은 조건을 만족하는 테스트 레이어 중 가장 높은 것을 선택하도록 되어 있었다.

모든 투표가 "결과가 브라우저에 보이는가?"에 예라고 답했다면 이 시나리오는 e2e다. 그보다 낮은 API 레이어 조건 하나가 "판단 불가"여도 최종 답은 e2e로 남아야 한다.

코드를 규칙에 맞게 수정하자 일치율은 93%로 돌아왔다. 한 번만 물어도 93%였기 때문에 N6는 다시 한 번만 묻도록 했다.

마지막 열은 새로 실행한 두 번째 묶음이다. 따라서 스토리 B의 시나리오 겹침에는 실행 간 편차가 포함되어 있다.

QABuddy와 비교해 무엇을 얻었나

앞선 측정은 모두 QABuddy를 Opus 5로 실행했다. 당시 사용하던 CLI가 Opus 5.5를 지원하지 않았기 때문이다.

CLI를 업데이트한 뒤 모델을 모두 5.5로 올려 다시 측정했다.

QABuddy는 Opus 5.5로 실행했다. 후속작은 러너를 두 가지로 나눠 실행했다. 러너는 헬퍼를 움직이는 메인 모델이다. 노드는 그대로 유지했다. 결정은 Haiku 5.5가, 문장 작성은 Sonnet 5.5가 담당한다.

이번에는 스토리 A와 C의 기존 테스트에 시나리오 ID 어노테이션을 붙였다. 후속작도 해당 테스트를 인식할 수 있게 되어 두 도구가 같은 초기 상태에서 출발했다. QABuddy는 ID와 관계없이 기존 테스트를 읽으므로 다시 실행하지 않았다.

측정 항목	QABuddy (Opus 5.5)	후속작 (Sonnet 러너)	후속작 (Haiku 러너)
시나리오 집합 겹침 (A / B / C)	0.36 / 0.71 / 0.54	0.86 / 1.00 / 0.93	0.91 / 0.93 / 0.76
같은 시나리오의 우선순위 레벨 일치	88%	96%	93%
같은 시나리오의 테스트 레이어 일치	98%	93%	93%

새 모델만으로 QABuddy의 우선순위와 테스트 레이어 판단은 대부분 안정됐다. 우선순위 레벨 일치율은 73%에서 88%로, 테스트 레이어 일치율은 80%에서 98%로 올랐다.

하지만 시나리오 목록의 일관성은 나아지지 않았다. QABuddy는 같은 스토리를 세 번 실행하면 실행마다 꽤 다른 목록을 내놓는다. 실행 간 겹침은 0.36에서 0.71이었다.

후속작은 0.76에서 1.00 사이였다. 같은 AC에 같은 규칙을 적용하고, 같은 노드가 시나리오를 작성하기 때문이다.

기존 테스트가 없는 스토리 B가 직접 비교하기에 가장 적합하다. QABuddy는 0.71, 후속작은 러너에 따라 1.00과 0.93이었다.

러너 모델은 품질에 거의 영향을 주지 않았다.

제목과 단계, 기대 결과는 N3에서 작성한다. N3는 어느 러너를 사용하더라도 Sonnet으로 실행된다. Haiku 러너에서 남은 불일치는 노드의 답에서 발생했다. 테스트 레이어 조건 하나에 대한 "판단 불가" 응답이나 경계에 걸린 심각도 판단 등이 그 예다.

스토리 C에서는 한 실행의 N3가 "Room #나 Type이 없을 때"라고 썼고, 다른 실행에서는 "Room #와 Type이 모두 없을 때"라고 썼다.

러너로 거슬러 올라가는 불일치는 없었다.

숫자로는 드러나지 않는 변화

세 가지 변화는 측정 결과만으로는 충분히 드러나지 않는다.

모든 결정에 주소가 있다.

테스트 레이어든 심각도든 "차단" 상태든, 그 결정을 만든 규칙이나 데이터의 이름이 붙는다. QABuddy는 무엇을 결정했는지 말할 수 있었다. 후속작은 왜 그렇게 결정했는지를 확인할 수 있는 형태로 기록한다.

작은 모델이 결정한다.

QABuddy의 품질은 모델에 달려 있다. Opus 5에서 Opus 5.5로 바꾼 것이 우리가 한 어떤 작업보다 큰 변화를 만들었다.

후속작에서는 모든 분류를 Haiku가 담당하고 Sonnet은 글만 쓴다. 결정이 불안정할 때 수정한 것은 더 큰 모델이 아니라 더 명확한 규칙이었다.

새 시나리오는 문서에 기대지 않는다.

QABuddy는 계획과 테스트 케이스 문서로 쌓은 지식 베이스를 바탕으로 새 테스트 케이스를 만들었다.

후속작은 기능 목록과 시나리오 ID 어노테이션이 붙은 테스트에서 만든다. 커버리지는 어노테이션을 기준으로 계산한다. 계획과 테스트 케이스 문서가 필요한 팀은 계속 남길 수 있다.

한 번 실행에 드는 비용

직관적으로는 Opus 한 번이 작은 호출 백 번보다 저렴할 것 같다.

하지만 실제 실행은 그렇지 않다. QABuddy의 /qa-test-cases 한 번은 18~29턴으로 이루어진 Opus 세션이다. 각 턴은 점점 불어나는 컨텍스트를 다시 읽는다.

후속작은 스토리당 노드 호출을 23-37번 한다. 대신 각 호출은 짧은 프롬프트 하나만 읽는다.

같은 스토리 세 개를 헤드리스 모드로 각각 세 번 실행해 비용을 측정했다.

비용은 실제 청구서가 아니라 CLI가 실행마다 보고한 값이다. CLI는 모델별 토큰 수에 API 정가를 곱해 비용을 계산한다. 노드와 러너의 비용은 같은 보고서의 모델별 내역에서 나눴다.

측정 항목	QABuddy (Opus 5.5)	후속작 (Sonnet 러너)	후속작 (Haiku 러너)
스토리당 비용	$1.31–$1.70 (평균 $1.51)	$1.49–$2.61 (평균 $1.92)	$0.49–$0.94 (평균 $0.61)
스토리당 시간	3.7–8.7분	6.5–11.2분	4.8–7.3분

Opus 5를 사용했을 때 QABuddy의 비용은 스토리당 $4.20이었다. 당시 후속작은 그 비용의 약 3분의 1 수준이었다.

Opus 5.5로 바꾸자 QABuddy의 비용은 약 3분의 2 줄었다. 그 결과 Sonnet 러너를 사용하는 후속작이 오히려 더 비싸졌다.

그런데 결정 자체에는 비용이 거의 들지 않았다. Haiku 5.5 노드 호출을 모두 합쳐도 스토리당 1-2센트 정도다. 전체 비용의 약 99%는 Sonnet 러너 몫이었다. 헬퍼 출력을 읽고, 작업을 내보내고, 보고서를 작성하는 데 드는 비용이다.

그래서 러너 모델도 양쪽 방향으로 바꿔 시험했다.

Opus 5.5 러너에 시나리오 작성까지 Opus로 맡겼을 때 스토리당 비용은 $3.57이었다. 하지만 실행 간 일치율은 Sonnet 러너보다 나을 게 없었다.

Haiku 러너는 평균 $0.61로 QABuddy 비용의 약 40% 수준이었다. 시나리오 집합 겹침은 0.76에서 0.93이었다.

러너가 하는 일은 기계적이다. 따라서 그 일을 안정적으로 수행할 수 있는 가장 저렴한 모델을 사용하는 편이 낫다.

글쓰기는 Sonnet에 남긴다. 시나리오 작성 비용은 스토리당 약 10센트다.

숫자가 말하지 않는 것

두 도구는 서로 다른 모델 조합으로 실행됐다. QABuddy는 Opus 5.5, 후속작은 Haiku 5.5와 Sonnet 5.5를 사용했다. 첫 번째 표에서는 QABuddy가 Opus 5로 실행됐다.

스토리당 세 번의 실행은 작은 표본이다. 심판 모델 자체에도 약 ±0.05의 편차가 있다.

QABuddy는 실행마다 출력 형식이 일정하지 않다. 스토리 A의 한 실행에서는 기존 테스트 참조가 추출기가 놓치는 형태로 나왔다. 이 때문에 스토리 A의 겹침이 낮아졌다. 새 시나리오만 비교하면 스토리 A는 0.43, 스토리 C는 0.71이다.

기존 테스트는 스토리 A와 C에서 QABuddy가 흔들리는 이유의 일부일 뿐이다. 새 시나리오만 비교해도 후속작이 앞선다. 후속작은 기존 테스트를 읽지 않는데도 스토리마다 겹침이 다르다. 스토리 크기도 영향을 준다는 뜻이다.

시나리오 형태 규칙의 기준은 QA 승인 계획에서 가져왔다. 따라서 그 규칙을 적용하지 않은 다른 스토리에서도 확인했다.

배운 것

투표는 노이즈를 줄이지만, 모호함을 해결하지는 않는다.

세 번의 투표 덕분에 Haiku의 불안정한 판단이 우선순위를 결정하는 문제는 줄었다. 하지만 같은 검증을 서로 다른 형태로 작성한 두 실행에는 아무런 효과가 없었다. 그 문제는 규칙을 고쳐야 해결할 수 있었다.

투표 횟수를 늘리기 전에 이미 받은 답부터 살펴봐야 한다.

테스트 레이어 불일치는 노이즈처럼 보였지만, 실제 원인은 코드가 답을 결합하는 방식에 있었다. 조건별 답이 저장돼 있었기 때문에 쿼리 한 번으로 원인을 찾을 수 있었다.

플레이북의 규칙 한 줄도 코드처럼 검증해야 한다.

예시에서 단어 하나가 빠지자 실제 심각도가 달라졌다. QA가 이미 내린 결정에 대고 규칙을 다시 실행해 보고 나서야 그 문제를 발견했다.

러너에는 기계적인 작업에 맞는 모델을 사용하면 된다.

더 좋은 모델을 러너에 사용한다고 결과가 더 좋아지지는 않았다. Haiku 러너는 비용을 3분의 2 넘게 줄이면서도 같은 시나리오를 만들어 냈다. 시나리오를 작성하는 모델은 한 번도 바뀌지 않았기 때문이다.

그리고 처음의 질문에도 답할 수 있게 됐다.

후속작에게 이 시나리오가 왜 P1인지 물으면, 이제는 표의 한 행을 가리킨다.

결론

출발점의 가설은 이것이었다.

스킬을 작은 결정의 메시로 분해하고, 각 결정에 플레이북 규칙이나 데이터를 근거로 연결하면 더 일관된 결과를 더 낮은 비용으로 얻을 수 있다.

일관성과 비용 측면에서는 가설이 맞았다.

같은 시나리오가 다시 나온다.

기존 테스트가 없는 스토리 B에서 QABuddy의 실행 간 겹침은 0.71이었다. 후속작은 0.93에서 1.00이었다.

비용이 낮다.

Haiku 러너를 사용하면 스토리당 평균 $0.61이 든다. QABuddy는 $1.51이다.

결정의 근거를 가리킬 수 있다.

모든 결정에는 그 결과를 만든 규칙이나 데이터의 이름이 붙는다. 결정이 흔들릴 때도 기록을 따라가면 원인을 확인할 수 있다.

다만 속도와 결정의 일관성까지 개선했다고 말할 수는 없다.

더 빠르지는 않다.

스토리당 실행 시간은 QABuddy가 3.7-8.7분, Haiku 러너를 사용한 후속작이 4.8-7.3분으로 비슷하다.

우선순위와 테스트 레이어의 일치율은 비슷하다.

QABuddy도 Opus 5.5에서는 거의 같은 수준에 도달했다. 차이는 후속작이 그 결정을 Haiku로 내린다는 점이다.