주요소식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위로 올라갔습니다.하지만 웹/이메일의 경우 파격적인 프로모션에도 불구하고, 조금 늘어나긴 했지만 엇비슷한 값으로 수렴하게 되었습니다.실질적으로 웹/이메일의 점유율을 올리려면 전이행렬의 기본값 자체를 높이는 구조적 변화가 필요합니다.랭턴의 개미와 마르코프 체인을 활용한 시뮬레이션을 통해, 단순한 규칙이 반복될 때 초기에는 예측할 수 없는 복잡한 변화가 나타나지만,시간이 지나면 결국 안정적인 상태로 수렴한다는 사실을 확인할 수 있었습니다.채널 점유율 역시 단기적으로는 다양한 변동 요인에 따라 불규칙하게 움직이지만, 장기적으로는 각 채널의 고유한 전이 확률에 따라 정상 상태로 수렴합니다.특히, 단순한 채널 이동 확률 상승이나 강화만으로는 웹/이메일의 점유율을 크게 높이기 어렵다는 점이 시뮬레이션 결과에서 드러났습니다.웹/이메일 채널의 점유율을 높이려면 기본값 자체를 구조적으로 변경하는 마케팅 전략이 필요하다는 사실을 알 수 있었습니다.이번 시뮬레이션은 단순한 초기 상태와 확률을 통한 간단한 시뮬레이션이지만, 고객의 채널 경험을 유도하거나 점유율을 예측하는 작업이 얼마나 복잡하고 어려운지,그리고 데이터 기반의 구조적 접근이 얼마나 중요한지 실감할 수 있었습니다.아래는 랭턴의 개미 시뮬레이션을 파이썬으로 구현한 예시입니다. 이 코드를 통해 랭턴의 개미를 각 단계별로 시뮬레이션 해보실 수 있습니다.