왜 지금 이 비교가 필요한가
팀에서 누군가 "무료 브라우저 기반 벡터 툴이 나왔다"는 링크를 공유하면, 의사결정자는 곧 비슷한 질문을 받는다. "Illustrator 라이선스 줄여도 될까요?" "Figma 없이 써도 되나요?" 비용이 분명한 절감 이유처럼 보이기 때문에 압력은 꽤 구체적으로 들어온다.
Scissor는 설치 없이 브라우저에서 실행되는 벡터·픽셀 혼합 에디터다. 계정 가입도 없고, 작업물은 서버에 올라가지 않으며, 현재 무료로 제공된다. 기능 목록을 훑으면 펜 툴, 패스 편집, 라이브 이펙트, 타입 툴, 심볼, 그라디언트, 익스포트까지 벡터 작업의 기본 체계를 갖추고 있다.
그런데 "기능이 있다"는 사실과 "우리 팀 워크플로를 감당할 수 있다"는 판단은 다른 문제다. 아래에서 다섯 개 축을 세워 어떤 조건에서 Scissor가 실질적인 대안이 될 수 있고, 어디서 한계가 드러나는지 따져본다.
파일 호환성: .ai·.fig 파일을 주고받는 팀이라면 먼저 확인해야 한다
Scissor 공개 자료에서 Adobe Illustrator(.ai), Figma(.fig), EPS 등 주요 포맷의 직접 가져오기·내보내기를 지원한다는 내용은 확인되지 않는다. 익스포트는 PNG, JPEG, WEBP, SVG 네 가지로 명시되어 있다.
즉, SVG를 중간 포맷으로 쓰는 한에서는 다른 툴과 파일을 주고받을 수 있다. 하지만 이미 Illustrator나 Figma 파일로 쌓인 에셋이 있다면, 변환 과정에서 레이어 구조나 폰트 처리가 얼마나 보존되는지를 먼저 직접 검증해야 한다. 이 부분은 Scissor 자체 설명에도 없고, 현 시점에서 외부 검증 데이터도 충분하지 않다. 기존 에셋 규모가 클수록 이 확인 비용이 먼저 든다.
클라이언트나 협력사가 특정 포맷으로 파일 납품을 요구하는 업무라면, 현재 Scissor를 단독 메인 툴로 쓰기는 어렵다.
협업 구조: 실시간 공동편집이 필요한 팀은 다르게 봐야 한다
Figma의 핵심 가치 중 하나는 여러 사람이 같은 파일에서 동시에 작업하고 코멘트를 남기는 흐름이다. 디자이너·PM·개발자가 링크 하나로 검토 의견을 주고받는 방식은 이미 많은 팀의 기본 프로세스가 됐다.
Scissor는 "모든 작업이 브라우저에서 실행되고 파일은 기기에 저장된다"는 구조를 택했다. 이 방식이 보안 측면에서는 장점이 되지만, 협업 측면에서는 파일을 수동으로 공유하고 버전을 별도로 관리해야 한다는 뜻이기도 하다. 공식 자료에서 실시간 협업이나 댓글 기능을 언급하지 않는다.
팀 규모가 작고, 결과물을 SVG나 이미지 파일로 전달하는 방식으로 이미 일하고 있다면 협업 부재가 실질적인 장애는 아닐 수 있다. 반면 "링크 보내면 바로 피드백"이 기본값인 팀이라면 Scissor를 쓰면서 별도 리뷰 프로세스를 다시 만들어야 한다.
보안과 데이터 주권: 장점과 리스크가 같은 곳에 있다
서버에 파일을 올리지 않는 구조는 특정 보안 요건에서 오히려 유리하다. 기밀 프로젝트 초안이나 내부 브랜드 에셋을 외부 클라우드에 올리고 싶지 않은 조직이라면, 이 특성 자체가 도입 이유가 될 수 있다.
그런데 같은 이유로, 백업과 복구도 온전히 사용자 책임이다. Scissor 이용 약관은 작업 손실이나 데이터 훼손에 대한 책임을 명시적으로 부담하지 않는다. "as-is" 제공, 무보증, 예고 없이 서비스·기능이 변경·중단될 수 있다는 조항을 사용 전에 팀 차원에서 확인해야 한다.
엔터프라이즈 환경에서는 별도 SLA(서비스 수준 계약)나 지원 채널 없이 이런 조건을 IT 정책이나 계약에 반영하기 어렵다. 보안 승인 프로세스가 있는 조직이라면, 무료·무계정 서비스가 내부 검토를 통과할 수 있는지를 먼저 확인하는 편이 순서다.
성능과 기능 범위: Scissor가 실제로 감당할 수 있는 업무
Scissor가 공개하는 기능 목록은 상당히 넓다. 펜 툴, 패스 편집, 워프 계열 도구, 심볼, 메시 툴, 그라디언트, 타입 도구, 보드, 슬라이스까지 기본적인 벡터 그래픽 작업 흐름을 커버한다.
단, 브라우저에서 실행된다는 사실이 성능의 상한을 정한다. 복잡한 패스가 많거나 고해상도 픽셀 레이어를 다루는 작업에서 브라우저 기반 툴이 네이티브 앱 수준의 처리 속도를 내는지는 아직 충분한 검증 데이터가 없다. 특히 수백 개 오브젝트가 포함된 도면이나 대용량 심볼 라이브러리를 다루는 경우, 실제 쓰면서 성능을 직접 확인해야 한다.
플러그인 생태계 측면에서는 Illustrator·Figma와 비교할 수준의 서드파티 확장이 존재한다는 정보가 없다. 특정 플러그인에 워크플로가 의존하는 팀이라면 그 부분을 명시적으로 점검해야 한다.
반면 아이콘 드로잉, 간단한 UI 요소 제작, 소규모 브랜드 에셋 작업처럼 툴 고유 기능보다 사용자 숙련도가 결과를 좌우하는 작업에서는 충분한 도구다. Illustrator나 Figma의 고급 기능을 실제로 쓰지 않는 팀원이 적지 않다면, 그 범위에서는 대체 가능성이 있다.
실제로 어떤 팀에 어떤 방식으로 쓸 수 있는가
전면 교체보다는 용도별 분리가 현실적인 경로다.
Scissor가 맞는 경우: 혼자 또는 소수가 작업하고 SVG나 이미지 파일로 결과를 전달하는 업무, 클라이언트 파일 포맷 요건이 없는 내부 작업, 파일을 클라우드에 올리지 않아야 하는 보안 이유가 있는 초안 작업, 라이선스 비용이 없는 외부 협력자나 프리랜서가 빠르게 작업물을 만들어야 할 때.
기존 툴을 유지해야 하는 경우: 협력사나 클라이언트와 네이티브 파일 포맷으로 주고받는 업무, 실시간 협업과 댓글 리뷰가 기본 프로세스인 팀, 플러그인이나 서드파티 연동에 워크플로가 달려 있는 경우, 서비스 연속성 보장이나 데이터 복구 책임을 계약으로 요구하는 환경.
"무료니까 일단 전환해 보자"는 접근에는 숨겨진 전환 비용이 있다. 파일 변환 검증, 새 프로세스 설계, 팀원 적응 기간, 그리고 서비스가 변경·중단될 때의 대응 비용이다. 이 비용이 라이선스 절감분을 넘는지는 팀의 업무 구조에 따라 달라진다.
도입 전에 팀에서 먼저 확인할 것들
Scissor를 테스트하기로 결정했다면, 아래 순서로 검증하는 것이 효율적이다.
첫째, 현재 Illustrator나 Figma 파일 중 실제로 자주 쓰는 에셋을 SVG로 변환해 Scissor에서 열어보고, 레이어 구조와 폰트가 얼마나 유지되는지 확인한다. 변환 손실이 허용 범위 안인지를 직접 보는 것이 문서 설명보다 빠르다.
둘째, 현재 팀에서 디자인 파일을 공유하고 피드백을 주고받는 방식을 적어본다. 그 프로세스를 Scissor로 어떻게 운영할지 구체적으로 그려보면, 협업 공백이 어디서 생기는지 명확해진다.
셋째, IT 또는 보안 담당자와 함께 브라우저 기반 툴이 내부 정책 요건을 충족하는지 확인한다. 무계정·무서버 구조라도 사용하는 브라우저 환경과 로컬 저장 방식이 IT 정책 검토 대상이 될 수 있다.
넷째, 서비스가 예고 없이 변경되거나 중단될 경우 진행 중인 작업을 어떻게 보존할지 백업 방식을 미리 정한다. 작업물이 기기에만 있다는 점을 팀 전체가 인식하고 운영 루틴을 만들어야 한다.
이 네 가지를 확인하고 나면, Scissor를 어느 업무에, 어떤 범위로 쓸지 결정할 근거가 생긴다. 그 전에 라이선스 계약을 줄이는 건 순서가 거꾸로다.
