"그 틈을 메우는 건 임의 판단이 아니라 승인이어야 한다"
새 작업(TASK-02-008)을 시작하려는 시점에 화면 스펙 문서를 확인했더니, PRJ-EDIT-001 화면에는 등록 화면과 동일한 필드에 더해 Project Status와 Owner까지 포함된다고 되어 있었습니다. 그런데 대응하는 API 스펙을 보니 organizationId나 industryId는 아예 없었고, Owner를 바꾸는 API는 완전히 별도 영역으로 분리되어 있었습니다.
이 상태로 바로 구현 지시서를 썼다면, Organization/Industry 편집 기능을 화면에 만들거나 Owner 재지정 기능을 끼워 넣는 식으로 임의 확장이 일어났을 가능성이 있었습니다. 그래서 두 문서를 나란히 대조해 불일치 지점을 먼저 명시적으로 정리했습니다.
Organization/Industry/Status/Owner는 읽기 전용으로만 표시하고, Name/Objective/Scope/Description만 실제로 편집 가능하게 하자는 해석안을 제시했습니다. Owner 재지정은 이번 스코프와 무관한 별도 영역이라 명확히 제외했습니다.
이 정리 작업 자체는 코드를 하나도 만들지 않았지만, 이후 구현 중간에 "이것도 편집 가능하게 할까" 같은 즉흥적 판단이 끼어들 여지를 없앴습니다. 화면에 있다고 다 API에 있는 건 아니고, 그 틈을 메우는 건 구현자의 임의 판단이 아니라 사전 승인이어야 한다는 걸 다시 확인한 작업이었습니다.
문서에 없는 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 스키마 구현 완료