용어 심층 해설 가이드

이 가이드는 부하 테스트, 장애 관리, 성능 엔지니어링, 클라우드 인프라에서 사용하는 핵심 영문 용어를 상세하게 설명합니다. 단순한 짧은 정의가 아니라, 각 항목마다 배경 맥락·예시·흔한 오해 정정·실무 활용 팁을 함께 제공합니다.

Part 1 — 부하 테스트 (Load Testing)

Apdex (Application Performance Index)

정의: 애플리케이션 응답 시간에 대한 사용자 만족도를 0.0~1.0으로 나타내는 표준화된 점수.

계산식:

Apdex = (만족 요청 수 + 허용 요청 수 × 0.5) / 전체 요청 수

임계값 기준 (T = 목표 응답 시간, 예: 500ms):

분류	조건	가중치
Satisfied (만족)	응답 시간 ≤ T	1.0
Tolerating (허용)	T < 응답 시간 ≤ 4T	0.5
Frustrated (불만)	응답 시간 > 4T 또는 오류	0.0

점수 해석:

점수	등급	의미
0.94–1.0	Excellent	거의 모든 사용자 만족
0.85–0.93	Good	대부분 만족
0.70–0.84	Fair	체감 성능 저하 시작
0.50–0.69	Poor	불만 사용자 다수
< 0.50	Unacceptable	심각한 성능 문제

왜 중요한가: 퍼센타일 레이턴시 차트를 잘 모르는 이해관계자에게 성능 상태를 단 하나의 숫자로 전달할 수 있다.

흔한 오해: Apdex 점수가 높으면 다 좋다고 생각하는 것. 대부분의 요청이 빠르면 0.94가 나와도 P99 문제를 숨길 수 있다. Apdex는 꼬리 레이턴시(tail latency)를 가린다.

Assertion

정의: 부하 테스트에서 응답이 기대값을 충족하는지 검증하는 규칙. 통과 여부에 따라 해당 요청을 성공 또는 실패로 분류한다.

JMeter의 Assertion 유형:

유형	검증 대상
Response Code Assertion	HTTP 상태 코드 (예: 200, 201, 404)
Response Body Assertion	응답 본문에 특정 텍스트 포함/미포함 여부
JSON Path Assertion	JSONPath 표현식이 기대값과 일치하는지
XPath Assertion	XML 구조 검증
Size Assertion	응답 크기가 허용 범위 내인지
Duration Assertion	응답 시간이 지정 시간 미만인지

실무 예시:

GET /api/orders/123
→ 검증: status code == 200
→ 검증: body에 "orderId" 포함
→ 검증: 응답 시간 < 2000ms
→ 검증: JSON $.status == "CONFIRMED"

주의: Assertion 없이 실행하면 서버가 500 오류나 잘못된 데이터를 반환해도 “성공”으로 집계된다. 반드시 정의해야 한다.

흔한 오해: Assertion이 테스트를 느리게 만든다는 생각. 실제로는 네트워크 I/O에 비해 Assertion 처리 오버헤드는 무시할 수준이다.

Baseline

정의: 정상 운영 조건에서 측정한 성능 기준값. 이후 모든 테스트 결과를 이 기준과 비교한다.

Baseline에 포함할 항목:

응답 시간 (P50, P95, P99)
처리량 (RPS, TPS)
오류율 (Error Rate)
CPU, 메모리, 네트워크 I/O 사용률
DB 쿼리 횟수 및 레이턴시

Baseline을 측정해야 하는 시점:

코드 변경 전 (릴리스 이전)
클린 환경에 배포 직후
인프라 변경 후 (스케일링, 설정 변경)

활용 방법:

Baseline: P99 = 250ms, 500 RPS, CPU 30%
릴리스 후: P99 = 480ms, 500 RPS, CPU 72%
→ 성능 회귀 감지: 레이턴시 92% 증가, CPU 급등

흔한 오해: Baseline은 한 번만 잡으면 된다는 생각. 비즈니스 요구사항과 트래픽 패턴이 바뀌면 Baseline도 업데이트해야 한다. 버전 관리에 포함시키는 것이 좋다.

Bottleneck

정의: 시스템 전체 처리량이나 성능을 제한하는 컴포넌트. 해당 지점에서 요청이 쌓이고 레이턴시가 증가한다.

주요 병목 발생 위치:

위치	증상
CPU	CPU > 80%, 큐 적체 증가
Memory	스왑 사용 증가, GC 일시 정지
Database	슬로우 쿼리 로그, 커넥션 풀 포화
Network	대역폭 포화, 패킷 손실
Thread Pool	스레드 고갈, 요청 큐잉
Disk I/O	높은 디스크 대기 시간, 쓰기 레이턴시
External API	외부 서비스 호출 레이턴시 급등

병목 식별 방법:

부하가 증가할 때 레이턴시가 먼저 오르는 지점 관찰
해당 시점의 리소스 사용률 확인
코드 경로 프로파일링 (플레임 그래프, 트레이스)
해당 병목을 격리해서 재현

왜 단순하지 않은가: 하나의 병목을 해결하면 다음 병목이 드러난다. 성능 엔지니어링은 반복적인 과정이다.

Concurrent Users

정의: 부하 테스트 중 동시에 요청을 보내고 있는 가상 사용자(Virtual User)의 수.

용어 구분:

용어	의미
Concurrent Users	테스트 내에서 동시에 실행 중인 스레드 수
Active Users	브라우저 세션을 열고 있는 실제 사용자 수
RPS (Requests per Second)	실제로 생성되는 초당 요청 수

관계식:

RPS ≈ 동시 사용자 수 / 평균 응답 시간(초)

예시:

동시 사용자 100명
평균 응답 시간: 200ms (0.2초)
예상 RPS ≈ 100 / 0.2 = 500 RPS

Think Time의 영향: 사용자가 액션 사이에 2초 대기한다면:

RPS ≈ 100 / (0.2 + 2.0) = 약 45 RPS

흔한 오해: 동시 사용자가 많으면 RPS도 비례해서 늘어난다는 생각. Think Time, 응답 시간, 커넥션 한도가 모두 실제 요청 속도를 제한한다.

Endurance Testing (Soak Testing)

정의: 중간 수준의 부하를 장시간(보통 8~72시간) 지속 적용해, 시간이 지나야 나타나는 문제를 찾아내는 테스트.

내구성 테스트로 발견하는 문제:

문제 유형	증상
메모리 누수 (Memory Leak)	RAM 사용량이 지속적으로 증가
커넥션 누수 (Connection Leak)	DB/HTTP 커넥션 수가 계속 쌓임
캐시 포화 (Cache Exhaustion)	캐시가 꽉 차고 나서 응답 시간 증가
디스크 공간	로그/임시 파일이 디스크를 가득 채움
스레드 누수 (Thread Leak)	스레드 수가 계속 증가, 결국 크래시
GC 저하	가비지 컬렉션 일시 정지 시간이 점점 길어짐

테스트 설계 기준:

부하: 정상 프로덕션 부하의 70~100%
기간: 최소 8시간, 중요 시스템은 24~48시간
모니터링: 최소 30초 간격으로 메트릭 수집
알림: 메모리가 Baseline 대비 10% 이상 지속 증가 시 경보

핵심 지표: 메모리 증가율. 시간당 1MB 누수는 작아 보이지만, 1GB 힙 기준으로 약 42일 후 OOM 크래시가 발생한다.

Error Rate

정의: 부하 테스트 중 전체 요청에서 실패 요청이 차지하는 비율.

계산식:

Error Rate = (실패 요청 수 / 전체 요청 수) × 100

실패 유형 분류:

유형	예시
네트워크 오류	연결 거부, 타임아웃, DNS 실패
서버 오류	HTTP 5xx (500, 502, 503, 504)
클라이언트 오류 (관련)	테스트 데이터 문제로 발생한 4xx
Assertion 실패	HTTP 200이지만 응답 본문이 기대값과 다름
타임아웃	설정된 제한 시간 내에 응답 없음

허용 기준 (일반적):

프로덕션 SLA: < 0.1%
부하 테스트 합격 기준: < 1%
스트레스 테스트 (한계점): 1% 이상으로 상승 시작

중요한 관점: Error Rate만으로는 전체 그림을 볼 수 없다. 100 RPS에서 0.5% = 초당 0.5건 오류. 10,000 RPS에서 0.5% = 초당 50건 오류 — 실제 영향은 완전히 다르다.

Percentile Latency (P50 / P95 / P99 / P99.9)

정의: 특정 통계적 백분위수에서의 응답 시간. 전체 요청 중 해당 비율이 이 값보다 빠르게 처리되었음을 나타낸다.

해석 표:

백분위	의미	활용
P50 (중앙값)	전체 요청의 50%가 이 값보다 빠름	일반 사용자 체감
P75	75%가 이 값보다 빠름	상위 일반 체감
P95	95%가 이 값보다 빠름	거의 최악의 케이스
P99	99%가 이 값보다 빠름	꼬리 레이턴시 (100명 중 1명)
P99.9	99.9%가 이 값보다 빠름	극단 꼬리 (1000명 중 1명)

왜 평균을 쓰면 안 되는가:

요청 10건: [20, 22, 21, 19, 23, 20, 21, 18, 24, 5000]ms
평균: 518ms  ← 이상값 1개에 지배됨
P99: 5000ms  ← 실제 문제를 드러냄
P50: 21ms    ← 일반 사용자 체감은 정상

꼬리 레이턴시 증폭 효과: 10개의 마이크로서비스를 병렬 호출할 때, 각 서비스의 P99가 1%라면:

적어도 하나가 느릴 확률 = 1 - (0.99)^10 ≈ 9.6%

→ 개별 서비스에서 P99였던 것이 시스템 전체에서는 P90 수준의 문제가 된다.

SLO 설계 원칙: 항상 백분위수로 SLO를 정의한다:

좋은 예: “1,000 RPS에서 P99 < 500ms” — 명확하고 측정 가능
나쁜 예: “평균 레이턴시 < 200ms” — 오해를 유발하고 조작하기 쉬움

Ramp-Up

정의: 부하 테스트의 초기 단계로, 가상 사용자 수를 0에서 목표 부하까지 점진적으로 증가시키는 구간.

Ramp-Up이 필요한 이유:

실제 트래픽을 반영하지 않는 대규모 동시 접속(thundering herd) 방지
캐시 워밍업 허용
시스템이 스케일링(오토스케일링, JIT 컴파일)할 시간 부여
성능 저하가 시작되는 부하 임계점을 더 쉽게 식별

주요 Ramp-Up 패턴:

패턴	설명	사용 사례
Linear (선형)	시간에 따라 균등하게 증가	일반 표준 테스트
Step (계단형)	일정 간격으로 고정 사용자 수 추가	용량 테스트
Exponential (지수형)	느리게 시작해서 빠르게 증가	스트레스 테스트
Instant (즉시)	모든 사용자가 동시 시작	스파이크 테스트

권장 기간: 시스템이 Steady State(안정 상태)에 도달할 만큼 길어야 하며, 대부분의 애플리케이션에서 5~10분이 적절하다.

Think Time

정의: 부하 테스트 스크립트에서 사용자 액션 사이에 의도적으로 삽입하는 대기 시간. 실제 사람의 행동을 시뮬레이션한다.

Think Time이 중요한 이유: 실제 사용자는 요청을 즉시 연속으로 보내지 않는다. 페이지를 읽고, 폼을 채우고, 클릭 사이에 멈춘다. Think Time 없이 테스트하면:

인위적으로 높은 RPS가 생성됨
응답 시간이 실제보다 빠르게 나타남
실제 사용자 세션을 정확히 재현하지 못함

행동 유형별 일반적인 Think Time:

행동	Think Time
페이지 간 이동	2~5초
폼 작성	10~30초
콘텐츠 읽기	15~60초
결제 프로세스	30~120초

구현 방식:

Fixed (고정): 항상 정확히 3초 대기 (비현실적)
Random (랜덤): 1~5초 사이 균등 분포
Gaussian (가우시안): 평균 Think Time을 중심으로 정규 분포 (가장 현실적)
Recorded (녹화): 실제 사용자 세션 녹화에서 추출

흔한 오해: Think Time을 제거하면 테스트가 더 가혹해진다는 생각. 오히려 비현실적이 된다. Think Time 없이 100명의 가상 사용자는 정상 Think Time을 가진 약 2,000명의 사용자와 동등한 부하를 발생시킨다.

Throughput

정의: 시스템이 단위 시간당 처리하는 요청, 트랜잭션, 또는 작업의 수.

주요 단위:

단위	의미	주요 사용 영역
RPS	초당 요청 수	API 엔드포인트
TPS	초당 트랜잭션 수	비즈니스 트랜잭션
QPS	초당 쿼리 수	데이터베이스
IOPS	초당 I/O 작업 수	스토리지 시스템
Mbps	초당 메가비트	네트워크 대역폭

Throughput과 Latency의 관계: 부하가 증가할수록 처리량은 시스템 포화 지점까지 증가하다가 평탄해지거나 감소한다. 반면 레이턴시는 급격히 상승한다. 이를 “하키 스틱 곡선”이라고 한다.

목표 RPS:  100   200   500   800   1000  1200
실제 RPS:  100   200   498   750   800   780  (포화)
P99 ms:     25    28    85   320  1200  5000  (레이턴시 급등)

지속 가능한 처리량: 허용 가능한 레이턴시와 오류율을 유지하면서 무한정 처리할 수 있는 RPS. 보통 최대 처리량의 60~80% 수준이다.

Part 2 — 장애 관리 (Incident Management)

Alert Fatigue

정의: 가치 없거나 노이즈가 많은 알림이 너무 많아져서 엔지니어가 알림을 무시하거나 묵살하기 시작하는 상태.

Alert Fatigue가 발생하는 과정:

낮은 심각도 알림이 너무 많이 온콜을 호출함
일시적으로 자동 회복되는 상황에도 알림이 자주 발화함
엔지니어가 알림을 조사 없이 확인하고 닫아버림
진짜 중요한 알림이 묻힘 — SEV-1을 놓치는 사태 발생

경고 신호:

온콜 엔지니어가 지속적인 방해를 호소함
알림 확인율은 높지만 해결율은 낮음
엔지니어들이 중요하지 않은 알림 시간에 “방해 금지” 설정을 만듦
사후 분석에서 “알림이 울렸지만 아무도 몰랐다”는 사실이 드러남

개선 방법:

모든 알림 감사: 조치가 필요한 것 vs. 정보성으로 분류
오탐(False Positive)이 20% 이상인 알림은 제거하거나 우선순위 낮춤
서비스 소유자별 알림 라우팅 구현
복합 알림 사용 (3개 이상의 신호가 동시에 이상일 때만 발화)
최소 지속 시간 설정 (1초 스파이크에는 알림 없음)

Blameless Postmortem

정의: 인시던트 이후 특정 개인에게 책임을 돌리지 않고, 무슨 일이 왜 일어났는지 이해하는 데 집중하는 구조화된 검토 회의.

블레임리스(Blameless) 원칙: 시스템이 실패하는 것이지, 사람이 실패하는 것이 아니다. 오류는 불명확한 런북, 불충분한 모니터링, 복잡한 설정, 불충분한 테스트 등 시스템의 틈새에서 발생한다. 비난은 정직한 보고를 막아 학습을 억제한다.

표준 포스트모텀 구성:

섹션	내용
인시던트 요약	무슨 일이 언제, 누구에게 발생했는가
타임라인	시간순 사건 흐름
근본 원인 분석	기술적·프로세스적 근본 원인
영향 범위	사용자 영향, 매출 영향, 지속 시간
잘 된 점	빠른 해결에 도움이 된 행동
잘 못 된 점	지연, 공백, 소통 오류
액션 아이템	담당자 지정된 구체적 개선 항목

좋은 액션 아이템의 5가지 조건:

구체적 — “모니터링 개선”이 아니라 “체크아웃 서비스에 레이턴시 알림 추가”
담당자 지정 — 한 명의 실명 책임자
기한 설정 — 30~90일 이내 마감일
측정 가능 — 완료 기준이 명확함
우선순위 — 영향도 기준으로 순위화

흔한 함정: 액션 아이템 후속 조치 없는 포스트모텀. 티켓 시스템에 등록하고, 다음 포스트모텀 사이클에서 완료 여부를 검토해야 한다.

Escalation

정의: 현재 대응자가 예상 시간 내에 해결하지 못할 때, 더 높은 전문성·권한·추가 자원으로 인시던트를 이관하는 과정.

에스컬레이션 트리거:

트리거	조치
SLA 내 해결 안 됨	보조 온콜(Secondary On-Call)로 에스컬레이션
대응자의 전문 영역 외	서비스 담당자로 에스컬레이션
비즈니스 영향 증가 중	온콜 매니저로 에스컬레이션
규제·데이터 침해 위험	경영진으로 에스컬레이션
벤더 개입 필요	벤더 지원팀으로 에스컬레이션

에스컬레이션 단계 (일반적):

Level 1: Primary On-Call (초동 대응자)
Level 2: Secondary On-Call (도메인 전문가)
Level 3: 팀 리더 / 시니어 엔지니어
Level 4: 엔지니어링 매니저 / 디렉터
Level 5: VP Engineering / CTO

에스컬레이션 커뮤니케이션 템플릿:

[에스컬레이션] SEV-1 - 결제 API 중단
현재 상태: 발생 45분 경과, 근본 원인 미확인
영향: 결제 플로우 100% 실패
시도한 것: DB 페일오버, 서비스 재시작, 캐시 초기화
필요한 것: DB 팀 전문성 - 쿼리 플랜 분석
다음 업데이트: 15분 후

안티패턴: “면피 에스컬레이션” — 실제로 전문성이 필요해서가 아니라 뭔가 하는 것처럼 보이려고 에스컬레이션하는 것.

Five Whys Technique

정의: 사건이 발생한 이유를 반복적으로 “왜?”라고 질문해 (보통 5번) 증상에서 근본 원인까지 추적하는 근본 원인 분석 기법.

예시 — 결제 서비스 장애:

질문 번호	질문	답변
Why 1	왜 결제가 실패했나?	DB 커넥션 타임아웃
Why 2	왜 DB 커넥션이 타임아웃됐나?	커넥션 풀 고갈
Why 3	왜 커넥션 풀이 고갈됐나?	커넥션이 반환되지 않음
Why 4	왜 커넥션이 반환되지 않았나?	예외 발생 시 connection.close()가 실행되지 않음
Why 5	왜 이게 발견되지 않았나?	리소스 정리를 위한 코드 리뷰 체크리스트가 없음

근본 원인: 버그 자체가 아니라, 리소스 관리에 대한 코드 리뷰 프로세스 부재.

Five Whys의 한계:

단일 인과 사슬을 가정하지만, 실제 인시던트는 복수의 기여 요인을 가진 경우가 많음
답변이 조사자의 지식 수준에 의존함
너무 일찍 멈추면 증상만 파악하고 근본 원인에 못 미침

보완 방법: 복잡한 인시던트에는 “여러 분기가 있는 Five Whys” 또는 피쉬본(이시카와) 다이어그램을 활용한다.

Incident Commander (IC)

정의: 인시던트 대응을 총괄하고, 팀 활동을 조율하며, 대응 전략에 대한 최종 결정을 내리는 시니어 엔지니어 또는 매니저.

IC의 역할:

역할	상세 내용
심각도 선언	SEV 등급 지정 및 대응 프로토콜 시작
인시던트 브릿지 개설	워룸 채널 생성 (Slack/Zoom/Teams)
역할 배정	스크라이브, 도메인 전문가 지정
조사 지휘	가설 우선순위화, 병렬 조사 조율
커뮤니케이션	이해관계자 상태 업데이트 승인
의사결정	롤백 vs. 픽스포워드, 에스컬레이션
인시던트 종료	해결 선언, 포스트모텀 시작

IC의 핵심 원칙:

단일 목소리: 인시던트 중 외부 커뮤니케이션은 IC만 담당
조사 위임: IC는 지휘하고, 엔지니어가 조사한다
터널 비전 방지: 여러 가설을 동시에 탐색하도록 보장
의사결정 시간 제한: “10분 내로 롤백 또는 픽스포워드를 결정한다”

IC는 기술 전문가 역할이 아니다: 가장 뛰어난 IC는 명확성을 만들어내는 오케스트레이터이지, 깊은 디버깅에 빠져드는 가장 시니어한 엔지니어가 아니다.

Mean Time to Detect (MTTD)

정의: 인시던트가 시작된 시점부터 모니터링 시스템이나 사용자 신고로 감지될 때까지 걸리는 평균 시간.

계산식:

MTTD = 평균(감지 시각 - 인시던트 시작 시각)

MTTD 벤치마크:

MTTD	평가
1분 미만	우수 (선제적 알림)
1~5분	양호
5~15분	수용 가능
15~30분	개선 필요
30분 초과	미흡 (사용자 신고로 감지)

MTTD 단축 방법:

모든 중요 경로에 레이턴시·오류율 메트릭 적용
Baseline 대비 3σ(표준편차)를 알림 임계값으로 설정
합성 모니터링 사용 (30초 간격 헬스 체크)
이상 탐지 활성화 (ML 기반 알림)
에러 버짓 추적 — 소진 속도(burn rate)가 높을 때 알림

MTTD와 사용자 영향: MTTD 2분이지만 5% 사용자만 영향받은 인시던트는, MTTD 1분이지만 100% 사용자에 영향을 준 인시던트보다 피해가 작다. MTTD와 영향 범위를 함께 추적해야 한다.

Mean Time to Resolution (MTTR)

정의: 인시던트가 감지된 시점부터 서비스가 완전히 정상으로 복구될 때까지 걸리는 평균 시간.

MTTR 구성 요소:

MTTR = MTTD + 인지 시간 + 진단 시간 + 완화 시간 + 검증 시간

MTTR 벤치마크 (SEV-1 기준):

MTTR	평가
15분 미만	엘리트 팀
15~60분	고성과 팀
1~4시간	평균
4시간 초과	프로세스 개선 필요

MTTR을 늘리는 요인:

부실한 런북 (절차 대신 즉흥 대응)
불충분한 모니터링 (진단 시간 증가)
수동 롤백 프로세스 (배포에 20분 이상 소요)
에스컬레이션 경로 부재 (보조 온콜 연락 불가)
Alert Fatigue (감지 지연)

자주 헷갈리는 MTTR: 신뢰성 지표의 MTTR(Mean Time to Repair)은 수리 시간을 측정한다. 인시던트의 MTTR은 서비스 복구 시간을 측정한다. 이 둘은 다르다. 완화(롤백으로 서비스 복구)는 근본 원인 수정 전에 이루어질 수 있다.

Mitigation vs. Resolution

Mitigation (완화): 근본 원인을 반드시 고치지 않더라도 서비스를 복구하는 임시 조치.

Resolution (해결): 근본 원인을 완전히 수정해 서비스를 완전한 건강 상태로 복구하고, 재발 위험을 제거하는 것.

비교 예시:

상황	Mitigation	Resolution
DB 쿼리 느림	커넥션 풀 증가, 레플리카 재시작	슬로우 쿼리 최적화, 인덱스 추가
메모리 누수 OOM	영향받은 파드 재시작	코드의 메모리 누수 수정
잘못된 배포 5xx	이전 버전 롤백	버그 수정 후 재배포
DDoS 공격	속도 제한 활성화, IP 차단	CDN WAF 보호 구현

구분이 중요한 이유:

Mitigation은 인시던트를 종료시킨다 (서비스 복구)
Resolution은 재발을 방지한다 (포스트모텀 액션 아이템)
Mitigation 단계에서 인시던트를 닫고 Resolution을 미루면 동일 인시던트가 반복된다

On-Call

정의: 엔지니어가 교대 일정을 정해 프로덕션 알림을 받고 대응할 책임을 지는 대기 시스템. 일반적으로 24/7 운영.

온콜 역할:

역할	책임
Primary On-Call	첫 번째로 페이지를 받음; 초기 조사
Secondary On-Call	Primary 부재 시 백업; 에스컬레이션 대상
On-Call Manager	비즈니스 결정에 대한 에스컬레이션; 경영진 통보

건강한 온콜 운영 방법:

로테이션: 주간 또는 격주 교대로 팀 전체에 분산
인수인계: 진행 중인 이슈를 컨텍스트와 함께 명시적으로 인수인계
보상: 과중한 온콜 주에 대한 대체 휴가(TOIL)
런북: 부족 지식에 의존하지 않도록 런북 유지
알림 조율: 온콜이 주간 알림을 검토해 노이즈 감소

온콜 번아웃 경고 신호:

하룻밤에 여러 번 페이지 받음
업무 시간 외 인시던트 비율 > 20%
동일 문제가 수정 없이 반복됨
온콜 엔지니어가 교대 기간 단축을 요청함

업계 기준: Google SRE는 온콜 시간 중 페이징 인시던트가 50%를 초과하지 않을 것, 온콜이 전체 업무 시간의 25%를 초과하지 않을 것을 권장한다.

Root Cause Analysis (RCA)

정의: 인시던트의 즉각적인 트리거가 아닌, 근본적인 원인을 체계적으로 찾아내는 조사 과정.

RCA 프레임워크:

증상 → 직접 원인 → 기여 요인 → 근본 원인 → 시스템적 공백

계층별 예시:

증상:         35분간 API 503 오류
직접 원인:    DB 커넥션 풀 고갈
기여 요인:    배경 작업이 모든 커넥션을 소비함
근본 원인:    배경 작업에 커넥션 타임아웃 설정 누락
시스템적 공백: DB 리소스 관리를 위한 코드 리뷰 체크리스트 없음

RCA 방법론:

방법	적합한 상황
Five Whys	단순하고 선형적인 인과 관계
피쉬본 (이시카와)	복수의 기여 요인이 있는 경우
타임라인 분석	사건 순서를 재구성할 때
결함 트리 분석	복잡한 시스템 상호작용

RCA 결과물: 포스트모텀에 작성되는 보고서로, 6개월 후 처음 읽는 사람도 무슨 일이 왜 일어났는지 이해할 수 있을 만큼 명확해야 한다.

흔한 RCA 실수: “인적 오류”에서 멈추는 것. 인적 오류는 시스템적 공백의 증상이다. 부적절한 도구, 불명확한 절차, 불충분한 자동화가 인간이 오류를 저지를 수 있도록 만든 것이다. RCA는 “왜 사람이 이 오류를 저지를 수 있었는가?”를 물어야 한다.

Runbook

정의: 특정 유형의 인시던트나 알림에 대응하기 위한 단계별 가이드 문서. 해당 시스템에 깊은 전문성이 없는 온콜 엔지니어도 따를 수 있도록 작성한다.

좋은 런북 구조:

# 알림: DB 커넥션 풀 사용률 높음

## 개요
이 알림은 커넥션 풀 사용률이 5분 이상 80%를 초과할 때 발화합니다.
영향: 풀이 100%에 도달하면 신규 요청이 커넥션 타임아웃으로 실패합니다.

## 즉시 조치 (5분 이내)
1. 활성 커넥션 확인: `SELECT count(*) FROM pg_stat_activity;`
2. 장기 실행 쿼리 식별: `SELECT pid, query, duration FROM ...`
3. 단일 쿼리가 커넥션의 50% 이상 점유 시: 쿼리 강제 종료

## 조사
- 최근 2시간 내 배포 여부 확인
- 커넥션 누수 패턴을 위한 애플리케이션 로그 검토
- 예상치 않게 실행 중인 배경 작업 확인

## 에스컬레이션
- 커넥션 풀 고갈이 10분 이상 지속: #db-oncall로 에스컬레이션
- 데이터 손실 의심: On-Call Manager 페이지

## 해결 확인
- 커넥션 풀 사용률 60% 미만으로 복귀
- API 게이트웨이 로그에 503 오류 없음
- 확인: `SELECT count(*) FROM pg_stat_activity;`

런북 품질 체크리스트:

시스템을 모르는 온콜 엔지니어도 따를 수 있는가?
복사해서 바로 실행할 수 있는 명령어가 포함됐는가?
에스컬레이션 기준이 명시됐는가?
인시던트 없을 때 드라이런으로 테스트했는가?
관련 인시던트 발생 후 업데이트됐는가?

Part 3 — 성능 엔지니어링 (Performance Engineering)

SLA / SLO / SLI (신뢰성의 세 기둥)

SLI (Service Level Indicator) — 서비스 수준 지표: 서비스 성능을 측정하는 구체적인 메트릭.

예시:
- 요청 성공률: (성공 요청 수 / 전체 요청 수) × 100
- 레이턴시: P99 응답 시간 (밀리초)
- 가용성: (업타임 분 / 전체 분) × 100

SLO (Service Level Objective) — 서비스 수준 목표: “충분히 좋은” 서비스를 정의하는 SLI의 내부 목표값.

예시:
- 성공률 SLO: 30일 기준 ≥ 99.9%
- 레이턴시 SLO: 1,000 RPS까지 P99 < 500ms
- 가용성 SLO: 월간 99.95% 업타임

SLA (Service Level Agreement) — 서비스 수준 협약: 위반 시 페널티가 있는 고객과의 공식 계약으로 최소 서비스 수준을 명시.

예시:
- "월간 99.9% 가용성 보장, 미달 시 월 청구액의 10% 크레딧 제공"
- "P95 응답 시간 ≤ 1초, 미달 시 전담 지원 제공"

관계:

SLI(측정된 현실)는 SLO(내부 목표)를 충족해야 하며,
SLO는 항상 SLA(외부 약속)보다 엄격하게 설정한다.

SLA: 99.9% 가용성 → SLO: 99.95% → SLI: 99.97% (실제값)

에러 버짓 (Error Budget):

에러 버짓 = 1 - SLO

99.9% SLO → 0.1% 버짓 → 월 약 43분 다운타임 허용
99.95% SLO → 0.05% 버짓 → 월 약 22분 다운타임 허용

에러 버짓은 팀이 합리적인 결정을 내릴 수 있게 한다. 버짓이 충분하면 자유롭게 배포하고, 거의 소진됐으면 배포를 동결한다.

Latency Percentiles — 심층 분석

꼬리 레이턴시가 중요한 이유:

분산 시스템에서 사용자가 체감하는 레이턴시는 평균이 아니라 가장 느린 의존성에 의해 결정되는 경우가 많다.

팬아웃 증폭 효과: 단일 프런트엔드 요청이 20개의 마이크로서비스를 병렬 호출할 때, 각 서비스의 P99가 100ms라면:

적어도 하나가 100ms를 초과할 확률 = 1 - (0.99)^20 ≈ 18.2%

개별 서비스의 P99가 사용자 입장에서는 P82 수준의 문제가 됨

꼬리 레이턴시 원인:

원인	설명
Garbage Collection	JVM GC 일시 정지로 모든 스레드 블록
Lock Contention	스레드가 공유 락을 대기
CPU 스케줄링	OS가 컨텍스트 스위치 중 스레드를 선점
Memory Pressure	페이지 폴트로 디스크 I/O 발생
Noisy Neighbors	클라우드 VM 리소스 경쟁
Background Jobs	컴팩션, 배큠, 리인덱싱

완화 전략:

Hedged requests (헤지 요청): 두 서버에 중복 요청을 보내고 먼저 응답한 것을 사용 (Google, Bing에서 활용)
Timeout + retry: 공격적인 P99 타임아웃 설정, 타임아웃 시 1회 재시도
레이턴시 인식 로드 밸런싱: 느린 인스턴스로의 요청 경로 회피
JVM 튜닝: G1GC, ZGC로 GC 일시 정지 시간 단축

Throughput vs. Latency Trade-off

근본적인 긴장 관계:

부하 증가 → 포화 지점까지 처리량 증가
포화 이후 → 처리량은 정체되거나 감소, 레이턴시는 급등

Little’s Law (리틀의 법칙):

L = λ × W

L = 시스템 내 평균 요청 수
λ = 평균 도착률 (RPS)
W = 요청이 시스템에 머무르는 평균 시간 (레이턴시)

실용적 의미:

W = 0.1초 (100ms), L = 50 (동시 요청 50개) 일 때:
λ = 50 / 0.1 = 500 RPS

레이턴시가 두 배 증가해 0.2초가 되면:
λ = 50 / 0.2 = 250 RPS (동시성 변화 없이 처리량 절반)

곡선의 무릎(Knee of the Curve): 레이턴시가 급격히 상승하기 시작하는 운영 지점이 “무릎”이다. 무릎 이상에서 운영하는 것은 지속 불가능하다. 목표 운영 지점은 보통 무릎 처리량의 60~75%이다.

Connection Pool

정의: 커넥션 생성 오버헤드를 피하기 위해 미리 생성해 둔 DB 커넥션 캐시. 요청마다 새 커넥션을 만들지 않고 재사용한다.

커넥션 라이프사이클:

애플리케이션 요청
    → 풀에서 커넥션 획득 (없으면 대기)
    → 쿼리 실행
    → 풀에 커넥션 반환

커넥션 생성 비용이 큰 이유:

TCP 핸드셰이크: 15ms
TLS 협상: 1050ms
DB 인증: 520ms
합계: 커넥션당 16~75ms, 재사용 시 마이크로초 수준

풀 설정 파라미터:

파라미터	설명	일반적인 값
min_pool_size	항상 열어둘 커넥션 수	5~10
max_pool_size	최대 총 커넥션 수	20~100
connection_timeout	커넥션 획득 최대 대기 시간	5~30초
idle_timeout	유휴 커넥션 유지 시간	10~30분
max_lifetime	커넥션 최대 수명	30~60분

풀 크기 계산식:

최적 풀 크기 ≈ 코어 수 × 2 + 유효 스핀들 수

SSD를 사용하는 16코어 서버:
16 × 2 + 1 = 33개 (HikariCP 권장값)

커넥션 누수: 애플리케이션 코드가 커넥션을 획득하고 반환하지 못하는 경우(예: 예외 처리 누락). 풀이 결국 고갈된다. try-with-resources 또는 반환을 강제하는 커넥션 풀 프레임워크를 항상 사용해야 한다.

Circuit Breaker Pattern

정의: 장애 발생 중인 하위 서비스로의 요청을 일시 중단해 연쇄 장애를 방지하고, 해당 서비스가 회복할 시간을 주는 디자인 패턴.

서킷 브레이커 상태:

CLOSED (정상) → OPEN (장애) → HALF-OPEN (회복 테스트) → CLOSED

상태	동작
Closed	요청이 정상적으로 흐름; 실패 횟수 추적
Open	모든 요청 즉시 실패 (하위 서비스 호출 없음)
Half-Open	제한된 테스트 요청 발송; 성공 → Closed, 실패 → Open

서킷이 열리는 조건:

실패율이 임계값 초과 (예: 10초 내 50% 이상 실패)
느린 호출 비율 초과 (예: 50% 이상 호출이 2초 이상)

왜 중요한가: 서킷 브레이커 없이 DB가 느려지면 API 스레드가 대기로 쌓이고, 스레드 풀이 고갈되어 API 자체가 응답 불능 상태가 된다. 이것이 **연쇄 장애(Cascading Failure)**이다.

구현 예시 (Resilience4j):

CircuitBreaker cb = CircuitBreaker.ofDefaults("paymentService");
// 슬라이딩 윈도우 10회 중 50% 이상 실패 시 Open
// 60초 동안 Open 상태 유지 후 테스트
// Half-Open: 3회 호출로 테스트

Part 4 — 클라우드 인프라 (Cloud Infrastructure)

Auto-Scaling — 상세 분석

정의: 수요에 따라 컴퓨팅 리소스를 자동으로 조정하는 기능. 피크 시 성능을 보장하고, 한산할 때는 비용을 절감한다.

오토스케일링 유형:

Reactive Auto-scaling (반응형): 실시간 메트릭이 임계값을 초과할 때 트리거.

CPU > 70%가 5분 지속 → 인스턴스 2개 추가
CPU < 30%가 10분 지속 → 인스턴스 1개 제거

단점: 트리거 발생 후 새 인스턴스가 준비될 때까지 2~5분 지연.

Predictive Auto-scaling (예측형): 머신러닝으로 수요를 예측해 부하 도착 전에 사전 스케일링.

월요일 08:45 → 10개 인스턴스로 사전 확장 (09:00 트래픽 피크 대비)
금요일 17:30 → 사전 축소 (주말 트래픽 감소)

Scheduled Auto-scaling (예약형): 알려진 반복 패턴에 대한 시간 기반 규칙.

평일 08:00: 최소 15개 인스턴스로 확장
평일 22:00: 최소 3개 인스턴스로 축소

스케일링 지연 — 핵심 문제:

T=0 : 트래픽 급증
T+2분: CPU 임계값 트리거 감지
T+4분: 스케일링 결정
T+6분: 새 인스턴스 실행
T+8분: 새 인스턴스 헬시 상태 확인 후 트래픽 수신

위험 구간: 약 8분간 성능 저하 가능성

완화 방법: 비피크 시간대 인스턴스 예열(pre-warming), 최소 인스턴스 수 유지, 예측 가능한 피크에 예약형 스케일링 활용.

High Availability (HA)

정의: 계획되지 않은 다운타임을 최소화하거나 없애도록 설계된 시스템. 일반적으로 99.9% 이상의 가용성을 목표로 한다.

가용성 수치 계산:

SLA	연간 허용 다운타임	월간 허용 다운타임
99%	87.6시간	7.3시간
99.9% (Three Nines)	8.76시간	43.8분
99.95%	4.38시간	21.9분
99.99% (Four Nines)	52.6분	4.4분
99.999% (Five Nines)	5.26분	26.3초

HA 설계 원칙:

원칙	구현 방법
단일 장애점 제거	가용 영역(AZ)에 걸친 중복 인스턴스
자동 페일오버	로드 밸런서 헬스 체크, 자동 라우팅 전환
지리적 이중화	멀티 리전 배포
데이터 이중화	DB 복제, 백업/복구
우아한 성능 저하	부하 시 비핵심 기능을 피처 플래그로 비활성화

Active-Active vs. Active-Passive:

모델	동작 방식	RTO	RPO
Active-Active	모든 노드가 동시에 트래픽 처리	거의 0	거의 0
Active-Passive	주 서버가 트래픽 처리; 대기 서버는 준비 대기	1~10분	수초~수분

Observability (Metrics, Logs, Traces)

정의: 시스템이 외부 출력으로부터 이해될 수 있는 능력. 코드를 수정하지 않고 내부 상태를 파악할 수 있게 해주는 텔레메트리 데이터의 조합.

관측 가능성의 세 기둥:

Metrics (메트릭): 일정 간격으로 집계된 수치형 시계열 데이터.

system.cpu.utilization = 72.3% (14:30:00)
api.requests.count = 1,250/s (14:30:00)
db.query.duration.p99 = 145ms (14:30:00)

저장 효율: 높음 (타임스탬프당 숫자 하나)
보존 기간: 수개월~수년
활용: 대시보드, 알림, 용량 계획

Logs (로그): 이산 이벤트에 대한 구조화/비구조화 텍스트 기록.

{
  "timestamp": "2026-03-23T14:30:01.234Z",
  "level": "ERROR",
  "service": "payment-api",
  "requestId": "abc-123",
  "message": "DB 커넥션 타임아웃 5000ms 초과",
  "userId": "user-456"
}

저장 효율: 낮음 (장황함)
보존 기간: 수일~수주
활용: 특정 오류 디버깅, 감사 추적

Traces (트레이스): 여러 서비스에 걸친 요청의 엔드투엔드 흐름.

사용자 요청 [총 450ms]
├── API Gateway [15ms]
├── Auth Service [25ms]
├── Payment Service [380ms]
│   ├── DB 쿼리: get_customer [45ms]
│   ├── DB 쿼리: get_payment_method [120ms]  ← 느림
│   ├── 외부: stripe_charge [180ms]
│   └── DB 쿼리: update_order [35ms]
└── Notification Service [30ms]

저장 효율: 중간 (샘플링)
보존 기간: 수일
활용: 성능 디버깅, 마이크로서비스 의존성 분석

상관 분석의 힘: 세 가지를 함께 연관짓는 것이 핵심이다:

메트릭에서 P99 레이턴시 알림 발화
트레이스로 결제 서비스 DB 호출이 느린 것 확인
로그에서 “커넥션 풀 고갈” 오류 발견

Content Delivery Network (CDN)

정의: 최종 사용자와 물리적으로 가까운 위치에서 콘텐츠를 캐싱하고 서비스하는 지리적으로 분산된 엣지 서버 네트워크. 레이턴시와 원본 서버 부하를 줄인다.

CDN 동작 원리:

CDN 없음:
사용자 (서울) → 원본 서버 (뉴욕) → 왕복 약 150ms

CDN 있음:
사용자 (서울) → CDN 엣지 (서울) → 왕복 약 5ms
               CDN 엣지가 원본에서 콘텐츠를 캐싱

CDN 캐시 유형:

콘텐츠 유형	TTL	캐시 전략
정적 자산 (JS/CSS/이미지)	수일~수개월	긴 TTL, 버전 URL
API 응답 (준정적)	수분~수시간	짧은 TTL 또는 stale-while-revalidate
동적 콘텐츠 (개인화)	캐시 없음	엣지 인증 포함 패스스루
스트리밍 영상	세그먼트 기반	매니페스트 갱신으로 엣지 캐싱

CDN과 부하 테스트: 부하 테스트 시 CDN이 원본 서버 문제를 가릴 수 있다. 측정 목적에 따라 CDN을 우회(원본 IP 직접 접속)하거나 CDN을 통해 테스트하도록 구성한다.

CDN 모니터링 핵심 지표:

캐시 적중률: 캐시에서 서비스된 요청 비율 (정적 자산 목표: > 90%)
Origin Pull Rate: 캐시 미스로 원본에 도달하는 요청
엣지 레이턴시: CDN 엣지 서버에서의 처리 시간
오프로드 비율: CDN이 흡수하는 전체 트래픽 비율

Distributed Tracing

정의: 단일 요청이 여러 마이크로서비스를 통과하면서 전파될 때 각 단계의 타이밍 데이터를 수집해 전체 성능 그림을 만드는 방법.

트레이스 구조:

Trace ID: abc-123 (요청당 고유값)
│
├── Span: api-gateway (15ms)
│   └── 태그: method=POST, path=/checkout, status=200
│
├── Span: auth-service (25ms)
│   └── 태그: user_id=456, token_valid=true
│
└── Span: payment-service (380ms)
    ├── Span: db.query.SELECT (45ms)
    ├── Span: db.query.SELECT (120ms) ← 태그: slow_query=true
    ├── Span: http.stripe.charge (180ms) ← 외부 호출
    └── Span: db.query.UPDATE (35ms)

샘플링 전략:

전략	동작 방식	사용 사례
Head-based	요청 시작 시 결정	단순하고 예측 가능한 오버헤드
Tail-based	완료 후 결정	느리거나 오류 있는 트레이스 포착
Adaptive	트래픽 볼륨에 따라 샘플링 비율 조정	고트래픽 시스템

주요 트레이싱 표준:

OpenTelemetry (OTEL) — 벤더 중립, 권장
Jaeger, Zipkin — 오픈소스 백엔드
Datadog APM, AWS X-Ray — 매니지드 서비스

CAP Theorem (CAP 정리)

정의: 분산 시스템에서 네트워크 분리(P) 발생 시, 일관성(C)과 가용성(A) 중 하나만 보장할 수 있다는 정리.

세 가지 속성:

속성	의미
Consistency (일관성)	모든 읽기는 최신 쓰기 또는 오류를 반환함
Availability (가용성)	모든 요청은 오류 없는 응답을 받음
Partition Tolerance (분리 내성)	노드 간 네트워크 분리가 발생해도 시스템이 동작함

CAP 트레이드오프 선택:

선택	동작	예시
CP (가용성 포기)	분리 발생 시 오래된 데이터 대신 오류 반환	HBase, Zookeeper, etcd
AP (일관성 포기)	분리 발생 시 오류 대신 오래된 데이터 반환	Cassandra, DynamoDB(기본), CouchDB

P가 선택지가 아닌 이유: 네트워크 분리는 반드시 발생한다. 모든 분산 시스템은 이를 허용해야 한다. 따라서 실제 선택은 분리 시 C vs. A이다.

부하 테스트 실무 시사점:

CP 시스템: 네트워크 분리 시뮬레이션 시 오류 예상
AP 시스템: 오래된 읽기는 예상되지만 높은 가용성 유지
PACELC (CAP 확장): 분리가 없을 때도 레이턴시 vs. 일관성 트레이드오프를 고려

Recovery Time Objective (RTO) vs. Recovery Point Objective (RPO)

RTO (복구 시간 목표): 장애 발생 후 허용 가능한 최대 다운타임 기간.

T=0에 재해 발생
서비스는 T=RTO까지 복구되어야 함

RTO = 4시간 → T+4:00까지 서비스 복구

RPO (복구 지점 목표): 허용 가능한 최대 데이터 손실량. 시간으로 측정.

T=0에 재해 발생
마지막 백업은 T-2시간에 수행됨

RPO = 2시간 → 최대 2시간 분량의 데이터 손실 허용

RTO vs. RPO 등급 기준:

등급	RTO	RPO	비용
Tier 1 (미션 크리티컬)	15분 미만	5분 미만	매우 높음
Tier 2 (비즈니스 크리티컬)	4시간 미만	1시간 미만	높음
Tier 3 (중요)	24시간 미만	4시간 미만	중간
Tier 4 (비핵심)	72시간 미만	24시간 미만	낮음

기술별 RTO/RPO:

기술	RTO	RPO
Active-Active 멀티 리전	거의 0	거의 0
동기 복제 핫 스탠바이	1분 미만	거의 0
비동기 복제 웜 스탠바이	5~15분	수분
콜드 스탠바이 (백업 복구)	수시간	수시간

빠른 참조 카드

부하 테스트 체크리스트

테스트 전:
□ 성공 기준 정의 (P95 < Xms, 오류율 < Y%)
□ 이전 테스트 또는 프로덕션에서 Baseline 확보
□ 테스트 환경이 프로덕션과 동일한지 확인
□ 핵심 요청에 Assertion 정의
□ 모니터링 및 대시보드 설정

테스트 중:
□ 오류율 지속 모니터링
□ 리소스 사용률 모니터링 (CPU, 메모리, DB)
□ 커넥션 풀 고갈 여부 확인
□ 레이턴시 백분위수 관찰 (P50, P95, P99)

테스트 후:
□ 모든 메트릭을 Baseline과 비교
□ 스크린샷과 함께 결과 문서화
□ 최적화를 위한 병목 식별
□ 필요 시 성능 예산 업데이트

인시던트 대응 빠른 참조

처음 5분:
□ 심각도 평가 (SEV 1~4)
□ 인시던트 브릿지 / 워룸 개설
□ 인시던트 커맨더 지정
□ 스크라이브 지정 (이 시점부터 기록 시작)
□ 사용자 영향 범위 파악 시작

처음 30분:
□ 최근 4시간 내 배포 확인
□ 오류 로그에서 이상 패턴 검토
□ 인프라 대시보드 확인
□ 첫 번째 외부 상태 업데이트 게시

30분마다:
□ 이해관계자 업데이트
□ 심각도 재평가
□ 인시던트 채널에 결정 사항 기록

해결 시:
□ 모든 메트릭이 Baseline으로 복귀 확인
□ 사용자 신고 해결 확인
□ 인시던트 요약 작성
□ 포스트모텀 일정 잡기 (48~72시간 이내)

핵심 공식

Apdex = (만족 요청 수 + 허용 요청 수 × 0.5) / 전체 요청 수
오류율 = (실패 요청 수 / 전체 요청 수) × 100%
처리량(RPS) ≈ 동시 사용자 수 / 응답 시간(초)
가용성 = (업타임 / 전체 시간) × 100%
에러 버짓 = 100% - SLO%
MTTR = 총 해결 시간의 합 / 인시던트 수
리틀의 법칙: L = λ × W

이 가이드는 TestForge 문서의 일부입니다. 관련 문서: 부하 테스트 용어집 · 장애 관리 용어집 · 클라우드 & 성능 참조 · 전체 용어 색인

이 가이드를 내 서비스에 직접 적용해 보세요.

TestForge 무료 스캔 시작 →