variables 이름 지을때 소문자,대문자 사용에 관해..

안녕하세요, 한별님. 타이포그래피 베리어블의 Name 값은 대소문자를 구분하지 않습니다.제가 강의를 촬영하던 시점에는 Value의 경우 대소문자에 영향을 받는 부분이 있었습니다. 예를 들어, 폰트 패밀리 Roboto에 Semi bold가 있다면 정확한 표기와 맞춰주어야 했습니다.하지만 현재 확인해보니 다음과 같이 작성해도 모두 정상적으로 인식됩니다:SemiboldSemiBoldsemiBoldsemibold 또한 붙여 쓰거나 띄어 쓰는 방식, 대소문자 차이와 관계없이 모두 인식되기 때문에 크게 문제는 없습니다. 다만 일반적으로 property를 작성할 때는 camelCase 방식을 많이 사용합니다. 반면, 이후에 배우실 컴포넌트의 경우에는 첫 글자를 대문자로 시작하는 방식(PascalCase)를 사용합니다. 회사마다 컨벤션은 조금씩 다르지만, _(언더스코어)를 사용하는 경우는 개인적으로 많이 보지는 못했습니다. Value의 경우에도 피그마에서 대문자로 작성하더라도 코드 단계에서 변경이 가능하기 때문에, 이 부분은 개발자와 협의하여 정하시는 것이 가장 좋습니다.마지막으로 이름이 길어질 경우에는 가독성을 위해 camelCase 대신 -(하이픈)을 사용하는 사례도 있습니다. 도움이 되었길 바랍니다 😊

예제 파일이 다릅니다.

RooRoo님 안녕하세요, 우선 불편을 끼쳐 드려 죄송합니다. 예제 파일은 강의 내용과 최대한 동일하게 맞춰서 제공해드리려고 했습니다. 혹시 빠진 부분이 있다면 말씀해주시면 바로 추가하도록 하겠습니다. 또한 이와 관련해 어려운 점이 있으시면 1:1로 도와드리겠습니다.boldplus.ux@gmail.com 으로 이메일 주시면 확인 후 도움드리겠습니다. 감사합니다.

시작 파일

안녕하세요, RooRoo님 네 말씀해주신대로, 예제파일을 열어서 실행하시면 됩니다. import로 파일을 불러서 시작하시면 됩니다. 피그마가 처음이시면 제 이메일로 따로 연락주시면 제가 1:1으로 자세하게 알려드리도록 하겠습니다. 궁금하신 부분도 다 알려주시면 제가 도와드리도록 하겠습니다. 감사합니다.

여러 요소들 하나의 프레임으로 묶기

강노님 안녕하세요, 아래 인프런 인턴이 말해준 것처럼 Option + Command + G가 맞습니다. 해당 부분은 영상 자막과 녹음을 새로 수정하도록 하겠습니다. 알려주셔서 정말 감사합니다. 안 되시는 부분은 제가 보기에 이미지가 그리드 안에서 확장되지 않는 문제인 것 같습니다. 아마 그리드가 Hug로 설정되어 있어서 그런 것으로 보입니다. Hug로 설정되어 있으면, 프레임이 늘어나더라도 내부 콘텐츠 크기만큼만 따라오기 때문에 원하는 방식으로 확장이 되지 않습니다. 이 경우에는 아래의 이미지처럼 Open grid settings를 눌러서 각 컬럼을 Fill 또는 Fixed로 변경해 주세요. 그렇게 설정하면 그리드가 고정되고, 내부 콘텐츠가 자연스럽게 자석처럼 붙으면서 함께 늘어날 것입니다. 궁금하신 부분은 언제든지 질문 주세요.(사진)(사진)

디자인 시스템 네이밍 순서에 대해 질문남깁니다!

안녕하세요, gusdyd20님. 네이밍 순서에는 정답이 없습니다. 그리고 굳이 외우려고 하지 않으셔도 됩니다. 예를 들어 primary는 어떤 시스템에서는 variant로 정의되기도 하고, 다른 곳에서는 type으로 정의되기도 합니다. 결국 중요한 것은 용어 자체가 아니라, 그 팀이나 시스템 안에서 어떻게 정의하고 구조화했는지입니다. 사실 variant와 type도 완전히 다른 개념이라기보다, 상위 카테고리를 구분하기 위한 구조적 레이어라고 이해하시면 됩니다. 용어가 다를 뿐, 역할은 비슷한 경우가 많습니다. 따라서 네이밍을 외우는 것보다,각 레이어의 정의가 명확한지,같은 체계 안에서 일관되게 사용되고 있는지이 두 가지를 더 중요하게 보시면 됩니다. 이와 관련된 원문 글이 매우 디테일하게 설명되어 있으니, 한글로 번역해서 천천히 읽어보시면 구조를 이해하는 데 큰 도움이 될 것입니다.

이미지 캐러셀 영상

안녕하세요, 제가 편집하는 과정에서 중요한 단어를 빠뜨린 것 같습니다. 강의에서 말씀드린 내용은 Shift 키를 누른 상태에서 키보드 오른쪽 방향키(→)를 두 번 누르라는 의미였습니다. 방향키 관련 표현이 편집 중에 누락된 것 같아요. 이렇게 누르면 저의 경우는 한 번에 8px씩 이동합니다. 만약 다른 값으로 움직이고 싶으시면 피그마 아이콘을 누르시고 Preferences → Nudge amount로 들어가서 Big nudge 값을 원하는 숫자로 변경하시면 됩니다. 감사합니다.

아이콘 사이즈 컴포넌트 구성 방식 관련

질문 주셔서 감사합니다. 아이콘을 관리하는 방법은 정말 다양합니다. 다른 디자인 시스템들을 찾아보셔도, 팀마다 방식이 전부 제각각일 거예요.그래서 강의에서 나온 방법을 “정답”이라고 생각하기보다는, 기본 개념과 원리를 이해한 뒤 지금 환경에 맞게 개선해 나가는 방식으로 접근하시면 좋습니다. 제가 지금 수강생 분께서 일하시는 회사에서 아이콘이 어떻게 구성되어 있는지, 또 개발 쪽에서 어떤 방식으로 관리하는지는 정확히 알 수 없지만, 일반적으로는 두 가지 방향이 있습니다. 1) 아이콘을 사이즈별로 따로 관리하는 방식아이콘을 16px, 20px, 24px처럼 사이즈별로 별도 파일/컴포넌트로 관리하는 시스템도 있습니다.개인적으로는 관리 비용이 커져서 선호하진 않지만, 만약 사이즈가 작아질수록 픽셀 단위로 더 정교하게 굵기나 디테일을 조정해야 한다면(예: 16px에서 선이 뭉개지는 문제), 이 방식이 더 안전할 수 있습니다.그런 경우에는 사이즈별 아이콘을 따로 만드는 게 맞는 선택입니다. 2) 강의에서 제안한 방식(더미 아이콘 + 기준 아이콘)강의에서 제안한 방식은, 예를 들어 기준 아이콘을 24px로 만든다고 가정했을 때:더미 아이콘(여러 사이즈용)을 먼저 만들고실제 개별 아이콘은 24px 기준으로 제작한 뒤더미 아이콘 안에서 실제 아이콘을 “교체”하는 방식입니다. 이 방식이 잘 동작하려면, 개별 아이콘이 아래처럼 정의되어 있어야 합니다:Constraints가 상/하/좌/우 Scale내부가 면(Shape) 으로 되어 있음레이어 이름이 동일하게 유지됨 이 조건이 맞으면, 더미 아이콘에서 개별 아이콘으로 교체해도 더미 아이콘의 사이즈에 맞춰 자연스럽게 리사이즈됩니다. 3) 이 개념을 응용하면: 아이콘 컴포넌트 + 사이즈 Variant같은 원리를 활용해서:아이콘을 하나의 아이콘 컴포넌트로 만들고16/20/24/32 같은 사이즈 Variant를 만든 다음내부 더미 아이콘만 교체해도결과물을 동일하게 만들 수 있습니다. 다만 2번째, 3번째 방식의 한계도 있습니다. 이 방법의 한계는 “선 두께”처럼 단순 배수 확대가 항상 정답이 아닐 때 생깁니다. 예를 들어, 24px에서 stroke가 1.5px이면 48px로 키웠을 때 자동으로 3px처럼 “배수”로 늘어날 수 있는데, 만약 내가 48px에서는 3px이 아니라 4px로 조정하고 싶다면, 이 자동 스케일 방식만으로는 해결이 어렵습니다. 그럴 때는 결국 앞에서 말한 것처럼 사이즈별로 아이콘을 따로 만들어 관리(첫번째 방식)해야 더 정확하게 컨트롤할 수 있습니다. 궁금하시면 더 질문 주세요.

완강/리뷰 이벤트 후 강의자료

이벤트란에도 언급드렸듯이 제출하셨다고 제가 바로 보내드릴 수는 없습니다. ㅠ 정해진 주기에 일괄적으로 보내드리는데, 몇일 전에 수강생분께 이메일로 보내드렸습니다. 확인해보시고, 받지 못했다면, 여기에 글 남겨주시기 바랍니다.정말 감사합니다!

Stack 컴포넌트 관련하여 궁금한 점이 있습니다.

안녕하세요, 허이짜님.제가 생각하는 Stack 컴포넌트의 실용성은 “여러 화면에서 동일한 간격을 유지한다”를 넘어, 반복되는 배치 패턴을 규칙으로 고정해서 디자인/개발 모두의 결정 비용을 줄여주는 것에 더 가깝다고 생각합니다. Stack이 간격 외에 줄 수 있는 장점을 예로 들자면..버튼 스택의 경우, 간격(spacing)만 통일하는 게 아니라 아래 같은 것들이 같이 정리될 수 있어요.방향: 가로/세로, 또는 모바일에서 세로로 자동 전환 등정렬: 왼쪽 정렬 / 오른쪽 정렬 / 양쪽 끝 정렬(space-between)레이아웃: 버튼이 콘텐츠만큼(Hug)인지, 부모 폭을 꽉 채우는(Fill)인지우선순위 패턴: 주요 버튼이 오른쪽에 오는지, 양쪽에 나뉘는지 등 즉 Stack은 “간격 컴포넌트”라기보다, 자주 쓰는 조합을 ‘하나의 레이아웃 규칙’으로 묶는 도구로 보는 편이 더 맞는 것 같습니다. “간격 토큰만 쓰면 Stack 활용도가 떨어지지 않나?”에 대한 생각에 대해서는버튼 간격을 토큰화해서 모두가 그 토큰만 쓰게 된다면, ‘간격을 통일하는 목적’만 놓고 보면 Stack의 이점이 줄어드는 건 맞아요.다만 Stack의 장점은 간격 하나가 아니라, 앞에서 언급했드이 간격 + 방향 + 정렬 + 폭 정책 같은 레이아웃 결정을 한 번에 묶어서 화면마다 “이거는 gap 8일까 12일까 / fill일까 hug일까 / 오른쪽 정렬일까?” 같은 고민을 줄이는 데 있어요.그래서 토큰이 잘 되어 있어도 Stack은 여전히 의미가 있고, 오히려 “토큰을 올바르게 쓰게 만드는 안전장치” 역할도 할 수 있다고 생각합니다. “2개 → 3개 → 10개 → 20개로 늘어나서 Stack이 애매해지는 이 부분은 저도 공감합니다. 그래서 저는 Stack을 ‘무한 확장 가능한 만능 컨테이너’로 설계하기보다는, 용도가 명확한 Stack을 따로 두는 방식을 선호해요. 예를 들어:ButtonStack: 보통 1~3개(많아도 4개) 정도를 전제로 한 패턴MenuList / DropdownList: 10개, 20개 이상 늘어날 수 있는 리스트 전용 패턴특히 드롭다운처럼 항목 수가 무한대로 늘어나는 케이스는, 말씀하신 것처럼 “스택 갯수 예시를 전부 UI로 다 보여주기”보다 보이는 영역은 최대 높이/표시 개수를 제한하고(스크롤), 나머지는 예시 데이터로 채우는 형태를 원칙으로 추천드립니다.예: 국제 전화번호처럼 리스트가 길 경우UI 예시는 “열었을 때 최대 N개가 보이고 스크롤 된다”까지만 보여주면 충분하고나머지 값은 엑셀/데이터/개발 라이브러리에서 가져다 쓰는 구조가 더 현실적입니다.질문 하신 부분에 대한 것은 정답은 없지만, 저의 생각을 정리해서 답변드립니다. 생각을 정리할 시간이 필요해서 다소 답변이 늦은 점 죄송합니다. 좋은 질문 주셔서 정말 감사합니다.

컴포넌트별 베리어블 구축

허이짜님 안녕하세요.말씀해주신 방향이 맞는 것 같습니다. 회사 프로덕트/서비스에 따르겠지만 결국 제품이 커지고, 다양한 UI가 생기다보면, 시맨틱 베리어블에 맞지 않는 것이 나오게 됩니다. 그때마다 새로 추가하거나 만들어진 규칙을 어긋내면서 하다보면 결국 일관성이 떨어지거나 일관성은 있는데 모두 주요색으로 뒤덮혀 있어서, 반복적인 지루한 UI가 만들어질 수 있습니다. 실제로 몇몇 회사 토큰 구조에서는 시맨틱을 넘어 컴포넌트 Level로 올라갑니다. 저도 서비스가 커지고, UI가 많아지고, 복잡해지면, 그것이 더 맞을 수 있다고 생각합니다. 그래서 그런 경우는 제 생각에는 개인적으로 콜랙션을 추가로 만들어, 시맨틱 단계를 넘어 컴포넌트 단계로 한층 더 만드시는 것을 추천드립니다. 그리고 컴포넌트 단계 베리어블에서 시맨틱에서 색을 가져다 쓰는 방법이 더 좋지 않을까 싶습니다. 감사합니다. 볼드 드림.