"Sign-off는 승인이지, 커밋이 아니다"
새 작업(TASK-02-001)의 결과물을 커밋하려던 중, 이상한 점을 발견했습니다. 메모리에는 이전 작업(TASK-01-003A)이 이미 "Sign-off 완료"로 기록되어 있었는데, 실제 git 상태를 확인해보니 관련 파일 11개가 전부 커밋되지 않은 채 Working Tree에 그대로 남아있었습니다. 그리고 그 위에 새 작업의 변경사항까지 얹혀 있는 상태였습니다.
이 상태로 그냥 새 작업만 커밋하면, 두 작업의 변경사항이 하나의 커밋에 뒤섞이거나 마이그레이션 적용 순서가 꼬일 위험이 있었습니다. git status를 기준으로 이전 작업 대상 파일 11개를 정확히 특정하는 프롬프트를 만들어 전달했고, 목록에 누락이나 초과가 없는지 교차 검증했습니다.
"이미 승인된 작업이 뒤에 있으면 먼저 커밋하고, 그다음 신규 작업을 커밋한다"는 순서 원칙을 세워 2단계로 나눠 진행했습니다. 그 결과 이전 작업(661296a)과 새 작업(13c447f)이 각각 독립적인 커밋으로 분리됐고, 마이그레이션 파일명의 타임스탬프 순서와 실제 커밋 순서도 일치하게 됐습니다.
이번 케이스로 확인한 건, Sign-off라는 승인 절차와 실제 커밋이라는 물리적 행위 사이에 간극이 생길 수 있다는 점입니다. 그 간극이 이번에 실제로 존재했고, 발견하지 못했다면 두 작업의 이력이 영구히 뒤섞였을 것입니다.
"한 번에 하나의 Backlog Task만 진행한다"는 운영 원칙은 코드 작성 시점뿐 아니라 커밋 단위에도 그대로 적용되어야 한다고 판단했습니다. 이미 승인된 작업을 미룬 채 새 작업을 그 위에 얹으면, 나중에 문제가 생겼을 때 두 작업의 변경사항이 뒤섞여 원인 추적 자체가 불가능해질 수 있다고 봤습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료