하루 로그

3줄 요약 동작이 바뀌는 코드를 고치면 테스트 3~28개만 다시 돕니다. JSON 설정을 바꾸면 0개를 골라 실패 2건을 놓칩니다. 설정 파일은 env 옵션에 넣고 야간에 전체를 돌립니다.

3줄 요약 팀에서 새너티 테스트가 가리키는 범위를 먼저 한 줄로 정합니다. 스모크 테스트는 빌드마다 돌리는 짧은 목록으로 만듭니다. 스모크가 실패하면 본 테스트를 멈춘다는 규칙까지만 적습니다.

3줄 요약 테스트 통과율이 높아도 릴리스가 안전하다는 보장은 없습니다. 통과율 94.2%에서 40만 달러가 환불됐다는 발표 사례가 있었습니다. 통과율 옆에 결함 유출률과 미검증 비율을 같이 적으십시오.

3줄 요약 스냅샷을 처음 만들 때도 -n auto 를 붙여 시간을 아끼는 것이 습관이 돼 있었습니다. syrupy 6.1.1과 pytest-xdist 3.8.0 조합에서 20개를 만들면 4워커는 15~16개, 8워커는 최악 2개만 파일에 남았습니다. 그런데 화면에는 20 snapshots generated 가 찍히고 종료 코드는 0이었습니다. 6.1.1에 새로 들어온 --snapshot-file-lock 을 붙이면 10회 실행에서 전부 20개가 남았고, 8워커 기준 실행 시간 차이는 0.001초였습니다.

3줄 요약 pytest 9.1.0(2026-06-13 릴리스)부터 caplog 가 propagate=False 로거에도 핸들러를 직접 답니다. 그동안 캡처를 포기하고 우회책을 넣어 둔 스위트가 영향을 받습니다. monkeypatch.setattr(log, "propagate", True) 우회책을 쓰던 테스트는 같은 로그 한 줄에서 레코드가 1개에서 2개로 늘었고, 같은 스위트의 --log-file 출력은 0줄에서 10줄(440B)이 됐습니다. 업그레이드 전에 propagate 를 손대는 자리부터 찾아 지우십시오. 로거 5,000개 환경에서는 스캔 비용도 300테스트당 0.16초에서 0.53초로 붙습니다.

3줄 요약 AI 테스트 에이전트를 붙이면 자동화 커버리지가 오른다는 말은 이번 주 리포트에서도 반복됐습니다. 다만 Wopee.io가 에이전트 5종을 비교한 조사에서 커버리지는 과거 상한이던 약 25%에서 51~60%로 올랐는데, 같은 조사의 완전 자율 자동화 만족도는 5점 만점에 2.2점이었고 무감독 운영을 실제로 지원하는 도구는 5종 중 하나도 없었습니다. 그러니 에이전트를 검토할 때 볼 값은 "자동화율이 몇 퍼센트까지 오르는가"가 아니라 "사람 검토 게이트가 주당 몇 건을 받아 내는가"입니다.

3줄 요약 두 라이브러리는 고정하는 함수 목록이 다릅니다. freezegun은 time.monotonic() 까지 멈추고, time-machine은 그것만 실제 시각으로 남깁니다. 같은 datetime(2026, 3, 1, 12, 0) 을 넣어도 datetime.now() 가 12:00과 21:00으로 갈립니다. 진입·해제 비용은 923.63us 대 8.52us로 108.4배 차이입니다. 옮길 계획이 있다면 python -m time_machine migrate 를 돌리기 전에 conftest에 naive_mode 부터 정해 두시면 됩니다.

3줄 요약 pytest-randomly 5.0.0이 pytest_collection_modifyitems 를 평범한 tryfirst 에서 훅 래퍼로 바꿔, 다른 플러그인보다 항상 먼저 셔플하도록 만들었습니다. 그룹 정렬 플러그인이 없으면 같은 시드가 4.1.0과 똑같은 순서를 냅니다. 있으면 40칸이 전부 달라지고, 그룹 경계를 넘는 순서 의존성 탐지율이 시드 60개 기준 56.7%에서 0%로 떨어졌습니다. 정렬 플러그인을 함께 쓰신다면 셔플 잡을 -p no:그룹플러그인 조합으로 따로 하나 더 돌리시면 됩니다.

가장 설명하기 어려운 장애가 있습니다. 우리 코드는 한 줄도 바뀌지 않았고, 배포도 없었고, 인프라 변경도 없었는데 어느 날 아침부터 회원가입이 실패합니다. 로그를 뒤져 보면 이메일 형식 검증에서 걸러지고 있습니다. 검증 로직은 3년 전에 작성된 것이고 그동안 아무 문제가 없었습니다. 바뀐 것은 우리가 아니라 상대편입니다. 이런 종류의 결함에 대응하는 방식은 셋 정도입니다. 첫째, 터진 뒤에 고칩니다. 대부분의 팀이 여기 있습니다. 둘째, 외부 서비스의 상태 페이지를 구독합니다. 도움은 되지만 이런 변경은 상태 페이지에 안 올라옵니다. 셋째, 우리가 하드코딩한 외부 상수의 목록을 만들고 그 목록에 대해 감시와 테스트를 붙입니다. 결론을 먼저 말씀드리면 셋째만이 실제로 작동합니다. 그리고 8월 24일 하루에 나온 공지 두 건이 이 작업을 지금 시작할 이유를 만들어 줍니다. 하나는 로그인 이메일 도메인이 바뀐다는 예고이고, 다른 하나는 CI 명령어 플래그가 3주 뒤에 사라진다는 통보입니다. 둘 다 우리 코드를 건드리지 않고 우리를 깨뜨릴 수 있는 변경입니다. 1. 8월 24일에 나온 두 건 1-1. Sign in with Apple 이메일 도메인 변경 Apple Developer News 에 2026-08-24 올라온 "Update: New domain for Sign in with Apple"의 문구를 원문 그대로 옮깁니다. "Starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com , will be issued on private.icloud.com ." 기존 주소는 계속 동작합니다. "Existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without ...