"판단하지 않는다는 게, 이 단계 설계의 핵심 의도였다"
"Graph Domain Model"과 "Graph Validation"은 백로그상 서로 다른 작업으로 나뉘어 있었습니다. 이 경계를 지키지 않고 자료구조를 만들면서 판단 로직까지 조금씩 섞으면, 검증이 전혀 없는 상태에서 저장 기능이 화면에 노출되는 위험한 중간 상태가 생길 수 있다고 판단했습니다.
그래서 이번 작업의 범위를 엄격하게 제한했습니다. ProcessGraph, ProcessGraphNode, ProcessGraphEdge라는 자료구조 타입과, getOutDegree처럼 판단이 섞이지 않은 순수 조회 함수 6개만 구현하도록 했습니다. 그래프를 저장하는 Action은 검증 로직이 전무한 상태에서 노출하면 위험하다고 판단해, 이번 범위에서 명시적으로 제외했습니다.
구현된 결과를 검토하면서 인상적이었던 건, "연결이 부족한 Gateway"에 대해서도 getOutDegree가 에러 없이 그냥 숫자를 반환하는 테스트가 있었다는 점입니다. 이게 바로 "판단하지 않는다"는 설계 의도가 코드와 테스트 양쪽에 그대로 남아있다는 증거였습니다.
이렇게 자료구조와 판단 로직을 파일 단위로 분리해두면, 이후 여러 검증 작업이 판단 로직만 추가하면 되는 깔끔한 구조가 됩니다. 이 시점에는 아직 실제 검증 규칙이 하나도 없는 상태였고, 이후 이어지는 작업들에서 하나씩 채워지게 됩니다.
자료구조와 그 위에 얹을 판단 로직을 파일 단위로 분리해두면, 이후 여러 작업이 판단 로직만 추가하면 되는 구조가 되어 "한 번에 하나의 규칙"을 지키기 쉬워진다고 판단했습니다. 이번 단계에서 판단 로직을 조금이라도 섞으면, 이후 검증 작업들이 이미 존재하는 판단과 충돌하거나 중복될 위험이 있다고 봤습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료