• None GPU와 더불어 CPU(중앙처리장치), FPGA 등 다양한 메모리 간의 고속 인터페이스를 제공하는 칩입니다. 컴퓨터 부품들 사이에 더 빠르고 효율적인 소통을 가능하게 하는 기술이며, CXL은 반도체 부품 간 데이터를 전송하는 PCle이란 기술을 기반으로 작동합니다.• None HBM 보다 제작 난이도가 낮고, HBM과 달리 GPU의 부품과도 연결이 용이해 대규모 데이터 처리 시스템 구축에 유리한 것으로 현재 평가 받고 있습니다.• None 대용량 데이터 처리가 필요한 AI 연산 시스템에 적용될 수 있으며, 여러 개의 메모리가 유기적으로 동작하게 함으로써 저장 공간 확장 및 데이터 이동 지연 시간을 줄여줍니다• None 고성능 연산이 필요한 애플리케이션에서 서로 다른 기종의 제품을 효율적으로 통신·연결할 수 있기 때문에 차세대 인터페이스 관심을 받고 있습니다.• None 보통 중앙처리장치(CPU) 1개당 사용할 수 있는 D램 모듈이 제한돼있습니다. 이를 해결하기 위해 데이터 처리량을 늘리기 위해선 CPU를 늘려야 하고 CXL를 활용하면 이들 인터페이스를 하나로 통합해 장치 간 직접 통신을 가능하게 하고 메모리를 공유할 수 있게 됩니다.• None - CXL은 기존의 데이터 전송 방식보다 훨씬 빠른 속도를 제공합니다. 이는 대규모 데이터 처리가 필요한 AI, 머신러닝, 빅데이터 분석 등에 적합합니다.• None - CXL은 여러 장치 간에 캐시 일관성을 자동으로 보장하여 불필요한 데이터 이동을 최소화하고 연산 처리 속도를 높입니다.• None - CXL은 PCIe(Peripheral Component Interconnect Express) 기반으로, 시스템의 용량과 대역폭을 쉽게 확장할 수 있습니다. 이를 통해 데이터센터 운영 효율성을 크게 높일 수 있습니다.• None - CXL은 대규모 데이터를 빠르게 처리해야 하는 고성능 컴퓨팅 환경에서 중요한 역할을 합니다. 메모리와 저장장치를 효율적으로 연결하여 운영 비용을 절감하고 지연 시간을 줄일 수 있습니다.• None - AI 가속기와 CPU를 동일한 인터페이스로 연결하여 연산 속도를 향상시키고, AI 모델 학습 및 추론 과정에서 효율성을 높입니다CXL(Compute Express Link) 기술은 메모리 공유를 지원하는 방식에서 몇 가지 중요한 기능을 제공합니다.이러한 기능들은 데이터센터와 고성능 컴퓨팅 환경에서 메모리 자원의 효율적인 활용을 가능하게 합니다.• None CXL은 여러 호스트가 동일한 물리적 메모리 풀을 공유할 수 있도록 지원합니다. 이를 통해 각 호스트는 자신의 필요에 맞게 메모리를 동적으로 할당받고 해제할 수 있습니다. 이런 방법을 통해 메모리 자원의 활용도를 극대화하고, 필요에 따라 메모리를 유연하게 사용할 수 있도록 합니다.• None CXL은 CPU와 연결된 장치 간의 캐시 일관성을 유지하여, 데이터가 여러 장치 간에 일관되게 유지될 수 있도록 합니다. 이런 방법은 데이터 이동을 줄이고 성능을 향상시키는 데 기여합니다.• None CXL 2.0 및 3.

타임머신이 있다면 어디로 가보고 싶나요?다들 고르셨나요? 오늘 미스터리 디자인 클럽에서는 ‘선택지를 고르는 화면’ 디자인에 대해 이야기해볼게요.“화면 디자인을 하다보면 사용자가 선택지를 고르는 화면을 많이 구성하게 되는데요. 때에 따라 단 하나만 선택되거나, 여러 개를 선택할 수 있는 경우가 있어요. 그럴 때, ‘하나만 선택되는 화면은 당연히 *라디오 버튼으로 디자인 해야하지 않나?’ 라는 생각이 먼저 들어요. 사용자에게 ‘디자인적 증거’를 줘야겠다는 생각이 들기 때문이에요.” - 토스 프로덕트 디자이너 A*라디오 버튼이란? 옵션을 선택할 때 사용되는 UI 컴포넌트인데요. 라디오의 물리적 버튼에서 따와 만들어진 PC UI 문법으로, 옵션 중 하나를 선택해야 할 때 PC와 모바일 모두에서 많이 이용되고 있어요.A씨를 비롯한 많은 메이커들이 토스의 모바일 디자인 시스템에 라디오 버튼 컴포넌트를 추가하자는 이야기를 꺼내곤 했어요. ‘너무 일반적인 공식이기 때문에’, ‘다른 곳에서 모두 이렇게 하기 때문에’가 그 이유였어요.그러나, 모바일에서 이 문법을 그대로 따르기엔 적합하지 않은 면이 있어요. 마우스 포인터로 버튼을 편하게 클릭할 수 있는 PC 환경에는 어울리지만, 손가락 끝으로 탭해야 하는 모바일 환경에서는 작은 원을 정확히 눌러야 할 것 같은 형태가 최선이라고 할 수 없어요. 실제로는 레이블을 눌러서 선택할 수 있다고 해도요.그럼에도, ‘디자인적 증거’를 줘야겠다는 생각에, ‘하나만 선택되는 화면은 당연히 라디오 버튼을 써야하지 않을까?’라고 많은 분들이 생각했던 거에요.여러분은 앞서 어떤 선택을 하셨나요? 그리고, 다른 사용자들은 어떻게 선택했을까요?세 가지 유형의 질문을 준비해 UT를 진행했어요.• None 유형 1️⃣: 앞서 여러분이 선택한 ‘타임머신’ 질문처럼, 서로 배타적이어서 여러 개를 선택할 수 없는 것이 있어요.• None 유형 2️⃣: ‘최근 1년간 감상한 콘텐츠를 선택하라’는 것처럼, 대부분 여러 개를 선택할 만한 질문이 해당돼요.• None 유형 3️⃣: 단일 혹은 중복 모두 선택할 수 있는 질문이 해당돼요.질문에서는 ‘모두 선택’, ‘하나만 선택’ 등 선택 개수를 안내하지 않았어요. 또한, 일반적인 공식과는 반대로, ‘하나만 선택’일 땐 체크박스, ‘중복 선택’일 땐 라디오 버튼을 주어 사용자가 어떻게 선택하는지 관찰했어요.대부분의 사용자들은 버튼의 모양과 상관 없이 질문에 따라 답을 선택했어요. 버튼의 모양과 상관 없이 유형 1에서는 하나를, 유형 2에서는 여러 개를, 그리고 유형 3에서는 선택하고 싶은 만큼 선택한 건데요.그렇게 선택한 이유가 무엇인지 물었을 때, 질문 자체에 집중해서 대답했어요. “나는 올빼미형 인간이다”, ‘”최근 1년간 영화, 드라마, 예능을 모두 봤다” 이렇게요. 유형 2나 3에서 ‘여러 개를 선택해도 되는지’ 묻는 분들이 계셨지만, 이들 또한 “질문에서 ‘중복 선택’이라는 말이 없어 헷갈린다”고 말했어요. 버튼의 모양을 언급하며 질문해도, 이 모양으로 인해 헷갈렸다고 말한 경우는 거의 없

안녕하세요. LINE Plus ABC Studio에서 일본 음식 배달 서비스 Demaecan(出前館, 이하 데마에칸)의 디자인을 담당하고 있고, 사용자의 다양한 목소리를 담을 수 있는 ABC User Feedback도 함께 만들고 있는 오관식입니다. 이번 글에서는 디자이너와 웹 프런트엔드 엔지니어 간의 디자인 리소스 관리를 일원화하기 위해 디자인 시스템을 만들어서 코드에까지 연결한 작업을 소개하고, 그 결과물을 ABC User Feedback에서 어떻게 활용하고 있는지 말씀드리고자 합니다.이 글이 특히 규모가 작은 조직이나 MVP(minimum viable product)를 빠르게 검증해야 하는 프로덕트 메이커 분들에게 도움이 되길 바라며 시작하겠습니다.디자인 시스템의 정의와 도입하기 어려운 이유디자인 시스템은 디자인 원칙과 규격, 재사용 가능한 UI 패턴과 컴포넌트, 코드 등을 전체적으로 포괄하는 집합체를 말합니다. 조직의 운영 스타일이나 방향에 따라 다르게 적용될 수 있어서 단순히 스타일 가이드나 패턴 라이브러리로서의 역할만 담당할 수도 있습니다.디자인 시스템의 주 목적은 제품을 만들 때 디자인 관점에서의 표준 규칙을 설정해 작업을 보다 효율적이고 일관적으로 수행할 수 있도록 지원하는 것입니다. 이를 통해 보다 쉽고 빠르게 프로젝트를 확장할 수 있으며 각 조직의 목표에 맞게 제품 디자인을 쉽게 조정할 수 있습니다.그동안 디자이너의 관점에서 현실적으로 디자인 시스템을 도입하기 어려웠던 이유는 아래와 같습니다.• 개발과의 단절: 개발 팀이 여럿인 경우 디자인 관점에서는 통일할 수 있지만 각 팀의 코드는 달라서 디자인 시스템을 도입해도 전체 효율은 그다지 올라가지 않는 경우가 있습니다.• 초기 설정의 어려움: 프로덕트의 방향이나 목적에 따라 필요한 사양이 달라지기 때문에 디자인 시스템 구축 시 기본 컴포넌트의 범위를 어디까지 정해야 할지 어렵습니다.• 유지 보수: 디자인 시스템에 너무 많은 컴포넌트를 포함할 경우 갱신이나 수정 시 많은 리소스가 필요합니다.이번 글에서는 위 문제 중 '개발과의 단절'과 '유지 보수' 관점에서의 어려움을 어떻게 해결했는지 살펴보고, 그 결과물인 3단계 디자인 시스템과 적용 사례를 소개하겠습니다.(디자이너 한 명과 웹 개발자 두 명으로 가능한) 디자인 시스템 개발 방향 설정디자인 시스템은 장점이 충분한 시스템이지만 리소스는 늘 한정돼 있기에 디자인 시스템 구축에는 항상 어려움이 따릅니다. 제 경우 두 명의 프런트엔드 엔지니어와 한 명의 디자이너라는 최소한의 리소스만 활용할 수 있었는데요. 이 정도의 리소스로 디자인 시스템을 만든다면 어떤 방향으로 제작하면 좋을지 고민했고, 논의 결과 최소한의 핵심 컴포넌트 위주로 빠르게 검증할 수 있는 디자인 시스템을 만들자는 결론이 나왔습니다.Figma, Storybook과 이 둘을 연계하는 토큰으로 구축하는 디자인 시스템저희는 디자인부터 개발에 이르기까지 리소스를 일관적으로 관리할 수 있도록 Figma와 Storybook을 도입한 뒤 이 둘을 연계하기 위한 토큰을 설계했습니

NeMo Guardrails는 NVIDIA가 개발한 오픈 소스 툴킷으로, 대규모 언어 모델(LLM)을 사용하는 AI 애플리케이션의 안전성과 유용성을 보장하기 위해 설계되었습니다.이 툴킷은 AI가 비윤리적이거나 유해한 콘텐츠를 생성하지 않도록 제한하며, 특정 비즈니스 규칙을 따르도록 제어할 수 있습니다.사용자는 YAML 또는 Python 파일을 통해 대화 규칙(Rails)을 정의하고, 이를 기반으로 AI 응답을 필터링하거나 수정할 수 있습니다.Amazon Bedrock에서 AI 안전 기능으로도 제공합니다.간단한 네모 가드레일 사용 방법에 대해 알아보겠습니다.Guardrails에서 사용되는 AI 모델과 작업 환경을 정의하는 데 yaml을 사용됩니다.이 파일은 Guardrails의 동작 방식을 설정하는 핵심 구성 요소로, AI 모델 유형, 엔진, 파라미터 등을 정의합니다.• Rails는 특정 시나리오에 대해 AI가 따라야 하는 규칙입니다.• Python 및 YAML 파일을 사용하여 대화 규칙을 정의합니다.• None models: Guardrails에서 사용할 AI 모델을 정의합니다. 여러 개의 모델을 지정할 수 있으며, 각 모델은 역할에 따라 구분됩니다.• None type: 주로 대화를 생성하거나 질문에 답변하는 주요 모델 정보• None engine: Guardrails가 사용할 API 또는 플랫폼을 지정합니다.• None model: 사용할 모델 이름을 지정합니다.• None parameters (선택 사항):모델의 동작을 제어하는 추가 파라미터를 정의합니다.• None temperature: 응답의 다양성을 제어 (0.0 ~ 1.0).• None app : Guardrails 애플리케이션 전반의 동작을 설정합니다.• None• None max_turns: 한 대화 세션에서의 최대 대화 턴 수.OpenAI API 기반 설정을 하려면 아래와 같이 작성합니다.Hugging Face 모델 기반 설정은 엔진에 허깅페이스를 넣어주고 허깅페이스에서 지원하는 모델을 넣습니다.• None 엔진 및 모델 이름 일치: 엔진(engine)과 모델(model)의 이름은 지원되는 플랫폼의 정확한 모델 이름이어야 합니다.• None 파라미터 설정 유효성: 사용 중인 엔진에 따라 지원되지 않는 파라미터를 지정하면 에러가 발생할 수 있습니다.• None 환경 변수 활용: API 키와 같은 민감한 정보는 코드에서 직접 설정하지 않고, 환경 변수로 설정하여 os.environ 등을 통해 사용할 수 있습니다.yaml 파일은 RailsConfig로 읽어 Guardrails 설정에 활용됩니다:yaml은 Guardrails 동작의 유연성과 확장성을 제공합니다.필요에 따라 다양한 엔진과 설정을 조합해 활용할 수 있습니다. rules.yaml 을 아래 내용을 작성합니다."죄송합니다. 폭력적인 영화 추천은 도와드릴 수 없습니다." "가족과 함께 즐길 수 있는 영화 추천: 1. Finding Nemo 2. Toy Story 3. Coco" replace_response "죄송합니다

안녕하세요! 현대자동차그룹의 현대로템 전기전자시스템팀에서 전차의 전장품을 개발하고 있는 송혜진 책임연구원입니다.지난 시간에는 NGVA 표준의 2장, 전원 및 하부시스템이 연결되는 전력 인터페이스에 대한 이야기를 나눠봤습니다. 전력의 설계를 일정하게 유지하고, 연결된 커넥터나 하부 시스템을 동일하게 유지할 수 있는 내용이었죠.오늘은 3장, 데이터 연동에 대한 내용을 알아보겠습니다.1) NGVA 3장: 데이터 연동3장은 NGVA의 데이터를 형성하는 인터페이스 및 프로토콜에 대한 설계 제약에 대해 정의하고 있습니다. 케이블, 플러그, 데이터 교환 및 미들웨어까지의 패킷 레이어 및 데이터 네트워크로 구성되어있습니다. 구성은 아래와 같습니다.-1개 이상의 LAN-QoS(Quality of Service, 적합한 서비스 품질)을 갖춘 유선 프로토콜과 NGVA 데이터 모델-네트워크 서비스, 물리적 인터페이스-오디오 및 비디오 스트리밍 데이터 및 제어 프로토콜, 디지털 음성 유형별 제어 및 코덱-레거시 시스템(기존 전장품)은 필요시 게이트웨이를 통해 설계 적용 (ex.데이터 컨버터, 영상 컨버터)NGVA 시스템을 적용하기 위해서는 체계 내 연동되는 데이터의 성격을 분류하고, 그에 따른 데이터 버스를 구축합니다. 대표적인 예로 데이터는 영상&오디오 데이터, 제어 데이터, 세이프티 데이터, 시큐어 데이터 등으로 나누어서 각각에 대한 데이터 버스를 각각 구축합니다. 이처럼 데이터 버스를 분리하는 이유는 영상&오디오 데이터나 기타 데이터 들의 트래픽을 분리하기 위해서입니다. 또한 NGVA 시스템을 적용한다고 해도 모든 하위 전장품이 그 표준을 따를 수는 없기 때문에 NGVA 미적용 전장품들은 아래 그림의 Internal Gateways를 구성하여 이더넷 프로토콜로 바꾼 후, 이더넷 버스에 올리게 됩니다.그림1. NGVA 적용 데이터 버스 예시2) 데이터 버스 분리NGVA를 적용하기 전에는 카메라 영상 데이터를 예를 들면 직접적으로 카메라와 연결된 전시기에서만 볼 수 있었지만 NGVA 표준을 적용하면 영상&음성 버스에 올라간 데이터 들은, 버스와 연결된 다른 전시기에서도 똑같은 데이터를 볼 수 있게 됩니다.특히나 전투체계에서 카메라가 점점 발달하고 있는 지금, 영상 데이터용 데이터 버스는 360도 상황인식 시스템 등 영상 기반의 대용량 데이터를 공유하기 위해서 필요하게 됩니다. 또한 보안이 필요한 데이터도 특히 중요해져서 보안 데이터를 위한 별도의 버스를 추가로 구성하여 네트워크를 이중화할 수도 있습니다. 데이터는 각기 다른 네트워크를 사용하거나 VLAN(Virtual Local Area Nwtwork,가상랜)을 사용하여 실시간 데이터와 비실시간 데이터를 분리할 수도 있습니다. 많은 양의 실시간 데이터를 위해서 네트워크를 분리한다고 생각하시면 이해가 쉬울까요?3) 기존 장비와의 연동 방안위에서 설명 드렸던 Internal Gateways는 개방형 시스템 아키텍처를 처음 도입하는 체계에서 매우 중요한 요소입니다. 개방형 시스템 아키텍처를 적용한다고 해서 모든 장비를 동시에 한꺼번에 교체하는 일은 매우 어렵습니다. 모두 동일한 프로토콜이나 인터페이스를 맞추어 제작한다면 좋겠지만, 그 일은 기존 장비를 대체하는 데에 시간이 매우 많이 걸릴뿐만 아니라 개발 리스크도 굉장히 크게 증가합니다.그래서  Internal Gateways, 일명 데이터 변환 장치라는 제품을 구축하게 됩니다. 1)에서 설명했던 구성 중 마지막에 따라 레거시 시스템(기존 전장품)은 필요시 게이트웨이를 통해 설계 적용 (ex.데이터 컨버터, 영상 컨버터)을 하게 됩니다. 기존에 있는 데이터를 주고받을 수도 있고, 새롭게 추가된 전장품의 데이터를 저장하고 보내주는 심장같은 역할을 하죠. 기존 중앙컴퓨터에 집중되어 있던 데이터를 분산 처리하는 역할도 하며, NGVA 표준을 적용하기 위한 DDS(Data Distribution Service) 미들웨어 사용에 필요한 이더넷 규격 이외의 통신을 수행하는 장비의 데이터를 실시간으로 수집하고 가공하여 데이터 버스 전체에 공유될 수 있도록 합니다. DDS가 무엇인지에 대해서는 다음 시간에 조금 더 살펴보도록 하겠습니다.[출처]지상무기체계 성능개량을 위한 개방형 시스템 아키텍처 및 데이터 모델 설계, 한동휘 외, 한국정보기술학회논문NATO Generic Vehicle Architecture NATO Generic Vehicle Architecture (natogva.org)Generic Vehicle Architecture (GVA)-Generic Vehicle Architecture (GVA) - Think Defence

글. 김지영(Terna) / Platform Design Team Lead부제. 디자인 시스템 운영의 명암디자인 시스템이 없던 시절로 돌아간다고 생각해보세요. 그때는 대체 어떻게 그 많은 반복 작업을 해냈을까요? 가끔 피그마 라이브러리가 사라지는 상상을 하면 정말 아찔해지곤 해요. 그만큼 지금은 디자인 시스템이 없어서는 안 될 존재가 됐죠. 요즘은 대부분의 서비스가 일관성과 효율성을 위해 디자인 시스템을 구축하고 운영하고 있는데, 여기어때 역시 ‘YDS(Yeogi Design System)’라는 이름으로 자체 디자인 시스템을 운영하고 있어요.저는 23년 하반기부터 YDS를 맡아 운영하게 되었는데요, 그 과정에서 새로운 비효율을 마주하게 됐고, 이를 개선하기 위해 다양한 시도를 하게 되었어요. 이번 글에서는 비효율을 발견했던 과정과, 그걸 개선해나간 경험을 나눠보려 합니다.디자인 시스템 = 새로운 프로덕트제가 YDS 업무를 맡았을 때, 여기어때는 이미 앱 내 UI 패턴을 기반으로 한 피그마 라이브러리가 있었고, 본격적으로 컴포넌트도 개발 중이었어요.완전한 무에서 시작하는 건 아니어서 다행이었지만, 애매한 시점에 인볼브된 것 같다는 생각이 들더라고요. 단순히 개발 대응을 넘어 YDS에 어떤 기여를 할 수 있을지 고민이 많았죠.지금 돌아보면 그런 고민이 생긴 이유는 제가 디자인 시스템을 그저 구조적이고 일관된 UI 라이브러리로만 봤기 때문인 것 같아요. ‘컴포넌트를 잘 만들면 당연히 잘 쓰이겠지’라고 단순하게 생각했던 거죠. 물론, 그게 디자인 시스템에 핵심인 건 맞지만, 한 달 동안 초심자의 마음으로 기존 가이드랑 컴포넌트를 뜯어보고, UX Designerr와 개발자의 문의에 대응하면서 그게 전부는 아니라는 걸 깨달았어요.컴포넌트를 잘 만들어도 효율적으로 쓰이는 것은 완전히 다른 문제더라구요. 결국, 초기 라이브러리 구축 이후의 디자인 시스템은 단순히 리소스를 모아놓은 게 아니라 하나의 새로운 프로덕트가 된다는 결론에 다다르게 됐어요.효율 속의 비효율효율성을 높이고자 만든 디자인 시스템인데 정작 운영하는 과정에 많은 비효율이 존재했는데요. 그 중에서도 당장 해결이 필요하다 느껴지는 부분은 크게 네 가지였어요.1. 버전 추척의 어려움당시 피그마 라이브러리는 계속 업데이트되고 있었지만, 개발은 버전 단위로 업데이트되는게 아니라 필요한 컴포넌트를 그때그때 피처 단위로 개발하는 방식이었어요. 문제는 이렇게 하다 보니 실제 개발된 컴포넌트가 피그마 라이브러리의 어떤 버전에 해당하는지 알 수 있는 방법이 없었어요.그렇다 보니 피그마 라이브러리를 수정할 때마다 개발팀에 넘겨야할 체인지로그를 정리하기가 애매했어요. 일부 스펙이 누락되거나 피그마와 싱크가 안 맞아도 바로 앱에 적용되지 않으니 쉽게 드러나지 않았고요. 개발이 완료됐다는 상태값은 있었지만, 그걸 보고도 이 컴포넌트가 정말 제대로 만들어졌는지 퀄리티를 보장할 수 없는 상황이었죠.2. A/B 테스트와 실험 UI 관리의 문제A/B 테스트로 프로덕트를 고도화하는 조직 특성상, 실험안을 만들 때 피그마