하루 로그

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줄 요약 합성 스위트(테스트 200개)에서 맵을 만드는 값은 전체 실행 대비 +19.7%이고, 잎 모듈 하나를 고쳤을 때 남는 실행은 25.1%입니다. 같은 맵이 conftest 변경·데이터 파일 변경·새 테스트 파일·아무 테스트도 안 닿은 파일 네 자리에서 0개 를 고릅니다. 데이터 파일 한 줄을 바꾼 경우 실제로는 40개가 깨졌는데 맵은 "돌릴 것 없음"을 냈습니다. 맵에 없는 경로가 변경 목록에 하나라도 섞이면 전체 실행으로 되돌리는 20줄짜리 가드를 먼저 붙이고, 그다음에 선택 실행을 1차 피드백 자리에만 두는 순서입니다.

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줄 요약 멈춘 테스트를 끊는 방법은 pytest-timeout의 signal · thread 와 pytest 내장 faulthandler 세 갈래인데, pytest-timeout 공식 문서는 thread를 "가장 확실한 방법"이라고 적고 있습니다. 행 11종을 상한 2초로 돌려 보니 signal 9/11, thread 10/11, faulthandler(exit=true) 11/11이었고 signal과 thread가 놓친 항목이 하나도 겹치지 않았습니다. 정규식 백트래킹은 thread만 놓쳤고, SIGALRM을 건드린 테스트는 signal만 놓쳤습니다. xdist로 병렬 실행 중이면 thread , 단일 프로세스면 signal 을 기본값으로 두고 느린 테스트만 @pytest.mark.timeout 으로 예외 처리하시면 됩니다.

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

3줄 요약 오퍼레이션 5개짜리 API에 Schemathesis 4.25.2를 처음 돌리니 2.5초 만에 667건을 만들어 실패 10건을 냈고, 그중 서버가 실제로 죽은 것은 2건이었습니다 나머지 8건은 코드가 아니라 스펙이 현실을 못 따라간 것이었고, 스펙을 정확하게 고치자 실패는 10건에서 3건으로 줄었지만 실행 시간은 2.5초에서 5.9초로 늘었습니다 처음 붙이신다면 --generation-deterministic 을 켜고 --phases coverage,fuzzing 으로 0.8초짜리 관문부터 만드시면 됩니다

3줄 요약 테스트를 잡으로 쪼개면 파이프라인이 빨라지지만, 어느 지점부터는 벽시계가 거의 안 줄고 청구 분만 늘어납니다. 200개·232초짜리 스위트를 실측한 결과 잡 4개에서 벽시계 120초, 8개에서 90초였고 청구는 8분에서 16분으로 정확히 2배였습니다. 잡 고정비를 60초로 잡았을 때입니다. 잡 수 상한을 전체 테스트 시간 ÷ 잡 고정비 로 먼저 계산하시고, 그 값을 넘기지 않는 선에서 --splitting-algorithm least_duration 을 붙이시면 됩니다.

3줄 요약 Allure Report 2의 트렌드와 History 탭은 리포트를 만들 때 나오는 history 폴더를 다음 실행의 결과 디렉터리로 되돌려 놓아야 이어집니다. CI에서 이 한 줄이 빠지면 리포트는 정상으로 보이는데 트렌드만 매번 1칸입니다. 26회를 쌓은 상태에서 복사를 한 번 빠뜨려 보니 트렌드 20칸이 1칸으로, statistic.total 이 26에서 1로 돌아갔습니다. 되돌릴 방법은 이전 리포트 아티팩트를 다시 찾는 것뿐입니다. CI 캐시나 GitHub Pages 브랜치로 history 를 영속화하고, flaky율은 20개 상한이 걸린 items 가 아니라 무한 누적되는 statistic 으로 계산하시면 됩니다.

3줄 요약 Newman의 마지막 릴리스는 2026-01-16 v6.2.2이고 내용은 의존성 갱신 한 줄입니다. 실제 소스 코드는 2024-08-20 이후 바뀌지 않았습니다. Postman CLI는 같은 기간 활발히 나오지만, 컬렉션을 v3 YAML로 바꾸는 순간 리포터가 cli 하나만 남습니다. CI에서 JUnit XML을 파싱하고 있다면 그 시점에 끊깁니다. 오늘은 갈아타지 마시고, 아래 점검 스크립트로 우리 컬렉션이 v2.1 JSON인지·파일 업로드 요청이 있는지·커스텀 리포터를 쓰는지 먼저 세어 보시면 됩니다.

3줄 요약 pytest-rerunfailures로 재시도를 걸어 CI 실패 알림을 줄였는데, "얼마나 자주 재시도됐는지"는 JUnit XML 어디에도 남지 않았습니다. 원인은 pytest의 리포트 훅이 재시도 과정을 표준 리포트 형식에 담지 않기 때문이며, pytest-reportlog의 --report-log 만 시도별 기록을 JSON 줄로 남깁니다. 오늘 CI 설정에 --report-log=results.jsonl 한 줄을 추가하고, 글 안의 스크립트로 재시도율을 GitHub Actions 요약에 올려보시면 됩니다.

3줄 요약 fail-fast 는 기본값이 true 라 매트릭스 한 칸이 실패하면 진행 중·대기 중 잡이 전부 취소되고, 취소된 잡은 리포트를 남기지 않습니다. 잡 실행 시간의 절반 지점에서 실패가 난다고 보면, 한 런에서 서로 다른 실패 원인이 2개 이상 나오는 팀부터 fail-fast: false 가 러너 분에서 이득입니다. fail-fast 를 건드리기 전에 리포트 업로드 스텝에 if: always() 를 붙이고 아티팩트 이름에 매트릭스 값을 넣으시면 됩니다.

3줄 요약 Selenium Grid의 노드 기본 최대 세션 수는 옵션값이 아니라 그 머신의 사용 가능한 프로세서 수입니다. GitHub Actions private 저장소 러너는 2코어라 병렬 10을 걸어도 슬롯은 2개만 열립니다. 늘리는 방법은 세 갈래입니다. 한 노드의 세션 수를 올리거나(세로), 노드를 더 붙이거나(가로), 남의 그리드를 빌립니다. 코어당 세션 1개라는 기본값을 넘기려면 --override-max-sessions true 가 필요하고, 공식 문서가 안정성 저하를 명시적으로 경고합니다. 오늘 curl http://localhost:4444/status 로 maxSessions 값을 먼저 확인하시고, 그 숫자보다 큰 병렬 수를 코드에 걸어두고 있었다면 그 차이만큼이 그동안 큐 대기 시간이었다고 보시면 됩니다.

3줄 요약 안드로이드 systemPort 는 8200~8299에서 자동으로 빈 포트를 잡아주지만, iOS wdaLocalPort 는 8100 하나로 고정이라 두 번째 세션부터 충돌합니다. 기기 1대에서 잘 돌던 스위트를 4대로 늘릴 때 유니크하게 지정해야 하는 포트는 안드로이드 4종, iOS 3종이며, 워커 인덱스 하나로 전부 계산할 수 있습니다. 아래 워커 인덱스 기반 포트 할당표를 그대로 옮겨 쓰시고, 세션이 남아 대역이 고갈될 때는 adb -s <UDID> forward --remove-all 로 정리하시면 됩니다.

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

AI 테스트 생성 도구 데모를 보고 나면 팀 채널이 잠깐 시끄러워집니다. 화면 녹화 안에서는 자연어 한 줄이 Playwright 스펙 파일로 바뀌고, 셀렉터가 깨져도 알아서 고쳐집니다. 그런데 두 달 뒤 릴리스 주기를 다시 재보면 아무것도 달라져 있지 않습니다. PR은 여전히 이틀 걸려 머지되고, QA는 여전히 금요일 저녁에 리그레션을 돌립니다. 도구를 잘못 골랐나 싶어 다른 벤더 데모를 또 잡습니다. 여기서 갈래는 셋입니다. 첫째, 모델이나 도구를 더 좋은 것으로 바꿉니다. 둘째, 자동화 커버리지를 더 올립니다. 셋째, 도구 검토를 멈추고 파이프라인이 실제로 몇 분 걸리는지부터 잽니다. 앞의 둘은 예산과 사람이 필요하고 셋째는 오늘 오후에 시작할 수 있습니다. 그런데 대부분의 팀이 앞의 둘부터 손을 댑니다. 결론을 먼저 말씀드리면, 셋째부터 하시는 편이 맞습니다. 파이프라인이 30분이면 그 안에서 사람이든 에이전트든 하루에 시도할 수 있는 횟수가 물리적으로 제한됩니다. 도구를 바꿔서 코드 작성 시간을 절반으로 줄여도 검증 대기 시간이 그대로면 전체 리드타임은 거의 움직이지 않습니다. 이건 정성적인 훈계가 아니라 8월 24일에 GitLab이 숫자와 함께 내놓은 주장이고, 저는 우리 팀 상황에 그대로 적용된다고 봅니다. 1. 8월 24일 GitLab이 내놓은 문장 하나 1-1. "코드는 더 이상 병목이 아니다" GitLab 공식 블로그 에 2026-08-24 올라온 CEO Bill Staples의 글 "When code is abundant"는 "Code is no longer the bottleneck."이라는 문장으로 시작합니다. 여기까지는 흔한 수사입니다. 이 글이 인용할 만해지는 지점은 그다음입니다. 같은 글에 이런 문장이 있습니다. "a thirty-minute CI pipeline defeats every model you point at it." 30분짜리 CI 파이프...