자랑스럽게도 나는 문서를 예쁘게 작성하는 것을 좋아한다.
물론 예쁘게라는 기준은 내 눈에 한해면 충분한 거고 내 미적 감각이 뛰어나진 않기 때문에 그닥 예쁜 결과가 나오지는 않지만, 여러 교육 과정을 거치면서 작성해오라는 레포트나 보고서 등에서도 항상 제출 형식에 목매여서 작성하곤 했다.
특히 컴퓨터 공학을 전공할 동안에는 플로우차트와 같은 다이어그램을 항상 레포트에 첨부했어야 했는데, 이 때 가끔 플로우차트를 그리는 데에 구현하는 것보다 많은 시간을 쏟아붓는, 구현은 점심에 끝났는데 플로우 차트를 밤새서 작성하느라 다음날 새벽에 제출하게 되는 대참사가 일어나곤 했다.
이건 그 때 그렸던 플로우차트 중에 하나인데, 보기에는 엄청난 규모의 시스템이라도 구축한 것처럼 보이지만 그냥 장바구니 출력 C 프로그램 과제의 플로우차트였다.😅
다른 친구들도 이렇게 보고서 작성하는 데에 심혈을 기울이나 싶어서 물어봤더니, 아니나 다를까 나보다 항상 성적 잘 받는 친구들도 보면 다 이 정도로 작성하시더라. 음. 학점을 잘 받으려고 보고서를 예쁘게 그릴 필요는 없겠구나 생각했다. 근데 나는 시각자료를 넣으려고 해도 예쁘게 만들고 싶고, 문서화도 있어보이게 하고싶은데?
이런 부분에서 커다란 고민이 생겼다. 나는 분명히 예쁘게 문서를 작성해서 제출하는 걸 포기할 수 없는데, 그렇다고 문서화에 모든 시간을 다 쏟을 수는 없다. 특히 시각자료 만드는 데에 시간이 너무 오래 걸린다는 것을 알았다. 다이어그램을 공부해야겠다는 생각이 들었다. 특히 빠르고 예쁘게 다이어그램을 만들기 위해선 어떤 걸 공부해야 할까?하는 생각 말이다.
다이어그램이란?
다이어그램은 정보를 조율, 묘사, 상징화 하여 2차원 기하학 모델(two-dimensional geometric model)로 시각화하는 기술을 의미하며, 2차원 기하학 모델로 모델링된 그 대상도 일반적으로 다이어그램이라고 칭한다.
그 종류는 비규격화되어있는 것들을 생각해보자면 무수히 많을 것인데, 간단히 data visualization을 위해 사용되는 여러 차트들(바 차트, 파이 차트, 간트 차트 등등)이나 시스템 아키텍처를 위한 도식들, 또는 circuit을 표현하는 도식들도 넓게는 다이어그램에 모두 포함된다.
전공 수업에서 소프트웨어 공학이나, 정보처리기사 공부를 할 때면 항상 다이어그램에 대한, 논리의 시각화를 공부한 적이 있었다. 음. 그럼 그 때의 로드맵을 다시 쫓아서 공부해보면 되지 않을까?
슬프게도 우리는 공부할 게 많아도 너무 많은 한국의 프론트엔드 개발자이다. 프론트엔드 개발자가 일을 하는데에 있어서 다이어그램을 그릴 때 한 치의 논리적 오차도 없이 명확하게 범주화된 다이어그램을 그리는 것이 궁극적으로 생산성을 높히는 데에 큰 도움을 주지는 못할 것이라 생각한다.
그러니 우리 적당한 타협을 해보자. 다이어그램에 대해서 깊게 공부해 한 치의 오차도 없는 아름다운 논리적 구조를 가진 다이어그램을 그리는 것을 목표로 하는 것이 아니라, 프론트엔드 개발자로써 언제 어떻게 다이어그램을 활용할 수 있어야 할지. 그리고 나처럼 다이어그램 때문에 하룻밤을 새가면서 그리는 일이 없도록 어떻게 하면 빠르고 예쁘게 다이어그램을 그릴 수 있을지를 공부해보자.
1장: 프론트엔드 개발자에게 다이어그램이 필요한가?
우리 프론트엔드 개발자들은 다이어그램을 작성할 일이 많이 없다. 백엔드 개발자들의 경우에는 소프트웨어 아키텍처의 전반적인 흐름을 설계하거나 데이터베이스의 논리적 구조를 구축하기 위해서 다이어그램을 많이 활용하지만, 프론트엔드 개발자들은 그런 명세들의 집합을 통해서 산출물을 만들어내는데 이 산출물 자체가 뷰의 역할을 하기 때문에 다이어그램을 그릴 일이 딱히 없는 것으로 느껴진다.
하지만 프론트엔드 개발자들도 엄연히 소프트웨어 개발자이다. 따라서 아래와 같은 내용으로 나는 프론트엔드 개발자들도 다이어그램에 대해서 공부해야 한다고 생각한다.
1. 다이어그램은 설득의 수단이다.
소프트웨어 개발자들은 위와 같은 사이클을 통해서 소프트웨어를 개발하게 된다. 프론트엔드 개발자의 경우에는 위쪽의 유지보수, 요구분석, 시스템 명세 같은 작업에 있어서는 개발자가 아닌 분들과의 소통이 주를 이루고, 설계, 구현, 테스트, 배포와 같은 작업에 있어서는 다른 개발자들과 협업을 하는 것이 일반적이다.
그 과정에서 우리는 항상 주장과 설득을 통해 서로에게 전달되는 요구사항을 왜곡 없이 효율적으로 전달하는 방법을 고민해야 한다.
새로운 웹 배포 환경을 구축하는 데 있어서 설득이 필요한 자리에 자료를 만드는 작업을 하고 있다고 해보자. 그리고 이 자리에는 개발자들만 함께하는 것이 아니라 웹 배포 환경에 대한 전반적인 지식이 없는 인원들도 함께한다고 해보자.
웹 배포 환경에 대한 전반적인 지식이 없는 사람들도 이러한 자리에서 효과적으로 정보를 전달받기 위해서는, 당연히 앞쪽에 웹 배포 환경에 대한 부가적인 설명이 필요할 것이다. 이러한 정보 전달을 위해 GPT에게 "웹 배포 환경에서 사용자와 프론트엔드, 백엔드가 어떻게 소통하는지 그 과정을 설명해줘."라고 물어보았다.
굉장히 친절하고 자세하게 설명해준다. 이 내용으로 발표하면 될까? 발표 앞 부분에서 이 스크립트를 화면에 띄워놓고 한줄한줄 읽어가는 우리의 모습을 상상해보자. 고통스럽지 않은가? 발표를 들으면서 저 빼곡한 글이 적힌 화면을 읽어가는 사람들은 더 고통스러울 것이다. 그래서 우리는 이 글이 담고 있는 핵심 내용인 사용자에게 서비스가 배포되는 과정을 시퀀스 다이어그램으로 그려보았다.
훨씬 보기 좋다. 보는 사람의 입장에서 시각적인 요소들로 하여금 관계를 예측할 수 있는 모델이 되었다. 글에는 그러한 요소들이 없다. 단순히 배경과 구분되는 글자들이 의미를 가지는 최소 단위를 구성하고, 그 의미들의 조합을 해석하여 우리는 단어들의 관계를 추론하여야 한다. 이것은 다이어그램만이 아닌, 모든 시각자료들과 글이 가지고 있는 큰 차이일 것이다. 이러한 시각적 정보가 가독성에 영향을 준다는 재미있는 글을 읽은 적이 있다.
⛓️ 게슈탈트 법칙으로 이해하는 클린코드: 가독성의 비밀
모든 글에는 중요한 부분과 중요하지 않은 부분이 나뉘어져 있는데, 글로 되어 있는 자료는 읽는 사람이 이것을 분류하는 작업을 하면서 읽어나가게 된다. 또한 발표 등에서 활용되는 시각자료는 항상 이 중요한 부분을 관통하고 있어야 한다. 그러니 우리는 설득의 도구로써 항상 글이 아닌 시각자료를 활용해야 하며, 소프트웨어 개발에 있어서 가장 활용도 높은 시각자료인 다이어그램을 활용해야 할 것이다.
2. 다이어그램은 설계도이다.
앞서 살펴봤던 소프트웨어 라이프 사이클에서 우리는 설계와 구현이 반복됨을 알 수 있다. 모든 공학 산출물이 구현되기 위해서는 설계가 필요하며, 설계를 구체화하기 위해서는 항상 설계도가 필요하다. 하다못해 천재 발명가가 혼자 차고에서 뚝딱뚝딱 만든 발명품이라 할지라도, 그 발명가의 머릿속에는 그 설계도가 어떠한 형태로든 남아있을 것이다.
또한 추상화 수준이 어떻든 설계도라 할 수 있는 것들은 같은 구현물을 함께 구현하려는 사람들에게 공유되어야 한다. 우리는 협업을 하기 때문에 설계도를 만들어야 한다는 것이다.
설계도가 어떤 형태를 띄어야 하는가는 그 조직에서 결정해야할 사항이다. 하지만 DDD(Diagram Driven Design)라는 다이어그램을 기반으로 소프트웨어 아키텍처를 설계해나가는 방식이 논의된 적이 있고, 이런 관점들에 의해서 UML과 같은 규격들이 논의되었을 정도로, 다이어그램은 재사용성과 의사소통 비용의 측면 등에서 꽤 강점을 가진다.
백엔드 개발에서는 ORM이 ERD cloud의 렌더링 코드를 불러와 자동으로 schema구조를 생성하는 쿼리로 변환해주고, 이를 통해 ERD에서 실제 RDB에 테이블을 생성하는 것까지 도와주는 기능도 제공한다고 한다. 이런 기능들이 없다고 하더라도 database를 구성하기 전에 ERD를 그리고 이를 토대로 triggering과 참조관계의 설정, 각 entity들의 특성을 설정하는 등의 작업을 하는 조직들도 다수 있는 것으로 보인다.
그렇다면 프론트엔드는 안 그럴 이유가 있을까? 특히 플로우 기반의 구현을 하는 프론트엔드 조직의 경우에는 충분히 테스트 코드만큼의 구체화를 하기 이전에 플로우 차트를 통해 명세를 할만하다고 생각된다. 나아가서 기획자와 디자이너, 백엔드 모두 함께 이 플로우차트를 기반으로 구체화하는 프로세스를 가지는 것도 충분히 가능한 모양이다.
조직 자체에서 다이어그램을 주요 소통 수단으로 가져가지 않더라도, 도메인 지식이 필요한 경우의 구현물에 대해서 개발자가 그 영역을 이해했는지 전문가들에게 확인받기 위해서 다이어그램이 활용되는 것도 아주 좋은 활용 방안이 될 수 있다.
2장: 모든 의사소통은 약속에 의해 이루어져야 한다.
❓ 그렇다면 최대한 전달하려는 모든 정보를 다이어그램으로 그려야할까? 당연히 아니다.
모든 정보들을 시각화하기 위해서 너무 세세한 부분까지 다이어그램화하는 것은 오히려 독이 될 수 있다.
예를 들어, 시퀀스 다이어그램이나 플로우차트처럼 이미 많이 사용되고 있는 다이어그램 형식을 따르지도 않고, 선택한 도식화 체계가 정보를 공유하는 조직 내에서 약속되지 않은 경우들에는 오히려 그 다이어그램을 해석하기 위해 그 규격을 공부해야 하는 역설적인 상황에 빠질 수 있다. 의사소통을 위해 사용되는 수단이니 만큼 그 언어적 특성은 무시하지 못할 것이다.
다행히 앞선 시대에서 선구적인 개발자 분들께서 이러한 의사소통 비용을 최소화하면서 다이어그램의 활용도를 높히기 위해 논리에 대한 모델링 체계를 정정의하고 규격화하려는 노력을 해주셨고, 그 결과물로 가장 유명한 것이 UML(Unified Modeling Language)이다.
UML(Unified Modeling Language)
UML은 소프트웨어 시스템의 구조와 설계를 시각화하기 위한 모델링 언어이다. UML과 같은 규격화된 모델링 언어로 작성된 다이어그램은 설계 과정에서 명확한 소통을 가능하게 하며, 소프트웨어 설계의 정확성을 높이고 유지보수성을 향상시키는 데 도움을 준다. 이 글에서는 UML의 모든 측면을 깊이 있게 다루지는 못하겠지만(저도 잘 모릅니다...), UML이 어떤 체계로 구성되어 있으며 다양한 다이어그램의 논리적 시각화를 어떻게 규격화하는지 간단히 살펴보도록 하자.
UML 1.0은 1997년 1월에 발표되어 OOSE(Object-Oriented Software Engineering) 등 여러 객체 지향 방법론을 통합하여 발표되었다. 이후 여러 번의 수정을 거쳐 2005년 8월에 UML 2.0이 발표되었으며, UML의 메타모델을 개선함으로써 확장성과 유연성을 높히는 방향으로 변화되었다.
2015년 6월 발표된 UML 2.5에서는 다이어그램을 크게 구조 다이어그램과 행동 다이어그램으로 나눈다.
⛓️ UML 2.5 Diagrams Overview
구조 다이어그램은 시스템의 정적인 측면을 나타내는 데 중점을 둔다. 특히 다양한 시스템의 구성 요소들과 그 구성 요소들끼리의 관계를 다루는 데 특화된 모델이라고 볼 수 있다.
반대로 행동 다이어그램은 시스템의 동적인 측면을 나타내는 데 중점을 둔다. 즉 시스템 내부의 객체들이 시간에 따라 어떻게 상호작용하고 변하는지를 표현함으로써 시스템의 동작과 기능적 요구사항을 이해하고 분석하는 데에 특화된 모델이라고 볼 수 있다.
일단 UML에서는 이처럼 특정 시스템에 대해서 이 시스템이 어떻게 생겼는지, 그리고 이 시스템이 어떻게 가동되는지 두 가지에 대하여 논리적으로 표현 가능한 모델을 구성한 것으로 보인다. 이렇게 오버뷰만 살짝 살펴보아도 우리는 논리적으로 어떤 시스템을 도식화하기 위해서 구조와 동작의 두 가지 측면에서 분석해야한다는 것을 알 수 있다.
이런 부분들을 적용하여, 우리 프론트엔드 개발자들의 업무인 웹 프로덕트 아키텍처의 설계와 구현을 위한 의사소통에 필요한 다이어그램을 정리해볼 수 있을 것이다.
내가 생각하는 프론트엔드 다이어그램 3신기
그럼 프론트엔드 개발자가 집중해야 하는 구조와 동작에는 어떤 것들이 있을까? 내가 생각하는, 프론트엔드 개발자가 익혀두면 좋은 세 가지 다이어그램을 이야기해보고자 한다.
1. ERD(Entity Relationship Diagram)
나는 프론트엔드가 중요하게 여겨야하는 구조는 크게 두 가지라고 생각한다. 원본 데이터의 구조와 뷰 컴포넌트의 구조이다. 프론트엔드는 궁극적으로 서버에서 제공해주는 도메인 데이터를 가공하여 유저에게 제공하는 역할을 하는 뷰를 생산한다. 서버와 유저의 거대한 어댑터인 셈이다. 따라서 우리가 가장 많은 관심을 갖는 구조는 서버 방향의 끝쪽 데이터 구조와 유저 방향의 끝쪽 데이터 구조 이다.
서버 방향의 끝쪽 데이터 구조는 DB에서 만들어지며, 유저 방향의 끝쪽 데이터 구조는 디자인에서 만들어진다. 우리는 따라서 DB를 읽을 줄 알아야 하고, 디자인을 읽을 줄 알아야 한다. 이것은 스키마의 구조나 디자인의 심미성에 대해서 평가하라는 말이 아니다. 그냥 적어도 읽을 줄 알아야 한다는 것이다. 그래서 우리는 백엔드 개발자와 소통하기 위해 ERD를 읽을 줄 알아야 하며, 디자이너와 소통하기 위해 디자인을 읽을 줄 알아야 한다. 따라서 내가 생각하는 프론트엔드에게 필요한 다이어그램 첫 번째는 ERD이다.
2. FlowChart
나는 프론트엔드에게 필요한 다이어그램의 두 번째로 FlowChart를 이야기하고 싶다.
FlowChart는 사용자의 행동이나 이벤트 흐름을 시각적으로 표현할 수 있는 도구이다. 프론트엔드 개발자는 사용자 인터페이스에서 발생하는 다양한 상호작용과 이벤트의 흐름을 설계하고 이해해야 한다. 또한 이것을 협업자들에게 공유할 수 있어야 한다. FlowChart를 사용하면 특정 작업이 어떻게 진행되고 어떤 조건에서 어떤 경로로 이동하는지를 쉽게 시각화할 수 있다. 심지어 구성 요소들이 굉장히 단순하기 때문에 거의 대부분의 구성원들이 직관적으로 그 의미를 해석할 수 있다.
이러한 FlowChart의 특성은 다이어그램 등 시각자료에 대한 약속이 따로 되어있지 않은 조직에서도 FlowChart를 활용가능하게 만들어준다. 특히 그러한 약속이 만들어지기 쉽지 않은 개발자와 디자이너간 혹은 개발자와 기획자간의 소통에 큰 무기가 될 수 있다. 이를테면 우리가 이해한 사용자 관점에서의 서비스 흐름이 그들이 요청한 것이 맞는지 확인하거나, 우리가 수정을 요청하려는 사용자 흐름이 그들에게 잘 이해되도록 만들기 위해서 채택할 수 있는 좋은 도구인 것이다.
또한 사용자의 입력 정보에 따른 분기 처리 등을 표현하기가 매우 쉽기 때문에 유저 플로우를 기반으로 프로덕트를 설계 및 구현하는 경우엔 FlowChart를 통해 논리적 흐름을 미리 확인하고 잠재적인 오류를 사전에 방지할 수도 있다. 설계도의 역할을 하기에 충분하다는 의미이다.
3. Sequence Diagram
세 번째는 Sequence Diagram이다. 앞서 이야기했던 것처럼 프론트엔드 개발은 사실상 거대한 어댑터의 개발이다. 또한 웹 프로덕트의 한 축을 담당하고 있는 거대한 레이어로 볼 수도 있다. 우리는 프론트엔드 산출물인 View를 통해 데이터에 대한 요청이 어떤 식으로 발생하고 어떤 과정을 통해 처리되어 유저에게 응답을 돌려주는지에 관심을 가져야 한다. FlowChart가 유저 관점에서 서비스의 흐름을 시각화하기에 강점이 있다면, 시스템 구조를 중시하는 관점에서 서비스 흐름을 시각화하기에는 Sequence Diagram이 적절하다.
3장: 다이어그램, 어떻게 작성하시나요?
내가 다이어그램을 소중하게 생각하는 이유부터 프론트엔드 개발자로써 필요하다고 생각되는 다이어그램 종류 등을 살펴보았다. 내 생각에 동감해주어서 다이어그램이 중요하다는 것을 인정해주셨다면, 언젠가는 다이어그램을 작성할 일이 있을 것이다. 근데 다이어그램 등의 시각자료를 그리는 건 여간 귀찮은 일이 아니다. 그리고 업무 시간에 다이어그램을 작성하고 시각자료를 짜느라고 다른 일을 못하게 되는 건 말 그대로 주객전도일 것이다.
따라서 우리는 어떻게하면 다이어그램을 최대한 빠르고 예쁘게 작성할 수 있는지 고민해보아야할 것이다.
나는 그래도 그런 고민들을 앞서 해보았다. 그래서 이번에는 내가 지금까지 어떤 방식으로 다이어그램을 작성해왔는지, 그 진화 과정을 한 번 공유해보고자 한다.
1. 종이와 펜으로 작성하기
역시 그림은 손으로 그려야 제 맛이다. 나도 맨 처음에 다이어그램을 그리는 등 도식화를 하는 건 당연히 종이와 펜이 처음이었다. 그도 그럴 것이 엄밀히 다이어그램이라는 이름을 가진 그림을 처음 그린 건 중학생 때 . 벤 다이어그램이었을 테니까...
아날로그는 강력하다. 별다른 제약사항 없이 머릿 속에 있던 내용들을 바로바로 꺼내서 정리할 수 있고, 남들에게 전달하기에도 작성 시간이 오래 걸리지 않기 때문에 디지털 신봉자들이 생각하는 것보다 효율적으로 의사소통이 가능하다.
하지만 우리는 이걸 여러 군데에 공유해야 한다. 그렇다고 연필로 그린 다이어그램을 핸드폰 스캐너로 찍어서 보고서에 첨부할 수는 없는 노릇이다. 심지어 예쁘게 그리기 위해서는 초안 스케치를 하고. 자를 대고 간격을 하나하나 계산하면서 그려야 할 것이다.
2. 이미지 편집 툴로 작성하기
다음으로 알게 된 방법은 다이어그램 이미지를 생성하는 툴을 활용하는 것이었다. 다이어그램은 각 종류마다 약속되어 있는 도식화 체계가 있기 때문에 사실 어떤 편집 툴로든 그려낼 수 있다. 그럼에도 특정 툴이 각광받는 이유는 간격 자동 계산 등으로 오토 레이아웃을 제공하거나, 다이어그램에서 주로 사용되는 도형 삽입 기능 등을 제공하기 때문일 것이다.
drawio
다이어그램을 그리는 데 가장 잘 알려져 있는 이미지 편집 툴은 단연 drawio일 것이다.
drawio는 웹 기반의 다이어그램 작성 도구이다. 따라서 특정 소프트웨어를 활용하지 않아도 충분히 편집이 가능하다. vsc extension으로 임베드하여 실시간으로 파일을 편집할 수도 있고, .drawio라는 확장자를 통해서 편집 가능한 원본 파일을 유지할 수도 있다.
처음에 이를 활용하면서 매우 편리하다고 느낀 점은, 다이어그램에서 주로 사용되는 도형들을 편리하게 삽입할 수 있는 툴바를 제공하며, 드래그 앤 드롭으로 요소를 쉽게 배치할 수 있다는 점과 그리드 시스템이 적용되어 레이아웃을 구성하기가 쉽다는 점들이었다.
Presentation
몇몇 분들은 프레젠테이션 툴로 다이어그램을 그리시기도 한다. 구글 슬라이드나 PowerPoint 등을 활용해서 말이다. 프레젠테이션 툴은 마진 등을 자동으로 계산해주고, 정렬을 쉽게 만들어 주는 등의 오토 레이아웃이 굉장히 편리하게 작동한다. 이러한 점들은 다이어그램 등 시각자료를 그리는 데 매우 유리하기 때문에 충분히 다이어그램 작성 도구로 활용될 수 있을 것으로 보인다.
3. 코드로 다이어그램 작성하기
시각 자료는 코드로도 충분히 그려낼 수 있다. 코드로 다이어그램을 작성하면 버전 관리와 협업에 매우 유리하다. 특히 여러 사람이 함께 작업하는 프로젝트에서는 일관성을 유지하기 쉽고, 코드 변경에 따른 업데이트도 자동화할 수 있다. 이 방법은 개발자들에게 특히 매력적이다.
이미지 편집 툴을 사용하는 방식은 종이와 펜에 비해 편리하지만, 여전히 마우스로 일일이 요소를 배치하고 조정해야하는 번거로움이 있다. 코드로 다이어그램을 작성하면 요소의 배치나 조정을 자동으로 해주기 때문에 자유도가 낮아지기는 하지만, 이러한 작업을 전부 자동으로 해주기 때문에 훨씬 더 편리하게 다이어그램을 작성하는 것이 가능해진다.
Mermaid
Mermaid는 간단한 텍스트 문법을 사용하여 다이어그램을 생성할 수 있는 도구이다. 문법이 비교적 간단하기 때문에 플로우차트, 시퀀스 다이어그램 등을 쉽게 그릴 수 있다. 위의 사진은 웹 프론트엔드 정적 배포 관련한 실습 프로젝트의 배포 형식을 다이어그램으로 그린 것인데, 좌측의 코드가 우측의 다이어그램으로 변환되는 것을 확인할 수 있다.
Mermaid는 Markdown 파일 안에서 다이어그램을 직접 작성할 수 있기 때문에, 개발자들이 문서화 작업을 할 때 굉장히 유용하다. 특히 노션에서는 mermaid 컴포넌트 자체를 임베드할 수도 있고, md로 작성된 머메이드 코드는 github에서도 다이어그램으로 전환된 뷰를 제공받을 수 있다.
PlantUML
PlantUML은 UML 다이어그램을 텍스트로 작성할 수 있게 해주는 도구이다. 다양한 UML 다이어그램을 코드로 정의할 수 있으며, 복잡한 구조도 간단하게 표현할 수 있다. PlantUML은 특히 시스템 설계나 소프트웨어 아키텍처를 문서화할 때 매우 유용하다.
Kroki
코드를 다이어그램으로 변환해주는 도구들은 코드를 사용할 수 없는 곳에는 다이어그램을 그릴 수 없다는 단점이 있다. 도구를 통해 생성한 다이어그램을 캡쳐해서 계속 들고 다닐 수도 없는 노릇인데, Kroki는 이러한 코드로 생성한 다이어그램을 호스팅해주는 서비스를 제공한다.
위의 사진을 보면, 좌측의 PlatUML 문법의 코드로 그려진 우측의 다이어그램을, 하단의 https URL로 호스팅하여 제공해주는 것을 볼 수 있다. svg형식으로 제공되기 때문에 이를 활용한다면 다른 웹에서 이미지화된 다이어그램을 쉽게 공유할 수 있게 된다.
Kroki는 위와 같이 여러 다이어그램 도구를 통합한 API 서비스로, Mermaid, PlantUML, Graphviz 등을 포함한 거의 대부분의 코드 다이어그램 툴을 지원한다. 본인이 익숙한 다이어그램 코드 문법을 활용하여 kroki에 작성한 뒤, 이를 공유하는 방식으로 활용할 수 있을 것이다.
4. AI로 생성한 코드로 다이어그램 작성하기
코드로 다이어그램을 그리는 데에도 단점은 존재한다.
코드 등의 글로 다이어그램을 작성하기 위해서는 묘사하려는 대상에 대해 특정 수준 이상의 구체화 수준이 요구된다. 즉, 머리를 짜내서 코드를 작성해야 한다는 것이다. 그리고 각 코드 다이어그램 문법들에 대한 학습도 아예 무시할 수는 없을 것이다.
특정 대상을 가지고 다이어그램을 그리는 과정을 코드로 한다고 하면, 대상 -> 코드 -> 다이어그램의 프로세스를 이야기할 수 있다. 그런데 코드 -> 다이어그램은 다이어그램 툴들이 자동화를 해주는데 대상 -> 코드는 머리를 쥐어짜내서 진행해야한다는 것이다.
근데 최근 우리에게 자연어를 코드로 전환해주는 강력한 도구가 생겼다. 바로 AI이다.
AI > 코드 > 다이어그램 프로세스로 다이어그램 이미지 만들기
백문이 불여일견. 어떻게 표현하고 싶은 개념을 다이어그램으로 만드는지, 그 파이프라인을 함께해보자.
대상 -> 코드의 과정을GPT -> PlantUML로 연습해보자.
아까 GPT가 뱉어줬던, 웹 배포 환경에 대한 설명이다. 그대로 복사해서 GPT에게 PlantUML 문법의 Sequence Diagram으로 변환해달라고 해보자. ⛓️ 역시 생각보다 빠르게 잘 만들어준다.
자, 이제 아까 찾아봤던 코드 -> 다이어그램 API인 ⛓️ Kroki!에 그대로 복붙해본다.
GPT가 작성해준 코드가 꽤 괜찮게 다이어그램으로 변환되는 것을 확인할 수 있다. 물론 원하는 복잡도의 코드가 한 번에 생성되기는 힘들 수 있다. 그러나 우리는 개발자이기 때문에 코드 플레이트를 대강 보면 그 구조를 파악해서 조금의 첨삭을 하는 것에 크게 어려움이 없다. 다이어그램 코드 초기 플레이트 작성을 위해 공식 문서를 꼼꼼히 뒤져보고 데모를 찾아서 따라 치지 않아도 된다는 점은, 충분히 매력적인 요소로 작동할 수 있다고 본다.
Kroki에서 호스팅하는 이미지파일은 위와 같이 웹에 임베드하여 출력해줄 수 있다.
마치며
이제 여러분도 다이어그램 작성에 있어 다양한 방법을 시도해 보길 바란다. 종이와 펜에서부터 AI 기반의 자동화된 코드 생성까지, 각 방법은 각각의 장단점이 있으니, 상황에 맞게 선택하여 사용해보자.
발표 배경
최근 프론트엔드 개발자들을 대상으로 하는 교육 과정인 항해 플러스 코스에 참여하고 있다. 10주 간의 교육 과정 내에서 이제 마지막 주간에 돌입했는데, 저번 주 오프라인 모임에서 토요 지식회 발표를 하게 되었다.
토요 지식회 발표는 같은 수강생분들을 대상으로 10-20분 정도의 발표를 진행한 뒤에, 발표자가 던져준 주제로 조를 나눠 토론해보는 형태이다.
코스 초기부터 발표지원자를 받아서 진행하였는데, 왠지 모르게 저런 발표까지도 하게 된다면 그게 본전 뽑는 것 아니겠는가?하는 생각이 들기 시작했고, 몇 주 전부터 발표 주제를 뭘로 할까 혼자 고민하고 생각난 주제들을 어떻냐고 주변에 물어보기 시작했다.
주제로 선정하려고 했던 후보들은 꽤 많았다. 발표 자체에 대해서 어딘가에 남길 곳이 이 글 밖에 없게 될테니, 그 후보가 되었던 주제들을 적어보자면 아래와 같다.
- 하드스킬 관련
- JavaScript의 가비지 콜렉션(메모리 할당이랑 해제 같은 이야기 다른 언어랑 비교해서)
- git rebase -i와 git cherry-pick으로 커밋 수정하기
- React의 역사(버전 히스토리 보면서 같이 훑어보기)
- 소프트스킬 관련
- 스타트업 업무 효율 극대화를 위한 노션 템플릿 구축기
- 다이어그램과 같은 시각자료를 최대한 활용해보자는 이야기
- 그 외
- 나는 왜 프론트엔드 개발자가 되었을까~하는 살아온 이야기
- 9주간 항해 플러스 진행하면서 배운 점과 느낀 점. 회고
각 주제들에 대해서 어떨까 열심히 고민해보았다. 여러 이유들 때문에 소프트 스킬 관련된 이야기를 하는 것이 내 발표 스킬과 잘 어울릴 것이라고 생각하게 되었고, 문서화를 좋아하던 내 성격에서 이야기를 풀어나가면 괜찮을 것 같다는 생각과 mermaid와 같이 평소에 사용하던 툴들을 공유하는 게 꽤 의미가 있을 것 같아서 다이어그램을 주제로 선정하게 되었다.
항해플러스 프론트엔드 3기 모집 중
🌊 항해플러스 프론트엔드 코스에서 3기 수강생들을 모집하고 있다고 한다.
8월 22일 이전에 지원하면 얼리버드 혜택으로 꽤 수강료를 할인해주고 있고, 추천코드 HHPGS0589입력 시에 20만원 할인 혜택을 받을 수 있다고 한다.
