운영팀이 도면 연결 정보를 직접 관리하게 만들기

앞선 두 글에서는 도면 요소의 좌표를 옮겨 적던 작업을 Figma 플러그인으로 자동화하고, 제작한 도면을 서비스 데이터로 연결하는 과정을 정리했습니다.

도면을 처음 등록하는 일은 간단해졌습니다. 하지만 운영을 이어가자 등록 이후의 문제가 보이기 시작했습니다. 공간이나 기기 정보가 바뀌면 이미 등록한 도면과 실제 데이터 사이에 차이가 생겼고, 이를 수정하려면 다시 개발팀을 거쳐야 했습니다.

이번 글에서는 도면의 형태와 연결 정보를 나눠 관리하고, 운영팀이 백오피스에서 공간과 기기의 연결을 직접 변경할 수 있도록 바꾼 과정을 다룹니다. 함께 진행한 또 다른 개선인 도면 데이터 재사용도 소개합니다.

추출을 자동화해도 변경 요청은 남았다

도면을 제작할 때는 각 요소가 서비스의 어떤 공간과 기기를 가리키는지 함께 저장했습니다. 그래야 도면 위에 현재 상태를 표시하고 사용자의 상호작용을 실제 데이터와 연결할 수 있습니다.

문제는 운영 중 공간과 기기 정보가 바뀐다는 점이었습니다. 그림으로는 같은 위치에 같은 기기가 보이더라도 연결된 식별 정보가 현재 데이터와 맞지 않으면 올바른 정보를 보여줄 수 없습니다.

당시에는 이 변경을 반영하려면 다음 과정을 거쳐야 했습니다.

1. 운영팀이 변경 사항을 개발팀에 전달합니다.
2. 개발팀이 Figma 도면의 연결 정보를 수정합니다.
3. 플러그인으로 도면 데이터를 다시 추출합니다.
4. 수정된 데이터를 서버에 다시 반영합니다.

좌표를 수기로 입력하는 일은 사라졌지만, 연결 정보 하나를 바꾸기 위해 Figma로 돌아가는 흐름은 남아 있었습니다. 플러그인의 추출 속도를 더 높여도 그 작업을 요청하고 기다리는 시간까지 없어지지는 않았습니다.

여기에서 자동화의 범위를 다시 생각하게 됐습니다. 첫 번째 개선은 도면을 서비스에 등록하는 작업을 대상으로 했습니다. 운영 단계에서는 이미 등록된 도면을 현재의 공간과 기기 정보에 맞게 유지하는 방법이 필요했습니다.

도면의 형태와 연결 정보를 나눠서 보기

도면의 변경은 두 종류로 나눌 수 있었습니다.

하나는 도면 형태의 변경입니다. 공간의 모양이나 배치가 달라지면 도면 자체를 수정해야 합니다. 도형의 모양, 크기, 좌표가 달라지는 작업입니다.

다른 하나는 연결 정보의 변경입니다. 도면의 모습은 그대로지만 도면 요소와 연결할 공간이나 기기 데이터가 달라지는 경우입니다. 이때는 기존 도형의 좌표와 크기를 다시 추출할 필요가 없습니다.

기존에는 두 변경이 모두 Figma 수정과 데이터 재등록으로 이어졌습니다. 실제로 바뀐 범위보다 거쳐야 하는 과정이 넓었습니다.

운영팀은 어떤 공간이나 기기 정보가 바뀌었는지 가장 먼저 알고 있었습니다. 그렇다면 도면의 형태를 건드리지 않는 연결 작업은 운영팀이 직접 처리할 수 있어야 한다고 생각했습니다.

운영팀이 도면을 보면서 직접 관리하도록

운영팀이 사용하는 백오피스에서 2D 도면 데이터를 직접 렌더링했습니다. 이어서 도면 위의 요소와 실제 공간·기기를 연결할 수 있는 관리 기능을 추가했습니다.

이제 연결 정보가 바뀌면 운영팀이 관리 화면에서 대상 요소를 확인하고 새로운 공간이나 기기를 매칭할 수 있습니다. 이 범위의 변경을 위해 개발팀에 Figma 수정을 요청하거나 도면 전체를 다시 등록할 필요가 없어졌습니다.

도면을 보면서 관리한다는 점도 중요했습니다. 식별자만 나열된 표에서는 실제 공간과 기기의 위치를 함께 판단하기 어렵습니다. 관리 화면에 도면을 표시하면 어떤 요소를 변경하고 있는지 공간의 맥락 안에서 확인할 수 있습니다.

작업의 흐름은 다음과 같이 바뀌었습니다.

처음 도면을 만드는 과정에는 여전히 디자인팀과 개발팀의 역할이 필요합니다. 디자인팀은 도면의 형태를 제작하고, 개발팀은 플러그인을 통해 데이터를 등록합니다. 그 이후의 공간·기기 연결은 운영팀이 이어서 관리합니다.

각 팀이 잘 알고 있는 정보를 직접 다루도록 작업 경계를 정리한 것입니다.

하나의 도면을 여러 형태로 재사용하기

운영 방식과 함께 제작 과정에 남아 있던 중복 작업도 개선했습니다. 서비스화 도면, 2D 도면, 3D 블록 도면을 각각 제작하던 부분입니다.

세 도면은 표현 방식이 다르지만 같은 공간을 담고 있습니다. 각각 바탕부터 따로 만들면 처음 제작할 때도 작업이 반복되고, 공간 구조가 바뀌었을 때 수정해야 할 대상도 늘어납니다.

그래서 서비스화 도면을 공통 출발점으로 삼았습니다. 플러그인이 도면의 형태를 분석해 2D 공간 후보를 만들고, 작업자가 그 결과를 확인하고 수정한 뒤 적용하도록 했습니다. 반복적인 형태 추출은 플러그인이 맡고, 최종 공간은 사람이 확인하는 흐름입니다.

완성된 2D 도면 데이터는 서비스의 2D 화면에 사용합니다. 같은 데이터는 3D 블록 도면을 렌더링할 때도 재사용합니다.

출처: SeedN 공식 LinkedIn.

이 흐름에서는 디자인팀이 서비스화 도면을 제작하면 시스템이 이를 바탕으로 2D 도면을 만들고, 3D 표현도 같은 데이터를 사용합니다. 같은 공간을 위해 세 종류의 원본을 별도로 제작하던 부담을 줄일 수 있었습니다.

제작부터 운영까지 이어진 새로운 흐름

두 차례의 개선을 거친 전체 과정은 다음과 같습니다.

1. 디자인팀이 Figma에서 서비스화 도면을 제작합니다.
2. Figma 플러그인이 서비스화 도면을 2D 형태로 변환합니다.
3. 작업자가 분석 결과를 확인하고 필요한 부분을 수정합니다.
4. 플러그인이 도면 데이터를 추출해 서버에 반영합니다.
5. 서비스가 같은 데이터를 바탕으로 2D와 3D 도면을 렌더링합니다.
6. 운영팀이 백오피스에서 공간과 기기의 연결 정보를 관리합니다.

각 팀의 작업에도 변화가 생겼습니다.

• 디자인팀은 같은 공간을 여러 형태로 따로 제작하는 작업을 줄였습니다.
• 프론트엔드팀은 좌표를 옮겨 적고 변경 요청에 따라 Figma를 반복해서 수정하던 작업을 줄였습니다.
• 백엔드팀은 도면마다 전달받은 데이터를 수동으로 입력하는 단계를 덜었습니다.
• 운영팀은 공간과 기기의 연결 변경을 관리 화면에서 직접 처리할 수 있게 됐습니다.

별도로 제작하는 도면이 세 종류에서 한 종류로 줄었다는 점은 분명하지만, 이를 제작 시간의 일정한 비율로 표현하지는 않았습니다. 도면마다 구조와 검수 난이도가 다르고, 변환 결과를 확인하는 작업도 남아 있기 때문입니다.

반복 작업을 줄인 뒤에 보인 것

처음에는 프론트엔드의 반복 입력이 가장 눈에 띄었습니다. 매번 직접 해야 하는 일이었고, 도면이 복잡할수록 부담도 컸습니다. 그래서 이 작업부터 줄여보고 싶었습니다.

플러그인을 만들고 나니 그 앞뒤의 일도 보이기 시작했습니다. 디자인팀이 도면을 만들고 서버에 등록하는 과정, 운영 중 정보가 바뀌면 다시 수정을 요청하는 과정까지 살펴보게 됐습니다. 좌표를 추출하는 일은 쉬워졌지만, 변경 요청을 받아 도면을 고치는 일은 남아 있었습니다. 이렇게 남은 일을 하나씩 개선하다 보니, 도면 제작에 사용할 요소를 생성하고 운영팀이 직접 연결 정보를 수정하는 기능까지 만들게 됐습니다.

처음부터 이 과정 전체를 바꾸려던 것은 아니었습니다. 제가 하던 일을 조금 편하게 만들어보려다 다른 팀의 작업까지 알아가게 됐습니다.

눈앞의 불편만 해결하기보다, 그 일의 전체 과정을 파악하여 이 일이 어떻게 이어지고, 어떤 상황에 변경점이 생기는지까지 함께 살펴봐야 한다는 점을 배운 프로젝트였습니다.

그리고 조금 더 욕심을 내본다면, 지금은 디자인팀이 직접 제작하는 서비스화 도면까지 자동으로 그릴 수 있을지 도전해보려고 합니다. 도면 데이터를 추출하고 여러 형태로 변환하는 데서 더 나아가, 도면을 그리는 과정 자체는 어디까지 자동화할 수 있을지……