이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
버그를 발견하면 제가 먼저 하는 것은 재현 조건을 최소화하는 작업입니다. 어떤 입력이 문제를 일으키는지, 어떤 환경에서만 발생하는지를 좁혀두면 추측 없이 원인을 향해 좁혀갈 수 있습니다.
원인 파악에는 로그를 주로 활용했습니다. 에러 발생 시점 전후 컨텍스트를 보면 어느 단계에서 값이 바뀌는지 추적할 수 있었습니다. 로그가 없는 구간에서는 디버거로 브레이크포인트를 설정해 상태를 직접 확인했습니다.
수정 후에는 동일 버그가 다시 발생하지 않도록 재현 케이스를 테스트로 추가했습니다. 버그 하나가 한 줄 테스트로 기록되면 이후 리팩터링 시에도 그 경계 조건을 실수로 깨뜨리는 상황을 막을 수 있었습니다. 이 습관이 쌓이면서 코드베이스에 대한 신뢰도도 높아졌습니다.
로그와 디버거로는 여러 서비스가 얽힌 버그를 추적하기 어렵다는 한계를 경험했습니다. 단일 서비스에서는 로그를 따라가면 원인을 찾을 수 있었는데, 마이크로서비스 환경에서 오류가 생기니 어느 서비스에서 시작됐는지 알 수가 없었습니다. 이때 분산 추적 도구(OpenTelemetry)를 처음 접했는데, 요청이 여러 서비스를 거치는 흐름을 하나의 트레이스로 연결해 어느 구간에서 지연이 생기는지 파악할 수 있었습니다. 이진 탐색 방법도 배웠는데, 커밋 히스토리에서 버그가 없던 커밋과 있는 커밋 사이를 반씩 좁혀가는 git bisect로 버그가 처음 생긴 커밋을 찾은 경험이 있습니다. 한계로는 재현이 안 되는 버그는 어떤 도구도 완벽하지 않다는 것입니다. 타이밍 의존 버그나 환경 의존 버그는 로그를 최대한 촘촘하게 남기는 것 외에 뾰족한 방법이 없었습니다.
디버깅 도구의 한계를 아는 것이 어떤 버그는 사전 계측으로만 잡을 수 있다는 인식을 만든다는 것을 배웠습니다.
처음에는 버그를 만나면 코드를 보면서 원인이 될 것 같은 부분을 수정하다가 원인 파악 없이 우연히 고치는 방식이었습니다. 이 방식의 문제는 같은 버그가 다른 형태로 다시 나타나는 경우가 많다는 것이었습니다. 이후 가설을 먼저 세우고 검증하는 방식으로 바꿨습니다. 증상을 보고 원인 후보를 좁힌 뒤, 각 후보를 빠르게 검증할 수 있는 방법을 찾는 순서로 접근했습니다. 시스템 콜 레벨에서 파일 접근이나 네트워크 호출이 어떻게 이뤄지는지 볼 때는 strace를 써봤는데, 애플리케이션이 예상한 파일을 열고 있는지를 코드 외부에서 확인할 수 있었습니다.
코드를 바꾸지 않고도 동작을 관측할 수 있다는 것이 유용했습니다. 한계는 strace 자체가 성능에 영향을 줘서 운영 환경에는 쓰기 어렵다는 점입니다. 디버깅은 추측이 아니라 관측 가능한 증거를 쌓아가며 원인을 좁히는 과정이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에피드게임즈 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.