인프런 커뮤니티 질문&답변

아 넵 답변 감사합니다.

두가지 질문이 더있는데

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에서 모드를 구분할지 고민됩니다.
(지금 라이트모드 다크모드 할지안할지도 모르는데 고려해야하나.. 개발 리소스 관점)

안녕하세요 동진님,

회사 내부의 정확한 상황을 제가 모두 알 수는 없기 때문에, “이렇게 하세요”라고 단정적으로 말씀드리긴 어렵습니다. 강의에서는 최대한 실무에서 마주칠 수 있는 다양한 경우의 수를 다루었지만, 실제 업무는 훨씬 더 복잡할 수 있기 때문입니다.

다만, 제 개인적인 의견을 드리자면 아래와 같은 방향으로 접근해보시는 것도 좋을 것 같습니다.

지금은 ‘미래’보다 ‘현재’에 집중하는 것이 더 효과적입니다.

• 미리 준비해두는 것도 좋지만, 지금 당장 필요하지 않은 것을 굳이 만들어둘 필요는 없습니다.

  실질적으로 사용될 시점에 맞춰 유연하게 대응하는 것이 오히려 효율적일 수 있습니다.

   

✅ 제가 이해한 바로는:

• 1번 서비스 = 라이트 모드

• 2번 서비스 = 다크 모드

   

  동일한 컴포넌트를 사용하고 계신다면, 굳이 라이트/다크 모드로 구분할 필요는 없어 보입니다.

  (물론 향후 확장성을 위해 구조는 열어둘 수 있습니다)

저라면 그냥 이렇게 정의할 거 같습니다.

• Primitive: 기본 토큰 정의

• Semantic: 의미 기반 토큰 정의[여기서 그냥 서비스 단위]

그리고 실제 개발에서는, 각 서비스별로 data.json 파일을 분리하여 “다크/라이트 모드”가 아니라 “서비스 단위”로 스타일을 추출하면, 라이브러리마다 모드 구조가 달라도 충분히 유연하게 대응 가능합니다.

개발 쪽에 대해서는 제가 사용하는 테크 스택을 잘 알지 못해 구체적인 조언은 어려운 점 양해 부탁드립니다. 그 부분은 동진님께서 개발자분과 먼저 방향을 논의하신 후, 어떻게 진행할지를 결정하시는 게 좋을 것 같습니다.

또한, 제 경험상 미리 구조를 단정 짓기보다는 개발 환경과 실제 사용 방식에 맞춰 유연하게 접근하시는 걸 추천드립니다.

참고로, 토큰 네이밍에서 예: "color-brand1-dark-bg-primary" 와 같은 방식은 일반적으로 많이 쓰이지 않습니다. 이처럼 여러 속성이 한꺼번에 섞인 네이밍 방식은 확장성과 관리 측면에서 오히려 불리할 수 있기 때문입니다.

더 권장되는 구조는 css 파일을 브랜드 단위로 분리 css/brand1, css/brand2하여 내부 토큰 명은 동일하고 참조를 달리한다던가. 미디어쿼리 또는 클래스 방식으로 처리하기도 합니다. 이 부분은 강의를 벗어나는 주제로 더 다루지는 않도록 하겠습니다.

반드시 혼자 고민하시고 개발자와 함께 고민하시기 바랍니다.