---
term: 'ID 및 접근 관리 (IAM)'
seoTitle: 'ID 및 접근 관리(IAM)란? 핵심 요소, 표준, 수명 주기'
headline: 'ID 및 접근 관리(IAM)란?'
slug: identity-access-management-iam
category: auth-security
shortDefinition: 'IAM은 적절한 사용자가 적절한 시점에 적절한 리소스에 대해 적절한 접근 권한을 갖도록 보장하는 정책과 기술의 프레임워크입니다.'
relatedTerms:
  - role-based-access-control-rbac
  - oauth-2-social-login
  - multi-factor-authentication-mfa
  - json-web-token-jwt
contrastsWith:
  - role-based-access-control-rbac
aboutTerms:
  - 'Identity Provider (IdP)'
  - 'Single Sign-On (SSO)'
  - 'Identity Lifecycle'
  - 'CIAM'
faq:
  - question: 'IAM을 쉽게 설명하면 무엇입니까?'
    answer: '누가 무엇에 접근할 수 있는지를 관리하는 분야입니다. 사용자가 주장하는 그 사람이 맞는지 증명하고(인증), 무엇을 할 수 있는지 결정하며(인가), 계정을 생성부터 삭제까지 관리하고(수명 주기), 이 모든 것을 기록합니다(감사). 모든 요청에 대해 "당신은 누구입니까?"와 "무엇을 할 수 있습니까?"에 답합니다.'
  - question: '인증과 인가의 차이는 무엇입니까?'
    answer: '인증은 자격 증명, 코드, 생체 인식으로 사용자가 누구인지 확인합니다. 인가(권한 부여)는 역할, 권한, 정책으로 사용자가 무엇을 할 수 있는지 결정합니다. 공항에 비유하면 여권 심사와 탑승권의 차이입니다. 인증은 항상 먼저 실행되고, 인가는 그 뒤의 모든 동작마다 실행됩니다.'
  - question: 'IAM 시스템은 어떤 구성 요소로 이루어집니까?'
    answer: 'ID 저장소(사용자 디렉터리), 인증 서비스(비밀번호, MFA, 싱글 사인온), 인가 메커니즘(역할, 권한, ACL), 수명 주기 도구(프로비저닝과 디프로비저닝), 감사 로깅입니다. 실제 시스템에는 직접 조립했든 플랫폼에서 물려받았든 이 다섯 가지가 모두 있습니다.'
  - question: 'ID 공급자(IdP)란 무엇입니까?'
    answer: 'ID를 소유하고 그 ID를 보증하는 시스템입니다. 사용자를 인증하고, 다른 애플리케이션이 신뢰하는 서명된 토큰이나 어설션을 OpenID Connect 또는 SAML로 발급합니다. 모든 "…로 로그인" 버튼은 IdP가 작동하는 모습이며, 기업은 직원용 싱글 사인온을 위해 자체 IdP를 운영합니다.'
  - question: '싱글 사인온(SSO)이란 무엇입니까?'
    answer: 'ID 공급자에서 한 번 인증한 뒤 새로 로그인하지 않고 여러 애플리케이션에 접근하는 방식입니다. 각 앱은 자체 자격 증명을 보관하는 대신 IdP의 어설션을 신뢰합니다. 비밀번호는 줄고, MFA를 강제할 곳은 한 곳이 되며, 스위치 하나로 모든 곳의 접근을 끊을 수 있습니다.'
  - question: '프로비저닝과 디프로비저닝이란 무엇입니까?'
    answer: '수명 주기를 이루는 동작입니다. 프로비저닝은 누군가 합류하거나 역할이 바뀔 때 계정을 만들고 권한을 부여하며, 디프로비저닝은 떠날 때 이를 회수합니다. SCIM 같은 표준으로 자동화됩니다. 디프로비저닝에 실패하면 고아 계정이 남는데, 이는 늘 감사 지적 사항의 상위에 오르며 공격자가 즐겨 노리는 발판입니다.'
  - question: '직원용 IAM과 CIAM의 차이는 무엇입니까?'
    answer: '대상과 우선순위가 다릅니다. 직원용 IAM(workforce IAM)은 직원을 관리합니다. 사용자는 수천 명 규모이고, IT가 통제를 의무화하며, 최소 권한과 규정 준수가 우선입니다. 고객 IAM(CIAM)은 앱의 사용자를 관리합니다. 수백만 명에 이를 수 있고, 셀프서비스 가입과 소셜 로그인이 기본이며, UX, 전환율, 개인정보 동의가 우선입니다. 대부분의 앱 개발자는 그 용어를 쓰든 안 쓰든 CIAM을 만들고 있습니다.'
  - question: 'IAM은 제로 트러스트와 어떤 관계입니까?'
    answer: '"절대 신뢰하지 말고 항상 검증하라"는 제로 트러스트는 네트워크 경계를 ID로 대체합니다. 모든 요청은 어디에서 왔든 인증과 인가를 거칩니다. 이를 가능하게 하는 메커니즘이 IAM이며, 그래서 "ID가 새로운 경계"라는 말이 이 분야의 슬로건이 되었습니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63-4 — Digital Identity Guidelines'
    url: 'https://pages.nist.gov/800-63-4/'
  - name: 'NIST Identity & Access Management program'
    url: 'https://www.nist.gov/identity-access-management'
  - name: 'OpenID Connect Core 1.0'
    url: 'https://openid.net/specs/openid-connect-core-1_0.html'
  - name: 'RFC 7644 — SCIM Protocol'
    url: 'https://datatracker.ietf.org/doc/html/rfc7644'
  - name: 'Identity and access management — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Identity_and_access_management'
cta:
  title: '앱 수준 IAM, 미리 조립된 상태로'
  text: 'Back4app은 앱에 첫날부터 필요한 IAM 기본 요소, 즉 사용자 저장소, 세션, 역할, ACL, 이메일 확인, 소셜 로그인, MFA를 제공하며, 플랫폼이 모든 요청에서 이를 강제합니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-11-02'
translationKey: identity-access-management-iam
---

**IAM은 적절한 사용자가 적절한 시점에 적절한 리소스에 대해 적절한 접근 권한을 갖도록 보장하는 정책과 기술의 프레임워크입니다.** ID 및 접근 관리는 모든 로그인 창과 권한 검사 뒤에 있는 분야입니다. 먼저 한 가지를 구분해 두겠습니다. 주요 클라우드 제공업체들도 자사 인프라에 대한 접근을 제어하는 "IAM"이라는 이름의 *제품*을 제공하지만, 이는 이 분야의 구현체일 뿐 정의가 아닙니다. 이 글은 분야 자체를 다루며, 모든 앱 개발자가 대개 IAM이라고 부르지 않은 채 직접 만들거나 물려받는 형태도 포함합니다.

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 네 가지 핵심 요소 | 인증 · 인가 · 수명 주기 · 감사 |
| 슬로건 | 적절한 사람, 적절한 접근, 적절한 리소스, 적절한 시점 |
| 두 개의 세계 | 직원용 IAM(직원, 규정 준수) · CIAM(앱 사용자, UX) |
| 표준 | 토큰에는 OIDC와 OAuth · 기업 SSO에는 SAML · 수명 주기에는 SCIM · 자격 증명에는 WebAuthn |
| 개발자 버전 | 사용자 저장소 + 세션 + 역할 + ACL + 복구 – 직접 만들거나 물려받습니다 |

## ID 수명 주기: 합류, 이동, 이탈

IAM의 일상 업무는 모든 계정이 거치는 순환이며, 각 단계는 구체적인 작업에 대응합니다:

```text
합류     ID 생성 → 이메일 확인 → 자격 증명/세션 발급
         (프로비저닝 – 직원용 시스템에서는 SCIM으로 자동화)
이동     역할 변경 · 팀 변경 · 권한 부여와 회수
         (인가는 역할을 따르므로, 이동은 데이터 갱신일 뿐)
이탈     세션을 지금 즉시 폐기 → 계정 비활성화 → 삭제 또는 익명화
         (디프로비저닝 – 건너뛴 단계는 "고아 계정"이 되고,
          침해 보고서에 계속 등장하는 감사 지적 사항으로 남음)
```

같은 순환을 API 호출로 표현하면 다음과 같습니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: 'ada@example.com' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, 'ada@example.com');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "ada@example.com"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "ada@example.com"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)
```

## 인증 vs. 인가

이 분야 전체가 기대고 있는 구분입니다:

| | 인증(AuthN) | 인가(AuthZ) |
| --- | --- | --- |
| 질문 | 당신은 누구입니까? | 무엇을 할 수 있습니까? |
| 증거 | 자격 증명, [MFA](/glossary/ko/multi-factor-authentication-mfa/) 코드, 생체 인식, 패스키 | 역할, 권한, [ACL](/glossary/ko/access-control-lists-acl/), 정책 |
| 시점 | 세션당 한 번 | 모든 동작마다 |
| 결과물 | 세션 또는 [토큰](/glossary/ko/json-web-token-jwt/) | 요청별 허용/거부 |
| 실패 형태 | 계정 탈취 | 권한 상승, 데이터 노출 |

공항 비유는 한 번이면 충분합니다. 여권 심사와 탑승권의 차이입니다. 더 중요한 것은 엔지니어링 관점입니다. 인증은 세션이 지니고 다니는 *ID를 만들어 내고*, 인가는 그 뒤의 모든 요청에서 *그 ID를 소비합니다*. 그래서 둘은 서로 다르게 실패하며, 따로 강화해야 합니다.

```mermaid
flowchart LR
  accTitle: 네 가지 핵심 요소에 걸친 IAM 요청 흐름
  accDescr: 사용자는 ID 저장소에 대해 인증하고 세션을 받습니다. 이후 각 요청은 리소스에 도달하기 전에 역할과 권한에 따라 인가되며, 수명 주기 관리는 계정의 존재 자체를 관리하고 감사 로깅은 인증과 인가 이벤트를 기록합니다.
  U["사용자"] -->|"자격 증명 + MFA"| AN["인증<br/>ID 저장소 · IdP"]
  AN -->|"세션 / 토큰"| AZ["인가<br/>역할 · 권한 · ACL"]
  AZ --> R[("리소스")]
  L["수명 주기<br/>합류 · 이동 · 이탈"] -.->|"계정 관리"| AN
  AN -.-> AU["감사<br/>누가, 언제, 무엇을 했는지"]
  AZ -.-> AU
```

## 네 가지 핵심 요소, 그리고 시장의 세 글자 약어

기능별로 해부하면 다음과 같습니다. **인증**(ID 증명 – 비밀번호, MFA, SSO, 비밀번호 없는 인증), **인가**(동작 결정 – [역할](/glossary/ko/role-based-access-control-rbac/), 권한, 객체 규칙), **수명 주기**(합류/이동/이탈의 순환), 그리고 **감사**(늘 과소평가되는 네 번째 요소 – 로그, 접근 검토, 그리고 "누가 이것을 읽을 수 있었고, 실제로 누가 읽었는가?"에 답할 수 있는 능력)입니다. 벤더 시장은 같은 영역을 구매 과정에서 만나게 될 세그먼트로 나눕니다. **AM**(접근 관리 – 로그인, SSO, MFA), **IGA**(거버넌스 – 접근 권한 재인증, 직무 분리, 운영 차원의 "할 수 있는가?" 위에 있는 "이 권한을 가져야 하는가?" 계층), 그리고 **PAM**(특권 접근 – 한 번 침해되면 모든 것이 뚫리는 계정을 위한 볼트 보관과 적시(just-in-time) 권한 상승)입니다. 같은 분야를 그린 두 개의 지도입니다.

## 표준 스택

약어의 홍수를 역할별로 정리했습니다. 검색 상위 페이지들이 결코 제공하지 않는 표입니다:

| 표준 | 하는 일 | 접하게 되는 곳 |
| --- | --- | --- |
| [OAuth 2.0](/glossary/ko/oauth-2-social-login/) | 위임된 인가 – 비밀번호 공유 대신 범위가 지정된 토큰 | API 접근, 소셜 로그인 밑의 연결 작업 |
| OpenID Connect | OAuth 위의 인증 – 서명된 ID 토큰이 누가 로그인했는지 보증 | 모든 "…로 로그인" 버튼, 최신 SSO |
| SAML 2.0 | XML 기반 페더레이션 어설션 – OIDC의 엔터프라이즈 선배 | 기업 SSO 연동 |
| SCIM | 계정 프로비저닝/디프로비저닝을 위한 표준 API | 직원 수명 주기 자동화 |
| WebAuthn / FIDO2 | 피싱 방지 공개 키 자격 증명 | 패스키, 하드웨어 보안 키 |
| [JWT](/glossary/ko/json-web-token-jwt/) | 어설션을 실어 나르는 토큰 형식 | ID 토큰, 액세스 토큰 |
| LDAP | 디렉터리 조회 프로토콜 | 레거시 ID 저장소 |

## 직원용 IAM vs. CIAM

| | 직원용 IAM | 고객 IAM(CIAM) |
| --- | --- | --- |
| 사용자 | 직원, 계약자 – 수천 명 | 앱의 사용자 – 최대 수백만 명 |
| 온보딩 | IT가 프로비저닝 | 셀프서비스 가입 – 마찰은 전환율을 떨어뜨림 |
| 인증 | 기업 SSO, 의무 MFA | 소셜 로그인, 비밀번호 없는 인증, 선택적 MFA |
| 우선순위 | 최소 권한, 규정 준수 | UX, 전환율, 개인정보 동의 |
| 수명 주기 | 인사 부서가 주도하는 합류/이동/이탈 | 사용자가 주도하는 가입/참여/이용 중단/삭제 |
| 구매 주체 | IT 및 보안 팀 | 제품 팀 – 구매하기보다 *직접 만드는* 경우가 많음 |

이 구분에 표 하나를 할애하는 이유가 있습니다. 상위에 노출되는 콘텐츠는 거의 모두 왼쪽 열에 관한 것인데, 용어집을 읽는 개발자 대부분은 오른쪽 열을 만들고 있기 때문입니다. 앱 사용자를 위한 가입 흐름, 세션 처리, 계정 복구는 *그 자체로* CIAM입니다. 그 자리의 누구도 이 약어를 쓰지 않더라도 이 분야는 그대로 적용됩니다.

## 일반적인 사용 사례

- **앱 사용자 관리** – 가입, 이메일 확인, 세션, 역할, 삭제. 일상적인 백엔드 작업으로서의 CIAM입니다.
- **기업 SSO** – IdP 하나에 여러 앱. MFA와 오프보딩을 한 지점에서 강제합니다.
- **API와 서비스 ID** – 사람이 아닌 호출자를 위한 머신 자격 증명, 범위가 지정된 토큰, 회전입니다.
- **규정 준수 프로그램** – GDPR, HIPAA, SOC 2를 위한 접근 검토, 감사 추적, 최소 권한의 증거입니다.
- **제로 트러스트 아키텍처** – 네트워크 위치 대신 요청별 ID 검사가 신뢰의 신호가 됩니다.

## IAM을 직접 구축할까, 구매할까? 결정 매트릭스

| 상황 | 권장 방향 |
| --- | --- |
| 제품을 위한 앱 수준 인증 | BaaS에서 물려받기 – 사용자 저장소부터 MFA까지 미리 구축됨 |
| SaaS 도구 전반의 직원용 SSO | IdP 서비스 구매 |
| 완전한 통제, 셀프 호스팅, 표준 프로토콜 | 오픈소스 IdP(Keycloak, Ory) |
| 단일 앱, 단순한 요구 사항, 프레임워크 세션 | 최소한으로 구축 – 단, 복구와 감사는 계획해야 함 |
| 규제 대상 신원 확인 | 구매 – 보증 수준은 인증(certification) 작업임 |
| "당분간" 비밀번호 저장소를 직접 구현 | 하지 말아야 함 – 다시 발명해서는 안 되는 단 하나의 바퀴 |

## 한계와 트레이드오프

- **IAM의 본질은 소프트웨어가 아니라 프로세스입니다.** 도구는 정책을 자동화할 뿐 만들어 내지는 못합니다. 역할 설계, 검토 주기, 오프보딩 규율은 여전히 사람의 일입니다.
- **중앙화는 위험을 집중시킵니다.** IdP가 하나라는 것은 보호해야 할 곳도 하나, 모두를 로그아웃시키는 장애 지점도 하나라는 뜻입니다. 편리함에는 가용성과 복구 계획이 따라와야 합니다.
- **페더레이션은 신뢰를 물려받습니다.** IdP를 신뢰하는 모든 앱은 그 IdP의 침해도 함께 물려받습니다. 토큰 검증과 짧은 토큰 수명이 피해를 가두는 수단입니다.
- **수명 주기 자동화에는 정확한 원천이 필요합니다.** 프로비저닝은 그것에 데이터를 공급하는 기준 시스템만큼만 정확합니다. 오래된 인사 데이터는 오래된 접근 권한이 됩니다.
- **검토 없는 감사는 보여 주기일 뿐입니다.** 아무도 읽지 않는 로그와 아무도 조치하지 않는 재인증은 체크리스트를 만족시킬 뿐, 공격자를 막지는 못합니다.

## Back4app에서의 IAM

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 개발자의 눈으로 본 IAM이 바로 Back4app이 제공하는 것입니다. `User` 클래스가 ID 저장소이고, 가입, 이메일 확인, 비밀번호 재설정, [소셜 로그인](/glossary/ko/oauth-2-social-login/)이 인증을 담당합니다(단계적 인증을 위한 MFA 어댑터 포함). 폐기 가능한 세션 토큰이 ID를 실어 나르고, [역할](/glossary/ko/role-based-access-control-rbac/)과 객체별 [ACL](/glossary/ko/access-control-lists-acl/)이 인가라는 핵심 요소로서 모든 REST, GraphQL, Live Query 요청에서 강제됩니다. 코드 탭의 수명 주기, 즉 합류, 이동, 이탈은 평범한 데이터 작업이며, Cloud Code 트리거는 정책을 강제하기에 알맞은 위치입니다(일회용 이메일 차단, 감사 이벤트 기록, 디프로비저닝 연쇄 처리). 플랫폼 계층으로서의 CIAM입니다. 핵심 요소는 조립된 채로 주어지고, 사용자의 일은 ID 메커니즘을 만드는 것에서 정책을 결정하는 것으로 옮겨 갑니다.