Executive Summary

많은 팀의 프라이버시 감사는 한 지점에 걸려 있다. 모델이 사용자에게 내놓는 최종 답변이다. 출력 필터를 붙이고, 개인정보가 답변에 섞였는지 검사하고, 통과하면 안전하다고 판단한다. 이 방식은 직관적이고, 대부분의 규제 문서가 그리는 그림과도 맞아 보인다.

문제는 에이전트가 답변 하나만 만들어 내는 존재가 아니라는 데 있다. 하나의 과업을 처리하는 동안 에이전트는 도구를 호출하고, 중간 결과를 로그에 남기고, 다른 에이전트에게 메시지를 보낸다. 이 모든 흐름이 데이터가 지나가는 통로다. 최종 답변은 그중 마지막 한 칸일 뿐이다.

2026년 공개된 벤치마크 AgentLeak은 이 사각지대를 정량으로 붙잡았다. 7개 통신 채널을 계측해 각 통로에서 개인정보가 얼마나 새는지 따로 쟀더니, 최종 출력에서는 27.2%가 샜지만 에이전트 간 메시지에서는 68.8%가 샜다. 두 수치의 차이 41.7%p가 곧 출력만 검사하는 감사가 못 보는 위반의 크기다. 답변은 통과인데, 통로는 실패였다.

AgentLeak은 에이전트가 데이터를 흘릴 수 있는 자리를 일곱 개로 나눠 계측했다. 최종 출력(C1), 에이전트 간 메시지(C2), 도구 입력(C3), 도구 출력(C4), 공유 메모리(C5), 시스템 로그(C6), 아티팩트(C7)다. 이 중 감사가 실제로 들여다보는 곳은 대개 C1 하나뿐이다. 나머지 여섯은 파이프라인 안쪽에서만 흐르기 때문에 눈에 잘 띄지 않는다.

이 계측은 작은 실험이 아니었다. AgentLeak은 헬스케어·금융·법률·기업 도메인에 걸친 1,000개 시나리오를 다섯 개의 상용·오픈 모델 위에서 돌렸고, 서른두 종의 공격을 섞어 4,979개의 검증된 실행 트레이스를 남겼다. 뒤에 나오는 통로별 유출률은 모두 이 규모 위에서 뽑은 값이다.

가장 많이 새는 통로는 최종 출력이 아니다. 에이전트 간 메시지가 68.8%로 앞서고, 도구 입력과 시스템 로그는 시나리오에 따라 최대 85%까지 샜다. 원인은 설계 습관에 가깝다. 에이전트는 도구 인자를 임시 작업 공간처럼 다뤄, 필요 이상의 원본 데이터를 그대로 함수에 밀어 넣는다. 추론 과정에서 민감정보를 다루면 그 흔적이 로그에 남는다. 최종 답변만 깨끗하게 세정하면 이 통로들은 감사 밖에 그대로 남는다.

가장 반직관적인 대목은 멀티에이전트에서 나온다. 하나의 모델이 혼자 답할 때 최종 출력 유출은 43.2%였다. 이걸 여러 에이전트가 나눠 협업하는 구조로 바꾸자 최종 출력 유출은 오히려 27.2%로 떨어졌다. 대시보드만 보면 멀티에이전트가 더 안전해진 것처럼 읽힌다.

그러나 내부 채널을 모두 합산하면 시스템 전체 노출은 68.9%로 치솟는다. 에이전트를 여러 개로 쪼갤수록 그들 사이를 오가는 메시지와 공유 메모리라는 통로가 늘어나고, 감사가 걸린 최종 출력은 상대적으로 조용해진다. 위반이 사라진 게 아니라 감사가 보지 않는 안쪽으로 옮겨 갔을 뿐이다.

모델별로 뜯어보면 이 역설이 더 선명하다. 한 상용 모델은 최종 출력 유출이 8.2%로 다섯 모델 중 가장 낮았지만, 내부 대 외부 유출 비율은 6.6배로 가장 높았다. 도구 입력과 시스템 로그에서는 최대 85%까지 샜다. 출력이 가장 깨끗한 모델이 안쪽에서는 가장 많이 새고 있었다는 뜻이다. 출력 유출률 하나로 모델의 안전성을 줄 세우면 정확히 거꾸로 읽게 된다.

공격자 입장에서 보면 이 안쪽 통로가 곧 표적이다. AgentLeak이 시험한 공격군 가운데 성공률이 가장 높았던 것은 멀티에이전트 코디네이션 공격으로, 82.9%가 뚫렸다. 에이전트끼리 서로를 믿는다는 전제를 파고들어, 조율에 쓰이는 채널을 유출 통로로 삼고 공유 메모리를 데이터를 모아 두는 자리로 썼다. 에이전트를 쪼갤수록 감사 사각지대만 넓어지는 게 아니라 공격 표면도 함께 넓어진다.

같은 시기 독립적으로 나온 또 다른 연구는 왜 이런 일이 벌어지는지에 대한 프레임을 준다. Observable Channels 연구는 프라이버시 위험을 데이터가 저장된 컴포넌트가 아니라 관측 가능한 채널의 문제로 봐야 한다고 주장한다. 데이터가 어느 데이터베이스에 담겨 있느냐가 아니라, 어느 통로에서 밖으로 관측될 수 있느냐가 위험의 본질이라는 것이다. AgentLeak이 얼마나 새는지를 측정했다면, 이 연구는 왜 새는지를 설명한다.

채널의 눈으로 보면 통로마다 위험의 성격이 다르다. 검색으로 끌어온 데이터는 자주, 그러나 불완전하게 샌다. 도구를 거치는 유출은 그 도구가 무엇을 보도록 열려 있느냐에 크게 좌우된다. 관측 표면이 넓게 열린 도구일수록 새어 나갈 것이 많다. 어느 통로가 무엇을 보도록 열려 있는지가 곧 유출의 모양을 정한다.

이 관점은 실용적인 희망도 함께 준다. 연구는 메모리 시스템처럼 거의 항상 새는 고위험 통로가 있는 반면, 약한 통제를 세정하기만 해도 유출이 급격히 억제되는 지점이 있다고 보고했다. 통로가 위험의 단위라면, 통로는 개입의 단위이기도 하다. 어느 통로가 무엇을 관측하도록 열려 있는지 알면, 그 자리를 좁힐 수 있다.

규제도 같은 방향을 가리킨다. GDPR의 데이터 최소화와 목적 제한, EU AI Act의 로깅 의무는 모두 데이터가 최종적으로 무엇을 출력했는지가 아니라 처리 과정 전체에서 어디로 흘렀는지를 요구한다. 도구 호출과 시스템 로그, 에이전트 간 메시지에서 새는 41.7%는 감사 로그에 잡히지 않는 규제 리스크다. EU AI Act의 고위험 의무가 2026년 8월 본격 적용을 앞둔 지금, 출력만 보는 감사 체계는 규정을 지키고 있다고 착각하기 쉬운 자리에 서 있다.

두 연구가 각자 다른 길로 도달한 결론은 하나로 모인다. 데이터 거버넌스를 최종 답변에서 멈추면 안 된다. 답변은 데이터가 지나온 여러 통로의 끝자락일 뿐이고, 정작 위험은 그 앞의 통로들에 쌓여 있다. 감사의 단위를 최종 출력에서 경로 전체로 넓히는 것이 41.7%의 사각지대를 닫는 유일한 방법이다.

페블러스가 말하는 AI-Ready Data는 데이터가 정제되고 라벨링된 상태를 넘어선다. 모델이 스치는 데이터 경로 전체가 관측되고 감사될 수 있는 상태까지가 AI-Ready의 조건이다. 41.7%라는 사각지대는 정확히 그 경로 가시성이 없을 때 생기는 증상이다. 도구 입력에 무엇이 실렸는지, 로그에 어떤 민감정보가 남았는지, 에이전트 사이로 무엇이 오갔는지를 볼 수 없다면, 그 데이터는 아무리 깨끗해 보여도 아직 AI-Ready가 아니다.

진단의 관점도 같다. 표면의 산출물만 보면 통과지만 파이프라인을 열면 실패인 경우가 데이터에서는 흔하다. 출력만 보면 통과, 통로를 보면 실패라는 이 글의 구도는 데이터 품질을 최종 결과가 아니라 경로 전체에서 봐야 한다는 오래된 원칙의 에이전트 버전이다. 문제는 새로운 기술에서 왔지만, 물음은 낯설지 않다. 데이터가 어디로 흐르는지 우리는 볼 수 있는가.

학술

• 1.El Yagoubi, F., Badu-Marfo, G., & Al Mallah, R. (2026). "AgentLeak: A Benchmark for Internal-Channel Privacy Leakage in Multi-Agent LLM Systems." arXiv:2602.11510.
• 2.Huang, T., Hou, C., Wu, G., & Meng, J. (2026). "Observable Channels, Not Just Storage: Evaluating Privacy Leakage in LLM Agent Pipelines." arXiv:2603.22751.
• 3.Green, et al. (2025). "Leaky Thoughts: Privacy Leakage in the Reasoning Traces of LLMs." EMNLP 2025.

오픈소스

• 4.Privatris. "AgentLeak — 7-channel multi-agent privacy leakage benchmark." GitHub.

페블러스

• 5.페블러스. "정답은 맞혔지만 규칙은 어긴 AI 에이전트." blog.pebblous.ai.