조직도 하나 그리는 데
왜 라이브러리가 필요한가
박스와 선을 그리는 일이니 며칠이면 될 것 같습니다. 실제로 착수하면 그때부터 목록이 길어집니다. 웹 다이어그램이 어려운 진짜 이유를 짚어 봅니다.
"조직도 화면 하나 넣어 주세요."
요구사항 회의에서 이 한 줄이 나올 때, 대개 아무도 긴장하지 않습니다. 박스를 그리고 선으로 잇는 일이니까요. 그런데 착수해 보면 이야기가 달라집니다. 박스를 그리는 것은 첫날 오전에 끝나고, 나머지가 몇 달을 잡아먹습니다.
이 글은 그 "나머지"에 관한 이야기입니다. 웹에서 다이어그램을 만든다는 일이 실제로 얼마나 큰 일인지, 그리고 GoJS 같은 전용 라이브러리가 무엇을 대신 지고 있는지 정리했습니다.
박스와 선을 그린 다음에 오는 것들
첫 번째로 부딪히는 것은 배치입니다. 노드가 열 개일 때는 좌표를 손으로 찍어도 됩니다. 그런데 조직이 300명이 되고, 사용자가 부서를 접었다 폈다 하기 시작하면 좌표를 계산해 주는 로직이 필요해집니다. 트리, 계층, 방사형, 격자, 힘 기반 배치는 각각 다른 알고리즘입니다.
두 번째는 선의 경로입니다. 두 박스를 직선으로 잇는 것은 쉽습니다. 그 직선이 다른 박스를 관통하지 않게 하고, 여러 선이 겹칠 때 보기 좋게 꺾이도록 하고, 노드를 드래그하면 선이 따라오게 하는 것은 다른 문제입니다.
세 번째가 되돌리기입니다. 사용자가 노드를 옮기다가 실수하면 되돌릴 수 있어야 합니다. 그런데 다이어그램의 한 동작은 여러 상태 변화를 동시에 일으킵니다. 노드를 옮기면 연결된 선 다섯 개의 경로가 함께 바뀌고, 그것이 하나의 취소 단위로 묶여야 합니다. 드래그하다 만 동작, 편집하다 취소한 값까지 정확히 되돌리려면 트랜잭션 개념이 필요합니다.
여기까지 만들고 나면 다음 요구가 옵니다. 그룹으로 묶어 접게 해 달라, 여러 개를 한꺼번에 선택하게 해 달라, 키보드로도 되게 해 달라, 오른쪽 클릭 메뉴를 넣어 달라, 마우스를 올리면 상세를 보여 달라, 화면 밖으로 나가면 자동으로 스크롤되게 해 달라. 어느 것도 부당한 요구가 아닙니다. 다이어그램을 쓰는 사람이라면 당연히 기대하는 동작들입니다.
이미 만들어져 있고, 테스트되어 있고, 문서화되어 있는 것
GoJS가 파는 것은 결국 그 목록입니다. 직접 만들었다면 하나씩 겪었을 문제들이 이미 해결된 채로 들어 있습니다.
레이아웃은 여러 종류가 내장되어 있고, 직접 만든 배치를 붙일 수 있도록 샘플도 함께 제공됩니다. 외형은 데이터와 분리되어 있어서, 다이어그램 요소의 생김새를 정의해 두고 데이터만 갈아 끼우는 방식으로 씁니다. 데이터와 화면은 양방향으로 동기화되므로 한쪽을 바꾸면 다른 쪽이 따라옵니다.
되돌리기는 트랜잭션 단위로 동작합니다. 취소된 드래그와 편집까지 포함해 완전히 되돌아갑니다. 키보드 명령과 제스처는 흔히 쓰는 방식대로 이미 붙어 있고 필요하면 바꿀 수 있습니다.
그룹은 서브그래프로 동작합니다. 묶음 안쪽에만 다른 배치 규칙을 적용하는 것이 가능하다는 뜻입니다. 드래그·크기 조절·선 그리기 같은 내장 도구는 오버라이드하거나 상속해서 우리 앱의 조작 방식에 맞출 수 있고, 사용자가 특정 동작을 하거나 키를 눌렀을 때 자체 로직을 끼워 넣거나 아예 그 동작을 막을 수도 있습니다. 컨텍스트 메뉴와 툴팁은 기본 제공이며, 캔버스 안에서 그리거나 HTML로 확장합니다.
"조직도를 그린다"는 요구사항에는 위 항목이 하나도 적히지 않습니다. 당연하다고 여겨져서 적지 않는 것이고, 그래서 견적에도 들어가지 않습니다. 일정이 밀리는 지점이 대개 여기입니다.
조직도만의 이야기가 아니다
다이어그램이라고 하면 조직도를 먼저 떠올리지만, 실제로 이 기술이 값을 하는 곳은 더 넓습니다.
발전소와 공장에서는 설비 감시와 제어 화면으로 쓰입니다. 배관과 밸브, 탱크의 상태가 실시간으로 바뀌는 SCADA 화면이 여기에 해당합니다. 물류 창고에서는 동선과 적재 상태를, 통신에서는 망 구성과 장애 지점을 그립니다.
업무 시스템 쪽에서는 BPMN 업무 흐름도, 상태 전이도, 승인 프로세스가 대표적입니다. 보안 분야에서는 출입 통제 도면과 접근 권한 관계를 시각화하고, 인사 쪽에서는 조직도와 계보도를 그립니다. GoJS의 쓰임을 한마디로 정리하면 사용자가 직접 만지고 편집하는 그림이 필요한 모든 자리입니다.
의존성이 없다는 것의 의미
GoJS는 외부 의존성이 하나도 없는 자립형 라이브러리입니다. React, Vue, Angular, Svelte, Electron, 그리고 순수 자바스크립트 어디에나 그대로 넣습니다.
이 점이 실무에서 갖는 무게는 생각보다 큽니다. 의존성이 없다는 것은 프런트엔드 스택을 바꿔도 다이어그램 코드가 살아남는다는 뜻이고, npm 의존성 트리에서 취약점이 올라올 여지가 그만큼 적다는 뜻이기도 합니다. 서버 사이드에서도 돌아가기 때문에 비동기 배치 계산, 테스트, 이미지 생성 같은 작업을 백엔드에서 처리할 수 있습니다.
만든 사람들이 직접 지원한다
GoJS를 만든 Northwoods Software는 25년 넘게 다이어그램 라이브러리만 지원해 온 회사입니다. GoJS 자체도 2011년부터 이어져 왔고, 2026년 6월에 4.0이 나왔습니다.
지원 방식도 특이합니다. 평가판을 등록하면 GoJS를 실제로 만든 엔지니어가 직접 개념검증 범위를 잡아 주고, 템플릿 설계를 돕고, 통합 과정에서 막힌 지점을 풀어 줍니다. 티켓 창구에서 1차 상담원이 받는 구조가 아닙니다.
도입 기업으로는 Airbus, Johnson & Johnson, Siemens, Visa, Bosch, Hitachi, EY, Kinaxis 등이 공개되어 있습니다. 산업 계획, 보안, 조직 관리처럼 화면이 틀리면 곤란해지는 영역에 들어가 있다는 점이 눈여겨볼 대목입니다.
미래웹의 관점
- 국내에서 다이어그램 요구가 나오는 자리는 대체로 정해져 있습니다. 제조 MES·SCADA, 통신 망관리, 금융 업무흐름, 공공 조직도와 승인 프로세스입니다. 공교롭게도 전부 화면이 틀리면 곤란해지는 영역입니다.
- 이런 화면은 한 번 만들고 끝나지 않습니다. 설비가 늘고 조직이 바뀌고 프로세스가 개편될 때마다 손이 갑니다. 직접 만든 다이어그램 엔진은 그때마다 원저자를 찾게 됩니다.
- 오픈소스 다이어그램 라이브러리도 선택지입니다. 다만 그리기까지는 비슷해도 되돌리기·그룹·대용량 성능·상용 지원에서 갈립니다. 어느 쪽이 맞는지는 그 화면이 업무에 얼마나 깊이 들어가는가로 판단하시는 편이 낫습니다.
- 도면성 화면을 검토 중이시라면 개념검증부터 해 보시길 권합니다. 실제 데이터 규모로 한 화면만 그려 봐도 판단이 섭니다.
다시 처음으로 돌아가 보겠습니다. "조직도 화면 하나 넣어 주세요"라는 요구를 받았을 때 물어야 할 것은 박스를 몇 개 그리느냐가 아닙니다. 사용자가 그것을 편집할 것인가, 데이터가 실시간으로 바뀌는가, 그리고 몇 년을 쓸 화면인가입니다. 세 질문의 답이 모두 "그렇다"라면, 그것은 며칠짜리 일이 아닙니다.
GoJS 라이센스 구성과 개념검증(PoC) 진행은 국내 공급사인 미래웹으로 문의해 주십시오. 화면 성격과 데이터 규모를 알려 주시면 적합 여부부터 함께 판단해 드립니다.
이 글은 GoJS 공식 사이트에 공개된 제품 소개 내용을 바탕으로 미래웹 주식회사가 국내 독자를 위해 재구성한 것입니다. 「미래웹의 관점」 항목은 원 자료에 없는 미래웹의 해설입니다. 이미지는 GoJS 원본을 그대로 사용했으며 저작권은 Northwoods Software 에 있습니다.