Scarab Systems는 AI 지원 소프트웨어 수리(AI-assisted software repair) 과정에서 Scarab Diagnostic Suite (SDS)를 사용하는 효율성을 공식적으로 평가하기 시작했습니다.

질문은 간단합니다:

진단 거버넌스 계층(diagnostic governance layer)이 에이전트 패칭 워크플로우(agent patching workflow)를 측정 가능한 방식으로 실제로 개선하는가?

이론적으로가 아닙니다.

철학적으로도 아닙니다.

"AI 거버넌스 (AI governance)"라는 말이 책임감 있게 들리기 때문도 아닙니다.

실제 공개 저장소(public repository)를 대상으로, 공개된 업스트림 이슈(upstream issue)와 실제 패치(patch)가 존재하는 구체적인 수리 시나리오에서 확인하고자 합니다.

워크플로우가 더 효율적이 되는가?

에이전트가 더 적은 컨텍스트(context)를 필요로 하는가?

수리가 더 증거 기반(evidence-bound)이 되는가?

프로세스가 낭비를 줄이는가?

이 비교 연구가 살펴본 것이 바로 이것입니다.

사례 (The Case)

테스트 케이스는 공개 이슈 emersion/xdg-desktop-portal-wlr#379였습니다.

해당 이슈는 xdg-desktop-portal-wlr 내의 SelectSources 동작과 관련이 있었습니다.

D-Bus 호출자가 선택 사항인 types 필드를 누락했을 때, 코드는 type_mask를 0으로 초기화했습니다.

이로 인해 다음과 같은 오류와 함께 타겟 선택이 실패했습니다:

wlroots: No supported targets specified

예상되는 동작은 누락된 types를 모니터 캡처(monitor capture)로 기본 설정하는 것이었습니다.

최종 패치는 다음과 같은 한 줄의 수리였습니다:

- uint32_t type_mask = 0;
+ uint32_t type_mask = MONITOR;

SDS가 지원하는 공개 PR(Pull Request)은 다음과 같이 열렸습니다:

emersion/xdg-desktop-portal-wlr#393

검토(review) 시점에 해당 PR은 초안(draft)이 아닌 오픈 상태였으며, 병합 가능(mergeable)하고, 검토가 필요(review-required)하며, Alpine, Arch Linux, FreeBSD 체크를 통과한 상태였습니다.

비교 (The Comparison)

Scarab은 두 가지 워크플로우를 비교했습니다.

첫 번째는 콜드 Codex 베이스라인(cold Codex baseline)입니다.

베이스라인 에이전트는 공개 이슈, 타겟 저장소 스냅샷, 그리고 중립적인 프롬프트(prompt)만을 전달받았습니다. SDS 결과(findings), 비공개 노트, 로컬 수리 이력, 런타임 아티팩트(runtime artifacts), 스탠딩 프로필(standing profiles), 또는 이전의 Scarab 컨텍스트는 전달받지 않았습니다.

두 번째는 SDS 가이드 워크플로우(SDS-guided workflow)입니다.

이 워크플로우는 최종 에이전트 의사결정 전에 수리 경계(repair boundary)를 좁히기 위해 선택된 진단 증거, 타겟-소스 조사(target-source inspection), 그리고 검증 출력(verification outputs)을 사용했습니다.

핵심은 SDS가 더 인상적인 diff (차이점)를 생성할 수 있는지 확인하는 것이 아니었습니다.

핵심은 SDS가 에이전트가 동일한 수정 결정 (repair decision)을 책임감 있게 내리는 데 필요한 컨텍스트 (context)의 양을 줄일 수 있는지 측정하는 것이었습니다.

콜드 베이스라인 (Cold Baseline) 결과

콜드 베이스라인 (cold baseline)은 성공했습니다.

이것은 중요한 지점입니다.

충분한 리포지토리 컨텍스트 (repository context)가 주어졌을 때, Codex는 다음과 같은 한 줄 수정 사항을 정확히 식별했습니다:

- uint32_t type_mask = 0;
+ uint32_t type_mask = MONITOR;

또한 호출자가 types를 명시적으로 제공할 때 왜 이 변경 사항이 기존 동작을 유지하는지에 대해서도 정확하게 설명했습니다.

따라서 솔직한 발견은 다음과 같습니다:

"Codex는 SDS 없이는 이 문제를 해결할 수 없었다."

아닙니다. 해결할 수 있었습니다.

더 흥미로운 발견은 에이전트가 그 결과에 도달하기 위해 컨텍스트 측면에서 지불해야 했던 비용입니다.

콜드 베이스라인 (cold baseline)이 사용한 수치는 다음과 같습니다:

• 입력 토큰 (Input tokens): 70,212
• 출력 토큰 (Output tokens): 1,982
• 총 토큰 (Total tokens): 72,194

이것이 오늘날 많은 AI 보조 코딩 (AI-assisted coding)의 표준적인 형태입니다.

모델에게 대규모 리포지토리 페이로드 (repo payload)를 제공합니다.

모델에게 광범위하게 추론하도록 요청합니다.

모델이 올바른 경계 (boundary)를 찾기를 바랍니다.

때로는 찾아내기도 합니다.

하지만 그것이 컨텍스트 전략 (context strategy)이 효율적이라는 것을 의미하지는 않습니다.

SDS 가이드 결과

SDS 가이드 워크플로 (SDS-guided workflow)는 더 좁은 증거 경로 (evidence path)를 통해 동일한 공개 패치 (public patch)에 도달했습니다.

최종 SDS 패치 결정 컨텍스트 (final SDS patch-decision context)는 다음과 같았습니다:

• 최종 SDS 컨텍스트 토큰 (Final SDS context tokens): 2,651

SDS 워크플로의 더 넓은 기록된 총 토큰 수는 다음과 같았습니다:

• 더 넓은 SDS 기록된 총 토큰 수 (Broader SDS recorded-token total): 6,445

패치는 동일했습니다.

차이점은 수정 태세 (repair posture)였습니다.

SDS는 에이전트 워크플로를 다음과 같이 변경했습니다:

대규모 리포지토리 스냅샷 (repo snapshot)을 읽고 광범위하게 추론한다.

에서:

선택된 증거를 사용한다.

소유 소스 경계 (owning source boundary)를 조사한다.

패치를 검증한다.

최종 결정 컨텍스트를 작게 유지한다.

이것이 핵심 결과입니다.

토큰 차이

콜드 베이스라인 (cold baseline)의 입력 토큰 수와 비교했을 때, SDS 가이드 최종 결정 컨텍스트는 약 96.2% 더 적은 토큰을 사용했습니다.

콜드 베이스라인의 총 토큰 수와 비교했을 때, SDS 최종 결정 컨텍스트는 약 27배 더 작았습니다.

더 넓은 범위인 SDS 기록 토큰 수 6,445개를 사용하더라도, SDS 가이드 워크플로우 (SDS-guided workflow)는 콜드 베이스라인 (cold baseline) 입력 수보다 약 90.8% 더 적은 토큰을 사용했습니다.

이 부분이 상업적으로 중요하다고 생각하는 지점입니다.

많은 AI 코딩 인프라가 에이전트 (agent)에게 거대한 페이로드 (payload)가 필요하다는 가정하에 구축되고 있습니다.

그리고 그 거대한 페이로드는 또 다른 문제를 야기합니다.

이제 기업들은 그 페이로드를 관리하기 위한 인프라가 필요해졌습니다.

컨텍스트 압축 (context compression)이 필요합니다.

메모리 시스템 (memory systems)이 필요합니다.

검색 레이어 (retrieval layers)가 필요합니다.

오케스트레이션 (orchestration)이 필요합니다.

더 많은 히스토리를 계속해서 가져갈 수 있는 에이전트가 필요합니다.

하지만 만약 에이전트가 수리 결정 (repair decision)을 내리는 데 70,000개의 토큰 페이로드가 필요하지 않다면 어떨까요?

더 가치 있는 레이어가 더 큰 컨텍스트 관리 시스템이 아니라, 에이전트가 실제로 필요로 하는 더 작은 진실 경계 (truth boundary)를 드러내는 진단 거버넌스 레이어 (diagnostic governance layer)라면 어떨까요?

그것이 바로 SDS가 테스트하고 있는 것입니다.

실제 발견 사항

이번 이슈에서 SDS는 Codex가 다른 수리 방식을 발견하도록 돕지는 않았습니다.

그렇게 주장하는 것은 잘못된 것입니다.

공개된 이슈는 충분히 명확했기에 콜드 베이스라인 또한 올바른 한 줄 패치 (one-line patch)를 찾아냈습니다.

SDS의 가치는 다른 곳에 있었습니다.

SDS는 에이전트를 더 규율 있고, 더 증거에 기반하며, 극적으로 더 컨텍스트 효율적 (context-efficient)으로 만들었습니다.

에이전트에게 더 많은 지능이 필요했던 것이 아닙니다.

에이전트에게는 더 좁은 진실 표면 (truth surface)이 필요했습니다.

이것이 중요한 이유는 실제 환경에서의 패칭 (patching)이 단순히 디프 (diff)를 생성하는 것만이 아니기 때문입니다.

또한 다음과 같은 사항을 아는 것에 관한 것이기도 합니다:

• 왜 이것이 올바른 수리인가?
• 어떤 증거가 이를 뒷받침하는가?
• 어떤 소스 경계 (source boundary)가 해당 동작을 소유하는가?
• 패치가 초과해서는 안 되는 범위는 어디까지인가?
• 어떤 검증기 (validators)가 충분한가?
• 어떤 다운스트림 동작 (downstream behavior)이 온전하게 유지되어야 하는가?

이것들은 거버넌스 (governance) 질문들입니다.

그리고 에이전트 기반의 소프트웨어 변경 (agentic software change) 비용이 급격히 상승하기 시작하는 지점이 보통 바로 여기입니다.

휘발성 컨텍스트의 중요성

여기에는 또 다른 중요한 점이 있습니다.

SDS 가이드 컨텍스트는 휘발성 (ephemeral)이었습니다.

에이전트는 전체 수리 내용을 영구적으로 기억할 필요가 없었습니다.

전체 리포지토리 (repo) 이력을 계속해서 가져갈 필요가 없었습니다.

다음번에 유용하게 사용되기 위해 이 코드베이스에 대한 거대한 장기 실행 내부 상태 (long-running internal state)를 유지할 필요도 없었습니다.

이것이 Scarab 이론의 핵심입니다.

에이전트가 리포지토리의 진실 (truth)을 소유해서는 안 됩니다.

리포지토리 거버넌스 계층 (repo governance layer)이 리포지토리의 진실을 소유해야 합니다.

다음 작업이 들어올 때, 시스템은 관련 있는 운영상의 진실 (operational truth)을 기계적으로, 그리고 작업별로 다시 드러내야 (surface) 합니다.

이는 에이전트에게 모든 것을 기억하도록 요구하는 것과는 매우 다른 아키텍처 (architecture)입니다.

Scarab의 입장은 장기적인 AI 지원 소프트웨어 변경 (long-horizon AI-assisted software change)이 에이전트가 계속해서 커지는 리포지토리 메모리를 들고 다니는 것에 의존해서는 안 된다는 것입니다.

시스템은 다음과 같은 것들을 드러낼 수 있어야 합니다:

• 활성 런타임 진실 (active runtime truth)
• 소유권 경계 (ownership boundaries)
• 검증기 커버리지 (validator coverage)
• 소스 조사 증거 (source inspection evidence)
• 변이 경계 (mutation boundaries)
• 수리 경로 (repair lanes)
• 작업 범위 컨텍스트 (task-scoped context)

그러면 에이전트는 그렇게 드러난 경계 안에서 작동할 수 있습니다.

컨텍스트는 사용되고, 검증되며, 해제될 수 있습니다.

리포지토리는 관리되는 진실의 원천 (source of governed truth)으로 남습니다.

채팅 스레드가 아닙니다.

모델 메모리가 아닙니다.

과거 프롬프트 잔해 (historical prompt residue)의 더미도 아닙니다.

이것이 중요한 이유

업계는 거대한 컨텍스트 윈도우 (context windows)를 더 사용하기 쉽게 만들기 위해 많은 돈을 쓰고 있습니다.

그 작업은 가치가 있습니다.

하지만 다른 경로가 있습니다.

다음과 같이 질문하는 대신:

어떻게 하면 에이전트가 더 많은 컨텍스트를 가져가게 할 수 있을까?

Scarab은 다음과 같이 질문합니다:

어떻게 하면 리포지토리가 올바른 컨텍스트를 드러내게 할 수 있을까?

이것들은 매우 다른 질문입니다.

첫 번째 질문은 에이전트가 더 많은 것을 섭취 (ingest)해야 한다고 가정합니다.

두 번째 질문은 에이전트가 행동하기 전에 시스템이 기계적으로 더 읽기 쉬운 상태 (legible)가 되어야 한다고 가정합니다.

이 사례에서 그 차이는 극명했습니다:

• 콜드 베이스라인 (Cold baseline): 총 72,194 토큰
• SDS 최종 결정 컨텍스트 (SDS final decision context): 2,651 토큰
• 동일한 최종 패치 (Same final patch)
• 검증된 공개 PR (Verified public PR)

이것이 모든 수리 작업에서 동일한 비율이 나타난다는 의미는 아닙니다.

SDS가 모든 컨텍스트 비용을 제거한다는 의미도 아닙니다.

진단 스위트 (diagnostic suite) 자체에 운영 비용이 없다는 의미도 아닙니다.

이 비교는 주변 SDS 워크플로우를 구축하거나 운영하는 총 비용이 아니라, 수리 시간(repair-time) 동안의 에이전트 컨텍스트 효율성(agent context efficiency)에 관한 것입니다.

하지만 이는 중요한 사실을 보여줍니다:

잘 정의된 진단 거버넌스 계층(diagnostic governance layer)은 에이전트 기반 수리(agentic repair)의 형태를 바꿀 수 있습니다.

모델을 마법처럼 만드는 방식이 아닙니다.

수리 경계(repair boundary)를 더 명확하게 만듦으로써 가능해집니다.

핵심 요약 (The Takeaway)

첫 번째 Scarab Field Lab 비교는 단순한 결과를 도출했습니다:

동일한 패치.

훨씬 적은 최종 결정 컨텍스트.

더 나은 증거 규율 (evidence discipline).

더 깔끔한 수리 경계.

공개 검증.

이것이 의미 있는 신호입니다.

SDS는 Codex가 도움 없이 패치할 수 없다는 것을 증명한 것이 아닙니다.

그보다 상업적으로 더 관련 있는 것을 증명했습니다:

만약 리포지토리(repo)가 에이전트에게 필요한 진실 경계(truth boundary)를 기계적으로 드러내 줄 수 있다면, AI 코딩 에이전트가 모든 수리마다 거대한 리포지토리 페이로드(repo payloads)를 필요로 하지 않을 수도 있다는 사실입니다.

그것이 바로 Scarab Systems가 구축하고자 하는 계층입니다.

AI 지원 소프트웨어 변경을 위한 리포지토리 진실 인프라 (Repo-truth infrastructure).

단순히 컨텍스트를 늘리기 위한 더 많은 컨텍스트가 아닙니다.

적절한 변이(mutation)를 위해, 적절한 경계에서 드러나는 적절한 진실입니다.

저의 Codex가 이 글을 작성하고 적절하게 형식을 맞추는 데 도움을 주었습니다. 하지만 글의 내용과 이론은 저의 것입니다. lol