코드검토🔬 AX 케이스 스터디2026. 08. 10.(업데이트: 2026. 08. 12.)

코드엔 4종, DB엔 2종 — 사라진 권한값을 되살렸습니다

🔴 Before (문제 상황)

DB의 platform_role이 ADMIN, MEMBER 2종류만 저장 가능한 상태
실제 코드(access.ts)에는 TRANSFORMATION_PLANNER, SI_PM, BUSINESS_REVIEWER까지 4종류가 정의되어 있어 불일치
"TRANSFORMATION_PLANNER/SI_PM은 허용, BUSINESS_REVIEWER는 거부" 같은 규칙을 DB 레벨에서 검증할 방법이 없는 상태

🟢 After (해결/결과)

문서(docs/05_data_model.md §6.2, §8) 확인 결과 원래 설계가 4종 체계였음을 확인, 새 정책이 아닌 기존 설계 복구로 규정
기존 MEMBER 계정을 TRANSFORMATION_PLANNER로 이관, Enum이 5종(레거시 포함)으로 확장
공용 권한 판정 함수 canManageIndustryOrOrganization() 신설, lint/typecheck/test(78건)/build 전부 통과 보고

다음 기능(Industry CRUD) 구현 프롬프트를 준비하던 중, Codex가 예상치 못한 충돌을 보고했습니다. DB의 platform_role은 ADMIN, MEMBER 딱 2종류만 저장 가능한데, 실제 코드에는 TRANSFORMATION_PLANNER, SI_PM, BUSINESS_REVIEWER까지 4종류가 정의되어 있다는 것이었습니다. 이 상태로는 특정 역할만 허용하고 다른 역할은 거부하는 규칙을 DB에서 실제로 검증할 방법이 없었습니다.

이게 새로 결정해야 할 문제인지, 아니면 원래 설계였는데 구현이 빠진 건지부터 확인해야 했습니다. 데이터 모델 문서를 찾아보니 원래 설계 자체가 4종 체계였다는 걸 확인했고, 이건 새 정책 결정이 아니라 기존 설계 대비 축소 구현된 결함이라고 규정했습니다.

세 가지 대안(DB Enum을 4종으로 확장, 별도 테이블/JWT claim 신설, 이번 작업 한정 ADMIN만 처리)을 검토했고, 문서 원안과 일치하는 확장 방식을 선택했습니다. 이 과정에서 기존 MEMBER 값을 가진 계정을 어디로 이관할지도 결정해야 했는데, BUSINESS_REVIEWER로 보내면 기존 계정의 관리 권한이 사라지는 회귀가 생기기 때문에 TRANSFORMATION_PLANNER로 이관하기로 했습니다. 이 수정은 원래 진행하려던 기능과 분리해 별도 작업으로 지정해 구현을 지시했습니다.

Enum이 5종으로 확장되고 공용 권한 판정 함수가 새로 만들어진 것까지는 lint, typecheck, 테스트 78건, build 통과로 확인했습니다. 다만 이 시점에서는 코드 레벨 검증까지만 마친 상태였고, 이 변경이 실제 운영 DB에도 반영됐는지는 다음 단계에서 확인해야 할 문제로 남아있었습니다.

🧐 재설계 근거 (Why)

"문서에 없는 Business Rule을 임의로 추가하지 않는다"는 원칙에 따라, 새 규칙을 만들기보다 이미 문서화된 원래 설계를 복구하는 방향을 택했습니다. MEMBER 계정을 어디로 이관할지 결정할 때도, BUSINESS_REVIEWER로 보내면 기존 계정의 관리 권한이 사라지는 회귀가 발생하기 때문에 TRANSFORMATION_PLANNER를 선택했습니다. 즉 새 기능을 만드는 판단이 아니라, 기존 사용자에게 손해가 가지 않는 쪽(least regression)을 기본값으로 삼은 결정이었습니다.

💡 재현 가능성 (Replicability)

docs/05_data_model.md에서 해당 컬럼의 타입/Enum 정의를 확인한다
실제 DB에서 SELECT unnest(enum_range(NULL::해당_enum))으로 실제 저장 가능한 값을 확인한다
코드의 TypeScript Enum 정의와 대조한다
불일치가 있으면 문서를 Source of Truth로 삼아 코드와 DB를 문서에 맞춘다
기존 데이터 이관 시 각 값이 어디로 옮겨져야 회귀가 없는지 먼저 판단한다

SI in AI Platform

프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료

Next.jsSupabaseTypeScriptZodVitestPostgreSQL