하루 로그

3줄 요약 기능을 처음 설계하는 단계면 상위 케이스까지만 씁니다. 자동화나 인계가 목적이면 입력값과 기대 결과까지 내립니다. 경계는 누가 돌려도 판정이 같은가입니다.

3줄 요약 ISTQB는 3값이 2값보다 더 엄격하다고 설명합니다. 유효 구간에만 3값을 써도 검출률은 2값과 똑같았습니다. 무효 구간의 바깥 이웃 두 칸만 더하면 100%였습니다.

3줄 요약 플래키는 재시도 설정으로 정리되는 작은 문제로 여기기 쉽습니다. Bitrise 집계로 플래키를 겪는 팀은 10%에서 26%로 늘었습니다. 재시도는 측정에만 쓰고 집계와 격리 레인부터 두십시오.

3줄 요약 개발자가 리포트를 보고 되묻는 이유는 대개 재현이 안 돼서입니다 재현 절차와 기대·실제 결과, 버전만 제대로 써도 되묻는 일이 줄어듭니다 가끔만 재현되는 버그라면 절차와 함께 빈도와 조건을 꼭 적어야 합니다

3줄 요약 계약 테스트를 이번 분기에 넣어야 하는가 — 같은 주에 나온 일간 QA 리포트 4건이 서로 다르게 답했습니다. 9월 18일자는 "MSA 전환 후 2단계 과제로 보류 권장", 9월 21일자는 "1순위 도입"이었고, 나흘 사이에 움직인 칸은 도구 평가가 아니라 유지보수 비용 한 칸이었습니다. 이 답이 뒤집히는 조건으로 두 건이 함께 든 숫자는 서비스 경계 3개입니다. 19일자는 "3개 이상 분리 시 ROI 최상"이라는 도입 조건으로, 20일자는 "3개 이상 + 팀 간 배포 독립성 문제"라는 재검토 조건으로 각각 다르게 적었습니다.

3줄 요약 먼저 확인할 것은 --strict-markers 가 막아 주는 범위입니다. 등록되지 않은 데코레이터는 수집 에러(exit 2)로 잡지만, -m 명령줄 표현식은 아예 보지 않습니다. 그다음 할 일은 -m 표현식을 검사하는 conftest.py 가드입니다. 20줄짜리 훅 하나로 실측한 오타 3종이 전부 exit 4에서 멈췄습니다. 여기서 멈추십시오. 수집 비용 차이는 2,400개 기준 0.54초뿐이고, 그 숫자 때문에 스위트를 디렉터리로 갈아엎을 이유는 없습니다.

3줄 요약 테스트마다 붙여 둔 Issue: QA-1042 태그를 7.5의 [Metadata] 로 옮겨도 되는지가 이 글의 질문입니다. 옮기면 태그 통계 표가 557행에서 0행으로 줄지만, --include 필터와 파일 단위 일괄 지정과 --tagstatlink 이슈 링크를 함께 잃습니다. 다만 이 판단보다 먼저 확인할 것이 있습니다. 리포트를 만드는 rebot 이 7.4.2 이하면 exit 252로 멈추고 파일을 한 개도 남기지 않습니다.

3줄 요약 예제 기반 테스트 12개가 모두 통과하고 coverage.py 분기 커버리지가 100%인 모듈에 속성 기반 테스트 4개를 붙였더니 3개가 즉시 반례를 냈습니다. 반례 탐지에 필요한 max_examples 는 25면 충분했고(세 속성 모두 시드 30개 중 30개 탐지), 비용은 속성 4개 기준 0.311초로 예제 12개의 0.132초 대비 0.179초 증가였습니다. 오늘 붙일 계획이라면 속성을 늘리기 전에 CI 환경변수가 있을 때 기본값 다섯 개가 한꺼번에 바뀐다는 것부터 확인하시면 됩니다.

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 9.1.1로 재현하니 파일 3개에 오류 2건, exit 2, 실행된 테스트 0건이었습니다. 처방은 __init__.py 와 --import-mode=importlib 두 가지이고 수집 시간 차이는 없었습니다(테스트 300개 기준 0.03초 대 0.04초). 갈리는 지점은 테스트 디렉터리 안에 헬퍼 모듈을 두고 있는지입니다. 지금 저장소에서 중복 파일명 탐지 스크립트를 한 번 돌려 보시면 됩니다. 아직 안 터졌더라도 파일 하나만 더 추가되면 그날 CI가 멈춥니다.

3줄 요약 pytest-xdist는 워커마다 따로 수집하고 따로 실행하기 때문에, scope="session" 픽스처가 워커 수만큼 반복 실행됩니다. 테스트 24개·준비 1.5초 기준으로 실측하니 실행 시간은 -n 0 1.62초에서 -n 8 1.85초로 거의 같았고, 실제 피해는 로그인·시드·외부 API 호출이 8번 일어나는 부작용이었습니다. 공식 FileLock 레시피로 준비를 1회로 줄일 수 있지만 yield teardown을 붙이면 준비가 다시 3번 돌았으니, teardown 없는 return 형태로 먼저 붙여 보시면 됩니다.

3줄 요약 테스트마다 로그인을 다시 하면 그 시간이 실행할 때마다 통째로 되풀이됩니다. 로그인 11초에 테스트 46개, 워커 4개면 매 실행에서 약 2분이 로그인에만 들어갑니다. 아끼는 양은 로그인 시간 × (테스트 수 ÷ 워커 수 − 1) 로 계산됩니다. 워커당 테스트가 5개를 넘지 않으면 절감이 작아서 손이 아깝습니다. 워커당 5개를 넘으신다면 Playwright setup 프로젝트로 한 번만 로그인해 storageState 를 재사용하시면 됩니다. 단, 세션 만료를 감지해 다시 만드는 규칙을 같은 커밋에 넣으십시오.

리뷰에서 이런 PR을 받아보신 적이 있을 겁니다. 에이전트가 모듈 하나를 통째로 새 구조로 옮겼고, CI는 전부 초록불이고, 디프는 800줄인데 리뷰어가 볼 만한 논리 변경은 눈에 띄지 않습니다. 머지하고 2주 뒤 프로덕션에서 이상한 값이 나옵니다. 되짚어 보면 에이전트가 새 구조를 만들면서 옛 구현을 어딘가에 그대로 남겨두고 그쪽을 호출하고 있었습니다. 테스트는 옛 구현을 검증하고 있었으니 당연히 통과했습니다. 이 상황에서 선택지는 셋입니다. 리팩터링 PR을 사람이 전부 다시 읽거나, 테스트 스위트를 더 촘촘히 만들거나, 아니면 테스트 통과 말고 다른 판정 기준을 하나 더 세우거나. 첫 번째는 확장이 안 되고 두 번째는 이미 하고 있는 일입니다. 남는 것은 세 번째인데, 그 세 번째가 정확히 무엇이어야 하는지가 늘 애매했습니다. 결론부터 적습니다. 2026-08-25 arXiv에 공개 배포된 리팩터링 벤치마크는 3단계 검증을 세워서 실행 520건을 판정했고, 세 단계를 모두 통과한 것은 28건, 5.4%였습니다. 그런데 저에게 중요한 숫자는 5.4%가 아니라 그 아래 있는 다른 숫자였습니다. 1단계를 통과한 340건 중 58%가 고정 체크 항목의 99%까지 도달했는데, 100%에 도달한 것은 26%뿐이었습니다. 거의 다 됐지만 안 된 상태가 전체의 대부분이라는 뜻입니다. 이 분포가 왜 QA 판정 기준을 바꿔야 하는 이유인지를 아래에 적겠습니다. 1. 벤치마크가 실제로 무엇을 쟀는가 3단계 검증 프로토콜 SWE Refactor Bench(arXiv:2608.23564) 는 2026-08-24 17:59 UTC에 제출되어 2026-08-25 배포분에 실린 논문입니다. 저장소 전체를 대상으로 하는 마이그레이션 과제 20개를 만들고, 그것을 기술 부채 유형 4가지로 나눴습니다. 판정은 한 번에 하지 않고 세 단계를 순서대로 통과해야 합니다. 단계 이름 무엇을 보는가 통과하면 확인되는 것 1 Migration Audit 목표 구조로 ...

가장 설명하기 어려운 장애가 있습니다. 우리 코드는 한 줄도 바뀌지 않았고, 배포도 없었고, 인프라 변경도 없었는데 어느 날 아침부터 회원가입이 실패합니다. 로그를 뒤져 보면 이메일 형식 검증에서 걸러지고 있습니다. 검증 로직은 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 ...