다크 모드.. "ON"
제 인생도 곧..
whats problem?
▶️ 웹 서비스를 운영하다 보니 시스템 기본 설정으로 따로 대응하지 않았던 다크모드로 서비스를 이용하는 고객들이 있다는 사실을 알게 됨 (사용 경험 이슈)
▶️ 현재 정의된 디자인토큰의 구조의 결함으로 전혀 사용하지 않는 토큰값도 항상 서비스에 들고 있음 (효율성 이슈)
▶️ 기존 디자인 토큰의 확장제한성으로 인한 예외케이스 빈번 (효용성 이슈)
why problem?
웹으로 접속해야 하는 불편함이 이미 있는 상황에서 시스템 설정값을 따라가지 못하는 것은 셀링하고 있는 기술 중심 설루션 경험과 이질적임
how solve?
▶️ 우선 현재 디자인 토큰의 구조를 바꿔 기존의 비효율적인 문제를 해결하고 다크모드를 대응할 수 있는 환경을 구성
▶️ {light}, {dark} 테마 단위 semantic 구조로 디자인 토큰 재정의
▶️ 새로운 구조의 디자인토큰으로 기존 값들을 마이그레이션 해서 다크모드 일대일 대응
▶️ 이후 제작하는 페이지부터 자동으로 테마 적용
progress
디자인 토큰 개선
우선 가장 고질적인 문제는 크게 두 가지로,
1. 내부 사정상 Semantic Color값이 Primitve Color값을 참조하지 못하고 있음
2. 토큰의 커버리지가 낮아서 자꾸 예외 색상을 쓰고 있음
특히 1번 문제 같은 경우, 사실상 Semantic, Primitive 토큰들이 아예 다른 값으로 존재하고 있다 보니 굉장히 비효율적이고, 다크모드 대응을 위해서도 필수적으로 개선이 필요했습니다.
저 같은 경우에는 일정 상 일주일 정도밖에 시간을 사용할 수밖에 없어서 Figma가 제공하는 Simple Design System 파일을 참고하면서 빠르게 적용할 수 있는 부분들 위주로 스코프를 조절하며 토큰을 정의했습니다.
테마 레벨까지 정의한 디자인 토큰위 토큰을 더욱 상세하게 보자면, 먼저 Primitive Color를 정의하고, Semantic 단위로 그룹화해서 토큰을 정의했습니다. 자세한 구조에 대한 내용은 이전에 쓴 글에도 자세히 적어두었으니 혹시라도 궁금하신 분은 읽어봐도 좋을 것 같아요!
Primitive Color
그렇다면 이제 다크모드가 실제로 프로덕트 레벨에서 어떻게 적용되는지 이해하고 가볼까요?
우선 현재 글은 웹 서비스를 기준이라는 점을 말씀드리며, 다크모드가 적용되는 방식 역시 다양하고 정답이 있는 건 아닐 거예요! (저도 잘 몰라요.)
다크모드는 어떻게 적용되나요?
웹서비스에서 다크모드가 적용되는 플로우크게 보면 위와 같은 흐름으로, 브라우저단에서 먼저 사용자의 테마 정보를 읽어오고, 읽어온 테마 정보 값을 서비스단에서 알맞게 대응하는 방식으로 라이트 모드 혹은 다크 모드 색상을 사용하게 됩니다.
어떤 어려움이 있었나요?
사실 다크모드를 처음 생각했을 때, "어 그냥 색상 반전 시키면 되는 거 아닌가?"라고 생각해서 큰 걱정이 없었는데, 실제로 토큰을 정의하면서 만만한 녀석이 아니라는 것을 뼈저리게 느꼈습니다.
대부분의 색상들은 아래와 같이 반전하는 것만으로도 커버리지를 유지할 수 있지만,,
일반적으로 떠올리는 다크모드 대응문제는 이런 상황입니다. 예를 들어, 왼쪽 사례처럼 라이트모드에서 Primary Color위에 흰색 글씨를 사용한다고 가정해 보죠.
이 상황에서 다크모드는 검은색 글씨가 되어야 할까요?
뭐 그럴 수도 있겠지만, 적어도 디자인을 하는 관점에선 라이트모드든 다크모드든 Primary는 Primary로 나오길 원하는 케이스가 많은 것 같아요.
애초에 라이트 모드든 다크모드든 브랜드 혹은 제품의 고유한 색상을 일관되어야 하고, 모드가 바뀌어도 Primary의 위계와 아이덴티티를 잘 전달하는 것은 디자이너의 재량이라고 생각합니다. (지극히 개인적 의견)
아무튼 그래서 다크모드지만 같은 Primary색을 사용하기 때문에 텍스트 역시 라이트모드에서 반전된 검은색이 아니라 흰색이 나와야 하는 케이스가 있습니다.
Primary를 사례로 들었지만 실제로 이런 케이스가 Semantic단위로 꽤 있어서 하나씩 프로토타입 만들면서 대응하느냐고 예상보다 조금 더 늦어져서 진땀 뺐네요 헤헤..
해당 사례를 대응하기 위한 방법참고차 저는 이런 식으로 Inverse 토큰을 따로 둬서 라이트모드든 다크모드든 진한 배경 위에 올라가는 텍스트는 일관된 색상으로 통일시켜서 대응했습니다. 혹시 더 좋은 방법이 있다면 공유 부탁드립니다..!
특히 어떤 것을 고민했나요?
디자인토큰이나 디자인 시스템도 결국에는 확장성을 항상 고민하게 되는데, 처음부터 완벽한 토큰과 정의는 존재할 수 없기 때문이죠.
그렇다면, 향후 시스템 확장에 있어서 수정이 필요할 때, 얼마나 유연하면서도 구조적으로 구성되어 있는지가 관건인데요,
특히 팀 개발자분과 함께 고민했던 부분 중 재밌었던 부분은 아래와 같아요.
라이트모드와 다크 모드 토큰값을 각각 갖고 있는 상황에서 한쪽 값이 달라지면 반대 모드의 값도 변경해야 할까?
예를 들어, {Light} Background / Secondary라는 토큰이 있고, 라이트 모드에서 이 토큰의 색상을 조금 더 어둡게 수정했다면, {Dark} Background / Secondary의 색상은 더 밝게 수정을 해줘야 할까요?
수정하지 않는다면 어떤 병목이 생길까요?
사실 참조 관계인 Primitive Color와 Semantic의 관계를 생각하면 금방 해결되는 문제이지만, 이런 상황에서 향후 확장성을 고려했을 때 어떤 정책을 잡고, 어떻게 얼라인을 맞춰야 할지 이야기하면서 디자인 토큰이 생각보다 깊고 심오한 세계라는 것을 새삼 느꼈습니다.
다행히도 특히 재사용이나 확장성 관점에서 탁월하신 개발자분이셔서, 크게 문제가 되지는 않았지만 결국 중요한 포인트는 앞으로의 토큰의 유지보수를 어떻게 할 것인가? 였어요.
이 부분은 Figma에서 변동이 생길 때 Git으로 Push 한다던가의 저희만의 방식을 충분히 고안해 볼 수 있지만, 아직 그렇게 대응할 Stage는 아니라고 판단해서 잠정적으로 별도의 스프린트를 가져가는 방식으로 이야기를 마무리했습니다.
다크모드 대응 미리 보기
retrospect
어떻게 시스템 설정값을 받아와서 토큰에 적용되어 라이트나 다크 색상을 표출하는 것인지 원리가 이해되지 않아서 개발자분 붙잡고 이해가 될 때까지 물어보면서 모르던 영역을 알게 되어서 뜻깊었읍니다. 저는 디자인을 하든 뭘 하든 이해가 되지 않으면 몰입하기 힘든 성격이라, 엉망으로 물어봐도 완벽하게 답변해 주신 개발자분에게 뜨거운 박수를..
사실 메이커 관점에서 웹서비스에 익숙하지 않아서 다크모드를 제공하지 않더라도 다크모드로 볼 수 있다는 사실을 뒤늦게 알게 되고 대응한 케이스에 가까워요. 이번 레슨런을 통해 앞으로는 제공하는 매체의 특성을 이해하고, 유저가 불편함을 느끼기 전에 먼저 생각하고 고민해서 더 좋은 경험을 제공하도록 노력해 보겠습니다..!
