282. 성능 (Performance) - 자원 요구 관리, 자원 관리, 스케줄링 전술

핵심 인사이트 (3줄 요약)

본질: 성능(Performance)은 시스템에 도착한 이벤트(요청)를 정해진 시간 제약(Deadline) 내에 얼마나 빠르고(Latency) 많이(Throughput) 처리할 수 있는가를 나타내는 아키텍처 품질 속성이다.

가치: 성능 저하는 곧 사용자 이탈과 직결되며, 클라우드 환경에서는 비효율적인 성능이 곧 막대한 인프라 비용 청구서로 돌아오기 때문에 비즈니스의 수익성을 결정짓는 가장 직접적인 기술 지표다.

융합: 성능을 끌어올리기 위한 아키텍처 전술은 결국 "할 일을 줄이거나(자원 요구 관리), 일할 사람과 도구를 늘리거나(자원 관리), 일의 순서를 현명하게 정하는 것(스케줄링)" 3가지 메커니즘으로 귀결되며, 이는 OS, 네트워크, 데이터베이스 튜닝의 모든 원리와 정확히 일치한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 성능은 시스템이 자극(요청)에 대해 응답하는 시간과 관련된 품질 속성이다. 주로 **응답 시간(Response Time/Latency)**과 **처리량(Throughput)**이라는 두 가지 상충하는(Trade-off) 지표로 측정된다.
필요성: 티켓팅 사이트가 오픈했다. 10만 명의 사용자가 동시에 접속(자극)했다. 만약 서버가 1초에 10명만 처리할 수 있다면, 대기열의 뒷사람은 티켓을 사기 위해 몇 시간을 기다려야 한다. 심지어 대기 큐(Queue)가 터지면 서버가 다운된다. 고객은 느린 시스템을 '고장 난 시스템'과 동일하게 취급한다. 이를 막기 위해 성능을 아키텍처 레벨에서 통제해야 한다.
💡 비유: 인기 있는 놀이공원의 롤러코스터와 같습니다. 대기줄에서 탑승까지 걸리는 대기 시간(응답 시간)을 줄이면서도, 하루에 최대한 많은 사람(처리량)을 태우기 위해 레일을 여러 개 깔거나, 한 번에 타는 인원을 늘리거나, VIP 패스를 도입해 순서를 조정하는 모든 고민이 성능 설계입니다.
등장 배경 및 발전 과정:
1. 수직적 확장 (Scale-Up) 의존: 과거에는 성능이 느리면 단순히 더 빠르고 비싼 CPU와 RAM을 사서 끼우는 하드웨어 업그레이드에 의존했다.
2. 수평적 확장 (Scale-Out) 대두: 인터넷의 발달로 단일 서버로는 감당할 수 없는 트래픽이 쏟아지자, 저렴한 서버 여러 대를 병렬로 묶고 로드밸런서(L4)를 두는 분산 아키텍처가 표준이 되었다.
3. 비동기/이벤트 주도 아키텍처: 현대에는 서버 대수를 늘리는 것을 넘어, 스레드가 멈춰서 기다리는 시간(Blocking) 자체를 없애기 위해 Node.js나 WebFlux 같은 Non-blocking I/O 성능 최적화가 주류를 이루고 있다.
📢 섹션 요약 비유: 옛날엔 짐을 빨리 옮기려고 소달구지 대신 비싼 페라리를 샀다면(Scale-Up), 지금은 저렴한 오토바이 수십 대를 고용해서 짐을 나눠 배달시키는(Scale-Out) 전략으로 진화했습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

성능 시나리오 (6요소)

성능 요구사항은 다음 6가지 요소로 구체화된다.

자극원: 외부 사용자, 타이머(배치 잡), 다른 내부 시스템
자극: 시스템에 도착하는 이벤트 (예: 초당 1만 건의 결제 요청 도착)
환경: 평상시, 트래픽 폭주(Peak Time), 일부 서버 장애 시
대상: 웹 서버, 데이터베이스, 네트워크 대역폭
응답: 이벤트를 처리하고 상태를 변경한 뒤 결과를 반환함
응답 척도: 응답 시간(Latency, 예: 99% 1초 이내 완료), 처리량(Throughput, 예: 초당 5,000 TPS 처리), 자원 활용률(CPU 70% 미만)

성능 최적화 3대 전술 (Performance Tactics)

성능 문제는 결국 **"수요(요청)와 공급(자원)의 불균형"**에서 온다. 따라서 전술도 1) 수요를 줄이거나, 2) 공급을 늘리거나, 3) 순서를 정리하는 3가지로 나뉜다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 성능 최적화 3대 전술 (Architecture Tactics)   │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │     [1. 자원 요구 관리]            [2. 자원 관리]            │
  │     (할 일을 줄이자!)              (도구와 일꾼을 늘리자!)      │
  │                                                             │
  │   - 계산 효율성 증대 (알고리즘)    - 동시성 (Concurrency) 증대 │
  │   - 이벤트 발생률 감소 (Sampling) - 데이터 다중 복제 (Replication│
  │   - 이벤트 응답 제한 (Sampling)   - 서버 스케일 아웃 (Scale-Out)│
  │   - 처리 단계 축소                 - 처리 크기 조절 (배치/풀링) │
  │                                                             │
  │                 ＼                 ／                       │
  │                   ▼               ▼                       │
  │                [3. 스케줄링 전술] (순서를 정하자!)               │
  │                                                             │
  │          - FIFO (먼저 온 놈 먼저)                            │
  │          - 우선순위 스케줄링 (VIP 먼저)                       │
  │          - 라운드 로빈 (공평하게 번갈아가며)                   │
  └─────────────────────────────────────────────────────────────┘

1. 자원 요구 관리 (Manage Resource Demand) 전술

시스템에 들어오는 작업량 자체를 줄이거나, 작업의 무게를 가볍게 만드는 전술이다.

계산 효율성 증대: O(N^2) 알고리즘을 O(N log N)으로 바꾸거나, 무거운 Join 쿼리에 인덱스(Index)를 태워 DB 스캔량을 극적으로 줄이는 코딩/튜닝 기법.
오버헤드 감소: 100번의 네트워크 호출(채팅)을 1번의 웹소켓 연결로 줄여 TCP Handshake 오버헤드를 날려버리는 기법.
이벤트 발생률 관리 (Sampling/Throttling): 너무 많은 센서 데이터가 초당 수만 개씩 들어올 때, 서버가 다 처리하지 않고 1초에 1번씩만 샘플링해서 받아(Throttle) 서버 부하를 줄이는 엣지 컴퓨팅 전술.

2. 자원 관리 (Manage Resources) 전술

처리해야 할 일이 고정되어 있다면, 일을 처리할 일꾼(서버, 스레드)이나 도구를 늘리는 전술이다.

동시성 (Concurrency) 도입: 싱글 스레드로 순차 처리하던 로직을 멀티스레드(Thread Pool)나 비동기 큐에 분산시켜 동시에 병렬 처리하게 만든다.
데이터 다중 복제 (Data Replication/Caching): 마스터 DB 한 대가 모든 조회를 감당하지 못할 때, Read-Replica(읽기 전용 DB)를 여러 대 두거나 Redis 같은 인메모리 캐시(Cache)를 앞단에 깔아 DB를 대신해 빛의 속도로 응답하게 한다.
서버 증설 (Scale-Out): L4/L7 로드밸런서를 앞단에 두고, 뒤에 웹 서버를 1대에서 10대로 수평 확장하는 가장 확실하고 돈이 드는 전술.

3. 스케줄링 (Scheduling) 전술

자원은 한정되어 있고 일은 쏟아질 때, 어떤 일부터 처리할지 똑똑하게 순서를 정하는 전술이다.

우선순위 스케줄링 (Priority): 일반 사용자의 다운로드 요청은 큐(Queue)에서 잠시 대기시키고, 관리자의 결제 승인 요청을 먼저 CPU에 할당해 처리하는 방식.
정적/동적 스케줄링: 라운드 로빈(Round Robin)으로 공평하게 주거나, 가장 작업량이 적은 서버(Least Connection)에게 일을 몰아주는 로드밸런싱 알고리즘.
📢 섹션 요약 비유: 피자집 장사가 너무 잘될 때, 피자 굽는 레시피를 단축하고(자원 요구 관리), 피자 화덕과 알바생을 늘리며(자원 관리), 배달앱 VIP 손님 주문을 먼저 빼주는(스케줄링) 사장님의 3가지 묘수와 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 성능의 딜레마: 응답 시간(Latency) vs 처리량(Throughput)

성능 지표 중 가장 헷갈리기 쉬운 두 가지다. 아키텍처 설계 시 이 둘은 종종 서로를 갉아먹는 트레이드오프 관계를 가진다.

비교 항목	응답 시간 (Latency)	처리량 (Throughput)
정의	1개의 요청이 처리되는 데 걸리는 총 소요 시간	1초(단위 시간) 동안 처리해 내는 총 작업 건수
단위	ms (밀리초), 초	TPS (Transactions Per Second), QPS
최적화 전술	오버헤드 제거, 알고리즘 개선, 캐싱 도입	멀티스레딩, 비동기 큐잉, 스케일 아웃
트레이드오프	수만 개의 요청을 모았다가 한 번에 DB에 밀어 넣으면(Batch), 처리량은 극대화되지만 첫 번째 요청자의 응답 시간은 극단적으로 느려진다.	반대로 1건마다 바로바로 DB 커밋을 때리면 응답 시간은 빠르지만 IO 병목으로 서버 전체의 처리량은 바닥을 친다.

과목 융합 관점

운영체제 (OS): 스케줄링 전술은 OS의 CPU 스케줄러(SJF, Round Robin, Multilevel Feedback Queue) 원리와 100% 동일하게 시스템 아키텍처 로드밸런싱에 적용된다.
데이터베이스 (DB): B-Tree 인덱스 생성, 정규화/반정규화 설계는 모두 DB 디스크 I/O를 줄이기 위한 '자원 요구 관리(계산 효율성 증대)'의 정수다.
네트워크 (NW): HTTP/1.1에서 발생하던 HOL(Head-of-Line) Blocking 병목(앞 패킷이 지연되면 뒤 패킷이 다 막힘)을 해결하기 위해, HTTP/2에서 멀티플렉싱(Multiplexing - 자원 관리 전술)을 도입해 성능을 극적으로 끌어올렸다.
📢 섹션 요약 비유: 톨게이트를 지날 때, 차 한 대가 표를 끊고 지나가는 '속도'가 응답 시간이고, 1시간 동안 톨게이트를 통과한 '총 차량 대수'가 처리량입니다. 하이패스를 달면 응답 시간이 줄고, 톨게이트 차로를 10개로 늘리면 처리량이 늘어납니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 조회 API의 극심한 지연과 캐시(Cache) 전략: 메인 화면에서 '실시간 랭킹'을 보여주기 위해, 1초에 5천 명의 유저가 접속할 때마다 DB에서 GROUP BY와 ORDER BY가 섞인 무거운 집계 쿼리가 5천 번씩 실행된다. DB CPU가 100%를 치고 웹 서버가 모두 뻗었다.
- 아키텍트의 해결책: **자원 관리 전술 중 '데이터 다중 복제(캐싱)'**를 도입해야 한다. 집계 쿼리는 아무리 알고리즘을 최적화해도 DB에 부담이 크다. 랭킹을 1분마다 한 번씩만 계산하여 Redis 같은 인메모리 캐시에 담아두고(Cache-Aside 패턴), 5천 번의 요청은 DB가 아니라 Redis에서 즉시 가져가게 만든다. 응답 시간은 수십 배 빨라지고 DB의 자원 요구량은 0에 수렴한다.
시나리오 — 동기(Synchronous) 처리로 인한 스레드 풀 고갈: 사용자가 회원가입을 하면 환영 이메일을 보내야 한다. 회원가입 API 로직 안에 이메일 발송 SMTP 통신 코드가 동기식으로 짜여 있다. 이메일 서버가 3초간 지연되자, 회원가입을 하려던 사용자 200명의 스레드가 모두 3초간 멈춰 섰고(Blocked), 톰캣(Tomcat) 스레드 풀이 고갈되어 로그인조차 불가능해졌다.
- 아키텍트의 해결책: 자원 요구 관리(처리 단계 축소) 및 동시성 전술을 적용한다. 회원가입 로직에서 이메일 발송을 기다릴 필요가 없다. 가입 완료 즉시 메인 스레드는 HTTP 200을 반환하여 응답 시간을 단축시키고, 이메일 발송이라는 작업은 Kafka나 RabbitMQ 같은 **메시지 큐(Message Queue)**에 던져 비동기 백그라운드 워커가 천천히 처리하게 분리(Decoupling)해야 한다.

도입 체크리스트

기술적: 수평 확장(Scale-Out) 전술을 적용하려면, 웹 서버가 사용자 세션(Session) 정보를 내부에 들고 있어서는 안 된다. 세션을 외부 저장소(Redis 등)로 분리하여 서버를 무상태(Stateless)로 만들었는가?
운영적: 시스템의 어느 부분이 병목(Bottleneck)인지 정확히 아는가? 병목이 DB 디스크 I/O에 있는데, 웹 서버의 CPU 알고리즘만 튜닝하고 있다면 헛고생이다. APM(Scouter, Pinpoint 등) 툴을 통한 프로파일링이 선행되어야 한다.

안티패턴

맹목적인 Scale-Out (돈으로 해결하기): 코드가 O(N^3)의 쓰레기 같은 시간 복잡도를 가지고 있거나, N+1 쿼리 문제가 터지고 있는데, 개발자가 이를 고치지 않고 AWS 서버 대수만 10배로 오토스케일링(Auto Scaling) 해버리는 행위. 이는 근본적인 '자원 요구 관리'를 무시한 채 클라우드 인프라 비용만 수천만 원씩 허공에 태우는 최악의 설계다.
📢 섹션 요약 비유: 밑빠진 독(나쁜 코드)에 물을 부으려면 펌프를 10대로 늘릴(Scale-Out) 게 아니라, 두꺼비집을 막아서 독의 구멍을 먼저 때워야(알고리즘 최적화) 합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	단일 서버 & 동기식 아키텍처 (AS-IS)	성능 전술 적용 (캐시, 비동기, 스케일아웃)	개선 효과
정량	피크 타임 시 API 평균 응답 시간 3,000ms	캐시 도입 및 알고리즘 개선으로 150ms 달성	사용자 응답 속도 95% 획기적 단축
정량	초당 동시 처리 한계치 500 TPS	스케일아웃 및 메시지 큐 비동기 처리 적용	시스템 처리량(Throughput) 10배(5,000 TPS) 확장
정성	트래픽 스파이크 시 매번 서버 장애 다운 발생	큐잉(Queueing)을 통한 부하 흡수 (Shock Absorber)	사용자 이탈(Churn Rate) 방지 및 매출 직결

미래 전망

서버리스(Serverless)와 오토스케일링의 극대화: 개발자가 서버 1대, 2대를 관리하는 것을 넘어, AWS Lambda나 Fargate처럼 들어오는 요청(이벤트) 단위로 인프라가 0.1초 만에 무한대로 확장(Scale-Out)되었다가 줄어드는 궁극의 자원 관리 전술이 보편화되고 있다.
머신러닝 기반 쿼리/자원 최적화: 과거에는 DBA나 아키텍트가 일일이 SQL 실행 계획을 뜯어보며 인덱스를 걸고 스레드 풀 사이즈를 튜닝했다면, 현재는 자율 운영 데이터베이스(Autonomous DB)가 AI를 통해 스스로 병목을 찾아내고 백그라운드에서 인덱스를 생성해 '자원 요구량'을 알아서 낮춰주는 시대가 도림했다.

참고 표준

Amdahl's Law (암달의 법칙): 시스템의 일부를 아무리 병렬화(멀티코어)로 최적화하더라도, 직렬로 처리되어야만 하는 남은 부분의 비율 때문에 전체 성능 향상에는 수학적 한계가 있다는 성능 공학의 절대 법칙.
Little's Law (리틀의 법칙): L = λ * W (시스템 내 머무는 손님 수 = 초당 도착하는 손님 수 * 머무는 시간). 큐잉 이론과 성능 튜닝(대기 시간 vs 처리량)의 근간이 되는 수학적 증명.

성능 최적화는 흔히 '돈(인프라 비용)'과 '시간(엔지니어링 공수)'을 맞바꾸는 예술이라고 불린다. 기술사는 단순히 코드를 빠르게 짜는 개발자를 넘어, 시스템 전체의 병목(Bottleneck)이 CPU인지, 메모리인지, 네트워크인지, 디스크인지 정확히 타격점을 찾고, 수백 가지 전술 중 **가장 돈이 적게 들면서 가장 효과가 확실한 전술(예: 캐시 한 줄 추가)**을 가장 먼저 선택해 내는 날카로운 진단 능력을 갖춰야 한다.

📢 섹션 요약 비유: 성능 전술은 막힌 고속도로를 뚫기 위해 1조 원을 들여 새 도로를 깔기(스케일 아웃) 전에, 혹시 톨게이트 직원 한 명이 거스름돈을 천천히 줘서(비효율적 코드 병목) 차가 밀리는 건 아닌지 확인하고 그 직원을 하이패스(캐시)로 바꾸는 스마트한 문제 해결 과정입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
스케일 업(Scale-Up) / 아웃(Scale-Out)	물리적 자원을 늘리는 성능 전술. 과거는 서버 스펙을 올리는 스케일 업 중심이었으나, 현재 클라우드는 저렴한 다수 서버로 분산하는 스케일 아웃이 표준이다.
비동기 큐잉 (Asynchronous Queueing)	자원 요구 관리의 핵심으로, 무거운 작업을 동기적으로 기다리지 않고 메시지 큐(Kafka 등)에 던져 처리량을 방어하는 전술.
캐시 (Cache)	데이터 다중 복제 전술의 일환으로, 느린 디스크 I/O를 빠른 메모리 I/O로 치환하여 응답 시간을 획기적으로 단축시키는 마법.
암달의 법칙 (Amdahl's Law)	병렬 컴퓨팅을 통해 동시성(자원 관리)을 높여도, 코드 내에 순차적으로 처리해야만 하는 동기화(Lock) 로직이 있다면 성능 향상에 한계가 온다는 딜레마.
로드밸런싱 (Load Balancing)	늘어난 일꾼(Scale-Out 서버들)에게 라운드 로빈이나 최소 연결 방식으로 트래픽을 분산시켜 주는 스케줄링 전술의 핵심 인프라.

👶 어린이를 위한 3줄 비유 설명

떡볶이집에 손님이 갑자기 100명이나 몰렸어요. 이대로면 손님들이 1시간을 밖에서 기다려야 해요.
사장님은 요리 과정을 줄여서 빨리 만들거나(자원 요구 관리), 알바생과 화구를 3배로 늘리거나(자원 관리), 단골손님을 먼저 들여보내는(스케줄링) 방법을 고민해야 해요.
이렇게 컴퓨터 서버에 많은 사람이 몰렸을 때 멈추거나 느려지지 않고 쌩쌩 돌아가게 만드는 모든 작전을 **'성능 전술'**이라고 한답니다!