Circleback, 회의 녹화 엔진을 Electron에서 네이티브 Swift로 재작성

무엇이 바뀌었나

AI 회의 기록 서비스 Circleback가 데스크톱 앱의 회의 녹화 엔진을 Electron 렌더 프로세스 기반에서 네이티브 코드로 다시 작성했다고 밝혔다. macOS에서는 ScreenCaptureKit, Windows에서는 libobs를 사용하는 방식으로 바뀌었으며 전체 작업에는 2개월이 걸렸다. Circleback는 봇을 회의에 초대하지 않고 데스크톱 앱이 화면과 오디오를 직접 캡처해 클라우드로 스트리밍하는 방식을 쓰는데, 이 캡처 엔진 자체를 새로 짠 것이다.[1]

이 과정에서 회사는 자체 내부 도구 'Atomic'을 만들어 사용했다. Swift 쪽 상태 관리에 쓰이는 Combine/OpenCombine의 @Published 속성을 프론트엔드 React가 쓰는 상태 관리 라이브러리 Jotai의 atom으로 자동 매핑해주는 브릿지로, 네이티브 코드와 웹 기반 UI가 공존하는 구조에서 상태를 동기화하기 위해 만들어진 것으로 보인다.[1]

재작성 과정에서 드러난 세부 기술 이슈

회사가 공개한 세부 내용을 보면 실제 캡처 엔진을 네이티브로 옮기면서 마주친 문제들이 꽤 구체적이다. macOS에서는 화면·시스템 오디오·마이크 오디오가 각각 독립된 하드웨어 클록을 쓰는 3개의 소스로 캡처되는데, 이 소스들 사이의 시간차(드리프트)가 30분 이상 이어지는 회의에서는 사람이 들을 수 있는 수준까지 벌어질 수 있다고 한다.[1] 이를 감지하기 위해 3개 연속 버퍼를 확인하는 방식을 쓰고, 특정 오디오 소스가 멈춘 것으로 판단되면 500ms 안에 단일 소스 모드로 전환하도록 설계했다.[1]

가상 오디오 드라이버 관련 문제도 언급됐다. 일부 가상 드라이버가 실제로는 44.1kHz로 오디오를 전달하면서 시스템에는 48kHz로 잘못 보고하는 경우가 있어, 샘플레이트를 그대로 신뢰하지 않고 별도로 검증하는 로직이 필요했다고 한다.[1] 최종 결과물은 fragmented MP4 형식으로 인코딩돼 스트리밍되며, Windows에서는 libobs를 감싼 자체 Swift 래퍼 OBSKit을 만들고 화면 캡처에는 Windows Graphics Capture(WGC)와 BitBlt를 함께 활용한 것으로 확인된다.[1]

실무에 주는 의미

이번 사례는 Electron 기반으로 데스크톱 미디어 캡처 앱을 만들어온 개발팀에 참고가 될 만하다. Electron 렌더 프로세스에서 화면·오디오 캡처를 처리하면 크로스플랫폼 개발은 쉬워지지만, 장시간 세션에서 발생하는 오디오-비디오 드리프트나 하드웨어 클록 편차, 드라이버별 예외 처리 같은 문제는 네이티브 API로 직접 제어하지 않으면 근본적으로 해결하기 어려울 수 있다는 점을 보여준다. 회의 녹화, 화면 녹화, 라이브 스트리밍처럼 저지연·장시간 오디오 동기화가 중요한 제품을 만드는 개발팀이라면, ScreenCaptureKit이나 libobs 같은 플랫폼별 네이티브 캡처 API로 전환할 때의 비용과 이득을 검토하는 데 이번에 공개된 기술적 디테일이 판단 기준이 될 수 있다.

또한 Swift 같은 네이티브 언어와 React 기반 UI를 함께 쓰는 하이브리드 아키텍처를 유지하려는 팀에는, Atomic처럼 상태 관리 라이브러리 간 자동 브릿지를 만드는 접근이 하나의 선택지로 참고될 만하다. 다만 이는 Circleback가 자사 제품 구조에 맞춰 만든 사내 도구로, 외부 공개나 오픈소스화 여부는 확인되지 않는다.

확인이 더 필요한 부분

이번 재작성 작업이 정확히 언제 시작되고 끝났는지 구체적인 날짜는 공개되지 않았다. 소요 기간이 2개월이라는 점만 확인되며, 게시 시점과 프로젝트 진행 시점이 직접 연결되는지도 알 수 없다.[1] Atomic 도구의 외부 공개 계획이나, 이번 재작성이 실제 사용자 체감 품질(녹화 안정성, 지연시간 등)에 어떤 변화를 가져왔는지에 대한 정량적 수치도 아직 공개되지 않았다.