[항해 플러스 Lite 백엔드] 2주차 WIL #시나리오 분석 #설계

과제

이번 주 과제는 3개의 시나리오 중 하나를 선택해 분석하고 설계하는 것이다.

시나리오는 e-커머스, 맛집 검색, 콘서트 예약 이렇게 3가지였고 콘서트 예약 서비스를 선택했다.

 

기능 구현에 앞서, 전체 API에 대한 요구사항을 분석하고 시퀀스 다이어그램, ERD, 인프라 구성도 등 설계 문서를 작성하는 작업을 진행했다.

 

 

 

과제 해결 과정

1. 요구사항 분석

시나리오를 기반으로 사용자와 시스템 간 상호작용을 세분화하여, 다음과 같은 주요 기능을 도출했다.

 

 핵심 기능 목록

• 유저 토큰 발급
• 예약 가능 날짜 / 좌석 조회
• 좌석 예약 요청
• 잔액 충전 / 조회
• 결제

 

고려사항

• 동일 좌석에 대한 중복 예매 방지
• 예매 요청 시 대기열 기반 선착순 처리
• 좌석 예약 요청 시 결제가 이루어지지 않더라도 일정 시간 동안 다른 유저가 해당 좌석 접근 불가능

 

 

2. 시퀀스 다이어그램

🔗 시퀀스 다이어그램

분석한 요구사항이 어떤 흐름으로 흘러가 최종적으로 어떤 데이터가 만들어지는지에 초점을 맞추며 시퀀스 다이어그램을 작성했다.

 

3. 엔티티 관계 다이어그램 (ERD)

🔗 엔티티 관계 다이어그램

 

서비스의 도메인을 반영하여 다음과 같이 ERD를 작성했다.

정규화 및 관계 설정을 통해 불필요한 중복을 최소화하였다.

 

Table	Title
users	사용자
user_balance_history	사용자 잔액 내역
queue_tokens	대기열 토큰
concert_schedules	콘서트 일정
seats	콘서트 좌석
seat_reservations	좌석 예약 내역
payments	결제 내역

 

 

4. 인프라 구성도 작성

서비스가 배포될 환경과 주요 구성 요소들을 다음과 같이 설계했다.

 

인프라 구성

• Backend: Spring Boot + REST API
• DB: MySQL (데이터 저장)
• Redis: 대기열 처리, Lock, 캐시 관리
• 서버 환경: Nginx + Docker 기반 컨테이너화

 

 

이번 주에 배운 것

항목	내용
요구사항 명세화	실제 유저 시나리오 기반으로 기능 정리 및 예외 상황까지 고려
전체 API 시퀀스 구성	하나의 흐름이 아닌 모든 API 흐름을 명확히 정의
ERD 설계	데이터 정합성과 확장성을 고려한 테이블 설계
인프라 설계	캐시, 락, 트래픽 분산을 포함한 현실적인 시스템 구성 고려

 

 

회고

이번 주는 코드를 짜지 않아도 할 수 있는 가장 중요한 설계에 집중한 시간이었다.
API 흐름 하나하나를 직접 그려보면서 서비스 전체 구조에 대한 감을 잡을 수 있었고,
구현 전에 설계를 명확히 해두는 것이 얼마나 중요한지 체감했다.