멀티암드 밴딧(Multi-Armed Bandit, MAB)은 확률론과 기계 학습(강화 학습)에서 제한된 리소스를 여러 대안(선택지)에 어떻게 최적으로 배분할 것인가를 다루는 고전적인 문제 프레임워크입니다. [1] 이름은 카지노의 여러 대의 슬롯머신(한 팔 강도라 불리는 One-Armed Bandit에서 유래) 앞에 선 도박꾼의 상황에서 따왔습니다. 각 슬롯머신의 보상 확률(수익률)을 모르는 상태에서, 도박꾼은 제한된 횟수 동안 어떤 머신을 어떤 순서로 당겨야 누적 보상을 최대화할 수 있을지 결정해야 합니다. [1, 2, 3] ⚖️ 핵심 딜레마: 탐색(Exploration) vs 활용(Exploitation) MAB의 핵심은 탐색과 활용의 균형(Trade-off)을 잡는 것입니다. [1, 4] 탐색(Exploration): 각 선택지의 실제 보상 확률을 알아내기 위해, 아직 잘 모르는 다양한 대안을 시도해보는 것. [2, 4] 활용(Exploitation): 지금까지의 경험을 바탕으로, 현재 가장 높은 보상을 줄 것으로 기대되는 최고의 대안을 계속 선택하는 것. [4, 5] 탐색만 너무 많이 하면 이미 검증된 좋은 대안으로 얻을 수 있는 이익을 놓치고(기회비용 발생), 활용만 너무 빨리 시작하면 더 나은 대안을 발견할 기회를 영영 잃게 됩니다. [2, 6] 🤖 대표적인 MAB 알고리즘 탐색과 활용의 딜레마를 해결하기 위해 여러 수학적 알고리즘이 사용됩니다. [5, 7] 그리디 (Greedy): 항상 현재 시점에서 가장 기대 보상이 높은 선택지만 고릅니다. 탐색을 거의 하지 않기 때문에 초반에 잘못된 데이터로 판단을 내리면 최적의 대안을 영영 놓칠 수 있습니다. [5, 6, 7] 입실론 그리디 (ε-Greedy): 기본적으로는 가장 좋은 선택지를 고르되(활용), 매우 작은 확률 ε(입실론)의 확률로 무작위 대안을 선택합니다(탐색). 단순하면서도 효과적이지만, 시간이 지나 학습이 많이 된 상태에서도 여전히 동일한 확률로 무작위 탐색을 한다는 단점이 있습니다. [5, 7, 8] UCB (Upper Confidence Bound): 대안의 평균 보상뿐만 아니라 '불확실성(신뢰구간의 상한선)'을 함께 계산합니다. 시도 횟수가 적어 불확실성이 높은 대안에 가중치를 부여함으로써, 덜 검증된 대안에게 공평한 기회를 주는 똑똑한 탐색 방식입니다. [6, 7, 8, 9] 톰슨 샘플링 (Thompson Sampling): 확률 분포(베타 분포 등)를 활용하여 각 대안이 우수할 확률을 베이지안 방식으로 추정하고 샘플링합니다. 실제 이커머스나 광고 추천 시스템 등 실무에서 가장 뛰어난 성능을 보이는 알고리즘 중 하나입니다. [8, 10] 📊 A/B 테스트와의 비교 현업(마케팅, 서비스 기획)에서 MAB는 전통적인 A/B 테스트의 대안이자 확장판으로 자주 쓰입니다. [3, 6] 비교 항목 A/B 테스트 멀티암드 밴딧 (MAB) 운영 방식 실험 기간 동안 트래픽을 50:50으로 고정하여 순수 탐색 성과 데이터에 따라 트래픽 배분율을 실시간으로 자동 조정 목적 어떤 안이 더 우수한지 통계적 유의성 검증 실험 진행과 동시에 기대 수익(클릭률, 매출 등)을 극대화 기회비용 (Regret) 성과가 나쁜 안에도 끝까지 50%의 트래픽이 가므로 손실이 큼 나쁜 안의 비중을 빠르게 줄이므로 손실(Regret)을 최소화 🌐 주요 활용 사례 온라인 광고 최적화: 클릭률(CTR)이 가장 높은 광고 배너를 실시간으로 찾아내어 노출 비중을 높입니다. 추천 시스템: 넷플릭스나 유튜브처럼 사용자에게 기존 인기 콘텐츠(활용)와 새로운 취향의 콘텐츠(탐색)를 적절히 섞어 추천합니다. 임상시험: 환자들에게 부작용이 적고 효과가 더 좋은 약물의 투여 비율을 실시간 데이터에 기반해 조율합니다. [4, 5, 8, 11] 멀티암드 밴딧과 관련하여 더 구체적인 알고리즘 수식이나 파이썬 구현 코드, 또는 A/B 테스트와의 실무적 차이점 중 어떤 부분을 더 자세히 알아보고 싶으신가요? [1] https://ko.wikipedia.org [2] https://glanceyes.com [3] https://playinpap.github.io [4] https://www.alphaxiv.org [5] https://m.blog.naver.com [6] https://brunch.co.kr [7] https://velog.io [8] https://sungkee-book.tistory.com [9] https://koosco.tistory.com [10] https://wikidocs.net [11] https://www.youtube.com
HTML 코드 작성 시 시맨틱 태그 사용하면 무엇이 좋길래 그렇게 강조하는 걸까? 시맨틱(Semantic) 태그는 태그 자체가 의미를 담고 있는 HTML 요소를 말합니다. [주요 시맨틱 태그] <header> 머리글 · 상단 (여러 개 가능) <nav> 내비게이션 · 주요 링크 모음 <main> 주요 콘텐츠 · 페이지당 1개 <article> 독립 콘텐츠 · 블로그 글, 뉴스, 댓글 <section> 주제별 섹션 · 논리적 구분 <aside> 부가 정보 · 사이드바, 관련 링크 <footer> 바닥글 · 저작권, 연락처 <figure> 이미지, 도표 + <figcaption> <time> 날짜 / 시간 · 작성일, 이벤트 시맨틱 태그를 사용할 때 얻을 수 있는 이점은 크게 4가지 핵심 영역으로 정리할 수 있습니다. 1. 검색엔진 최적화 (SEO: Search Engine Optimization) 구글, 네이버 같은 검색엔진의 크롤러 로봇은 사람이 눈으로 보는 것처럼 디자인을 보는 것이 아니라 HTML 코드를 읽어 페이지를 해석합니다. 핵심 정보의 정확한 색인: <main> , <article> , <h1> 등의 시맨틱 태그를 사용하면 크롤러가 수많은 텍스트 중에서 어떤 것이 핵심 본문이고 주요 제목인지 명확하게 구분 합니다. 검색 노출 우위: 검색 로봇이 정보의 구조를 쉽게 이해할 수 있는 웹사이트는 검색 결과 상위에 노출될 확률이 훨씬 높아 집니다. 2. 웹 접근성 (Web Accessibility) 향상 및 미래 호환성 시각 장애인이나 보조 공학 기기를 사용하는 사용자들은 스크린 리더(음성 읽기 프로그램) 를 통해 웹사이트를 이용합니다. 음성 비서/AI 에이전트도 내용을 올바르게 해석합니다. 랜드마크 탐색 제공: 스크린 리더 사용자는 키보드 단축키를 이용해 <header> , <nav> , <main> , <footer> 같은 주요 구역(Landmark)으로 바로 이동할 수 있습니다. 정보 소음 감소: 레이아웃용 div는 무시하고 의미 있는 시맨틱 구역과 헤딩( <h1> ~ <h6> ) 구조만 선별하여 음성으로 들려주므로 탐색 피로도가 대폭 줄어듭니다. 3. 코드 가독성과 유지보수성 향상 개발자가 코드를 작성하거나 동료의 코드를 분석할 때 직관적인 구조를 제공 합니다. 'div 지옥(Div Hell)' 탈출: 모든 영역이 <div> 로 겹겹이 쌓여 있으면 해당 상자가 상단 메뉴인지, 본문인지, 하단 저작권 정보인지 클래스명(class="...")을 일일이 찾아봐야 합니다. 직관적인 뼈대 파악: 시맨틱 태그를 쓰면 태그 이름만 보고도 웹페이지의 레이아웃 구조를 한눈에 파악할 수 있어, 협업할 때 소통이 원활해지고 유지보수가 쉬워집니다. 4. 웹 표준 준수 및 가벼운 코드 작성 추가적인 클래스/아이디 절약: <div class="header"> 또는 <div class="nav"> 처럼 레이아웃 구분을 위해 매번 클래스명을 지어줄 필요 없이, <header> , <nav> 라는 태그 자체로 스타일을 지정하거나 역할을 명시할 수 있습니다. 다양한 기기에서의 호환성: 스마트폰, 태블릿, 스마트 TV, 웨어러블 기기 등 서로 다른 화면 환경이나 웹 브라우저에서도 시맨틱하게 작성된 문서는 기본 구조를 유지하며 안정적으로 렌더링됩니다.
로봇 모델을 준비해도 물건을 잡고 옮기는 시범 기록이 부족하면 학습을 이어가기 어렵습니다. 여러 작업과 환경의 시범을 확보하려면 데이터를 모으는 장비와 운영 부담도 함께 커집니다. 2026년 7월 21일 Hugging Face에 공개된 Grabette 는 이 수집 과정의 문턱을 낮추려는 공개형 그리퍼 시스템입니다. 로봇 대신 손으로 시범을 기록합니다 Grabette는 사람이 손에 쥔 그리퍼로 작업을 시연하고, 카메라 기록에서 움직임을 복원하는 장치입니다. 원격 조작에는 장비를 구성하고 운영하는 부담이 따릅니다. 조작 방식에 따라 긴 수집 작업이 사용자에게 고될 수도 있습니다. 특히 여러 장소에서 시범을 꾸준히 확보하려면, 한 실험실에 장비를 갖추는 것과는 다른 운영 문제가 생깁니다. Grabette가 기록하려는 핵심 정보는 위치와 방향을 함께 담는 6자유도, 즉 6-DoF 궤적입니다. 물건을 잡는 장면뿐 아니라 그리퍼가 어디에서 어떤 자세로 움직였는지를 표현해야 하므로, 촬영한 정보에서 궤적을 복원하는 과정이 필요합니다. 기록을 가공과 공유로 연결합니다 Grabette의 구성은 시범을 촬영하는 장치에서 끝나지 않고, 학습용 데이터셋을 정리하고 공유하는 과정까지 이어집니다. 개발진이 직접적인 영감으로 밝힌 것은 Stanford의 Universal Manipulation Interface, UMI입니다. UMI는 어안 카메라를 장착한 휴대형 그리퍼로 현장의 시범을 기록합니다. 이후 SLAM으로 카메라 궤적을 복원하고, 시각 정보와 동작을 연결하는 정책을 학습합니다. Grabette 개발진은 데이터셋에 LeRobot을, 공유에 Hugging Face Hub를 활용합니다. 처리 파이프라인은 별도 설치 없이 브라우저에서 실행하도록 소개되어 있습니다. 수집 장치를 마련한 참여자에게도 파일을 학습용 형식으로 가공하고 공유할 곳을 정하는 일이 남습니다. Grabette는 이 후속 작업까지 연결해, 촬영 이후의 부담도 낮추려 합니다. 공동 수집으로 작업과 환경을 넓힙니다 개발진의 목표는 여러 참여자가 시범을 보태는 개방형 공동 조작 데이터셋입니다. 한 연구실이 혼자 확보하기 어려운 작업과 환경을 나누어 기록하겠다는 구상입니다. 개인 기록을 모으는 단계에서 공동 데이터셋으로 범위가 넓어지면, 수집량과 함께 기록의 일관성도 중요해집니다. 공개된 장치와 공유 경로는 참여의 기반이며, 기록을 어떤 기준으로 함께 사용할지는 운영에서 다룰 문제입니다. 맞는 경우와 맞지 않는 경우 Grabette는 로봇 장비를 먼저 갖추는 부담 때문에 시범 수집을 시작하지 못하는 경우에 검토할 만합니다. 여러 장소의 참여자가 각자 작업을 기록해 공동 데이터셋에 보태려는 목적도 개발진이 제시한 방향과 맞습니다. 반면 수집부터 학습, 실제 로봇의 동작 검증까지 모두 로봇 없이 해결하려는 기대에는 맞지 않습니다. 로봇이 필요 없다는 설명은 시범 수집 단계에 관한 것이며, 기록한 움직임을 목표 로봇이 얼마나 잘 재현하는지는 별도 검증 대상입니다. 장비의 정밀도나 구매 비용을 기준으로 선택하려는 경우에도 추가 정보가 필요합니다. Grabette에는 역할을 나눈 카메라 두 대가 탑재된다고 소개되지만, 소개된 내용에는 각 카메라의 상세 사양과 역할 전체가 담겨 있지 않습니다. 저비용이라는 설명에도 구체적인 구매 금액은 제시되지 않아, 이를 가격 비교의 근거로 삼기는 어렵습니다. 기능보다 작업의 완성을 봅니다 Grabette를 평가할 때는 참여자가 시범 기록을 끝까지 완성할 수 있는지가 중요한 기준입니다. 장비 준비, 시범 기록, 학습용 가공으로 이어지는 작업에서 실제 부담이 줄어드는지를 보는 것입니다. GeekNews의 「AI는 나를 슬프게 한다」 는 개발 속도 향상이라는 약속에 비해 일상 소프트웨어의 개선은 체감하기 어렵다는 개인의 비판을 전합니다. 이 문제의식을 Grabette에 적용하면, 새 기능의 수보다 기록을 완성하고 학습에 활용하는 과정이 얼마나 나아지는지에 관심을 두게 됩니다. 도입 전에 따져 볼 질문 다음은 자신의 작업에 도입하기 전에 따져 볼 질문의 예입니다. 공동 수집과 가공 결과를 검토하기 위한 항목이며, Grabette에 구현된 기능 목록은 아닙니다. 같은 작업을 반복한 시범과 다른 환경에서 수행한 시범을 구분할 수 있습니까? 궤적 복원에 문제가 생긴 기록을 찾아 검토할 수 있습니까? 가공에 넣은 입력과 그 결과를 대조할 수 있습니까? 가공한 데이터에 목표 로봇과 학습 과정이 요구하는 정보가 들어 있습니까? 자동 가공이 데이터 품질을 보장하지는 않으며, 소개된 내용에는 정량적인 성공률이나 오차 수치가 제시되지 않습니다. 따라서 도입 검토에서는 자신의 작업 시범을 기록하고, 처리 결과를 받아 위 질문에 답하는 순서가 필요합니다. 마무리 Grabette의 도입은 직접 기록한 시범의 가공 결과가 목표 학습에 필요한 정보를 담는지 확인하는 데서 판단을 시작할 만합니다. 개발진이 지향하는 공동 데이터셋의 실질적인 가치는 어떤 작업의 기록이 쌓이고, 그 기록으로 무엇을 학습할 수 있는지에 달려 있습니다. 원문: webi 기술 블로그 참고한 자료: Grabette: an open system to record robot-manipulation data AI는 나를 슬프게 한다 폰 노이만의 전설(1973) [PDF]
https://www.hackerrank.com/contests/leetcode-bootcamp-week-1/challenges/move-zeroes-45-3/problem?isFullScreen=true 문제 0 을 뒤쪽으로 움직이는 문제 (in-place) 답안 public static List<Integer> moveZeroes(List<Integer> nums) { int count = 0; for (int num: nums) { if (num == 0) { count++; } } for (int i = 0; i < count; i++) { nums.remove(Integer.valueOf(0)); nums.add(0); } return nums; } 메모 돌면서 지워버리면 Concurrent 관련 Exception 이 뜬다. 그래서 돌면서 0 개수 세어주고, 그 이후에 그만큼 지우고 더하는 작업을 실행해줬다.
https://www.hackerrank.com/contests/leetcode-bootcamp-week-1/challenges/set-matrix-zeroes-21/problem?isFullScreen=true 문제 2차원 배열 주어지면 해당 요소의 행과 열의 모든 요소 0 으로 (in-place) 답안 public static void setZeroes(List<List<Integer>> grid) { int row = grid.size(); int column = grid.get(0).size(); int[] rowCheck = new int[row]; int[] columnCheck = new int[column]; for (int i = 0; i < row; i++) { for (int j = 0; j < column; j++) { if (grid.get(i).get(j) == 0) { rowCheck[i] = 1; columnCheck[j] = 1; } } } for (int i = 0; i < row; i++) { for (int j = 0; j < column; j++) { if (rowCheck[i] == 1 || columnCheck[j] == 1) { grid.get(i).remove(j); grid.get(i).add(j, 0); } } } } 메모 in-place 니까 돌면서 바꾸면 안 되고.. 체크해놓고 그 다음에 돌면서 바꿔줘야 된다. 단계적 사고~~
10.5 1) 3년간 들어온 소장품 집계하기 select classification, sum(case when year(acquisition_date) = 2014 then 1 else 0 end) as '2014', sum(case when year(acquisition_date) = 2015 then 1 else 0 end) as '2015', sum(case when year(acquisition_date) = 2016 then 1 else 0 end) as '2016' from artworks group by 1 order by 1 2) 12월 우수 고객 찾기 select customer_id from records where month(order_date) = 12 group by 1 having sum(sales) >= 1000 10.6 1) 스탬프를 찍어드려요 select case when total_bill >= 25 then 2 when total_bill >= 15 then 1 else 0 end as stamp, count(*) as count_bill from tips group by 1 order by 1 2) DVD 대여점 우수 고객 찾기 select customer_id from rental r join customer c using(customer_id) where c.active = 1 group by 1 having count(*) >= 35
https://www.hackerrank.com/contests/leetcode-bootcamp-week-1/challenges/contains-duplicate-27-2/problem?isFullScreen=true 문제 안에 중복 요소 있으면 true, 다 unique 하면 false 답안 public static boolean containsDuplicate(List<Integer> nums) { Set<Integer> set = new HashSet<>(); for (int num: nums) { int beforeSize = set.size(); set.add(num); if (beforeSize == set.size()) { return true; } } return false; } 메모 Set 으로 체크하면 So 간단..
로컬 이미지 생성에서는 GPU 메모리에 모델을 올리지 못해 실험을 시작하지 못하는 일이 생깁니다. Hugging Face는 2026년 7월 23일 Nunchaku의 4비트 추론을 Diffusers에 통합하는 방법 을 소개했습니다. 개발자가 이 기술을 살펴볼 때 풀어야 할 문제는 모델을 작게 저장하는 효과와 실제 생성 계산을 빠르게 하는 효과를 구분하는 것입니다. Nunchaku Lite는 무엇인가 Nunchaku Lite는 Nunchaku의 4비트 체크포인트를 익숙한 Diffusers 로딩 방식으로 사용하도록 연결합니다. 기반 기술인 SVDQuant는 주요 트랜스포머 계층에서 가중치와 활성값을 함께 4비트로 처리하는 W4A4 방식을 사용합니다. 가중치는 학습을 통해 정해진 모델의 값이고, 활성값은 입력을 처리하는 동안 생기는 중간 값입니다. W4A4는 저장된 가중치뿐 아니라 계산 도중 사용하는 활성값의 정밀도도 낮춥니다. 이를 통해 메모리 사용량을 줄이면서 이미지 생성의 디노이징 반복 구간을 가속하는 것을 겨냥합니다. 적용 대상은 주요 트랜스포머 계층이며, 파이프라인의 모든 구성요소를 일괄적으로 4비트로 바꾸는 방식은 아닙니다. Hugging Face의 설명에서 현대적인 텍스트 기반 이미지 생성 모델을 BF16으로 로드할 때 흔히 필요한 VRAM은 20~30GB입니다. 소비자용 GPU에서 양자화가 중요한 이유는 이런 메모리 요구량이 모델을 실행할 수 있는지부터 결정하기 때문입니다. 가중치 양자화와 계산의 차이 가중치 중심 양자화는 저장 공간을 줄이지만, 계산 전에 값을 높은 정밀도로 복원하는 경로에서는 속도 이득을 기대하기 어렵습니다. Diffusers는 이미 bitsandbytes, GGUF, torchao, Quanto 등의 양자화 백엔드를 지원합니다. Hugging Face는 이들 가운데 많은 방식이 가중치 중심 양자화를 사용한다고 설명합니다. 여기서 살펴볼 것은 백엔드 이름 자체보다 실제 계산에 어떤 정밀도의 값이 들어가는지입니다. 복원을 거치는 방식은 대체로 추론을 빠르게 만들지 않으며, 복원 작업 때문에 오히려 지연이 조금 늘어날 수도 있다는 것이 Hugging Face의 설명입니다. 따라서 체크포인트 파일 크기는 메모리 절감의 단서로 삼되, 생성 속도를 나타내는 측정값으로 취급해서는 안 됩니다. 로딩은 익숙하게, 준비는 별도로 Diffusers 통합으로 달라지는 실행 준비는 일반적인 from_pretrained() 호출로 Nunchaku 체크포인트를 불러올 수 있다는 점입니다. 이전에는 별도 추론 라이브러리가 필요했지만, 통합된 환경에서는 별도 파이프라인 클래스를 작성하거나 로컬에서 CUDA 코드를 컴파일할 필요가 없습니다. 다만 NVFP4 커널은 처음 사용할 때 Hugging Face Hub에서 다운로드합니다. 실행 환경을 재현하려는 팀이라면 사용한 체크포인트와 패키지 구성을 함께 기록하는 편이 좋습니다. 같은 로딩 코드를 다시 실행하는 것뿐 아니라, 그 코드가 어떤 구성으로 실행됐는지도 남기기 위해서입니다. 예제에서 확인할 구성과 조건 시작 예제는 사전 양자화된 ERNIE-Image-Turbo 체크포인트를 ErnieImagePipeline 으로 불러오며, 구성요소별로 서로 다른 최적화를 사용합니다. 트랜스포머에는 Nunchaku NVFP4를, 텍스트 인코더에는 bitsandbytes를 적용합니다. 생성 조건은 가로와 세로 각각 1024픽셀, 추론 8단계, guidance_scale=1.0 , 난수 시드 42입니다. 이는 예제를 실행한 조건이며 모든 모델에 적용할 권장 설정은 아닙니다. 다른 결과와 비교할 때는 체크포인트 이름에 더해 이런 생성 설정도 함께 보아야 합니다. 구체적인 GPU 지원 목록과 벤치마크 수치가 제시되지 않은 설명이므로, 특정 그래픽카드에서의 실행 가능 여부나 가속 배율은 이 예제만으로 정할 수 없습니다. 실제 작업으로 비교하는 순서 비교는 자신이 반복해서 사용하는 프롬프트와 해상도를 고정하는 데서 시작하는 편이 좋습니다. ITWorld의 「프론티어 모델의 그늘에서 벗어나는 로컬 LLM...올라마 완전 정복」은 모델 선택에서 매개변수 수뿐 아니라 작업 종류, 가용 메모리, 모델 구조를 함께 고려해야 한다고 설명합니다. 단순한 작업이라면 장비에 들어가는 가장 큰 모델이 반드시 필요한 것도 아닙니다. 이미지 생성에 이 관점을 적용할 때 측정할 시간은 요청을 시작한 순간부터 이미지가 나올 때까지입니다. Nunchaku가 겨냥하는 디노이징 구간의 개선이 사용자 대기 시간에 얼마나 반영되는지는 전체 생성 시간을 통해 살펴보게 됩니다. 최초 실행 기록은 이후 실행과 나누어 남깁니다. 첫 실행에는 다운로드와 준비 과정이 섞일 수 있어 반복 생성과 같은 조건으로 비교하기 어렵기 때문입니다. 결과 이미지도 함께 보아야 하며, 품질 평가 수치가 제시되지 않은 상태에서 기존 모델과 동일한 품질을 전제하지는 않습니다. 도입 조건과 검토 질문 메모리 제약이 있는 로컬 이미지 생성에서 기존 Diffusers 작업을 이어 가려는 경우에는 Nunchaku Lite를 비교 대상으로 둘 만합니다. 서비스에 도입하려면 실행 성공에 더해 승인 기준을 먼저 정해야 합니다. ITWorld의 「AI가 짓는 집, 설계도는 누가 그리나...AI 코드 시대의 거버넌스 설계」는 성능, 오류 처리, 관찰가능성과 같은 비기능 요구사항을 실행 가능한 승인 기준으로 만들라고 강조합니다. 이미지 생성 서비스에 적용하면 허용할 생성 시간과 실패 조건을 정하고, 실제 용도에 맞는 결과를 얻었는지 평가하는 일이 여기에 해당합니다. 로딩 코드가 짧아졌다는 이유만으로 운영 도입을 결정하는 접근은 맞지 않습니다. 비교 결과가 나왔을 때 도입을 승인할 기준은 무엇입니까? 생성이 실패하거나 요구한 결과를 얻지 못했을 때, 서비스가 받아들일 실패 조건은 어디까지입니까? 다른 팀원이 같은 실험을 재현할 수 있도록 체크포인트, 패키지 구성, 생성 설정을 함께 남겼습니까? 마무리 Nunchaku Lite로 실행 준비의 부담이 줄어든 만큼, 도입 판단에서는 같은 조건으로 얻은 결과와 그 결과를 반복해서 재현할 수 있는지를 우선할 만합니다. 4비트라는 표기보다 자신의 작업에서 남긴 비교 기록을 선택의 근거로 삼는 것이 이 글의 제안입니다. 원문: webi 기술 블로그 참고한 자료: Bringing Nunchaku 4-bit Diffusion Inference to Diffusers 프론티어 모델의 그늘에서 벗어나는 로컬 LLM...올라마 완전 정복 AI가 짓는 집, 설계도는 누가 그리나...AI 코드 시대의 거버넌스 설계
https://www.hackerrank.com/contests/leetcode-bootcamp-week-1/challenges/valid-palindrome-60/problem?isFullScreen=true 문제 주어진 string 에서 문자/숫자 아닌 거 빼고 앞뒤로 똑같은지 답안 public static boolean isPalindrome(String s) { int i = 0; int j = s.length() - 1; while (i < j) { while ((i < j) && !Character.isLetterOrDigit(s.charAt(i))) { i++; } while ((i < j) && !Character.isLetterOrDigit(s.charAt(j))) { j--; } if (Character.toLowerCase(s.charAt(i)) != Character.toLowerCase(s.charAt(j))) { return false; } i++; j--; } return true; } 메모 투포인터로.. 접근은 잘 했지만 while 문 돌 때 이중 while 문에서도 i < j 를 체크해줘야 된다는 것을 까묵.. 꼼꼼히 체크해주자!!!
https://www.hackerrank.com/contests/leetcode-bootcamp-week-1/challenges/rotate-image-31-1/problem?isFullScreen=true 문제 2차원 배열 주어지면 시계 방향으로 90도 회전 답안 public static void rotate(List<List<Integer>> grid) { int row = grid.size(); int column = grid.get(0).size(); for (int i = 0; i < row; i++) { for (int j = i + 1; j < column; j++) { int tmp = grid.get(i).get(j); grid.get(i).remove(j); grid.get(i).add(j, grid.get(j).get(i)); grid.get(j).remove(i); grid.get(j).add(i, tmp); } } for (int i = 0; i < row; i++) { for (int j = column - 1; j >= 0; j--) { int tmp = grid.get(i).get(j); grid.get(i).remove(j); grid.get(i).add(tmp); } } } 메모 90도 돌리려면 행렬을 transpose 하고, 각 행을 역순으로 바꿔주면 된다. transpose 는 어떻게 하는가.. 가 어려웠는데 for 문에서 대각선 위쪽만 돌아주면 되는 것! 그리고는 쓸데없이 List<List > 로 인풋을 줘서 그거 처리하는 것만 어려웠다.
무슨 일이 있었나 신한은행·KB국민은행의 고객정보 유출 사고 이후에도 'AI 해킹' 의심 공격이 국내 금융권 전반으로 번지고 있다. 2026년 10월 6일 금융감독원은 12개국에서 유입된 공격자 IP 28개를 차단하도록 금융권에 지시했다고 밝혔다. 같은 날 토스뱅크는 유사한 침입 시도를 방어에 성공했다고 밝혔고, 케이뱅크와 카카오뱅크에도 동일한 유형의 접속 시도가 포착된 것으로 전해졌다. 국민건강보험공단 역시 AI 해킹 확산 우려에 긴급 비상대책회의를 여는 등 대응 범위가 금융권을 넘어서고 있다. 이번 공격의 배후로 지목되는 것은 'ARTEX'로 불리는 공격 도구다. 신한은행에 대한 크리덴셜 스터핑(탈취한 계정정보 대입 공격) 과정에서 사용된 공격 서버의 HTML 제목에 '자주渗透测控制台(자율 침투 테스트 콘솔)'라는 문자열이 포함된 사실이 확인되며 ARTEX와의 연관성이 제기됐다. ARTEX는 LLM과 멀티에이전트 구조를 기반으로 정보 수집, 취약점 발견, 공격 경로 설계, 보안 도구 실행, 취약점 검증까지 전 과정을 자동화하도록 설계된 자율 침투테스트 시스템으로, 중국어 위주로 깃허브에 오픈소스로 공개돼 있다. 다만 이 도구가 실제 이번 공격에 쓰였는지는 금융당국이나 은행 측에서 공식 확인하지 않았다. 왜 중요한가 이번 사태가 주목받는 이유는 단일 은행의 보안 사고가 아니라, 공격자가 '자동화된 침투 파이프라인'을 통해 여러 금융기관을 순차적으로 두드리는 양상을 보이고 있다는 점이다. 토스뱅크처럼 방어에 성공한 사례가 있는 반면 케이뱅크·카카오뱅크처럼 시도 단계에서 포착된 경우도 있어, 공격이 특정 기관을 노린 것이 아니라 금융권 전반을 대상으로 한 광범위한 스캐닝에 가깝다는 분석이 나온다. 업계 전문가들은 기존의 망분리 중심 방어 체계만으로는 LLM 기반 자율 공격 도구의 속도와 범위를 따라잡기 어렵다고 지적한다. 사람이 수작업으로 수행하던 정찰·취약점 탐색·공격 경로 설계를 AI가 자동화하면서 공격 주기가 극적으로 단축되고 있기 때문이다. 실제로 국내 보도에 따르면 이런 공격 도구의 사용료가 매우 저렴한 수준인 것으로 알려지면서, 자본력이 크지 않은 공격자도 금융권급 표적을 노릴 수 있게 됐다는 우려가 커지고 있다. 이번 사태는 금융권뿐 아니라 개인정보를 다루는 공공기관 전반이 AI 공격에 대한 탐지·대응 체계를 재점검해야 한다는 신호로 읽힌다. 원문: https://www.newsis.com/view/NISX20261006_0003816173