이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
배포 후에 특정 조건에서만 계산 결과가 달라지는 버그가 발생했는데, 어디서 값이 틀어지는지 처음에는 감이 오지 않았습니다.
우선 문제가 발생하는 최소 조건을 찾는 것을 먼저 진행했습니다. 입력값을 하나씩 바꿔가면서 어떤 조건에서 오류가 발생하는지 범위를 좁혔고, 결국 소수점 아래 값을 넣을 때만 문제가 생긴다는 것을 확인했습니다. 그 조건을 재현하고 나서야 코드의 반올림 로직이 의도와 다르게 동작한다는 것을 발견했습니다.
'전체에서 부분으로'라는 흐름이 이슈 분석에서 가장 효율적이라는 것을 그 경험에서 배웠습니다. 전체를 동시에 보면 어디가 문제인지 알 수 없고, 재현 조건을 좁혀야 원인이 보입니다. 지금도 버그를 만나면 먼저 '이게 항상 일어나는가, 아니면 특정 조건에서만 발생하는가'를 구분하는 것부터 시작합니다.
그 경험이 디버깅 접근 방식을 체계화해주었습니다.
운영 중인 서비스에서 간헐적으로 데이터가 빠지는 이슈가 있었는데, 에러 로그가 남지 않아서 원인을 찾기가 어려웠어요.
에러 없이 데이터가 빠진다는 건 예외가 아니라 조건 분기에서 의도치 않은 경로로 빠진 것이라고 가설을 세웠어요. 의심되는 분기 지점마다 로그를 추가하고, 다음 발생 시 로그를 수집했습니다. 로그를 보니 특정 상태값이 null일 때 else 분기로 들어가면서 저장 단계를 건너뛰는 케이스가 있었어요.
그 이후로 로그가 없으면 분석이 어렵다는 걸 기본 원칙으로 삼고, 중요한 분기 지점엔 항상 로그를 남기게 됐어요. 재현이 어려운 이슈일수록 '다음 발생 때 잡겠다'는 준비를 미리 해두는 게 낫다는 걸 배웠습니다. 그 실패가 로그 습관을 만들어줬어요.
'운영에서만 에러가 난다'는 버그를 처음 받았을 때 로컬에서 아무리 해봐도 재현이 안 됐어요. 코드는 같은데 왜 다른지 감이 안 왔습니다.
로컬과 운영 환경의 차이를 목록으로 만들어봤어요. 환경 변수 값, 라이브러리 버전, DB 데이터 상태 이렇게 세 축으로 나눠서 하나씩 맞춰봤습니다. 라이브러리 버전을 맞추니까 로컬에서도 재현이 됐어요. 특정 버전에서 동작이 바뀐 부분이 있었고, 운영 서버만 구 버전이었던 거였습니다.
그 경험에서 '로컬에서 안 된다'는 건 '버그가 없다'가 아니라 '환경이 다르다'는 신호일 수 있다는 걸 배웠어요. 환경 정규화가 재현의 전제 조건이라는 걸 그때 처음 체감했습니다. 이 과정에서 얻은 인사이트는 지금도 제 디버깅 방식에 영향을 주고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.