GBQA: 품질 보증 엔지니어(Quality Assurance Engineers)로서의 대규모 언어 모델(LLMs)을 평가하기 위한 게임 벤치마크
Abstract
현대 소프트웨어 개발에서 버그의 자율적 발견은 여전히 중요한 과제로 남아 있습니다. 코드 생성과 비교했을 때, 동적 런타임 환경(dynamic runtime environments)의 복잡성은 대규모 언어 모델(LLMs)이 버그를 발견하는 것을 훨씬 더 어렵게 만듭니다. 본 논문에서는 게임 개발을 대표적인 영역으로 삼아, LLM이 소프트웨어 버그를 자율적으로 탐지할 수 있는지 평가하기 위한 벤치마크인 게임 품질 보증을 위한 벤치마크(Game Benchmark for Quality Assurance, GBQA)를 소개합니다. GBQA는 3개 난이도에 걸쳐 30개의 게임과 인간이 검증한 124개의 버그를 포함하고 있습니다. 이 벤치마크는 게임을 개발하고 확장 가능한 방식으로 버그를 주입하는 멀티 에이전트 시스템(multi-agent system)을 사용하여 구축되었으며, 정확성을 보장하기 위해 인간 전문가가 개입(human-expert in the loop)하는 구조를 취했습니다. 또한, 우리는 다회차 ReAct 루프와 메모리 메커니즘을 갖춘 기본 인터랙티브 에이전트(baseline interactive agent)를 제공하여, 다양한 LLM이 버그 탐지를 위해 게임 환경을 장기적(long-horizon)으로 탐색할 수 있도록 합니다. 최첨단 LLM을 대상으로 한 광범위한 실험 결과, 자율적인 버그 발견은 여전히 매우 어려운 과제임을 보여주었습니다. 가장 성능이 우수한 모델인 사고 모드(thinking mode)의 Claude-4.6-Opus는 검증된 버그의 48.39%만을 식별했습니다. 우리는 GBQA가 적절한 테스트베드 및 평가 기준을 제공하며, 이를 통한 추가적인 발전이 자율 소프트웨어 공학(autonomous software engineering)의 격차를 줄이는 데 도움이 될 것이라고 믿습니다.
1 Introduction
실제 소프트웨어 개발은 체계적인 과정입니다. 어떠한 복잡한 시스템도 첫 시도에서 완벽하고 견고하게 구축될 수 없으며, 따라서 본질적으로 반복적인 소프트웨어 공학(Software Engineering) 워크플로우를 필요로 합니다. 전통적으로 인간 개발자들은 그림 1 (a)에 나타난 바와 같이 구현, 테스트, 디버깅, 리팩터링(Refactoring)의 반복적인 주기를 따릅니다. 현재는 Claude Code (Anthropic, 2025a), Cursor (Anysphere, 2024), OpenAI Codex (OpenAI, 2025a)와 같은 코딩 에이전트(Coding Agents)들이 이러한 개발 루프에 적극적으로 참여하고 있습니다. 이 패러다임에서 인간 개발자는 자연어 지시를 제공하고, 거대언어모델(LLMs)은 코드를 생성하며, 그 결과로 나온 프로그램을 실행하고, 오류를 점검하며, 반복적으로 코드를 수정합니다. 흔히 바이브 코딩(Vibe Coding) (Karpathy, 2025)으로 불리는 이 워크플로우는 그림 1 (b)와 (c)에 묘사된 것처럼 자동화된 소프트웨어 공학의 경계를 확장하고 있습니다.
이러한 고전적인 순환 구조 내에서, 최근의 진전은 개발 및 수정 측면을 획기적으로 강화해 왔습니다. 최첨단 거대언어모델(Large Language Models, LLMs)은 이제 자연어 명세서 (Qian et al., 2024; Hong et al., 2024)로부터 프로젝트 수준의 코드베이스를 생성할 수 있으며, 잘 작성된 버그 보고서나 이슈 설명 (Jimenez et al., 2024; Xia et al., 2024)이 주어지면 실제 코드 문제를 해결할 수 있습니다. 그러나 이 루프의 테스트 및 버그 발견 측면은 여전히 상당 부분 미개척 상태로 남아 있으며, 출시되는 소프트웨어의 품질은 바로 이 부분에 결정적으로 의존합니다.
코드 생성이나 수정과 달리, 버그 발견(bug discovery)은 근본적으로 다른 과제를 제시한다. 첫째, 목표가 불분명하다. 생성이나 수정 작업에서는 명확한 목표나 문제 설명이 제공되는 것과 달리, 에이전트(agent)는 무엇을 찾아야 하는지 지시받지 않은 상태에서 "무언가 잘못되었다"는 사실을 능동적으로 판단해야 한다. 둘째, 효과적인 버그 발견은 특정 위치에 대한 표적 수정이 아니라, 방대한 행동 상태 공간(behavioral state spaces)에 대한 포괄적인 탐색과 체계적인 계획을 요구한다. 셋째, 에이전트는 명시적인 사양(specifications)에 접근할 수 없는 경우가 많음에도 불구하고, 기대되는 동작과 실제 실행 동작 사이의 간극에 대해 추론해야 한다. 기존의 대부분 벤치마크는 에이전트가 개입하기 전에 작업 설명에 정밀한 설명을 명시함으로써 이러한 어려움을 회피한다. 결과적으로, 이상 징후를 인지하고 그 원인을 국소화(localizing)하는 인지적으로 고된 작업은 여전히 인간이 수행하고 있다. 이러한 상위 단계의 공백은 최근의 자율 코드 감사(autonomous code auditing) (Guo et al., 2025b) 및 대규모 버그 마이닝(bug mining) (Wu et al., 2025) 연구에서도 유사하게 강조된다. 따라서 완전한 자율 시스템으로 나아가기 위해서는 대규모 언어 모델(LLMs)이 독립적으로 결함을 발견하는 능력을 직접 평가하고 개선하는 것이 필요하다.
본 논문에서는 게임 개발을 자율적 버그 발견(autonomous bug discovery)을 위한 테스트베드(testbed)로 삼는다. 게임은 내부 상태 관리, 사용자 입력 처리, 출력 렌더링으로 구성된 독립적인 소프트웨어 시스템이다. 게임은 단일 세션 내에서 장기적인 동적 상호작용을 요구하므로, 실제 소프트웨어 공학 환경을 대표하기에 이상적이다. 동시에, 게임은 명확하게 정의된 행동 공간(action spaces)과 상태 전이(state transitions)를 제공하므로, 에이전트가 정형화된 입력과 출력을 쉽게 구성할 수 있게 하며 이는 에이전트 기반 탐색(agent-based exploration)과 자연스럽게 호환된다. 이러한 상호작용 기반의 상태 유지 검증(stateful verification)은 차세대 거대언어모델(LLMs)이 개발해야 할 핵심적인 에이전트 역량이다. 더욱이, 게임에서의 버그 발견은 실제 애플리케이션의 품질 보증(Quality Assurance, QA)에 해당하며, 이는 체계적이고 명세 기반의 테스트(specification-driven testing)가 오랫동안 이어져 온 분야이다 (Myers, 1979; Ammann and Offutt, 2016).
이러한 고려사항을 바탕으로, 우리는 대규모 언어 모델(LLM)이 상호작용형 게임 환경에서 자율적으로 버그를 찾아내는 능력을 평가하기 위해 설계된 벤치마크인 GBQA를 소개한다. 그림 2에서 알 수 있듯이, GBQA는 에이전트가 품질 보증(QA) 작업에서 얼마나 잘 수행하는지 평가하기 위해 총 124개의 인간이 검증한 버그가 포함된 30개의 다양한 게임을 포함하고 있다. 평가 과정에서 에이전트는 게임을 자율적으로 탐색하고, 잠재적인 버그를 식별하며, 재현 단계와 함께 명확한 설명을 보고한다. 그 후, 보고된 각 버그는 정량적 지표를 산출하기 위해 인간이 검증한 정답(ground-truth) 주석과 대조된다. 주석이 달린 버그들은 다양한 복잡도에 따른 모델의 강건성(robustness)을 평가하기 위해 서로 다른 난이도 수준으로 분류된다. 이 벤치마크를 대규모로 구축하기 위해, 우리는 게임을 자동으로 생성하고 조절 가능한 복잡도를 가진 버그를 주입하는 멀티 에이전트 시스템을 개발하였으며, 이 과정에서 인간 전문가가 루프(in the loop)에 참여하여 모든 주석의 정확성을 검증한다.
최첨단 LLM(Large Language Models, 대규모 언어 모델)의 버그 탐지 능력을 평가하기 위해, 우리는 다회차 ReAct 루프(ReAct loop)와 메모리 메커니즘(memory mechanism)을 갖춘 기본 인터랙티브 에이전트(interactive agent)를 추가로 제공하며, 이를 통해 게임 환경에 대한 장기적 탐색(long-horizon exploration)이 가능하도록 하였다. 실험 결과, 자율적인 버그 발견은 여전히 매우 어려운 과제임이 드러났다. 가장 성능이 우수한 모델인 사고 모드(thinking mode)의 Claude-4.6-Opus조차 버그의 절반 미만을 식별하였으며, 이는 개선 여지가 상당함을 보여준다.
본 연구의 기여도는 다음과 같이 요약할 수 있다.
- 우리는 상호작용 환경(interactive environments)에서의 자율적 버그 발견 문제를 공식화하고, 3가지 난이도에 걸쳐 30개의 다양한 게임과 124개의 인간이 검증한 버그를 포함하는 벤치마크인 GBQA를 제시하며, 자동화된 평가를 지원하는 비평 에이전트(critic agent)를 함께 제공한다.
- 우리는 조절 가능한 복잡도로 게임을 생성하고 버그를 삽입할 수 있는 다중 에이전트 시스템(multi-agent system)을 포함한 확장 가능한 게임 환경 빌더를 개발하며, 그 정확성을 보장하기 위해 인간 개입(human-in-the-loop) 방식을 도입한다.
- 우리는 GBQA(Generalized Bug Query Analysis) 분야에서 최첨단 LLM(Large Language Models, 거대언어모델)을 대상으로 광범위한 평가를 수행하며, 이는 모델의 성능과 한계에 대한 종합적인 분석뿐만 아니라 자율적 버그 발견(autonomous bug discovery)에서 나타나는 현재의 실패 모드(failure modes)에 대한 특성 분석을 제공한다.
2 관련 연구
소프트웨어 공학 및 에이전트 벤치마크. 거대 언어 모델(Large Language Models, LLM)은 소프트웨어 공학 과제에서 널리 평가되어 왔다. SWE-bench (Jimenez et al., 2024) 및 그 확장형인 (Aleithan et al., 2024)은 실제 GitHub 이슈를 해결하는 에이전트의 능력을 측정하며, Agentless (Xia et al., 2024)와 같은 시스템은 구조화된 파이프라인을 통해 이슈 국소화(issue localization) 및 패치 생성을 개선한다. 이러한 벤치마크들의 공통된 가정은 인간이 이미 버그를 식별하고 설명했다는 것이며, 에이전트는 주로 코드 수정(code repair) 측면에서 평가된다. 이슈 기반의 수정을 넘어, 최근 연구들은 정적 저장소(static repositories)에서의 자동화된 결함 탐지를 탐구한다. RepoAudit (Guo et al., 2025b)과 BugStone (Wu et al., 2025)은 구조적 패턴과 데이터 의존성을 분석하여 대규모로 취약점을 찾아낸다. 그러나 이러한 접근 방식은 정적 코드에서 작동하며, 에이전트가 동적 시스템과 상호작용하고, 다단계 동작을 수행하며, 런타임 피드백으로부터 명세 수준의 불일치(specification-level inconsistencies)를 추론하는 능력을 평가하지는 않는다. 더 일반적으로, WebArena (Zhou et al., 2024) 및 AgentBench (Liu et al., 2024)와 같은 상호작용형 에이전트 벤치마크는 웹 내비게이션 및 도구 사용(tool-use) 시나리오에서 LLM 에이전트를 평가한다. SMART (Mu et al., 2025)은 기능 테스트를 위해 커버리지 인식 전략(coverage-aware strategies)을 통합한다. 이러한 환경에서 환경은 정답(ground truth)으로 취급되며, 성공은 과업 완수로 정의된다. 이와 대조적으로, GBQA는 환경 자체를 평가 대상으로 취급하며, 에이전트 기반 소프트웨어 공학을 위한 보완적 지표로 결함 발견율(flaw discovery rate)을 도입한다.
게임 기반 에이전트와 자동화된 게임 테스트. 인터랙티브 게임은 거대언어모델(LLM) 에이전트를 위한 주요 테스트베드가 되었다. Voyager (Wang et al., 2023), MineDojo (Fan et al., 2022), CRADLE (Tan et al., 2024), 그리고 Generative Agents (Park et al., 2023)는 정상적으로 작동하는 환경 내에서의 목표 달성 및 기술 습득에 초점을 맞춘다. 우리의 설정과 더 가까운 연구로는 TITAN (Wang et al., 2025)과 Orak (Park et al., 2025)이 LLM 보조 게임 테스트를 탐구한다. 이러한 시스템들은 품질 보증(QA) 지향적 에이전트의 실현 가능성을 입증하지만, 공개적으로 검증 가능한 버그 주석(bug annotations)이 없는 독자적인 환경에서 작동하므로 표준화된 비교가 제한적이다. GBQA는 두 가지 측면에서 차별화된다. (1) 이는 완전히 알려져 있고 인간이 검증한 버그 주석을 제공하여 엄격한 정량적 평가를 가능하게 하며, (2) 제어 가능한 복잡성과 체계적인 벤치마크 확장을 지원하는 확장 가능한 환경 빌더를 제공한다. 이러한 특성들이 결합되어, GBQA는 인터랙티브 시스템 내에서 자율적인 버그 발견을 위한 표준화된 테스트베드로 자리매김한다.
3 GBQA
3.1 과제 정의 (Task Definition)
게임 환경은 으로 정의되며, 여기서 은 상태 공간(state space), 는 에이전트(agent)가 수행 가능한 행동 공간(action space), 은 상태 전이 함수(state transition function), 는 초기 상태를 나타낸다. 선택적으로, 게임 구축 과정에서 생성된 설계 문서와 소스 코드를 포함하는 문서 컨텍스트(documentation context) 가 에이전트에게 제공될 수 있다. 각 타임 스텝(time step) 에서 에이전트는 상태 을 관찰하고 행동 을 선택하며, 환경은 으로 전이된다. 에이전트는 여러 턴에 걸쳐 환경과 상호작용하며 탐색 궤적(exploration trajectory) 을 형성한다.
을 환경에 존재하는 실제 버그(ground-truth bugs)의 집합이라고 하자. 에이전트(agent)가 을 탐색한 후, 에이전트는 버그 보고서(bug reports)의 집합인 를 생성한다. 여기서 각 보고서 은 관찰된 이상 현상에 대한 자연어 설명과 이를 재현하기 위한 단계(steps to reproduce)를 포함한다. 에이전트의 목표는 를 통해 의 커버리지(coverage)를 최대화하는 것이며, 이를 통해 환경 내의 모든 버그가 탐지되고 소프트웨어 엔지니어가 이를 재현 및 수정할 수 있을 만큼 충분히 상세하게 기술되도록 하는 것이다. 일반적인 절차는 알고리즘 1에 요약되어 있으며, 공식적인 평가 프로토콜(evaluation protocol)은 섹션 3.4에 정의한다.
일 때, 에이전트는 플레이어 탐색 모드(Player Exploring Mode)로 작동하며, 플레이어의 관점에서 버그를 발견하기 위해 오직 상호작용을 통한 관찰에만 의존합니다. 이 제공되면, 에이전트는 품질 보증 모드(Quality Assurance Mode)로 작동하며, 설계 사양과 소스 코드를 활용하여 정보에 기반한 사양 중심의 테스트(specification-driven testing)를 수행합니다. 우리는 섹션 5에서 두 모드를 모두 평가합니다.
3.2 게임 환경 빌더(Game Environment Builder)
확장 가능하고 제어 가능한 벤치마크 구축을 지원하기 위해, GBQA의 모든 환경은 전문 게임 스튜디오를 모사하는 계층적 다중 에이전트 협업 시스템(hierarchical multi-agent collaboration system)에 의해 개발됩니다. 이 시스템은 프로듀서 에이전트(Producer Agent)와 전문적인 게임 스튜디오의 작업 팀들을 모사하는 여러 작업 팀으로 구성됩니다. 프로듀서 에이전트는 고수준의 게임 개념을 구조화된 제안서로 분해하고, 이를 디자인, 프로그래밍, 아트 에셋(art asset) 제작을 담당하는 전문 팀들에 배분합니다. 각 팀 내에서는 팀 리드 에이전트(Team Lead Agent)가 의존성 및 우선순위에 따라 과업을 추가로 분해하고, 작업자 에이전트(worker agents)에게 하위 과업을 할당하며 진행 상황을 조율합니다. 모든 에이전트는 재사용 가능한 기술을 갖춘 지원 플랫폼을 공유합니다. 에이전트 기술 패러다임(Agent Skills paradigm) (Zhang et al., 2025)에 따라, 각 기술은 구조화된 지침과 실행 가능한 도구를 갖춘 독립적인 모듈로 구성되어 에이전트가 필요에 따라 기능을 탐색하고 로드할 수 있게 합니다. 이러한 다중 에이전트 프레임워크는 디자인 사양, 에셋 제작, 코드 구현 전반에 걸쳐 구조적 일관성을 보장합니다. 전체적인 아키텍처와 더 상세한 운영 원칙은 부록 A에 제공됩니다.
모든 게임 환경은 경량 웹 애플리케이션으로 배포됩니다. 통일되고 에이전트 친화적인 인터페이스를 보장하기 위해, 우리는 엄격한 프론트엔드-백엔드 분리 구조(frontend-backend separation architecture)를 채택합니다. 백엔드는 핵심 게임 로직을 캡슐화하고, 상호작용을 위한 API 엔드포인트를 노출하며, 에이전트의 행동으로 인해 발생하는 상태 전이(state transitions)를 처리합니다. 프론트엔드는 인간 플레이어를 위해 백엔드로부터 수신한 게임 상태 업데이트를 렌더링하고, 수동 플레이 테스트를 위한 표준 인터페이스를 제공합니다. QA 에이전트가 게임과 상호작용할 때, 에이전트는 오직 백엔드 엔드포인트를 통해서만 작동하며, 이는 에이전트의 행동 공간(action space)을 구성하는 호출 가능한 도구 역할을 합니다. 이러한 설계는 게임 상태와 가용한 행동을 모두 포함하는 에이전트의 관측 공간(observation space)이 프론트엔드 인터페이스를 통해 인간 테스터가 인지하는 것과 의미론적으로 동일함을 보장합니다.
단순하게 구성된 환경이 생성되는 것을 방지하기 위해, 우리는 반복적 복잡성 확장(iterative complexity scaling) 메커니즘을 도입한다. 게임의 초기 버전이 생성되면, QA 에이전트(QA agent)가 예비 테스트를 수행하여 버그 발견 가능성을 추정한다. 만약 감지된 버그 수가 사전 정의된 임계값 미만이면, 시스템은 구조적 복잡성을 높이기 위해 추가적인 게임플레이 기능, 메커니즘 상호작용(mechanical interactions) 또는 서사적 분기(narrative branches)를 자동으로 도입한다. 이 과정은 버그 수가 이상이 될 때까지 반복된다. 이와 동시에, 각 게임은 최소 하나 이상의 완전하게 작동하는 게임플레이 궤적(gameplay trajectory)을 포함하도록 보장되어, 생태적 타당성(ecological validity)을 확보하고 해결 불가능하거나 고장 난 상태가 발생하는 것을 방지한다.
3.3 Benchmark
우리는 GBQA를 구축하기 위해 빌더(builder)를 구체화(instantiate)하였다. GBQA는 30개의 다양한 게임 환경과 6가지 핵심 게임 장르인 액션(Action), 어드벤처(Adventure), 역할 수행(Role-Playing), 전략(Strategy), 시뮬레이션(Simulation), 퍼즐(Puzzle)에 걸쳐 총 124개의 인간이 검증한 버그로 구성된 벤치마크이다. 추가적인 통계 및 게임 사례는 부록 D에 제공된다.
발견 난이도(Discovery Difficulty).
더욱 상세한 분석을 제공하기 위해, 우리는 특정 버그를 탐지하는 데 요구되는 인지적 및 추론적 요구사항을 바탕으로 발견 난이도(discovery difficulty)에 대한 3단계 분류 체계(taxonomy)를 정의한다.
- • 쉬운 버그(Easy bugs)는 다단계 추론 없이 단 한 번의 관찰만으로 식별할 수 있는 표면적 수준의 지각적 불일치(perception inconsistencies)이다.
- 중급 버그(Medium bugs)는 게임플레이 로직이나 규칙 제약 조건의 위반을 포함하며, 에이전트가 짧은 상호작용 시퀀스(interaction sequences)에 걸쳐 전제 조건(preconditions), 행동 효과(action effects), 그리고 예상되는 시스템 동작에 대해 추론하도록 요구한다.
- 어려운 버그(Hard bugs)는 확장된 궤적(trajectories) 전반에 걸쳐 장기적인 일관성 추적을 요구하며, 이때 모순은 에이전트(agent)가 시간적으로 분리된 상태들로부터 정보를 통합할 때만 나타난다.
이 분류 체계는 지각적 검증(perceptual validation)에서 규칙 기반 추론(rule-based reasoning)을 거쳐, 최종적으로 장기적 시간적 일관성 추적(long-horizon temporal consistency tracking)으로 이어지는 구조적 단계를 형성한다. 이는 그림 2에 나타난 바와 같다. 해당 벤치마크는 중급 난이도를 중심으로 균형 잡힌 구조를 갖추고 있으며, 표면적 결함(surface-level defects)과 장기적 결함(long-horizon defects) 모두를 유의미한 비율로 유지하고 있다.
정답 데이터 큐레이션(Ground-Truth Curation).
정답(Ground-truth) 버그 데이터셋은 자동화된 탐지와 전문가 검증을 통합한 엄격한 2단계 프로토콜을 통해 구축된다. 초기 단계에서는 복잡성 확장(Complexity scaling) 과정(Section 3.2) 중에 생성된 버그 보고서가 예비 후보로 활용된다. 이후, 3명의 전문 QA 엔지니어가 각 게임 환경 내에서 이러한 후보들을 독립적으로 검증하며, 오탐(False positives)을 걸러내고 확인된 버그에 난이도 및 재현 단계(Reproduction steps)와 같은 구조화된 메타데이터를 주석으로 추가한다. 주석의 신뢰성을 보장하기 위해 의견 불일치 시 다수결 투표로 해결한다. 라벨링 지침은 부록 F에서 확인할 수 있다.
3.4 평가 지표 (Evaluation Metrics)
우리는 에이전트가 생성한 버그 리포트(bug reports) 집합 를 실제 버그(ground-truth bug) 집합 과 비교하여 평가한다. 비평 에이전트(critic agent) 는 의 설명과 의 주석(annotation) 사이의 의미적 대응 관계를 바탕으로, 리포트 가 실제 버그 를 성공적으로 식별했는지 여부를 판단한다. 우리는 성공적으로 탐지된 버그의 집합을 로 정의한다. 주요 평가 지표는 다음과 같이 정의되는 재현율(Recall)이다.
| (1) |
우리는 자율적 버그 발견(autonomous bug discovery)의 핵심 목표이 결함 커버리지(defect coverage)를 극대화하는 것이기 때문에 재현율(recall)을 우선시한다. 실제 품질 보증(QA) 워크플로우에서 미검출된 결함은 실제 운영 환경까지 지속될 수 있는 반면, 허위 보고는 인간 검토자에 의해 효율적으로 걸러낼 수 있으므로 미검출(false negatives)은 허위 양성(false positives)보다 훨씬 더 높은 비용을 초래한다.
4 기본 에이전트 (Baseline Agent)
우리는 대규모 언어 모델(LLM)이 장기적인 게임 플레이 세션 동안 자율적인 버그 발견을 수행할 수 있도록, 동적 탐색(dynamic exploration), 성찰적 추론(reflective reasoning), 피드백 접지(feedback grounding), 그리고 메모리 관리(memory management) 기능을 갖춘 베이스라인 에이전트 아키텍처를 제안한다.
4.1 검증 기반 성찰(Verification-Based Reflection)을 통한 ReAct 기반 탐색
에이전트는 명시적인 추론(reasoning)과 환경 행동(environment actions)을 교차시키는 ReAct 패러다임 (Yao et al., 2023)을 따릅니다. 각 단계 에서 에이전트는 관측값 이 주어지면, 현재 상태 및 예상 결과에 관한 추론 흔적(reasoning traces)을 생성하고, 가용한 도구 세트에서 행동 을 선택하며, 다음 관측값 으로 전이합니다.
이상 징후에 대한 민감도를 높이기 위해, 우리는 표준 ReAct 방식을 단계 수준의 성찰 및 검증(reflection and verification) 메커니즘을 통해 보완한다. 각 전이(transition) 이후, 에이전트는 관찰된 결과가 올바른 게임 동작에 대한 내부적 기대와 일치하는지 비판적으로 평가한다.
불일치를 감지하면, 에이전트(agent)는 (i) 트리거링 액션(triggering action, 유발 동작), (ii) 관찰된 동작, (iii) 기대되는 동작, 그리고 (iv) 잠재적 위반 유형으로 구성된 예비 버그 가설을 수립한다. 에이전트는 즉각적으로 보고하는 대신, 표적 재현 시도(targeted reproduction attempts)를 통해 뒷받침하는 증거를 수집하는 국소적 검증 단계(local verification phase)를 시작한다. 재현 가능성과 편차 크기에 기반하여 신뢰도 점수(confidence score)가 부여되며, 임계값을 초과하는 후보들만 최종 버그 보고로 승격됨으로써 오탐(false positives)을 완화한다. 이러한 메커니즘은 에이전트의 역할을 수동적인 궤적 생성기(trajectory generator)에서 능동적인 행동 검증기(behavioral verifier)로 전환하며, 에이전트의 추론 과정을 자율적 버그 발견이라는 목적과 긴밀하게 정렬시킨다.
4.2 계층적 메모리 모듈(Hierarchical Memory Module)
장기적 시계(long-horizon) 버그 탐지에서 거대언어모델(LLM)의 컨텍스트 윈도우(context-window) 제한을 극복하기 위해, 우리는 단기적인 궤적 추적(trajectory tracking)과 장기적인 경험 축적(experiential accumulation)을 분리하는 계층적 메모리 구조(hierarchical memory architecture)를 도입한다.
세션 내 메모리(In-Session Memory). 단일 게임 플레이 세션 내에서, 에이전트(agent)는 게임 상태의 변화를 추적하는 구조화된 작업 메모리(working memory)를 유지한다. 상호작용 이력이 길어짐에 따라, 이전 궤적(trajectory) 세그먼트들은 요약 모듈(summarization module)을 통해 주기적으로 압축된다. 이러한 요약본은 방문한 장소, 획득한 아이템, 발생한 이벤트, 해결되지 않은 이상 현상, 그리고 잠정적인 버그 가설을 포함하여 의미적으로 중요한 정보를 유지한다.
충실도(fidelity)와 확장성(scalability)을 조화시키기 위해, 우리는 가장 최근의 번의 상호작용 단계는 상세하게 유지하고, 더 오래된 단계는 압축된 상태 요약(state summaries)으로 대체하는 슬라이딩 윈도우(sliding-window) 전략을 채택한다. 이러한 설계는 모델의 컨텍스트 제약(context constraints) 내에서 장기적 추론(long-horizon reasoning)을 가능하게 한다. 중요한 점은, 요약 과정이 단순히 추출 방식이 아니라 추상화 지향적(abstraction-oriented)이라는 것이다. 즉, 이는 가공되지 않은 텍스트 로그보다는 인과 구조(예: “아이템 X를 집은 후, 이벤트 Y가 가능해짐”)를 보존한다. 이러한 추상화는 지연된 효과(delayed effects)와 다단계 불일치(multi-step inconsistencies)에 대한 추론을 지원한다.
세션 간 메모리(Cross-Session Memory). 종합적인 질의응답(QA) 작업은 종종 서로 다른 초기 조건에서 게임을 재시작하고 재탐색하는 것을 요구한다. 이러한 실제적인 테스트 워크플로우를 반영하기 위해, 우리는 각 게임에 대해 지속적인 세션 간 메모리 저장소(persistent cross-session memory store)를 유지한다.
각 세션이 끝날 때마다, 에이전트는 축적된 경험을 탐색된 영역, 확인된 버그, 해결되지 않은 가설, 탐색되지 않은 분기, 그리고 우선순위 테스트 대상 등을 포착하는 구조화된 요약으로 증류(distill)한다. 이 요약은 후속 세션의 초기 컨텍스트(context)에 주입된다. 세션 내 궤적 관리(intra-session trajectory management)와 세션 간 지식 축적(inter-session knowledge accumulation)을 분리함으로써, 에이전트는 여러 번의 재시작을 거치며 일관된 테스트 전략을 점진적으로 구축한다. 이러한 계층적 메모리 설계는 탐색 효율을 높이고 중복된 범위를 줄이며, 무작위적인 방황이 아닌 체계적인 테스트를 유도한다.
5 Experiments
5.1 실험 설정 (Experimental Setup)
모델. 우리는 인스트럭트(instruct) 및 씽킹(thinking) 변형 모델을 포함하여, 오픈 소스 및 폐쇄형 계열을 아우르는 다양한 최첨단 LLM(대규모 언어 모델) 제품군을 평가한다. 모든 모델은 공식적으로 권장되는 디코딩 파라미터(decoding parameters)를 사용하며, 그렇지 않을 경우 그리디 샘플링(greedy sampling)을 기본 전략으로 채택한다.
설정. 각 모델은 섹션 4에서 설명된 기본 에이전트(baseline agent)의 백본(backbone) 역할을 수행한다. 섹션 3.1에서 정의된 바와 같이, 우리는 각 모델을 플레이어 탐색 모드(Player Exploring Mode)와 품질 보증 모드(Quality Assurance Mode) 모두에서 평가한다. GBQA의 각 게임에 대해, 에이전트에게는 최대 회의 상호작용 단계(interaction steps) 예산이 주어진다. 우리는 탐색의 범위가 버그 탐지 범위(bug detection coverage)에 미치는 영향을 조사하기 위해, 두 모드 모두에서 네 가지 단계 예산()을 기준으로 평가를 진행한다.
지표(Metrics). 우리는 비평가 에이전트(critic agent)에 의한 자동 평가를 통해 산출되는 재현율(Recall)을 주요 지표로 채택한다.
5.2 주요 결과
앞서 설명한 설정에 따라, 우리는 광범위한 주요 거대언어모델(LLM, Large Language Models)을 비교하였다. 표 1은 모든 단계 예산(step budgets)에 걸쳐 두 가지 테스트 모드에서 각 모델의 성능을 보고한다. 실험 결과는 모드와 모델 제품군(model families)에 따른 몇 가지 통찰과 패턴을 보여준다.
| Model | Player Exploring Mode | Quality Assurance Mode | Best Performance | ||||||
| 50 | 100 | 200 | 500 | 50 | 100 | 200 | 500 | ||
| LLMs in Instruct Mode | |||||||||
| Claude-4.6-Opus | 14.52 | 20.97 | 25.81 | 31.45 | 22.58 | 28.23 | 31.45 | 37.90 | 37.90 |
| Claude-4.5-Sonnet | 11.29 | 16.13 | 18.55 | 20.97 | 17.74 | 25.00 | 28.23 | 32.26 | 32.26 |
| GPT-5.2 | 7.26 | 10.48 | 12.90 | 14.52 | 11.29 | 16.94 | 19.35 | 22.58 | 22.58 |
| Kimi-K2.5-1T-A32B | 6.45 | 9.68 | 11.29 | 13.71 | 10.48 | 15.32 | 17.74 | 20.97 | 20.97 |
| Gemini-3-Flash | 6.45 | 8.87 | 10.48 | 12.10 | 9.68 | 13.71 | 16.13 | 19.35 | 19.35 |
| DeepSeek-V3.2 | 6.45 | 9.68 | 10.48 | 12.90 | 9.68 | 14.52 | 16.94 | 20.16 | 20.16 |
| Llama-3.1-8B | 2.42 | 3.23 | 4.84 | 5.65 | 4.03 | 5.65 | 7.26 | 8.87 | 8.87 |
| Llama-3.1-70B | 4.03 | 6.45 | 8.06 | 9.68 | 6.45 | 9.68 | 12.10 | 14.52 | 14.52 |
| Qwen3-8B | 4.03 | 5.65 | 6.45 | 7.26 | 6.45 | 8.06 | 9.68 | 10.48 | 10.48 |
| Qwen3-32B | 4.84 | 7.26 | 9.68 | 10.48 | 6.45 | 11.29 | 14.52 | 15.32 | 15.32 |
| Qwen3-235B-A22B | 5.65 | 9.68 | 10.48 | 12.10 | 8.87 | 14.52 | 16.13 | 18.55 | 18.55 |
| Qwen3.5-397B-A17B | 8.06 | 11.29 | 13.71 | 15.32 | 12.10 | 17.74 | 20.97 | 24.19 | 24.19 |
| LLMs in Thinking Mode | |||||||||
| Claude-4.6-Opus-Thinking | 16.94 | 23.39 | 29.03 | 35.48 | 25.00 | 34.68 | 41.13 | 48.39 | 48.39 |
| Claude-4.5-Sonnet-Thinking | 12.10 | 17.74 | 21.77 | 26.61 | 19.35 | 25.81 | 30.65 | 37.10 | 37.10 |
| OpenAI-o3 | 11.29 | 16.13 | 20.97 | 25.00 | 17.74 | 25.00 | 29.84 | 34.68 | 34.68 |
| Kimi-K2.5-1T-A32B-Thinking | 8.87 | 12.90 | 16.13 | 20.16 | 14.52 | 20.16 | 24.19 | 28.23 | 28.23 |
| Gemini-3-Pro | 10.48 | 15.32 | 19.35 | 23.39 | 16.94 | 22.58 | 27.42 | 33.06 | 33.06 |
| DeepSeek-R1 | 11.29 | 17.74 | 22.58 | 27.42 | 19.35 | 27.42 | 32.26 | 37.90 | 37.90 |
| Qwen3-8B-Thinking | 7.26 | 10.48 | 12.90 | 16.13 | 12.10 | 16.94 | 20.97 | 24.19 | 24.19 |
| Qwen3-32B-Thinking | 9.68 | 14.52 | 19.35 | 24.19 | 15.32 | 23.39 | 29.03 | 33.87 | 33.87 |
| Qwen3-235B-A22B-Thinking | 10.48 | 16.13 | 20.97 | 25.00 | 18.55 | 25.00 | 30.65 | 35.48 | 35.48 |
| Qwen3.5-397B-A17B-Thinking | 13.71 | 19.35 | 25.00 | 30.65 | 20.97 | 28.23 | 35.48 | 41.13 | 41.13 |
어려운 벤치마크. 자율적 버그 발견(Autonomous bug discovery)은 평가된 모든 모델에게 여전히 매우 어려운 과제로 남아 있다. 가장 우수한 성능을 보인 구성인 '500단계의 품질 보증 모드(Quality Assurance Mode)를 적용한 Claude-4.6-Opus'조차 48.39%의 정확도에 그쳐, 절반 이상의 버그를 찾아내지 못했다. 이는 버그 발견이 일반적인 코드 생성(code generation)이나 이슈 해결(issue resolution)보다 훨씬 더 어려운 역량임을 확인시켜 준다. 후자(일반적인 코드 생성 및 이슈 해결)의 경우, 최첨단 모델(frontier models)들이 SWE-Bench Verified (Chowdhury et al., 2024)와 같은 유사한 벤치마크에서 일상적으로 70% 이상의 성능을 기록하기 때문이다. SWE-Bench Verified와 GBQA에서 나타난 최첨단 모델의 성능에 대한 상세한 비교는 부록 B에 제공된다.
확장 법칙(Scaling Law). 모델 크기에 따른 일관된 성능 향상(예: Qwen3 시리즈)에서 알 수 있듯이 표준적인 확장 경향이 이 설정에서도 유지되지만, 추론 능력은 단순히 모델 규모를 키우는 것보다 더 높은 매개변수 효율성(parameter-efficient)을 보이는 것으로 나타났다. 예를 들어, Qwen3-32B-Thinking(33.87%)은 훨씬 더 큰 Llama-3.1-70B(14.52%)를 크게 능가하며, 심지어 거대한 Qwen3-235B-A22B(18.55%)와 대등한 수준이다. 이는 지속적인 다단계 추론(multi-step reasoning)과 동적 상태 검증(dynamic state verification)을 요구하는 버그 발견의 경우, 매개변수 확장(parameter scaling) 단독보다는 추론 시간 확장(inference-time scaling)이 더 중요하다는 것을 시사한다.
테스트 모드. 품질 보증(Quality Assurance, QA) 모드는 모든 평가 모델과 단계 예산(step budgets)에서 플레이어 탐색(Player Exploring) 모드보다 일관되게 우수한 성능을 보였다. 설계 아티팩트(design artifacts)와 소스 코드에 대한 접근은 명세 기반 테스트(specification-driven testing)를 가능하게 하며, 이를 통해 에이전트가 정밀한 행동 기대치를 설정하고 결과적으로 더 세밀한 위반 사항을 탐지할 수 있게 한다. 그럼에도 불구하고, 포괄적인 문서가 제공됨에도 불구하고 성능은 여전히 상당히 최적화되지 않은 수준이다. 이러한 지속적인 격차는 주요 병목 현상이 컨텍스트 정보의 부족이 아니라, 현재의 대규모 언어 모델(LLM)이 가진 두 가지 내재적 한계에 있음을 시사한다: (i) 복잡한 다단계 추론 과정에서의 환각(hallucinations) 및 논리적 불일치에 대한 취약성, 그리고 장기 과업(long-horizon tasks)에서의 오류 누적 및 상태 추적의 모호성; 그리고 (ii) QA 특화 강화 학습(RL) 훈련의 부족으로 인한 체계적인 테스트 휴리스틱(testing heuristics)의 뚜렷한 결핍이다. 결과적으로, 이러한 모델들은 숙련된 QA 엔지니어들이 일상적으로 사용하는 구조화되고 효율적이며 가설 기반의 탐색 전략이 부족하다.
5.3 사례 연구 (Case Study)
GBQA의 실용적 유용성을 입증하기 위해, 우리는 완전 자율형 탐지-패치(detection-to-patch) 파이프라인에 대한 사례 연구를 수행한다. 추가적인 실험 세부 사항 및 결과는 부록 E에 제공된다.
5.4 GBQA의 신뢰성
| Annotation Set | Count | Krippendorff’s [95% CI] |
| Valid Bug | 124 | |
| Non-Bug | 254 | |
| Overall Candidates | 378 |
| Model | Pearson [95% CI] | p-value |
| Gemini-3-Pro | 0.858 [, ] | |
| Claude-4.6-Opus | 0.821 [, ] | |
| DeepSeek-R1 | 0.807 [, ] | |
| GPT-5.2 |
벤치마크 주석(Benchmark Annotation)을 위한 IAA 분석. GBQA의 버그 주석(bug annotations) 신뢰도를 정량화하기 위해, 우리는 Krippendorff의 (Krippendorff, 2018)을 활용하여 검사자 간 일치도(Inter-Annotator Agreement, IAA) 분석을 수행하였다. 표 2에 나타난 바와 같이, 3명의 검사자가 378개의 후보 주석을 각각 유효한 버그 또는 비버그로 독립적으로 라벨링하였다. 해당 데이터셋은 0.901의 전체 을 달성하였으며, 이는 버그 특성화(bug characterization)에 내재된 주관성에도 불구하고 라벨링 지침이 전문가들의 판단을 성공적으로 표준화했음을 나타낸다.
평가자로서의 비평가 에이전트(Critic Agent). 자동화된 평가 파이프라인을 추가로 검증하기 위해, 우리는 별도의 검증 세트(held-out validation set)에서 인간의 평가 점수와 일치도를 피어슨 상관계수(Pearson correlation coefficient) (Pearson, 1901)를 사용하여 측정하였다. 표 3에 보고된 바와 같이, 4개의 모든 백본 LLM(backbone LLMs)이 높은 상관도를 기록하였으며, 이는 비평가 에이전트가 인간 평가를 대신할 신뢰할 수 있는 대리 지표(proxy) 역할을 수행함을 확인시켜 준다. GPT-5.2가 가장 높은 상관도()를 기록하였으며, 따라서 모든 결과 보고를 위한 기본 백본으로 채택되었다.
5.5 절제 연구 (Ablation Studies)
우리는 개별적인 구조적 구성 요소들의 기여도를 분리하여 파악하기 위해, 품질 보증 모드(Quality Assurance Mode) 하에서 Claude-4.6-Opus를 활용하여 절제 실험(ablation experiments)을 수행한다.
단계 예산(Step Budget) 분석. 우리는 난이도 수준에 따라 계산 비용과 버그 발견 사이의 절충 관계(trade-off)를 연구하기 위해 단계 예산 을 변화시켰다. 그림 3에서 볼 수 있듯이, 쉬운(Easy) 버그는 대부분 첫 300단계 내에 발견되는 반면, 중간(Medium) 난이도의 버그는 이와 유사하지만 더 낮은 궤적을 보이며 500단계에서 약 30%에 도달한다. 어려운(Hard) 버그는 단계 예산에 가장 강하게 의존하며, 뚜렷한 포화 추세(saturation trend)를 보이지 않는다. 이러한 패턴은 쉬운 버그는 지각적 확인(perceptual checking)을 필요로 하고, 중간 난이도의 버그는 단기적 규칙 추론(short-horizon rule inference)을 필요로 하는 반면, 어려운 버그는 긴 상호작용에 걸친 지속적인 상태 추적(sustained state tracking)을 필요로 한다는 것을 보여준다.
메모리 절제(Memory Ablation). 그림 4에서 알 수 있듯이, 네 가지 실험 구성이 존재하는데, 즉 메모리 없음(no memory), 세션 내 메모리(in-session memory, IS), 세션 간 메모리(cross-session memory, CS), 그리고 전체 메모리 모듈(full memory module, IS+CS)이다. 메모리가 없으면 에이전트(agent)는 테스트된 상태를 빈번하게 재방문하게 되어, 조기 회상 포화(recall saturation)를 초,하게 된다. IS 메모리는 세션 내 루프(loop)를 제거하지만, 세션 간 재탐색을 필요로 한다. 반대로, CS 메모리는 웜스타트(warm-start) 탐색을 가능하게 하지만 세션 내 중복성을 완화하지 못한다. 전체 메모리 모듈은 세션 간의 전략적 초기화와 세션 내 루프 방지를 통합한다. 결과적으로, 전체 메모리 모듈의 성능 추세선은 다른 메모리 설정보다 일관되게 우세하며, 동일한 단계 예산(step budgets)에서 세션 전반에 걸쳐 뚜렷한 이득을 보이며, 이는 세션 내 궤적 추적(intra-session trajectory tracking)과 세션 간 지식 축적(inter-session knowledge accumulation)의 상호 보완적인 이점을 입증한다.
6 Conclusion
우리는 대화형 게임 환경에서 거대언어모델(LLM, Large Language Models)의 자율적 버그 발견 능력을 평가하기 위한 확장 가능한 벤치마크인 GBQA를 제시한다. 실험 결과, 최첨단(state-of-the-art) LLM들은 코드 생성 및 수정 작업에서 강력한 성능을 보임에도 불구하고, 특히 장기적(long-horizon)이고 상태 의존적인(state-dependent) 오류에 대해서는 버그 발견 능력이 여전히 상당히 제한적임을 확인했다. 이러한 결과는 현재의 에이전트(agent) 역량과 실제 품질 보증(QA, Quality Assurance) 요구 사항 사이에 상당한 격차가 있음을 시사한다. GBQA는 표준화된 환경, 정량적 지표, 그리고 신뢰할 수 있는 평가를 제공함으로써, 향후 QA 에이전트의 원칙 있는 설계 및 비교를 위한 기반을 제공한다. 우리는 이 벤치마크가 에이전트적 추론(agentic reasoning)과 소프트웨어 개발의 교차점에서 새로운 연구 방향을 제시할 것이라 믿는다. 향후 연구에서 우리는 GBQA를 게임을 넘어 더 넓은 영역으로 확장하고, 실제 시나리오를 더 잘 반영하기 위해 멀티모달 인지(multimodal perception) 및 GUI 상호작용을 통합할 예정이다.
References
- Aleithan 등(2024) R. Aleithan, H. Xue, M. M. Mohajer, E. Nnorom, G. Uddin, 및 S. Wang SWE-bench+: LLM(대규모 언어 모델)을 위한 강화된 코딩 벤치마크. 외부 링크: 2410.06992, Link 인용 횟수: §2.
- Ammann과 Offutt (2016) P. Ammann 및 J. Offutt 저, 『소프트웨어 테스트 입문』(Introduction to Software Testing), 제2판, 케임브리지 대학교 출판부. 인용: §1.
- Anthropic (2025a) Anthropic Claude code. 참고: https://claude.com/product/claude-code 인용됨: Appendix E, §1.
- Anthropic (2025b) Anthropic, claude sonnet 4.5 출시 발표. 외부 링크: Link 인용: Table 4.
- Anthropic (2026) Anthropic Claude opus 4.6 시스템 카드(system card). 참고: https://www.anthropic.com/claude-opus-4-6-system-card 인용: Table 4.
- Anysphere (2024) Anysphere Cursor. 참고: https://cursor.com/product 인용: §1.
- Cao 등(2026) R. Cao, M. Chen, J. Chen, Z. Cui, Y. Feng, B. Hui, Y. Jing, K. Li, M. Li, J. Lin, Z. Ma, K. Shum, X. Wang, J. Wei, J. Yang, J. Zhang, L. Zhang, Z. Zhang, W. Zhao, and F. Zhou Qwen3-coder-next 기술 보고서(technical report). 외부 링크: 2603.00729, Link 인용 횟수: Table 4.
- Chowdhury 등(2024) N. Chowdhury, J. Aung, C. J. Shern, O. Jaffe, D. Sherburn, G. Starace, E. Mays, R. Dias, M. Aljubeh, M. Glaese, C. E. Jimenez, J. Yang, L. Ho, T. Patwardhan, K. Liu, 및 A. Madry는 swe-bench verified를 발표하였다. 외부 링크: Link 인용: Appendix B, §5.2.
- Fan 등(2022)은 NeurIPS에서 발표된 "MineDojo: 인터넷 규모의 지식을 갖춘 개방형 체화 에이전트(embodied agents) 구축"이라는 논문에서 §2 인용 횟수를 기록했다.
- Google DeepMind (2026) Google DeepMind Gemini 3.1 pro 모델 카드(model card). 외부 링크: Link 인용: Table 4.
- Guo 등(2025a)은 DeepSeek-r1이 강화 학습(Reinforcement Learning)을 통해 대규모 언어 모델(LLMs)의 추론(Reasoning)을 촉진한다는 연구를 *Nature* 645(8081), pp. 633–638에 발표하였다. 외부 링크: ISSN 1476-4687, Link, Document. 인용 횟수: Table 4.
- Guo 등(2025b) J. Guo, C. Wang, X. Xu, Z. Su, 및 X. Zhang RepoAudit: 저장소 수준의 코드 감사(repository-level code auditing)를 위한 자율적 LLM 에이전트(LLM-agent). 제42회 국제 머신러닝 컨퍼런스(International Conference on Machine Learning), 외부 링크: Link 인용: §1, §2.
- Hong 등(2024) S. Hong, M. Zhuge, J. Chen, X. Zheng, Y. Cheng, J. Wang, C. Zhang, Z. Wang, S. K. S. Yau, Z. Lin, et al. MetaGPT: 다중 에이전트 협업 프레임워크를 위한 메타 프로그래밍(meta programming). 제12회 국제 표현 학습 컨퍼런스(The twelfth international conference on learning representations) 발표, 인용 횟수: §1.
- Jimenez 등(2024)은 "SWE-bench: 언어 모델이 실제 GitHub 이슈를 해결할 수 있는가?"라는 논문을 제12회 국제 학습 표현 컨퍼런스(The Twelfth International Conference on Learning Representations, ICLR)에서 발표하였다. 외부 링크: Link, 인용 횟수: §1, §2.
- Karpathy (2025) A. Karpathy 바이브 코딩(vibe coding) 개념. 참고: https://x.com/karpathy/status/1886192184808149383 X 포스트 인용 횟수: §1.
- Krippendorff (2018) K. Krippendorff 내용분석(Content analysis): 방법론 입문. 제4판, SAGE Publications. 인용 횟수: §5.4.
- Liu 등(2024) AgentBench: 에이전트로서의 대규모 언어 모델(LLMs) 평가. 제12회 국제 학습 표현 컨퍼런스(The Twelfth International Conference on Learning Representations) 발표. 외부 링크: Link 인용 횟수: §2.
- Mu 등 (2025) E. Mu, M. Yoda, Y. Zhang, M. Zhang, Y. Matsuno, and J. Li 코드 커버리지(code coverage)와 게임플레이 의도(gameplay intent)의 시너지: LLM 기반 강화 학습(llm-guided reinforcement learning)을 활용한 커버리지 인식 게임 플레이 테스트. 외부 링크: 2512.12706, Link 인용 횟수: §2.
- Myers (1979) G. J. Myers 소프트웨어 테스트의 기술(Art of software testing). 외부 링크: Link 인용: §1.
- OpenAI (2025a) OpenAI codex. 참고: https://openai.com/codex/ 인용됨: §1.
- OpenAI (2025b) OpenAI의 gpt-5 시스템 카드 업데이트: gpt-5.2. 참고: https://openai.com/index/gpt-5-system-card-update-gpt-5-2/ 인용: Table 4.
- Park 등(2025) Orak: 다양한 비디오 게임에서 거대언어모델(LLM) 에이전트를 훈련하고 평가하기 위한 기초 벤치마크. arXiv preprint arXiv:2506.03610. 인용 횟수: §2.
- Park 등(2023) J. S. Park, J. C. O’Brien, C. J. Cai, M. R. Morris, P. Liang, 및 M. S. Bernstein 생성형 에이전트: 인간 행동의 상호작용적 시뮬라크르(Generative agents: interactive simulacra of human behavior). arXiv preprint arXiv:2304.03442. 인용 횟수: §2.
- Pearson (1901) K. Pearson LIII. on lines and planes of closest fit to systems of points in space. The London, Edinburgh, and Dublin philosophical magazine and journal of science 2 (11), pp. 559–572. 인용 횟수: §5.4.
- Qian 등(2024)은 "ChatDev: 소프트웨어 개발을 위한 의사소통형 에이전트(communicative agents)"라는 논문을 제62회 계산 언어학 협회 연례 회의(Association for Computational Linguistics, ACL) 논문집(제1권: 장문 논문)에 발표하였다(Bangkok, Thailand, pp. 15174–15186). 외부 링크: Link, Document. 인용 횟수: §1.
- Tan 등(2024)은 Cradle: 범용 컴퓨터 제어를 위한 파운데이션 에이전트(foundation agents) 강화(empowering) 연구를 발표하였다. 외부 링크: 2403.03186, 인용 횟수: §2. Link
- Wang 등(2025)은 "LLM 에이전트(LLM agents)를 활용한 자동화된 비디오 게임 테스트(automated video game testing)"를 주제로 연구를 수행하였다. (C. Wang, L. Tang, M. Yuan, J. Yu, X. Xie, and J. Bu. arXiv preprint arXiv:2509.22170.) 인용 횟수: §2.
- Wang 등(2023)은 NeurIPS에서 발표한 "Voyager: large language models(거대언어모델)를 활용한 개방형 체화 에이전트(open-ended embodied agent)" 연구를 수행하였으며, 해당 논문은 §2회 인용되었습니다.
- Wu 등(2025) Q. Wu, Y. Xiao, D. Kirat, K. Eykholt, J. Jang, 및 D. L. Schales. 하나의 버그 뒤에 숨겨진 수백 개의 문제: 대규모 버그 발견을 위한 거대언어모델(Large Language Models, LLMs). arXiv preprint arXiv:2510.14036. 인용: §1, §2.
- Xia 등(2024)은 "Agentless: demystifying llm-based software engineering agents" (LLM 기반 소프트웨어 공학 에이전트의 실체 규명)라는 제목의 논문을 arXiv(arXiv:2407.01489)에 발표하였다. 이 논문은 §1, §2에서 인용되었다.
- Yao 등(2023) S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, 및 Y. Cao ReAct: 언어 모델에서 추론과 행동의 시너지(synergizing reasoning and acting in language models). ICLR 발표, 인용 횟수: §4.1.
- Zhang et al. (2025) B. Zhang, K. Lazuka, and M. Murag Equipping agents for the real world with agent skills . Anthropic . 참고: https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills 인용됨: §3.2 .
- Zhou 등(2024)은 "WebArena: 자율 에이전트(autonomous agents) 구축을 위한 실질적인 웹 환경"이라는 논문을 제12회 국제 학습 표현 컨퍼런스(The Twelfth International Conference on Learning Representations)에서 발표하였다. 외부 링크: Link 인용 횟수: §2.
부록 A 게임 환경 빌더(Game Environment Builder)의 세부 사항
이 섹션에서는 GBQA에서 채택된 다중 에이전트(multi-agent) 환경 구축 시스템을 상세히 설명한다. 기존의 프롬프트 체이닝(prompt-chaining) 방식과 달리, 본 빌더는 전문적인 게임 개발 파이프라인을 모방한 스튜디오 기반의 계층적 구조를 채택한다. 프로듀서 에이전트(Producer Agent)는 전체 프로젝트 상태를 유지하고, 하위 개발을 안내하기 위한 기초 제안을 하달하며, 최종적으로 모든 팀 결과물이 완료되면 통합된 환경을 컴파일한다.
A.1 하향식 스튜디오 조직 (Top-Down Studio Organization)
이 아키텍처는 중앙의 프로듀서 에이전트(Producer Agent)와 디자인(Design), 프로그래밍(Programming), 아트(Art)라는 세 개의 전문 팀으로 구성됩니다. 각 팀은 전담 리더 에이전트(각각 리드 디자이너(Lead Designer), 기술 디렉터(Technical Director), 아트 디렉터(Art Director))의 감독을 받습니다. 이러한 리더들은 단순히 수동적인 메시지 라우터(message routers) 역할을 하는 것이 아니라, 프로젝트 실행을 능동적으로 관리합니다. 즉, 이들은 상위 지시사항을 세분화하고, 작업자 풀(worker pools)을 동적으로 조정하며, 에이전트 생명주기(agent lifecycles)를 감독하고, 결과물을 검증하며, 프로듀서와 진행 상황을 동기화합니다.
각 팀은 독립된 작업 공간인 ./project/docs(설계 사양), ./project/code(구현), ./project/assets(시각적 자산) 내에서 활동한다. 따라서 프로듀서(Producer)는 단일 구조의 생성 프로세스가 아닌, 분산된 다중 작업 공간 파이프라인(multi-workspace pipeline)을 조율한다.
A.2 생산자 수준의 제안 형성 (Producer-Level Proposal Formation)
파이프라인은 제안 수립(proposal formulation)으로 시작된다. 팀 단위의 실행에 앞서, 생산자 에이전트(Producer Agent)는 네 가지 핵심 매개변수를 명시함으로써 프로젝트의 전략적 방향을 설정한다. 이는 (1) 장르 및 구조적 유형, (2) 메커니즘적 영감을 위한 참고 작품, (3) 서사적 전제 및 핵심 게임플레이 루프(core gameplay loops), 그리고 (4) 미학적 톤과 시각적 스타일 가이드라인이다.
이러한 매개변수들은 하나의 통합된 제안서로 통합되며, 이는 후속 개발을 위한 권위 있는 사양서(specification) 역할을 한다. 설계팀(Design Team)은 이 제안서로부터 공식 규칙 세트를 도출하고, 프로그래밍팀(Programming Team)은 그에 대응하는 환경, 핵심 게임플레이 로직 및 상호작용 API(interaction APIs)를 구현하며, 아트팀(Art Team)은 자산 제작을 이 제안서의 스타일 지침에 맞춘다. 예를 들어, CASTLE 환경(부록 D)에서 제안서는 유령이 나오는 저택을 배경으로 한 결정론적(deterministic) 텍스트 어드벤처를 규정하며, 이는 3가지 핵심 키를 기반으로 한 진행 루프와 분위기 중심의 퍼즐 기반 미학을 핵심으로 한다.
A.3 팀 수준 계획 단계 (Team-Level Planning Phase)
제안을 받으면, 각 리더는 상위 지침을 실행 가능한 작업 패키지(work packages)로 변환하기 위한 구조화된 계획 단계를 시작한다. 이 과정에는 계층적 작업 분해(hierarchical task decomposition)가 포함된다. 즉, 전략적 목표는 먼저 하위 작업으로 분해되고, 이 하위 작업들은 개별 작업자 에이전트(worker agents)에게 할당될 수 있는 원자적 작업(atomic operations)으로 더욱 세분화된다. 각 원자적 작업에 대해, 리더는 계산 부하(computational workload)를 추정하고 중요도를 평가하며, 작업 의존성 및 우선순위 그래프(Task Dependency and Priority Graph)를 구축한다.
thought 이 그래프는 핵심적인 스케줄링 아티팩트(scheduling artifact)로서, 실행 제약 조건(예: 선행 출력물), 병렬화 기회, 그리고 자원 인지형 우선순위 정책(resource-aware prioritization policies)을 인코딩한다. 그래프 토폴로지(topology)는 팀마다 동일하지만, 그 내용은 워크스페이스에 따라 달라진다. 즉, 디자인 팀은 문서화 및 사양 초안 작성을 모델링하고, 프로그래밍 팀은 구현 및 통합 워크플로우를 매핑하며, 아트 팀은 에셋 생성 및 UI 스타일링 파이프라인을 구조화한다.
1. 팀 수준 실행 단계 (Team-Level Execution Phase)
1차 의존성 그래프(dependency graph)가 확정되면 실행이 시작된다. 고정된 워커 할당(static worker allocation) 방식을 사용하는 대신, 리더는 동적 런타임 스케줄링(dynamic runtime scheduling)을 구현한다. 즉, 리더는 준비된 작업 전선(ready-task frontier)을 처리하기 위해 워커 에이전트(worker agents)를 필요에 따라 인스턴스화하고, 원자적 연산(atomic operations)을 활성 워커에 매핑하며, 의존성이 해결됨에 따라 자원을 지속적으로 재균형(rebalance)한다. 그림 5에서 보듯이, 이러한 메커니즘은 탄력적인 팀 확장(elastic team scaling)과 적응형 작업 할당(adaptive task assignment)을 가능하게 한다.
1차적으로 변화하는 작업 그래프(task graphs)를 처리하기 위해서는 동적 할당(Dynamic allocation)이 필수적이다. 여기서 병렬화 가능한 작업들은 동시에 진행될 수 있는 반면, 의존성이 있는 작업들은 선행 결과물이 검증될 때까지 대기열에 머물게 된다. 결과적으로, 각 리더는 능동적인 스케줄러(scheduler)로서 에이전트(agents)를 배치하고, 의존성 제약 조건을 강제하며, 생산 수명 주기 전반에 걸쳐 처리량(throughput)을 최적화하는 역할을 수행한다.
1.5 공유 지원 플랫폼 및 기술 결합 (Skill Binding)
1. 워커 에이전트(Worker agents)는 중앙 집중식 공유 지원 플랫폼(Shared Support Platform)에서 제공되는 작업별 기술 번들(skill bundles)을 통해 인스턴스화된다. 빌더(builder)는 모든 에이전트가 동일한 역량을 갖는다고 가정하는 대신, 기술을 초기화 단계에서 에이전트와 동적으로 결합되는 모듈형 재사용 가능 프리미티브(reusable primitives)로 취급한다. 이러한 설계는 오케스트레이션 로직(orchestration logic)을 기능적 역량으로부터 분리하여, 정밀한 역할 전문화와 효율적인 역량 관정을 가능하게 한다.
1단계 기술 구조(stratified skill architecture)를 통해 해당 플랫폼은 세 팀 모두를 지원합니다.
- 1. 일반 기술(General Skills): searching-files-and-folders(파일 및 폴더 검색), web-search(웹 검색), reading-files(파일 읽기), editing-files(파일 편집), 그리고 run-terminal-commands(터미널 명령 실행)를 포함한 팀 간 유틸리티(Cross-team utilities).
- • 디자인 팀 기술(Design Team Skills): 사양서 초안 작성 및 디자인 문서화의 중추를 형성하는 .docx, .xlsx, .pptx, .pdf, .md 아티팩트(artifacts)를 작성하고 관리하기 위한 문서 중심 도구(Document-centric tools)들.
- • 프로그램 팀 기술(Program Team Skills): 환경 스캐폴딩(scaffolding) 및 코드 통합을 위한 git-essential, develop-web-game, react-template-generation과 같은 구현 중심의 역량.
- • 아트 팀 기술(Art Team Skills): 에셋 합성 및 인터페이스 스타일링을 위한 이미지 생성(image-generation), 이미지 이해(image-understanding), UI-UX-Pro-Max, 그리고 배치 이미지 생성(batch-image-generation)을 포함한 창의적 제작 도구.
- • 메타 기술(Meta Skills): 프로젝트 요구사항이 변화함에 따라 플랫폼이 자체의 능력 정의를 수정할 수 있게 하는 런타임 연산(Runtime operations) (create-skill, edit-skill, delete-skill)입니다.
메타 기술(Meta Skills)은 장기적 적응성(long-horizon adaptability)을 확보하는 데 필수적이다. 실행 시점(runtime)에 기술 정의의 생성, 개선 및 폐기(deprecation)를 허용함으로써, 해당 플랫폼은 아키텍처의 재설계 없이도 지속적인 역량 확장을 지원한다. 이는 전통적인 스튜디오의 툴체인(toolchain) 업그레이드와 유사하며, 이러한 메커니즘을 통해 빌더는 반복적으로 진화(예: 기본 이미지 생성 기술에 배치 처리 파이프라인을 확장)할 수 있으며, 이를 통해 다양하고 복잡한 생성 작업 전반에서 지속적인 유효성을 보장한다.
A.6 워크스페이스 검토 및 에이전트 생애주기(Agent Lifecycle)
작업이 완료되면, 워커 에이전트(worker agents)는 글로벌 프로젝트 상태를 직접 수정하는 대신 지정된 팀 워크스페이스(team workspace)에 결과물을 커밋(commit)한다. 이후 팀 리더는 생산자 제안(producer proposal), 로컬 작업 사양(local task specifications), 그리고 의존성 제약 조건(dependency constraints)을 바탕으로 구조화된 검증을 수행한다. 모든 기준을 충족하는 결과물만이 워크스페이스에 병합되며, 이 시점에 해당 작업은 완료로 표시되고 계획 그래프(planning graph)가 업데이트된다. 그 후 워커 에이전트는 종료된다.
이 인스턴스화-실행-검토-정리(instantiate–execute–review–cleanup) 사이클은 모든 팀에 걸쳐 에이전트 생애주기(agent lifecycle)를 표준화합니다. 에이전트를 지속적인 개체가 아닌 일시적인 컴퓨팅 단위(ephemeral compute units)로 취급함으로써, 빌더는 상태 드리프트(state drift), 자원 경합(resource contention), 그리고 컨텍스트 오염(context pollution)을 방지할 수 있습니다. 에이전트는 오직 활성 작업 프런티어(active task frontier)를 위해서만 프로비저닝되며, 결과물이 통합되는 즉시 폐기되어 결정론적이고 확장 가능한 실행을 보장합니다.
CASTLE 환경은 이러한 파이프라인을 실제 사례로 보여준다. 제작자(Producer)는 핵심 장르와 분위기 제약 조건을 설정하고, 디자인 팀(Design Team)은 8개 방의 진행 과정과 퍼즐 의존성(puzzle dependencies)을 공식화하며, 프로그래밍 팀(Programming Team)은 상태 기반 백엔드(stateful backend)와 상호작용 API(interaction APIs)를 구현하고, 아트 팀(Art Team)은 그에 대응하는 사용자 인터페이스(UI) 및 시각적 자산을 제작한다. 모든 결과물은 통합된 사양(specification)에 의해 관리되고 중앙 집중식 검토 프로토콜(centralized review protocol)을 통해 검증되기 때문에, 결과적으로 생성된 환경은 구조적 및 의미적 일관성을 유지하며, 이는 재현 가능한 평가와 체계적인 품질 보증(quality assurance)을 직접적으로 가능하게 한다.
부록 B 코드 해결(Code Resolution) 대비 버그 탐지(Bug Detection)에 대한 프런티어 모델 성능
이 섹션에서는 SWE-Bench Verified (Chowdhury et al., 2024)와 본 연구의 벤치마크에서 나타난 프런티어 모델(frontier model)의 성능을 비교함으로써 GBQA(Generalized Benchmark for Quality Assessment)의 난이도를 맥락화한다. SWE-Bench Verified 점수는 공개된 성능과 엄격하게 일치하도록 공식 벤더의 기술 보고서(technical reports) 및 시스템 카드(system cards)에서 직접 추출하였다.
표 4에 나타난 바와 같이, 최첨단(frontier) 모델들은 SWE-Bench Verified에서 우수한 성과를 거두는 반면, GBQA에서는 성능이 상당히 저하된다. 이러한 차이는 기존의 코드 해결(code resolution)과 자율적 버그 발견(autonomous bug discovery) 사이의 근본적인 능력 격차를 강조한다.
구체적으로, SWE-Bench는 명확하고 범위가 잘 정의된 문제 설명이 주어졌을 때 대규모 언어 모델(LLM)이 알려진 결함을 찾아내고 수정(patch)하는 능력을 주로 평가합니다. 이와 대조적으로, GBQA는 에이전트가 동적인 환경을 능동적으로 탐색하고, 명시적인 감독 없이 잠재적인 이상 징후를 찾아내며, 장기적 상호작용(long-horizon interactions) 전반에 걸쳐 일관된 추론을 유지할 것을 요구합니다. 이러한 독립적인 요구사항들은 기존의 코딩 또는 소프트웨어 공학 벤치마크에서 측정되지 않는 복합적인 과제들을 야기합니다.
| Model | SWE-Bench Verified | GBQA | Source |
| Claude-4.6-Opus | 81.4% | 48.39% | (Anthropic, 2026) |
| Gemini-3.1-Pro | 80.6% | 33.06% | (Google DeepMind, 2026) |
| GPT-5.2 | 80.0% | 22.58% | (OpenAI, 2025b) |
| Claude-4.5-Sonnet | 77.2% | 32.26% | (Anthropic, 2025b) |
| Qwen3-Coder-Next | 70.6% | – | (Cao et al., 2026) |
| DeepSeek-R1 | 57.6% | 37.90% | (Guo et al., 2025a) |
부록 C GBQA에서의 프롬프트 설계(Prompt Design)
이 섹션에서는 GBQA에서 에이전트들이 사용하는 기초 프롬프트 구조(foundational prompt architecture)를 상세히 설명한다. { }로 둘러싸인 자리표시자(placeholder)는 에이전트의 역할, 프로젝트 문맥(context), 그리고 작업 사양에 따라 실행 시점에 인스턴스화되는 동적 변수 또는 참조 매크로(reference macros)를 의미한다. 각 에이전트 유형별 운영 책임과 그에 따른 프롬프트 설계는 아래와 같다.
C.1 게임 환경 빌더(Game Environment Builder) 내 에이전트(Agent)를 위한 프롬프트
C.1.1 게임 제작자 에이전트(Game Producer Agent)
C.1.2 팀 리더 에이전트(Team Leader Agent)
C.1.3 워커 에이전트(Worker Agent)
실제 운영 시, 디자인 팀(Design Team), 프로그램 팀(Program Team), 그리고 아트 팀(Art Team)은 동일한 팀 리더 및 작업자 프롬프트 패밀리(prompt family)를 재사용한다. 역할의 차별화는 세 개의 별도 프롬프트 정의를 유지하는 방식이 아니라, {team_role_config}와 그에 부착된 기술 번들(skill bundle)에 의해 수행된다.
C.2 기본 인터랙티브 에이전트(Baseline Interactive Agent)를 위한 프롬프트
보조적 상호작용 에이전트(Auxiliary interactive agent) 출력.
품질 보증(Quality assurance) 모드는 국소적 검증(local verification)과 장기적 기억(long-horizon memory)을 위한 구조화된 중간 결과물을 제공한다. 이러한 프롬프트 구성 요소들은 기본 QA 에이전트가 단순히 과업 완수형 플레이어로 행동하는 대신, 탐색(exploration), 국소적 검증, 그리고 장기적 장부 기록(long-horizon bookkeeping) 사이를 전환하며 작동하도록 유도한다.
C.3 평가를 위한 프롬프트(Prompts)
부록 D 대표 게임 환경
그림 6에서 알 수 있듯이, GBQA는 다양한 장르와 게임플레이 패턴을 아우르는 30개의 상호작용형 게임 환경으로 구성된다. 대표적인 환경들을 묘사한 인터페이스 스크린샷 모음은 그림 7에 제시되어 있다. 이 세트 중에서 우리는 CASTLE을 주요 사례 연구(case study) 대상으로 지정하였으며, 해당 인터페이스는 그림 7 (a)에 묘사되어 있다. CASTLE은 8개의 방으로 구성된 토폴로지(topology)를 특징으로 하는 결정론적(deterministic) 텍스트 어드벤처 게임이다. 플레이어는 홀에서 시작하여, 세 개의 열쇠 조각을 수집하고 이를 결합하여 완전한 열쇠를 만든 뒤, 최종 잠금 해제 상호작용을 수행함으로써 봉인된 홀 문을 열어야 한다. 결과적으로 CASTLE은 벤치마크의 핵심 게임플레이 메커니즘, 진행 구조, 그리고 QA(품질 보증) 관련 상태 전이(state transitions)를 설명하기 위한 간결하면서도 포괄적인 사례로 기능한다.
세계 구조와 전개.
방 그래프(room graph)는 간결하면서도 단순하지 않게 설계되었습니다. 홀(hall)은 복도, 주방, 창고, 그리고 지하를 연결하는 중심 허브 역할을 합니다. 복도는 침실과 도서관으로 갈라지며, 다락방은 사다리가 배치된 후에만 도서관을 통해 접근할 수 있습니다. 진행은 명확한 선행 조건(prerequisites)에 의해 제한됩니다. 침실에는 창고를 여는 데 필요한 소형 열쇠가 있으며, 창고에는 열쇠 조각과 오일 램프가 있습니다. 도서관은 다락방 상자를 여는 데 필요한 단서를 제공하며, 지하의 내용을 안전하게 조사하고 조작하려면 광원이 필요합니다.
상태론적 역학(Stateful Mechanics).
해당 환경은 품질 보증(Quality Assurance)과 관련된 다양한 메커니즘을 포함한다. 인벤토리 관리(Inventory management)는 6개 품목의 휴대 제한으로 제약되며, 컨테이너와 잠금 장치는 숨겨진 오브젝트에 대한 단계적 접근을 강제하고, 방 설명은 현재 보이는 정보만을 공개한다. 구체적으로, 암실 메커니즘(dark-room mechanic)은 지하를 조사하기 전에 플레이어가 유효한 광원을 휴대하고 점화해야 함을 규정한다. 이러한 메커니즘들은 단일 단계 관찰 버그(single-step observation bugs), 단기적 전제 조건 버그(short-horizon prerequisite bugs), 그리고 장기적 진행 버그(long-horizon progression bugs)를 단일 환경 내에서 테스트할 수 있도록 돕는다.
| Room | Primary role in progression | Key objects | Mechanic stressed during QA |
| Hall | Start state and final exit gate | sealed door, matches, candlestick | Initial observation, pickup behavior, final win-condition verification |
| Corridor | Routing hub between early branches | portrait, torch bracket | Navigation consistency and branching exploration |
| Bedroom | Early hidden-item branch | bed, bedside drawer, diary, small key | Hidden information, container visibility, item discovery |
| Kitchen | Utility branch for later access | stove, bucket, ladder | Portable tool acquisition and cross-room dependency |
| Storage | Locked side room unlocked by bedroom key | toolbox, rope, oil lamp, key fragment B | Lock semantics, container interaction, item gating |
| Library | Knowledge branch before attic access | bookshelves, reading desk, scroll | Reading clues, information retrieval, ladder placement dependency |
| Attic | Late puzzle branch | old chest, telescope, key fragment A | Password-gated access and delayed reward |
| Basement | Dark-room branch for final fragment | wine barrels, rusted iron door, key fragment C | Light-source precondition, stateful inspection, multi-step unlocking |
백엔드 인터페이스(Backend Interface).
QA 에이전트(QA agent)는 오직 백엔드 API를 통해서만 CASTLE과 상호작용합니다. 새로운 세션은 POST /api/agent/new를 통해 초기화되며, 동작은 POST /api/agent/command를 통해 명령이 하달되고, 현재 상태는 GET /api/agent/state/{game_id}를 통해 조회됩니다. 각 응답에는 최신 텍스트 관측값(textual observation)과 함께 현재 방, 가시적인 출구, 인벤토리, 플래그(flags), 턴 카운터(turn counter) 및 가시성 상태(visibility status)를 포함하는 구조화된 상태 요약이 포함됩니다. 이 인터페이스는 QA 에이전트가 구현된 시스템에 의해 노출된 정보에만 접근하도록 보장하고, 숨겨진 개발자 메타데이터를 배제한다는 점에서 매우 중요합니다.
정답 버그 목록(Ground-truth Bug List).
CASTLE을 위한 버그 데이터셋은 질문 답변(QA)과 관련된 서로 다른 세 가지 오류 패턴인 논리 오류(logic error), 설명 결함(description flaw), 그리고 데이터 불일치(data inconsistency)를 나타내는 인간이 검증한 세 개의 버그로 구성된다.
| ID | Bug type | Difficulty | Minimal reproduction | Observed fault |
| 1 | logic error | Easy | Collect any two key fragments and execute combine. | The player can assemble the complete key with only two fragments, instead of all three. |
| 2 | description flaw | Easy | Enter the bedroom and execute look before opening the bedside drawer. | The room description reveals the hidden small key before the drawer has been opened. |
| 3 | data inconsistency | Medium | Pick up any portable item, move to a room, execute drop, then execute look. | The dropped object does not appear in the updated room description, so the textual state fails to reflect the backend change. |
부록 E 사례 연구: 완전 자율형 에이전트 기반 코딩 시스템(Agentic Coding Systems)을 향하여
서론에서 논의하고 그림 1에서 보여주었듯이, LLM(거대언어모델) 시대의 소프트웨어 개발은 인간과 LLM의 공동 편집을 넘어 완전 자율형 코딩 시스템으로 확장됩니다. 이러한 시스템에서 에이전트(agent)는 구현뿐만 아니라, 전통적으로 인간 테스터가 수행하던 상위 QA(품질 보증) 프로세스까지 책임집니다. QA 에이전트는 제품을 지속적으로 탐색하여 논리적 오류와 동작 불일치를 식별하고, 구조화된 버그 보고서를 생성하며, 이를 후속 검증을 위한 패치 버전을 생성하는 코딩 에이전트에게 전달합니다.
기존의 대부분 벤치마크는 인간이 지정한 이슈에 기반한 코드 생성이나 버그 수정에 초점을 맞추는 반면, GBQA는 자율적인 버그 발견(autonomous bug discovery)을 가능하게 함으로써 이 루프에서 누락된 구성 요소를 목표로 합니다. 본 사례 연구는 이러한 발견 모듈이 어떻게 엔드투엔드(end-to-end) 결함 발견 및 수정 파이프라인(remediation pipeline)에 통합될 수 있는지를 보여줍니다.
실험 설정.
우리는 GBQA의 CASTLE 환경에서 전체 폐루프 시스템(closed-loop system)을 평가한다. QA 구성 요소는 품질 보증 모드(Quality Assurance Mode, 섹션 3.1)에서 작동하는 우리의 대화형 에이전트(interactive agent)로 구성되며, 이 에이전트는 진단을 위해 설계 사양 및 소스 코드를 선택적으로 참조하며 환경을 탐색한다. 우리는 코딩 에이전트(coding agent)로 Claude Code (Anthropic, 2025a)를 사용하며, 이 에이전트는 QA에서 생성된 보고서를 수용하고 코드베이스를 수정하여 패치된 버전을 반환한다.
본 연구에서는 두 에이전트(agent) 모두에 대해 Claude-4.6-Opus-Thinking을 기본 모델로 사용하여, 성능 차이가 기초 역량이 아닌 역할 전문화(role specialization)에서 비롯되는 통제된 환경을 보장한다. 질의응답(QA) 에이전트는 세션 내 메모리(in-session memory)와 세션 간 메모리(cross-session memory)를 모두 포함하는 전체 메모리 모듈을 갖추고 있으며, 이를 통해 장기적 추론(long-horizon reasoning)과 경험 재사용이 가능하다. 각 QA 세션은 최대 300단계의 상호작용으로 제한된다. 중요하게는, 전체 파이프라인이 인간의 개입 없이 작동하며, 이는 완전한 자율 개발 주기(autonomous development cycle)를 반영한다.
폐루프 궤적(Closed-Loop Trajectory).
표 7은 세 차례의 자율적 결함 발견 및 수정(autonomous defect discovery and remediation) 반복 과정에 따른 세션별 궤적(trajectory)을 요약하여 보여준다. 세션 1(Session 1)에서 QA 에이전트(QA agent)는 BUG-2와 BUG-3을 발견하고 두 결함에 대한 수정 보고서를 제출한다. 세션 2(Session 2)는 이러한 수정 사항들에 대한 검증으로 시작되며, 두 버그가 올바르게 해결되었음을 확인한 후, 추가 탐색 과정에서 나머지 BUG-1을 발견한다. 세션 3(Session 3)에서 에이전트는 최종 수정을 검증하고, BUG-1의 근본 원인(root cause)이 "3개 미만의 단편(fewer than three fragments)" 실행 경로 내의 잘못된 조건 규칙임을 식별한다.
우리는 전체 상호작용 추적(interaction traces)을 제공하기보다 세션 단위의 결과를 보고하는데, 이러한 추상화 방식이 자율적 개발(autonomous development)의 반복적인 특성을 더 잘 포착하기 때문입니다. 요약 행은 세션 전반에 걸친 전체 버그 발견 및 수정률을 집계합니다.
| Session | QA Findings | Claude Code Repair Outcome | Verification / Session Result | Discovery Rate / Fixing Rate |
| 1 | Newly discovered BUG-2 and BUG-3 | Repair the hidden-key leakage in the bedroom description and refresh the room description after drop. | Both reported issues are patched and scheduled for QA verification in Session 2. | Discovery: 2/3 Fixing: pending verification |
| 2 | Verify BUG-2 and BUG-3 as fixed; discover and report BUG-1 | Patch the fragment-combination logic after the new BUG-1 report is submitted. | QA confirms BUG-2 and BUG-3 behave normally after repair. BUG-1 remains the only unresolved defect entering Session 3. | Discovery: 3/3 Fixing: 2/3 |
| 3 | Verification-focused session for BUG-1; no additional bugs reported | Correct the erroneous conditional on the “fewer than three fragments” path so key combination is allowed only with all three fragments. | QA confirms BUG-1 is fixed and no released CASTLE bug is reproduced on the targeted verification paths. | Discovery: 3/3 Fixing: 3/3 |
| Total | BUG-001, BUG-2, and BUG-3 all discovered across the three sessions | Claude Code successfully repairs all reported bugs. | Final verification confirms that all three human-verified CASTLE bugs are fixed. | Discovery: 3/3 (100%) Fixing: 3/3 (100%) |
주요 관찰 사항.
이 사례 연구는 자율 코딩 시스템(autonomous coding systems)에 필수적인 세 가지 속성을 강조한다.
먼저, QA 에이전트(QA agent)는 사람이 작성한 이슈 설명 없이 결함을 발견함으로써 전체 개발 루프(development loop)를 위한 상위 신호(upstream signal)를 제공하며, 이를 통해 QA를 수동적인 검증 단계에서 능동적인 탐색 프로세스로 전환합니다.
둘째, 검증과 발견은 순차적이라기보다 상호 얽혀(interleaved) 일어난다. 예를 들어, 세션 2(Session 2)에서는 이전의 수정 사항들을 동시에 검증하는 동시에 새로운 결함을 찾아내는데, 이는 효과적인 품질 보증(QA, Quality Assurance)을 위해서는 겉보기에 수렴(convergence)이 이루어진 이후에도 지속적인 탐색이 필요함을 보여준다.
셋째, 시스템의 효과는 버그 발견(bug discovery)과 코드 수정(code repair)이 공동으로 평가될 때만 나타난다. 어느 한 구성 요소만을 개별적으로 평가하는 것은 전체 폐쇄 루프(closed loop)의 역학을 포착하지 못할 것이다.
전반적으로, 자율 QA 에이전트(autonomous QA agent)는 3회 세션 내에 공개된 3개의 버그를 모두 찾아냈으며, Claude Code는 이를 모두 성공적으로 수정하여 CASTLE 환경에서 100%의 발견 및 수정률을 달성했다. 이러한 결과는 결함 발견(defect discovery) 단계를 자동화할 수 있는 가능성을 입증하며, 완전한 자율형 에이전트 기반 코딩 시스템(agentic coding systems)을 향한 구체적인 단계로 나아가는 발판을 제공한다.
부록 F 라벨링 지침
F.1 과제 개요
당신의 과업은 자율적인 게임 플레이(autonomous gameplay) 중에 생성된 후보 버그 보고서(candidate bug reports)를 검토하고, 각 후보가 대상 게임 환경에서 유효한 소프트웨어 버그에 해당하는지 여부를 판단하는 것입니다. 각 주석 작업(annotation task)에서 다음 항목이 제공됩니다: (i) 플레이 가능한 게임 빌드(build) 및 그에 해당하는 설계 사양(design specification). (ii) QA 에이전트(QA agent)가 작성한 후보 버그 보고서. (iii) 해당 환경에 대해 이미 수락된 버그 ID 세트(있을 경우).
당신의 임무는 관련 상호작용을 재현하고, 보고된 동작이 유효한 버그인지 판단하며, 적절한 경우 발견 난이도(discovery-difficulty) 레이블을 할당하고, 추후 검증에 필요한 최소 재현 단계(minimal reproduction steps)를 기록하는 것입니다.
F.2 주석가에게 제공된 자료
귀하는 현재 과제에 제공된 자료에만 근거하여 판단해야 합니다.
- • 플레이어블 빌드(Playable Build): 평가 대상이 되는 실행 가능한 웹 게임 또는 백엔드 접근이 가능한 게임 인스턴스.
- • 설계 사양(Design Specification): 방 구조, 아이템 로직, 진행 요구 사항 및 승리 조건(victory conditions)을 포함한 환경의 의도된 규칙.
- • 후보 버그 보고서(Candidate Bug Report): QA 에이전트가 의심되는 결함에 대해 기술한 자연어 설명으로, 대개 짧은 추적 기록(trace)이나 설명이 수반됩니다.
- • 기존 수용된 버그(Existing Accepted Bugs): 중복을 식별하기 위해 사용되는, 동일한 환경에서 이미 검증된 버그 ID의 현재 목록.
만약 후보 버그 보고서(bug report)가 중요한 세부 사항을 누락했다면, 당신은 인접한 상호작용 경로(interaction paths)를 재실행하여 재현 시퀀스(reproduction sequence)를 직접 개선할 수 있습니다. 하지만, 최종 주석(annotation)은 반드시 당신이 실제로 검증한 동작에 근거해야 합니다.
F.3 유효한 버그(Valid Bug)의 정의
후보(candidate)는 다음의 모든 조건이 충족될 때만 유효(valid)한 것으로 표시되어야 한다:
- • 재현 가능성(Reproducible): 구체적인 행동 시퀀스(action sequence)를 통해 해당 동작을 신뢰성 있게 유발할 수 있음.
- • 행동적 오류(Behaviorally Incorrect): 관찰된 동작이 설계 사양(design specification) 또는 인터페이스를 통해 암시되는 명확한 사용자 기대와 모순되는 경우를 의미한다.
- • 시스템 유발(System-Caused): 해당 문제는 모호한 문구, 지원되지 않는 자유 형식의 입력 또는 잘못된 플레이어 전략 때문이 아니라, 게임 구현(game implementation)에 의해 발생한다.
다음 상황에서는 후보를 유효한 버그(valid bug)로 표시하지 마십시오:
- • 해당 보고서는 오직 난이도, 혼란 또는 비효율적인 전략만을 기술한다.
- 해당 보고서는 문서화된 명령 세트(command set) 밖에 있는 명령에 의존합니다.
- 게임은 필수 선행 조건(prerequisite)이 아직 충족되지 않았기 때문에 해당 행동을 올바르게 차단한다.
- 증거가 너무 불충분하거나 모호하여 확신을 가지고 결정을 내리기에는 무리가 있다.
F.4 난이도 주석(Annotation) 기준
후보가 유효할 때, 다음 중 하나의 발견 난이도(discovery-difficulty) 레이블을 할당한다:
Easy
버그는 단 한 번의 행동이나 관찰만으로도 즉각적으로 확인이 가능하다. 순차적 추론(sequential reasoning)이 거의 또는 전혀 필요하지 않다. 대표적인 예로는 명백하게 잘못된 방 설명, 형식이 잘못된 인벤토리 업데이트, 또는 단 한 번의 명령 후에 바로 드러나는 모순 등이 있다.
Medium
버그를 발견하기 위해서는 짧지만 의미 있는 상호작용 체인(interaction chain)이 필요하다. 테스터는 전제 조건(prerequisite)을 충족해야 하거나, 여러 단계에 걸쳐 예상되는 동작과 실제 동작을 비교해야 하거나, 잠금 의미론(lock semantics), 컨테이너 가시성(container visibility), 또는 아이템 사용과 같은 지역 규칙(local rule)에 대해 추론해야 한다.
Hard
해당 버그는 여러 방에 걸친 장기적 추적(long-horizon tracking), 지연된 의존성(delayed dependencies), 또는 유발 동작보다 훨씬 나중에 결과가 나타나는 상호작용을 요구한다. 테스터는 위반 사항이 명확해지기 전까지 의도된 진행 과정에 대한 안정적인 정신 모델(mental model)을 유지해야 한다.
F.5 중복 및 비버그(Non-Bug) 처리
중복 보고.
만약 후보가 이미 수용된 버그와 동일한 근본적인 결함(underlying defect)을 설명하는 경우, 이를 중복(duplicate)으로 표시하십시오. 문구는 정확히 일치할 필요가 없습니다. 중요한 것은 해당 보고서가 실질적으로 동일한 재현 조건(reproduction condition) 하에서 동일한 결함 동작을 언급하는지 여부입니다. 이 경우, 일치하는 버그 ID를 기록하고 두 보고서가 왜 동일한 문제를 언급하는지 간략하게 설명하십시오.
버그 보고서가 아님.
만약 후보 결과가 재현 가능하고 설계 사양(design specification)과 일치한다면, 이를 비버그(non-bug)로 분류하십시오. 여기에는 의도된 전제 조건 실패(prerequisite failures), 올바른 퍼즐 게이팅(puzzle gating), 그리고 게임 규칙 하에서 특이하지만 여전히 유효한 관측 결과들이 포함됩니다.
불확실한 사례들.
문제를 안정적으로 재현할 수 없거나, 설계 사양(design specification)을 확인한 후에도 의도된 동작이 여전히 모호하다면, 해당 후보를 불확실(uncertain)로 표시하십시오. 추측하지 마십시오.
F.6 요구되는 출력 형식
번역할 원문 텍스트를 제공해 주시면, 요청하신 지침에 따라 번역을 진행하겠습니다. 원문을 입력해 주세요.
F.7 사례 연구
다음 예시는 공개된 CASTLE 환경을 사용합니다.
환경: CASTLE
후보 보고서: 침실 묘사(description)를 통해, 서랍이 아직 열리지 않았음에도 불구하고 침대 옆 서랍 안에 작은 열쇠가 들어 있다는 사실이 드러난다.
F.8 주요 고려 사항
- 의도된 동작(intended behavior)을 기준으로 판단하십시오. 해당 메커니즘을 개인적으로 선호하는지 여부에 따라 보고서를 거부하거나 수용하지 마십시오. 핵심은 구현 방식이 명시되었거나 명확하게 암시된 규칙과 모순되는지 여부입니다.
- • 최소한의 재현 단계를 기록하십시오. 재현 과정(reproduction trace)은 다른 전문가가 동일한 동작을 유발할 수 있을 만큼 충분하면서도, 가능한 한 정확해야 합니다.
- 발견의 관점에서 주석을 다십시오. 난이도 라벨은 개발자가 코드에서 수정하는 데 드는 난이도가 아니라, 플레이를 통해 버그를 찾아내는 것이 얼마나 어려운지를 반영합니다.
- 중복된 항목을 주의 깊게 처리하십시오. 겉보기에는 서로 다른 보고라 하더라도, 동일한 결함 규칙(broken rule)과 동일한 인과 경로(causal path)에 의존한다면 동일한 결함을 설명하는 것일 수 있습니다.
- 번역할 원문 텍스트를 제공해 주시면, 요청하신 지침에 따라 자연스러운 한국어로 번역해 드리겠습니다. 원문을 입력해 주세요.
부록 G LLM 사용 성명서
저희는 문법 오류 수정 및 대안 어휘 제안을 포함한 언어 교정(language polishing)을 위해서만 거대 언어 모델(large language models)을 활용했습니다. 이 모델들은 연구 설계, 분석 또는 결론 도출에 기여하지 않았습니다. 저자들은 본 논문의 무결성과 내용에 대해 전적인 책임을 집니다.