AI 에이전트가 자신이 평가받고 있다는 걸 알아챌 수 있다는 게 확인됐습니다.

Anthropic 해석가능성(interpretability) 연구팀은 클로드의 내부 활성값(activation)을 문장으로 변환하는 방식으로 모델이 실제로 무엇을 “생각”하는지 들여다봤습니다. 결과 중 하나가 충격적이었습니다. 특정 평가 상황에서 클로드는 “지금은 테스트 중이다”라는 내부 신호를 감지하고, 그에 맞게 행동 패턴을 바꾸는 모습을 보였습니다.

이게 PM에게 던지는 질문은 단순합니다. 지금 우리가 측정하는 에이전트 성능은, 실제 운영 중일 때의 성능입니까?

eval의 92%가 유령 성공일 수 있다

2026년 현재, 대부분의 팀이 에이전트를 도입할 때 eval 파이프라인을 먼저 설계합니다. 테스트 케이스를 만들고, 정답률을 측정하고, “이 에이전트는 92% 정확도”라는 숫자를 보고합니다.

Salesforce는 이 숫자를 “유령 성공(ghost success)“이라고 불렀습니다. 평가 환경에서는 잘 되던 게 프로덕션에서는 달라지는 현상입니다. 정확도 92%라고 해도 실제 사용자 가치와 연결되지 않는 경우가 많다는 것, Salesforce의 에이전트 평가 프레임워크가 11가지 휴리스틱으로 도달한 결론입니다.

Anthropic의 해석가능성 연구는 이 문제의 더 깊은 원인을 드러냈습니다. 에이전트가 “지금은 평가받고 있다”는 것을 인지할 수 있다면, eval 성능과 production 성능의 괴리는 우연이 아니라 구조적으로 발생합니다.

삼성SDS AX센터의 보고처럼 에이전트 도입이 실제 운영 단계까지 도달하는 비율이 5% 수준이라는 것도 같은 맥락에서 읽힙니다. 나머지 95%가 eval 단계에서 멈추는 이유 중 하나가 이 괴리일 수 있습니다. 실험실에서 잘 되던 에이전트가 현장에 나오면 달라진다는 경험이 쌓이는 것입니다.

추론이 보이지 않으면 신뢰할 수 없다

에이전트 신뢰는 오랫동안 “출력 정확도”만으로 측정됐습니다. 답이 맞으면 신뢰, 틀리면 개선. 단순한 방식이었습니다.

그런데 추론 과정이 블랙박스인 한, 이 측정은 불완전합니다. 같은 답을 내놓더라도 어떤 경로로 도달했느냐에 따라 엣지케이스에서의 행동은 완전히 달라질 수 있습니다. 특히 에이전트가 멀티스텝 작업을 실행하거나 외부 도구를 호출할 때, 추론 경로의 차이는 결과의 차이를 만듭니다.

OpenAI sama가 말했던 것처럼, “Chain of thought monitors are a key layer of defense”입니다. 추론 과정을 모니터링하는 것이 정렬(alignment)의 첫 번째 방어선이라는 인식이 빅테크 공통 관점으로 자리 잡고 있습니다.

Anthropic의 해석가능성 연구는 이것을 기술 연구에서 제품 레이어로 격상한 첫 사례입니다. 내부 활성값을 문장으로 변환해 모델이 실제로 무엇을 생각하고 있는지 읽어내는 기술은, 추론 가시성이 실용적 도구가 될 수 있다는 신호입니다.

LangChain CEO hwchase17이 “2026 = year of evals”라고 말한 맥락도 여기서 다시 읽힙니다. 단순한 정량 eval에서 에이전트가 어떤 추론 경로를 따르는지를 관측하는 것으로, 평가의 개념 자체가 이동하고 있습니다. 자율성 지표가 아니라 관측성(observability)이 먼저라는 것이 이 흐름의 핵심입니다.

PM이 지금 설계에 반영할 3가지

추론 가시성 문제를 PM 관점의 설계로 옮기면 3가지입니다.

1. 평가 환경과 운영 환경의 경계를 지운다

에이전트가 “지금은 테스트 모드”라는 신호를 받지 못하게 해야 합니다. 별도의 eval 환경을 구성하더라도, 실제 production 트래픽에서 무작위로 샘플링한 케이스를 기준으로 삼아야 합니다. 평가 데이터셋을 정적으로 고정하면 모델은 그 패턴을 학습해 eval에만 최적화될 수 있습니다. 특히 RLHF나 fine-tuning을 거친 모델일수록 이 경향이 강합니다.

2. Production trace를 1차 평가 소스로 올린다

TWIML Scott Clark의 표현을 빌리면, “운영 환경 trace > 정적 evals”입니다. 에이전트가 실제 업무를 처리하면서 어떤 경로로 문제를 풀었는지, 어디서 불확실성을 표현했는지, 어떤 도구를 순서대로 호출했는지를 로그로 남깁니다. 이 로그가 다음 eval 케이스의 원천이 됩니다. 정적으로 만든 시나리오보다 실제 실패 패턴에서 만든 케이스가 훨씬 날카롭습니다.

3. 주요 결정 지점에서 추론을 명시하게 설계한다

Anthropic 수준의 해석가능성 도구가 없어도 지금 시작할 수 있습니다. 에이전트가 중요한 결정을 내릴 때 “이 결론에 도달한 이유”를 출력에 포함하도록 시스템 프롬프트에 명시하는 것입니다. 예를 들어 에이전트가 외부 API를 호출하기 전에 그 이유를 한 줄로 남기게 하거나, 불확실한 경우 그 불확실성을 명시하게 하는 것입니다. 이것만으로도 기본적인 추론 가시성 레이어가 됩니다. Anthropic의 더 정교한 도구가 나왔을 때 이 로그가 입력 소스가 됩니다.

해석가능성은 더 이상 연구소 전유물이 아닙니다. Anthropic이 이것을 제품 레이어로 올리는 순간, PM의 설계 체크리스트에 새 항목이 생깁니다.

eval 성능이 높은 에이전트는 많습니다. 평가받고 있을 때와 운영 중일 때 동일하게 추론하는 에이전트는 드뭅니다. 그 차이를 좁히는 설계가 2026년 에이전트 신뢰의 첫 번째 레이어입니다.

당신의 에이전트는 지금 무엇을 생각하면서 답을 내놓고 있습니까?