Mission 1 설계 첫 사용자 되어보기 실습 가이드
📥 실습 입력 (Input)
- •
day5_signup_flow.md(회의 대화 기록)
💾 실습 출력 (Output)
- •
design-decision-log.md(첫 사용자 되어보기 문서)
1. 스토리 및 실습 배경
스마트폰을 이용해 메신저를 보내거나 뉴스를 읽는 것은 가능하지만, 새로운 모바일 가입 양식을 기입하거나 시간 예약을 복잡한 절차에 맞춰서 처리해 본 적이 거의 없는 50대 개인 사업자 유저가 있습니다.
개발팀은 비밀번호 가입 유효 조건 등을 무심코 설계했으나, 초보 고객들은 아이디 중복확인 버튼 클릭 누락, 글자 크기 인지 문제, 에러 발생 시 모든 입력이 통째로 날아가는 장애 앞에서 좌절하게 됩니다.
이번 미션에서는 기술설계 단계에서 진행된 데이터 정규화 및 아키텍처 의결 배경을 Codex를 활용해 정형화된 Design Decision Log 문서로 작성하여, 시스템의 역사적 자산과 설계 근거(Why)를 안전하게 관리하는 법을 배웁니다.
2. 학습 목표
- 회의록에서 정규화 및 데이터베이스 구조 설계 결정을 정확하게 추출할 수 있다.
- 의결 항목, 배경 사유, 대안 검토, 승인자, 향후 변경 가능성을 명문화할 수 있다.
- 설계 의사결정의 역사(Why)를 기록하여 신규 팀원의 중복 회의와 실수를 예방할 수 있다.
🛠️ 실제 따라 하기 실습 가이드
- 실습용 파일 생성: 아래 다운로드 버튼을 눌러
day5_signup_flow.md파일을automation/폴더 내에 저장합니다. - Codex 로깅 위임: Codex Client 프롬프트 입력창에 아래 **Codex 요청 프롬프트**를 전송하여 빌드합니다.
- 로그 점검: 출력된 리포트에서 결정 ID(DEC-003), 의결 배경, 검토 대안(기각 사유), 승인 주체가 정확히 구조화되었는지 검토합니다.
실습 자료 다운로드
Codex 요청 프롬프트
Mission 01 Prompt
당신은 디지털 스마트폰 앱 사용이 다소 서툰 50대 자영업자입니다. 제공된 day5_signup_flow.md 명세서에 작성된 회원가입 및 첫 화면 UI 명세를 보면서, 당신의 입장에서 가입 시 무엇이 가장 헷갈리고 어려운지 감정적인 반응과 개선 요구사항을 적어주세요.
4. 결과물 예시
Codex는 대화 내역에서 아키텍처적 결론과 그 타협 근거를 아래와 같이 문헌화해 냅니다.
[결정 ID: DEC-003]
• 결정 사항: 예약 취소 이력을 Reservations 테이블에 직접 누적하지 않고 별도의 Reservation_Histories 테이블로 1:N 분리 설계.
• 생생한 사용자 첫 반응 및 피드백 (Pain Point): 예약 상태 변경이 잦아 메인 테이블의 쓰기 잠금(Write Lock) 병목 방지 및 일자별/상담사별 이력 추적 요건 충족.
• 검토 대안: Reservations 테이블에 canceled_at, cancel_reason 직접 추가 (기각: 다중 취소 이력 기록 불가 및 테이블 비대화 리스크)
• 승인 주체: PM 및 Lead Engineer (승인자: Dev_Lead)
• 향후 변경 가능성: 대규모 트래픽 발생 시 NoSQL Document DB로 이력 이관 가능성 있음.
• 결정 사항: 예약 취소 이력을 Reservations 테이블에 직접 누적하지 않고 별도의 Reservation_Histories 테이블로 1:N 분리 설계.
• 생생한 사용자 첫 반응 및 피드백 (Pain Point): 예약 상태 변경이 잦아 메인 테이블의 쓰기 잠금(Write Lock) 병목 방지 및 일자별/상담사별 이력 추적 요건 충족.
• 검토 대안: Reservations 테이블에 canceled_at, cancel_reason 직접 추가 (기각: 다중 취소 이력 기록 불가 및 테이블 비대화 리스크)
• 승인 주체: PM 및 Lead Engineer (승인자: Dev_Lead)
• 향후 변경 가능성: 대규모 트래픽 발생 시 NoSQL Document DB로 이력 이관 가능성 있음.