소프트웨어 공급망 보안에서 서명, 배포 출처 증명, 소프트웨어 구성요소 목록은 서로 다른 질문에 답한다. 서명은 파일과 서명자의 관계를, 출처 증명은 소스·빌드 경로와 배포물의 연결을, 구성요소 목록은 포함된 부품과 관계를 확인하는 데 쓰인다. 이 자료들을 연결하고 기대한 조건과 대조해야 외부 코드를 채택한 근거를 설명할 수 있다.

홈페이지는 직접 작성한 코드만으로 움직이지 않는다. 화면을 만드는 라이브러리, 이미지 처리 도구, 서버 모듈, 플러그인, 배포 자동화가 함께 작동한다. 외부 코드가 어디에서 왔는지 묻는 일은 최종 화면에 보이는 기능뿐 아니라 그 화면을 만드는 과정까지 살펴보는 일이다. 이 글은 공식 기술 문서를 바탕으로 각 검증 수단의 범위를 정리하고, 홈페이지 개발·유지보수에 적용할 수 있는 기록 방식을 제안한다.

1. 소프트웨어 공급망 보안은 무엇을 확인하는가?

소프트웨어 공급망(Software Supply Chain)은 소스, 의존성, 빌드 도구, 배포 과정, 최종 파일이 연결되는 경로다. 공급망 보안은 이 경로에서 의도하지 않은 변경이 들어오는 위험을 줄이고, 채택한 배포물이 기대한 과정에서 나왔는지 확인하는 활동이다. 공급망 무결성 수준 체계(Supply-chain Levels for Software Artifacts, SLSA)의 빌드 검증 지침도 파일과 출처 증명의 연결, 신뢰하는 빌더, 기대한 소스와 입력값의 일치를 다룬다. ^[1]

소스 코드와 배포물(Artifact)은 구분해야 한다. 개발자는 저장소의 TypeScript 파일을 읽지만, 사용자는 변환된 JavaScript와 압축 패키지를 설치할 수 있다. 빌드 과정에서는 파일 생성, 코드 변환, 외부 자료 다운로드가 일어날 수 있다. 저장소를 확인한 사실과 최종 설치 파일을 확인한 사실은 같은 기록이 아니다.

예를 들어 홈페이지의 이미지 처리 도구를 검토했다고 가정하자. 저장소의 함수에는 문제가 없어 보이더라도 패키징 과정에서 추가된 파일이나 실행 절차는 별도 확인 대상이다. 이 사례는 이해를 위한 가상 상황이다. 공급망 검증에서는 검토한 소스, 사용한 빌드 경로, 실제 채택한 파일을 연결하는 근거가 필요하다.

2. 해시·서명·출처 증명·SBOM의 차이는 무엇인가?

해시는 파일의 일치 여부, 서명은 서명자와 파일의 연결, 출처 증명은 제작 경로, SBOM은 구성요소를 다룬다. 각 수단은 확인 대상이 다르므로 하나의 ‘안전 인증’으로 묶어 이해하면 검증 범위를 놓치기 쉽다. 다음 표의 한계 설명은 공식 문서의 기능 범위를 바탕으로 정리한 기술적 해석이다. ^{[1] [2] [3] [4] [5]}

패키지를 받으며 ‘기대한 파일이 맞다’는 결과를 얻었더라도, 그 기대값을 처음부터 잘못된 배포물에서 가져왔다면 채택 판단은 여전히 잘못될 수 있다. 검증은 비교 대상이 신뢰할 만한지 정하는 일까지 포함한다. 파일의 일치 여부와 코드의 동작 적합성은 따로 설명해야 한다.

3. 디지털 서명은 무엇을 증명하는가?

디지털 서명(Digital Signature)은 대상 데이터와 서명 키의 관계를 검증하고, 서명 대상의 변경을 탐지하는 수단이다. 정체성 기반 검증에서는 키를 인증서의 정체성과 연결해 확인할 수 있다. 시그스토어(Sigstore)의 Cosign 문서는 키 없는 서명 검증에서 기대하는 인증서 정체성과 개방형 인증 연결(OpenID Connect, OIDC) 발급자를 지정하는 방법을 제공한다. ^[2]

따라서 ‘서명 검증 성공’이라는 문장을 읽을 때는 어떤 키나 정체성을 신뢰하도록 설정했는지 함께 물어야 한다. 정상적으로 서명된 파일이라도 그 서명자가 서비스 운영자가 채택하려던 공급자인지는 별도의 대조가 필요하다. 서명자가 해당 내용을 승인했다는 사실도 코드의 모든 동작을 허용할 이유가 되지는 않는다.

또한 npm 레지스트리 서명과 제작 과정의 출처 증명 서명은 구분해야 한다. npm의 npm audit signatures는 다운로드한 패키지의 레지스트리 서명을 검사하고 출처 증명도 검증한다. 이 결과를 설명할 때는 어떤 패키지와 증명을 확인했는지 기록해야 한다. ‘모든 개발자가 직접 서명한 코드’라고 일반화해서는 안 된다. ^[5]

4. 배포 출처 증명은 어떻게 검증하는가?

배포 출처 증명(Provenance)은 특정 배포물과 소스·빌드 과정 사이의 검증 가능한 정보를 제공한다. npm은 출처 증명과 게시 증명(Publish Attestation)을 구분한다. 전자는 소스와 빌드 지침을 연결하고, 후자는 레지스트리가 권한 있는 게시자의 배포를 기록한다. npm 문서는 출처 증명이 악성 코드의 부재를 보장하지 않는다고 명시한다. ^[3]

검증은 증명 문서가 존재하는지 확인하는 데서 끝나지 않는다. SLSA 지침을 바탕으로 보면 다음 항목을 나누어 살펴볼 수 있다. 실제 구현에서는 사용한 증명 형식과 검증 도구가 제공하는 필드를 확인해야 한다. ^[1]

1. 대상 연결: 증명 문서의 대상이 지금 받은 파일의 해시와 일치하는가?
2. 증명의 신뢰: 증명 서명이 유효하고, 생성한 빌더를 신뢰할 근거가 있는가?
3. 소스의 일치: 공식적으로 채택한 소스 저장소에서 만들어졌는가?
4. 빌드 조건의 일치: 빌드 유형과 외부 입력값이 허용한 조건에 맞는가?

가상의 패키지 A가 평소에는 공식 저장소에서 만들어졌는데 새 버전은 다른 저장소에서 만들어졌다고 하자. 새 증명이 유효하게 서명돼 있더라도 저장소 변경을 승인하지 않았다면 채택을 보류할 이유가 생긴다. 반대로 승인된 저장소의 코드 자체에 문제가 있다면 출처 대조만으로 그 문제를 찾을 수는 없다.

신뢰 기반 배포와 출처 증명은 같은 기능인가?

신뢰 기반 배포(Trusted Publishing)는 OIDC를 사용해 승인된 자동화 실행 정체성에 배포 권한을 부여하는 방식이다. 장기간 보관하는 쓰기 토큰에 대한 의존을 줄인다. 출처 증명은 배포물의 제작 경로를 검증하기 위한 자료이므로 두 기능의 목적은 다르다. npm에서 출처 증명의 자동 생성에는 CI 제공자와 공개 저장소·패키지 여부 등의 조건이 있다. ^[6]

실무적으로는 배포 인증을 개선한 뒤에도 자동화가 실행하는 내용을 관리해야 한다. GitHub는 워크플로 토큰에 최소 권한을 부여하고 외부 액션을 전체 커밋 SHA로 고정하는 방법 등을 안내한다. 누구의 실행인가를 확인하는 작업과 그 실행이 어떤 파일을 만들어내는지 검토하는 작업을 연결해야 한다. ^[7]

5. SBOM은 무엇이며 사고 대응에 어떻게 쓰이는가?

소프트웨어 구성요소 목록(Software Bill of Materials, SBOM)은 소프트웨어에 포함된 구성요소와 관계를 구조화한 자료다. CycloneDX는 이를 통해 구성요소와 의존 관계 등을 표현한다. SBOM은 ‘무엇을 사용하고 있는가’를 추적할 근거가 되지만 생성 도구와 대상 범위에 따라 포함되는 정보가 달라질 수 있다. ^[8]

npm은 npm sbom으로 프로젝트의 의존성 목록을 SPDX 또는 CycloneDX 형식으로 출력할 수 있다. --package-lock-only를 쓰면 잠금 파일의 정보만 읽고 node_modules를 무시한다. 의존 패키지의 package.json에서 가져오는 설명·홈페이지·엔진 정보 등도 결과에서 빠질 수 있다. ^[4]

따라서 잠금 파일 기반 SBOM을 만들었다는 사실을 실제 설치 디렉터리의 모든 파일을 검사했다는 뜻으로 설명하면 안 된다. 홈페이지의 외부 CDN 스크립트, 별도 설치 플러그인, 서버 운영체제까지 이 명령 하나가 자동으로 포괄한다고 가정할 수도 없다. 생성한 목록의 대상과 실제 서비스의 전체 구성을 구분해야 한다.

가상 사례: 특정 버전의 문제가 발표됐을 때

가상의 이미지 처리 패키지 example-image-kit 2.4.1에 문제가 발표됐다고 가정하자. 유지보수자는 먼저 서비스별 구성요소 기록에서 해당 이름과 버전을 찾는다. 직접 설치한 패키지뿐 아니라 다른 패키지를 통해 들어온 간접 의존성도 확인한다. 이후 해당 서비스의 배포 이력과 실행 위치를 대조하고, 실제 영향과 조치 방법을 판단한다.

목록에 이름이 있다는 사실은 조사 대상이라는 뜻이다. 실제 악용 가능성과 노출 범위는 실행 환경·호출 경로·권한 등을 더 살펴봐야 한다. 반대로 목록에서 찾지 못했어도 목록의 생성 범위가 불완전했다면 사용하지 않았다고 단정할 수 없다.

이 글에서 제안하는 운영 방식은 SBOM과 함께 생성 날짜, 서비스 식별자, 소스 커밋, 배포 버전, 생성 도구 버전, 개발 의존성 포함 여부, 잠금 파일 기준인지 여부를 남기는 것이다. 이런 메타데이터가 있어야 서로 다른 시점의 목록을 비교하고 조사 대상 배포를 좁힐 수 있다.

6. 잠금 파일과 npm 명령은 어디까지 확인해주는가?

잠금 파일(Lockfile)은 해결된 의존성 트리를 기록하고, 서명 검사와 취약점 검사는 각각 별도의 검증을 수행한다. npm의 package-lock.json은 생성된 정확한 트리를 설명하며, 저장소에 포함해 의존성 변경을 확인하도록 설계돼 있다. 직접 의존성의 버전만 확인하면 간접 의존성의 변화를 놓칠 수 있으므로 전체 트리의 차이도 검토해야 한다. ^[9]

npm ci는 기존 잠금 파일을 요구하고, package.json과 잠금 파일의 의존성이 맞지 않으면 실패한다. 기존 node_modules를 제거한 뒤 설치하고 잠금 파일을 갱신하지 않는다. 이는 설치 일관성을 위한 동작이다. 잠긴 버전 자체가 문제가 있다면 일관되게 설치한다는 사실만으로 위험이 사라지지는 않는다. ^[10]

명령 설명의 근거는 npm 공식 문서다. --ignore-scripts를 설정해도 사용자가 명시적으로 요청한 npm run이나 npm test 등의 대상 스크립트는 실행될 수 있다. 정상 빌드에 필요한 설치 스크립트가 빠질 수도 있다. 또한 npm audit fix는 내부적으로 설치를 수행하므로 단순한 조회 명령으로 취급하면 안 된다. ^{[4] [5] [10]}

7. 홈페이지 유지보수에서는 어떤 기록을 남겨야 하는가?

유지보수에서는 채택한 구성요소, 배포물, 검증 결과, 승인 이유를 서비스별로 연결해 남기는 것이 유용하다. 다음은 앞선 기술적 구분을 홈페이지 운영에 적용한 실무 제안이다. 특정 조직이 이미 시행 중인 절차나 모든 프로젝트에 적용되는 의무를 뜻하지 않는다.

빌드에만 쓰는 도구와 운영 서버에서 실행되는 코드는 목록을 구분하는 편이 좋다. 전자는 최종 파일을 만드는 과정에 영향을 줄 수 있고, 후자는 운영 중 실행 권한을 가진다. 한쪽 목록만으로 서비스의 전체 위험을 판단하기 어려운 이유다.

외부 코드의 모든 줄을 매번 전수 검토하기는 어렵다. 대신 예상과 다른 변경을 찾아 검토할 수 있도록 기록을 연결해야 한다. 잠금 파일이 크게 바뀌었는지, 빌드 경로가 달라졌는지, 새 실행 스크립트가 들어왔는지, 증명이 사라졌는지 등을 검토 항목으로 정할 수 있다. 증명이 없다는 사실 자체로 악성을 단정하지 않고 추가 검토나 예외 승인 기준을 마련하는 방식이다.

고객에게도 ‘보안 검사 완료’라는 한 문장보다 어떤 버전을 사용했고 어떤 검사를 언제 했으며 어떤 예외를 허용했는지 설명하는 편이 구체적이다. 공급망 신뢰는 이렇게 남긴 근거를 다음 업데이트와 사고 대응에서 다시 활용하는 과정으로 유지된다.

8. 소프트웨어 공급망 검증에 관한 자주 묻는 질문

SBOM이 있으면 취약점이 없는 소프트웨어인가?

아니다. SBOM은 구성요소를 설명하는 자료다. 포함된 버전을 취약점 정보와 대조하는 검사는 별도이며, 목록의 범위와 생성 시점도 확인해야 한다. ^[8]

서명과 출처 증명이 모두 유효하면 설치해도 안전한가?

그 결과만으로 무해성을 확정할 수는 없다. 서명 대상과 제작 경로를 확인한 뒤에도 코드의 동작과 서비스에서 허용할 권한을 판단해야 한다. npm도 출처 증명이 악성 코드 부재를 보장하지 않는다고 설명한다. ^[3]

취약점 검사 결과가 0건이면 공급망 문제가 없는가?

해당 검사에서 알려진 취약점을 찾지 못했다는 뜻으로 읽어야 한다. 모든 악성 동작을 심사하거나 미래에 공개될 취약점까지 배제한 결과가 아니다. ^[5]

잠금 파일이 있으면 재현 가능한 빌드인가?

잠금 파일만으로 충분하지 않다. 재현 가능한 빌드(Reproducible Build)는 같은 소스, 빌드 환경, 지침으로 누구나 바이트 단위로 동일한 결과를 만들 수 있는 성질이다. 의존성 고정 외에도 빌드 도구·환경·입력의 관리가 필요하다. 동일하게 재현되는 코드도 안전성 판단은 별도로 해야 한다. ^[11]

설치 스크립트를 막으면 악성 코드 실행을 모두 막을 수 있는가?

아니다. 설치 스크립트 제한은 특정 실행 경로를 줄이는 조치다. 이후 애플리케이션이 패키지를 불러 실행하는 경로까지 코드의 안전성을 검증해주는 기능은 아니다. ^[10]

용어 정리

직접 의존성·간접 의존성

프로젝트가 직접 선언한 패키지와, 그 패키지 등을 통해 추가로 필요한 패키지. 전체 의존성 트리를 함께 추적해야 한다.

배포물(Artifact)

빌드·패키징을 거쳐 배포하거나 설치하는 파일 또는 묶음.

증명 문서(Attestation)

특정 대상에 관한 주장을 담은 구조화된 자료. 출처 증명과 SBOM 등 서로 다른 내용을 담을 수 있으며, 주장 유형과 서명 여부를 구분해 읽는다.

빌더(Builder)

소스를 입력받아 배포물을 만드는 빌드 시스템. 검증에서는 해당 빌더를 신뢰할 기준이 필요하다.

CI/CD

지속적 통합·배포(Continuous Integration / Continuous Delivery). 코드 통합, 빌드, 검사, 배포 등의 절차를 자동화하는 체계.

참고 자료

기술적 사실은 아래 공식 문서를 근거로 정리했다. 가상 사례와 유지보수 기록 방식은 이를 적용한 설명·제안이다. 명령의 옵션과 지원 조건은 사용하는 도구 버전의 문서를 함께 확인한다.

1. SLSA 1.2 — Build: Verifying artifacts
2. Sigstore — Verifying Signatures
3. npm — Generating provenance statements
4. npm CLI 12 — npm sbom
5. npm CLI 12 — npm audit
6. npm — Trusted publishing for npm packages
7. GitHub Actions — Secure use reference
8. CycloneDX — Software Bill of Materials
9. npm CLI 12 — package-lock.json
10. npm CLI 12 — npm ci
11. Reproducible Builds — Definitions

홈페이지를 만드는 코드는 모두 한 회사에서 작성되지 않는다. 화면을 구성하는 라이브러리, 파일을 변환하는 도구, 빌드와 배포를 수행하는 자동화까지 여러 개발자가 만든 코드를 가져와 사용한다. 따라서 서비스의 신뢰를 살펴보려면 직접 작성한 코드와 함께 외부 코드가 들어오는 경로도 확인해야 한다.

최근 npm의 업데이트는 이 경로에서 누가 파일을 제출할 수 있고, 누가 공개를 승인하며, 어떤 자동화 실행에 배포 권한을 줄 것인가를 더 세밀하게 나누고 있다. GitHub는 9월 18일 단계적 배포 전용 토큰을 발표했고, 10월 2일에는 신규 패키지의 승인 대기 생성과 미검증 배포 신뢰 설정의 만료 정책을 공개했다.^[1][2][3]

10월 5일에는 보안업체 StepSecurity가 npm 패키지 @subql/common@5.8.3의 악성 동작을 보고했다. 이 사건은 배포 인증의 강화와 함께 실제 배포 파일을 검토해야 하는 이유를 보여준다. 두 npm 정책이 이 사건 때문에 도입됐다는 인과관계는 확인되지 않았다.^[5][6]

1. 소프트웨어 공급망은 설치 버튼 앞에서 시작된다

소프트웨어 공급망(Software Supply Chain)은 소스 코드가 작성되고, 빌드되고, 배포되어 다른 서비스에서 사용되는 경로를 뜻한다. 여기에는 개발자와 소스 저장소뿐 아니라 빌드 환경, 배포 파일, 패키지 저장소와 의존성도 포함된다. 공급망 보안의 핵심은 이 연결 과정에서 의도하지 않은 변경이나 파일 교체가 들어오는 지점을 확인하는 것이다.^[7]

자바스크립트 생태계에서 널리 쓰이는 npm은 개발자가 패키지를 공유하고 프로젝트에 설치할 수 있도록 한다. 패키지는 재사용할 코드와 관련 정보를 묶은 단위다. 다른 패키지가 필요한 경우에는 추가 의존성도 함께 해결된다. 그래서 프로젝트가 직접 선택한 이름 몇 개만으로 설치되는 코드 전체를 설명할 수는 없다.^[8]

이때 저장소의 소스 코드와 사용자가 설치하는 배포물(Artifact)을 구분해야 한다. 빌드가 소스를 변환하거나 생성 파일을 추가할 수 있고, 배포 과정에서도 파일을 다룬다. SLSA의 공급망 모델 역시 소스가 의도대로 관리되는지와 최종 패키지가 올바른 입력·절차로 만들어지는지를 나누어 설명한다.^[7]

2. 신규 npm 패키지도 공개 전에 검토할 수 있게 됐다

GitHub의 10월 2일 발표에 따르면, 이제 npm stage publish로 새로운 패키지를 생성할 수 있다. 로컬 세션이나 세분화 접근 토큰(Granular Access Token)을 사용할 수 있으며, 단계적 배포 전용 토큰도 포함된다. 자동화 작업에서 신규 패키지를 만들 때 먼저 수동으로 첫 배포를 해야 하는 부담을 줄이는 변화다.^[2]

단계적 배포(Staged Publishing)는 파일을 곧바로 공개하는 대신 검토 대기 영역에 제출하는 방식이다. 패키지 관리자가 검토하고 2단계 인증(Two-factor Authentication, 2FA)을 거쳐 승인하면 해당 버전이 공개된다. npm 문서는 제출된 압축 파일을 내려받아 살펴볼 수 있는 절차도 제공한다.^[4]

이번 확대는 공개 패키지의 scoped·unscoped 유형과 비공개 scoped 패키지를 지원한다. scoped는 @조직/패키지처럼 이름에 범위를 붙이는 형식이다. 실제 첫 버전은 관리자가 승격해야 설치 가능해지고, 패키지를 생성한 뒤 설정과 신뢰 기반 배포를 구성할 수 있다.^[2]

신규 생성 때는 공개된 자리표시 버전 0.0.0-stage가 생길 수 있다. 따라서 승인 전까지 패키지 이름조차 드러나지 않는 구조로 이해하면 안 된다. 공개된 자리표시 버전과 아직 승인되지 않은 실제 버전의 내용을 구분해야 한다. 공식 문서의 최소 요구사항은 npm CLI 11.15.0과 Node.js 22.14.0이다.^[4]

여기서 주목할 변화는 자동화의 제출과 사람의 공개 결정을 분리할 수 있다는 점이다. 모든 npm 패키지에 이 절차가 강제되는 것은 아니며, 승인 기능을 사용한다고 해서 사람이 모든 코드를 검토했다는 의미도 아니다.

3. stage-only 토큰은 무엇을 제한하는가

이 흐름은 9월 18일 발표된 단계적 배포 전용 토큰(Stage-only Token)과 연결된다. 해당 토큰은 자동화가 검토용 버전을 제출할 수 있도록 하면서, 새로운 버전을 직접 공개하는 npm publish는 거부한다. 자동화를 위해 2단계 인증을 우회하도록 설정했더라도 직접 배포 제한은 유지된다.^[1]

다만 이름만 보고 읽기 전용 수준의 권한이라고 생각하면 안 된다. GitHub는 이 토큰에 배포 태그를 이동하거나 버전의 사용 중단을 표시하는 등의 다른 쓰기 권한이 남아 있다고 설명한다. 직접 공개가 제한됐다는 사실과 패키지 운영에 영향을 줄 수 없다는 주장은 다르다.^[1]

9월 발표는 선택적으로 적용하는 기능이며 기존 토큰의 직접 배포 능력을 자동으로 바꾸지 않는다. 또한 GitHub는 2단계 인증을 우회하는 토큰을 통한 직접 배포 제거 목표를 2027년 1월로 안내했다. 이는 발표에 명시된 향후 목표로, 현재 모든 토큰 배포가 중단됐다는 뜻은 아니다.^[1]

4. ‘48시간 만료’는 미검증 신뢰 설정에 적용된다

신뢰 기반 배포(Trusted Publishing)는 개방형 인증 연결(OpenID Connect, OIDC)을 사용해 승인된 자동화 실행의 정체성을 확인하는 방식이다. 패키지에 특정 저장소와 워크플로 등을 등록하고, 해당 실행에서 단기 자격 증명을 사용해 배포한다. 장기 npm 쓰기 토큰을 자동화 환경에 보관하는 부담을 줄일 수 있다.^[9]

GitHub는 10월 2일부터 검증되지 않은 신뢰 기반 배포 설정이 생성 48시간 후 만료되며, 더 이상 배포를 허용하지 않는다고 발표했다. 저장소나 프로젝트 이름의 소유권이 바뀔 때 남아 있는 신뢰 설정의 위험을 제한하기 위한 조치다.^[3]

일반적인 설정 수정은 만료 기한을 다시 시작하지 않는다. 패키지에 있는 다른 유효한 설정도 영향을 받지 않는다. 같은 발표에서는 GitHub Actions의 issue_comment 이벤트에서 오는 배포 토큰도 거부한다고 안내했다. 이는 기존 pull_request_target 제한에 추가된 것으로, 댓글 기반 이벤트를 배포 경로로 사용하는 자동화는 실행 이벤트를 검토해야 한다.^[3]

이 변경은 패키지 버전이 48시간 뒤 사라진다는 정책이 아니다. ‘검증되지 않은 배포 신뢰 관계’를 정리하는 규칙이다. 저장소 이름을 등록하는 단계와 실제 배포가 성공해 해당 관계가 검증되는 단계를 구분하면 적용 범위를 이해하기 쉽다.

5. 10월 5일 보고는 실제 배포 파일의 문제를 드러냈다

StepSecurity는 10월 5일 @subql/common@5.8.3을 분석해 자격 증명을 수집하고 원격 셸 접근을 지원하는 숨겨진 코드를 확인했다고 보고했다. 조사 대상은 SubQuery 생태계의 공통 라이브러리다. 보고서는 개발자 작업 환경과 지속적 통합(CI) 환경을 대상으로 하는 동작을 설명한다.^[5]

조사에서 중요한 지점은 파일의 실행 시점과 배포 직전의 교체다. 보고서에 따르면 악성 동작은 설치 스크립트와 코드 가져오기(import)에서 각각 시작할 수 있었다. 또한 저장소 소스를 빌드한 뒤 외부 아카이브로 패키지 디렉터리를 바꾸는 워크플로 변경이 발견됐다. 추가된 교체 단계에는 외부 파일의 해시나 서명을 검증하는 절차가 없었다고 설명한다.^[5]

StepSecurity 측이 작성한 공개 이슈 #3047은 해당 버전이 GitHub Actions OIDC 신뢰 기반 배포를 통해 게시됐다고 보고한다. 이슈는 프로젝트 저장소에 올라온 조사자의 신고이며, 프로젝트 관리자가 발행한 공식 사고 확정 공지와 구분해야 한다. 10월 6일 확인한 이슈 화면에서는 관리자의 답변을 확인하지 못했다.^[6]

따라서 공격자의 신원이나 최초 침입 경로, 전체 피해 규모를 이번 자료만으로 확정할 수는 없다. 해당 조사 보고와 공개 이슈는 같은 조사기관의 자료다. 두 개의 독립적인 조사 결과로 세거나, 저장소에 표시된 계정명을 실제 공격자의 신원으로 단정해서는 안 된다.

이 사례에서 확인할 수 있는 질문은 명확하다. 승인된 배포 정체성으로 파일이 올라왔더라도, 그 파일을 만드는 과정과 최종 내용은 따로 살펴봐야 한다. 설치 스크립트 차단만으로 이후 import 경로까지 통제했다고 볼 수도 없다.

6. 출처 증명이 있다는 것은 무엇을 의미하는가

배포 출처 증명(Provenance)은 패키지의 소스와 빌드 지침 등에 연결되는 검증 가능한 정보를 제공한다. npm은 출처 증명과 권한 있는 사용자의 게시를 레지스트리가 기록하는 배포 증명을 구분한다. 서명과 공개 투명성 기록은 이러한 정보의 진위와 변경 여부를 확인하는 데 사용된다.^[10]

npm 공식 문서는 출처 증명이 있는 패키지라도 악성 코드가 없다고 보장하지 않는다고 명시한다. 증명은 개발자가 경로를 확인하고 검토할 수 있는 근거다. 기록의 존재와 코드에 대한 안전성 판단은 별도의 단계로 남는다.^[10]

이 표의 ‘추가로 살펴볼 부분’은 공식 문서의 기능 범위를 바탕으로 정리한 해석이다. 각각의 확인을 연결하면 기록을 통해 판단할 수 있는 범위가 넓어지지만, 하나의 배지나 인증 결과를 모든 보안 검토의 대체물로 사용할 수는 없다.

7. 홈페이지 유지보수에서는 무엇이 달라지는가

직접 npm 패키지를 배포하지 않는 회사도 외부 패키지를 소비하는 입장에서 이 변화를 읽을 수 있다. 공급자에게는 제출·승인·배포 권한을 나누는 문제가 있고, 소비자에게는 어떤 버전과 파일을 채택했는지 확인하는 문제가 있다. 아래는 최근 발표와 공식 문서에서 도출한 실무 관점이다.

사용한 전체 의존성 트리를 기록한다

잠금 파일(Lockfile)인 package-lock.json은 해결된 의존성 트리를 기록한다. npm 문서는 이를 저장소에 포함해 팀원과 배포 환경이 같은 의존성을 설치하고, 변경 차이를 확인하도록 설명한다. 상위 패키지의 이름과 버전만 기록하는 것보다 실제 채택한 구성을 추적하기에 적합하다. 다만 잠긴 버전 자체가 안전하다는 인증서는 아니다.^[8]

인증 성공과 취약점 검사 결과를 따로 읽는다

npm audit는 알려진 취약점에 관한 보고를 요청한다. npm audit signatures는 레지스트리 서명과 출처 증명을 검증한다. 검사 이름이 비슷하더라도 확인하는 대상은 다르다. 어느 검사를 수행했고 무엇을 확인했는지 기록해야 ‘검사 통과’라는 한 문장보다 결과를 정확하게 설명할 수 있다.^[11]

배포 파일을 만드는 자동화도 검토한다

GitHub는 자동화 토큰에 최소 권한을 부여하고 외부 action을 전체 커밋 식별자로 고정하는 등의 보안 원칙을 안내한다. 기능 코드가 바뀌지 않더라도 자동화 설정이 달라지면 실행되는 코드와 파일 처리 경로가 달라질 수 있다. 워크플로 변경은 최종 결과물에 영향을 주는 변경으로 읽어야 한다.^[12]

사고 패키지와 고객 서비스를 연결할 자료를 남긴다

소프트웨어 구성요소 목록(Software Bill of Materials, SBOM)은 프로젝트의 구성요소를 정리하는 자료다. npm은 SPDX와 CycloneDX 형식의 목록 생성을 지원한다. 다만 잠금 파일만 읽어 만든 목록과 실제 설치·배포 상태는 구분해야 한다. 기록의 대상과 생성 시점을 함께 남겨야 특정 버전이 어느 서비스에 포함됐는지 판단하는 데 도움이 된다.^[13]

8. 최근 변화가 넓히는 확인의 범위

이번 발표들을 함께 읽으면 npm이 배포 권한을 더 세분화하고 있다는 흐름이 보인다. 자동화에는 제출 권한을 주고, 공개 결정에는 사람의 승인을 둘 수 있으며, 검증되지 않은 배포 신뢰 관계에는 유효 기간을 적용한다. 이는 각 발표를 연결한 해석이다.

동시에 최근 사고 보고는 승인된 배포 경로와 실제 배포 파일을 함께 확인해야 하는 이유를 보여준다. 저장소에 무엇이 있었는지, 빌드가 무엇을 했는지, 공개된 패키지에 무엇이 들어갔는지는 연결해서 살펴볼 대상이다.

소프트웨어 공급망의 신뢰는 어떤 코드를 선택했는지에 더해, 어떤 경로로 받아들였고 무엇을 확인했는지 설명할 수 있는 기록에서 구체화된다. 최근 npm의 변화는 그 기록과 권한을 나누는 도구를 늘리고 있다. 실제 안전성 판단에는 각 도구가 확인해주는 범위와 남아 있는 검토 대상을 함께 읽는 일이 필요하다.

용어 정리

참고 자료

발표일과 조사 보고일을 구분했다. 제품 동작은 2026년 10월 6일 조회한 공식 문서를 기준으로 정리했으며, 사건 내용은 조사기관에 귀속했다.

1. GitHub · Stage-only npm tokens for safer automation — 2026.09.18.
2. GitHub · npm staged publishing now supports creating new packages — 2026.10.02.
3. GitHub · Unvalidated npm trusted publishing configurations now expire — 2026.10.02.
4. npm Docs · Staged publishing for npm packages
5. StepSecurity · SubQuery Ecosystem Compromise: Hidden Credential Theft and Backdoors — 2026.10.05.
6. subquery/subql · 공개 이슈 #3047, StepSecurity 측 신고 — 2026.10.05.
7. SLSA 1.2 · Supply chain threats
8. npm Docs · package-lock.json, CLI v12
9. npm Docs · Trusted publishing for npm packages
10. npm Docs · Generating provenance statements
11. npm Docs · npm audit, CLI v12
12. GitHub Docs · Secure use reference
13. npm Docs · npm sbom, CLI v12

“거실 에어컨을 24도로 맞춰줘.” 사용자는 기기의 이름과 원하는 상태를 말한다. 시스템이 이 요청을 처리하려면 ‘거실 에어컨’에 해당하는 실제 기기를 찾고, 24도라는 값을 그 기기가 받아들일 수 있는 명령으로 바꿔야 한다. 이어서 명령을 전달하고 결과를 확인한 뒤, 어디까지 처리됐는지 알려줘야 한다.

사용자에게는 하나의 대화처럼 보이지만, 시스템 안에서는 소리와 언어, 데이터와 기기 상태가 연결된다. 그중 어느 연결이 잘못되느냐에 따라 오류도 달라진다. 다른 방의 기기가 동작하는 문제와 올바른 기기가 연결되지 않는 문제, 실행되지 않았는데 완료했다고 답하는 문제는 서로 다른 원인을 갖는다.

이 글은 한 문장의 요청이 실제 동작으로 이어지는 과정을 따라가며 음성 AI의 구조를 설명한다. 먼저 음성을 처리하고 발화의 경계를 판단하는 원리를 살펴본 뒤, 요청을 실행 가능한 정보로 구체화하는 방법과 결과를 확인하는 과정을 연결한다. 마지막에는 취소·재시도·처리 위치·품질 평가를 통해 같은 구조가 실제 운영에서 어떻게 달라지는지 살펴본다.

이 글의 에어컨·조명 사례와 명령 데이터는 원리 설명을 위한 가상 예시다. 특정 제품의 실제 API나 시험 결과를 나타내지 않는다. 실제 구현에서는 일부 과정이 통합되거나 병렬로 진행될 수 있다.

CONTENTS / 본문 목차

1. 음성 인식과 기기 제어는 어떻게 연결될까
2. 음성 AI가 소리를 처리하는 방식
3. AI는 언제 사용자의 말이 끝났다고 판단할까
4. 자연스러운 표현을 실행 가능한 요청으로 바꾸는 과정
5. 함수 호출은 실제 실행과 어떻게 이어질까
6. 명령을 보낸 뒤 무엇을 확인해야 할까
7. 말을 정정하거나 취소하면 어떻게 될까
8. 온디바이스와 클라우드는 어디에서 나뉠까
9. 음성 AI의 품질은 무엇으로 평가할까
10. 자주 묻는 질문
11. 용어집
12. 참고 자료

01 / PROCESS

음성 인식과 기기 제어는 어떻게 연결될까

자동 음성 인식(Automatic Speech Recognition, ASR)은 소리를 문자로 바꾸는 기술이다. “거실 에어컨을 24도로 맞춰줘”라는 음성을 같은 내용의 문장으로 변환했다면 받아쓰기는 성공한 셈이다. 그러나 문장 안의 ‘거실 에어컨’이 실제로 어느 기기인지, ‘맞춰줘’가 어떤 기능을 뜻하는지는 추가로 해결해야 한다.

요청을 해석하는 과정에서는 사용자가 원하는 동작과 필요한 정보를 구분한다. 이 예시의 동작은 온도 설정이고, 대상은 거실 에어컨이며, 입력값은 24도다. 이어지는 실행 과정에서는 시스템에 등록된 기기를 찾고, 사용할 수 있는 제어 기능과 허용 범위를 확인한 뒤 명령을 보낸다. 마지막 응답은 이러한 실행의 결과에 근거해야 한다.

Home Assistant의 공식 개발 문서는 음성 파이프라인, 대화 처리, 의도 실행의 역할을 구분한다. 이 구분은 음성 제어를 이해하는 데 유용하지만 모든 제품에 동일한 모듈 구성을 요구하는 것은 아니다. 한 모델이 여러 역할을 함께 처리하더라도, 소리를 이해하는 문제와 외부 상태를 바꾸는 문제는 개념적으로 구분할 수 있다.[3]

이 구분은 오류를 찾을 때도 중요하다. 음성은 정확히 인식했는데 다른 방의 기기가 바뀌었다면 대상 연결의 문제일 수 있다. 올바른 명령을 만들었는데 기기가 오프라인이었다면 실행의 문제다. 결과를 확인하지 않고 성공했다고 답했다면 응답을 만드는 기준의 문제다. 이들을 모두 ‘음성 인식이 나빴다’고 설명하면 실제 원인을 놓치게 된다.

02 / ARCHITECTURE

음성 AI가 소리를 처리하는 방식

전체 과정을 이해했다면 첫 번째로 살펴볼 것은 소리가 시스템에 들어오는 방식이다. 음성의 문자 변환(Speech-to-Text, STT), 요청 처리, 문자의 음성 변환(Text-to-Speech, TTS)을 연결하는 연쇄형 구조가 있고, 실시간 모델이 음성을 입력받아 음성으로 출력하는 구조도 있다. OpenAI의 음성 에이전트 가이드는 이러한 구성 경로를 설명한다.[1]

연쇄형에서는 음성 인식 결과가 명시적인 문자로 다음 단계에 전달된다. 개발자는 잘못 들은 문장인지, 올바른 문장을 잘못 해석한 것인지 중간 결과를 보고 살펴볼 수 있다. 각 구성요소를 따로 선택하거나 교체할 수도 있다. 대신 여러 구성요소의 처리 시간과 데이터 전달이 전체 응답 시간에 영향을 줄 수 있다.

직접 음성 입출력형에서는 음성을 받아쓴 문장인 전사문이 외부 처리 흐름의 필수 입력으로 드러나지 않을 수 있다. 그렇다고 문자 정보가 어느 곳에서도 사용되지 않는다는 뜻은 아니다. 전사나 도구 호출 등 함께 제공하는 기능은 모델과 서비스에 따라 다르며, 내부 구현을 사용자 인터페이스만으로 단정할 수 없다.

전이중(Full-Duplex)은 동시에 듣고 말하는 통신·상호작용 특성이다. 이는 음성을 문자로 바꾸는지와 별개의 문제다. 음성 처리를 구성하는 방식과 대화 차례를 운영하는 방식을 나눠 살펴보면 비교가 명확해진다. 사용자 발화가 시작되면 기존 음성을 멈추는 방식과, 입력·출력을 동시에 처리하는 방식도 구현상 구분할 필요가 있다.

구조의 이름만으로 성능의 우열을 정할 수도 없다. 음성 응답이 빨리 시작되더라도 연결된 기기 제어가 오래 걸릴 수 있고, 모델 처리보다 네트워크 지연이 더 클 수도 있다. 비교할 때는 첫 응답이 나오는 시간과 실제 작업이 끝나는 시간을 분리해야 한다.

03 / TURN DETECTION

AI는 언제 사용자의 말이 끝났다고 판단할까

소리를 처리하는 기능만으로는 언제 요청을 실행해야 하는지 알 수 없다. 시스템은 먼저 어떤 발화를 자신에게 하는 요청으로 받을지, 언제까지 들어야 할지를 결정해야 한다. 깨우는 말(Wake Word)은 시스템을 호출하는 표현이다. 음성 활동 감지(Voice Activity Detection, VAD)는 입력된 소리에 말소리 활동이 있는지 판단한다. 발화 종료 판단(Turn Detection)은 사용자의 차례가 끝나 반응을 시작해도 되는지를 결정한다.[4]

침묵을 기준으로 종료를 판단하는 방식에서는 일정 시간 말소리가 없으면 사용자 차례가 끝났다고 볼 수 있다. 짧게 기다리면 반응이 빨라지는 대신 생각하는 동안의 쉼을 종료로 오인할 가능성이 생긴다. 오래 기다리면 사용자의 말을 더 받아들일 수 있지만 응답이 늦게 느껴질 수 있다. 발화 내용의 완결성을 고려하는 방식도 있으며, 지원 여부와 설정은 서비스에 따라 다르다.[6]

이 문제는 마이크의 음질만 높여서는 해결되지 않는다. 모든 단어를 정확히 들어도 사용자가 아직 말을 이어갈지 판단해야 하기 때문이다. 버튼을 누르고 말하는 방식에서는 버튼을 놓는 동작이 종료 신호가 될 수 있고, 대화형 시스템에서는 음향 정보와 발화 내용 등을 활용해 종료를 판단할 수 있다.

화면에 나온 받아쓰기가 확정된 결과는 아닐 수 있다

스트리밍 음성 인식은 문장이 끝나기 전에 부분 결과를 전달할 수 있다. Amazon Transcribe 문서는 뒤의 문맥이 추가되면서 이 결과가 수정될 수 있다고 설명한다. 빠르게 표시되는 문자와 최종적으로 판단에 사용할 문자를 구분해야 하는 이유다.[8]

예를 들어 “에어컨을 켜…”까지 보였는데 뒤에 “지 말아줘”가 이어지면 동작의 의미가 달라진다. 중간 결과로 관련 기기를 찾는 준비 작업과 상태를 실제로 바꾸는 실행은 영향이 다르다. 둘을 분리하는 것은 오류를 줄이기 위한 설계 방법이 될 수 있다. 다만 언제 실행을 허용할지는 작업의 성격과 구현에 따라 정해야 하며, 모든 음성 시스템에 하나의 대기 규칙을 적용할 수는 없다.

04 / INTENT AND TARGET

자연스러운 표현을 실행 가능한 요청으로 바꾸는 과정

요청을 처리할 시점이 정해지면 말의 내용을 실행에 필요한 정보로 바꿔야 한다. 요청의 의도(Intent)는 사용자가 수행하려는 동작이고, 슬롯(Slot)은 그 동작에 필요한 변수다. “거실 에어컨을 24도로 맞춰줘”에서 온도 설정은 의도에, 거실·에어컨·24도는 입력 정보에 해당한다. Alexa의 상호작용 모델도 의도와 슬롯을 구분하고 여러 표현을 같은 요청으로 연결한다.[13]

의도와 입력값을 다루는 기능은 생성형 AI 이전의 음성 시스템에도 존재했다. 생성형 모델을 활용하는 시스템에서는 요청과 이어지는 대화, 제공된 도구 설명 등을 함께 해석하도록 구성할 수 있다. 그러나 표현을 유연하게 이해하는 능력과 실행 정보를 충분히 확보하는 것은 다르다. “좀 시원하게 해줘”라는 말을 이해해도 어떤 기기를 사용할지, 어떤 상태를 목표로 할지는 남아 있다.

시스템이 값을 정하는 근거도 구분해야 한다. 사용자가 이번 문장에서 직접 말한 값인지, 앞선 대화에서 확인된 값인지, 사용자가 지정한 기본 설정인지, 모델이 추정한 값인지에 따라 확실성이 다르다. 불명확한 상태에서 실행하면 같은 문장에 서로 다른 결과가 나올 수 있다.

문장 안의 이름을 실제 환경의 대상으로 연결하는 것도 별도의 문제다. ‘거실 에어컨’이라는 말이 데이터에서 어떤 기기 식별자를 뜻하는지 알아야 한다. 기기 이름이 중복되거나 사용자가 별명을 쓰면 후보를 좁히는 과정이 필요하다. 문자열을 추출한 것만으로 대상 연결이 끝났다고 볼 수 없다.

확인 질문은 부족한 정보를 정확히 드러내는 방식으로 구성할 수 있다. “무엇을 원하시나요?”보다 “거실 에어컨과 침실 에어컨 중 어느 기기인가요?”가 사용자가 해결해야 할 모호성을 명확하게 보여준다. 이는 모든 명령에 확인 질문을 추가하라는 의미가 아니다. 요청과 환경에서 충분히 결정된 값까지 반복해서 묻는 것은 대화를 불필요하게 길게 만들 수 있다.

05 / FUNCTION CALLING

함수 호출은 실제 실행과 어떻게 이어질까

동작과 대상, 값이 구체화됐다고 기기가 곧바로 움직이는 것은 아니다. 이를 실제 기능에 연결하는 과정이 필요하다. 함수 호출(Function Calling)은 모델이 정의된 함수와 입력값을 선택해 외부 기능과 연결하는 방식이다. 도구 호출(Tool Calling)은 검색·조회·계산·실행 등 외부 기능을 사용하는 더 넓은 표현으로 쓰인다. Gemini의 공식 가이드에서는 애플리케이션이 함수의 이름·설명·입력 구조를 제공하고, 모델이 제안한 호출을 애플리케이션이 실행하며, 그 결과를 다시 모델에 전달한다.[2]

따라서 자연어를 이해하는 모델과 기기 제어 인터페이스(Application Programming Interface, API)를 호출하는 애플리케이션의 책임을 분리해서 봐야 한다. 모델이 ‘온도 설정’ 기능을 선택했다는 사실은 실제 기기의 온도가 바뀌었다는 사실이 아니다. 애플리케이션은 호출을 받아 자신의 실행 규칙에 따라 검사하고 전달해야 한다.

{
  "tool": "set_temperature",
  "arguments": {
    "device_id": "living_room_ac",
    "temperature": 24,
    "unit": "celsius"
  }
}

위 데이터는 역할을 설명하기 위한 가상 형식이다. 특정 업체의 SDK나 기기 API에 그대로 사용할 수 있는 코드가 아니다.

이 명령에는 세 가지 중요한 값이 담겨 있다. 기기 식별자는 실행 대상을, 온도는 목표 설정값을, 단위는 숫자의 해석 방법을 정한다. 설명에 필요한 정보가 분리돼 있으므로 애플리케이션은 누락된 항목이나 잘못된 자료형을 검사할 수 있다. 그러나 형식이 맞는 것만으로 실제 환경에서 유효한 요청이 되지는 않는다.

구조화 출력(Structured Output)은 정해진 데이터 형식에 맞는 결과를 얻는 데 쓰인다. 예를 들어 온도를 숫자로 받고 기기 식별자를 문자열로 받도록 정의할 수 있다.[14] 그와 별개로 해당 식별자의 기기가 존재하는지, 온도 설정을 지원하는지, 값이 허용 범위에 있는지, 사용자가 실행할 권한이 있는지는 애플리케이션의 데이터와 규칙으로 확인해야 한다.

모델에 어떤 기능을 제공하는지도 해석에 영향을 준다. 읽기 전용 조회와 상태를 바꾸는 실행을 명확하게 구분하고, 필요한 입력값과 기능의 의미를 설명해야 한다. 이름만 다른 비슷한 기능이 많으면 선택이 모호해질 수 있다. 여기서 설명하는 검증은 실행 연결의 문제이며, 실행 환경 자체의 격리 원리는 AI 에이전트 샌드박스 글에서 따로 다룬다.

06 / RESULT VERIFICATION

명령을 보낸 뒤 무엇을 확인해야 할까

명령을 전달한 다음에는 결과를 해석해야 한다. 서버가 요청을 받았다는 응답, 실행이 완료됐다는 응답, 기기의 상태를 조회한 결과는 의미가 다를 수 있다. 예를 들어 비동기 작업에서는 요청을 먼저 접수하고 실제 처리를 나중에 수행할 수 있다. 이때 접수 응답을 완료로 해석하면 사용자가 듣는 안내와 기기의 상태 사이에 차이가 생긴다.

성공 조건도 요청에 맞게 정해야 한다. 에어컨 설정을 바꾸는 작업이라면 설정값의 변경이 조건이 될 수 있고, 특정 실내 온도에 도달했는지 묻는 요청이라면 온도 측정값이 필요하다. 무엇을 확인할지 정하기 전에 단순히 ‘성공’이라는 상태만 붙이면 서로 다른 결과를 같은 의미로 취급하게 된다.

Home Assistant의 대화 API는 작업 완료·조회 응답·오류를 구분하며, 요청의 성공 대상과 실패 대상을 표현할 수 있다.[5] 이를 통해 여러 기기를 함께 제어할 때 전체 성공과 일부 성공을 나눠 이해할 수 있다. 아래 표는 원리 설명을 위한 결과 분류이며, 모든 API가 사용하는 공통 상태 코드는 아니다.

에어컨 예시에서는 설정 온도와 현재 실내 온도를 구분해야 한다. 설정값이 24도로 바뀌었다고 해서 방이 이미 24도가 된 것은 아니다. 앞의 결과는 제어 설정의 변경이고, 뒤의 결과는 물리적인 환경의 변화다. “24도로 설정했어요”와 “방 온도가 24도예요”는 서로 다른 확인 근거가 필요한 문장이다.

상태 정보가 어디에서 오는지도 중요하다. Google Home의 Report State는 연동 시스템이 기기의 상태를 보고해 저장된 정보를 갱신하는 구조이며, 보고한 상태와 조회한 상태 사이의 불일치를 다룬다.[12] 저장된 상태를 활용하는 시스템에서는 정보의 최신성과 갱신 실패가 결과 해석에 영향을 줄 수 있다.

이를 종합하면, 상태 조회를 한 번 추가했다고 모든 결과가 완전히 검증되는 것은 아니다. 조회 정보가 명령의 접수 상태인지, 기기가 보고한 설정값인지, 별도 센서가 측정한 물리 상태인지 구분해야 한다. 시스템은 확인하지 못한 사실까지 완료 응답에 포함하지 않도록 구성해야 한다.

실행 과정을 화면에 전달하는 방법과 결과 자체의 의미도 구별된다. AG-UI 같은 상호작용 규격으로 진행 상황을 표시하더라도, 실제 기기가 동작했는지 판단하는 근거는 연결된 실행 시스템에서 마련해야 한다.

07 / INTERRUPTION AND RETRY

말을 정정하거나 취소하면 어떻게 될까

사용자는 AI가 답하는 동안 말을 끊거나 요청을 바꿀 수 있다. 실시간 음성 시스템은 이러한 끼어들기(Barge-In)를 처리하면서 진행 중인 음성 응답을 중단할 수 있다. OpenAI의 실시간 대화 문서는 응답 취소와 사용자가 듣지 않은 음성 부분을 대화 기록에서 처리하는 방식을 설명한다.[7]

하지만 음성 출력과 외부 작업은 서로 다른 흐름이다. 다음 구분은 응답 취소 기능과 외부 실행 구조를 연결한 설계상의 해석이다. AI가 말을 멈춘 것만으로 이미 기기에 전달한 명령이 자동으로 취소되거나 되돌아간다고 볼 수는 없다.

“24도로 맞춰줘” 뒤에 “아니, 26도로”가 이어지면 어떤 요청이 이미 실행됐는지 알아야 한다. 첫 명령을 아직 보내지 않았다면 새 값으로 대체할 수 있지만, 이미 보냈다면 두 번째 명령의 실행 순서와 결과를 관리해야 한다. 정정된 문장을 대화 기록에 반영하는 일과 기기의 최종 상태를 맞추는 일은 함께 해결해야 한다.

두 요청을 동시에 처리하는 구현에서는 나중에 도착한 결과가 사용자의 마지막 의도와 같은지도 확인해야 한다. 새 명령을 보냈다는 사실만으로 오래된 작업의 영향을 제거할 수는 없다. 작업마다 식별자와 상태를 연결해 두면 어떤 요청의 응답인지 구분할 수 있고, 순차 처리나 이전 요청 취소 같은 정책을 해당 기능의 특성에 맞춰 적용할 수 있다.

응답을 받지 못했다고 실행되지 않은 것은 아니다

연결이 끊기거나 시간 초과가 발생하면 시스템은 작업 결과를 모를 수 있다. 명령이 서버에 도달하지 않았을 수도 있지만, 기기가 동작한 뒤 응답만 유실됐을 수도 있다. 이 상태에서 같은 명령을 다시 보내면 중복 실행이 발생할 가능성이 있다.

멱등성(Idempotency)은 같은 작업을 반복해도 정의된 효과가 반복해서 추가되지 않는 성질이다. Stripe는 동일 요청의 재시도를 식별하는 멱등성 키를 제공해 중복 작업을 방지하는 실제 API 사례를 보여준다.[11] 기기 제어에도 중복 방지와 재시도 설계가 중요하지만, Stripe의 기능이 모든 기기 API에 제공되는 것은 아니다.

“24도로 설정”과 “2도 내려”를 비교하면 차이가 보인다. 후자를 두 번 실행하면 설정값이 누적해서 바뀔 수 있다. 같은 값으로 설정하는 명령도 부수효과까지 모두 안전하게 반복된다고 단정할 수는 없다. 재시도 여부는 요청 식별자, 처리 기록, 현재 상태와 해당 API의 동작 계약을 함께 보고 결정해야 한다.

08 / LOCAL AND CLOUD

온디바이스와 클라우드는 어디에서 나뉠까

온디바이스(On-Device)는 해당 처리를 기기 안에서 수행한다는 의미다. 그러나 마이크가 기기에 붙어 있거나 호출어를 기기에서 감지한다는 사실만으로 전체 음성 AI가 로컬에서 작동한다고 볼 수 없다. 음성 입력부터 실제 기기 제어까지 각 단계의 처리 위치를 살펴봐야 한다.

Home Assistant는 음성 인식·대화 처리·음성 합성 등을 로컬로 구성하는 경로를 안내한다.[9] 여기서 로컬 처리는 반드시 작은 기기 하나 안에서 모든 기능을 수행한다는 뜻은 아니다. 집 안의 다른 서버를 활용하는 구성도 로컬 환경에 포함될 수 있다. 기기 내부 처리와 로컬 네트워크 처리를 구분하면 데이터 이동 경로를 더 정확히 이해할 수 있다.

표는 단계별 조합을 설명하기 위한 예시이며, 특정 제품의 실제 구성이나 권장 구성을 뜻하지 않는다.

인터넷 없이 작동하는 범위도 같은 방식으로 판단할 수 있다. 음성을 로컬에서 인식해도 기기 제어가 제조사 클라우드에 의존하면 연결이 끊긴 상태에서 해당 작업을 수행하지 못할 수 있다. 반대로 기기 제어가 로컬이어도 외부 정보를 조회하는 요청은 인터넷이 필요할 수 있다.

처리 위치를 비교할 때는 연결 의존성, 지연, 지원 기능, 필요한 자원, 데이터 이동을 함께 살펴봐야 한다. 로컬이라는 단어만으로 모든 데이터가 저장되지 않는다거나 보안 문제가 없다고 결론 내릴 수는 없다. 보관·전송·접근 정책은 실제 구현과 서비스 정책에 따라 확인해야 한다.

09 / EVALUATION

음성 AI의 품질은 무엇으로 평가할까

음성 AI의 품질은 받아쓰기 정확도와 작업 수행 품질을 나눠 평가해야 한다. 단어 오류율(Word Error Rate, WER)은 기준 문장에 비해 대체·삭제·삽입된 단어 수를 기준 문장의 단어 수로 나눈 값이다. AWS의 음성 인식 설명도 이 정의와 함께 입력 조건에 따른 인식의 차이를 다룬다.[10]

하지만 단어 오류의 개수가 같아도 작업에 미치는 영향은 다를 수 있다. ‘거실’을 ‘침실’로 인식한 오류는 대상 기기를 바꾼다. 숫자나 부정 표현을 틀리면 설정값이나 실행 여부가 달라질 수 있다. 반면 표현이 달라도 요청의 의미가 유지되는 경우도 있다. 받아쓰기 점수만으로 기기 제어의 성공률을 대신할 수 없는 이유다.

아래 표는 음성 제어의 품질을 나눠 살펴보기 위한 평가 항목이다. 특정 서비스의 공식 종합 점수나 모든 시스템에 적용되는 합격 기준은 아니다. 실제 측정에서는 성공의 정의, 비교 조건, 실패의 분류를 먼저 정해야 한다.

시간을 측정할 때도 기준점을 통일해야 한다. 사용자가 말을 시작한 시점부터 재는지, 말을 마친 시점부터 재는지에 따라 같은 시스템의 수치가 달라진다. 첫 음성 응답이 접수 안내인지 실제 완료 안내인지도 구분해야 한다. 하나의 ‘응답 속도’ 수치로 모든 상호작용을 비교하면 빠른 안내와 빠른 실행을 혼동할 수 있다.

평가용 요청에는 명확한 문장뿐 아니라 자기 정정, 생략된 대상, 여러 기기, 오프라인 상태, 응답 유실 같은 조건도 포함할 수 있다. 같은 시나리오를 반복하면 우연히 성공한 사례와 일관되게 처리되는 동작을 구분하는 데 도움이 된다. 한국어 받아쓰기를 비교할 때는 띄어쓰기와 숫자 표기 등 전처리 기준도 일정하게 맞춰야 한다.

FAQ / 자주 묻는 질문

음성 AI 기기 제어에 관한 질문

음성 AI는 어떻게 기기를 제어하나요?

음성 요청을 동작·대상·입력값으로 구체화하고, 연결된 애플리케이션이 기기 기능을 호출한다. 이후 실행 응답이나 상태 정보를 바탕으로 확인된 결과를 사용자에게 전달한다. 구체적인 처리 구조는 서비스에 따라 다르다.

음성 인식이 정확하면 기기 제어도 정확한가요?

정확한 받아쓰기는 전체 과정의 일부다. 대상 연결, 입력값 검증, 실행, 결과 확인 중 어느 단계에서도 오류가 생길 수 있다. 인식 정확도와 실제 작업 성공을 따로 평가해야 한다.

모든 음성 AI가 먼저 음성을 문자로 바꾸나요?

문자 변환을 거쳐 요청을 처리하는 연쇄형과 음성을 직접 입출력하는 구조가 있다. 별도의 전사문이 모든 시스템의 필수 중간 입력인 것은 아니다.

함수 호출은 모델이 기기를 직접 움직인다는 뜻인가요?

대표적인 함수 호출 구조에서는 모델이 함수와 인자를 제안하고 애플리케이션이 실제 실행을 담당한다. 호출 정보 생성과 실행 성공은 별도로 확인해야 한다.

“취소해”라고 말하면 이미 실행한 작업이 되돌아가나요?

음성 응답 중단과 작업의 취소·되돌리기는 다르다. 작업이 어느 단계에 있는지와 연결 기능이 취소나 복원을 지원하는지에 따라 결과가 달라진다.

온디바이스 음성 AI는 인터넷 없이 모든 기능을 사용할 수 있나요?

전체 처리 경로에 따라 다르다. 음성 인식이 로컬이어도 기기 제어나 외부 정보 조회가 클라우드에 의존할 수 있다. 단계별 처리 위치와 연결 의존성을 확인해야 한다.

GLOSSARY / 용어집

본문의 주요 용어

자동 음성 인식(Automatic Speech Recognition, ASR)

입력된 소리에서 말의 내용을 인식해 문자로 표현하는 기술.

음성의 문자 변환(Speech-to-Text, STT)

음성을 문자로 바꾸는 기능을 가리키는 표현. 본문에서는 연쇄형 시스템의 입력 변환 단계에 사용한다.

문자의 음성 변환(Text-to-Speech, TTS)

문자로 작성된 응답을 재생할 수 있는 음성으로 만드는 기능.

음성 활동 감지(Voice Activity Detection, VAD)

입력된 오디오에 말소리 활동이 있는지 판단하는 기술.

발화 종료 판단(Turn Detection)

사용자의 말이 끝나 시스템이 다음 반응을 시작할 수 있는지 판단하는 과정.

전이중(Full-Duplex)

입력과 출력을 동시에 처리하는 특성. 음성 시스템에서는 동시에 듣고 말하는 동작과 관련된다.

의도(Intent)와 슬롯(Slot)

의도는 사용자가 원하는 동작이고, 슬롯은 동작에 필요한 대상·장소·수치 등의 변수.

함수 호출(Function Calling)

정의된 함수와 입력값을 모델이 선택·제안해 애플리케이션의 외부 기능에 연결하는 방식.

구조화 출력(Structured Output)

미리 정한 데이터 형식에 맞춰 출력하는 방식. 실제 기기의 존재나 실행 가능 여부는 별도로 검증해야 한다.

끼어들기(Barge-In)

시스템이 응답하는 동안 사용자가 새 발화를 시작하는 상황과 그 처리.

멱등성(Idempotency)

같은 작업을 반복해도 정의된 효과가 반복해서 추가되지 않는 성질. 재시도와 중복 실행을 다룰 때 중요하다.

온디바이스(On-Device)

해당 처리를 기기 내부에서 수행하는 방식. 시스템 전체의 처리 위치는 단계별로 확인해야 한다.

REFERENCES / 참고 자료

공식 문서와 관련 읽을거리

각 문서는 해당 서비스의 구조를 설명하는 1차 자료다. 사례의 세부 기능을 모든 음성 AI의 공통 기능으로 일반화하지 않는다. 취소·검증·평가에 관한 일부 설명은 문서의 구조를 연결한 기술적 해석이며, 본문의 표와 가상 사례는 이해를 돕기 위한 종합 설명이다.

1. OpenAI — Voice agents
   음성 에이전트의 구성 경로와 시스템 설계.
2. Google — Gemini Function calling
   함수 정의, 모델의 호출 제안, 애플리케이션 실행과 결과 전달.
3. Home Assistant — Voice overview
   음성 파이프라인·대화 처리·의도 실행의 역할.
4. Home Assistant — Assist pipelines
   호출과 음성 처리 단계 및 이벤트.
5. Home Assistant — Conversation API
   작업·조회·오류 응답과 성공·실패 대상.
6. OpenAI — Voice activity detection
   침묵 및 발화 내용을 고려하는 종료 판단.
7. OpenAI — Realtime conversations
   끼어들기, 응답 취소와 음성 재생 기록 처리.
8. AWS — Streaming and partial results
   부분 인식 결과의 수정과 안정화.
9. Home Assistant — Local voice assistant
   로컬 음성 처리 구성과 구성요소 선택.
10. AWS — Transcribe responsible AI service card
    단어 오류율과 음성 인식의 평가 조건.
11. Stripe — Idempotent requests
    멱등성 키를 통한 재시도와 중복 작업 방지의 API 사례.
12. Google Home — Report State
    기기 상태 보고와 조회, 상태 불일치.
13. Amazon Alexa — Voice interaction models
    의도·슬롯과 다양한 발화의 연결.
14. Google — Structured outputs
    정해진 데이터 형식의 출력.

함께 읽기: AG-UI란? AI Agent와 사용자 화면이 통신하는 원리와 구조 · AI 에이전트 샌드박스란? 실행 권한을 격리하는 보안 기술

자동차에 목적지를 설명하던 대화가 음악 재생과 온도 조절로 이어진다. 냉장고는 소프트웨어 업데이트로 더 다양한 식재료를 인식하고, 안경 제조사는 사용자가 바라보는 대상을 개인 AI 에이전트의 작업에 연결하겠다고 발표한다. 생성형 AI가 생활형 디바이스에 들어오는 방식이 제품별로 구체화되고 있다.

최근 발표의 변화는 ‘AI 탑재’라는 문구만으로는 잘 드러나지 않는다. 어떤 제품은 음성 대화의 문맥을 실제 기능 실행에 연결하고, 어떤 제품은 카메라로 확보한 정보를 활용한다. 또 어떤 회사는 이미 판매한 기기에 새로운 AI 기능을 배포하고 있다. 사용자가 AI 서비스를 따로 실행해 질문하는 방식에 더해, 평소 사용하는 제품에서 AI를 호출하는 접점이 늘어나는 상황이다.

특히 9월에는 삼성전자의 기존 가전 업데이트, Google의 새로운 실시간 음성 모델, Grok의 음성 인식 모델 개선, Meta의 AI 안경·개인 에이전트 연결 발표가 이어졌다. 앞서 자동차 업계가 공개한 자연어 기반 기능 실행 사례와 함께 보면, 무엇이 새로 추가되고 있으며 실제 사용 범위는 어디까지인지 구분할 수 있다.

기능 실행: Tesla Grok은 길 안내·전화·미디어·공조 등과 연결된다. BMW와 GM도 대화 맥락을 반영하는 차량 인터페이스를 도입하거나 배포 계획을 발표했다.

기존 제품의 확장: 삼성전자는 9월부터 일부 기존 냉장고와 세탁 가전에 Tizen 10.0 기반 업데이트를 순차 제공한다고 밝혔다.

착용형 AI: Meta는 Connect 2026에서 AI 안경에 개인 에이전트 Muse를 연결하는 계획과 새 안경 제품군을 공개했다.

음성 기술의 변화: 최근 모델 발표에서는 대화를 이어가며 도구를 호출하는 기능과 소음·다국어 환경의 음성 인식 개선이 함께 제시됐다.

01. Tesla Grok이 보여주는 변화는 ‘말투’보다 넓다

Tesla의 차량용 Grok은 운전자가 AI의 목소리와 성격(Personality)을 고를 수 있게 한다. 공식 문서에 등장하는 Storyteller와 Unhinged 같은 선택지는, 자동차의 음성 인터페이스가 정해진 안내문을 읽는 기능에만 머물지 않는다는 점을 보여준다. 이용자는 어떤 방식으로 대화할지도 선택한다.

그러나 이 사례의 중심은 독특한 말투만이 아니다. Tesla는 Grok의 지원 기능으로 내비게이션, 전화, 음악 검색·재생, 실내 온도 조절, 글로브박스 열기 등을 안내하고 있다. 질문에 답하는 AI와 차량의 소프트웨어 기능이 하나의 음성 접점에 연결돼 있다.

8월 19일 공개된 Grok Voice의 Tesla 적용 사례에서는 여러 경유지가 포함된 이동 요청을 소개한다. 운전자가 귀가 중 장을 보고 아이를 수영 연습 장소에 데려다주는 일정을 설명하면, Grok이 관련 장소와 주소를 찾고 경유지를 구성한다는 내용이다. 회사는 같은 인터페이스에서 공조나 미디어 기능도 이용할 수 있다고 설명한다.

사용자가 직접 장소 검색 결과를 확인하고 주소를 옮겨 적고 경유지를 추가하던 조작을 자연어 요청으로 연결하는 사례다. 여기에서 변화하는 것은 자동차의 주행 원리가 아니라 목적과 조건을 소프트웨어 기능에 전달하는 방식이다. 경유지 설정과 조향·가속·제동을 수행하는 자율주행은 별개의 기능이다.

실행 권한도 대화 설정에 따라 다르다. Tesla 매뉴얼은 차량 명령을 수행하려면 Assistant 성격을 선택해야 하며, 다른 성격은 일반 대화만 지원한다고 명시한다. 대화의 성향과 기기 조작 권한이 제품 설정에서 나뉘어 있는 것이다. 기존 음성 명령도 그대로 유지된다.

Grok은 현재 베타로 제공된다. 공식 지원 문서가 제시한 기본 요건은 AMD 프로세서, 차량 소프트웨어 2025.26 이상, Premium Connectivity 또는 Wi-Fi 연결이다. 실제 기능은 차량 구성과 시장에 따라 달라진다. 따라서 ‘차량에 AI가 들어간다’는 표현은 차량 내부에서 모든 AI 계산을 수행한다는 뜻과도 구별해야 한다.

근거: Tesla 지원 안내 · 차량 매뉴얼 · Grok Voice 차량 적용 사례

02. BMW·GM은 기존 차량으로, Mercedes-Benz·Volkswagen은 차량 내부 처리로

차량용 AI 도입은 회사마다 서로 다른 경로를 택하고 있다. 기존 음성비서를 생성형 AI로 확장하는 사례, 이미 판매한 차량에 업데이트하는 사례, 차량 내부에서 AI를 실행하기 위한 설계를 마련하는 사례가 함께 등장한다. 같은 ‘차량용 AI’라도 적용 대상과 계산 위치가 다르다.

BMW: 목적지와 조건을 대화로 전달

BMW는 Amazon Alexa+의 일부 기능을 BMW 지능형 개인 비서(BMW Intelligent Personal Assistant)에 통합했다. 공식 설명에 따르면 이용자가 이동 계획을 자유롭게 말하고 필요한 배경을 덧붙이면, 시스템이 원하는 목적지를 내비게이션에 전달한다. 여러 정류장을 포함한 경로도 자연어로 구성할 수 있다.

BMW는 5월 말부터 기존 iX3 차량에 소프트웨어 업데이트로 해당 기능을 도입했다고 밝혔다. 하반기에는 BMW Operating System 9와 X를 사용하는 추가 모델에 순차 확대하는 계획이다. 초기 시장은 독일과 미국이며 영어·독일어 버전을 소개했다. 신차 발표에만 포함되는 기능이 아니라 지원되는 기존 차량의 인터페이스도 바꾸는 업데이트라는 점이 구체적인 변화다.

GM: 약 400만 대를 Gemini 업데이트 대상으로 제시

GM이 4월 28일 발표한 대상은 Google built-in을 지원하는 2022년형 이후 Cadillac·Chevrolet·Buick·GMC 차량이다. 회사는 미국 약 400만 대가 업데이트 대상이라고 밝혔다. 이는 설치 완료 대수가 아니라 적용 가능한 차량의 규모이며, 배포는 여러 달에 걸쳐 진행하도록 안내했다.

GM이 제시한 예시에서는 가까운 카페를 찾으면서 가족에게 늦는다는 메시지를 보내고, 이어서 야외 좌석이 있는 카페로 조건을 바꾸는 요청이 등장한다. 음악 재생으로 화제를 바꾸는 대화도 같은 흐름에서 처리한다. 메시지 요약·수정·번역도 포함된다. 핵심은 명령의 개수보다 직전 요청의 대상을 유지하면서 조건을 수정할 수 있다는 점이다.

GM은 이 Gemini 업데이트와 자사 차량 데이터를 활용하는 더 깊은 통합형 AI 비서 계획을 따로 설명한다. Gemini가 들어간다는 사실만으로 차량의 모든 데이터와 제어 기능에 곧바로 접근하는 것은 아니다. 발표에 명시된 초기 조건에는 OnStar 연결, Google Play 로그인, 미국 영어 설정과 이용 동의가 포함된다.

Mercedes-Benz·Volkswagen: AI를 어디에서 실행할 것인가

Mercedes-Benz는 4월 23일 Liquid AI와의 협력을 발표하면서, 북미의 3·4세대 MBUX 탑재 모델을 대상으로 음성·언어 이해·추론의 주요 기능을 차량 내부에 넣는 방향을 제시했다. 기기 자체에서 처리하는 온디바이스 AI(On-device AI)를 통해 지연을 줄이고 지속적인 클라우드 데이터 교환에 대한 의존을 낮추겠다는 설명이다. 첫 양산 적용 목표는 하반기로 제시됐으며, 기존 클라우드 기반 모델을 보완하는 접근이다.

Volkswagen은 중국 시장용 전자 아키텍처인 CEA 기반 차량에 차내 대규모 언어 모델(LLM)을 사용하는 AI 에이전트를 도입하는 로드맵을 발표했다. 회사는 사용자의 의도를 해석해 여러 시스템에 걸친 작업을 실행하는 구조라고 설명한다. 2027년 CEA 2.0에는 운전·실내 경험·외부 서비스를 담당하는 에이전트를 조정하는 멀티 에이전트(Multi-Agent) 구조를 계획했다.

이들 발표는 대화 모델의 이름을 고르는 문제에 더해, 기존 차량에 어떻게 배포할지, 클라우드와 차내 처리를 어떻게 나눌지, 여러 기능을 어떤 소프트웨어 구조로 연결할지를 다룬다. 다만 Mercedes-Benz의 양산 목표와 Volkswagen의 차세대 구조는 발표된 계획으로, 그 일정 자체가 실제 배포 완료를 증명하지는 않는다.

근거: BMW · GM · Mercedes-Benz · Volkswagen 공식 발표

03. 삼성전자, 이미 판매한 냉장고와 세탁 가전의 AI 기능 확대

삼성전자는 9월 7일 일부 기존 냉장고와 세탁 가전에 Tizen 10.0 기반 업데이트를 순차 제공한다고 발표했다. 신제품을 구매하지 않아도 지원되는 하드웨어에서 새로운 기능을 받는 방식이다.

Google Gemini 기반 AI Vision의 대상은 카메라와 AI Vision을 갖춘 2021~2025년형 21.5·32인치 Family Hub와 일부 2025년형 9인치 냉장고다. 회사는 브랜드·지역별 포장식품을 포함해 식품 인식 범위를 넓힌다고 설명했다.

세탁 가전에서는 일부 2024·2025년형 세탁건조기·세탁기·건조기에 최신 Bixby 경험과 화면 개선을 제공한다. 완료 시점을 물으면 남은 시간을 문장으로 알려주는 대화가 예시로 제시됐다. 배포 시점과 기능은 국가·모델별로 다르다.

냉장고의 시각 인식과 세탁기의 상태 안내는 서로 다른 기능이다. 이번 발표는 모든 가전이 같은 생성형 모델로 움직인다는 의미보다, 기존 제품의 인식·대화 기능을 업데이트로 확장하는 구체적인 사례로 읽을 수 있다.

근거: 삼성전자 기존 가전 AI 소프트웨어 업데이트 발표

04. 스마트홈은 개별 기기 제어에서 생활 맥락의 연결로

여러 가전을 함께 사용하는 환경에서는 요청의 대상이 하나의 제품에 그치지 않는다. Google이 소개한 Gemini for Home의 활용 예시에는 조명을 어둡게 하면서 온도를 조절하는 요청, 침실을 제외한 집 안의 조명을 끄는 요청이 포함된다. 기기 이름을 하나씩 나열하는 대신 대상의 범위와 예외를 문장으로 설명하는 방식이다.

이 서비스는 지난해 발표된 뒤 지원 국가·언어의 스피커와 디스플레이를 대상으로 조기 이용 배포가 시작됐다. 현재 지원 문서는 해당 가정에 이용 가능 안내가 도착하면 전환할 수 있다고 설명한다. 기본 음성비서 기능과 Gemini Live 등 구독이 필요한 고급 기능은 제공 범위가 다르다. 따라서 최초 발표를 이번 달의 신제품 소식으로 볼 수는 없지만, 최근의 AI 홈 발표와 비교할 수 있는 실제 서비스 사례다.

LG전자가 IFA 2026에서 공개한 ThinQ Claw는 생활의 맥락을 더 직접적으로 다룬다. LG는 이를 문자 대화 기반 AI 에이전트 경험으로 소개했다. 사용자의 일정, 생활 패턴, 집 안 환경과 가전 사용 정보를 토대로 필요한 행동을 제안하고 관련 기기와 서비스를 연결하는 구조다.

LG가 제시한 사례에는 손님을 맞이할 때 조리기기를 관리하는 일, 귀가 전 실내 공기질과 온도를 확인하는 일이 있다. 캘린더 같은 생활 서비스와의 연계도 포함된다. 복잡한 자동화 규칙을 직접 작성하는 대신 계획이나 현재 상황을 대화로 전달하도록 설계했다는 설명이다. ThinQ Claw의 공개 범위는 IFA 전시·시연이며, 발표문은 전체 가전의 상용 배포 완료를 뜻하지 않는다.

두 사례가 다루는 차이는 요청의 범위에서 드러난다. 특정 방의 조명을 끄는 일은 기기 선택과 제어가 중심이다. 일정과 귀가 상황을 반영하는 일에는 기기 밖의 정보까지 연결된다. 대화 기능의 확장이 곧 연결 가능한 기기와 서비스의 확장 문제로 이어지고 있는 것이다.

근거: Gemini for Home 발표 · Google 현재 이용 안내 · LG IFA 2026 발표

05. Meta Connect의 새 발표: 안경에서 개인 에이전트를 부른다

9월 23일 열린 Meta Connect 2026에서는 자동차·가전과 다른 형태의 생활형 AI 접점이 제시됐다. Meta는 개인 AI 에이전트 Muse를 향후 수개월에 걸쳐 AI 안경에 연결하겠다고 발표했다. 안경을 통해 에이전트를 호출하고, 카메라로 보고 있는 대상을 작업의 맥락으로 전달하는 방향이다.

Meta가 제시한 예시에는 매장 진열대의 제품, 벽에 붙은 안내문, 학교 준비물 목록을 보며 에이전트에게 일을 요청하는 상황이 포함된다. 사용자가 눈앞의 내용을 길게 설명하거나 별도로 타이핑하는 과정을 줄이려는 구성이다. 회사는 대화를 이어가는 동안 에이전트가 백그라운드에서 작업하는 음성 모드도 소개했다.

외부 서비스를 연결하는 커넥터(Connector) 확대도 함께 발표했다. 쇼핑·결제·일상 업무 서비스를 에이전트가 이용할 수 있도록 연결하는 내용이다. 안경이 정보를 받아들이는 창구가 되고, 연결된 서비스가 작업을 수행하는 통로가 되는 구조다. 다만 이는 공개된 제품 방향과 제공 계획이며, 발표 시점에 안경에서 Muse의 모든 작업을 사용할 수 있다는 뜻은 아니다.

같은 행사에서 공개된 하드웨어도 이 접근을 보여준다. Ray-Ban Meta Audio는 음성 중심 모델로, 회사가 제시한 무게는 43g이다. 음악·통화·AI 대화를 지원하며 최대 12시간의 배터리 사용 시간을 안내했다. 미국 기준 349달러부터 사전 주문을 받고 10월 13일 배송 예정이라고 밝혔다.

카메라가 포함된 Ray-Ban Meta Gen 3에는 AI에 바로 접근하는 사용자 지정 액션 버튼이 추가됐다. Meta는 최대 9시간의 배터리, 6개 마이크, 12MP 카메라 등을 소개했고 미국 기준 449달러부터 판매한다고 발표했다. 이 수치는 제조사 발표 기준이다. 음성 중심 모델과 카메라 모델을 나누어 보면, 같은 ‘AI 안경’이라도 입력 수단과 가능한 활용이 다르다는 점을 알 수 있다.

안경 제품의 판매와 Muse 연결 일정 역시 별개다. 새로운 하드웨어를 구매할 수 있다는 사실이 발표된 모든 에이전트 기능의 즉시 이용을 뜻하지는 않는다. 이번 소식의 핵심은 스마트 안경이 통화·촬영 기기를 넘어 개인 에이전트에 접근하는 제품으로 확장되도록 설계되고 있다는 데 있다.

근거: Meta Connect 2026 주요 발표 · Ray-Ban Meta 새 제품군 발표

06. 스마트폰도 ‘AI 앱을 실행하는 기기’에서 역할을 넓힌다

스마트폰 역시 별도의 채팅 앱을 실행하는 통로에만 머무르지 않는다. Google은 9월 Android 업데이트 발표에서 Gemini와 Find Hub를 연결해 물건의 보관 위치를 기록하는 기능을 예고했다. 추적 태그를 붙이지 않은 여권이나 여분 열쇠도 어디에 두었는지 말하고 사진을 덧붙인 뒤, 나중에 질문하거나 목록에서 확인하는 방식이다.

이 기능은 물건이 움직인 위치를 자동 추적하는 기능과 다르다. 사용자가 알려준 보관 정보를 저장하고 다시 찾는 구성이다. 발표에서 제시한 대상은 Gemini와 Find Hub가 지원되는 국가의 Android 16 이상 기기이며, 출시 예정으로 안내됐다. 음성 요청이 답변 생성뿐 아니라 기기의 다른 서비스에 정보를 기록하는 동작으로 이어지는 사례다.

같은 발표의 Guided vision은 스마트폰 카메라를 Gemini Live와 연결한다. 시각장애·저시력 이용자를 고려해 식품 라벨의 작은 글씨, 어두운 곳의 메뉴, 집 안 물건 등을 설명하고, 카메라 방향이 맞지 않으면 다시 비추도록 음성으로 안내하는 기능이다. Google은 Android 9 이상과 지원 국가를 대상으로 제공을 예고했다.

기기의 설정을 자연어로 조작하는 사례도 있다. 삼성전자가 올해 2월 소개한 One UI 8.5의 새 Bixby는 이용자가 화면을 보고 있는 동안 꺼지지 않게 해 달라는 요구를 말하면 관련 설정을 켜는 식으로 동작한다. 정확한 메뉴 이름을 모르더라도 원하는 결과를 설명해 기능에 접근하도록 한 것이다.

최근 Android 발표와 앞선 Bixby 사례는 AI가 기기에서 맡는 서로 다른 역할을 보여준다. 보관 정보를 다른 서비스에 기록하는 역할, 카메라가 포착한 대상을 설명하는 역할, 기기 설정을 찾아 실행하는 역할이다. 이를 모두 ‘대화가 자연스러워졌다’는 말로 묶으면 실제로 추가된 기능의 차이를 놓치게 된다.

근거: Google 9월 Android 업데이트 · 삼성전자 Bixby 발표

07. 최근 음성 AI의 개선점: 대화 중 실행, 소음 속 인식, 시각적 맥락

제품의 변화와 함께 그 기반이 되는 음성 모델의 발표도 이어지고 있다. 최신 발표에서 확인할 수 있는 개선 대상은 단순히 더 자연스러운 목소리만이 아니다. 작업을 수행하는 동안 대화가 끊기지 않게 하는 기능, 짧고 시끄러운 발화를 정확히 받아들이는 기능, 사용자가 보고 있는 장면을 대화에 반영하는 기능이 함께 제시된다.

Grok Voice: 말하는 동안 추론하고 도구 호출

7월 29일 발표된 Grok Voice Think Fast 2.0은 음성을 출력하면서 추론을 병렬로 수행한다고 설명한다. 개발사는 추론 효율을 높여 실제 운영 환경에서 도구 호출이 대개 첫 문장이 끝나기 전에 이루어지도록 했다고 밝혔다. 사용자가 작업 결과를 기다리는 동안 길게 침묵하는 상황을 줄이려는 설계다.

대화 방식에 대한 학습도 공개했다. 짧은 문장을 사용하고 한 번에 하나씩 질문하며 불필요한 말을 줄이는 방향으로 강화학습을 적용했다는 내용이다. 차량이나 착용형 기기처럼 화면을 계속 보지 않는 환경에서는 무엇을 실행하는지 음성으로 전달하는 방식 자체가 제품 사용 경험에 포함된다.

9월의 음성 인식 업데이트: 짧은 명령과 생활 소음

9월 18일 공개된 Grok Voice Transcribe 2.0은 음성을 문자로 변환하는 모델이다. 개발사는 소음과 여러 언어가 섞인 실제 환경의 데이터를 활용했으며, 전화 음성·일반 대화·계정 정보·짧은 다국어 명령을 나눈 내부 평가를 공개했다.

발표에서 특히 구체적인 수치는 짧은 발화 평가의 단어 오류율이 20.6%에서 6.8%로 낮아졌다는 결과다. 차량 명령처럼 문장이 짧으면 언어를 식별할 문맥도 적다는 설명이 함께 제시됐다. 이는 개발사의 해당 평가 세트 결과이며 모든 차량과 소음 환경의 실사용 오류율을 뜻하지 않는다.

발화 종료 감지, 화자 구분, 제품명 같은 특정 용어 인식 보정도 지원 기능으로 소개됐다. 음성 에이전트가 언제 사용자의 말을 받아들이고 언제 답변을 시작할지 판단하는 데 필요한 요소들이다. 다만 음성 인식 모델의 공개와 Tesla 개별 차량에 적용되는 소프트웨어 버전은 별도로 확인해야 한다.

Google: 시각 정보를 반영하며 대화를 이어가는 모델

Google은 9월 16일 한국어 공식 발표를 통해 Gemini 3.8 Live와 Gemini 3.8 Live Extended Thinking을 소개했다. 3.8 Live에는 시각적 맥락 이해와 97개 언어의 자동 감지·전환을, Extended Thinking에는 더 복잡한 다단계 작업을 위한 추론을 주요 특징으로 제시했다.

회사 설명에 따르면 모델은 대화를 이어가면서 백그라운드에서 도구와 API를 호출한다. 더 복잡한 작업에서는 추론과 발화를 동시에 수행하며 진행 상황을 말로 전달한다. 여기서 도구 사용(Tool Use)은 검색·조회·외부 서비스 실행처럼 모델 바깥의 기능을 이용하는 것을 뜻한다.

이 발표는 개발자용 API와 Google 자체 서비스의 제공 경로를 설명하는 자료다. 같은 Gemini 이름을 사용하는 GM 차량이나 Gemini for Home에 새 모델이 동시에 적용됐다고 추정할 수는 없다. 모델의 기능 공개와 완성품의 기능 배포를 구분하면서도, 최근 음성 AI가 어떤 문제를 개선하고 있는지는 확인할 수 있다.

근거: Grok Voice Think Fast 2.0 · Grok Voice Transcribe 2.0 · Gemini 3.8 Live 공식 발표

08. 최근 발표에서 확인되는 세 가지 사용 경험의 변화

서로 다른 제품의 발표를 비교하면, 현재 추가되고 있는 기능은 세 가지 측면에서 정리할 수 있다. 이는 업계가 합의한 세대 구분이 아니라 앞선 공식 사례들을 읽기 위한 분류다.

첫째, 기능의 이름 대신 원하는 상황을 설명하는 요청이 늘어난다. BMW의 복합 이동 계획, Google Home의 예외를 포함한 조명 제어, Bixby의 화면 설정 사례가 여기에 해당한다. 이용자가 모든 메뉴 경로를 알지 못해도 지원되는 기능에 도달할 수 있도록 만든다. 다만 기존 음성비서에도 자연어 처리는 있었으므로, 자연어 자체의 발명보다 처리할 수 있는 문맥과 작업 범위의 확장으로 보는 것이 정확하다.

둘째, 기기가 확보한 정보가 AI 요청의 일부가 된다. 삼성 냉장고에서는 내부 영상이 식품 인식의 입력이 되고, Google Guided vision에서는 스마트폰 카메라가 주변 대상을 전달한다. Meta가 발표한 Muse의 안경 연결도 보는 대상과 작업 요청을 결합한다. 사용자가 모든 내용을 문자나 말로 다시 설명하지 않아도 되도록 제품의 센서를 활용하는 사례들이다.

셋째, 한 제품의 기능을 넘어 다른 서비스와 작업이 이어진다. GM의 목적지·메시지 요청, LG의 일정·가전 연계 시연, Gemini와 Find Hub의 정보 기록, Meta의 커넥터 확대가 해당한다. 제품에 대화 창을 붙이는 것에 더해, AI가 어떤 정보를 받고 어떤 소프트웨어 기능까지 호출할 수 있는지가 구체적인 서비스 범위를 결정한다.

한편 제품의 제공 형태는 균일하지 않다. 삼성은 지원되는 기존 가전의 순차 업데이트를 발표했고, LG는 전시 시연을 공개했으며, Meta는 판매하는 하드웨어와 이후 연결할 에이전트 기능을 함께 발표했다. 다음 표는 최근 소식과 이를 이해하기 위한 앞선 발표를 나누어 정리한 것이다.

09. 지금 확인되는 것은 ‘인터페이스의 소멸’이 아니라 사용 경로의 확장

생활형 디바이스의 생성형 AI를 모두 같은 수준의 자율적 에이전트로 부르는 것은 정확하지 않다. 식품을 인식하는 모델, 대화형 음성비서, 외부 도구를 사용하는 에이전트, 차량 내부 추론 모델은 맡는 일이 다르다. 최신 발표를 읽을 때에는 AI라는 이름보다 실제 입력과 실행 기능을 보는 편이 제품의 변화를 구체적으로 설명한다.

현재 자료가 보여주는 것은 버튼과 화면이 일괄적으로 없어졌다는 상황도 아니다. Tesla는 기존 음성 명령을 유지하고, 삼성의 가전 업데이트에는 화면 인터페이스 개선도 함께 포함된다. AI 대화와 기존 조작 수단이 병행되면서, 사용자가 목적을 전달할 수 있는 방법이 늘어나고 있다.

사용자의 정보가 처리되는 방식도 제품마다 다르다. Tesla는 Grok에 네트워크 연결이 필요하다고 안내하는 한편, 전화 기능에 사용하는 연락처를 Grok 개발사로 보내지 않는다고 설명한다. Mercedes-Benz와 Volkswagen은 차량 내부 처리에 초점을 둔 설계를 발표했다. ‘AI 탑재’ 하나로 동일한 데이터 흐름을 가정할 수 없는 이유다.

최근 소식들을 연결하는 공통점은 분명하다. AI가 답변을 보여주는 창구에 더해, 사용자의 말·기기 상태·카메라 입력을 받아 지원되는 작업과 연결하는 제품 인터페이스로 적용되고 있다. 구체적인 변화는 이미 일부 제품의 기능과 업데이트에서 확인되며, 다른 일부는 전시 시연과 출시 계획의 형태로 제시돼 있다.

종합 근거: Tesla의 연결·데이터 처리 안내 · 기존 조작 수단 유지 · 차내 AI 처리 설계 · 가전 기능·화면 업데이트

용어집

공식 출처

최근 발표는 뉴스의 중심 자료로, 앞선 발표와 현재 지원 문서는 적용 배경과 이용 범위를 확인하는 자료로 사용했다. 제조사의 기능·성능 설명과 시연은 독립적인 실사용 검증 결과와 구분했다.

1. Tesla — Grok 지원 안내 · 현재 기능·요건·데이터 처리 안내.
2. Tesla — Model Y Owner’s Manual: Grok (Beta) · 성격별 차량 명령 지원·기존 음성 명령 유지.
3. Grok 개발사 — How Tesla enables drivers to control the car with Grok Voice · 2026년 8월 19일.
4. BMW Group — Milestone in in-car speech interaction thanks to AI integration · 최초 2026년 1월 5일 표기, 현재 본문에 5월 말 도입·하반기 확대 안내 포함.
5. General Motors — GM brings Google Gemini to millions of vehicles on the road · 2026년 4월 28일.
6. Mercedes-Benz — Next Generation in-car intelligence · 2026년 4월 23일.
7. Volkswagen Group — Auto China 2026: Agentic AI Roadmap for China · 2026년 4월 21일.
8. 삼성전자 — Refrigerators and Laundry Appliances: AI-Focused Software Updates · 2026년 9월 7일.
9. Google — Gemini for Home: Your household’s new, more helpful assistant · 2025년 8월 20일. 기존 서비스의 기능 배경.
10. Google — Gemini for Home 음성비서 제공 범위 · 기능 이용 안내.
11. LG — LG Electronics Unveils the Next Evolution of AI Home at IFA 2026 · 본문 발표 2026년 8월 31일, 게시일 9월 1일.
12. Meta — The Biggest News From Connect 2026 · 9월 23일 행사, 2026년 9월 24일 게시.
13. Meta — Introducing Ray-Ban Meta Audio and More AI Glasses Styles · 2026년 9월 23일.
14. Google — September Android Drop · 2026년 9월 1일.
15. 삼성전자 — Samsung Introduces the New Bixby in One UI 8.5 · 2026년 2월 20일. 기기 설정 연동의 배경 사례.
16. Grok 개발사 — Introducing Grok Voice Think Fast 2.0 · 2026년 7월 29일.
17. Grok 개발사 — Introducing Grok Voice Transcribe 2.0 · 2026년 9월 18일.
18. Google — Gemini 3.8 Live 및 Extended Thinking 소개 · 한국어 공식 발표 2026년 9월 16일.

브라우저 호환성(Browser Compatibility)은 모든 브라우저에서 화면을 픽셀 단위로 똑같이 만드는 문제가 아니다. 웹 표준으로 정의된 기능이 각 브라우저에 실제로 구현되는 시점과 범위가 다르기 때문에, 프로젝트가 지원할 환경을 정하고 기능 지원 여부를 판단한 뒤 핵심 기능이 유지되도록 설계하고 실제 브라우저에서 반복 검증하는 과정이다.

브라우저 호환성은 ‘지원 상태 확인 → 지원 범위 정의 → 기능 탐지 → 대체·향상 설계 → 실제 환경 테스트 → 변경 후 재검증’으로 이어지는 연속적인 관리 과정이다. Baseline은 웹 플랫폼 기능의 공통 지원 상태를 보여주지만 개별 사이트의 지원 정책이나 실제 동작을 보장하지 않는다. 따라서 호환성 정보와 프로젝트 정책, 런타임 대응, 테스트를 서로 다른 층위로 구분해야 한다.

1. 브라우저 호환성이란 무엇인가
2. 웹 표준과 브라우저 구현은 왜 다른가
3. Baseline으로 지원 상태 판단하기
4. Target Browsers로 지원 범위 정의하기
5. Feature Detection으로 실행환경 확인하기
6. Progressive Enhancement로 핵심 기능 유지하기
7. Cross-browser Testing과 Regression Testing
8. Web Platform Tests가 검증하는 것

01. 브라우저 호환성이란 무엇인가

호환성 테스트(Compatibility Testing)는 웹 애플리케이션이 서로 다른 브라우저·운영체제·기기에서 의도한 기능을 수행하는지 확인하는 작업이다. 여기서 중요한 것은 ‘모든 환경에서 완전히 동일한 시각 결과’를 목표로 삼는 것이 아니라, 정해진 지원 환경에서 사용자가 필요한 콘텐츠와 기능을 이용할 수 있는지를 검증하는 것이다.

실제 웹사이트는 브라우저 하나만을 대상으로 실행되지 않는다. 같은 HTML·CSS·JavaScript라도 브라우저 엔진, 버전, 운영체제, 입력 장치, 화면 크기와 기능 지원 수준의 조합에 따라 결과가 달라질 수 있다. 따라서 호환성은 코드의 단일 속성이 아니라 웹사이트와 실행환경의 조합에서 확인해야 하는 상태에 가깝다.

02. 웹 표준과 브라우저 구현은 왜 다른가

웹 표준(Web Standard)은 브라우저와 각종 웹 소프트웨어가 구현할 기술의 공통 규칙을 정의한다. W3C는 웹 표준을 브라우저·검색엔진·저작 도구 등에서 구현되는 웹의 구성 요소로 설명하며, 상호운용성(Interoperability)을 중요한 목표로 둔다.^[1]

그러나 명세가 존재한다고 해서 모든 브라우저가 같은 시점에 해당 기능을 제공하는 것은 아니다. 표준화 상태, 엔진별 개발 일정, 플랫폼 제약, 구현상의 버그와 상호운용성 문제 때문에 실제 지원 시점에는 차이가 생길 수 있다. CSS의 경우에도 W3C의 CSS Snapshot은 명세의 안정성과 현재 CSS의 상태를 정리하는 문서이며, 브라우저 채택률 자체를 나타내는 목록은 아니다.^[2]

03. Baseline으로 지원 상태 판단하기

Baseline은 API, CSS 속성, JavaScript 문법 등 웹 플랫폼 기능이 주요 브라우저에서 어느 정도 사용할 수 있는지를 공통 기준으로 요약한다. 현재 Baseline은 Safari(iOS·macOS), Chrome(Android·desktop), Edge(desktop), Firefox(Android·desktop)를 핵심 브라우저 집합으로 사용한다.^[3]

Baseline의 장점은 복잡한 버전표를 매번 읽지 않고도 기능의 전반적인 지원 수준을 빠르게 판단할 수 있다는 데 있다. 하지만 Baseline 자체가 프로젝트의 ‘지원 브라우저 목록’은 아니다. MDN은 Baseline이 브라우저 지원의 요약이며 접근성·사용성·성능·보안 테스트를 대체하지 않고, 오래된 기기와 브라우저, 운영체제 WebView, 스크린리더 같은 보조기술의 동작까지 보장하지 않는다고 설명한다.^[3]

04. Target Browsers로 지원 범위 정의하기

모든 브라우저와 모든 과거 버전, 모든 기기 조합을 동일한 수준으로 테스트하는 것은 현실적으로 어렵다. MDN의 테스트 전략도 모든 조합을 검사하기보다 목표 사용자가 실제로 사용하는 중요한 브라우저와 기기를 식별해 테스트 범위를 구성하는 방식을 설명한다.^[4]

대상 브라우저(Target Browsers)는 프로젝트가 공식적으로 지원하기로 정한 브라우저·버전 범위다. 이를 코드 도구와 공유하는 대표적인 설정 체계가 Browserslist다. Browserslist는 Babel, Autoprefixer, PostCSS 계열 도구 등에서 공통으로 사용할 대상 브라우저 설정을 제공하며, last 2 versions, 사용률 조건, 지역별 통계, 프로젝트 자체 사용 통계와 같은 쿼리를 지원한다.^[5]

# 개념 예시 — 실제 프로젝트 정책은 사용자 통계와 요구사항에 따라 결정
> 0.5%
last 2 versions
Firefox ESR
not dead

따라서 Baseline과 Browserslist는 역할이 다르다. Baseline은 웹 플랫폼 기능의 공통 지원 상태를 설명하고, Target Browsers는 개별 프로젝트가 책임질 지원 범위를 정의한다. 둘을 혼동하면 “Baseline이므로 무조건 사용 가능하다”거나 “특정 브라우저가 목록에 없으니 웹 표준과 무관하다”는 잘못된 판단으로 이어질 수 있다.

05. Feature Detection으로 실행환경 확인하기

기능 탐지(Feature Detection)는 현재 브라우저가 필요한 기능을 실제로 지원하는지 실행 시점에 확인하고, 결과에 따라 다른 코드를 적용하는 방식이다. MDN은 이를 특정 브라우저 이름을 판별하는 브라우저 스니핑(Browser Sniffing)과 구분하며, 기능 지원 여부를 직접 검사하는 방식을 권장한다.^[6]

JavaScript API는 객체나 메서드의 존재 여부를 확인할 수 있고, CSS는 @supports 또는 CSS.supports()를 이용해 특정 속성·값 조합을 브라우저가 지원하는지 조건부로 판단할 수 있다.

/* CSS 기능 탐지 예시 */
@supports (grid-template-columns: subgrid) {
  .layout {
    grid-template-columns: subgrid;
  }
}

/* JavaScript API 존재 여부 확인 예시 */
if ("geolocation" in navigator) {
  // 지원되는 환경에서만 관련 기능 실행
}

Feature Detection도 만능은 아니다. 특정 선언이나 API 진입점이 존재한다는 사실은 그 기능이 모든 세부 조건에서 버그 없이 동작한다는 보증이 아니다. 따라서 기능 탐지는 런타임 분기의 도구이고, 실제 사용자 흐름의 정상 동작 여부는 별도의 브라우저 테스트에서 확인해야 한다.

06. Progressive Enhancement로 핵심 기능 유지하기

점진적 향상(Progressive Enhancement)은 가능한 많은 사용자에게 필수 콘텐츠와 기본 기능을 먼저 제공하고, 더 현대적인 기능을 실행할 수 있는 환경에서는 경험을 추가로 향상시키는 설계 철학이다. MDN은 오래된 브라우저나 기능이 제한된 기기에서도 단순하지만 사용할 수 있는 경험을 제공하고, 더 풍부한 기능을 지원하는 환경에서는 더 나은 경험으로 확장하는 접근으로 설명한다.^[7]

예를 들어 기본 폼 제출이 HTML만으로 가능하게 설계되어 있다면, JavaScript를 사용할 수 있는 환경에서는 실시간 검증이나 비동기 제출 같은 기능을 추가할 수 있다. 핵심은 최신 기능을 피하는 것이 아니라, 최신 기능이 없는 환경에서도 서비스의 본질적인 작업이 가능한 구조를 만드는 데 있다.

이 접근은 Feature Detection과 연결된다. Feature Detection이 “현재 환경에서 무엇을 사용할 수 있는가”를 판단한다면, Progressive Enhancement는 “지원 수준이 달라도 어떤 경험을 제공할 것인가”를 설계한다.

07. Cross-browser Testing과 Regression Testing

크로스 브라우저 테스트(Cross-browser Testing)는 정해진 대상 브라우저와 기기에서 사이트의 실제 동작을 확인하는 단계다. 여기서는 단순히 페이지가 열리는지만 보는 것이 아니라 레이아웃, 탐색, 입력, 폼 전송, 로그인, 모달, 미디어, 반응형 동작처럼 실제 사용자 작업이 정상적으로 수행되는지를 확인해야 한다.

MDN은 모든 브라우저·기기 조합을 테스트할 수 없으므로 목표 사용자에게 중요한 환경을 선택하고, 실제 기기·가상환경·자동화 도구 등을 조합하는 전략을 설명한다. 반복적인 검증은 Selenium/WebDriver나 Playwright 같은 자동화 도구, 원격 브라우저 테스트 서비스 등을 통해 일부 자동화할 수 있다.^[4][8]

회귀 테스트(Regression Testing)는 코드나 실행환경이 변경된 뒤 기존에 정상 작동하던 기능이 계속 정상인지 다시 확인하는 검증이다. 브라우저 호환성 문제를 수정한 뒤에도 다른 브라우저나 다른 페이지가 깨질 수 있으므로, 수정한 지점만 확인하지 않고 기존 핵심 기능을 다시 검사해야 한다. MDN 역시 브라우저 문제를 수정한 뒤 테스트 과정을 반복해 다른 위치나 다른 브라우저가 손상되지 않았는지 확인할 것을 설명한다.^[9]

08. Web Platform Tests가 검증하는 것

웹사이트 개발자가 수행하는 크로스 브라우저 테스트보다 한 단계 아래에는 브라우저 구현 자체의 상호운용성을 검증하는 체계가 있다. Web Platform Tests(WPT)는 웹 플랫폼 스택을 위한 크로스 브라우저 테스트 스위트로, 동일한 테스트를 여러 브라우저 구현에서 실행할 수 있도록 구성된다. 이를 통해 브라우저 프로젝트는 다른 구현과 호환되는 동작을 제공하는지 검증할 수 있다.^[10]

WPT에는 API 동작만 확인하는 테스트뿐 아니라 렌더링 결과를 기준 페이지와 비교하는 Reftest, 플랫폼별 기대 렌더링과 비교하는 Visual Test, 문서를 로드했을 때 브라우저가 충돌하지 않는지 확인하는 Crashtest, WebDriver 프로토콜을 검증하는 wdspec 테스트 등이 포함된다.^[11]

이 구분은 중요하다. WPT 결과가 좋다고 특정 쇼핑몰의 결제 과정이나 기업 홈페이지의 메뉴가 자동으로 검증되는 것은 아니다. 반대로 개별 사이트가 Chrome에서 잘 작동한다고 브라우저 엔진 전체의 표준 준수가 입증되는 것도 아니다. 브라우저 구현의 상호운용성 검증과 개별 사이트의 품질 검증은 서로 연결되지만 다른 테스트 층위다.

Baseline은 웹 기능의 공통 지원 상태, Browserslist는 프로젝트의 대상 브라우저 설정, Feature Detection은 실행환경의 기능 지원 확인, Progressive Enhancement는 지원 수준에 따른 경험 설계, WPT는 브라우저 구현 간 상호운용성 검증을 담당한다. 서로 비슷해 보이지만 각각 다른 층위의 문제를 해결한다.

1. W3C, Web Standards.
2. W3C CSS Working Group, CSS Snapshot 2026.
3. MDN Web Docs, Baseline (compatibility).
4. MDN Web Docs, Strategies for carrying out testing.
5. Browserslist, Browserslist README.
6. MDN Web Docs, Implementing feature detection.
7. MDN Web Docs, Progressive enhancement.
8. MDN Web Docs, Introduction to automated testing.
9. MDN Web Docs, Introduction to cross-browser testing.
10. web-platform-tests, web-platform-tests documentation.
11. web-platform-tests, Writing Tests.