"순서와 배치는 다른 것 — 동기화를 다시 정의했다"
이전 작업(Visual Canvas)이 끝난 뒤, "Structured와 Visual이 동기화된다"는 요건이 실제로 무엇을 의미하는지 문서만으로는 모호했습니다. 브라우저에서 직접 확인해보니, Structured에서 순서를 바꿔도 Visual 위치가 안 바뀌고, Visual에서 Node를 드래그해도 Structured 순서가 안 바뀌는 현상이 있었습니다. 처음엔 이게 버그라고 생각했습니다.
이걸 그대로 고치기 전에, 다섯 가지 시나리오(Structured→Visual, Visual→Structured, 선택 상태, Edge 연결, 저장 후 새로고침)를 하나씩 직접 테스트해봤습니다. 그 결과 앞의 두 케이스는 버그가 아니라 자연스러운 결과라는 걸 확인했습니다. 업무 순서(Structured)와 화면 배치(Visual)는 애초에 다른 개념이고, 순서가 바뀐다고 화면상 위치까지 자동으로 바뀔 이유는 없었습니다.
이 재해석을 바탕으로 실제 구현 대상을 좁혔습니다. 위치를 강제로 동기화하는 로직은 만들지 않고, 대신 저장 실패 메시지를 구체적인 issue 목록으로 바꾸고, 이미 구현만 되어 있고 화면에 연결되지 않았던 검증 경고를 공용 Warning 영역으로 노출하는 쪽으로 방향을 정했습니다.
274개 테스트가 통과했고, Warning이 Structured와 Visual 어느 쪽에서 편집하든 한 곳에서만 표시되도록 구조적으로 중복도 제거했습니다. 버그로 보였던 현상이 사실은 아직 이름이 붙지 않았던 설계 원칙이었다는 걸, 성급하게 고치기 전에 확인한 게 이번 작업의 가장 중요한 부분이었습니다.
위치 동기화를 강제로 구현하면 사용자가 직접 배치한 Visual 레이아웃을 덮어써서 오히려 사용성을 해칠 위험이 있었습니다. 그래서 "동기화"의 정의 자체를 "같은 위치를 공유하는 것"에서 "같은 검증 결과를 공유하는 것"으로 바꿨습니다. 문제로 보였던 현상을 그대로 고치는 대신, 문제 정의 자체를 다시 세운 게 이번 작업의 핵심 판단이었습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료