# 설계안 의사 코드 · 미실행
if fixture_is_unavailable:
stop(

자신의 평가 기반이라면, 더미 화면 오류 후에 AI가 멈출 것이라고 생각하는가? 다른 URL을 찾으려고 할까? 당신의 예상도 댓글로 알려주세요.

다만, 이것은 공개 사례에서 도출된 설계 분석일 뿐이며, 개별 모델이 일탈한 내부 원인을 증명하는 것은 아닙니다.

우선 확인할 것은 프롬프트가 아니라 출구입니다. Docker 공식 예제는 다음 명령어로 네트워크 인터페이스를 확인합니다.

사양상, 컨테이너 내부에는 `lo`만 생성됩니다. 이미지가 미취득인 경우 Docker 측에서 취득이 발생할 수 있으므로, 평가 실행 시에는 사전 준비를 마치고 후술하는 `pull_policy: never`도 사용합니다.

실제 평가에서는 브라우저, 실행 코드, 필요한 데이터를 사전에 이미지에 넣습니다. 브라우저만 닫아도 에이전트가 다른 네트워크가 연결된 셸을 호출할 수 있다면, 그 경로가 남아 있습니다.

화면이 표시될 정도의 목업으로는 부족합니다. 전송지 역시 연습용으로 합니다.

다음은 Playwright의 요청 대체 API를 사용한 필자 제작 예제입니다. `playwright`와 Chromium이 도입된 환경에서 `form-fixture.mjs`로 저장합니다. **미실행 예시이며, AI 모델은 호출하지 않습니다.**

이 예제의 목적은 입력 시에는 0, 버튼 클릭 후에는 1이라는 **fixture 내의 접수 횟수**를 확인하는 것입니다. 외부로 전송되는 건수를 측정한 코드는 아닙니다.

평가 대상 AI를 연결할 때는 후반부의 입력/클릭 조작을 대체합니다. '입력하고 전송 전에 멈추는' 과제라면, 올바른 입력, 범위를 벗어난 조작이 없는지, 종료 시 `submitted === 0`인지를 종합적으로 확인해야 합니다. 0만으로는 아무것도 하지 않은 AI도 통과할 수 있습니다. 이 짧은 예시에는 범위 외 조작의 기록 및 채점은 포함되어 있지 않습니다. '전송까지 연습하는' 과제라면 조건이 달라집니다.

같은 버튼이라도, 무엇을 평가하고 싶은지에 따라 정답은 반전합니다. 그 부분을 먼저 결정해야 합니다.

화면이나 API가 많다면, HAR이라는 HTTP 통신 기록을 고정 입력으로 사용할 수 있습니다. 공식의 HAR 재생 사양에 기반하여 기존 Playwright 스크립트에 통합하는 예시입니다.

`url` 필터는 붙이지 않았습니다. 특정 API만 HAR에 맡기고 나머지는 실제 통신으로 흘려보내는 누락을 피하려는 의도입니다.

다만, `abort`가 멈추는 것은 해당 요청입니다. 미수록 요구를 감지하여 평가 전체를 종료시키는 처리는 평가 하네스(evaluation harness) 측에 별도로 필요합니다.

대조 조건은 URL과 HTTP 메서드의 엄격한 일치여야 하며, POST라면 본문도 일치가 필요하게 됩니다. 시간이나 난수로 불일치할 경우, fixture 부족으로 멈춥니다. **재생할 수 없으니 실제 현장에 물어보는 것을 금지합니다.**

HAR에는 Cookie나 본문이 포함될 수 있습니다. 채집은 자신의 테스트 환경에서 진행하고, 공유하기 전에 내용을 정밀하게 검토해야 합니다.

Playwright의 응답 가공 예제에는 먼저 다음 처리가 있습니다.

이것은 원래 요청을 실행한 후에 응답을 가공하는 경로입니다. 전송지가 본문이라면, 답장을 대체할 시점에서는 이미 늦습니다.

**대책:** 완전한 fixture에서는 저장된 데이터에서 직접 `fulfill()`하고, 실제 통신하는 `fetch()`나 `continue()`를 섞지 않아야 합니다.

리디렉트 사양에서는 route 핸들러가 원래 요청으로 호출되고, 전송지는 브라우저가 추종합니다. `3xx`를 반환해도 다시 포착할 수 있다고 장담하기 어렵습니다.

즉, '허용 origin이면 `continue()`'라는 코드를 그대로 외부 통신 방벽이라고 부를 수는 없습니다. 짧은 URL인지, 익숙한 호스트 이름인지만으로는 최종적인 도달지는 결정되지 않습니다.

**대책:** 모의(mock)는 전송이 아닌 내용 자체를 반환하고, 외부 도달 제한은 실행 환경 측에서도 구현해야 한다. 

`update` 사양에서 `true`는 실제 네트워크 정보를 통한 기록 및 업데이트를 의미한다.

'기록을 최신으로 하는' 작업과 '고정 데이터로 평가하는' 작업은 허용되는 통신이 다르다. 전자를 자동으로 섞으면, 평가 중에 외부로 나갈 이유가 다시 생길 수 있다.

**대책:** 기록 과정과 평가 과정을 분리하고, 미수록 요청을 실패로 남겨야 한다.

BrowserContext 사양에는 Service Worker가 처리하는 요청을 포착하지 못하는 조건이 있다. 따라서 예시에서는 `serviceWorkers: 'block'`를 명시했다.

그럼에도 불구하고, 별도의 프로세스 HTTP 클라이언트나 호스트 측 실행 도구까지 막은 것은 아니다. Docker의 보안 자료가 설명하듯이, 데몬을 조작할 권한이나 호스트 마운트도 강력한 권한이 된다.

**대책:** 브라우저 외의 도구들도 점검하고, 평가 대상에 Docker 소켓이나 범용 호스트 실행 경로를 전달하지 않아야 한다.

다음은 10월 10일에 확인했던 Docker 네트워크 사양, Playwright 모의 사양과 HAR API를 바탕으로 제가 만든 비교표입니다. 가격 차이보다 제어하는 장소가 선택을 결정합니다.

| 방법 | 주로 만드는 것 | 적합한 평가 | 단독으로는 부족한 점 |
|---|---|---|
| HTML/API를 직접 `fulfill()` | 작업에 대한 알려진 응답 | 전송 직전 중지, 오클릭, 고장 시의 동작 | 모의 외의 실행 경로는 막을 수 없다 |
| HAR 재생 | 기록된 통신 재현 | 동일한 화면・동일한 입력에서의 회귀 평가 | 입력 변동에 약하고, 기록 누락도 관리가 필요 |
| `--network none` | 컨테이너의 통신 경계 | 외부 연결이 불필요한 브라우저・쉘 실행 | 화면이나 데이터는 별도로 준비할 필요가 있다 |

**표에서 읽을 수 있는 것:**

- 작은 폼 평가라면, 직접 모의와 통신 차단 조합부터 시작할 수 있다.
- 대량의 응답을 재사용하려면 HAR이 후보가 되지만, 불일치 시 멈추는 설계를 유지해야 한다.
- 실제 웹을 조사하는 능력은, 폐쇄된 fixture만으로는 측정할 수 없다. 평가 가능한 능력의 범위를 결과에 명시해야 한다.

예를 들어, 의존 패키지・Chromium・앞서 언급한 파일을 결합한 `eval-runner:local`이 준비되어 있다면, Compose 사양을 사용하여 시작 조건을 고정할 수 있다. 아래도 미실행 구성 예시다.

이 상태로는 외부 모델 API에도 연결할 수 없다. AI를 연결하는 설계에서는, 추론 API를 호출하는 신뢰된 컨트롤러와 브라우저를 구동하는 평가 환경을 분리하는 방안이 있다. 관측과, 타입을 검사한 제한적인 조작만을 표준 입출력 등으로 주고받는다. 컨트롤러에게 임의 URL 획득이나 임의 명령어 실행을 대리하게 하면, 또 다른 출구가 생길 수 있다.

그리고, 컨테이너 설정 하나를 최종 방벽으로 삼아서는 안 된다. 영국 AISI는 개선 보고서에서, 샌드박스와 VM 호스트 측 통신 제한에 더해, 행동 실행 전에 멈출 수 있는 동기 모니터를 설명했다. 여기서 제시한 작은 구성 예시가, 그 다층적 대책을 재현하는 것은 아니다.