"Project는 삭제 금지, Process는 조건부 허용 — 그 구분을 RLS로 옮겼다"
이전 작업에서 만든 RLS 헬퍼 함수가 있었지만, 아직 다른 테이블에서 실제로 재사용된 적은 없었습니다. 이번 business_processes 테이블 작업이 그 첫 재사용 사례가 될지, 아니면 또 새로운 함수를 만들게 될지 확인이 필요한 시점이었습니다.
process_status enum과 owner_role_id FK를 포함한 테이블을 설계하면서, 앞서 만든 테이블과 다른 결정을 하나 내렸습니다. 이번엔 DELETE RLS 정책을 포함시키기로 한 것입니다. 문서를 확인해보니 Business Process는 Project와 달리 조건부 Hard Delete가 허용되는 엔티티였고, 이 구분을 RLS 정책 자체에 반영해야 한다고 판단했습니다.
구현 결과를 마이그레이션 원문으로 확인해보니, RLS 4개 정책이 새 함수를 만들지 않고 기존 3개 헬퍼만으로 구현되어 있었습니다. 이 헬퍼 함수들이 실제로 재사용되는 구조라는 걸 이번에 처음 확인한 셈입니다. owner_role_id가 삭제될 때 SET NULL로 동작하는지도 실제 DB에서 검증했습니다.
한 가지는 이번 범위에서 의도적으로 제외했습니다. Process가 참조하는 자식 테이블(Pain Point 등)이 아직 없는 상태라, 참조 관계 기반 삭제 차단 로직은 만들 수 없었고 다음 작업으로 미뤘습니다. DELETE 정책이 있고 없고의 차이 하나가, 문서상의 구분을 그대로 코드에 반영하는 방법이 될 수 있다는 걸 확인한 작업이었습니다.
Process 참조 관계 기반 삭제 차단 같은 애플리케이션 레벨 로직은 아직 존재하지 않는 자식 테이블을 가정해야 해서, 이번 작업에서 만들지 않고 이후 작업으로 미뤘습니다. "한 번에 하나의 작업"과 "존재하지 않는 것을 가정한 코드를 만들지 않는다"는 두 원칙이 함께 작용한 결정이었습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료