개인적으로 복잡한 다이어그램의 등장을 좋지 않은 신호로 여깁니다. 설명하는데 다이어그램이 필요하다면 그 다이어그램은 최대한 단순한 모양이어야 합니다. 다이어그램이 복잡해진다면 그리는 사람이 다이어그램을 다이어그램/을 통해 설명하려는 주제를 잘 이해하지 못했거나 못할 수 있습니다. 또 설명 받는 사람에게 주제를 충분히 잘 이해 시키기 어려워진다는 의미입니다의미이기도 합니다.
항상 다이어그램을 웬만하면 피하고 굳이 그려야 한다면 가장 간단한 모양을 유지하려고 노력했습니다. 다이어그램이 복잡해진다면 한번에 너무 많은 주체가 다이어그램에 출연하고 있거나 서로 다른 레벨의 주제를 같은 다이어그램으로 설명하려고 하고 있을 수 있습니다. 그래서 설명할 주제를 나누고 다른 수준에 침범하지 않도록 주의하곤 합니다.
...
과거에 다이어그램을 그릴 때는 주로 비지오를 사용해 왔습니다. 비지오를 사용할 때 유일한 단점은 종종 파워포인트가 있는데 왜 훨씬 비싼 도구를 구입해야 하는지 설명을 요구하던 구매 담당자가 존재한다는 사실 뿐이었습니다. 다행히 시간이 흐르며 더이상 비지오를 왜 따로 써야 하는지 설명할 일은 크게 줄어들었습니다. 물론 비슷한 도구들이 제법 발달한 현대에는 이전만큼 비지오를 사용해야만 하는 일 역시 줄어들었고요. 하지만 여전히 비지오에서 드로잉을 만들 때 느껴지는 특유의 안정감은 요즘 유행하는 어지간한 웹 기반 도구들이 흉내 내지 못합니다. 그럼에도 다른 드로잉 도구가 컨플루언스나 노션 같은 도구에 더 잘 통합되었고 어지간한 다이어그램은 웹 기반 도구로도 큰 무리 없이 만들 수 있었기 때문에 한동안 비지오를 구입해달라고 요청하지 않았습니다않고서도 다이어그램을 만드는데 문제가 없었습니다.
한동안은 draw.io를 사용했습니다. 컨플루언스와 노션 양쪽에 잘 통합될 뿐 아니라 대부분의 상황에 무료이면서도 웬만한 드로잉을 그리는데 지장이 없었습니다. 특히 처음에 이야기한 대로 다이어그램을 최대한 작게 유지하려고 노력한다면 보안 상 다이어그램을 반드시 오프라인에서 그려야 하는 상황이 아니라면 굉장히 좋은 선택입니다. 플로우차트 이외에도 여러 템플릿을 통해 어지간한 드로잉은 대부분 만들 수 있었습니다.
또 한동안은 도구 광신도에 의해 피그마를 사용해야만 했는데 다이어그램을 그려야 하는 입장에서 피그잼은 솔직히 쓰레기 같았습니다쓰레기입니다. 다이어그램을 본격적으로 그릴 일이 별로 없는 사람들이 도구를 만들면 이 꼴이 날 수도 있겠다는 생각을 하게 해 주었습니다. 단점은 수없이 많지만 다이어그램 그리는 도구인 주제에 링크 커스터마이징을 거의 할 수 없고 노드에 커넥터를 추가 정의할 수도 없으며 링크 정리 기능이 기능도 없었습니다. 어쩔 수 없이 한동안 사용했지만 얼마 동안 사용했지만 높지는 않은 가격에도 불구하고 앞으로 진지하게 다이어그램을 그리는데 사용할 수는 없겠다는 결론을 내리게 되었습니다.
한편 이번에 크고 복잡한 관계를 다이어그램으로 그릴 일이 생겼습니다. 어떤 도구를 사용해야 할지 고민하면서 잠깐 동안 피그잼을 사용해 대강 견적을 낸 다음 꺼버렸습니다. 이 작업은 다른 도구가 필요했고 도구를 선택해야 했습니다. draw.io는 괜찮은 도구이지만 여기서는 컨플루언스나 노션에 통합이 중요한 조건은 아니었습니다. 바로 비지오로 넘어갈까 했지만 다이어그램이 복잡해지면 관리하기 어려운 것 같았습니다. 초반 작업에서는 그럴싸한 그림보다는 실제 노드 간의 관계를 정의하는 것이 더 중요했습니다. 그렇게 괜히 마스토돈에서 피그잼을 욕하다가 머메이드를 추천 받게 되었습니다.
...
이 규칙을 기반으로 다이어그램에 들어갈 모든 구성요소를 정의하고 서브그래프로 이들의 포함 관계를 정의해 모든 구성요소가 빠짐 없이 들어갔는지, 또한 이들의 위계가 잘 정의 되었는지를 문자와 그림으로 동시에 점검할 수 있었습니다. 또한 이들 사이에 연결을 정의하기 시작하면서 이전에 경험한 적 없는 정신이 전혀 없지 않은 상태를 유지할 수 있었습니다. 이전에는 구성요소 사이에 화살표가 붙기 시작하면 순식간에 정신 없는 상태가 되곤 했습니다. 마치 선 정리가 안 되어 모든 기계에 랜선이 주렁주렁 늘어진 지옥 같은 데이터센터를 보는 느낌이었습니다. 뭔가 복잡하지만 관계를 설명할 수도 없었고 그림을 보고 이 그림에 오류가 있는지를 파악하기도 어려웠음어려웠습니다. 솔직히 거의 불가능했습니다.
하지만 머메이드 문법으로 정의한 다이어그램은 구성요소와 이들 사이 관계를 텍스트로 읽을 수 있을 뿐 아니라 다이어그램 사이 연결 관계의 의도를 주석을 통해 기입해 둘 수도 있어 다이어그램이 복잡해져도 이 다이어그램이 오류 없이 그려졌는지 충분히 파악할 수 있었습니다. 다이어그램으로 표현하려고 하는 시나리오를 충분히 숙지한 상태에서 텍스트로 정의된 다이어그램을 따라가며 모든 시나리오를 표현하고 있는지 점검할 수 있었습니다. 이전에 복잡한 다이어그램을 그리면서 한 번도 해본 적 없는 경험이었고 이 경험을 통해 다이어그램을 설명할 때 이전에 비해 훨씬 큰 자신감을 가질 수 있었습니다.
머메이드는 단순하고 강력해 앞으로 어지간한 다이어그램을 그릴 때 맨 먼처 먼저 찾을 도구임에 확실합니다. 하지만 장점만 있는 것은 아닙니다. 해결되지 않았고 또 언제 해결될지 알 수 없는 고약한 문제도 있고 또 개인적으로는 설계 결함이라고 생각하는 문제도 있어 다이어그램을 편안하게 그리기 어렵게 만듭니다.
서브그래프를 여러 겹 겹치기 시작하면 디렉션이 오동작합니다. 상하 방향과 좌우 방향이 서로 반대로 동작하기도 하고 방향 정의 자체가 동작하지 않기도 해서 서브그래프를 포함한 상황에서는 디렉션을 사용할 생각을 접어야 합니다. 또 복잡한 연결 관계에서 링크들이 최대한 서로 겹치지 않도록 알아서 조정해 주지만 복잡도가 일정 수준을 넘어서면 제대로 동작하지 않거나 구성요소를 침범해 글자를 알아볼 수 없게 만드는데 이건 해결할 방법이 없다는 점에서 치명입니다치명적입니다.
또 다이어그램 노드에는 이름을 정의하고 이 이름을 기반으로 스타일을 적용할 수 있는 반면 링크에는 이름을 정의할 수가 없어 스타일을 적용하려면 전체 다이어그램에 사용된 노드의 순서를 사용해야 합니다. 다이어그램에 링크가 50개쯤 있고 스타일을 적용한 상태에서 중간에 있는 노드를 수정하면 노드 순서가 틀어지면서 전체 스타일이 어긋나는데 이를 다시 바로잡기에 대단히 불편합니다. 노드에 이름을 부여하도록 설계했을 사람들이라면 링크에도 당연히 이름을 정의하고 이름에 의해 스타일을 정의할 수 있도록 설계하는 것 역시 당연하다고 생각하는데 이렇게 설계한 이유를 납득하기 어려웠습니다. 한편으로는 노드에 스타일을 적용하는 것은 당연하지만 링크에 스타일을 적용하는 것은 지원하긴 하지만 별로 사용하지 않았으면 하는 의도일 수도 있겠다는 생각도 듭니다. 마치 노션이 빈약한 테이블만 지원하는 이유와 비슷한 것일 수도 있습니다.
...
또 수정하는 부분에 따라 작은 수정인데도 프리뷰가 크게 바뀔 때가 있는데 만약 리얼타임으로 피드백을 받으며 바로바로 수정하는 상황일 때 코드 상으로는 순식간에 수정하고 이야기를 이어 나갈 수 있지만 이로 인해 프리뷰가 크게 바뀌면 방금 전까지 설명하던 노드를 전체 그림에서 다시 찾아야 해서 상당히 불편했습니다. 실은 이런 단점들은 머메이드 자체의 문제라기보다는 문제라기 보다는 에디터의 문제이지만 앞으로 개선될 여지는 아주 많아 보입니다. 다만 이런 개선들이 언제 이루어질지는 전혀 알 수 없습니다.
존재는 알고 있었지만 시도하지 않았던 도구를 시도해보고 그 장점과 앞으로 활용 가능성을 인식한 훌륭한 기회였습니다. 앞으로도 웬만한 다이어그램은 처음부터 머메이드를 통해 그릴 작정입니다. 이번 작업은 생각보다 훨씬 복잡해져 부득이하게 그럴싸한 그림을 만드는 후반 작업은 비지오에서 할 작정이긴 합니다. 하지만 비지오로 옮겨 오기 전에 모든 노드의 포함 관계와 이들 사이의 연결을 시나리오에 맞춰 완전히 검증할 수 있어 비지오로 넘어온 다음에는 그럴싸한 그림을 만드는데만 만드는 데만 집중할 작정입니다. 이런 작업 프로세스를 만들 수 있다는 점 만으로 머메이드에 굉장히 만족합니다.