우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›네이버›시스템 운영›질문 상세
    問
    네네이버시스템 운영상황·판단2026년 출제

    Linux 서버에서 CPU 사용률이 갑자기 100%로 치솟았을 때, 본인은 어떤 명령어와 순서로 원인을 분석하시겠습니까?

    답변 미리보기

    CPU 사용률이 100%로 치솟으면 먼저 top 명령어로 어떤 프로세스가 CPU를 잡아먹고 있는지 확인합니다. PID와 함께 CPU 점유율이 높은 프로세스를…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    문제 해결 접근법은 어떤가?
    문제 해결을 위한 접근법을 정리한 흔적이 답에 있어야 합니다. 없으면 면접관이 '왜 그 순서로 진행했나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    사용할 명령어는 무엇인가?
    문제를 분석하기 위해 사용할 명령어의 목록이 답에 있어야 합니다. 없으면 면접관이 '왜 그 명령어를 선택했나요?' 같은 질문을 던지는 자리가 자주 보입니다.
    語
    03
    원인 분석 결과는 어떻게 도출하나?
    원인 분석 결과를 도출하는 방식의 흔적이 답에 있어야 합니다. 없으면 면접관이 '결과적으로 무엇을 발견했나요?'를 추가로 묻는 경우가 많습니다.
    本
    04
    문제 발생 후 조치는 어떤가?
    문제 발생 후 취할 조치에 대한 언급이 답에 있어야 합니다. 없으면 면접관이 '어떤 방법으로 문제를 해결할 건가요?'를 추가로 묻는 경우가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    네이버 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    CPU 100% 상황에서 체계적인 명령어 순서로 원인을 좁혀가는 방법 서술약 90초명령어로 프로세스 확인 후 로그와 연결해 근본 원인 추적하는 방식약 88초하드웨어·OS·애플리케이션 레이어를 순서대로 격리해 원인 범위를 좁히는 방식약 86초
    프로세스 기반 분석 접근
    약 90초

    CPU 100% 상황에서 체계적인 명령어 순서로 원인을 좁혀가는 방법 서술

    CPU 사용률이 100%로 치솟으면 먼저 top 명령어로 어떤 프로세스가 CPU를 잡아먹고 있는지 확인합니다. PID와 함께 CPU 점유율이 높은 프로세스를 식별하는 것이 출발점입니다.

    특정 프로세스가 원인이라면 ps aux | grep [PID]로 해당 프로세스의 상세 정보를 보고, strace -p [PID]로 어떤 시스템 콜을 반복하는지 추적합니다. 여러 프로세스가 동시에 높은 경우에는 커널 영역에 문제가 있는 경우도 있어서 vmstat으로 컨텍스트 스위치나 인터럽트 수치도 확인합니다.

    실습 환경에서 의도적으로 무한 루프를 돌리는 스크립트로 실험해본 경험이 있습니다. top으로 프로세스를 잡고 kill -9로 종료하는 과정을 직접 해보았습니다. 이론으로만 알던 것과 실제로 명령어를 입력해보는 것은 체감이 다르다는 것을 느꼈습니다. 실제 운영 환경에서는 종료 전에 스냅샷을 남기는 것이 중요하다는 것도 그때 배웠습니다.

    이 결의 특징
    문제의 증상을 보는 도구(top)부터 원인 추적 도구(strace, vmstat)까지의 계층 흐름이 명확합니다. 단계적 격리를 통해 범위를 좁혀가는 체계성이 관찰됩니다.
    이 결이 통하는 자리
    복잡한 시스템을 운영하는 조직에서 신뢰를 얻습니다. 즉흥적 해결이 아니라 근본 원인까지 찾는 문화가 있는 팀에서 이 체계적 접근이 평가됩니다.
    로그 연계 분석 접근
    약 88초

    명령어로 프로세스 확인 후 로그와 연결해 근본 원인 추적하는 방식

    CPU가 100%면 먼저 `top` 또는 `htop`으로 어떤 프로세스가 원인인지 파악하고, 해당 프로세스의 로그를 확인하는 순서로 접근해요. 프로세스를 찾는 것만으로는 '왜' 그렇게 된 건지 알기 어렵거든요.

    수업 프로젝트에서 서버가 갑자기 느려지는 문제를 진단해보는 실습을 했는데, top에서 웹 서버 프로세스가 CPU를 80% 이상 쓰고 있었어요. 로그를 보니 특정 엔드포인트로 반복 요청이 쏟아지고 있었고, 그게 CPU를 올린 거였습니다.

    근본 원인이 코드 문제인지 외부 공격인지에 따라 대응이 달라져요. 해당 실습에서는 코드 내 무거운 쿼리가 반복된 거였고, 캐싱으로 해결했어요. 명령어는 증상을 보여주는 도구고, 로그가 원인을 알려주는 단서라는 걸 그때 처음 체감했습니다.

    이 결의 특징
    명령어만으로는 부족하고 로그를 통해 '왜'를 추적하는 습관입니다. 증상과 로그를 연결하는 이중 검증 방식이 관찰됩니다.
    이 결이 통하는 자리
    인프라 신뢰도가 중요한 결제나 거래 시스템 팀에서 통합니다. 표면 증상만이 아니라 비즈니스 맥락(코드 버그 vs 외부 공격)까지 포함해 진단하는 능력이 필요한 자리에서 값어치 있습니다.
    체계적 격리 분석 접근
    약 86초

    하드웨어·OS·애플리케이션 레이어를 순서대로 격리해 원인 범위를 좁히는 방식

    CPU 100% 문제는 레이어를 순서대로 격리해서 보는 게 효과적이에요. 먼저 top으로 프로세스 목록을 보고, 커널 프로세스가 원인인지 사용자 프로세스인지부터 구분합니다.

    사용자 프로세스가 원인이면 해당 PID를 lsof -p [PID]로 어떤 파일·소켓을 열고 있는지 확인하고, 필요하면 perf top으로 어떤 함수가 CPU를 많이 쓰는지까지 봐요. 커널 영역이 문제라면 하드웨어 인터럽트 급증을 보기 위해 `cat /proc/interrupts`를 쓰기도 합니다.

    이 과정을 처음 배울 때 명령어를 외우는 게 아니라 '왜 이 명령어를 쓰는가'를 이해하는 게 중요하다는 걸 느꼈어요. 명령어 하나하나가 어떤 계층 정보를 보는지 알면 처음 보는 문제에서도 어디서부터 봐야 할지 방향이 잡혀요. 그게 진단 능력의 핵심이라고 생각합니다.

    이 결의 특징
    문제를 하드웨어·OS·애플리케이션 레이어로 격리하는 아키텍처 사고입니다. 명령어를 외우기보다 각 계층이 무엇을 보는 도구인지 이해하려는 접근이 있습니다.
    이 결이 통하는 자리
    새로운 장비나 낯선 시스템의 문제를 수동으로 진단해야 하는 환경에서 강점을 발휘합니다. 레이어 사고방식이 있으면 문서가 부족해도 스스로 원인을 찾을 수 있다는 신뢰를 얻습니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹문제를 해결하기 위해 어떤 로그를 확인하시겠어요?
    貳CPU 사용률이 높은 프로세스를 어떻게 확인하나요?
    參만약 모든 방법을 시도했는데도 해결되지 않았다면 어떻게 하시겠어요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 네이버 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    토스 · 인프라/클라우드
    Linux 시스템 관리에서 로그 및 성능 분석을 어떻게 접근하셨나요?
    이 질문 보기
    HL그룹 · SW·IT 일반
    Linux 기본 명령어를 사용해본 경험이 있다면, 어떤 명령어를 주로 사용했나요?
    이 질문 보기
    배달의민족(우아한형제들) · 백엔드
    Linux/Unix 명령어를 사용하여 문제를 해결한 경험이 있나요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 네이버 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기