개발자, 2023 기술회고를 하다.

jinho park·2023년 12월 31일

개발자 기술 내맘대로 회고

회고를 하면 보통 개인적인 이야기를 많이 하기 때문에 잘 안하려고 하다가 기술회고라는걸 해본다.
이건 한해동안 했던 일들에 대한 이야기 이다.

난 기본적으로 Front-End 개발자로 살고 있다.
조금 다른게 있다면 분야를 가리지 않고 살고 있는 것 같다.

올해에 한 일만 해도 기준이 없다.

동시편집 CRDT 서비스 Yorkie 프로젝트 참여
에디터 프레임워크 개발
디자인 시스템 개발

보통 일을 이렇게 하면 정체성이 의심 될 수도 있지만 난 그렇지 않다.
왜냐하면 항상 이렇게 해왔기 때문이다.

다만 이렇게 하는 것들이 일의 기준이 없고, 경험치가 쌓이는 느낌이 전혀 아니기 때문에 내 주변 사람들은 힘들어한다. 그래서 주변에 미안하지만.... (이 일을 내가 준게 아니니)

참고로 난 경력 16년 동안
BE, FE 가리지 않고 다 했는데
지금은 FE 를 열심히 더 배우고 있다.
너무 배울게 많아서 코딩을 놓지 못하고 있다.

내가 하는 일 중에는 오픈소스와 회사일이 섞여 있다.

자, 본격적으로 하나씩 까보자.

동시편집 CRDT 서비스 , Yorkie

Yorkie 는 여기서 https://yorkie.dev/

Yorkie 는 CRDT 라는 동시편집 기술을 개발하고 있는 서비스라고 볼 수 있다.
왜냐하면 CRDT 자료형만 만드는게 아니라 서비스 할 수 있는 서버까지 같이 만들고 있어서 그렇다.

동시편집이라는 자료형을 만드는건 생소 할 수 있는데 다행이 내 옆에 그 것을 하는 동료가 있다.
그래서 항상 감사한 마음을 가지고 있다.
내가 조금이라도 기여할 수 있는 부분이 있어서 ...

Yorkie 는 몇년 전부터 알고 있었지만 본격적으로 올해에 잠깐 참여했다.
잠깐 한 일을 몇가지 나열하자면

codepair 서비스 업데이트
Yorkie text 자료형 개발자 도구 만들기
Yorkie Tree 초기 구현 참여

여기 있는 일들이 FrontEnd 와 전혀 연관이 없을 것 같지만 상당히 많은 연관성이 있다.

codepair 라는 서비스를 보자.

site: https://codepair.yorkie.dev
github: https://github.com/yorkie-team/codepair

처음에는 이런 모습이었다.

codepair 는 yorkie 기반으로 만들어지는 동시편집 노트 서비스이다. 아직은 yorkie 자체를 테스트 할 수 있는 것에 초점을 맞추고 있다. (조금 더 발전 시키면 Notion 같은 것을 동시편집으로 구현 할 수도 있다.)

codepair 는 기본적으로 노트 하나만 열어주는 서비스였는데, 여기에 여러가지 기능을 추가 해봤다.

전체 구성 디자인 바꾸기
사이드 패널에 링크 추가하기
에디터에 신택스 하일라이팅 추가
mermaid, tldraw 기능 추가 하기
user 상태 저장하기
markdown 에디터 업데이트 하기

딱히 누가 시켜서 한건 아니고 하다 보니 내가 필요해서 여러가지 기능을 추가 했다.
시간을 좀 쓰긴 했지만 테스트 한다는 마음으로 빠르게 진행 했었다.

그렇게 해서 이렇게 바뀌었다.

사람들에게 가장 많은 칭찬을 들은 기능

오른쪽 화면 밑에 보면 Yorkie 마스코트가 있다.
상대방이 글 입력하거나 하면 마스코트가 움직인다.

그래서 사용성이 좀 좋아지긴 했는데 아직 할게 많다.

최종 목표는 노션과 비슷한 형태로 만드는 것

원래 이것만 하고 싶었는데 다른 일들이 계속 들어오는 바람에 여기서 멈출 수 밖에 없어서 안타깝다.

동시편집 에디터 서비스에 관심 있는 분들은 codepair 프로젝트에 참여해도 좋을 것 같다.

Text 자료형 개발자 도구

보통 자료구조에 대한 뷰(시각화)를 잘 안 만들지 않는다.

왜냐하면 단순히 Tree, Graph 같은 경우는 이미 도구가 너무 많이 나와 있기 때문에 특별히 다른 도구를 만들어야 할 이유가 잘 없다.

Yorkie는 자체적으로 자료구조를 만들고 있다 보니 이야기가 조금 다르다.

하지만 대부분의 프로젝트들이 초반에는 이런 개발자 도구부터 만들기가 쉽지 않다.
정확히 어떤 자료구조 형태가 만들어질지 모르기 때문인데,
어느 임계점에 다다르면 더이상 코드만으로 테스트 할 수 없는 부분들이 생겨나기 때문에 개발자 도구가 필요한 시점들이 온다.

개발자 도구는 거창한 것은 아니고 내부 자료형을 보여주는 것만 해줘도 된다.

다만 그게 실제로 테스트 할 때 의미를 만들 수 있어야 한다.
버그같은 부분을 쉽게 찾을 수 있어야 하기 때문에 그렇다.

Yorkie.Text 는 text 가 아니라 tree 의 결합체

일반적으로 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단계로 분리를 하는데

Styled System : CSS in JS 를 활용할 수 있는 기능
Design Tokens: Design Token 을 관리할 수 있는 기능
State Machine: UI 와 상관없는 상태 관리 기법
Headless Component: 스타일이 없고 상태만 가지고 있는 컴포넌트 모음

UI 개발을 각각의 영역으로 좀 더 집중하게 해준다. 그리고 Chakra-ui는 총 3가지 솔루션을 만들어냈다.

Styled System + Design Tokens : https://panda-css.com
State machine: xstate 의 미니멀한 구현인 zagjs https://zagjs.com/
Headless Component: ZagJS 를 UI 컴포넌트별로 감싼 ArkUI https://ark-ui.com/

이번에 만드는 디자인 시스템은 이 3가지를 사용해서 하나씩 랩핑하고 있다.
각자의 영역에서 최선을 다하면 되기 때문에 익숙해지면 UI 만들기가 훨씬 쉬워지지 않을까 생각한다.

ark-ui 만 가지고 사용 할 수 있을줄 알았지만 ark-ui 는 zagjs 에서 만들어지는 상태를 가진 ui 만 있다.
즉, 상태가 없는 UI 는 따로 만들어야 하는데 그럴 때 https://park-ui.com 을 참고하면 좋다.

다 만들어지면 PandaCSS 구조로 이루어진 Preset 만 잘 갖추면 UI 스타일도 데이타로써 충분히 가치를발휘 할 수 있게 된다.

디자인시스템 개발을 시작하면서 당연하게도 여러가지 여러움에 부딪히게 되는데 이 것 또한 다들 흔히들 겪는 것들이다.

token 개념 정의, 이름 지정하기
semantic token 을 어디까지 정의해야할까?
개발과 디자인 개념을 어떻게 일치 시킬까?
컴포넌트 개념을 디자인과 어떻게 공유해야할까?

등등 무수히 많은 영역들을 개발자와 디자이너간에 협의를 하면서 찾아가야한다.

디자인 시스템은 서비스를 만들 때와 행동 패턴들이 좀 다른데 기획이 따로 존재하지 않는 경우가 많기 때문이다. 기획이 존재하는 서비스는 기획을 기준으로 디자인과 개발이 맞추면 되지만, 디자인 시스템은 그렇지 않기 때문이다. 개발과 디자인 둘 사이에 했던 것들을 체계화 시켜야 하는데, 그동안 아무도 그러라고 하지 않았기 때문에 알고있는 항목들이 모두다 다르다.

그 중에 가장 어려웠던 것이 컴포넌트를 구조화 하는 작업이었는데, 개발자,디자인 모두 알고 있는 컴포넌트 개념이 다르고 사용하는 네이밍이 다 달랐다.

그래서 zagjs 기반으로 anatomy 형태를 통일하자고 의견을 냈고, 그대로 진행하기로 했다.
덕분에 여러가지 시행착오를 겪던 부분들이 조금씩 사그라지기 시작했다.

대부분의 프로젝트들이 그렇듯이 이 분야도 지식없이 들어오는 사람들이 많기 때문에 이 간극부터 해결해야했다. 그럴때 가장 중요한 것은 기준을 마련하는 것이다.

특정 이슈를 처리 할 때 잘 알고 있어도 외부의 것을 써야 할 때가 있고,
잘 모르지만 직접 만들어야 할 때가 있다.

서로 책임질 수 없는 상태가 되면, 이미 잘 나와있는 개념을 참고하자.

먼저 빠르게 시도 해보고, 그 안에서 어떤걸 바꿔야 할지 배워야 한다.