Scarab Diagnostic Suite 현장 테스트 #001: 실제 Azure Provider 버그를 제한된 수정 경로(Bounded

저는 현장 테스트(field tests)로서 실제 오픈 소스 버그를 대상으로 Scarab Diagnostic Suite를 실행하기 시작했습니다.

합성된 예시(synthetic examples)가 아닙니다.

장난감 저장소(toy repos)도 아닙니다.

통제된 데모 피스처(demo fixtures)도 아닙니다.

실제 이슈, 실제 저장소, 실제 기여자의 마찰(contributor friction)입니다.

첫 번째 현장 테스트는 Open WebUI 이슈 #25078을 대상으로 진행되었으며, 연결 설정을 편집한 후 Azure OpenAI 연결이 끊어지는 문제였습니다. 보고된 실패 사례는 구체적이었습니다. 원래 작동하던 Azure 설정에는 azure: true가 포함되어 있었으나, 연결을 편집한 후 저장된 설정이 기존의 azure 플래그 없이 provider: "azure"로 바뀔 수 있었습니다. 그러면 백엔드는 해당 연결을 일반적인 OpenAI 엔드포인트처럼 취급하여 올바른 Azure 경로가 아닌 /models를 호출하려고 시도합니다. 사용자에게 나타나는 결과는 404 "Resource not found" 오류였습니다.

이것은 사후에 보면 단순해 보이지만, 수정 과정에서는 소음이 심해질 수 있는 바로 그런 종류의 버그입니다.

다음과 같은 여러 영역이 연관되어 있습니다:

설정 지속성 (configuration persistence),

프로바이더 메타데이터 형태 (provider metadata shape),

런타임 프로바이더 분기 (runtime provider branching),

Azure 엔드포인트 동작 (Azure endpoint behavior),

모델 목록화 동작 (model listing behavior),

그리고 업스트림 브랜치/릴리스 드리프트 (upstream branch/release drift).

이 첫 번째 현장 테스트의 질문은 다음과 같지 않았습니다:

"SDS가 마법처럼 알려지지 않은 버그를 발견할 수 있는가?"

그것은 과장된 표현일 것입니다.

이것은 가이드된 진단 수정 패스(guided diagnostic repair pass)였습니다. 이슈는 이미 알려져 있었습니다. 대상은 실제 서비스 중이었습니다. 질문은 Scarab Diagnostic Suite가 알려진 문제 보고를 받아, AI 코딩 에이전트가 저장소 전체를 헤매지 않고 실행할 수 있는 '제한된 수정 경로(bounded repair lane)'로 전환할 수 있는지 여부였습니다.

답은 '예'였습니다.

SDS가 발견한 것

SDS는 이 문제를 프로바이더/설정 계약 실패(provider/config contract failure)로 식별했습니다:

provider_config_contract.runtime_branch_missing_provider_shape

쉬운 말로 설명하자면:

Open WebUI에는 "이것은 Azure이다"라고 말하는 하나의 지속된 설정 형태(persisted config shape)가 있었지만, 런타임 분기(runtime branch)는 오직 이전 형태만을 인식했습니다.

깨진 경계(broken boundary)는 다음과 같습니다:

설정에 provider: "azure"가 지속되었으나,

런타임 로직은 오직 azure: true만을 확인했습니다.

이는 Azure 형태의 설정(Azure-shaped config)이 일반적인 OpenAI /models 경로로 빠져버릴 수 있음을 의미했습니다.

이것이 바로 Scarab이 식별하도록 설계된 종류의 문제입니다. 즉, "openai.py의 무작위 버그"가 아니라, 지속된 프로바이더 형태(persisted provider shape)와 런타임 프로바이더 처리(runtime provider handling) 사이의 계약 불일치(contract mismatch)인 것입니다.

수정 경로 (The repair lane)

로컬 수정 사항은 작았습니다:

azure: true와 provider: "azure"를 모두 Azure 형태의 설정으로 수용하도록 하는 것이었습니다.

회귀 테스트(Regression test)를 통해 수정 전에는 실패를 증명했고, 수정 후에는 통과함을 확인했습니다.

베이스라인(Baseline)은 다음을 시도함으로써 잘못된 동작을 재현했습니다:

https://example.openai.azure.com/models

수정된 경로는 집중 회귀 테스트(focused regression)를 통과했습니다.

그 후 SDS는 동일한 집중 진단 경로(focused diagnostic lane)를 다시 실행하였고, 프로바이더/설정 관련 발견 사항이 해결되었음을 확인했습니다.

제가 중요하게 생각하는 루프(loop)는 바로 이것입니다:

계약 경계(contract boundary)를 진단하고,

해당 경계만을 수정하며,

저장소 네이티브 회귀 테스트(repo-native regression)로 동작을 증명하고,

진단을 다시 실행하여,

발견 사항이 해결되었음을 확인하는 것.

상류(Upstream)에서 발생한 일

상류 기여(Upstream contribution)의 형태는 로컬 진단 결과보다 더 복잡했습니다.

원래의 수정 사항은 버그가 존재했던 릴리스 베이스라인(release baseline)을 대상으로 생성되었습니다. 하지만 Open WebUI의 활성 기여 브랜치는 dev였으며, 해당 브랜치가 상류 제출을 위해 준비되었을 때 dev의 런타임 동작에는 이미 프로바이더를 인식하는 Azure 라우팅이 포함되어 있었습니다.

이것이 상류의 형태를 변화시켰습니다.

로컬 수정 사항은 현장 증거(field evidence)로서 여전히 유효했지만, 상류 PR(Pull Request)은 현재의 dev가 여전히 해당 수정을 필요로 하는 것처럼 런타임 수정 사항을 정직하게 제출할 수 없게 되었습니다. 상류에서 안전하게 기여할 수 있는 유일한 방법은 회귀 테스트 커버리지(regression coverage)였습니다.

이 차이는 중요합니다.

SDS 증명과 상류 PR의 형태는 항상 동일한 것이 아닙니다.

진단 현장 테스트는 특정 영향을 받은 버전에 대해 수정이 유효했음을 증명할 수 있지만, 현재의 상류 브랜치는 이미 변화했을 수 있습니다. 그런 경우, 올바른 공개 기여는 중복된 수정을 강제하는 것이 아닙니다. 그것은 회귀 테스트 커버리지, 이슈 노트(issue note), 또는 공개적인 조치를 취하지 않는 것입니다.

이 현장 테스트가 증명한 것

현장 테스트(Field Test) #001은 특정한 한 가지를 증명했습니다:

Scarab Diagnostic Suite는 알려진 라이브 이슈를 가져와, 근본적인 계약 경계(contract boundary)를 식별하고, AI 수정 경로(repair lane)를 제한하며, 수정 후 목표로 했던 발견 사항(finding)이 해결되었는지 검증할 수 있다는 점입니다.

이것은 맹목적인 발견(blind discovery)을 증명한 것이 아닙니다.

전체 리포지토리(repo) 수정을 증명한 것도 아닙니다.

업스트림(upstream) 수용을 증명한 것도 아닙니다.

그것은 AI 지원 개발(AI-assisted development)에 있어 더 실용적인 무언가를 증명했습니다:

진단 스위트(diagnostic suite)가 AI 코딩 에이전트(AI coding agent)가 알려진 버그를 지나치게 광범위한 패치(overbroad patch)로 변질시키는 것을 막을 수 있다는 사실입니다.

이것이 제품 테제(product thesis)의 시작입니다.

AI 코딩 에이전트는 빠르지만, 경계가 없는 속도는 드리프트(drift)를 유발합니다.

Scarab의 역할은 "코더(coder)가 되는 것"이 아닙니다.

Scarab의 역할은 코딩 에이전트가 작동하는 동안 리포지토리의 진실성(repo truth)을 유지하는 것입니다.

이 첫 번째 현장 테스트에서, 그것은 지저분한 provider/config 버그를 좁고 테스트 가능한 수정 경로(repair lane)로 전환하는 것을 의미했습니다.

내부 분류

현장 테스트(Field Test) #001

프로젝트: Open WebUI

이슈: #25078

표면(Surface): provider/config 계약(contract)

모드: 가이드형 진단 수정 패스(guided diagnostic repair pass)

결과: 로컬 수정 성공, SDS 발견 사항 해결됨, 업스트림 브랜치에 이미 동일한 런타임 동작이 포함되어 있었음, 공개 PR 형태가 회귀 테스트 커버리지(regression coverage) 수준으로 축소됨

주요 교훈: SDS 진단 증명과 업스트림 기여 형태를 분리할 것

이것이 중요한 이유

많은 AI 지원 코딩이 실패하는 이유는 에이전트가 증상(symptom)에서 시작하여 갈팡질팡하기 때문입니다.

에이전트는 주변 코드를 수정합니다.

새로운 동작에 맞추기 위해 테스트를 편집합니다.

관련 없는 파일들을 정리합니다.

너무 넓은 표면 영역(surface area)을 변경합니다.

리포지토리를 추론하기 더 어렵게 만듭니다.

이 현장 테스트는 그 반대의 패턴을 보여주었습니다:

하나의 이슈,

하나의 계약 경계(contract boundary),

하나의 집중된 회귀(regression),

하나의 제한된 수정(bounded repair),

하나의 진단 사후 점검(diagnostic after-check).

이것이 제가 Scarab Diagnostic Suite가 강제하기를 원하는 수정 스타일입니다.

더 강력한 AI가 아니라,

더 나은 경계(boundaries)입니다.