"삭제해도 되는가 전에, 이게 뭔지부터 알아야 한다"
Project 테이블 자체가 아직 없는 상태에서, 이 테이블이 생기면 자동으로 문제가 되는 미해결 부채 2건이 예고되어 있었습니다. 하나는 project_members에 FK가 없는 상태였고, 다른 하나는 멤버가 0명인 신규 Project에는 Workspace ADMIN조차 접근하지 못하는 권한 로직 결함이었습니다.
Project 테이블과 enum, 복합 FK를 설계한 뒤 FK를 적용하려는데 마이그레이션이 실패했습니다. 조사해보니 실제 DB에 project_members orphan 행 2건이 남아있었습니다. 이걸 곧바로 지우지 않고, 이메일 패턴과 workspace 이름 패턴을 근거로 이게 과거 RLS 통합 테스트를 실행한 뒤 정리되지 않은 잔재라는 걸 먼저 확인했습니다. 삭제해도 되는지 판단하기 전에 이게 뭔지부터 확실히 아는 게 우선이라고 봤기 때문입니다.
정체가 확정된 뒤에야 승인을 받고, 트리거를 일시 비활성화한 상태로 삭제하고 다시 활성화한 뒤 FK를 VALIDATE하는 방식으로 안전하게 정리했습니다. 이 전체 과정을 하나의 마이그레이션 트랜잭션 안에서 처리한 것도, 중간에 실패해도 트리거가 비활성화된 채로 남지 않게 하기 위한 것이었습니다.
FK가 convalidated=true 상태가 되고 orphan count가 0이 된 것을 확인했고, 멤버 0명 Project에도 Workspace ADMIN이 접근 가능한지도 통합 테스트로 검증했습니다. 97개 테스트가 통과한 것까지 확인한 뒤 커밋하고 Sign-off했습니다.
원인 불명의 데이터를 그냥 NOT VALID 상태로 방치한 채 다음 단계로 넘어가는 것은 데이터 무결성 원칙에 어긋난다고 판단해, 정체를 완전히 규명하기 전까지는 삭제를 승인하지 않았습니다. 단일 트랜잭션 안에서 트리거를 다루기로 한 것도, 중간에 실패해도 트리거 비활성화 상태가 영구화되지 않아야 한다는 원자성 요구 때문이었고, 이를 Supabase CLI의 실제 동작 방식을 근거로 확인한 뒤에만 승인했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료