이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
특정 API에서 간헐적으로 500 오류가 발생한다는 이슈를 받았을 때, 가장 먼저 한 건 에러 로그를 타임스탬프 기준으로 정렬하는 것이었습니다. ELK 스택으로 로그를 집계해 오류가 몰리는 시간대를 찾았고, 특정 시간에만 발생하는 패턴이 보였습니다. 같은 시간대 DB 슬로우 쿼리 로그를 함께 분석하니 특정 세션이 잠금을 오래 잡고 있는 케이스가 연결됐습니다.
EXPLAIN ANALYZE로 실행 계획을 보니 인덱스 미사용으로 풀 스캔이 일어나고 있었고, 인덱스 추가 후 오류가 사라졌습니다. 로그와 DB 지표를 함께 봐야 원인을 정확히 짚을 수 있다는 걸 그 경험으로 배웠습니다.
운영에서 간헐적인 오류가 발생했을 때 로그를 분석하려 했는데 필요한 정보가 로그에 남아 있지 않아서 원인 파악에 시간이 더 걸린 경험이 있습니다. 오류 메시지는 남아 있었는데, 그 오류가 어떤 입력값에서 발생했는지나 어떤 흐름을 거쳤는지가 기록되지 않아서 재현을 위한 조건을 찾는 데 어려움이 있었습니다. 개발할 때는 로그에 어떤 정보를 남길지를 꼼꼼히 생각하지 않았는데, 실제로 문제가 생겼을 때 로그가 진단에 얼마나 중요한지를 직접 경험했습니다. 이후에는 요청 처리 시 입력값의 핵심 정보와 처리 단계를 함께 기록하는 방식으로 바꿨습니다. 로그는 남기는 것 자체가 목적이 아니라 문제가 생겼을 때 원인을 찾을 수 있는 정보를 담는 것이 중요하고, 어떤 정보가 진단에 필요한지를 개발 단계에서 미리 생각해야 한다는 것을 이 경험에서 배웠습니다.
SQL 분석으로 성능 문제의 원인을 찾았다고 생각했는데, 수정 후에도 문제가 재현된 경험이 있습니다. 슬로우 쿼리 로그에서 특정 쿼리의 실행 시간이 길었는데 인덱스를 추가하고 나서도 간헐적으로 같은 현상이 발생했습니다. 다시 분석해보니 슬로우 쿼리는 결과였고 실제 원인은 특정 시간대에 트래픽이 집중되면서 DB 연결 풀이 소진되는 것이었습니다. 처음에 보이는 지표만으로 원인을 단정했던 것이 문제였는데, 증상과 원인을 구분하는 것이 얼마나 중요한지를 이 경험에서 배웠습니다. SQL과 로그 분석에서 찾은 것을 가설로 두고 그것이 실제로 유일한 원인인지를 다른 지표와 함께 교차 확인하는 것이 분석의 신뢰도를 높이는 방법이라는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.