"문서화된 불변조건을 옮기는 것과 새 규칙을 발명하는 것은 다르다"
process_nodes 테이블을 설계하는 시점에 두 종류의 규칙이 섞여 있었습니다. 하나는 이미 문서에 서술되어 있던 "Gateway는 Role을 가질 수 없다"는 일반 모델링 규칙이었고, 다른 하나는 아직 문서에 명시적으로 서술되지 않은 미래 동작, 즉 Process가 삭제될 때 하위 Node를 어떻게 처리할지에 대한 것이었습니다.
첫 번째 규칙은 CHECK 제약으로 DB 레벨에 그대로 옮겼습니다. 이건 이미 문서화된 불변조건을 코드로 반영하는 것이지, 새로운 규칙을 만드는 게 아니라고 판단해 별도 확인 없이 진행했습니다. 두 번째, Process 삭제 시 Node 처리 방식은 문서에 직접적인 서술은 없었지만, 다른 조항에서 "Node/Edge는 Process 삭제와 함께 정리될 수 있다"는 걸 명시적으로 허용하고 있어 이 근거를 바탕으로 CASCADE 삭제로 결정했습니다.
구현 결과를 검증한 결과, CHECK 제약이 INSERT뿐 아니라 UPDATE 방향에서도 제대로 동작했습니다. 즉 이미 STEP으로 만들어진 Node에 Role이 걸려있는 상태에서 Gateway로 전환을 시도해도 거부되는 걸 확인했습니다. CASCADE 삭제도 실제 서비스 롤로 삭제해보며 검증했습니다.
이 작업으로 확인한 건, 문서화된 불변조건을 DB 제약으로 옮기는 것과 새 규칙을 발명하는 것은 다른 성격의 작업이라는 점입니다. 전자는 확인 없이 진행할 수 있지만, 후자는 반드시 근거를 명시하거나 확인을 받아야 한다는 기준을 이번에 세워두게 됐습니다.
이미 문서화된 불변조건을 DB 제약으로 옮기는 것은 새로운 Business Rule을 발명하는 게 아니라고 판단해 별도 확인 없이 진행했습니다. 반면 CASCADE처럼 문서에 직접 서술은 없지만 다른 조항에서 논리적으로 도출 가능한 경우는, 근거를 명시하고 진행하는 방식으로 처리했습니다. 완전한 확인 요청이 필요한 경우와 근거만 있으면 진행 가능한 경우를 이렇게 구분했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료