"두 저장 사이 간격 없이 눌러도 CONFLICT가 안 나는지가 검증의 핵심"
저장 Action은 이전 작업에서 준비됐지만, 이를 실제로 호출하는 UI가 없어 사용자가 Process의 Step을 추가하거나 수정할 방법이 전혀 없었습니다. Visual Flow Canvas와 두 에디터 간 동기화 기능은 아직 없는 상태라, 두 에디터가 완전히 동기화된다는 요건을 이번에 전부 충족할 수는 없는 시점이었습니다.
백로그가 의도한 대로, 이번엔 Structured Editor만 단독으로 완결되게 만들기로 했습니다. Visual과 합쳐서 한 번에 만들지 않겠다는 뜻이었습니다. useReducer 기반의 로컬 상태 관리(추가/수정/삭제/복제/재정렬/선택 등 8개 action)로 구현했고, Save 버튼을 누르기 전까진 서버에 아무것도 보내지 않는 Explicit Save 방식을 택했습니다. 이건 문서가 "Node Drag마다 서버 Autosave 금지"를 명시하고 있었기 때문입니다.
핵심은 두 가지였습니다. Node를 삭제할 때 그 Node에 연결된 Edge까지 함께 제거하는 정합성 로직, 그리고 저장이 성공한 뒤 서버가 반환한 새 updatedAt 값으로 로컬의 expectedUpdatedAt을 갱신하는 처리였습니다. 이걸 하지 않으면 두 번째 저장부터 항상 충돌(CONFLICT)이 나는 구조였습니다.
Step 추가, 수정, 삭제, 복제, 순서변경, 저장이 전부 동작하는 걸 확인했고, 267개 테스트가 통과했습니다. 기존 조회 함수의 시그니처를 확장하면서 호출부에 영향이 없는지도 grep으로 확인했습니다. 두 저장 버튼 사이 간격 없이 연달아 저장해도 충돌이 나지 않는지가, Optimistic Concurrency 구현이 제대로 됐는지 확인하는 가장 쉬운 방법이었습니다.
"한 번에 하나의 작업만" 원칙과 백로그 순서를 지키기 위해, 두 에디터 동기화 요건을 이번에 완전히 충족하지 못해도 괜찮다고 판단했습니다. 그건 이후 작업의 몫으로 명확히 남겨뒀습니다. Explicit Save 방식은 문서가 "Node Drag마다 서버 Autosave 금지"를 명시하고 있어 그대로 따랐습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료