"트리거는 코드 리뷰가 아니라 실제로 막아봐야 믿을 수 있다"
RLS 정책의 허점을 막기 위해 DB 트리거를 추가하는 방향(Option B)이 선택됐지만, 이 시점에는 아직 트리거 코드도, 에러코드 체계도, 검증 방법도 정해지지 않은 상태였습니다.
처음부터 새로 설계하는 대신, 기존에 있던 OWNER Guard 트리거(SIA01)의 패턴을 그대로 참고하기로 했습니다. SECURITY DEFINER와 고정된 search_path, 커스텀 Postgres 에러코드라는 동일한 컨벤션을 따라 새 에러코드 SIA02를 정의하고, 불변 컬럼은 누구든 변경 불가, status 변경은 OWNER 또는 Workspace ADMIN만 허용하는 조건으로 트리거를 설계하도록 지시했습니다.
Codex가 트리거 SQL과 에러 매핑, 통합 테스트 코드까지 제출했고 코드 리뷰는 통과했습니다. 하지만 여기서 끝내지 않았습니다. 이 트리거는 실제 DB 트랜잭션에서만 검증 가능한 로직이라, 코드가 그럴듯해 보인다고 해서 승인하지 않고 실제 DB(si-in-ai-dev)에 적용한 뒤 RLS 통합 테스트를 실행하도록 요구했습니다.
직접 supabase db push로 적용하고 환경변수를 설정해 실행한 결과, 11개 테스트가 전부 통과하는 것을 확인했습니다. 트리거는 코드 리뷰로 끝나는 게 아니라, 실제로 막아보고 나서야 믿을 수 있다는 걸 이번에 다시 확인했습니다.
새 함수를 처음부터 설계하지 않고 기존 SIA01 트리거의 컨벤션을 그대로 재사용한 것은, 일관된 패턴 재사용이 이 프로젝트에서 반복적으로 강조된 원칙이었기 때문입니다. 이 트리거는 mock으로는 검증 불가능한 종류의 로직이라, 코드 리뷰만으로 승인하지 않고 반드시 실제 DB에서 실행된 결과를 요구해야 한다고 판단했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료