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

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

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를 숫자 베리어블로 바꾸시면 해결 될 것 입니다. 이는 저도 가끔 헷갈릴 때가 있긴 합니다. 그리고, 제가 알기로는 타입을 변경하는건 없는걸로 알고 있어서 새로 지우시고 다시 만드시면 될 것 같습니다. 또 안되시거나 궁금하신 부분 있으시면 질문주세요. 감사합니다.

폰트 웨이트 지정에서, '바디만 따로 웨이트를 시멘틱에 그룹핑 하는 이유'가 무엇인가요??

안녕하세요, 허이짜님 🙂질문 주신 “바디만 따로 웨이트를 시맨틱에서 그룹핑한 이유”는 말씀해주신 부분이 맞습니다. 조금 더 설명드리면, 이유는 크게 두 가지입니다. 1) 바디는 실제로 사용하는 웨이트 종류가 여러 개(N개)바디 텍스트는 상황에 따라 Regular / Medium / Semibold처럼 여러 웨이트를 사용합니다. 그래서 “바디”라는 카테고리 안에서 스타일이나 컴포넌트가 끌어다 쓸 수 있도록 바디 전용 웨이트 토큰이 N개가 필요합니다.(이 때 이걸 Primitive에서 가져옵니다.)즉, 바디는 ‘하나의 타입’이 아니라 ‘여러 변형 웨이트를 가진 타입’이라서, 별도로 웨이트를 그룹핑해두는 것이 유지보수/사용성 면에서 가장 합리적입니다. 2) 강의/피그마 구조상 “스타일”과 “시맨틱 타이포 베리어블”이 사실상 같은 역할 수행강의에서 사용하는 구조는 개념적으로 실질적으로 같은 목적이라고 보셔도 됩니다.스타일 = 시맨틱 토큰(복합 토큰)다만 피그마에서는 기존에 텍스트 스타일이라는 별도의 기능이 이미 존재했고, Variables는 나중에 생긴 기능이라 둘이 “완전히 동일하게” 동작하지는 않습니다. 그래서 실무에서 흔히 하듯이 스타일과 시맨틱 토큰을 같은 구조로 유지하면서도 베리어블에서 모드 전환(예: 다크모드/브랜드 변경)에서도 잘 동작하도록 설계해둔 겁니다.정리하자면:✅바디는 웨이트가 여러 개라 N개의 토큰이 필요했고✅스타일과 시맨틱을 사실상 같은 구조로 운영하려다 보니✅바디 웨이트를 따로 그룹핑하는 방식이 가장 효율적이었다라고 이해하시면 됩니다. 좋은 질문 주셔서 감사합니다 🙂