서버는 켜져 있는데 접속이 안 될 때 확인할 것｜IT 운영자가 보는 장애 점검 순서
2026. 6. 22. 11:22ㆍIT 실무노트
시스템이 느릴 때 IT 운영자가 확인해야 할 항목을 정리했습니다. 특정 사용자 여부, 느린 메뉴, 네트워크 지연, 서버 CPU·메모리·디스크, WAS Thread, DB 쿼리, DB Lock, Connection Pool, 외부 API, 배치 작업까지 실무 기준으로 설명합니다.
IT 운영 업무를 하다 보면 사용자가 시스템이 느리다고 문의하는 경우가 많습니다.
사용자는 보통 이렇게 말합니다.
“화면이 너무 늦게 열립니다.”
“조회 버튼을 누르면 한참 걸립니다.”
“저장하는 데 시간이 오래 걸립니다.”
“특정 메뉴만 느립니다.”
“오전에는 괜찮았는데 오후부터 느려졌습니다.”
“다른 사람도 다 느리다고 합니다.”
시스템이 느리다는 문의는 단순한 오류보다 원인 파악이 더 어려운 경우가 많습니다.
아예 접속이 안 되거나 오류 메시지가 명확하게 뜨면 확인 방향을 잡기 쉽습니다.
하지만 “느리다”는 현상은 사용자 PC 문제일 수도 있고, 네트워크 문제일 수도 있고, 서버 리소스 문제일 수도 있고, DB 쿼리 문제일 수도 있습니다.
IT 운영직이나 SM팀 업무에서는 시스템이 느릴 때 어느 구간에서 지연이 발생하는지를 나눠서 확인해야 합니다.
이번 글에서는 시스템이 느릴 때 IT 운영자가 확인해야 할 서버·DB·네트워크 점검 순서를 실무 기준으로 정리해보겠습니다.
시스템이 느리다는 말의 의미
사용자가 “시스템이 느리다”고 말할 때 그 의미는 다양합니다.
예를 들어 다음과 같은 상황이 모두 “느리다”로 표현될 수 있습니다.
- 로그인 화면이 늦게 열림
- 메뉴 이동이 느림
- 조회 결과가 늦게 나옴
- 저장 버튼을 누른 뒤 오래 걸림
- 엑셀 다운로드가 오래 걸림
- 파일 업로드가 오래 걸림
- API 응답이 지연됨
- 배치 처리가 평소보다 오래 걸림
- 특정 시간대에만 느림
- 특정 사용자 PC에서만 느림
즉, “시스템이 느리다”는 말만 듣고 바로 서버 문제라고 판단하면 안 됩니다.
운영자는 먼저 어떤 동작이 느린지, 언제부터 느린지, 누구에게 발생하는지 확인해야 합니다.
시스템 지연이 발생하는 대표적인 원인
시스템이 느려지는 원인은 여러 가지입니다.
대표적인 원인은 다음과 같습니다.
- 사용자 PC 성능 문제
- 브라우저 캐시 또는 세션 문제
- 사용자 네트워크 지연
- VPN 또는 외부망 속도 저하
- 서버 CPU 사용률 증가
- 서버 메모리 부족
- 디스크 사용률 증가
- WAS Thread 부족
- DB 쿼리 지연
- DB Lock 발생
- DB Connection Pool 부족
- 대량 데이터 조회
- 외부 API 응답 지연
- SFTP 또는 파일 처리 지연
- 배치 작업과 사용자 업무 시간 충돌
- 최근 배포 후 성능 저하
이처럼 시스템 지연은 한 가지 원인만으로 발생하지 않습니다.
서버, DB, 네트워크, 애플리케이션, 외부 연동을 함께 봐야 하는 경우가 많습니다.
1. 특정 사용자만 느린지 전체가 느린지 확인
시스템이 느리다는 문의가 들어오면 가장 먼저 영향 범위를 확인해야 합니다.
특정 사용자만 느린지, 전체 사용자가 느린지에 따라 확인 방향이 달라집니다.
확인해야 할 항목은 다음과 같습니다.
- 특정 사용자만 느린지
- 특정 PC에서만 느린지
- 특정 부서나 지점에서만 느린지
- 특정 메뉴만 느린지
- 전체 시스템이 느린지
- 사내망과 외부망 차이가 있는지
- VPN 사용자만 느린지
- 특정 시간대에만 느린지
특정 사용자만 느리다면 사용자 PC, 브라우저, 네트워크, VPN 문제일 수 있습니다.
반대로 전체 사용자가 동시에 느리다면 서버, DB, 네트워크 장비, 외부 연동, 배치 작업 문제를 의심할 수 있습니다.
운영자는 먼저 “누가, 어디서, 어떤 메뉴에서 느린지”를 확인해야 합니다.
2. 어느 화면이나 기능이 느린지 확인
시스템 전체가 느린 것인지, 특정 메뉴나 기능만 느린 것인지 확인해야 합니다.
사용자는 “시스템이 느리다”고 말하지만 실제로는 특정 조회 화면만 느린 경우가 많습니다.
확인해야 할 항목은 다음과 같습니다.
- 로그인만 느린지
- 메인 화면만 느린지
- 특정 조회 화면만 느린지
- 저장 기능만 느린지
- 엑셀 다운로드만 느린지
- 파일 업로드만 느린지
- 특정 고객사나 특정 조건에서만 느린지
- 특정 기간 조회 시에만 느린지
예를 들어 전체 메뉴는 정상인데 재고 조회 화면만 느리다면 DB 조회 조건이나 쿼리 문제일 가능성이 있습니다.
저장만 느리다면 DB 저장 처리, API 호출, 후속 프로세스 문제일 수 있습니다.
엑셀 다운로드만 느리다면 조회 데이터 건수, 파일 생성 로직, 서버 메모리 사용량을 확인해야 합니다.
3. 언제부터 느려졌는지 확인
시스템 지연 장애에서는 발생 시점이 중요합니다.
언제부터 느려졌는지 확인하면 최근 변경사항과 연결해서 원인을 찾을 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 오늘부터 느려졌는지
- 특정 시간대부터 느려졌는지
- 배포 이후 느려졌는지
- 서버 재기동 이후 느려졌는지
- DB 작업 이후 느려졌는지
- 방화벽 또는 네트워크 작업 이후 느려졌는지
- 특정 배치 실행 시간과 겹치는지
- 월말, 마감, 출고 피크 시간대인지
예를 들어 매일 오전 9시부터 10시 사이에 느리다면 사용자 접속량 증가나 배치 작업과 겹치는 문제일 수 있습니다.
월말마다 느려진다면 마감 데이터 조회, 정산 배치, 대량 엑셀 다운로드가 원인일 수 있습니다.
운영자는 지연 발생 시점과 반복 패턴을 함께 확인해야 합니다.
4. 사용자 PC와 브라우저 확인
특정 사용자만 시스템이 느리다면 사용자 PC 환경을 확인해야 합니다.
서버가 정상이어도 사용자 PC나 브라우저 상태 때문에 화면이 느릴 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 다른 사용자도 같은 증상인지
- 같은 계정으로 다른 PC에서 정상인지
- 다른 브라우저에서도 느린지
- 브라우저 캐시 삭제 후 정상인지
- PC CPU나 메모리 사용률이 높은지
- 보안 프로그램이나 백신 영향은 없는지
- 회사 네트워크가 아닌 외부망에서 접속 중인지
- VPN 접속 상태인지
예를 들어 같은 계정으로 다른 PC에서는 정상인데 특정 PC에서만 느리다면 서버 문제보다는 해당 PC나 브라우저 문제일 가능성이 큽니다.
운영자는 전체 장애로 확대하기 전에 사용자 환경 문제인지 먼저 분리해볼 필요가 있습니다.
5. 네트워크 지연 확인
시스템이 느릴 때 네트워크 상태도 확인해야 합니다.
특히 지점, 외부망, VPN, 협력업체 접속 환경에서는 네트워크 지연이 원인일 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 사내망에서 접속해도 느린지
- 외부망에서만 느린지
- 특정 지점에서만 느린지
- VPN 접속자만 느린지
- 서버까지 ping 응답 시간이 높은지
- 패킷 손실이 있는지
- 특정 포트 접속이 지연되는지
- DNS 조회가 느린지
기본 확인은 ping으로 할 수 있습니다.
ping example.com응답 시간이 평소보다 높거나 Request timed out이 반복된다면 네트워크 지연이나 손실을 의심할 수 있습니다.
단, ping 결과만으로 전체 네트워크 상태를 판단하면 안 됩니다.
웹 서비스나 API는 포트, 방화벽, 서버 응답 시간까지 함께 확인해야 합니다.
6. 서버 CPU 사용률 확인
전체 사용자가 시스템이 느리다고 느낀다면 서버 CPU 사용률을 확인해야 합니다.
CPU 사용률이 높은 상태가 지속되면 요청 처리가 늦어질 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- CPU 사용률이 평소보다 높은지
- 특정 프로세스가 CPU를 많이 사용하는지
- 순간적으로만 높은지 지속적으로 높은지
- 배치 작업과 겹치는지
- 최근 배포 이후 CPU 사용량이 증가했는지
- 사용자 접속량이 증가했는지
예를 들어 특정 배치가 실행되는 시간에 CPU 사용률이 급격히 올라가면 사용자 화면 응답도 느려질 수 있습니다.
운영자는 CPU 사용률만 보는 것이 아니라 어떤 프로세스가 자원을 사용하는지도 확인해야 합니다.
7. 서버 메모리 사용률 확인
메모리 부족도 시스템 지연의 주요 원인입니다.
메모리가 부족하면 서버가 요청을 처리하는 데 시간이 오래 걸리거나, WAS가 불안정해질 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 메모리 사용률이 높은지
- 사용 가능한 메모리가 부족한지
- 특정 프로세스가 메모리를 과도하게 사용하는지
- 메모리 사용량이 계속 증가하는지
- GC가 자주 발생하는지
- Out of memory 오류가 있는지
특히 Java 기반 WAS에서는 메모리 사용량과 GC 로그가 중요할 수 있습니다.
메모리 부족이 반복되면 단순 재기동으로 일시 해소될 수 있지만, 근본 원인은 메모리 누수, 대량 데이터 처리, 설정 부족일 수 있습니다.
8. 디스크 사용률 확인
디스크 사용률이 높거나 디스크 I/O가 느려도 시스템이 느려질 수 있습니다.
특히 로그 파일, 임시 파일, 업로드 파일, 배치 결과 파일이 많이 쌓이는 시스템에서는 디스크 상태를 확인해야 합니다.
확인해야 할 항목은 다음과 같습니다.
- 디스크 사용률이 90% 이상인지
- 로그 파일이 과도하게 쌓였는지
- 임시 파일이 정리되지 않았는지
- 업로드 파일이 많이 쌓였는지
- 디스크 I/O가 높은지
- 백업 작업과 시간이 겹치는지
- 파일 생성이나 다운로드가 느린지
디스크가 가득 차면 로그 기록, 파일 업로드, 엑셀 다운로드, 배치 처리에 문제가 생길 수 있습니다.
운영자는 시스템이 느릴 때 CPU와 메모리뿐 아니라 디스크도 함께 확인해야 합니다.
9. WAS Thread 상태 확인
업무 시스템이 WAS를 사용하는 경우 Thread 상태도 확인해야 합니다.
WAS Thread는 사용자의 요청을 처리하는 작업 단위입니다.
동시에 들어오는 요청이 많거나 특정 요청이 오래 걸리면 Thread가 부족해질 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- Active Thread 수가 높은지
- 대기 중인 요청이 많은지
- Thread Pool이 부족한지
- 특정 URL 요청이 오래 걸리는지
- Thread가 DB 응답을 기다리고 있는지
- 외부 API 응답을 기다리고 있는지
- Deadlock 의심 상황이 있는지
사용자는 단순히 화면이 느리다고 느끼지만, 실제로는 WAS Thread가 모두 사용 중이라 새 요청이 대기하고 있을 수 있습니다.
이 경우 서버 CPU가 낮아도 시스템이 느릴 수 있습니다.
10. DB 쿼리 지연 확인
시스템 지연에서 가장 자주 확인해야 하는 영역 중 하나가 DB입니다.
조회 화면이 느리거나 저장이 오래 걸린다면 DB 쿼리 지연을 의심할 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 특정 쿼리가 오래 걸리는지
- 조회 조건이 너무 넓은지
- 인덱스를 타지 않는 쿼리인지
- 데이터 건수가 갑자기 증가했는지
- 특정 테이블에 부하가 몰리는지
- Full Scan이 발생하는지
- 통계 정보가 오래되었는지
- 평소보다 실행 시간이 길어졌는지
예를 들어 사용자가 기간 조건을 1년으로 잡고 대량 데이터를 조회하면 화면이 느려질 수 있습니다.
또 최근 데이터가 많이 쌓였는데 인덱스나 조회 조건이 맞지 않으면 특정 화면만 느려질 수 있습니다.
운영자는 느린 화면이 있을 때 해당 화면의 SQL이나 DB 처리 시간을 확인해야 합니다.
11. DB Lock 확인
저장이나 수정 기능이 오래 걸린다면 DB Lock도 확인해야 합니다.
DB Lock은 특정 데이터가 다른 작업에 의해 잠겨 있어서 대기하는 상태를 의미합니다.
확인해야 할 상황은 다음과 같습니다.
- 저장 버튼을 누르면 오래 걸림
- 특정 데이터 수정이 안 됨
- 특정 주문이나 재고만 처리 지연
- 배치 작업 중 화면 저장이 느려짐
- 같은 테이블을 여러 작업이 동시에 처리함
- 트랜잭션이 오래 유지됨
DB Lock이 발생하면 서버나 네트워크가 정상이어도 사용자는 시스템이 멈춘 것처럼 느낄 수 있습니다.
특히 배치 작업과 사용자 업무가 같은 테이블을 동시에 처리하면 지연이 발생할 수 있습니다.
12. DB Connection Pool 확인
애플리케이션은 DB에 접속할 때 Connection Pool을 사용합니다.
DB Connection Pool이 부족하면 사용자의 요청이 DB 연결을 기다리면서 느려질 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- Active Connection 수
- Idle Connection 수
- 최대 Connection 수
- Connection 대기 시간
- Connection timeout 발생 여부
- DB 연결 누수 가능성
- 최근 접속자 수 증가 여부
DB 서버가 정상이어도 애플리케이션에서 사용할 수 있는 DB Connection이 부족하면 화면 응답이 느려질 수 있습니다.
특히 특정 시간대에 접속자가 몰리거나 대량 조회가 발생하면 Connection Pool 부족이 발생할 수 있습니다.
13. 외부 API 응답 지연 확인
저장이나 조회 과정에서 외부 API를 호출하는 시스템이라면 외부 API 응답 지연도 확인해야 합니다.
사용자는 내부 시스템이 느리다고 느끼지만, 실제로는 외부 시스템 응답을 기다리고 있는 경우가 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 해당 기능에서 외부 API를 호출하는지
- API 응답 시간이 평소보다 느린지
- Timeout이 발생하는지
- 특정 API만 느린지
- 상대 시스템 장애 공지가 있는지
- 요청 데이터 건수가 많은지
- 재시도 로직이 반복되고 있는지
예를 들어 주문 저장 시 외부 시스템에 재고 확인 API를 호출한다면, 외부 API 응답이 늦어질 때 내부 화면도 함께 느려질 수 있습니다.
운영자는 내부 서버와 DB만 보지 말고 외부 연동 구간도 확인해야 합니다.
14. 배치 작업 영향 확인
시스템이 특정 시간대에만 느리다면 배치 작업과 시간이 겹치는지 확인해야 합니다.
배치가 대량 데이터를 처리하면 서버, DB, 네트워크 리소스를 많이 사용할 수 있습니다.
확인해야 할 항목은 다음과 같습니다.
- 지연 발생 시간에 실행 중인 배치가 있는지
- 배치 처리 건수가 평소보다 많은지
- 배치가 DB 부하를 유발하는지
- 배치가 파일 생성이나 전송을 많이 하는지
- 사용자 업무 시간과 배치 시간이 겹치는지
- 배치 실패 후 재처리가 반복되는지
예를 들어 새벽에 도는 배치가 지연되어 오전 업무 시간까지 실행 중이라면 사용자 화면도 느려질 수 있습니다.
운영자는 시스템 지연이 발생했을 때 실행 중인 배치 작업을 확인해야 합니다.
15. 최근 배포나 설정 변경 확인
시스템이 갑자기 느려졌다면 최근 변경사항을 확인해야 합니다.
성능 저하는 배포 이후 발생하는 경우도 많습니다.
확인해야 할 항목은 다음과 같습니다.
- 최근 프로그램 배포가 있었는지
- SQL이 변경되었는지
- 신규 기능이 추가되었는지
- 서버 설정이 변경되었는지
- DB 인덱스나 테이블 변경이 있었는지
- 방화벽이나 네트워크 설정이 변경되었는지
- 외부 API 연동 방식이 변경되었는지
- 배치 스케줄이 변경되었는지
예를 들어 배포 이후 특정 조회 화면이 느려졌다면 변경된 SQL이나 로직을 확인해야 합니다.
최근 변경사항은 장애 원인을 좁히는 중요한 단서입니다.
시스템이 느릴 때 운영자 확인 순서
시스템이 느릴 때는 아래 순서로 확인하면 좋습니다.
- 특정 사용자 문제인지 전체 문제인지 확인
- 어떤 화면이나 기능이 느린지 확인
- 언제부터 느려졌는지 확인
- 특정 시간대 반복 여부 확인
- 사용자 PC와 브라우저 상태 확인
- 네트워크 지연 여부 확인
- 서버 CPU 사용률 확인
- 서버 메모리 사용률 확인
- 디스크 사용률과 I/O 확인
- WAS Thread 상태 확인
- DB 쿼리 지연 확인
- DB Lock 여부 확인
- DB Connection Pool 상태 확인
- 외부 API 응답 시간 확인
- 실행 중인 배치 작업 확인
- 최근 배포나 설정 변경 확인
- 로그에서 응답 시간과 오류 확인
- 조치 후 정상 여부 확인
- 장애 이력 기록
이 순서대로 보면 시스템 지연 원인을 서버, DB, 네트워크, 애플리케이션 영역으로 나눠서 확인할 수 있습니다.
사용자에게 안내할 때는 어떻게 말할까?
시스템 지연 문의가 들어왔을 때는 확인 범위와 현재 상태를 간단히 안내하는 것이 좋습니다.
전체적으로 느린 경우에는 이렇게 안내할 수 있습니다.
현재 시스템 응답 지연이 확인되어 서버, DB, 네트워크 상태를 점검 중입니다. 원인 확인 후 조치 결과를 다시 안내드리겠습니다.
특정 화면만 느린 경우에는 이렇게 안내할 수 있습니다.
해당 메뉴 조회 시 응답 시간이 지연되는 것으로 확인되어 조회 조건과 DB 처리 시간을 확인 중입니다.
특정 사용자만 느린 경우에는 이렇게 안내할 수 있습니다.
현재 다른 사용자는 정상 접속되는 것으로 확인되어 사용자 PC 또는 네트워크 환경을 우선 확인하고 있습니다. 다른 브라우저 또는 다른 PC에서도 동일한지 확인 부탁드립니다.
외부 API 지연이 원인일 수 있다면 이렇게 안내할 수 있습니다.
해당 기능 처리 중 외부 시스템 응답 지연 가능성이 확인되어 연동 로그와 상대 시스템 응답 상태를 함께 확인 중입니다.
사용자에게는 “서버는 정상입니다”라고만 말하기보다 어떤 구간을 확인 중인지 알려주는 것이 좋습니다.
개발자나 외부 업체에 전달할 정보
시스템 지연이 애플리케이션이나 외부 연동 문제로 보이면 개발자나 외부 업체에 확인 요청을 해야 합니다.
전달하면 좋은 항목은 다음과 같습니다.
- 지연 발생 시간
- 느린 메뉴 또는 기능
- 사용자 ID
- 조회 조건
- 처리 데이터 건수
- 응답 시간
- 오류 로그 여부
- 서버 리소스 상태
- DB 쿼리 실행 시간
- 외부 API 응답 시간
- 최근 배포 여부
- 재현 가능 여부
예를 들어 다음과 같이 전달할 수 있습니다.
금일 10:30경 재고 조회 화면에서 응답 지연이 발생했습니다.
특정 고객사 기준 최근 3개월 조회 시 응답 시간이 40초 이상 소요됩니다.
서버 CPU와 메모리는 정상이나 DB 쿼리 실행 시간이 길게 확인되어 조회 SQL 및 인덱스 확인 부탁드립니다.외부 API 지연이라면 이렇게 전달할 수 있습니다.
주문 저장 처리 중 외부 재고 확인 API 응답 시간이 평소보다 지연되고 있습니다.
금일 14:00~14:30 사이 API 응답 시간이 30초 이상 소요된 로그가 확인됩니다.
해당 시간대 상대 시스템 응답 지연 여부 확인 부탁드립니다.이렇게 정리하면 담당자가 원인을 더 빠르게 확인할 수 있습니다.
시스템 지연 대응 시 주의할 점
시스템이 느릴 때는 몇 가지 주의할 점이 있습니다.
첫 번째, 사용자 표현만 듣고 바로 서버 문제로 단정하지 않아야 합니다.
느림의 원인은 PC, 네트워크, 서버, DB, 외부 API, 배치 등 다양합니다.
두 번째, 전체 장애인지 일부 사용자 문제인지 먼저 확인해야 합니다.
영향 범위를 확인해야 대응 우선순위를 정할 수 있습니다.
세 번째, 단순 재기동으로만 해결하려고 하면 안 됩니다.
재기동은 일시적으로 증상을 완화할 수 있지만, 원인을 기록하지 않으면 같은 문제가 반복될 수 있습니다.
네 번째, 지연 시간을 수치로 확인해야 합니다.
“느리다”는 표현보다 실제 응답 시간이 몇 초인지 확인해야 원인 분석이 쉬워집니다.
다섯 번째, 최근 변경사항을 반드시 확인해야 합니다.
배포, DB 작업, 배치 변경, 외부 시스템 변경 이후 성능 저하가 발생하는 경우가 많습니다.
IT 운영자가 시스템 지연을 알아야 하는 이유
IT 운영직이나 SM팀 업무에서는 시스템 지연 문의가 자주 발생합니다.
오류 메시지가 명확한 장애보다 “느리다”는 문의가 더 어렵게 느껴질 수 있습니다.
시스템 지연을 이해하면 다음을 구분할 수 있습니다.
- 사용자 PC 문제인지
- 네트워크 문제인지
- 서버 리소스 문제인지
- WAS Thread 문제인지
- DB 쿼리 문제인지
- DB Lock 문제인지
- 외부 API 지연인지
- 배치 작업 영향인지
- 최근 배포 영향인지
이 차이를 구분할 수 있어야 정확한 담당자에게 문제를 전달하고, 불필요한 장애 확대를 줄일 수 있습니다.
운영자는 모든 성능 문제를 직접 튜닝하지 않더라도, 어느 구간에서 지연이 발생하는지 좁혀야 합니다.
마무리
시스템이 느리다는 문의는 IT 운영 업무에서 자주 발생하는 장애 유형입니다.
하지만 “느리다”는 표현만으로는 원인을 알 수 없습니다.
특정 사용자 문제인지 전체 문제인지, 어떤 화면이나 기능이 느린지, 언제부터 느려졌는지 먼저 확인해야 합니다.
그다음 사용자 PC, 네트워크, 서버 CPU, 메모리, 디스크, WAS Thread, DB 쿼리, DB Lock, Connection Pool, 외부 API, 배치 작업, 최근 배포 여부를 순서대로 확인해야 합니다.
IT 운영직이나 SM팀 업무를 준비하고 있다면 시스템 지연을 단순히 “서버가 느리다”로 보지 말고, 어느 구간에서 시간이 걸리는지 나눠서 보는 습관을 들이는 것이 좋습니다.
이런 관점이 있어야 장애 대응 속도도 빨라지고, 개발자·DBA·네트워크 담당자와도 정확하게 소통할 수 있습니다.
다음 글에서는 시스템 지연과 연결해서 DB Lock이 발생하면 어떤 증상이 나타나는지를 정리해보겠습니다.
함께 보면 좋은 글
'IT 실무노트' 카테고리의 다른 글
| DB Connection Pool 부족 증상과 확인 방법｜시스템이 느릴 때 운영자가 봐야 할 것 (0) | 2026.06.24 |
|---|---|
| DB Lock이 걸리면 어떤 증상이 나타날까｜저장·수정이 느릴 때 확인할 것 (0) | 2026.06.23 |
| 서버는 켜져 있는데 접속이 안 될 때 확인할 것｜IT 운영자가 보는 장애 점검 순서 (0) | 2026.06.21 |
| VPN 접속이 안 될 때 확인할 것｜IT 운영자가 보는 네트워크·계정·권한 문제 (0) | 2026.06.20 |
| DNS 오류와 도메인 접속 장애 확인 방법｜IT 운영자가 먼저 봐야 할 네트워크 기본 (0) | 2026.06.19 |