discord2026년 5월 18일

디스코드의 모든 음성 및 영상 통화가 이제 종단 간 암호화됩니다 (새 탭에서 열림)

Discord는 2026년 3월부터 Stage 채널을 제외한 모든 음성·영상 통화에 종단간 암호화(E2EE)를 기본 적용했다. 이를 위해 DAVE 프로토콜을 데스크톱·모바일·웹·콘솔·봇·Social SDK 등 모든 플랫폼에 적용했으며, 사용자가 별도로 설정하지 않아도 암호화가 작동한다. Discord는 통화 품질과 지연 시간을 유지하면서도 공개 프로토콜, 오픈소스 구현, 외부 감사를 통해 검증 가능한 개인정보 보호를 제공하는 것을 목표로 했다. ## DAVE 프로토콜 도입과 전면 적용 - Discord는 2023년 음성·영상 통화 E2EE 실험을 시작했다. - 2024년 DAVE 프로토콜을 공개했다. - 오디오·비디오 통화를 위한 공개 E2EE 프로토콜 - 외부 보안 기업 Trail of Bits의 설계·구현 감사 진행 - 오픈소스 구현체 공개 - 버그 바운티 프로그램에 프로토콜 포함 - 2025년 웹 브라우저, PlayStation·Xbox 같은 게임 콘솔, Discord 봇·앱, Social SDK까지 지원 범위를 확대했다. - 2026년 3월 초 마이그레이션을 완료해 다음 통화가 기본적으로 암호화된다. - 개인 메시지 통화 - 그룹 DM 통화 - 음성 채널 - Go Live 스트림 ## 다양한 플랫폼을 동시에 지원한 설계 - Discord 통화에는 노트북, 스마트폰, 웹 브라우저, PlayStation, Xbox 사용자가 함께 참여할 수 있다. - 각 플랫폼의 암호화 구현이 서로 호환되면서도 낮은 지연 시간과 높은 통화 품질을 유지해야 했다. - Discord는 플랫폼 다양성 때문에 DAVE를 인터넷에서 가장 폭넓은 플랫폼을 지원하는 음성·영상 E2EE 구현 중 하나로 설명한다. - 모든 클라이언트가 DAVE를 지원해야 통화에 참여할 수 있도록 변경했다. - 현재는 암호화되지 않은 연결로 되돌아가는 폴백 코드를 제거하는 중이며, 제거가 끝나면 비암호화 연결은 불가능해진다. ## 공개 검증과 외부 협업 - DAVE의 설계와 구현을 공개해 커뮤니티가 직접 검토할 수 있도록 했다. - 외부 감사를 통해 보안성을 검증하고, 버그 바운티로 추가적인 취약점 제보를 유도했다. - 웹 지원 과정에서는 Firefox의 문제로 DAVE가 실제 통화에서 정상 작동하지 않는 사례가 발견됐다. - Discord는 우회책을 적용하는 대신 Mozilla와 Firefox 코드베이스를 함께 조사해 근본 원인을 수정하고 패치를 반영했다. - 이는 자체 코드뿐 아니라 관련 플랫폼과 생태계까지 개선하는 방식으로 프로젝트를 진행했음을 보여준다. ## 사용자 경험과 Stage 채널 예외 - E2EE 적용 이후에도 통화 품질과 성능은 기존 수준을 유지하도록 설계했다. - 사용자가 별도로 opt-in할 필요 없이 암호화가 투명하게 적용된다. - 유일한 예외는 대규모 방송을 위한 Stage 채널이다. - 라이브 이벤트, AMA, 커뮤니티 타운홀 등에 사용되는 방송형 구조 - 개인적인 대화 보호를 목적으로 하는 일반 통화와 설계 목적이 다름 - 따라서 현재는 E2EE 대상에서 제외된다. ## 텍스트 메시지 암호화 계획 - Discord는 현재 텍스트 메시지까지 E2EE를 확장할 계획이 없다고 밝혔다. - Discord의 다양한 텍스트 기능이 비암호화 환경을 전제로 구축되어 있기 때문이다. - E2EE를 도입하려면 검색, 관리, 신고, moderation 등 기존 기능을 대규모로 재설계해야 한다. - Discord는 음성·영상 암호화를 완료했지만 개인정보 보호 강화는 계속 진행되는 작업이라고 강조한다. 이번 변화로 Discord 사용자는 별도 설정 없이 개인 음성·영상 대화에 구조적이고 검증 가능한 보호를 받을 수 있게 됐다. 다만 Stage 채널과 텍스트 메시지는 적용 범위에서 제외되므로, 민감한 대화에는 일반 음성 채널이나 DM 통화를 사용하는 것이 적절하다.

cross-platformopen-sourceend-to-end-encryptionbug-bounty+3

meta2026년 1월 27일

대규모 환경의 Rust (새 탭에서 열림)

WhatsApp은 최근 30억 명 이상의 사용자들을 멀웨어 위협으로부터 보호하기 위해 미디어 처리 라이브러리를 Rust 언어로 재구축하여 성공적으로 배포했습니다. 이는 글로벌 규모의 서비스에서 Rust가 프로덕션 환경에 적합함을 증명한 사례로, 특히 메모리 안전성이 취약한 C/C++ 기반의 미디어 파싱 라이브러리에서 발생할 수 있는 보안 취약점을 근본적으로 해결하는 데 중점을 두었습니다. 결과적으로 WhatsApp은 성능과 메모리 효율성을 동시에 개선하면서도 사용자 보안을 한층 더 강화하는 성과를 거두었습니다. **미디어 보안의 취약점과 대응의 역사** - 이미지나 영상처럼 무해해 보이는 파일도 운영체제의 취약점을 공격하는 악성 코드를 포함할 수 있으며, 2015년 안드로이드의 'Stagefright' 취약점이 대표적인 사례입니다. - 당시 WhatsApp은 OS 라이브러리의 패치를 기다리는 대신, 자체 개발한 C++ 기반의 미디어 일관성 검사 라이브러리인 'wamedia'를 통해 표준을 준수하지 않는 파일을 사전에 차단하는 방식을 택했습니다. - 하지만 미디어 체크 로직 자체가 신뢰할 수 없는 입력을 자동으로 처리하기 때문에, 이 라이브러리 자체의 메모리 안전성을 확보하는 것이 보안의 핵심 과제로 떠올랐습니다. **Rust를 통한 대규모 현대화 및 성능 개선** - WhatsApp은 점진적인 수정 대신 기존 C++ 버전과 병행하여 Rust 버전의 라이브러리를 새롭게 개발했습니다. - 두 언어 간의 호환성을 보장하기 위해 '디퍼런셜 퍼징(Differential Fuzzing)'과 광범위한 통합 테스트를 거쳐 안전성을 검증했습니다. - 기존 160,000줄의 C++ 코드를 90,000줄의 Rust 코드로 대체했으며, 결과적으로 이전보다 더 우수한 성능과 낮은 런타임 메모리 사용량을 기록했습니다. - 안드로이드, iOS, 웹, 웨어러블 등 다양한 플랫폼 지원을 위한 빌드 시스템 구축과 바이너리 크기 최적화라는 기술적 난관을 극복하고 글로벌 배포를 완료했습니다. **다층 방어 체계 'Kaleidoscope'의 구축** - Rust로 작성된 이 라이브러리들은 'Kaleidoscope'라 불리는 종합 보안 체크 시스템의 핵심 구성 요소입니다. - 단순히 파일 구조의 결함을 찾는 것을 넘어, PDF 내의 스크립트 요소나 임베디드 파일, 확장자를 위조한 MIME 타입 변조 등을 감지합니다. - 실행 파일이나 앱 설치 파일과 같은 위험한 파일 형식을 식별하여 사용자 인터페이스(UX) 차원에서 특별 관리함으로써 비공식 클라이언트나 악성 첨부파일로부터 사용자를 보호합니다. **메모리 안전 언어 중심의 보안 로드맵** - WhatsApp의 분석에 따르면 심각도가 높은 취약점의 대부분은 C/C++의 메모리 관리 문제에서 발생하며, 이를 해결하기 위해 새로운 코드 작성 시 메모리 안전 언어(Memory Safe Language)를 기본으로 선택하고 있습니다. - 불필요한 공격 표면을 최소화하고, 기존 C/C++ 코드에 대해서는 강화된 메모리 할당자와 보안 버퍼 API를 적용하는 등 보안 보증 투자를 병행하고 있습니다. - 이번 Rust 도입의 성공을 바탕으로 향후 더 많은 영역에 Rust 채택을 가속화하여 내부 방어 체계를 지속적으로 강화할 계획입니다. **결론 및 제언** WhatsApp의 사례는 보안이 중요한 클라이언트 사이드 애플리케이션에서 Rust가 단순한 대안을 넘어 최고의 선택지가 될 수 있음을 보여줍니다. 특히 외부에서 유입되는 미가공 데이터를 파싱해야 하는 시스템이라면, 메모리 안전성이 보장되는 Rust로의 전환을 통해 보안 사고의 근본 원인을 제거하고 운영 효율성을 높이는 전략을 적극 검토할 필요가 있습니다.

cross-platformrustapplication-securitymemory-safety+3

discord2025년 3월 19일

디스코드, 첫 모바일 (새 탭에서 열림)

디스코드가 자사의 성공적인 광고 모델인 ‘비디오 퀘스트(Video Quests)’를 2025년 6월부터 모바일 플랫폼으로 확장하며 본격적인 모바일 광고 시장 진출을 선언했습니다. 이번 확장은 사용자 경험을 최우선으로 하는 디스코드의 보상형 광고 철학을 모바일로 옮겨와 광고주들에게 더욱 넓은 도달 범위를 제공하는 것을 목표로 합니다. 이를 통해 게임 및 엔터테인먼트 브랜드들은 디스코드의 활발한 크로스 플랫폼 커뮤니티와 더욱 밀접하게 연결될 전망입니다. **모바일 비디오 퀘스트의 도입과 전략적 가치** * 2025년 6월 파일럿 출시 예정인 모바일 비디오 퀘스트는 디스코드가 선보이는 최초의 모바일 전용 광고 상품입니다. * 사용자가 직접 참여 여부를 결정하는 '옵트인(Opt-in)' 방식과 시청 후 보상을 제공하는 '리워드(Rewarded)' 형식을 유지하여 광고에 대한 유저의 거부감을 최소화합니다. * 모바일 환경에 최적화된 풀스크린 형식을 채택하여 게임 트레일러, 신규 시즌 발표, 프리미엄 콘텐츠 홍보 시 몰입감 있는 사용자 경험을 제공합니다. **디바이스를 넘나드는 퀘스트 광고의 두 가지 축** * **비디오 퀘스트(Video Quests):** 브랜드 인지도 확산에 집중하는 포맷으로, 영화나 게임의 예고편, DLC 출시 소식 등을 전달하는 데 특화되어 있으며 모바일 확장을 통해 모바일 게임 광고주들에게도 새로운 기회를 제공합니다. * **플레이 퀘스트(Play Quests):** 유저가 특정 게임을 직접 플레이하거나 스트리밍해야 보상을 받을 수 있는 참여형 포맷으로, 유저와 게임 간의 실질적인 상호작용과 충성도를 높이는 데 기여합니다. **주요 캠페인 사례로 증명된 성과** * **원신(Genshin Impact):** 신규 캐릭터 업데이트에 맞춰 플레이 퀘스트를 진행한 결과, 수백만 명의 참여를 이끌어냈으며 캠페인 기간 중 유저들의 게임 플레이 타임이 평소보다 80% 증가하는 성과를 거두었습니다. * **Max(Dune: Prophecy):** 드라마 시리즈 홍보를 위해 최초의 비디오 퀘스트를 집행했으며, 2분 38초라는 긴 분량의 트레일러임에도 불구하고 85%라는 높은 시청 완료율을 기록했습니다. * **넥슨 게임즈(The First Descendant):** 시즌 2 런칭 비디오 퀘스트를 통해 100만 회 이상의 시청 완료를 달성했으며, 전체 수치의 10%가 유저 간 자발적인 공유를 통해 발생하며 강력한 바이럴 효과를 입증했습니다. 디스코드는 PC와 콘솔을 넘어 모바일 유저까지 아우르는 통합 광고 생태계를 구축하고 있습니다. 게임 및 콘텐츠 기업들은 2025년 6월 시작되는 모바일 비디오 퀘스트 파일럿 프로그램에 참여함으로써, 월간 2억 명 이상의 활성 사용자가 포진한 디스코드의 고관여 유저 층을 선점하는 전략을 검토해 볼 필요가 있습니다.

cross-platformvideo-streamingad-techmobile-advertising+3

figma2024년 8월 19일

크런치롤이 개발자 (새 탭에서 열림)

글로벌 애니메이션 스트리밍 서비스인 크런치롤(Crunchyroll)은 15개의 플랫폼과 12개의 언어를 지원하는 복잡한 환경 속에서 디자인 일관성을 유지하기 위해 '유니버설 디자인 시스템(Universal Design System)'과 피그마의 '개발 모드(Dev Mode)'를 적극 도입했습니다. 과거 인수합병 과정에서 쌓인 파편화된 워크플로우와 기술 부채를 정리함으로써, 디자이너와 엔지니어 간의 협업 효율을 극대화하고 사용자에게 통일된 브랜드 경험을 제공하게 되었습니다. 이번 전환은 단순히 도구를 바꾼 것을 넘어, 복잡한 다중 플랫폼 환경에서 제품의 출시 속도와 품질을 동시에 잡는 전략적 선택이었습니다. **다중 플랫폼 환경에서의 복잡성과 레거시 문제** * 크런치롤은 웹, 모바일뿐만 아니라 게임 콘솔, 스마트 TV 등 9개의 거실용 기기를 포함해 총 15개의 플랫폼을 지원하며, 1,500만 명 이상의 글로벌 팬들에게 서비스를 제공합니다. * 과거에는 각 플랫폼별로 개별적인 디자인 시스템(iOS, Android, tvOS 등)을 운영했으며, 이는 협업 과정에서 심각한 불일치와 혼선을 초래했습니다. * 기존 워크플로우는 Jira 트리거와 Zeplin에 의존했으나, 아트보드 로딩에만 4~5분이 소요되거나 시차 문제로 인해 최신 디자인 사양을 실시간으로 공유하기 어려운 구조였습니다. **디자인 시스템을 통한 효율성 극대화: "식재료 준비(Meal Prepping)"** * 디자인 시스템을 '식재료 미리 준비하기'에 비유하여, 매번 새로운 기능을 만들 때마다 처음부터 설계하는 것이 아니라 준비된 컴포넌트를 재사용하여 리소스를 절약합니다. * 엔지니어링의 DRY(Don't Repeat Yourself) 원칙을 디자인에도 적용하여 중복 컴포넌트를 제거하고 일관된 타이포그래피, 그리드, 간격 시스템을 구축했습니다. * 이러한 표준화는 사용자의 인지 부하를 줄여 구독 전환율을 높이는 동시에, 제품 관리자가 아이디어를 빠르게 검증할 수 있는 속도 경쟁력을 제공합니다. **개발 모드(Dev Mode)를 활용한 협업 프로세스의 혁신** * 개발자가 피그마 링크를 통해 '개발 준비 완료(Ready for development)' 페이지에 접속하면, 수많은 아이데이션 과정은 생략하고 오직 구현에 필요한 최신 스펙과 코드 값만 바로 확인할 수 있습니다. * 기존에 5분씩 걸리던 데이터 파싱 속도가 획기적으로 개선되어, 엔지니어가 특정 결제 플로우나 컴포넌트의 상세 정보를 찾는 데 드는 시간을 대폭 단축했습니다. * 코드 커넥트(Code Connect) 베타 버전을 통합하여 디자인 시스템의 컴포넌트와 실제 코드를 더 밀접하게 연결함으로써 디자인과 코드 간의 괴리를 좁히고 있습니다. **디자인 시스템 운영의 철학과 변화 관리** * 디자인 시스템은 팀을 지원하기 위한 도구일 뿐, 프로세스의 포로가 되어서는 안 된다는 철학 아래 지속적인 교육과 온보딩 워크숍을 진행했습니다. * 과거의 복잡한 QA 단계나 불필요한 태그 시스템을 과감히 삭제하고, 개발자가 필요한 정보에 직접 접근할 수 있는 자율적인 환경을 조성했습니다. * 전문화된 디자인 원칙(계층 구조, 그리드 등)을 준수하는 '좋아 보이는 디자인'과 엣지 케이스까지 고려한 '잘 작동하는 디자인'을 디자인 성공의 핵심 지표로 삼고 있습니다. 디자인 시스템은 한 번 구축하고 끝나는 것이 아니라 팀의 성장에 맞춰 계속 진화해야 합니다. 크런치롤의 사례처럼 도구의 기능을 활용해 불필요한 단계를 제거하고, 개발자와 디자이너가 동일한 언어로 소통할 수 있는 환경을 만드는 것이 복잡한 글로벌 서비스를 운영하는 핵심 전략입니다.

cross-platformfigmadesign-systemsdesign-to-code+4

figma2017년 8월 9일

Figma 이모지 출시의 (새 탭에서 열림)

Figma는 사용자 요청이 많았던 이모지 지원을 추가하면서, 운영체제마다 다르게 표시되는 이모지 문제를 해결하고자 했다. 브라우저나 OS의 이모지 렌더링에 의존하지 않고, 개별 이모지를 64×64 컬러 PNG로 제공한 뒤 캐싱하는 방식을 선택했다. 이를 통해 플랫폼 간 일관성과 디자이너가 요구하는 시각적 품질을 모두 확보했다. ## 이모지가 제품에 필요한 이유 - 이모지는 감정, 말투, 뉘앙스를 전달하는 디지털 커뮤니케이션의 시각 언어로 자리 잡았다. - Figma에서 실제 서비스 화면을 디자인하려면 광고 문구, 메시지, 트윗 등에 사용되는 이모지도 정확히 표현할 수 있어야 했다. - 이모지 지원 부족으로 일부 팀이 Figma를 이탈할 정도로 사용자 요구가 컸다. - Mac에서는 `Control + Command + Space`, Windows에서는 터치 키보드의 이모지 아이콘으로 입력할 수 있다. ## 이모지 표준과 플랫폼별 차이 - 이모지는 1999년 일본 휴대전화 사업자가 텍스트만으로 감정을 표현하기 어렵다는 문제를 해결하기 위해 처음 만들었다. - 통신사마다 자체 이모지 세트를 사용하면서 플랫폼 간 호환 문제가 발생했다. - 2009년 Unicode Consortium이 이모지를 문자 체계에 포함하고, 각 이모지에 고유 코드 포인트를 부여했다. - 예를 들어 `U+1F355`는 피자 이모지를 의미한다. - Unicode는 코드와 기본 지침을 정의할 뿐, 구체적인 그림의 디자인은 플랫폼에 맡긴다. - 따라서 같은 이모지도 Apple, Google, Facebook, Twitter, Samsung 등에서 서로 다르게 보일 수 있으며, 감정이나 의미가 왜곡될 위험이 있다. ## Figma에서 OS 렌더링을 사용할 수 없었던 이유 - Figma는 Mac, Windows 등 여러 플랫폼에서 협업하므로 모든 사용자가 동일한 디자인을 봐야 한다. - 브라우저가 운영체제의 이모지 라이브러리를 사용하면 같은 코드가 플랫폼마다 다른 이미지로 렌더링된다. - 이는 협업 디자인 도구에서 시각적 일관성을 훼손하고, 사용자가 의도한 이모지의 의미를 바꿀 수 있다. ## Slack 방식과 한계 - Slack은 Apple 이모지를 표준으로 정하고, 모든 이모지를 하나의 대형 PNG 파일에 담아 자체 호스팅했다. - 사용자가 이모지를 선택하면 대형 이미지의 해당 영역만 표시하므로 삽입 속도가 빠르다. - 그러나 PNG 기반 방식은 확대 시 화질이 떨어지고, 저해상도 이미지가 된다. - 채팅 화면에서는 문제가 크지 않지만, 시각 품질에 민감한 디자이너가 사용하는 Figma에는 적합하지 않았다. ## Figma의 개별 PNG와 캐싱 방식 - Figma는 각 이모지를 별도의 64×64 풀컬러 PNG로 제공했다. - 처음 특정 이모지를 삽입할 때는 이미지를 불러오느라 약간의 지연이 발생한다. - 이후에는 해당 이미지를 캐시해 재사용하므로 반복 사용 시 빠르게 표시된다. - 하나의 거대한 PNG를 내려받는 대신 필요한 이모지만 관리해 메모리 효율도 높였다. - 결과적으로 Slack 방식보다 높은 해상도를 유지하면서도 플랫폼에 관계없이 동일한 이모지를 표시할 수 있었다. 사용자 요구가 제품 이탈과 직결될 수 있는 기능이라면 우선순위를 재평가해야 한다. 특히 협업·디자인 도구에서는 운영체제에 따른 렌더링 차이를 그대로 허용하기보다, 일관된 리소스 제공과 캐싱을 조합해 품질과 성능을 함께 관리하는 것이 효과적이다.

cross-platformfigmaunicodeemoji+1