카스퍼스키(Kaspersky)의 위기 돌파: 7일 만에 수천 개의 figma파일 가져오기 및 마이그레이션 성공기

1부. 카스퍼스키 소개 및 마이그레이션을 결정한 이유

카스퍼스키(Kaspersky Lab)는 1997년에 설립된 글로벌 사이버 보안의 선두주자입니다. 2025년 말 기준 8억 3,600만 달러의 매출을 기록하고 200개 이상의 국가에 진출한 이 기업은 엔드포인트 보호부터 XDR 및 위협 인텔리전스 제공을 통한 포괄적인 기업 보안에 이르기까지 고도로 복잡한 솔루션을 개발합니다. 이 정도 규모의 기업에게 제품, 분석, 엔지니어링 팀 간의 원활한 동기화는 무엇보다 중요합니다.

하지만 2025년 말, 회사는 불가항력적인 상황에 직면했습니다. 피그마(Figma)로부터 기업 계정 폐쇄 통보를 받은 것입니다. 수천 개의 디자인 목업을 안전하게 저장하고 피그마 파일 옮기기를 완료하는 데 주어진 시간은 단 7일뿐이었습니다.

이 위기 상황에서 카스퍼스키는 글로벌 디자인 팀을 픽소(Pixso)로 긴급 이전하기로 결정했습니다. 이는 우연한 선택이 아니었습니다. Pixso는 이미 사전에 성능 테스트를 마친 도구였기 때문입니다.

카스퍼스키 팀이 활용한 주요 기능에는 디자인 토큰, API 커스텀 설정, 그리고 내장된 AI 기능 등이 포함되었습니다.

이것은 단순한 소프트웨어 교체가 아니라 비즈니스 연속성을 확인하는 극한의 테스트였습니다. 어떻게 단 한 번의 릴리스 중단 없이 수천 개의 figma파일 가져오기를 성공했을까요? 카스퍼스키의 제품 디자인 부서장인 그리고리 데그터(Grigory Degter)로부터 직접 그 과정을 들어보겠습니다.

2부. 1인칭 시점-긴급 마이그레이션의 기록

안녕하세요! 카스퍼스키 제품 디자인 부서를 이끌고 있는 그리고리입니다. 불가항력적인 상황으로 시작해 관리적 도전 과제로 이어졌지만, 결과적으로 우리 프로세스의 안정성, 팀의 저력, 그리고 새로운 기술 파트너의 신뢰성을 확인할 수 있었던 소중한 경험을 들려드리고자 합니다.

이 글을 통해 긴급하게 피그마 파일 다른 계정으로 옮기기와 같은 마이그레이션을 진행하며 겪었던 어려움과 이를 극복한 방법, 그리고 기존 도구를 대체하는 과정에서 우리와 함께 성장할 준비가 된 기술 파트너를 어떻게 찾았는지 공유하고 싶습니다.

위기: 갑작스러운 서비스 중단 통보

시장의 대부분의 제품 팀과 마찬가지로, 우리도 피그마에서 인터페이스를 디자인해 왔습니다. 지난 5~6년간 구축된 디자인 시스템, 컴포넌트 라이브러리, 개발자 핸드오프 프로세스, 플러그인 등 모든 것이 피그마 안에서 안정적으로 작동하며 제품 릴리스 속도를 뒷받침하고 있었습니다. 하지만 어느 날 밤, 이 안정성이 흔들렸습니다.

2025년 11월 21일에서 22일로 넘어가는 밤, 피그마로부터 협력 종료 통보와 함께 일주일 뒤 기업 계정 액세스가 차단될 것이라는 메시지를 받았습니다.

물론 우리는 기존의 리스크를 충분히 이해하고 평가하고 있었기에 대안을 사전에 조사하고 있었습니다. 몇 년 전부터 다양한 솔루션을 테스트한 끝에 우리에게 필요한 기능을 가장 잘 충족하는 옵션이 Pixso라는 결론을 내리고 테스트 라이선스를 구매해 성능을 평가해 왔습니다. 계획은 세워두었지만, 주력 도구를 선제적으로 교체하는 결정을 서두르지는 않았습니다. 하지만 이번 사건이 프로세스 변화를 위한 결정적인 트리거가 되었습니다.

통보를 받은 후 우리의 행동은 크게 몇 가지 단계로 나뉘었습니다.

1단계: 피해 최소화 (데이터 백업)

우리는 정보 보안 분야에서 일하고 있기에 내부 시스템을 위협으로부터 보호하기 위한 선제적 조치의 중요성을 누구보다 잘 알고 있습니다. 불가항력적인 조건 하에서, 우리는 작업 파일과 라이브러리를 최대한 빨리 저장하기 위해 비정기적인 백업 프로세스를 즉시 가동했습니다.

말은 쉬워 보일 수 있습니다. 하지만 수십 개의 복잡한 제품 디자인을 담당하고 1,000개 이상의 파일을 관리하는 부서에게 피그마 파일 옮기기는 결코 간단한 작업이 아니었습니다. 게다가 사내에서 피그마를 사용하는 것은 제품 디자이너뿐만이 아니었습니다. 브랜딩, 마케팅, 소셜 미디어, 분석, 현지화 팀까지 모두가 피그마를 단일 도구로 사용하고 있었기 때문에 사용자 수와 파일 양이 어마어마했습니다.

가장 큰 난관은 피그마가 캡차(CAPTCHA) 인증 없이 한 번에 50개 이상의 목업을 다운로드하는 것을 허용하지 않는다는 점이었습니다. 수천 개의 파일을 생각하니 시간 단위가 아니라 며칠이 소요될 것이라는 공포가 밀려왔습니다. 마지막 날까지 미루는 것은 불가능했습니다.

우리는 즉시 토요일부터 파일 백업을 시작했습니다. 각 디자이너는 자신이 담당한 제품의 백업을 책임졌고, 디자인 리드가 이를 전수 점검했습니다. 또한 사내 모든 피그마 사용자를 위한 소통 채널을 개설했습니다. 우리 팀원 중 한 명은 파일 다운로드를 자동화하는 스크립트를 신속하게 제작하여 캡차를 완전히 우회할 순 없었지만, 적어도 초기 50개 파일을 훨씬 쉽게 다운로드할 수 있도록 도왔습니다.

2단계: 비즈니스 연속성을 유지하는 마이그레이션

백업이 끝난 후, 다음 단계는 Pixso로 데이터를 임포트하고 작업을 시작하는 것이었습니다. Pixso 팀의 신속한 확장 지원 덕분에 우리는 빠르게 환경을 옮기고 figma파일 가져오기를 시작할 수 있었습니다.

물론 어려움도 있었습니다. 아이콘이나 로컬 라이브러리 링크 문제로 임포트가 실패하거나 파일이 열리지 않는 경우가 있었고, 이런 사례들은 일일이 수동으로 해결해야 했습니다.

도구 교체로 인해 분석 및 개발 팀의 업무가 중단되지 않도록 최대한 빨리 파일을 임포트하는 것이 최우선 과제였습니다. 이를 위해 우선순위가 낮은 모든 작업과 내부 디자인 리뷰 프로세스를 일시 중단했습니다. 오직 개발 팀이 목업에 최단 시간 내에 접근할 수 있도록 하는 것에만 집중했습니다. 개발이 진행 중인 핵심 과제부터 우선적으로 처리했습니다.

결과는 성공적이었습니다. 수십 개의 프로젝트 중 단 하나도 우리 때문에 릴리스 날짜가 미뤄지는 일은 없었습니다.

여기서 피그마와 Pixso 개발사 간의 대응 차이가 매우 인상적이었습니다.

• 우리는 수년 동안 피그마의 유료 고객이었음에도 불구하고, 피그마의 고객 지원 팀은 우리의 요청에 매우 미온적으로 반응했으며 때로는 아예 응답하지 않았습니다.
• 반면, Pixso 매니저들은 우리 질문에 적극적으로 답변하고 문제 해결을 도왔습니다. 그들은 선제적으로 우리 팀과 공유 채팅방을 만들어 임포트 중 발생하는 버그를 수집하고 즉각적인 해결책을 제시해 주었습니다.

비동기적인 벤더 지원에 익숙했던 우리 팀에게 이러한 수준의 협력은 매우 이례적이고 가치 있는 경험이었습니다. 도구 제공업체와의 열린 대화는 작업 속도와 프로세스 안정성에 직접적인 영향을 미칩니다.

3단계: 디자인 자산의 "대청소"

개발 팀에 목업 접근 권한을 제공하는 데는 성공했지만, 지속적인 작업을 위해서는 깨진 컴포넌트를 수정하고 라이브러리를 재연결하며 누락된 텍스트 등을 업데이트하는 정리가 필요했습니다.

우리가 진행한 작업은 다음과 같습니다:

• 먼저, 툴의 성능을 극대화하기 위해 모든 파일을 더 작은 단위로 분해했습니다.
• 그다음 디자인 시스템 라이브러리를 게시했습니다. 디자인 시스템 팀은 리스크를 최소화하고 업무 중단 시간을 제로(Zero)로 만드는 데 초점을 맞춰 피그마에서 Pixso로 자료를 이관했습니다. figma에서 pixso로 옮기기 과정에서의 실패를 줄이기 위해 단계별 접근 방식을 택했으며, 문제가 있는 파일은 세분화하여 순차적으로 업로드했습니다.

결과적으로 팀은 100개 이상의 디자인 시스템 파일을 성공적으로 이관했으며, 짧은 시간 안에 모든 링크와 종속성을 복구하여 제품 팀의 디자인 시스템 활용 흐름이 끊기지 않도록 했습니다.

4단계: 미래를 위한 전략 수립

물론 우리는 Pixso가 고유한 아키텍처 특징을 가진 완전히 새로운 소프트웨어라는 점을 명확히 인지하고 있었습니다. 예를 들어, Pixso는 컴포넌트 중첩(Nesting) 접근 방식이 피그마와 약간 달랐습니다. 이는 대부분의 컴포넌트 구조를 대대적으로 재검토하고 업데이트해야 함을 의미했습니다.

상태 관리(Status) 방식이나 문서화의 기술적 동기화 등 플랫폼의 메커니즘을 연구하면서 일부 프로세스의 최적화 필요성을 느꼈습니다. Pixso의 로직에 맞게 컴포넌트를 재구축하는 과정은 오히려 지난 몇 년간 쌓인 기술 부채(레거시)를 제거하고 시스템 전반의 품질을 높이는 전화위복의 기회가 되었습니다.

이러한 세부적인 차이는 대규모 마이그레이션 실무 과정에서만 드러나는 자연스러운 현상입니다. 결과적으로 우리의 전환 작업은 일회성 구출 작전을 넘어, 시스템 개선과 안정화를 위한 일관된 프로세스로 진화했습니다.

현재 우리는 디자인 시스템의 아키텍처 업데이트를 위해 상당한 노력을 기울이고 있습니다. Pixso의 내장 메커니즘을 최대한 효율적으로 활용하기 위한 최적화 전략을 수립 중이며, 이러한 단계적 계획은 카스퍼스키의 글로벌 디자인 시스템을 더욱 견고하고 유연하며 확장 가능하게 만들 것입니다.

결론.

개발 중단 없이 단 며칠 만에 완수한 엄청난 작업량을 되돌아볼 때, 우리는 이 전환이 성공적이었으며 팀의 전문성을 한 단계 성장시킨 중요한 계기였다고 자신 있게 말할 수 있습니다. 이번 경험을 통해 얻은 교훈은 다음과 같습니다:

1. 도구보다 프로세스가 안정성을 결정합니다.
2. 응집력 있는 팀은 어떤 변화도 효과적으로 통과할 수 있습니다.
3. 신뢰할 수 있는 기술 파트너는 장기적 안정성의 핵심 요소입니다.

시장의 여러 선택지 중 우리는 카스퍼스키의 과업에 가장 적합한 도구로 픽소(Pixso)를 선택했습니다. 가장 결정적인 요인은 소프트웨어 개발사가 고객과 함께 진화하고, 고객을 위해 개선하며 협력할 준비가 되어 있다는 점이었습니다.

복잡한 제품 아키텍처를 가진 우리에게 Pixso 팀의 열린 대화와 유연성, 세심함은 특히나 가치 있었습니다. 지속적인 실무 상호작용과 제품 개선에 대한 진정성 있는 준비, 이러한 협력 모델이야말로 안정적인 장기 전략을 구축할 수 있게 합니다. 이는 우리가 필요한 기능을 얻고 Pixso 팀은 업데이트 수요에 대한 생생한 피드백을 받는 상호 호혜적인 협력입니다.

우리의 사례는 체계적인 접근 방식, 성숙한 리스크 관리, 그리고 강력한 팀워크가 있다면 대규모 변화조차 성장의 발판이 될 수 있음을 보여줍니다.

출처: 마이그레이션에서 협업으로: Pixso로의 전환 경험기