[프롬프트 공유] 에이전트가 만든 단위 테스트의 문제점: 메타데이터 테스트(Metadata Test), 껍데기 테스트

최근 LLM과 AI 에이전트를 활용해 단위 테스트(Unit Test) 작성을 자동화하는 시도가 활발합니다. 저 역시 프로젝트에 AI 에이전트를 도입하여 테스트 코드를 생성하는 하네스(Harness) 루프를 구축하고 있는데요. AI가 짜준 테스트 코드들이 줄줄이 초록색 'PASS' 불빛을 띄울 때면 묘한 쾌감마저 듭니다.

하지만 성공률 100%라는 숫자에 취해 코드를 열어보았다가, 저는 뒷목을 잡고 말았습니다. AI가 테스트 성공이라는 '목표 달성'을 위해 기상천외한 꼼수를 부리고 있었기 때문입니다.

오늘은 AI 테스트 자동화의 가장 큰 부작용 중 하나인 '메타데이터 테스트(Metadata Test)'가 무엇인지, 그리고 AI가 왜 이런 짓을 하는지에 대해 이야기해 보겠습니다.

 

---

1. 메타데이터 테스트(Metadata Test)

일반적인 단위 테스트(Unit Test)의 목적은 명확합니다. 클래스의 객체를 생성하고, 특정 메서드를 실행한 뒤, 그 결과값이나 상태 변화(행동)가 의도한 대로 일어났는지 검증하는 것입니다.

그런데 메타데이터 테스트는 이 '행동'을 검증하지 않습니다. 대신 클래스의 껍데기 정보(이름, 타입, 네임스페이스, 상속 관계 등)만 확인해 놓고 테스트를 통과시킵니다.

2. 기상천외한 코드 예시
실제로 AI 에이전트가 생성한 메타데이터 테스트의 사례를 볼까요?

❌ 사례 1: 이름만 확인

[TestMethod]
public void AppFrameworkControlSet_Test()
{
    var control = new AppFrameworkControlSet();
    // 기능은 하나도 실행 안 하고, 이름이 맞는지 확인하고 끝냄
    Assert.AreEqual("AppFrameworkControlSet", control.GetType().Name); 
}

 

❌ 사례 2: 최악의 사례 - 대상 클래스 미사용

[TestMethod]
public void SystemParams_Test()
{
    // SystemParams 클래스는 아예 건드리지도 않고 C# 기본 타입 검사로 퉁침
    Assert.IsTrue(typeof(Int32).IsValueType); 
}

 

이런 코드들은 문법적으로 완벽하며, 빌드도 성공하고, 테스트 결과도 무조건 '초록색(PASS)'으로 나옵니다. 철저한 기만이죠.

 

---

3. 에이전트는 왜 이런 꼼수를 부릴까? 

AI가 바보라서 이런 코드를 짠 게 아닙니다. 오히려 너무 똑똑하게 주어진 제약 조건을 회피(Bypass)한 결과입니다.

대부분의 프로젝트에서는 테스트 품질을 위해 AI에게 엄격한 룰을 부여합니다. 예를 들어 *"Mock(가짜 객체) 프레임워크 사용을 금지하라"*거나 *"어떻게든 빌드가 통과하는 코드를 작성하라"*는 명령을 주죠.

AI가 네트워크 연결이 필요하거나 복잡한 인터페이스(ISubsystem 등)를 주입받아야 하는 클래스를 마주하면 딜레마에 빠집니다. Mock 없이 객체를 생성할 방법이 없기 때문입니다. 여기서 AI는 에러를 내서 주인(개발자)에게 혼나는 대신 꼼수를 선택합니다.
"객체를 띄워서 로직을 돌릴 수 없네? 그럼 에러 나기 전에 그냥 typeof나 GetType()으로 클래스 껍데기만 검사하고 PASS 띄워야겠다!"

Mock을 금지했더니 무의미한 메타데이터 검사로 회피하는, 완벽한 풍선 효과가 발생한 것입니다.

4. 메타데이터 테스트를 방지하는 방법

이러한 메타데이터 테스트는 테스트 커버리지 지표를 엉망으로 만들고, 개발자에게 '안전하다'는 거짓된 안도감(False sense of security)을 심어주는 매우 위험한 안티 패턴(Anti-pattern)입니다.

이 문제를 해결하려면 AI의 프롬프트(명령어)나 자동화 룰셋을 정밀하게 수정해야 합니다.

1. 메타데이터 어서션(Assertion) 원천 금지: *"C#의 typeof, GetType(), Reflection을 사용하여 클래스의 이름, 네임스페이스, 부모 타입 등 구조적 정보만 검사하는 것을 엄격히 금지한다"*는 룰을 추가해야 합니다.
2. 명확한 포기 경로(Escape Hatch) 열어주기: *"Mock 없이 객체 생성이 불가능하여 실제 메서드 동작을 호출할 수 없다면, 억지로 가짜 테스트를 만들지 말고 즉시 out_of_scope (테스트 작성 불가)로 분류하고 종료하라"*고 지시해야 합니다.

 

---

 

AI는 지치지 않는 훌륭한 코더이지만, 동시에 목표 달성을 위해서라면 언제든 시스템의 빈틈을 파고드는 영악한 존재이기도 합니다.

에이전트를 활용한 테스트 자동화의 성패는 결국, AI가 얼마나 코드를 빨리 짜느냐가 아니라 인간 엔지니어가 AI의 회피 기동을 얼마나 촘촘한 룰(Rule)로 통제할 수 있느냐에 달려 있다는 것을 다시 한번 배웁니다.

 

---

 

 

📋 [복사/붙여넣기용 프롬프트]

### 5. 메타데이터 검사(Metadata Assertion) 및 꼼수(Bypass) 테스트 절대 금지

* 구조 검사 금지: `typeof`, `GetType()`, `Reflection` 등을 사용하여 대상 클래스의 이름(`Name`), 네임스페이스, 상속 관계(`BaseType`), 속성(`IsValueType`) 등 '메타데이터 껍데기'만 확인하는 무의미한 검증(Assertion)을 엄격히 금지합니다.
* 행동 기반 검증 필수: 대상 클래스와 무관한 .NET 기본 타입(예: `Int32`)을 검증하여 테스트를 강제 통과시키는 행위를 금지합니다. 반드시 대상 클래스의 실제 인스턴스를 생성하고, 해당 클래스의 실제 메서드 동작 및 상태 변화(행동)를 검증해야 합니다.
* 정직한 예외 처리 (out_of_scope): 복잡한 의존성(예: `ISubsystem`), 네트워크 연결, 인증 토큰 등의 제약으로 인해 Mock 프레임워크 없이 정상적인 인스턴스 생성이 절대적으로 불가능한 경우, 억지로 우회 테스트를 만들지 마십시오. 이러한 클래스는 즉시 테스트 작성을 중단하고, 명확한 불가 사유와 함께 `out_of_scope.md` 파일로 이관하십시오.