GCPW란 무엇인가 - Windows 로그온을 Google 인증으로 처리하는 방법

Windows 단말의 로그온을 Google 중심으로 정리하고 싶다는 상담에서는, 상당히 높은 빈도로 이런 이야기들이 한꺼번에 뒤섞입니다.

• GCPW는 「Google 로그인 화면을 띄우기만 하는」 것인가
• 기존 로컬 프로필이나 AD 프로필은 어떻게 되는가
• Windows의 관리자 권한, BitLocker, 업데이트 관리까지 챙길 수 있는가
• 최초 로그온, 오프라인, 2단계 인증, 비밀번호 변경은 어떻게 동작하는가
• Active Directory와 공존할 수 있는가, 아니면 대체하는가

이 부분을 대충 정리하고 넘어가면, 도입 전 기대치가 어긋나 이전이나 초기 설정에서 사고가 나기 쉬워집니다.

GCPW는 단순한 「Google 로그인 화면」도, Windows 도메인 그 자체의 완전한 대체도 아닙니다. 실무에서는 Windows에 대한 Google 로그인, 기존 프로필과의 대응 관계, Google 측의 비밀번호 / 세션 운영, Windows device management 병용을 나누어 생각하면 전체 그림이 훨씬 잘 보입니다.

이 글에서는 Google Credential Provider for Windows(GCPW)를 Windows 10 / 11 환경에서 사용할 때 무슨 일이 일어나는지, 적합한 구성, 도입 절차, 자주 걸리는 함정을 Mermaid 다이어그램을 많이 곁들여 실무 관점에서 정리합니다. 내용은 2026년 3월 시점에 확인할 수 있는 Google Workspace 공식 문서를 주된 근거로 삼고 있습니다.

다이어그램은 개념도입니다. Mermaid를 지원하는 Markdown 환경에서는 도표로 표시됩니다.

1. 먼저 결론

먼저 결론만 나열해 두겠습니다.

• GCPW는 관리 대상 Google 계정으로 Windows 10 / 11에 로그인시키기 위한 메커니즘입니다.
• GCPW 단독의 주역은 Windows 로그인과 Chrome Browser의 SSO 경험입니다.
• Windows 업데이트, BitLocker, 로컬 관리자 권한, 커스텀 설정, 초기화까지 챙기고 싶다면 Windows device management 병용을 전제로 하는 것이 실무적입니다.
• 기존 로컬 / AD 프로필이 있는 환경에서는 「기존 프로필을 연계할지, 신규 프로필을 만들지」를 먼저 정해두지 않으면 이전 과정에서 막히기 쉽습니다.
• 최초 로그인은 온라인이 전제입니다. 게다가 AD 가입 단말에서 기존의 AD 기반 프로필이 없는 경우에는 최초 로그인 시에 AD에 연결할 수 있는 것도 중요합니다.
• 오프라인 로그인은 가능하지만, 며칠까지 허용할지를 정해두지 않으면 운영이 흔들립니다.
• 2단계 인증은 사용할 수 있지만, USB 보안 키는 GCPW에서 지원하지 않습니다.
• 비밀번호 운영을 먼저 정하지 않으면 Google 측과 Windows 측의 불일치로 로그온 사고가 발생합니다. 특히 AD / Entra ID 측에서만 먼저 재설정하는 운영은 위험합니다.
• GCPW는 Google만을 ID 공급자로 다루므로, 이를 전제로 구성을 생각하는 것이 어긋나지 않는 길입니다.

요컨대 GCPW는 「Google로 Windows에 들어가기 위한 메커니즘」이며, Windows 단말 운영 전체를 챙기고 싶다면 Windows device management와 함께 설계하는 것이 순리입니다.

먼저 포지셔닝을 한 장으로 파악하기

flowchart TD
    A["Windows 단말에서 Google 계정을 쓰고 싶다"] --> B{"무엇을 실현하고 싶은가"}
    B --> C["Windows에 대한 Google 로그인"]
    B --> D["Windows 설정의 일원화 관리"]
    B --> E["기존 프로필 이전"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["기존 로컬 / AD 프로필 연계 설계"]

    F --> I["Windows 로그온"]
    F --> J["Chrome Browser SSO"]
    F --> K["Google 비밀번호 동기화"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["로컬 관리자 권한"]
    G --> O["커스텀 설정 / 초기화 / 감사"]

    H --> P["신규 프로필을 만들 것인가"]
    H --> Q["기존 프로필을 재사용할 것인가"]

2. GCPW를 4개 계층으로 나누면 이해하기 쉽다

GCPW 이야기가 복잡해지는 이유는 「로그인」과 「프로필 이전」과 「단말 관리」가 같은 하나의 상자 안 이야기로 취급되기 쉽기 때문입니다. 실무에서는 이 4개 계층으로 나누어 버리는 것이 가장 빠릅니다.

이렇게 보면, 「GCPW를 설치했는데 BitLocker가 적용되지 않는다」, 「Google로 로그인했는데 기존 사용자 데이터가 보이지 않는다」 같은 어긋남의 원인이 훨씬 잘 보입니다.

계층 구조

flowchart LR
    subgraph Id["ID / 세션"]
        A["Google 계정"]
        B["2단계 인증"]
    end

    subgraph SignIn["로그인 계층"]
        C["GCPW"]
    end

    subgraph Profile["Windows 프로필 계층"]
        D["기존 로컬 프로필"]
        E["기존 AD 기반 프로필"]
        F["신규 Windows 프로필"]
    end

    subgraph Mgmt["관리 계층"]
        G["Windows device management"]
        H["BitLocker / 업데이트 / 로컬 관리자 권한"]
        I["커스텀 설정 / 초기화 / 감사"]
    end

    subgraph Config["설정 계층"]
        J["Admin console"]
        K["레지스트리 설정"]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F
    J --> C
    K --> C
    G --> H
    G --> I
    C --> G

3. Windows 환경에서 어떻게 동작하는가

3.1 지원 요구사항을 먼저 파악한다

Windows 환경에서는 먼저 요구사항에서 걸리지 않는 것이 중요합니다.

여기서 놓치기 쉬운 것이 Chrome과 ARM 미지원입니다. Windows 단말 이야기이므로 OS만 보기 쉽지만, GCPW는 Google 로그인 화면을 실행하는 데 Chrome에도 의존하므로, Chrome의 부재나 배치 불일치로도 로그온이 실패합니다.

3.2 최초 로그인부터 평소 로그온까지

GCPW 도입 이후의 흐름을 단순화하면 다음과 같습니다.

1. 단말에 GCPW를 설치한다
2. 사용자가 Google 계정으로 최초 로그인한다
3. GCPW가 기존 프로필을 연계하거나, 새로운 Windows 프로필을 만든다
4. 그 이후에는 평소의 Windows 로그온 화면으로 들어간다
5. 다만 Google 비밀번호 변경이나 세션 만료 같은 보안 이벤트 시에는 다시 Google 로그인 화면이 요구된다

여기서 중요한 것은, 「매번 반드시 Google 대화창을 통해 들어가는 것은 아니다」라는 점입니다. 최초 로그온이나 특정 보안 이벤트 시에는 Google 측 인증이 앞으로 나오지만, 평소에는 Windows 로그온 화면에서의 로그인이 주가 됩니다.

최초 로그인 흐름

sequenceDiagram
    participant U as 사용자
    participant W as Windows 로그인 화면
    participant G as Google 로그인
    participant P as GCPW
    participant R as 기존 / 신규 프로필
    participant C as Chrome Browser

    U->>W: Add Work Account 또는 기존 계정을 선택
    W->>G: Google 인증 화면을 실행
    G->>U: 이메일 주소 / 비밀번호 / 2SV
    U->>G: 자격 증명을 입력
    G->>P: 인증 성공

    alt 기존 프로필을 연계
        P->>R: 기존 로컬 / AD 프로필을 찾아 연계
    else 신규 작성
        P->>R: 새로운 Windows 프로필을 작성
    end

    P->>C: Google 로그인 상태를 이어받음
    P->>W: Windows 세션을 시작

3.3 비밀번호 동기화, 오프라인, 2단계 인증

GCPW를 Windows 환경에서 안정적으로 운영하고 싶다면, 사실 가장 먼저 봐야 할 것은 비밀번호 운영입니다.

Google의 공식 가이드에서도, GCPW를 사용하는 단말에서는 Google 비밀번호와 Windows 비밀번호가 동기화되어 있는 것이 전제입니다. 게다가 사용자는 보통 Google 측 비밀번호를 주로 관리하는 것이 전제입니다. 그래서 Ctrl + Alt + Delete를 통한 Windows 비밀번호 변경에 의존하는 설계와는 궁합이 좋지 않습니다.

비밀번호 동기화의 개념

flowchart LR
    A["Google 비밀번호 변경"] --> B{"단말이 온라인인가"}
    B -- 예 --> C["GCPW가 Windows 측 비밀번호를 동기화"]
    C --> D["다음 로그온 성공"]

    B -- 아니오 --> E["동기화가 보류됨"]
    E --> F["다음 온라인 시 재동기화"]

    G["AD / Entra ID 측에서만 비밀번호 변경"] --> H["Google과 Windows의 불일치"]
    H --> I["Password incorrect / 동기화 오류"]

실무에서 자주 발생하는 것은 다음과 같습니다.

• Google 측에서 비밀번호를 변경했다고 생각했지만, 단말이 오프라인이라 아직 Windows 측과 동기화되지 않은 경우
• 반대로 AD / Entra ID 측에서만 먼저 재설정하여 Google 측과 불일치가 생긴 경우
• Google 측의 비밀번호 복잡도가 Windows / AD보다 약해서, Windows 측 요구사항을 충족하지 못하는 문자열로 바꿔버린 경우

이 때문에 도입 전에 최소한 다음 정도는 정해두어야 합니다.

• 비밀번호의 주도권을 Google에 둘 것인가
• 아니면 AD / Entra ID / 다른 도구에서 Google로 동기화할 것인가
• 비밀번호 복잡도를 Windows 측 이상으로 맞출 것인가

오프라인과 2단계 인증

GCPW는 오프라인 로그인 자체는 가능합니다. 다만 마지막 온라인 로그인으로부터 며칠까지 허용할지를 설정할 수 있습니다. 이를 정하지 않은 채 도입하면, 지나치게 엄격해서 현장이 곤란해지거나, 지나치게 완화해서 단말 분실 시 위험이 높아지는 쪽으로 치우치기 쉽습니다.

또한 2단계 인증은 사용할 수 있지만, 이 부분은 미리 현장에 알려두는 것이 안전합니다.

• USB 보안 키는 GCPW에서 지원하지 않음
• 대신 Google 프롬프트, Google Authenticator, 백업 코드 등의 방식을 전제로 함
• 보안 키만 허용하는 구성이라면 사용자가 Windows에 들어갈 수 없게 될 가능성이 있음

4. 기존 로컬 / AD 프로필을 어떻게 다룰 것인가

GCPW 이전에서 가장 사고가 나기 쉬운 부분이 여기입니다.

단말에 이미 업무용 Windows 프로필이 있을 때, GCPW 측에서 이를 연계하여 재사용할지, 새로운 Windows 프로필을 만들지에 따라 사용자 경험도 이전 난이도도 크게 달라집니다.

대표적인 3가지 패턴

Google의 안내에서도, 기존 프로필에 연계하는 경우에는 Directory 측의 custom attribute로 Windows 계정 이름이나 AD 계정을 대응시키거나, 단말 측의 SID 기반 레지스트리 설정을 사용하기도 합니다. 즉, 「설치 후에 사용자가 그 자리에서 대충 선택하는」 운영이 아니라, 사전 설계가 필요한 이전 작업입니다.

더 중요한 것은, 연계하지 않을 경우의 동작입니다.

• 기존 로컬 프로필 사용자는 예전 프로필 쪽으로 들어갈 여지가 남는 경우가 있음
• 기존 AD 사용자는 Google 로그인용 신규 프로필이 만들어지면, 원래 기대했던 업무 프로필로 순순히 들어가지 못할 수 있음

기존 프로필을 어떻게 다룰지 판단하는 흐름도

flowchart TD
    A["단말에 기존 업무용 Windows 프로필이 있다"] --> B{"그대로 데이터 / 설정을 사용하고 싶은가"}
    B -- 예 --> C["기존 프로필 연계를 설계한다"]
    B -- 아니오 --> D["GCPW가 신규 Windows 프로필을 만들게 한다"]

    C --> E{"기존 프로필의 종류"}
    E -- 로컬 --> F["Local Windows accounts 등으로 대응"]
    E -- AD 기반 --> G["AD accounts 등으로 대응"]

    G --> H["최초 로그인 시 AD 연결성을 확인"]
    F --> I["Windows 사용자명 / 단말 단위 제한을 정리"]
    D --> J["기존 데이터 이전을 별도 계획으로 진행"]

5. GCPW 단독과 GCPW + Windows device management의 차이

GCPW를 이야기할 때, 실무에서는 이 둘을 나누는 것이 매우 중요합니다.

비교표

Google 공식에서도 회사 지급 단말에는 GCPW와 Windows device management를 함께 사용하는 구성을 추천합니다. 반대로 이미 다른 관리 기반이 있고 Google 로그인 경험만 원한다면 GCPW 단독이라는 사고방식이 됩니다.

병용 시 은근히 중요한 제약

Windows device management를 병용할 때는, 한 단말에서 enroll할 수 있는 사용자는 1명뿐이라는 점을 먼저 이해해두는 것이 안전합니다.

Google 공식에서도 이는 Windows 10 / 11 측의 제약으로 안내되고 있습니다. 여러 사용자가 GCPW로 그 단말에 들어갈 수 있는 구성이라 해도, Windows device management에 enroll되는 것은 최초 1명의 사용자입니다. 게다가 BitLocker나 업데이트, 로컬 관리자 권한 같은 단말 수준의 설정은 그 단말을 사용하는 다른 사용자에게도 영향을 줍니다.

첫 번째 사용자 문제

flowchart TD
    A["단말을 설정한다"] --> B["최초로 GCPW로 로그인한 사용자"]
    B --> C["Windows device management에 enroll"]
    C --> D["단말 수준 설정이 적용됨"]
    D --> E["BitLocker / 업데이트 / 로컬 관리자 권한 / 커스텀 설정"]

    F["나중에 GCPW로 들어오는 다른 사용자"] --> G["Windows 로그인 자체는 가능"]
    G --> H["다만 enroll되는 사용자는 늘어나지 않음"]
    H --> I["단말 수준 설정은 최초 enroll을 전제로 동작"]

이것이 무엇으로 이어지느냐면, 세팅 담당자가 먼저 GCPW로 들어가버리는 문제입니다. 원래 그 단말을 사용할 직원이 아니라, 세팅 담당자의 계정이 enroll되면, 나중에 의도한 설정이 적용되지 않는 사고가 발생합니다.

6. 도입 전에 결정해야 할 것

GCPW 도입에서 나중에 효과를 발휘하는 것은 installer 실행 자체보다 사전 설계입니다. 공식 가이드를 실무 관점으로 바꿔 말하면, 적어도 다음 6가지는 먼저 정해두고 싶은 부분입니다.

flowchart LR
    A["도입 전에 결정한다"] --> B["비밀번호 주도권"]
    B --> C["복잡도 요구사항"]
    C --> D["허용 도메인"]
    D --> E["기존 프로필 대응"]
    E --> F["지원용 관리자 권한"]
    F --> G["자동 enrollment의 staging 방침"]
    G --> H["오프라인 허용 일수"]

좋지 않은 진행 방식과 실무적인 진행 방식

특히 놓치기 쉬운 3가지

1. 허용 도메인은 필수

GCPW에서는 어느 도메인의 계정을 로그인 허용할지를 정하지 않으면 사용자가 들어갈 수 없습니다. Admin console에서도, 레지스트리의 domains_allowed_to_login에서도 설정할 수 있지만, 어느 쪽이든 이 부분은 필수입니다.

2. Admin console과 레지스트리는 역할을 나눈다

오래된 해설에서는 레지스트리 설정 중심의 글이 많지만, 현재는 Admin console 관리가 기본입니다. 다만 단말마다 다른 허용 도메인을 두고 싶은 경우처럼, 세밀하게 나누고 싶을 때는 레지스트리가 더 적합한 경우도 있습니다.

3. Admin console의 설정은 즉시 반영되지 않는다

GCPW의 설정은 단말에 대략 1시간 단위로 동기화됩니다. 「설정은 입력했는데 바로 반영되지 않는다」는 흔한 일이므로, pilot 시에는 이 시간 지연을 감안하고 보는 것이 안전합니다.

7. 실무를 위한 도입 절차

여기서는 Windows 환경에서 GCPW를 실무적으로 도입할 때의 흐름을 최대한 짧게 정리합니다.

도입 흐름

flowchart TD
    A["1. 계약 플랜 / OS / Chrome 요구사항을 확인"] --> B["2. 비밀번호 전략과 복잡도를 정한다"]
    B --> C["3. 허용 도메인과 각종 설정을 정한다"]
    C --> D["4. 기존 프로필 연계 필요 여부를 정한다"]
    D --> E["5. Windows device management를 사용한다면 활성화"]
    E --> F["6. Admin console에서 installer를 취득"]
    F --> G["7. 단말에 배포 / 관리자 권한으로 설치"]
    G --> H["8. 사용자가 최초 온라인 로그인"]
    H --> I["9. 단말 세부 정보 / enrollment / 로그를 확인"]

7.1 먼저 구성을 결정한다

가장 먼저 정할 것은 다음입니다.

• GCPW 단독으로 사용할 것인가
• GCPW + Windows device management로 사용할 것인가
• 기존 프로필을 연계할 것인가
• 아니면 신규 프로필로 전환할 것인가

이 판단이 먼저입니다. 이를 정하지 않고 installer만 배포하면, 나중에 「생각했던 단말 관리를 할 수 없다」, 「기존 사용자 데이터가 이어지지 않는다」라는 결과가 됩니다.

7.2 허용 도메인과 옵션을 결정한다

설정 방법은 2가지입니다.

• Admin console 같은 설정을 조직 전체에 배포하고 싶을 때 적합합니다. 지금의 기본은 이쪽입니다.
• 단말 레지스트리 단말마다 세밀하게 나누고 싶을 때 적합합니다.

레지스트리를 사용한다면 최소한 domains_allowed_to_login은 필요합니다. GCPW를 Windows device management와 병용한다면 enable_dm_enrollment나 validity_period_in_days, 공유 단말 같은 운영이라면 enable_multi_user_login도 판단 포인트가 됩니다.

7.3 installer를 취득하여 배포한다

Admin console에서 32bit / 64bit의 GCPW installer를 취득하여 단말에 배포합니다. 현재의 관리 모델에서는 Admin console에서 다운로드한 installer에 organization-specific token이 내장되므로, 지금은 이것을 기준으로 생각하는 것이 이해하기 쉽습니다.

7.4 설치한다

수동 설치라면, 예를 들어 다음과 같이 할 수 있습니다.

# 64bit 버전
gcpwstandaloneenterprise64.exe /silent /install

# 32bit 버전
gcpwstandaloneenterprise.exe /silent /install

7.5 레지스트리로 개별 설정하고 싶을 때의 예

Admin console에서 설정하지 않은 값을 단말마다 넣고 싶을 때의 예입니다.

주의: Admin console과 레지스트리 양쪽에 같은 설정이 있는 경우, Admin console 쪽이 우선됩니다.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"domains_allowed_to_login"="example.com"
"enable_dm_enrollment"=dword:00000001
"validity_period_in_days"=dword:00000007
"enable_multi_user_login"=dword:00000000

7.6 기존 프로필을 재사용한다면, 연계 정의를 먼저 만든다

기존 로컬 / AD 프로필을 재사용하고 싶다면, 사용자의 Google 계정과 Windows 계정의 대응 관계를 Directory 측의 custom attribute 등으로 먼저 준비해둡니다. 이를 미루고 먼저 로그인시키면, 신규 프로필이 만들어진 후에 되돌리는 상황이 되기 쉽습니다.

7.7 최초 온라인 로그인 후에 확인한다

최초 로그인 후에는 다음을 확인합니다.

• 기대했던 Windows 프로필로 들어갔는가
• Windows device management를 병용한다면, 의도한 사용자로 enroll되었는가
• 단말 세부 정보가 Admin console에 표시되는가
• 정책 동기화가 완료되었는가

8. 자주 발생하는 문제와 Windows에서의 원인 분리

GCPW의 문제는 대부분 이 표의 항목 중 하나로 귀결됩니다.

문제 해결 흐름

flowchart TD
    A["GCPW에서 문제 발생"] --> B{"무슨 일이 일어나고 있는가"}
    B -- 로그인 거부 --> C["허용 도메인 확인"]
    B -- Google 화면이 나오지 않음 --> D["Chrome 존재 여부 / 경로 / AV 확인"]
    B -- Password incorrect --> E["Google / Windows의 동기화 상태 확인"]
    B -- 기존 데이터가 보이지 않음 --> F["프로필 연계 확인"]
    B -- device management에 들어가지 않음 --> G["최초 enroll 사용자 확인"]
    C --> H["Admin console / 레지스트리를 확인"]
    D --> I["Chrome을 재설치"]
    E --> J["비밀번호 운영을 다시 정리"]
    F --> K["custom attribute / SID 매핑을 재확인"]
    G --> L["staging 절차를 재검토"]

Windows에서 로그를 확인하는 위치

GCPW를 Windows 상에서 추적할 때는 먼저 Event Viewer입니다.

• Windows Logs > Application
• Event source는 GCPW

이것으로 기본적인 정보는 대부분 확인할 수 있습니다. 더 자세히 보고 싶다면, 레지스트리로 verbose logging을 활성화할 수 있습니다.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"enable_verbose_logging"=dword:00000001
"log_file_path"="C:\\GCPW.log"
"log_file_append"=dword:00000001

Windows device management까지 보고 싶을 때는, 필요에 따라 이쪽도 확인합니다.

• Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

반영을 빨리 확인하고 싶을 때

허용 도메인이나 정책을 수정한 후 바로 반영을 확인하고 싶다면, Google의 안내에서는 Task Scheduler에서 GoogleUpdateTaskMachineUA를 실행하여 동기화를 유도하는 방법을 안내하고 있습니다. pilot 중에는 이 절차를 손에 익혀두면 원인 분리가 빨라집니다.

9. 어떤 조직에 적합한가, 적합하지 않은가

적합한 상황

적합하지 않은 상황

10. 정리

GCPW를 Windows 환경에서 잘 활용하는 요령은 기능을 하나로 뭉쳐서 보지 않는 것입니다.

• GCPW는 Google로 Windows에 들어가기 위한 메커니즘
• 기존 프로필 연계는 이전을 위한 메커니즘
• Windows device management는 단말 운영을 위한 메커니즘

이 3가지를 나누어 생각하면, 도입 판단이 훨씬 쉬워집니다.

실무에서 특히 중요한 것은 다음 5가지입니다.

1. 비밀번호 운영을 먼저 정한다
2. 허용 도메인을 먼저 정한다
3. 기존 프로필을 재사용할지 정한다
4. Windows device management를 사용한다면 최초 enroll 사용자를 잘못 정하지 않는다
5. Event Viewer를 전제로 한 문제 해결 절차를 갖춰둔다

GCPW는 Windows 로그온을 Google 쪽으로 옮기기 위한 실무적인 도구입니다. 다만 진짜 효과를 발휘하는 것은 installer를 실행하는 순간이 아니라 그 전의 설계입니다. 이 부분을 먼저 다져두면, Google 로그인, 기존 데이터의 지속 활용, Windows 단말 관리의 선이 깔끔하게 연결됩니다.

관련 기사

• Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법
• Windows 샌드박스로 Windows 앱 개발의 검증을 빠르게 하는 방법 - 관리자 권한 문제, 클린 환경, 권한 부족・리소스 부족의 재현을 실무용으로 정리
• ClickOnce란 무엇인가 - 구조, 업데이트, 어울리는 장면・어울리지 않는 장면을 실무 시점에서 정리

관련 토픽

• Windows 기술 토픽

이 주제가 이어지는 서비스

• Windows 앱 개발
• 기술 상담・설계 리뷰
• 문의하기

참고 자료

1. Google Workspace Help - Overview: Enhanced desktop security for Windows
2. Google Workspace Help - Prepare to install GCPW
3. Google Workspace Help - Install Google Credential Provider for Windows
4. Google Workspace Help - Set up GCPW and Windows device management together
5. Google Workspace Help - Associate Google accounts with existing Windows profiles
6. Google Workspace Help - Set account privileges on Windows 10 or 11 devices
7. Google Workspace Help - FAQ for GCPW
8. Google Workspace Help - Troubleshoot GCPW
9. Google Workspace Learning Center - Sign in to Windows after GCPW installation
10. Google Workspace Help - Set token to manage GCPW from the Admin console
11. Google Workspace Help - What’s new in GCPW

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

GCPW란 무엇인가요?

GCPW(Google Credential Provider for Windows)는 관리 대상 Google 계정으로 Windows 10 / 11에 로그인시키기 위한 메커니즘입니다. 단독으로 주역이 되는 것은 Windows 로그인과 Chrome Browser의 SSO 경험이며, 단순한 「Google 로그인 화면」도, Windows 도메인의 완전한 대체도 아닙니다. 지원 OS는 Windows 10 / 11의 Pro, Pro for Workstations, Enterprise, Education이며, ARM 기반 단말은 지원하지 않고, Chrome Browser 81 이상이 관리자 권한으로 설치되어 있는 것이 전제입니다.

GCPW만으로 BitLocker나 Windows Update 관리를 할 수 있나요?

GCPW 단독으로는 기본적으로 할 수 없습니다. GCPW 단독으로 할 수 있는 것은 Google을 통한 Windows 로그인, Chrome SSO, 기존 프로필 연계까지이며, BitLocker, Windows Update 제어, 로컬 관리자 권한 제어, 커스텀 설정 배포, 초기화 등은 Windows device management 병용이 전제입니다. 병용 시에는 한 단말에서 enroll할 수 있는 사용자는 최초 1명뿐이라는 제약이 있으므로, 세팅 담당자가 먼저 로그인하여 enroll되어 버리는 사고에 주의해야 합니다.

GCPW는 오프라인에서도 Windows에 로그인할 수 있나요?

오프라인 로그인 자체는 가능합니다. 다만 최초 로그인은 인터넷 연결이 필수이며, AD 가입 단말에서 기존의 AD 기반 프로필이 없는 경우에는 최초 로그인 시에 AD에 연결할 수 있어야 합니다. 오프라인을 허용하는 일수는 validity_period_in_days 등으로 설정할 수 있으며, 마지막 온라인 로그인으로부터 며칠까지 허용할지를 정해두지 않으면 지나치게 엄격해서 현장이 곤란해지거나, 지나치게 완화해서 단말 분실 시 위험이 높아지는 쪽으로 치우치기 쉽습니다.

GCPW에서 2단계 인증이나 보안 키를 사용할 수 있나요?

2단계 인증은 사용할 수 있지만, USB 보안 키는 GCPW에서 지원하지 않습니다. 대신 Google 프롬프트, Google Authenticator, 백업 코드 등의 방식을 전제로 합니다. 보안 키만 허용하는 구성이라면 사용자가 Windows에 들어갈 수 없게 될 가능성이 있으므로, 도입 전에 현장에 미리 알려두는 것이 안전합니다. 또한 비밀번호는 Google 측과 Windows 측의 동기화가 전제이므로, AD / Entra ID 측에서만 먼저 재설정하는 운영은 불일치로 인한 로그온 사고로 이어집니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.