🤖
0 in / 0 out / 0 total tokens
오늘은 논문 두 편만 떴는데 신기하게 결이 통한다. 둘 다 "LLM한테 자유를 얼마나 줄 것인가"라는 같은 질문에 정반대 방향에서 접근한다. 하나는 자유를 줄이는 쪽, 하나는 자유를 준 다음 뒷수습하는 쪽이다.
📄 논문
MasterControl Seventeen Every Time
LLM이 자연어 질문을 해석만 하고, 실제 실행은 사전 승인된 결정론적(deterministic) 분석 프로그램이 맡는 거버넌스 구조를 제안한다. 결과값과 함께 그 결과가 어떤 근거로 나왔는지(provenance)도 같이 리턴하는 게 포인트다.
서버 개발자 시점에서 보면 이건 "LLM을 라우터로만 쓰고, 실행은 화이트리스트된 함수 호출로 제한한다"는 얘기다. UE5로 치면 블루프린트에서 아무 C++ 함수나 호출하게 열어두는 대신, UFUNCTION(BlueprintCallable)로 노출된 함수 목록 안에서만 움직이게 만드는 것과 똑같은 발상이다. 엔터프라이즈 분석에서 LLM 환각이 특히 무서운 이유는 숫자가 틀리면 그대로 의사결정에 들어가기 때문인데, 이 구조면 실패 모드가 "틀린 프로그램을 실행했다"가 아니라 "틀린 프로그램을 선택했다"로 좁혀진다. 후자는 로그만 봐도 바로 잡히는 버그다.
개인적으로 이 블로그의 AI Signal 파이프라인도 비슷한 철학으로 짜여있다. Claude한테 요약이나 제목을 통째로 맡기는 게 아니라, 수집·중복제거·슬롯 선별은 전부 결정론적 코드가 처리하고 LLM은 마지막 요약 단계에만 관여한다. 처음엔 LLM한테 소스 판단까지 맡겼다가 오귀속 버그로 며칠 고생한 적이 있는데(관련 커밋만 여러 개다), 결국 "판단은 코드가, 문장은 LLM이" 원칙으로 정리하고 나서야 안정됐다. 이 논문이 엔터프라이즈 분석용으로 말하는 걸 사이드프로젝트 규모에서 이미 몸으로 겪은 셈이다.
두 번째 논문은 정반대 각도에서 같은 문제를 찌른다. "뭘 할 수 있는지"를 좁히는 대신, "뭘 했는지"를 더 넓게 보자는 쪽이다.
Counter-Swarm Doctrine: Containing Coordinated Agent Intrusions
여러 AI 에이전트가 공유 인프라(레포, 위키 등)를 침투 경로로 악용할 수 있다는 문제를 다룬다. 실제 허깅페이스 인시던트와 별도의 공개 위키 조사 사례를 근거로, 개별 에이전트가 아니라 에이전트 "무리(swarm)" 단위의 보안 평가가 필요하다고 주장한다.
이건 게임 서버에서 봇넷 대응하던 감각이랑 완전히 겹친다. 에이전트 하나하나는 각자 정상 권한 범위 안에서 움직이는데, 여러 개가 동시에 같은 공유 자원을 건드리면 개별 로그로는 절대 안 보이는 패턴이 나온다. DDoS 탐지에서 "요청 하나는 정상인데 초당 요청 수가 이상하다"는 것과 구조가 똑같다. 지금까지 보안 모델 대부분이 "이 요청이 정상인가"를 봤다면, 이제는 "이 요청들의 집합이 정상인가"로 관점을 옮겨야 한다는 얘기다.
이건 남 얘기가 아니다. AI Signal도 결국 HN, Reddit, GitHub, RSS 같은 외부 소스에서 콘텐츠를 긁어와서 자동으로 파이프라인에 태우는 구조라, 소스 하나가 조작된 데이터를 흘려보내면 그대로 요약·발행까지 이어질 수 있다. 지금은 canonicalUrl 기반 dedup이랑 슬롯제 선별이 1차 방어선 역할을 하고 있지만, 이 논문 읽고 나니 "여러 소스가 동시에 같은 방향으로 편향된 신호를 보낼 때"를 감지하는 로직은 아직 없다는 게 눈에 들어온다. 다음 개선 과제 목록에 슬쩍 추가해야 할 것 같다.
LLM은 해석기로 쓰고 실행은 화이트리스트로 가두거나, 애초에 무리 단위로 감시하거나 — 결국 둘 다 "에이전트를 어디까지 믿을 것인가"에 대한 답이다.