PlantUML Viewer가 VS Code에서 서버 없이 인터랙티브 SVG 미리보기를 제공함

이 확장은 PlantUML을 별도 렌더링 도구로 다루던 번거로움을 VS Code 안으로 끌어왔다는 점에서 의미가 큽니다. 기사에 따르면 ReViewer 엔진은 자바나 Graphviz, 외부 서버 없이 다이어그램을 로컬에서 SVG로 변환합니다. 이 주장이 실제 사용 환경에서도 유지된다면, 문서와 설계도를 고치는 순간 결과를 확인할 수 있어 피드백 주기가 크게 짧아질 가능성이 큽니다.

특히 실시간 갱신과 확대·축소·이동은 단순한 편의 기능 이상입니다. PlantUML의 강점은 이미지 편집이 아니라 텍스트로 구조를 관리하는 데 있는데, 미리보기가 느리거나 별도 창을 오가야 하면 그 장점이 쉽게 사라집니다. 편집기 옆에서 바로 결과를 보고 SVG와 PNG를 복사할 수 있다면 개발자는 그림의 배치보다 모델의 정확성과 관계 표현에 집중하기 쉬워질 겁니다. 코드 기반 다이어그램이 문서화 과정에 더 자연스럽게 들어오는 셈이죠.

오프라인 실행과 비공개 처리는 기업 환경에서 가장 설득력 있는 부분입니다. 기사에서는 다이어그램 코드가 컴퓨터 밖으로 전송되지 않는다고 설명하고 있으며, 고객 구조나 내부 시스템을 외부 렌더링 서버에 보내기 어려운 팀에는 분명한 장점이 있습니다. 다만 저는 이 대목을 기능 소개만으로 완전히 믿기보다는 확장 프로그램의 실제 네트워크 요청, 포함된 라이브러리, 업데이트 방식까지 확인해야 한다고 봅니다. 프라이버시는 서버가 없다는 문구보다 실행 파일과 통신 경로를 검증할 때 비로소 확보됩니다.

가장 큰 변수는 PlantUML 전체와의 호환성입니다. 기사에는 시퀀스, 클래스, 상태, 마인드맵, WBS, JSON·YAML 등 여러 유형을 지원한다고 나와 있지만, PlantUML 사용자는 기본 문법만 쓰지 않습니다. 복잡한 전처리, 매크로, 외부 파일, 특수한 레이아웃 옵션, 최신 문법까지 기존 서버나 공식 환경과 동일하게 처리되는지는 별도의 문제입니다. 따라서 이 도구가 널리 쓰이려면 지원 목록보다 호환성 테스트 결과와 실패 시 오류 메시지의 품질을 더 투명하게 보여줘야 합니다.

SVG 출력도 양면성이 있습니다. 벡터 형식은 문서와 프레젠테이션에 적합하고 확대해도 선명하지만, SVG 안에 포함되는 스타일과 텍스트 구조가 다른 도구에서 얼마나 안정적으로 열리는지는 확인이 필요합니다. 외부에 공유하는 SVG라면 스크립트나 위험한 속성이 들어가지 않는지, 글꼴이 없는 환경에서도 모양이 유지되는지, 스크린 리더가 관계를 이해할 수 있는지도 중요합니다. 기사에는 고해상도 PNG와 표준 SVG 복사가 언급되지만 접근성·보안·호환성에 대한 설명은 상대적으로 부족합니다.

또 하나의 관건은 성능과 유지보수입니다. 작은 다이어그램에서는 클라이언트 렌더링이 빠르겠지만, 요소가 많은 클래스 다이어그램이나 반복 수정이 잦은 문서에서는 브라우저 메모리와 렌더링 시간이 부담이 될 수 있습니다. ReViewer 엔진이 PlantUML의 변화하는 문법을 얼마나 꾸준히 따라갈지도 지켜봐야 합니다. MIT 라이선스는 생태계 확장에 유리하지만, 라이선스가 곧 장기적인 업데이트와 버그 대응을 보장하는 것은 아닙니다.

그럼에도 방향은 긍정적입니다. 이 확장은 거대한 새 기능보다 설계도 작성의 마찰 제거에 집중하고 있고, 그 선택이 오히려 현실적인 경쟁력이 될 가능성이 큽니다. 이미 VS Code를 작업 공간으로 쓰는 팀이라면 별도 Java 설치와 서버 설정을 줄이는 것만으로 도입 장벽이 낮아집니다. 다만 실제 표준 도구가 되려면 기본 문법 데모를 넘어 대형 프로젝트의 호환성, 오프라인 검증, 오류 복구, 접근성까지 공개적으로 증명해야 합니다. 그 검증을 통과한다면 PlantUML은 단순한 문서 이미지 생성기가 아니라 코드 리뷰와 설계 변경의 일상적인 인터페이스로 자리 잡을 수 있습니다.