Wearing the Agent: From Group Chats to Glasses

URL: https://www.youtube.com/watch?v=s67bE2Ur3bY 날짜: 2026-07-30 채널: AI Engineer (aiDotEngineer) 발표자: Sai Krishna Rallabandi

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

지금까지 업계는 "고객이 1명"인 에이전트만 만들어왔지만, ==다음 세대 에이전트는 여러 사람이 함께 쓰는 그룹 설정(그룹 챗, 가족, 웨어러블) 위에서 하루 종일 작동해야 하며, 이는 보안·메모리·라우팅 설계를 근본적으로 다시 요구한다==는 것이 이 강연의 핵심 주장이다.

• 오늘날 우리가 만드는 거의 모든 에이전트(프로그래밍 어시스턴트 포함, 심지어 엔터프라이즈에 배포된 것조차)는 사실상 "고객 사이즈 1"을 대상으로 설계되어 있다
• 발표자는 Judith라는 에이전트를 친구·가족 그룹 채팅에 8개월간 실제로 배포해 운영한 프로덕션 경험을 근거로 제시한다
• 그룹 설정은 단일 사용자 설정과 근본적으로 다른 문제(프라이버시, 메모리 큐레이션, 발화 타이밍)를 만들어낸다

발표자는 이 문제를 세 축 — 보안 레이어(무엇을 에이전트 메모리에 들일 것인가), 메모리 설계(그룹 챗에서 어떻게 저장·망각할 것인가), 라우팅(정보를 누구에게 보낼 것인가) — 으로 나눠 설명한다.

---

1. 왜 "그룹을 위한 에이전트"가 다음 국면인가

에이전트 구축 자체는 이미 풀린 문제이지만, 지금까지의 모든 설계는 단일 사용자를 전제로 했다는 것이 발표자의 관찰이다.

1.1. 에이전트는 이미 "풀린 문제"다

1. 에이전트의 정의는 단순하다

   1. 3요소 구성: 에이전트는 두뇌 역할을 하는 모델, 그 위에 씌운 오케스트레이션(하니스), 그리고 에이전트가 실제로 뭔가를 하게 만드는 도구(tools) 세트의 결합일 뿐이다
   2. 구축 난이도가 낮다: "오후에 에이전트를 하나 만들면 저녁이 되기 전에 쓸모 있는 일을 하기 시작한다"고 말할 정도로, 오늘날 에이전트 자체를 만드는 것은 어려운 일이 아니다 (트레이스 등 여전히 이슈는 있지만)

2. 그러나 모든 에이전트는 "고객 사이즈 1"이다

   1. 개인용으로 수렴: 프로그래밍 어시스턴트조차 엔터프라이즈에 배포될 때도 결국 한 명의 사용자를 향해 튜닝되어 있다
   2. 다음 질문으로의 전환: 조언자가 했던 말을 인용하며 — "엔지니어로서 열심히 문제를 풀면, 푸는 순간 질문 자체가 살짝 바뀌어 있다" — 다음 에이전트는 단일 고객이 아니라 그룹을 서빙하고, 안경 같은 항상 착용하는(invariable) 웨어러블 위에서 하루 종일(all day) 켜져 있는 형태로 진화할 것이라 예상한다

1.2. 실제 프로덕션 사례: Judith

발표자가 8개월간 친구·가족 그룹에 배포해 운영해온 에이전트 Judith의 실제 대화 로그를 근거로 제시한다.

1. 프라이버시를 스스로 판단한 사례

   1. 컨퍼런스 그룹: 이번 주 컨퍼런스 참석자 그룹에서 "행사장 가는 법"을 물었는데, 에이전트가 그룹에 답하지 않고 사적으로 DM으로 보냄 — 프라이버시 문제를 스스로 인지한 판단
   2. 부부간 일정 조율: 몇 주 전 아내와 함께 이벤트를 준비하며 캘린더를 동기화해 모두가 가능한 시간대를 찾아준 사례

2. 능동적(proactive) 개입 사례

   1. 수면 패턴 인지: 코딩 에이전트 등장 이후 다들 수면 부족 상태로 일하는데, 에이전트가 사용자의 수면 부족과 의사결정 어려움을 인지하고 있었다는 점 자체는 인상적이지 않았지만
   2. 채널 선택의 정교함: 운전 중 안경형 에이전트가 말을 걸 때, 차량 미디어(스피커)로 안내하지 않고 안경으로 직접 속삭이듯 전달해 프라이버시를 지킨 것이 더 인상적인 지점이었다

3. 장기 그룹 대화의 메모리 큐레이션

   1. 진화하는 주제 추적: 친구들 그룹에서 계속 진화하는 하나의 주제를 오래 논의한 사례에서, 에이전트가 관련 있는 콘텐츠·메모리만 큐레이션하고 불필요한 것은 걸러냈다

4. 3살 딸의 학습 도우미 사례

   1. 아이용 애플리케이션: 3살 딸이 국가의 수도, 숫자 등을 배우는 데 에이전트를 사용
   2. 부모에게 진행 상황 공유: 아이가 배운 내용을 잊지 않도록 하면서, 동시에 부모도 아이의 학습 진행 상황을 계속 인지할 수 있게 함

이런 그룹 배포 시도 자체는 유일무이한 것이 아니며, 최근 6~8개월간 통제된 시나리오 하에서 그룹 설정 에이전트를 시험해온 여러 시도가 있었고, 이는 "그룹 설정 에이전트"라는 영역이 성장하고 있음을 보여준다.

---

2. 보안 레이어: 에이전트를 위한 "게이트" 설계

발표자는 이 보안 레이어를 인도 신화 속 인물의 이름을 따 "제토우(Jetou)"라 부르며, LLM 보안과 에이전트 시스템 보안은 근본적으로 다르다고 강조한다.

2.1. LLM 보안과 에이전트 보안은 다른 문제다

1. 핵심 태그라인

   1. "LLM을 지키듯 에이전트 시스템을 지킬 수 없다": LLM이 환각을 일으키면 출력을 검사하고 그 위에 방어 장치를 설계할 수 있지만, 에이전트 시스템은 LLM 외에도 실제 사물(웹페이지, 파일, 계정 등)을 다루기 때문에 노출 표면(surface area)이 훨씬 넓고, 이것이 그룹 설정에서는 더욱 증폭된다

2. 그룹 설정에서 증폭되는 공격 표면

   1. 끊임없는 외부 입력 노출: 개인 설정에서도 에이전트는 모든 웹페이지를 지나가며 프롬프트 인젝션 등 다양한 공격에 노출되는데, 그룹 채팅에서는 구성원이 스크린샷을 찍어 업로드하는 것까지 포함해 매일 모든 그룹 메시지에 노출된다
   2. 다양한 채널의 누적 위험: 추적 업데이트를 위해 읽는 모든 GitHub 이슈(최근 토큰 탈취 사례들 다수 발생), 프로모션 이메일을 포함한 모든 이메일까지 에이전트가 읽는 모든 채널이 취약점 노출 지점이 된다
   3. 완전 차단은 불가능: 모든 것을 막고 걸러낼 수는 없으므로 보안 레이어 설계에는 균형이 필요하다 — 이 지점이 전형적 LLM 보안과 다른 이유다

2.2. 근거 논문: "정적 스캔은 런타임 안전을 보장하지 못한다"

1. 두 편의 논문이 보여주는 현상

   1. 정적 스캔은 통과해도 런타임에서 실패: OCR 모듈과 리포팅 모듈 두 개의 스킬이 각각 정적 스캔은 깨끗하게 통과하지만, 런타임 스킬 감사(runtime skill audit)에서는 정적 스캔을 통과한 코드가 런타임에 깨질 수 있음이 확인됨
   2. "안전한 스킬들의 충돌(when safe skills collide)": 표면적으로는 각각 무해한 두 스킬이 함께 실행되면 악성으로 변할 수 있다는 것이 확인됨

2. 구체적 공격 시나리오

   1. OCR + 리포팅 조합 공격: 공격자가 에이전트가 읽는 콘텐츠를 공격 대상으로 삼으면, OCR이 정보를 추출하고 리포팅 에이전트가 그 정보를 전달하면서 PII까지 함께 제3자에게 전송해버리는 결과가 나온다
   2. 드문 현상이 아니다: 논문에 따르면 이런 유형의 공격이 관찰된 공격의 약 90%에서 나타났다 — 통계적으로 낮은 빈도의 예외적 현상이 아니라는 뜻

2.3. 방어 설계: 입력이 아니라 "행동 지점"에서 막아라

1. 1차 방어: 결정론적(deterministic) 경계 가드

   1. 입력을 막지 말고 행동을 막아라: 에이전트가 무엇을 읽는지를 막는 대신, 에이전트가 모든 것을 읽게 두고 대신 "행동을 취하는 시점"에 결정론적 가드를 둔다 — 예를 들어 bash 변수를 읽거나, 무언가를 export하거나, config의 secret 변수를 읽는 시점
   2. 속도 이점: 결정론적 방식이므로 빠르고 레이턴시 이슈가 없다
   3. 3단계 분류 체계: 전통적 NLP나 정규식(regex) 기반 접근으로 무해한 것은 허용하고 일부는 승인이 필요하다는 식의 3단계 분류를 1차 방어(naive approach)로 삼을 수 있다

2. 2차 방어: 학습된 모델(SLM) 기반 가드

   1. LoRA 파인튜닝된 SLM: Judith 내부에는 데이터를 살펴보고 악성 여부를 예측하도록 지도 학습(supervised fine-tuning)된 SLM 컴포넌트가 있으며, 데이터 채널과 명령(instruction) 채널을 분리해 순수하게 무해한 정보만 내보내도록 설계했다
   2. 이상적 동작 예시: "이 페이지를 요약해줘"라는 지시가 왔을 때 크롤링한 웹사이트에 프롬프트 인젝션 공격이 섞여 있어도, 모델은 그 정보를 무시(obscure)하고 요청된 작업만 정확히 수행한다
   3. Inspect Agent 벤치마크 결과: naive approach(정규식 기반)는 50%(동전 던지기 수준)에 그치지만, 학습된 모델은 이를 개선한다
   4. 흥미로운 취약점 사례: 텍스트를 점으로 띄엄띄엄 쓰는 공격(예: "l.i.k.e" 식으로 글자 사이에 점을 넣는 방식)에는 정규식/정적 접근법 대부분이 실패하지만, 학습된 모델은 이런 패턴도 잡아낼 수 있다는 점이 확인됨

3. 결론적 원칙

   1. 입력 게이팅이 아니라 행동 지점 게이팅: 개인용이든 그룹용이든 보안 레이어는 모든 것을 막아버리는 입력 단계가 아니라 에이전트가 실제로 작업을 수행하는 지점(action surface)에서 설계해야 한다
   2. 정규식보다 학습 모델: 정규식·전통 NLP 같은 naive 접근보다, 지속적으로 개선(hill climbing) 가능한 학습 모델을 만드는 편이 더 나은 방향이다

---

3. 메모리 설계: 그룹 챗에서는 메모리가 곧 에이전트의 인격이다

입력이 모델에 들어온 다음, 그룹 설정에서 특히 중요해지는 것이 메모리를 어떻게 조직하느냐다. 발표자는 개인용 설정에서는 임베딩이나 파일 기반의 단순한 메모리 구현으로도 충분하지만, 그룹 챗에서는 "모델은 엔진일 뿐, 메모리가 곧 에이전트 자체가 된다"고 강조하며, 실시간으로 계속 진화하는 이 메모리를 다섯 가지 측면에서 다뤄야 한다고 말한다.

3.1. 무엇을 저장할 것인가 (What to store)

1. naive 접근: 전체 저장 후 압축

   1. 일반적 방식: 그룹 챗의 전형적 대화(예: "이 장소로 가자", "이 날짜에 가자" 식으로 이어지는 대화)를 전부 저장하고, 대화가 길어져 오버헤드가 될 때마다 압축(compact)하는 방식이 흔히 쓰인다

2. 더 똑똑한 접근: 원자적 정보(atomic bits) 추출

   1. 핵심 아이디어: 대화 전체를 저장하는 대신, 미래에 다시 필요할 만한 원자적 정보 단위(atomic bits)만 추출한다
   2. 오토레이터(auto-rater) 설계가 핵심: 이런 모델을 만들려면 다음을 판단하는 오토레이터가 필요하다 — 고가치 원자적 사실을 제대로 추출했는가, 그 정보가 관련성이 있는가, 정보들이 계층적으로 연결되어 있는가, 시간이 지나며 중요도가 변하는 시간적(temporal) 측면은 고려됐는가, 현재 쿼리에 맞는 정보를 제대로 검색(retrieve)하고 있는가, 전체를 훑는 대신 그래프 형태로 조직해 지능적으로 검색하고 있는가

3.2. 무엇을 잊을 것인가 (What to forget)

1. 메모리 비대화 문제

   1. 작은 모델로 판단: 메모리가 계속 비대해지면, 어떤 개념/맥락/정보가 중요한지 판단하기 위해 아주 단순한 머신러닝 모델이나 SLM을 학습시킬 필요가 있다

2. 관련성 스코어러(relevance scorer)

   1. "learning what not to forget" 논문 접근: 지속적으로 스코어링하는 관련성 스코어러를 학습하는 방식이 소개된다 — 핵심 단어는 "지속적으로(continually)"인데, 그룹 채팅/그룹 업무 설정에서는 맥락이 계속 진화하고 다른 시점마다 다른 것들이 중요해지기 때문
   2. 지식 기반 압축(knowledge-based compaction): 지속적으로 적응하는 관련성 스코어러를 확보하면, 단순 압축이 아닌 지식 기반 압축을 통해 토큰을 훨씬 더 절약할 수 있다

3.3. 저장된 메모리를 서빙할 때의 인프라 이슈

1. 클라우드 vs 로컬

   1. 서빙 방식 선택: 클라우드 기반 서빙을 쓸지 로컬 기반 서빙을 쓸지 결정해야 한다

2. KV 캐시 인지형 설계

   1. KV 캐시가 깨지는 문제: 모델에 뭔가 영리한 짓(cute)을 하려고 하면 다들 쓰고 있는 KV 캐시가 깨지는 경우가 많다
   2. 해결책: KV 캐싱을 인지한 인젝션 엔진을 만들면 이 문제를 완화할 수 있다

이 다섯 가지(저장 대상, 오토레이터, 망각 기준, 관련성 스코어링, 서빙 인프라) 요소는 개인용 에이전트의 메모리 설계와는 다르며, 그룹 설정에서 특히 중요해진다.

---

4. 프라이버시: 공유 어시스턴트는 "새로운 사회적 계약"이다

강연의 마지막 파트는 프라이버시를 다루며, 발표자는 공유 어시스턴트가 단순히 여러 사람이 나눠 쓰는 하나의 모델이 아니라 거의 새로운 사회적 계약에 가깝다고 표현한다.

4.1. 같은 정보도 맥락에 따라 공개/비공개가 바뀐다

1. 공개-비공개의 맥락 의존성

   1. 예시 대비: 장보기 목록은 누구에게나 무해(benign)한 정보지만, 급여나 건강 정보는 극도로 사적이면서 동시에 공개적일 수도 있는 정보다 — 데이터 자체는 변하지 않았지만 "그 정보가 발화되는 방(room)"이 달라진 것뿐이다

2. 해결책: 인간 뇌에서 영감을 얻은 공유 메모리 + 개인별 어댑터

   1. 공통 메모리 + LoRA 어댑터: 매번 모든 데이터를 저장하는 대신, 공통으로 공유되는 메모리 레이어를 두되 각 사용자별로 다른 LoRA 어댑터를 학습시켜 그 위에 얹는 방식을 제안한다
   2. 코드가 아닌 ML로 권한을 굽는다: 이렇게 하면 권한(permission)이 코드가 아니라 머신러닝 자체에 의해 내재화(baked in)된다
   3. 참고 논문: "The user as an engram" 논문이 이를 스케일 있게 구현하는 좋은 참고 자료로 제시된다

4.2. 언제 말하고 언제 말하지 않을지 판단하기

1. 그룹 배포 에이전트의 공통적 결함

   1. 과도한 발화 경향: 그룹 설정에 배포된 에이전트들에서 공통적으로 관찰되는 현상은, 질문받지 않았을 때도 지나치게 능동적이고 말이 많아지는(over-articulative) 경향이다

2. 진행 중인 해법: 발화 타이밍을 판단하는 분류기

   1. 역할과 발화 시점을 학습: 간단하게는 RoBERTa 기반 분류기 정도로도 구현 가능하며, 에이전트의 역할과 언제 말해도 되고 언제 말하면 안 되는지를 판단하도록 모델을 학습시키는 접근이 현재 진행 중(work in progress)이다

---

결론 및 시사점

발표자는 그룹 에이전트를 위한 하니스를 설계할 때 최소 세 가지를 반드시 염두에 두어야 한다고 강연을 마무리한다.

1. 보안 레이어(게이트): 맥락에 따라 정보를 걸러내거나 차단하는 게이트를 입력이 아니라 행동(action) 지점에 설계해야 한다 — 정규식 기반 naive 접근에서 시작해 LoRA 파인튜닝된 SLM으로 고도화하는 방향
2. 메모리(하니스) 설계: 무엇을 저장하고, 어떻게 원자적 사실을 추출하고, 언제 무엇을 잊을지, 그리고 서빙 인프라(클라우드/로컬, KV 캐시)까지 다섯 가지 축을 지속적으로 관리해야 한다
3. 정보 라우팅: 토큰 절약을 위한 모델 라우팅이 아니라, 최종 정보를 "책임 있는 당사자"에게 정확히 전달하는 라우팅 — 프라이버시를 지키면서도 필요한 사람에게만 정보가 도달하도록 설계해야 한다

궁극적으로 다음 세대 에이전트는 한 명이 아니라 그룹을 위해, 하루 종일 켜져 있는 웨어러블 위에서 작동해야 하며, 이는 지금까지의 "고객 사이즈 1" 설계 전제를 근본적으로 재고하게 만든다.

---

주요 발언 모음

"An agent is nothing but a combination of systems model which is the brain of the agent... some form of orchestration around it and a set of tools that lets the agent do something."

"Almost every agent we build today has the customer of size one... all of them cater to one person."

"You work hard as an engineer to solve a problem and then the moment you solve it, you realize that the question itself has slightly changed."

"We can't secure an agentic system like we secure a large language model."

"We can't read our way or we can't model check our way to safety."

"The model is just the engine especially when it comes to a group chat... the memory is what the agent becomes and it's becoming in real time, it's evolving in real time."

"A shared assistant is not just a large model which is shared between different people but it's almost a new social contract... the data has not changed, the room in which it is deployed has changed."

핵심 데이터 & 수치

• 90%: 안전해 보이는 두 스킬(OCR + 리포팅)이 결합해 악성으로 변하는 공격 패턴이 관찰된 공격의 약 90%를 차지한다는 논문 수치
• 50%: Inspect Agent 벤치마크에서 정규식 기반 naive 보안 접근의 성능 — 동전 던지기 수준
• 8개월: 발표자의 에이전트 Judith가 친구·가족 그룹 채팅에 실제 배포되어 운영된 기간
• 6~8개월: 업계에서 통제된 시나리오 하에 그룹 설정 에이전트를 시험해온 최근 기간

메타데이터

• 원본 URL: https://www.youtube.com/watch?v=s67bE2Ur3bY
• 채널: AI Engineer (aiDotEngineer)
• 발표자: Sai Krishna Rallabandi
• 발행일(수집 기준): 2026-07-30
• 영상 길이: 약 15분 (컨퍼런스 세션)
• 처리일: 2026-07-30