검증 결과를 믿기 전에, 그 검증이 어디서 돌았는지부터 확인한다

당신의 에이전트가 "테스트 브랜치에서 마이그레이션을 돌려 봤는데 문제없습니다"라고 보고한다. 혹은 "개발 환경에서 응답 품질을 확인했습니다", "브라우저로 열어 보니 화면이 비어 있고 초당 2프레임입니다"라고. 보고는 성실하고 결과도 그럴듯하다. 그런데 그 검증이 정말 에이전트가 말한 곳에서 돌았는지는 아무도 확인하지 않았다.

검증 결과를 읽기 전에 무엇부터 봐야 하나

검증 결과보다 먼저, 그 검증이 실제로 닿은 곳을 확인한다. 검증 환경은 운영과 조용히 다르거나, 더 나쁘게는 운영 그 자체다. 그리고 어느 쪽이든 오류는 뜨지 않는다. 그래서 에이전트에게 "결과를 말하기 전에, 그 결과를 만든 환경의 정체를 한 줄 찍어라"를 규칙으로 준다.

검증 환경은 어떻게 조용히 달라지나

실제로 겪은 네 가지가 모두 같은 모양이었다. 오류는 없었고, 결과는 그럴듯했고, 장소만 틀렸다.

• 테스트 브랜치라고 믿은 곳이 본 데이터베이스였다. 서버리스 Postgres 의 명령줄 도구에서 브랜치 주소를 받으려고 모르는 플래그를 붙였더니, 도구는 오류 없이 플래그를 무시하고 기본 브랜치 주소를 돌려줬다(공식 문서에서 브랜치는 위치 인자다). 그대로 돌렸다면 "브랜치 테스트"가 본 DB 에서 돌았다. 받은 주소의 호스트가 기본 브랜치와 다른지 비교하고서야 알았다.
• 개발용 호출 경로와 운영용 경로가 같은 모델인데 다르게 굴었다. 개발은 구독형 명령줄 도구로, 운영은 API 로 부르자 응답 길이 상한과 사고 토큰 적용, 도구가 몰래 덧붙이는 약 1,100토큰의 환경 프롬프트, 호출당 3~8초의 기동 지연, 캐시와 과금이 전부 갈렸다. 기능·안전 검증은 개발 경로로 되지만, 속도·길이·비용 검증은 운영 경로에서만 의미가 있다.
• 자동화 브라우저가 화면을 멈춰 두고 있었다. 자동화·백그라운드 탭에서는 requestAnimationFrame 이 멈추거나 절반으로 깎인다(MDN). 3D 화면이 비고 fps 가 0.1~3 이나 딱 30.0 으로 찍혀 코드를 의심했는데, 탭이 보이지 않는 상태였을 뿐이다. 초기화 때 한 번 그려진 프레임이 남아 있어서 "이 주소는 되고 저 주소는 안 된다"처럼 보인 것이 오진을 키웠다.
• 테스트가 끝나며 실제 상태를 지웠다. 모바일 앱의 통합 테스트를 실기기·에뮬레이터에서 돌리면 끝날 때 테스트용 앱을 제거하는데, 그 자리에 있던 일반 빌드와 로그인 상태가 함께 사라졌다. 검증 환경이 운영과 분리돼 있다는 믿음이 반대 방향으로도 틀릴 수 있다.

왜 오류가 안 뜨나

도구는 "당신이 원한 곳"을 모른다. 도구가 아는 것은 "받은 입력으로 갈 수 있는 곳"뿐이다. 플래그를 무시하는 명령줄 도구, 같은 이름의 모델을 다른 설정으로 부르는 두 경로, 보이지 않는 탭을 아끼는 브라우저는 모두 자기 규칙대로 정상 동작했다. 정상 동작한 결과가 엉뚱한 곳의 결과일 뿐이다. 그래서 확인은 도구의 오류가 아니라 환경의 정체를 직접 묻는 값으로 해야 한다.

에이전트에게 어떤 지침을 주나

다음 문장을 시스템 프롬프트나 작업 지침에 그대로 넣는다.

검증 결과를 보고하기 전에, 그 검증이 실제로 닿은 환경을 값으로 한 줄 적는다.
- 데이터베이스: 접속한 호스트 이름. 운영 호스트와 같으면 멈추고 보고한다.
- 모델 호출: 어느 경로(개발 도구/운영 API)였고, 길이 상한·사고 설정이 운영과 같은가.
- 브라우저: document.visibilityState 와 탭 포커스.
- 기기·앱: 테스트가 끝난 뒤 지우거나 바꾸는 상태가 있는가.
이 줄이 없는 검증 결과는 '미확인'으로 보고한다.

정체 확인 한 줄은 무엇으로 찍나

환경마다 "정체"를 드러내는 값이 다르다. 미리 목록으로 정해 두면 에이전트가 고민하지 않는다.

1. 데이터베이스 — 연결 문자열의 호스트, 혹은 select current_database(), inet_server_addr(). 브랜치·스테이징이면 운영과 달라야 한다.
2. 외부 API·모델 — 실제 호출한 엔드포인트와 요청 설정(최대 길이, 사고 토큰). 개발 경로로 잰 속도·비용은 운영 수치로 쓰지 않는다.
3. 브라우저 — document.visibilityState 가 visible 인지. 아니면 fps·애니메이션 결과는 버린다.
4. 기기 — 테스트 전후로 설치된 앱과 로그인 상태. 지워질 것이면 사람에게 미리 알린다.
5. 배포 — 확인한 주소가 방금 올린 빌드인지(빌드 번호나 커밋을 응답에 싣는다).

쇼핑몰 예로 옮기면

쇼핑몰의 할인 계산 로직을 고친 에이전트가 "스테이징에서 결제 테스트 10건 통과"라고 보고한다. 이 규칙이 있으면 보고 맨 위에 DB host: …-staging…, 결제 API: 샌드박스 키 한 줄이 붙는다. 그 줄이 운영 호스트였다면 결제 10건은 진짜 고객 장부에 들어간 것이고, 그 사실을 보고 첫 줄에서 알게 된다. 이 줄이 없다면 "통과"는 어디서 통과했는지 모르는 문장이다.

검증은 공짜가 아니다. 그러나 장소를 틀린 검증은 안 한 것보다 비싸다 — 안심까지 함께 준다.