クイズ: 混在した形式を1レコードにまとめる

자바 애플리케이션 로그에서 grep -c ERROR 로 오류 건수를 셌더니 실제 사건보다 훨씬 많았다. 가장 그럴듯한 원인은?

• 예외의 스택트레이스가 여러 줄이라 사건 한 건이 여러 줄로 세어졌다
• grep 이 대소문자를 구별하지 않아 error 가 포함된 정상 로그까지 셌다
• 로그 회전이 일어나 같은 줄이 두 파일에 중복으로 남았다
• 로그 수준이 DEBUG 로 내려가 평소에 안 찍히던 줄이 섞였다

정규화한 모든 시각을 2026-03-05T05:22:31.118Z 처럼 UTC · 밀리초 세 자리 · Z 로 굳혔다. RFC 3339 가 설명하는 이 표기의 실용적 이점은?

• 문자열 길이가 짧아져 저장 공간이 줄어든다
• 오프셋과 소수 자릿수가 같으면 문자열 정렬이 곧 시간순 정렬이 된다
• 윤초가 자동으로 보정되어 시각 차이가 사라진다
• 사람이 읽을 때 지역 시각으로 자동 변환되어 보인다

정규화 결과를 통짜 JSON 배열 하나가 아니라 NDJSON(한 줄에 객체 하나)으로 내보내는 이유로 가장 알맞은 것은?

• JSON 배열은 한글을 담을 수 없어 인코딩 오류가 난다
• NDJSON 은 객체마다 스키마를 다르게 쓸 수 있어 검증이 필요 없다
• 줄 단위 도구와 스트리밍이 그대로 통해 큰 파일을 끝까지 읽지 않아도 된다
• NDJSON 은 압축률이 높아 같은 내용이 훨씬 작은 파일이 된다

syslog 줄의 머리가 <134> 였다. RFC 5424 에 따라 facility 와 severity 를 구하면?

• facility 134, severity 0 — PRI 전체가 facility 이고 severity 는 따로 온다
• facility 8, severity 6 — PRI 를 16으로 나눈 몫과 나머지다
• facility 13, severity 4 — 앞 두 자리와 마지막 자리를 나눠 읽는다
• facility 16, severity 6 — PRI 를 8로 나눈 몫과 나머지다

파서가 읽지 못한 줄을 continue 로 건너뛰는 구현이 있다. 실무에서 이것이 위험한 이유는?

• 건너뛴 줄이 다음 레코드에 붙어 내용이 뒤섞인다
• 손실이 어디에도 기록되지 않아, 나중에 기록이 빈 구간을 설명할 수 없다
• 파이썬은 continue 를 만나면 파일 핸들을 닫아 이후 줄을 읽지 못한다
• 건너뛴 줄만큼 뒤 줄의 줄 번호가 밀려 원본과 대조할 수 없다

세 원본을 합치면서 등급을 ERROR·WARN·INFO 세 값으로 접었다. 이 결정의 대가로 반드시 함께 해야 하는 일은?

• 원본의 등급 값을 지우고 접은 값만 남겨 저장 용량을 아끼는 일
• 모든 레코드의 등급을 사람이 한 번씩 확인해 손으로 고치는 일
• 접는 규칙과 원본 등급을 문서로 남겨 되짚을 수 있게 하는 일
• 세 원본의 등급 체계를 하나로 바꾸도록 고객 시스템을 수정하는 일