18만 건의 회의. 회의당 5명으로 계산하면 90만 명의 대화 내용입니다. 영업 협상, 채용 면접, 인사 평가, 회사 전략 회의, 나아가 정부 기관의 작업 회의까지 포함됩니다. 이 데이터는 한 AI 회의록 도구의 클라우드 데이터베이스에 저장되어 있었지만, 해당 데이터베이스의 문은 잠겨 있지 않았습니다. 누구나 무료 계정을 하나 만들기만 하면 18만 건의 회의 기록을 전부 검색할 수 있었고, 심지어 현재 진행 중인 실시간 회의 링크를 받아 직접 참석할 수도 있었습니다. 보안 연구원 Bob Diachenko가 실제로 시도해 보았습니다. 그는 157명이 참석 중이던 말레이시아 교육부의 온라인 회의에 초대 없이 들어갔습니다. 그 회의는 여전히 녹음 중이었습니다.
타인의 비밀을 보관하며 성장한 기업
문제의 기업은 tl;dv(“Too Long; Didn’t View”의 약자로, 너무 길어서 보지 않았다는 의미)입니다. Zoom, Google Meet, Teams 회의에 봇을 참석시켜 전체 과정을 녹음하고, 텍스트 자막을 생성한 뒤 AI로 핵심 요약을 제공하는 서비스입니다. 200만 명 이상의 사용자를 보유하고 있으며, 벤처 캐피털의 투자를 받고 LinkedIn 영업 커뮤니티에서도 널리 추천받는 도구입니다.
영업 통화, 채용 면접, 인사 평가, 내부 전략 회의까지 사용자들은 온갖 중요 정보를 여기에 저장했습니다. “이 회의는 녹음됩니다”라는 안내음이 울리고 참석자들이 어색하게 웃은 뒤, 향후 45분간 영업 비밀을 이어나가던 바로 그 내용들입니다.
취약점은 어떻게 발생했나: 해커는 없었고 잠기지 않은 문만 있었다
먼저 분명히 할 점은, 이것이 정교한 사이버 공격이 아니었다는 사실입니다. 비밀번호를 해킹하거나 고도의 제로데이 취약점을 이용한 것이 아니었으며, 공격자는 해킹이라는 단계조차 거칠 필요가 없었습니다.
문제는 데이터베이스의 접근 제어(문잠금)에 있었습니다. Google의 Firestore 같은 클라우드 데이터베이스에는 “각 사용자는 자신의 데이터만 조회할 수 있다”는 기본 규칙(기술 용어로 테넌트 격리)이 있습니다. 하지만 tl;dv의 데이터베이스에는 이 격리 레이어가 전혀 존재하지 않았습니다. 아파트 건물에 비유하자면, 각 세대별로 독립된 열쇠가 있어야 함에도 건물 전체에 로비 하나만 있고, 그 로비에 전체 세대 번호, 입주자 이메일, 어느 방이 지금 회의 중인지 적힌 장부가 놓여 있던 셈입니다. 무료 계정을 만든 입주자라면 누구나 그 장부를 넘겨보고 방 번호를 확인해 문을 두드릴 수 있었습니다.
그림: 연구원이 확인한 회의록 목록. 로그인한 사용자라면 누구나 전체 기록을 검색할 수 있었다. 출처: bobdahacker.com
연구원이 집계한 바에 따르면, 데이터베이스에는 35,003개 기업 도메인에 속한 84,312명 사용자의 회의 기록 181,874건이 담겨 있었습니다. 23개국 정부 기관 회의, 버클리 및 도쿄대 등 주요 대학 회의, 미쓰이 및 HubSpot 같은 대기업 회의가 모두 포함되어 있었습니다. 가장 가파르게 증가한 지난해 7월에는 한 달 동안에만 43,209건의 회의가 새로 저장되었습니다.
더욱 심각한 것은 실시간 영역이었습니다. 임의의 시점에 약 1,000건의 회의가 녹음 중이었으며, 회의 접속 링크가 데이터베이스에 그대로 노출되어 있어 스크립트를 작성하면 자동으로 일괄 참석할 수 있었습니다. 연구원이 말레이시아 교육부의 157명 회의에 접근했을 때, 화면에서는 발표가 진행 중이었고 참석자 목록에는 tl;dv 자체 봇도 포함되어 있었습니다.
그림: 연구원이 초대 없이 참석한 온라인 회의. 157명이 참석 중이었으며 회의는 여전히 녹음 중이었다. 출처: bobdahacker.com
공격자 입장에서 이 데이터의 가치는 요약본 이상으로 음성 자체에 있습니다. 보이스 피싱 방지 전문가들은 댓글을 통해 “직원의 실제 음성 샘플이 있으면 AI를 통해 목소리를 완벽히 복제하여 재무 담당자에게 전화를 걸어 송금을 요청할 수 있다. 이번 유출은 수만 명의 음성 바이오 정보를 전 세계에 뿌린 것과 같다”고 지적했습니다.
회의록 속에 담겨 있던 비밀들
회의 안에는 어떤 내용이 들어 있었을까요? 연봉 협상, 감원 명단, 인수합병 계획, 법적 분쟁, 고객 제출 최저가 정보 등입니다. 정부 기관 회의의 경우 안보 문제와 직결될 수 있습니다. 유출 목록에는 우크라이나 디지털전환부의 회의록도 포함되어 있었으며, 커뮤니티에서는 “우크라이나는 러시아가 이 내용을 보고 있다는 사실을 알고 있는가”라는 질문이 올라왔습니다. 연구원이 무단 접속한 또 다른 회의에서는 미국 한 대학의 학생 창업 팀이 화면을 공유하며 시연을 진행 중이었습니다. 그들이 이메일 검증 기능 구현을 논의할 때 연구원은 “제발 데이터베이스 권한 설정도 올바르게 해주기를 바란다”고 속으로 생각했습니다.
그림: 연구원이 확인한 또 다른 회의. 학생 팀이 화면을 공유하며 스타트업 프로젝트 시연을 진행하고 있었다. 출처: bobdahacker.com
또한 사용자가 “공개”로 설정해 둔 회의도 1,000건 이상 존재하여 녹음과 자막 내용을 직접 시청할 수 있었습니다. 여기에는 브라질 정부의 환경 보호 회의(세계자연기금, 대자연보호협회 참석) 및 HubSpot의 영업 통화가 포함되어 있었습니다. 아울러 228개 도메인에 걸친 715명의 참석자 이메일 주소도 노출되어 피싱 공격의 대상 목록이 되었습니다.
기업의 대응: 반년의 침묵 후 “공개 데이터”라는 해명
기술 커뮤니티를 가장 분노케 한 것은 문제 발견 이후의 기업 대응이었습니다. 연구원은 1월 28일 LinkedIn을 통해 tl;dv 측에 연락을 취했고, 몇 분 만에 “감사합니다! CTO에게 전달해 주세요”라는 답변을 받았습니다. 그러나 이후 CTO로부터는 아무런 연락이 없었습니다. 2월, 3월, 7월에 걸쳐 연구원이 수차례 추적 연락을 취했음에도 데이터베이스는 열려 있었습니다. 8월 초 조사 보고서가 공개되고 언론 보도가 시작되어서야 기업은 며칠 만에 패치를 완료하고 공식 해명글을 발표했습니다.
해명글에서 가장 논란이 된 문장은 노출된 데이터가 “엄격히 메타데이터에 한정되며” 녹음과 자막은 “절대 유출되지 않았다”는 주장이었습니다. 또한 조회 가능했던 것은 “사용자가 주도적으로 공개를 선택한” 회의로 “공개 데이터”에 해당한다고 설명했습니다. 커뮤니티는 즉각 반발했습니다. 연구원은 실제로 1,000건이 넘는 공개 회의의 전체 내용을 입수할 수 있었고, 사용자가 공개 공유를 체크할 때 전 세계가 검색할 수 있도록 허용하는 것임을 알지 못했기 때문입니다. 더욱 아이러니하게도 해당 기업 CEO는 몇 달 전 인터뷰에서 유럽 기업들이 “데이터, 보안, 개인정보를 더 중요하게 생각하며” “첫날부터 컴플라이언스를 제품에 내장한다”고 밝힌 바 있으며, 이 발언은 이번 사건 토론글에 그대로 인용되었습니다.
업계 보안 인증은 도대체 무엇을 검사했는가
이 사건은 다시 보안 인증이라는 질문으로 돌아오게 만듭니다. 이 회사의 공식 웹사이트 보안 페이지에는 SOC 2 인증, GDPR 준수, AES-256 암호화 등 각종 배지가 자랑스럽게 게시되어 있었습니다. 사건이 폭로된 후 개발자 커뮤니티에서 가장 크게 울려 퍼진 목소리는 “이러한 인증은 아무런 의미가 없다”는 것이었습니다.
보안 인증은 실제 무엇을 검사할까요? 쉽게 말해 보안 정책이 문서로 작성되어 있는지, 그리고 자신이 작성한 정책대로 수행하고 있음을 증명할 수 있는지를 봅니다. 검사하지 않는 것은 정책 자체의 우수성, 데이터베이스의 문이 잠겼는지 여부, 제품의 실제 안전성입니다. 비유하자면 시험에서 “자신이 적어낸 규칙에 따라 답안을 작성했는가”만 평가하고 답의 정답 여부는 묻지 않는 것과 같습니다. “1+1=3”이라고 써놓고 그 방식대로 계산했음을 증명하면 통과하는 구조입니다. 식당에 비유하면 위생 점검원이 ‘주방 위생 수칙’ 게시 여부와 이행만 확인할 뿐, 수칙 내용이 ‘매일 청소’인지 ‘개업 전 1회 청소’인지 묻지 않고 실제 주방 청결도 검사하지 않는 것과 같습니다.
한 업계 관계자가 공유한 사례는 이러한 인증의 현실을 보여줍니다. 그가 다니던 회사는 인증을 통과하기 위해 업무용 노트북에 “컴플라이언스 모니터링 소프트웨어”를 설치하도록 요구했습니다. 그는 지시대로 설치한 후 해당 노트북을 한쪽에 치워두고 개인 노트북으로 업무를 계속 처리했으며, “인증은 아무런 문제 없이 통과했다”고 밝혔습니다. 또 다른 사용자는 동일하게 인증을 받은 타사 제품을 이용할 때 채팅 기록이 사측 서버로 강제 업로드되고 클릭 한 번으로 공개되는 구조였음을 지적했습니다. 인증 체계가 증명하는 것은 “말한 대로 실행한다”는 점이며, 문제는 항상 “말한 내용 자체에 실질적 가치가 있는가”에 있습니다.
신뢰와 적합성에 대한 깊은 성찰
이번 사건에서 기술적 세부사항은 복잡하지 않습니다. 복잡한 것은 무너진 신뢰의 회복입니다. 사용자들은 회의실의 가장 사적인 대화를 도구에 맡겼고, 도구는 이를 잠기지 않은 장장에 방치했습니다. 사용자들은 인증 배지를 안전에 대한 약속으로 믿었지만, 인증 체계는 절차가 갖추어졌음만을 보장했습니다. 데이터베이스의 허점은 메울 수 있고 Firebase 설정은 다시 할 수 있지만, ‘인증’이라는 단어에 대해 대중이 갖게 된 불신을 회복하기는 쉽지 않을 것입니다.
어느 한쪽의 입장을 단정할 의도는 없습니다. 회사 측은 “두 개의 독립된 취약점이 있었으며 첫 번째는 이미 오래전에 수정되었다”고 주장하고, 연구원은 “6개월간 응답이 없었고 데이터베이스는 계속 열려 있었다”고 기록하여 양측의 설명에 차이가 존재합니다. 독자 여러분께서는 원문을 대조하여 직접 판단하시기 바랍니다. 다만 다음에 온라인 회의에서 “이 회의는 녹음됩니다”라는 안내가 나올 때, 한 번쯤 생각해 볼 가치는 있을 것입니다. 그 회의를 기록하는 도구가 당신의 목소리를 담기에 자격이 있는지를 말입니다.
참고 링크:
- Bob Diachenko: Tl;dv 유출 조사 보고서
- Hacker News 토론 스레드 (HN)
- tl;dv 공식 해명 글 “Our thoughts on the darkreading.com article”
- Dark Reading 보도 “AI Notetaker Exposes Government, Corporate Video Calls”
- SourceFeed 분석 “One Missing Firestore Rule Exposed 181,874 Meetings”
