시퀀스 다이어그램과 데이터 흐름 설계
화면 뒤에서 어떤 객체가 어떤 순서로 통신하는가? 핵심 이론부터 사례 분석, 단계별 실습, 품질 검수, 종합 문제까지 혼자 학습할 수 있도록 구성한 전공 실습 교재입니다.
오늘의 질문과 학습목표
화면 뒤에서 어떤 객체가 어떤 순서로 통신하는가? 이 질문에 자신의 말로 답할 수 있고, 설계 결과물을 직접 만들고 검수하는 것이 오늘의 완료 기준입니다.
요구사항을 Actor·Boundary·Control·Entity로 분해한다.
동기·비동기 메시지와 반환을 구분한다.
alt·opt·loop 구문으로 예외와 반복을 표현한다.
동시 요청에서 발생하는 경쟁 조건을 설명한다.
Mermaid로 실행 가능한 시퀀스 다이어그램을 작성한다.
다이어그램과 API·데이터 설계의 일관성을 검수한다.
혼자 공부하는 순서
- 용어를 암기하기 전에 사례에서 문제가 생기는 이유를 설명합니다.
- 좋은 예와 나쁜 예의 차이를 관찰 가능한 기준으로 적습니다.
- 예시를 보지 않고 종합 실습을 먼저 해결합니다.
- 모범답안과 비교한 뒤 빠진 조건을 다른 색으로 보완합니다.
교재 목차
- 학습 안내와 학습목표Page 02
- 제1장. 핵심 이론과 설계 원칙Page 04
- 제2장. 단계별 설계 실습Page 05
- 제3장. 사례 분석과 품질 검수Page 06
- 제4장. 종합 실습과 모범답안Page 07
- 핵심 용어와 최종 점검Page 08
- 자기주도 심화학습과 안내형 실습Pages 09–11
종합 실습 결과물, 자가진단 80점 이상, 핵심 질문 4개에 대한 자신의 답을 남기면 Day 2 학습을 완료한 것입니다.
시퀀스 다이어그램과 데이터 흐름 설계 핵심 이론
전문 용어는 복잡해 보이지만, 각 용어는 설계에서 반복되는 한 가지 문제를 해결하기 위해 존재합니다. 아래 표에서 “무엇을 뜻하는가”보다 “언제 필요한가”를 중심으로 학습하세요.
| 핵심 개념 | 설명 |
|---|---|
| Lifeline | 상호작용에 참여하는 사용자, 화면, 서비스, DB 같은 객체의 시간축입니다. |
| Message | 객체 사이의 요청과 응답입니다. 호출 방향과 순서가 핵심입니다. |
| Activation | 객체가 실제로 작업을 수행하는 구간입니다. |
| Combined Fragment | 조건 분기(alt), 선택(opt), 반복(loop), 병렬(par)을 표현합니다. |
| Boundary | 사용자나 외부 시스템과 맞닿는 화면 또는 API 경계입니다. |
| Control / Entity | 업무 흐름을 조정하는 로직과 영속 데이터를 각각 뜻합니다. |
좋은 설계와 나쁜 설계의 차이
피해야 할 접근
사용자 → 시스템 → DB처럼 모든 내부 책임을 “시스템” 하나로 표현한다.
권장 접근
사용자 → 예약 화면 → 예약 서비스 → 결제 게이트웨이 → DB로 책임과 실패 지점을 분리한다.
[시작 조건] → [참여 객체] → [동기/비동기 메시지] → [상태 변화] → [응답 또는 보상 처리]
단계별 설계 절차
문제 정의
요구사항에서 사용자 목표와 시작 조건을 표시한다.
구조 추출
화면·서비스·외부 API·데이터 저장소를 참여 객체로 추출한다.
핵심 설계
정상 흐름을 시간순으로 배치하고 요청/응답을 구분한다.
실패 조건
실패·타임아웃·중복 요청을 alt 블록으로 추가한다.
정책 연결
동시 접근 자원에 락, 버전, 멱등성 정책을 연결한다.
검증과 추적
요구사항 ID와 API·테이블 이름을 다이어그램에 추적한다.
작동하는 예시
예시를 읽을 때 확인할 것
- 입력과 시작 조건이 명확한가?
- 정상 결과뿐 아니라 실패 결과도 관찰 가능한가?
- 중복·권한·동시성·외부 장애가 필요한 수준으로 다뤄졌는가?
- 요구사항과 구현 결과를 서로 추적할 수 있는가?
사례 분석과 품질 검수
스스로 설명해 보기
- 동기 호출과 비동기 이벤트를 어떤 기준으로 선택하는가?
- alt와 opt의 차이는 무엇인가?
- 다이어그램에서 타임아웃을 반드시 표현해야 하는 이유는?
- 같은 요청이 재전송될 때 중복 처리를 막는 방법은?
각 질문에 2~3문장으로 답하고, 답을 뒷받침하는 사례를 하나씩 적으세요.
품질 자가진단 · 100점
| 영역 | 판단 기준 | 점수 |
|---|---|---|
| 정확성 | 개념과 기술 선택이 요구사항 및 사실에 맞는다. | 25 |
| 완전성 | 정상 흐름, 경계 조건, 실패와 복구를 함께 다룬다. | 25 |
| 일관성 | 용어, ID, 상태, 인터페이스가 산출물 사이에서 일치한다. | 20 |
| 검증 가능성 | 관찰 가능한 결과와 완료 기준을 제시한다. | 20 |
| 설명력 | 선택한 방법과 대안의 차이를 자신의 말로 설명한다. | 10 |
틀린 결과만 고치지 말고, 빠진 질문이 무엇이었는지 기록하세요. 좋은 엔지니어는 정답을 외우기보다 다음 설계에서 같은 누락을 막는 점검 기준을 만듭니다.
종합 실습과 모범답안
같은 좌석을 두 사용자가 동시에 예약하는 상황을 시퀀스로 설계하세요. 결제 성공 후 DB 저장이 실패하는 경우도 포함하세요.
- 핵심 가정과 미결정 사항을 먼저 적습니다.
- 주요 설계 결과물을 표, 코드 또는 다이어그램으로 작성합니다.
- 정상 흐름과 최소 3개의 실패·경계 조건을 포함합니다.
- 자가진단표로 채점하고 개선 전후를 비교합니다.
모범답안의 핵심 방향 보기
예약 서비스가 좌석 행을 잠그거나 버전 값을 검사한 뒤 한 요청만 결제로 진행시켜야 합니다. 결제는 성공했지만 예약 저장이 실패하면 승인 취소 또는 환불이라는 보상 트랜잭션을 호출하고 운영 알림을 남깁니다.
답안 사용법
모범답안은 유일한 정답이 아닙니다. 자신의 설계가 다른 경우에는 요구사항, 비용, 복잡도, 위험 중 어떤 근거로 다른 선택을 했는지 설명할 수 있어야 합니다.
핵심 용어와 최종 점검
| 용어 | 쉽게 말하면 |
|---|---|
| Actor | 시스템 밖에서 목표를 수행하는 사용자나 외부 시스템 |
| Lifeline | 참여 객체의 시간축 |
| alt | 조건에 따라 하나의 흐름을 선택하는 분기 |
| par | 동시에 실행 가능한 흐름 |
| Race Condition | 실행 순서에 따라 결과가 달라지는 경쟁 상태 |
| Compensation | 완료된 앞 단계의 효과를 되돌리는 후속 처리 |
제출 전 8문항
- 오늘의 핵심 질문에 자신의 말로 답할 수 있는가?
- 설계의 입력, 조건, 결과가 명확한가?
- 정상 흐름뿐 아니라 실패와 복구를 포함했는가?
- 동시성, 중복 요청, 권한 문제를 검토했는가?
- 외부 시스템 장애와 타임아웃을 고려했는가?
- 선택한 방법의 단점과 대안을 설명할 수 있는가?
- 산출물 사이의 용어와 상태가 일치하는가?
- 테스트하거나 관찰할 수 있는 완료 기준이 있는가?
화면 뒤에서 어떤 객체가 어떤 순서로 통신하는가? 오늘 만든 결과물을 근거로 이 질문에 답해 보세요.
맥락으로 이해하는 핵심 용어
용어를 정의만 외우지 말고 판단 도구로 익히세요. 각 행을 정의→필요한 이유→예시 또는 주의점 순서로 읽습니다.
| 용어 | 쉬운 정의 | 왜 중요한가 | 예시 또는 주의점 |
|---|---|---|---|
| 동기 호출 | 호출자가 응답을 받을 때까지 다음 작업을 기다리는 통신 | 즉시 결과가 필요한 조회·검증에 적합 | 외부 API가 느리면 전체 요청도 느려진다. |
| 비동기 이벤트 | 요청을 보낸 뒤 기다리지 않고, 결과를 이벤트로 전달하는 방식 | 알림·로그·후속 처리의 결합도를 낮춤 | 처리 순서와 중복 소비 정책을 별도로 정해야 한다. |
| 멱등성 | 같은 요청을 여러 번 실행해도 최종 결과가 한 번 실행한 것과 같은 성질 | 재시도 때 중복 결제·중복 예약을 방지 | 요청 키를 저장하고 기존 처리 결과를 재사용한다. |
| 경쟁 조건 | 동시에 실행된 작업의 순서에 따라 결과가 달라지는 문제 | 재고·좌석처럼 수량이 제한된 자원에서 필수 | 검사와 갱신을 하나의 트랜잭션으로 묶는다. |
| 타임아웃 | 정해진 시간 안에 응답이 없으면 호출을 실패로 종료하는 규칙 | 무한 대기와 자원 고갈을 방지 | 재시도 횟수와 사용자 안내도 함께 설계한다. |
| 보상 처리 | 이미 성공한 앞 단계의 효과를 취소하는 후속 작업 | 분산된 서비스 사이에서 부분 실패를 복구 | 결제 성공·예약 실패 시 승인 취소를 실행한다. |
두 사용자가 마지막 좌석을 동시에 예약하고, 결제 승인 직후 데이터베이스 저장이 한 번 실패한다.
안내형 실습과 문제 해결
실습 상황
두 사용자가 마지막 좌석을 동시에 예약하고, 결제 승인 직후 데이터베이스 저장이 한 번 실패한다.
순서대로 수행하기
- Actor·화면·예약 서비스·결제 서비스·DB를 lifeline으로 적는다.
- 정상 흐름을 먼저 그리고 각 메시지에 입력값과 반환값을 쓴다.
- 동시 요청, 결제 거절, 저장 실패를 alt 블록으로 분리한다.
- 멱등성 키·좌석 잠금·보상 결제를 어느 객체가 책임지는지 표시한다.
산출물 1개, 핵심 가정 3개, 실패 사례 3개 이상을 저장하세요. 다른 학습자가 추가 질문 없이 판단 과정을 재현할 수 있어야 합니다.
결과가 다를 때 진단하기
| 관찰한 증상 | 가능한 원인 | 다음 조치 |
|---|---|---|
| 좌석이 두 번 판매됨 | 가용성 확인과 차감이 분리됨 | 행 잠금 또는 조건부 갱신 |
| 결제가 두 번 승인됨 | 재시도 요청을 새 요청으로 처리 | 멱등성 키와 처리 결과 저장 |
| 화면이 계속 대기함 | 외부 호출 타임아웃 없음 | 타임아웃·재시도·실패 응답 정의 |
스스로 이해도 확인하기
인출 연습 — 펼치기 전에 답하기
alt와 opt의 차이는?
alt는 여러 조건 중 하나를 선택하고, opt는 조건이 참일 때만 선택 구간을 실행합니다.
DB 저장 실패 뒤 결제를 왜 취소해야 하나?
돈은 빠졌지만 예약이 없는 불일치를 해소하기 위해서입니다.
다이어그램 완료 기준은?
정상·실패·복구 흐름과 각 책임이 구현 요소에 연결되어야 합니다.
페이지를 보지 않고 오늘의 핵심 판단, 대표 실패 원인, 검증 방법을 연결해 설명하세요. 세 가지가 이어지지 않으면 놓친 용어나 진단 사례로 돌아갑니다.