서버 증설과 성능 모니터링, 느린 시스템의 해법은 다르다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

업무 시스템이 느려지면 가장 먼저 서버 사양부터 올려야 한다는 이야기가 나옵니다. 하지만 CPU와 메모리를 추가한 뒤에도 결재 화면은 여전히 늦게 열리고, 월말마다 같은 장애가 반복되는 경우가 적지 않습니다. 서버 증설은 부족한 자원을 늘리는 조치이고, 성능 모니터링은 느려진 원인을 찾아내는 과정이기 때문입니다.

직원 50명이 사용하는 시스템이 오전에는 빠른데 오후 3시만 되면 느려진다면 단순한 서버 용량 부족이 아닐 수 있습니다. 데이터베이스 쿼리, 외부 API, 네트워크, 저장장치, 배치 작업 가운데 어느 지점이 병목인지 먼저 구분해야 비용을 낭비하지 않습니다.

느린 화면과 부족한 서버 자원은 같은 문제가 아닙니다

체감 속도를 만드는 구간부터 나눠 봅니다

사용자가 말하는 ‘느리다’는 표현에는 여러 증상이 섞여 있습니다. 로그인 버튼을 누른 뒤 첫 화면이 늦는 문제, 검색 결과만 늦게 나오는 문제, 파일 첨부에서 멈추는 문제는 원인이 서로 다릅니다. 서버의 CPU 사용률만 확인해서는 이 차이를 파악하기 어렵습니다.

웹 기반 업무 시스템의 요청은 일반적으로 사용자 단말, 사내 네트워크, 웹 서버, 애플리케이션, 데이터베이스, 외부 서비스의 순서로 이동합니다. 디지털 데이터가 어떤 형태로 표현되고 처리되는지 기본 개념이 필요하다면 디지털의 용어 정의도 함께 참고할 수 있습니다. 중요한 점은 어느 한 구간의 지연도 사용자의 화면에서는 똑같은 ‘느림’으로 보인다는 사실입니다.

예를 들어 CPU 사용률이 35%에 불과한데 주문 조회가 12초 걸린다면 서버 증설의 우선순위는 낮습니다. 특정 데이터베이스 쿼리가 전체 응답 시간의 10초를 차지하거나, 외부 인증 API가 응답하지 않아 대기 시간이 길어졌을 가능성이 큽니다. 반대로 CPU가 업무 시간 내내 90% 이상이고 실행 대기 요청이 계속 쌓인다면 자원 증설도 유효한 선택이 됩니다.

• 모든 메뉴가 지속적으로 느림: CPU, 메모리, 디스크 입출력, 네트워크 포화 상태를 우선 확인합니다.
• 특정 검색이나 보고서만 느림: 느린 SQL, 인덱스 누락, 과도한 데이터 조회 범위를 점검합니다.
• 로그인이나 전자서명만 느림: 인증 서버와 외부 API의 응답 시간 및 실패율을 확인합니다.
• 파일 업로드에서만 멈춤: 파일 크기 제한, 저장 공간, 보안 검사, 회선 업로드 속도를 살펴봅니다.
• 특정 시간대에만 느림: 예약 배치, 백업, 대량 동기화 작업이 겹치는지 확인합니다.

진단 팁: ‘시스템이 느리다’고 기록하지 말고 ‘오후 3시 10분, 고객 검색 버튼 클릭 후 결과 표시까지 11초’처럼 시간·기능·소요 시간을 함께 남기십시오. 이 한 줄이 원인 추적 시간을 크게 줄입니다.

재부팅으로 사라진 장애와 해결된 장애를 구분합니다

재부팅은 원인 제거가 아니라 상태 초기화일 수 있습니다

서버를 재부팅한 직후 속도가 정상으로 돌아오면 문제가 해결됐다고 판단하기 쉽습니다. 그러나 메모리 누수, 연결 풀 고갈, 임시 파일 누적, 장시간 실행되는 프로세스가 원인이었다면 재부팅은 쌓인 상태를 잠시 비웠을 뿐입니다. 며칠 뒤 같은 조건이 만들어지면 장애는 다시 나타납니다.

재부팅 전에 CPU, 사용 가능 메모리, 스왑 사용량, 디스크 여유 공간, 주요 프로세스 상태와 오류 로그를 보존해야 합니다. 가능하다면 장애 시점 전후 30분의 지표를 별도 파일이나 모니터링 화면에 남기십시오. 재부팅 후에는 사라지는 정보가 많아, 먼저 껐다 켜면 가장 가치 있는 단서를 직접 없애는 셈이 됩니다.

반복 장애는 주기와 조건을 함께 찾습니다

매주 월요일 아침에 느려진다면 주말 백업이나 월요일 일괄 동기화를 의심할 수 있습니다. 매일 사용자가 늘어날수록 속도가 떨어지고 새벽 재시작 후 회복된다면 메모리 또는 데이터베이스 연결이 반환되지 않는 문제일 수 있습니다. 장애의 주기, 동시 사용자 수, 직전에 실행된 작업을 나란히 보면 단순 로그보다 원인이 선명해집니다.

1. 증상을 재현합니다. 어느 메뉴에서 어떤 입력을 했을 때 지연되는지 동일한 절차로 확인합니다.
2. 재부팅 전 지표를 저장합니다. CPU 평균만 보지 말고 최대치, 메모리 증가 추세, 디스크 대기 시간도 함께 기록합니다.
3. 오류 발생 시각을 맞춥니다. 사용자 신고 시간과 애플리케이션·웹 서버·데이터베이스 로그의 시간대를 통일합니다.
4. 재부팅 후 같은 절차를 반복합니다. 응답 시간과 자원 사용량이 얼마나 달라졌는지 숫자로 비교합니다.
5. 재발 조건을 관찰합니다. 사용량, 경과 시간, 배치 작업 가운데 무엇이 다시 쌓이는지 추적합니다.

운영 중 긴급 재부팅이 불가피하다면 최소한 화면 캡처, 핵심 지표 내보내기, 로그 복사 세 가지는 먼저 수행하는 편이 좋습니다. 서비스 복구가 우선인 상황에서도 3분 정도의 증거 수집 절차를 정해 두면 다음 장애에서 같은 추측을 반복하지 않게 됩니다. 복구 속도와 원인 분석은 경쟁 관계가 아니라 순서를 정해 함께 수행할 업무입니다.

서버 증설 전 네 가지 병목을 숫자로 확인합니다

CPU와 메모리만 보면 놓치는 지표가 많습니다

성능 모니터링을 시작할 때는 수십 개의 그래프보다 판단에 필요한 핵심 지표를 선정하는 것이 효과적입니다. CPU 사용률이 높다는 사실만으로는 부족합니다. 실제 작업이 많아 높은 것인지, 디스크나 네트워크 응답을 기다리느라 처리 대기열이 생긴 것인지 구분해야 합니다.

메모리도 사용률 80%라는 숫자 하나로 증설을 결정하면 안 됩니다. 운영체제가 남는 메모리를 캐시로 활용할 수 있기 때문에 ‘사용 중’이라는 표시가 곧 부족을 뜻하지는 않습니다. 사용 가능한 메모리가 계속 감소하는지, 스왑 입출력이 발생하는지, 특정 프로세스의 점유량이 시간에 따라 끝없이 증가하는지를 확인해야 합니다.

디지털 시스템을 구성하는 정보 처리 방식에 대한 다른 관점은 지식백과의 디지털 설명에서 확인할 수 있습니다. 실제 운영에서는 개별 부품의 사양보다 요청이 여러 구성 요소를 통과하며 소비하는 시간을 연결해서 보는 관점이 중요합니다.

비용은 도구보다 관찰 범위에서 달라집니다

소규모 환경은 운영체제 기본 지표와 오픈소스 모니터링 도구로도 시작할 수 있습니다. 다만 설치 비용이 없더라도 대시보드 구성, 알림 조정, 저장 공간, 담당자의 운영 시간이 필요합니다. 상용 서비스는 서버 수, 지표 보관 기간, 로그 수집량, 사용자 수에 따라 월 비용이 달라지므로 단순한 제품 가격보다 월간 데이터 수집량과 보관 정책을 먼저 계산해야 합니다.

예산이 제한적이라면 첫 달부터 모든 로그를 무기한 보관하지 마십시오. 핵심 성능 지표는 3개월 이상 추세를 볼 수 있게 남기고, 상세 로그는 14일 또는 30일처럼 장애 분석에 필요한 기간부터 설정할 수 있습니다. 개인정보나 인증 정보가 로그에 섞이지 않도록 마스킹 규칙과 접근 권한도 함께 정해야 합니다.

• 업무 시간의 평균 응답 시간과 95백분위 응답 시간을 함께 봅니다.
• 오류율은 전체 요청 대비 비율과 실제 오류 건수를 동시에 기록합니다.
• 서버 지표와 애플리케이션 요청 추적 정보를 같은 시간축에 배치합니다.
• 로그 보관 기간별 예상 저장량과 초과 과금 조건을 확인합니다.
• 알림 수신자는 담당자 한 명이 아니라 업무·개발·인프라 역할별로 지정합니다.

운영 원칙: 평균값이 정상이어도 일부 사용자는 심각한 지연을 겪을 수 있습니다. 평균 1초뿐 아니라 느린 요청 5%가 몇 초인지 보여 주는 95백분위 지표를 함께 확인하십시오.

알림 폭탄과 무음 장애 사이에서 기준을 조정합니다

임계값 하나보다 지속 시간과 영향도를 봅니다

모니터링 도구를 설치한 첫 주에는 알림이 너무 많이 오는 경우가 흔합니다. CPU가 1분 동안 80%를 넘을 때마다 메시지를 보내면 백업이나 보고서 생성 같은 정상 작업도 장애로 취급됩니다. 담당자가 의미 없는 알림에 익숙해지면 실제 장애 알림까지 무시하는 ‘알림 피로’가 생깁니다.

반대로 임계값을 지나치게 높이면 사용자는 이미 불편을 겪는데 운영팀은 정상으로 판단할 수 있습니다. CPU 95%만 감시하기보다 ‘결제 API 응답 시간이 5분 연속 3초 초과’처럼 사용자 영향이 드러나는 조건을 함께 설정해야 합니다. 업무의 중요도가 높은 기능일수록 더 짧은 지속 시간과 낮은 오류율을 기준으로 삼는 편이 적절합니다.

알림은 정보, 주의, 긴급의 세 단계로 나누면 대응이 쉬워집니다. 정보 단계는 다음 근무일에 추세를 검토하고, 주의 단계는 담당자가 원인을 확인하며, 긴급 단계는 즉시 복구 절차를 시작하도록 정합니다. 각 단계에 ‘누가, 몇 분 안에, 무엇을 확인할지’가 없다면 알림은 단순한 통계 메시지에 그칩니다.

• 정보: 디스크 사용량 70% 도달, 인증서 만료 30일 전처럼 계획 가능한 항목에 적용합니다.
• 주의: 응답 지연이 10분 지속되거나 오류율이 평소보다 두 배 증가한 상황에 적용합니다.
• 긴급: 핵심 서비스 접속 불가, 데이터베이스 연결 실패, 저장 공간 고갈 위험에 적용합니다.
• 복구 알림: 정상화 시점도 전송해 장애 지속 시간을 자동으로 계산합니다.

알림을 받은 뒤 볼 화면까지 설계합니다

‘CPU가 높습니다’라는 알림만 보내면 담당자는 여러 시스템을 열어 원인을 다시 찾아야 합니다. 알림 메시지에 대상 서버, 발생 시각, 현재 값, 정상 기준, 관련 대시보드 링크, 최근 배포 여부를 포함하면 초동 대응이 빨라집니다. 야간 담당자가 시스템을 잘 모르더라도 같은 순서로 확인할 수 있어야 합니다.

오탐은 매주 한 번 검토해 임계값을 수정하고, 한 번도 울리지 않는 알림은 실제 테스트로 동작 여부를 확인하십시오. 특히 메일이나 메신저 전송 경로가 끊기면 모니터링 화면에는 장애가 보이지만 담당자는 알 수 없습니다. 월 1회 테스트 알림을 보내 수신자, 전송 지연, 대체 연락 경로를 검증하는 절차가 필요합니다.

1. 알림이 실제 사용자 불편과 연결되는지 확인합니다.
2. 일시적 급증을 제외할 최소 지속 시간을 지정합니다.
3. 같은 원인의 알림은 하나의 사건으로 묶어 중복 전송을 줄입니다.
4. 담당자가 부재할 때 다음 수신자에게 전달되는 시간을 정합니다.
5. 복구 후에는 원인, 조치, 재발 방지 항목을 장애 기록에 남깁니다.

내일의 증설 회의 전에 15분 기준선을 만드십시오

도구 구매 없이 첫 측정부터 시작합니다

성능 관리의 첫 행동은 거대한 관제 화면을 만드는 일이 아닙니다. 지금 가장 불만이 많은 업무 기능 하나를 골라 정상 상태의 응답 시간을 측정하는 것입니다. 로그인, 고객 검색, 주문 저장처럼 직원이 매일 반복하는 동작 가운데 하나면 충분합니다.

먼저 오전의 한산한 시간과 오후의 바쁜 시간에 같은 동작을 각각 세 번 실행하십시오. 클릭 시각과 화면 완료 시각을 초 단위로 기록하고, 동시에 서버의 CPU·가용 메모리·디스크 여유 공간을 확인합니다. 가능하면 브라우저 개발자 도구의 네트워크 항목에서 가장 오래 걸린 요청도 적어 두십시오.

다음으로 최근 변경 사항을 나란히 기록합니다. 시스템 업데이트, 신규 사용자 증가, 대량 데이터 입력, 외부 서비스 변경, 백업 시간 조정처럼 느려지기 시작한 시점과 맞물리는 사건이 단서가 됩니다. 기술 담당자가 없더라도 ‘언제부터, 어느 기능이, 몇 초 느려졌는지’만 정확히 작성하면 외부 IT 서비스 업체에 훨씬 구체적으로 진단을 요청할 수 있습니다.

1. 직원 불만이 가장 많은 화면 하나를 선택합니다.
2. 한산한 시간과 혼잡한 시간의 응답 시간을 각각 세 번 잽니다.
3. 측정 시각의 CPU, 가용 메모리, 디스크 상태를 한 줄에 함께 적습니다.
4. 최근 30일 안에 있었던 배포, 데이터 증가, 연동 변경을 표시합니다.
5. 증설 견적을 받기 전에 ‘어떤 지표가 부족함을 증명하는가’를 공급업체에 질문합니다.

측정 결과 CPU와 메모리에 여유가 있는데 특정 요청만 늦다면 애플리케이션 또는 데이터베이스 진단을 먼저 진행하십시오. 여러 기능이 동시에 느리고 자원 포화가 업무 시간 내내 지속된다면 서버 증설의 근거가 생깁니다. 외부 API에서 대부분의 시간이 소비된다면 자사 서버를 키우는 대신 시간 초과 설정, 캐시, 비동기 처리, 공급사 응답 품질을 살펴야 합니다.

지금 바로 할 행동은 간단합니다. 메모장을 열고 ‘기능명·측정 시각·응답 시간·CPU·가용 메모리·최근 변경’ 여섯 칸을 만든 뒤, 가장 느린 화면을 세 번 실행해 숫자를 채우십시오. 이 15분짜리 기준선이 서버 증설과 성능 개선 가운데 어느 쪽에 예산을 써야 하는지 결정하는 첫 증거가 됩니다.