PaperlayerView exact revision on arXiv

Source-linked AI summary

GBQA: A Game Benchmark for Evaluating LLMs as Quality Assurance Engineers

Shufan Jiang, Chios Chen, Zhiyang Chen

arXiv:2604.02648v1cs.SEcs.AI

TL;DR

자율적 버그 발견은 에이전트가 실행 중 이상을 인지하고 원인을 국소화해야 하므로 아직 충분히 탐구되지 않았다. GBQA는 대화형 게임에서 이 능력을 평가하며, 최고 성능 모델조차 검증된 버그의 절반 미만을 식별한다는 결과를 제시한다.

  • 문제

    LLM 테스트와 버그 발견은 에이전트가 정확한 작업 설명을 받는 대신 실행 중 이상을 인지하고 그 원인을 국소화해야 하므로 아직 충분히 탐구되지 않았다.

  • 방법

    GBQA는 124개의 human-verified bugs가 포함된 30개의 다양한 게임에서 multi-round exploration과 memory를 갖춘 interactive agent를 사용해 자율적 버그 발견을 평가한다.

  • 결과

    최고 성능 모델인 thinking mode의 Claude-4.6-Opus도 검증된 버그의 절반 미만만 식별한다.

  • 시사점 및 한계

    State-of-the-art LLMs는 버그 발견, 특히 장기 탐색과 상태 의존적 오류 발견에 상당한 한계를 보이며, quality-assurance 요구와의 격차가 여전히 크다.

  • 시사점 및 한계

    이 평가는 발견되지 않은 결함이 human reviewer가 걸러낼 수 있는 false-positive reports보다 더 큰 비용을 초래한다고 보고 recall을 우선시한다.

Abstract

from arXiv · show

The autonomous discovery of bugs remains a significant challenge in modern software development. Compared to code generation, the complexity of dynamic runtime environments makes bug discovery considerably harder for large language models (LLMs). In this paper, we take game development as a representative domain and introduce the Game Benchmark for Quality Assurance (GBQA), a benchmark containing 30 games and 124 human-verified bugs across three difficulty levels, to evaluate whether LLMs can autonomously detect software bugs. The benchmark is constructed using a multi-agent system that develops games and injects bugs in a scalable manner, with human experts in the loop to ensure correctness. Moreover, we provide a baseline interactive agent equipped with a multi-round ReAct loop and a memory mechanism, enabling long-horizon exploration of game environments for bug detection across different LLMs. Extensive experiments on frontier LLMs demonstrate that autonomous bug discovery remains highly challenging: the best-performing model, Claude-4.6-Opus in thinking mode, identifies only 48.39% of the verified bugs. We believe GBQA provides an adequate testbed and evaluation criterion, and that further progress on it will help close the gap in autonomous software engineering.

1 서론

GBQA는 명시적인 이슈 설명 없이 능동적인 이상 탐지, 체계적인 탐색, 실행 시간 동작에 대한 추론을 요구하는, 아직 거의 탐구되지 않은 자율적 버그 발견 문제를 다룬다. 이 benchmark는 사람이 검증한 버그, 확장 가능한 버그 주입, 장기 탐색이 가능한 ReAct agent를 활용해 interactive game에서 이 능력을 평가하며, 최고 성능 모델조차 버그의 절반 미만을 탐지한다는 결과를 제시한다.

  • 동기: 자율적 버그 발견이 어려운 이유는 agent가 명시되지 않은 이상을 인식하고, 방대한 행동 상태 공간을 체계적으로 탐색하며, 예상한 실행 시간 동작과 실제 실행 시간 동작을 비교해야 하기 때문이다.코드 생성이나 수정과 달리 이 과제에는 정확한 목표나 버그 보고서가 없으므로, 이상 인식과 원인 위치 특정을 사람에게 맡길 수 없다.
  • 동기: Game은 내부 상태, 사용자 입력, 렌더링, 장기적인 동적 상호작용, 그리고 명확하게 정의된 action space와 state transition을 결합하므로 대표적인 testbed를 제공한다.이러한 특성은 game을 복잡한 실행 시간 환경에서 구조화된 agent 상호작용을 지원하는 self-contained 환경으로 만든다.
  • Benchmark: GBQA는 3개의 난이도 수준에 걸쳐 124개의 사람이 검증한 버그를 포함하는 30개의 다양한 game에서 자율적 버그 발견을 평가하며, critic agent가 자동 평가를 지원한다.Agent는 game을 탐색하고 잠재적 버그를 식별한 뒤 재현 가능한 단계와 함께 설명을 보고한다.
  • Benchmark 구축: 확장 가능한 multi-agent builder가 제어 가능한 복잡도로 game을 생성하고 버그를 주입하며, human expert가 annotation의 정확성을 검증한다.이 benchmark는 주입된 버그를 Easy, Medium, Hard 범주로 구성한다.
  • 결과: 최고 성능 모델인 thinking mode의 Claude-4.6-Opus조차 장기 탐색을 위한 memory를 갖춘 제공된 multi-round ReAct agent를 사용해 버그의 절반 미만을 식별한다.실험은 자율적 버그 발견의 개선 여지가 크며, 현재 모델의 한계와 실패 양상을 구체적으로 보여준다.

2 관련 연구

기존 software-engineering, interactive-agent, game-based benchmark는 대부분 정상적으로 작동하는 환경에서의 task completion 또는 skill acquisition을 평가한다. 반면 GBQA는 환경을 평가 대상으로 보고 flaw discovery를 측정함으로써 agent를 평가한다.

  • Software Engineering 및 Agent Benchmark: WebArena (Zhou et al., 2024), AgentBench (Liu et al., 2024), SMART (Mu et al., 2025)와 달리, GBQA는 환경 자체를 평가 대상으로 보고 task completion에 flaw discovery rate를 추가한다.이 비교는 환경을 ground truth로 취급하는 경우와 agent가 환경의 flaw를 발견해야 하는 경우를 구분한다.
  • Game-Based Agent 및 Automated Game Testing: Voyager (Wang et al., 2023), MineDojo (Fan et al., 2022), CRADLE, Generative Agents (Park et al., 2023)는 정상적으로 작동하는 game 환경에서 goal achievement와 skill acquisition을 연구한다.TITAN (Wang et al., 2025)과 Orak (Park et al., 2025)은 LLM-assisted game testing을 탐색하므로 GBQA에 더 가깝다.

3 GBQA

GBQA는 자율적 게임 버그 발견을 ground-truth 결함을 포괄하는 재현 가능한 버그 리포트를 생성하는 상호작용적 탐색으로 정의하며, 플레이어 지향 또는 사양 기반 테스트를 가능하게 하는 선택적 문서를 제공한다. 6개 장르에 걸친 30개 게임 환경과 124개의 human-verified bugs로 구성되며, 발견 난이도에 따라 조직되고 주로 recall로 평가된다.

  • Task formulation: 에이전트는 상태를 관찰하고 행동을 선택하며 재현 단계를 포함한 자연어 리포트를 생성하는 방식으로 환경을 탐색하여 ground-truth bugs의 포괄 범위를 최대화한다.각 환경은 E = (S, A, T, s0)로 모델링되며, 목표는 엔지니어가 모든 버그를 재현하고 수정할 수 있을 만큼 충분히 탐지하고 기술하는 것이다.
  • Task formulation: 문서가 없을 때 에이전트는 Player Exploring Mode를 사용하고, 설계 문서나 소스 코드가 있을 때는 정보를 활용한 사양 기반 테스트를 위해 Quality Assurance Mode를 사용한다.두 모드 모두 Section 5에서 평가된다.
  • Benchmark construction: 계층적 multi-agent 게임 개발 시스템은 확장 가능한 구축을 지원하며, 반복적 복잡도 확장은 예비 버그 발견이 임계값 아래로 떨어질 때 기능, 상호작용 또는 내러티브 분기를 추가한다.이 시스템은 producer와 전문 팀 에이전트를 통해 전문 게임 스튜디오를 시뮬레이션한 다음, 탐지된 버그 수가 τ 이상이 될 때까지 구조적 복잡도를 높인다.
  • Benchmark construction: GBQA는 Action, Adventure, Role-Playing, Strategy, Simulation, Puzzle에 걸친 30개의 다양한 게임 환경과 124개의 human-verified bugs를 포함한다.benchmark의 ground-truth bugs는 여러 핵심 게임플레이 장르에 걸쳐 평가할 수 있도록 선별된다.
  • Discovery difficulty: benchmark는 지각, short-horizon 규칙 추론, long-horizon 시간적 일관성 추적에 대한 요구가 증가하는 정도에 따라 버그를 easy, medium, 또는 hard로 분류한다.난이도 구조는 medium bugs를 중심으로 균형을 이루면서도 표면적 결함과 long-horizon 결함을 의미 있는 비율로 유지한다.
  • Evaluation: 평가는 생성된 리포트를 ground-truth bugs와 대응시키고 false positives 회피보다 결함 포괄 범위를 우선시하므로 Recall이 주요 metric이다.critic agent가 리포트와 주석이 달린 버그 사이의 의미적 대응을 판정하며, 실제 QA 워크플로에서는 false negatives를 더 큰 비용으로 간주한다.

4 기준 에이전트

기준 에이전트는 ReAct 기반 interactive exploration을 reflection, verification, feedback grounding, hierarchical memory와 결합해 장시간 gameplay session에서 자율적 bug discovery를 지원한다. 메모리는 단기 trajectory 추적과 session 간 지속되는 경험을 분리해 context 제약하에서 장기 horizon testing을 가능하게 한다.

  • 아키텍처: 기준 아키텍처는 LLM에 dynamic exploration, reflective reasoning, feedback grounding, memory management를 탑재해 장시간 자율 bug-discovery session을 지원한다.
  • Interactive exploration: 각 ReAct step에서 에이전트는 현재 observation을 추론하고, 사용 가능한 tool action을 선택한 뒤, 다음 observation으로 전이한다.
  • Reflection and verification: 각 전이 후 step-level reflection은 관찰된 결과가 에이전트가 예상한 올바른 game behavior와 일치하는지 확인한다.
  • Reflection and verification: 불일치가 발생하면 에이전트는 triggering action, observed behavior와 expected behavior, violation type을 기록한 뒤 후보를 재현하고, 충분히 높은 confidence를 가진 bug만 승격한다.Confidence는 재현 가능성과 deviation magnitude에 따라 결정된다.
  • Hierarchical memory: Hierarchical memory는 단기 trajectory tracking과 장기 experiential accumulation을 분리해 장기 horizon bug discovery에서 context-window 한계에 대응한다.
  • Hierarchical memory: Session 간 summary는 explored regions, confirmed bugs, unresolved hypotheses, unexplored branches, priority targets를 보존해 multiple restarts에 걸친 testing을 안내한다.Session 내에서는 최근 interaction을 상세하게 유지하고, 오래된 trajectory segment는 의미적으로 중요한 state information과 causal structure를 보존하는 summary로 압축한다.

5 실험

실험 결과, frontier LLM에서도 자율적 버그 발견은 여전히 어려우며, 성능은 reasoning capability, testing mode, exploration budget, memory의 영향을 받는다. 또한 benchmark와 evaluation pipeline은 강력한 annotation 및 critic-agent validation을 거친다.

  • 주요 결과: 보고된 Recall 중 최고치는 48.39%로, Quality Assurance Mode에서 500 steps를 사용한 Claude-4.6-Opus가 달성했으며 버그의 절반 이상을 발견하지 못했다.Table 1은 두 testing mode와 네 가지 step budget에서의 Recall을 보고한다.
  • 주요 결과: Qwen3-32B-Thinking은 33.87%에 도달해 14.52%의 Llama-3.1-70B를 앞서고 18.55%의 Qwen3-235B-A22B와 경쟁하는 성능을 보였으며, 단순한 scale보다 reasoning이 parameter-efficient하다는 점을 보여준다.일반적으로 model size가 커질수록 성능이 향상되지만, 지속적인 multi-step 버그 발견에서는 reasoning capability가 더 큰 efficiency gain을 제공한다.
  • 주요 결과: Quality Assurance Mode는 design artifact와 source code를 통해 specification-driven testing이 가능하므로 Player Exploring Mode를 일관되게 앞선다.실험에서는 네 가지 interaction budget, T ∈{50, 100, 200, 500}을 사용하고 Recall을 primary metric으로 평가한다.
  • 검증: 378개 candidate annotation에 대한 Krippendorff’s α는 0.901에 도달했으며, GPT-5.2는 가장 높은 critic-agent correlation인 ρ = 0.903을 기록해 default backbone이 되었다.이 결과는 human annotation과 automated evaluation 모두의 신뢰성을 뒷받침한다.
  • Step Budget 분석: Easy bug는 대체로 300 steps 이내에 발견되고, Medium bug는 500 steps에서 약 30%에 도달하며, Hard bug는 no clear saturation trend를 보인다.분석에서는 Easy bug를 perceptual checking, Medium bug를 short-horizon reasoning, Hard bug를 longer-horizon reasoning과 연결한다.
  • Memory Ablation: full memory module은 in-session memory와 cross-session memory를 결합해 반복 상태를 줄이고 재탐색을 방지하며, 어느 한 component만 사용하는 경우와 다르다.memory가 없으면 recall이 일찍 포화되고, in-session memory는 cross-session redundancy를 남기며, cross-session memory는 within-session redundancy를 남긴다.

6 결론 … A.3 팀 수준 계획 단계

GBQA는 state-of-the-art LLM이 자율적 버그 발견에서 여전히 상당한 한계를 보이며, 특히 장기 탐색과 상태 의존적 오류에서 그러하다는 점을 보여 주는 확장 가능한 benchmark로 제시된다. 계층적 builder는 Producer Agent, specialized teams, unified proposals, dependency-aware planning을 활용해 상호작용형 game environment를 구축한다.

  • 6 결론: GBQA는 현재 LLM agent의 능력과 실제 quality-assurance 요구 사이에 상당한 격차가 있음을 보여 주며, 특히 장기 탐색 및 상태 의존적 버그 발견에서 그러하다.이 benchmark는 LLM이 code generation과 repair에서 강력한 성능을 보임에도 상호작용형 game environment에서 자율적 버그 발견을 평가한다.
  • A 게임 environment builder의 세부 사항: builder는 일반적인 prompt chaining 대신 studio에서 영감을 받은 계층적 multi-agent architecture를 사용해 game environment 개발을 조정한다.Producer Agent는 전역 project state를 유지하고, 하위 개발을 이끌며, team deliverable이 완료된 뒤 통합된 environment를 취합한다.
  • A.1 하향식 studio 조직: 세 specialized teams—Design, Programming, Art—은 directive를 세분화하고, worker 규모를 조정하며, deliverable을 검증하고, Producer와 진행 상황을 동기화하는 leader의 감독을 받는다.각 leader는 각각 Lead Designer, Technical Director, Art Director이며, 단순히 message를 전달하는 데 그치지 않고 execution을 적극적으로 관리한다.
  • A.1 하향식 studio 조직: 각 team은 문서, code, asset을 위한 독립된 workspace에서 작업하므로 Producer의 process는 distributed multi-workspace pipeline이 된다.workspace는 ./project/docs, ./project/code, ./project/assets이다.
  • A.2 Producer 수준 proposal 형성: team execution에 앞서 Producer는 unified project proposal에서 genre, reference title, narrative 및 gameplay loop, aesthetic guideline을 정의한다.이 proposal은 하위 개발을 위한 전략적 방향을 확립한다.
  • A.2 Producer 수준 proposal 형성: 이 proposal은 authoritative specification으로 기능한다. Design은 rule을 도출하고, Programming은 environment와 interaction API를 구현하며, Art는 asset을 명시된 style에 맞춘다.세 team은 공유된 proposal을 documentation, implementation, visual production으로 변환한다.
  • A.3 팀 수준 계획 단계: team leader는 workload와 criticality를 추정하고 Task Dependency and Priority Graph를 구성해 high-level directive를 atomic worker task로 변환한다.이 graph는 prerequisite, parallelization 기회, resource-aware priority를 인코딩하며, Design, Programming, Art 전반에 workspace별 content를 포함한다.

A.4 팀 수준 실행 단계 · A.5 공유 지원 플랫폼 및 스킬 바인딩 · A.6 워크스페이스 검토 및 에이전트 수명 주기

Builder는 격리된 팀 워크스페이스에서 작동하는 동적 스케줄링 및 스킬 특화 worker agent를 통해 변화하는 task graph를 실행한다. Validation-controlled merging과 ephemeral agent lifecycle은 Design, Programming, Art 전반에서 적응적이고 결정론적이며 확장 가능한 production을 지원한다.

  • A.4 팀 수준 실행 단계: Dynamic runtime scheduling은 필요에 따라 worker를 생성하고, 실행 가능한 atomic task를 할당하며, dependency가 해결될 때 리소스를 재조정해 탄력적인 팀 확장을 가능하게 한다.병렬화 가능한 operation은 동시에 진행되고, dependency가 있는 task는 prerequisite가 검증될 때까지 queue에 남는다.
  • A.4 팀 수준 실행 단계: 팀 리더는 production 전반에서 agent를 provision하고 dependency constraint를 적용하며 throughput을 최적화하는 능동적 scheduler로 작동한다.이 architecture는 구조화된 planning–execution loop를 통해 특화된 Design, Programming, Art 팀을 조정한다.
  • A.5 공유 지원 플랫폼 및 스킬 바인딩: Task-specific skill bundle은 중앙집중식 Shared Support Platform에서 동적으로 바인딩되어 orchestration과 capability를 분리하고 정밀한 role specialization을 가능하게 한다.이 platform은 General, Design, Program, Art, Meta Skill을 계층화된 architecture로 구성해 세 팀 모두를 지원한다.
  • A.5 공유 지원 플랫폼 및 스킬 바인딩: General, Design, Program, Art skill은 각 팀에 맞춘 file, web, document, implementation, asset-generation, interface-styling capability를 제공한다.예로 terminal 및 file operation, office-format authoring, game development와 React scaffolding, image-generation 및 UI/UX tool이 있다.
  • A.5 공유 지원 플랫폼 및 스킬 바인딩: Meta Skill은 runtime에서 capability를 생성·개선·삭제할 수 있게 하여 architectural rewrite 없이 지속적인 확장과 적응을 지원한다.이 platform은 project requirement가 변함에 따라 skill을 발전시킬 수 있으며, 예를 들어 image generation을 batch-processing pipeline으로 확장할 수 있다.
  • A.6 워크스페이스 검토 및 에이전트 수명 주기: Worker는 proposal, specification, dependency에 대해 구조화된 리더 검증을 받을 수 있도록 output을 팀 workspace에 commit하며, 승인된 결과가 merge된 뒤 task가 완료된다.Integration 후 planning graph가 업데이트되고 worker는 종료된다.
  • A.6 워크스페이스 검토 및 에이전트 수명 주기: 표준화된 instantiate–execute–review–cleanup lifecycle은 agent를 일시적인 compute unit으로 취급해 state drift, resource contention, context pollution을 방지한다.Agent는 active task frontier에 대해서만 provision되고 deliverable이 integration된 직후 decommission되어 결정론적이고 확장 가능한 실행을 지원한다.
  • A.6 워크스페이스 검토 및 에이전트 수명 주기: CASTLE은 room design, puzzle dependency, backend implementation, interaction API, visual asset 전반에서 통합 specification과 중앙집중식 review를 조정해 이 pipeline을 적용한다.Producer, Design, Programming, Art 팀은 공유 constraint 아래에서 서로 다른 deliverable을 기여한다.

B 코드 해결과 버그 탐지에서의 프론티어 모델 성능

프론티어 모델은 기존 코드 해결에서는 강력한 성능을 보이지만 GBQA에서는 성능이 크게 저하되어, 자율적 버그 발견 역량의 격차를 드러낸다. GBQA는 표준 벤치마크를 넘어 능동적 탐색, 이상 탐지, 일관된 장기 추론을 요구한다.

  • B 코드 해결과 버그 탐지에서의 프론티어 모델 성능: SWE-Bench는 명시적이고 범위가 명확한 문제에서 알려진 결함의 위치를 찾고 패치하는 능력을 평가하는 반면, GBQA는 자율적인 동적 환경 탐색을 통해 잠재적 이상을 발견하도록 요구한다.따라서 두 벤치마크는 서로 다른 역량을 평가하며, GBQA는 명시적 감독 없이 에이전트가 버그를 드러내도록 요구한다.
  • B 코드 해결과 버그 탐지에서의 프론티어 모델 성능: GBQA는 장기간 상호작용 전반에 걸친 일관된 추론도 요구하며, 현재의 코딩 및 소프트웨어 엔지니어링 벤치마크가 측정하지 않는 누적적 난제를 도입한다.SWE-Bench Verified 점수는 공개적으로 보고된 역량과 엄밀히 일치시키기 위해 공식 벤더 기술 보고서와 system card에서 추출했다.
  • B 코드 해결과 버그 탐지에서의 프론티어 모델 성능: 프론티어 모델은 SWE-Bench Verified에서 강력한 결과를 달성하지만 GBQA 성능은 상당히 낮아, 자율적 버그 발견의 더 큰 복잡성을 부각한다.Table 4는 두 벤치마크의 성능을 비교하고, 이러한 격차를 표준 코드 해결을 넘어서는 역량이 필요한 것으로 규정한다.

C GBQA의 PROMPT DESIGN

GBQA는 게임 제작을 조율하고, 범위가 정해진 구현 작업을 관리하며, 증거 기반 interactive QA를 안내하고, 예측된 버그를 사람이 검증한 ground truth와 비교 평가하기 위해 역할별 prompt architecture를 사용한다. 동적 runtime 변수와 구조화된 출력은 일관된 실행, 감사 가능성, memory, 재현 가능한 평가를 뒷받침한다.

  • C GBQA의 PROMPT DESIGN: prompt architecture는 runtime에 역할 및 context에 따라 달라지는 변수를 인스턴스화하고, 각 agent 유형의 운영상 책임과 이에 대응하는 prompt를 정의한다.Placeholder에는 project context, task specifications, workspace state, skills, tools, interaction history가 포함된다.
  • C.1.1 GAME PRODUCER AGENT: Game Producer Agent는 장르, reference, concept, mechanics, presentation, player objective, winning condition을 포함한 게임의 global direction을 정의한다.또한 inventory rules, locks, visibility constraints, combination logic, delayed updates와 같은 QA 관련 stateful mechanics와 compact deterministic environment를 지정한다.
  • C.1.2 TEAM LEADER AGENT: Team Leader Agent는 producer proposal을 dependency-aware atomic tasks로 변환하고, 적절한 skills와 tools를 갖춘 worker를 일정에 배치하며, 이들의 workspace 변경을 검토한다.계획 단계에서는 Task Dependency and Priority Graph를 유지하고, 실행 단계에서는 repository-level inspection과 명시적인 acceptance 또는 revision 결정을 따른다.
  • C.1.3 WORKER AGENT: Worker Agents는 할당된 경계 안에서 하나의 scoped atomic task를 수행하며, 장착된 skills와 허용된 tools를 사용하고, leader 검토를 위해 구체적이고 감사 가능한 결과를 반환한다.유효한 변경에는 pull request를 생성하고, commit을 조작하는 대신 blocker 또는 no-change 상태를 보고한다. 팀 간 차이는 configuration과 skill bundle에서 비롯된다.
  • C.2 BASELINE INTERACTIVE AGENT를 위한 PROMPTS: baseline Interactive Agent는 backend API를 사용해 evidence-driven reflection, one-command planning, memory-supported summaries를 통해 재현 가능한 버그와 state inconsistency를 드러낸다.이 prompt는 순수한 task completion이 아니라 exploration, local verification, longer-horizon bookkeeping을 번갈아 수행하도록 구성된다.
  • C.3 EVALUATION을 위한 PROMPTS: evaluation Critic은 제공된 bug list와 match threshold를 사용해 각 predicted bug report가 사람이 검증한 human-verified ground-truth bug와 일치하는지 판단한다.이 prompt는 agent report와 target-game reference bug 간의 구조화된 비교를 정의한다.

D 대표 게임 환경

GBQA는 여러 장르에 걸친 30개의 interactive game environment로 구성되며, CASTLE을 주요 사례 연구로 지정한다. CASTLE은 단계적으로 진행되는 구조, 상태 기반 메커니즘, backend-only interface, 그리고 사람이 검증한 세 가지 버그를 갖춘 결정론적 8-room text adventure로 QA 평가를 지원한다.

  • 대표 환경: GBQA는 여러 장르와 gameplay pattern에 걸친 30 interactive game environment를 포함하며, CASTLE을 주요 사례 연구로 선정한다.CASTLE은 8-room topology를 갖춘 결정론적 text adventure game으로 제시된다.
  • 월드 구조와 진행: CASTLE은 key, fragment, tool, access condition을 통해 prerequisite-gated progression이 이루어지는 간결하지만 단순하지 않은 room graph를 사용한다.hall은 central hub 역할을 하며, ladder를 배치한 뒤에만 library에서 attic으로 진입할 수 있다.
  • 상태 기반 메커니즘: CASTLE은 six-item inventory limit, 단계적으로 작동하는 container와 lock, 제한된 visibility, 그리고 light-dependent basement mechanic을 통해 stateful QA mechanic을 시험한다.basement를 검사하려면 유효한 light source를 소지하고 점화해야 한다.
  • Backend interface: QA agent는 session creation, command execution, state retrieval을 위한 backend endpoint를 exclusively through backend endpoints 방식으로만 사용해 CASTLE과 상호작용한다.응답에는 room, exit, inventory, flag, turn counter, visibility status에 대한 textual observation과 structured summary가 노출되지만, 숨겨진 developer metadata는 제외된다.
  • Ground-truth bug list: CASTLE dataset에는 logic error, description flaw, data inconsistency를 포괄하는 three human-verified bugs가 포함된다.이 버그들은 QA와 관련된 서로 다른 failure pattern을 나타낸다.

E 사례 연구: 완전 자율형 Agentic Coding System을 향하여

CASTLE 사례 연구는 자율 QA와 코드 수정을 완전 폐쇄 루프 agentic coding system에 통합한다. 세션 세 번에 걸쳐 이 시스템은 인간 개입 없이 공개된 버그 세 개를 모두 발견하고 수정하여, 100% 발견률과 수정률을 달성했다.

  • 실험 설정: 이 파이프라인은 CASTLE을 탐색하고 보고서를 생성하는 QA agent와 codebase를 수정하고 패치된 버전을 반환하는 Claude Code를 결합한다.두 agent 모두 Claude-4.6-Opus-Thinking을 사용하며, QA는 장기 추론과 경험 재사용을 위해 세션 내 memory와 세션 간 memory를 사용한다.
  • 주요 관찰: 자율 QA는 사람이 작성한 issue description 없이 결함을 발견함으로써 상위 개발 신호를 제공하고, QA를 수동 검증에서 능동적 탐색으로 전환한다.이 발견 모듈은 기존 code-generation 및 bug-fixing benchmark에서 누락된 자율 버그 발견 구성 요소를 대상으로 한다.
  • 폐쇄 루프 궤적: CASTLE에서 100% 발견률과 수정률을 달성했다. 공개된 버그 세 개를 모두 세 번의 자율 세션 안에서 발견하고 수정했다.Table 7은 세션 수준의 발견, 검증, remediation 궤적을 요약한다.
  • 폐쇄 루프 궤적: 세션 2는 이전 수정 사항의 검증과 BUG-1 발견을 교차 진행하며, 겉보기 수렴 이후에도 효과적인 QA에는 지속적인 탐색이 필요함을 보여준다.세션 1에서는 BUG-2와 BUG-3을 발견했고, 세션 2에서는 해당 수정 사항을 검증하고 BUG-1을 발견했으며, 세션 3에서는 최종 수정을 검증하고 그 근본 원인을 식별했다.
  • 주요 관찰: 발견과 수정을 공동으로 평가해야 한다. 어느 한 구성 요소만 고립해 평가하면 전체 폐쇄 루프의 동역학을 포착하지 못하기 때문이다.이 사례 연구는 어느 한 모듈만이 아니라 종단 간 결함 발견 및 remediation 파이프라인을 평가한다.

F 라벨링 지침 · G LLM 사용 성명

주석자는 제공된 게임 빌드와 설계 명세를 기준으로 후보 보고서를 재현해 보며 버그를 검증하고, 발견 난이도를 부여하며, 최소 재현 단계를 기록한다. 검증된 동작을 바탕으로 유효한 결함을 중복 보고, 버그 아님, 불확실한 사례와 구분하며, LLM은 언어 다듬기에만 사용했다.

  • F.1 과업 개요: 주석자는 플레이 가능한 게임에서 각 후보 보고서를 재현해 보며, 설계 명세와 기존 승인 버그를 활용해 유효성, 난이도, 재현 단계를 판단한다.재현이 불완전하면 인접한 상호작용을 다시 수행해 재현 순서를 다듬을 수 있지만, 최종 주석은 실제로 검증된 동작에 근거해야 한다.
  • F.3 유효한 버그의 정의: 유효한 버그는 재현 가능하고, 설계 명세 또는 명확한 인터페이스 기대와 비교해 동작이 잘못되며, 게임 구현으로 인해 발생해야 한다.난이도, 지원되지 않는 명령, 충족되지 않은 선행 조건 또는 불충분한 증거에만 근거한 보고서는 유효한 버그로 인정하지 않는다.
  • F.4 난이도 주석 기준: 발견 난이도는 유효한 후보에 대해서만 부여하며, 버그를 수정하기 어려운 정도가 아니라 게임플레이를 통해 버그를 찾기 어려운 정도를 반영한다.필수 출력에는 유효성, 난이도, 일치하는 버그 ID, 검증된 최소 재현 단계, 구체적인 동작 설명이 기록된다.
  • F.5 중복 및 버그 아님 처리: 중복 보고는 표현이 다르더라도 실질적으로 동일한 재현 조건에서 동일한 근본 결함을 설명한다.주석자는 일치하는 버그 ID를 기록하고, 해당 보고서들이 동일한 이슈를 가리키는 이유를 간략히 설명한다.
  • F.5 중복 및 버그 아님 처리: 설계 명세와 일치하는 재현 가능한 동작은 버그 아님으로 라벨링하고, 재현할 수 없거나 해결되지 않은 모호한 사례는 추측하지 않고 불확실로 라벨링한다.예로는 의도된 선행 조건 실패, 올바른 퍼즐 진행 제한, 게임 규칙상 여전히 유효한 특이 관찰이 있다.
  • F.7 구체적 예시: 구체적으로 검토한 CASTLE 예시에서는 상호작용 순서를 검증한 뒤 침대 옆 서랍 열쇠의 조기 공개를 유효, 중간 난이도, BUG-2로 라벨링한다.위반 내용은 관련 컨테이너를 열기 전에 방 설명이 숨겨진 아이템을 노출한다는 것이다.
  • F.8 중요 고려 사항 •: 주석자는 개인적 선호가 아니라 의도된 동작을 판단해야 하며, 다른 전문가가 해당 동작을 재현할 수 있을 만큼 정확한 최소 재현 추적을 제공해야 한다.재현 연쇄를 완료하는 가장 짧은 검증된 순서를 기록해야 한다.
  • G LLM 사용 성명: 저자들은 large language models를 언어 다듬기에만 사용했으며 연구 설계, 분석 또는 결론에는 기여하지 않았다고 밝힌다.저자들은 논문의 무결성과 내용에 대한 전적인 책임을 진다.
Loading 2604.02648v1…