AI 지원 드라이버로 Windows 98 SE에 Thunderbolt 지원 도입

Yeo Kheng Meng의 AI 지원 xHCI98 프로젝트를 통해 Windows 98 SE Thunderbolt 지원이 도입되면서, 전혀 다른 하드웨어 시대의 운영체제에 실험적인 연결 기능이 추가됐다. 이번 릴리스는 레트로컴퓨팅 애호가가 마주하는 현실적인 문제, 즉 원래 운영체제에 적합한 드라이버가 없을 때 최신 컨트롤러를 작동시키는 문제를 겨냥한다. 다만 Thunderbolt와 USB4의 근거는 서로 다르므로, 테스트 세부 사항은 헤드라인만큼 중요하다.

핵심 긴장은 기존 소프트웨어 기반을 확장하는 일과 더 이상의 진전을 막는 구성 요소를 교체하는 일 사이에 있다. Microsoft의 오래된 USB 인프라는 초기 발판을 제공했다. 그 전제를 넘어가려면 더 폭넓은 구현이 필요했지만, 그 위 계층의 소프트웨어와의 호환성은 유지해야 했다.

AI 지원 프로그래밍을 지켜보는 개발자에게 이 프로젝트는 살펴볼 만한 구체적 사례를 제공한다. 그 의미는 생성된 코드, 테스트 환경, 실제 하드웨어 간의 관계에 있다. 작동하는 시연은 주목할 가치가 있지만, 그 한계를 이해해야 성과를 더 유용하게 활용할 수 있다.

Windows 98 SE Thunderbolt 지원이 실제로 추가하는 것

xHCI98은 레거시 Windows와 최신 하드웨어 간 연결을 확장하며, 신중한 해석이 필요한 실험적 지원을 제공한다.

xHCI98 driver는 Windows 98 SE, ME, 2000, XP, Vista, 7을 대상으로 한다. 공개된 지원 범위에는 USB 3.x, USB4, Thunderbolt 3/4가 포함된다. 프로젝트는 후자의 기능을 실험적 기능으로 설명하며, 주요 테스트 범위 밖의 컨트롤러 구현에 대해서는 보장하지 않는다고 경고한다.

드라이버는 운영체제의 요청을 하드웨어가 이해하는 명령으로 변환한다. 여기서 관련된 출발점은 최신 USB 연결을 관리하는 데 쓰이는 컨트롤러 인터페이스인 xHCI다. 이 인터페이스를 지원하는 일은 개별 마우스나 저장 장치를 위한 드라이버를 추가하는 것과는 다른 문제를 해결한다.

이 차이는 이 작업이 더 빠른 외장 드라이브 이상의 의미를 갖는 이유를 설명한다. 액세서리에 적합한 레거시 소프트웨어가 있어도 컴퓨터에는 해당 장치에 도달할 정상적인 경로가 없을 수 있다. 그 경로를 복원하면 근본적인 장애물 하나는 제거되지만, 그 위 계층의 모든 호환성 문제를 자동으로 해결하는 것은 아니다.

프로젝트 이름도 다소 주의해서 볼 필요가 있다. Windows 98이라는 정체성에도 불구하고 대상 범위는 여러 Windows 세대에 걸친다. 이처럼 넓은 범위는 외형적 유사성 뒤에 서로 다른 내부 동작이 숨을 수 있는 운영체제 전반의 테스트를 요구한다.

보도된 소식은 버전 3.0.0.0을 중심으로 한다. 하지만 공개 릴리스 이력에는 이미 2026년 10월 19일자 버전 3.1.0.0이 올라와 있다. 따라서 프로젝트를 평가하는 독자는 기능 발표와 현재 제공되는 패키지를 구분해야 한다.

이는 활발히 개발되는 커뮤니티 소프트웨어에서 흔히 볼 수 있는 과제다. 뉴스 헤드라인은 하나의 이정표를 포착하지만, 설치 안내와 알려진 제한 사항은 계속 바뀐다. 기사에 나온 버전 번호를 영구적인 권장 사항으로 받아들이면 이러한 지속적인 작업을 가리게 된다.

Windows 98 SE Thunderbolt 지원은 서로 연결된 여러 책임도 포괄한다. 연결 수립, 연결된 하드웨어 검색, 해당 드라이버 로드, 분리 처리 모두 별개의 작업이다. 한 단계에서 성공했다고 해서 전체 과정에서 성공한 것은 아니다.

따라서 독자에게 유용한 질문은 구체적이다. 어떤 컨트롤러, 액세서리, 운영체제, 연결 동작을 함께 테스트했는가? 정확한 답은 자신의 장비와 관련성이 있는지 판단하는 데 도움이 된다. 광범위한 표준 명칭은 그보다 안내력이 떨어진다.

이처럼 좁은 범위 안에서 보면 즉각적인 변화도 의미가 있다. 애호가들은 원래 소프트웨어가 예상하지 못했던 하드웨어에 레거시 Windows를 연결할 또 하나의 경로를 얻었다. 다음 섹션에서는 이 경로를 구축하는 일이 왜 오래된 드라이버를 확장하는 것 이상이었는지 설명한다.

이전 USB 드라이버는 더 깊은 호환성 문제를 드러냈다

프로젝트의 진행 과정은 초기 호환성 지름길이 다음 아키텍처 제약으로 바뀔 수 있음을 보여준다.

Meng의 original USB implementation은 2026년 8월 30일에 공개됐다. 이는 오래된 Windows USB 인프라를 사용했으며 USB 2.0 속도로 동작했다. 그의 시연에는 운영체제가 실행 중인 상태에서 장치를 연결하고 분리하는 핫플러깅도 포함됐다.

이 동작은 실용적으로 중요한 차이다. 시작 시에만 사용할 수 있는 장치는 연결 이후 인식되는 장치보다 제한적인 경험을 제공한다. 이동식 주변기기를 사용하는 사람에게 세션 중 변화 처리는 기본적인 사용성의 일부다.

이전 접근법은 출발점으로서 타당했다. 기존 소프트웨어를 재사용하면 개발자가 구현해야 할 새로운 동작의 양을 줄일 수 있다. 또한 프로젝트를 확장하기 전에 하드웨어와의 통신이 작동함을 확인할 기회도 제공한다.

재사용한 기반이 최신 하드웨어가 더 이상 따르지 않는 가정을 담고 있을 때 어려움이 나타난다. 그러면 호환성 계층은 그러한 가정을 유지하거나, 이를 우회해 변환하거나, 교체 책임을 떠안아야 한다. 각각의 선택은 서로 다른 유지보수 부담을 만든다.

이것이 프로젝트가 주는 가장 유용한 아키텍처 교훈이다. 낯선 컨트롤러를 지원하는 일은 단순히 식별 번호를 인식하는 문제가 아니다. 주변 소프트웨어도 인식 이후 가능해지는 동작을 이해해야 한다.

레트로컴퓨팅 사용자에게 이는 하드웨어 선택에 부담을 준다. 최신 액세서리를 구매한다고 해서 사용 가능한 업그레이드가 보장되지는 않는다. 컴퓨터 내부 컨트롤러와 이를 관리하는 소프트웨어를 포함해 전체 연결 경로가 중요하다.

유지관리자에게 부담은 호환성이 어디까지 이어져야 하는지를 결정하는 쪽으로 옮겨간다. 오래된 구성 요소를 유지하면 유용한 동작을 보존할 수 있지만, 점점 더 복잡한 우회책이 필요해질 수도 있다. 이를 교체하면 제어 범위는 넓어지지만 테스트해야 할 영역도 커진다.

어느 쪽도 자동으로 승리하지는 않는다. 즉각적인 목표가 기본 연결성일 때는 점진적 접근이 적절할 수 있다. 기존 기반이 필요한 동작을 반복적으로 막을 때는 더 광범위한 재작업이 더 쉽게 정당화된다.

여기서 비교하는 것은 경쟁 상용 제품이 아니라 접근 방식이다. Microsoft의 원래 인프라는 역사적 호환성을 제공하고, 커뮤니티 구현은 접근 가능한 하드웨어 범위를 넓히려 한다. 두 목표는 겹치지만 동일하지는 않다.

이러한 틀은 취미 프로젝트를 공급업체 실패에 대한 뒷받침되지 않은 주장으로 바꾸는 일을 피한다. 이번 릴리스가 상업적 대응을 강제했다는 근거는 없다. 구체적인 부담은 레거시 호환성에 얼마나 많은 새 인프라가 필요한지 결정하는 유지관리자와 사용자에게 있다.

프로젝트의 궤적은 속도만으로는 불완전한 척도인 이유도 설명한다. 빠른 전송은 눈에 보이지만, 일반적인 사용 중에는 안정적인 검색과 분리 처리가 더 중요할 수 있다. 벤치마크만으로는 누군가가 시스템을 사용 가능하다고 느끼는 모든 이유를 포착할 수 없다.

USB4에는 더 빠른 USB 연결 이상의 것이 필요하다

더 큰 기술적 과제는 오래된 소프트웨어가 기대하는 동작을 보존하면서 전체 연결 경로를 조율하는 일이다.

USB4는 터널을 통해 다른 프로토콜을 전송할 수 있으며, 터널은 연결을 가로질러 트래픽을 전달하는 논리적 경로다. 저장 컨트롤러 같은 장치에 사용되는 확장 인터페이스인 PCIe가 관련 사례 중 하나다. 이 경로를 수립한 뒤에도 운영체제는 그 너머의 하드웨어를 인식할 책임이 있다.

Microsoft가 문서화한 USB4 설계는 터널링된 장치가 마치 기본 연결된 것처럼 동작해야 한다는 원칙을 따른다. 이는 레거시 구현을 평가할 때 유용한 비교 기준을 제공한다. 더 복잡한 전송 경로에도 불구하고, 목적지는 익숙한 장치 동작이다.

외장 스토리지 인클로저를 생각해 보자. 인클로저 연결을 인식하는 일은 과정의 일부일 뿐이다. 운영체제는 저장 컨트롤러도 검색하고, 이를 통신할 수 있는 소프트웨어를 사용해야 한다.

분리는 또 다른 책임 계층을 더한다. 소프트웨어는 계속 연결된 장치와 사라진 장치를 구분해야 한다. 연결을 성공적으로 처리하는 구현도 같은 하드웨어가 분리될 때는 다른 문제에 직면할 수 있다.

보조 Stor98 storage driver는 프로젝트 범위의 이 부분을 다룬다. 이는 이동식 Thunderbolt 및 USB4 연결 뒤에 있는, 솔리드 스테이트 드라이브에 흔히 사용되는 스토리지 인터페이스인 NVMe를 대상으로 한다. 문서는 이 목적을 영구적으로 연결된 스토리지용 드라이버와 구분한다.

이러한 분리는 하나의 헤드라인이 여러 엔지니어링 프로젝트를 감출 수 있는 이유를 설명한다. 연결된 하드웨어로 가는 경로를 수립하고 유지하는 연결 관리자는 하나의 책임을 맡는다. 스토리지 드라이버는 다른 책임을 맡으며, 운영체제는 그 결과를 조율해야 한다.

사용자에게 중요한 결과는 지원을 동작으로 평가해야 한다는 점이다. 장치가 시작 이후에도 나타나는가? 깔끔하게 중지할 수 있는가? 다시 연결하면 사용 가능한 드라이브가 복원되는가?

이 질문들은 포트가 “작동하는지” 묻는 것보다 더 많은 정보를 제공한다. 또한 연결 문제와 스토리지 문제를 구분하는 데도 도움이 된다. 데스크톱에서 나타나는 비슷한 증상도 소프트웨어의 서로 다른 부분에서 비롯될 수 있다.

같은 논리는 여러 기능을 담은 도크에도 적용된다. 도크에 접근할 수 있다고 해서 그 안의 모든 기능에 적합한 레거시 소프트웨어가 있다는 뜻은 아니다. 연결된 각 구성 요소는 또 하나의 호환성 경계를 만들 수 있다.

따라서 실험적 전송 지원을 모든 최신 도킹 구성에 대한 약속으로 해석하는 것은 시기상조다. 현재의 근거는 구체적인 경로와 장치에 관한 더 좁은 설명을 뒷받침한다. 더 광범위한 주장은 더 광범위한 테스트를 필요로 한다.

개발자에게 아키텍처적 관심사는 방해가 되는 하위 인프라는 교체하면서 유용한 인터페이스는 보존하는 데 있다. 이러한 접근법은 기반 하드웨어가 변하지 않았다고 가장하지 않으면서 오래된 소프트웨어가 계속 의미를 갖도록 할 수 있다.

하지만 이는 까다로운 테스트 문제도 만든다. 교체 구현은 최신 하드웨어를 충족하면서도 오래된 구성 요소가 이해하는 동작을 계속 제시해야 한다. 구현이 내부적으로 일관돼 보여도 이 경계 양쪽에서 실패가 발생할 수 있다.

따라서 Windows 98 SE Thunderbolt 지원은 드라이버 이야기인 동시에 통합 이야기다. 눈에 보이는 결과는 여러 구성 요소가 무엇이 존재하는지, 어디에 나타나는지, 언제 사라지는지에 합의할 때 만들어진다.

AI 지원은 목적에 맞게 구축된 테스트 환경과 함께 작동했다

가장 중요한 개발 교훈은 생성된 코드에 도전할 수 있는 피드백 루프의 가치다.

Meng은 프로젝트에 상당한 AI 지원이 사용됐지만, 실제 문제 해결과 하드웨어 테스터와의 소통에는 여전히 자신의 주의가 필요했다고 말한다. 그의 설명은 AI를 검증을 자율적으로 대체하는 수단이 아니라 개발 과정 내부에 배치한다.

연관된 USB4 host emulator는 이 과정의 또 다른 부분을 제공한다. 에뮬레이터는 선택된 하드웨어 동작을 소프트웨어로 재현한다. 이 프로젝트는 모든 실험을 실제 장비에서 수행하지 않아도 운영체제 연결 관리자가 모델링된 Thunderbolt 및 USB4 하드웨어와 상호작용할 수 있게 한다.

문서에 따르면 장치 검색, 저장소 액세스, 제거 동작을 포함해 Windows 11의 기본 연결 관리자로 테스트했습니다. 이러한 검증은 모델링된 환경에 대한 외부 기준을 제공합니다. 모든 물리적 컨트롤러가 동일하게 동작한다는 점까지 입증하는 것은 아닙니다.

이 구분은 AI 보조 시스템 작업을 해석하는 데 핵심적입니다. 생성된 코드는 기대치에 따라 테스트할 수 있지만, 그 기대치의 품질이 중요합니다. 잘못된 동작을 허용하는 테스트 환경에서는 결함 있는 코드도 성공한 것처럼 보일 수 있습니다.

별도의 구현은 유용한 검증 과제를 제시합니다. 다른 곳에서 개발된 소프트웨어가 에뮬레이터와 상호작용할 수 있다면 모델의 유용성에 대한 신뢰가 높아집니다. 다만 이는 하드웨어 검증을 대체하는 것이 아니라 보조 증거로 남습니다.

이는 여기서 “vibe-coded”라는 표현을 이해하는 방식도 바꿉니다. 이 표현은 주로 프롬프트와 즉각적인 인상에 의해 이끌리는 과정을 암시할 수 있습니다. 문서화된 프로젝트에는 참고 자료, 테스트 인프라, 실제 장치에서 얻은 피드백이 포함됩니다.

흥미로운 질문은 이 조합이 얼마나 많은 개발 작업을 현실적으로 가능하게 했는지입니다. 하나의 성공적인 프로젝트만으로 일반적인 생산성 향상 배율을 입증할 수는 없습니다. 그러나 더 면밀히 살펴볼 만한 프로세스를 식별할 수는 있습니다.

다른 개발자에게 이전 가능한 요소는 구현과 관찰 사이의 관계입니다. 코드 변경은 검사할 수 있는 동작을 만들어야 합니다. 결과가 기대와 다르면, 그 과정에는 불일치 지점을 찾는 데 도움이 되는 증거가 필요합니다.

이는 소프트웨어가 하드웨어와 상호작용할 때 특히 중요합니다. 그럴듯한 설명은 코드 리뷰를 통과할 수 있지만 실제 실행에서는 실패할 수 있습니다. 실패를 관찰하면 또 한 번의 추측으로는 대체할 수 없는 정보를 얻게 됩니다.

같은 원칙은 문서화에도 적용됩니다. 의사 결정을 기록하면 이후 작업에서 의도적인 제약과 우연한 동작을 구분하는 데 도움이 됩니다. 이러한 맥락을 유지하는 데 관심 있는 독자를 위해, engineering knowledge base는 관련된 조직적 접근 방식을 제시합니다.

이 연결이 어떤 노트 작성 제품이 드라이버의 정확성을 검증한다는 뜻은 아닙니다. 문서화는 개발자가 활용할 수 있는 추론을 보존하며, 테스트와 하드웨어 관찰은 그들의 결정이 실제로 작동하는지를 평가합니다.

이 프로젝트는 AI 사용자에게 생성된 코드의 양보다 더 구체적인 기준을 제공합니다. 유용한 질문은 재현 가능성, 진단된 실패, 변경 사항을 설명할 수 있는 능력에 관한 것입니다. 이러한 질문은 최초 구현을 어떤 모델이 생성했는지와 관계없이 여전히 중요합니다.

실제 하드웨어 증거에는 중요한 한계가 있다

물리적 Thunderbolt 테스트와 에뮬레이션된 USB4 테스트는 서로 다른 결론을 뒷받침합니다.

Meng은 자신의 USB4 development account에서 Windows 98 SE 및 Windows 7 환경의 ThinkPad P14s Gen 1으로 Thunderbolt 3를 테스트했다고 보고합니다. 그는 Windows 10 환경의 Framework Laptop 13에서 USB4를 별도로 테스트했다고도 전합니다. 해당 기록에서는 실제 USB4 호스트에서의 레거시 Windows 테스트는 수행되지 않았습니다.

이 구분은 Thunderbolt 4 헤드라인을 가장 넓게 해석하는 데 제약을 둡니다. 물리적 Thunderbolt 3 구성에서 얻은 증거는 그 수준에서 설명되어야 합니다. 에뮬레이터는 유용한 범위를 추가하지만, 이 결과를 보편적인 물리적 호환성으로 바꾸지는 않습니다.

이는 구현을 폄하할 이유가 아닙니다. 실험적 소프트웨어는 종종 제한된 하드웨어 접근성에서 시작됩니다. 책임 있는 해석은 작동한 사례를 인정하면서도, 뒷받침되지 않는 조합은 결론에서 제외합니다.

개발자가 문서화한 결과와 독립적인 재현 사이에도 차이가 있습니다. 스크린샷, 로그, 설명은 독자가 주장을 검토하는 데 도움이 됩니다. 다른 환경에서 동일한 동작을 재현하면 결과가 원래 환경을 넘어선다는 증거가 추가됩니다.

유용한 재현에는 전체 구성을 식별해야 합니다. 컨트롤러 모델, 펌웨어 설정, 운영체제 버전, 드라이버 패키지, 액세서리 모두가 무엇을 테스트했는지 설명하는 데 도움이 됩니다. 이러한 세부 정보가 없으면 겉보기의 일치가 실질적으로 다른 구성을 감출 수 있습니다.

현재 릴리스 노트는 프로젝트의 실험적 성격을 강화합니다. 버전 3.1.0.0에는 베타 그래픽 설치 관리자와 통합 변경 사항이 추가되었습니다. 또한 Thunderbolt 또는 USB4 장치가 연결된 상태에서는 대기 모드와 최대 절전 모드를 지원하지 않는다는 점을 포함해 제한 사항도 나열합니다.

호환성에는 상태 전환도 포함되므로 이러한 세부 사항이 중요합니다. 컴퓨터를 시작하고, 드라이브를 연결하고, 이를 제거하고, 저전력 상태로 진입하는 것은 서로 다른 작동 조건입니다. 한 조건에서의 결과가 다른 조건까지 확정하지는 않습니다.

저장소는 눈에 잘 띄지 않는 문제가 나타나기 전에도 장치가 사용 가능한 것처럼 보일 수 있으므로 특히 주의할 필요가 있습니다. 드라이브를 인식하는 것은 하나의 이정표이고, 반복 작업 전반에서 올바른 동작을 보존하는 것은 또 다른 이정표입니다. 평가는 둘 다 고려해야 합니다.

마찬가지로 처리량은 측정 맥락과 함께 제시되어야 합니다. 연결에 대해 광고되는 전송률과 애플리케이션이 측정한 속도는 서로 다른 것을 설명합니다. 더 빠른 전송 방식이 시스템의 다른 모든 제약을 없애지는 않습니다.

기업 독자에게 이 릴리스는 실험적 호환성을 지원되는 마이그레이션 전략으로 간주할 근거를 제공하지 않습니다. 취미 활동가의 시연은 특정 구성이 작동할 수 있는지에 답합니다. 운영 환경 도입은 유지보수, 복구, 재현성에 관한 추가 질문을 요구합니다.

이러한 구분은 프로젝트 자체의 가치를 보호하기도 합니다. 유지 관리자가 주장하지 않은 기준으로 커뮤니티 작업을 평가하면 불공정한 비교가 됩니다. 문서화된 실험 범위는 더 합리적인 평가 기준을 제공합니다.

따라서 Windows 98 SE Thunderbolt 지원에 대한 가장 신뢰할 수 있는 해석은 구체적이고 조건부입니다. 조사할 가치가 있는 물리적 기능 보고가 있으며, 그와 함께 여전히 증거가 필요한 더 넓은 호환성 범위가 존재합니다.

물리적 USB4 테스트, 재현성 및 유지보수를 지켜봐야 한다

다음으로 주목할 만한 발전은 호환성 경계를 확장하거나 명확히 하는 구체적인 테스트 결과입니다.

첫 번째로 살펴볼 신호는 물리적 USB4 호스트에서 실행되는 레거시 Windows입니다. 이는 개발자 기록에서 확인된 공백을 다룰 것입니다. 상세한 결과는 소프트웨어가 모델링된 환경을 넘어 확장된다는 근거를 강화할 수 있습니다.

보고서의 품질은 헤드라인만큼 중요합니다. 컨트롤러와 액세서리를 식별하면 결과가 더 유용해집니다. 연결, 제거, 저장소 동작을 설명하면 경로의 어느 부분이 검증되었는지 보여줄 수 있습니다.

실패한 테스트도 정보를 제공합니다. 지원되지 않는 구성, 펌웨어 상호작용 또는 조사가 필요한 소프트웨어 결함을 드러낼 수 있습니다. 명확한 실패 보고는 단순히 프로젝트에 불리한 사례를 세는 대신 호환성 지도를 개선합니다.

두 번째 신호는 독립적인 구성 전반의 재현성입니다. 추가 테스터의 보고는 하나의 작동 사례와 여러 구성에서 유지되는 동작을 구분하는 데 도움이 됩니다. 반복적인 연결과 제거는 특히 유용한 증거가 될 것입니다.

모든 테스터가 모든 기능을 재현할 필요는 없습니다. 더 작고 명확하게 설명된 결과도 개별 경계를 설정할 수 있습니다. 좁게 문서화된 성공 사례는 모든 것이 작동했다는 광범위한 주장보다 평가하기 쉽습니다.

세 번째 신호는 최초 발표 이후의 유지보수입니다. 후속 릴리스는 어떤 문제를 설명하고 해결하는지를 통해 평가해야 합니다. 중요한 질문은 변경 사항이 이전에 작동하던 사례를 유지하면서 동작을 더 예측 가능하게 만드는지입니다.

릴리스 활동만으로는 이 질문에 답할 수 없습니다. 더 긴 변경 목록이 자동으로 더 높은 신뢰성을 입증하지는 않습니다. 보고된 문제, 그 진단, 검증된 수정 간의 연결이 더 유용한 증거를 제공합니다.

이러한 신호는 AI의 기여를 공정하게 평가하는 방법도 제공합니다. 추가적인 작동 구성은 개발 프로세스의 실용적 가치를 강화할 것입니다. 지속적이고 설명되지 않는 실패는 도구와 테스트의 개선이 필요한 지점을 드러낼 것입니다.

이 릴리스를 둘러싸고 상업적 대결 구도를 억지로 만들 필요는 없습니다. 직접적인 대상은 주류 제품이 더 이상 우선시하지 않는 호환성을 탐색하는 애호가와 개발자입니다. 더 넓은 관련성은 이들이 결과를 평가하고 유지할 수 있는 방식에 있습니다.

AI 제품 사용자에게 이 교훈은 증거에 관한 것입니다. 설득력 있는 시연은 흥미로운 일이 일어났다는 점을 보여줄 수 있습니다. 문서화와 반복 가능한 테스트는 무엇이, 어떤 조건에서, 어디까지 일어났는지를 확인하는 데 도움이 됩니다.

앞으로 몇 달 동안에는 표준 목록을 다시 언급하는 것보다 이러한 세부 사항이 더 많은 정보를 제공할 것입니다. 이 프로젝트는 이미 검토할 수 있는 구체적인 구현을 제공합니다. 다음 단계는 이를 둘러싼 관찰의 범위를 넓히는 데 달려 있습니다.

이 프로젝트에 관심이 있다면 문서화된 하드웨어 결과부터 살펴보고, 실제로 이해하려는 구성과 비교해 보세요. 물리적 테스트와 에뮬레이션된 테스트를 분리해서 보며, 시연을 해석하기 전에 현재 제한 사항을 읽으세요. 개발자라면 테스트 환경이 구현 변경에 대한 피드백을 어떻게 만드는지 검토하세요. 애호가라면 전체 연결 경로를 식별하고 제거 동작을 설명하는 보고서를 찾아보세요. Windows 98 SE Thunderbolt 지원은 구체적인 호환성 문제를 실질적으로 보여주기 때문에 주목할 가치가 있습니다. 증거가 쌓이는 과정을 따라가며, 다음 결과가 지원 경계를 확장하는지 또는 그 경계를 더 명확히 하는지 물어보세요.