백엔드 로직과 데이터 통합
동시 요청과 외부 장애 속에서도 데이터 일관성을 어떻게 지키는가? 핵심 이론부터 사례 분석, 단계별 실습, 품질 검수, 종합 문제까지 혼자 학습할 수 있도록 구성한 전공 실습 교재입니다.
오늘의 질문과 학습목표
동시 요청과 외부 장애 속에서도 데이터 일관성을 어떻게 지키는가? 이 질문에 자신의 말로 답할 수 있고, 설계 결과물을 직접 만들고 검수하는 것이 오늘의 완료 기준입니다.
서비스 계층과 저장소의 책임을 나눈다.
트랜잭션 경계를 설계한다.
낙관적·비관적 락을 비교한다.
외부 API 장애에 타임아웃·재시도·차단기를 적용한다.
이벤트 기반 통합과 보상 처리를 설명한다.
로그·메트릭·추적 정보로 문제를 진단한다.
혼자 공부하는 순서
- 용어를 암기하기 전에 사례에서 문제가 생기는 이유를 설명합니다.
- 좋은 예와 나쁜 예의 차이를 관찰 가능한 기준으로 적습니다.
- 예시를 보지 않고 종합 실습을 먼저 해결합니다.
- 모범답안과 비교한 뒤 빠진 조건을 다른 색으로 보완합니다.
교재 목차
- 학습 안내와 학습목표Page 02
- 제1장. 핵심 이론과 설계 원칙Page 04
- 제2장. 단계별 설계 실습Page 05
- 제3장. 사례 분석과 품질 검수Page 06
- 제4장. 종합 실습과 모범답안Page 07
- 핵심 용어와 최종 점검Page 08
- 자기주도 심화학습과 안내형 실습Pages 09–11
종합 실습 결과물, 자가진단 80점 이상, 핵심 질문 4개에 대한 자신의 답을 남기면 Day 7 학습을 완료한 것입니다.
백엔드 로직과 데이터 통합 핵심 이론
전문 용어는 복잡해 보이지만, 각 용어는 설계에서 반복되는 한 가지 문제를 해결하기 위해 존재합니다. 아래 표에서 “무엇을 뜻하는가”보다 “언제 필요한가”를 중심으로 학습하세요.
| 핵심 개념 | 설명 |
|---|---|
| Transaction | 여러 데이터 변경을 하나의 성공 또는 실패 단위로 묶습니다. |
| Optimistic Lock | 충돌이 적다고 보고 버전 비교로 갱신 충돌을 검출합니다. |
| Pessimistic Lock | 충돌 가능성이 높을 때 자원을 먼저 잠급니다. |
| Timeout / Retry | 응답 대기 한계와 일시 실패 재시도 정책입니다. |
| Circuit Breaker | 계속 실패하는 외부 호출을 잠시 차단합니다. |
| Outbox Pattern | DB 변경과 이벤트 발행의 불일치를 줄이는 패턴입니다. |
좋은 설계와 나쁜 설계의 차이
피해야 할 접근
DB 저장, 결제 API, 이메일 발송을 하나의 긴 요청에서 무제한 재시도한다.
권장 접근
핵심 DB 트랜잭션을 짧게 유지하고 외부 작업은 타임아웃·멱등성·이벤트와 보상 정책으로 분리한다.
[입력 검증] → [권한 확인] → [트랜잭션] → [상태 저장] → [이벤트/외부 연동] → [관측과 복구]
단계별 설계 절차
문제 정의
유스케이스의 불변 조건과 최종 상태를 정의한다.
구조 추출
원자적으로 처리할 DB 변경만 트랜잭션으로 묶는다.
핵심 설계
동시 수정 빈도에 따라 락 전략을 선택한다.
실패 조건
외부 호출에 연결·응답 타임아웃과 제한된 재시도를 둔다.
정책 연결
중복 메시지와 부분 실패에 멱등성·보상 처리를 적용한다.
검증과 추적
correlation ID로 로그, 메트릭, 분산 추적을 연결한다.
작동하는 예시
예시를 읽을 때 확인할 것
- 입력과 시작 조건이 명확한가?
- 정상 결과뿐 아니라 실패 결과도 관찰 가능한가?
- 중복·권한·동시성·외부 장애가 필요한 수준으로 다뤄졌는가?
- 요구사항과 구현 결과를 서로 추적할 수 있는가?
사례 분석과 품질 검수
스스로 설명해 보기
- DB 트랜잭션 안에서 외부 API를 오래 호출하면 왜 위험한가?
- 재시도에 지수 백오프가 필요한 이유는?
- 낙관적 락이 적합한 상황은?
- at-least-once 메시지에서 중복 처리는 어떻게 막는가?
각 질문에 2~3문장으로 답하고, 답을 뒷받침하는 사례를 하나씩 적으세요.
품질 자가진단 · 100점
| 영역 | 판단 기준 | 점수 |
|---|---|---|
| 정확성 | 개념과 기술 선택이 요구사항 및 사실에 맞는다. | 25 |
| 완전성 | 정상 흐름, 경계 조건, 실패와 복구를 함께 다룬다. | 25 |
| 일관성 | 용어, ID, 상태, 인터페이스가 산출물 사이에서 일치한다. | 20 |
| 검증 가능성 | 관찰 가능한 결과와 완료 기준을 제시한다. | 20 |
| 설명력 | 선택한 방법과 대안의 차이를 자신의 말로 설명한다. | 10 |
틀린 결과만 고치지 말고, 빠진 질문이 무엇이었는지 기록하세요. 좋은 엔지니어는 정답을 외우기보다 다음 설계에서 같은 누락을 막는 점검 기준을 만듭니다.
종합 실습과 모범답안
재고가 1개 남은 상품에 동시에 100개의 주문이 들어오는 흐름을 설계하세요. 결제 성공 후 재고 저장 실패도 처리하세요.
- 핵심 가정과 미결정 사항을 먼저 적습니다.
- 주요 설계 결과물을 표, 코드 또는 다이어그램으로 작성합니다.
- 정상 흐름과 최소 3개의 실패·경계 조건을 포함합니다.
- 자가진단표로 채점하고 개선 전후를 비교합니다.
모범답안의 핵심 방향 보기
재고 감소는 조건부 UPDATE 또는 행 잠금으로 한 요청만 성공시킵니다. 주문 요청에는 멱등성 키를 사용합니다. 결제 후 재고 확정이 실패하면 결제 취소 이벤트를 발행하고 처리 결과를 추적 가능한 상태로 저장합니다.
답안 사용법
모범답안은 유일한 정답이 아닙니다. 자신의 설계가 다른 경우에는 요구사항, 비용, 복잡도, 위험 중 어떤 근거로 다른 선택을 했는지 설명할 수 있어야 합니다.
핵심 용어와 최종 점검
| 용어 | 쉽게 말하면 |
|---|---|
| ACID | 트랜잭션의 원자성·일관성·격리성·지속성 |
| Deadlock | 트랜잭션들이 서로의 락을 기다리는 상태 |
| Backoff | 재시도 간격을 점차 늘리는 전략 |
| Circuit Breaker | 연속 실패 시 호출을 차단하는 장치 |
| Outbox | DB와 이벤트 발행을 함께 기록하는 패턴 |
| Correlation ID | 여러 서비스의 한 요청을 연결하는 식별자 |
제출 전 8문항
- 오늘의 핵심 질문에 자신의 말로 답할 수 있는가?
- 설계의 입력, 조건, 결과가 명확한가?
- 정상 흐름뿐 아니라 실패와 복구를 포함했는가?
- 동시성, 중복 요청, 권한 문제를 검토했는가?
- 외부 시스템 장애와 타임아웃을 고려했는가?
- 선택한 방법의 단점과 대안을 설명할 수 있는가?
- 산출물 사이의 용어와 상태가 일치하는가?
- 테스트하거나 관찰할 수 있는 완료 기준이 있는가?
동시 요청과 외부 장애 속에서도 데이터 일관성을 어떻게 지키는가? 오늘 만든 결과물을 근거로 이 질문에 답해 보세요.
맥락으로 이해하는 핵심 용어
용어를 정의만 외우지 말고 판단 도구로 익히세요. 각 행을 정의→필요한 이유→예시 또는 주의점 순서로 읽습니다.
| 용어 | 쉬운 정의 | 왜 중요한가 | 예시 또는 주의점 |
|---|---|---|---|
| 서비스 계층 | 업무 규칙과 여러 저장소·외부 API 호출을 조정하는 영역 | 화면·DB 세부사항에서 핵심 정책을 분리 | 컨트롤러에 모든 로직을 넣지 않는다. |
| 트랜잭션 | 여러 데이터 변경을 전부 성공하거나 전부 취소하는 단위 | 부분 저장으로 인한 불일치를 방지 | 트랜잭션 범위를 외부 API 대기까지 길게 잡지 않는다. |
| 검증 | 입력 형식과 업무 규칙을 확인하는 과정 | 잘못된 상태가 저장되기 전에 차단 | 형식 검증과 권한·재고 같은 업무 검증을 구분한다. |
| 캐시 | 자주 쓰는 결과를 빠른 저장소에 임시 보관하는 방식 | 읽기 지연과 원본 부하 감소 | 무효화 시점과 오래된 데이터 허용 범위를 정한다. |
| 큐 | 작업을 순서대로 보관해 비동기로 처리하는 구조 | 느린 후속 작업과 트래픽 급증을 완충 | 재시도·실패 큐·중복 소비를 설계한다. |
| 관측 가능성 | 로그·메트릭·추적으로 내부 상태를 추론할 수 있는 능력 | 운영 장애의 위치와 원인을 빠르게 찾음 | 요청 ID를 서비스 간에 전달한다. |
주문 생성 시 재고를 차감하고 결제를 요청한 뒤 이메일을 비동기로 발송한다.
안내형 실습과 문제 해결
실습 상황
주문 생성 시 재고를 차감하고 결제를 요청한 뒤 이메일을 비동기로 발송한다.
순서대로 수행하기
- 업무 불변조건과 실패 시 유지해야 할 상태를 적는다.
- DB 트랜잭션과 외부 호출 경계를 나눈다.
- 재시도 가능한 오류와 즉시 실패할 오류를 분류한다.
- 요청 ID·구조화 로그·핵심 메트릭을 추가하고 장애를 재현한다.
산출물 1개, 핵심 가정 3개, 실패 사례 3개 이상을 저장하세요. 다른 학습자가 추가 질문 없이 판단 과정을 재현할 수 있어야 합니다.
결과가 다를 때 진단하기
| 관찰한 증상 | 가능한 원인 | 다음 조치 |
|---|---|---|
| 재고만 줄고 주문이 없음 | 트랜잭션 범위 오류 | 주문·재고 변경을 원자적으로 처리 |
| 이메일 장애로 주문도 실패 | 후속 작업 강결합 | 주문 확정 후 큐로 발행 |
| 장애 원인을 찾기 어려움 | 상관관계 ID 없음 | 요청 ID와 단계별 결과 기록 |
스스로 이해도 확인하기
인출 연습 — 펼치기 전에 답하기
외부 결제를 DB 트랜잭션 안에서 기다리면 왜 위험한가?
잠금 시간이 길어져 처리량이 떨어지고 장애 전파 가능성이 커집니다.
캐시 무효화란?
원본 데이터가 바뀔 때 오래된 캐시를 삭제하거나 갱신하는 정책입니다.
백엔드 완료 기준은?
업무 규칙, 실패 복구, 보안, 관측 가능성을 테스트로 증명해야 합니다.
페이지를 보지 않고 오늘의 핵심 판단, 대표 실패 원인, 검증 방법을 연결해 설명하세요. 세 가지가 이어지지 않으면 놓친 용어나 진단 사례로 돌아갑니다.