Scarab 진단 필드 테스트 #025 — VS Code 마우스 에코 (Mouse Echo) 런타임 설정 경계

대상: microsoft/vscode

이슈: microsoft/vscode#247522

PR: microsoft/vscode#320877

필드 랩 (Field Lab): https://github.com/scarab-systems/scarab-field-lab

이번 필드 테스트는 NVDA 및 JAWS와 같은 스크린 리더 (Screen Reader) 사용 시 마우스 에코 (Mouse Echo) 기능이 올바르게 작동하지 않는 Visual Studio Code의 접근성 회귀 (Accessibility Regression) 문제를 대상으로 했습니다.

가시적인 문제는 사용자에게 직접적이며 심각합니다:

• 스크린 리더가 실행 중임
• 마우스 에코 (Mouse Echo)가 활성화되어 있음
• 사용자가 VS Code 에디터 내의 텍스트 위로 마우스를 이동함
• 스크린 리더가 더 이상 포인터 아래의 텍스트를 읽어주지 않음
• 보고된 바에 따르면 이전 VS Code 버전에서는 정상적으로 작동했음

영향을 받는 사용자들에게 이것은 단순한 외관상의 회귀가 아닙니다. 마우스 에코 (Mouse Echo)는 일부 사용자들이 보조 기술 (Assistive Technology)을 통해 가시적인 텍스트를 검사하고 탐색하는 방식의 일부입니다.

하지만 중요한 진단 질문은 단순히 다음과 같은 것이 아니었습니다:

마우스 에코 (Mouse Echo)를 어떻게 수정할 것인가?

더 나은 질문은 다음과 같았습니다:

이 실패의 어느 부분이 실제로 VS Code의 책임인가?

필드 랩 (Field Lab) 기록

이 필드 테스트에 대한 공개 사례 기록은 Scarab Field Lab에서 확인할 수 있습니다:

https://github.com/scarab-systems/scarab-field-lab

SDS 결과

이 테스트는 일회성 VS Code 아레나를 대상으로 완전한 SDS 필드 테스트 태세로 수행되었습니다.

완료된 실행에서는 전체 감사 프로필 (Audit Profile) 및 전체 실행 모드를 사용하여 제품 수준의 진단 (Product-level Diagnose)을 사용했습니다. 최종 패치를 겨냥한 맞춤형 일회성 쿼리를 사용하는 대신, VS Code 대상을 광범위하게 스캔했습니다.

이것이 중요한 이유는 최종 수정 사항이 진단 과정에 미리 포함되어 있지 않았기 때문입니다.

SDS는 다음과 같이 명시적인 지침을 제시하지 않았습니다:

Chromium 기능 플래그 (Feature Flags)를 추가하십시오.

실제로 일어난 일은 그것이 아닙니다.

대신, SDS는 경계가 정해진 수정 (Bounded Repair)을 지원할 수 있을 만큼 주변의 런타임 (Runtime), 설정 (Configuration), 접근성 (Accessibility) 및 Electron 경계를 강력하게 드러냈습니다.

이 차이가 중요합니다.

진단 시스템은 유용해지기 위해 스스로 패치를 만들어내야 하는 상황에 처해서는 안 됩니다. 때로는 올바른 진단 출력(diagnostic output)이란 인접 영역, 즉 프로젝트가 전체 근본 원인(root cause)을 소유한 척하지 않고도 동작할 수 있는 소유된 표면(owned surface)이어야 합니다.

이 경우, 그 소유된 표면은 VS Code의 런타임 인자(runtime argument) 및 Electron 시작 구성 경로(startup configuration path)였습니다.

실패의 형태 (Failure shape)

보고된 회귀(regression)는 여러 계층의 교차점에 위치합니다:

• VS Code 에디터 동작
• 보조 기술 (assistive technology) 동작
• NVDA 및 JAWS와 같은 Windows 스크린 리더 (screen readers)
• Electron
• Chromium 접근성 제공자 (accessibility-provider) 동작
• VS Code 데스크톱 런타임 시작 구성

이는 패치를 적용하기에 매우 위험한 형태입니다.

버그가 이토록 많은 계층을 가로지를 때, 잘못된 부분을 수정하기 쉽습니다.

패치는 에디터 렌더링 (rendering)을 변경하려 할 수 있습니다.

패치는 스크린 리더 상호작용을 수정하려 할 수 있습니다.

패치는 NVDA 또는 JAWS에 대한 가정을 인코딩(encode)하려 할 수 있습니다.

패치는 실제로는 스택(stack)의 더 낮은 곳에 위치한 Chromium/Electron 제공자 회귀를 VS Code가 소유한 것처럼 가장할 수도 있습니다.

그것은 범위가 너무 넓을 것입니다.

더 나은 수정 경로(repair lane)는 더 작았습니다:

VS Code는 자체 런타임 구성 경로를 통해 Chromium 기능 플래그 (feature flags)를 전달할 수 있는 지속적인 방법을 노출할 수 있습니다.

이것이 근본적인 제공자 버그를 해결하는 것은 아닙니다.

하지만 더 깊은 곳의 접근성 회귀가 조사되는 동안, 유지 관리자(maintainers)와 영향을 받는 사용자들에게 Chromium/Electron 기능 플래그 진단 또는 워크아라운드 (workarounds)를 적용할 수 있는 안정적인 방법을 제공합니다.

경계 (Boundary)

여기서의 경계는 다음과 같습니다:

VS Code가 소유한 런타임 구성 (runtime configuration)

대(versus)

Chromium/Electron 접근성 제공자 (accessibility-provider) 동작

VS Code는 접근성 제공자 스택의 모든 부분을 소유하지 않습니다.

VS Code는 NVDA를 소유하지 않습니다.

VS Code는 JAWS를 소유하지 않습니다.

VS Code는 Chromium을 소유하지 않습니다.

VS Code는 모든 Electron 수준의 접근성 동작을 소유하지 않습니다.

하지만 VS Code는 Electron 및 Chromium 시작 스위치 (startup switches)가 구성되고 허용되는 경로의 일부를 소유합니다.

그것이 바로 수정 표면 (repair surface)입니다.

패치는 그 표면 내에 머뭅니다.

그것은 에디터 렌더링 (rendering)을 변경하지 않습니다.

그것은 스크린 리더 (screen-reader) API를 변경하지 않습니다.

그것은 마우스 히트 테스트 (mouse-hit testing) 동작을 변경하지 않습니다.

그것은 모든 사용자에게 하나의 Chromium 기능 조합이 올바르다고 단정하지 않습니다.

그것은 VS Code의 기존 인자/설정 (argument/configuration) 메커니즘을 통해 지속적인 런타임 기능 플래그 (runtime feature-flag) 경로를 추가합니다.

그것은 경계 수정 (boundary repair)이지, 근본 원인 (root-cause)에 대한 주장 이 아닙니다.

변경 사항

이 PR은 다음 항목에 대한 지원을 추가합니다:

enable-features

및

disable-features

VS Code의 네이티브 런타임 인자 (runtime argument) 경로 전반에 걸쳐.

패치는 해당 스위치들을 다음을 통해 연결합니다:

• 네이티브 파싱된 인자 (native parsed args)
• CLI 파서 옵션 (CLI parser options)
• argv.json 스키마 (argv.json schema)
• 지원되는 Electron 스위치 허용 목록 (supported Electron switch allowlist)

값은 쉼표로 구분된 Chromium 기능 이름으로 문서화됩니다.

기본 동작은 변경되지 않습니다. 이 스위치들은 명시적으로 구성되었을 때만 전달됩니다.

마지막 점이 중요합니다.

이 패치는 모든 사용자에게 기능 플래그를 강요하지 않습니다. 어떤 Chromium 접근성 제공자 (accessibility-provider) 동작이 올바른지 결정하지도 않습니다. 이것은 유지 관리자(maintainers)와 영향을 받는 사용자들이 테스트를 수행하거나 워크아라운드 (workaround)를 적용해야 할 때 런타임 플래그를 유지할 수 있는 지원된 경로를 생성합니다.

집중된 테스트는 빈 값 및 반복된 값을 포함한 파서 (parser) 동작을 다룹니다.

이것이 에디터 렌더링 수정이 아닌 이유

가장 먼저 살펴볼 곳은 에디터입니다.

실패 현상은 에디터에서 경험됩니다. 사용자가 에디터 텍스트 위로 마우스를 움직입니다. 스크린 리더는 이전에 발표하던 내용을 발표하지 않습니다.

하지만 "사용자가 버그를 느끼는 곳"과 "프로젝트가 안전한 수정을 소유하는 곳"이 항상 같은 곳은 아닙니다.

이는 Electron 기반으로 구축된 데스크톱 애플리케이션에서 특히 그렇습니다.

사용자 대상의 접근성 회귀 (accessibility regression)는 가시화되기 전에 VS Code UI, Electron 접근성 API, Chromium 접근성 제공자 동작, 그리고 외부 스크린 리더의 기대치를 모두 통과할 수 있습니다.

만약 VS Code가 아직 최하위 수준의 근본 동작을 소유하고 있지 않다면, 좁은 범위의 패치가 마치 소유하고 있는 것처럼 가장해서는 안 됩니다.

더 안전한 수정 방법은 에디터 코드를 왜곡하지 않으면서, 하위 수준의 동작을 테스트하거나 우회할 수 있도록 설정 경로 (configuration path)를 노출하는 것입니다.

이 패치가 수행하는 작업이 바로 그것입니다.

이 패치는 추측에 기반한 접근성 로직 (accessibility logic)을 에디터 표면 (editor surface)으로 밀어 넣는 대신, 런타임 시작 경계 (runtime startup boundary) 내에 수정을 유지합니다.

진단 결과가 중요했던 이유

이 사례가 유용한 이유는 SDS가 마법 같은 정답을 내놓지 않았기 때문입니다.

대신 SDS는 경계가 지정된 증거 영역 (bounded evidence neighborhood)을 생성했습니다.

이는 실제 디버깅이 작동하는 방식에 더 가깝습니다.

가치는 다음과 같은 것이 아니었습니다:

SDS가 정확한 패치를 찾아냈다.

가치는 다음과 같았습니다:

SDS가 관련 소유권 영역 (ownership area)을 충분히 좁혀서 패치가 작게 유지될 수 있도록 했다.

계층 간 접근성 회귀 (cross-layer accessibility regression) 문제에서 이는 매우 중요합니다.

스택에는 유혹적인 표면 (surfaces)이 너무 많습니다. 코딩 에이전트 (coding agent)는 증상을 쫓다가 에디터 코드, 스크린 리더 (screen-reader) 가정, 또는 Electron 내부 로직으로 쉽게 빠져버릴 수 있습니다. 사람도 마찬가지입니다.

진단 질문은 수정을 근거 있는 상태로 유지했습니다:

하위 수준의 제공자 버그 (lower-level provider bug)를 수정한다고 주장하지 않으면서도, 유지 관리자와 사용자가 이 회귀 문제를 조사할 수 있도록 돕는 VS Code의 소유 표면은 무엇인가?

정답은 네이티브 인자/설정/Electron 스위치 경로 (native argument/configuration/Electron switch path)였습니다.

검증

패치는 VS Code 프로젝트 체크와 집중된 파서 테스트 (parser test)를 통해 검증되었습니다.

집중 테스트를 통해 Chromium 기능 스위치 (feature switches)가 인자 파서 (argument parser)를 통해 인식됨을 확인했습니다.

전체 검증 기록과 공개 상태는 필드 랩 (Field Lab) 사례 기록을 참조하십시오:

https://github.com/scarab-systems/scarab-field-lab

필드 테스트 결과

이것은 VS Code 접근성 회귀에 대한 경계가 지정된 런타임 설정 (runtime-configuration) 수정 후보였습니다.

문제는 다음과 같이 축약되었습니다:

• 영향을 받는 스크린 리더 (screen-reader) 사용자들에게 마우스 에코 (mouse echo) 기능이 작동하지 않음
• 근본적인 회귀 (regression) 원인은 Chromium/Electron 접근성 제공자 (accessibility-provider) 동작과 관련이 있는 것으로 보임
• VS Code가 하위 레벨 제공자 (lower-level provider)의 버그 전체를 자신의 책임이라고 주장해서는 안 됨
• VS Code는 자신의 런타임 시작 인자 (runtime startup argument) 및 설정 (configuration) 영역에 대해서는 책임을 가짐
• enable-features 및 disable-features를 추가함으로써 유지 관리자와 영향을 받는 사용자들에게 지속적인 기능 플래그 (feature-flag) 경로를 제공함
• 스위치 (switches)가 명시적으로 구성되지 않는 한 기본 동작은 변경되지 않음

이것이 수정 경로 (repair lane)입니다.

이 패치는 NVDA를 수정한다고 주장하지 않습니다.

이 패치는 JAWS를 수정한다고 주장하지 않습니다.

이 패치는 Electron을 수정한다고 주장하지 않습니다.

이 패치는 Chromium을 수정한다고 주장하지 않습니다.

이 패치는 더 깊은 수준의 접근성 제공자 (accessibility-provider) 회귀 (regression) 문제가 조사되는 동안, VS Code에 더 깔끔하고 소유권이 명확한 설정 경로를 제공합니다.

이것이 Scarab의 경계 (boundary)입니다:

증거가 더 좁은 소유 영역 (owned surface)을 지지할 때는 근본적인 버그 (root bug)를 자신의 것이라고 주장하지 마십시오.

공개 주장 (Public claim)

이번 필드 테스트에 대한 올바른 주장은 다음과 같습니다:

Scarab/SDS는 NVDA 및 JAWS와 같은 스크린 리더 (screen-reader) 사용 시 마우스 에코 (mouse echo) 동작과 관련된 접근성 회귀 (accessibility regression) 문제인 microsoft/vscode#247522에 대해, 제한된 수정 후보를 도출하는 데 기여했습니다. 전체 SDS 필드 테스트 진단을 통해 런타임/설정/접근성/Electron의 경계가 충분히 강력하게 드러났으며, 이를 통해 VS Code가 소유한 좁은 범위의 수정 경로를 지원할 수 있었습니다. 업스트림 PR (upstream PR)은 VS Code의 네이티브 인자 파서 (argument parser), argv.json 스키마 (schema), 그리고 Electron 스위치 허용 목록 (switch allowlist)에 enable-features 및 disable-features를 추가하여, 유지 관리자와 영향을 받는 사용자들이 하위 레벨의 접근성 제공자 (accessibility-provider) 회귀 문제를 조사하는 동안 지속적인 Chromium 기능 플래그 (feature-flag) 경로를 가질 수 있도록 합니다. 이는 근본적인 NVDA, JAWS, Electron 또는 Chromium 버그를 수정한다고 주장하는 것이 아닙니다.

공개 (Disclosure): 이 필드 보고서는 본인의 필드 테스트 노트, 공개 이슈 및 PR 기록, 검증 요약, 그리고 수정 기록을 바탕으로 AI 보조 편집을 통해 작성되었습니다. 기술적 주장과 최종 문구는 발행 전 검토되었습니다.