생태계 확장: Obsidian의 새로운 플러그인 리뷰 방식
커뮤니티 주도 생태계에 의존하는 모든 플랫폼에서 "scaling bottleneck"은 피할 수 없는 장애물입니다. 도구가 니치한 파워 유저용 애플리케이션에서 주류 지식 베이스로 성장함에 따라, 서드파티 확장을 검토하는 과정은 종종 주요 마찰 지점이 됩니다. Obsidian은 최근 7명의 소규모 핵심 팀이 수백만 명의 사용자를 위해 수천 개의 플러그인을 수동으로 검토해야 하는 상황에 직면하며 이 벽에 부딪혔습니다.
이를 해결하기 위해 Obsidian은 제출 프로세스를 간소화하고 플러그인 생태계의 보안 태세를 강화하기 위해 설계된 새로운 커뮤니티 사이트와 자동화된 리뷰 시스템을 공개했습니다. 이러한 변화는 회사가 개방형 확장성과 플랫폼 안정성 사이에서 어떻게 균형을 맞출 것인지에 대한 중요한 진화를 나타냅니다.
수동 리뷰를 넘어서
최근까지 Obsidian 커뮤니티 갤러리에 새로운 플러그인을 제출하려면 수동 리뷰 프로세스가 필요했습니다. 보안과 품질을 보장하기 위한 의도였지만, 이 방식은 지속 불가능해졌습니다. AI 지원 코딩의 부상으로 플러그인 제작의 진입 장벽이 낮아지면서 제출 건수가 급증하여 핵심 팀의 업무가 과부하되었습니다.
커뮤니티 멤버인 @dtkav가 언급했듯이, 수동 리뷰 프로세스는 "새로운 플러그인을 제출하는 것을 사실상 불가능하게" 만들었으며, 이는 개발자의 좌절과 팀의 번아웃을 초래했습니다. 새로운 자동화 시스템은 이러한 압박을 완화하여 개발자가 보안의 기본 수준을 유지하면서도 자신의 도구를 사용자에게 더 빠르게 전달할 수 있도록 설계되었습니다.
보안 논쟁: 자동화 vs. 샌드박싱
자동화된 검사로의 전환은 개발자 속도 측면에서는 이득이지만, 기술 커뮤니티 내에서는 플러그인의 실제 보안에 관한 상당한 논쟁을 불러일으켰습니다. 현재 모델은 코드를 검토하는 것에 의존하고 있지만, 비판론자들은 이것이 근본적인 아키텍처 리스크를 해결하지 못한다고 주장합니다.
샌드박싱의 필요성
여러 사용자가 강력한 권한 시스템이 없다면 플러그인이 기본적으로 사용자의 시스템에 대한 전체 접근 권한을 갖게 된다는 점을 지적했습니다. 사용자 @troad는 현재 상태를 "click here for RCE" (Remote Code Execution)라고 묘사하며, 플러그인이 여전히 전체 디스크와 네트워크에 접근할 수 있다고 주장했습니다.
마찬가지로, @varun_ch는 자동화된 검사가 플러그인이 악성인지 여부를 신뢰할 수 있게 평가할 수 없다고 제안하며, 유일한 실제 해결책은 "명시적인 API와 권한 시스템을 통해 적절히 샌드박싱하는 것"이라고 제안했습니다.
리뷰에서의 AI의 역할
코드를 검토하기 위해 AI를 사용하는 것에 대해서도 회의론이 존재합니다. 일부는 이를 유망한 유스케이스로 보지만, @aucisson_masque와 같은 다른 이들은 "만약 AI가 코드에서 멀웨어를 찾아낼 수 있다면, 그것은 자기 자신으로부터 멀웨어를 숨길 수도 있다"고 경고합니다.
Obsidian 팀의 통찰
Obsidian CEO Kepano는 이 시스템을 구축하는 과정에서의 어려움에 대한 맥락을 제공하기 위해 토론에 참여했습니다. 그는 이 프로젝트가 1년 동안 준비되어 왔으며 다음과 같은 상충하는 우선순위들 사이에서 균형을 맞춰야 한다고 강조했습니다.
- 채택 용이성: 시스템은 기존 개발자들이 사용하기 쉬워야 합니다.
- 하위 호환성: 수백만 명의 사용자들을 위한 기존 워크플로우를 깨뜨려서는 안 됩니다.
- 점진적 개선: 목표는 즉시 완벽하고 일률적인 솔루션을 시도하는 대신, 보안과 발견 가능성을 반복적으로 강화하는 것입니다.
Kepano는 새로운 시스템을 "work in progress"라고 특징지으며, 팀이 커뮤니티 피드백을 경청하고 리뷰 프로세스를 지속적으로 개선할 것임을 시사했습니다.
커뮤니티 관점 및 마찰 지점
플러그인 리뷰 시스템 외에도, 이번 토론에서는 Obsidian 사용자들을 위한 몇 가지 반복되는 고충점들이 강조되었습니다.
- 오픈 소스 요구 사항: @dakiol과 같은 일부 사용자는 핵심 애플리케이션이 독점적(proprietary)이기 때문에 도구를 사용하기 거부합니다. 폐쇄형 소스 KB (Knowledge Base)에 의존하는 것이 소프트웨어가 변경될 경우 너무 많은 리스크를 만든다는 방식으로 워크플로우를 형성한다는 점을 주장합니다.
- 협업 Gap: Obsidian의 개인 중심적 강력함과 팀의 협업 요구 사항 사이의 간극극이 감지됩니다. 사용자 @jkcorrea는 권한 및 공유 기능의 부재가 Notion과 같은 도구와 비교했을 때 업무 환경에서의 "non-starter"를 만드는 데 있다고 언급했습니다.
- 플랫폼 파리티티(Platform Parity): 일부 사용자는 iOS에서의 경험이 미흡하다고 보고했으며, 플러그인 로딩 및 일반적인 성능 문제를 언급했습니다.
결론
Obsidian의 자동화된 플러그인 리뷰로의 전환은 전 세계적인 커뮤니티를를 관리하는 7명의 팀에게는 필수적인 단계입니다. 이는 개발자 번아웃과 제출 프로세스의 병목 현상을 즉시 해결하지만, 샌드박싱과 공식적인 권한 API를 도입해야 한다는 더 깊은 논의를 열어줍니다. 현재로서는 커뮤니티는 더 확장 가능한, 투명한 시스템으로 나아가고 있지만, "전체 확장성"과 "강화된 보안" 사이의 긴장 관계는 Obsidian의 진화 과정에서 핵심적인 주제로 남아 있습니다.