인증/인가를 제로(Zero)부터 배우기 #1 로드맵과, 패스키가 비밀번호보다 안전한 이유

1. 이 연재에 대하여

AI 제품을 만들다 보면 반드시 이런 상황에 부딪힙니다.

• AI 에이전트가 직원을 대신하여 사내 시스템을 조작하는 경우
• AI가 사용자별로 볼 수 있는 자료만 검색하여 답변하는 경우
• AI가 송금이나 삭제와 같은 되돌릴 수 없는(irreversible) 조작을 실행하려 하는 경우

어떤 상황이든 그 기반에는 **'누구인지 (인증, Authentication)'와 '무엇을 할 권한이 있는지 (인가, Authorization)'**가 있습니다.

본 연재는 인증/인가를 기초부터 순서대로 학습하는 학습 로그입니다. 저 자신의 이해를 다지기 위해 작성하고 있지만, 처음 인증/인가를 배우는 분들도 읽을 수 있도록 전문 용어는 그때그때 설명하겠습니다.

• 초보자분들: 용어와 전체적인 그림, 그리고 '왜 그렇게 되어 있는지'를 알 수 있습니다 -
• 엔지니어분들: 메커니즘의 핵심과 설계 시 막히기 쉬운 포인트를 정리하는 데 활용할 수 있습니다

2. 학습 로드맵

인증부터 인가까지, 기초에서 응용으로 총 5개의 장에 걸쳐 진행합니다.

각 테마는 다음 5단계 순서로 이해합니다

'방식의 이름만 외우는 것'으로는 설계 상황에서 활용할 수 없습니다. 그래서 모든 테마를 다음 5단계로 정리했습니다.

• 메커니즘: 무엇을 해결하는 기술인가 -
• 처리 플로우(Processing Flow): 누가, 누구에게, 무엇을 보내고 있는가 -
• 비교: 다른 방식과 무엇이 다르고 어떤 단점이 있는가 -
• 실무 설계: 어떤 상황에서 선택해야 하는가 -
• AI 적용: AI 에이전트나 AI 서비스에서는 무엇이 달라지는가

이번에는 제1장의 첫 번째 테마인, 비밀번호와 패스키에 대해 다룹니다.

3. 먼저 알아야 할 용어

방식 이야기에 들어가기 전에, 용어를 통일합니다. 여기서 모호하면 이후 장에서 반드시 혼란을 겪게 됩니다.

가장 중요한 점: 인증과 인가는 별개입니다

오피스 빌딩을 생각해보겠습니다.

• 인증: 입구에서 사원증을 보여주고, '사원 A 씨가 맞다'고 확인받는 것 -
• 인가: A 씨가 들어갈 수 있는 곳은 자신의 부서 층만 가능하다. 임원실이나 서버실에는 들어갈 수 없다.

직원으로서 인증되었다고 해서 모든 방에 들어갈 수 있는 것은 아닙니다. '본인임을 알았다'는 것과 '그것을 할 권한이 있다'는 것은 별개의 판단입니다.

AI도 마찬가지입니다. AI 에이전트가 직원에게 요청을 받았다고 하더라도, 그 직원의 권한을 무엇이든 자유롭게 사용할 수 있는 것은 아닙니다. 이 구분이 앞으로 배우게 될 모든 방식의 토대가 됩니다.

4. 비밀번호의 문제점은 무엇인가

비밀번호는 '비밀의 암호(secret passphrase)를 본인과 서버 양쪽이 알고 있는' 메커니즘입니다. 이 '양쪽이 알고 있다'는 점이 약점의 근원입니다.

그렇다면, '비밀을 공유하지 않는' 인증으로 할 수는 없을까요? 이것을 실현한 것이 바로 패스키입니다.

5. 패스키의 메커니즘

생각하는 방식: '비밀의 암호'에서 '서명(Signature)'으로

패스키는 **공개키 암호 (Public Key Cryptography)**를 사용합니다. 어렵게 들리지만, 생각은 이렇습니다.

• 당신의 단말기(인증기) 안에,
  **당신만이 가진 '서명용 비밀키(private key)'**가 있다 (인증기 밖으로는 그대로의 형태로 꺼낼 수 없음) -
• 서버에는,
  **그 서명이 진짜인지 구별하기 위한 '공개키(public key)'**만 맡긴다 (견본장 같은 것) -
• 로그인할 때, 서버가 내는 문제(Challenge)에 단말기가 비밀키로 서명하여 되돌려준다
• 서버는 공개키로 서명을 확인한다

서버가 가진 것은 공개키뿐입니다. 공개키가 유출되어도 서명을 만들 수는 없습니다. 도난당해 곤란한 비밀을, 서버가 가지고 있지 않다는 것이 가장 큰 포인트입니다.

등록과 로그인 흐름

먼저, 패스키를 만드는 '등록(Registration)' 과정이 있습니다.

다음으로, 패스키를 사용하는 '로그인(Login)' 과정이 있습니다.

3가지 핵심 포인트

1. 생체 정보는 서버로 전송되지 않습니다

지문이나 얼굴은 기기가 잠금 해제(본인 확인) 할 때만, 기기 내부에서 사용합니다. 서버가 받는 것은 오직 서명뿐입니다.

2. 도전 과제는 매번 바뀐다

로그인할 때마다 서버는 새로운 랜덤 값을 생성합니다. 과거의 서명을 훔쳐 재사용하더라도 통하지 않습니다 (리플레이 공격 방지).

3. 서명에 '어떤 사이트에 대한 것인지'가 포함된다

다음 장에서 자세히 설명하겠습니다. 이것이 패스키가 피싱에 강한 이유입니다.

자주 묻는 질문

Q1. 키 쌍은 사이트마다 만드나요? 아니면 인증기 하나로 충분한가요?

등록할 때마다 새로 만듭니다. 단위는 '사이트(도메인) × 계정'입니다. A사와 B사는 다른 키 쌍을 사용하며, 같은 A사라도 다른 계정이라면 또 다른 키 쌍이 필요합니다.

만약 인증기가 하나의 키를 재사용한다면, 사이트를 넘나들며 동일한 공개키가 노출되어 '같은 사람이 A사와 B사에 모두 존재한다'고 추적당할 수 있습니다. 이는 그러한 것을 방지하기 위한 설계입니다.

Q2. 공개키와 함께 보내는 'Credential ID'는 무엇에 사용되나요?

'어떤 키 쌍인지'를 가리키는 명찰과 같습니다. 인증기는 사이트나 계정별로 많은 키를 가지고 있기 때문에, 서명 시점에 '어떤 것을 사용할지' 지정해야 합니다.

• 로그인 시작 시: 서버가 브라우저에 '이 사용자의 키는 이 ID다'라고 전달하고, 인증기가 올바른 개인키를 선택합니다.
• 서명 검증 시: 서버가 Credential ID를 단서로 데이터베이스에서 해당하는 공개키를 찾아 서명을 확인합니다.

사용자 이름 입력 없이 로그인할 경우, 인증기가 Credential ID 등을 서버에 반환하고, 서버는 이를 단서 삼아 사용자를 특정합니다.

Q3. 키 쌍은 언제 만들어지나요?

등록할 때만 합니다. 본인 확인(지문・얼굴・PIN)이 완료된 직후, 인증기 내부에서 생성됩니다 (사이트 설정에 따라 본인 확인 대신 터치만 하는 '존재 확인'일 수도 있습니다).

로그인 시에는 새로운 키가 만들어지지 않습니다. 이미 존재하는 개인키로 도전 과제에 서명하기만 합니다.

6. 왜 피싱에 강한가

패스키는 생성되는 순간 특정 사이트(도메인)에 연결됩니다.

로그인 시, 브라우저는 '현재 열려 있는 사이트의 도메인'을 서명의 대상에 포함합니다. 따라서 가짜 사이트에서 로그인하려고 해도,

• 실제 사이트용 패스키는 가짜 사이트에서는 사용할 수 없으며,
• 가짜 사이트에서 서명을 하더라도, 그 서명은 실제 사이트에서는 통하지 않습니다.

비밀번호의 경우, '이 사이트는 진짜인가?'를 사람이 구별해야 했습니다. 하지만 패스키는 그것을 시스템이 자동으로 처리합니다. 사용자 주의력에 의존하지 않는 설계이기 때문에 강력한 것입니다.

7. 다른 방식과 비교

'다요소 인증(MFA)'을 했다고 해서 안전하다고 단정할 수 없습니다. 중요한 것은, 피싱에 강하냐입니다.

원타임 코드(One-Time Code)는 비밀번호보다는 확실히 안전합니다. 하지만 가짜 사이트가 입력된 값을 그대로 실제 사이트로 전달하는 수법에는 취약합니다. 이 점이 패스키와의 결정적인 차이점입니다.

패스키의 두 가지 유형

보급률도 높아지고 있습니다. FIDO Alliance는 2026년 5월에 전 세계적으로 약 50억 개의 패스키가 사용되고 있다는 추정치를 발표했습니다(참고 링크 참조).

8. 패스키로도 막을 수 없는 것

'패스키가 안전하다'라고만 기억하는 것은 위험합니다. 무엇을 방어할 수 있고, 무엇을 방어할 수 없는지를 알아야 합니다.

9. 실무에서 설계할 경우 (금융 서비스 예시)

금융과 같이 사고가 미치는 영향이 큰 영역에서 패스키를 사용한다면, 예를 들어 다음과 같이 위험도에 따라 단계를 나눕니다.

• 일반 고객: 동기형(Synchronous) 패스키를 기본으로 합니다. 기기 분실에 대비하여 여러 개의 패스키 등록을 권장하고, 비밀번호는 점진적으로 폐지합니다.
• 직원 및 관리자: 기기에 고정된 보안 키(Security Key)를 사용하며, 이용을 허가하는 인증기 종류를 관리합니다.
• 송금 등 중요 작업: 로그인 상태이더라도, 작업할 때마다 재인증합니다 (단계별 인증/Step-up Authentication).
• 복구 및 추가 등록: 새로운 패스키를 추가할 때는 등록된 연락처로 알림을 보냅니다. 추가 직후에는 중요한 작업에 제한을 두는(쿨다운 기간) 등의 장치가 효과적입니다.

엔지니어 대상: 서버 측에서 확인해야 할 사항

구현 시에는 라이브러리(WebAuthn 검증 라이브러리)를 사용하는 것이 기본입니다. 직접 서명 검증 로직을 작성하기보다는, 무엇을 검증하고 있는지 이해하는 것이 중요합니다.

• 체인징지(Challenge)가 서버에서 발행한 것인지,
  그리고 단 한 번만 사용되며 유효기간 내인지 - 서명의 대상에 포함되는
  Origin(스키마/호스트/포트 조합)과 RP ID(패스키를 연결한 사이트의 식별자)가 예상하는 값과 일치하는지 - 본인 확인(지문, PIN 등)이 필요한 상황에서 요구되었는지
• 서명이 등록된 공개키로 검증 가능한지

체인징지의 일회성 관리와 Origin 비교는 구현 오류가 발생하기 쉬운 부분입니다.

10. AI 제품에서는 무엇이 달라지는가

여기서 이 연재에서 가장 전달하고 싶은 내용입니다.

패스키는 '인간의 본인 확인' 수단

패스키는 사람이 본인이 맞는지를 확인하는 메커니즘입니다. AI 에이전트 자체를 인증하는 수단은 아닙니다. 에이전트는 별도의 인증/인가 메커니즘이 필요합니다 (제3장, 제4장에서 다룹니다).

패스키가 유효한 것은 '인간의 승인'

AI 에이전트는 프롬프트 인젝션(Prompt Injection: 악의적인 지시를 혼입시키는 공격)으로 인해 속을 수 있습니다.

따라서, '위험한 작업을 수행하기 전에는 인간이 피싱에 강한 방식으로 승인한다'는 설계가 효과적입니다.

에이전트가 속더라도, 인간의 승인 서명은 위조할 수 없습니다. 'AI에게 맡길 범위'와 '인간이 반드시 확인해야 하는 범위'를 분리하는 사고방식은 제4장에서 자세히 다룹니다.

11. 이해 점검

다음 세 가지 질문에 자신의 언어로 답할 수 있는지 시험해 보세요.

• 가짜 사이트에서 패스키가 사용될 수 없는 이유는 무엇인가요? ('도메인'이라는 단어를 사용하여 설명해 봅시다.)
• 일회용 코드(One-Time Code)를 이용한 다중 요소 인증이 패스키보다 피싱에 취약한 이유는 무엇인가요?
• 패스키를 도입하더라도 남아있는 위험은 어디에 있나요?

12. 다음 편 예고

다음 편에서는 로그인 후의 세계를 다룹니다.

• 세션(Session), 쿠키(Cookie), JWT
• OpenID Connect (OIDC)와 PKCE

'로그인한 후, 서버는 어떻게 당신을 기억하는지'를 메커니즘부터 배워보겠습니다.

참고

Discussion