조건부 액세스 정책이 적용되지 않는 문제: Microsoft Entra 문제를 진단하고 해결하는 방법

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

조건부 액세스 정책이 적용되지 않는 문제를 해결하려면 명확한 업무 시나리오, 검증된 보안 및 데이터 경계, 책임 있는 담당자가 필요합니다. 의도한 결과를 먼저 정의하고, 대표 사용자와 함께 구성과 정책 영향을 테스트한 뒤, 결정 사항과 지원 절차를 문서화하는 것이 좋습니다. 그리고 요구 사항과 Microsoft 365 기능이 바뀜에 따라 접근 방식을 정기적으로 검토합니다.

Automatically translated with AI from the original post. Read the English original

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

조건부 액세스 정책이 적용되지 않음: 실무 체크리스트

시나리오, 담당자, 결정 기준을 정의합니다.
권한, 정책, 보안 및 사용자 영향을 검증합니다.
파일럿으로 테스트하고 지원 및 검토 결정을 문서화합니다.

최신 안내는 Microsoft Learn을 참조하십시오.

마지막 검토: 2026년 7월.

조건부 액세스는 Microsoft Entra(이전 명칭 Azure AD)에서 ID 보호의 핵심입니다. 그러나 로그에서 "NotApplied" 상태가 보이면 액세스 제어가 제 역할을 하지 못하고 있다는 뜻이며, 조직이 잘못된 사용자에게 노출되어 있을 수 있습니다. 이 문제는 규정 준수 감사, 보안 사고 대응, 또는 통제되지 않은 사용자 행동이 허점을 드러낼 때까지 조용히 숨어 있는 경우가 많습니다.

까다로운 점은 조건부 액세스 정책이 적용되지 않는 이유가 하나뿐인 경우가 드물다는 것입니다. 설정이 누락되었거나, 서비스 주체가 허점을 통과하거나, 정책이 난립하여 상황을 흐리게 만드는 경우일 수 있습니다. 조건부 액세스가 작동하지 않으면 문제 해결은 금방 복잡해집니다. 따라서 Microsoft Entra가 정책을 평가하고 건너뛰는 방식을 이해하는 것이 중요합니다. 그래야 보이지 않는 틈새를 메우고, 사용자 불편을 줄이며, 보안 팀의 우려를 해소할 수 있습니다.

이 가이드에서는 정책이 왜 적용되지 않았는지 진단하는 명확한 절차를 안내하고, 흔히 빠지는 함정을 피하는 방법을 설명합니다. 이를 통해 의도한 대로 정확히 작동하는 조건부 액세스 정책을 구축할 수 있습니다. 더도 덜도 아닌 정확한 정책 말입니다.

Azure에서 조건부 액세스 평가를 이해하고 정책에 "NotApplied"가 표시되는 이유

Microsoft Entra의 조건부 액세스는 규칙을 적용하면 결과가 나오는 단순한 구조처럼 보이지만, 내부적으로는 빠르게 복잡해집니다. "NotApplied" 문제를 해결하기 전에, 사용자가 로그인을 시도하는 순간 Entra가 모든 정책을 어떻게 처리하는지 알아야 합니다. 모든 정책이 관리 포털에서 확인한 내용만으로 적용되거나 빗나가는 것은 아닙니다.

정책이 "NotApplied"로 표시되면 Entra가 로그인을 해당 정책에 대해 평가했지만, 규칙이 상황에 맞지 않는다고 판단했다는 뜻입니다. 사용자, 디바이스, 앱 또는 로그인 컨텍스트가 정책 범위와 일치하지 않았을 수도 있고, 우선순위가 더 높은 다른 규칙이 먼저 적용되어 필요한 결과를 이미 제공했을 수도 있습니다.

핵심은 평가 순서와, 정책이 겹칠 때 Entra가 어느 정책을 우선 적용하는지입니다. 여기에 정책 제외, 서비스 주체 흐름, 명명된 위치의 특이 동작, 그리고 일부 Microsoft 365 서비스의 고유한 동작도 관련이 있습니다. 많은 정책이 때로는 명확하지 않은 이유로 건너뛰어지며, "NotApplied" 표시가 문제가 있다는 유일한 단서가 되기도 합니다.

이러한 이유를 깊이 파악하지 않고 "NotApplied"를 있는 그대로 인식하지 못하면, 보안 허점을 놓치거나 정상 사용자의 로그인에 불편을 초래할 위험이 있습니다. 이때 로그인 로그가 도움이 됩니다. 적용된 정책, 건너뛴 정책, 무시된 정책을 구분해 실제로 무슨 일이 일어나고 있는지 정확히 파악할 수 있습니다. 조건부 액세스와 위험 관리에 대해 더 깊이 알고 싶다면, 대규모 조직을 위한 검증된 전략을 다룬 정책 난립과 거버넌스 관련 이 팟캐스트 에피소드를 참고하십시오.

Microsoft Entra 로그인 로그로 정책 적용 격차 식별하기

Microsoft Entra 로그인 로그는 조건부 액세스 문제를 파악하는 핵심 도구입니다. 각 로그 항목에는 로그인에 대해 평가된 정책이 상세히 기록되며, "Applied", "NotApplied", "Failure", "Success"와 같은 상태를 명확히 확인할 수 있습니다. "NotApplied"는 Entra가 정책을 무시했다는 뜻이 아니라, 조건이 충족되지 않았거나 다른 정책이 우선했다는 의미입니다.

로그인 로그에서 "Conditional Access" 탭을 확인합니다. 여기에서 사용자, 디바이스, 애플리케이션 컨텍스트를 교차 확인하여 정책이 트리거되지 않은 이유를 찾을 수 있습니다. 서비스 주체(service principal) 로그인이나 앱 전용(app-only) 흐름 같은 흔적을 주의해서 보십시오. 이런 로그인은 대개 "NotApplied"로 표시되는데, CA가 대화형이 아닌(non-interactive) 토큰을 처리하지 않기 때문입니다. 이러한 로그를 읽는 방법을 아는 것은 보안 공백을 찾고 잘못된 구성을 배제하는 데 매우 중요합니다. 기준 정책과 신뢰 문제 추적에 대한 자세한 내용은 Conditional Access 신뢰 공백에 대한 이 가이드를 참고하십시오.

Conditional Access 정책 적용을 방해하는 가장 흔한 잘못된 구성

솔직히 말해서, Conditional Access는 작은 실수가 큰 보안 문제로 번질 수 있는 도구입니다. "NotApplied" 상태의 가장 흔한 원인은? 단순하게 말해 잘못된 구성입니다. 잘못 지정된 제외 항목, 느슨한 위험 임계값, 간과된 레거시 프로토콜 모두 모두가 단단히 잠갔다고 생각한 보안 문을 열어 둘 수 있습니다.

범위와 조건의 불일치는 특히 위치 설정이나 위험 로그인 로직에서 자주 발생합니다. 예상치 못한 장소에 있는 사용자이든, 오래된 인증을 사용하는 애플리케이션이든, 적용이 예상하기 어려운 방식으로 무너집니다. 여기에 "모두 필요"를 "하나 이상 필요"로 혼동하는 것처럼 액세스 제어의 미묘한 특성까지 더해지면, 의도한 규칙이 얼마나 쉽게 빠져나갈 수 있는지 알 수 있습니다.

게다가 레거시 인증은 Conditional Access와 MFA를 우회하는 뒷길과 같습니다. 많은 조직이 이 허점을 잊고 있다가 컴플라이언스 검토에서 문제가 드러나곤 합니다. 가장 숙련된 관리자는 작업을 꼼꼼히 다시 확인하고, Microsoft 365가 성장함에 따라 새로 생기는 허점을 계속 살펴보면서 감각을 유지합니다. 미묘한 구성 드리프트가 Microsoft 자체의 컴플라이언스 결과까지 어떻게 바꿀 수 있는지 알고 싶다면, 이 Microsoft 365 컴플라이언스 드리프트 팟캐스트가 많은 깨달음을 줄 것입니다.

Conditional Access 정책의 위치 및 위험 조건 함정

잘못 구성된 명명된 위치: 명명된 위치의 IP 범위가 잘못되었거나, 신뢰할 수 있는 주소가 누락되었거나, 국가 목록이 불완전하면 일부 로그인이 경고 없이 정책을 우회할 수 있습니다.
부적절한 위험 수준: 위험한 사용자 또는 위험한 로그인 임계값을 너무 높게(또는 너무 낮게) 설정하면 실제 위험이 통과하거나, 사용자가 잘못된 경보로 차단될 수 있습니다.
누락되었거나 지나치게 넓은 위치: 필요한 모든 IP 범위나 클라우드 앱을 포함하지 않거나, 과거의 "신뢰할 수 있는" 지역을 그대로 남겨 두면 적용이 고르지 않게 됩니다.
디바이스 상태의 사각지대: 디바이스 규정 준수 또는 하이브리드 Azure AD 조인을 고려하지 않으면 관리되지 않는 엔드포인트에서 발생하는 로그인이 빠지게 됩니다.

이러한 실수를 피하려면, 이 Azure 거버넌스 가이드에서 설명하듯이 정기적인 감사와 명확한 거버넌스가 큰 차이를 만듭니다.

Conditional Access를 실패하게 만드는 액세스 제어 및 권한 부여 규칙

상충하는 권한 부여 컨트롤("모두 필요" 대 "하나 이상 필요"): MFA, 규정 준수 디바이스, 승인된 앱처럼 모든 권한 부여 컨트롤을 요구하도록 정책을 설정하면, 충족되지 않은 요구 사항 하나 때문에 "NotApplied" 또는 의도하지 않은 거부가 발생합니다.
불명확한 차단 액세스 로직: 정책에서 "권한 부여"와 "차단" 컨트롤을 실수로 함께 활성화하면 서로 상쇄되어 예측할 수 없는 적용 결과가 나오거나(차단 조건이 트리거되지 않으면 "NotApplied" 결과), 결과가 일정하지 않습니다.
중복되거나 제외된 사용자 그룹: 우선순위가 높은 정책에 광범위한 그룹을 포함하면 더 세분화된 정책을 덮어써서, 조건이 트리거될 기회조차 얻지 못해 "NotApplied"로 보이게 만듭니다.
잘못된 클라우드 앱 대상 지정: 잘못된 클라우드 앱에 정책을 적용하거나 핵심 앱을 아예 누락하면, 의도한 제한이 전혀 작동하지 않습니다.

공백을 남기는 레거시 인증 및 MFA 우회

레거시 프로토콜: POP, IMAP, SMTP 같은 구형 프로토콜은 Conditional Access와 MFA를 우회하여 Exchange Online 및 기타 클래식 엔드포인트를 통해 방어를 빠져나갑니다.
관리되지 않는 앱 등록: 조건부 액세스가 적용되기 전에 등록되었거나 클라이언트 자격 증명 흐름을 사용하는 앱은 최신 정책 검사를 받지 않으므로, 공격자나 사정을 모르는 사용자가 아무런 확인 없이 리소스에 접근할 수 있습니다.
서비스 계정에 대한 MFA 제외: 레거시 시스템이나 공유 사서함을 일괄적으로 제외하면 핵심 보호 기능이 비활성화되어, 공격자가 노리는 사각지대가 생깁니다.
앱 간 허점: 클라이언트 앱 간의 잘못된 통합으로 인해 MFA 요청이 필요한 상황에서도 이를 건너뛸 수 있습니다. 이러한 제로 트러스트 공백을 막는 방법을 자세히 알아보려면 Microsoft 365/Dynamics 365 제로 트러스트 가이드를 확인하세요.

Microsoft 365 앱, B2B 및 디바이스 플랫폼 전반의 조건부 액세스 문제 해결

조건부 액세스 적용은 가장 약한 고리만큼만 강력합니다. Microsoft 365에는 고유한 서비스 특성이 있고, B2B 게스트/파트너 로그인은 다르게 동작하며, 디바이스에 대한 정책 적용도 항상 예상대로 이루어지지는 않습니다. 이러한 세부 사항 때문에 잘 설계된 정책도 문제가 생길 수 있으며, "NotApplied" 흔적이 남기도 합니다.

특히 파트너 프로젝트가 끝난 뒤 잊힌 게스트 계정이 대표적인 예입니다. 이러한 계정의 신뢰 경계와 수명 주기는 내부 사용자와 다르므로, 정책이 이를 놓치거나 불완전하게 적용될 수 있습니다. Exchange Online이나 SharePoint 같은 Microsoft 365 서비스별 동작은 앱 권한부터 세션 제한 시간에 이르기까지 복잡성을 한층 더 높입니다.

디바이스 측면도 살펴봐야 합니다. 사용자 엔드포인트가 어떻게 조인, 등록 또는 관리되는지(예: 하이브리드 Azure AD 조인, Intune 규정 준수, 모바일 디바이스 플랫폼)에 따라 어떤 정책이 적용되고 건너뛰어지는지가 결정됩니다. 여러 환경에 걸친 조건부 액세스 적용을 제대로 파악하려면, 실시간으로 공백을 찾아낼 수 있는 환경별 체크리스트를 만드십시오. 그래야 야간에 지원 전화를 받는 상황이 생기기 전에 문제를 발견할 수 있습니다. 게스트 사용자와 Teams 거버넌스에 관한 거버넌스 함정을 더 자세히 알아보려면 게스트 계정 위험 전략과 Teams 거버넌스 개선 방안을 참고하여 변화하는 위험을 폭넓게 이해하시기 바랍니다.

조건부 액세스에 영향을 주는 Microsoft 365 서비스별 특성

조건부 액세스와 관련해서는 모든 Microsoft 365 워크로드가 같은 규칙을 따르지는 않습니다. Exchange Online, SharePoint, Teams는 고유한 API, 엔드포인트, 세션 관리 로직을 가지고 있습니다. 일부 프로토콜이나 모바일 앱 액세스는 특히 레거시 엔드포인트나 OAuth 동의 앱이 관련된 경우 최신 CA 설정을 항상 따르지는 않습니다.

앱이 Exchange Online PowerShell이나 레거시 흐름을 통한 SharePoint Online 등 다른 인증 방식을 사용하면 정책이 "NotApplied"로 표시될 수 있습니다. 이는 동의 피싱이나 토큰 탈취를 통한 공격 체인의 빌미가 될 수 있으므로, 워크로드별로 표적화된 해결 조치가 필요합니다. 이러한 서비스 수준의 공격 벡터와 보호 방법에 대해서는 Microsoft 365 공격 체인 해결 방법을 참고하십시오.

B2B 협업 및 게스트 사용자를 위한 조건부 액세스

B2B 신뢰 경계: 게스트 사용자의 소속 조직은 자체 보안 규칙을 가지고 있을 수 있으며, 귀사의 CA가 항상 이를 우선 적용하지는 않습니다. 따라서 정책 트리거가 일관되게 작동하지 않을 수 있습니다.
초대와 로그인 흐름: 조건부 액세스는 초대 시점이 아니라 로그인 시점에 적용됩니다. 게스트가 한 번도 로그인하지 않으면 정책도 실행되지 않습니다.
모니터링 및 알림: 알림을 설정하고 Entra 로그를 검토하여 게스트 로그인 이상 징후를 지속적으로 확인하십시오. 이를 통해 외부 공유나 남아 있는 게스트 액세스가 규정 준수 위험으로 이어지지 않도록 할 수 있습니다.
검토 및 만료: 정기적인 액세스 검토와 기간이 정해진 초대는 환경을 깔끔하게 유지하고 공격 표면을 줄이는 데 도움이 됩니다. 최상의 결과를 얻으려면 외부 공유 제어에 관한 실용 가이드에 설명된 대로 적용 범위를 강화한 지속적인 감사 프로세스를 운영하십시오.

조건부 액세스의 Windows 및 디바이스 규정 준수 과제

디바이스 플랫폼 제외: Windows, iOS, Android를 대상으로 하는 정책은 디바이스가 인식되지 않거나 규정 준수 기준을 벗어나면 사용자를 아예 건너뛸 수 있습니다.
하이브리드 Azure AD 조인 함정: 하이브리드 조인이든 다른 방식이든 디바이스가 올바르게 조인되지 않으면 조건부 액세스 디바이스 검사를 통과하지 못해 정책 적용이 차단됩니다.
Intune 통합 공백: Intune 기반 규정 준수 정책은 등록에 시간이 걸릴 수 있으며, 그 사이에는 정책 적용이 일관되지 않아 보이는 구간이 생길 수 있습니다.
규정 준수 미충족 또는 인증되지 않은 디바이스: 탈옥된 기기, 오래된 기기, 관리되지 않는 기기에서 발생한 로그인은 일반적으로 디바이스 기반 보호 정책을 트리거하지 않습니다. 규정 준수와 위협 보호를 통합하는 방법은 이 Microsoft 365 Defender 및 Purview 개요에서 더 자세히 확인할 수 있습니다.

조건부 액세스를 예측 불가능하게 만드는 정책 난립과 중복 정리하기

대규모 환경에서는 조건부 액세스 정책이 쉽게 많아집니다. 빈틈없는 보호를 원하지만, 그 결과 중복되거나 충돌하는 규칙이 너무 많아져서 실제로 어떤 정책이 적용될지 아무도 예측하지 못하는 상황에 이를 수 있습니다. 정책이 많아지면 복잡성이 커지고, 보이지 않는 공백이 생기며, 문제 해결도 어려워집니다.

정책 난립은 관리자가 선의로 "정책 하나만 더"를 계속 쌓아 올릴 때 생기며, 숨은 적용 사각지대를 만듭니다. 특히 그룹 포함이나 예외에 의존하거나 테스트 정책을 정리하지 않고 방치할 때 그 위험이 커집니다. 여기에 서비스 간 종속성까지 더해지면 상황은 더 나빠집니다. 클라우드 앱 하나를 변경하거나 새 통합을 추가하면, 예전에는 안정적으로 작동하던 정책 체인이 무너질 수 있습니다.

현명한 방법은 정책을 정기적으로 감사하고 정리하는 것입니다. 기본이 되는 포괄적 정책에 집중하고, 기간이 정해진 예외는 최소화하십시오. 모든 정책에 명확한 목적과 문서화된 결과가 있어야 하며, 실행 가능한 보고와 함께 운영해야 합니다. 그리고 환경이 "설정하고 잊어도 된다"고 가정하지 마십시오. 조건부 액세스에서 신뢰 격차를 모니터링하고 섀도 IT를 다루는 방법은 이 CA 신뢰 문제 플레이북과 섀도 IT 해결 가이드를 참고하십시오.

서비스 종속성 관리와 정책 난립 방지

현재 정책 감사: 활성 상태인 모든 CA 정책을 정기적으로 목록화하고 문서로 남기며, 불필요하게 중복되거나 오래된 규칙이 있는지 확인하십시오.
연결된 서비스 매핑: Azure, Microsoft 365, 타사 앱 전반에 걸친 CA 종속성을 파악하여 새 통합으로 생기는 적용 공백을 찾아내십시오.
통합 및 정리: 유사한 정책을 합치고 오래되었거나 사용하지 않는 정책은 폐기하십시오. 넓고 잘 문서화된 규칙을 중심으로 하고, 필요한 예외만 대상을 좁혀 적용하십시오.
AI 및 자동화 위험 검토: 백그라운드 프로세스를 잊지 마십시오. AI 에이전트와 자동화에도 섀도 IT 위험을 차단할 수 있도록 별도의 범위 지정 제어가 필요합니다. 자세한 내용은 AI 에이전트 섀도 IT 위협에서 확인할 수 있습니다.

"모두 선택" 결과와 보고를 활용해 정책 영향을 안전하게 테스트하기

먼저 보고 전용 모드 사용: 배포하기 전에 보고 전용 모드를 사용해 정상적인 사용자를 차단하지 않고 정책 영향을 시뮬레이션하십시오. 기본 제공 보고 대시보드로 효과를 분석하십시오.
"모두 선택" 결과는 신중하게 사용: 전체 롤아웃 전에 안전한 테스트 환경에서 모든 적용 작업을 실행하여 예상치 못한 결과나 계획되지 않은 예외를 찾아내십시오.
영향받는 사용자와 앱 문서화: 변경으로 영향을 받는 모든 사용자, 그룹, 앱의 기록을 남겨 두십시오. 그래야 이해관계자와 소통할 수 있고, 문제가 생겼을 때 방향을 되돌릴 수 있습니다.
사용자와 시스템 피드백 수집: 사용자가 문제를 즉시 신고하도록 독려하고, 정책으로 인한 잠금이 있는지 시스템 오류 로그를 확인하십시오.
사고 대응을 위해 감사 로그 활용: Microsoft Purview 감사와 테넌트 로그를 사용해 사용자 활동을 추적하고 정책 결과를 검증하십시오. 감사에 대한 지침은 이 Purview 감사 심층 분석을 참고하십시오.

잠겼거나 조건부 액세스 정책이 적용되지 않을 때 대처 방법

모든 Conditional Access 관리자가 한 번쯤 겪는 악몽이 있습니다. 새 정책을 배포했더니 갑자기 본인이나 팀 전체가 테넌트에서 잠겨 버리거나, 문제를 해결해 줄 것이라 믿었던 정책이 전혀 작동하지 않는 상황입니다. 에스컬레이션 요청이 쌓이고, 비즈니스를 계속 운영하려면 탄탄한 복구 전략이 필요하다는 사실을 깨닫게 됩니다.

좋은 소식은 상황을 더 악화시키지 않고 액세스를 신속하게 되찾을 수 있는 실행 절차가 있다는 것입니다. 긴급 액세스(break-glass) 계정을 미리 준비하고, 롤백 및 예외 적용 방법을 갖춘 뒤, 필요하면 Microsoft 지원 또는 보안 팀에 에스컬레이션하면 됩니다.

하지만 복구에서 멈추면 안 됩니다. 근본 원인을 해결하지 않으면 다음에 정책을 조정할 때 같은 문제가 반복됩니다. 그래서 서비스를 복원하는 스위치를 올바르게 전환하는 것만큼이나 사후 검토, 이해관계자 업데이트, 지속적인 테스트, 그리고 문서화된 교훈이 중요합니다. 도구 소유권이 분산되면 거버넌스가 어떻게 무너지는지 알고 싶다면 거버넌스 실패에 관한 심층 분석을 살펴보시기 바랍니다.

Conditional Access 실패 시 단계별 복구 방법

긴급 액세스(Break-Glass) 계정 사용: 전역 관리자 권한이 있으면서 Conditional Access 정책이 적용되지 않은 긴급 계정을 최소 한 개 유지하십시오. 이 계정으로 로그인하면 언제든 액세스를 되찾을 수 있습니다.
임시 예외 정책 적용: 잠금 상태라면 영향을 받는 계정이나 그룹에 대해 예외 정책을 생성하거나 활성화하십시오. 그래야 정상적인 액세스를 회복하고 근본 문제를 해결할 수 있습니다.
관리자 재정의를 위한 에스컬레이션: 1차 조치가 실패하면 Microsoft 지원 또는 보안 팀에 연락하여 직접 개입이나 테넌트 잠금 해제를 요청하십시오.
최근 정책 변경 롤백: 새로 추가했거나 최근에 변경한 Conditional Access 규칙을 마지막으로 정상 작동한 구성으로 되돌리고, 로그인 로그를 확인하여 문제가 해결되었는지 검증하십시오.

미적용 문제 확인 후 다음 단계 및 효과적인 정책 검토

교훈 문서화: 무엇이 잘못되었는지, 어떤 조치가 문제를 해결했는지, 앞으로 어디에 통제 장치나 감사가 필요한지를 정확히 기록하십시오.
보고 전용 모드에서 테스트: 정책을 다시 켜기 전에 Entra의 보고 전용 모드를 사용하여 새로운 장애를 일으키지 않고 문제를 탐지할 수 있는지 확인하십시오.
피드백 수집 및 반영: 영향을 받은 사용자와 시스템 로그에서 피드백을 받고, 이를 바탕으로 남은 공백을 메우십시오.
이해관계자와 소통: 영향을 받은 모든 팀, IT 리더십, 외부 파트너, 사용자에게 사고 내용, 해결 과정, 장기적인 예방 계획을 공유하십시오.
정기 거버넌스 실행 약속: Conditional Access 정책에 대한 정기 검토, 보고, 업데이트 일정을 잡으십시오. 거버넌스 착각에 관한 팟캐스트에서 말하듯, 좋은 거버넌스는 한 번 설정하고 잊는 체크박스 작업이 아니라 지속적으로 이어가는 실천이기 때문입니다.

🎧 함께 들어보시면 좋은 에피소드

Microsoft Entra의 ID 거버넌스
액세스 및 수명 주기 통제를 살펴봅니다.
Microsoft Purview – 쉽게 이해하기
보호 및 규정 준수 관점을 살펴봅니다.
Microsoft 365 거버넌스 운영 모델
지속 가능한 소유권과 의사 결정 체계를 이해합니다.