싹 틔우기

이번주 수요일에 디자인시스템 팀 안에서 방향성 논의를 진행했다. 다른 얘기들도 많았지만, 내가 중요하게 생각하고 있는 부분들은 아래와 같다.

• Observability
• SEED Docs
• 상호작용 가능한 디자인시스템 만들기
• 생동감 넘치는 당근 앱 만들기 (e.g Motion, Haptic)

최근에 1.0.0 릴리즈를 하기도 했고, 내 생각을 남겨두면 좋을 것 같아 글을 쓴다.

Observability#

디자인시스템의 가시성을 높이는 작업이다. 현재는 어떤 값을 변경한다던지, 인터페이스를 변경한다던지 할 때 기준이 없이 변경하고 있다. 데이터를 통해서 합리적인 변경을 할 수 있는 것이 목표다.

우리는 Vite, Rsbuild, Webpack과 같이 번들러에 대해서 디자인시스템 플러그인을 제공하고 있다. 거기에 telemetry 옵션을 추가해서 빌드 시점에 프로젝트가 디자인시스템을 어떻게 사용하는지에 대해 쌓으려고 한다. 어느정도 검증은 끝났고 완성도만 올리면 되는 상황이긴한데 다른 우선순위에 밀려 진행하지 못하고 있었다.

패키지 별 버전 분포도라던지 컴포넌트 사용량, Prop 사용량 (이거까지 가능할진 모르겠다. 꽤나 telemetry 구현이 복잡해질듯)을 추적되길 기대하고 있다.

최근에 컴포넌트 스타일을 쉽게 Override 할 수 있게 만들자는 얘기가 나왔고 웹뷰에서 의논한 다음 타일러가 빠르게 구현해주셨는데, 너무 열어 두는 것보단 Override도 Variant 형태로 제공할 수 있지 않을까 하는 얘기가 나왔다.

예를들어 Action Button이라고 치면 배경색을 바꿀 때 단순 enabled의 배경만 변경하는 것이 아닌, disabled, active와 같은 상태의 배경색도 고려해서 변경해야한다.

사실 이런 정보들이 피그마에서 먼저 고려되면 좋겠지만 쉽지 않다. 피그마에서 배경색을 커스텀으로 사용할 때 disabled, active의 모든 색을 고려하는 프로덕트 디자이너분을 자주 보진 못했다. 그래서 개발단에서 버튼안에서 사용되는 CSS Variable을 전부 열어줬는데 이걸 전부 열어주는 것이 아니라 Custom Variant 형태로 지정하게 해서 상태에 대응되는 값들을 유저가 지정하게끔 해야하자는 식으로 얘기가 됐다.

사실 그냥 disabled, active 색상들을 opacity로 처리하면 문제가 조금 쉽게 해결될 것 같긴하지만... 지금은 그렇지 못하므로

그리고 이렇게 Custom Variant 형태로 제공이 됐을 때 Telmetry에서 사용된 Prop들까지 분석할 수 있다면 어떤 조합이 많이 사용됐고, 어떤 Variant는 사용되지 않는지 그래서 어떤 것들을 삭제하고 어떤 것들을 추가할 수 있는지 판단하고 싶은 것이다. 색상 뿐만 아니라 다른 모든 인터페이스에 확장 가능한 얘기다.

SEED Docs#

SEED Docs는 디자인시스템 문서 사이트다.

나는 이곳에 모든 맥락을 쌓고 싶다. 맥락이라고함은 토큰 정보, 컴포넌트 스펙, 스타일 가이드라인, 구현체 인터페이스 정보, 구현체 사용 예시 등을 일컫는다.

우리 사이트에서는 LLMs.txt를 제공하고 있다. 웹사이트는 사람들에게 정보를 제공할 뿐만 아니라 LLM에도 정보를 제공하는 데 사용된다. 다양한 언어 모델들에서 공개된 정보들을 바탕으로 학습하는데, 이 덕분에 잘 정리된 공개되어있는 정보가 중요해졌다.

이제는 다른 곳으로 가신 애셔의 말을 인용하자면, 디자인시스템은 맥락을 압축시켜 놓은 것이다.

어떤 색상을 사용할 것인지, 어느정도의 여백을 가져갈 것인지, 어느정도의 둥글기를 가져갈 것인지, 텍스트 사이즈, 굵기, 간격 모든 것이 의사결정의 결정체이자 맥락이다. 스타일 가이드라인도 마찬가지로 이미지가 아닌 텍스트로 설명할 수 있어야한다. 이미지는 텍스트 부연설명 정도의 느낌으로만 사용한다. llms.txt와 같이 맥락을 쌓아두고 해당 맥락을 public한 공간에 뿌려놓는다.

요즘 UI Generator (Lovable, Bolt, etc)와 같은 서비스들이 많아졌다. 만약 '상품 리스트를 보여주는 페이지를 만들고 싶어'라고 했을 때 언어 모델 입장에서 부족한 정보가 너무 많다. 디자인시스템은 그 부족한 정보들을 함축적으로 전달할 수 있다. 맥락을 공개해놓음으로써 위의 이점을 자연스럽게 누릴 수 있다.

몇 개월전에는 Lovable, Bolt와 같은 것을 사내에서 만들어보려고 했었는데 이곳에 리소스를 많이 쓰기보다는 UI Generator의 시장이 커지길 기대하고 우리는 자연스럽게 맥락을 잘 쌓아두기로 했다. 이후에는 쌓인 맥락만 잘 넣어주면 당근스럽게 라는 말을 잘 이해하지 않을까.

문서 컨텐츠가 당연히 훨씬 중요하겠지만, SEED를 조금 더 브랜딩 강화하고 사이트도 멋지게 만들고 싶다. 보기 좋은 문서가 읽기도 쉽다고 했던가, 지금은 우리끼리 정리해놓은 문서 느낌에 가깝다면 조금 더 공식적인 느낌이 났으면 좋겠다.

그리고 문서에 대한 정보를 MCP로도 제공하려고 한다. 사내 LLM 채팅 서비스에도 사용되고, 아래에서 얘기할 에이전트에서도 사용될 수 있다.

상호작용 가능한 디자인시스템 만들기#

최근에 토스에서 100번 실패하고 살려 낸 문서 시스템으로 발표한 것을 봤는데 내가 하고자 하는 방향과 너무 비슷하게 구축되어 있어서 놀랐다.

현재는 디자인시스템이 너무 일방적이다. 문서라던지, 컴포넌트, 제공하는 다양한 시스템들과 상호작용 한다는 느낌이 없다.

나는 당근만의 지식의 궁전이 있고, 우리가 대화하는 곳(슬랙)에서 대화 가능하고, 기여 가능하고, 같이 쌓아가는 느낌을 내고 싶다.

구현은 슬랙 봇을 만들고 있고, 우리팀 n8n 컨테이너를 하나 띄워서 슬랙 관련 설정과 디비 설정은 끝내놓은 상태다. 지식의 궁전 + 디자인시스템 맥락을 제공해서 질답을 해주는 SEEE 봇을 만들면 된다.

디자인시스템 맥락은 위에서 얘기한 것과 같이 MCP로 해결될 것 같고, 지식의 궁전에 대해서 부연설명하자면 슬랙에서 대화하다 보면 중요한 얘기인데 흘러지나가는 경우가 많다. 그리고 이후에 다시 해당 맥락이 필요해졌을 때 슬랙 메시지를 찾거나 기억속에서 꺼내려고 하지만 생각나지 않는 경우가 많다. 의미있는 대화가 오갔고, 해당 맥락들을 우리의 지식으로 쌓아야 한다면 저장해두고 계속해서 발전시켜야한다.

구체적인 지식을 쌓는 방식과 상호작용 가능한 방식에 대해서는 조금 더 고민과 공부가 필요하다. 보통 이런 원하는 정보를 찾고, 알맞은 정보를 제공할 때 RAG를 구축하는 것이 일반적인가 싶긴한데 이쪽은 아는 게 많이 없다. RAG까지 아니더라도 엑셀(혹은 저장될 수 있는 어떤 공간 어디든)로 정보를 쌓고, 컨텍스트에 넣어주는 방식으로도 어떻게든 구현은 가능하다.

처음부터 완벽할 필요는 없다. 그럴수도 없고

생동감 넘치는 당근 앱 만들기#

항상 예전부터 하고 싶었다.

당근 앱은 너무 정적이다. 햅틱도 거의 안 들어가있고, 모션도 많이 넣지 않는다. 내부적으로는 V3인 SEED를 적용하면서 몇몇 컴포넌트에 transition, animation이 들어갔지만 아직도 너무 정적이다.

최근에 카카오톡이 대격변 업데이트를 하면서 완전히 뜨거운 감자인데, 카카오톡에도 바텀 네비게이션 아이템 눌렀을 때 햅틱과 화면 전환 트랜지션이 들어갔다. 카카오톡이 좋은 사례라고는 단정 지을 수 없겠지만 앱이 조금 더 생동감이 있어졌다. 생동감이 있다 못해 너무 시끄러워진 것 같기도 하지만

항상 좋은 예시로 올라오는 토스 앱도 터치하면 내가 터치를 했다는 확실한 피드백과 유려한 모션들이 들어가있다.

좋은 사례를 따라하는 것이 아닌, 좋은 사례들이 해결한 문제를 우리도 해결하고 싶다.

터치를 했다면 터치가 됐다는 피드백을 받을 수 있어야 하고, 제스쳐를 취했다면 그에 맞는 전환이 일어나야 한다. 성공과 실패는 확실히 인지되어야 하고, 선택과 선택 해제는 쉽게 납득이 가야한다.