"무엇을 저장할지와 어디로 이동할지는 다른 관심사다"
Process 등록 화면을 만드는데, 생성 Action은 이전 작업에서 이미 만들어져 있었습니다. 문제는 Owner Role을 선택하려면 필요한 "Project 내 Business Role 목록 조회" Action이 아무 데도 없다는 것이었습니다. 이 Action을 최소 기능으로 새로 추가했습니다.
폼 자체는 기존 등록 화면 패턴을 그대로 재사용해 구현했습니다. 다만 이번 화면엔 "저장"과 "저장 후 편집기 열기" 두 버튼이 있었고, 이 둘이 서로 다른 곳으로 이동해야 한다는 요구가 있었습니다. 이걸 Server Action 내부에서 처리하면 Action 자체가 "무엇을 저장할지"뿐 아니라 "어디로 이동할지"까지 알아야 해서 복잡해질 것 같았습니다. 대신 클라이언트에서 useState로 intent를 미리 설정한 뒤 제출하는 방식으로, Server Action은 건드리지 않고 UI 레벨에서만 분기를 처리했습니다.
폼이 정상 동작하는 것까지 확인했습니다. "편집기 열기" 버튼은 아직 편집기 화면 자체가 없어 지금은 404로 이어지는데, 이건 이전 작업 때의 선례(존재하지 않는 라우트를 미리 연결해두는 방식)를 그대로 따른 것입니다. 253개 테스트가 통과하는 것까지 확인했습니다.
한 가지 non-blocking 이슈는 남겨뒀습니다. 이 Action에서만 에러 메시지의 언어 스타일(한국어 vs 영어)이 다르게 나오는 문제인데, 화면엔 노출되지 않지만 나중에 정리가 필요한 부분으로 기록해뒀습니다.
두 버튼의 목적지 분기를 Server Action 안에서 처리하려면 Action 자체를 복잡하게 만들어야 했는데, 이건 UI 레벨의 관심사(어디로 이동할지)이지 Server Action의 관심사(무엇을 저장할지)가 아니라고 판단했습니다. 이 관심사를 분리하는 게 나중에 Action을 재사용하거나 수정할 때도 더 유리하다고 봤습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료