처음이어도 괜찮아요 · 그림부터 시작해요
named logger hierarchy와 propagation을 추적한다
`logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다. 이 판단을 생략하면 통과한 test와 많은 log가 있어도 결함을 놓치거나 잘못된 수정을 승인할 수 있습니다.
아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.01 · 가볍게 시작하기
정답을 보기 전에 먼저 골라볼까요?
synthetic td36 fixture · secret 없는 고정 입력 · exact Python 3.14.6- 1먼저 골라보기
틀려도 괜찮아요. 지금 생각한 답 하나를 정해요.
- 2그림으로 확인하기
움직이는 순서와 달라지는 곳만 천천히 찾아요.
- 3내 말로 다시 말하기
한 문장으로 말해 보면 내가 이해한 곳을 확인할 수 있어요.
02 · 그림으로 보기
그림이 움직이는 순서를 직접 확인해요
- 01관찰named logger · hierarchy · propagation · effective level
- 02추론점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다. originating logger의 effective level·filter는 emission을 결정하지만 propagation 중 ancestor logger의 level·filter는 다시 적용되지 않고 각 ancestor handler의 level·filter만 적용된다. library는 root logging을 임의 구성하지 않고 application composition root가 handler·format 정책을 소유한다.
- 03검증named logger hierarchy와 propagation을 추적한다의 예상 결과·관찰 결과·판정 oracle을 실행 전에 분리해 기록한다. child·root handler가 모두 같은 sink를 쓴다.에서 최초 불일치 지점과 근본 원인을 재현 가능한 evidence로 국소화한다. 각 level의 record가 의도한 handler에 정확히 한 번 전달되거나 명시적으로 제거됨을 정상·경계·실패 fixture에 적용하고 false green·false red가 없는지 검증한다.
처음 보는 말도 책 읽듯 풀어봐요
이 수업은 쉬운 뜻과 생활 예를 아직 함께 준비하지 못했어요. 설명 없는 정확한 이름은 먼저 보여 주지 않을게요.
그림에서 찾을 쉬운 규칙
- 01점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
- 02originating logger의 effective level·filter는 emission을 결정하지만 propagation 중 ancestor logger의 level·filter는 다시 적용되지 않고 각 ancestor handler의 level·filter만 적용된다.
- 03library는 root logging을 임의 구성하지 않고 application composition root가 handler·format 정책을 소유한다.
03 · 같이 풀어보기
한 단계씩 따라가면 어렵지 않아요
multi-module service logging 구성에서 named logger hierarchy와 propagation을 추적한다 계약을 적용한다.
synthetic td36 fixture · secret 없는 고정 입력 · exact Python 3.14.604 · 이제 내가 해볼 차례
여기까지 오면 이런 일을 할 수 있어요
`logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다.
- named logger hierarchy와 propagation을 추적한다의 예상 결과·관찰 결과·판정 oracle을 실행 전에 분리해 기록한다.
- child·root handler가 모두 같은 sink를 쓴다.에서 최초 불일치 지점과 근본 원인을 재현 가능한 evidence로 국소화한다.
- 각 level의 record가 의도한 handler에 정확히 한 번 전달되거나 명시적으로 제거됨을 정상·경계·실패 fixture에 적용하고 false green·false red가 없는지 검증한다.
05 · 자주 헷갈리는 지점
틀린 답도 이유를 알면 다음에는 맞힐 수 있어요
01ancestor logger를 ERROR로 올리면 이미 child에서 생성된 INFO record도 propagation 중 자동 제거된다.
한 번 더 생각해 볼 질문named logger hierarchy와 propagation을 추적한다의 최소 fixture에서 이 주장을 깨는 관찰값과 판정 근거를 각각 한 줄로 쓰세요.
이렇게 고쳐 생각해요점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
02child와 root에 handler를 두면 같은 event가 더 안전하게 한 번 기록된다.
한 번 더 생각해 볼 질문named logger hierarchy와 propagation을 추적한다의 최소 fixture에서 이 주장을 깨는 관찰값과 판정 근거를 각각 한 줄로 쓰세요.
이렇게 고쳐 생각해요originating logger의 effective level·filter는 emission을 결정하지만 propagation 중 ancestor logger의 level·filter는 다시 적용되지 않고 각 ancestor handler의 level·filter만 적용된다.
03library module이 basicConfig를 호출해도 host application에는 영향이 없다.
한 번 더 생각해 볼 질문named logger hierarchy와 propagation을 추적한다의 최소 fixture에서 이 주장을 깨는 관찰값과 판정 근거를 각각 한 줄로 쓰세요.
이렇게 고쳐 생각해요library는 root logging을 임의 구성하지 않고 application composition root가 handler·format 정책을 소유한다.
06 · 더 궁금할 때만 보기
선생님과 검토자를 위한 믿을 만한 원문
원문과 어디까지 참고했는지 펼쳐 보기처음 배우는 동안에는 열지 않아도 괜찮아요.
Logger hierarchy, level, Handler·Filter·Formatter·LogRecord와 propagation의 공식 계약
library·application logging 구성, level 선택, formatting과 operational event 입문
testing purpose·error/defect/failure, types·levels·process, coverage·refactoring, debugging·assertions·logging·white/black-box objective
Block 3 logging·monitoring, print 한계, level·format·structured context·secret 비노출. 시험 availability는 별도 확인 필요
1.9 traceback object 분석과 5.2 logging events·levels·LogRecord·custom handlers/formatters의 선택적 겹침. pytest 직접 범위 아님