Mission 2 예외 시나리오 발굴 실습 가이드
📥 실습 입력 (Input)
- •
database-schema.md(DB 물리 스키마 정의서)
💾 실습 출력 (Output)
- •
edge-case-analysis.md(예외 시나리오 리포트)
1. 스토리 및 실습 배경
스타트업이 MVP 제품을 성공적으로 론칭한 첫날 밤, 예상치 못한 서버 알람이 울립니다. 똑같은 예약 시간대에 두 명의 사용자가 동시에 결제 버튼을 눌렀고, 결제는 둘 다 성공했는데 데이터베이스에는 마지막 결제자만 덮어쓰기되어 첫 번째 결제자의 예약 데이터가 날아가 버린 것입니다. (동시성 제어 예외 상황)
또한, 회원 탈퇴를 한 사용자의 DB 레코드를 물리적으로 완전히 삭제(Hard Delete)했더니, 기존에 그 사용자가 결제했던 과거 매출 데이터의 user_id 외래키 참조 무결성이 깨져 일일 정산 매출 통계 쿼리 실행이 중단되는 끔찍한 연쇄 장애도 발생했습니다.
설계 단계에서 이러한 비정상 흐름이나 예외 상황(Edge Cases)을 꼼꼼하게 예측하여 데이터 무결성 규칙을 세워두지 않으면 제품 배포 후 치명적인 비즈니스 손실을 입게 됩니다. 이번 미션에서는 구축된 데이터 모델을 기준으로 발생 가능한 데이터 왜곡 및 잠재적 예외 케이스를 Codex를 가동해 사전에 전수 도출하고 대응 방안을 선제 설계하는 기법을 체득합니다.
2. 학습 목표
- 정의된 테이블 스키마와 외래키 참조 구조에서 논리적 설계 결함을 감지할 수 있다.
- 동시성 쓰기, 참조 무결성 붕괴, 트랜잭션 롤백 실패 등 Edge Case 시나리오를 도출할 수 있다.
- Hard Delete 탈퇴를 방어하는 Soft Delete(논리 삭제) 등 대처 방안을 마련할 수 있다.
🛠️ 실제 따라 하기 실습 가이드
- 실습용 파일 생성: 아래 다운로드 버튼을 눌러
database-schema.md파일을automation/폴더 내에 저장합니다. - Codex 검증 위임: Codex Client 프롬프트 입력창에 아래 **Codex 요청 프롬프트**를 전송하여 빌드합니다.
- 대처 설계 확인: 도출된 리포트에서 중복 예약 방지책(분산 락/Unique 제약) 및 Soft Delete 논리식별값 설계 등 구체적인 DB 개선책이 수립되었는지 검토합니다.
실습 자료 다운로드
Codex 요청 프롬프트
Mission 02 Prompt
현재 정의된 User, Expert, Reservation, Payment 테이블 구조에서 발생할 수 있는 데이터 정합성 위배 Edge Case 예외 시나리오를 도출하고 개선 방안을 제시해 주세요.
4. 결과물 예시
Codex는 스키마 논리를 화이트박스로 해부하여 아래와 같은 치명적 예외 시나리오를 도출합니다.
| 예외 분류 | 발생 가능 시나리오 (Edge Case) | 시스템 영향도 | 권장 개선 방안 |
|---|---|---|---|
| 동시성 오류 | 동일 상담 시간대에 두 사용자가 동시에 예약 결제를 진행해 둘 다 성공 판정이 나서 중복 매핑되는 현상 | 치명적 | DB 예약 테이블에 복합 UNIQUE 제약조건 생성 또는 Redis 분산 락 적용 |
| 참조 무결성 | 결제 이력이 있는 User 레코드를 Hard Delete 처리해 외래키 관계가 끊겨 일일 매출 정산 통계 쿼리가 깨지는 현상 | 치명적 | is_deleted 컬럼 및 탈퇴 시간을 기록하는 Soft Delete(논리 삭제) 테이블 설계 변경 |
| 데이터 불일치 | 외부 PG 결제 승인은 성공했으나 우리 DB 인서트 단계에서 네트워크 장애로 롤백되어 결제 기록이 공중 분해되는 현상 | 보통 | 결제 트랜잭션을 분산 트랜잭션(Saga Pattern)으로 묶고, 결제 미확정 건 배치 검증 스크립트 가동 |