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, 로컬 관리자 권한, 커스텀 설정, wipe까지 보려면 Windows device management를 함께 쓰는 것을 전제로 하는 편이 실무적입니다.
• 기존 로컬 / AD 프로필이 있는 환경에서는 「기존 프로필을 연결할지, 새 프로필을 만들지」를 먼저 정하지 않으면 이전에서 막히기 쉽습니다.
• 최초 로그인은 온라인이 전제입니다. 여기에 AD 가입 단말에 기존 AD-backed 프로필이 없으면 최초 로그인 때 AD에 연결될 수 있는지도 중요합니다.
• 오프라인 로그인은 가능하지만, 며칠까지 허용할지를 정해 두지 않으면 운영이 흔들립니다.
• 2단계 인증은 되지만, USB 보안 키는 GCPW에서 미지원입니다.
• 비밀번호 운영을 먼저 정하지 않으면 Google 측과 Windows 측이 어긋나 로그온 사고가 납니다. 특히 AD / Entra ID 쪽에서만 먼저 재설정하는 운영은 위험합니다.
• GCPW는 Google만 ID provider로 다루므로, 이 전제로 구성을 생각하는 편이 어긋나지 않습니다.

요컨대 GCPW는 「Google로 Windows에 들어가는 방식」이며, Windows 단말 운영 전체까지 쥐고 싶다면 Windows device management와 세트로 설계하는 것이 맞습니다.

이 글에서 쓰는 용어

Google 측과 Windows 측 말이 섞이므로 먼저 정리합니다.

먼저 위치를 한 장으로 보기

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["커스텀 설정 / wipe / 감사"]

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

이 그림은 「하고 싶은 일」에서 「쓸 도구」를 끌어오기 위한 그림입니다. 왼쪽에서 오른쪽으로, 실현하고 싶은 일을 고르면 담당하는 방식(GCPW / Windows device management / 프로필 설계)이 정해집니다. 여기서 확인할 것은 한 가지뿐입니다. BitLocker나 Windows Update 같은 단말 수준 관리는 GCPW 열에 나오지 않는다는 점입니다.

이 글의 지식 맵

이 글은 GCPW(Google Credential Provider for Windows)를 관리 대상 Google 계정으로 Windows 10/11에 로그인하게 하는 자격 증명 공급자로 정리하고, BitLocker나 업데이트 관리 같은 단말 수준 제어는 Windows device management를 함께 쓰는 것이 전제임을 보입니다. 기존 로컬/AD-backed 프로필은 Directory 쪽 custom attribute로 연결할지 새 프로필을 만들지 미리 설계해야 하며, 함께 쓸 때는 처음 로그인한 사용자만 enroll된다는 제약이 있습니다. Google과 Windows의 비밀번호는 동기화가 전제이므로 AD/Entra ID 쪽에서만 먼저 재설정하는 운영은 사고의 원인이 됩니다. USB 보안 키는 지원되지 않으며, 허용 도메인을 설정하지 않으면 아무도 로그인할 수 없습니다.

flowchart LR
    accTitle: GCPW의 지식 맵
    accDescr: GCPW를 통한 Windows 로그인이 Chrome Browser와 허용 도메인을 전제로 한다는 점, Windows device management의 단말 수준 관리가 GCPW에서의 최초 enroll을 전제로 한다는 점, 기존 프로필 연결과 비밀번호 동기화의 운영상 주의점의 관계를 보여주는 그림
    gcpw["GCPW"]
    windows_device_management["Windows device management"]
    chrome_browser["Chrome Browser"]
    fido2_security_key["보안 키"]
    permitted_domains["허용 도메인(permitted domains)"]
    admin_console_gcpw_settings["Admin console의 GCPW 설정"]
    installer_token_embedding["installer에 토큰 자동 삽입"]
    gcpw_enrollment["Windows device management로의 enroll"]
    staging["staging(키팅)"]
    first_user_enrollment_constraint["최초 1사용자 enroll 제약"]
    existing_profile_association["기존 프로필 연결"]
    custom_attribute_profile_mapping["Directory 측 custom attribute 프로필 대응"]
    initial_signin_ad_connectivity_requirement["최초 로그인 시 AD 연결성 요건"]
    ad_backed_profile["AD-backed 프로필"]
    active_directory["Active Directory(AD DS)"]
    ad_side_only_password_reset_antipattern["AD/Entra ID 측만의 선행 비밀번호 재설정"]
    password_sync_requirement["Google/Windows 비밀번호 동기화 전제"]
    offline_signin_validity_period["오프라인 로그인 허용 일수"]
    google_2sv["2SV(2단계 인증)"]
    google_password_complexity_policy["Google 측 비밀번호 복잡도 설정"]
    bitlocker["BitLocker"]
    windows_update["Windows Update"]
    admin_rights["관리자 권한"]
    gcpw -->|"전제로 한다"| chrome_browser
    gcpw -.->|"양립하지 않는다"| fido2_security_key
    gcpw -->|"전제로 한다"| permitted_domains
    permitted_domains -->|"에서 구성할 수 있다"| admin_console_gcpw_settings
    admin_console_gcpw_settings -->|"전제로 한다"| installer_token_embedding
    windows_device_management -->|"전제로 한다"| gcpw
    windows_device_management -->|"전제로 한다"| gcpw_enrollment
    gcpw_enrollment -->|"전제로 한다"| gcpw
    staging -.->|"원인이 될 수 있다"| first_user_enrollment_constraint
    existing_profile_association -->|"이용한다"| custom_attribute_profile_mapping
    existing_profile_association -.->|"전제로 한다"| initial_signin_ad_connectivity_requirement
    ad_backed_profile -->|"전제로 한다"| active_directory
    ad_side_only_password_reset_antipattern -->|"양립하지 않는다"| password_sync_requirement
    offline_signin_validity_period -->|"에서 구성할 수 있다"| admin_console_gcpw_settings
    gcpw -.->|"이용한다"| google_2sv
    google_password_complexity_policy -.->|"양립하지 않는다"| active_directory
    windows_device_management -->|"이용한다"| bitlocker
    windows_device_management -->|"이용한다"| windows_update
    gcpw -.->|"전제로 한다"| admin_rights
    chrome_browser -.->|"전제로 한다"| admin_rights
    gcpw -->|"에서 구성할 수 있다"| admin_console_gcpw_settings
    gcpw -->|"이용한다"| existing_profile_association
    existing_profile_association -->|"이용한다"| ad_backed_profile
    gcpw -->|"전제로 한다"| password_sync_requirement
    staging -->|"보다 먼저 해야 한다"| gcpw_enrollment

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 25건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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-backed 프로필"]
        F["새 Windows 프로필"]
    end

    subgraph Mgmt["관리 계층"]
        G["Windows device management"]
        H["BitLocker / 업데이트 / 로컬 관리자 권한"]
        I["커스텀 설정 / wipe / 감사"]
    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

1장의 그림이 「목적에서 도구를 끌어오는」 것이었다면, 이 그림은 같은 요소를 「어느 계층 이야기인지」와 「무엇이 무엇에 의존하는지」로 다시 늘어놓은 것입니다. 읽어야 할 것은, 화살표가 모두 GCPW(로그인 계층)를 지난다는 점, 그리고 GCPW에서 프로필 계층으로 뻗는 화살표가 3갈래로 갈린다는 점입니다. 이 분기가 4장에서 다루는 「기존 프로필을 연결할지, 새로 만들지」 설계 그 자체입니다.

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

3.1 지원 요건을 먼저 잡는다

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

지원 에디션의 차이(도입 판단의 첫 관문)

「GCPW 단독」과 「Windows device management 병행」은 필요한 에디션이 다릅니다. Google 공식 문서(Overview: Enhanced desktop security for Windows)가 드는 지원 에디션은 다음과 같습니다.

읽는 법은 이렇습니다. GCPW 로그인만이면 거의 모든 에디션에서 쓸 수 있습니다. 반면 BitLocker나 Windows Update, 로컬 관리자 권한까지 관리하려면 Business Plus, Enterprise Standard 이상, Cloud Identity Premium 같은 지원 에디션이 필요합니다. 특히 Business Starter / Business Standard와 Cloud Identity Free는 GCPW는 되지만 Windows device management는 안 됩니다. 「GCPW를 넣었는데 BitLocker를 관리할 수 없다」는 상담은 여기가 원인인 경우가 있습니다.

에디션 구성은 바뀔 수 있으므로, 계약 전에는 반드시 공식 문서의 최신 지원 표를 확인하세요.

여기서 놓치기 쉬운 것이 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: credential을 입력한다
    G->>P: 인증 성공

    alt 기존 프로필을 연결한다
        P->>R: 기존 로컬 / AD 프로필을 찾아 연결한다
    else 새로 만든다
        P->>R: 새 Windows 프로필을 만든다
    end

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

이 그림에서 봐야 할 것은 분기가 한곳뿐이라는 점입니다. 기존 프로필을 연결할지, 새 프로필을 만들지. 여기는 최초 로그인 한순간에 정해지고, 나중에 「역시 기존 프로필로」 되돌리기는 재작업이 됩니다. 그래서 4장의 연결 설계를 installer 배포보다 먼저 끝냅니다.

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 쪽에서 변경)은 온라인이면 동기화되고, 오프라인이어도 다음 온라인 때 따라잡습니다. 아래 흐름(AD / Entra ID 쪽에서만 변경)은 아무리 기다려도 동기화되지 않습니다. 비밀번호 재설정 절차서를 만들 때는 아래 흐름을 금지 절차로 적어 두는 편이 실무적입니다.

실무에서 흔한 것은 여기입니다.

• Google 쪽에서 비밀번호를 바꿨다고 생각했는데, 단말이 오프라인이라 Windows 측과 아직 동기화되지 않은 경우
• 반대로 AD / Entra ID 쪽에서만 먼저 재설정해서 Google 쪽과 어긋난 경우
• Google 쪽 비밀번호 복잡도가 Windows / AD보다 약해서, Windows 측 요건을 못 채우는 문자열로 바꿔 버린 경우

그래서 도입 전에 적어도 여기까지는 정해 둬야 합니다.

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

세 번째 복잡도는 Google Admin console의 「보안」→「인증」→「비밀번호 관리」에서 조직 단위(OU)마다 설정합니다. 다만 여기서 지정할 수 있는 것은 「안전한 비밀번호를 적용한다」는 체크와 최소·최대 글자 수(8〜100자), 재사용 여부, 만료일까지입니다. Active Directory 비밀번호 정책처럼 「대문자·소문자·숫자·기호 중 몇 종류를 포함할 것」 같은 문자 종류 지정은 할 수 없습니다. Google 쪽은 문자 종류 내역이 아니라 비밀번호 전체 강도를 평가하는 방식이기 때문입니다.

그래서 실무에서는 AD 측 최소 글자 수와 같거나 그 이상을 Google 쪽에 설정하고, 「안전한 비밀번호를 적용한다」를 켠다는 맞추기가 됩니다. AD 측 문자 종류 요건이 빡센 경우, Google 쪽에서 통과한 비밀번호가 Windows 쪽에서 거절될 여지가 남으므로, 그 조합은 반드시 pilot에서 확인하세요.

오프라인과 2단계 인증

GCPW는 오프라인 로그인 자체는 됩니다. 다만 마지막 온라인 로그인부터 며칠까지 허용할지를 설정할 수 있습니다. 여기를 정하지 않은 채 넣으면 너무 빡세서 현장이 곤란해지거나, 너무 느슨해서 단말 분실 시 위험이 커지는 쪽으로 기울기 쉽습니다.

또한 2단계 인증은 되지만, 이 부분은 먼저 현장에 알려 두는 편이 안전합니다.

• USB 보안 키는 GCPW에서 미지원
• 대신 Google prompt, Google Authenticator, backup code 같은 방식을 전제로 한다
• 보안 키만 허용한 구성이면 사용자가 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-backed --> 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나 업데이트, 로컬 관리자 권한 같은 단말 수준 설정은 그 단말을 쓰는 다른 사용자에게도 영향을 줍니다.

처음 1명 문제

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["오프라인 허용 일수"]

이 그림은 순서가 의미를 갖습니다. 왼쪽에서 오른쪽으로, 정하지 않으면 다음을 정할 수 없는 순으로 늘어놓았습니다. 예를 들어 복잡도는 비밀번호 주도권을 Google에 둘지 AD 쪽에 둘지가 정해지지 않으면 정할 수 없습니다. 거꾸로 말하면, 이 나열의 어딘가를 건너뛴 채 installer를 뿌리면 그다음 판단이 전부 보류인 채로 단말이 늘어납니다.

잘못된 진행과 실무적인 진행

특히 놓치기 쉬운 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를 받아 단말에 배포합니다. 받는 화면 경로는 다음과 같습니다.

Google 관리 콘솔
  → 메뉴
  → 기기（Devices）
  → 모바일 및 엔드포인트（Mobile & endpoints）
  → 설정（Settings）
  → Windows
  → 「Google Credential Provider for Windows setup」
  → 「Download GCPW」

이 작업에는 특권 관리자(super administrator)로 로그인해야 합니다. 여기서 64bit 또는 32bit 버전을 다운로드해 배포합니다.

현행 관리 모델에서 중요한 것은 Admin console에서 다운로드한 installer에는 그 조직의 토큰이 자동으로 들어간다는 점입니다. 토큰 유무는 나중에 먹힙니다.

참고로 Chrome Enterprise Core용 등록 토큰을 이미 단말에 뿌린 경우에는, 그 토큰으로 GCPW 설정도 Admin console에서 관리할 수 있습니다. 「Admin console에서 허용 도메인을 설정했는데 단말에 반영되지 않는다」면, 먼저 토큰 없는 installer를 배포하지 않았는지 의심하세요. 설정 반영 자체에도 최대 1시간 정도 걸리므로, 그 시간을 기다린 뒤 판단합니다.

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로 먼저 준비합니다. 여기를 미루고 먼저 로그인시키면 새 프로필이 만들어진 뒤 되돌리게 되기 쉽습니다. 이 글에서 가장 사고가 나기 쉬운 곳이므로 구체적으로 적습니다.

절차 1: 커스텀 속성을 만든다

Admin console의 「디렉터리」→「사용자」→ 상단 「기타」→「커스텀 속성 관리」에서 추가합니다. 값은 대소문자까지 포함해 다음과 같이 입력합니다(틀리면 나중에 이름을 고치지 못하고 다시 만들게 됩니다).

Directory API로 만들 때는 스키마 이름 Enhanced_desktop_security, 필드 이름 AD_accounts / Local_Windows_accounts로 등록합니다. 기존 AD에서 값을 흘려 넣으려면 Google Cloud Directory Sync를 쓰는 방법도 있습니다.

절차 2: 사용자마다 값을 넣는다

사용자 상세 화면의 「사용자 정보」에 「Enhanced desktop security」 칸이 나오므로, 거기에 Windows 측 계정 이름을 넣습니다. 서식이 정해져 있습니다.

잡아 둘 제약은 3가지입니다.

• AD 계정은 사용자당 1개뿐입니다. 여러 개를 넣어도 GCPW는 처음 1건만 씁니다.
• AD와 로컬을 둘 다 설정하면 GCPW는 AD 계정을 먼저 찾습니다.
• 속성이 없거나 일치하는 Windows 프로필을 못 찾으면 새 Windows 프로필이 만들어집니다. 「연결한 줄 알았는데 기존 데이터가 안 보인다」의 대부분은 여기입니다.

AD 가입 단말에서 아직 그 단말에 AD-backed 프로필이 없는 사용자(로그인 화면의 「다른 사용자」로 들어오는 사람)는 최초 로그인 때 단말이 AD에 연결되어야 합니다. 원격 근무 중인 단말에서 최초 로그인시키면 여기서 실패합니다.

정확한 화면 절차와 최신 사양은 공식 Associate Google accounts with existing Windows profiles를 참조하세요.

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

최초 로그인 뒤에는 여기를 확인합니다.

• 기대한 Windows 프로필로 들어갔는가
• Windows device management를 함께 쓰면, 의도한 사용자로 enroll되었는가
• 단말 상세가 Admin console에 나오는가
• 정책 동기화가 끝났는가

8. 흔한 막힘과 Windows에서의 원인 분리

GCPW 문제는 대개 이 표 중 하나로 떨어집니다.

「Chrome / AV 간섭」을 항목별로 나눈다

이 표에서 가장 모호한 것이 「AV 간섭」입니다. 실제로 문제가 되는 것은 다음 중 하나입니다. 위에서부터 확인하면 원인 분리가 빨라집니다.

이 중 로그온 전 통신은 놓치기 쉬운 지점입니다. 사용자가 로그인한 뒤에는 통하는 통신이어도, 로그온 화면 시점에는 다른 경로나 다른 credential로 움직이므로, 거기서 멈추지 않았는지 확인합니다.

문제 해결 흐름

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 절차를 다시 본다"]

이 그림은 증상에서 먼저 볼 곳을 하나로 정하기 위한 것입니다. GCPW 문제는 「인증」「Chrome」「비밀번호 동기화」「프로필 연결」「enrollment」 중 하나로 떨어지므로, 먼저 어느 열의 이야기인지를 확정한 뒤 상세 로그로 갑니다. 증상이 여러 개처럼 보일 때는 처음 로그인한 사용자가 누구였는지를 확인하면 enrollment 열로 모이는 경우가 많습니다.

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 Sandbox로 앱 검증을 빠르게 하는 방법
• 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
12. Google Workspace 관리자 고객센터 - 사용자 비밀번호 요구사항을 적용·모니터링하기

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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 제어, 로컬 관리자 권한 제어, 커스텀 설정 배포, wipe 등은 Windows device management를 함께 쓰는 것이 전제입니다. 함께 쓸 때는 한 단말에서 enroll할 수 있는 사용자는 처음 1명뿐이라는 제약이 있으므로, 키팅 담당자가 먼저 로그인해서 enroll되는 사고에 주의해야 합니다.

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

오프라인 로그인 자체는 됩니다. 다만 최초 로그인은 인터넷 연결이 필수이고, AD 가입 단말에 기존 AD-backed 프로필이 없으면 최초 로그인 때 AD에도 연결되어야 합니다. 오프라인을 허용하는 일수는 validity_period_in_days 등으로 설정할 수 있으며, 마지막 온라인 로그인부터 며칠까지 허용할지를 정해 두지 않으면 너무 빡세서 현장이 곤란해지거나, 너무 느슨해서 단말 분실 시 위험이 커지는 쪽으로 기울기 쉽습니다.

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

2단계 인증은 되지만, USB 보안 키는 GCPW에서 미지원입니다. 대신 Google prompt, Google Authenticator, backup code 같은 방식을 전제로 합니다. 보안 키만 허용한 구성이면 사용자가 Windows에 못 들어갈 수 있으므로, 도입 전에 현장에 알려 두는 편이 안전합니다. 또한 비밀번호는 Google 측과 Windows 측 동기화가 전제라서, AD / Entra ID 쪽에서만 먼저 재설정하는 운영은 불일치로 로그온 사고로 이어집니다.

저자 프로필

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

Go Komura

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

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