이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 중 서비스 응답이 특정 시간대에 느려지는 문제를 분석하면서 서버 리소스 프로파일링을 처음 제대로 해봤습니다. top이나 vmstat 같은 기본 도구로 CPU·메모리·I/O 사용 패턴을 시간축으로 기록하는 방식으로 전환했는데, 병목이 CPU 바운드인지 I/O 바운드인지를 먼저 구분하는 게 해결 방향을 정하는 데 중요했습니다. 애플리케이션 레벨에서는 py-spy로 Python 프로세스의 핫 경로를 시각화했더니 함수 호출 스택에서 예상 외 위치가 시간을 잡아먹고 있었습니다. 배치 작업이 실행될 때 DB 연결 풀이 고갈되는 패턴이 원인이었는데, 프로파일링 데이터가 없었다면 추측으로만 접근했을 겁니다. 이 경험에서 성능 문제는 계측 데이터를 먼저 쌓고 좁혀가는 순서가 훨씬 효율적이라는 걸 배웠습니다.
서버 프로파일링을 할수록 단일 서비스 내부만 보는 도구로는 근본 원인을 찾기 어려운 경우가 있다는 것을 느꼈습니다. py-spy로 핫 경로를 찾아도 다른 서비스에 의존하는 지점에서 왜 느린지는 알 수가 없었습니다. 이 한계를 인식한 이후 APM(애플리케이션 성능 모니터링)의 분산 추적 기능을 공부하게 됐습니다. 서비스 A가 B를 호출하고 B가 DB를 조회하는 흐름에서 p99 응답 시간이 어느 구간에서 올라가는지를 전체 요청 추적으로 파악할 수 있다는 것이 단일 프로파일러와 다른 점이었습니다. 도구를 어느 맥락에서 쓰는지가 중요하다는 것도 배웠는데, 개발 단계에서는 py-spy로 특정 함수의 핫 경로를 찾고, 운영 단계에서는 분산 추적으로 서비스 간 병목을 파악하는 것이 더 실용적이었습니다.
프로파일링 도구의 한계를 아는 것이 도구를 잘 쓰는 것만큼 중요하다는 것을 이 경험에서 배웠습니다.
서버 성능 최적화 과정에서 사용하는 언어나 도구가 달라져도 접근법이 같다는 것을 느꼈습니다. CPU 사용률이 높으면 핫 경로를 찾고, 메모리가 올라가면 할당 패턴을 추적하고, 응답이 느리면 I/O 대기 여부를 확인하는 순서는 Go를 프로파일링할 때나 Python을 프로파일링할 때나 동일했습니다.
플레임 그래프는 도구에 관계없이 공통으로 사용하는 시각화 방식인데, 호출 스택별 소요 시간을 한눈에 보여줘서 어디서 시간을 잡아먹는지를 직관적으로 파악할 수 있었습니다. Go의 pprof와 Python의 py-spy 모두 플레임 그래프를 출력할 수 있어서, 언어가 바뀌어도 분석 흐름이 동일하다는 것을 이때 이해했습니다. 추측 기반 최적화의 위험도 직접 겪었습니다. 데이터 없이 느릴 것 같은 부분을 먼저 고쳤다가 실제 병목과 달랐던 적이 있었습니다.
계측 데이터로 병목을 확인한 뒤 최적화하는 원칙은 어떤 도구나 언어를 써도 변하지 않습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.