이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 게시글 목록 API가 데이터가 늘수록 눈에 띄게 느려지는 현상이 생겼습니다. 처음엔 서버 자원이 부족한 줄 알았는데 EXPLAIN ANALYZE로 쿼리 실행 계획을 보니 정렬 단계에서 인덱스가 전혀 안 쓰이고 있었습니다. created_at 컬럼에 단독 인덱스가 있었는데, WHERE 조건 컬럼의 카디널리티가 낮아 옵티마이저가 시퀀셜 스캔을 선택하고 있었습니다. 복합 인덱스로 교체하고 쿼리를 조정했더니 응답 시간이 약 1.2초에서 120ms 수준으로 줄었습니다.
이후로 성능 문제는 추측보다 계측 도구를 먼저 쓰는 순서로 접근하는 습관이 생겼고, 느리다고 느끼는 순간 곧바로 프로파일링부터 켜는 것이 지금의 루틴이 됐습니다.
병목을 혼자 찾다 막혔을 때 동료의 코드 리뷰 질문이 돌파구가 됐습니다. 특정 API가 느린데 로그나 메트릭으로 원인을 특정하지 못하고 있었습니다. PR 리뷰에서 동료가 이 부분에서 루프마다 DB 조회가 일어나는 거 아닌가 라고 물어봤는데, 그 질문이 N+1 문제라는 단서를 줬습니다. 코드를 다시 보니 ORM이 연관 데이터를 건별로 쿼리하는 구조였고, Eager Loading으로 한 번에 가져오도록 바꾸니 쿼리 수가 수십 개에서 2개로 줄었습니다. 혼자 보고 있으면 익숙해져서 눈에 안 띄는 것이 다른 사람의 시각으로는 바로 보이는 결이 있었습니다.
코드 리뷰는 버그를 찾는 것만이 아니라 병목을 함께 발견하는 결이라는 것을 이 경험에서 배웠습니다.
병목을 한 번 발견한 뒤 같은 유형의 문제가 다른 곳에서 또 생겼습니다. 매번 처음부터 원인을 찾는 것이 비효율적이라고 느꼈습니다. 병목 유형별 진단 체크리스트를 만들었습니다. 느린 쿼리는 EXPLAIN ANALYZE, 메모리 누수는 힙 스냅샷, 응답 시간 증가는 이벤트 루프 지연과 미들웨어 타이밍 로그를 확인하는 순서로 정리했습니다.
이 체크리스트를 팀에 공유했더니 다른 팀원도 비슷한 문제를 만났을 때 직접 원인을 찾아오는 경우가 늘었습니다. 병목은 한 번 찾으면 끝이 아니라 유사 패턴이 반복될 수 있어서, 발견 절차를 재사용 가능한 형태로 남기는 것이 팀 전체 생산성을 높이는 결이었습니다. 문제를 잘 푸는 것과 그 풀이를 절차로 남기는 것은 다른 결이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근서비스 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.