좌표를 옮겨 적는 도면 작업 개선하기

지금 회사의 서비스에서 도면은 사용자가 공간의 구조와 기기의 위치를 이해하는 데 사용됩니다. 일부 도면에서는 사용자가 공간의 상태를 확인하거나 도면 위에서 기기를 제어할 수도 있습니다. 화면에 놓인 하나의 이미지처럼 보이지만, 실제로는 공간과 기기 데이터가 연결된 인터페이스인 셈입니다.

도면 기반 기능은 잘 발전시키면 서비스의 강점이 될 수 있다고 생각했습니다. 문제는 도면 하나를 추가하거나 수정할 때마다 디자인팀, 프론트엔드팀, 백엔드팀의 작업이 차례로 필요했다는 점입니다. 기능을 고도화하기 전에 도면을 만들고 유지하는 비용부터 줄여야 했습니다.

이 시리즈에서는 수동으로 좌표를 옮겨 적던 작업에서 출발해, 도면 데이터를 추출하는 플러그인을 만들고 운영팀이 연결 정보를 직접 관리할 수 있도록 개선한 과정을 세 편에 걸쳐 정리합니다. 첫 번째 글은 어떤 문제에서 출발했고, 왜 팀에서 관리하는 플러그인을 만들기로 했는지에 관한 이야기입니다.

하나의 공간을 세 가지 도면으로 표현하기

서비스에서 사용하던 도면은 크게 세 가지 형태였습니다.

첫 번째는 실제 도면을 서비스 스타일에 맞게 가공한 서비스화 도면입니다. 사용자가 공간의 구조와 기기 위치를 쉽게 파악할 수 있도록 정리한 이미지입니다.

두 번째는 2D 도면입니다. 공간을 평면으로 표현하면서 도면 위의 공간과 기기를 서비스 데이터에 연결합니다. 사용자는 각 공간의 정보를 확인하고 기기와 상호작용할 수 있습니다.

세 번째는 3D 블록 도면입니다. 공간을 입체적인 블록 형태로 보여줍니다. 시각적으로 공간을 이해하는 데 도움이 되지만, 별도로 제작하고 유지해야 하는 부담이 있었습니다.

(실제 서비스 도면이나 매장 구조는 아닙니다)

같은 공간을 담고 있어도 표현 방식마다 도면을 따로 준비해야 했습니다. 지원하는 형태가 늘어날수록 처음 만드는 작업도 늘고, 공간 구조나 기기 위치가 바뀌었을 때 확인해야 할 대상도 많아졌습니다.

초기 작업 방식

초기의 도면 등록 과정은 다음과 같았습니다.

1. 디자인팀이 Figma에서 도면을 제작합니다.
2. 프론트엔드팀이 각 요소의 위치와 크기를 확인해 JSON으로 정리합니다.
3. 백엔드팀이 전달받은 데이터를 서버에 반영합니다.

제가 담당하던 것은 두 번째 단계였습니다. Figma에서 공간과 기기 요소를 하나씩 선택한 뒤 x, y, width, height 같은 값을 확인해 옮겨 적었습니다.

도면 안에 요소가 N개 있고 도면이 M개라면, 사람이 확인해야 하는 대상은 대략 N × M개가 됩니다. 도면이 많아질수록 작업량이 그대로 늘어나는 구조였습니다. 숫자를 잘못 적거나 요소를 빠뜨릴 여지도 있었습니다.

수정할 때도 비슷한 과정이 반복됐습니다. 공간 구조나 기기 위치가 바뀌면 요청을 받아 도면을 고치고, 변경된 데이터를 다시 추출하고, 서버에 반영해야 했습니다. 앞 단계가 끝나야 다음 담당자가 작업할 수 있어 실제 작업 시간에 팀 사이의 대기 시간까지 더해졌습니다.

그러다 Figma 안에 이미 위치와 크기가 데이터로 존재한다는 점이 눈에 들어왔습니다. 사람이 화면에서 그 값을 읽어 다시 데이터로 입력하고 있었습니다. 먼저 이 부분부터 줄여보기로 했습니다.

이미 함께 쓰는 도구 안에서 해결하기

해결할 위치는 Figma로 정했습니다. 디자이너와 개발자가 이미 도면을 제작하고 검토하며 소통하는 공간이었기 때문입니다.

새로운 도구로 작업을 옮기면 사용법을 익히고 기존 흐름을 다시 맞춰야 합니다. Figma 안에서 데이터를 추출할 수 있다면 도면을 만드는 방식은 유지하면서 반복 작업만 줄일 수 있었습니다.

처음부터 직접 플러그인을 만들기로 한 것은 아니었습니다. 먼저 JSON을 추출해주는 기존 플러그인들을 시험해봤습니다.

외부 플러그인에 정제 스크립트를 붙인 첫 시도

당시 확인한 플러그인 중에는 필요한 값이 빠지는 것도 있었고, 사용하던 환경에서 정상적으로 동작하지 않는 것도 있었습니다. 반대로 도면을 구성하는 정보를 거의 전부 추출하는 플러그인도 있었습니다.

필요한 값이 포함돼 있다면 결과를 다시 정제할 수 있으므로, 우선 많은 정보를 추출하는 플러그인을 활용해보기로 했습니다. 시험한 도면 하나에서도 결과가 약 1만 줄에 달했습니다. 서비스에서 도면을 렌더링하는 데 필요하지 않은 디자인 속성까지 포함되어 있었기 때문입니다.

그래서 추출된 노드를 순회하면서 필요한 요소를 찾고, 이름과 위치, 크기 등의 값만 새로운 JSON으로 모으는 스크립트를 작성했습니다.

작업의 단위는 눈에 띄게 줄었습니다.

as-is: 요소 선택 → 값 확인 → 입력 → 다음 요소에서 반복

to-be: 도면 추출 → 정제 스크립트 실행

사람이 모든 요소를 클릭하는 과정은 줄었지만, 이 방식을 계속 사용하기에는 몇 가지 한계가 있었습니다.

• 추출한 파일에 별도의 스크립트를 실행해야 했습니다.
• 사각형 중심의 처리만으로는 다각형 공간을 충분히 표현하기 어려웠습니다.
• 외부 플러그인에 문제가 생겼을 때 팀에서 수정할 수 있는 범위가 제한적이었습니다.

데이터 추출이 앞으로 더 고도화될 가능성까지 생각하면, 서비스에 필요한 규칙을 플러그인 안에 넣고 팀에서 직접 관리하는 편이 적절하다고 판단했습니다.

직접 관리할 범위를 정하기

직접 구현하면 플러그인을 유지보수하는 일도 팀의 책임이 됩니다. 그래서 처음부터 많은 기능을 넣기보다 현재의 반복 작업을 없애는 데 필요한 범위부터 정했습니다.

1. 사용자가 Figma에서 도면을 선택합니다.
2. 플러그인이 선택한 도면에서 필요한 위치, 크기, 형태 정보를 추출합니다.
3. 결과를 JSON으로 확인하고 복사할 수 있게 합니다.

기존에 별도로 실행하던 정제 과정은 플러그인 내부로 옮겼습니다. 다각형 형태를 다루기 위해 SVG 정보도 함께 추출했습니다. 필요한 데이터의 범위를 서비스에 맞춰 결정하고, 요구사항이 바뀌면 직접 수정할 수 있는 구조를 만든 것입니다.

내 작업에서 팀 사이의 작업으로

처음에는 제가 좌표를 덜 옮겨 적기 위한 도구라고 생각했습니다. 구현을 진행할수록 디자인팀과 백엔드팀의 작업도 함께 보이기 시작했습니다.

필요한 요소만 안정적으로 추출하려면 디자인팀과 도면 제작 규칙을 맞춰야 했습니다. 추출한 결과를 서비스에서 사용하려면 백엔드팀과 데이터 형식도 정해야 했습니다. 제 단계만 짧아지고 앞뒤 단계에서 다시 데이터를 가공한다면 전체 과정에는 여전히 일이 남습니다.

그래서 다음 목표는 플러그인으로 데이터를 얻는 것에서 서버에 반영하는 과정까지 연결하는 것으로 넓어졌습니다. 다음 글에서는 플러그인의 실행 구조와 도면 제작 규칙, 중첩된 레이어의 좌표를 하나의 기준으로 맞춘 방법을 정리하겠습니다.