"못 만든 이유와 고칠 지점을 코드·문서·테스트 3곳에 남긴다"
프로젝트 단위로 누가 속해 있고 무슨 역할인지를 저장하는 구조가 전혀 없었습니다. 그런데 정작 프로젝트 자체를 나타내는 테이블은 다음 단계(EPIC-02)에서나 만들어질 예정이라, 참조할 대상이 아직 존재하지 않는 구조적 딜레마가 있었습니다.
이 문제를 FK 없이 project_id 컬럼만 우선 만들고, 나중에 반드시 연결한다는 사실을 주석과 거버넌스 문서, static test 3곳에 남기는 방식으로 풀었습니다. Backlog상 EPIC 순서를 깨지 않으면서도 실무적으로 진행할 수 있는 절충안이라고 판단했습니다.
이어서 "마지막 OWNER가 지워지거나 강등되면 프로젝트에 책임자가 0명이 되는" 상황을 막는 별도 작업을 진행했습니다. UI에서 버튼을 숨기는 것만으로는 권한이 보장되지 않는다는 원칙에 따라, 어떤 경로로 접근하든 걸리는 DB 트리거로 구현했습니다. 리뷰 과정에서 이 예외를 나중에 코드에서 구분할 수 있도록 기본 에러코드 대신 커스텀 SQLSTATE(SIA01)를 지정하도록 요구했습니다.
두 작업 모두 커밋까지 마쳤고, 트리거가 실제로 마지막 OWNER 삭제 시도를 막는지는 이후 테스트 단계에서 확인할 사항으로 남겨두었습니다. 지금 당장 완전한 구조를 만들 수 없다면, 못 만든 이유와 나중에 고칠 지점을 여러 곳에 남겨 잊지 않게 하는 게 중요하다는 걸 확인한 작업이었습니다.
FK 없이 진행하기로 한 건, Backlog의 EPIC 순서(이번 단계가 다음 단계보다 먼저)를 깨지 않으면서 실무적으로 진행 가능한 절충안이었습니다. 트리거를 DB 레벨에 둔 이유는 "UI 버튼을 숨기는 것만으로 권한을 보장하지 않는다"는 프로젝트 원칙 때문으로, 어떤 경로로 접근하든 뚫리지 않는 최종 방어선이 필요하다고 판단했습니다. 커스텀 에러코드를 요구한 것도 나중에 이 예외를 프로그램에서 구분해 처리할 수 있어야 한다는 실무적 이유였습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료