폐쇄망 UI 디자인 툴 도입: 대표 파일로 검증하는 방법

외부 인터넷 접근이 제한된 업무망에서 UI 디자인 도구를 고를 때는 ‘내부 서버에 설치할 수 있는가’와 ‘그 환경에서 필요한 작업을 끝낼 수 있는가’를 따로 판단해야 합니다. 먼저 로그인, 편집, 저장, 공유, 개발자 전달을 필수 경로로 정하고, AI나 플러그인은 실제 업무에 필요한 항목만 별도로 다룹니다.

망분리 방식과 외부 연결의 예외 승인 절차는 조직마다 다릅니다. 특정 업종이라는 이유만으로 모든 클라우드 도구가 금지된다고 단정하지 마세요. 오픈소스와 상용 프라이빗 배포의 차이를 먼저 구분한 뒤, 이 글에서는 승인된 시험망에 대표 파일을 옮겨 도입 범위를 결정하는 과정을 살펴보겠습니다.

1. 차단 원인과 필요한 작업을 구분하기

Figma의 클라우드 공동 편집에는 서비스 연결이 필요합니다. 일부 오프라인 작업이 가능한지와 서비스를 자체 서버에 배포하는지는 별개의 문제입니다. 단순히 기존 파일이 열리는지만 보지 말고 로그인, 라이브러리 사용, 공동 작업, 저장과 다시 열기까지 이어 보세요.

예를 들어 내부 업무 시스템을 만드는 팀이 ‘신청 목록 → 상세 검토 → 승인 결과’ 화면을 옮긴다고 가정해 보겠습니다. 인터넷 연결은 제한되지만 디자이너와 개발자는 같은 내부망에 있습니다. 이 팀의 필수 작업은 한글이 포함된 파일 편집, 공통 컴포넌트 사용, 내부 검토와 에셋 전달입니다. 외부 AI 이미지 생성은 이번 도입의 필수 조건이 아닙니다.

이처럼 필수와 선택을 먼저 나누면 AI 기능 하나가 동작하지 않아도 기본 제작 경로를 검토할 수 있습니다. 반대로 내부 인증이나 저장이 되지 않는 문제를 ‘대부분의 기능은 된다’는 말로 넘길 수 없게 됩니다.

2. 자체 호스팅과 상용 배포를 같은 조건으로 비교하기

Penpot은 자체 호스팅과 상용 지원 옵션을 제공하며, Pixso는 프라이빗 배포 상담을 제공합니다. 자체 호스팅 여부만으로 운영 비용이나 지원 수준이 같아지는 것은 아닙니다. 동일한 사용자 수, 설치 환경, 백업 범위와 지원 책임을 놓고 비교해야 합니다.

대표 파일은 보기 좋은 한 화면보다 작업의 경계를 담아야 합니다

원본의 복사본을 만들고 신청 목록과 상세 화면, 공통 버튼, 한글 글꼴, 이미지, 상태별 컴포넌트, 필요한 화면 전환을 포함하세요. 조직이 사용을 허용한 자료만 시험망에 반입합니다. 실제 고객 정보 대신 같은 길이와 형식의 예시 데이터를 쓰면 민감한 데이터를 옮기지 않고도 글자 넘침과 표의 구조를 확인할 수 있습니다.

가져오기 직후에는 화면 모양만 비교하지 않습니다. 디자이너가 신청명을 길게 바꾸고 버튼 상태를 수정한 뒤 저장하고, 다른 편집자가 파일을 다시 열어 변경을 이어 가게 합니다. 개발자는 이미지 에셋과 필요한 디자인 사양을 확인합니다. 화면이 한 장의 이미지로만 남았다면 열기는 성공했어도 편집 가능한 이전에는 실패한 것입니다.

내부 설치라고 해서 AI·플러그인·글꼴 서비스까지 모두 외부 통신 없이 작동하는 것은 아닙니다. 각 기능이 연결하는 서비스가 다르기 때문입니다. 글꼴을 내부에 보관할 수 있어도 해당 글꼴의 사용권이 생기는 것은 아니므로, 조직이 확보한 사용 범위 안에서 배포합니다.

실패한 항목은 같은 방식으로 처리하지 마세요

위 예시에서는 디자이너가 편집 구조와 화면 결과를, 개발자가 전달할 사양을, IT가 인증·운영·복구를 담당하도록 나눕니다. 한 사람이 모든 항목에 ‘가능’이라고 표시하는 것보다 실패를 누구에게 넘길지 분명해집니다.

3. 반입과 운영에서 자주 놓치는 범위

KRDS 리소스를 폐쇄망에서 활용하려면? 필요한 컴포넌트와 문서를 승인된 경로로 반입하고 사용 조건과 버전을 함께 보관합니다. Figma 파일로만 제공된 자산은 가져온 뒤 색상·글꼴·컴포넌트가 편집 가능한지 확인하세요. ‘파일이 있다’와 ‘새 도구에서 관리할 수 있다’는 다른 조건입니다.

외부 인터넷이 전혀 없는 경우에는? 설치 시점뿐 아니라 활성화, 인증, 갱신, 패치와 장애 지원의 경로를 나눠 정해야 합니다. 시험망에서는 실제 운영과 같은 연결 조건을 적용합니다. 설치 때만 외부 인터넷을 잠시 열어 성공한 결과를 전체 오프라인 운영의 근거로 사용하지 마세요.

기존 파일을 모두 한 번에 옮겨도 될까요? 원본을 보관하고 대표 파일로 편집·공유·전달 경로가 성립하는지 먼저 봅니다. 그 결과를 바탕으로 단순한 파일과 복잡한 파일을 나눠 순서대로 이전합니다. 변환되지 않는 동작이 있다면 새 도구의 지원 방식으로 재구성할지, 기존 파일을 참고 자료로 남길지 결정합니다.

누가 운영을 담당하나요? 공급업체와 내부 IT의 역할을 나눠야 합니다. 계정 발급·회수, 보안 패치, 백업·복원, 장애 연락 창구와 응답 목표를 각각 맡길 주체를 정합니다. 파일 편집이 가능하다는 확인만으로 운영 인수까지 끝난 것은 아닙니다.

4. 통과한 작업 범위부터 도입하기

예시 팀에서 로그인·편집·저장·내부 검토·에셋 전달이 가능하고 외부 AI만 제외됐다면, ‘기본 UI 제작과 내부 검토’로 도입 범위를 제한할 수 있습니다. 반면 필수 인증이나 백업 복원이 되지 않았다면 화면이 잘 보이더라도 먼저 그 문제를 해결해야 합니다.

최종 결정에는 승인된 사용 범위, 이전 대상 파일, 남은 수작업, 운영 담당자와 보류된 기능을 남기세요. 범위가 명확하면 팀은 사용할 수 없는 기능을 반복해서 시도하지 않고, 다음 확장 시 어떤 조건을 충족해야 하는지도 알 수 있습니다. 기능 이름이나 ‘Figma와 동등하다’는 설명보다 실제 업무 경로가 판단 기준이 되어야 합니다.