AI 회의록 18만 건이 열려 있었다 — 받아쓰는 봇에 넘긴 신뢰의 비용

AI 회의 녹화 서비스에 대화를 넘기는 것은 편의를 산 거래인가, 아니면 조직의 가장 민감한 순간을 우리가 통제할 수 없는 곳에 예치하는 일인가? tl;dv에서 18만 건이 넘는 회의가 접근 통제 없이 열려 있었고, 그 문이 6개월째 닫히지 않았다는 사실은 이 거래의 청구서가 어디로 오는지를 보여준다.

도입

2026년 초, 한 보안 연구자(블로그 bobdahacker)가 AI 회의 녹화·요약 서비스 tl;dv의 백엔드를 들여다봤다. tl;dv는 Google Meet·Zoom·Teams에 붙어 통화를 녹화하고, 발화를 받아쓰고, 요약까지 만들어 주는 서비스로, 사용자가 200만 명이 넘는다고 알려져 있다. 연구자가 발견한 것은 단순했다. 무료 등급 계정 하나만 있으면, 자기 것이 아닌 남의 회의 기록을 계정 경계를 넘어 조회할 수 있었다. 노출 규모는 회의 기록 181,874건, 고유 사용자 84,312명, 이메일 도메인 35,003개였다(출처: bobdahacker). 그리고 이 문은 연구자가 발견해 통보한 뒤에도 6개월 동안 닫히지 않았다. 세일즈 콜, 채용 면접, 인사 평가, 그리고 23개국 정부 부처의 회의까지 — 조직이 가장 조심스럽게 다루는 대화들이 한 벤더의 데이터베이스 한 컬렉션에 모여 있었고, 그 컬렉션의 자물쇠만 걸려 있지 않았다. 이 글은 무엇이 어떻게 열려 있었는지(팩트)와, 왜 이런 사고가 반복되며 우리가 무엇을 착각하고 있는지(분석)를 나눠 본다.

무엇이 열려 있었나: 회의록 18만 건과 ‘들어올 수 있는’ 방들

먼저 취약점의 성격부터 정확히 짚자. 이것은 흔히 IDOR(부적절한 객체 참조)로 불리는 접근 통제 결함의 한 갈래다. tl;dv는 백엔드로 Firebase/Firestore를 쓰는데, 데이터를 담는 여러 컬렉션 가운데 사용자(users)·트랜스크립트(transcripts)·녹화(recordings) 컬렉션에는 테넌트 격리(tenant isolation) 규칙이 제대로 걸려 있었다. 문제는 회의(meetings) 컬렉션이었다. 이 한 컬렉션만 격리 규칙이 빠져 있었고, gw.tldv.io/v1/users/firebase/token에서 발급받은 Firebase 토큰을 쥔 인증 사용자라면 누구든 다른 계정의 회의 레코드를 질의할 수 있었다(출처: bobdahacker). 즉 인증 자체가 없었던 게 아니라, 인증된 사용자를 자기 데이터에 가두는 경계가 이 컬렉션에만 없었다. 담장은 있는데 한 집 대문만 활짝 열려 있던 셈이다.

조회할 수 있었던 것은 목록만이 아니었다. 각 레코드에는 회의 생성자의 이메일 주소, 녹화 상태와 타임스탬프, 그리고 결정적으로 컨퍼런스 ID가 들어 있었다. 이 컨퍼런스 ID는 실제로 참여 가능한 Google Meet·Teams 방의 주소였다. 연구자에 따르면 임의의 순간에 1,000건 이상의 회의가 실시간으로 녹화되고 있었고, 그 방들의 ID가 그대로 노출됐다. 연구자는 이를 두고 “봇을 쓰는 공격자라면 1,000개의 라이브 통화에 동시에 들어갈 수 있다”고 적었다(출처: bobdahacker). 이것은 사후에 새어 나간 기록의 문제가 아니라, 지금 진행 중인 대화에 낯선 사람이 걸어 들어올 수 있다는 실시간 침입의 문제다. 실제로 연구자는 개념 증명으로 참가자 157명이 넘는 말레이시아 교육부 회의와 참가자 21명 규모의 미국 대학 스타트업 기획 세션에 들어가 봤다고 밝혔다.

규모의 감각을 위해 몇 가지 숫자를 더 옮긴다. 공개(public)로 표시된 회의 1,000건 이상은 트랜스크립트와 녹화 내용까지 노출됐고, 그런 공개 회의의 초대 대상 이메일 715개가 228개 도메인에 걸쳐 드러났다. 연구자는 27,334개의 회의 ID를 수집해 그중 어떤 것이 공개 녹화인지 식별했다. 녹화량은 2025년 7월 한 달 43,209건으로 정점을 찍었고, 가장 붐비는 시간대인 수요일 오후 2시(UTC)에는 7,804건이 동시에 진행됐다(출처: bobdahacker). 노출된 회의에는 브라질·콜롬비아·페루·우크라이나·필리핀·멕시코·미국·카타르·말레이시아·일본·이스라엘 등 23개국의 정부 회의가 포함됐다. HN 토론에서 한 참여자가 이 국가 목록을 그대로 인용하며 우크라이나 정부 회의가 러시아에 노출됐을 가능성을 반쯤 농담으로 짚은 것도 이 명단 때문이었다.

여기에 곁가지 하나가 더 있었다. tl;dv 내부용으로 만든 FIFA 월드컵 예측 앱(worldcup.tldv.io)의 API 엔드포인트가 인증 없이 열려 있어, 직원 19명의 실명과 회사 이메일, 사실상 전체 직원 명부가 드러났다(출처: bobdahacker). 규모는 작지만 신호는 분명하다. 접근 통제를 빠뜨린 게 한 곳이 아니라는 것, 즉 이것이 일회성 실수가 아니라 습관에 가깝다는 것이다.

왜 이런 일이 반복되는가: 편리한 기본값과 부서진 접근 통제

접근 통제 결함은 새로운 병이 아니다. OWASP가 꼽는 웹 취약점 1위가 바로 ‘깨진 접근 통제(Broken Access Control)‘이고, 그 안에서 IDOR류 — 내 식별자를 남의 식별자로 바꾸면 남의 데이터가 딸려 나오는 결함 — 는 가장 흔하고 가장 지루한 실수다. 지루하다는 게 핵심이다. 이런 결함은 정교한 공격 기술이 아니라, 개발자가 “이 사용자가 이 레코드를 볼 권한이 있는가”라는 질문을 한 곳에서 빠뜨렸을 때 생긴다. HN 토론에서 한 보안 실무자는 “교차 테넌트 격리는 내가 점검할 때 가장 먼저 확인하는 항목 중 하나인데, 이렇게 기본적인 것이 안 되어 있는 걸 볼 때마다 놀란다”고 적었다. 자물쇠를 새로 발명할 필요는 없다. 그냥 모든 문에 같은 자물쇠를 다는 규율의 문제다.

그 규율이 왜 무너지는가. 한 가지 구조적 원인은 도구의 기본값이다. HN에서 여러 참여자가 Firebase/Firestore를 지목했다. 플랫폼 자체를 탓하는 게 아니라, “시작하기 쉽다(easy to start)“를 전면에 내세운 마케팅과, “기본값으로 안전하다(secure by default)“가 아닌 설계 사이의 간극을 지적하는 것이다. 한 참여자는 “같은 일이 반복해서 일어난다면 그것은 우연이 아니라 선택”이라며, Firebase가 안전을 기본값으로 두기보다 시작을 쉽게 만드는 쪽을 택했다고 꼬집었다. 다른 이는 “이 도구를 안전하게 쓰려면 지식과 경험이 필요한데, 마케팅은 그게 필요 없다고 말한다”고 덧붙였다. 여러 컬렉션 중 하나만 규칙이 빠졌다는 이 사고의 형태 자체가, 규칙을 명시적으로 하나하나 걸어야 하는 시스템에서 사람이 한 개를 잊는 전형적인 실패다.

또 다른 원인은 만드는 방식 자체를 둘러싼 논쟁이다. HN에서는 이 백엔드를 AI가 작성한 것 아니냐는 추측과 그에 대한 반박이 오갔다. 한쪽은 요즘의 최신 모델이라면 인증 없는 구현을 그냥 뱉어내지는 않을 것이며 릴리스 전 점검에서 이런 명백한 문제는 걸러질 것이라고 했고, 반대쪽은 “최신 모델(SOTA)“이라는 방패가 7초마다 바뀌며 무엇이든 변호하는 데 쓰인다고 냉소했다. 흥미로운 절충안도 나왔다. 이미 허술한 코드베이스 위에서 모델을 굴리면 모델은 기존의 ‘관례’에 맞춰 더 허술한 코드를 즐겁게 써낸다는 것, 그리고 어느 쪽이든 코드에 리뷰를 한 번 돌렸다면 이 문제는 잡혔을 것이라는 지적이다. AI가 범인이냐 아니냐를 떠나, 검토라는 절차가 빠졌다는 결론은 같다.

그러나 이 사건에서 가장 무거운 구조적 문제는 코드가 아니라 배치(configuration)의 문제, 더 정확히는 집중(concentration)의 문제다. AI 노트테이커는 본질적으로 조직에서 가장 민감한 대화들을 한곳에 모으는 장치다. 세일즈 협상의 밑패, 채용 면접의 평가, 인사 평가 면담, 이사회 논의 — 예전 같으면 각자의 머릿속과 흩어진 메모에 남았을 것들이, 이제 받아쓰는 봇을 거쳐 한 벤더의 스토리지로 흘러 들어간다. 편의의 대가로 우리는 위험을 한 점에 응축한다. 그 한 점의 접근 통제가 무너지는 순간, 흩어져 있었다면 결코 한 번에 새지 않았을 것들이 18만 건 단위로 한꺼번에 샌다. HN에서 딥페이크 음성 피싱 회사를 운영한다는 한 참여자는 이 위험을 실무 관점에서 짚었다. 고객들이 늘 “공격자가 대체 우리 직원 목소리를 어디서 구하겠느냐”고 반문하는데, 바로 이런 유출이 그 답이라는 것이다. 회의 녹화는 목소리·이름·맥락을 한 묶음으로 제공하고, 그것은 표적형 사기의 완벽한 원료가 된다. 편의와 프라이버시의 트레이드오프는 추상이 아니라, 유출된 음성 클립이 그대로 무기가 되는 구체적 손익이다.

침묵한 6개월: 공개(disclosure)와 벤더의 책임

취약점 자체만큼이나 이 사건을 주목하게 만든 것은 공개(disclosure) 과정이다. 연구자는 2026년 1월 28일 tl;dv 측에 결함을 통보했다. tl;dv의 보안 안내에는 “보안 문제를 발견하면 privacy@tldv.io로 알려 달라, 보안팀이 24시간 내에 응답한다”는 한 줄이 적혀 있었다(출처: bobdahacker). 현실은 그 약속과 달랐다. CEO Raphael Allstadt는 통보를 받고 “고맙다, CTO에게 보고해 달라, 곧바로 살펴보겠다”고 답했지만, 정작 CTO는 끝내 응답하지 않았다. 2월 19일 “우리가 처리 중이다, 시간이 좀 필요하다”는 답이 마지막에 가까웠고, 3월과 7월까지 결함은 그대로 살아 있었다. 발견에서 6개월이 지나도록 문은 닫히지 않았다.

이 지점에서 HN 토론은 두 갈래의 날 선 논쟁으로 갈렸다. 첫째는 벤더의 태만에 대한 것이다. “이 정도로 치명적인 문제라면 여섯 시간도 아니고 여섯 달을 방치한다는 게 말이 되느냐, 큰 빨간 정지 버튼을 눌러야 할 사안”이라는 격앙된 반응이 많았다. CEO가 인지하고도 움직이지 않았다는 점에서, 경영진의 실패는 개인 개발자의 실수와 다른 무게를 갖는다는 지적도 나왔다. 둘째는 공개의 윤리다. 연구자가 노출된 고객사 명단(정부 부처 등)을 공개한 것이 오히려 고객을 위험에 빠뜨린 것 아니냐는 비판에 대해, 다수는 반대로 답했다. 고객을 위험에 빠뜨린 것은 공개한 연구자가 아니라 6개월간 방치한 회사이며, 이미 이 결함을 알고 조용히 악용하는 다른 이들이 있을 수 있다는 것이다. 한 참여자는 “고객을 탓하는 것은 폭스바겐이 디젤차를 산 게 네 잘못이라고 말하는 것과 같다”고 반박했다. 신뢰할 만한 규제 기관이 즉각적 서비스 중단을 명령할 수 없는 현실에서, 공개적 망신이 사실상 유일한 시정 지렛대라는 냉정한 진단도 있었다.

법적 지점도 흥미로웠다. “6개월이나 안 고쳤으니 마음껏 긁어가도 되는 것 아니냐”는 반농담에 대해, 여럿이 그것은 여전히 범죄일 수 있다고 선을 그었다. 데이터가 쉽게 접근된다는 사실이 그 데이터를 ‘공개 데이터’로 만들지는 않는다는 것이다. 한 참여자는 “물건이 나사로 고정돼 있지 않다고 해서 가져가도 되는 게 아니다”라고 비유했고, 다른 이는 미국 CFAA가 “권한 없이, 또는 허용된 접근 범위를 넘어 컴퓨터에 접근하는 행위”를 금지한다는 점을 상기시켰다. 접근이 기술적으로 쉬웠다는 사실은 면책 사유가 아니다.

실무자에게 남는 시사점은 분명하다. AI 노트테이커를 도입한다는 것은 편리한 도구를 켜는 일이 아니라, 조직의 가장 민감한 대화를 처리하는 데이터 프로세서 하나를 신뢰의 사슬에 추가하는 일이다. 그렇다면 벤더 실사(due diligence)의 질문은 “요약이 얼마나 정확한가”에서 “테넌트 격리를 어떻게 검증하는가, 취약점 신고에 실제로 몇 시간 안에 응답하는가, 녹화·트랜스크립트의 보존과 파기 정책은 무엇인가”로 옮겨가야 한다. 24시간 응답을 약속한 회사가 6개월을 침묵했다는 이 사건은, 벤더의 보안 문구를 계약서가 아니라 마케팅으로 읽어야 한다는 값비싼 교훈을 남긴다. HN에서 한 참여자는 아예 로컬(온디바이스) 노트테이커만이 이 문제의 근본 해법이라며, 다만 로컬에서 화자 분리(diarization)와 발화자 식별이 여전히 충분히 좋은 제품을 찾지 못했다고 토로했다. 편의를 로컬로 되가져오는 길은 아직 좁다.

결론

리드의 질문으로 돌아가자. AI 회의 녹화에 대화를 넘기는 것은 편의의 구매인가, 위험의 예치인가. tl;dv 사건은 그것이 동시에 둘 다임을 보여준다. 우리는 받아쓰기와 요약이라는 편의를 사면서, 조직의 가장 민감한 순간을 한 벤더의 한 데이터베이스에 응축해 맡긴다. 그 응축은 벤더가 모든 문에 같은 자물쇠를 거는 규율을 지킬 때만 안전하다. 한 컬렉션의 격리 규칙이 빠지는 순간, 흩어져 있었다면 결코 한꺼번에 새지 않았을 18만 건이 인증 사용자 한 명 앞에 열린다. 그리고 그 문을 닫는 데 6개월이 걸린다면, 문제는 코드 한 줄이 아니라 그 회사가 신뢰를 다루는 방식 전체다.

그러니 이 글이 남기려는 것은 특정 서비스에 대한 규탄이 아니라 하나의 점검 습관이다. 지금 당신의 조직이 쓰는 받아쓰는 봇은, 당신이 통제할 수 없는 곳에 무엇을 얼마나 모아 두고 있는가. 그 벤더는 테넌트 격리를 검증하는가, 신고에 몇 시간 안에 답하는가, 녹화를 언제 지우는가. 다음 회의에서 “녹화를 시작합니다”라는 알림이 뜰 때, 우리가 실제로 눌러 승인하는 것은 편의만이 아니다. 그 자리에서 오간 모든 말이 누군가의 미납 청구서로 쌓이지 않으리라는, 검증되지 않은 신뢰다. 그 신뢰의 값은 얼마이며, 청구서는 지금 누구 앞에 놓여 있는가.

출처: