"메모리가 말하는 것과 실제 파일 상태는 다를 수 있다"
다른 작업을 리뷰하던 중, 우연히 governance 문서를 다시 열어보게 됐습니다. 메모리에는 SIA01과 SIA02 둘 다 문서화되어 있다고 기록되어 있었는데, 실제 문서를 확인해보니 SIA02 항목이 존재하지 않았습니다. 이전 작업 당시 실제 트리거는 구현됐지만, 문서화만 빠뜨린 것으로 보였습니다.
이걸 그냥 지나치지 않고, 코드나 DB는 건드리지 않는 순수 문서 수정 작업으로 별도로 분리해 진행했습니다. 실제 migration 파일에서 정확한 에러코드와 메시지를 git grep으로 직접 확인하게 했고, 그 결과를 기존 SIA01, SIA03과 동일한 형식으로 문서에 삽입했습니다.
수정이 끝난 뒤 git status --short로 이 커밋에 문서 파일 딱 하나만 변경됐다는 걸 확인한 뒤 커밋했습니다. 코드 변경이 전혀 없는 순수 문서 작업이라, 검증도 "문서에 실제 코드와 일치하는 정보가 들어갔는가"에 집중했습니다.
이 사례로 다시 확인한 건, 메모리에 "다 됐다"고 적혀 있어도 실제 파일을 열어보기 전엔 확정하지 않아야 한다는 점입니다. 추측이 아니라 실물로 재확인하는 습관이 이런 종류의 누락을 잡아냅니다.
"메모리가 말하는 것"과 "실제 파일 상태"가 다를 수 있다는 걸 실제로 겪은 사례라, 추측(메모리 기록)에 의존하지 않고 항상 실물(git grep, 실제 파일)로 재확인하는 원칙을 다시 확인시켜준 계기였습니다. 이런 종류의 불일치는 발견하지 못하면 다음 세션에서도 계속 잘못된 전제로 이어질 수 있다고 판단했습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료