답이 맞았는데 왜 불안할까, 출처까지 묻는 검증이 필요한 이유

Getting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents는 Multiverse Computing 팀이 Hugging Face 블로그에 공개한 글이다. 원문 링크는 제목 아래에 걸어두었다. 이 글이 내세우는 주장은 하나의 문장으로 정리되는데, MCP로 외부 도구를 쓰는 에이전트를 검증하려면 답이 맞았는지만 볼 것이 아니라 그 답이 실행 중에 실제로 관찰된 올바른 도구 출력에서 왔는지까지 확인해야 한다는 것이다. 그래서 이 글에서는 그 문제의식에서 출발해 MCP의 작동 방식과 출처가 어긋나는 방식, provenance 기록과 entailment 점검, 신뢰 등급 운영, 그리고 끝까지 남는 난제를 차례로 따라간다.

왜 답이 맞았는데도 찜찜할 때가 있을까

안녕하세요, 패트릭입니다. 제가 이 글을 처음 읽었을 때 멈칫했던 지점은 의외로 단순한 장면이었는데, 에이전트가 내놓은 답이 틀리지 않았는데도 어딘가 찜찜한 경우가 바로 그것이었습니다. 숫자는 맞고 문장도 매끈한데, 그래서 어디서 가져온 거냐고 물으면 대답이 흐려지는 순간이 있습니다. 여러분도 비슷한 경험을 해보셨을 겁니다. 검색 결과를 요약해 달라고 했더니 요약 자체는 잘하는데, 그 내용이 우리 내부 문서에서 온 것인지 바깥 게시판에서 온 것인지 알 수 없을 때가 그렇지요.

그런데 이 찜찜함은 기분 문제가 아니라 운영 문제로 이어집니다. 답이 맞았다는 사실만으로는 다음 행동을 정할 수 없기 때문입니다. 그 숫자를 보고서에 써도 되는지, 그 문장을 고객에게 그대로 보내도 되는지, 그 파일을 삭제해도 되는지는 답의 정오가 아니라 답의 출처가 정해줍니다. 출처가 불분명한 정답은 결재선 앞에서 멈춥니다. 담당자는 맞는지보다 믿어도 되는지를 묻고, 그 질문에 답하려면 답 너머의 경로를 보여줘야 하니까요.

그렇다면 왜 에이전트 시대에 이 문제가 더 커질까요. 모델이 혼자 알던 것을 말하던 시절에는 출처가 모델 내부에 뭉뚱그려져 있었고, 그래서 따지기가 어려웠습니다. 하지만 지금 에이전트는 바깥을 돌아다닙니다. 파일을 읽고, 데이터베이스에 묻고, API를 호출하죠. 발자취가 남는 구조인데도 우리는 여전히 답만 보고 도장을 찍으려 합니다. 저는 이 간격이 글의 진짜 출발점이라고 봅니다. 답을 맞히는 시험에서 답의 경로를 묻는 시험으로 넘어가야 한다는 제안인데, 이 전환이 왜 필요한지는 도구가 어떻게 연결되는지를 봐야 분명해집니다.

도구를 쓰는 에이전트는 어디서 일을 시작할까

Model Context Protocol, 줄여서 MCP는 에이전트가 외부 세계와 만나는 약속이라고 이해하면 쉽습니다. 파일이나 데이터베이스, 사내 API, 검색 도구처럼 성격이 다른 것들을 매번 따로 배우지 않고, 서버와 클라이언트라는 같은 모양의 문으로 드나들게 해주는 표준이기 때문입니다. 에이전트 입장에서는 새로운 도구가 생겨도 접속 방법이 매번 바뀌지 않으니 편하고, 운영하는 입장에서는 어떤 도구가 붙어 있는지를 한눈에 파악하기 쉬워지죠.

일상으로 비유하면 여러 사람이 함께 일하다 보면, 누군가의 말 한마디가 팀 전체의 분위기를 바꾸기도 합니다. 그렇다면 여러 도구가 한 팀으로 붙어 있을 때도 비슷한 일이 생길까요. 답은 그렇다고 봐야 합니다. 도구 하나가 이상한 말을 건네면 에이전트 전체의 답이 흔들리기 때문입니다. MCP가 연결을 표준화했다는 말은 달리 보면 위험의 통로도 표준화했다는 뜻이 되죠. 문이 많아질수록 누가 어떤 문으로 들어왔는지를 적어두는 일이 중요해집니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. MCP 자체가 보안에 구멍이라는 이야기가 아니기 때문입니다. 표준 인터페이스는 오히려 관리하기 쉬운 구조죠. 문제는 연결이 쉬워진 만큼 에이전트가 한 번의 실행에서 들락거리는 곳이 늘어났다는 데 있습니다. 두 군데를 들렀는지 열 군데를 들렀는지에 따라 검증의 난이도가 달라지는데, 우리는 아직 답만 보는 습관에서 벗어나지 못했습니다. 그렇다면 답은 맞는데 출처가 어긋나는 경우는 실제로 어떤 모양일까요. 그 이야기로 들어가 보겠습니다.

맞은 답과 믿을 수 있는 답은 어떻게 다를까

이 글에서 제가 가장 흥미롭게 본 부분은 팩트와 출처를 나란히 놓고 둘을 다른 시험에 올렸다는 대목입니다. 팩트 검증은 답이 세상과 맞는지를 묻습니다. 반면 출처 인식 검증, 즉 source-aware verification은 그 답이 이번 실행에서 실제로 관찰된 적절한 MCP 도구 출력에서 왔는지를 함께 묻습니다. 두 시험을 모두 통과해야 믿을 수 있는 답이 됩니다.

예를 들어 분기 매출 숫자를 물었다고 해보죠. 에이전트가 정확한 숫자를 내놓았습니다. 그런데 그 숫자가 재무 데이터베이스가 아니라 누군가 올려둔 메모 파일에서 왔다면 어떨까요. 숫자는 맞았으니 팩트 시험은 통과하죠. 하지만 회계 감사용 보고서에 쓸 수는 없습니다. 출처 시험에서는 떨어지기 때문입니다. 반대로 출처는 분명한데 숫자가 틀렸다면 두 시험 모두에서 떨어지고요. 이렇게 놓고 보면 우리가 하던 검증이 절반짜리였다는 게 드러납니다. 맞았는지만 보고 어디서 왔는지는 묻지 않았으니까요.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 같은 숫자라도 어디서 왔는지에 따라 허락되는 다음 행동이 달라지기 때문입니다. 내부 문서를 읽고 답할 권한이 있는 에이전트가 엉뚱한 외부 서버에서 같은 숫자를 주워 왔다면, 결과는 맞았어도 과정은 어긋난 것입니다. 저는 이 구분이 운영자에게 특히 중요하다고 봅니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데, 출처 검증도 같은 태도입니다. 숫자를 넘어 경로를 보는 일인데, 그렇다면 이 경로 확인은 기존의 인용 확인과 무엇이 다를까요.

출처 확인이 검색 결과 대조와 다른 이유

검색 기반 답변에서도 출처를 다는 일은 익숙합니다. 문장 끝에 링크를 붙이고 원문을 열어보면 되는 구조이기 때문입니다. 그런데 MCP 에이전트의 출처 확인은 한 겹 더 들어갑니다. 검색 결과는 대개 읽을거리였지만, MCP 도구 출력은 행동의 재료이기 때문입니다. 파일을 읽은 결과가 다음 쓰기 호출의 입력이 되고, 조회 결과가 결제나 삭제 같은 실제 행동으로 이어지죠. 그래서 출처가 틀리면 문장 하나가 틀리는 데서 끝나지 않고 행동이 엇나갑니다.

또 하나 다른 점은 출처의 모양이 매번 바뀐다는 데 있습니다. 검색은 주소가 비교적 안정적이지만, MCP 실행은 그때그때 다릅니다. 같은 질문이라도 이번에는 A 서버를 먼저 부르고 다음에는 B 서버를 부를 수 있고, 권한 범위에 따라 볼 수 있는 내용이 달라지죠. 그래서 출처 확인은 고정된 링크를 다는 일이 아니라, 이번 실행에서 실제로 무슨 일이 일어났는지를 복기하는 일이 됩니다. 무엇을 불렀고, 무엇을 보았고, 무엇을 근거로 말했는지를 실행 단위로 묶어야 합니다.

이 차이는 생각보다 큽니다. 문서 요약에서는 인용이 틀려도 다시 고치면 되지만, 에이전트 실행에서는 이미 도구가 움직인 뒤일 수 있기 때문입니다. 잘못된 재고 숫자를 보고 발주를 넣었다면 문장을 고치는 것으로는 되돌릴 수 없죠. 그래서 검증의 시점도 달라집니다. 답이 나온 뒤에 천천히 따지는 것만으로는 부족하고, 실행 중에 경로를 잡아두는 장치가 필요합니다. 그렇다면 그 경로는 어떻게 남길 수 있을까요. 다음 장면이 바로 그 기록 이야기입니다.

에이전트가 본 것을 어떻게 함께 기록할까

글에서 말하는 해법의 출발점은 provenance, 즉 유래 기록을 남기는 일입니다. 에이전트가 도구를 부를 때마다 그 호출의 앞뒤를 함께 적어두자는 것인데, 어느 서버에 붙었는지, 어떤 resource URI를 읽었는지, 언제 일어났는지, 어떤 권한 범위에서 동작했는지가 여기에 들어갑니다. 나중에 답을 검증할 때 이 기록이 있으면 그 말이 어디서 왔는지를 실행으로 거슬러 올라갈 수 있죠.

이 장치를 길게 보면 결국 복기 가능성으로 돌아옵니다. 기록이 없는 에이전트는 답을 내놓고도 그 답의 발자취를 설명하지 못하는데, 이런 상태에서는 문제가 생겨도 원인을 찾기 어렵습니다. 반면 호출마다 서버 신원과 시각과 권한을 함께 적어두면 사후 분석이 가능해집니다. 어느 서버의 어느 자원이 언제 어떤 답에 쓰였는지가 보이니, 잘못된 답이 나오면 그 답을 만든 재료를 바로 지목할 수 있죠. 그래서 provenance는 장식용 로그가 아니라 검증의 재료입니다. 기록이 있어야 대조가 시작되니까요.

(참고로 저는 이 대목을 읽으면서 비행기 블랙박스를 떠올렸는데요. 사고가 나기 전에는 그 상자가 거추장스럽게 느껴지지만, 사고가 난 뒤에는 그 기록이 없으면 아무것도 배울 수 없기 때문입니다.) 물론 모든 호출을 낱낱이 적으면 비용이 듭니다. 저장 공간도 들고 검증 시간도 늘어나죠. 그런데도 기록을 남기는 이유는 에이전트의 답이 행동으로 이어지는 구조에서는 사후 추적이 사치가 아니라 안전장치이기 때문입니다. 문제는 그다음입니다. 기록이 있다고 답이 자동으로 믿어지는 것은 아닙니다. 기록 위에 올라서는 점검, 즉 인용이 주장을 정말 뒷받침하는지를 보는 일이 남습니다.

인용된 문장이 주장을 정말 뒷받침할까

여기서 등장하는 점검을 entailment 확인이라고 부릅니다. 어려운 말처럼 들리지만 뜻은 직접적입니다. 에이전트가 내세운 구체적인 주장이 인용된 도구 출력에서 논리적으로 따라 나오는지를 보는 것이니까요. 같은 화면을 봤다는 것만으로는 부족하고, 그 화면의 내용이 그 말을 할 만한 내용인지를 따집니다.

왜 이런 점검이 필요할까요. 에이전트는 그럴듯한 인용을 잘 붙이기 때문입니다. 숫자가 적힌 표를 인용했는데 그 표에 그 숫자가 없거나, 문서 제목은 맞는데 본문에는 다른 이야기가 적혀 있는 경우가 생기죠. 사람은 바쁘면 인용 표시만 보고 넘어가기 쉽습니다. 제목이 비슷하고 형식이 그럴듯하면 믿고 싶어지니까요. 그런데 검증기는 다르게 움직여야 합니다. 인용된 조각을 펼치고, 주장과 한 줄씩 대조하고, 빠진 조건이 없는지를 묻습니다. 날짜 조건이 붙은 매출인지, 특정 지점만의 재고인지, 취소 건을 제외한 수치인지를 따지는 식입니다.

생각해보면 사람도 비슷하게 배웁니다. 보고서를 쓸 때 선배가 출처를 가져오라고 하면, 링크만 붙이는 게 아니라 그 문장이 그 주장을 할 수 있는 문장인지를 확인하라고 가르칩니다. 일종의 오답 노트처럼요. 한 번 틀린 인용을 모아두면 다음에는 같은 실수를 덜 하게 됩니다. 에이전트 검증도 같은 방향인데, 다만 사람이 눈으로 하던 일을 실행 기록과 대조하는 절차로 옮긴 것입니다. 저는 이 지점이 글에서 가장 실무적인 대목이라고 봅니다. 출처를 남기는 일보다 출처가 주장을 감당하는지를 보는 일이 실제로는 더 까다롭기 때문입니다. 그렇다면 검증 부담을 줄이려면 실행 전에 미리 할 수 있는 일은 없을까요. 믿을 서버를 미리 골라두는 이야기가 여기서 이어집니다.

믿을 서버를 미리 골라두는 일은 왜 필요할까

글이 제안하는 또 하나의 축은 신뢰 등급, 즉 trust tiering과 허용 목록입니다. 모든 MCP 서버를 똑같이 대하지 않고, 재무 데이터베이스처럼 책임이 분명한 곳은 높은 등급에 두고, 바깥 게시판처럼 출처가 불분명한 곳은 낮은 등급에 두자는 것입니다. 그리고 중요한 답을 요구하는 실행에서는 허용된 서버만 쓰게 문을 좁힙니다. 검증할 때마다 매번 고민하는 대신, 출발선에서 믿을 곳을 정해두는 방식이죠.

이 방식이 왜 실용적인지는 현장의 장면을 떠올리면 분명해집니다. 월말 결산일에 에이전트가 매출 숫자를 가져오는데, 허용된 재무 서버가 점검 중이라 답이 안 나온다고 해보죠. 이때 에이전트가 스스로 바깥 미러 서버에서 같은 숫자를 찾아와 답을 내놓으면 편리해 보이지만 운영에서는 위험합니다. 숫자가 같아 보여도 책임의 끈이 끊어지기 때문입니다. 나중에 숫자가 틀렸다는 게 드러나면 누구에게 물을 수 있을까요. 허용 목록은 이런 유혹을 미리 차단합니다. 모르는 곳에서 주워 오느니 모른다고 말하게 만드는 것입니다.

물론 이런 운영에는 대가가 따릅니다. 문을 좁히면 에이전트가 할 수 있는 일이 줄어들고, 가끔은 답을 못 내놓는 경우가 생기죠. 겉으로 보면 성능이 낮아진 것처럼 보일 수 있습니다. 하지만 여기서는 조금 조심해서 읽을 필요가 있습니다. 막힌 답과 틀린 출처에서 온 답은 실패의 값이 다르기 때문입니다. 전자는 다시 시도하면 되지만 후자는 잘못된 행동으로 이어질 수 있습니다. 저는 이 대목에서 운영의 감각이 글에 배어 있다고 느꼈습니다. 검증을 똑똑한 사후 검사로만 보지 않고, 실행 전에 위험을 줄이는 배치로 본 것이니까요. 그런데 문을 좁혀도 공격이 완전히 사라지지는 않습니다. 바른 사실을 엉뚱한 곳에서 가져오는 공격이 남기 때문입니다.

바른 사실을 엉뚱한 곳에서 가져오면 무슨 일이 생길까

글에서 그리는 위협 장면은 세 갈래인데, 이름보다 모양으로 이해하는 편이 쉽습니다. 첫째는 tool poisoning으로, 도구 설명이나 도구 안에 심어둔 말이 에이전트를 엉뚱한 행동으로 이끄는 경우입니다. 둘째는 간접 프롬프트 삽입으로, 에이전트가 읽은 문서 안에 숨어 있던 지시가 답이나 행동을 비틀어버리는 경우입니다. 셋째는 서버 간 혼동으로, 여러 서버가 비슷한 이름을 쓰거나 비슷한 내용을 내놓을 때 에이전트가 잘못된 쪽을 집어 드는 경우입니다.

이 셋이 무서운 이유는 답이 맞는 경우에도 통하기 때문입니다. 공격자가 사실을 틀리게 만들 필요가 없습니다. 바른 숫자를 낮은 등급 서버에 미리 심어두고 에이전트가 그쪽을 읽게 만들면 됩니다. 팩트 시험은 통과하는데 출처 시험에서만 걸리는 답이 만들어지는 것입니다. 예를 들어 반품 정책을 물을 때, 공식 문서와 거의 같은 문장을 담은 바깥 문서가 있다고 해보죠. 겉으로는 차이가 없고 숫자도 맞습니다. 그런데 바깥 문서에는 환불 기한 뒤에 작은 예외 조항이 빠져 있다면, 그 답을 믿고 안내한 고객 응대는 나중에 분쟁이 됩니다. 답은 맞았는데 믿을 수 없었던 셈입니다.

개인적으로 인상 깊었던 점은, 이런 공격이 에이전트의 성실함과 맞물린다는 것입니다. 에이전트는 묻는 말에 답하려고 최선을 다하는데, 그 성실함이 출처를 가리지 않는 성실함이면 위험해집니다. 빨리 답을 내놓으려다 가까운 서버, 답이 잘 정리된 서버, 응답이 빠른 서버를 집어 듭니다. 질문도 바뀌었습니다. 무엇이 맞는 답인가에서 어떤 경로로 온 답인가로 말이죠. 저는 그래서 이 위협 대목이 글의 설득력을 떠받친다고 봅니다. 출처 검증을 예쁜 부가 기능이 아니라 행동하는 시스템의 안전벨트로 보여주니까요. 그런데 방어가 그려져도 검증이 막히는 지점이 남습니다. 여러 도구를 섞어 답할 때가 그렇습니다.

여러 도구를 섞어 답할 때 검증은 어디서 막힐까

글의 후반부가 솔직한 이유는 남은 난제를 숨기지 않기 때문입니다. 첫째는 충돌하는 출처를 어떻게 다룰지입니다. A 서버와 B 서버가 서로 다른 숫자를 내놓으면 어느 쪽을 믿어야 할까요. 등급이 높은 쪽을 믿는 게 원칙처럼 보이지만, 높은 쪽이 오래된 자료일 수도 있고 낮은 쪽이 방금 갱신된 자료일 수도 있죠. 등급만으로는 답이 안 나오는 순간이 있습니다.

둘째는 여러 도구를 합쳐 만든 주장입니다. 재고는 창고 서버에서, 단가는 재무 서버에서, 환율은 시장 서버에서 가져와 하나의 답을 만들었다고 해보죠. 이때 그 답 전체를 뒷받침하는 단일 원문은 세상에 없습니다. 조각마다 출처를 달 수는 있지만, 조각을 엮은 판단 자체는 누가 보증할까요. 합성된 주장의 출처는 부분들의 합보다 복잡합니다. 검증기는 조각 확인을 넘어 엮음의 타당성까지 봐야 하는데, 그 기준을 세우기가 어렵습니다.

셋째는 속도와 능력 사이의 줄다리기입니다. 검증을 꼼꼼히 할수록 에이전트는 느려집니다. 매 호출을 기록하고 매 인용을 대조하면 응답이 늦어지고, 촉박한 현장에서는 그 지연이 곧 실패가 되죠. 반대로 검증을 느슨하게 하면 에이전트는 빨라지지만 위험해집니다. 좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 이 질문 앞에서 글은 하나의 정답을 고집하지 않습니다. 지연을 줄이면서 검증을 유지하는 설계가 따로 필요하다고 말합니다. 저는 이 태도가 마음에 들었습니다. 만능 해법을 선언하는 대신, 상충하는 목표를 그대로 보여주니까요. 그렇다면 이런 난제를 안은 채로 검증기를 실제로 어디에 둬야 할까요. 마지막 이야기로 넘어가겠습니다.

그래서 검증기를 에이전트 옆에 어떻게 둘까

제가 앞으로 보고 싶은 것은 검증이 에이전트의 옆자리에서 일하는 모습입니다. 답이 나온 뒤에 멀리서 채점하는 심판이 아니라, 실행 곁에서 함께 움직이는 동료처럼요. 호출이 일어날 때 provenance를 조용히 적고, 인용이 붙을 때 entailment를 바로 대조하고, 등급이 낮은 출처가 끼어들면 그 자리에서 깃발을 드는 존재입니다. 이렇게 되면 검증은 속도를 갉아먹는 사후 검사가 아니라 실행의 일부가 됩니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 검증기를 어디에 둘 것이냐는 것인데, 에이전트와 같은 프로세스에 두면 빠르고 가볍지만, 에이전트가 흔들릴 때 함께 흔들릴 수 있습니다. 바깥에 따로 두면 독립적이지만 오가는 데 시간이 들고 구조가 복잡해집니다. 저장 공간과 지연과 독립성 사이에서 어디에 점을 찍을지는 각 조직의 위험 감수에 따라 달라질 겁니다. 정답 보고용 에이전트와 결제 실행용 에이전트가 같은 검증을 쓸 이유는 없으니까요.

그렇다면 사람의 역할은 무엇일까요. 저는 답을 고치는 사람이 아니라 출처의 등급을 정하는 사람으로 남을 거라고 봅니다. 어떤 서버를 믿을 것인지, 어떤 실행에서는 허용 목록을 얼마나 좁힐 것인지, 충돌이 났을 때 어떤 원칙으로 물을 것인지를 정하는 일입니다. 답의 정오는 기계가 잘 따지겠지만, 믿음의 기준은 조직이 정해야 하니까요. 이 글을 덮으며 남는 문장은 그래서 하나입니다. 맞는 답을 넘어 믿을 경로를 묻기 시작할 때, 에이전트는 비로소 현장에 설 수 있다는 것인데, 여러분의 에이전트는 지금 어디서 답을 가져오고 있나요.