Power BI와 Microsoft Fabric에서 동적 행 수준 보안 구현하기: 아키텍처, DAX 패턴, 엔터프라이즈급 거버넌스

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Power BI와 Microsoft Fabric에서 동적 행 수준 보안을 구현하여 사용자별 데이터 접근을 제어하고, 규정 준수를 보장하며, 조직의 변화에 대응하는 방법을 알아봅니다.

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

동적 행 수준 보안은 변화하는 시스템으로 보아야 합니다. 조직과 함께 성장하고 변화합니다. 데이터 모델 설계, DAX 식, 사용자 ID, 거버넌스가 모두 Power BI와 Microsoft Fabric에서 보안이 어떻게 작동할지를 결정하는 데 영향을 줍니다. 올바르게 구성하면 특정 데이터를 누가 볼 수 있는지 선택할 수 있습니다.

핵심 요약

• 동적 행 수준 보안은 회사의 필요에 맞게 변경됩니다. 특정 데이터를 누가 볼 수 있는지 선택할 수 있게 해 주며, 이는 각 사용자의 ID를 확인하여 이루어집니다.

• 클라우드에서 보안을 적용하려면 USERPRINCIPALNAME()을 사용하십시오. 이 함수를 사용하면 사용자가 자신의 데이터만 볼 수 있으며, 정보를 안전하게 지키는 데 도움이 됩니다.

• 보안 설정과 사용자 그룹을 자주 점검하십시오. 이렇게 하면 사용자가 보면 안 되는 데이터를 보는 일을 막을 수 있으며, 데이터를 안전하게 유지하는 데 도움이 됩니다.

• 사용자 권한을 관리할 수 있도록 명확한 보안 테이블을 만드십시오. 회사가 성장하더라도 누가 무엇을 볼 수 있는지 제어하는 데 도움이 됩니다.

• 실제 사용자와 함께 클라우드에서 보안 규칙을 테스트하십시오. 이를 통해 데이터가 안전한지 확인할 수 있으며, 사용자가 허용된 데이터만 볼 수 있도록 합니다.

행 수준 보안 시스템 다시 생각하기

모델 중심 시스템으로서의 보안

행 수준 보안은 분석 플랫폼의 여러 구성 요소를 연결하는 시스템입니다. 데이터 모델을 만들 때 데이터 보안의 구축이 시작됩니다. 테이블을 구성하고 연결하는 방식과 역할을 만드는 방식에 따라 사용자가 데이터를 보는 방식이 달라집니다. 회사가 성장하거나 새로운 팀이 합류하면 보안 규칙도 업데이트해야 합니다. 행 수준 보안은 한 번 설정하고 잊어버리는 것이 아닙니다. 비즈니스가 변하고 새로운 요구가 생기면 함께 변해야 합니다.

팁: 데이터 모델을 자주 점검하십시오. 잘 설계된 모델은 보안을 더 쉽게 만들고 오류를 줄이는 데 도움이 됩니다.

모델에는 명확한 관계와 별도의 보안 테이블이 있어야 합니다. 이렇게 하면 특정 데이터를 누가 볼 수 있는지 제어하고 민감한 데이터를 보호할 수 있습니다. 동적 행 수준 보안을 사용하면 사용자가 보는 데이터를 Fabric 내의 그룹이나 직무에 맞출 수 있습니다. 이렇게 하면 회사가 변할 때 권한을 빠르게 변경할 수 있습니다.

정적 행 수준 보안 vs. 동적 행 수준 보안

데이터 보안을 설정하는 방법에는 크게 정적 행 수준 보안과 동적 행 수준 보안의 두 가지가 있습니다. 정적 보안은 고정된 규칙을 사용합니다. 그룹마다 역할과 필터를 만듭니다. 소규모 팀이나 접근 권한이 자주 바뀌지 않는 경우에 적합합니다. 동적 행 수준 보안은 로그인한 사용자와 매핑 테이블을 사용합니다. 사용자를 확인하여 그 사용자가 볼 데이터를 즉시 바꿉니다. 사용자가 많고 규칙이 자주 변하는 대규모 기업에 더 적합합니다.

다음 표에서 차이점을 확인할 수 있습니다:

동적 행 수준 보안은 접근을 제어하는 방법을 더 다양하게 제공합니다. USERPRINCIPALNAME()과 매핑 테이블 같은 요소를 사용하여 사용자를 적합한 데이터에 연결합니다. 정적 보안은 설정이 간단하지만, 회사가 성장하거나 크게 변할 때는 잘 작동하지 않습니다.

• 정적 행 수준 보안은 고정된 규칙으로 데이터를 제한합니다.

• 동적 행 수준 보안은 사용자가 누구인지에 따라 그 사용자가 보는 데이터를 바꿉니다.

• 동적 보안은 규칙이 많은 대규모 기업에 가장 적합합니다.

데이터를 안전하게 지키려면 필요에 가장 맞는 방식을 선택하십시오. 충분한 계획과 탄탄한 모델이 있으면 민감한 데이터를 보호하고 분석 환경을 안전하게 유지할 수 있습니다.

Fabric의 동적 행 수준 보안 패턴

DAX 함수: USERPRINCIPALNAME()과 USERNAME() 비교

Fabric에서 ID가 어떻게 작동하는지 이해하는 것이 중요합니다. 행 수준 보안을 설정하는 데 도움을 주는 두 가지 주요 함수가 있습니다. 바로 USERPRINCIPALNAME()과 USERNAME()입니다. 두 함수 모두 보고서를 보는 사용자를 확인합니다. USERPRINCIPALNAME()은 클라우드의 사용자 이메일을 반환합니다. USERNAME()은 주로 Power BI Desktop에서 로컬 계정 이름을 반환하는 경우가 많습니다. 클라우드에서 USERNAME()을 사용하면 제대로 작동하지 않을 수 있으며, 이는 데이터 보안을 약하게 만들 수 있습니다.

팁: Fabric에서 동적 행 수준 보안을 적용할 때는 항상 USERPRINCIPALNAME()을 사용하십시오. 이 함수는 사용자의 클라우드 이메일 주소와 일치하므로 데이터를 안전하게 보호할 수 있습니다.

잘못된 함수를 사용하면 사용자가 보아서는 안 되는 데이터를 볼 수 있습니다. Desktop에서만 테스트하지 말고 클라우드에서 보안을 반드시 테스트해야 합니다.

안전한 DAX 패턴과 안티 패턴

데이터를 안전하게 보호하려면 동적 행 수준 보안을 위한 견고한 DAX 패턴이 필요합니다. 가장 좋은 방법은 매핑 테이블과 동적 규칙을 사용하는 것입니다. 이렇게 하면 누가 어떤 데이터를 볼 수 있는지 제어할 수 있습니다.

• 행 필터를 사용하면 사용자가 볼 수 있는 범위를 제한할 수 있습니다. 지역, 부서 또는 계정 단위로 데이터를 차단할 수 있습니다.

• 열 마스크를 사용하면 사용자가 누구인지에 따라 데이터를 숨기거나 변경할 수 있습니다.

좋은 DAX 패턴은 조회를 사용해 사용자를 해당 그룹과 매칭합니다. 그룹이 많은 회사에 특히 효과적입니다. 다음은 좋은 예입니다:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

이 패턴은 사용자의 이메일을 확인하고 해당 그룹을 찾습니다. 이를 활용하면 올바른 데이터만 표시할 수 있습니다. 이 방식은 단순히 이메일을 매칭하는 것보다 낫습니다. 회사가 성장해도 잘 작동하며 데이터를 안전하게 보호합니다.

참고: 액세스 제어에 이메일을 하드코딩하거나 계산 열을 사용하지 마십시오. 사용자가 변경되거나 회사 규모가 커지면 이런 방식은 작동하지 않을 수 있습니다.

일부 잘못된 패턴은 데이터 유출을 일으킬 수 있습니다:

• 클라우드에서 USERNAME()을 사용하기.

• 사용자 이메일이나 도메인을 하드코딩하기.

• 보안 로직을 계산 열에 넣기.

항상 동적 규칙과 매핑 테이블을 사용하십시오. 그래야 데이터 모델이 단순하게 유지되고 데이터가 안전하게 보호됩니다.

계층 구조와 PATH() 함수

관리자, 팀 또는 부서별 보안이 필요한 경우가 있습니다. 이때 계층 구조가 도움이 됩니다. DAX의 PATH() 함수를 사용하면 상위-하위 관계를 구성할 수 있습니다. 이를 통해 각 수준에서 누가 무엇을 볼 수 있는지 제어할 수 있습니다.

예를 들어 직원 ID와 관리자 ID가 담긴 테이블을 만들 수 있습니다. PATH()는 각 직원에서 상사까지 이어지는 체인을 만듭니다. 그다음 DAX로 각 수준의 데이터를 필터링할 수 있습니다.

PATH(Employee[EmployeeID], Employee[ManagerID])

이 함수는 대규모 회사의 동적 행 수준 보안을 설정하는 데 도움이 됩니다. 관리자가 자기 팀의 데이터를 볼 수 있도록 할 수 있습니다. 또한 일반 직원이 지나치게 많은 데이터를 보지 못하도록 막을 수도 있습니다.

팁: 계층 구조에 따른 보안에는 PATH()를 사용하십시오. 이렇게 하면 데이터 모델이 유연해지고 데이터가 안전하게 보호됩니다.

행 필터, 열 마스크, 계층 함수를 함께 사용할 수 있습니다. 이를 통해 민감한 데이터를 보호하고 회사가 성장하는 동안에도 액세스를 제어할 수 있습니다.

역할 및 관계 아키텍처

보안 테이블 설계

동적 행 수준 보안을 위해 보안 테이블을 만들어야 합니다. 이 테이블은 사용자가 어떤 데이터를 볼 수 있는지 보여줍니다. 사용자 이메일, 그룹, 액세스 수준에 대한 열을 사용하십시오. 이렇게 구성하면 회사가 성장하는 동안에도 데이터를 안전하게 보호할 수 있습니다.
역할을 만들 때는 엄격한 역할과 개방형 역할을 분리하십시오. 어떤 역할이 모든 데이터를 보도록 허용하면, 행 수준 보안이 적용된 다른 역할이 제대로 작동하지 않을 수 있습니다. 데이터를 안전하게 지키려면 역할끼리 충돌하지 않도록 해야 합니다.

• 사용자와 권한을 명확하게 나타내는 열로 보안 테이블을 만드십시오.

• 역할이 서로 겹쳐 문제가 생기지 않도록 역할을 분리해 두십시오.

• 변경 사항을 따라잡을 수 있도록 보안 테이블을 자주 점검하십시오.

데이터 모델 관계

데이터 모델을 어떻게 구성하느냐에 따라 액세스를 제어하는 방식이 달라집니다. 테이블 간에는 단방향 관계를 사용하십시오. 그래야 모델이 단순해지고 오류를 피할 수 있습니다.
권한을 사실 테이블에 넣기보다 별도의 보안 테이블을 사용하는 편이 낫습니다. 보안 테이블을 부서나 지역 같은 다른 테이블과 연결할 수 있습니다. 이렇게 하면 사용자 또는 그룹별로 데이터를 필터링할 수 있습니다.

팁: 브리지 테이블을 사용해 사용자와 데이터를 연결하십시오. 이렇게 하면 동적 행 수준 보안이 제대로 작동하고 데이터가 안전하게 보호됩니다.

역할 세분화: 작은 역할과 큰 역할

역할을 얼마나 세분화할지 정해야 합니다. 역할을 작게 나누면 더 세밀하게 통제할 수 있습니다. 직무나 그룹 단위로 액세스를 부여할 수 있습니다. 반대로 역할을 크게 잡으면 더 많은 사람을 포괄하지만, 상황이 바뀌었을 때 위험할 수 있습니다.
각 역할을 누가 가지고 있는지 자주 확인하십시오. 그래야 데이터를 안전하게 지키고, 필요할 때 변경할 수 있습니다.
세밀하게 통제하고 쉽게 업데이트하려면 작은 역할을 선택하십시오. 큰 역할은 단순한 그룹에는 맞을 수 있지만, 대기업에서는 문제를 일으킬 수 있습니다.

Fabric의 사용자 및 그룹 할당

Azure AD 그룹과 개별 사용자 비교

Fabric에서 액세스는 사용자를 Azure AD 그룹에 넣어서 부여합니다. 이렇게 하면 많은 사람의 데이터를 한 번에 통제할 수 있습니다. 사용자를 한 명씩 추가하는 것보다 그룹을 사용하는 편이 더 안전합니다. 그룹을 활용하면 적은 작업으로 시스템을 관리할 수 있습니다. 팀 구성이 바뀌면 그룹을 빠르게 업데이트할 수 있습니다. 그룹을 역할에 연결하면 데이터 모델링이 쉬워집니다. 행 수준 보안 규칙도 명확하고 단순하게 유지됩니다.

팁: 액세스 제어에는 Azure AD 그룹을 사용하십시오. 실수를 줄이고 시간을 아낄 수 있습니다.

중복 그룹과 섀도 액세스

중복된 그룹을 주의해서 살펴야 합니다. 사용자가 둘 이상의 그룹에 속해 있는 경우가 종종 있습니다. 이렇게 되면 사용자가 보아서는 안 되는 데이터를 볼 수 있습니다. 섀도 액세스는 이런 실수로 사용자가 추가 데이터를 보게 되는 상황을 말합니다. 이를 막으려면 그룹 목록을 자주 확인하십시오. 각 그룹에 어떤 사용자가 속해 있는지 표로 관리하는 것도 방법입니다. 좋은 데이터 모델링은 문제를 조기에 찾는 데 도움이 됩니다. 더 이상 필요하지 않은 그룹에서는 사용자를 제거해 데이터를 안전하게 지키십시오.

참고: 섀도 액세스로 비공개 데이터가 노출될 수 있습니다. 시스템을 안전하게 유지하려면 그룹 중복을 해소하십시오.

정기 액세스 검토 예약

정기적인 액세스 검토를 계획해야 합니다. 각 그룹에 누가 속해 있는지 주기적으로 확인하십시오. 그룹 소유자에게 누가 액세스 권한을 가져야 하는지 확인을 요청하십시오. 이렇게 해야 회사가 성장하는 동안에도 동적 행 수준 보안이 제대로 작동합니다. 이런 점검에는 Fabric 도구를 활용하십시오. 오래된 사용자를 제거하면 데이터를 더 안전하게 보호할 수 있습니다. 이렇게 하면 분석 시스템을 깨끗하고 안전하게 유지할 수 있습니다. 액세스 검토를 비즈니스 인텔리전스 업무의 일상적인 부분으로 만드십시오.

• 모든 그룹을 검토할 날짜를 정하십시오.

• Fabric 도구를 사용해 그룹을 점검하십시오.

• 소유자에게 각 그룹의 구성원을 확인해 달라고 요청하십시오.

경고: 정기적인 검토는 문제가 생기기 전에 실수를 찾아내는 데 도움이 됩니다.

ID 확인 방식: Desktop과 Fabric 비교

ID 함수와 클라우드 환경의 차이

Power BI Desktop과 Microsoft Fabric에서 ID가 어떻게 작동하는지 아는 것이 중요합니다. Power BI Desktop에서는 USERNAME()이 보통 컴퓨터 이름을 반환합니다. Microsoft Fabric에서는 USERPRINCIPALNAME()이 클라우드 이메일 주소를 반환합니다. 이 차이는 데이터를 안전하게 지키는 데 중요합니다. 클라우드에서 USERNAME()을 사용하면 잘못된 사람이 데이터를 볼 수 있습니다. 클라우드 보고서에는 항상 USERPRINCIPALNAME()을 사용하십시오. 그래야 데이터를 보호하고 회사의 ID 체계와도 맞출 수 있습니다.

팁: 행 수준 보안 규칙은 클라우드에서 테스트하십시오. Desktop 테스트로는 실제 사용자 액세스를 확인할 수 없습니다.

데이터 세트 소유자와 테넌트 설정

데이터 세트의 소유자가 누구인지 알아야 합니다. 소유자는 새로 고침 설정을 변경할 수 있고, 누가 데이터를 볼 수 있는지에도 영향을 줍니다. 소유자를 변경하면 비공개 데이터를 볼 수 있는 사람이 바뀔 수도 있습니다. 테넌트 설정도 중요합니다. 이 설정은 회사에서 ID가 어떻게 작동할지를 결정합니다. 보고서를 게시하기 전에 테넌트 설정을 확인하십시오. 데이터 모델이 회사의 보안 규칙과 일치하는지 반드시 확인하십시오.

행 수준 보안 유출의 일반적인 원인

클라우드에서 테스트하지 않으면 행 수준 보안을 통제하지 못할 수 있습니다. 때로는 사용자가 필요 이상의 데이터를 보게 됩니다. 잘못된 ID 함수를 사용하거나 그룹 구성원 업데이트를 잊은 경우에 이런 일이 생길 수 있습니다. 보안 테이블을 확인하지 않고 데이터 모델을 변경해도 유출이 발생할 수 있습니다. 변경 후에는 항상 데이터 보안 설정을 검토하십시오. 클라우드 테스트와 정기 감사를 활용하면 문제를 조기에 찾아낼 수 있습니다.

경고: 데이터 보안 유출은 비공개 정보를 노출시킬 수 있습니다. 조직을 보호하려면 설정을 자주 검토하십시오.

테스트, 감사 및 거버넌스

클라우드 기반 RLS 테스트

클라우드에서 행 수준 보안을 반드시 테스트해야 합니다. 그래야 실제 사용자에게 데이터가 안전한지 확인할 수 있습니다. Desktop의 “View As” 도구는 미리 보기만 보여 줍니다. Microsoft Fabric에서 규칙이 어떻게 동작하는지는 보여 주지 않습니다. 보고서를 게시한 후에는 실제 사용자와 그룹으로 테스트하십시오. 그래야 각 사용자가 무엇을 볼 수 있는지 확인할 수 있습니다. 테스트 계정을 사용해 사용자가 자신의 데이터만 보는지 확인하십시오. 역할을 변경하거나 모델을 업데이트할 때마다 다시 테스트하십시오. 클라우드 테스트는 비즈니스에 피해를 주기 전에 문제를 찾는 데 도움이 됩니다.

팁: Desktop이 아닌 클라우드에서 실제 사용자로 항상 테스트하십시오. 그래야 데이터 보안을 튼튼하게 유지할 수 있습니다.

감사 및 검토를 위한 자동화

Fabric에서 감사와 검토를 더 쉽게 하려면 자동화를 활용할 수 있습니다. 자동화는 일정에 따라 작업 영역 권한, 데이터 흐름, 민감도 레이블을 점검합니다. Microsoft Purview는 플랫폼 전반의 규칙을 추적할 수 있는 대시보드를 제공합니다. 활동 로그와 Admin API를 사용해 규정 준수 문제를 찾을 수 있습니다. 자동화를 활용하면 문제를 조기에 발견할 수 있으며 시간도 절약됩니다. 감사 담당자는 시작부터 보고서까지 민감한 열의 전체 경로를 확인할 수 있습니다. 이를 통해 검토가 더 빠르고 정확해집니다. 또한 자동화를 활용하면 GDPR, HIPAA 같은 규정을 더 쉽고 저렴하게 준수할 수 있습니다.

• 권한과 데이터 흐름에 대한 자동 점검을 설정하십시오.

• 대시보드를 사용해 보안 규칙의 변경 사항을 모니터링하십시오.

• 활동 로그를 확인해 문제를 빠르게 찾으십시오.

문서화 및 변경 관리

데이터 보안 체계를 명확하게 유지하려면 체계적인 기록이 필요합니다. 보안 규칙, 그룹 목록, 역할 변경 사항을 기록해 두십시오. 모델을 변경하거나 새 사용자를 추가할 때마다 기록을 업데이트하십시오. 명확한 기록은 어떤 사용자가 어떤 데이터를 볼 수 있는지 추적하는 데 도움이 됩니다. 또한 새로운 팀원이 시스템을 이해하는 데에도 도움이 됩니다. 변경 관리란 업데이트를 실제 적용하기 전에 검토하고 승인하는 것을 의미합니다. 이를 통해 회사가 성장하는 동안에도 행 수준 보안을 안전하게 유지할 수 있습니다.

경고: 기록을 항상 최신 상태로 유지하십시오. 그래야 데이터를 보호하고 문제를 빠르게 해결할 수 있습니다.

행 수준 보안은 데이터와 회사의 성장에 따라 계속 변하는 것으로 생각해야 합니다. 견고한 구성은 민감한 정보를 안전하게 지키는 데 도움이 됩니다. 적절한 DAX 패턴을 사용하고 사용자 ID를 잘 관리하면 데이터를 보호할 수 있습니다. 보안을 점검하고 변경 사항을 기록하면 문제를 조기에 발견하는 데 도움이 됩니다. 미리 계획하면 누가 데이터를 볼 수 있는지 통제하고 분석 환경을 안전하게 유지할 수 있습니다.

• 보안 구성을 자주 점검하십시오.

• 변화하는 규칙을 활용해 데이터를 더 잘 보호하십시오.

• 항상 개인정보 보호를 최우선으로 생각하십시오.

자주 묻는 질문

Power BI와 Fabric에서 동적 행 수준 보안이란 무엇입니까?

동적 행 수준 보안을 사용하면 보고서를 보는 사용자에 따라 데이터 액세스를 제어할 수 있습니다. DAX 함수와 매핑 테이블을 사용해 사용자를 올바른 데이터와 연결합니다.

USERNAME() 대신 USERPRINCIPALNAME()을 사용해야 하는 이유는 무엇입니까?

USERPRINCIPALNAME()은 사용자의 클라우드 이메일을 반환합니다. 이는 Power BI와 Fabric에서 가장 잘 작동합니다. USERNAME()은 로컬 이름을 표시할 수 있으며, 이로 인해 클라우드에서 보안 문제가 발생할 수 있습니다.

Azure AD 그룹은 보안에 어떻게 도움이 됩니까?

Azure AD 그룹을 사용하면 많은 사용자의 액세스를 한꺼번에 관리할 수 있습니다. 사용자를 그룹에 추가하고 역할을 할당하면 됩니다. 이렇게 하면 보안 구성이 더 쉽고 안전해집니다.

보안 테이블이란 무엇이며, 왜 필요합니까?

보안 테이블은 사용자, 그룹, 권한을 나열합니다. 이를 사용해 특정 데이터를 누가 볼 수 있는지 제어합니다. 회사가 성장하더라도 데이터를 안전하게 보호하는 데 도움이 됩니다.

클라우드에서 행 수준 보안을 얼마나 자주 테스트해야 합니까?

역할, 그룹 또는 데이터 모델을 변경할 때마다 행 수준 보안을 테스트해야 합니다. 클라우드 테스트는 실제 사용자가 볼 수 있는 내용을 보여 주며 문제를 조기에 발견하는 데 도움이 됩니다.