• 느려짐 원인은 대부분 CPU / 메모리(swap) / 디스크 I/O / 프로세스 폭주 중 하나다.
• Load는 CPU 사용률이 아니라 “밀린 작업량”이다.
• wa(iowait)가 높으면 CPU 문제가 아니라 디스크 병목일 가능성이 크다.
• swap이 증가하면 체감 성능은 급격히 나빠진다.
• top → htop → 원인별 1개 명령 추가 확인이면 대부분 10분 안에 범위를 좁힐 수 있다.

1️⃣ 문제 상황

어느 날 갑자기 이런 연락이 옵니다.

• “사이트가 너무 느려요.”
• “SSH는 되는데 명령이 버벅여요.”
• “DB 쿼리가 갑자기 지연됩니다.”

이때 제 머릿속에 가장 먼저 뜨는 후보는 네 가지입니다.

1. CPU 과부하
2. 메모리 부족(swap)
3. 디스크 I/O 병목
4. 프로세스 폭주

2️⃣ 내 환경 (예시 기준)

• Ubuntu 22.04
• 4 vCPU / 8GB RAM
• Nginx + PHP-FPM + MariaDB
• Docker 일부 사용

※ 코어 수에 따라 Load 해석이 달라지므로 환경은 항상 먼저 확인합니다.

nproc

3️⃣ 1차 가설

처음엔 대부분 “CPU가 문제인가?”부터 의심합니다.

하지만 경험상 절반 이상은 CPU가 아니었습니다.

특히:

• Load 높음 + CPU idle 많음 → 디스크 병목
• 체감 심한 느려짐 + swap 증가 → 메모리 압박

그래서 1차 스냅샷은 반드시 OS 레벨에서 봅니다.

4️⃣ 1분 스캔: top으로 상태 스냅샷

top

1️⃣ Load average

Load는 CPU 사용률이 아닙니다.
“대기 중인 작업 수”에 가깝습니다.

4코어 서버 기준:

• 0~4 → 정상 범위
• 6~10 → 병목 의심
• 10 이상 → 거의 확실히 무언가 막힘

2️⃣ CPU 라인 해석

• id 낮고 us 높음 → 연산/쿼리/압축 등 CPU 사용
• sy 높음 → 커널/네트워크/컨텍스트 스위칭
• wa 높음 → 디스크 기다리는 중 (I/O 병목)

⚠ wa가 15~20% 이상이면 디스크 문제 가능성 높음

3️⃣ 메모리 / Swap

• Swap 사용 증가 = 체감 성능 급락 시작
• RAM 사용률만 보고 판단하면 안 됨

5️⃣ 3분: htop으로 범인 찾기

htop

• F6 → CPU% 정렬
• F6 → MEM% 정렬
• 필요 시 “Show threads” 활성화

확인 포인트:

• 특정 프로세스가 계속 튀는가?
• 같은 서비스가 여러 개 과도하게 생성되는가?
• 사용자 계정이 예상과 다른가?

6️⃣ 원인별 다음 확인 (한 번만 더 본다)

① CPU 과부하 (us/sy 높음)

ps -eo pid,user,ppid,cmd,%cpu,%mem --sort=-%cpu | head

확인:

• 배치 작업인가?
• 쿼리 폭주인가?
• 무한 루프인가?

운영 팁:
재시작은 임시 해결일 뿐.
로그를 먼저 확인해야 재발 방지 가능.

② 메모리 부족 (swap 증가)

free -h

확인:

• swap 사용량
• 캐시 vs 실제 사용 메모리

운영 팁:

• 도커 메모리 제한 설정 점검
• 자바/DB 힙 설정 확인
• OOM 로그 확인

dmesg | grep -i oom

③ 디스크 I/O 병목 (wa 높음)

df -h

90% 이상이면 위험 구간.

sudo du -h -d 1 /var | sort -h | tail

로그/도커 파일 폭증 확인.

가능하면:

iostat -xz 1 3

I/O wait가 높고 await 값이 크면 디스크 병목.

운영 경험상:

• /var/log 폭증
• Docker json 로그 무제한 증가
• 백업 파일 미정리

이 세 가지가 단골입니다.

④ 프로세스 폭주 / 좀비

ps -eLf | wc -l

좀비 프로세스:

ps aux | awk '$8 ~ /Z/ { print }'

systemd 실패 확인:

systemctl --failed

크래시 루프는 CPU보다 더 체감 성능을 떨어뜨립니다.

7️⃣ 실제 원인 패턴 (운영 경험)

제가 겪은 실제 비율 체감:

• 디스크 I/O 병목: 35%
• 메모리(swap) 문제: 30%
• CPU 과부하: 20%
• 프로세스/크래시 루프: 15%

의외로 CPU는 가장 흔한 원인이 아니었습니다.

8️⃣ 해결 후 반드시 하는 것 (재발 방지)

✔ 로그 보존 및 원인 기록
✔ swap 사용률 모니터링 추가
✔ 디스크 80% 이상 알림 설정
✔ Docker 로그 제한 설정
✔ 주기적 용량 점검 자동화

임시 재시작만 하고 끝내면, 같은 장애가 반복됩니다.

9️⃣ 10분 진단 루틴 정리

1️⃣ top → Load / id / wa / swap
2️⃣ htop → CPU% / MEM% 정렬
3️⃣ 원인별 명령 1개만 추가
4️⃣ 임시 조치 + 로그 확인
5️⃣ 재발 방지 설정

🔟 자주 하는 실수

• Load만 보고 CPU 문제로 단정
• wa를 안 보고 CPU%만 보는 실수
• swap 증가를 정상으로 넘김
• 디스크 95%인데 방치
• 재시작만 하고 원인 기록 안 남김

📌 교훈

느려짐은 대부분 “OS 자원 병목”입니다.
애플리케이션부터 의심하기보다,
커널이 관리하는 CPU/메모리/I/O 상태를 먼저 보는 습관이
장애 대응 속도를 가장 빠르게 올려줍니다.

게시물 서버가 갑자기 느려질 때: TOP/HTOP로 10분 안에 범위 좁히는 방법이 하우인포-IT·테크에 처음 등장했습니다.

1. Git: 코드 변경 이력 관리 도구
2. Repository(Repo): 소스코드 저장소
3. Commit: 변경 사항을 기록하는 단위
4. Branch: 작업 분리용 가지
5. Merge: 브랜치 변경 사항 합치기
6. Rebase: 커밋을 다시 정리하며 이력 재배치
7. Conflict: 병합 중 충돌(같은 줄 수정 등)
8. PR/MR: 코드 리뷰 및 병합 요청(Pull/Merge Request)
9. Tag: 특정 버전(릴리즈 지점) 표시
10. Git Flow: 브랜치 운영 전략(예: main/dev/feature)

2) 빌드·패키징·릴리즈 (11~20)

11. Build: 실행 가능한 결과물 생성 과정
12. Artifact: 빌드 결과물(jar, 이미지, zip 등)
13. Dependency: 프로젝트가 필요로 하는 외부 라이브러리
14. Versioning: 버전 관리 규칙(예: 1.2.3)
15. Semantic Versioning(SemVer): MAJOR.MINOR.PATCH 규칙
16. Release: 사용자에게 제공되는 배포 버전
17. Rollback: 문제 발생 시 이전 버전으로 되돌리기
18. Hotfix: 긴급 수정 배포
19. Patch: 소규모 수정(버그/보안 등)
20. Changelog: 버전별 변경 기록

3) CI/CD (21~30)

21. CI(Continuous Integration): 코드 통합/빌드/테스트 자동화
22. CD(Continuous Delivery/Deployment): 배포 자동화(전달/배포)
23. Pipeline: 자동화 작업 흐름(빌드→테스트→배포)
24. Runner/Agent: 파이프라인 작업을 실행하는 실행기
25. Stage/Job: 파이프라인 단계/실행 단위
26. Build Cache: 빌드 속도를 높이는 캐시
27. Artifact Registry: 빌드 결과물 저장소(이미지/패키지)
28. Environment: dev/stage/prod 같은 배포 환경
29. Approval/Gate: 운영 반영 전 승인 단계
30. Blue-Green Deploy: 두 환경 전환으로 무중단 배포

4) 컨테이너·오케스트레이션 (31~40)

31. Container: 실행 환경을 묶은 단위(가볍고 이식성 높음)
32. Docker: 컨테이너 빌드/실행 도구
33. Docker Image: 실행 템플릿(스냅샷)
34. Dockerfile: 이미지 생성 레시피
35. Container Registry: 이미지 저장소(Docker Hub 등)
36. Kubernetes(K8s): 컨테이너 운영 자동화(배치/확장)
37. Pod: K8s의 최소 배포 단위(컨테이너 묶음)
38. Deployment: Pod를 선언적으로 배포/업데이트 관리
39. Service: Pod에 안정적인 접근 주소 제공
40. Ingress: 외부 트래픽을 서비스로 라우팅(HTTP 경로 기반)

5) 인프라·클라우드·운영 (41~50)

41. IaC(Infrastructure as Code): 인프라를 코드로 관리(Terraform 등)
42. Provisioning: 서버/자원 생성 및 초기 구성
43. Configuration Management: 설정 자동화(Ansible 등)
44. Observability: 로그/메트릭/트레이스를 통한 가시성
45. Logging: 이벤트 기록(장애 분석의 핵심)
46. Metrics: 수치 기반 지표(CPU, Memory, QPS 등)
47. Tracing: 요청 흐름 추적(분산 환경에서 필수)
48. Alerting: 이상 징후 알림(PagerDuty, Slack 등)
49. SLA/SLO/SLI: 서비스 약속/목표/지표(신뢰성 관리)
50. Incident Response: 장애 대응 프로세스(탐지→완화→복구→회고)

✅ DevOps에서 특히 자주 나오는 “핵심 세트” 5개

• CI/CD: 자동화의 중심
• Docker/K8s: 배포 단위와 운영 자동화
• IaC: 인프라를 코드로 재현 가능하게
• Observability: 장애를 “빨리 찾고, 빨리 고치기”
• SLO 기반 운영: 목표를 숫자로 관리

게시물 DevOps 필수 용어 50 (DevOps Essentials)이 하우인포-IT·테크에 처음 등장했습니다.

1. Server(서버): 요청을 받고 처리해 응답을 주는 컴퓨터/프로그램
2. Client(클라이언트): 서버에 요청하는 쪽(브라우저, 앱 등)
3. HTTP: 웹 통신 규약(요청/응답의 규칙)
4. HTTPS: TLS로 암호화된 HTTP(보안 강화)
5. Request / Response: 요청 / 응답(백엔드의 기본 흐름)
6. Header / Body: 부가정보 / 실제 데이터(JSON 등)
7. Status Code: 응답 결과 코드(200, 400, 401, 404, 500 등)
8. URI / URL: 자원 식별자 / 자원 위치
9. DNS: 도메인 → IP로 변환하는 시스템
10. Port(포트): 한 서버 안에서 서비스를 구분하는 번호(80, 443 등)

2) API 설계·통신 (11~20)

11. API: 기능을 외부에서 사용하게 하는 인터페이스
12. Endpoint: API 주소(예: /api/users)
13. REST: 자원 중심 설계 스타일(HTTP 메서드 활용)
14. CRUD: Create/Read/Update/Delete(기본 데이터 작업)
15. JSON: 데이터 교환 포맷(가장 흔함)
16. Serialization: 객체 → 전송 가능한 형태(JSON)로 변환
17. Validation: 입력값 검증(보안/품질에 매우 중요)
18. Pagination: 목록을 페이지로 나눠 제공
19. Filtering/Sorting: 조건 검색/정렬(쿼리 파라미터로 구현)
20. Rate Limit: API 호출 횟수 제한(남용/공격 방지)

3) 인증·보안 (21~30)

21. Authentication(인증): “너 누구야?”(로그인 확인)
22. Authorization(인가): “이거 할 권한 있어?”
23. Session(세션): 서버가 로그인 상태를 관리하는 방식
24. Cookie(쿠키): 브라우저가 저장하는 작은 데이터(세션ID 등)
25. Token(토큰): 인증 정보를 담아 전달하는 값
26. JWT: 토큰 형식(서명으로 위변조 방지, stateless에 유리)
27. OAuth 2.0: 외부 로그인/권한 위임 표준(구글 로그인 등)
28. CORS: 다른 출처 요청을 제어하는 브라우저 보안 정책
29. Hash(해시): 되돌릴 수 없는 변환(비밀번호 저장에 사용)
30. Encryption(암호화): 키로 암·복호화 가능한 변환(민감데이터 보호)

4) 데이터베이스(DB) (31~40)

31. DB(Database): 데이터 저장소
32. RDBMS: 관계형 DB(MySQL, PostgreSQL 등)
33. SQL: 관계형 DB 질의 언어
34. NoSQL: 비관계형 DB(MongoDB, Redis 등)
35. Schema(스키마): 테이블 구조(컬럼/타입/제약조건)
36. Index(인덱스): 조회 성능을 올리는 “목차”(쓰기 비용 증가 가능)
37. Transaction(트랜잭션): 여러 작업을 하나로 묶어 처리(롤백 가능)
38. ACID: 트랜잭션의 4대 성질
39. Join: 여러 테이블을 연결해 조회
40. ORM: 객체로 DB를 다루게 해주는 도구(JPA, Hibernate 등)

5) 캐시·메시징·확장 (41~45)

41. Cache(캐시): 자주 쓰는 데이터를 빠르게 저장(성능 개선)
42. Redis: 대표적인 인메모리 캐시/세션/큐 활용 DB
43. Queue(큐): 작업을 순서대로 처리하는 구조
44. Message Broker: 메시지를 중계하는 시스템(RabbitMQ, Kafka 등)
45. Async(비동기): 기다리지 않고 다음 작업 진행(메일 발송/알림 등)

6) 배포·운영(DevOps) (46~50)

46. CI/CD: 빌드·테스트·배포 자동화 파이프라인
47. Container(컨테이너): 실행 환경을 묶어 어디서나 동일 실행
48. Docker: 컨테이너 생성/실행 도구
49. Kubernetes(K8s): 컨테이너 오케스트레이션(배치/스케일링)
50. Monitoring/Logging: 운영 상태 관측/기록(Prometheus, Grafana, ELK 등)

✅ “헷갈리는 핵심 5개” 한 줄 정리

• 인증 vs 인가: 누구냐 / 권한 있냐
• 세션 vs 토큰: 서버가 상태 저장 / 클라가 증명서 들고 다님
• SQL vs NoSQL: 관계형 / 비관계형
• 캐시 vs DB: 빠른 임시 저장 / 원본 저장
• 동기 vs 비동기: 기다림 / 안 기다림

게시물 백엔드 필수 용어 50 (Back-end Essentials)이 하우인포-IT·테크에 처음 등장했습니다.