이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 배치 처리가 느리다는 말은 있었지만 어느 단계가 느린지 아무도 몰랐습니다. 다들 '전체적으로 느리다'고만 했습니다.
각 처리 단계 시작과 끝에 타임스탬프 로그를 심어서 단계별 소요 시간을 측정하였습니다. 결과를 보니 전처리 단계 하나가 전체 시간의 68%를 차지하고 있었습니다. 그 단계에서 루프 안에 정규식을 매번 컴파일하고 있었던 것이 원인이었고, 패턴 객체를 루프 밖에서 한 번만 만들도록 바꾸니 해당 단계가 9초에서 1.2초로 줄어들었습니다.
병목을 찾는 것이 추측이 아니라 측정에서 시작해야 한다는 것을 그 경험에서 배웠습니다. '여기가 느릴 것 같다'는 직관이 틀리는 경우가 더 많다는 것도 알게 되었습니다. 그 경험이 성능 문제를 대할 때 항상 먼저 측정하는 습관을 만들어주었습니다.
팀 프로젝트 중반에 특정 팀원이 맡은 부분이 다른 작업들의 시작을 막고 있었어요. 개발이 다 됐는데 그 한 모듈을 기다려야 했습니다.
의존성 관계를 그림으로 그려봤어요. 어떤 작업이 어느 작업을 기다리는지 시각화했더니 병목 지점이 한눈에 보였습니다. 그 팀원이 혼자 너무 많은 부분을 맡고 있었던 거였어요. 일부를 분리해서 다른 팀원이 함께 진행하도록 재분배하면서 전체 일정이 맞춰졌습니다.
팀원한테 미리 말했더라면 더 빨리 해결됐을 텐데 하는 아쉬움도 있었어요.
기술적 병목만이 아니라 팀 내 역할 분배도 병목이 될 수 있다는 걸 그때 배웠어요. 그리고 문제를 눈에 보이게 만드는 것만으로도 해결 방향이 보인다는 것도요. 그 경험이 프로젝트 상황을 가시화하는 걸 먼저 하는 습관을 만들어줬어요.
배포 후 특정 페이지만 로딩이 3초 이상 걸린다는 피드백이 들어왔어요. 다른 페이지는 빠른데 이상했습니다.
슬로우 쿼리 로그를 켰더니 해당 페이지의 API가 호출하는 쿼리 하나가 매번 2.8초를 소비하고 있었어요. 실행 계획을 보니 풀 테이블 스캔이 발생하고 있었고, 조회 조건으로 쓰는 컬럼에 인덱스가 없었습니다. 인덱스를 추가하니 해당 쿼리가 2.8초에서 0.05초로 줄었어요.
그 경험에서 느린 건 대부분 DB에서 온다는 걸 배웠어요. 코드를 최적화하기 전에 쿼리와 인덱스를 먼저 보는 게 맞는 순서라는 것도요. 지금도 API가 느리다는 신호가 오면 제일 먼저 쿼리 실행 계획을 확인합니다. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.