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

질문 주셔서 감사합니다. 아이콘을 관리하는 방법은 정말 다양합니다. 다른 디자인 시스템들을 찾아보셔도, 팀마다 방식이 전부 제각각일 거예요.그래서 강의에서 나온 방법을 “정답”이라고 생각하기보다는, 기본 개념과 원리를 이해한 뒤 지금 환경에 맞게 개선해 나가는 방식으로 접근하시면 좋습니다. 제가 지금 수강생 분께서 일하시는 회사에서 아이콘이 어떻게 구성되어 있는지, 또 개발 쪽에서 어떤 방식으로 관리하는지는 정확히 알 수 없지만, 일반적으로는 두 가지 방향이 있습니다. 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가 많아지고, 복잡해지면, 그것이 더 맞을 수 있다고 생각합니다. 그래서 그런 경우는 제 생각에는 개인적으로 콜랙션을 추가로 만들어, 시맨틱 단계를 넘어 컴포넌트 단계로 한층 더 만드시는 것을 추천드립니다. 그리고 컴포넌트 단계 베리어블에서 시맨틱에서 색을 가져다 쓰는 방법이 더 좋지 않을까 싶습니다. 감사합니다. 볼드 드림.

인풋 텍스트필드에서는 왜 'interactive/bg' 배리어블을 활용하지 않는 것인가요?

허이짜님 안녕하세요.말씀해주신 것처럼 강의에서 제공된 토큰(베리어블) 구조 관점에서 텍스트 필드 안에 있는 요소들은 모두 interactive 컬러를 사용하는 것이 좋습니다. 제가 작업할 때는, (말씀해주신대로) 사용자가 보았을 때 시각적으로 상태가 변하는 요소들에만 interactive 컬러를 적용했습니다. 제 텍스트 필드의 경우에는 배경색이 상태에 따라 변하지 않기 때문에 interactive 값을 따로 적용하지 않았습니다. 이런 선택을 한 이유는, 작업을 하다 보면 예외 케이스가 생기게 되고, 그때마다 값을 추가하다 보면 불필요하게 갯수가 늘어날 수 있기 때문입니다. 그래서 기본적인 기준만 두고, 나머지는 상황에 맞게 확장할 수 있도록 하였습니다. 강의에서는 이러한 기준으로 설명드렸지만, 제가 현재 회사 실무/사이드 프로젝트에서는 오히려 interactive 개념을 아예 제거하고 더 슬림하게 사용합니다. 결국에는 회사 내 디자이너·동료분들과 협업하면서 상황에 맞게 선택하시고, 강의에서 제공되는 것은 하나의 예시로 봐주시면 될 것 같습니다. 감사합니다.볼드 드림!

섹션 6 / 29.Button 강의의 아이콘 인스턴스 스왑 질문

아이콘 형태가 동일해야 된다는 의미는 두가지 조건이 반드시 충족 되어야 합니다.레이어 이름가 반드시 동일해야합니다. 현재 Shape 컴포넌트 안에 어떤 구조, 이름으로 되어 있는지는 모르겠지만, 만약 레이어 최상위 레이어 이름이 Vector라고 한다면, 다른 아이콘 컴포넌트도 반드시 동일하게 Vector라고 해야합니다.구조라 하면, 예를 들어, 최상위 레이어가 Union으로 되어 있어서 면으로 구성되어 있는지 아니면 선으로 구성되어 있는지입니다. 예를 들어, Shape는 면에 색이 적용되었다고 가정할 경우, 다른 아이콘은 선으로 구성 되어 있다면, 다른 아이콘으로 변경시에는 선의 색이 따라오게 됩니다.제공 드린 아이콘 컴포넌트에 잘 이 부분이 되어 있으니 한번 참고해보시기 바랍니다.감사합니다.만약 그래도 안되면, boldplus.ux@gmail.com으로 파일 보내주시면 제가 확인 해보고 문제상황에 대한 해결책을 더 자세히 알려드리겠습니다.

UI Kit에서 배리어블 등록 안되는 문제

연진님 안녕하세요, 우선 질문에 답변을 늦게 드린 점 죄송합니다.개인적인 건강 사정으로 인해 접속이 어려웠습니다.제가 보기에는 아래에 Bold Plus Foundation 2025가 있는 것으로 보아, 스크롤을 하시면 보일 것 같습니다. 우선 라이브러리를 등록했는지 아래처럼 꼭 체크하시고, 그렇지 않은 경우는 보이지 않습니다. (사진) 그러면 아래 화면처럼 찾으실 수 있으실 것입니다.(사진) Apply variable의 경우 등록된 라이브러리를 기준으로 만들어지기 때문에 꼭 확인 하시고, 순서대로 해주셔야 합니다. 가끔 Library 파트에 Apply variable name 같은 글자가 자동으로 생성되어 콜렉션을 찾을 수가 없는데, 이 경우 지워주시면 됩니다. (사진)또 질문 있으시면 바로 주세요. 바로 답변해드리도록 하겠습니다.

교육용 피그마 계정 문의

안녕하세요, 연진님작년까지 에듀계정이 신청 가능했는데, 작년 9월에 피그마에서 정책을 변경하여, 이 강의를 통해서 신청은 불가합니다. 저희가 운영하는 부트캠프를 통해서는 신청이 가능한데, 이또한 그 기간에서만 사용가능하며, 부트캠프 참여자만 신청가능합니다. 아직 부트캠프 운용 계획은 없지만 3~4월 상반기에 할 예정입니다. 우선은 강의 들으실 때 내보내기를 하지 마시고 동일한 파일내에서 컴포넌트, 페이지를 만드셔도 강의 따라오시는데 무리가 없습니다.

베리어블 등록했는데 스타일에 연결하려니까 안보여요..

안녕하세요, 질문 감사합니다! 베리어블 타입을 잘 보셔야 합니다. 타이포그래피에 속하는 베리어블 타입은 텍스트와 숫자입니다. Font size의 경우는 반드시 숫자여야합니다. 하지만 현재는 시맨틱 Font size는 텍스트로 설정이 되어 있고, Primitive에는 숫자 베리어블로 설정이 되어 있어서 이런 문제가 생기는 것입니다. 시맨틱 Font size를 숫자 베리어블로 바꾸시면 해결 될 것 입니다. 이는 저도 가끔 헷갈릴 때가 있긴 합니다. 그리고, 제가 알기로는 타입을 변경하는건 없는걸로 알고 있어서 새로 지우시고 다시 만드시면 될 것 같습니다. 또 안되시거나 궁금하신 부분 있으시면 질문주세요. 감사합니다.

베리어블 등록했는데 스타일에 연결하려니까 안보여요..

안녕하세요, 질문 감사합니다! 베리어블 타입을 잘 보셔야 합니다. 타이포그래피에 속하는 베리어블 타입은 텍스트와 숫자입니다. Font size의 경우는 반드시 숫자여야합니다. 하지만 현재는 시맨틱 Font size는 텍스트로 설정이 되어 있고, Primitive에는 숫자 베리어블로 설정이 되어 있어서 이런 문제가 생기는 것입니다. 시맨틱 Font size를 숫자 베리어블로 바꾸시면 해결 될 것 입니다. 이는 저도 가끔 헷갈릴 때가 있긴 합니다. 그리고, 제가 알기로는 타입을 변경하는건 없는걸로 알고 있어서 새로 지우시고 다시 만드시면 될 것 같습니다. 또 안되시거나 궁금하신 부분 있으시면 질문주세요. 감사합니다.