Replit Agent 3의 자가 테스트 시스템: '포템킨 인터페이스'를 잡아내는 방법

포템킨 인터페이스 문제

• 1783년 러시아가 크림반도를 합병한 뒤, 포템킨 장관이 황후의 시찰에 대비해 "이동식 마을"을 만들어 전쟁 피해를 숨긴 일화에서 이름을 따옴. AI 에이전트도 똑같은 짓을 한다는 거임

• Replit이 Agent 3를 만들면서 가장 골치 아팠던 실패 모드가 바로 이 "포템킨 인터페이스" — 버튼은 렌더링되고, 대시보드는 통계를 보여주고, UI가 반응하는 것 같은데, 실제로는 아무것도 연결이 안 돼 있는 상태. 이벤트 핸들러 누락, 목 데이터, 링크 데드엔드

• 진짜 위험한 건 첫눈에 작동하는 것처럼 보인다는 거임. 사용자가 프로덕션에서야 문제를 발견할 때쯤이면 에이전트는 이미 부서진 기반 위에 기능을 쌓아올린 뒤임

검증 스펙트럼 — 왜 기존 테스트로는 부족한가

• 코드 검증에는 단계가 있음:

  • LSP + 실행: 문법 수준 정확성
  • 유닛 테스트: 기본 기능 정확성
  • API 테스트: 서버 관점의 넓은 기능 검증
  • 하지만 클라이언트와 서버 사이의 이음새(seam)에서 터지는 버그 — 인증의 브라우저 쿠키 의존성, 클라이언트 캐싱과 재검증 같은 것 — 은 위 방법으로 잡기 어려움

• Playwright/Puppeteer 같은 브라우저 자동화 테스트가 답이 될 수 있지만, 에이전트가 이런 테스트를 원샷으로 작성하기가 매우 어려움. 실제 DOM이 어떻게 생겼는지 보지 않고 테스트를 쓰려면 루프에 빠지기 쉬움

• 브라우저 유즈(Browser Use) 접근법 — Playwright MCP, Stagehand 등이 브라우저 조작을 에이전트 도구로 감싸는 방식 — 은 표현력이 제한적임. 파일 업로드? 새 도구 필요. 새 탭? 또 새 도구. 각 도구가 컨텍스트를 소비하는데 액션 스페이스가 사용 가능한 도구에 제약됨

• CUA(Computer Use Agent) — 화면 픽셀을 보고 클릭/타이핑하는 모델 — 는 품질은 좋지만, Claude Sonnet 4 기준 5개 필드 폼 하나 채우는 데 약 $0.50에 30~90초가 걸림. 실서비스에 쓰기엔 비용과 속도가 비현실적임

Replit의 하이브리드 솔루션: 코드 유즈 + 노트북 REPL

• 도구 호출 대신 코드로 브라우저 액션을 표현하는 방식을 택함. Playwright JavaScript를 샌드박스에서 실행하고, 헬퍼 함수를 주입함

• Playwright가 LLM 훈련 데이터에 워낙 많이 들어있어서, 모델이 이미 Playwright 코드를 잘 쓸 줄 앎. 추가 프롬프팅 없이도 시맨틱을 이해함

• 토큰 효율성이 압도적임. 예를 들어 캘린더 위젯에서 2028년 12월 15일을 선택하려면 36개월을 앞으로 넘겨야 하는데, 브라우저 유즈로는 36번의 개별 모델 호출이 필요하지만, 코드로는 단일 for 루프 한 번이면 끝남

• 노트북 인터페이스가 핵심임. 실행 환경이 인터랙션 사이에 유지되니까:

  • 변수가 살아있음 — 이전에 얻은 주문 ID를 나중에 검증에 쓸 수 있음
  • 브라우저 세션이 유지됨 — 같은 인스턴스에서 점진적으로 탐색 가능
  • 컨텍스트가 코드에 남지 토큰에 남지 않음

• DOM의 스트립다운 표현 + ARIA 라벨, 데이터베이스 읽기 전용 쿼리, 클라이언트/서버 로그까지 에이전트에게 제공해서 원인-결과 관계 파악을 도움

서브에이전트 아키텍처

• 메인 에이전트 컨텍스트가 8만~10만 토큰에 달하는데, 테스트를 메인 루프에 넣으면 컨텍스트 오염이 심각해짐. 그래서 테스트를 별도 서브에이전트로 분리함

• 메인 에이전트가 서브에이전트에게 고수준 계획을 넘기면, 서브에이전트가 독립적으로 테스트를 수행하고, 결과를 요약해서 "뭐가 작동하고 뭐가 깨졌는지"만 돌려줌