LabHub

디버깅 실전 · 증상에서 원인으로 · 퀴즈

퀴즈: 증상에서 원인으로

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 필수 파라미터가 빠진 요청에 500 을 반환하면 무엇이 잘못됩니까?

    1. 5xx 로그가 지저분하게 쌓인다
    2. 오류 처리 때문에 응답이 느려진다
    3. 브라우저가 5xx 응답을 캐시하지 못하게 된다
    4. 클라이언트가 5xx 를 재시도 대상으로 보고 영원히 실패할 요청을 반복한다
  2. 고객사 코드에서 가장 발견이 늦어지는 결함 유형은?

    1. 200 과 함께 그럴듯한 틀린 값을 반환하는 코드
    2. 기동 시 즉시 죽는 코드
    3. 예외를 던지고 500 을 반환하는 코드
    4. 메모리를 많이 쓰는 코드
  3. 문서와 코드의 동작이 다릅니다. 올바른 태도는?

    1. 문서에 적힌 것을 사실로 믿고 코드 쪽을 고친다
    2. 코드를 사실로 믿고 문서 쪽을 고친다
    3. 관측된 동작을 사실로 삼되, 문서와 어긋나는 지점을 버그 후보 목록으로 쓴다
    4. 둘 다 폐기하고 처음부터 새로 만든다
  4. 평균을 구하는 함수가 원소 세 개일 때는 맞고 한 개일 때 틀립니다. 가장 유력한 원인은?

    1. 나누는 수가 원소 개수와 어긋나 있다
    2. 부동소수점 오차
    3. 정렬이 빠졌다
    4. 입력 파싱이 잘못됐다
  5. 배치 스크립트가 어느 날부터 실패합니다. 고객은 '데이터가 늘어서' 라고 말합니다. 가장 먼저 확인할 것은?

    1. 배치를 돌리는 서버의 메모리 사용량
    2. 남아 있는 디스크 용량
    3. 새로 들어온 데이터에 지금까지 없던 형태의 행이 섞였는지
    4. 스크립트 실행 시간 추이
  6. 고객이 틀린 원인을 확신하고 있습니다. 가장 좋은 대응은?

    1. 명확히 아니라고 정정한다
    2. 검증 목록에 넣고 함께 확인해 본다
    3. 일단 동의하고 넘어간다
    4. 근거 자료를 만들어 반박한다