"순서대로 하는 것과, 준비된 것부터 하는 것은 다르다"
이전 작업이 마무리된 뒤, 백로그 순번상으로는 Project Status State Machine 작업이 다음 차례였습니다. 그런데 이 작업이 완료되려면 두 가지 조건, 즉 첫 Process 생성 시 상태 전환과 Blueprint 승인 시 상태 전환이 필요한데, 이 둘 다 아직 존재하지 않는 다른 Epic의 기능에 의존하고 있었습니다.
이 상태로 작업을 강행하면 실제 데이터 소스 없이 목업이나 TODO 주석만 채우게 될 것이 뻔했습니다. 이걸 그냥 순번대로 진행하는 게 맞는지 다시 생각해봐야 했습니다. 완료 조건이 실제로 충족 가능한 시점인지를 기준으로 판단하기로 하고, 이 작업을 지금 강행하는 대신 다른 영역(TASK-03-001)을 먼저 진행하는 방향을 제안했습니다.
이 판단의 근거는 목업으로 채워 넣으면 나중에 다시 뜯어고쳐야 하는 이중 작업이 생기고, "이번엔 임시로"라는 명목의 임의 규칙이 끼어들 위험이 있다는 것이었습니다. 이 근거를 설명한 뒤 동의를 받았고, 보류된 작업은 완전히 미뤄진 게 아니라 "의존 항목이 준비되는 시점마다 나눠서 완성"으로 상태를 명확히 정의했습니다.
이 결정 자체는 코드를 건드리지 않은 계획 조정이었지만, 다음에 무엇을 해야 할지가 명확해졌다는 점에서 실질적인 진전이었습니다. 순서대로 하는 것과 준비된 것부터 하는 것은 다르다는 걸, 이번에 다시 한번 판단 기준으로 세워두게 됐습니다.
"한 번에 하나의 작업만, 순서대로"라는 원칙을 문서 순번을 기계적으로 따르는 것으로 해석하지 않고, 각 작업의 완료 조건이 실제로 충족 가능한 시점인지를 기준으로 판단했습니다. 목업으로 채워 넣으면 나중에 다시 뜯어고쳐야 하는 이중 작업과, "이번엔 임시로"라는 명목의 임의 Business Rule이 끼어들 위험을 피하고자 했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료