먼저 Toss의 Frontend Assistant로 Deus팀의 면접을 볼 수 있는 기회가 생겼고,
홈페이지에 따로 공지가 올라와있지 않아서 토스의 영상을 통해 Deus팀을 알아보게 되었다.

Deus란?

Deus란 토스에서 자체적으로 개발한 Figma와 같은 디자인 편집기이다.

왜 자체개발을 했을까?

Toss_serviceToss_service토스 디자인 컨퍼런스, Simplicity
위 링크에 Deus에 대해 아주 자세한 설명이 나와있다.
토스가 필요한 플러그인을 마음대로 추가할 수 없는 점이 불편했다고 한다.
그럼에도 크롬의 플러그인을 추가하여 사용해왔지만,
기존에 쓰던 Framer의 방향성이 토스의 방향성과 달라지게 되어서 자체 툴을 개발하게 되었다고 한다.
 
Figma는 캔버스 위에 벡터 기반의 그래픽을 그리는 도구이지만,
Deus는 DOM 기반 편집기 → 웹뷰 위에 컴포넌트를 올리는 작업 도구이다.
즉, iframe을 사용하게 되면 HTML 문서를 임베드 하는 것이고,
또 다른 HTML DOM 트리를 불러오는 것이라고 생각하면 될 것 같다.
  • 핸드오프(디자이너가 개발자에게 시안을 전달하는 과정)를 원할하며
  • 개발과 디자이너의 간극이 좁아졌다.
  • 데우스를 토스가 가지게 되면서 무한한 가능성, 확장성을 갖게 되었다.
 

기술적 과제

  1. MobX 상태 관리 라이브러리 선택
    1. 상태관리는 프론트엔드에서 정말 중요한 요소
    2. Magic이 많고 React의 아키텍처에 반하는 점들이 MobX의 단점이라고 느끼셨다고 한다.
    3. 이러한 단점에도 Fine-grained Reactivity라는 장점이 있어 MobX를 선택했다.
      1. React는 필요한 부분이 아니라 통째로 리렌더되는 경우가 있다.
      2. 필요한 부분만 리렌더링 되는 것이 Fine-grained Reactivity라고 생각할 수 있다.
      3. Solid.js는 위의 기능이 가능하다는데 왜 React.js를 사용한 것일까?
  1. 쉘 캔버스 분리
    1. 쉘: 에디터에서 선택, 편집과 같은 도구를 선택하는 부분
    2. 캔버스: 에디터에서 실제 디자인 작업물이 표현되는 부분
    3. 쉘, 캔버스를 iframe으로 분리를 하는 작업을 했다.
      1. 캔버스에 요소가 늘어났을 때, 느려지면 안되는 부분까지 느려졌었다.
      2. 메시지를 통해 비동기로 접근해야 했다. → 하지만 유의미한 속도 개선은 없었다.
      3. 단순히 프레임을 분리하면 안됐고, CORS분리만으로는 부족했고 크로스 사이트 격리까지 참고했다.
  1. 스트리밍 파싱
    1. 하드웨어적으로는 문제가 없어도 문자열이 일정 이상 되면 런타임에서 파싱을 거부한다.
    2. Fetch할 때 순서대로 스트리밍을 하듯이 스트리밍하며 파싱하는 것을 구현하여 요소가 많은 트리 형태의 데이터를 가져올 수 있었다.
 

목표

  1. AI와 관련된 기능을 넣는 것이다.
  1. 프로토타이핑이 완성된 결과물과 충분히 흡사하지 않아서 진짜 제품 같은 UT를 하기 어렵다.
 

정리하며,

Deus의 슬로건은 ‘메이커의 유일한 병목이 상상력이 되도록’이다.
즉. 디자이너의 어려움을 없앤다는 뜻이다. 정말 간단하지만 멋있는 북극성 지표인 것 같다.
Deus팀 관련 영상 덕분에 나는 스스로 정해놨던 프론트엔드의 한계점이 깨지게 된 것 같다.
그동안 내가 해왔던 프로젝트들은 기술적 도전들이 필요했던 영역보다는 유저들을 모으기 위한 MVP 정도의 프로젝트였던 것 같다.
이 영상을 보며 난 정말 아무것도 모르는 감자였구나 싶었고,
AI시대에서 프론트엔드의 가능성은 여전히 무궁무진하다는 것을 배웠다.
 
무엇보다 나는 프로젝트를 하면서 라이브러리들의 장단점을 분석하여 썼기 보다는,
내가 원하는 회사의 기술 또는 사람들이 많이 쓰는 기술들을 위주로 사용하였다.
어쩌면 힙한 사람들만 사용하는 라이브러리들도 결국 매력이 있기 때문에 사람들이 사용하는 것이다.
앞으로 개발을 할 때에, 내가 선택하는 모든 것들에 다 이유를 설명할 수 있는 개발자가 되어야겠다.
 

참고