회고를 하면 보통 개인적인 이야기를 많이 하기 때문에 잘 안하려고 하다가 기술회고라는걸 해본다.
이건 한해동안 했던 일들에 대한 이야기 이다.
난 기본적으로 Front-End 개발자로 살고 있다.
조금 다른게 있다면 분야를 가리지 않고 살고 있는 것 같다.
올해에 한 일만 해도 기준이 없다.
보통 일을 이렇게 하면 정체성이 의심 될 수도 있지만 난 그렇지 않다.
왜냐하면 항상 이렇게 해왔기 때문이다.
다만 이렇게 하는 것들이 일의 기준이 없고, 경험치가 쌓이는 느낌이 전혀 아니기 때문에 내 주변 사람들은 힘들어한다. 그래서 주변에 미안하지만.... (이 일을 내가 준게 아니니)
참고로 난 경력 16년 동안
BE, FE 가리지 않고 다 했는데
지금은 FE 를 열심히 더 배우고 있다.
너무 배울게 많아서 코딩을 놓지 못하고 있다.
내가 하는 일 중에는 오픈소스와 회사일이 섞여 있다.
자, 본격적으로 하나씩 까보자.
Yorkie 는 여기서 https://yorkie.dev/
Yorkie 는 CRDT 라는 동시편집 기술을 개발하고 있는 서비스라고 볼 수 있다.
왜냐하면 CRDT 자료형만 만드는게 아니라 서비스 할 수 있는 서버까지 같이 만들고 있어서 그렇다.
동시편집이라는 자료형을 만드는건 생소 할 수 있는데 다행이 내 옆에 그 것을 하는 동료가 있다.
그래서 항상 감사한 마음을 가지고 있다.
내가 조금이라도 기여할 수 있는 부분이 있어서 ...
Yorkie 는 몇년 전부터 알고 있었지만 본격적으로 올해에 잠깐 참여했다.
잠깐 한 일을 몇가지 나열하자면
여기 있는 일들이 FrontEnd 와 전혀 연관이 없을 것 같지만 상당히 많은 연관성이 있다.
site: https://codepair.yorkie.dev
github: https://github.com/yorkie-team/codepair
처음에는 이런 모습이었다.
codepair 는 yorkie 기반으로 만들어지는 동시편집 노트 서비스이다. 아직은 yorkie 자체를 테스트 할 수 있는 것에 초점을 맞추고 있다. (조금 더 발전 시키면 Notion 같은 것을 동시편집으로 구현 할 수도 있다.)
codepair 는 기본적으로 노트 하나만 열어주는 서비스였는데, 여기에 여러가지 기능을 추가 해봤다.
딱히 누가 시켜서 한건 아니고 하다 보니 내가 필요해서 여러가지 기능을 추가 했다.
시간을 좀 쓰긴 했지만 테스트 한다는 마음으로 빠르게 진행 했었다.
그렇게 해서 이렇게 바뀌었다.
사람들에게 가장 많은 칭찬을 들은 기능
오른쪽 화면 밑에 보면 Yorkie 마스코트가 있다.
상대방이 글 입력하거나 하면 마스코트가 움직인다.
그래서 사용성이 좀 좋아지긴 했는데 아직 할게 많다.
최종 목표는 노션과 비슷한 형태로 만드는 것
원래 이것만 하고 싶었는데 다른 일들이 계속 들어오는 바람에 여기서 멈출 수 밖에 없어서 안타깝다.
동시편집 에디터 서비스에 관심 있는 분들은 codepair 프로젝트에 참여해도 좋을 것 같다.
보통 자료구조에 대한 뷰(시각화)를 잘 안 만들지 않는다.
왜냐하면 단순히 Tree, Graph 같은 경우는 이미 도구가 너무 많이 나와 있기 때문에 특별히 다른 도구를 만들어야 할 이유가 잘 없다.
Yorkie는 자체적으로 자료구조를 만들고 있다 보니 이야기가 조금 다르다.
하지만 대부분의 프로젝트들이 초반에는 이런 개발자 도구부터 만들기가 쉽지 않다.
정확히 어떤 자료구조 형태가 만들어질지 모르기 때문인데,
어느 임계점에 다다르면 더이상 코드만으로 테스트 할 수 없는 부분들이 생겨나기 때문에 개발자 도구가 필요한 시점들이 온다.
개발자 도구는 거창한 것은 아니고 내부 자료형을 보여주는 것만 해줘도 된다.
다만 그게 실제로 테스트 할 때 의미를 만들 수 있어야 한다.
버그같은 부분을 쉽게 찾을 수 있어야 하기 때문에 그렇다.
일반적으로 Text 를 다루는 자료형은 string 의 나열로 볼 수 있지만 CRDT 에서 사용되는 구조는 좀 다르다.
여러명이서 동시에 기록을 할 수 있어야 하기 때문에 시간과
앞뒤 순서를 맞추기 위한 ID 를 맵핑시켜야 하기 때문에
현재 보이는 부분과 삭제된 부분이 모두다 tree 형태로 아주 긴밀히 연결되어 있다.
즉, 단순히 string 이 아닌 것이다.
내가 작업한 부분은 Yorkie JS SDK 에 그 소스가 있다.
https://github.com/yorkie-team/yorkie-js-sdk
화면이 이상해 보일지라도 작게라도 보여주자.
그런 다음부터 또 다른 기회들이 생긴다.
CRDT 자료형은 특이하게 지워진 상태도 모두 가지고 있어야 하는데, 그렇다 보니 콘솔로 찍히는 보이는 영역으로만 판단할 수가 없다. 시각화를 하면 그 상태가 한눈에 보이기 때문에 엄청나게 유용하다.
자료형을 깊게 들여다 볼 일 많이 없는 일상에서 Yorkie라는 프로젝트를 통해서 많이 배우고 있는 것 같아서 좋다.
FE 개발자들은 자료구조 시각화, 회사 데이타 시각화에 시간을 할애하면 몇가지 이점이 있다.
- 내부 데이타 구조를 다 확인 해야한다.
- 데이타와 데이타 사이 연결 구조도 확인 해야한다.
- 그 안에서 의미 있는 연결을 실제로 화면에 보여줘야 한다.
계속 하면 데이타 보는 관점이 단순히 저장에서 뷰까지 확장이 된다. (개안을 한다고 해야하나 ... )
CRDT 에 대한 자세한 이야기는 여기서 하지 않는다.
Yorkie 디자인 문서를 보자. (https://github.com/yorkie-team/yorkie/blob/main/design/README.md)
Yorkie 에 대해서 더 자세히 알고 싶으면 https://yorkie.dev 가서 오픈소스 참여해도 좋다.
대부분이 한국 개발자들이기 때문에 부담(?) 없이 시작할 수 있다.
에디터 프레임워크가 뭘까?
먼저 이 질문에 대답을 잘 해야한다.
왜냐하면 에디터가 서비스가 될 수도 있고, 어플리케이션이 될 수도 있고, 라이브러리가 될 수도 있기 때문이다. 각자의 역할에 따라서 너무 다 다른 영역을 개발해야한다.
에디터라는 이름은 특이하게도 어디에 붙어도 이상하지 않다.
생각보다 스펙트럼이 상당히 넓은데 그러다 보니 정작 만드는 사람들도 어디까지를 해야할지 헷갈릴 때가 많다.
https://editor.easylogic.studio/
EasyLogic Studio 라는 웹디자인툴을 만들면서 가장 큰 고민이 어떻게 하면 에디터를 쉽게 만들 수 있을까였다. 그래서 그 안에서 몇가지 기능들을 계속적으로 정제하고 있었다.
그래서 작년에 이런것도 만들었었다.
https://www.elf-framework.com/pages/base-editor/getting-started/index.html
코드는 여기에
https://github.com/elf-framework/editor/tree/develop/packages/base-editor/src
기존에 잡았던 컨셉들은 UI 와 완전히 결합된 에디터 프레임워크 였는데 이러다 보니깐 렌더링 구조에 엄청나게 영향을 받는 문제가 생겼다.
그래서 이번에는 UI 와 완전히 분리 시키는 형태로 제작하고 있다.
xxx/core
xxx/react
2가지 형태로 패키지가 존재한다.
core 패키지는 UI 와 연관성 없이 에디터 자체를 구성할 수 있는 여러가지 Manager 와 Plugin 시스템들을 통해서 하나의 어플리케이션 단위를 만들 수 있도록 한다.
react 패키지는 core 패키지를 react 용으로 감싸는 역할이다. 리액트에서 사용하기 편한 몇가지 Hook, Context 개념이 제공된다.
이 작업은 vscode 영향을 많이 받았는데, vscode 자체도 UI 프레임워크를 사용하지 않고 native dom 을 써서 만들어지고 있어서 최대한 구조에 UI 영향을 안 받도록 하는게 목표가 되었다.
에디터 프레임워크라고 하지만 어플리케이션 만드는 기본 구조에 가까워지고 있는 것 같다.
대략 이정도 스펙을 맞추고 있다.
Application - App을 만들기 위한 기본 구조
├── CommandManager - Manager 는 App과 Service 를 연결하는 객체
│ └── CommandService - App과 상관없이 순수 데이타를 관리하기 위한 객체
├── PluginManager
│ └── PluginService
├── ConfigurationManager
│ └── ConfigurationService
├── LanguageManager
│ └── LanguageService
├── ActionManager
│ └── ActionService
├── ContextManager
│ └── ContextService
├── KeyBindingManager
│ └── KeyBindingService
└── HistoryManager
└── HistoryService
이번에 할 때는 ChatGPT와 함께 기존에 만들었던 구조(elf-framework)를 계속 비교해가면서 테스트 코드까지 다 작성해보면서 만들었다.
상당히 재미난 경험이었음.
디자인 시스템은 FE 개발자들에게는 꿈의 시스템이기도 하지만 고난의 시작이기도 하다.
너무 코어한 레벨이다 보니 이 자체만 가지고 할 수 있는게 별로 없지만 잘(?) 만들어야 한다.
우연히 회사에서 디자인 시스템을 만들 수 있는 기회가 생겨서, 어떻게 만들까 고민을 많이 하다가 이 글을 읽고 바로 동의했다.
https://www.adebayosegun.com/blog/the-future-of-chakra-ui
The future of Chakra UI 라는 글인데 중간쯤 이런 그림이 나온다.
UI 개발 구조를 총 4단계로 분리를 하는데
UI 개발을 각각의 영역으로 좀 더 집중하게 해준다. 그리고 Chakra-ui는 총 3가지 솔루션을 만들어냈다.
이번에 만드는 디자인 시스템은 이 3가지를 사용해서 하나씩 랩핑하고 있다.
각자의 영역에서 최선을 다하면 되기 때문에 익숙해지면 UI 만들기가 훨씬 쉬워지지 않을까 생각한다.
ark-ui 만 가지고 사용 할 수 있을줄 알았지만 ark-ui 는 zagjs 에서 만들어지는 상태를 가진 ui 만 있다.
즉, 상태가 없는 UI 는 따로 만들어야 하는데 그럴 때 https://park-ui.com 을 참고하면 좋다.
다 만들어지면 PandaCSS 구조로 이루어진 Preset 만 잘 갖추면 UI 스타일도 데이타로써 충분히 가치를발휘 할 수 있게 된다.
디자인시스템 개발을 시작하면서 당연하게도 여러가지 여러움에 부딪히게 되는데 이 것 또한 다들 흔히들 겪는 것들이다.
등등 무수히 많은 영역들을 개발자와 디자이너간에 협의를 하면서 찾아가야한다.
디자인 시스템은 서비스를 만들 때와 행동 패턴들이 좀 다른데 기획이 따로 존재하지 않는 경우가 많기 때문이다. 기획이 존재하는 서비스는 기획을 기준으로 디자인과 개발이 맞추면 되지만, 디자인 시스템은 그렇지 않기 때문이다. 개발과 디자인 둘 사이에 했던 것들을 체계화 시켜야 하는데, 그동안 아무도 그러라고 하지 않았기 때문에 알고있는 항목들이 모두다 다르다.
그 중에 가장 어려웠던 것이 컴포넌트를 구조화 하는 작업이었는데, 개발자,디자인 모두 알고 있는 컴포넌트 개념이 다르고 사용하는 네이밍이 다 달랐다.
그래서 zagjs 기반으로 anatomy 형태를 통일하자고 의견을 냈고, 그대로 진행하기로 했다.
덕분에 여러가지 시행착오를 겪던 부분들이 조금씩 사그라지기 시작했다.
대부분의 프로젝트들이 그렇듯이 이 분야도 지식없이 들어오는 사람들이 많기 때문에 이 간극부터 해결해야했다. 그럴때 가장 중요한 것은 기준을 마련하는 것이다.
특정 이슈를 처리 할 때 잘 알고 있어도 외부의 것을 써야 할 때가 있고,
잘 모르지만 직접 만들어야 할 때가 있다.서로 책임질 수 없는 상태가 되면, 이미 잘 나와있는 개념을 참고하자.
먼저 빠르게 시도 해보고, 그 안에서 어떤걸 바꿔야 할지 배워야 한다.
디자인시스템을 만들면서 한번 더 느끼지만
FrontEnd 개발자는 코딩보다 디자인 공부를 더 많이 해야한다고 생각한다.
이것도 언젠가 오픈 할 수 있기를 기대하면서...
올해도 그냥 지나가지 않고, 여러가지를 해보았다.
전혀 다른 영역의 일을 하는건 쉽지 않을 수도 있다.
다만 그 안에서 내가 원하는 영역이 있으면 상관 없다고 생각한다.
그 동안은 구현은 했지만 더 이상 안 쓰는 것들을 만드는 느낌이었다면 지금은 어디선가에 잘 적용되어 있을테니....
내년도 다양한 일들을 해보자.