이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
본인의 디버깅 결은 추측을 멈추고 재현을 먼저 고정하는 일에서 시작합니다.
프론트엔드 버그는 간헐적이라 재현이 안 되는 자리가 가장 어렵습니다. 그래서 본인은 버그가 난 순간의 상태와 입력을 그대로 기록해 재현 케이스로 고정하는 방식을 씁니다. 한 번은 특정 사용자만 화면이 깨지는 자리가 있었는데, 그 사용자의 상태를 재현 케이스로 박아 보니 오래된 캐시 데이터가 새 화면 코드와 충돌하는 자리였습니다. 추측만으로는 며칠 헤맸을 자리가 재현을 고정하자 반나절 만에 좁혀졌습니다.
이 방식이 팀에도 통할 것 같아, 버그 리포트 양식에 재현 상태를 함께 남기는 칸을 제안했습니다. 그 뒤로 재현 안 되는 버그를 두고 도는 회의가 줄었습니다.
본인은 디버깅을 감이 아니라 재현을 고정하는 일로 보고 있습니다.
본인의 디버깅 결은 문제 범위를 절반씩 잘라 좁히는 일입니다.
복잡한 화면에서 버그가 나면, 어디가 원인인지 막막한 자리가 많습니다. 그때 본인은 의심 구간을 절반으로 나눠 한쪽을 꺼보고, 증상이 사라지는 쪽으로 다시 좁힙니다. 한 번은 상태가 꼬여 화면이 멈추는 자리에서, 이 방식으로 세 번 만에 특정 전역 상태 갱신이 원인임을 좁힌 적이 있습니다.
그 자리에서 처음부터 코드를 읽어 내려가는 것보다, 증상으로 범위를 자르는 게 훨씬 빠르다는 걸 체감했습니다. 이 방식을 신입 팀원에게 디버깅할 때 코드부터 읽지 말고 범위부터 자르라고 공유했고, 그 뒤 그 팀원의 버그 처리 속도가 눈에 띄게 빨라졌습니다.
본인의 디버깅 결은 브라우저 도구를 그냥 쓰는 게 아니라, 반복되는 자리를 도구로 고정하는 일입니다.
같은 류의 버그를 매번 손으로 추적하는 게 비효율이라, 본인은 자주 보는 상태를 한눈에 띄우는 작은 디버그 패널을 직접 붙여 씁니다. 한 번은 결제 흐름에서 상태가 어디서 어긋나는지를 그 패널로 단계별 상태를 한 화면에서 비교해 빠르게 찾은 적이 있습니다.
이게 본인만 쓰면 의미가 적을 것 같아, 팀 공통 디버그 패널로 정리해 공유했습니다. 그 뒤 비슷한 상태 버그가 나면 팀원들이 그 패널부터 켜는 자리가 됐습니다.
본인은 디버깅 역량을 한 번 겪은 자리를 다음엔 도구로 빨리 보게 만드는 일로 보고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스뱅크 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.