"안전장치를 만들면 어딘가에 새로운 제약이 반드시 생긴다"
로그인 계정은 만들 수 있었지만, 화면에 표시할 이름 같은 프로필 정보를 저장할 곳이 없었습니다. 운영자가 계정을 수동으로 만드는 정책과 맞물려서, 계정만 만들고 프로필 만드는 걸 깜빡하는 운영 실수가 구조적으로 가능한 상태였습니다.
프로필 생성을 수동으로 할지, 계정 생성 시 자동으로 함께 만들어지는 트리거로 할지 두 가지 안을 검토했습니다. 사람이 기억해야 하는 단계를 하나라도 줄이는 게 실수를 줄인다고 판단해 자동 트리거 방식을 택했고, SECURITY DEFINER와 고정 search_path로 트리거를 작성했습니다.
리뷰 과정에서 이메일이 NULL인 계정, 예를 들어 전화번호로 가입하는 방식은 이 트리거에서 실패해 auth 계정 생성 자체가 롤백된다는 부작용을 발견했습니다. 이걸 그냥 넘기지 않고 의도된 제약으로 명시적으로 문서화하기로 했습니다.
결과적으로 계정 생성과 동시에 프로필 존재가 DB 트랜잭션 레벨에서 보장되는 구조를 확보했습니다. 다만 이메일 없는 계정은 아예 만들 수 없게 되는 새로운 제약이 함께 생겼습니다. 안전장치 하나를 만들면 어딘가에 반드시 새로운 제약이 생긴다는 걸 숨기지 않고 기록하는 게 진짜 완료라는 걸 이번에 다시 확인했습니다.
운영 절차에서 사람이 기억해야 하는 단계를 하나라도 줄이는 게 실수를 줄인다고 판단해 자동 트리거 방식을 택했습니다. 다만 이걸 "부작용 없는 개선"으로 포장하지 않기로 했습니다. 이메일이 없는 계정은 아예 생성 자체가 실패하는 새로운 제약이 생겼고, 이건 트레이드오프이지 순수한 개선이 아니라고 판단해 그대로 기록해두었습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(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 스키마 구현 완료