NAVER D2 최신 글
d2.naver.com에서 발행한 기술 글을 테크곳간이 수집해 최신순으로 보여드립니다.
최신 글
딸깍으로 안되는 Multi-interest 개발기
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. 딸깍으로 안되는 Multi-interest 개발기 NAVER D2 | 딸깍으로 안되는 Multi-interest 개발기 naver.me 발표 내용 다양한 관심사 추천 모델인 Multi-interest를 여러 지면에 적용하며 겪었던 문제를 해결했던 과정을 공유합니다. 주제: Multi-interest 추천 모델(MINER)의 KREAM 실서비스 적용 사례 문제: 인기 상품 목록에서 특정 상품이 전체 유저에게 동시 노출되는 hubness 발생 분석: 점수를 유저 의존 성분과 유저 무관 성분으로 분해, 가설 3개를 실측으로 검증 조치: 유저 무관 성분 제거(centering, bias 분리), 추천 결과 다양화, 분포 지표 기반 평가 체계 도입 결과: 과노출 상품 전량 제거, 노출 상품 종류 +25%, 구매 지표 유지 시사점: 논문 구조의 실서비스 적용 시 발생하는 문제와 사전 점검 항목 발표 대상 Multi-interest 추천 모델에 관심 있으신 분들 목차 문제상황 가설 수립, 유저 의존 성분 + 유저 무관 성분 전략 1. 유저 무관 성분 낮추기 전략 2. 유저 유관 성분 높이기 전략 3. 두 성분을 지표에서 모니터링 남은 과제 및 점검항목 ◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
2026년 11월 3일
컨테이너처럼 쓰고, VM처럼 격리하기
네이버 사내 기술 교류 행사인 NAVER Engineering Day 10th 에서 발표되었던 세션을 공개합니다. 컨테이너처럼 쓰고, VM처럼 격리하기: kata-containers with GPU NAVER D2 | 컨테이너처럼 쓰고, VM처럼 격리하기: kata-containers with GPU naver.me 발표 내용 Kubernetes GPU 노드를 VM으로 격리해 나눠 쓰면서, 호스트 수준의 성능까지 최적화한 방법을 소개합니다. 발표 대상 여러 사용자가 GPU node를 함께 쓰는 환경에서 격리를 강화하려는 플랫폼 개발자 Kubernetes에서 kata-containers나 VM 기반 runtime 도입을 검토하는 개발자 DRA로 GPU·NIC 같은 device 할당을 직접 구현하려는 개발자 VM 환경에서 GPU·IB·storage 성능을 bare metal 수준으로 맞추려는 개발자 발표자료 국문 영문 목차 도입 배경과 kata-containers의 구조 GPU와 NIC를 VM에 함께 할당하기 VM 부팅 시간과 성능 개선하기 마무리: 사용자가 작성하는 Pod spec과 bare metal 대비 성능 ◎ NAVER Engineering Day란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 이제는 매회 평균 100개 이상의 발표가 이루어지는 NAVER Engineering Day를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다.(관련 포스팅 보기) 올해 진행된 NAVER Engineering Day의 일부 세션을 공개합니다. [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
2026년 11월 2일
모두가 함께 성장하는 기술 축제, NAVER Engineering Day 10년의 여정
기술은 혼자 완성되지 않습니다. 한 사람이 발견한 문제와 해결 과정이 동료에게 전해지고, 그 경험이 또 다른 시도와 개선으로 이어질 때 조직의 기술은 앞으로 나아갑니다. NAVER Engineering Day는 이런 믿음에서 출발했습니다. 2016년, 실무에서 얻은 개발 경험과 새로운 기술 및 플랫폼을 도입하며 배운 점을 나누는 사내 개발자 행사로 시작해 올해 10주년을 맞았습니다. 그동안 Engineering Day는 발표자가 정리한 지식을 듣는 자리를 넘어, 서로의 경험을 연결하고 각자의 업무 문제를 함께 해결하는 장으로 꾸준히 확장돼 왔습니다. 특히 AI가 특정 직군의 전문 도구를 넘어 일하는 방식 전반을 바꾸기 시작하면서 기술을 나눈다는 말의 의미도 달라졌습니다. 중요한 것은 새로운 도구를 아는 데 그치지 않고, 내 문제에 적용해 보고 막히는 지점을 동료와 함께 풀어 보는 경험입니다. 10주년 Engineering Day는 이러한 변화에 맞춰 전 직군이 함께 온라인 세션, 오프라인 워크숍, AI 오픈 코칭데이로 이어지는 4일간의 여정으로 진행됐습니다. 10년 동안 이어진 동료의 경험 Engineering Day의 중심에는 늘 구성원이 직접 준비한 이야기가 있었습니다. 완성된 기술을 소개하는 데 그치지 않고, 실제 업무에서 마주한 문제와 선택, 시행착오, 그 과정에서 얻은 교훈을 나눴습니다. 주제의 범위도 기술 환경과 함께 넓어졌습니다. 백엔드, 데이터, 모바일을 비롯한 개발 분야부터 AI 도구를 활용한 업무 개선과 협업 방식까지, 서로 다른 역할의 구성원이 각자의 관점에서 경험을 꺼내 놓았습니다. 발표를 통해 한 사람의 경험은 여러 동료가 다시 활용할 수 있는 지식이 됐고, 질문과 대화는 다음 실험의 출발점이 됐습니다. Engineering Day가 10년 동안 이어질 수 있었던 힘은 거창한 구호보다 이 단순한 선순환에 있습니다. 먼저 경험한 동료가 기꺼이 나누고, 다른 동료가 자신의 업무에 맞게 다시 시도하며, 그 결과를 또다시 공유하는 문화입니다. 서로의 경험을 발견하는 온라인 세션 첫날에는 구성원들이 직접 준비한 온라인 세션이 열렸습니다. 발표자들은 성공 사례만 소개하지 않았습니다. 문제를 어떻게 정의했는지, 어떤 선택지 사이에서 고민했는지, 실제 적용 과정에서 무엇이 기대와 달랐는지까지 공유했습니다. 덕분에 참가자들은 익숙한 분야의 지식을 확장하는 동시에 평소 접하기 어려웠던 다른 직무의 문제 해결 방식도 살펴볼 수 있었습니다. 온라인 세션은 기술을 '아는 것'에서 시작하는 단계였습니다. 이어진 프로그램에서는 이 지식을 직접 다뤄 보고 각자의 업무와 연결했습니다. 더 나아가 네이버 내부에서만 그치지 않고, 다음 주 부터 Engineering Day에서 발표된 30여개의 온라인 세션을 D2를 통해서 공개할 예정입니다. 두 손으로 따라하며 내 것으로 만드는 워크숍 이어서 오프라인 워크숍을 진행했습니다. 참가자들은 설명을 듣는 데 머물지 않고, 준비된 예제와 각자의 과제를 직접 다루며 기술을 적용했습니다. 워크숍에서는 개발자를 위한 심화 기술뿐 아니라 비개발 직군의 AI 협업, 디자이너와 개발자의 연결 등 다양한 역할에서 활용할 수 있는 주제를 함께 다뤘습니다. 같은 도구도 맡은 업무와 해결하려는 문제에 따라 쓰임이 달라졌고, 참가자들은 실습 과정에서 동료와 의견을 나누며 각자에게 맞는 활용 방식을 찾았습니다. 이 과정은 기술 공유의 효과가 좋은 설명만으로 완성되지 않는다는 점을 보여 줬습니다. 직접 실행해 보고, 예상과 다른 결과를 확인하고, 그 이유를 함께 짚어 볼 때 지식은 비로소 자신의 경험이 됩니다. 각자의 경험으로 함께 고민하는 AI 오픈 코칭데이 마지막 날에는 올해 처음으로 AI 오픈 코칭데이를 열었습니다. 온라인 세션에서 개념을 익히고 워크숍에서 실습했더라도, 실제 업무에 적용하려는 순간에는 새로운 질문이 생깁니다. 어디서 시작해야 할지, 문제를 어떻게 나눠야 할지, 현재 방식에서 무엇을 바꿔야 할지 막막할 수 있습니다. AI 오픈 코
2026년 10월 30일
사이드카의 선언적 관리: OpenKruise SidecarSet 도입과 운영
Kubernetes에서 서비스를 운영하다 보면 메인 컨테이너 옆에 사이드카(sidecar) 컨테이너를 붙이는 일이 흔합니다. 사이드카에는 로그와 메트릭 수집, 프록시처럼 주 기능은 아니지만 같은 Pod 안에서 함께 실행되어야 하는 기능이 포함됩니다. 저희 팀이 운영하는 관리형 데이터베이스 서비스도 DB 인스턴스를 Pod 단위로 실행하고, 그 Pod에 DB 컨테이너 외에 헬스 체크, 메트릭과 로그 수집 등을 위한 사이드카를 함께 둡니다. 이 사이드카들은 DB와 같은 데이터 볼륨에 접근해야 하므로 같은 Pod 안에 있어야 하지만, 라이프사이클은 DB와 다릅니다. DB는 한 번 실행하면 몇 달씩 그대로 운영하는 반면, 사이드카는 기능 추가와 버그 수정, 보안 패치로 훨씬 자주 바뀝니다. 사이드카가 바뀔 때마다 그 변경을 모든 인스턴스에 반영해야 하는데, DB 서비스는 유지한 채 실행 중인 Pod의 사이드카만 바꿔야 합니다. 사이드카는 모든 DB Pod에 붙으므로 이 작업은 인스턴스 수만큼 반복됩니다. 그 결과 반영 시점이 인스턴스마다 다를 수 있고, 사이드카 종류가 여럿이면 버전 조합도 인스턴스마다 제각각이 됩니다. DB Pod는 오래 실행되니 이 상태가 그대로 굳어지고, 어떤 인스턴스에 어떤 버전이 실행 중인지 알려면 Pod를 하나씩 조회해야 합니다. 사이드카 수가 늘수록 형상 관리와 배포, 모니터링이 모두 어려워집니다. 이 글은 Kubernetes 환경에서 사이드카를 운영하는 독자를 대상으로, 사이드카를 선언적으로 관리할 수단으로 OpenKruise SidecarSet을 도입한 이유, SidecarSet의 기능과 동작 방식, 운영하며 알게 된 점을 다룹니다. 사이드카 관리의 어려움: 형상 관리, 배포, 모니터링 사이드카를 관리하려면 사이드카 이미지를 한곳에 선언하는 형상 관리, 선언을 실행 중인 Pod에 적용하는 배포, 결과를 조회하는 모니터링이 필요합니다. 그런데 Kubernetes만으로는 이 세 가지가 모두 어렵습니다. 예를 들어 로그 수집 사이드카의 이미지를 바꾸면, 그 사이드카가 들어간 모든 DB Pod에 같이 적용되어야 합니다. 하지만 Kubernetes에서 사이드카 이미지는 Pod 스펙이나 Deployment, StatefulSet의 Pod 템플릿마다 따로 지정되어 있어서 한 번에 바꿀 방법이 없습니다. Pod 템플릿을 고치면 Kubernetes가 Pod를 다시 만들면서 새 이미지를 적용합니다. 하지만 이 과정에서 DB 컨테이너도 함께 재시작되므로 사이드카를 바꿀 때마다 이 방법을 쓸 수는 없습니다. DB는 그대로 둔 채 사이드카만 바꾸려면 실행 중인 Pod의 이미지를 직접 수정(in-place 갱신)해야 합니다. 이때 kubelet은 이미지가 바뀐 컨테이너만 다시 시작하므로 DB 컨테이너는 영향을 받지 않습니다. 다만 이렇게 수정할 수 있는 컨테이너 스펙은 이미지뿐이고, 수정도 Pod마다 따로 해야 합니다. 사이드카 이미지가 바뀔 때마다 대상 Pod를 찾아 하나씩 고치는 일은 Kubernetes가 해 주지 않습니다. 조회도 같은 한계가 있습니다. Deployment, StatefulSet의 status에 updatedReplicas가 있지만 템플릿 기준이므로, Pod에서 직접 바꾼 이미지는 집계되지 않습니다. 반영 여부를 확인하려면 Pod마다 status에 기록된 이미지를 선언과 하나씩 비교해야 합니다. Kubernetes는 워크로드 단위의 재생성과 Pod 하나의 이미지 교체까지만 제공합니다. 여러 워크로드의 사이드카를 한곳에 선언하고, DB를 유지한 채 실행 중인 Pod에 반영하며, 그 결과를 조회하려면 별도의 수단이 필요합니다. 직접 만들 것인가, 가져다 쓸 것인가 가장 단순하게는 대상 Pod를 순회하며 사이드카 이미지를 패치하는 스크립트를 만들 수 있습니다. 그런데 스크립트는 실행한 순간의 Pod 목록에 패치를 보내고 끝나므로, 패치가 실제로 반영됐는지 확인하고 실패한 Pod에 패치를 다시 보내려면 또 다른 스크립트가 필요합니다. 실행 뒤에 생긴 변화도 마찬가지입니다. 사람이 직접 이미지를 되돌린
2026년 10월 29일
AI 시대의 개발자를 꿈꾸는 학생 개발자에게
시작하며: 2018년과 2026년 사이의 간격과 격변기의 고민 2018년에 저는 '백엔드 개발자를 꿈꾸는 학생개발자에게'라는 글을 이곳 D2 블로그에 공유했습니다. 당시 학생 개발자들과의 미트업 행사에서 나왔던 질문과 답변을 정리한 글이었습니다. 그 후 8년의 시간이 흘렀기에 그 글만 노출된다면 학생들에게 현시점에 적절한 정보를 주지 못할까 봐 걱정되었습니다. 그래서 2025년 말 설문으로 질문을 받아 후속편을 작성했습니다. 그동안 저도 경험과 지식을 더 쌓았습니다. 하지만 지금 학생 개발자들이 한 질문에는 답하기가 더 어려워졌습니다. 개발자의 역할과 같은 큰 주제를 묻는 질문이 많았는데, 지금은 AI로 인한 변화가 큰 시기이기 때문입니다. 스스로도 확신이 없는 시기에 이런 글을 쓰는 것이 적절할지 고민도 했습니다. 그럼에도 2018년의 글에 보내 주신 관심에 용기를 얻어서 이 글을 발행합니다. 최근의 경험을 나누고 미래를 함께 상상해 보는 일이 지금 시점에는 더 의미가 있다고 생각합니다. 이 글을 목적지가 명확한 안내서보다는 격변기의 스냅샷 정도로 봐 주셨으면 합니다. 주요 질문과 답변 설문을 통해 들어온 질문들을 비슷한 주제로 모아서 답변을 정리했습니다. [AI 시대와 개발자] 가장 비중이 높은 질문 유형이었고 근본적인 주제이기도 합니다. 이 질문에 먼저 답하지 않고서는 다른 이야기를 풀어 가기가 어려웠습니다. AI 시대에 개발자의 역할은 어떻게 달라졌을까요? 누군가는 AI를 인터넷이나 전기, 불에 비견될 정도의 혁명이라고 말합니다.[1] 2025년부터는 그 주장이 과장이 아니라고 느낍니다. 제가 프로그래밍을 시작한 1989년 이후로 '코딩’이라는 활동에 가장 큰 변화가 왔습니다. AI 코딩 도구가 코드를 추천해 주는 역할에서 나아가 소스 작성, OS 명령 실행 등 사람의 실질적인 대리로 행동합니다. 역사를 돌아보면 기술이 발전하면서 지식 근로자가 하는 일은 이전 시대 관리자의 역할에 가까워졌습니다. 1980년대에 개인용 컴퓨터가 보급되기 전까지 지식 근로자의 작업 공간은 종이였고, 수기로 정보를 처리하는 일에 쓰는 시간의 비중이 컸습니다. AI 시대 전에도 계산, 정보의 형식 변환과 취합 등 컴퓨터가 하는 일의 범위는 꾸준히 늘어 왔습니다. 과거의 실무 일부를 컴퓨터가 하게 되면서 말단의 지식 근로자도 영향력이 큰 의사결정에 많이 관여할 수 있게 되었고 권한도 커졌습니다. CAD 도입 전 General Motors의 기술자들이 작업하는 모습 (이미지 출처: ArchDaily) 이제는 조직의 말단 작업자는 AI이고 모든 개발자는 AI 팀의 관리자가 되었습니다. 사람은 여러 AI 에이전트에게 업무를 지시하고 결과에 피드백을 줍니다. 아래에 나열한 일들은 전통적인 관리자의 역할이기도 하지만 '작업자’를 'AI 에이전트’로 바꿔서 읽어 본다면 이제는 모든 개발자가 하는 일입니다. 다수의 작업자에게 목표와 배경, 추구하는 가치, 평가 기준을 제시한다. 작업자의 정보 탐색 비용을 줄여 준다. 참조할 정보가 어디에 있는지 알려 준다. 작업자별 역할을 명확히 정의하여 할 일을 분배한다. 작업자별 장점과 투자액(과금액) 수준을 고려하여 각자의 작업에 집중할 수 있도록, 컨텍스트가 과도하게 넓어지지 않고 컨텍스트 전환이 최소화되도록 의사결정자와 작업자 간의 효율적인 피드백 사이클을 구축한다. 관리 업무의 멀티태스킹도 개발자가 적응해야 할 환경이 되었습니다. 에이전트에게 많은 일을 맡기려면 다수의 작업자가 병렬로 일을 진행할 수 있도록 지시를 내리고 결과물에는 빠른 피드백을 주어야 합니다. 작업자마다 컨텍스트를 좁혀 줄수록, 넓은 범위의 맥락을 머리에 올려 두고 빠르게 전환해야 하는 부담은 사람에게 더 크게 돌아옵니다. AI 에이전트와 일하는 형태는 여러 메신저 창을 왔다 갔다 하면서 다수와 병렬로 대화를 이어 가는 관리자의 모습과도 닮아 갑니다. 어떤 순간에는 화면을 어지럽게 전환하면서 게임 유닛에게 작업 지시와 확인, 판단을 쉴 틈 없이 하는 프로게이머와도 유사하게 느껴집니다. 정보를 찾을
2026년 10월 27일
2026년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript
브라우저 밖의 JavaScript 동향을 마지막으로 다루었던 2019년 시점(1부, 2부)에서는 Node.js 12와 막 1년을 넘긴 Deno를 소개하며 "Node.js와 같은 성공을 거둘 수 있을지는 아직 미지수"라고 썼습니다. 패키지 관리자 영역은 "npm의 독주 체제"라고 표현했고 npm 회사의 불확실한 상황에 맞서 Entropic, Open-Registry, GitHub Package Registry 같은 도전자가 등장했다고 전했습니다. 7년이 지난 지금 Node.js는 연 1회 릴리스로 일정을 바꾸기로 했습니다. Node.js 호환을 목표로 삼게 된 Deno와 Bun은 각각 Cloudflare와 Anthropic에 합류했고, npm은 GitHub의 일부가 되어 공급망 공격과 싸우고 있습니다. 이번 연재는 다음 네 편으로 구성됩니다. 1편: JavaScript(ECMAScript) 2편: 브라우저 밖의 JavaScript 3편: WebAssembly 4편: 라이브러리와 프레임워크 이 글에서는 먼저 2019년 이후 7년의 변화를 짧게 정리합니다. 이어서 Node.js의 사용 현황과 릴리스 일정, 주요 기능, Deno와 Bun, 서버 런타임 표준인 WinterTC, 공급망 공격으로 크게 바뀐 패키지 관리자와 레지스트리, 데스크톱과 모바일 애플리케이션 개발 도구, PWA와 XR, OpenJS Foundation을 차례로 살펴봅니다. 마지막으로 AI 코딩 도구가 런타임과 패키지 생태계를 어떻게 바꾸었는지 정리합니다. 번들러와 브라우저 밖의 WebAssembly는 짧게 언급만 합니다. WASI와 엣지 플랫폼에서의 WebAssembly 실행은 3편 WebAssembly에서 자세히 다룹니다. 이 글의 내용은 2026년 10월을 기준으로 작성되었습니다. 글을 읽는 시점에 따라 글의 내용과 사실이 다를 수 있습니다. 2019년 이후 7년 2019년 글을 쓸 때 Node.js의 최신 버전은 12.13이었습니다. 2026년 10월 현재 최신 버전은 26.12이고 그사이 메이저 버전이 열네 번 나왔습니다(참고: Node.js 26.12.0 릴리스). 숫자보다 큰 변화는 런타임의 역할입니다. 2019년의 Node.js는 서버와 빌드 도구를 실행하는 런타임이었다면, 지금의 Node.js는 TypeScript 파일을 바로 실행하고 테스트 러너와 SQLite, WebSocket 클라이언트를 내장하며 권한 모델로 파일과 네트워크 접근을 제한합니다. 2019년에 별도 패키지를 설치해야 했던 기능 상당수가 런타임에 내장되었습니다. 경쟁 구도도 달라졌습니다. 2019년에는 Node.js와 Deno를 비교했지만 지금은 Bun까지 세 런타임이 Node.js 호환성을 두고 경쟁합니다. 다만 2026년 10월 Deno 팀이 Cloudflare에 합류하면서 Deno 런타임의 개발은 1년 뒤 끝나게 되었습니다. 패키지 생태계에서는 2020년 GitHub이 npm을 인수하면서 2019년 글이 걱정한 "기술 외적인 불확실성"이 해소되었습니다. 그 대신 2025년부터는 공급망 공격이 가장 큰 문제가 되었습니다. 메인테이너 계정을 탈취해 악성 버전을 올리는 공격이 반복되었고 스스로 퍼지는 웜까지 등장했습니다. npm과 pnpm은 설치 스크립트를 기본으로 실행하지 않도록 바꾸었습니다. 표 1 2019년 이후 브라우저 밖의 JavaScript 주요 사건 시기사건 2020년 3월 GitHub, npm 인수 발표(4월 인수 완료) 2021년 9월 Electron, 8주 릴리스 주기로 전환(Electron 15) 2024년 10월 Deno 2 출시, Tauri 2.0 출시, React Native 0.76에서 새 아키텍처 기본화 2024년 12월 Node.js 22.12에서 require(esm) 플래그 제거 2025년 1월 WinterCG가 Ecma TC55(WinterTC)로 이동, pnpm 10에서 의존성 설치 스크립트 기본 미실행 2025년 9월 chalk, debug 등 메인테이너 계정 탈취, Shai-Hulud 웜 2025년 11월 npm classic 토큰
2026년 10월 21일
2026년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)
2016년부터 매년 이어 오던 "JavaScript의 동향" 연재는 2020년을 마지막으로 한동안 쉬었습니다. 그사이 6년이 지났고, 그 6년 동안 ECMAScript 명세는 여섯 번 개정되었습니다. 2020년 글을 쓸 때 Stage 2였던 Temporal은 9년에 걸친 논의 끝에 Stage 4에 올랐고, 이제 Chrome과 Firefox, Node.js에서 플래그 없이 쓸 수 있습니다. 달라진 것은 명세만이 아닙니다. 2020년에는 상상하기 어려웠던 방식으로 코드를 쓰는 사람이 늘었습니다. AI 코딩 도구가 코드의 상당 부분을 작성하고, 사람이 방향을 정하면 AI 에이전트가 브라우저 엔진의 JavaScript 엔진 코드를 다른 언어로 옮기는 일까지 생겼습니다. 2025년 GitHub Octoverse에서 TypeScript가 처음으로 가장 많이 쓰인 언어 1위에 올랐고, GitHub은 그 배경으로 AI를 꼽았습니다. 이번 연재는 다음 네 편으로 구성됩니다. 1편: JavaScript(ECMAScript) 2편: 브라우저 밖의 JavaScript 3편: WebAssembly 4편: 라이브러리와 프레임워크 직전 회차인 2020년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)에서는 ECMAScript 2020, 2021과 당시 진행 중이던 제안들을 살펴보았습니다. 해마다 발표되는 명세는 'ECMAScript 2026'처럼 연도를 붙여 부르고, 줄여서 'ES2026'이라고도 씁니다. 이 글에서는 먼저 2020년 이후 6년의 공백을 정리하고, 2020년 글에서 소개한 제안들이 어떤 결말을 맞았는지 확인합니다. 이어서 TC39 프로세스의 변화, 2026년 6월 승인된 ECMAScript 2026과 2027년 명세에 포함될 기능, 브라우저와 임베디드 엔진의 현황, JavaScript 상표권 분쟁, TypeScript 7을 살펴봅니다. 마지막으로 AI 코딩 도구가 JavaScript와 TypeScript를 쓰는 방식, 그리고 표준을 만드는 방식에 어떤 영향을 주고 있는지 정리합니다. 이 글의 내용은 2026년 10월을 기준으로 작성되었습니다. 글을 읽는 시점에 따라 글의 내용과 사실이 다를 수 있습니다. 2020년 이후 6년 2020년 글은 swyx의 The Third Age of JavaScript를 인용하며 2020년 이후를 JavaScript의 세 번째 주기로 보았습니다. 이 주기에서는 레거시를 정리하고 도구가 만든 레이어를 걷어 내는 일이 일어날 것이라고 했습니다. 구체적으로는 세 가지를 예상했습니다. CommonJS, AMD 같은 비표준 모듈이 ESM으로 전환될 것입니다. JavaScript 도구가 반드시 JavaScript로 작성될 필요는 없다는 흐름이 강해질 것입니다. TypeScript와 JavaScript가 서로 영향을 주며 함께 발전할 것입니다. 6년이 지난 지금 세 가지 모두 예상한 방향으로 진행되었습니다. 다만 속도와 모습은 예상과 달랐습니다. ESM 전환은 생각보다 오래 걸렸습니다. 전환을 가로막던 가장 큰 장벽은 CommonJS 코드에서 ESM 패키지를 require()로 불러올 수 없다는 점이었고, 이 문제는 2024년 말이 되어서야 Node.js의 require(esm) 지원으로 풀렸습니다(참고: Node.js 22.12.0 (LTS)). 인기 npm 패키지의 모듈 형식을 정기적으로 집계하는 wooorm/npm-esm-vs-cjs 데이터에 따르면, ESM을 제공하는(ESM 전용이거나 ESM과 CommonJS를 함께 제공하는) 패키지 비율은 2021년 8월 7.8%에서 2024년 11월 25.9%, 2026년 6월 38.0%로 늘었습니다. 다만 2025년 12월부터 집계 대상 목록의 출처가 바뀌어 그 이전 수치와 바로 비교하기는 어렵습니다. Anthony Fu(Vue, Vite, Nuxt 코어 팀원이자 Vitest, Slidev, UnoCSS 제작자)는 2024년 말 수치를 근거로 새 패키지는 ESM 전용으로 내자고 제안하기도 했습니다(참고: Move on to ESM
2026년 10월 20일
Python의 GC가 멀티프로세싱과 만나면 생기는 일 - Python과 Airflow, 그리고 관련된 문제 해결기 2편
Python의 멀티프로세싱과 Airflow의 task 동작 방식 - Python과 Airflow, 그리고 관련된 문제 해결기 1편에서는 Airflow가 task를 실행할 때 요구되는 병렬성과 격리성을 살펴보고, 이를 만족하기 위해 Airflow가 task마다 만들었다 버리는 단기 프로세스와 만들어 두고 재사용하는 장기 프로세스를 모두 fork 방식으로 생성한다는 점을 확인했습니다. fork는 생성 속도와 메모리 효율 모두에서 spawn을 크게 앞섰지만, 두 가지 한계가 따라온다는 점도 언급했습니다. 부모의 자원을 그대로 승계한다는 점과, Python에서는 Copy-on-Write(COW)가 기대만큼 동작하지 않는다는 점입니다. 이번 글에서는 이 두 한계가 저희 PoC(Proof of Concept) 환경에서 실제로 어떤 문제로 나타났는지부터 시작합니다. 두 문제는 worker 프로세스의 메모리가 계속 늘어나는 현상과, MySQL 환경에서 dag-processor가 간헐적으로 재시작되는 현상이었습니다. 겉으로는 전혀 다른 두 증상이었지만, 파고들면 결국 Python의 GC가 fork와 만나면서 생기는 문제라는 공통점이 있습니다. 원인을 추적해 해결하고 Airflow에 기여하기까지의 과정을 자세히 다룹니다. PoC 과정에서 발견한 두 가지 문제 문제 1: worker 프로세스의 메모리가 계속 증가한다 Airflow 3.1 계열을 CeleryExecutor로 PoC하면서 처음 눈에 띈 것은 worker 컨테이너의 메모리 사용량이 시간이 지날수록 늘어나는 현상이었습니다. CeleryExecutor는 worker 컨테이너 안에 fork로 만든 worker 프로세스를 여러 개 두고 workload를 처리합니다. 1편의 "Airflow의 task 수행 모델"에서 본 것처럼 Airflow 3의 LocalExecutor도 scheduler 프로세스 안에서 worker 프로세스를 fork로 만들어 재사용하는 같은 구조입니다. Airflow 메이저 버전업 초기라 메모리 증가 리포트도 많이 올라와 있어 LocalExecutor부터 조사했습니다. Memray로 찾은 두 가지 문제 Python 프로세스의 메모리 증가를 볼 때 자주 사용하는 도구는 Memray입니다. 힙(heap) 할당을 호출 스택 단위로 추적하여 UI로 보여 주기 때문에 어느 코드가 메모리를 잡고 있는지 쉽게 확인할 수 있습니다. worker 프로세스 하나를 Memray로 추적한 결과 두 가지 문제를 확인했습니다. 첫째, secrets masker가 타입 확인을 위해 kubernetes.client 전체를 import하고 있었습니다. worker가 task를 실행하는 데 필요 없는 모듈인데, worker당 약 32MB, worker 32개면 1GB 가까이 차지했습니다. 둘째, Task SDK client가 SSL context를 반복 생성하는 누수가 있었습니다. 첫째 문제를 걷어낸 뒤에도 worker 하나가 30분 만에 8MB에서 23MB로 늘었고, 이후로도 멈추지 않았습니다. 두 문제는 전형적인 힙 낭비와 누수였고, Airflow에 이슈로 정리해 올린 뒤 3.1.2에서 해결되었습니다. 이 과정에서 Memray가 매우 유용했기 때문에, 코드 수정 없이 주요 컴포넌트를 Memray 추적 아래 실행할 수 있는 기능과 Memory Profiling with Memray 문서를 Airflow에 추가했습니다. Memray에 보이지 않는 증가 두 문제를 고친 뒤에도 worker의 메모리 사용량은 여전히 올랐습니다. 문제는 이 증가가 Memray에 잡히지 않았다는 점입니다. 즉, worker 자체가 새로 할당한 메모리는 별로 없는데 메모리 사용량은 늘어나고 있었습니다. 그래서 1편에서 정리한 지표로 돌아갔습니다. 각 프로세스의 PSS, USS를 smem으로 확인했더니 특이한 점이 보였습니다. 생성 직후 20~30MB 수준이던 PSS가 서서히 오르다가, 어느 순간 100MB 이상으로 올라가 내려오지 않습니다. 1~2시간 정도면 대부분의 worker가 이 상태에 도달했습니다. PID Co
2026년 10월 8일
Python의 멀티프로세싱과 Airflow의 task 동작 방식 - Python과 Airflow, 그리고 관련된 문제 해결기 1편
저희 팀은 데이터 입수 플랫폼의 배치 워크플로를 Airflow 2.10.2로 운영하고 있습니다. 2025년 4월 Airflow 3.0이 릴리스되었고, UI 개선과 다양한 신규 기능이 포함되었습니다. 이 변화가 저희 운영 환경에 필요하다고 판단했고 도입을 위한 PoC(Proof of Concept)를 진행했습니다. 이 글은 그 PoC 과정에서 Python의 멀티프로세싱 방식 중 하나인 fork로 인해 발생한 문제를 발견해 해결하고 기여한 과정을 다루는 시리즈의 1편입니다. 1편에서는 이 문제를 이해하는 데 필요한 배경지식을 다룹니다. Airflow가 task를 실행할 때 요구되는 조건을 살펴보고, 이를 만족하는 Python 멀티프로세싱 방식을 비교한 뒤, Airflow가 실제로 채택한 방식과 그 한계를 설명합니다. 2편에서는 이 한계가 Airflow에 실제로 어떤 문제를 일으켰는지, 원인과 해결 과정을 다룹니다. Airflow의 task 실행 요구 사항 Apache Airflow는 Python으로 작성된 워크플로 오케스트레이션 도구입니다. 사용자는 task들 사이의 의존 관계를 Dag로 정의하고, Airflow는 정해진 스케줄에 따라 그 task들을 실행합니다. Dag는 task 집합과 그 사이의 의존 관계, 실행 순서를 정의하는 Airflow의 기본 단위입니다. task 실행에는 병렬성과 격리성이라는 두 가지 핵심적인 요구 사항이 있으며, Airflow는 이를 모두 만족해야 합니다. 병렬성 병렬성은 여러 task를 동시에 수행할 수 있는 능력입니다. Airflow는 정해진 스케줄에 따라 다수의 task를 실행해야 하므로 병렬성이 필요합니다. 그런데 Airflow는 Python으로 작성된 도구입니다. Python의 표준 구현체인 CPython에는 GIL(Global Interpreter Lock)이 있습니다. 이 때문에 하나의 인터프리터 안에서는 스레드가 아무리 많아도 Python 바이트코드는 한 순간에 하나만 실행됩니다. 즉, 멀티코어 CPU에서도 Python 코드는 동시에 코어 하나에서만 실행됩니다. CPU 집약적인(CPU-bound) 작업에서 멀티코어의 병렬 처리 이점을 얻지 못합니다. Airflow는 이 제약을 극복해야 합니다. 격리성 각 task의 수행이 부모 프로세스와 다른 task에 영향을 주지 않아야 합니다. 여기서 부모 프로세스는 task를 실행하는 프로세스를 생성한 상위 프로세스를 뜻합니다. Airflow는 사용자가 작성한 코드가 task로 실행되는 구조입니다. 심한 경우 해당 task가 부모 프로세스 전체를 종료시킬 수도 있으며, 이는 전체 task의 장애로 이어질 수 있습니다. Airflow가 격리성을 필요로 하는 이유는 하나 더 있습니다. Python은 모듈을 전역(sys.modules)으로 관리하며, 한 번 등록된 모듈을 전역에서 삭제하거나 갱신하기가 어렵습니다. 런타임에 import된 모듈은 코드가 바뀌어도 이를 다시 등록하기가 매우 어렵다는 뜻입니다. 가령 사용자는 task에서 import mypackage.plugins와 같이 본인이 작성한 모듈을 불러옵니다. 격리성이 보장되지 않는다면, 해당 모듈은 Git-Sync를 통해 변경이 일어나도 반영되지 않음을 의미합니다. task가 등록한 모듈은 task 완료와 함께 폐기되어야 합니다. Airflow의 멀티프로세싱 도입 Airflow는 앞서 살펴본 두 요구 사항을 만족하기 위해 멀티프로세싱을 사용했습니다. 즉, task 하나당 프로세스를 하나씩 생성해 그 안에서 실행하고, 종료 시 폐기하는 것입니다. 이를 통해 진정한 CPU 병렬성을 얻을 수 있습니다. 또한 task의 비정상 종료가 부모 프로세스에 영향을 주지 않게 하고, 부모 프로세스의 전역 모듈이 오염되는 것을 막습니다. task 종료 시 프로세스를 폐기함으로써 격리성을 보장할 수 있습니다. Python의 멀티프로세싱 방식 Airflow가 멀티프로세싱을 택했다면, 다음 질문은 프로세스를 어떻게 만드느냐입니다. Python에서 멀티프로세싱을 지원하는 방식은 fork와 spawn 두 가지입
2026년 10월 8일
D2Coding 폰트 1.4.0 릴리즈 소식을 전합니다.
D2 Coding은 한글과 영문, 숫자, 기호가 함께 있는 코드에서도 일정한 간격과 높은 가독성을 유지하도록 만든 코딩 전용 글꼴입니다. 이번 1.4.0에서는 기존의 빗금이 들어간 숫자 0 대신 점이 들어간 0을 선택해서 사용할 수 있는 기능을 추가했습니다. 일부 크기에서 글자가 기준선보다 한 픽셀 위에 표시되던 문제도 수정했으며, 마침표의 의미를 다르게 보이게 할 수 있었던 리거처 네 종류를 제거했습니다. 최근 공개한 1.3.4와 1.3.5의 개선 사항도 모두 포함되어 있습니다. 한글 주석이 포함된 줄에서도 코딩 리거처가 적용되며, Keynote에서 줄 끝에 불필요한 기호가 표시되던 문제가 해결되었습니다. 터미널에서 폭이 맞지 않던 기호 20자와 위첨자, 아래첨자, 분수 문자도 개선했습니다. 다운로드 : https://github.com/naver/d2-coding-font/releases/tag/VER1.4.0 소스 코드 : https://github.com/naver/d2-coding-font D2 Coding 미리 보기 : https://naver.github.io/d2-coding-font/ 기존 버전이 설치되어 있다면 먼저 제거한 뒤 새 버전을 설치해 주세요. 글꼴을 설치한 다음에는 사용 중인 에디터나 터미널을 다시 실행해야 새 버전이 적용될 수 있습니다. 1. 점이 들어간 숫자 0 추가 D2 Coding의 기본 숫자 0에는 영문 대문자 O와 쉽게 구분할 수 있도록 빗금이 들어가 있습니다. 1.4.0에서는 기존의 빗금이 들어간 0과 함께, 가운데에 점이 들어간 0을 선택해서 사용할 수 있습니다. 점이 들어간 0은 기본적으로 비활성화되어 있으며, OpenType의 cv01 기능을 켜면 적용됩니다. cv01을 지원하지 않고 스타일 세트만 제공하는 애플리케이션에서는 ss01 기능을 사용할 수 있습니다. 점이 들어간 0은 기존 숫자 0의 외곽선과 너비, 세로 방향 힌팅을 유지하므로 다른 숫자와 동일하게 정렬됩니다. 리거처 글꼴에서도 다른 리거처 기능에 영향을 주지 않고 사용할 수 있습니다. Visual Studio Code에서는 다음과 같이 설정할 수 있습니다. "editor.fontLigatures": "'cv01'" 리거처를 끄고 점이 들어간 0만 사용하려면 다음과 같이 설정합니다. "editor.fontLigatures": "'calt' off, 'liga' off, 'cv01'" Windows Terminal에서는 글꼴 설정에 다음 기능을 추가합니다. "font": { "face": "D2Coding", "features": { "cv01": 1 } } D2 Coding 미리 보기 사이트에서도 Dotted zero 옵션을 이용해 두 형태를 비교할 수 있습니다. https://naver.github.io/d2-coding-font/ 2. 일부 글자의 기준선 정렬 개선 FreeType 힌팅을 사용하는 환경에서 일부 글자가 주변 문자보다 한 픽셀 위에 표시되는 문제가 있었습니다. Regular 글꼴에서는 i와 일부 키릴 문자를 포함한 27개 글자가 영향을 받았습니다. Bold 글꼴에서는 악센트가 있는 문자와 그리스 문자, 키릴 문자 등을 포함한 87개 글자가 일부 크기에서 기준선보다 한 픽셀 위에 표시됐습니다. 1.4.0에서는 9에서 29ppem 사이의 해당 크기에 힌팅 보정을 적용해 글자들이 주변 문자와 같은 기준선 위에 놓이도록 수정했습니다. 글자의 외곽선은 변경하지 않았으며, 문제가 없었던 다른 크기의 표시 결과도 기존과 같습니다. 3. 마침표의 의미를 바꾸던 리거처 제거 1.4.0에서는 다음 네 가지 문자 조합의 리거처를 제거했습니다. .= .- {. .} 기존 리거처는 이 조합에 포함된 마침표를 가운데점 높이로 올려서 표시했습니다. 하지만 마침표 자체가 의미를 갖는 코드에서는 원래 문자를 오해하게 만들 수 있었습니다. 예를 들어 다음과 같은 코드가 영향을 받을 수 있습니다. 1.-x {{.}} {.inline.} .-mt-2 각각 숫자와 연산자가 결합된
2026년 10월 7일
FE News 26년 10월 소식을 전해드립니다.
주요소식 The Story of VS Code Visual Studio Code 공식 채널이 공개한 약 1시간 38분 분량의 다큐멘터리로, Erich Gamma가 이끈 취리히 팀이 브라우저용 편집기 컴포넌트 Monaco Editor를 만들던 시기부터 데스크톱 VS Code 발표와 오픈 소스 전환까지의 과정을 30여 명의 관계자 인터뷰로 보여 준다. 확장을 별도 프로세스에서 실행하고 한번 공개한 API는 바꾸지 않는 원칙, TypeScript 서버에서 출발한 LSP, UI와 확장 호스트를 분리한 구조가 원격 개발과 vscode.dev로 이어진 배경을 설명한다. 후반부에서는 GitHub Copilot의 출발과 Ask, Edits, Agent Mode로 이어진 AI 기능, Cursor 같은 포크를 바라보는 VS Code 팀의 시각도 소개한다. Native is now the future of mobile at Shopify 2020년 React Native 전면 도입을 선언했던 Shopify가 모바일 앱을 다시 Swift와 Kotlin 네이티브로 옮긴다고 발표했다. 코딩 에이전트 덕분에 두 플랫폼에 각각 구현하는 비용이 줄면서 공유 구현보다 네이티브의 이점이 커졌다는 판단으로, Shop 앱은 12주 만에 재구축했고 화면을 작은 체크포인트로 나눠 테스트, 시각 비교, 적대적 코드 리뷰, 사람의 승인을 거치게 하는 Helix 시스템을 만들었다. React Native Skia, FlashList, Restyle 등 Shopify가 관리해 온 오픈소스의 향후 계획도 공개해, 이 라이브러리를 쓰는 프로젝트라면 전환 일정을 확인해 둬야 한다. 토스 FE 개발자들의 검증법 토스 웨비나에서 Front AI 팀이 AI로 만든 결과물을 검증하는 방법을 소개한 세션이다. 코드에서 시나리오를 추론해 E2E 테스트를 자동 생성하려던 시도가 실패한 뒤, 얼굴 인식 결제처럼 실수 비용이 큰 영역에서 테스트를 직접 작성하며 디바이스 팜 조작 도구, 액션 로그 조회 스킬처럼 테스트를 막던 요소를 해결하는 도구를 만들어 온 과정을 설명한다. 사람이 CI 실패 원인을 파악하도록 만든 replay 도구를 에이전트에 그대로 넘기자 버튼 문구 변경 같은 실패를 스스로 고쳤다는 경험은 AI 검증 체계를 고민하는 FE 팀이 참고할 만하다. penpot 브라우저에서 쓰거나 직접 설치해 운영할 수 있는 오픈소스 디자인, 프로토타이핑 플랫폼이다. 디자인을 SVG, CSS, HTML 같은 개방형 표준으로 표현하고 CSS Grid와 Flex 레이아웃, 디자인 토큰, 컴포넌트를 기본 기능으로 제공하며, MCP 서버를 통해 Cursor나 Claude Code 같은 AI 에이전트가 컴포넌트, 토큰, 레이어 구조를 읽고 수정할 수 있다. 셀프 호스팅이 가능해 디자인 데이터를 사내에 두어야 하는 조직이 검토해 볼 만한 MPL-2.0 라이선스 프로젝트다. Full Course: Spec-Driven Development with Coding Agents DeepLearning.AI와 JetBrains가 만든 명세 주도 개발(Spec-Driven Development) 강좌의 전체 영상으로, 마크다운 명세를 먼저 쓰고 코딩 에이전트가 이를 구현하게 하는 흐름을 WebStorm과 Claude Code로 Next.js 예제 앱을 만들며 보여 준다. mission.md, techstack.md, roadmap.md로 프로젝트 헌장을 만든 뒤 기능마다 명세를 작성하고 컨텍스트를 비운 상태에서 구현을 맡기는 반복 과정을 설명한다. 기존 코드베이스에서 헌장을 역으로 만드는 방법과 Spec Kit, OpenSpec 같은 공개 SDD 도구도 소개해, 코딩 에이전트 결과물의 일관성을 고민하는 개발자에게 도움이 된다. >> FE News 26년 10월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움
2026년 10월 7일
에이전트, 개념부터 같이 정리해봐요 - 워크플로우 · 하네스 · Context/Memory · MCP/A2A
네이버 사내 Tech Meetup에서 발표되었던 인기 세션을 공유합니다. 에이전트를 개발하다 보면 같은 개념을 서로 다른 뜻으로 쓰고 있어서 논의가 겉도는 경험, 한 번쯤 해보셨을 것 같습니다. "이거 에이전트인가요?" "하네스를 만들어야죠" — 그런데 하네스가 정확히 무엇인가요? "Context 에 넣어두면 되죠" "그건 Memory 아닌가요?" "그건 MCP 인가요 A2A 인가요? 기존 REST API 랑 뭐가 다른가요?" 사실 이 개념들은 사외에서도 정리가 덜 된 것들입니다. 그래서 원문(Anthropic · OpenAI · MCP · A2A 스펙 등)을 다시 읽고, 실제로 실물들을 확인해보며 정리해본 내용을 공유합니다. 에이전트, 개념부터 같이 정리해봐요 - 워크플로우 · 하네스 · Context/Memory · MCP/A2A devreld2 | 에이전트, 개념부터 같이 정리해봐요 - 워크플로우 · 하네스 · Context/Memory · MCP/A2A naver.me [동영상 제공 채널 안내] 네이버 TV 서비스 종료로 인해 기존 네이버 TV 채널을 클립(@devrel_d2)으로 이동하였습니다. 앞으로도 많은 관심과 팔로우 부탁드리겠습니다.
2026년 10월 1일
Hive는 잊으려 했지만, Spark는 기억하고 있었다: 사라진 get_table RPC 복원기
TApplicationException · UNKNOWN_METHOD Invalid method name: 'get_table' 이 글은 네이버의 Hadoop 플랫폼인 C3의 Metastore를 Apache Hive 4.2로 올리는 과정에서 Spark 잡(job)이 실패한 현상과 그 원인을 추적해, Metastore Thrift 인터페이스에서 조용히 사라졌던 RPC 하나를 복원하기까지의 과정을 다룹니다. 코드 변경 자체는 IDL 두 줄과 서버 구현 몇 줄이 전부지만, 그 이면에는 Thrift RPC의 동작 방식과 Hive와 Spark 사이의 오래된 버전 호환성이라는 맥락이 얽혀 있습니다. 그리고 직접 수정한 코드보다 훨씬 큰 비중을 차지하는 'Thrift 생성 코드를 어디까지 확인해야 변경이 완료되는가'라는 질문도 함께 다룹니다. 이 글의 내용은 사내 Apache Hive 포크(aida-4.2.0)를 기준으로 작성되었으며, 코드 예시는 설명을 위해 일부가 축약, 편집되었습니다. 문제 상황: Invalid method name: 'get_table' 네이버의 사내 Hadoop 플랫폼 C3는 HDFS, YARN, Hive, Spark 등 다양한 컴포넌트가 한데 묶여 동작하는 대규모 데이터 플랫폼입니다. 최근 저희 팀은 이 플랫폼의 근간을 이루는 Hive Metastore(이하 HMS)를 오랫동안 사용해 온 버전에서 Apache Hive 4.2 기반의 사내 포크(aida-4.2.0)로 올리는 작업을 진행했습니다. 동시에 HMS와 HiveServer2(이하 HS2)를 기존의 물리 서버 배포에서 Kubernetes 위의 컨테이너 배포로 전환하는 현대화 작업도 함께 진행했습니다. HMS는 이름 그대로 테이블, 파티션, 스키마 같은 메타데이터의 단일 창구입니다. Hive뿐 아니라 Spark, Trino, 그리고 각종 사내 배치 파이프라인이 이 HMS에 "이 테이블의 스키마가 뭐야?", "이 파티션은 어디에 있어?"를 묻습니다. 그만큼 HMS는 신경 써서 다뤄야 하는 공용 인프라입니다. 호환성이 한 곳이라도 깨지면 그 파장이 플랫폼 전체 사용자에게 미칩니다. 업그레이드한 HMS를 스테이징 환경에 올리고 검증하던 중, Spark 잡에서 다음과 같은 예외가 보고되기 시작했습니다. # spark driver: stack trace org.apache.thrift.TApplicationException: Invalid method name: 'get_table' at org.apache.thrift.TApplicationException.read(TApplicationException.java:111) at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:79) at ...ThriftHiveMetastore$Client.recv_get_table(...) at ...ThriftHiveMetastore$Client.get_table(...) at ...HiveMetaStoreClient.getTable(...) at org.apache.spark.sql.hive.client.HiveClientImpl... 증상은 명확했습니다. Hive CLI나 Beeline(Hive의 JDBC 기반 명령줄 클라이언트) 같은 Hive 4.2 클라이언트로는 정상 동작합니다. Spark에서 테이블 메타데이터를 조회하는 순간 위 예외가 발생하며 잡이 실패합니다. 오류 메시지는 인증 실패나 네트워크 문제가 아니라 Invalid method name: 'get_table', 즉 '그런 이름의 메서드는 없다'는 서버의 응답입니다. HMS는 살아 있고, 대부분의 요청은 정상 처리됩니다. 그런데 Spark가 던지는 특정 요청 하나만 서버가 '그런 API는 모른다'고 거절하고 있었습니다. 왜 유독 get_table만, 그리고 왜 유독 Spark에서만 문제가 되었을까요? 이 질문에 답하려면 HMS가 요청을 받아 처리하는 방식, 즉 Thrift RPC의 구조부터 짚어야 합니다. 배경지식: HMS는 어떻게 요
2026년 9월 29일
FE News 26년 9월 소식을 전해드립니다.
26년 9월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. 주요소식 The AI Engineering Skills Map Andrew Ng이 DeepLearning.AI 팀과 함께 1만 건이 넘는 채용 공고 분석과 전문가 인터뷰, 설문을 종합해 정리한 AI 엔지니어링 역량 지도다. AI 애플리케이션 구축·배포, 소프트웨어 엔지니어링 기본기, 코딩 에이전트 활용, 그리고 무엇을 만들지 정하는 일(shaping the build) 네 가지를 지금 익힐 가치가 큰 역량으로 꼽는다. 저자는 이 역량들이 "AI 엔지니어"라는 직함에 한정되지 않고 풀스택, 데이터, DevOps를 포함한 모든 개발자에게 필요해진다고 보며, 앞으로 무엇을 학습 우선순위에 둘지 고민하는 개발자에게 참고할 만한 정리다. How We Migrated lovable.dev Away from Next.js 월 4,200만 방문 규모의 lovable.dev를 Next.js에서 Cloudflare workerd 런타임 위의 TanStack Start로 옮긴 기록이다. 전면 재작성 대신 6개월간 두 프레임워크를 동시에 운영하면서 프록시 워커가 라우트 단위로 분기하도록 하고, 사용자 여정에 따라 묶은 라우트 그룹을 순차 전환했으며 실제 코드 이전은 대부분 AI 에이전트가 처리했다. 빌드 시간은 6~9분으로 줄고 중위 TTFB는 49% 빨라졌으며 개발 환경 메모리 사용량은 8GB에서 1.5GB로 내려간 수치도 함께 공개해, 대규모 프로덕션 앱의 프레임워크 전환을 무중단으로 진행하는 방법론으로 참고할 만하다. How AI text watermarking works: a visual guide AI가 생성한 텍스트에 눈에 보이지 않는 표식이 어떻게 새겨지는지를 다섯 단계로 나눠 시각적으로 설명하는 가이드다. 워터마크는 글자가 아니라 단어와 단어 사이의 선택에 숨는데, 비밀 키로 후보 단어를 초록과 빨강으로 나누고 초록 쪽으로 확률을 살짝 기울인 뒤 검출 시 같은 방식으로 다시 색을 칠해 초록 비율을 세는 방식이다. 가벼운 편집은 표식을 희석하는 정도지만 표현이 겹치지 않게 다시 쓰면 사실상 지워지고, 키를 가진 쪽만 검증할 수 있어 공개된 "AI 탐지기" 사이트로는 확인할 수 없다는 실무적인 한계도 함께 짚는다. Bun 1.4 Bun 1.4의 헤드라인은 코어를 Zig에서 Rust로 재작성한 것이다. 시작 시간은 Linux에서 2배, Windows에서 2.5배 빨라졌고 HTTP 서버의 메모리 사용량은 13~48% 줄었다. 내장 헤드리스 브라우저 자동화(Bun.WebView), Bun.Image, Bun.markdown, Terminal과 cron API가 추가되었고 Node.js 26.3.0 호환으로 1,517개 테스트가 새로 통과한다. React 사용자에게 눈에 띄는 것은 React Compiler 지원으로, Babel이나 SWC를 거치지 않고 Bun 자체 파서 안에서 컴파일러가 돌기 때문에 약 860개 컴포넌트 규모의 코드베이스에서 빌드 시간이 71ms 늘어나는 데 그쳐 Babel 플러그인 대비 약 20배 빠르다. Next.js 16.3 Next.js 16.0 이후 가장 큰 업데이트로, 코드 변경 없이 얻는 개선과 옵트인 기능이 함께 담겼다. dev 서버는 Turbopack의 디스크 캐싱과 메모리 축출이 기본 활성화되어 메모리 사용량이 최대 90% 줄었고, next build에도 디스크 캐싱이 적용되어 CI 반복 빌드가 최대 5.5배 빨라졌다. 옵트인 기능인 Instant Navigations는 cacheComponents와 partialPrefetching 플래그를 켜면 Suspense 인라인 로딩 상태나 'use cache'로 표시한 UI를 추출해 내비게이션 전에 클라이언트로 실어 보내, 서버 주도 모델을 유지하면서 SPA 수준의 반응성을 확보한다. 이 외에 retry()로 서버 컴포넌트를 다시 가져올 수 있는 catchError 에러 바운더리, Vite 호환 import.meta.glob, root params가 추가되었
2026년 9월 3일
[네이버피셜] 네이버 개발자라면 꼭 만나게 됩니다
네이버의 기술과 개발 경험을 개발자들과 나누는 Developer Experience 팀의 인터뷰가 네이버피셜에 공개됐습니다. Developer Experience 팀은 D2를 비롯한 기술 콘텐츠를 만들고, 네이버 개발자의 성장 단계에 맞는 교육과 기술 공유 프로그램을 통해 개발자의 경험과 노하우를 연결하고 있습니다. 이번 인터뷰에서는 사람과 사람, 사람과 도구를 잇는 Developer Experience 팀의 역할과 네이버의 공유 문화, 그리고 AI 시대에도 동료 간의 대화가 중요한 이유를 들어볼 수 있습니다. 본문 인터뷰 중 발췌 Q. Developer Experience 팀은 어떤 일을 하나요? DevRel이나 기술 커뮤니케이션이라고 불리는 일을 포함해서, 기술을 바탕으로 사람들을 연결하는 일을 해요. 개발을 베이스로 전략, 기획, 마케팅, 홍보, 채용, 나아가 개발 문화까지 만듭니다. 여기에, 개발자가 매일 쓰는 도구와 환경도 함께 봐요. (...) 사람과 사람, 사람과 도구를 잇는 일이 한 팀에서 굴러간다고 보시면 됩니다. Q. 네이버의 개발 문화를 하나의 키워드로 표현한다면 무엇일까요? ‘공유’와 ‘성장’이라고 생각해요. 보통 발표하시는 분들은 본인이 가진 지식과 노하우를 알려주겠다는 마음으로 준비하시고, 들으러 오신 분들은 저분의 인사이트를 잘 흡수해야겠다고 생각하시잖아요. 그런데 정작 저희가 더 중점적으로 보는 부분은 발표자의 성장이에요. 우리 팀 안에서만 나누던 이야기를 업무 맥락을 모르는 사람들에게 어떻게 전달해야 할지 고민하는 순간부터 이미 성장이 시작되는 거거든요. Q. 업무를 하다 막히거나 궁금한 점이 생기면 사람이 아닌 AI에게 먼저 묻는 게 당연해졌어요. 이런 상황에서 사람끼리의 공유는 어떤 의미를 가질까요? 집단 지성은 이제 AI가 잘 대답해 주는 것 같아요. 그렇지만 ‘네이버에서 이 방법이 유효한가’의 답은 외부에서 찾기 힘들다고 생각해요. 같은 환경 속에 있는 동료들만이 공감하는 부분이 있고, 적확한 팁을 줄 수 있죠. ▶️ Developer Experience 팀이 어떻게 개발자의 성장을 돕고 네이버의 개발 문화를 만들어 가는지, 네이버피셜 인터뷰 전문에서 확인해 보세요.
2026년 9월 2일
우리 팀만의 vLLM 플러그인 만들기 2편 - 모델 변환부터 배포까지 AI-native로 자동화하기
1편에서는 검색·추천 모델을 vLLM 사용자 정의 플러그인으로 옮겨 서빙 성능을 높인 과정을 소개했습니다. 모델을 vLLM에서 실행할 수 있게 된 뒤에는 또 다른 문제가 남았습니다. 모델마다 반복해야 하는 변환 작업이 복잡하고, vLLM의 빠른 변화까지 계속 따라가야 한다는 점입니다. Hugging Face 모델 하나를 vLLM에 올리는 과정은 버튼 한 번으로 끝나지 않습니다. ‘딸깍’ 한 번으로 완성할 수는 없습니다. 하지만 자동화를 우리 문제에 맞게 계속 ‘깎아’ 나갈 수는 있습니다. 저희는 변환 절차를 Claude Code Skill로 만들고, 실제 모델을 변환하며 두 번의 큰 시행착오를 거쳐 스킬 자체도 계속 개선했습니다. 이 글은 vLLM 모델 변환부터 배포까지를 AI-native로 자동화하고, 그 자동화를 어떻게 다듬어 왔는지에 대한 기록입니다. 그 결과 서로 다른 유형의 모델 7개를 같은 절차로 변환해 운영에 적용했고, 변환 과정에서 발견한 주의 사항 45개를 재사용 가능한 지식으로 축적했습니다. 호출할 때마다 전체 지식을 입력하던 방식도 필요한 지식만 불러오는 구조로 바꿔, 지식 전달에 필요한 호출당 토큰 수를 6,900개에서 170개로 97% 줄였습니다. 마지막에는 이 협업 방식을 저장소 경계 너머로 확장해, 사용자가 GitHub Issue 하나를 작성하면 변환부터 배포까지 이어지는 E2E 파이프라인을 만들었습니다. 이 글에서 다루는 모델 변환과 배포 자동화의 전체 구조는 다음과 같습니다. 변환과 배포 절차를 담당하는 스킬이 필요한 시점에 도메인 지식 스킬을 호출하는 전체 구조 모델 변환이 어려운 이유 모델 변환은 단순한 코드 마이그레이션이 아닙니다. Hugging Face로 학습한 가중치는 유지하되 모델 구현을 vLLM의 실행 방식에 맞게 다시 작성해야 합니다. 이 과정에는 모델과 서빙 인프라 양쪽의 지식이 모두 필요합니다. 모델 구조를 아는 모델 개발자와 vLLM 인프라를 아는 MLOps 엔지니어 사이에 존재하는 지식의 공백 모델 개발자는 모델의 내부 구조와 가중치 매핑을 잘 알지만 vLLM의 풀링 인터페이스나 IO Processor 패턴과 같은 vLLM 특수 지식은 없습니다. MLOps 엔지니어는 vLLM 기반 인프라를 잘 알지만 모델의 가중치 구조나 Transformers 구현과 vLLM 구현 사이의 미묘한 차이는 모릅니다. 즉, 모델 개발자 혼자도 MLOps 엔지니어 혼자도 하기 어려운 작업입니다. 프레임워크가 빠르게 바뀐다는 점도 어려움을 더합니다. vLLM은 약 3년 동안 v0.1에서 v0.20까지 발전했고, 약 2주 간격으로 새 버전이 배포되면서 인터페이스도 계속 바뀌었습니다. 이 변화를 사람이 매번 따라가 적용하는 일은 누구에게도 쉽지 않습니다. 이처럼 두 도메인이 교차하고 프레임워크가 빠르게 변하는 문제가 있었기 때문에, 저희는 AI 도입 초기부터 모델 변환 자체를 AI-native 방식으로 풀기로 했습니다. 모델 경로에서 PR까지 이어지는 변환 스킬 변환 절차는 convert-vllm이라는 Claude Code Skill로 구현했습니다. Claude Code Skill은 Anthropic의 코딩 에이전트 CLI인 Claude Code에서 반복 작업의 절차를 SKILL.md에 정의해 두고, 에이전트가 필요할 때 읽어 실행하는 기능입니다. 매번 긴 프롬프트를 작성하는 대신 검증된 순서와 판단 기준을 재사용할 수 있습니다. 사용자가 Hugging Face 모델 경로를 입력하면 독립적으로 실행할 수 있는 다섯 개의 하위 스킬이 순서대로 실행돼 PR 생성까지 진행합니다. convert-vllm 스킬의 다섯 단계. 입출력 전후처리가 필요 없는 모델은 세 번째 단계를 건너뜁니다. setup-environment: MLflow와 S3에서 모델 아티팩트를 내려받고 개발 환경을 구성합니다. convert-model: 변환의 핵심 단계입니다. config.json을 분석해 생성, 풀링, 분류 등의 모델 유형을 판단합니다. 이어서 vLLM용 설정 클래스, 모델 클래스, 가중치 적재 코드, 모델 등록
2026년 8월 10일
우리 팀만의 vLLM 플러그인 만들기 1편 - 검색 AI 모델 서빙 성능 극대화하기
네이버 플레이스 AI MLOps는 지난 1년간 검색과 추천에 사용하는 스코어링 모델의 서빙 구조를 vLLM 기반으로 전환했습니다. 이 글에서는 사내 Engineering Day에서 발표한 내용을 바탕으로, 모델 서빙 경로를 최적화해 성능을 높인 과정을 소개합니다. 먼저 결과부터 살펴보겠습니다. 0.6B 재순위화(reranking) 모델을 Hugging Face Transformer.encode로 서빙했을 때 처리량은 63.85 QPS였습니다. 같은 모델과 GPU, 입력을 사용하면서 vLLM의 score 태스크로 옮기자 397.21 QPS로 약 6.2배 증가했습니다. 속성 기반 감성 모델(ABSA, Aspect-Based Sentiment Analysis)의 단건 p50 지연 시간은 101.22ms에서 16.43ms로 83.8% 감소했고, CLIP 기반 이미지 랭킹 모델의 처리량은 최적화를 다섯 단계 적용하자 3.76 img/s에서 62.2 img/s로 누적 16.5배 증가했습니다. 모델은 한 줄도 더 빠르게 만들지 않았는데 어떻게 이런 차이가 났을까요? 저희가 찾은 지점은 두 군데였습니다. 하나는 모델의 순전파를 실행하는 런타임 자체의 효율이고, 다른 하나는 순전파 앞뒤의 요청 경로입니다. 모델을 vLLM 사용자 정의 모델로 구현해 풀링 런타임에 올리고, 전처리와 후처리를 IO Processor 안으로 옮겼습니다. 그리고 이 결과물을 플러그인 패키지로 만들어 pip install 한 번으로 설치할 수 있도록 배포했습니다. 어디서 성능이 새고 있었나 검색·추천 모델의 작업 특성은 생성형 LLM과 다릅니다. 생성 모델은 한 요청에서 토큰을 길게 생성하므로 토큰당 지연 시간과 KV 캐시 관리가 중요합니다. 반면 재순위화, 감성 분석, 이미지 스코어링 모델은 입력이 짧지만 한 번의 검색 요청에서 후보 수십~수백 개를 함께 평가해야 합니다. 검색 응답 흐름 안에서 실행돼야 하므로, p95 지연 시간 예산(latency budget)도 수십 ms 수준으로 매우 제한적입니다. 기존 구조에서는 모델마다 별도의 추론 경로를 운영했습니다. 검색 백엔드에서 시작한 요청이 애플리케이션 서버, 전처리 서비스, 모델 서버, 후처리 서비스, 랭킹 서비스를 차례로 거쳤고, 모델이 늘어날 때마다 이 경로가 하나씩 복제되었습니다. 그 결과 전후처리 로직은 여러 서비스에 흩어지고, 배포와 운영은 모델별로 파편화되고, 모델 하나를 바꿀 때마다 API 스키마와 전처리, 배포가 같이 흔들렸습니다. 지연 시간 예산이 어디서 무너지는지 분석해 보니, 의외로 원인은 모델의 순전파(forward) 처리가 아니라 그 주변에 있었습니다. 여러 네트워크 구간을 지나는 비용 JSON과 텐서의 직렬화 비용 토크나이저와 모델 서버가 분리되면서 발생하는 추가 왕복 작은 요청이 여러 경로로 흩어져 배치를 충분히 구성하지 못하는 문제 서비스가 나뉜 만큼 장애 지점도 늘어나 폴백과 타임아웃 정책을 일관되게 유지하기 어려웠습니다. 결국 모델 최적화가 아니라 경로 최적화의 문제였습니다. 개선해야 할 대상은 모델 하나가 아니라, 순전파를 실행하는 런타임과 그 앞뒤를 연결하는 전체 경로였습니다. vLLM 풀링 런타임으로 모델 실행 구조 통합 vLLM은 주로 생성형 모델을 위한 엔진으로 알려져 있지만, 핵심에는 Transformer의 은닉 상태를 효율적으로 처리하는 런타임이 있습니다. 생성은 이 런타임에 샘플링 계층을 결합한 하나의 사용 방식일 뿐이고, 같은 런타임을 풀링 관점에서는 은닉 상태를 임베딩, 분류 확률, 토큰 점수와 같은 출력으로 바꾸는 시스템이라고 볼 수 있습니다. 검색·추천 모델에서 원하는 출력이 바로 이것이었기 때문에, 감성 분석, 재순위화, 이미지 랭킹 모델을 전부 vLLM 사용자 정의 모델로 구현해 같은 풀링 런타임 위에서 실행하기로 했습니다. 이는 하나의 vLLM 프로세스가 여러 모델을 동시에 서빙한다는 뜻은 아닙니다. 모델별로 서빙 인스턴스를 실행하되 런타임, 기본 이미지, 플러그인 패키지, 배포 방식을 공유하는 것입니다. 이 구조의 핵심 이점은 vLLM이 제공
2026년 8월 10일
FE News 26년 8월 소식을 전해드립니다.
주요소식 26년 8월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. State of CSS 2026 매년 진행되는 CSS 생태계 설문 조사인 State of CSS의 2026년 결과다. 2026년 5월 15일부터 6월 29일까지 진행되어 4,902명이 응답했고, 앵커 포지셔닝(Anchor Positioning)이 "가장 마음에 드는 신규 기능"과 "브라우저 지원 때문에 쓰지 못해 아쉬운 기능" 양쪽에서 1위를 차지했다. CSS의 AI 생성 비율이 평균 28%에 그쳤다는 응답도 눈에 띄는데, 다음 프로젝트에서 어떤 CSS 기능과 도구를 채택할지 판단하려는 개발자에게 참고할 만한 자료다. Hydration and Rendering Strategies 웹 렌더링 전략의 진화를 화면이 시각적으로 준비되는 시점과 실제로 상호작용 가능해지는 시점 사이의 간극을 줄인다는 관점에서 정리한 글이다. SSG·ISR부터 CSR, SSR, 스트리밍 SSR, 아일랜드 아키텍처, React Server Components까지 계보순으로 훑으며, 각 전략이 설정 복잡도·번들 크기·하이드레이션 지연·빌드 시간을 서로 맞바꾼다는 점을 짚는다. 콘텐츠 사이트에는 정적 생성과 아일랜드를, 앱에는 Server Components를 쓰고 이색적인 방식은 측정 가능한 성능 문제가 있을 때만 도입하라는 결론이 실용적이다. How does a request travel in ~200ms? 하나의 HTTP 요청이 약 200밀리초 동안 거치는 여정을 단계별로 보여 주는 인터랙티브 시각화 도구다. DNS 해석, TCP 연결, TLS 협상, 커널, Node의 이벤트 루프, Postgres 작업, 응답이 클라이언트로 되돌아오는 경로까지 요청의 생애주기 전체를 추적하며 각 단계가 전체 지연 시간에서 차지하는 비중을 보여 준다. 추상화 뒤에 감춰져 있던 네트워크·시스템 계층을 구체적으로 이해하고 싶은 개발자에게 좋은 학습 자료다. Announcing Vite+ Beta 런타임 관리, 패키지 관리, 프런트엔드 도구를 하나의 워크플로로 통합하는 웹 개발 툴체인 Vite+의 베타 출시 소식이다. Vite, Vitest, Rolldown, tsdown, Oxlint, Oxfmt를 하나의 스택으로 묶어 vp dev, vp check, vp test, vp build 같은 명령 체계로 제공하며, 알파 이후 500개 이상의 PR이 반영되어 스마트 캐싱과 조직 템플릿·프록시 등 엔터프라이즈 기능이 추가되었다. 1,300개 이상의 공개 저장소가 이미 사용하고 있다고 밝히고 있어, 프런트엔드 툴체인의 통합 흐름을 지켜보는 개발자에게 참고가 된다. Ant, a lightweight JavaScript runtime 기존 엔진을 감싸지 않고 자체 "Ant Silver" 엔진 위에 처음부터 만든 경량 JavaScript 런타임이다. Node 호환 API와 VM 샌드박스, WebAssembly를 내장하고 9MB 단일 바이너리로 실제 npm 패키지와 TypeScript를 실행하며, 자체 패키지 매니저와 레지스트리·배포 플랫폼까지 하나의 생태계로 구성된다. 50MB가 넘는 런타임을 감당하기 어려운 서버리스 함수, 엣지 컴퓨팅, 임베디드 환경을 겨냥한 프로젝트다. >> FE News 26년 8월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기
2026년 8월 5일
[AI 해커톤 후기] AI 해커톤 1위 팀이 AI에게 맡기지 않은 것
기업의 업무에 AI를 도입하면 무엇이 달라질까요? 반복 업무를 자동화하고, 매달 작성하던 보고서를 대신 만들고, 업무 시스템과 연결해 사용자가 요청한 작업까지 처리할 수 있을까요? 네이버 사내에서 열린 ‘모두의 Engineering Day AI 해커톤’에 참여하면서 저희도 비슷한 의문을 품었습니다. 낯선 재무 업무를 이해하고 Claude Code를 활용해 실제로 동작하는 결과물을 만들어야 하는 상황에서, 처음에는 자연스럽게 ‘AI가 무엇을 해줄 수 있을까?’부터 생각했습니다. 하지만 프로젝트가 진행될수록 질문은 달라졌습니다. AI가 할 수 있는 일보다 어떤 일을 맡겨도 되는지, 결과가 그럴듯한지보다 틀렸을 때 발견하고 설명할 수 있는지, 자동화할 수 있는지보다 AI가 멈춰도 업무가 계속될 수 있는지가 더 중요해졌습니다. 이 글은 하나의 재무 업무를 AI로 바꿔 보려다 문제를 어떻게 다시 정의했고, 어떤 방식으로 접근했으며, AI를 쓰며 어떤 한계를 마주했는지를 정리한 기록입니다. 실제 사내 문제를 함께 해결하는 해커톤 ‘모두의 Engineering Day AI 해커톤’은 참가자가 각자 준비한 아이디어로 경쟁하는 일반적인 해커톤과 조금 달랐습니다. 출발점은 사내 구성원이 실제 업무에서 겪고 있는 문제였습니다. 현업에서 해결하고 싶은 문제를 겪고 있는 구성원은 출제자(problem holder)로, AI를 활용해 그 문제를 함께 풀고 싶은 참가자는 문제를 푸는 사람(solver)으로 참여했습니다. 참가자는 개발, 기획, 디자인, 재무, 운영 등 여러 직군이 섞여 네 명이 한 팀을 이루었고, 출제자가 업무의 배경과 예외를 설명하면 참가자는 문제를 구조화하고 실제 동작하는 프로토타입을 만들었습니다. 문제를 푸는 과정은 팀당 두 대의 개발 환경을 두고 여러 명이 함께 프롬프트를 작성하고 결과를 검토하는 ‘페어 프롬프팅’ 방식으로 진행되었습니다. 한 사람이 AI에 지시한 결과를 그대로 받아들이는 대신, 서로 화면을 보며 질문을 고치고 결과를 함께 확인했습니다. 행사 당일 오전 10시부터 오후 4시까지, 문제를 구체화하고 설계해 동작하는 결과물로 만드는 데 주어진 시간은 약 6시간이었습니다. 완성된 서비스를 만드는 시간이 아니라 실제 업무 문제를 여러 직군의 시선으로 다시 보고, AI로 어디까지 바꿀 수 있는지 실험하는 시간이었습니다. 가장 낯선 문제를 선택 저희 팀이 선택한 문제는 다음과 같았습니다. 수기 Microsoft Excel(이하 엑셀) 기반 출자 현황 관리를 LLM·MCP 기반 투자 포트폴리오 관리 플랫폼으로 전환한다. 저희는 서비스 개발에는 익숙했지만 발행 주식 수, 보유 주식 수, 지분율, 유상증자, 구주 양수도, RCPS, 감자 같은 재무·투자 용어에는 익숙하지 않았습니다. 더 빠르게 이해하고 결과물을 만들기 쉬워 보이는 과제도 있었지만, 네 명 모두 이 문제를 1순위로 선택했습니다. 당시 네이버와 계열사가 투자한 법인의 변동 사항은 17명의 담당자가 각자의 엑셀 파일로 관리하고 있었습니다. 매월 담당자에게 직접 연락해 변동 사항을 받은 뒤 여러 파일을 다시 모아 전체 출자 현황을 정리해야 했습니다. 투자 대상이 늘고 다국가, 다통화, 다단계 지분 구조가 복잡해질수록 거래 이력을 관리하기 어려워졌고, 경영진이 원하는 기준으로 데이터를 다시 추출하는 데도 시간이 들었습니다. 사용자가 아주 많은 업무는 아니었지만, 이 숫자들은 사업보고서 같은 외부 공시의 기초 자료로 쓰일 수 있었습니다. 숫자 한 건이 잘못되었을 때의 영향은 작지 않았습니다. 익숙해서 빠르게 풀 수 있는 문제보다 제대로 바뀌었을 때 효과가 분명한 문제를 선택하자고 판단했고, 그렇게 NStake 프로젝트가 시작되었습니다. 문제는 엑셀이 아니라 설명하기 어려운 숫자 처음 떠올린 해결책은 비교적 명확했습니다. 담당자가 엑셀 대신 웹 화면에서 투자 내역을 입력하고, 여러 파일의 데이터를 하나의 데이터베이스에 모읍니다. 대시보드에서 현재 투자 현황을 보여주고, 자연어 질문에 답하며, AI가 월말 변동 보고서를 만들면 된다고 생각했습니다. 그러나 자세히 들
2026년 7월 24일
VictoriaMetrics 운영기 2편 — 장비 증설 없이 리소스 위기를 해결한 3단계 최적화 전략
VictoriaMetrics 운영기 1편에서는 네이버 검색의 대규모 메트릭 저장소 VictoriaMetrics 클러스터의 규모, 2계층 아키텍처, 180대 노드의 무중단 장비 교체와 증설 전략을 소개했습니다. 2편에서는 장비를 더 늘리지 않고 리소스 위기를 해결하기 위해 진행한 소프트웨어적 최적화 과정을 다룹니다. 메모리 문제를 해결한 뒤에도 쿠버네티스 전환은 계속 빨라졌고, 컨테이너 수는 수백만 개를 넘어섰습니다. 카디널리티가 급격히 증가하면서 조회 컴포넌트의 메모리 사용량이 치솟고, 저장소 디스크가 고갈되었습니다. 문제는 특정 컴포넌트 하나에 국한되지 않고 데이터 파이프라인 전반에서 발생했습니다. 저희는 장비 증설 대신 데이터 파이프라인의 각 구간을 나누어 분석했습니다. 그 결과 다음 세 레이어에서 최적화를 진행했습니다. 최적화 영역 핵심 전략 조회(query) 레이어 Slow Query가 vmselect OOM으로 이어지는 구조를 쿼리 분할 전략으로 개선 저장(storage) 레이어 vmstorage의 저장 구조와 IndexDB 로테이션 메커니즘을 분석해 데이터 기반의 RetentionPeriod 정책 재설계 수집(collection) 레이어 수집 대상 대부분을 차지하던 비서비스 컨테이너를 제외해 과도한 메트릭 유입을 앞단에서 통제 이 글에서 설명하는 vmstorage의 저장 및 조회 동작과 IndexDB 로테이션 메커니즘은 VictoriaMetrics 공식 엔지니어링 블로그의 How vmstorage Handles Data Ingestion From vminsert, How vmstorage's IndexDB Works, How vmstorage Handles Query Requests From vmselect를 참고했습니다. 1. 조회 레이어 최적화: vmselect OOM 해결 카디널리티 폭증의 영향은 조회 컴포넌트인 vmselect에서 가장 먼저 드러났습니다. 컨테이너 수가 급증한 시점 이후 vmselect의 메모리 사용률 90% 초과 알람이 자주 발생했고, 심한 경우 OOM으로 Pod가 재시작되었습니다. 알람이 발생한 시점을 살펴보면 공통적으로 Slow Query가 확인되었습니다. 원인은 매분 실행되는 전체 컨테이너 집계 쿼리였습니다. 수백만 개의 시계열을 대상으로 한 쿼리 결과가 vmselect 한 대에서 병합되고 집계되면서, 단일 Pod의 메모리 한계를 초과한 것입니다. VictoriaMetrics는 이런 상황을 방어할 수 있도록 여러 리소스 제한 옵션을 제공합니다. 플래그 역할 -search.maxUniqueTimeseries 단일 쿼리가 조회할 수 있는 최대 고유 시계열 수 제한 -search.maxQueryDuration 단일 쿼리의 최대 실행 시간 제한 -search.maxMemoryPerQuery 단일 쿼리가 사용할 수 있는 최대 메모리 제한 -search.maxPointsPerTimeseries 시계열 하나당 반환할 수 있는 최대 데이터포인트 수 제한 -memory.allowedPercent vmselect 프로세스 전체의 메모리 사용 상한 저희도 이 옵션들로 안전 장치를 설정했습니다. 그러나 리소스 제한은 쿼리가 시스템을 과도하게 사용하는 일을 막을 뿐 쿼리 결과셋 자체를 줄이지는 못하며, 제한에 걸리면 쿼리는 오류로 실패할 뿐입니다. 결국 OOM을 근본적으로 줄이려면 한 번의 쿼리가 처리하는 시계열 수를 줄여야 했습니다. 이를 위해 먼저 메트릭이 vmstorage에 저장되는 방식과 vmselect가 데이터를 조회하는 방식을 살펴봤습니다. 배경: IndexDB와 Data 영역을 분리해 저장하는 vmstorage 구조 vminsert가 전달한 메트릭은 vmstorage 안에서 두 영역으로 나뉘어 저장됩니다. IndexDB는 검색에 필요한 인덱스를 관리하고, Data 영역은 압축된 시계열 데이터를 보관합니다. 두 영역을 분리하면 원하는 시계열을 찾는 과정과 실제 값을 읽는 과정을 각각 최적화할 수 있습니다. IndexDB: 시계열 존재 여부 확인을 위한 인덱스 vmstorage는 메트릭을
2026년 7월 21일