Skip to main content

행 필터란?

행 필터(Row Filter) 는 테이블의 데이터를 조회할 때 사용자에 따라 보이는 행을 동적으로 제한 하는 기능입니다. 원본 데이터를 변경하지 않고, SQL 함수를 통해 조회 시점에 필터가 자동 적용됩니다.
💡 왜 필요한가요? 같은 테이블이라도 서울 지역 담당자는 서울 데이터만, 부산 지역 담당자는 부산 데이터만 봐야 하는 경우가 있습니다. 뷰를 만들어 분리할 수도 있지만, 담당자가 늘어날 때마다 뷰를 추가해야 하므로 관리가 어렵습니다. 행 필터를 사용하면 하나의 테이블에 하나의 정책 으로 해결할 수 있습니다.
이 기능의 기본 개념은 권한 관리의 “행 수준 보안” 섹션에서 소개했습니다. 이 문서에서는 다양한 시나리오와 고급 패턴을 상세히 다룹니다.

동작 원리

행 필터는 SQL 함수 로 구현됩니다. 이 함수는 각 행에 대해 TRUE 또는 FALSE를 반환하며, TRUE인 행만 사용자에게 보입니다.

필터 함수에서 사용하는 주요 함수


기본 설정 방법

단계 1: 필터 함수 생성

단계 2: 테이블에 행 필터 적용

단계 3: 동작 확인

행 필터 제거


시나리오별 예제

시나리오 1: 부서별 데이터 접근 제어

시나리오 2: 본인 데이터만 조회 (CURRENT_USER 활용)

시나리오 3: 날짜 기반 접근 제어

시나리오 4: 다중 컬럼 기반 필터


주의사항 및 제한


모범 사례


현업 사례: 다국적 기업에서 리전별 데이터 격리를 Row Filter로 구현

🔥 GDPR, 개인정보보호법 등 규제를 다루는 프로젝트에서 자주 등장하는 패턴입니다.
글로벌 기업에서 “한국 팀은 한국 고객 데이터만, EU 팀은 EU 고객 데이터만 볼 수 있어야 합니다”라는 요구사항은 매우 흔합니다. 뷰를 리전별로 만들면 리전이 추가될 때마다 뷰를 추가해야 합니다. Row Filter를 사용하면 하나의 테이블에 하나의 정책 으로 해결됩니다.

실제 구현 사례

구현 후 실제 동작 확인


성능 영향: 필터 함수가 모든 쿼리에 추가됩니다

⚠️ 많은 팀이 간과하는 부분입니다. Row Filter는 해당 테이블에 대한 모든 쿼리 에 자동으로 WHERE 조건이 추가되는 것과 같습니다. 이것이 성능에 미치는 영향을 반드시 이해해야 합니다.

성능 테스트 실측 결과

성능 최적화 규칙


복잡한 필터 로직의 디버깅 전략

Row Filter가 적용된 테이블에서 “왜 이 데이터가 안 보이죠?”라는 질문은 현업에서 매우 자주 발생합니다. 디버깅이 까다로운 이유는 필터가 투명하게 적용되어 사용자가 필터의 존재를 모르는 경우 가 많기 때문입니다.

디버깅 체크리스트

흔한 디버깅 시나리오

테스트 환경에서의 필터 검증 패턴

💡 현업 팁: Row Filter를 적용할 때는 반드시 각 그룹별 테스트 계정 을 준비하세요. “admin으로 로그인하면 다 보이니까 괜찮겠지”는 가장 위험한 생각입니다. 실제 일반 사용자의 관점에서 데이터가 올바르게 필터링되는지 확인해야 합니다. 그리고 필터 함수를 변경할 때는 dev 환경에서 먼저 테스트 한 후 production에 적용하는 프로세스를 반드시 지켜야 합니다.

정리


참고 링크