핵심 인사이트 (3줄 요약)
- 본질: 리틀의 법칙(Little's Law)
L = λW는 시스템 내 평균 요청 수(L), 처리율(λ, TPS), 평균 응답 시간(W)의 관계를 나타내며, 세 지표 중 하나를 알면 나머지를 계산할 수 있다.
- 가치: 스레드 풀(Thread Pool)과 커넥션 풀(Connection Pool) 크기를 수학적으로 산정할 수 있어 "감(感) 기반" 설정에서 "근거 기반" 설정으로 전환한다.
- 판단 포인트: 감리 현장에서 스레드 풀 크기 설정 근거 문서가 없거나, 리틀의 법칙과 크게 괴리된 값이 설정된 경우 재검토를 요구한다.
Ⅰ. 개요 및 필요성
리틀의 법칙(Little's Law)은 1961년 존 리틀(John D.C. Little)이 증명한 큐잉 이론(Queuing Theory)의 기본 정리다. 원래는 대기열 분석에서 유도되었지만, IT 성능 공학에서 스레드 풀·DB 커넥션 풀·메시지 큐 크기 산정에 광범위하게 활용된다.
공공정보화 감리에서 스레드 풀과 커넥션 풀 설정값은 핵심 성능 파라미터다. 잘못된 설정은 서버 자원 낭비(과다 설정) 또는 요청 거부·타임아웃(과소 설정)을 유발한다.
L = λ × W
L (Lambda) : 시스템 내 평균 요청 수 (동시 처리 중인 요청)
λ (Lambda) : 처리율 (TPS, Transactions Per Second)
W (Wait) : 평균 응답 시간 (초, second)
| 변수 | 실무 매핑 | 예시 값 |
|---|
| L | 필요 스레드 풀 크기 (활성 스레드 수) | 50개 |
| λ | TPS (초당 처리 트랜잭션 수) | 100 tps |
| W | 평균 응답 시간 | 0.5초 |
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Problem │──▶│ Core Idea │──▶│ Expected Gain │
└──────────────┘ └──────────────┘ └──────────────┘
- 📢 섹션 요약 비유: 리틀의 법칙은 "마트 계산대(시스템)에 항상 몇 명이 줄 서 있는지(L)는 시간당 처리 고객 수(λ)와 1명당 걸리는 시간(W)의 곱"이라는 상식적 수학이다.
Ⅱ. 아키텍처 및 핵심 원리
┌─────────────────────────────────────────────────────────────┐
│ 실무 계산 예시 │
│ │
│ 목표 성능: │
│ - 목표 TPS (λ): 200 tps │
│ - 평균 응답 시간 (W): 0.3초 │
│ │
│ 필요 스레드 수 (L): │
│ L = λ × W = 200 × 0.3 = 60개 │
│ │
│ 안전 마진 (20%) 적용: │
│ 스레드 풀 설정 = 60 × 1.2 = 72개 → 75개 설정 │
│ │
│ 커넥션 풀 산정: │
│ - DB 쿼리 TPS: 150 tps (쿼리 비중 75%) │
│ - 평균 DB 응답 시간: 0.1초 │
│ L_db = 150 × 0.1 = 15개 → 커넥션 풀 20개 설정 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 스레드 풀 설정 시나리오 비교 │
│ │
│ [과소 설정: 스레드 풀 = 10개] │
│ │
│ 요청 60개 ──► 활성 스레드 10개 ──► 대기 큐 50개 │
│ │ │
│ ▼ │
│ 응답 시간 급증, 타임아웃(Timeout) 발생, 500 오류 │
│ │
│ [과다 설정: 스레드 풀 = 500개] │
│ │
│ 요청 60개 ──► 활성 스레드 60개 ──► 유휴 스레드 440개 │
│ │ │
│ ▼ │
│ 메모리 낭비 (스레드 1개 = 약 1MB 스택) │
│ 불필요한 컨텍스트 스위칭(Context Switching) 오버헤드 │
│ │
│ [적정 설정: 스레드 풀 = 75개] │
│ │
│ 요청 60개 ──► 활성 스레드 60개 ──► 여유 스레드 15개 │
│ │ │
│ ▼ │
│ 안정적 TPS 유지, 피크 부하 흡수 가능 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 커넥션 풀 최적화 원리 │
│ │
│ WAS 스레드 ──► 커넥션 풀에서 커넥션 획득 │
│ │
│ 커넥션 풀 부족 시: │
│ 스레드가 커넥션 대기 ──► 응답 시간 증가 ──► 스레드 풀 포화 │
│ │
│ 권장 공식: │
│ DB 커넥션 풀 = (WAS 스레드 풀) × (DB 쿼리 비중) │
│ × (DB 응답 시간 / WAS 응답 시간) │
│ │
│ HikariCP(히카리CP) 권장: │
│ connections = ((core_count × 2) + effective_spindle_count) │
│ │
│ 예: CPU 4코어, SSD 1개 = (4×2)+1 = 9개 (약 10개 설정) │
└─────────────────────────────────────────────────────────────┘
| 항목 | 설명 | 포인트 |
|---|
| 핵심 역할 | 입력·상태·출력을 분리하는 책임 경계 | 구현보다 경계를 먼저 본다. |
| 제어 지점 | 조건, 이벤트, 정책이 만나는 곳 | 병목과 결합이 생기는 곳이다. |
| 검증 포인트 | 테스트·로그·모니터링으로 확인할 지점 | 운영 가능성이 설계 품질을 결정한다. |
- 📢 섹션 요약 비유: 커넥션 풀은 "공유 자동차(카쉐어링)"와 같다. 차가 너무 적으면 대기자가 생기고, 너무 많으면 주차 공간(메모리)이 낭비된다. 리틀의 법칙은 적정 차량 수를 수학적으로 알려준다.
Ⅲ. 비교 및 연결
| 방법 | 정확도 | 실무 적용성 | 권장 상황 |
|---|
| 리틀의 법칙 (Little's Law) | 높음 | 높음 | 목표 TPS·응답 시간 명확 시 |
| 부하 테스트 기반 경험치 | 중간 | 높음 | 실제 부하 데이터 존재 시 |
| HikariCP 공식 | 중간 | 중간 | CPU 바운드 DB 서버 |
| 임의 설정 (200, 100 등) | 낮음 | 낮음 | 근거 없는 관행 설정 ❌ |
| 적용 분야 | L (큐 내 항목 수) | λ (처리율) | W (처리 시간) |
|---|
| WAS 스레드 풀 | 활성 스레드 수 | TPS | 평균 응답 시간 |
| DB 커넥션 풀 | 활성 커넥션 수 | DB 쿼리 TPS | 평균 쿼리 시간 |
| 메시지 큐 | 큐 적재 메시지 수 | 소비 TPS | 평균 처리 시간 |
| 네트워크 버퍼 | 버퍼 내 패킷 수 | 패킷/초 | 전송 지연 시간 |
- 📢 섹션 요약 비유: 리틀의 법칙은 "슈퍼마켓 계산대 수 결정"에서 "공장 생산라인 설계"까지 어디서나 통하는 범용 공식이다. 단지 IT에서는 스레드와 커넥션에 적용할 뿐이다.
Ⅳ. 실무 적용 및 기술사 판단
| 단계 | 확인 항목 | 기대 결과 |
|---|
| 1단계 | 성능 목표 TPS 및 응답 시간 확인 | 요건 정의서에 명시 |
| 2단계 | 현재 스레드 풀 설정값 확인 | server.xml 또는 application.yml |
| 3단계 | 리틀의 법칙으로 이론적 적정값 계산 | L = λ × W |
| 4단계 | 설정값 vs 이론값 비교 | 20% 이내 오차 허용 |
| 5단계 | 부하 테스트 결과와 일치 여부 확인 | APM 스레드 활성 수 모니터링 |
# Tomcat server.xml
<Executor name="tomcatThreadPool"
maxThreads="75" ← 리틀의 법칙 기반 설정
minSpareThreads="10"/>
# Spring Boot application.yml
server:
tomcat:
threads:
max: 75
min-spare: 10
# HikariCP (DB 커넥션 풀)
spring:
datasource:
hikari:
maximum-pool-size: 20 ← L_db = λ_db × W_db
minimum-idle: 5
connection-timeout: 30000
판단 체크리스트
- 위험 시나리오와 점검 범위가 문서로 합의되었는가?
- 지표·증적·로그가 재현 가능하게 수집되는가?
- 예외 상황과 오탐·미탐 처리 절차가 있는가?
- 재시험 또는 후속 조치 기준이 수치로 정의되었는가?
- 📢 섹션 요약 비유:
maxThreads=200으로 설정된 이유를 개발팀이 "기본값이라서요"라고 답한다면 감리 지적 대상이다. 설정 값에는 반드시 산정 근거가 있어야 한다.
Ⅴ. 기대효과 및 결론
리틀의 법칙을 기반으로 스레드 풀과 커넥션 풀을 산정하면 자원 낭비 없이 목표 TPS를 달성하는 최적 설정이 가능하다. 실무에서 스레드 풀 과소 설정으로 인한 타임아웃, 과다 설정으로 인한 GC(Garbage Collection) 압박은 모두 리틀의 법칙 산정 미적용에서 비롯된다. 감리인은 설정값의 산정 근거 문서를 반드시 요구하고, 이론값과의 비교 검증을 수행해야 한다.
확장 방향은 ① Policy as Code, ② Continuous Audit, ③ 인공지능(AI, Artificial Intelligence) 기반 이상 탐지와 결합하는 것이다.
- 📢 섹션 요약 비유: 리틀의 법칙은 "교통 신호등 초록불 시간을 도로 차량 수와 통과 시간으로 최적화하는 공식"이다. 초록불이 너무 짧으면 정체, 너무 길면 다른 방향이 막힌다.
📌 관련 개념 맵
| 관계 | 개념 | 설명 |
|---|
| 상위 개념 | 큐잉 이론 (Queuing Theory) | 리틀의 법칙의 수학적 기반 |
| 상위 개념 | 성능 공학 (Performance Engineering) | 성능 설계·분석 학문 |
| 하위 개념 | 스레드 풀 (Thread Pool) | L = λW 적용 대상 |
| 하위 개념 | 커넥션 풀 (Connection Pool) | DB 접속 자원 관리 |
| 연관 개념 | TPS (Transactions Per Second) | λ 값의 실무 측정 |
| 연관 개념 | P95 응답 시간 | W 값의 실무 측정 기준 |
| 연관 개념 | APM (Application Performance Management) | L, λ, W 실시간 측정 도구 |
📈 관련 키워드 및 발전 흐름도
queue theory → 리틀의 법칙 성능 진단 → capacity planning
👶 어린이를 위한 3줄 비유 설명
- 리틀의 법칙은 "놀이공원에서 항상 몇 명이 줄 서 있는지는 1시간에 몇 명 태우는지와 1번 타는 데 걸리는 시간을 곱하면 나온다"는 거야.
- 스레드 풀 크기는 "롤러코스터 직원이 몇 명 필요한가"와 같아서, 너무 적으면 손님이 기다리다 포기하고, 너무 많으면 직원만 놀아.
- 이 공식을 모르고 설정하는 건 "감으로 직원을 뽑는 것"이고, 리틀의 법칙을 쓰면 "정확한 계산으로 딱 맞는 직원 수를 구하는 것"이야.