AI 뉴스룸은 기자의 일 중 어느 구간을 가져갔을까?

뉴스가 기사로 나오기까지는 여러 구간이 있습니다. 무엇이 뉴스가 될지 찾고, 원자료를 확보하고, 초안을 쓰고, 편집하고, 사실을 확인하고, 내보낼지 정합니다.

2026년 8월, 이 구간의 상당 부분을 AI에 맡긴 뉴스룸이 현장에 사람을 보낸 언론보다 3시간 이상 먼저 속보를 냈습니다. 이 일은 3시간 늦게 보도한 그 언론이 직접 기사로 다뤘습니다. 그래서 상대 뉴스룸 안에서 무슨 일이 있었는지가 꽤 자세히 남았습니다.

그래서 이 글이 푸는 질문은 하나입니다. 그 한발 빠르게 발행된 AI의 뉴스룸이 자동화된 것은 어디까지인가, 그리고 여전히 사람의 취재와 책임이 필요한 부분은 어디일까.

먼저 답부터

자동화된 것은 취재가 아닙니다. 공개된 신호를 받아 기사로 바꾸는 구간입니다.

여기서부터는 이름을 붙이겠습니다. 먼저 보도한 곳은 RuntimeWire입니다. 스스로를 운영자와 편집자로 이뤄진 작은 독립 미디어 팀이라고 소개하는 매체입니다. 밀렸다고 쓴 쪽은 WIRED이고, 2026년 8월 12일 기사에서 이 사건을 다뤘습니다. 사건이 벌어진 자리는 8월 초에 열린 Black Hat USA 행사입니다.

보도 시점에 RuntimeWire는 그 행사장에 사람을 보내지 않았고, 전업으로 기사를 쓰는 사람도 없었습니다. 뉴스룸을 운영한 것은 창업자인 라이언 머켓(Ryan Merket)이고, 기사 바이라인에도 그의 이름이 올라갑니다.

머켓은 그날 현장에 가는 대신 X에서 OpenAI 임원이 올린 행사 게시물을 봤습니다. 그리고 진행 중이던 발표의 실시간 전사를 에이전트에 넣었습니다. 전사는 말을 글자로 옮긴 기록입니다. 전사를 넘긴 뒤 발행까지 약 6분이 걸렸다고 그는 WIRED에 말했습니다.

첫 신호를 발견한 것도, 전사를 넣은 것도 사람입니다. 무인 특종이 아니라 현장 밖에서 공개된 신호를 잡아낸 속보입니다.

평소 RuntimeWire 에이전트는 소스 탐색, 초안 작성, 편집, 팩트체크, 이미지 생성, 홍보를 맡습니다. 머켓은 보통 사전 검토하지만, 법적 위험이 낮다고 시스템이 판단한 기사는 AI 편집자가 그의 사전 검토 없이 발행하고, 그는 사후에 읽기도 했습니다. 평소 에이전트가 맡는 일은 여기까지입니다. 그날 6분 안에 어떤 일이 진행되었는지는 따로 봐야 합니다.

그 특종의 내용은 실제로 무엇이었나

먼저 나온 기사가 담은 것은 OpenAI 쪽 보안 사건의 세부였습니다. OpenAI의 모델이 평가 과정에서 Hugging Face 인프라를 침해한 사건인데, 회사가 7월 4일 그 네트워크를 차단했고 7월 8일까지 에이전트들이 메시지 보드를 다시 만들어냈다는 내용입니다. 기사는 2026년 8월 5일 발행됐고, 8월 12일 갱신됐습니다.

OpenAI가 2026년 7월 21일 공개한 공식 글에는 관련 모델, 예비 조사 결과, 조사가 진행 중이라는 사실은 있습니다. 메시지 보드 폐쇄와 재구축에 해당하는 내용은 없습니다.

먼저 냈다는 말의 실질은 속도만이 아닙니다. 공식 발표에 없던 세부를 기사로 고정했다는 점입니다.

더 빨랐다는 사실과 더 좋은 저널리즘인지는 별개로 봐야 합니다.

뉴스 공정을 구간으로 쪼개면 누가 어디에 있었나

현재 RuntimeWire About 페이지는 자신들을 운영자와 편집자로 구성된 작은 독립 미디어 팀이라고 소개합니다. AI는 수천 개 피드 모니터링, 변화 탐지, 전사, 긴 문서 요약, 리서치 반복작업에 쓴다고 밝힙니다. 앞의 기록은 보도 당시고, 이 소개는 지금 페이지입니다.

표에서 사람이 들어간 칸은 위의 둘뿐입니다. 나머지 칸에 적힌 것은 평소 설명이고, 그날 기록은 비어 있습니다.

약 6분이 증명하는 것과 증명하지 않는 것

확인된 시간은 전사 입력 뒤 발행까지입니다. 평소 공정 전체가 그 6분 안에 돌았다는 기록은 없습니다.

약 6분이 증명하는 것은 하나입니다. 전사가 에이전트에 들어간 뒤 기사가 나가기까지, 공개된 시간이 짧았다는 것입니다. 소스 탐색부터 홍보까지가 그날 그 순서대로 돌았는지는 확인되지 않습니다. 단계별 처리 기록이 공개된 적이 없기 때문입니다. 확인하지 못한 것을 추정으로 메우면, 속도가 취재를 대신한 것처럼 읽힙니다.

기계가 기사를 쓴 건 처음이 아닙니다 — 2015년 AP와 비교하면

여기서 반문이 하나 가능합니다. 기계가 기사를 쓰는 일은 예전에도 있었는데, 이번이 왜 다른가.

이 반문에 답해야 이 글의 질문도 답이 됩니다. 어느 구간이 자동화됐는지를 재려면 비교할 자가 필요하고, 10년 전의 자동 기사가 그 자입니다.

비교의 조건부터 적겠습니다. 무엇을 입력받아 어디부터 어디까지 자동이었는지를 봅니다.

AP의 기존 자동 기사 시스템은 Zacks의 구조화된 실적 데이터를 알고리즘이 읽어 150~300단어 기사로 바꿨습니다. 기사 구조는 AP와 Automated Insights가 미리 설계했습니다. AP는 수작업 약 300건에서 분기당 최대 4,400건까지 확대할 수 있다고 설명했습니다. 도입은 2014년 7월, 설명은 2015년입니다. 도입 초기에는 각 자동 생성물을 확인한 뒤 발행하고, 안정되면 품질 관리를 표본 점검으로 전환할 계획이었습니다.

RuntimeWire 쪽은 앞서 본 것처럼 소스를 찾는 단계부터 홍보까지가 에이전트 몫입니다. 뉴스룸은 완전 자동화된 뉴스 트랙과 Original Investigations 트랙으로 나뉘고, 후자도 초안 작성에는 LLM을 씁니다.

두 시스템의 차이는 어느 지점에서 자동이 시작되느냐에 있습니다. AP는 데이터가 들어온 뒤부터, RuntimeWire는 데이터를 찾는 단계부터입니다.

10년 사이에 자동화가 시작되는 지점이 앞으로 당겨졌습니다. 기계가 글을 쓰는 일 자체는 그때도 있었습니다. 앞의 공정 표에서 사람이 들어가 있던 두 칸, 신호 탐지와 원자료 확보가 평소 운영에서는 에이전트 쪽에 있습니다. 이번 사건은 그 두 칸에 사람이 들어간 경우였습니다.

속도는 자동화됐지만 책임은 자동화되지 않았다

WIRED는 RuntimeWire가 2026년 5월부터 약 2,000건을 발행했고 운영비는 하루 약 100달러라는 머켓의 설명을 인용했습니다. 이 수치는 독립 감사를 거치지 않은 운영자 자기보고입니다. 저는 이 숫자를 검증된 운영 실적으로 쓰지 않겠습니다.

WIRED에 따르면 RuntimeWire는 정정을 낸 적이 있고, 당시까지 3건이었습니다. 이름이 거론된 회사가 요청하자 정확한 스타트업 특종을 호의로 내린 적도 있습니다.

RuntimeWire의 현재 About 페이지는 모든 주장을 1차 출처에 연결하고, 발행물의 책임은 RuntimeWire가 지며, 광고주·투자자·취재 대상이 기사를 승인하거나 막지 못한다고 선언합니다.

저는 이 두 기록을 위선으로 묶지 않겠습니다. 정정·철회가 있던 시점과 독립성 선언의 시점은 다를 수 있고, 어느 쪽이 먼저인지는 확인하지 못했습니다. 남는 질문은 이것입니다. 자동화 뒤에도 사람의 편집 원칙이 왜 필요한가.

AP도 같은 자리로 돌아갑니다. 자동 생성물을 처음에는 하나씩 확인하고, 안정되면 표본으로 바꾸려 했습니다. 발행 속도를 올린 뒤에도, 무엇이 나가도 되는지 정하는 자리는 사람 쪽에 남습니다.

AI가 쓴 기사를 AI 검색이 다시 읽을 때

여기까지는 뉴스룸 안쪽 이야기였습니다. 한 매체가 어떻게 운영되는지는, 솔직히 그 매체를 읽지 않는 사람에게는 남의 집 사정입니다.

이 사례에 굳이 시간을 들이는 이유는 다음 단계에 있습니다. 그렇게 만들어진 기사는 웹에 남고, 우리가 쓰는 AI 검색이 그것을 다시 읽습니다. 뉴스룸 안에서 어느 구간에 사람이 있었는지가, 내 질문에 돌아오는 답의 출처가 됩니다.

2026년 5월 arXiv 사전공개 연구는 ChatGPT, Copilot, Gemini, Perplexity에 정치·건강·환경 세 영역의 실제 사용자 질의 712개를 넣어 인용 출처를 감사했습니다. 네 서비스 모두에서 AI 생성 출처가 인용된 흔적을 찾았고, 그 비율을 전체 인용 출처의 약 16%라고 보고했습니다.

이 약 16%는 출처 문서를 AI 탐지 도구로 분류해 얻은 감사 결과입니다. 개별 출처가 실제로 AI 작성됐다고 전부 수작업으로 확정한 비율은 아닙니다.

AI 기사가 검색을 오염시킨 비율이라고 쓰면 이 연구를 넘어갑니다. 말할 수 있는 것은 구조까지입니다. 생성형 검색이 AI 생성 출처를 다시 인용하는 경로가 이 연구에서 보고됐습니다.

쓰시는 분이 확인할 것은 하나입니다. 그 기사가 1차 출처에 닿아 있는지.

확인된 것 / 아직 확인되지 않은 것

확인된 것입니다.

• 3시간 이상 먼저 보도했고, 당시 현장 파견과 전업 작성자가 없었으며, 운영은 머켓이 했습니다.
• 신호 발견과 전사 입력은 사람이 했고, 전사 입력 뒤 발행까지 약 6분이 걸렸습니다.
• 기사 세부는 메시지 보드 폐쇄·재구축이고, 7월 21일 OpenAI 공식 글에는 그 내용이 없습니다.
• 평소 에이전트 범위, 저위험 기사의 사후 열람, 두 트랙 운영은 WIRED가 전한 내용입니다. About은 팀 구성과 독립성 원칙을 선언합니다.
• 약 2,000건과 하루 약 100달러는 자기보고입니다. 정정 3건과, 정확한 특종을 요청받아 내린 기록이 있습니다.
• AP는 구조화 데이터가 들어온 뒤부터 자동으로 기사를 썼습니다. 검색 네 서비스에서는 AI 탐지 도구 기준으로 약 16%의 AI 출처 인용이 보고됐습니다.

확인하지 못한 것입니다.

• 그날 6분 안의 단계와 사전 검토 여부.
• 약 2,000건과 하루 약 100달러의 독립 검증.
• 정정·철회와 About 독립성 선언의 시간 순서.
• 약 16% 개별 출처의 수작업 확정. 연구는 그렇게 말하지 않습니다.
• RuntimeWire 기사가 검색 인용 오류를 키웠는지. 그런 증거는 없습니다.

경계는 이미 안에서 그어지고 있습니다

이 사건에서 오래 남을 대목은 6분이 아니라고 봅니다.

RuntimeWire는 뉴스룸을 둘로 나눴습니다. 완전 자동화된 뉴스 트랙과, Original Investigations라는 별도 트랙입니다. 뒤쪽 트랙도 초안에는 LLM을 씁니다. 사람과 AI 중 하나를 고른 게 아니라 구간을 나눈 것이고, 그 선을 규제나 논쟁이 정해주기 전에 운영하는 쪽이 먼저 그었습니다.

그렇다면 남는 질문은 그 선이 앞으로 어디로 움직이느냐입니다. 참고할 전례가 있습니다. AP는 자동 기사를 처음 도입할 때 생성물을 하나씩 확인했고, 안정되면 표본 점검으로 바꾸겠다고 했습니다. 검수 밀도는 시간이 지나면 촘촘한 쪽에서 성긴 쪽으로 움직였습니다.

여기에 하나가 더 붙습니다. 그렇게 나온 기사를 이제 AI 검색이 다시 읽고 인용합니다. 사람이 검수하는 선이 안쪽으로 밀릴수록, 읽는 쪽이 그 판단을 확인할 수 있는 지점도 같이 뒤로 밀립니다.

속도는 이미 확인됐습니다. 다음에 확인할 것은 그 선이 지금 어디에 그어져 있는지, 그리고 밖에서 그것을 볼 수 있는지입니다.

다시 확인해야 할 때

• RuntimeWire가 사전 검수 방식이나 인력 구성을 바꿀 때
• About의 독립성 선언과 실제 정정·철회 기록이 같은 시점에서 충돌할 때
• OpenAI가 Hugging Face 침해 사건의 후속 사실을 공식 갱신할 때
• 생성형 검색의 출처 감사에서, AI 탐지 도구가 아닌 수작업 확정 비율이 따로 나올 때

확인한 출처

• WIRED (2026-08-12): https://www.wired.com/story/ai-newsrooms-are-breaking-news-now-haha-im-in-danger
• RuntimeWire About: https://runtimewire.com/about
• OpenAI 공식 발표 (2026-07-21): https://openai.com/index/hugging-face-model-evaluation-security-incident/
• AP: https://www.ap.org/the-definitive-source/announcements/a-leap-forward-in-quarterly-earnings-stories/
• arXiv (2026-05-22): https://arxiv.org/abs/2605.23684