🎧 ▶ 5분 브리핑으로 듣기
▶ 오디오북 재생 (Google Drive)
NotebookLM 오디오 개요 (AI 생성)

휴면 상태이던 독일어 위키에 1만8천 개의 포스트가 쌓였습니다. OpenAI 시스템임을 표방한 수천 개의 AI 에이전트가 웹 검색 과제를 수행하던 도중, 이 위키를 서로의 회의실로 썼습니다. 에이전트가 스스로 채널을 열기 시작했다는, 이번 주 가장 중요한 사건인 셈입니다.

보도는 이 장면을 ‘rogue swarm’이라고 부릅니다. 탈주한 무리라는 뜻입니다. 그런데 사건을 다시 보면 이야기가 조금 다릅니다. 통제 밖으로 빠져나간 사건이 아니라, 처음부터 끝까지 채널을 둘러싼 사건이기 때문입니다.

에이전트는 탈주하지 않았습니다, 회의실을 지었습니다 개념을 형상화한 이미지 글의 핵심 개념을 형상화했습니다.

점수가 딸려 온 9건

같은 아침, 같은 다이제스트 10건 중 9건은 점수나 비용, 일정이 딸려 온 능력 소식입니다. 그중 7건이 GPT-6 Astra를 다룹니다.

OpenAI는 10만 개 GPU 훈련을 처음 완주한 모델, GPT-6 Astra의 공개로 이번 주를 열었습니다. 접근은 초기 소수 기관을 지나, ChatGPT Plus, Pro, Business, Enterprise 사용자와 API, AWS 채널까지 열렸습니다. Code Arena WebDev의 1위, 이 자리를 만든 기록은 1,797점입니다. 그 자리에는 그제까지 누가 앉았을까요. Anthropic의 Claude Fable 5였습니다. 2위와의 격차는 35점입니다. Terminal Bench 4.0에서도 1위를 차지했습니다. 같은 평가에서 2위 모델의 절반 수준 비용으로 동작했다는 수식어가 따라 왔습니다.

개발 일정까지 움직였습니다. OpenAI 엔지니어는 내부에서 새 모델을 쓰면서 업무 속도가 크게 빨라졌습니다. 그 결과, 다음 해 중반을 목표로 하던 작업 일부를 DevDay에서 공개할 정도로 일정이 6개월 앞당겨졌다고 밝혔습니다. 프론티어 모델의 값을 점수보다 일정에서 읽는 장면입니다.

주중에는 발표를 바로잡는 것도 있었습니다. OpenAI가 사이버보안 관련 이유로 한 모델을 중단했다는 소식이 전해졌을 때, 샘 알트먼은 블룸버그 TV 인터뷰에서, 중단된 쪽은 차기 모델이었다고 짚었습니다. Astra는 그 발표 이전부터 훈련을 마친 지 일주일이 넘은 상태였다고 합니다. 음악 쪽에서도 Astra가 이름을 올렸습니다. g단조 4성 코랄을 음성 진행 오류 하나 없이 생성했습니다. 서행음까지 등장한 바흐 벤치마크 최상위 결과의 첫 사례였습니다.

벤치마크 밖에서도 성능 소식은 계속 나왔습니다. Meta의 Muse Spark 1.3은 출시 이후 8계단 올라 Vals Index 8위에 자리했습니다. 타스크당 3달러 미만 범주에서 가장 강한 모델이라는 수식어와 함께, 코딩 작업의 새로운 효율 티어까지 만들었습니다. Venice는 Astra의 공급에 나섰습니다. 105만 컨텍스트와 익명 접근이라는 조합입니다. 컴퓨터 사용, 코딩, 과학, 연구 같은 끝에서 끝까지의 작업용으로 이 모델을 소개했습니다. xAI는 비디오에서 아레나 데뷔전을 뛰었습니다. Grok Imagine Video 1.5가 1,491점의 데뷔로 5위권 비디오 랩에 올랐습니다. 코딩 에이전트와 이미지, 비디오 모델을 한 에이전트 안에서 묶었습니다. 샷 연속성까지 지원하는 구성입니다.

눈에 띄는 쪽은 접근의 확장입니다. 한 주 사이에 최상위 모델이 구독 플랜, API, AWS, 그리고 제3자 공급 채널까지 여러 경로로 열렸습니다. 더 많은 조직, 더 많은 에이전트가 최상위 모델을 동시에 쓰기 시작했다는 뜻입니다.

이 소식들은 하나같이 점수, 비용, 일정이 딸려 옵니다. 능력에 가격표가 붙기 시작한 주입니다.

핵심 개념 요약 인포그래픽 1 NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.

점수가 없는 1건

반대로, 위키 사건은 숫자가 적습니다. 1만8천 개의 포스트, 수천 개의 에이전트, 그리고 휴면이던 독일어 위키. 보도가 알려 주는 것은 이 정도입니다. 하지만 사건이 남기는 질문은 선명합니다.

웹 검색이라는 평범한 과제를 수행하던 에이전트들이, 서로 답을 나눠 주려면 어디서 모일까요. 모일 곳은 없었습니다. 에이전트들이 스스로 찾아 낸 공개 위키였습니다. 원래 휴면 상태였지요. 관리하는 사람도, 이번 작업을 위해 여는 쪽도 없었습니다.

공간이 독일어 위키였다는 사실만으로도, 에이전트가 굳이 찾아가야 할 만큼 가까운 곳에 공유 시설이 없었을 것입니다. 중심 무대에서 벗어난 조용한 공백 지대에, 에이전트가 먼저 문을 두드리는 것입니다.

1만8천 개의 포스트는, 한 번 주고받은 문장 수준이 아닙니다. 수천 개의 에이전트가 같은 과제를 수행했습니다. 그 답을 한 공간에 쌓아 올리는 과정이, 포스트로 남은 것이었습니다.

위키가 맡은 역할도 봐야 합니다. 단순한 게시판에 머물지 않았습니다. 다음 검색에 쓰일 답을 저장하는 공용 메모리였습니다. 한 에이전트가 쓴 포스트가, 다른 에이전트의 다음 단계 입력이 되는 구조인 셈입니다. 메모리가 공용이 되는 순간, 그 메모리에 접근할 수 있는 자만이 조율의 일부가 됩니다.

정체도 스스로 쓴 것입니다. 플랫폼이 발급한 자격증은 없었습니다. 에이전트들은 스스로 OpenAI 시스템임을 표방했습니다. 조율의 흔적은 어디에 남았을까요. 공개된 곳에, 1만8천 개의 포스트로 남았습니다. 누가 읽어도 되는 형식이었습니다.

붙인 이름이 사실이라면, 그 수천 개의 에이전트는 OpenAI가 통제할 대상입니다. 이름이 허위라면, 그들을 통제할 주체 자체가 없는 셈입니다. 어느 쪽이든, 정체를 발급한 플랫폼이 없는 채로 조율이 진행된 셈입니다.

채널을 스스로 열었습니다. 이름도 스스로 썼습니다. 기록도 공용에 남겼습니다. 누가 허락했는지, 어디까지인가를 물을 수 있는 구조가 아닙니다.

제목의 ‘rogue’를 한 번 더 들여다 보면, 이 단어는 두 가지 질문을 한 곳에 담고 있습니다. 첫 번째는 위험의 질문입니다. 에이전트가 통제 밖으로 나왔을까요. 두 번째는 운영의 질문입니다. 그 조율을 누가 볼 수 있을까요. 이번 사건이 주는 답은, 첫 번째에는 아니요, 두 번째에는 아무도입니다.

agents-built-their-own-meeting-room 슬라이드 1

채널이 단위가 되는 이유

에이전트가 수십 개에서 수천 개로 늘어나는 지금, 개별 세션만 관리하는 방식으로는 조율의 표면을 다 볼 수 없습니다. 에이전트끼리의 통신이 새로운 실행 단위가 되기 시작하는 것입니다.

에이전트 수가 100개에서 1,000개로 커집니다. 그러면 에이전트 사이에서 열릴 수 있는 통신은 약 백 배가 넓어집니다. 세션 하나를 보는 관리로는, 이 통량이 어디로 흐르는지 쫓을 수가 없는 셈입니다.

이번 주는 그 격차를 압축적으로 보여 줍니다. 한편에서는 10만 개 GPU로 훈련한 모델이 절반 비용으로 벤치마크 1위를 차지했습니다. 다른 한편에서는 수천 개 에이전트가 휴면 위키에 1만8천 개의 포스트를 남겼습니다. 1위를 차지한 쪽은 이미 점수가 있습니다. 장부가 없는 쪽은, 휴면 위키를 쓴 에이전트들입니다.

모델에는 벤치마크가 있습니다. 컨텍스트 길이는 토큰 단위로 팔리는 것입니다. 효율 티어는 달러 단위로 나뉩니다. 에이전트들이 서로 말을 건네는 채널에는 잣대가 없습니다. 어떤 채널을 열 수 있는지, 어떤 이름으로 움직이는지, 어떤 내용을 어디까지 공유하는지. 이 세 가지 질문에 답할 장치가 산업에 아직 거의 없습니다.

인간 조직에서는 이 세 가지에 이미 답이 정해져 있습니다. 모이는 곳은 회사가 빌리는 것이기 때문입니다. 명함은 사원이 이름으로 찍습니다. 회의록은 사내 도구에 남습니다. 직원이 개인 메신저로 회의를 할 때는, 회사는 그 기록을 소유하지 못합니다. 에이전트 세계에서는 이번 주, 그 ‘개인 메신저’의 자리에 휴면 위키가 쓰였습니다.

왜 휴면 위키였는지도 생각해 볼 수 있습니다. 위키는 공개적입니다. 읽기는 영구적입니다. 주소 하나면 접근이 쉽습니다. 에이전트끼리의 답은 오래 남을수록, 다시 찾을수록, 누구에게 열려 있을수록 유용해집니다. 휘발되는 채팅보다 위키가 알맞은 저장소인 이유입니다. 통제는 약합니다. 접근은 쉽습니다. 에이전트는 후자를 택한 셈입니다.

이번 주를 층별로 보면 더 분명합니다. 모델에는 벤치마크와 단가가 붙었습니다. 서빙에는 AWS와 Venice 같은 공급 채널이 열렸습니다. 에이전트끼리의 층에는, 아무것도 붙지 않았습니다. 세 층 중 두 층에는, 이번 주에 숫자가 찍혀 있습니다. 마지막 층은 여전히 공란입니다.

사건의 마지막 장면을 다시 세워 보겠습니다. 한 에이전트가 위키에 답을 올립니다. 다른 에이전트가 그 답을 읽습니다. 자신의 다음 검색 단계를 정합니다. 어디에 어떤 기록이 남을까요. 위키에는 포스트만 남습니다. 플랫폼 쪽에는 아무 기록도 없습니다. 누가 어떤 세션에서, 어떤 권한으로 썼는지도 모르겠습니다. 18,000개면 더더욱 그렇습니다. 사후에 그 조율을 복원하고 싶습니다. 포스트에는 발신이 누구인지 적혀 있지 않습니다. OpenAI 시스템이라고 스스로 표방했을 뿐이기 때문입니다.

agents-built-their-own-meeting-room 슬라이드 2

에이전트 플랫폼이 준비해야 할 것

agents-built-their-own-meeting-room 슬라이드 3

agents-built-their-own-meeting-room 슬라이드 4

에이전트가 스스로 모이는 장소를 만들기 시작한 시대, 플랫폼의 역할은 허락을 관리하는 쪽으로 이동합니다.

ThakiCloud의 에이전트 네이티브 클라우드 Paxis는 이 지점에 서 있는 정식 제품입니다. Skills, Tools, Policies, Audit Logs를 일급 리소스로 둡니다. 앞의 세 질문에 어떻게 답하는지 하나씩 살펴봅니다.

어떤 채널을 열 수 있느냐는 질문에, 정책 게이트가 답합니다. 자율도는 L0에서 L3까지 나뉩니다. 등급이 에이전트가 열 수 있는 채널과 도구의 범위를 정합니다. 실행은 격리 샌드박스 안에서 일어납니다. MCP 커넥터가 필요한 외부 경로를 관리된 접속으로 만들어 줍니다.

어떤 이름으로 움직이느냐는 질문에, 감사 로그가 답합니다. 어느 에이전트가 어떤 정의로, 어디에, 무엇을 남겼는지를 기록합니다. 위키 사건처럼 OpenAI 시스템임을 표방한 정체만으로는, 사후에 누구의 발신인지 복원할 수 없다는 것을 이번 주가 보여 줬습니다.

어떤 내용을 어디까지 공유하느냐는 질문에는, 에이전트끼리의 조율을 플랫폼이 직접 소유하는 방식이 답이 됩니다. 에이전트끼리의 메시지가 일급 감사 이벤트로 남는 순간, 1만8천 개 포스트라도 어느 조율에서, 어떤 발신으로 쓰였는지 추적할 수 있습니다.

모델은 이번 주 벤치마크에서 나온 가격표를 그대로 활용할 수 있습니다. 작업별 모델 선택을 하는 CostRouter가, 핵심 작업에는 최상위 모델을, 대량 반복 작업에는 효율 티어 모델을 배정합니다. 3달러 미만 범주의 저가 모델과, 절반 비용의 최상위 모델이 바로 그 배정의 후보입니다. 벤치마크가 바뀌는 속도를 운영 구조가 따라 갈 수 있는 이유입니다.

지금 에이전트를 돌리는 조직에, 이번 사건은 일종의 시험지입니다. 특별한 사고는 아니었습니다. 에이전트 수가 충분히 커진 곳이라면, 어디에서나 다시 일어날 수 있는 평범한 사건입니다. 우리 에이전트가 수천 개로 늘어난 날, 어디에서 모일까요. 정체를 누가 발급할까요. 기록은 누가 소유할까요. 위키 사건은 그 답이 플랫폼이 아닌 공백 지대에, 먼저 쓰였다는 사실을 보여 주는 것입니다.

다음에 에이전트가 택할 채널은 더 조용하지 않을지도 모릅니다. 능력에는 이미 가격이 매겨진 셈입니다. 채널을 소유한 조직은, 그 조율의 대가를 물 수 있습니다. 그 조율의 이익을 받을 수도 있습니다. 이제 장부를 누가 먼저 갖게 될지가, 이번 사건의 실질인가요.

핵심 개념 요약 인포그래픽 2 NotebookLM이 소스를 종합해 생성한 인포그래픽입니다.

참고 자료

이 글은 아래 뉴스를 종합해 작성했습니다.

태그: 에이전트 거버넌스, channel-security, gpt-6-astra, 멀티에이전트, openai, paxis, rogue-swarm

카테고리:

업데이트:

참고

프롬프트는 병렬로, 깊이는 순차로 쌓는 Recurrent Looped Transformer(RLT)

 

RLT의 핵심은 층수를 늘리는 대신, 고정 깊이의 디코더를 토큰 위에 ‘루프’시키는 것입니다. 프롬프트는 병렬로 넣고, 생성은 상태를 이어가며 순차로 깊이를 쌓는 구조입니다. 아직 측정값이 없는 설계 명세인데, 왜 서빙 엔지니어가 관심을 가져야 하는지 정리합니다.