"시나리오를 몰아넣으면 실패할 때 반드시 대가를 치른다"
앞서 만든 개별 규칙들, 즉 Workspace 격리와 권한 매트릭스는 각각 테스트를 통과한 상태였습니다. 하지만 이 규칙들이 동시에 얽히는 실제 시나리오, 예를 들어 다른 회사 사람과 비멤버와 VIEWER와 관리자가 한 프로젝트에 동시에 접근을 시도하는 상황은 한 번도 검증한 적이 없었습니다.
4가지 시나리오, 즉 비멤버 차단, VIEWER 경계, ADMIN 허용, 타 회사 차단을 테스트로 설계했습니다. 그런데 1차 구현 결과를 확인해보니, 이 4개 시나리오가 하나의 it() 블록 안에 전부 몰려있는 구조였습니다. 이렇게 되면 테스트가 통과할 땐 편하지만, 하나라도 실패하면 어디서 문제가 생겼는지 특정하기 어렵다는 문제가 있었습니다.
beforeAll과 afterAll로 셋업과 정리는 한 번만 수행하되, 검증 로직 자체는 시나리오별로 개별 테스트로 쪼개도록 재작성을 요구했습니다. 계정 5개와 회사 2개를 생성하는 셋업 비용은 유지하면서도, 실패 위치는 독립적으로 특정할 수 있는 구조를 만든 것입니다.
재작성된 구조로 4개 시나리오가 각각 독립적으로 통과/실패를 확인할 수 있는 상태가 됐고, 커밋으로 이 단계의 작업 전체가 마무리됐습니다. 테스트 하나에 여러 시나리오를 몰아넣는 것의 대가는 통과할 때가 아니라 실패할 때 드러난다는 걸 확인한 작업이었습니다.
테스트 실패 시 디버깅 속도와, 계정 5개·회사 2개를 매번 생성해야 하는 셋업 비용 사이에서 균형을 잡아야 했습니다. 셋업과 정리는 한 번만 하되 검증 로직은 시나리오별로 쪼개는 방식이, 두 요구를 동시에 만족시킨다고 판단했습니다. 이는 순수하게 실용적인 이유였고, 대단한 설계 철학이 있었던 건 아닙니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료