Now

다음 Feature로 넘어가기 위해 관련 데이터 모델과 여러 Acceptance Criteria를 조사했습니다. 관련 Enum이 이전 단계에서 이미 정의됐을 가능성이 있어 이걸 확인 필요 사항으로 남겨뒀습니다. 스키마 파일을 기존 폴더에 얹을지 새 폴더로 분리할지는 아직 결정하지 못해, 이 부분을 이어서 새 채팅창에서 논의하기로 했습니다.

이전 작업 리뷰 중 발견한 비블로킹 항목, 즉 Pain Point Drawer의 라벨이 영어로 되어 있던 걸 바로 처리하기로 결정했습니다. 한글 라벨로 교체하고 관련 테스트 셀렉터까지 갱신해 커밋했습니다. 이 과정에서 완전히 무관한 다른 프로젝트의 출력이 잘못 붙여넣어진 해프닝이 있었는데, 즉시 감지해 확인을 요청한 뒤 정정했습니다.

목록 화면과 Step Detail Panel에 있던 Pain Point 관련 placeholder를 실제 데이터로 연결하는 작업을 진행했습니다. 리뷰 과정에서 Pain Point를 추가하기만 해도 Step 전체가 "저장 안 됨"으로 표시되는 실사용 버그를 발견해, 구조를 분리하도록 수정을 지시하고 회귀 테스트까지 추가해 검증했습니다. 이 과정에서 Windows 경로에 특수문자가 들어가 명령어가 계속 실패하는 문제도 겪어, 다른 방식으로 우회했습니다.

Pain Point 생성/수정/목록/상세 Server Action과 관련 화면을 설계해 구현을 지시했습니다. Confirm/Reject를 얇은 별도 Action으로 분리하는 설계 결정을 거쳐 진행했습니다. 원본 파일을 직접 리뷰해 cross-project 검증, Empty State 구분, placeholder 처리가 모두 정확한지 확인한 뒤 커밋했습니다.

백로그 순서에 따라 Pain Point 테이블 설계에 착수했습니다. pain_points 테이블과 관련 Enum, "Process 또는 Node 중 최소 하나 필수"라는 CHECK 제약까지 구현을 지시했습니다. 리뷰 중 처음 지시한 dual-defense composite FK가 실제 코드베이스 패턴과 맞지 않다는 걸 Codex가 역으로 지적해와 단일 FK로 정정했고, migration부터 도메인 타입, Zod schema까지 확인한 뒤 커밋했습니다.

새 기능을 만드는 작업이 아니라, 관련 요건 5가지를 기존 구현과 하나씩 대조 확인하는 작업이었습니다. 4가지는 이미 충족되어 있었고, Step Detail Panel에만 Unsaved Changes 표시가 빠져 있어 최소로 보강했습니다. Step Detail의 Optimistic Concurrency는 계약 범위 밖이라 판단해 구현하지 않고 미해결 항목으로 남겼으며, 이 작업으로 관련 Epic 전체가 완전히 종결됐습니다.

Step Detail Panel 구현을 위해 먼저 백엔드로 기존 4개 RPC를 오케스트레이션하는 Action을 만들었고, 중복 저장 경로를 막기 위해 특정 필드는 의도적으로 제외했습니다. 이어서 STEP Node 선택 시에만 노출되는 편집 화면을 구현했습니다. 데이터 모델에 없는 필드는 명세와 다르게 의도적으로 제외했고, 아직 착수되지 않은 기능들은 각각 placeholder로 남겨뒀습니다.

관련 검증 로직은 이미 있었지만, 정방향 Edge와 뒤로 돌아가는 Loop Edge를 화면에서 시각적으로 구분할 방법이 없었습니다. displayOrder를 기준으로 한 순수 계산으로 Loop 여부를 판별해 점선 스타일을 적용하고, 모든 Edge에 방향 화살촉을 추가했습니다. 새 검증 로직이나 색상 팔레트는 추가하지 않고 최소 범위로 처리했습니다.

관련 검증 로직 자체는 이미 구현되어 있었지만, Conditional Gateway에서 나가는 Edge에 조건 Label을 입력할 UI가 없어 실질적으로 저장이 항상 막히는 상태였습니다. 리듀서에 Edge 수정 액션을 추가하고, 선택한 Edge의 출발점이 Conditional Gateway일 때만 Label 입력이 노출되도록 구현했습니다. 리뷰 중 diff에서 문자 하나가 잘린 걸 발견해 재확인했지만 실제 코드는 문제없었습니다.

브라우저 테스트 중 Project Overview에서 완성된 Process 목록으로 가는 링크 자체가 없다는 걸 발견했습니다. 이미 명세에 있던 항목이었는데 구현이 빠져 있었던 것이라, 범위를 명세 그대로로 잡아 Phase Checklist의 관련 항목만 최소로 링크 처리했습니다.

브라우저 실사용 테스트로 Structured 순서 변경과 Visual 위치 변경이 서로 반영되지 않는 걸 확인했습니다. 이걸 버그가 아니라 업무 순서와 화면 배치는 다른 개념이라는 의도된 설계로 판단했습니다. 대신 "동기화"를 두 화면이 같은 검증 결과를 공유하는 것으로 재정의해, 저장 실패 메시지를 구체적인 issue 목록으로 바꾸고 경고를 공용 영역에 표시하는 것으로 범위를 확정했습니다.

Structured Step Editor는 이미 있었지만 Visual Flow Canvas가 없어 새로 구현을 시작했습니다. 4종 Custom Node를 만들고 Domain Graph와 React Flow 간 Adapter를 분리했으며, 리듀서에 Edge 관련 액션을 추가했습니다. Codex가 diff를 요약 보고해 두 차례 원본을 재요청한 끝에 리뷰를 완료했고, Save 흐름의 Edge id 처리를 재검증해 문제없음을 확인했습니다.

백로그가 의도한 대로 Visual Canvas 없이 Structured 부분만 완결되게 구현했습니다. 로컬 상태 기반의 추가/수정/삭제/복제/재정렬/선택 기능과 명시적 저장을 구현했는데, 삭제 시 연결된 데이터를 함께 제거하는 정합성 로직과 저장 성공 후 다음 저장이 충돌 나지 않도록 상태를 갱신하는 처리가 정확한지 확인했습니다. 기존 조회 함수의 시그니처를 확장해 호출부 영향 범위까지 확인한 뒤 커밋했습니다.

다음 작업을 시작하기 전, Structured Editor가 저장할 Action 자체가 아직 없다는 걸 발견해 먼저 만들기로 했습니다. 구현 리뷰 중 Node를 delete+insert하는 방식이 CASCADE로 연결된 하위 데이터를 매 저장마다 전부 삭제시키는 심각한 데이터 유실 버그를 발견했습니다. UPSERT 방식으로 재설계해 해결했고, 실제 DB에 통합 테스트를 붙여 하위 데이터가 살아남는지 직접 검증했습니다.

Process 등록 화면을 구현하면서 Owner Role 선택에 필요한 조회 Action이 아직 없다는 걸 확인해 신규로 추가했습니다. 기존 등록 화면 패턴을 그대로 재사용해 폼을 구현했고, "저장"과 "저장 후 편집기 열기" 두 버튼의 목적지를 분기시켰습니다. 에러 메시지 언어 스타일 불일치라는 사소한 이슈만 남기고 순조롭게 커밋했습니다.

스키마/백엔드 단계에서 실제 UI 구현 단계로 전환한 첫 작업으로 Process 목록 화면을 진행했습니다. 화면 명세에 있는 일부 컬럼이 아직 없는 테이블에 의존한다는 걸 미리 확인해 placeholder로 의도적으로 축소했습니다. 리뷰 중 검색 결과 0건과 실제 데이터 0건을 구분하지 못하는 Empty State 버그를 발견해 수정한 뒤 커밋했습니다.

리뷰 중 거버넌스 문서에 특정 트리거(SIA02)가 실제로는 등록되어 있지 않다는 걸 발견했습니다. 메모리에는 등록됐다고 잘못 기록되어 있었던 것이었습니다. 이전 작업 때 실제 구현된 트리거를 git grep으로 재확인해 다른 트리거들과 동일한 형식으로 문서에 추가하는 순수 문서 수정 작업을 별도로 진행했습니다.

System/Data Reference 스키마가 Node의 자식이 아니라 Project 범위의 독립 재사용 엔티티임을 파악해 설계를 두 부분으로 분리했습니다. 리뷰 중 Codex가 diff를 요약하다 실제 구현된 테스트 코드를 주석처럼 보이게 잘못 전달한 사고가 있어, 원본 그대로 재확인을 요구해 실제로는 문제없음을 확인했습니다. 또한 존재하지 않는 project에 잘못된 에러 순서로 응답하는 문제를 발견해 정정했고, 이로써 관련 기능 전체가 완료됐습니다.

Process Exception 스키마 작업을 시작하기 전, 대응하는 AC가 문서에 없는 순수 스키마 작업임을 백로그와 AC 문서 양쪽에서 재확인했습니다. 이전 작업과 같은 이유로 AI Origin 컬럼은 추가했지만, 대응 AC가 없는 verified 컬럼은 추가하지 않기로 구분해서 결정했습니다. 동일한 패턴으로 테이블과 RPC를 구현해 순조롭게 커밋까지 마쳤습니다.

AI Origin/Human Verification 구분을 위해 데이터 모델 문서에 없던 컬럼을 추가할지 논의했는데, 다른 문서에는 이미 명시되어 있던 문서 간 불일치임을 확인해 추가하기로 결정했습니다. 이전 작업에서 확립한 RPC 패턴을 그대로 재사용해 business_rules 테이블과 관련 RPC를 구현했고, Gateway Node 차단 에러코드로 신규 코드를 부여했습니다. AI 생성/Human 작성 Rule이 정확히 구분되어 저장되는지 테스트로 검증한 뒤 커밋했습니다.

process_inputs/process_outputs 스키마를 설계하면서 RPC 시그니처를 두 차례 수정했습니다. 처음엔 project 경계 검증이 빠져있어 p_project_id를 추가했고, 이미 원격에 적용된 migration이라 새 버전 migration으로 처리해야 한다는 점을 확인해 그렇게 진행했습니다. DELETE RLS 정책 없이 SECURITY DEFINER RPC로 전체 교체하는 패턴을 이번에 처음 확립했고, Workspace ADMIN 예외 처리 여부까지 재확인한 뒤 커밋했습니다.

작업이 늘어날수록 RLS 통합 테스트 파일마다 테스트 유저를 새로 생성하면서 Auth 서비스의 rate-limit이 발생할 위험이 커지고 있다는 걸 보고에서 포착했습니다. 유저는 세션 전체에서 공유하고 나머지 데이터는 기존처럼 파일별로 독립 생성하는 절충안을 제안해 확정했습니다. 다만 당장 처리하지는 않고, 이후 특정 시점에 별도의 작은 작업으로 진행하기로 보류했습니다.

중복 Edge, Self Loop, Gateway 연결 수, 비정상 Cycle, Orphan Node, Start/End 검증까지 총 8개 작업을 하나의 파일에 규칙 함수를 하나씩 쌓아가는 방식으로 진행했습니다. 문서에 정확한 판정 알고리즘이 없던 항목은 해석 방향을 먼저 확인받은 뒤 알고리즘으로 구현했고, 특정 시점부터는 저장 차단용 검증과 경고용 검증을 별도 함수로 분리하는 설계를 도입했습니다. 매 작업마다 결과물 원문을 직접 대조 검토한 뒤 Sign-off하는 절차를 반복해 8개 작업 전부 완료했습니다.

"Graph Domain Model"과 "Graph Validation"이 백로그상 별도 작업으로 분리되어 있다는 점에 착안해, 이번엔 검증 로직 없이 자료구조와 순수 조회 함수만 구현하기로 스코프를 정했습니다. 저장 액션도 검증 로직이 없는 상태에서 노출하면 위험하다고 판단해 함께 보류시켰습니다. 구현이 "판단하지 않는다"는 원칙을 실제로 지켰는지 위주로 검토한 뒤 Sign-off하고 커밋했습니다.

Codex의 정상적인 커밋 완료 보고 말미에 한자, 키릴 문자, 도박 관련 문구, 가짜 시스템 태그가 붙어 나오는 현상이 발생해 원인을 조사했습니다. git log와 git grep으로 실제 커밋과 저장소를 직접 재검증한 결과 코드나 커밋 어디에도 이물질이 없음을 확인했습니다. 저장소 오염이 아니라 도구 자체의 출력 스트리밍 과정에서 생긴 노이즈로 결론 내렸고, 자기 보고를 곧이곧대로 믿지 않고 항상 git으로 재검증한다는 기존 원칙을 다시 확인하는 계기가 됐습니다.

process_edges 테이블을 설계하면서, 중복 Edge나 Self Loop 같은 검증 규칙은 이후 별도 작업의 몫이라 이번엔 DB 제약을 일절 넣지 않기로 결정하고 오히려 "의도적으로 막지 않았다"는 걸 증명하는 테스트를 요구했습니다. Sign-off까지는 정상 진행했는데, 이후 커밋 안내를 빠뜨린 채 다음 작업으로 넘어가는 실수가 있었습니다. 미커밋 파일이 남아있던 걸 뒤늦게 발견해 순서를 바로잡아 커밋했습니다.

process_nodes 테이블을 설계하면서 "Gateway는 Role을 가질 수 없다"는 기존 문서 규칙을 CHECK 제약으로 반영했고, Process 삭제 시 Node가 함께 삭제되도록 CASCADE 정책을 결정했습니다. 구현 결과의 CHECK 제약, CASCADE, SET NULL 동작을 마이그레이션 원문과 통합 테스트로 확인한 뒤 Sign-off하고 커밋했습니다.

백로그상 작업명은 "Process CRUD API"였지만, 실제 API 문서에는 Create Action만 정의되어 있고 Update/Archive/Delete는 근거가 없다는 걸 확인했습니다. 문서에 없는 기능을 임의로 만들지 않는다는 원칙에 따라 스코프를 Create와 조회로 제한해서 구현·검토·Sign-off했습니다.

앞서 만든 RLS 헬퍼를 재사용해 business_processes 테이블을 설계·구현했습니다. 이전 테이블과 달리 이번엔 DELETE RLS 정책을 포함시키기로 했는데, 문서상 Business Process는 조건부 Hard Delete가 허용되는 엔티티였기 때문입니다. 구현 후 마이그레이션 원문과 통합 테스트를 직접 검토해 Sign-off하고 커밋했습니다.

EPIC-03 첫 작업으로 business_roles 테이블을 설계하던 중, 이게 Project 범위 Domain Table로는 처음 등장하는 형태라는 걸 확인해 RLS 설계 방향을 먼저 확인받았습니다. is_workspace_member, has_project_access, has_project_role 세 RLS 헬퍼 함수와 테이블을 구현받았고, 이 과정에서 권한 컨텍스트에 상태 체크가 추가된 것이 기존 로직에 회귀를 일으키지 않는지 실제 계정 상태로 검증했습니다. 이 헬퍼 함수들은 이후 전체 작업이 재사용하는 기반이 됐습니다.