주요소식25년 7월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.링크 & 읽을거리Goodbye UseState: XState의 창시자 David Khourshid가 useState 사용을 피하는것이 좋은 케이스를 소개합니다. 3년전의 Goodbye UseEffect를 잇는 시리즈 발표입니다.Search Params Are State, Beware The URL Type-Safety Iceberg: search params를 state로 활용하는것에서 오는 문제들에 대한 글들입니다. react-query로 유명한 tanstack과 nuqs 라이브러리 author들의 다양한 시각을 소개합니다.The State of React and the Community in 2025: 현재의 React 생태계와 커뮤니티에 대한 분석글입니다. Meta와 Vercel 간의 관계가 React 생태계에 미치는 영향과 개발자들이 앞으로 고려해야 할 사항들을 심도 있게 분석합니다.Ecma International approves ECMAScript 2025: What's new?: 6월 25일 Ecma International 총회에서 ECMAScript 2025 언어 사양이 공식적으로 승인되었습니다. 여러 스펙들이 있지만 그중에서도 Iterator 관련 스펙은 눈여겨 볼만합니다.튜토리얼No Server, No Database: Smarter Related Posts in Astro with transformers.js: 서버나 DB없이 관련 포스트(추천 포스트)를 구현하는 방법에 대한 가이드입니다. Static하게 Serving하는 블로그를 운영하고 있다면 따라해보기를 추천드립니다.Reactivity is easy: React에서 세밀한 반응성(fine-grained reactivity)을 구현하는 방법을 설명하는 튜토리얼입니다.초보자를 위한 Model Context Protocol (MCP) 커리큘럼: 마이크로소프트에서 제공하는 Model Context Protocol(MCP) 한국어 학습 자료입니다.코드와 도구i18n-check: React, Next.js 앱에서 잘못된 키, 누락된 키, 사용되지 안않는 키 등을 검출해줍니다.Lingo.dev: Lingo.dev 컴파일러는 어떤 React 앱이더라도 빌드 시점에 다중 언어를 지원할 수 있도록 만들어 주는 미들웨어로, 기존 React 컴포넌트를 수정할 필요가 전혀 없습니다.AI Version Control: YOYO: YOYO는 Vibe Coding을 위한 형성관리 도구입니다.liquid-glass: 애플이 WWDC25 행사를 통해 공개한 liquid glass 디자인을 적용할 수 있는 react 컴포넌트입니다. >> FE News 25년 7월 소식 보러가기 FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. 구독하기

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용웹브라우저에서 대용량 데이터를 높은 성능으로 표현할 수 있는 Windowing 기법에 관해 소개하고 적용 사례를 공유합니다.발표 대상Windowing 기법에 관심이 있는 개발자목차Windowing 기법이란데이터 스트리밍 / 시계열 처리에서의 Windowing머신러닝에서의 Windowing컴퓨터 그래픽스에서의 WindowingReact에서의 Windowing / Virtualization 기술Windowing 기법을 활용한 오픈소스 라이브러리들Windowing기법을 사용하는 오픈소스 라이브러리 비교react-virtualizedreact-window@tanstack/react-virtual대용량 고성능 표 컴포넌트 Big Table 개발 배경Table이 아니기 때문에 발생하는 어려움들오픈소스 이슈의 원인 파악의 어려움Big Table 컴포넌트의 주요 Windowing 기법대용량 데이터를 무한 스크롤 표로 나타내려면 어떻게 해야 할까? Key 를 활용해서 불필요한 Re-rendering을 방지주어진 영역에 보여줄 데이터 범위를 구하기Windowing (Virtualization) 적용Overscan을 통해 미리 그려 놓기Bottom Threshold 통해 미리 Fetch하기컬럼에 대한 가상화고정 헤더/컬럼 지원행 접고/펴기성능 / 장점 / 한계성능ResizeScroll접고/펴기펴고 스크롤30만건 데이터 로드자체 개발로 얻은 장점한계와 대안 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

사내 빅데이터 플랫폼을 Cloud Native 환경에서 개발하고 있습니다.20PiB 규모의 데이터를 최저 network 비용을 사용해 통신할 수 있는 구조를 확보해야 합니다.제조 빅데이터의 특징은 쿼리 수행 규모가 매우 큽니다.하루 60만건 정도의 빅데이터 ad-hoc 쿼리를 처리할 수 있는 분산 환경을 구성해야 하는데,현재 200G Sprine -> 40G*2(bonding) Leaf 기반의 네트워크 토폴로지에서 microburst 현상이 자주 발견되어극단적인 K8S 네트워크 최적화에 대한 검증을 하고 있습니다.그 일환으로 Istio Mesh를 적용하여 각 노드간의 observability를 확보할려고 했으나 빅데이터 서비스 환경에는 적합하지 않다는 결론을 내렸고,그 다음 단계로 Istio Ambient를 사용하여 트래픽 관리 및 어플리케이션의 가시성을 확보할려고 했으나 역시 적절한 기술이 아니라는 결론을 얻었습니다.몇 가지 테스트한 내용 중 일부를 공유합니다.• None Cloud Native 기반 빅데이터 플랫폼 서비스의 아키텍처에는 적합하지 않음• None 노드에서 실행하는 수 많은 분산 컴포넌트의 통신을 ztunnel을 통해 라우팅될 경우 bottleneck이 발생하는 악성 구조 유발• None mTLS를 위해 zTunnel을 사용하는 이점만큼 병목이라는 단점이 극대화• None waypoint는 north-south 통신을 위한 gateway 역할을 기대했으나, 실제로는 ztunnel을 통해 라우팅되는 만큼 Direct Return 구조가 중요한 분산 환경에서 사용할 수 없는 구조• None 현재의 Istio와 Istio Ambient는 대규모 분산 트랜잭션과 트래픽을 위한 설계는 고려되지 않은것으로 파악됨• None Kmesh 역시 istiod를 통해 실행되는 구조이기 때문에 L3 라우팅이 bpf로 처리된다고 해도 cilium 단일 CNI로 모두 대응 가능• None 특히 Istio Ambient 모드를 실행하기 위해서 Cilium CNI의 ebp.masquerade 모드를 false로 설정해야 하기 때문에 노드간의 라우팅은 iptables에 의존해야하는 불합리가 발생 -> true일 경우 원본 source ip가 변경될 수 있기 때문에 라우팅 오류 발생사이드카 없는 istio 데이터플레인 모드 : A new dataplane mode for Istio without sidecars - Blog• None 앰비언트 메시는 사용자에게 사이드카 프록시 대신 인프라에 통합된 데이터 플레인을 사용할 수 있는 옵션을 제공하며, 동시에 Istio의 핵심 기능인 제로 트러스트 보안, 원격 측정, 트래픽 관리는 그대로 유지됩니다.• None• None 파드들은 해당 노드에 존재하는 ztunnel 파드를 공유하여 다른 파드들(동일 노드, 다른 노드)과 안전한 통신 환경을 제공Basic ztunnel L4-only datapath -> ambient 모드가 적용된 Pod는 hbone 통신(미적용된 Pod는 TCP)• None Layer7 통제와 정책이 필요 시, Waypoint Proxy 파드를 통하여 기능을 구현• None -> 이러한 구조 때문에 대규모 분산 트랜잭션 서비스에는 적합하지 않음• None HBONE HTTP Based Overlay Network Encapsulation는 애플리케이션 통신 트래픽을 HTTP CONNECT 메서드를 통해 표준 HTTP 터널링을 사용합니다. TCP 상위에 HTTP/2를 사용하며, TLS를 통해 상호 인증과 암호를 제공합니다. HBONE tunnel 은 TCP 15008 포트를 사용합니다 - HTTP CONNECT & HTTP/2• None Ztunnel 동작 : Istiod에서 ztunnel 에 xDS Config 구성, ztunnel 연결 구성• None Ztunnel and Waypoint : L7 필터/통제는 목적지 파드에 매칭되는 Waypoint proxy를 통해 기능 구현• None Security Deep Dive : ztunnel 을 통해 Secure Overlay 를 제공, Waypoint는 L7 통제/정책 제공 - Link• None 공통 : 파드 트래픽을 ztunnel 로 redirection 하기 위해서, Istio CNI DaemonSet 을 활용⇒ sidecar proxy 를 경유하기 위해서 파드 내에서 초기화 컨테이너로 iptables 설정한 것 처럼,ztunnel 를 경유하기 위해서 istio cni DaemonSet 이 CNI Network Plugin 으로 호스트 네트워크 네임스페이스에 iptables 과 ztunnel 파드 내부에 iptables 에 설정함.⇒ 현재는 다른 방식을 사용 중!(1)(2)(3) sleep 파드에서 bar NS의 httpbin 목적지로 요청 ⇒ Istio CNI DaemonSet에 의해서 설정된 iptables 에 따라, 요청 트래픽이 istioout → (Geneve Tunnel) → pistoout 전달(4)(5) pistoout 은 iptables rule 을 통해 파드 내의 eth0 인터페이스에 port 15001로 redirect(6) ztunnel 파드는 목적지 httpbin 정보를 기반으로 전달 ⇒ 노드 B eth0(7) 요청 트패릭은 httpbin 파드 내의 iptables rule 을 통해 port 15006로 redirect 되고 이후 목적지 httpbin 파드에 도착(1)(2) Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨(3) 목적지 httpbin 파드는 waypoint proxy disabled로 목적지 파드가 있는 (오른쪽 상단) 워커 노드 B로 전달됨(4)(5)(6) veth httpbin ↔ httpbin 파드 내 eth0 과 device pair 관계이지만, iptables rule에 의해 가로채어 istioin → pistioin device로 전달(7)(8) ztunnel 파드 내에 iptables rule에 의해 port 15008 redirect(9) 최종적으로

안녕하세요! 지난 주 목요일, 카카오 AI 캠퍼스에서는 크루들을 대상으로 한 특별한 '10K 해커톤’이 열렸습니다. 이 해커톤은 무박 2일의 전통적인 방식에서 벗어나, 단 10시간 동안 AI 도구를 최대한 활용해 아이디어를 MVP(최소 기능 제품)로 구현하는 '바이브 코딩(Vibe Coding)'에 중점을 둔 행사였죠.이런 취지를 살려 "심사도 AI로 해야 하지 않을까요?"라는 의견이 나왔고… 제가 무심코 "Gemini를 쓰면 시연 영상 심사도 가능할 것 같은데요?"라고 말했다가 덜컥 프로젝트의 담당자가 되어버렸습니다. 😅🚀 D-30, 아이디어에서 v1.0 기획서까지행사 한 달 전, 저와 동료 sue.cream는 AI 심사 시스템 구축의 여정을 시작했습니다. sue.cream는 순식간에 v0를 이용해 시스템의 초기 프로토타입을 만들어냈습니다. “와, AI로 하니 정말 뚝딱이네!” 저희는 이른 성공에 안도하며 다른 급한 업무를 먼저 처리하기로 했습니다. 😂하지만 시간은 흘러 D-14, 일정의 압박이 시작되었습니다. 관련 담당자들과 모여 심사 프로세스 전반에 대한 깊은 논의를 진행했습니다. 놀랍게도, 미팅이 끝난 직후 회의록을 Gemini에게 전달하자 단 몇 분 만에 AI 심사의 목표, 주요 기능, 단계별 체크리스트가 담긴 AI 심사 시스템 기획서 v1.0이 완성되었습니다.기획서가 나온 당일, 저는 v0를 붙잡고 3시간 동안 화면 설계를 시작했습니다. 로그인, 결과 제출, 팀 대시보드, 동료 평가, 최종 결과 페이지 등 총 14개에 달하는 페이지 구성을 완료했죠. v0에게 대화하듯 요구사항을 전달하니 자유자재로 화면이 만들어졌고, 에셋 이미지를 올리자 제법 그럴듯한 사이트가 완성되었습니다. 프론트엔드의 세션 유지나 API 호출을 가정한 Mock 데이터 바인딩 같은 기술적인 부분까지 미리 처리해두었습니다.💻 D-13, AI가 개발해주는 프론트엔드와 백엔드다음 날, v0에서 작업한 결과물을 깃헙으로 연동해 소스코드를 확보했습니다. 보통 이런 UI 도구는 코드가 지저분하게 생성되곤 하는데, v0의 결과물은 놀라울 정도로 깔끔했습니다. 로컬에서 실행했을 때 완벽하게 돌아가는 것을 보고 '이제 거의 다 끝났다’고 생각했죠. 하지만 그것은 거대한 착각이었습니다. 모든 것은 이제 시작이었습니다.😱이제 Claude Code를 만날 시간이었습니다. 가장 먼저 프론트엔드 코드를 분석해 API 명세서를 만들어달라고 요청했습니다. v0에서 이미 Mock 데이터 구조를 잡아두었기에, Claude는 이를 기반으로 필요한 API 스펙을 정확하게 설계해주었습니다.이 명세서를 들고 백엔드 프로젝트 구성에 돌입했습니다. 기존에 Spring AI + Kotlin 기반 프로젝트 경험이 있어서 자신감은 있었지만, OpenAI, Claude, Gemini라는 각기 다른 LLM을 하이브리드 심사위원으로 구성하는 것은 처음이었습니다.start.spring.io에서 Spring AI, PostgreSQL, Google OAuth2, JWT, Modulith 등 필요한 의존성을 추가해 템플릿 프로젝트를 생성했습니다. 그리고 Claude Code에게 이 프로젝트와 API 명세서를 보여주며라고 지시했습니다.정말 이게 가능하냐고요? 네, 가능했습니다. Claude는 프로젝트 구조를 분석한 뒤, 명세서에 맞춰 Controller, Service, Repository, Entity를 척척 개발하기 시작했습니다. 이 작업이 진행되는 약 10분 동안 저는 사내 시스템에서 개발용 DB를 생성하며 기다렸죠.그림 8. Claude Code의 백엔드 코드 생성 기다리는 중백엔드 작업이 끝나자마자, 프론트엔드 프로젝트로 돌아와 Claude에게 "이제 백엔드 API 서버가 준비됐으니, 프론트에서 실제 API를 호출하도록 코드를 수정해줘"라고 요청했습니다. 놀랍게도 Claude는 백엔드 프로젝트의 컨트롤러 코드를 스스로 확인하며 Mock 데이터를 실제 API 호출로 하나씩 교체하기 시작했습니다.잠시 후, 로컬에서 프론트와 백엔드 서버를 모두 실행했습니다. 설마 했는데… 한 번에 성공했습니다! 로그인부터 팀 대시보드까지 모든 기능이 순조롭게 동작했습니다.🤯 D-10, 배포와 구글 로그인이라는 거대한 벽이제 담당자들에게 공유하기 위해 사내 시스템에 배포할 차례였습니다. 사내 클러스터(DKOS) 생성, 인그레스 설정, 방화벽 처리 등 대부분의 작업은 직접 진행했지만, Dockerfile이나 k8s 설정 파일 등은 Claude의 도움을 받았습니다. (물론, 기존 프로젝트 설정을 참고해 수정하는 과정은 필요했습니다.)* DKOS: 카카오 사내의 Kubernetes(k8s) 기반 클러스터 오케스트레이션 서비스로, 대다수의 카카오 서비스가 DKOS 기반으로 개발/운영되고 있습니다.다음은 구글 로그인 구현이었습니다. Claude에게 Google OAuth2 인증과 JWT 세션 유지를 요청했고, 프론트와 백엔드 코드가 순식간에 수정되었습니다. 로컬 테스트는 완벽했죠.그러나 배포된 환경에서는 구글 로그인이 먹통이었습니다. 여기서부터 기나긴 삽질이 시작되었습니다. AI는 한번 문제에 빠지면 헤어나오지 못하는 경향이 있는데, 딱 그런 상황이었습니다. 원인은 로드밸런서 환경에서 여러 서버 인스턴스를 오가며 세션이 유실되는 문제였습니다. 이 문제는 과거 프로젝트 코드를 참고해 겨우 해결했습니다.하지만 이번엔 구글 로그인 시 무한 로딩에 빠지는 문제가 발생했습니다. 시간은 흘러가고 해결책은 보이지 않았습니다. 결국 '내일의 나’에게 맡기기로 하고 잠시 작업을 중단했습니다.다른 업무를 처리하느라 시간은 어느새 D-5로 다가왔습니다. 여전히 문제는 해결되지 않았죠. 날을 잡고 AI가 작성한 코드를 한 줄 한 줄 뜯어보다가 마침내 원인을 찾았습니다. k8s 설정 파일 중, AI가 작성한 프록시 설정이 잘못되어 구글 인증 서버에 접근하지 못하고 타임아웃이 발생했던 것입니다. 설정을 수정하자 거짓말처럼 모든 문제가 해결되었습니다. AI로 로그인 하나 구현 못 하나 싶었는데, 정말 다행스러운 해프닝이었습니다.🛠️ D-4, 전면 개편과 코드베이스의 역습시스템이 안정되자 근본적인 질

제품의 진입점을 사용자가 잘 찾는지 알고 싶을 때, 어떻게 하시나요?토스는 자체 리서치 도구로 알아봐요. 사용자가 원하는 기능을 얼마나 잘 찾아가는지를 수치로 측정하는 툴로, 이름은 TNS(Toss Navigation Score)예요.“토스에 있는 모든 서비스를 보려면 어디를 눌러보시겠어요?”라는 질문을 주면, 사용자는 실제 앱 화면 위에서 직접 그 기능을 찾아가요. 이때 사용자가 얼마나 헤매지 않고 빠르게 도달했는지를 점수로 계산해요. 내비게이션이 잘 설계돼 있을수록 점수가 높아지는 거죠.사실 이런 정성적인 경험을 수치화해서 제품 개선에 활용하는 리서치 툴은 리서치 업계에서도 쉽게 보기 힘든 방식이라, 특허까지 출원했어요.이렇게 생소한 개념의 툴을 어떻게 처음부터 만들어낼 수 있었을까요? 레퍼런스 하나 없는 상태에서 처음 길을 만들어간 TNS 길드 팀원을 만나 이야기를 들어봤어요.TNS는 "사용자가 어떤 경로를 거쳐 기능에 도달하는지"를 실제 라이브 앱에서 추적하기 위해 만들어졌어요. 기존에 쓰던 EVR(Entrance conVersion Rate) 이라는 툴을 쓰고 있었는데요. 화면 단위로 사용자의 클릭을 측정할 수는 있었지만, 사용자가 여러 화면을 거치는 실제 여정을 담기엔 한계가 있었어요.예를 들어, EVR은 캡처된 특정 화면을 보여준 뒤 사용자가 어디를 클릭했는지를 확인하는 방식이에요. 정답을 클릭한 비율로 점수를 매기는 일종의 무인 사용자 테스트인 셈이죠.하지만 이 방식은 A → B → C 같은 실제 사용자의 탐색 경로를 파악할 수 없고, 정해진 화면 내에서만 행동을 측정해야 해요. 그러다 보니 복잡한 내비게이션 이슈, 즉 사용자가 어떤 경로를 헤매다 기능에 도달하는가를 이해하기 어려웠죠.실제 앱 안에서 사용자가 어떤 경로를 통해 목표에 도달했는지를 추적할 수 있는 새로운 툴이 필요하다고 생각했고, 그게 TNS예요.라이브 앱에서 테스트하는 방법을 찾다처음에는 이게 되겠어? 싶은 마음이 컸어요. 기존처럼 캡처 화면으로만 실험하던 방식이 아니라, 실제 앱 환경에서 사용자가 자유롭게 탐색하는 걸 측정해야 하니까요. 이걸 하려면 앱을 아예 복제해서 별도 환경을 만들어야 하는 건가 고민도 했었고요.맞아요. 저도 두세 달 동안 엔지니어분들한테 하나하나 찾아다니면서 이걸 어떻게 구현할 수 있을지 방법을 찾아다녔거든요. 그런데 대부분 "그건 안 되지 않나요"라는 답을 들었어요. 토스에 와서 이렇게 많이 안 된다는 말을 들어본 건 처음이었어요.그런데 어느 날 서진님이 아이디어를 주셨어요. TNS 설문에 참여 중인 사용자를 로그 상에서 별도로 식별할 수 있게 하자. 앱 로그에 TNS ID를 심어서, 이 사용자가 어떤 경로를 탐색했는지 일반 사용자의 로그와 분리해서 기록하는 방식이었어요. 이걸로 결국 라이브 앱 환경을 그대로 쓰면서도 실험 사용자의 행동만 따로 추적할 수 있게 됐어요.이게 돌파구였어요. 이걸 계기로 프로젝트가 본격적으로 시작될 수 있었죠.사실 TNS는 구현 자체가 엄청 복잡하진 않았어요. 그런데 이게 앱 전체에 적용되는 시스템이다

랭턴의 개미(Langton's Ant) 는 매우 단순한 규칙을 따르는 2차원 격자 위의 개미입니다.해당 개미는 흰색 칸에서는 시계방향으로 90도 회전하고, 칸 색을 반전(흰색->검은색, 검은색->흰색)한 뒤 한 칸 전진하며,검은색 칸에서는 반시계방향으로 90도 회전하고, 칸 색을 반전하고 한 칸을 전진하는데요,이 단순한 규칙만으로도 격자 위에 신기한 패턴을 그리게 됩니다.아래는 초기 - 중기 - 후기로 나누어 랭턴의 개미의 행동 과정을 설명한 내용입니다.처음에는 모든 격자가 흰색이고, 개미가 가운데에 위치합니다.개미는 규칙에 따라 움직이지만 초기에는 격자 위에 남기는 패턴이 매우 단순하거나 대칭적입니다.몇 백 번 움직인 후에는 격자 위에 무질서한 흑백 무늬가 형성되기 시작합니다.수천 번의 이동 후, 개미는 격자 위를 마치 무작위처럼 움직이며 불규칙하고 복잡한 패턴을 만듭니다.이 단계에서는 격자 위에 남겨지는 흑백 무늬가 매우 혼란스럽고, 어떤 규칙성도 보이지 않습니다.후기 : 질서가 생기고, 반복되는 패턴으로 안정화약 만 번의 이동 이후, 개미는 갑자기 반복적인 고속도로 패턴을 만들기 시작합니다.이 패턴은 104번 이동마다 반복되며, 개미는 이 패턴을 계속해서 따라가면서 격자 한쪽으로 빠져나갑니다.이처럼 단순한 규칙이 반복될 때 예측할 수 없는 복잡한 패턴이 나타나고, 결국에는 안정적인 반복 구조로 수렴하는 것이 랭턴의 개미의 특징입니다.랭턴의 개미와 마케팅 시뮬레이션• None 마케팅 시뮬레이션도 랭턴의 개미와 유사하게, 단순한 규칙 (ex - 고객 이동, 채널 전환 등)이 반복되면 예측 불가능한 변화와 복잡한 결과가 나타날 수 있습니다.• None 단기적으로는 변화가 불규칙하지만, 장기적으로는 랭턴의 개미처럼 안정적인 정상 상태로 수렴하는 경향이 있습니다.2. 고객 접점 점유율과 시뮬레이션• None 새로운 사업이나 서비스를 시작할 때, 고객이 어떤 채널을 주로 이용하는지, 그리고 시간이 지남에 따라 그 점유율이 어떻게 변화하는지 예측하는 것은 매우 중요합니다.• None 마르코프 체인을 활용하면 랭턴의 개미처럼 각 채널의 점유율이 '정상 상태'로 어떻게 수렴하는지 시뮬레이션할 수 있습니다.• None 기본적으로 고객들이 아래와 같은 확률로 채널 간 전이를 한다고 가정합니다.• None 상담센터 50%, 오프라인 매장 30%, 온라인 앱 15%, 웹/이메일 등 기타 5%• None 그리고 기본적으로 랭턴의 개미처럼, 고객들은 현재 채널에 대해 20%정도의 추가적인 매력도를 느낀다고 가정합니다.각 채널 별 점유율은 아래와 같은 루트를 통해 수렴하게 됩니다.초기 상태와는 달리, 50%였던 상담센터는 54% 가량으로, 30%의 오프라인 매장은 26%로, 15%였던 앱은 16%로, 5%였던 웹/이메일은 약 3% 가량으로 변경되게 됩니다.4) 현재 채널에 대해 더 큰 추가 가중치 적용만약 고객들이 경험한 채널에 대해 좀 더 애착을 가지고 자주 사용한다고 가정하고, 해당 채널에 1.4배의 가중치를 추가적으로 더 주게 되면 어떻게 바뀔까요?이 때는 초기에 큰 비중을 가지고 있던 상담센터의 비율이 매우 높아지고, 앱은 잠시 비중이 높아지다가 다시 수렴하며, 나머지 채널들은 각각 감소하는 방향으로 바뀌게 됩니다.5) 시뮬레이션 적용 - 온라인 채널의 활성화 (1단계)디지털 전환과 리소스 효율화로 인해, 온라인 채널을 활성화하려고 합니다.온라인 앱이나 웹에 추가적인 쿠폰을 주거나, 무료 배송 등의 프로모션을 진행해, 상담센터와 오프라인 매장 방문 비중을 줄이고 (-10%), 앱과 웹/이메일의 비중을 높이려고 합니다. (+20%)프로모션을 통해 고객 분들이 현재 경험한 채널에서 벗어나 좀 더 다양한 채널을 경험할 수 있게 유도하였습니다. (+40% -> -40%)하지만 오프라인 매장의 경우에는 유의미한 수치로 줄어들었지만, 상담센터의 비중은 여전히 높고, 웹/이메일의 경우 거의 비중이 변하지 않았습니다.그렇다면 좀 더 강한 프로모션을 진행해본다면 어떨까요? 기존 채널에서 벗어나진 않고는 못 버틸 정도로 매력적인 프로모션을 제공하겠습니다.6) 시뮬레이션 적용 - 온라인 채널의 활성화 (2단계)더 강력한 프로모션을 진행해, 상담센터와 오프라인 매장 방문 비중을 줄이고 (-30%), 앱과 웹/이메일의 비중을 높이려고 합니다. (+50%)강력한 프로모션을 통해 고객 분들이 현재 경험한 채널에서 벗어나 좀 더 다양한 채널을 경험할 수 있게 유도하였습니다. (-40% -> -80%)상담센터와 오프라인 매장 방문이 유의미하게 줄어들고, 앱 방문률은 큰 폭으로 늘어나 상담센터를 이은 2위로 올라갔습니다.하지만 웹/이메일의 경우 파격적인 프로모션에도 불구하고, 조금 늘어나긴 했지만 엇비슷한 값으로 수렴하게 되었습니다.실질적으로 웹/이메일의 점유율을 올리려면 전이행렬의 기본값 자체를 높이는 구조적 변화가 필요합니다.랭턴의 개미와 마르코프 체인을 활용한 시뮬레이션을 통해, 단순한 규칙이 반복될 때 초기에는 예측할 수 없는 복잡한 변화가 나타나지만,시간이 지나면 결국 안정적인 상태로 수렴한다는 사실을 확인할 수 있었습니다.채널 점유율 역시 단기적으로는 다양한 변동 요인에 따라 불규칙하게 움직이지만, 장기적으로는 각 채널의 고유한 전이 확률에 따라 정상 상태로 수렴합니다.특히, 단순한 채널 이동 확률 상승이나 강화만으로는 웹/이메일의 점유율을 크게 높이기 어렵다는 점이 시뮬레이션 결과에서 드러났습니다.웹/이메일 채널의 점유율을 높이려면 기본값 자체를 구조적으로 변경하는 마케팅 전략이 필요하다는 사실을 알 수 있었습니다.이번 시뮬레이션은 단순한 초기 상태와 확률을 통한 간단한 시뮬레이션이지만, 고객의 채널 경험을 유도하거나 점유율을 예측하는 작업이 얼마나 복잡하고 어려운지,그리고 데이터 기반의 구조적 접근이 얼마나 중요한지 실감할 수 있었습니다.아래는 랭턴의 개미 시뮬레이션을 파이썬으로 구현한 예시입니다. 이 코드를 통해 랭턴의 개미를 각 단계별로 시뮬레이션 해보실 수 있습니다.

안녕하세요. SK Hynix의 AI Transformation 팀 김지수입니다.이번에 업무를 진행하면서 redis sub / pub 구조를 고민하게 된 과정 대해 공유 차 작성하게 되었습니다.비슷한 고민이 있으시다면 함께 나눠보면 좋을 것 같네요.우선 서버-인스턴스 간 통신을 통해 특정 작업을 진행하는 과정이 있습니다.기존엔 SSH를 통해 인스턴스에서 작업을 지시하는 방식으로 구현되었으나 대량의 작업이 필요할 경우,서비스의 고도화를 위해 다수의 클라이언트 서버와 통신해야 하는 과정에서 병목이 발생하였습니다.이해를 돕기 위해 간단하게 도식화 해보면 다음과 같습니다.자 그럼 이 문제를 해결하기 위해 어떤 고려 사항이 있을지 정리해보면..• None client, worker, pod의 개수가 가변적정도가 있겠네요다음으로는 병목의 주 원인이었던 SSH 구조를 대체할 만한 프레임워크를 프롬프트를 통해 정리해 보았습니다.저희는 Latency가 크게 중요하지 않으며 구성 서버들이 가변적이므로 비동기 방식을 항상 channel을 subscribe 하는 worker를 둔다면 로깅 문제도 해결할 수 있겠네요.표로 보았을 때, redis Pub/Sub 구조가 가장 적당해 보입니다.그럼 pub / sub 구조로 구현하는 것으로 하고 한 번 자세한 개념을 알아보죠.Redis Pub/Sub은 Redis의 기능을 활용한 메시지 브로커 시스템의 일종입니다.이 시스템은 데이터를 '발행자'(publisher)가 특정 '채널' 또는 '주제'(topic)에 메시지를 보내면,이 채널을 구독하고 있는 '구독자'(subscriber)들이 메시지를 받아 처리할 수 있도록 해주는 통신 방식입니다.유튜브 채널 구독과 비슷하게, 크리에이터가 새 글을 발행하면 구독자에게 알림이 오는 원리와 유사하다고 설명될 수 있습니다.아하~ 위 예를 보면 인스턴스(publisher)가 무수히 많이 늘어나더라도 간단하게 서버와 인스턴스 간 Pub / Sub 으로 비동기 통신을 구현할 수 있겠네요. 아래 그림처럼 말이죠.cursor로 Mockup code도 요청해 보았습니다.실제 구현은 좀 다르게 되겠지만 의도대로 동작하는 코드가 만들어졌습니다.

해당 이미지는 OpenAI의 이미지 생성 모델 DALL·E를 활용하여 GPT-4o에서 생성한 이미지입니다.안녕하세요! 당근 채팅팀에서 백엔드 엔지니어 인턴으로 일하고 있는 카펠이에요. 이 글에서는 연간 LLM 호출 비용을 약 25%, 연간 2.1억 원가량 절감한 프로젝트를 소개해보려고 해요.당근에서는 AI를 다양한 프로덕트에 적극적으로 활용하고 있는데요. 그중 하나가 채팅창에서 대화 흐름에 맞춰 다음 문장을 자동으로 추천해 주는 AI 메시지 추천 기능이에요. 이 기능은 사용자들의 채팅 경험을 더욱 편리하게 개선했지만, LLM 호출 비용이 과도하게 높다는 문제가 있었어요. AI를 잘 활용하면서도 비용을 효율적으로 관리하는 게 중요한 과제였던 거죠.저는 시맨틱 캐싱(Semantic Caching)이라는 기술을 실제 프로덕션 환경에 적용해 비용을 크게 절감해 냈어요. 시맨틱 캐싱은 기존 캐싱 기법과는 달리 문장 간 의미 유사도를 고려해, 표현은 달라도 의미가 비슷한 요청에 캐싱이 동작하도록 하는 기법이에요.이 프로젝트는 제가 인턴 생활 중에 직접 문제를 발견하고 아이디어를 제안해 주도적으로 진행했던 경험이기도 해요. 기술적으로도, 개인적으로도 큰 의미가 있었던 여정을 공유해 볼게요.과제 정의 및 해결 아이디어 도출1. 채팅 추천 기능의 도입, 그리고 LLM 호출 비용 문제당근에서 중고거래 채팅, 다들 한 번쯤 해보신 적 있으시죠? 이때 거래 시간을 정하거나 또 가격을 조율할 때 자주 쓰게 되는 말들이 있어요. 그런데 이런 문장들을 매번 키보드로 일일이 입력하려니 은근 번거로울 때가 있어요. 이런 불편함에 주목한 당근 채팅팀은, 사용자가 더 간편하게 대화하고 빠르게 거래할 수 있도록, LLM이 상황에 맞는 문장을 똑똑하게 추천해 주는 AI 추천 메시지 기능을 만들게 되었어요.AI 추천 메시지 기능은 LLM이 대화의 흐름을 실시간으로 파악해, 다음에 이어질 만한 적절한 문장을 2개 이상 추천해 주는 기능이에요. 이 기능 덕분에 사용자는 텍스트를 키보드로 직접 입력하지 않고도, 추천된 문장을 탭 한 번으로 보내며 더욱 빠르고 간편하게 중고거래를 이어갈 수 있어요. 실제로 이 기능은 사용자들로부터 많은 관심과 호응을 받고 있어요.그런데 여기에는 LLM 호출 비용이라는 현실적인 큰 장애물이 있었어요. 당근에서는 하루에 오가는 메시지만 해도 1,000만 건이 넘기 때문에, 이 기능을 모든 사용자에게 제공하려면 그 트래픽만큼이나 빈번하게 LLM을 호출해야 했거든요. 내부 추산에 따르면 연간 비용이 약 8~9억 원에 이르는 수준이었어요. 이처럼 막대한 비용은 기능 확장에 중요한 제약으로 작용했고, 당근 채팅팀은 이를 해결하기 위한 다양한 방법을 고민하게 되었어요.2. 캐싱 기반의 해결 아이디어 제안가장 먼저 떠올린 방법은 캐싱 기법이었어요. 캐싱은 자주 바뀌지 않는 데이터를 미리 저장해 두고, 동일한 요청이 들어왔을 때 DB 조회나 API 호출 없이 바로 저장된 데이터를 반환하는 방식이에요.하지만 이 방식은 요청 문장이 미리 저장된 문장과 완전히 동일할 때만 캐시 HIT이 발생해요. 예를 들어 안녕하세요! 라는 문장을 캐싱해 두었다면, 정확히 똑같은 문장 안녕하세요! 가 다시 들어와야만 캐싱이 동작해요.그런데 이 부분을 단순한 문자열 일치가 아니라, 의미 기반의 유사도를 활용한다면 어떨까 하는 아이디어가 떠올랐어요. 코사인 유사도와 같은 거리 기반 유사도 계산을 활용해서 문장 간 의미가 얼마나 가까운지를 측정하고, 그 거리가 일정 임계값 이상이라면 같은 의미라고 판단해 캐시 HIT를 적용하는 방식이에요.이렇게 동작하는 것이 바로 시맨틱 캐싱이에요. 예를 들어 안녕하세요! 라는 문장에 대해 시맨틱 캐싱이 되어 있다면, 안녕하셨어요! 나 안녕하신가요? 처럼 형태는 다르지만 의미가 유사한 문장도 캐시 HIT으로 처리할 수 있어요.3. 시맨틱 캐싱 도입 시 비용 절감 예상 효과우선 LLM을 직접 호출해 응답을 생성하는 기존 방식의 비용부터 계산해 볼게요. 이 경우 연간 약 9억 원의 비용이 발생할 수 있는데, 이를 하루 단위로 환산하면 다음과 같아요:다음으로는 시맨틱 캐싱을 적용했을 때의 비용을 계산해 볼게요. 예를 들어 OpenAI의 text-embedding-3-small 모델을 사용할 경우, 100만(1M) 토큰당 $0.02의 비용이 발생해요.이때 계산을 단순화하기 위해 하루 1,000만 건의 채팅 요청 중 100% 모두가 캐시 HIT된다고 가정해 볼게요. 또 문장 하나당 평균적으로 5~7 단어, 약 5토큰이라고 본다면, 시맨틱 캐싱을 위한 하루 임베딩 비용은 다음과 같은 방식으로 계산할 수 있어요:즉, 하루 약 247만 원에 달하는 LLM 호출 비용과 비교해 보면, 시맨틱 캐싱은 하루 1,400원(약 1달러) 수준으로 운영할 수 있어요. 이는 무려 1,760배나 저렴하기 때문에, 비용 측면에서 매우 큰 이점을 확인할 수 있었어요.물론 현실적으로 캐시 HIT이 100% 발생하는 경우는 거의 없어요. 따라서 실제 절감 효과는 시맨틱 캐싱의 HIT 비율에 따라 달라지게 되어요. 다시 말해, HIT 비율이 높아질수록 LLM 호출 횟수가 감소하고, 그만큼 API 비용도 더 크게 절감할 수 있어요.현재 진행 중인 Phase 1에서는 약 25% 수준의 캐시 HIT 비율을 목표로 하고 있어요. 이 경우, 전체 LLM 호출 비용의 약 24%에 해당하는 연간 2.16억 원의 비용을 절감할 수 있어요. 더 나아가, 궁극적으로는 HIT 비율을 50% 이상으로 끌어올리는 것을 목표로 하고 있어요. 아래에 캐시 HIT 비율에 따른 예상 비용 절감 효과를 정리한 표를 함께 보여드릴게요:시맨틱 캐싱 아키텍처 설계 및 구현1. 시맨틱 캐싱 서버 구현과 성능 최적화 전략시맨틱 캐싱을 처리하는 서버는 메인 서버와 분리된 add-on 형태로 구성했으며, 서로 간의 통신은 gRPC 프로토콜을 통해 이루어지고 있어요. 이처럼 분리형 구조를 채택한 이유는, 기존 서비스 로직에 영향을 주지 않으면서도 시맨틱 캐싱 기능을 독립적으로 운영하고 유연하게 확장할 수 있도록 하기 위함이었어요.또한, 유사도가 임계값을 넘지 못해 캐시 미스가

안녕하세요. 카카오에서 AI를 연구개발하는 카나나(Kanana) - Visual Content Generative AI팀의 Orca입니다. 저희 팀에서는 고품질의 이미지와 동영상 등 시각 콘텐츠를 생성하는 비주얼 생성 모델을 연구하고 있습니다. 지난 if(kakaoAI) 2024에서 나만의 프로필 이미지 생성 모델 개발기 발표를 통해서도 저희 팀의 연구 성과를 공유드린 바 있는데요.이번에는 저희 연구가 ‘CVPR(Computer Vision Pattern Recognition) 2025’에 하이라이트 논문(Highlight paper)으로 선정되어, 지난 6월 11일부터 15일까지 미국 테네시주 내슈빌에서 열린 ‘CVPR(Computer Vision Pattern Recognition) 2025’ 학회에 직접 다녀올 수 있었습니다. CVPR은 컴퓨터 비전 분야에서 세계 최고 권위를 지닌 국제 학술대회로, 매년 전 세계의 최신 연구 성과와 기술 트렌드가 공유되는 자리입니다.이번 글에서는 현장에서 확인한 생성 모델의 연구 동향과 저희가 발표한 인물 이미지 생성 기술 관련 “Boost Your Human Image Generation Model via Direct Preference Optimization” 논문에 대해서도 간략히 소개해 드리고자 합니다.생성 모델은 현재 가장 활발히 연구되고 있는 분야 중 하나로, 이번 CVPR에서도 굉장히 많은 생성 모델 연구를 확인할 수 있었습니다. 우선 Diffusion model을 이용한 이미지 생성 모델 연구가 가장 활발한 분야 중 하나였습니다. 이러한 Diffusion model 기반의 이미지 생성 모델을 이용한 Personalized text-to-image와 같은 응용 연구도 활발히 이루어지고 있었고, 이미지 생성을 넘어서 Diffusion model을 이용한 비디오 생성 모델 연구도 굉장히 활발하게 이루어지고 있었습니다.실사에 가까운 고품질 이미지 생성하기이어 저희 발표 논문 “Boost Your Human Image Generation Model via Direct Preference Optimization”을 소개해보겠습니다. 저희 논문은 앞서 소개한 Diffusion model을 기반으로 한 인물 이미지 생성 관련 연구입니다. 전체 발표 논문 중 13.5%에 해당되는 하이트라이트 논문(Highlight paper)에 선정되며 그 기술력을 인정받았습니다.저희가 진행한 연구는 고품질 인물 이미지를 생성하는 것을 목표로 합니다. 인물 이미지 생성은 인체 구조나 포즈가 조금만 어색해도 품질이 저하되기 때문에 난이도가 어려운 과제입니다. 아래 이미지에서도 볼 수 있듯이, 고품질 인물 이미지 데이터셋으로 Fine-tuning된 Base model마저도 만족스러운 품질의 인물 이미지를 생성하지 못하는 문제가 있었습니다. 저희가 제안하는 HG-DPO 방식을 이용하면, Base model을 개선시켜 효과적으로 고품질 인물 이미지를 생성할 수 있습니다.Base model과 성능을 개선시킨 HG-DPO 모델의 생성 이미지 비교저희는 이를 위해 기존 LLM Alignment 분야에서 사용되던 Direct Preference Optimization(DPO) 기법을 Diffusion 기반 이미지 생성 모델에 접목했습니다. DPO는 하나의 Input에 대해 인물이 더 선호하는(Winning) 결과와 덜 선호하는(Losing) 결과 쌍을 학습 데이터로 모델에 제공해, 사람들이 더 선호하는 결과를 생성하도록 모델을 학습시키는 방법입니다. HG-DPO의 목적은 DPO를 이용하여 Base model을 한 번 더 Fine-tuning 시킴으로써 인물 이미지 생성 성능을 극대화시키는 것입니다. 이를 통해 실사에 가까운 고품질의 자연스러운 이미지를 생성할 수 있습니다.기존 방식들의 한계와 HG-DPO의 전략DPO는 최근 LLM Alignment를 넘어 이미지 생성 분야로도 확장되어 Diffusion-DPO와 같은 방법들이 등장했습니다. 하지만, 인물 이미지는 굉장히 높은 사실성을 필요로 하기 때문에, 이러한 기존 방법들을 그대로 적용하기에는 한계가 존재합니다. 그것은 기존의 방법들이 생성 이미지들만을 이용하여 Winning과 Losing 이미지 쌍을 구성하여 학습하기 때문에 학습 가능한 이미지 품질의 상한선이 낮다는 것입니다. 생성된 이미지는 그 품질이 아무리 좋더라도, 실사의 품질에는 미치기 어려운데요. 그 결과, 인물의 디테일이나 모델이 학습할 수 있는 표현력에 한계가 생기게 됩니다.전략 1: 학습 데이터에 실사 도입이러한 한계를 뛰어넘기 위해, HG-DPO는 첫 번째 전략으로 기존 DPO 방식들과 다르게 실사를 Winning 이미지로, 생성 이미지를 Losing 이미지로 삼는 새로운 DPO 학습 방식을 사용합니다. 이를 통해 모델이 단순히 생성 이미지 중 상대적으로 나은 수준의 품질을 추구하는 것을 넘어, 실사 수준의 품질을 추구하도록 유도할 수 있습니다.전략 2: 안정적인 학습을 위한 Curriculum learning 기반의 3단계 학습 방식 도입하지만, 위의 전략을 기반으로 한 단순 Single stage 학습은 좋은 결과로 이어지지 못했습니다. 이러한 문제에 대해 저희는 저희의 전략을 Single stage로 수행하는 것이 너무 어렵다고 가정하고, 두 번째 전략으로 여러 Stage로 이루어진 Curriculum learning 방식을 도입했습니다.Curriculum learning은 모델을 쉬운 방법으로 먼저 학습시키고, 점진적으로 어려운 방법으로 학습시키는 방식으로 모델을 더욱 안정적으로 학습시킬 수 있습니다. HG-DPO의 Curriculum learning은 아래 이미지와 같이 Easy, Normal, 그리고 Hard stages를 통해 수행됩니다. 각 Stage마다 학습 난이도를 점차 높이며, 모델은 실사와 비슷한 이미지를 생성할 수 있도록 학습됩니다.Easy stage에서는 실사의 품질을 추구하기 전에, 기본적으로 사람들에게 선호되는 이미지를 생성하는 방법을 학습합니다. 이 Stage에서는 실사를 사용하지 않고, 생성된 이미지만을 사용합

안녕하세요. SK텔레콤의 정지헌입니다.Language model의 새로운 패러다임 Large Language Diffusion Model, 일명 LLaDA라고 불리는 논문을 소개하려고 합니다.개인적으로 Diffusion model에 관심이 있고 Language model에 사용한 것이 재밌어서 유심히 읽어보게 되었고 여러 가지 활용 방법들을 구상 중에 있습니다.우선 왜 Vision쪽에서 활용되던 Diffusion model이 Language에 사용되고, 적용되고 있는 지 알아보고자 합니다.지금의 대형 언어모델의 성능에서는 너무 뛰어나지만, 대부분 Autoregressive(AR) 방식 (Left-to-Right)으로 학습 및 생성합니다.약점이 전혀 없을 것 같지만 이 구조에는 세 가지 고질적 약점이 있습니다.• None Exposure bias: 추론 때 모델이 스스로 낸 오류를 계속 입력으로 받아 악순환이 벌어집니다.• None 길이 편향: 로그확률 합을 극대화하려다 보니 응답을 지나치게 짧게 끝내거나 불필요하게 길게 늘어뜨리곤 합니다.• None 장기 의존 실패: 순차 생성 특성상 먼 거리 토큰 간 일관성을 유지하기가 어렵습니다.이를 고치려고 scheduled sampling, Prefix LM, 고급 디코딩 기법 등을 시도했지만, 모두 AR 틀 안에서 부분 수정을 가한 정도에 머물렀습니다.하이퍼파라미터가 민감하거나, 짧은 문장엔 효과가 있어도 길고 복잡한 context에서는 오류 누적을 막지 못합니다.Diffusion 이 무엇인가요?이미지 생성 분야에서 두각을 나타낸 Diffusion(확산) 모델은 무작위 노이즈를 넣었다가 조금씩 걷어 내어 데이터를 복원하는 방식을 자연어 영역으로 확장했습니다.이미지에서 성공한 Diffusion기법 즉, 노이즈를 넣고 단계별로 걷어내며 복원 하는 방식을 그대로 자연어에 적용한 것이 Diffusion LM입니다.AR 모델은 토큰을 왼쪽에서 오른쪽으로 하나씩 예측하기 때문에, 앞서 틀린 토큰이 계속 영향을 미치는 exposure bias와 긴 문장에서 뒤쪽 품질이 떨어지는 길이 편향 문제가 있었습니다.반면에, Diffusion LM은 문장 전체(또는 넓은 블록)를 여러 단계에 걸쳐 반복 정제합니다.한 단계에서 잘못 생성된 토큰도 다음 단계에서 다시 고칠 수 있으므로 exposure bias가 줄어들고, 주어진 컨텍스트 윈도 안에서 전역적 일관성을 확보하기 쉽다고 합니다.훈련(Forward) 단계에서는 일정 비율의 토큰을 로 가려 노이즈를 만듭니다.그 이후 추론(Reverse) 단계에서는 모든 토큰이 상태에서 시작해 마스크를 단계적으로 지우며 디노이징을 수행합니다.일부 구현에서는 중간에 다시 re-masking을 넣어 세밀하게 수정하는 과정을 반복해 “한꺼번에 문장을 그려 넣는다”는 이상적인 생성 방식으로 문장을 생성하게 됩니다.즉, AR은 한 단계에서 틀린 토큰을 다음 단계에서 되돌릴 수 없지만, Diffusion LM은 문장 전체를 반복 정제하기 때문에,exposure bias가 줄어들고, context window 내에서 일관성을 확보하기 쉽습니다.위 내용을 그림으로 좀 더 직관적으로 살펴보겠습니다.LM에서의 Diffusion생성 모델에서의 확산 모델은 데이터를 점진적으로 노이즈화한 뒤, 역방향으로 노이즈를 제거하면서 원본을 복원하도록 학습되는 모델입니다.노이즈 혹은 어떠한 방법으로 원본 데이터를 훼손을 시키고, 다시 훼손시키는 것을 복구하는 방법을 학습해 완전 노이즈인 상태에서 부터 생성을 시작하는 아이디어를 갖고 있고,두 가지 주요 process가 존재합니다.• None 이미지 같은 연속 데이터에서는 단계 t마다 가우시안 노이즈를 더합니다.• None 텍스트처럼 이산 토큰으로 이루어진 데이터에서는 단계마다 일부 토큰을 로 바꿔 노이즈를 만들어줍니다.• None 이 process에서 노이즈를 어떻게 복원시킬 것인가를 학습하게 됩니다. 연속형 데이터의 경우 epsilon을 학습하거나 (stein) score 를 학습합니다. 사실 epsilon과 score는 수식적으로 큰 차이는 없습니다. 이산 토큰에서는 을 다시 어떤 Token으로 예측할 지 학습하게 됩니다.• None 학습된 모델이 가장 강한 노이즈 상태에서 출발해 단계 번호를 하나씩 줄여 가며 노이즈를 걷어 냈습니다.• None 연속 도메인에서는 스코어 매칭을 통해 노이즈 자체를 예측했고, 이산 도메인에서는 Masked-LM 손실이나 Rao-Blackwellized Cross-Entropy(RB-CE) 손실을 이용해 위치의 정답 토큰 분포를 맞히도록 학습했습니다.텍스트 Diffusion LM의 학습에서는 토큰이 한 번 마스크되면 다시 원본으로 돌아가지 않는 흡수 상태가 됩니다. 이렇게 두 가지 상태(마스크 / 비-마스크)만 고려하면, 원래 Diffusion ELBO에서 요구하던 복잡한 KL 계산 대신 마스크 위치에서 올바른 토큰을 맞히도록 하는 가중 Cross-Entropy 하나로 목적 함수를 단순화할 수 있었습니다. 에서 실제 데이터 분포 q를 살펴보면 Mask/Non-mask로 구분될 수 있습니다. 따라서, 으로 정의될 수 있고, 부분에서는 t번째 z가 원본 토큰이라면, posterior가 Dirac-delta로 deterministic하게 됩니다. Rao-Blackwellization 후에는 “현재 토큰이 [MASK]일 때만 1, 아닐 때는 0”인 indicator가 KL 앞 가중치에 곱해지기 때문에, 자리의 KL 기여도는 실제로 0이 됩니다. 그러므로 부분만 고려하게 된다면, Rao-Blackwellized CE으로 변경될 수 있고, 이 손실 함수를 쓰면• None Monte-Carlo 샘플링이 줄어들어 분산이 낮아졌고, (Rao-Blackwell theorem)• None 기존 Masked-LM 코드베이스를 거의 그대로 활용할 수 있고,• None 다양한 노이즈 수준을 고려해 학습했기 때문에 다양하고 일관된 문장을 생성할 수 있습니다.autoregressive모델이 next token을 예측하는 것이라면, diffusion 모델은 쉽게 말해서 Mask token pr