"App이 막아도 DB가 안 막으면, 그건 안 막은 것이다"
Codex가 제출한 UPDATE RLS 정책을 리뷰하는 과정에서, 겉보기엔 문제없어 보이는 코드에서 구조적인 허점을 발견했습니다. 정책은 "OWNER, EDITOR, Workspace ADMIN이면 허용"이라는 행 단위 조건만 걸려 있었고, 어떤 컬럼이 바뀌는지는 전혀 구분하지 않고 있었습니다.
Server Action 쪽에서는 EDITOR가 mutable 필드만 수정하도록 이미 제한하고 있었기 때문에, 겉으로 보면 아무 문제가 없어 보였습니다. 하지만 RLS 정책 자체만 놓고 보면, EDITOR가 Supabase 클라이언트를 통해 Server Action을 거치지 않고 직접 status나 organization_id 같은 값을 바꿀 수 있는 경로가 여전히 열려 있었습니다.
이 프로젝트가 초기부터 지켜온 "Server Action 검증 + DB 레벨 제약 이중 방어" 원칙을 기준으로 삼아, 이 상태는 그 원칙에서 벗어나 있다고 판단했습니다. commit 승인을 보류하고, App만 신뢰하는 옵션 A와 DB 트리거로 컬럼별 제약을 추가하는 옵션 B 두 가지를 각각의 트레이드오프와 함께 제시했습니다.
이 시점에서는 아직 문제를 발견하고 승인을 보류한 단계였고, 실제 해결은 다음 작업(Option B 트리거 구현)으로 이어졌습니다. App이 막아도 DB가 막지 않으면 그건 안 막은 것과 같다는 걸, 이번에 코드 리뷰 단계에서 확인한 사례였습니다.
이 프로젝트가 EPIC-01/02에서부터 유지해온 "Server Action 검증 + DB 레벨 제약 이중 방어" 원칙을 기준으로 삼아, 이번 RLS 정책이 그 원칙에서 벗어나 있다는 걸 판단 근거로 사용했습니다. 코드가 스펙대로 동작하는지뿐 아니라, 이 프로젝트가 지켜온 보안 패턴과 일관되는지까지 리뷰 범위에 포함시켜야 한다고 봤습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(BPR)을 지원하는 한국어 기반 웹 애플리케이션. 컨설팅 프로젝트의 AS-IS 프로세스 분석부터 TO-BE 설계, Blueprint 승인까지의 전체 워크플로우를 디지털화하는 플랫폼으로, EPIC 단위로 구조화된 백로그를 기반으로 개발 중. 역할 및 워크플로우 PM / Architect / Reviewer 역할 수행 Codex(구현 담당)에게 Task 단위 구현 프롬프트 설계 Codex 구현 결과를 git log, git grep, git status로 직접 검증 후 승인 승인 전에는 Codex가 commit하지 않는 엄격한 게이팅 프로세스 운영 한 번에 하나의 Backlog Task만 진행, Task 완료 전 다음 Task 착수 금지 기술적 의사결정 및 성과 워크스페이스/프로젝트 접근 권한을 DB 레벨(복합 FK, SECURITY DEFINER 트리거)과 애플리케이션 레벨(Server Action 권한 검증)의 이중 방어 구조로 설계 Hard Delete 미구현 원칙 하에 배열 필드 전체교체(replace)를 단일 트랜잭션 RPC로 처리하는 패턴 확립 및 재사용 AS-IS 프로세스 그래프의 순환 참조 탐지에 Tarjan SCC 알고리즘 적용, 차단 오류(Error)와 경고(Warning)를 분리한 이중 Validator 아키텍처 설계 도메인 규칙 위반을 커스텀 Postgres 에러 코드 체계(SIA0104)로 문서화하여 거버넌스 문서와 코드베이스 간 정합성 유지 AI 생성 데이터와 사람이 검증한 데이터를 구분하는 generatedbyai / verified 메타데이터 패턴을 여러 도메인 테이블에 일관되게 적용 진행 상태 ✅ EPIC-01 (인증 / 워크스페이스 / 프로젝트 접근) ✅ EPIC-02 (조직 / 산업 / 프로젝트) 🚧 EPIC-03 (AS-IS 프로세스 그래프) — 그래프 검증, Input/Output 스키마, Business Rule 스키마 구현 완료