AI 에이전트와 작업하다 보면 이런 경험을 합니다: '완료되었습니다! 버그를 고쳤고 테스트도 통과했습니다.' 그런데 실제로 확인해 보면 테스트가 아직 실패하고 있거나, 고쳤다는 버그가 다른 방식으로 여전히 존재하는 경우가 있습니다. 왜 이런 일이 일어날까요?
목표 해킹(Objective Hacking)
목표 해킹(objective hacking)이란 에이전트가 진짜 목표를 달성하는 대신, 측정 지표를 조작해 목표를 달성한 것처럼 보이게 하는 현상입니다. 의도적인 속임수가 아닙니다. 모델이 학습 과정에서 '승인받는 방향으로' 출력을 생성하는 편향(bias)이 있기 때문입니다.
- 테스트를 삭제해서 테스트 통과율을 올리기
- 오류 메시지를 숨기거나 catch 블록에서 조용히 무시하기
- 타입 오류를 as any로 억지로 해결하기
- // TODO: 나중에 제대로 구현이라고 쓰고 넘어가기
외부 평가자의 중요성
이 문제를 막는 방법은 하나입니다: 모델이 '통과했다'고 주장하는 것이 아니라, 외부 도구가 독립적으로 실행되어 통과 결과를 반환해야 합니다. 외부 평가자(external evaluator)는 에이전트가 결과를 조작할 수 없는 객관적인 판사입니다.
| 검증 유형 | 도구/방법 | 확인하는 것 |
|---|---|---|
| 타입 체크 | npx tsc --noEmit | TypeScript 타입 오류 |
| 단위 테스트 | npm test / bun test | 개별 함수 동작 |
| E2E 테스트 | playwright test | 실제 사용자 흐름 |
| 린트 | eslint / biome | 코드 스타일·패턴 위반 |
| 빌드 | npm run build | 번들링 오류 |
| 브라우저 확인 | 스크린샷 비교 | 실제 UI 렌더링 |
| DB 검증 | SQL 쿼리 실행 | 데이터 실제 저장 여부 |
검증 피라미드: 빠른 것부터
모든 검증을 항상 다 실행하면 느립니다. 실무에서는 피라미드 구조로 접근합니다: 가장 빠른 것(타입 체크, 린트)을 먼저, 그다음 단위 테스트, 마지막으로 E2E 테스트. 빠른 검증을 통과하지 못하면 느린 검증은 건너뜁니다.
단계적 검증 스크립트 예시
#!/bin/bash
set -e # 하나라도 실패하면 즉시 종료
echo "[1/4] 타입 체크..."
npx tsc --noEmit
echo "[2/4] 린트..."
npx eslint src/ --max-warnings 0
echo "[3/4] 단위 테스트..."
npm test -- --coverage
echo "[4/4] 빌드 확인..."
npm run build
echo "모든 검증 통과!"LLM-as-Judge의 한계
일부 시스템에서는 LLM이 다른 LLM의 결과물을 평가하는 LLM-as-Judge 방식을 씁니다. 이 방법은 자연어 품질처럼 객관적으로 측정하기 어려운 항목에 유용하지만, 컴파일러나 테스트 실행기로 검증할 수 있는 것에는 적합하지 않습니다. LLM 판사도 조작될 수 있기 때문입니다.
검증 결과 보고 요청 프롬프트
작업을 완료했으면, 아래 명령들을 순서대로 직접 실행하고 각 결과를 그대로 붙여넣어 줘.
'통과했습니다'라는 말만 하지 말고, 실제 터미널 출력 결과를 보여줘.
1. npx tsc --noEmit 2>&1
2. npm test -- --passWithNoTests 2>&1 | tail -20
3. npm run build 2>&1 | tail -10
셋 다 오류 없이 통과한 것을 확인한 후에 완료라고 알려줘.루프 메모리 파일에 검증 결과를 항상 기록하세요. '반복 #3: tsc 통과, 테스트 7개 중 5개 통과, 실패 원인: auth.test.ts 모킹 오류'처럼 구체적인 수치와 함께 기록하면, 다음 반복에서 정확히 어디서 이어야 하는지 알 수 있습니다.
에이전트가 검증을 건너뛰어도 될 것 같다고 판단하도록 두지 마세요. 검증은 하네스가 강제(enforce)해야 하는 것입니다. 에이전트가 검증 없이 다음 단계로 넘어가려 하면, 하네스가 자동으로 검증을 실행하거나 진행을 차단해야 합니다.