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 테스트로 프로덕트를 고도화하는 조직 특성상, 실험안을 만들 때 피그마

이번 토스 피플에서는 쇼핑 탭을 맡고 있는 이혜인님의 인터뷰를 공유드려요. 토스는 금융 앱이기도 하지만 다양한 혜택 기능들로 ‘앱테크’로서 사랑을 받고 있기도 한데요. 받은 혜택으로 할인을 받아 구매하기도 하고, 혜택 구조를 활용해서 제휴사와 협의해 좋은 물건을 저렴하게 판매하고, 토스 밖에서도 토스 페이를 쓰고 있죠. 토스 쇼핑은 토스의 세계관을 완성하는 일이라고 할 수 있어요.혜인님은 원래 디자인을 전공하진 않으셨다고 들었어요. 어쩌다 UX 디자인을 시작하게 되신 거예요?처음에는 공대에 다니다가 나중에 미대에 들어갔어요. 제 전공은 제품 디자인이었는데, 일찍 재능이 없다는 걸 알았어요. 고등학교 때, 한창 뇌가 말랑말랑할 때부터 미술을 공부한 친구들을 절대 못 따라 잡겠는 거예요. 저는 계속 현실적인 얘기를 하는데, 그 친구들은 되게 열린 사고를 하는 거죠. 막 하늘을 날아다니는 자동차 얘기를 하는 동안 저는… (웃음)그러다 우연히 UX 수업을 듣게 됐는데, 그게 저한테는 너무 쉬운 거예요. ‘어떻게 그렇게 쉽게 화면을 그려?’하고 같은 수업 듣는 친구가 물어봐서 ‘어, 내가 이건 잘하나?’ 생각하게 됐어요. 재능 발견 이런 느낌.그렇게 처음으로 UX 디자이너로 입사하게 되신 거군요.맞아요. 2013년도 쯤? 휴학하고 스타트업에 취업했었어요. 그런데 학교에서 와이어프레임 만드는 건 쉬웠는데, 아름다운 화면을 만드는 건 또 다른 문제더라고요. 당시엔 스큐어모피즘이 대세였는데, 화면 위에서 실제 물체와 유사한 디테일과 텍스쳐를 재현해야 했거든요. 원하는 디자인을 만들고 싶으면 그래픽을 잘하는 것도 중요했지만 그걸 어떻게 구현할지에 대한 이해도 필요했었어요.그래서 개발을 배우는 프로그램에 참여했었어요. 거기서 또 재능이 없다는 걸 깨달았어요. 프로그램의 목표는 풀스택 개발자로 양성하는 거였는데, ‘나는 개발 짱 못해.’하면서 프론트 엔드까지만 배우고 나왔어요. 그런데 그게 두고두고 도움이 되더라고요. 화면이 그려지는 동작 방식을 이해하니까 개발자 분들과 협업하면서 가이드를 드릴 때 효과적으로 드릴 수 있게 됐어요. 예전에는 그림 그리듯이 화면을 드렸거든요.와, 졸업하기도 전인데 정말 많은 경험을 하셨었네요.그렇게 졸업하고서 취업 준비를 하는데… 다 떨어지는 거예요. 좋은 UX를 하는 회사가 없기도 했어요. 디자이너가 갈 수 있는 회사가 카카오, 네이버, 삼성 디자인 멤버십 정도가 전부였던 것 같아요. 대기업도 넣어봤는데 다 떨어졌고요. 그러다 쿠팡에서 경력직을 채용하고 있었는데, 스타트업 다녔을 때의 포트폴리오로 입사하게 됐어요. 회사에서도 베팅으로 주니어를 한 번 채용해볼까?해서 운좋게 들어가게 된 것 같아요.거기서 오래 근무하시기도 했고, 그때의 경험이 지금 제품에도 영향을 끼치고 있는 것 같아요.맞아요. 당시 엄청 가고 싶은 회사 중 하나였어요. 그래서 만족도가 급상승했었죠. 데이터를 중요하게 생각하는 회사였는데, 지금 생각해보면 데이터로 일하는 환경이 쉽게 주어지는 게 아니었더라고요. 아름다운 화면을 추구하는 건 아니었지만 사용자

광고추천 조직에서 타게팅 광고 서빙 시스템을 담당하고 있는 에이든입니다.안녕하세요. 카카오 광고추천팀에서 광고 추천 개발 업무를 담당하고 있는 aiden.song입니다. 이번 글은 ingress nginx controller의 대용량 트래픽 환경에서의 병목 현상 분석의 두 번째 글로 1부에서 문제 발생의 배경과 ingress-nginx-controller의 구조적인 측면에서 발생했던 원인에 대해 파악 했다면, 2부에서는 controller에서 병목이 발생한 근본적인 원인을 찾는 과정과 이를 해결하는 방법에 대해 정리해보겠습니다.본론에 들어가기에 앞서 본 글은 golang과 kubernetes 그리고 prometheus에 대한 기본적인 이해가 필요합니다. golang은 자체적인 문법이 간단해서 초보자가 코드를 봐도 이해하기 어렵지 않으나 kubernetes와 prometheus에 대해서는 사용해본 경험이 있는 수준의 배경 지식이 있어야 본론을 이해하기 수월합니다. 각 기술셋에 대한 자세한 내용을 모두 설명하기는 어려우나 설명 중간중간에 최대한 이해를 도울 수 있게 설명을 해보도록 해보겠습니다.1부에서 간단하게 설명했던 Ingress Nginx Controller(이하 IC)에 대해 조금 더 설명을 해보겠습니다. IC는 kubernetes에서 Pod 형태로 실행됩니다. IC Pod 내부에는 크게 세 종류의 프로세스가 실행되며 IC, Nginx master, Nginx worker가 이에 해당합니다. 이 세 종류의 프로세스는 Pod의 리소스를 공유합니다. 이런 구조 때문에 Nginx Master나 Worker 프로세스 뿐만 아니라 IC 프로세스 메모리 사용량이 늘어나게 되면 IC Pod의 메모리 사용량이 증가하게됩니다. 마지막으로 IC 프로세스의 주요 역할은 아래와 같습니다• Nginx의 master, worker 프로세스를 실행하고 관리• kubernetes 리소스로 관리되는 Nginx 관련 설정들을 Nginx 프로세스와 동기화이번 트러블 슈팅 과정에서 중심적으로 살펴볼 IC 프로세스의 동작은 마지막 항목인 메트릭 수집 부분입니다.1부에서 nginx worker가 생성하는 메트릭들을 소켓 통신을 통해 IC 프로세스로 전달되고, 이 메트릭들을 처리하는 과정에서 병목이 발생할것으로 추정하며 마무리 했었습니다. 이번에는 해당 추정이 맞았는지 확인하는 과정, 그리고 병목 현상을 해결하는 방법을 찾는 과정을 자세히 정리해보겠습니다.go는 자체적으로 프로세스를 진단할 수 있는 프로파일 기능을 풍부하게 지원하고 있고 간단한 설정 및 CLI을 활용해 모니터링이 가능합니다. 관련해서 프로파일 설정 및 자세한 활용 방법에 대해서는 카카오 테크 블로그의 “Golang GC 튜닝 가이드 포스트”(https://tech.kakao.com/posts/618)를 참고하시면 좋습니다. 앞서 안에 고루틴 영역을 병목지점으로 추정했으니, 실제로 해당 지점에 병목이 있는지를 goroutin 프로파일을 통해서 확인해 봤습니다.goroutine 프로파일에서 가장 많은(4309개

안녕하세요 광고추천 조직에서 타게팅 광고 서빙 시스템을 당당하고 있는 푸입니다.안녕하세요. 카카오 광고 추천팀에서 광고 추천 개발 업무를 담당하는 pooh.duck입니다. 이 글에서는 Ingress Nginx Controller에서 발생한 Prometheus metric 병목 현상에 대한 원인 분석과 해결 방법을 소개합니다. 본 글은 1부와 2부로 구성되어 있으며, 실무에서 Trouble Shooting을 어떻게 하는지, Ingress Nginx Controller, Go 프로파일링에 관한 내용을 담고 있습니다. 1부에서는 문제 발생의 배경과 원인 분석 과정을 상세히 설명하고, 2부에서는 이를 바탕으로 한 해결 방법을 소개합니다. 단계별로 우리 팀이 겪었던 실제 사례와 적용했던 방법들을 공유하며, 비슷한 문제를 겪고 있는 다른 분들께 도움이 되기를 기대합니다.우리는 웹사이트를 방문할 때마다 다양한 광고를 접하게 됩니다. 이러한 광고가 사용자에게 노출되기까지 여러 카카오 광고 API 서버들이 상호작용을 하게 되고, 이에 따라 대부분의 광고 API 서버들은 평균적으로 매우 높은 트래픽을 받게 됩니다. 제가 담당하는 API 서버 중 하나는 피크 시간대에 최대 약 16만 req/sec의 요청을 처리하고 있습니다.대용량 트래픽을 처리하기 위해서, 저희 API 서버는 Kubernetes 위에서 다수 Pod를 실행 중입니다. 이 서버들에 HTTP(S) 트래픽을 라우팅하기 위해 Ingress를 사용하고 있으며, 구현체로는 가장 범용적으로 사용되는 Ingress Nginx Controller를 채택하고 있습니다.현재 저희는 재해 복구(Disaster Recovery)와 부하 분산을 위해 두 개의 Region에 걸쳐 다수의 Ingress Nginx Controller를 구성해 운영하고 있습니다.저희는 서비스 모니터링을 위해 서버에서 발생하는 Metric들을 Prometheus로 수집하고, Grafana를 통해 모니터링하고 있습니다. 그러던 어느 날 모든 Nginx 'request volume’이 No Data라는 알람이 발생했습니다. 또한, 간헐적으로 기록되는 Metric도 정상치에 비해 매우 낮게 기록되는 것을 확인할 수 있었습니다.Request Volume은 Nginx의 Prometheus Metric 중 하나로, 현재 Nginx가 처리하는 Request Count를 뜻합니다. 이 값이 Null이라는 것은 현재 Nginx 자체에 문제가 발생해 트래픽을 제대로 처리하지 못하고 있거나, Nginx가 처리하는 요청에 대한 metric이 정상적으로 수집되지 않는 상태임을 뜻합니다. 이에, 서비스를 점검해 보니 서버는 요청을 정상적으로 처리하고 있었습니다. 만약 Nginx에 문제가 생겼다면 이는 불가능한 일입니다.이러한 현상은 트래픽이 일정 기준치를 상회하면 재현된다는 것을 확인할 수 있었습니다. 아래와 그래프와 같이 Metric이 요동치다, Metric이 유실되고 이후 트래픽이 감소하면 Metric이 복구되는 것을 관찰할 수 있었습니다. 아래 그래프는 Ing