브라우저 기반 IPFS 네트워크에 관심이 많습니다.웹브라우저만으로 IPFS 네트워크를 구축할 수 있다면, 서버 없는 서비스(웹3 서비스)가 가능해질 것입니다.IPFS 블로그(https://blog.ipfs.tech/)에서 이와 관련된 기사를 엄선하여 요약합니다.• None SPA 또는 MPA 형태로 개발된 Dapp은 IPFS로 쉽게 배포할 수 있다• None Helia는 브라우저를 IPFS 노드로 만들어주는 라이브러리다• None Helia가 브라우저에서 제공하는 기능은 'CID 데이터 관리'와 'CID 데이터에 대한 Verified Retrieval' 2가지다• None CID 데이터 관리: 데이터를 CID 데이터로 만들고 해석하는 기능을 제공한다• None CID 데이터에 대한 Verified Retrieval: CID로 지정된 데이터를 Bitswap 또는 IPFS Gateway를 통해 가져올 수 있다• None 브라우저 IPFS 노드는 보통 수명주기가 짧기 때문에, CID 데이터를 업로드할 때 pinning 서비스를 이용하거나 직접 운영하는 IPFS 노드(서버)를 이용하는 것이 좋다• None IPFS Gateway는 브라우저에서 IPFS 데이터를 가져올 때 특히 유용한 기술이다• None IPFS 데이터에 대한 검증(Verification: IPFS Gateway가 전송한 데이터가 내가 요구한 그 데이터가 맞는가에 대한 검증)을 브라우저가 수행한다면, 브라우저는 IPFS Gateway를 신뢰하지 않더라도 문제 없이 이용할 수 있다 (Trustless Gateway 사용이 가능하다)• None 이를 위해 Interplanetary Shipyard팀(프로토콜랩으로부터 분사한 개발조직)이 @helia/verified-fetch 라이브러리를 개발/배포한다• None Shipyard팀의 다음 목표는 WebRTC와 WebTransport 프로토콜을 이용해서 브라우저에서 직접 Kubo IPFS 노드와 통신하는 것이다• None 우리(Interplanetary Shipyard)가 관심을 갖는 주제는 웹에서 IPFS를 사용하는 것이다• None 다시 말해 웹브라우저에서 다른 IPFS 노드에 연결할 수 있게 만드는 것이다• None 이를 위해 다음과 같은 프로젝트를 진행하고 있다• None Verified Fetch: 브라우저의 fetch API와 유사한 API를 제공, 이를 통해 IPFS 데이터를 검증/수신하는 기능을 제공한다• None Browser Transport: 브라우저에서 사용할 수 있는 WebRTC와 WebTransport 프로토콜을 기반으로 외부 IPFS 노드와 통신하는 기능을 제공한다• None AutoTLS: 브라우저는 보안 통신을 위해 CA 공인 인증서를 요구하나 IPFS 노드는 통상 인증서 없이 운영된다. AutoTLS는 이 갭을 메꾸는 기능을 한다• None Delegated Routing: 브라우저가 IPFS 기능을 호출할 때 이용할 수 있는 https://delegated-ipfs.dev/routing/v1 엔드포인트를

Image created by ChatGPT.안녕하세요 스푼랩스 오디오팀에서 안드로이드 라이브 스트리밍 SDK 개발을 담당하고 있는 Tom입니다. 최근 오디오팀에서 방송 관련 기능들을 테스트하기 위한 용도로 만든 안드로이드 데모앱에 대한 소개와 개발 과정에 대해 얘기해보겠습니다.데모앱 개발을 시작한 배경오디오팀은 다양한 방송 관련 기술을 연구하고 개발하며, 실시간 이슈 대응 및 모니터링을 통해 안정적인 서비스를 유지하는 역할을 담당하고 있습니다. WebRTC, RTMP, SRT 같은 스트리밍 기술은 물론이고, 라이브콜, 목소리 효과 등 고도화된 방송 기능의 개선 및 신규 기능 개발도 중요한 업무 중 하나입니다.“WebRTC 옵션을 조정하면 어떤 변화가 있을까?”“모니터링 기능을 추가하면 어떤 모습일까?”“목소리 효과를 몇 개까지 중첩할 수 있지?”“라이브 방송과 라이브콜 방송을 통합해볼 수 있을까?”이러한 요구사항을 테스트하기 위해 기존에는 스푼앱에 직접 기능을 추가하고 빌드 후 테스트를 진행했습니다. 하지만 스푼앱은 방송 기능 외에도 다양한 기능들을 포함하고 있는 방대한 애플리케이션이기 때문에, 작은 기능 하나를 실험하기 위해서도 많은 시간과 노력이 필요했습니다.• 복잡한 코드베이스: 스푼앱은 많은 기능을 포함하고 있어, 새로운 기능을 테스트할 환경을 추가하는 것 자체가 부담스러웠습니다.• 속도와 효율성 부족: 작은 테스트를 위해도 전체 앱을 빌드하고, 테스트하는 과정이 시간이 많이 걸렸습니다.• 기능 간 간섭 문제: 새로운 기능이 기존의 다른 기능에 영향을 미칠 가능성도 배제할 수 없었습니다.결과적으로, 오디오팀에서 실험하고자 하는 기능을 보다 빠르고 독립적으로 테스트할 수 있는 환경이 필요하다는 결론에 이르렀고, 데모앱 개발을 본격적으로 시작하게 되었습니다.데모앱 개발Image created by ChatGPT.기존에 오디오팀에서는 View 기반으로 작성된 데모앱을 사용하고 있었지만, 시간이 지나면서 유지보수가 어렵고 제대로 작동하지 않는 기능들이 많아졌습니다. 데모앱을 새롭게 개발하기로 결심한 시점에, 저는 안드로이드팀과 함께 Jetpack Compose 스터디를 진행하고 있었습니다. Compose의 간결한 선언형 UI 작성 방식과 XML을 대체할 수 있다는 점에 매료되어, 새로운 데모앱을 Compose로 개발하기로 결정했습니다.Compose Navigation으로 화면 전환Compose Navigation은 Kotlin 코드로 화면 전환을 선언적으로 작성할 수 있도록 도와주는 라이브러리입니다. 데모앱은 스플래시, 로그인, 권한 요청, 홈, 설정, 세부 기능 등으로 화면이 구성되었으며, 화면 전환 간에 필요한 다양한 로직을 Compose Navigation을 통해 간결하게 구현했습니다. 특히, ViewModel과의 자연스러운 통합 덕분에 화면 간 데이터 전달과 상태 관리가 직관적이고 체계적으로 이루어졌습니다.권한 요청과 같은 일회성 화면의 경우, 기존 View 기반 방식처럼 Fragment를 별도로 작성하지 않고 하나의 Compo

이전글[디지털 트윈 기술 #1] 현대오토에버 디지털 트윈 소개인사말안녕하세요, 현대오토에버에서 Software Defined Factory 분야의 소프트웨어 개발 업무를 하고 있는 우정우입니다.오늘은 현대/기아 자동차 공장에 디지털 트윈 기술을 적용하면서 사용한 일부 기술에 관한 흥미로운 소식을 공유 드리고자 해요.이 기술들 덕분에 생산 공정을 더욱 효율적으로 관리하고, 실시간으로 데이터를 활용해 의사 결정을 할 수 있게 되었습니다.그 중 WebRTC 기술을 적용하면서 공간의 제약이 사라지고 실시간으로 즉각적인 피드백을 주고받을 수 있게 되었어요. 덕분에 생산 라인의 모니터링과 유지보수가 훨씬 더 원활해질 것으로 기대하고 있습니다.그래서 오늘은 WebRTC에 대해서 말씀드리겠습니다.WebRTC란?WebRTC(Web Real-Time Communication)는 특별한 플러그인이나 프로그램을 설치할 필요 없이, 웹 브라우저만 있으면 누구나 간편하게 실시간으로 음성, 영상, 데이터를 주고받을 수 있는 혁신적인 오픈소스 기술이에요. 구글이 주도하여 개발했으며, 현재는 W3C와 IETF의 표준으로 자리잡았죠.또한 WebRTC는 데이터 전송 시 SRTP(Secure Real-time Transport Protocol)와 와 DTLS(Datagram Transport Layer Security) 같은 보안 프로토콜을 사용할 수 있어, 여러분의 정보가 안전하게 보호된다는 것도 큰 장점이에요.이 기술은 원격 회의, 고객 서비스, 실시간 협업 등 다양한 상황에서 유용하게 쓰이고 있습니다. 세상이 더 나은 소통과 경험을 만들어가는데 기여하고 있어요.WebRTC와 디지털 트윈 적용 예시기아 광명 EVO Plant 일부 공정에서는 공간의 제약 없이 3D로 현황을 실시간으로 파악할 수 있도록 디지털 트윈 기술이 적용되었어요.또한 웹 브라우저를 통해 다양한 환경에서 서비스를 경험할 수 있답니다.그림. WebRTC 웹사이트 및 공장 상황 확인그림. WebRTC 사용 사례WebRTC를 디지털 트윈 구현에 적용한 이유스마트 팩토리에서 디지털 트윈 기술은 제조 현장을 정확하게 모사한 가상 공장 환경을 구축하여 생산 공정을 최적화하고 효율적으로 운영, 관리 및 빠른 의사 결정에 도움을 주기 위해서에요. 하지만 이를 위해서는 고사양의 3D 그래픽을 계산할 수 있는 장비와 전용 어플리케이션이 필요합니다. 이는 구축 및 운영 비용이 많이 들어가며, 사용자마다 별도의 설치와 관리가 요구되는 문제가 있어요.WebRTC는 이러한 과제를 해결할 수 있는 대안으로 볼 수 있습니다. WebRTC를 활용하면 다음과 같은 장점을 얻을 수 있습니다.장비 의존도를 낮춤: GPU 서버에서 가상 공장 어플리케이션을 실행하고 사용자는 장비의 사양에 관계 없이 웹 브라우저만 있으면 가상 공장 환경을 제공받을 수 있어요.설치 및 배포 용이: 웹 브라우저만 있으면 별도의 애플리케이션 설치 없이 디지털 트윈 플랫폼에 접근할 수 있습니다. 이를 통해 사용자 경험을 크게 향상시킬 수 있어요.실시간 협업 지원:

안녕하세요, 하이퍼커넥트 Media Lab의 Media Server Team에서 Media Server Engineer로 일하고 있는 Simon.Y 입니다.저희 Media Server Team은 “사람들이 제약 없이 모여서 소통할 수 있도록 안정적인 연결을 제공하고 미디어 품질을 높이기 위해 노력한다”는 미션을 가지고 있습니다. 이 목표 아래, 대규모 실시간 스트리밍 서비스를 지원하는 미디어 서버를 개발하고, 전 세계에 위치한 미디어 서버 인프라를 운영하고 있습니다. 지난 글(글로벌 라이브 스트리밍을 지탱하는 하이퍼커넥트 미디어 서버 인프라를 소개합니다)에서는 WebRTC 기반 글로벌 라이브 스트리밍을 제공하기 위한 Media Server Team의 미디어 서버 인프라의 구성을 구체적으로 설명드렸습니다.하이퍼커넥트에서는 다년간 축적한 영상 커뮤니케이션 및 라이브 스트리밍 기술을 여러 프로덕트에서 활용해왔습니다. 1:1 영상 통화 기술은 아자르(Azar) 서비스에서 활용되고 있고, 지난 글에서 언급했던 1:N 라이브 스트리밍 기술은 아자르 내 아자르 라이브(Azar Live) 서비스에서 활용되고 있습니다. 뿐만 아니라 저희는 N:N 그룹 통화 기술도 개발하여 다양한 곳에서 활용하고 있습니다.혹시 여러분께서는 수십 명의 사용자가 동시에 소통할 수 있는 그룹 통화(그룹콜) 서비스를 제공하는 서버는 어떻게 구성되어 있는지 생각해보신 적이 있나요? 라이브 스트리밍 서비스에서는 호스트 한 명의 미디어를 다수의 시청자들에게 안정적으로 전달하는 것이 중요합니다. 이때 사용자는 미디어 서버 인프라와 연결되어 미디어를 보내거나(호스트) 받기만 하면 됩니다(시청자). 반면, 그룹콜 서비스에서는 참여자가 자신의 미디어를 다른 참여자들에게 전달할 뿐만 아니라, 모든 참여자의 미디어를 안정적으로 수신하는 것도 매우 중요합니다.이번 글에서는 하이퍼커넥트의 그룹 통화 서비스를 뒷받침하고 있는 그룹콜 미디어 서버 인프라를 소개하고자 합니다.라이브 스트리밍 인프라로 그룹콜 서비스를 구현할 수 있을까?여러분께서는 아자르에서 멀티게스트 라이브를 보신 적이 있나요? 아자르 멀티게스트 라이브에서는 호스트를 포함해 최대 5명의 참여자가 동시에 소통하며 라이브의 재미를 더하고 있습니다. 그렇다면 이 방식으로 그룹콜 서비스를 구현하면 별도의 그룹콜 미디어 서버 인프라를 만들 필요가 없지 않을까요? 아자르 라이브의 멀티게스트 기능을 통해 라이브 스트리밍 미디어 서버 인프라를 간단하게 설명하고, 왜 그룹콜 미디어 서버 인프라가 필요한지 알아보겠습니다.아자르 라이브에서는 호스트 1명과 게스트 4명, 최대 5명이 동시에 소통하고, 여러 시청자들이 이 장면을 실시간으로 시청할 수 있는 멀티게스트 기능을 지원하고 있습니다. 이해를 돕기 위해 Alice, Bob, Charlie, David가 멀티게스트 라이브를 진행 중인 상황을 가정해 봅시다.멀티게스트 기능을 라이브 스트리밍 미디어 서버 인프라의 관점에서 보면, 참여자를 모두 호스트이자 시청자로 구현한 것이라 볼 수 있습니다. 예를 들어, A