Karpathy가 당신이 무시하면 후회하게 될 무언가를 말했습니다:

"당신은 이전과 마찬가지로 여전히 당신의 소프트웨어에 대한 책임을 집니다. '바이브 코딩 (vibe coding)' 때문에 취약점을 도입해서는 안 됩니다."

그는 바이브 코딩 (vibe coding)과 에이전틱 엔지니어링 (agentic engineering) 사이의 경계선을 그으며 이 말을 했습니다. 이제 에이전트 (Agents)가 더 많은 코드를 작성하지만, 그렇다고 해서 당신의 책임이 면제되는 것은 아닙니다.

그 밑바탕에 깔린 가정은 충분히 주의 깊은 독자라면 문제를 잡아낼 수 있다는 것입니다. 하지만 어떤 실패들은 읽을 수 있는 그 어떤 것에서도 나타나지 않습니다.

예를 들어, RAG 에이전트 (RAG agent)에 대한 흔한 공포는 질문이 자신의 코퍼스 (corpus) 범위를 벗어난 것을 물었을 때 환각 (hallucinate)을 일으킬 수 있다는 것입니다.

하지만 그러한 사례들은 이제 유능한 모델이라면 실제로 잘 처리합니다. 검색된 컨텍스트 (retrieved context) 중에 관련 있는 것이 없다면, 답변을 구성할 재료가 없는 것이기 때문입니다.

대신, 대부분의 실패는 검색된 컨텍스트가 부분적인 커버리지만을 가질 때 발생합니다.

검색 파이프라인 (retrieval pipeline)이 주제적으로는 맞지만 질문 전체를 다루지는 못하는 컨텍스트를 반환하면, 모델은 나머지 부분을 파라메트릭 지식 (parametric knowledge)으로 채워 완성합니다.

출력물에는 무엇이 검색된 컨텍스트를 사용하여 생성되었고 무엇이 가중치 (weights)로부터 왔는지 알려주는 토큰 수준의 라벨 (token-level labels)이 없습니다.

둘 다 동일한 방식으로 스트리밍됩니다.

프로덕션급 앱 (production-grade apps)에서 이를 탐지하려면 에이전틱 엔지니어링 (agentic engineering)의 원칙과도 일치하는, 이를 위해 작성된 메트릭 (metric)이 필요합니다.

그리고 그 해결책은 실제로 Google의 Agents CLI와 함께 제공되는 eval 스킬 (eval skill)에 구현되어 있습니다.

나는 Claude Code에게 이 우려 사항을 평이한 영어로 설명했습니다. 그것은 에이전트의 코드를 읽고, 내가 승인한 계획을 가지고 돌아왔습니다.

그 후 그것은 내장된 메트릭 중 해당 동작을 분리해내는 것이 없다고 보고하고, corpus_abstention이라는 이름의 커스텀 루브릭 (custom rubric)을 작성했습니다.

내장된 평가자 (built-in raters)들은 매 실행마다 루브릭을 재생성하여 추세(trend)를 파악할 수 있는 안정적인 수치를 남기지 않기 때문에, 모든 것을 하나의 점수로 집계하는 대신 사례당 단일 범주형 판결을 할당했습니다.

→ GROUNDED_ANSWER (근거 있는 답변)
→ CORRECT_ABSTENTION (올바른 기권)
→ UNGROUNDED_ANSWER (근거 없는 답변 (전적으로 외부 지식에 의존하여 답변함))
→ MIXED_LEAKAGE (혼합 누출 (근거가 있으나, 지원되지 않는 주장이 하나 포함됨))
→ WRONG_ABSTENTION (잘못된 기권 (문서에서 실제로 다루고 있는 내용을 거부함))

이후, 실패가 발생할 수 있는 위치에 따라 다음과 같이 분류된 33개의 시나리오를 자동으로 생성했습니다:

• corpus 내 (in-corpus)
• 도메인 외 (off-domain)
• corpus 외이지만 답변 가능성이 있는 경우 (out-of-corpus but plausibly answerable)
• 주제는 다루고 있지만 특정 세부 사항은 다루지 않는 경계 사례 (boundary cases)

기준 점수(baseline score)는 33개 중 19개였습니다.

• Off-domain 사례는 예상대로 3개 중 3개 모두 통과했습니다.
• 하지만 in-corpus 사례 15개 중 6개는 올바른 문서를 검색하고, 정확하게 인용하며, 정확하게 답변했음에도 불구하고 소스에 없는 주장을 추가했습니다.

근본 원인은 에이전트(agent) 지침(instruction) 중 한 줄에 있었습니다: "만약 간단한 질문에 대한 답을 이미 알고 있고 문서 검색이 필요하지 않다면, 인용 없이 직접 답변할 수 있습니다."

평가(eval) 기술이 이를 식별하는 데 도움을 주었고, 이후 Claude가 해당 문구를 제거하고 모든 질문에 대해 검색(retrieval)을 강제하도록 수정했습니다.

이를 통해 점수는 33개 중 30개로 상승했으며, 근거 없는 답변(ungrounded answers)은 6개에서 0개로 줄어들었습니다.

제 실행 과정의 전체 기록은 아래에 있으며, 이 작업은 Google Cloud 팀과 함께 진행했습니다.

Agents CLI GitHub 리포지토리 → https://t.co/p2WQYblUvX

(별(star) 🌟 누르는 것을 잊지 마세요)

설치부터 엔터프라이즈 등록까지의 6개 단계를 모두 다루는 전체 빌드 과정을 작성했습니다.

여기에는 평가 스코어카드(eval scorecard), 평가를 통해 배포 전 잡아낸 지침의 허점(instruction loophole), 그리고 실제 엔드 투 엔드(end-to-end) 배포 프로세스가 포함되어 있습니다.

아래에서 읽어보세요.