이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 실습에서 리눅스 서버에서 간헐적으로 프로세스가 죽는 문제를 처음 직접 분석해봤습니다. 처음에는 원인이 보이지 않았는데, dmesg와 /var/log/syslog를 함께 확인하면서 OOM killer가 메모리 부족으로 프로세스를 강제 종료하는 로그를 발견했습니다. 원인을 파악하고 나서 메모리 사용량을 코드 레벨에서 프로파일링해보니, 특정 조건에서 대량의 데이터를 한 번에 메모리에 올리는 로직이 있었습니다. 데이터를 스트리밍 방식으로 나눠서 처리하도록 수정했더니 메모리 피크가 줄었습니다. 이 과정에서 단순히 서버 메모리를 늘리기보다 코드 구조를 먼저 보는 것이 더 근본적인 해결이라는 걸 배웠습니다.
리눅스 로그는 증상을 기록하는 게 아니라 원인을 찾는 시작점이라는 걸 그때 알았습니다.
리눅스 서버에서 특정 시간대에 CPU 점유율이 90%를 넘어 서비스 응답이 느려지는 문제를 맡아 분석해봤습니다. top으로 프로세스별 CPU 사용량을 보니 백그라운드 배치 작업이 범인이었는데, 단순히 cron 스케줄을 피크 시간 밖으로 옮기는 것만으로 해결될 것 같았습니다. 하지만 스케줄을 바꿔도 비슷한 증상이 재발했습니다.
더 깊이 보려고 strace -p로 해당 프로세스의 시스템 콜을 추적하니, 파일을 1바이트씩 수천 번 읽는 패턴이 반복됐습니다. 원인은 버퍼링 없이 open·read를 반복하는 코드 구조였습니다. 읽기를 버퍼 단위로 묶으니 CPU 사용이 크게 줄었습니다.
이 경험 이후 같은 문제가 다시 오지 않도록 CPU 사용률 임계값 알람을 설정하고, 분석 과정을 팀 위키에 기록해두었습니다. 다음에 비슷한 증상이 왔을 때 절반 시간 만에 원인을 좁혔습니다.
인턴 중에 특정 엔드포인트에서만 응답 시간이 간헐적으로 1초 이상 걸리는 현상을 분석해봤습니다. 처음엔 코드 로직 문제로 생각했는데, 애플리케이션 로그에는 해당 시간에 아무것도 찍히지 않았습니다. 네트워크 레이어를 살펴봐야 한다는 걸 처음으로 의식한 순간이었습니다.
ss -tn으로 연결 상태를 확인하니 CLOSE_WAIT 상태의 소켓이 쌓이는 것이 보였습니다. tcpdump로 패킷을 잡아 타임스탬프를 분석하니, 요청 도착 후 ACK 사이에 이상한 지연이 있었고, TCP Nagle 알고리즘이 작은 패킷을 모아 보내는 것이 원인이었습니다.
TCP_NODELAY 옵션을 적용하니 지연이 사라졌습니다.
이 경험으로 응답 지연은 코드에서 시작하지 않을 수 있고, 네트워크를 패킷 수준에서 봐야 원인이 보이는 자리가 있다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.