인증과 인가 완벽 정복 핸드북 개발자도 헷갈리는 개념 끝내기

2025-09-22 23:40

• 인증]은 당신이 누구인지 증명하는 과정이며, 인가]는 당신이 무엇을 할 수 있는지 허락하는 과정이다.

• 아이디와 비밀번호로 로그인하는 것이 인증의 대표적인 예시이며, 로그인 후 게시글을 작성하거나 삭제할 수 있는 권한을 부여받는 것이 인가의 예시다.

• 이 두 가지 개념은 디지털 세상의 안전과 질서를 유지하는 핵심적인 보안 장치로, 함께 작동하여 시스템을 보호한다.

인증과 인가 완벽 정복 핸드북 개발자도 헷갈리는 개념 끝내기

디지털 세상의 문을 열고 들어갈 때, 우리는 거의 항상 두 가지 중요한 관문을 거치게 된다. 바로 **인증(Authentication)**과 **인가(Authorization)**다. 이 두 용어는 종종 혼용되거나 헷갈리는 개념으로 여겨지지만, 사실은 디지털 시스템의 보안과 접근 제어를 책임지는 명확히 구분되는 핵심적인 역할을 수행한다. 마치 클럽에 들어갈 때 입구에서 신분증을 확인하는 절차와, VIP 룸에 들어갈 수 있는 권한을 부여받는 것이 다른 차원의 문제인 것과 같다.

이 핸드북은 개발자부터 일반 사용자까지, 인증과 인가라는 개념을 명확하게 이해하고 그 중요성을 깨닫는 것을 목표로 한다. 두 개념이 왜 탄생했으며, 어떤 구조로 작동하고, 어떻게 우리 일상과 시스템에 적용되는지, 그리고 더 나아가 어떤 심화된 내용들이 있는지 포괄적으로 다룰 것이다.

1. 모든 것의 시작 왜 인증과 인가가 필요해졌을까?

컴퓨터 시스템이 독립적인 단일 개체로 존재하던 초기에는 인증이나 인가의 개념이 희박했다. 시스템을 사용하는 사람 자체가 물리적으로 제한되어 있었기 때문이다. 하지만 컴퓨터가 네트워크로 연결되고, 여러 사람이 하나의 시스템에 원격으로 접속하는 시대가 열리면서 문제가 발생하기 시작했다.

‘누가’ 시스템에 접속하는지, 그리고 그 접속한 사용자가 ‘무엇을’ 할 수 있는지 통제할 필요성이 생긴 것이다. 악의적인 사용자가 시스템에 침투하여 정보를 탈취하거나 시스템을 파괴하는 것을 막아야 했고, 선량한 사용자라도 실수로 중요한 데이터를 삭제하거나 수정하는 것을 방지해야 했다.

이러한 필요성에 의해 두 가지 핵심적인 질문에 대한 해답으로 인증과 인가가 탄생했다.

• 인증 (Authentication): “당신은 정말 당신이 맞습니까?” (Are you who you say you are?)

• 인가 (Authorization): “당신은 이 일을 할 자격이 있습니까?” (Are you allowed to do that?)

인증은 사용자의 신원을 확인하는 과정이다. 시스템은 사용자가 제시하는 정보를 통해 등록된 사용자인지 아닌지를 판단한다. 가장 고전적인 예가 바로 아이디와 비밀번호다. 사용자가 아이디와 비밀번호를 정확하게 입력하면, 시스템은 ‘아, 이 사람은 우리가 아는 그 사용자가 맞구나’라고 인식하고 문을 열어준다.

인가는 인증을 통과한 사용자에게 특정 권한을 부여하는 과정이다. 인증이 시스템의 문을 열어주는 열쇠라면, 인가는 그 문 안으로 들어온 사용자가 특정 방에 들어가거나, 특정 물건을 만질 수 있도록 허락해 주는 것이다. 예를 들어, 같은 웹사이트에 로그인했더라도 일반 사용자는 글을 읽기만 할 수 있지만, 관리자(Admin)는 글을 쓰고, 수정하고, 삭제할 수 있는 권한을 가진다. 이것이 바로 인가의 역할이다.

이 두 과정은 반드시 순차적으로 일어난다. 인증이 성공적으로 이루어져야만 인가 절차를 진행할 수 있다. 누구인지도 모르는 익명의 사용자에게 특정 권한을 부여할 수는 없기 때문이다.

2. 내부 들여다보기 인증과 인가의 구조와 작동 방식

인증과 인가는 어떻게 시스템 내부에서 구현되고 작동하는 것일까? 그 구조를 이해하면 두 개념의 차이를 더욱 명확하게 파악할 수 있다.

2.1 인증의 3요소 (Factors of Authentication)

인증은 사용자가 자신이 누구인지를 증명하는 방법, 즉 ‘인증 요소’에 따라 크게 세 가지 유형으로 나눌 수 있다. 보안 수준을 높이기 위해 이 요소들을 두 개 이상 조합하는 것을 **다중 인증(Multi-Factor Authentication, MFA)**이라고 부른다.

유형 (Type)	설명	예시	비유
지식 기반 (Something You Know)	사용자만이 알고 있는 정보	비밀번호, PIN 번호, 보안 질문에 대한 답변	나만 아는 암구호
소유 기반 (Something You Have)	사용자만이 가지고 있는 물리적 또는 논리적 객체	스마트폰 OTP 앱, 보안 토큰, 신용카드, 공인인증서	나만 가진 열쇠
존재 기반 (Something You Are)	사용자의 고유한 생체 정보	지문, 홍채, 얼굴 인식, 목소리	나의 고유한 신체 특징

예를 들어, 은행 앱에 로그인할 때 비밀번호(지식 기반)를 입력하고, 추가로 스마트폰으로 전송된 OTP 번호(소유 기반)를 입력하거나 지문(존재 기반)을 인식시키는 것이 바로 다중 인증의 대표적인 사례다. 하나의 인증 요소가 탈취되더라도 다른 요소가 방어선 역할을 해주기 때문에 보안성이 훨씬 강화된다.

2.2 인가 모델의 종류 (Authorization Models)

인증을 통과한 사용자에게 어떤 기준으로 권한을 부여할 것인지를 정하는 규칙의 집합을 인가 모델 또는 **접근 제어 모델(Access Control Model)**이라고 한다. 대표적인 모델들은 다음과 같다.

1. 접근 통제 목록 (Access Control List, ACL)

   • 개념: 가장 직관적이고 오래된 모델. 파일이나 폴더 같은 각 객체(Object)에 ‘누가(Subject) 어떤 작업(Operation)을 할 수 있는지’ 목록을 붙여두는 방식이다.

   • 작동 방식: 사용자가 특정 파일에 접근을 시도하면, 시스템은 그 파일의 ACL을 확인한다. 목록에 해당 사용자와 요청한 작업(읽기, 쓰기 등)이 허용된 것으로 명시되어 있으면 접근을 허용하고, 그렇지 않으면 거부한다.

   • 비유: 파티 초대 명단과 같다. 각 방(객체) 입구에 들어갈 수 있는 사람(주체)의 이름이 적힌 명단이 붙어 있는 것과 같다.

   • 장단점: 특정 객체에 대한 접근 권한을 관리하기는 쉽지만, 사용자별로 권한을 관리하기는 복잡하다. 사용자가 수백 명이라면 모든 객체의 ACL을 수정해야 하는 불편함이 있다.

2. 역할 기반 접근 통제 (Role-Based Access Control, RBAC)

   • 개념: 현대 시스템에서 가장 널리 사용되는 모델. 사용자에게 직접 권한을 부여하는 대신 ‘역할(Role)‘을 부여하고, 그 역할에 권한을 할당하는 방식이다.

   • 작동 방식:

     • 관리자는 ‘편집자’, ‘뷰어’, ‘관리자’와 같은 역할을 정의한다.

     • 각 역할에 필요한 권한(예: 편집자는 글쓰기/수정 가능, 뷰어는 글읽기만 가능)을 할당한다.

     • 사용자에게는 역할을 부여한다. (예: A는 편집자, B는 뷰어)

   • 비유: 회사의 직책과 같다. ‘마케팅팀 팀장’이라는 직책(역할)을 부여받으면, 그 직책에 따르는 결재 권한, 팀원 평가 권한 등이 자동으로 생기는 것과 같다.

   • 장단점: 사용자 관리가 매우 효율적이다. 새로운 사용자가 들어오면 적절한 역할만 부여하면 되고, 역할의 권한이 변경되면 해당 역할을 가진 모든 사용자의 권한이 한 번에 변경된다. 조직 구조를 반영하기에 용이하다.

3. 속성 기반 접근 통제 (Attribute-Based Access Control, ABAC)

   • 개념: 가장 유연하고 강력한 차세대 모델. 사용자의 속성, 접근하려는 객체의 속성, 그리고 환경적 속성(시간, 위치 등)을 종합적으로 고려하여 동적으로 접근을 제어한다.

   • 작동 방식: 미리 정의된 정책(Policy)에 따라 접근을 결정한다. 예를 들어, “재무팀 소속(사용자 속성)의 매니저(사용자 속성)는, 근무 시간(환경 속성) 내에, 회사 내부 네트워크(환경 속성)에서만, ‘1급 비밀’로 분류된(객체 속성) 재무 문서에 접근할 수 있다”와 같은 복잡한 규칙을 설정할 수 있다.

   • 비유: 고급 레스토랑의 복장 규정(드레스 코드)과 같다. 단순히 신분(역할)만 보는 것이 아니라, 시간(디너 타임), 복장(정장), 동반자 등 다양한 조건(속성)을 종합적으로 판단하여 입장을 허가하는 것과 유사하다.

   • 장단점: 매우 세밀하고 동적인 접근 제어가 가능하지만, 정책 설계와 관리가 복잡하고 시스템 성능에 영향을 줄 수 있다.

3. 실전 활용법 인증과 인가는 어떻게 사용될까?

이론적인 개념을 넘어, 인증과 인가가 실제 우리 삶과 디지털 서비스에서 어떻게 구현되고 있는지 살펴보자.

3.1 웹 애플리케이션의 인증과 인가 흐름

우리가 매일 사용하는 웹사이트나 앱의 로그인 과정은 인증과 인가의 교과서적인 예시다.

1. 인증 요청 (로그인 시도): 사용자가 브라우저에 아이디와 비밀번호를 입력하고 ‘로그인’ 버튼을 클릭한다.

2. 자격 증명 확인: 서버는 사용자가 입력한 정보를 데이터베이스에 저장된 정보와 비교한다. (보통 비밀번호는 암호화되어 저장됨)

3. 세션 또는 토큰 발급 (인증 성공): 정보가 일치하면 서버는 인증이 성공했음을 확인하고, 사용자를 식별할 수 있는 고유한 식별자인 세션 ID나 JWT(JSON Web Token) 같은 접근 토큰을 생성하여 사용자 브라우저에 보내준다.

   • 세션 기반 인증: 서버가 각 사용자의 로그인 상태를 저장하고, 브라우저에는 세션 ID만 쿠키로 저장하는 방식. 서버에 부담이 갈 수 있다.

   • 토큰 기반 인증 (JWT): 사용자의 정보와 권한 정보를 암호화하여 토큰 자체에 담아 전달하는 방식. 서버는 토큰의 유효성만 검증하면 되므로 확장성이 좋다. (Stateless)

4. 인가 요청 (API 호출): 사용자가 로그인 후 ‘내 정보 보기’나 ‘글쓰기’ 같은 기능을 요청하면, 브라우저는 요청과 함께 발급받은 세션 ID나 토큰을 서버로 보낸다.

5. 권한 확인 (인가 결정): 서버는 세션 ID나 토큰을 통해 사용자가 누구인지 식별하고, 해당 사용자가 요청한 작업을 수행할 권한이 있는지(예: 관리자 역할인지) 확인한다.

6. 결과 반환: 권한이 있으면 요청된 데이터를 보여주거나 작업을 수행하고, 권한이 없으면 ‘403 Forbidden’ 같은 에러 메시지를 반환한다.

3.2 OAuth 2.0과 OpenID Connect (OIDC)

“구글 계정으로 로그인하기”, “카카오 계정으로 로그인하기”와 같은 소셜 로그인은 어떻게 가능할까? 이것이 바로 OAuth 2.0이라는 인가 프레임워크 덕분이다.

• OAuth 2.0 (Authorization): 핵심은 **‘위임’**이다. 사용자가 직접 자신의 아이디와 비밀번호를 제3자 서비스(예: ‘오늘의집’)에 알려주는 대신, 자신이 신뢰하는 서비스(예: 구글, 카카오)에게 “오늘의집이 내 프로필 정보를 조회하도록 허락해 줘”라고 권한을 위임하는 방식이다. 오늘의집은 구글로부터 ‘접근 토큰(Access Token)‘을 발급받아 제한된 정보에만 접근할 수 있게 된다. 즉, OAuth 2.0의 본질은 인가에 초점이 맞춰져 있다.

• OpenID Connect (OIDC): OAuth 2.0은 인가만을 다루기 때문에, 사용자가 누구인지에 대한 정보(인증)를 표준화된 방식으로 제공하지 않는 단점이 있었다. OIDC는 OAuth 2.0 프로토콜 위에 구축된 **인증 계층(Identity Layer)**이다. OAuth 2.0의 인가 흐름을 그대로 사용하면서, 추가로 사용자의 신원 정보를 담은 **‘ID 토큰(ID Token)‘**을 제공한다. 이를 통해 제3자 서비스는 사용자가 누구인지 명확하게 확인할 수 있다.

간단히 말해, 소셜 로그인은 OIDC(인증)를 통해 사용자를 확인하고, OAuth 2.0(인가)을 통해 해당 서비스가 사용자 데이터에 접근할 권한을 얻는 과정이라고 할 수 있다.

4. 더 깊은 이야기 심화 개념과 미래 전망

인증과 인가의 세계는 기술의 발전에 따라 계속해서 진화하고 있다.

4.1 싱글 사인온 (Single Sign-On, SSO)

여러 개의 다른 서비스나 시스템에 접근할 때, 한 번의 인증 과정만으로 여러 시스템에 대한 접근 권한을 자동으로 얻게 해주는 기술이다. 사용자는 매번 아이디와 비밀번호를 입력할 필요가 없어 편리하고, 기업은 중앙에서 사용자의 접근을 통제할 수 있어 보안 관리가 용이하다. SAML, Kerberos와 같은 프로토콜이 SSO를 구현하는 데 사용된다.

4.2 제로 트러스트 아키텍처 (Zero Trust Architecture)

“절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)“라는 원칙에 기반한 현대적인 보안 모델이다. 기존의 ‘내부 네트워크는 안전하다’는 경계 기반 보안 모델에서 벗어나, 내부든 외부든 모든 접근 요청을 신뢰할 수 없는 것으로 간주하고 철저하게 인증하고 인가하는 방식이다. 사용자의 신원, 기기의 상태, 위치, 접근하려는 데이터의 민감도 등 다양한 컨텍스트를 실시간으로 분석하여 접근 권한을 동적으로 부여한다. 이는 ABAC 모델의 철학을 시스템 전체로 확장한 개념으로 볼 수 있다.

4.3 비밀번호 없는 인증 (Passwordless Authentication)

비밀번호는 여전히 가장 널리 쓰이는 인증 수단이지만, 유출이나 추측 공격에 취약하다는 근본적인 문제를 안고 있다. 이를 해결하기 위해 비밀번호를 아예 사용하지 않는 인증 방식이 주목받고 있다.

• FIDO (Fast Identity Online): 비밀번호 대신 생체 정보(지문, 얼굴)나 보안 키(YubiKey 등)를 사용하여 안전하고 편리하게 인증하는 기술 표준이다. 사용자의 생체 정보는 개인 기기 밖으로 절대 나가지 않으므로 서버가 해킹당해도 유출될 위험이 없다.

• Magic Links: 이메일이나 SMS로 일회용 로그인 링크를 전송하는 방식. 사용자는 받은 링크를 클릭하는 것만으로 인증을 완료할 수 있다.

5. 결론: 디지털 세상의 보이지 않는 문지기

인증과 인가는 우리가 디지털 세상을 안전하고 질서 있게 살아갈 수 있도록 지켜주는 보이지 않는 문지기와 같다. 인증은 “누구신가요?”라고 물으며 신원을 확인하고, 인가는 “무엇을 도와드릴까요?”라고 물으며 허용된 범위 내에서 서비스를 제공한다.

이 두 개념을 명확히 이해하는 것은 단순히 기술적 지식을 쌓는 것을 넘어, 우리가 사용하는 서비스가 어떻게 우리의 정보를 보호하고 있는지, 그리고 더 안전한 디지털 환경을 만들기 위해 어떤 기술들이 발전하고 있는지를 꿰뚫어 볼 수 있는 통찰력을 제공한다. 앞으로 우리가 마주할 수많은 디지털 문 앞에서, 인증과 인가의 원리를 기억한다면 그 문이 어떻게 열리고 닫히는지 훨씬 더 깊이 있게 이해할 수 있을 것이다.