named logger hierarchy와 propagation을 추적한다

오늘의 질문

`logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다. 이 판단을 생략하면 통과한 test와 많은 log가 있어도 결함을 놓치거나 잘못된 수정을 승인할 수 있습니다.

아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.

01 · 같이 연습해요

작은 문제부터 하나씩 직접 풀어봐요

먼저 예상하고, 한 단계씩 확인하고, 막힌 곳을 고쳐 봐요. 도움을 열어도 괜찮아요. 도움을 본 문제는 나중에 모양을 바꿔 다시 풀어보면 됩니다.

연습에서 작성 중인 답0 / 8

01
찾아보기 · 기초
td36 td36 named logger hierarchy와 propagation을 추적한다: `logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다.에서 expected·actual·oracle·fixture·diagnostic evidence와 근거 없는 주장을 분류한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
정답과 비교
02
먼저 생각하기 · 기초
td36 multi-module service logging 구성에서 named logger hierarchy와 propagation을 추적한다 계약을 적용한다.의 collection·setup·act·assert·teardown·log 결과를 실행 전에 예측한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
정답과 비교
03
순서 따라가기 · 익힌 것을 써보기
td36 td36 named logger hierarchy와 propagation을 추적한다: `logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다.를 baseline→inject/run→first divergence→replay 순서로 누적 추적한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
정답과 비교
04
내 말로 설명하기 · 익힌 것을 써보기
td36 결과를 Python 3.14.6·pytest 9.0.0 공식 계약과 최소 반례로 설명한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
설명 기준과 비교
05
빈칸 채우기 · 도전
td36 logger hierarchy별 delivery path와 duplicate count를 계산하는 diagnostic를 구현한다.의 fixture·oracle·assertion·diagnostic 빈칸을 완성하고 각 level의 record가 의도한 handler에 정확히 한 번 전달되거나 명시적으로 제거됨
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
답과 설명 함께 비교
06
틀린 곳 고치기 · 도전
td36 child·root handler가 모두 같은 sink를 쓴다.에서 last-good·first-bad state와 실패 owner를 찾아 최소 수정을 검증한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
답과 설명 함께 비교
07
직접 만들기 · 도전
td36 logger hierarchy별 delivery path와 duplicate count를 계산하는 diagnostic를 구현한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
답과 설명 함께 비교
08
새 문제에 써보기 · 새 문제
td36 td36 named logger hierarchy와 propagation을 추적한다: `logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다.를 multi-module service logging 구성에 전이하고 결정성·격리·oracle·비노출 경계를 방어한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  named logger hierarchy와 propagation을 추적한다에서 expected, actual, exception/warning/log, state before/after를 섞지 말고 따로 기록하세요.
2. 개념
  점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
설명 기준과 비교

8개 답이 남았습니다.

02 · 막힌 곳을 찾아요

틀린 답에서 생각이 갈라진 첫 지점 찾기

헷갈림 01

child·root handler가 모두 같은 sink를 쓴다.

겉으로 보이는 막힘: record가 두 번 저장된다.
막힌 까닭: 검증 계약에서 다음 원칙을 빠뜨렸다: 점으로 구분된 logger 이름은 hierarchy를 만들고 child record는 propagate가 true이면 ancestor logger가 아니라 그 logger에 연결된 handler로 직접 전달된다.
다시 해보는 방법: handler owner를 한 계층으로 정하거나 propagation을 명시한다.

헷갈림 02

ancestor logger level과 ancestor handler level을 같은 gate로 취급한다.

겉으로 보이는 막힘: 설정 표와 실제 delivery가 어긋나 missing·unexpected record를 잘못 진단한다.
막힌 까닭: 검증 계약에서 다음 원칙을 빠뜨렸다: originating logger의 effective level·filter는 emission을 결정하지만 propagation 중 ancestor logger의 level·filter는 다시 적용되지 않고 각 ancestor handler의 level·filter만 적용된다.
다시 해보는 방법: originating effective level 뒤에는 ancestor logger를 건너뛰고 handler level·filter를 추적한다.

헷갈림 03

import된 library가 basicConfig를 호출한다.

겉으로 보이는 막힘: application format과 destination이 오염된다.
막힌 까닭: 검증 계약에서 다음 원칙을 빠뜨렸다: library는 root logging을 임의 구성하지 않고 application composition root가 handler·format 정책을 소유한다.
다시 해보는 방법: library는 named logger만 사용하고 config를 host에 맡긴다.

03 · 내게 맞는 도움 고르기

같은 목표를 원하는 도움만큼 연습해요

안내 받으며

안내형

named logger → hierarchy → propagation → effective level 순서로 expected·actual·first divergence·oracle·evidence 칸을 채우고, 각 칸의 출처를 표시한다.

named logger hierarchy와 propagation을 추적한다의 정상 경로와 실패 경로 및 최초 불일치 지점을 번호와 선 종류로 구분한 도식에서 색 외에도 baseline·actual·first divergence·oracle·phase·verdict label과 선 종류를 대응한다.

혼자 해보기

내 힘으로

td36 named logger hierarchy와 propagation을 추적한다: `logging.getLogger(__name__)` hierarchy에서 originating logger의 effective level과 propagation 뒤 ancestor handler의 level·filter를 구분해 duplicate·missing record를 방지한다.의 처음 보는 fixture를 먼저 예측한 뒤 exact Python 3.14.6과 고정 toolchain에서 실행하고 불일치만 공식 규칙으로 교정한다.

공식 문서·문법·도구 사용법은 열 수 있지만 해당 변형의 exact expected·failure owner·patch target·hidden verdict는 먼저 제공하지 않는다.

더 도전하기

심화형

multi-module service logging 구성에 같은 test contract를 이식하고 입력·상태·시간·dependency 중 두 축을 바꾼 미공개 변형을 추가한다.

named logger hierarchy와 propagation을 추적한다에서 짧은 test 수보다 결함 탐지력·결정성·격리·진단성·유지보수 비용을 우선하고 선택 근거를 남긴다.