페이지를 새로고침해도 그 어떤 수정도 작동하지 않았다

라우트는 고쳐졌다. State 엔드포인트는 다시 작성됐다. 데이터 포맷은 수정됐다. 모든 변경이 리포지토리에서 확인됐고, 파일에서 보였고, 의도한 그대로였다.

브라우저를 새로고침했다. 아무것도 바뀌지 않았다.

같은 깨진 테이블. 같은 빈 캔버스.

실제로 무슨 일이 일어나고 있었나

플랫폼은 Docker에서 로컬로 실행된다 — 각자 서비스를 돌리는 여러 컨테이너가 공유 설정을 통해 연결되어 있다. 프런트엔드 웹 앱은 볼륨 마운트되어 있다: 디스크의 소스 파일이 컨테이너에 직접 매핑된다. 빌드 도구인 Vite는 파일 변경을 감지해 브라우저를 자동으로 다시 로드한다.

다만, 감지하고 있지 않았다.

Windows에서 WSL2 위에서 Docker가 돌아가는 환경에서 — WSL2는 Windows가 컨테이너를 위해 사용하는 Linux 호환 계층이다 — Vite가 변경 감지를 위해 의존하는 파일시스템 이벤트 알림이 가상화 경계를 넘어 제대로 전달되지 않는다. Linux의 알림 시스템은 변경을 보고한다. Windows는 그것을 전달하지 않는다. Vite는 파일 업데이트를 절대 보지 못한다. 브라우저는 이전에 있던 코드를 계속 서빙한다.

수정은 Vite 설정의 한 줄이었다: usePolling: true. 변경 알림을 기다리는 대신 Vite는 300밀리초마다 확인한다. 약간 덜 효율적이다. 작동한다.

테이블 엔진 — 실제 게임 상태를 관리하는 백엔드 서비스 — 도 같은 문제의 자신만의 버전을 갖고 있었다. 이 스택의 백엔드 서비스들은 watch 모드로 돌지 않는다. 코드 변경은 컨테이너 수동 재시작을 요구한다. 프로덕션급 서비스에서는 표준 동작이다. 그냥 재시작해야 한다는 걸 알면 된다.

또 다른 잘못된 것

환경 문제가 해결된 후, 세 번째 버그가 드러났다: 테이블 라우트에 auth guard가 있었는데, 항상 브라우저를 로그인 페이지로 보냈다.

사용자가 로그인되어 있지 않아서가 아니다. 로그인되어 있었다. Guard는 절대 채워지지 않는 TanStack Router 컨텍스트 값을 확인하고 있었다 — 라우터가 context provider 없이 설정되어 있어서 context.auth는 항상 undefined였다. Guard는 "인증되지 않음"으로 읽고 로그인으로 리다이렉트했다. 로그인은 인증된 세션을 보고 다시 로비로 리다이렉트했다. 브라우저는 루프에 빠졌다.

한 줄을 변경했다. Guard는 authentication store에서 직접 읽도록 업데이트됐다 — 애플리케이션의 다른 모든 라우트가 사용하는 동일한 패턴이다. 해결.

이것이 키보드 앞 사람에게 요구하는 것

수정은 정확했다. 시스템이 그것들을 받아들이지 않고 있었다. 그 관찰 — 정확한 코드와 실행되는 코드는 두 가지 다른 것이라는 — 은 올바른 질문을 던질 수 있을 만큼 개발 환경을 잘 아는 것을 요구했다.

에이전트는 수정을 작성할 수 있다. 일단 버그를 설명하면 추적할 수 있다. 브라우저가 설정 변경 전 코드의 캐시된 버전을 서빙하고 있다는 걸 알아챌 수는 없다. 그 관찰은 사람의 몫이다.

정확한 수정이 왜 효과를 내지 않는지 진단할 수 있을 만큼 시스템을 잘 아는 것 — 그 부분은 자동화되지 않는다.

Polling 설정 후, 컨테이너 재시작 후, auth guard 수정 후: 테이블이 로드됐다. 좌석이 나타났다. Buy-in 다이얼로그가 렌더됐다. 로비 카드가 올바른 높이였다. 모든 것이 작동했다.

다음 글은 작동하는 시스템이 생긴 후 integration testing이 어떻게 보였는지를 다룬다 — 그리고 그 단계가 AI든 사람이든 누가 코드를 썼는지에 관계없이 똑같이 보이는 이유.

파운더의 시각에서 이런 종류의 디버깅 프로세스를 항해하는 것 — AI가 코드베이스의 대부분을 작성했을 때 human-in-the-loop 역할이 실제로 무엇을 요구하는지 — 는 The Salty Korean에 있다.

Stay salty.