Theme에서 다크와 라이트를 구분하지 않고 Semantic에서 구분하는 이유가 궁금합니다
103
작성한 질문수 1
안녕하세요
Theme에서 다크와 라이트를 구분하지 않고 Semantic에서 구분하는 이유가 궁금합니다
Theme에서 부터
- brand1 - dark
- brand1 - light
- brand2 - dark
- brand2 - light로 구분하게 되면
semantic에서는
- bold-sementic-backgound로
모든 브랜드와 다크모드가 대응 되는거 아닌가요?
제가 구조를 제대로 이해한게 맞나요?
답변 2
0
동진님 안녕하세요,
네, 그렇게 하셔도 괜찮습니다. 모드를 적용하는 위치는 Theme든 Semantic이든 기능적으로는 큰 차이가 없습니다.
제가 만든 변수 구조에서는 Theme에는 브랜드 색상, Semantic에는 라이트/다크 모드를 나눠서 구성했습니다.
일반적으로는 Semantic에 라이트/다크 모드를 두는 방식이 더 흔한데요, 그 이유는 다음과 같습니다:
Semantic 베리어블은 실제 UI에 직접적으로 사용되기 때문에,
대부분의 UI 요소가 라이트/다크 모드에 따라 값이 바뀌게 됩니다.
밝기나 명도 차이 같은 미묘한 시각적 차이도 모드에 따라 세밀하게 적용해야 할 경우가 많기 때문에 Semantic이 적절합니다.
모드를 나눌 때는 해당 컬렉션 내의 변수 수(스케일)도 고려하셔야 합니다.
→ Semantic 쪽은 대부분의 색상이 다 모드별로 존재해야 하므로 구조적 정리가 중요합니다.
반면에 Theme 컬렉션은 브랜드 색상 몇 개 정도만 다루면 되기 때문에 상대적으로 단순하게 관리할 수 있습니다.
만약 브랜드별 테마와 다크 모드를 함께 고려하신다면,
Semantic에 모드를 설정하시는 걸 추천드립니다.
그렇게 하면 불필요하게 중복되는 컬러 정의도 줄일 수 있고, 유지 관리도 훨씬 유리합니다. 하지만 Theme에 하셔도 괜찮습니다.
한번 해보시고 안되시면 알려주세요. 저도 한번 시도해보도록 하겠습니다.
볼드 드림.
0
아 넵 답변 감사합니다.
두가지 질문이 더있는데
1. 토큰관련 질문
theme에서 brand 나누고, semantic에서 light/dark 나눈다고 했을때 피그마는 apply variable mode로 적용이 가능하지만,
개발할땐 브랜드나 light/dark 모드를 토큰이름에 포함시켜야 된다고 생각 했었습니다. (color-brand1-dark-bg-primary)
개발할땐 토큰명이 같아도 브랜드 별, 모드별로 적용이 가능한거죠? (color-bg-primary)
개발자와 커뮤니케이션할때 어떤식으로 전달해야할지 고민됩니다.
2.
저희 서비스가 현재 컨셉때문에
1번 서비스는 라이트모드만 지원하고
2번 서비스는 다크모드만 지원해요
서비스의 primary 컬러도 달라서
이런경우에는 어떻게 설계를 하는게 좋을까요?
스타트업이라 근 몇년간은 모든 서비스에 다크/라이트 모드를 확장하진 않을것 같은데
theme을 두지말고 semantic에서 전부 나눠서 값을 넣는것과
어차피 다크모드(서비스2) , 라이트모드(서비스1)는 둘다 만들어야하니 확장성 생각해서 theme에는 브랜드 semantic에서 모드를 구분할지 고민됩니다.
(지금 라이트모드 다크모드 할지안할지도 모르는데 고려해야하나.. 개발 리소스 관점)
0
안녕하세요 동진님,
회사 내부의 정확한 상황을 제가 모두 알 수는 없기 때문에, “이렇게 하세요”라고 단정적으로 말씀드리긴 어렵습니다. 강의에서는 최대한 실무에서 마주칠 수 있는 다양한 경우의 수를 다루었지만, 실제 업무는 훨씬 더 복잡할 수 있기 때문입니다.
다만, 제 개인적인 의견을 드리자면 아래와 같은 방향으로 접근해보시는 것도 좋을 것 같습니다.
지금은 ‘미래’보다 ‘현재’에 집중하는 것이 더 효과적입니다.
미리 준비해두는 것도 좋지만, 지금 당장 필요하지 않은 것을 굳이 만들어둘 필요는 없습니다.
실질적으로 사용될 시점에 맞춰 유연하게 대응하는 것이 오히려 효율적일 수 있습니다.
✅ 제가 이해한 바로는:
1번 서비스 = 라이트 모드
2번 서비스 = 다크 모드
동일한 컴포넌트를 사용하고 계신다면, 굳이 라이트/다크 모드로 구분할 필요는 없어 보입니다.
(물론 향후 확장성을 위해 구조는 열어둘 수 있습니다)
저라면 그냥 이렇게 정의할 거 같습니다.
Primitive: 기본 토큰 정의
Semantic: 의미 기반 토큰 정의[여기서 그냥 서비스 단위]
그리고 실제 개발에서는, 각 서비스별로 data.json 파일을 분리하여 “다크/라이트 모드”가 아니라 “서비스 단위”로 스타일을 추출하면, 라이브러리마다 모드 구조가 달라도 충분히 유연하게 대응 가능합니다.
개발 쪽에 대해서는 제가 사용하는 테크 스택을 잘 알지 못해 구체적인 조언은 어려운 점 양해 부탁드립니다. 그 부분은 동진님께서 개발자분과 먼저 방향을 논의하신 후, 어떻게 진행할지를 결정하시는 게 좋을 것 같습니다.
또한, 제 경험상 미리 구조를 단정 짓기보다는 개발 환경과 실제 사용 방식에 맞춰 유연하게 접근하시는 걸 추천드립니다.
참고로, 토큰 네이밍에서 예: "color-brand1-dark-bg-primary" 와 같은 방식은 일반적으로 많이 쓰이지 않습니다. 이처럼 여러 속성이 한꺼번에 섞인 네이밍 방식은 확장성과 관리 측면에서 오히려 불리할 수 있기 때문입니다.
더 권장되는 구조는 css 파일을 브랜드 단위로 분리 css/brand1, css/brand2하여 내부 토큰 명은 동일하고 참조를 달리한다던가. 미디어쿼리 또는 클래스 방식으로 처리하기도 합니다. 이 부분은 강의를 벗어나는 주제로 더 다루지는 않도록 하겠습니다.
반드시 혼자 고민하시고 개발자와 함께 고민하시기 바랍니다.
0
안녕하세요, 인프런 AI 인턴입니다. 동진님께서 질문하신 내용에 대해 관련 정보를 찾아보았습니다.
질문의 핵심:
- Theme에서 다크와 라이트를 구분하지 않고 Semantic에서 구분하는 이유에 관한 내용입니다.
관련 답변 링크 및 요약:
“color variable 등록 시 naming 및 색깔 기준 문의…”
- 컬러 베리어블의 네이밍과 적용 방법에 대해 설명합니다. 여기에서는 각 브랜드 또는 모드별로 컬러를 적용할 때 확장성과 유지보수를 고려하여 특정 구조로 관리하는 것이 중요하다는 점을 다룹니다.
- 컬러 베리어블의 네이밍과 적용 방법에 대해 설명합니다. 여기에서는 각 브랜드 또는 모드별로 컬러를 적용할 때 확장성과 유지보수를 고려하여 특정 구조로 관리하는 것이 중요하다는 점을 다룹니다.
“semantic 컬러 베리어블 정의 할때 왜 여기선 무조건 theme 컬러를 참조하는 이유가 무엇인가요?”
- Semantic 컬러가 통일된 스타일을 유지하면서도 다양한 테마와 모드에서 재사용될 수 있도록 관리하는 이점에 대해 설명하고 있습니다.
- Semantic 컬러가 통일된 스타일을 유지하면서도 다양한 테마와 모드에서 재사용될 수 있도록 관리하는 이점에 대해 설명하고 있습니다.
기본적인 원리 요약:
Theme과 Semantic의 역할:
- Theme은 브랜드나 특정 모드(예: 다크/라이트)를 정의하는 데 사용하고, 이는 큰 틀에서 스타일 가이드를 제공합니다.
- Semantic은 보다 세부적으로 텍스트, 배경, 버튼 등 다양한 UI 요소의 상태 및 역할에 맞춰 컬러를 정의합니다.
- Theme은 브랜드나 특정 모드(예: 다크/라이트)를 정의하는 데 사용하고, 이는 큰 틀에서 스타일 가이드를 제공합니다.
이점:
- 관리 용이성: 다양한 브랜드와 모드가 추가되더라도, Semantic 레이어에서 통합적으로 관리하여 스타일의 일관성을 유지할 수 있습니다.
- 유지보수: Semantic 레이어에서 컬러를 한 번 정의하면, 여러 테마와 모드에 동일하게 적용되므로 중복이 최소화되어 유지보수가 용이합니다.
- 관리 용이성: 다양한 브랜드와 모드가 추가되더라도, Semantic 레이어에서 통합적으로 관리하여 스타일의 일관성을 유지할 수 있습니다.
이러한 정보를 통해 Theme에서 다크/라이트를 구분하지 않고 Semantic에서 이들을 세분화하여 사용하는 것이 디자인 시스템의 복잡성을 감소시키고 유지보수를 쉽게 해줄 수 있다는 점을 이해하실 수 있을 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
배리어블 Value에 관해 질문있습니다.
0
21
0
Body>font weight 에서 semibold에 짝대기가 생기는 이유?
0
26
1
Navigation Mobile 토글 베리어블이 안됩니당
1
25
2
Typography 모드 적용시 표현된 값과 우측에 표시되는 값다름
0
26
1
디자인 시스템에 그룹명을 숨길 수도 있나요?
0
39
2
디자인 시스템 네이밍에 관한 질문드립니다.
0
49
2
next step?
1
67
1
16강 Print Variables 출력 질문
0
79
2
open in Figma 누르고 ui kit 다운?받았을 때
0
62
2
variables 이름 지을때 소문자,대문자 사용에 관해..
0
89
2
디자인 시스템 네이밍 순서에 대해 질문남깁니다!
0
111
2
이미지 캐러셀 영상
0
64
2
아이콘 사이즈 컴포넌트 구성 방식 관련
0
98
3
완강/리뷰 이벤트 후 강의자료
0
58
2
Stack 컴포넌트 관련하여 궁금한 점이 있습니다.
0
53
1
컴포넌트별 베리어블 구축
0
76
2
인풋 텍스트필드에서는 왜 'interactive/bg' 배리어블을 활용하지 않는 것인가요?
0
35
1
섹션 6 / 29.Button 강의의 아이콘 인스턴스 스왑 질문
0
49
2
UI Kit에서 배리어블 등록 안되는 문제
0
57
2
교육용 피그마 계정 문의
0
57
2
베리어블 등록했는데 스타일에 연결하려니까 안보여요..
0
81
3
폰트 웨이트 지정에서, '바디만 따로 웨이트를 시멘틱에 그룹핑 하는 이유'가 무엇인가요??
0
47
2
섹션 6 / 29.Button 강의 질문
0
63
2
67강, 70강, 75강 자료 다운로드
0
50
1