이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 특정 사용자만 로그인이 안 되는 버그를 맡았습니다. 처음엔 '로그인 기능이 왜 안 되지?'라는 질문으로 인증 코드를 계속 뒤졌는데 원인이 안 나왔습니다.
두 시간을 헤매다가 '어떤 사용자에게만 발생하는가'로 질문을 바꿨습니다. 패턴을 보니 이메일에 특수문자가 있는 사용자에게만 나타났습니다. 문제를 '로그인 실패'에서 '특수문자 입력값 처리 누락'으로 재정의하니 원인이 5분 만에 나왔습니다.
URL 인코딩 처리가 빠진 것이었고, 한 줄 수정으로 해결됐습니다. 두 시간 동안 엉뚱한 범위를 본 실패였습니다. 이후로 버그를 잡을 때 어떤 조건에서만 발생하는가를 먼저 좁히는 것이 문제 재정의의 시작이라는 걸 배웠습니다.
졸업 작품에서 SNS 플랫폼을 만들려고 시작했는데, 팀원들의 기능 요청이 계속 추가돼 2개월이 지나도 완성이 안 됐습니다. 이대로는 마감을 못 맞추겠다고 판단했습니다.
팀에 '완성하지 못한 10개 기능보다 완성된 3개 기능이 낫다'고 설득했습니다. 핵심 흐름 — 가입, 글 작성, 피드 조회 — 3개로 범위를 재정의하고 나머지는 미구현으로 문서화하기로 했습니다. 팀원 한 명이 처음엔 기능을 빼는 것에 불만을 표했지만 데모 때 완성도를 보고 나서 동의했습니다.
그 경험에서 경계를 설정하는 것이 기능을 더 하는 것만큼 중요한 결정이라는 걸 배웠습니다. 무엇을 하지 않을지 결정하는 것이 프로젝트를 끝내는 핵심이라는 것이 지금도 제 기준입니다.
인턴 때 '서비스가 느리다'는 문의를 받았는데, 어디가 느린지 아무 단서도 없었습니다. 전체 API를 하나씩 보려면 몇 날이 걸릴 것 같아서, 먼저 범위를 좁히는 것부터 시작했습니다.
사용자에게 어떤 화면에서 느린지 다시 물었고, 그 화면의 API 호출 로그를 확인했습니다. 특정 조회 API만 평균 3초가 나왔습니다. '서비스 전체'에서 '이 API 하나'로 문제를 재정의하니 원인 파악이 30분 안에 됐습니다.
인덱스 없는 컬럼으로 정렬하고 있었던 것이 원인이었고, 인덱스 추가 후 80ms로 줄었습니다. 막연한 문제일수록 질문을 바꿔서 범위부터 좁혀야 한다는 걸 그때 배웠습니다. 문제를 재정의하는 것이 해결의 절반이라는 것이 지금도 제 디버깅 원칙입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.