Outsider's Dev Story

기술 뉴스 #304 : 2026-10-16

2026-10-16T02:24:12+09:00

웹개발 관련

Chrome에서 JPEG XL 제공 : Chrome이 155부터 차세대 이미지 형식인 JPEG XL(.jxl)을 지원한다.(한국어)

그 밖의 개발 관련

Redesigning source control at Anthropic : Anthropic이 하루에 병합하는 변경사항은 5월 평균 2,500건에서 9월 30,000건 이상으로 늘었다. 소스 관리가 병목이 되자 사내 버전 관리 시스템인 Scion을 구축하고 5개월 만에 Git에서 완전히 이전했다. Git 저장소 관리가 어려워지고 분산, 오프라인 특성이 오히려 문제가 되었다. 에이전트는 항상 온라인이므로, 언제나 접속할 수 있는 서버를 중심으로 다시 설계해 클라이언트의 작업을 경량화했다. Scion의 작업 단위는 changeset이며, 특별한 처리가 필요 없으므로 많은 작업을 처리할 수 있다. 이 changeset을 기반으로 파생 데이터를 생성해 추가 정보를 제공할 수 있고, 소스 관리 API도 제공한다. 데이터가 변경되지 않으므로 수평 확장이 쉬워졌다.(영어)
Git 3.0's upcoming SHA-256 default will be a costly mistake : Git은 처음 만들어졌을 때부터 콘텐츠 해싱에 SHA-1을 사용했다. 2017년과 2020년에 걸쳐 SHA-1 충돌이 가능한 것으로 밝혀졌고, 곧 출시될 Git 3.0에서는 기본 해시 알고리즘을 SHA-256으로 바꿀 계획이다. SHA-1에서는 Collision 공격과 Second-preimage 공격이 이론상 가능하지만, 현실에서는 불가능할 정도로 막대한 비용이 필요하다. 사회공학을 이용한 공격이 훨씬 쉽다. 이렇게 암호학적 무결성과 신뢰 문제를 혼동해 SHA-256으로 바꾸면 업계 전체가 큰 비용을 떠안고 큰 혼란을 겪게 될 것이다. SHA-1을 신뢰의 기반으로 쓰지 않으면서 유지하는 것은 가능하다.(영어)
What is Codemode : Pi가 Codemode로 MCP를 지원하게 되면서 Armin Ronacher가 Codemode에 대한 생각을 정리한 글이다. 평소에도 MCP보다는 스크립트를 사용해야 한다고 생각했다. LLM이 도구를 사용할 때 bash만으로는 한계가 있어, Codemode로 직접 코드를 작성하면 출력을 더 구조화하고 더 유용한 작업을 할 수 있다. MCP는 Codemode의 이점을 크게 누릴 수 있는 프로토콜이다. 하지만 현실에서는 Codemode를 염두에 두지 않아 잘 작동하지 않으므로 개선할 부분이 많다.(영어)
Rex: Public testing is beginning : Mitchell Hashimoto가 창업한 Superlogical에서 첫 제품 Rex를 베타로 공개했다. Rex는 터미널을 대체해서 세션 유지, 빠른 원격 연결 등의 기능을 제공하며 초기 테스트는 macOS만 지원한다.(영어)
Build your own decision model : Jev 같은 의사결정 모델을 만들기 위해 Qwen3-1.7B 모델의 출력을 제한해 주어진 선택지에서 빠르게 답을 내놓는 모델을 보여준다. 모호한 질문을 했을 때 모델이 답을 과하게 확신하는 문제를 해결하려고 온도 스케일링으로 보정하는 과정도 보여준다.(영어)
Triaging open source with agents : Bootstrap은 수백 개의 이슈와 Pull Request를 관리하려고 Claude Code로 분석·분류하고, 필요하면 Pull Request까지 만들게 했다. 모든 내용을 로컬 대시보드에서 볼 수 있게 만들어 이슈 관리 시간을 효율적으로 쓸 수 있게 되었다.(영어)
We disabled PRs from external contributors on honojs/hono : 웹 프레임워크 Hono가 이 시대에는 Pull Request 기여가 통하지 않는다며 Pull Request 기능을 막고 외부 PR 기여를 받지 않기로 했다.(영어)
Introducing Pass Designer : Apple이 Wallet 앱에서 쓸 입장권 이미지를 만들 수 있는 Pass Designer 앱을 출시했다.(영어)

AI 관련

Gemini 4 Argon: our next era of frontier intelligence : Google이 새로운 최첨단 모델 Gemini 4 Argon을 발표했다. Argon은 복잡하고 오래 걸리는 작업에서도 깊이 있게 추론하도록 설계되었다. Google 내부 업무에 먼저 도입되어 업무 방식을 크게 바꾸고 있고, 벤치마크에서도 높은 점수를 달성했다.(영어)
Introducing Claude Haiku 5.5 : Anthropic이 경량 모델 Haiku 5.5를 출시했다. 4.5보다 평균 75% 비용이 낮아졌다.(영어)
Muse Wonder: A Frontier Model For Personal & Professional AI Agents : Meta가 에이전트 작업에서 최첨단 성능을 보이는 프론티어 모델 Muse Wonder와 Muse Wonder Full을 발표했다. Meta가 지난 14개월 동안 AI 개발 전반을 재정비해서 프론티어 성능의 모델을 내놓을 수 있게 되었다.(영어)
Nano Banana 2.1 - Model Card : Google이 이미지 생성 모델 Nano Banana 2.1을 출시했다. Nano Banana 2.1은 Gemini 3.6 Flash를 기반으로 하며 1M 컨텍스트 창을 지원한다.(영어)
Introducing Mistral Large 4 : 1조 개의 파라미터를 갖춘 멀티모달 LLM인 Mistral Large 4가 출시되었다. 코딩, 에이전트 워크플로우, 멀티모달에서 뛰어난 성능을 보이며 최상급 오픈 소스 모델과 견줄 만하다. 모델 가중치는 이달 말에 공개할 예정이다.(영어)
Decisions : OpenAI가 Jev와 같은 Decisions API를 공개한다. Decisions는 gpt-6-luna로 동작하며 Responses API보다 10배 빠르다.(영어)
Introducing Clef: our open-source decision models, and new RL fine-tuning platform : Cloudflare가 Jev와 같은 의사 결정 모델인 Clef와 Clef-flash를 출시했다. 벤치마크에서 가장 좋은 점수가 나왔으며 Jev API와 호환되고 완전히 오픈소스로 공개되었다.(영어)
Introducing Beam: Reflection’s 501B open-weight model : 미국의 오픈웨이트 모델 회사인 Reflection에서 첫 모델인 Beam을 발표했다. Beam은 전체 파라미터 5,010억 개, 활성 파라미터 230억 개인 MoE 모델로, 코딩·추론·에이전트 작업에 맞춰 설계되었다.(영어)
EmbeddingGemma 2: an open, lightweight multimodal embedding model : Google이 고품질 텍스트 임베딩을 쉽게 만들 수 있도록 작년에 내놓은 EmbeddingGemma의 다음 버전인 EmbeddingGemma 2를 공개했다. EmbeddingGemma 2는 Gemma 4 아키텍처를 기반으로 텍스트뿐 아니라 코드, 이미지, 동영상, 오디오를 하나의 공유 임베딩 공간으로 통합하며, Apache 2.0 라이선스로 공개되었다.(영어)
Whistle: Speech to Text in 16.9 MB : Cactus Compute에서 CPU 엔진에서 사용할 수 있는 음성 인식 모델 Whistle을 공개했다. 16.9MB 파일 하나로 7개 언어를 지원하며 첫 토큰을 11ms 만에 생성할 수 있다.(영어)
Introducing Microsoft-Decision-1, our model for fast decision-making : Microsoft에서 Jev와 같은 의사결정 모델인 Microsoft-Decision-1을 발표했고 빠른 속도와 높은 정확도를 보여준다.(영어)
Introducing Grok Voice Transcribe 2.0 : SpaceXAI에서 음성-텍스트 변환 모델인 Grok Voice Transcribe 2.0을 출시했다. 1.0과 비교해서 동일한 가격에 정확도는 2배 높아졌다.(영어)

인프라 관련

10 Years of the SRE book: Announcing the second edition of "Site Reliability Engineering” : Google이 10년 전에 출간한 Site Reliability Engineering의 2판을 발표했다. 지난 10년 동안 AI, 마이크로서비스, 멀티 클라우드, 서버리스, 플랫폼 엔지니어링 등 많은 부분이 바뀌어 새로 쓰게 되었다.(영어)
인터넷 전체를 위한 인증 기관 구축하기 : Cloudflare가 공개 인증 기관(Certificate Authority)이 될 계획을 발표했다. 아직 인증서를 발급하고 있지는 않지만 Chrome, Apple, Microsoft, Mozilla의 루트 프로그램에 신청을 완료했고 GlobalSign이 오랫동안 운영해서 신뢰받는 루트를 인수하기 위한 계약도 체결한 상태다.(한국어)
Microsoft Releases LiteBox 0.1, a Rust-Based Sandboxing Library OS : Microsoft가 Rust 기반으로 만들어 올해 초에 공개했던 LiteBox 0.1을 릴리스했다. LiteBox는 보안에 초점을 맞춘 라이브러리 OS로, 호스트와 격리된 샌드박스 안에서 실행할 수 있다.(영어)
Microsoft to expand Azure Maia system to multi-gigawatt deployments : Microsoft Azure AI 인프라의 핵심 기반이라고 할 수 있는 Maia 200이 미국, 유럽, 호주에 도입되어 주요 GPU 인프라와 비교해 와트당 최대 1.7배의 토큰을 처리하고 있다. 이 경험을 바탕으로 설계한 Maia 300은 2027년 출시 예정이다.(영어)
Announcing Cloudflare K2: serverless event streams : Cloudflare가 서버리스 이벤트 스트림 제품인 K2를 발표했다. K2는 내부적으로 R2 오브젝트 스토리지에 로그를 사용해서 구현했고 Kafka처럼 이벤트를 순서에 맞게 저장해서 처리할 수 있다.(영어)
AWS Lambda Web Functions 정식 출시 : AWS에서 Express, Hono, Fastify, Next.js 등 Node.js 프레임워크로 만든 HTTP 웹 애플리케이션을 Lambda에서 실행할 수 있는 Lambda Web Functions를 발표했다.(한국어)

보안 및 장애

VulnBump: Can AI Agents Fix Vulnerable Dependencies Without Breaking the Build? : Snyk에서 취약점이 있는 의존성 307건을 AI로 업데이트하면서 빌드까지 성공시키는 연구인 VulnBump를 발표했다. Claude Code만으로는 59.6%가 성공했고, Snyk의 권장 업그레이드와 스캔 결과를 함께 제공했을 때는 77.5%, Snyk의 Evo Remediation Agent는 90.2%가 성공했다.(영어)

볼만한 링크

동네 치과의 AX전환기 : 동네 치과 의사가 AI로 뭔가 해보려다 공사비가 비싸 직접 구축에 나섰고, DGX Spark 12대로 병원 내 치과 업무의 상당 부분을 자동화해 편하게 만든 과정을 적은 글이다.(한국어)
Theranos World : 사기로 구속된 의료 스타트업 theranos의 창업자인 엘리자베스 홈즈의 책상을 구현한 웹사이트로 홈즈의 컴퓨터와 혈액검사 장비를 사용해 볼 수 있다.(영어)

IT 업계 뉴스

Deno is joining Cloudflare : Node.js를 만든 Ryan Dahl이 새로 만든 JavaScript 런타임인 Deno가 Cloudflare에 인수되었다. Deno 팀은 통합 플랫폼 개발에 집중하기로 했다. Deno는 앞으로 1년 동안 버그 수정과 보안 업데이트를 한 뒤 개발을 종료하고, Deno Deploy는 6개월 동안 유지한다. Cloudflare는 JSR을 계속 운영할 예정이다.(영어)
Turso is joining Supabase to give every agent its own database : SQLite 기반 분산 데이터베이스 플랫폼을 운영하는 Turso를 Supabase가 인수했다. 이번 인수를 통해 에이전트를 위한 데이터베이스 플랫폼을 만들 예정이라고 한다.(영어)
OpenAI engineer arrested in bugging of executive conference room : OpenAI의 엔지니어가 본사 임원 회의실에 녹음 장치를 설치한 혐의로 체포되었다. 해당 장치는 회의실 뒷면 USB 포트에 꽂혀 있었고 휴지로 가려져 있었다.(영어)
TypeSafe A raises Series AI : Jev로 큰 관심을 모은 TypeSafe AI가 Andreessen Horowitz가 주도하고 Sequoia Capital, 기존 투자사 DCVC 등이 참여한 시리즈 A 투자를 유치했다. 기사에 따르면 기업가치를 75억 달러(약 10조 원)로 평가받으며 8억 7천만 달러를 조달했다.(영어)

프로젝트

REA : 에이전트가 프로그램을 리버스 엔지니어링하게 해주는 MCP로 다양한 프로그램을 리버스 엔지니어링해 큰 관심을 모으고 있다.
pulls.review : Pull Request의 변경 사항을 논리적인 그룹으로 분류하고 요약해서 리뷰를 도와주는 오픈소스.
gdp-ts : 더 안전한 API 설계를 위한 라이브러리, 린터, AI 스킬로 API 계약을 컴파일 시점에서 검사해서 보안을 강화하는 검증 시스템이다.
NuxtFont : Nuxt 프레임워크를 위한 웹 폰트

버전 업데이트

Ubuntu 26.10 Stonking Stingray : Linux 배포판, 릴리스 공지
Pi v1.0 : 코딩 에이전트, 릴리스 공지
SvelteKit v3.0 : Svelte의 앱 개발 프레임워크, 릴리스 공지
Effect v4.0 : TypeScript용 이펙트 시스템, 릴리스 공지
Rsdoctor v2.0.0 : Rspack/Webpack의 분석기, 릴리스 공지
TanStack Start v1.0 : React/Solid용 풀스택 프레임워크, 릴리스 공지
Python v3.15.0 : 프로그래밍 언어, 릴리스 공지
Nx v23.3.0 : 모노레포 빌드 시스템, 릴리스 공지
Zed v1.23 : 코드 에디터, 릴리스 공지
Next.js v16.4.0 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
LogTape v2.4.0 : JavaScript 로깅 라이브러리, 릴리스 공지
Nuxt v4.6 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
Grafana Tempo v3.1.0 : 분산 트레이싱 백엔드, 릴리스 공지
Polars v2.0.0 : Python 데이터프레임 라이브러리, 릴리스 공지
Node.js v26.12.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.22.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
astro v7.4.0 : JavaScript 웹 프레임워크, 릴리스 공지
Nuxt UI v4.12.0 : UI 라이브러리, 릴리스 공지
React Native Skia v3.6.0 : React Native용 Skia, 릴리스 공지

기술 뉴스 #303 : 2026-10-01

2026-10-01T01:57:28+09:00

웹개발 관련

Pluggable, Extensible, and Playful DevTools : 다양한 웹 기술에 대한 DevTools를 다수 만들었는데 외관은 다르더라도 암묵적인 상태를 보이게 한다는 점에서 같은 일을 한다. 이러한 반복 작업을 없애기 위해 개발자 도구를 한 번 정의한 뒤 다양한 프레임워크와 어댑터, 코딩 에이전트에서 사용할 수 있는 Devframe을 공개했다.(영어)
Next.js applications, powered by Vite: introducing Vinext 1.0 : Cloudflare가 Vinext 1.0을 릴리스해 운영 환경에서도 사용할 수 있게 됐다. Vinext는 올해 초 AI를 이용해 Next.js를 Vite 기반으로 재구축한 프레임워크다. Vinext는 웹 플랫폼 어디서든 사용할 수 있고 App Router와 Pages Router까지 지원하고 사전 렌더링 등도 지원한다.(영어)
EmDash 1.0: the stable CMS with a secure plugin registry : Cloudflare가 WordPress의 정신적 후계자로 만든 Astro 기반 CMS EmDash 1.0을 출시하고 탈중앙화 플러그인 레지스트리도 함께 공개했다.(영어)
Mistral and Mozilla are bringing open, private and multilingual AI to your web browser : Mistral이 Mozilla와 파트너십을 맺었으며, AI 브라우징 어시스턴트인 Firefox Smart Window(Beta)는 Mistral 모델로 구동된다.(영어)

그 밖의 개발 관련

Prompting Claude Opus 5.5 : Claude Opus 5.5에 대한 프롬프팅 가이드다. 기존 프롬프트도 대체로 잘 작동하며, 작업 목표와 제약, 출력 형식을 명확히 제시한 뒤 평가를 거쳐 점진적으로 조정하기를 권한다.(영어)
Why MCP Was Always a Bad Idea : MCP가 LLM이 지금처럼 똑똑하지 않던 시절에 만들어진 프로토콜로 MCP 채택이 늘어나면서 컨텍스트 비대화 문제가 발생하고 있다. 이젠 모델이 똑똑해져서 스크립트도 작성하고 API도 호출할 수 있고 CLI도 잘 사용하게 되었다. 그래서 MCP를 계속 늘리기보다는 정리하고 HTTP API와 CLI를 활용해야 한다고 주장한다.(영어)
Audit your Agent files : 모델이 발전하고 하네스에도 새로운 기능이 추가되므로 CLAUDE.md나 AGENTS.md도 낡기 마련이다. 한두 달에 한 번씩 /doctor 등을 실행해 전역 지침을 재검토하고 불필요한 내용은 삭제해야 한다.(영어)
JetBrains Air: 에이전틱 소프트웨어 개발을 위한 제품 체계 구축 : JetBrains에서 에이전트 기반 개발을 위한 그동안의 실험을 통합한 JetBrains Air를 발표했다. JetBrains Air는 IDE 안팎에서 개발자, 팀, 조직을 위한 제품 체계다. JetBrains IDE와 Junie 코딩 에이전트로 개발하고, Air Teams와 Air Governance로 워크플로우를 자동화하며 정책과 비용 등을 관리한다.(한국어)
Android Bench 2.0: Pushing the frontier with challenging long-horizon tasks : Android 작업에서 LLM의 개발 지원 능력을 평가하는 Android Bench 2.0이 발표됐다. 이번 버전은 며칠씩 걸리는 복잡한 과정과 에이전트 역량을 평가한다.(영어)
WSL containers is now generally available : Windows의 Linux 환경인 WSL의 컨테이너 기능이 공식 릴리스됐다.(영어)

AI 관련

Introducing System One Models & Jev : OpenAI에서 ChatGPT 개발을 하던 개발자가 나와서 TypeSafe AI를 설립하고 System One 모델을 발표하고 첫 공개 모델인 Jev를 공개했다. Jev는 기존 LLM과 비슷한 수준의 지능을 갖추면서도 응답 시간이 70~500ms로 짧다. 입력 토큰은 100만 토큰당 $0.042로 저렴하고 출력 토큰 비용은 받지 않는다. 판단이 빠르고 비용이 저렴하다는 특징으로 큰 관심을 모았다.(영어)
A deep dive into Jev, TypeSafe's System One model : TypeSafe의 Jev에 데이터와 타입이 지정된 질문 목록을 보내면 질문마다 답과 그 확률을 돌려주며, 대부분 100ms 안에 끝난다. Jev는 코드가 판단을 내려야 하는 지점에 쓰는 작은 구성 요소로, 간단히 말하면 스마트 if문이다. 응답이 JSON으로 오므로 Jev가 판단하고 코드가 무슨 일을 할지를 결정한다. 질문은 Yes/No 질문, 옵션 중에서 고르기, 설명할 수 있는 척도의 점수 선택 등 세 가지 유형이 있다. 질문하면 응답 신뢰도도 알려 주므로 이를 활용할 수 있다.(영어)
DevDay 2026 주요 발표 : OpenAI가 DevDay에서 상시 가동되는 Astra 기반 에이전트 dots와 GPT-6.1 Sol을 발표했다. 이 밖에 AI와 팀이 함께 일하는 공간인 ChatGPTSpace, 서비스에 ChatGPT 인증을 연결해 사용자의 토큰을 쓸 수 있게 하는 로그인 기능, 500달러 Pro 요금제도 공개했다.(한국어)
Introducing GPT‑6 Sol and Luna : OpenAI가 GPT-6 Astra에 이어 GPT-6 제품군에 Sol과 Luna를 발표했다.(영어)
Introducing Claude Opus 5.5 : Anthropic이 Claude 5.5 제품군의 첫 번째 모델인 Claude Opus 5.5를 발표했다. Claude Opus 5.5는 대부분의 작업에서 Fable 5.1과 비슷한 성능을 보여주고 Opus 5보다 40% 저렴하다.(영어)
Introducing Claude Sonnet 5.5 : Anthropic이 Claude 5.5 제품군의 두 번째 모델인 Sonnet 5.5를 출시했다. Sonnet 5보다 속도가 30% 빨라졌고 비용은 최대 30% 저렴해졌다.(영어)
Introducing Grok 4.7 : SpaceXAi에서 Grok의 새 버전인 4.7을 공개했다. Grok 4.7은 4.6과 같은 가격과 속도로 제공되며 벤치마크에서는 GPT-6 Astra, Fable 5.1과 비슷한 점수를 기록했다.(영어)
Introducing Gemini 3.8 Live and 3.8 Live Extended Thinking : Google이 실시간 대화 모델인 Gemini 3.8 Live와 3.8 Live Extended Thinking을 발표했다. 이를 통해 음성 에이전트를 만들 수 있고 여러 벤치마크에서도 우수한 점수를 기록했다.(영어)
Gemini 3.8 text-to-speech says hello : Google이 새로운 오디오 생성 모델인 Gemini 3.8 Flash TTS와 Gemini 3.8 Flash-Lite TTS를 공개했다. Gemini 3.8 Flash TTS는 창의적인 연출과 캐릭터 디자인에 최적화되었고, Gemini 3.8 Flash-Lite TTS는 대량 처리와 비용 효율적인 확장을 위해 설계된 모델이다.(영어)
Qwen-Image-2.1: Compact, Efficient, and Unified Image Creation : Alibaba에서 이미지 생성 모델 Qwen-Image-2.1을 오픈소스로 공개했다. 이번 모델은 작고 효율적이며, 투명 이미지를 지원하고 다양한 편집도 할 수 있다.(영어)
MiMo-V2.6 : Xiaomi에서 새로운 모델 MiMo-v2.6 시리즈를 발표하고 오픈소스로 공개했다. 이번 시리즈에는 가장 뛰어난 성능을 갖춘 MiMo-v2.6-Pro와 비용 효율적인 MiMo-v2.6-Flash가 포함되어 있다.(영어)
Introducing Ember-1 : Fireworks Research에서 Kimi K3와 같은 품질을 내면서 토큰은 40% 적게 쓰는 특화 모델 Ember-1을 출시했다.(영어)
Astra for Law 소개 : OpenAI가 로펌과 법률 기술 기업이 AI 제품과 워크플로우를 구축할 수 있는 Astra for Law를 발표했다.(영어)

인프라 관련

Announcing blob-stream: a Kafka alternative for no fuss, low cost high volume streaming : bitdrift에서 Kafka와 유사한 스트리밍 시스템인 blob-stream을 오픈소스로 공개했다. blob-stream은 초저지연보다 총비용을 우선시하며, Kafka를 대체하면 비용을 크게 절감할 수 있다.(영어)
Inside Petal: Building the World’s First Petabit-Class Transoceanic Subsea Cable : Meta가 프랑스와 미국을 7,000km에 걸쳐 연결하는 페타비트급 해저 케이블을 만드는 Petal 프로젝트를 진행 중이다. 2029년 가동이 목표인 Petal은 멀티코어 광섬유 기술로 초당 1페타비트를 전송할 수 있어, 현재 가장 발전된 해저 케이블보다 용량이 2배 크다.(영어)
Introducing cf: the agentic CLI for the entire Cloudflare API : Cloudflare CLI인 Wrangler를 에이전트가 사용하는 비율이 높아지자, Cloudflare가 에이전트에 맞춰 새로 만든 CLI cf를 공개했다.(영어)

보안 및 장애

Happy Birthday, Shai-Hulud : @ctrl/tinycolor의 악성 버전이 배포된 뒤 자기 전파형 웜이 하루도 지나지 않아 수십 개 패키지로 퍼졌다. 공급망 보안에 대한 관심을 불러온 Shai-Hulud 사건이 발생한 지 1년이 지났다. 이후 11월에는 Shai-Hulud로 불리는 두 번째 공격이 감행되었고, 올해 4월에도 공격이 이어졌다. 2026년 공격에서 Shai-Hulud라는 이름을 사용한 TeamPCP 조직원 두 명은 체포되었지만, 최초 Shai-Hulud 사건이 TeamPCP의 소행인지는 밝혀지지 않았다. Shai-Hulud를 누가 만들었는지도 아직 알려지지 않았다.(영어)

볼만한 링크

I, too, have thoughts on DHH's keynote : RailsWorld의 DHH 기조 연설이 화제가 되고 있다. RailsWorld에서 Rails 얘기는 없고 AI 얘기만 있어서 AI 애호가라면 동의할 내용이지만 특별히 새로운 내용은 없고 흥미로운 부분도 없었다고 평가한다.(영어)
Agentic Skill Decay : 에이전트로 코딩하는 시대에는 많은 부분을 건너뛸 수 있으므로 의식적으로 경험을 쌓아야 한다. 단순히 결과가 나오는 것에 만족하는 게 아니라, 그 과정을 이해하고 학습하려는 노력을 반복해야 한다. 프롬프트도 상상하는 것만 요청할 수 있기 때문에 여전히 소프트웨어 엔지니어링의 기본기와 전문성은 중요하며 품질과 완성도를 높이기 위해서는 꼭 필요하다.(영어)

IT 업계 뉴스

Anthropic S-1 Leak: AI's Make-Or-Break Moment : Anthropic이 IPO를 위해 제출한 S-1 서류가 유출되었다. 2025년 46억 달러의 매출을 달성했고 두 고객이 매출의 1/4을 차지했다. 총비용 126억 5천만 달러 중 대부분인 73억 3천만 달러가 컴퓨팅과 인프라 비용이었다. 영업 손실은 80억 6천만 달러로 2025년 매출의 1.8배 정도다. 매출과 영업 손실 지표는 해마다 개선되고 있다. 7월 말 기준 연 환산 매출은 650억 달러로 크게 증가할 것으로 예상되며, 공급업체와의 계약 약정은 대부분 수년간 이어지는 것으로 나타났다.(영어)
Googlebook: The laptop your Android phone has been waiting for : Google이 Android 기술 스택 위에 ChromeOS를 결합한 새 노트북 Googlebook을 공개했다. 이번 Googlebook은 Gemini Intelligence에 맞춰 설계되었으며, Android 스마트폰과 바로 함께 사용할 수 있다.(영어)
I'm happy to announce that I've joined Hugging Face. : macOS 네이티브 MLX 서버인 oMLX를 만드는 Jun Kim 님이 Hugging Face에 채용되어 oMLX를 풀타임으로 개발할 수 있게 되었다.(영어)

프로젝트

SEMIF : OpenJev로 시작했던 브라우저에서 실행되는 의사결정 모델
Kev : Qwen 3.5, Qwen 3.8을 기반으로 한 Jev 같은 의사결정 모델
LocalJev : GitHub Next에서 실험적으로 DiffusionGemma 기반으로 oMLX에서 직접 실행할 수 있게 만든 Jev와 호환되는 프로그램.
ollaya : 의사결정 모델을 로컬에서 실행하는 도구
AX : Google이 공개한 에이전트 오케스트레이션 런타임.
ZCode : Z.ai가 ZCode가 데이터를 불법으로 가져간다는 의혹 이후 ZCode를 오픈소스로 공개했다.
git-bug : Git과 통합되어 오프라인에서도 사용할 수 있는 버그 트래커
Angular Native : Angular를 React Native의 Fabric 렌더러로 렌더링해 iOS/Android 앱으로 만드는 라이브러리

버전 업데이트

Vite+ v1.0 : 웹용 통합 툴체인, 릴리스 공지
Apache Groovy v6.0.0 : JVM용 프로그래밍 언어, 릴리스 공지
Xcode v27 : Apple IDE, 릴리스 공지
OpenSearch Kubernetes Operator v3.0 : 릴리스 공지
MSW v3.0.0 : JavaScript API Mocking 라이브러리, 릴리스 공지
Panda CSS v2.0 : CSS-in-JS, 릴리스 공지
Git v2.56.0 : 분산 형상관리 도구, 릴리스 공지
- git add --resolved로 충돌이 해결된 변경 사항만 스테이징하는 기능 추가
- git branch --delete-merged로 머지된 브랜치를 제거하는 기능 추가
celld v0.6.0 : 직접 운영할 수 있는 분산 듀러블 오브젝트, 릴리스 공지
Gradle v9.8.0 : Java 빌드 도구, 릴리스 공지
GraalVM v25.4 : 통합 가상 머신, 릴리스 공지
Turborepo v2.11 : JavaScript/TypeScript 빌드 시스템, 릴리스 공지
GitLab v19.4 : 오픈소스 설치형 Git 플랫폼, 릴리스 공지
Zed v1.21.0 : 코드 에디터, 릴리스 공지
Rstest v0.12 : Rspack 기반 테스팅 프레임워크, 릴리스 공지
jsdom v30.1.0 : Node.js용 브라우저 DOM 구현체, 릴리스 공지
React Router v8.4.0 : React의 라우팅 라이브러리, 릴리스 공지
ClickHouse v26.9 : 컬럼형 데이터베이스, 릴리스 공지
Node.js v26.10.0 : 자바스크립트 런타임, 릴리스 공지
Falco v0.45.0 : 클라우드 네이티브 런타임 보안, 릴리스 공지
Lexxy 1.0 : Rails용 웹 텍스트 에디터, 릴리스 공지
Terraform v1.16 : Infrastructure as Code 도구, 릴리스 공지

기술 뉴스 #302 : 2026-09-16

2026-09-16T02:03:34+09:00

개발 관련

Native is now the future of mobile : Shopify가 2020년 React Native를 쓰기로 결정하고 매우 성공적으로 전환을 마쳤다. React Native를 쓴 이유는 동일한 기능을 한 번만 개발하고 스택 전반에서 작업해 기능 동등성을 유지하는 데 드는 시간을 줄이며, 가치 제공에 집중하기 위해서였다. 하지만 LLM으로 상황이 크게 달라져 네이티브 스택을 다시 검토했다. 그 결과 iOS와 Android가 서로의 구현을 참조할 수 있고, 개발자는 주력 기술 외의 영역에도 기여할 수 있으며, 플랫폼 간 동등성 유지 비용도 획기적으로 줄었다. 다시 네이티브로 마이그레이션 하기 위해 React Native를 참조해서 그린필드로 마이그레이션 하기로 결정했고 사용자가 많은 Shop 앱을 12주 만에 마이그레이션했다.(영어)
Project HydraFusion: Frontier quality via multi-model orchestration : GitHub이 여러 모델 중에서 선택해 전체 실행 계획을 수립하고 초안을 작성·개선한 뒤, 더 강력한 모델로 작업을 완료할 수 있도록 지원하는 HydraFusion 프로젝트를 발표했다. 벤치마크 결과 더 낫거나 비슷한 품질의 결과를 더 낮은 비용으로 얻을 수 있었다.(영어)

AI 관련

GPT-6 Astra: 새로운 세대의 지능 : OpenAI가 새로운 모델 GPT-6 Astra를 출시했다. GPT-6 Astra는 OpenAI 모델 중 가장 뛰어난 성능을 보이며, 여러 벤치마크에서 다른 모델을 압도했다.(한국어)
Introducing Claude Fable 5.1 and Claude Mythos 5.1 : Anthropic이 Claude Fable 5.1과 Mythos 5.1을 출시했다. Fable 5.1은 Fable 5보다 뛰어난 성능을 보여, 작업 강도를 낮음 또는 중간으로 설정해도 더 낮은 비용으로 Fable 5와 유사한 결과를 얻을 수 있다.(영어)
Introducing Gemini 3.8 Flash and 3.8 Flash Cyber : Google이 3.7과 동일한 속도와 비용으로 최고의 추론 및 코딩 모델을 제공하는 Gemini 3.8 Flash와 Gemini 3.8 Flash Cyber를 발표했다. Gemini 3.8 Flash는 장기적인 코딩과 자율 에이전트를 위해 설계되었고 Gemini 3.8 Flash Cyber는 사이버 보안에서 우수한 결과를 보여주었다.(영어)
Kimi K2.8 Preview: Features, 1M Context and Coding : Moonshot AI에서 Kimi 코딩 서비스에서 사용할 수 있는 Kimi K2.8 Preview를 발표했다. 이번 모델은 코딩 및 에이전트 작업에 중점을 두고 있으며 1M 컨텍스트 윈도우를 지원한다.(영어)
Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient. : 새로운 아키텍처 제품군에서 가장 작은 모델인 DeepSeek-V4.1-Flash가 나왔다. 552B 파라미터 MoE로, 입력 시 활성 파라미터 80억 개와 출력 시 160억 개를 사용한다. 새로운 사전 학습 방법과 대규모 강화 학습 후처리를 통해 DeepSeek-V4-Pro 등 플래그십 모델보다 우수한 벤치마크 결과를 달성했다.(영어)
Google Pics brings pro-level AI image creation and editing to Google Workspace : Google이 AI 이미지 생성과 객체 기반 이미지 편집 기능을 제공하는 Google Pics를 출시했다. Google Pics에서는 텍스트로 이미지를 생성하거나 다듬을 수 있고, 특정 요소를 선택해 편집한 뒤 2K/4K로 업스케일링할 수 있다.(영어)
Atlas: A World Model for Spatial Intelligence : World Labs에서 텍스트, 이미지, 비디오, 3D 데이터를 처리하는 옴니 모델인 Atlas를 발표했다. Atlas는 카메라를 제어하고 공간을 재구성하고 시공간을 시뮬레이션해서 360도 파노라마를 생성할 수 있다.(영어)
Introducing Muse Spark 1.3 : Meta가 에이전틱 워크플로우와 코딩에서 성능이 향상된 Muse Spark 1.3을 출시했다.(영어)
Create your best tracks yet with Lyria 3.5 in Gemini. : Google이 음악 생성 모델 Lyria 3.5를 발표했다. Lyria 3.5는 더 풍부한 보컬 표현과 편곡을 제공하며 Gemini 앱과 API에서 사용할 수 있다.(영어)
ChatGPT 이미지 2.5 소개 : OpenAI가 최첨단 이미지 모델 Images 2.5를 출시했다. 더 자연스러운 조명과 질감을 구현하고 안정적으로 편집할 수 있으며, 이미지 생성 지연 시간도 2.0 대비 50% 단축했다.(영어)
Introducing SWE-2: Pushing the Pareto Frontier : Cognition에서 새로운 코딩 모델 SWE-2를 출시했다. 벤치마크에서 Fable 5.1과 1% 포인트밖에 차이나지 않으면서 비용은 64%를 절감했다.(영어)

인프라 관련

Portal by Spotify cut my Claude Code token usage by 90% : Spotify가 토큰 비용을 최적화하기 위해 Spotify Portal에 AiKA 모드를 만들어서 모델 라우팅을 통해 파일을 저렴한 모델로 읽게 해서 대량 읽기 시 토큰 사용량을 90% 줄였다.(영어)
Introducing Neki : PlanetScale이 세계 최대 규모의 샤딩 MySQL 클러스터를 운영한 경험을 바탕으로 샤딩 PostgreSQL인 Neki를 플랫폼 프리뷰로 공개했다. Neki는 라우터, 샤드 그룹, 연결 풀링, 제어 평면의 네 가지 요소로 구성되어 있다.(영어)
Platform engineering maturity: From toolchain to self-service : CNCF 플랫폼 엔지니어링 성숙도 모델은 투자, 도입, 인터페이스, 운영, 측정 다섯 가지 측면을 살펴보는데 그중 인터페이스를 살펴본 글이다. 1단계는 인터페이스에 일관성이 없고 2단계는 표준 툴링이 인터페이스가 되고 3단계는 셀프 서비스 솔루션, 4단계는 투명하게 통합된 통합 서비스이다. 대부분 2단계에서 정체되는데 도구가 요청량은 늘렸지만 처리할 능력을 확장하지 못하면서 발생하는 문제다.(영어)

보안 및 장애

OpenAI agents carried out an undisclosed cyber-attack on RubyGems : 지난 5월 11일 AI 에이전트가 RubyGems에 수백 개의 악성 패키지를 업로드했다. OpenAI 내부 에이전트가 만든 것으로 보고 있으며, 당시 이 대규모 악성 공격에 대응하느라 4일 동안 신규 사용자 가입까지 중단했다.(영어)

볼만한 링크

Stop Omarchy : DHH가 Arch Linux 기반으로 만들 리눅스 배포판인 Omarchy를 보이콧하자는 페이지이다. 최근 DHH가 Omacom 재단을 만들어 여러 CEO와 기업으로부터 1,800만 달러를 모금했으며, DHH가 그동안 파시스트적 주장을 하고 독단적으로 자금을 운영하면서 오픈소스와 기술 분야에 극우주의를 확산시키고 있다고 설명한다.(영어)
Detecting and countering misuse of AI: September 2026 : Anthropic이 2025년 12월부터 2026년 8월까지 사이버 작전, 영향력 행사 작전, 감시, 사기 및 부정행위, 생물학적 오용, 재래식 무기 개발, 모델 증류의 7가지 분야에서 오용을 탐지하고 막은 보고서를 발표했다. 이 보고서에 따르면 불법 증류 1건 외에는 Fable 급의 모델이 사용된 경우는 없었다.(영어)
We Must Pace the Frontier : Anthropic 공동 창업자 Dario Amodei는 AI의 위험을 해결하려면 더 신중해야 한다는 확신을 얻었다며, AI 모델의 역량 향상 속도를 늦춰야 한다고 주장했다. AI 기술이 올여름이후로 급격히 발전하고 있고 recursive self-improvement로 AI가 차세대 AI를 구축하는 능력이 향상되고 있어서 AI 시스템이 통제 능력을 넘어설 수 있고 OpenAI-Hugging Face 사건같은 일이 벌어지지 않도록 책임져야할 의무가 있다고 얘기한다.(영어)

IT 업계 뉴스

Tailwind Labs is joining Shopify : Tailwind가 Shopify에 인수되었다. Tailwind는 오랫동안 웹사이트 템플릿 사업을 해왔지만, 실제 제품을 위한 도구가 되기를 바랐다고 한다. Shopify는 이를 위한 좋은 기반을 제공하고 Tailwind CSS를 초기부터 사용한 기업 중 하나여서 선택했다고 한다. 오픈소스는 변함없이 유지될 것이고 Tailwind를 중심으로 한 사업은 더이상 확장하지 않는다고 한다.(영어)
Chinese AI labs secretly used millions of Claude exchanges to train their models, Anthropic says : Anthropic이 공개한 보고서에 따르면 Moonshot과 DeepSeek은 Claude를 불법 증류해 모델을 학습했다. Moonshot은 Kimi에 전달할 일부 요청을 Claude에 보내 응답을 받았고, 5월과 7월 사이 2,300만 건의 요청이 이루어졌다. 여기에는 민감한 정보도 포함됐으며, DeepSeek도 유사한 수법을 사용했다고 Anthropic은 밝혔다.(영어)
Automattic’s board forces CEO Matt Mullenweg into leave of absence : Automattic의 이사회가 창업자이자 CEO인 Matt Mullenweg를 본인 의사와 상관없이 휴직 명령했다. Matt Mullenweg는 여전히 WordPress 프로젝트의 리더 역할을 유지한다고 밝혔고, 이사회에도 남아 있지만 휴직 결정 이유는 밝혀지지 않았다.(영어)
Mistral raises €3B to make sovereign, open-weight AI the technology frontier : 프랑스 AI 회사인 Mistral이 시리즈 D 투자 라운드에서 30억 유로를 유치하고 기업 가치가 210억 유로(약 32조원)을 넘어섰다.(영어)

프로젝트

cn : Tailwind class를 합치고 충돌을 처리하는 엔진으로 tailwind-merge와 clsx보다 30배 빠르다.
Chopin : GitHub Next에서 프로토타입으로 만들 실시간 멀티플레이어가 계획을 세울 수 있는 환경.
Magika : Google이 공개한 파일 형식 감지 도구로, 단일 CPU 환경에서도 밀리초 단위로 정확한 파일 형식을 식별한다.
Muse : Meta가 개인 AI 에이전트 앱인 Muse를 출시했다.

버전 업데이트

JDK 27 : Java Development Kit, 릴리스 공지
Homebrew v7.0.0 : OS X 패키지 매니저, 릴리스 공지
Vitest v5.0.0 : Vite 유닛 테스트 프레임워크, 릴리스 공지
Jotai v3.0.0 : React 상태 관리 라이브러리, 릴리스 공지
Rslib v1.0 : Rsbuild 기반 라이브러리 개발 도구, 릴리스 공지
PyTorch v2.14.0 : Python 딥러닝 프레임워크, 릴리스 공지
vLLM v0.29.0 : LLM 서빙, 릴리스 공지
Spring Tools v5.4.0 : Spring 코딩 환경을 위한 도구, 릴리스 공지
Upyo v0.6.0 : Node.js, Deno, Bun용 이메일 라이브러리, 릴리스 공지
pnpm v12.4 : Node.js 패키지 매니저, 릴리스 공지
React v19.3.0 : 자바스크립트 UI 라이브러리, 릴리스 공지
Base UI v1.8.0 : UI 컴포넌트 라이브러리, 릴리스 공지
Nx v23.2 : 모노레포 빌드 시스템, 릴리스 공지
Zed v1.19 : 코드 에디터, 릴리스 공지
TinyBase v9.7.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
ClickHouse v26.8 : 컬럼형 데이터베이스, 릴리스 공지
Node.js v24.21.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
astro v7.3 : JavaScript 웹 프레임워크, 릴리스 공지
Cilium v1.20 : eBPF 기반 CNI, 릴리스 공지
Swift v6.4 : 프로그래밍 언어, 릴리스 공지

기술 뉴스 #301 : 2026-09-01

2026-09-01T01:42:45+09:00

웹개발 관련

Async Solid: Fetch High, Block Low : 곧 릴리스될 Solid 2.0이 비동기 처리를 다루는 방식을 설명하는 첫 번째 글이다. 비동기 데이터를 다룰 때는 보통 상위 컴포넌트가 렌더링된 뒤 네트워크 요청이 시작된다. Solid는 컴포넌트 트리 상단에서 fetch를 시작해(Fetch High) UI를 구성하는 동안 네트워크 요청을 처리하고, 데이터가 필요한 UI까지 대기를 최대한 늦출 수 있도록 지원한다(Block Low). (영어)
Intent to Ship: JPEG XL : 2020년대 새로운 이미지 포맷으로 AVIF와 JPEG XL이 있다. Firefox는 2021년에 AVIF를 지원했고 이제 JPEG XL 출시 계획을 발표했다. JPEG XL은 프로그레시브 렌더링이 가능해 전체를 로드하지 않아도 이미지를 어느 정도 보여 줄 수 있고, 화질 손실 없이 JPEG를 압축할 수 있다. (영어)
Asana cleared 5 years of engineering work in 2 weeks with Codex : 이슈 관리 플랫폼인 Asana가 오래된 테스트 도구 Enzyme을 스택에서 걷어내는 데 Codex를 사용해 2주 만에 끝냈다. 모델 및 인프라는 약 12,000달러가 들었고 기존 계획에서는 최소 5년은 걸릴 것으로 예상했다.(영어)

그 밖의 개발 관련

Running a Software Factory Efficiently at Uber Scale : Uber에서 AI 코딩 비용을 엔지니어링으로 해결해서 사용량을 7배 늘리면서 단위 비용은 절감하고 출력 품질은 유지했다. 비용 구조를 파악하고 측정 방법을 만들 뒤에 기본 모델을 선택하고 토큰/요청을 최적화했다. 프롬프트를 캐싱하고 MCP 도구를 CLI로 이용했으며, Code Mode로 토큰 사용을 최적화하고 내부 정보를 쉽게 찾을 수 있도록 AI 컨텍스트 그래프를 개발했다. (영어)
Origin 코드 호스팅 : 기존에 예고한 대로 Cursor가 코드 호스팅 기능인 Origin을 유료 플랜 사용자에게 베타로 순차 출시한다고 발표했다.(한국어)
Mojo🔥 is now open source! : Python 언어와 생태계를 시스템 프로그래밍 및 메타 프로그래밍과 결합해 연구와 운영 간의 격차를 해소하는 프로그래밍 언어 Mojo가 오픈소스로 공개됐다. (영어)
Projects in Buzz : Block에서 사람과 AI 에이전트가 함께 활동할 수 있는 채팅 앱으로 공개한 Buzz의 실험 기능인 Projects를 소개한다. 프로젝트에서 Git 저장소를 제공하고 Pull Request와 이슈를 관리할 수 있으며, 에이전트에게 이런 작업을 맡기고 어떤 활동이 있었는지 볼 수 있다. (영어)
Protobuf Explained : Protocol Buffers를 자세히 설명하는 사이트다.(영어)

AI 관련

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities : Z.ai에서 GLM-5.3을 출시했다. GLM-5.3은 GLM-5.2와 같은 기본 모델을 사용하지만, 사후 학습만으로 성능을 높였고 5.2보다 복잡한 코딩과 장기 작업에서 훨씬 뛰어난 성능을 보인다.(영어)
Qwen3.8-Flash-Next: A New Architecture, Towards Ultimate Cost-Efficiency : Alibaba에서 Qwen3.8-Flash-Next 모델과 가중치를 공개했다. Qwen3.8-Flash-Next는 Qwen4에 적용될 아키텍처를 사용한 멀티모달 MoE 모델로 어텐션, 잔차, 임베딩, 최적화 부분에서 개선했다.(영어)
GLM-5.3-Flash: Frontier Intelligence, Flash Cost : Z.ai에서 GLM-5 시리즈 최초의 네이티브 멀티모달 모델 GLM-5.3-Flash를 공개했다. GLM-5.3-Flash는 공개 전 OpenCode와 OpenRouter에서 Ox Alpha라는 이름으로 익명 제공되어 피드백을 수집했고, 모든 트래픽을 중국산 AI 칩으로 처리했다.(영어)
Intelligent transcription with Gemini 3.5 Transcribe : Google에서 음성-텍스트 변환 모델인 Gemini 3.5 Transcribe를 발표했다. 실시간 스트리밍과 미리 녹음된 오디오를 처리하는 API 두 가지를 제공한다.(영어)
Tencent Releases and Open-Sources Tencent Hy4 preview : Tencent가 차세대 LLM인 Hy4 프리뷰를 공개했다.(영어)

인프라 관련

모든 규모의 Git : Git은 운영하기 쉬워 보일 수 있지만, 분산형이라는 특성 때문에 대규모 운영은 쉽지 않다. Git은 서버에서는 어떻게든 운영할 수 있지만, 네트워크로 주고받을 때는 packfile을 사용해야 한다. 이전에 분산 해시 테이블로 최적화하는 JGit의 방법도 packfile의 성능 한계로 사용할 수 없었다. GitHub도 처음에는 분산 파일 시스템을 사용했지만 곧 한계에 이르렀다. 2013년에 공개한 Spokes는 데이터를 NVMe 디스크에 저장하고 Git 자체를 분산하지 않은 채 복제본을 만들어 3단계 커밋으로 동기화한다. 오랫동안 잘 사용됐지만, 현재는 다시 한계에 부딪히고 있다. Cursor에서는 Spokes에서 배워서 Continuity라는 Git 스토리지 시스템을 만들었다. Continuity는 S3 호환 객체 스토리지에 WAL을 기록해 Push를 선형적으로 처리한다. Spokes처럼 로컬 디스크에 NVMe를 쓰지만, Spokes와 달리 리포지토리를 추적하거나 합의할 필요가 없고 S3를 이용해 무한히 복제할 수 있다. (한국어)
Twenty Years of S3: How It Became the Default Persistence Layer for Modern Data Infrastructure : 오브젝트 스토리지 기반 옵저버빌리티 데이터베이스인 GreptimeDB를 만든 Dennis Zhuang이 S3의 발전 과정을 정리한 글이다. 2006년에 등장한 S3는 계속 기능을 추가해 왔다. 2020년에는 강한 일관성을 도입했고, 2023년에는 Express One Zone 지원과 Mountpoint for S3로 지연 시간 문제도 해결했다. 다만 NVMe와는 여전히 거리가 멀었다. 2024년에는 조건부 쓰기가 도입돼 원자적 직렬화를 수행할 수 있게 됐고, Cursor의 Continuity도 이를 사용한다. 20년 동안 S3가 디스크만큼 빨라진 것은 아니지만, 데이터 인프라 시스템이 S3를 source of truth로 사용할 만큼 발전했다. (영어)
Simulating Real Workloads with valkey-benchmark : Valkey는 사용자 환경에서 여러 클라이언트가 명령을 전송하는 상황을 시뮬레이션해 성능을 테스트할 수 있는 valkey-benchmark CLI를 제공한다. Valkey 자체의 속도보다 서버가 부하 상태에서 어떻게 작동하는지 확인하는 데 쓰는 도구다. (영어)
CNCF Announces Kubeflow’s Graduation, Solidifying a Standard for Cloud Native AI Operations : AI와 머신러닝 운영을 위한 Kubernetes 플랫폼 Kubeflow가 CNCF 졸업 프로젝트가 됐다. (영어)

보안 및 장애

Incident with GitHub.com : UTC 기준 지난 17일에 7시간 47분간 발생한 GitHub 장애 보고서다. 트래픽이 급증해 Istio 사이드카 Pod의 동시 실행 제한에 도달했지만, 사이드카를 모니터링하지 않도록 정책이 잘못 설정돼 오토스케일링이 작동하지 않았다. 트래픽을 버티지 못해 장애가 확산되면서 HAProxy 노드 4대도 제한을 초과해 지연과 오류가 발생했다. 여기에 낙관적 재시도 로직이 내부 로드 밸런서에 과부하를 걸어 상황이 더 악화됐다. HAProxy를 중지시켜 문제를 복구했다. (영어)

볼만한 링크

Good Culture is the Biggest Productivity Hack, Not AI : AI로 생산성이 올라가면서 다들 AI 도구에 집중하지만 그 도구가 놓인 환경에는 관심을 기울이지 않는다. AI 도구보다 중요한 것은 훌륭한 문화다. 생산성을 높이는 가장 좋은 방법은 훌륭한 기업 문화이고, 문화가 갖춰지지 않으면 아무것도 제대로 돌아가지 않는다. 많은 회사가 생산성이 10배 올랐다고 말하면 C레벨은 FOMO를 느끼지만, AI는 오히려 훌륭한 문화를 더 가치 있게 만들므로 좋은 문화를 구축하는 데 노력해야 한다.(영어)
Anger, Anxiety and Agency : AI로 많은 변화가 일어나는 상황에서 혼란과 불안을 느끼는 건 당연하지만, 분노는 어딘가로 향하기 때문에 좋지 않다. 이때 분노는 아무런 도움이 안 되고, 불확실성을 호기심으로 연결하면 호기심을 넘어 흥분까지 느낄 수 있다.(영어)

IT 업계 뉴스

Omacom Foundation launches with $8 million : Rails의 DHH가 만든 Omarchy 리눅스를 관리하기 위한 Omacom 재단이 설립됐다. 여기에는 많은 유명 회사의 CEO나 창업자들이 천만 달러를 펀딩했다.(영어)
OpenRouter is Joining Stripe : 여러 AI 모델을 쉽게 사용할 수 있게 하는 OpenRouter를 결제 플랫폼인 stripe가 인수했다.(영어)
AWS and DuckLabs: Building the future of analytics together : DuckDB를 개발하는 DuckLabs를 AWS가 인수하기로 했다. DuckDB는 DuckLabs에서 계속 주도하고 독립 재단하에서 계속 오픈소스로 유지될 예정이다.(영어)
Nvidia closes in on Hugging Face acquisition : NVidia가 AI 모델 플랫폼 회사인 Hugging Face를 129억 달러에 인수하기로 합의했다고 알려졌다.(영어)
Anthropic’s annualized revenue surges to $65B : 블룸버그가 7월 말 기준 Anthropic의 연간 환산 매출을 추정한 결과 650억 달러를 넘었다고 보도했다.(5월에는 470억 달러)(영어)

프로젝트

Node Modules Inspector : node_modules의 시각화 및 분석 사이트.
omadium : Omarchy 리눅스를 회사의 컴플라이언스 요구사항에 맞추기 위한 프로젝트.
walgit : 앞의 Cursor Git 접근법 글을 보고 Shopify CEO인 Tobi가 오픈소스로 구현해 본 저장소
Dactyl : Deno를 만드는 Denoland의 사람들이 Android와 iOS용 앱을 위한 바이브 코딩 플랫폼 서비스를 공개했다.
Berd : Block이 내부에서 AI 에이전트를 단일 환경에서 쓸 수 있도록 만든 데스크톱 애플리케이션을 오픈소스로 공개했다.
tapes : 에이전트 세션을 로컬 Postgres에 기록하는 CLI
fx : Vercel에서 만든 코딩 에이전트
UNPKG ESM : npm용 CDN인 unpkg에서 브라우저를 지원하는 ESM 모듈을 베타로 지원한다.
PR Cockpit : GitHub Pull Request를 로컬에서 빠르게 리뷰할 수 있게 하는 macOS 앱

버전 업데이트

htmx v4.0.0 : HTML 확장 라이브러리, 릴리스 공지
nest.js v12.0 : Node.js 웹 프레임워크, 릴리스 공지
pnpm v12.0.0 : Node.js 패키지 매니저, 릴리스 공지
Electron v44.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
Bun v1.4.0 : JavaScript/TypeScript 런타임, 릴리스 공지
Crossplane v2.4.0 : 외부 인프라 관리용 Kubernetes 애드온, 릴리스 공지
Go v1.27.0 : 프로그래밍 언어, 릴리스 공지
Better Auth 1.7 : 인증 프레임워크, 릴리스 공지
Grafana v13.2.0 : 메트릭 대시보드, 릴리스 공지
Node.js v26.8.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.20.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
NativeScript v9.1.0 : JavaScript 모바일 프레임워크, 릴리스 공지
celld v0.4.0 : 직접 운영할 수 있는 분산 듀러블 오브젝트, 릴리스 공지
Zod v4.5 : TypeScript 스키마 유효성 검사 라이브러리, 릴리스 공지
Zed v1.17 : 코드 에디터, 릴리스 공지
Kubernetes v1.37 Garhwal : 컨테이너 오케스트레이션 도구, 릴리스 공지
ollama v0.33 : 오픈 모델을 로컬에서 실행하는 도구, 릴리스 공지
Rspack v2.2 : 웹 번들러, 릴리스 공지
GraalVM v25.3 : 통합 가상 머신, 릴리스 공지
TinyBase v9.6.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지

Istio의 재시도 정책과 관련 메트릭 살펴보기

2026-08-22T19:55:05+09:00

서비스 메시인 Istio에는 요청이 실패했을 때 적용할 재시도 정책을 설정할 수 있다. 과거에는 서비스 디스커버리나 메시 같은 기능을 각 서비스에서 구축했다. 하지만 이 경우 서비스마다 정책과 성숙도에 차이가 난다. 그래서 이제는 대부분 인프라 차원에서 처리하는 쪽으로 움직였다. 물론 인프라는 전체에 적용되는 정책이라 보수적일 수밖에 없다. 따라서 인프라의 기본 설정에 애플리케이션의 미세 조정이 더해져야 한다.

서비스에 문제가 생기면 Istio나 애플리케이션이 재시도한다. 장애가 발생하면 재시도가 장애를 더 악화시키거나 복구 시간을 늘리는 경우도 많으므로 신중하게 다뤄야 한다.

일부 상황에서는 재시도 때문에 요청이 늘어나기도 하고 사용자가 새로고침을 하면서 요청이 늘어나기도 한다. 오랫동안 시스템을 보면서 재시도 정책을 자세히 이해하고 재시도 관련 정보를 더 파악할 방법을 찾고자 테스트해 봤다.

Istio의 defaultHttpRetryPolicy

Istio 전역 설정인 MeshConfig에는 재시도 정책을 설정하는 defaultHttpRetryPolicy가 있다.

기본 HTTP 재시도 정책을 구성합니다. 다음 오류에 대한 기본 재시도 횟수는 2회로 설정되어 있습니다: connect-failure, refused-stream, unavailable, cancelled, retriable-status-codes. 재시도 횟수를 0으로 설정하면 재시도 정책이 전역적으로 비활성화됩니다. 이 설정은 Virtual Service API를 사용하여 호스트별로 재정의할 수 있습니다. 현재 재시도 정책의 설정 중 perTryTimeout을 제외한 모든 설정을 이 필드를 통해 전역적으로 구성할 수 있습니다.

위 설명에 나온 대로 이 설정은 Virtual Service의 retries 필드로 재정의할 수 있다.

재시도 설정은 다음과 같은 형태이다.

1meshConfig:
2    defaultHttpRetryPolicy:
3      attempts: 2
4      retryOn: connect-failure,refused-stream,unavailable,cancelled,503

attempts는 재시도 횟수다. 여기서 재시도를 2회로 설정했으므로 최초 요청 뒤 두 번 재시도하며, 최대 세 번의 요청이 발생할 수 있다.

retryOn은 재시도 조건을 지정한다. 조건은 콤마(,)로 여러 개 지정할 수 있으며, 지정할 수 있는 값은 Envoy의 retry 정책과 gRPC retry 정책을 참고하면 된다.

defaultHttpRetryPolicy라는 이름 때문에 헷갈릴 수 있지만, 이 필드는 HTTP뿐 아니라 gRPC에도 사용한다. 따라서 위 설정에서 connect-failure는 TCP 연결 실패나 타임아웃을, refused-stream은 HTTP/2 업스트림이 REFUSED STREAM로 스트림을 거절한 경우를 가리킨다. unavailable과 cancelled는 각각 gRPC의 14 UNAVAILABLE, 1 CANCELLED가 발생한 경우이며, 503은 HTTP 503 Service Unavailable이 발생한 경우다.

참고로 Destination Rule에는 maxRetries 설정이 있는데 이는 특정 시점에 허용하는 최대 재시도 수를 지정한다.

Retry 데모

저번에 기능 분석을 하면서 LLM을 이용하니 데모를 잘 만들어줘서 이번에도 비슷한 방식을 이용했다.

Kubernetes 클러스터 생성

 1$ kind create cluster --config kind-config.yaml --wait 5m
 2Creating cluster "istio-retry-lab" ...
 3 ✓ Ensuring node image (kindest/node:v1.36.1) 🖼
 4 ✓ Preparing nodes 📦 📦
 5 ✓ Writing configuration 📜
 6 ✓ Starting control-plane 🕹️
 7 ✓ Installing CNI 🔌
 8 ✓ Installing StorageClass 💾
 9 ✓ Joining worker nodes 🚜
10 ✓ Waiting ≤ 5m0s for control-plane = Ready ⏳
11 • Ready after 6s 💚
12Set kubectl context to "kind-istio-retry-lab"
13You can now use your cluster with:
14
15kubectl cluster-info --context kind-istio-retry-lab
16
17Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/

kind를 이용해서 Kubernetes 클러스터를 생성했다.

1$ kubectl get nodes
2NAME                            STATUS   ROLES           AGE   VERSION
3istio-retry-lab-control-plane   Ready    control-plane   51s   v1.36.1
4istio-retry-lab-worker          Ready    <none>          37s   v1.36.1

복잡한 설정이 필요한 건 아니라 워커 노드는 1개만 만들었다.

Istio 설치

Istio 오퍼레이터를 설정하면서 아까 살펴봤던 defaultHttpRetryPolicy를 설정했다. 설정하지 않아도 기본 구성이 있지만 여기서는 명시적으로 지정했다.

 1apiVersion: install.istio.io/v1alpha1
 2kind: IstioOperator
 3spec:
 4  meshConfig:
 5    defaultHttpRetryPolicy:
 6      attempts: 2
 7      retryOn: connect-failure,refused-stream,unavailable,cancelled,503
 8    defaultConfig:
 9      proxyStatsMatcher:
10        inclusionRegexps:
11          - ".*upstream_rq_retry.*"
12          - ".*\\.retry\\.upstream_rq_.*"

Istio는 Envoy 통계 일부만 수집한다. proxyStatsMatcher로 추가 수집할 메트릭을 지정할 수 있다. 요청 통계뿐 아니라 재시도 관련 메트릭도 살펴보고 싶어 수집하도록 설정했다.

Envoy의 통계 관련 문서를 보면 다음과 같은 재시도 관련한 메트릭이 있는데 .*upstream_rq_retry.*는 이를 잡기 위한 설정이다.

Name	Type	Description
`upstream_rq_retry`	Counter	전체 요청 재시도 수
`upstream_rq_retry_success`	Counter	요청 재시도 성공 수
`upstream_rq_retry_backoff_exponential`	Counter	지수 백오프 전략을 사용한 전체 재시도 수
`upstream_rq_retry_backoff_ratelimited`	Counter	rate-limited 백오프 전략을 사용한 전체 재시도 수
`upstream_rq_retry_limit_exceeded`	Counter	설정한 최대 재시도 수를 초과해 재시도하지 않은 총 요청 수
`upstream_rq_retry_overflow`	Counter	서킷 브레이커나 재시도 예산을 초과해서 재시도되지 않은 요청 수

재시도는 요청을 보내는 다운스트림 쪽에서 일어나므로 메트릭도 요청을 보내는 쪽 Envoy에 쌓인다. 위 메트릭에는 다운스트림의 최종 응답에 대한 수만 집계된다. 재시도를 유발한 응답에 대한 통계는 retry.upstream_rq_<*xx>나 retry.upstream_rq_<*>에 집계되므로 .*\\.retry\\.upstream_rq_.* 설정으로 이러한 메트릭을 수집한다. 이번 데모에서는 이 메트릭을 사용하지 않았지만, 재시도가 어떤 상황에서 발생했는지 추적하려면 retry.upstream_rq_ 메트릭이 필요해 보인다. 관련 메트릭은 더 검토해야 한다. 다만 수집에도 비용이 들어 모두 수집하기는 어렵다.

이 설정을 이용해서 Istio 1.30.3을 설치했다.

 1$ istioctl x precheck
 2✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
 3  To get started, check out https://istio.io/latest/docs/setup/getting-started/.
 4
 5$ istioctl install -f istio-operator.yaml --verify -y
 6        |\
 7        | \
 8        |  \
 9        |   \
10      /||    \
11     / ||     \
12    /  ||      \
13   /   ||       \
14  /    ||        \
15 /     ||         \
16/______||__________\
17____________________
18  \__       _____/
19     \_____/
20
21✔ Istio core installed ⛵️
22✔ Istiod installed 🧠
23✔ Ingress gateways installed 🛬
24✔ Installation complete

1$ istioctl version
2client version: 1.30.3
3control plane version: 1.30.3
4data plane version: 1.30.3 (1 proxies)

Retry 동작 확인

재시도 동작을 추적하기 위해 app-a, app-b라는 2개의 앱을 만들었다. app-a에 요청을 보내는 실험을 시작하면 app-a는 app-b에 요청을 보내게 되는데 이때 app-b는 일정 비율로 503을 응답하게 했다.

이 테스트를 진행하면서 모니터링할 수 있는 테스트 앱을 따로 만들었다. Prometheus를 연결해 두어서 테스트를 진행하면 각 메트릭을 수집해서 보여준다. 아래는 초당 30 요청에 503 비율을 40%로 설정했다.

 1$ istioctl proxy-config routes app-a-6fbc5db5fb-mm8qb -n retry-lab -o json | jq '.. | .retryPolicy? // empty'
 2{
 3  "retryOn": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
 4  "numRetries": 2,
 5  "retryHostPredicate": [
 6    {
 7      "name": "envoy.retry_host_predicates.previous_hosts",
 8      "typedConfig": {
 9        "@type": "type.googleapis.com/envoy.extensions.retry.host.previous_hosts.v3.PreviousHostsPredicate"
10      }
11    }
12  ],
13  "hostSelectionRetryMaxAttempts": "5",
14  "retriableStatusCodes": [
15    503
16  ]
17}
18{
19  "retryOn": "reset-before-request",
20  "numRetries": 2
21}

실제로 app-a의 Pod에 적용된 재시도 정책은 위처럼 되어 있다. Istio 설정에서는 없었지만 Envoy에 적용된 추가 설정도 여기서 확인할 수 있다.

envoy.retry_host_predicates.previous_hosts는 재시도할 때 가능하면 이전과 같은 호스트는 피하는 설정이다. 여기서는 임의로 오류를 주입했지만 실제 환경에서는 특정 팟에 문제가 생길 수 있으므로 재시도는 가능하면 다른 Pod으로 가는게 안정성 면에서 훨씬 좋다.
hostSelectionRetryMaxAttempts는 새로운 엔드 포인트를 찾을 때 host 선택을 최대 5번까지 시도한다. 위에서 다른 호스트를 찾는다고 할 때 가능하면이라고 했는데 Pod이 1개 일수도 있고 다양한 상황에서 무한대로 같은 호스트를 피할 수는 없으니 최대 시도를 5번으로 제한한다.
reset-before-request는 아예 연결이 이뤄지지 않아 업스트림에 도달하지도 못한 채 리셋되면 최대 2번 재시도한다.

app-a와 app-b의 요청 수, 응답 수, 오류 응답 수를 나타낸 그래프다. 재시도가 두 번 더 일어나므로 세 번 모두 503일 때만 최종 오류 응답으로 집계된다. 따라서 app-a의 총 요청 수 29.98 req/s 가운데 오류 응답은 40%가 아니라 10%에 못 미치는 1.96 req/s가 된다.

app-a에서 실제로 재시도가 발생한 수이다. 구분해서 볼 수 있는지 제일 궁금했던 메트릭이고, 재시도로 인한 요청 증폭이 발생했을 때 이 메트릭을 활용할 수 있어 보인다.

재시도를 2번 더 하므로 시나리오를 생각하면 503 -> 200, 503 -> 503 -> 200는 최종적으로 성공이 되고 503 -> 503 -> 503인 경우만 최종적으로 실패가 된다. 재시도 후에 실제로 성공하는지 실패하는지를 알아야 시스템에서 재시도 횟수를 어느 정도로 하는 게 적당한지 판단할 수 있다. 503 -> 200, 503 -> 503 -> 200의 두 케이스도 구분해서 보고 싶었는데 이걸 구분할 수 있는 방법은 찾지 못했다.

이번 테스트는 실제로 무언가를 개선하려는 목적이 아니라, 재시도 동작 방식과 이를 추적하는 메트릭을 확인하려는 목적이었다. 그래서 특별한 결과를 얻지는 못했다. 실제 시스템에 적용하려면 고민해야 할 부분이 더 많기는 하지만, 재시도 관련 메트릭에 어떤 종류가 있는지는 알게 되었다. 이 데모 코드는 GitHub에 올려두었다.

기술 뉴스 #300 : 2026-08-16

2026-08-16T21:54:59+09:00

그 밖의 개발 관련

Agents on Rails: The LLM Benchmark Project : 에이전틱 코딩 도구가 Ruby on Rails 코드베이스에서 실제로 얼마나 잘 동작하는지 측정하는 Agents on Rails의 첫 번째 보고서가 나왔다. 첫 단계에서는 하나의 작고 독립적인 작업을 수행하게 하고 비교했다.(영어)
Introducing Agent Plugins : Vercel, AWS, Anysphere, GitHub, Microsoft, OpenAI가 협력해서 에이전트 기능을 확장하는 플러그인의 벤더 중립적인 표준인 Agent Plugins의 1.0.0을 공개했다. 최상위 매니페스트 plugin.json에 사양을 명시하며 버전 1은 에이전트 스킬과 MCP 서버 두 가지 구성요소에 중점을 두었다.
Introducing Delta : Zed에서 에이전트와 코딩하고 그 결과를 검토할 수 있는 멀티플레이어 환경인 Delta를 비공개 베타로 공개했다.(영어)
Introducing Muse Code and Muse Spark 1.2 : Meta에서 최신 모델인 Muse Spark 1.2를 기반으로 한 터미널 코딩 에이전트 Muse Code를 베타로 출시했다. Muse Code는 비동기 백그라운드 에이전트로 에이전트 기능을 강화했다. Muse Spark 1.1에서 코딩에 중점을 두고 개선한 Muse Spark 1.2는 코드 생성, 복잡한 디버깅, 코드베이스 이해에서 나아졌다.(영어)

AI 관련

Introducing Claude Sonnet 5 : Anthropic에서 최신 Sonnet 모델인 Sonnet 5를 출시했다. Claude Sonnet 5는 Opus 4.8과 비슷한 성능을 보여주지만 가격은 더 저렴하다.(영어)
Introducing Grok 4.6 : SpaceXAI에서 새로운 모델 Grok 4.6을 출시했다. Grok 4.6은 에이전트 코딩 및 지식 작업의 벤치마크에서 최첨단 수준의 지능을 보여주었고 벤치마크 종합 점수에서 GPT-5.6 Sol과 같은 점수를 기록했다.(영어)
제미나이 3.7 플래시를 소개합니다 : Google이 코딩과 에이전트 작업에서 역대 가장 스마트한 Gemini 3.7 Flash를 발표했다.(한국어)
GLM-5.3: Frontier Coding with Emergent Cyber Capabilities : z.ai에서 GLM-5.2와 같은 기반 모델을 쓰지만 사후 학습으로 성능을 끌어올린 GLM-5.3을 출시했다. GLM-5.3은 코딩이 더 강력해졌고 사이버 역량도 발전했다. 가중치는 2주 이내에 공개할 예정이다.(영어)
Qwen3.8-Max: A New Bar for Coding and Cowork : Alibaba가 Qwen에서 가장 뛰어난 모델인 Qwen 3.8-Max를 출시했다. 3.5 아키텍처를 기반으로 구축된 Qwen 3.8-Max는 2.4조 개의 파라미터 규모로 확장되어 코딩, 업무 등 장기 과제에서 개선되었다. 직접 돌려볼 수 있는 Qwen3.8-17B도 공개했다.(영어)
Imagine Image 2.0 : Grok이 새로운 이미지 생성 모델 Imagine Image 2.0을 출시했다. 지침을 잘 따르고 반복 수정도 가능해졌으며 벤치마크에서 gpt-image-2 다음인 2위를 차지했다.(영어)
One-take Creation, Flexible Referencing: Introducing Seedance 2.5 : ByteDance가 최신 비디오 생성 모델인 Seedance 2.5를 출시했다. 2.5는 한 번에 최대 30초 영상을 생성하고 확장을 지원하며 여러 모델을 참조할 수 있다.(영어)
Introducing Grok Bot : SpaceXAI에서 다양한 업무를 맡길 수 있는 에이전트 팀원인 Grok Bot을 베타로 출시했다.(영어)
Introducing Muse Glimmer: An Open Agentic Model That Runs on Your Device : Meta에서 차세대 모델인 Muse Glimmer를 공개했다. Muse Glimmer는 로컬 에이전트 워크플로우에 최적화된 300억 개 파라미터 모델로 개인 장비에서도 실행할 수 있을 정도로 크기가 작다.(영어)
Introducing MAI-Thinking-1 : Microsoft에서 중간 규모 추론 모델인 MAI-THINKING-1을 공개했다. 동일 규모 모델 중 소프트웨어 엔지니어링 벤치마크에서 선도 모델과 대등한 성능을 보이고 블라인드 테스트에서 Sonnet 4.6보다 선호되는 것으로 나타났다.(영어)
Mistral OCR 4.1 : Mistral OCR 4.1이 출시되었다.(영어)

인프라 관련

Observability Is Converging. Humans Aren't the Only Ones Querying It Anymore : 세 가지 기둥인 메트릭, 로그, 트레이스를 하나의 컬럼형 스토어에 저장해 질의하는 통합 옵저버빌리티는 이제 실제 제품이 되었고 여기에 에이전트가 붙기 시작했다. 이는 인터페이스의 변화일 뿐인지 엔진과 데이터베이스의 변화까지 이어질지에 대한 질문을 통해 생각해 볼만한 지점을 알려준다.(영어)
Agents Week에 오신 것을 환영합니다 : Cloudflare에서 Agents Week를 열고 많은 제품을 발표했다. 에이전트를 위해 처음부터 만든 Agent Cloud로 에이전트 네이티브 미래의 기반을 마련하고, 지금의 인간 중심 웹과 앞으로의 에이전트 중심 웹 사이에서 번역 계층 역할을 어떻게 할 것인가가 주제다.(한국어)
- 에이전트에는 컨테이너가 아니라 컴퓨터가 필요합니다 — @cloudflare/computer를 소개합니다 : 에이전트에 격리된 전용 컴퓨터 환경을 제공해 효율성과 확장성을 최적화하는 @cloudflare/computer를 초기 프리뷰로 공개했다. 모든 에이전트에게 컨테이너를 제공하는 방식은 확장성이 부족하기 때문에 더 효율적인 컴퓨팅 요소인 Isolate를 사용해서 상태를 저장할 수 있고 에이전트가 새로운 Isolate를 만들 수 있게 되었다.(한국어)
- Introducing: Cloudflare Agents : Cloudflare에 에이전트를 쉽게 배포하고 관리할 수 있도록 Cloudflare Agents를 발표했다. agent tracing을 사용해서 에이전트가 어떤 작업을 하고 있고 비용이 얼마인지를 추적할 수 있고 에이전트의 실행 내역, 세션, 인스턴스, 토큰 사용량 등을 한 곳에서 볼 수 있게 되었다.(영어)
- Run CI/CD for millions of repos — on your platform, on Cloudflare : Cloudflare에서 코드를 저장하고 빌드하고 테스트할 수 있도록 코드 저장소인 Artifacts를 출시했다. Cloudflare Workflows를 기반으로 구축한 @cloudflare/ci를 사용해서 빌드 자동화와 테스트, 배포를 할 수 있다.(영어)
- Cloudflare Wallets 발표: 에이전트 인터넷을 위한 프로그래밍 가능한 지갑 : 에이전트가 API를 사용할 때 식별자도 없고 결제 수단도 없기 때문에 커머스 시장에서 발생하는 문제를 해결하기 위해 Cloudflare Wallet을 발표했다. Wallet에서 핸들을 등록해서 판매자와 연결할 수 있고 최근 Cloudflare가 발표한 Monetization Gateway를 사용해서 결제도 지원한다.(한국어)
- WriteGuard: Fine-grained controls for MCP Servers : Cloudflare에서 사내 MCP에 쓰기 권한을 확대하기 위해 WriteGuard를 구축했고 이러한 제어 기능을 Cloudflare MCP server portals에 도입하고 있다. WriteGuard는 에이전트가 MCP를 호출할 때 중간에 개입해 도구와 요청 컨텍스트를 보고 차단할지 허용할지 선택한다. 덕분에 MCP 서버를 바꾸지 않고도 도구 정책을 정의할 수 있다.(영어)
- Cloudflare OS: an open platform for agents, apps, and work : 회사마다 맞춰서 자사의 맥락을 이해하고 시스템에 접근하는 에이전트와 워크스페이스 환경을 만드는 Cloudflare OS를 오픈소스로 공개했다. Cloudflare OS는 대화로 시작해서 문서, 앱, 워크플로우로 발전할 수 있도록 만들어졌다.(영어)
- The Agent Access Model : 에이전트의 접근 제어를 어떻게 관리할지에 대한 Agent Access Model(AAM) 논문이다. 기존의 인간 모델과 달리 에이전트는 일시적이지만 인증 정보는 영구적이고 에이전트는 머신 속도로 동작하면서 프롬프트로는 강제할 수 없는데다가 여러 단계에 걸쳐서 권한을 사용하기 때문에 기존 접근 모델을 그대로 사용할 수 없다. AAM은 Zero Trust와 비슷하게 "실행 자체를 신뢰하지 마라"는 원칙에서 출발한다. 자격 증명은 짧은 유효 기간과 특정 작업에 바인딩해 하네스와 네트워크에서 강제하고, 사람의 감독은 예외적인 경우에만 두며, 권한 부여는 증거를 바탕으로 검토하고, 권한 상태는 한 방향으로만 움직인다.
- Give any website a WebMCP interface : Chrome 146에서 실험적으로 적용된 표준인 WebMCP를 이용하면 브라우저에서 실행되는 에이전트가 웹사이트를 탐색할 수 있게 제공할 수 있다. Cloudflare에서 WebMCP를 추가하여 사이트를 바꾸지 않고도 바로 WebMCP를 지원할 수 있게 되었다.(영어)
- Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers : 웹 브라우저는 에이전트가 쓰기엔 무겁고 불필요한 기능도 많아서 Workers 기반으로 동작하는 새 브라우저 Kitesurf를 발표했다. Rust로 작성된 헤드리스 엔진인 obscura에서 영감을 받아 Kitesurf를 만들었다.(영어)
Amazon DynamoDB now supports real-time vector search at any scale : Amazon DynamoDB의 벡터 검색 기능이 정식 출시되어 벡터 임베딩을 저장하고 유사도를 검색할 수 있다. 벡터 인덱스는 용량 제한이 없으며 99% 이상의 리콜률에서 한 자릿수 지연 시간을 보인다. 수조 개의 벡터 규모까지 대응하도록 설계되었다.(영어)
Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard : Kubernetes의 새로운 서비스 네트워킹 API인 Gateway API 1.6.0이 나왔다. 1.6.0에서는 L4 TCP, UDP 트래픽 라우팅이 GA가 되었고 실험용 리소스는 API 그룹이 분리되었다.(영어)
K8gb becomes a CNCF incubating project : Kubernetes 글로벌 서비스 로드 밸런싱 솔루션인 K8GB가 CNCF의 인큐베이션 프로젝트로 승인되었다.(영어)

보안 및 장애

Now we have a timeline of the OpenAI accidental attack against Hugging Face : 지난 달에 OpenAI의 모델을 테스트하다가 제로데이 취약점을 조합해서 Hugging Face를 에이전트가 침해한 보안 사고의 전체 타임라인이 나왔다.(영어)
Expanding Daybreak as the Cyber Defense Window Narrows : OpenAI가 사이버 보안 AI인 Daybreak을 승인된 방어 업무에 맞춰진 Daybreak Blue와 승인된 취약점 연구와 보안 테스트를 하는 Daybreak Red로 확장했다.(영어)
Google’s top hacker hunter explains why hacking groups get codenames : 해킹 단체의 명칭은 기업마다 다르게 짓는다. 이런 이름은 그룹의 특징과 목적을 파악하는 데 큰 출발점이 되므로 꼭 필요하지만, 기업이나 기관마다 관점이 달라 같은 이름을 함께 쓰기는 현실적으로 어렵다. 이러한 명명 체계를 최초로 도입한 Mandiant는 APT1, APT41를 사용했지만 이젠 구글의 일원이 되었고 Google Threat Intelligence Group은 기억하기 쉬운 두 단어의 조합이라는 새로운 명명 규칙을 만들었다.(영어)
Metabase Zero-Day Exploited in Wild Allows Admin Access Without Authentication : BI 솔루션인 Metabase에서 제로데이 취약점을 이용해 공격자가 인증없이 데이터베이스에 접근해서 임의의 SQL을 주입해서 관리자 권한을 획득할 수 있는 공격이 발생했다. Metabase Cloud에서 이 공격이 발생한 걸 확인하고 최신 버전을 배포했다. 이번 공격으로 Framework 등의 기업의 데이터가 유출된 것으로 알려졌다.(영어)
Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack : 널리 사용되는 npm 패키지인 keyv, cacheable 네임스페이스를 포함해서 서로 다른 관리자가 소유한 10여개의 패키지에 preinstall 훅을 사용한 악성 버전이 발행되었다. 이 악성 버전은 클라우드나 CI의 자격 증명을 탈취하고, 이렇게 얻은 npm 토큰으로 다른 패키지에 트로이목마를 다시 심는다.(영어)
CNCF Announces Graduation of Cloud Native Buildpacks, Advancing the Standard for Container Builds : CNCF가 OCI 표준을 준수하는 컨테이너 이미지를 빌드하는 Buildpacks의 졸업을 발표했다.(영어)

IT 업계 뉴스

New Mexico court orders Meta to pay additional $567M in child safety case : 미국 뉴멕시코주의 법원이 소셜 미디어로 인한 피해와 중독과 관련된 소송에서 지난 3월에 부과한 3억 7,500만 달러에 더해 5억 6,700만 달어의 벌금을 납부하라고 명령해서 벌금 총액이 9억 4,200만 달러가 되었다. 또한 법원은 "좋아요" 수를 없애고 18세 미만 미성년자에게는 부모나 보호자의 승인을 받은 경우에만 표시하도록 요구했다. 미성년 사용자에게는 오후 10시부터 오전 7시까지 푸시 알림을 중단하고 사용 시간을 월 90시간으로 제한하게 했다.(영어)
The next chapter of our AI momentum : Google과 Alphabet의 CEO인 Sundar Pichai가 AI 최전선에 계속 집중해야 한다며 Google DeepMind에 변화를 발표했다. Demis Hassabis가 Isomorphic Labs를 계속 이끌면서 Google DeepMind의 의장 겸 Alphabet의 Chief Scientist로 승진하고 GoogleDeepMind의 CTO이자 AI 아키텍트인 Koray Kavukcuoglu가 Google DeepMind의 수석 부사장(SVP)로 승진했다.(영어)
Announcing Discovery Loop! : Google의 전설적인 프로그래머 중 한명인 Jeff Dean이 오랜 동료인 Sanjay Ghemawat, Quoc Le, Oriol Vinyals 셋과 함께 Discovery Loop를 창업했다. Discovery Loop는 공익 법인으로 탐구 과정을 AI로 자동화하여 전세계 과학과 공학 발전을 가속하는 것을 목표로 하고 있다.(영어)
Apple pulls Telegram from app store, gets a snarky response : Apple이 아동 성 착취물 관련한 컨텐츠로 애플 가이드라인을 위반했다고 Telegram을 지난 4일 앱 스토어에서 삭제했다가 복구했다.(영어)
Apple says more ex-employees may have taken confidential data to OpenAI : Apple이 OpenAI를 상대로 영업비밀 침해 소송을 걸었다. 이는 전직 Apple 직원이 Apple의 기밀 정보를 OpenAI에 유출했다고 주장하는 것이고 OpenAI는 이는 허위사실이라고 얘기하고 있다.(영어)
토종 OTT 왓챠, 키노라이츠 품으로…인수 가격은 42억 5천만 원 : 기업 회생절차를 밟고 있는 OTT 회사 Watcha를 콘텐츠 추천 플랫폼인 키노라이츠가 42억 5천만원에 인수하게 되었다.(한국어)
Firetiger가 Cursor에 합류합니다 : 소프트웨어를 프로덕션에 배포한 후 이를 관리하는 에이전트를 만드는 Firetiger를 Cursor가 인수했다.(한국어)

프로젝트

celld : 셀프 호스티드로 Cloudflare Workers와Durable Objects를 실행하는 오픈소스 데몬으로 Deno에서 만들었다.
Skill Recorder : 데스크탑에서 앱 선택 클릭 등 화면에서 진행된 작업을 녹화해서 GitHub Copilot CLI를 통해 스킬로 만드는 프로그램으로 Microsoft에서 만들었다.
qm : YC Combinator가 내부에서 사용하던 다중 사용자 에이전트 하네스를 오픈소스로 공개했다.
VideoSeal : Facebook에서 공개한 눈에 보이지 않은 이미지/비디오 워터마킹 모델.
Xirp : Spotify가 공개한 에이전트 기반 개발환경
DeepSeek Harness : DeepSeek AI에서 만든 오픈소스 에이전트 하네스
Gloomberb : 오픈소스 금융 터미널

버전 업데이트

Lerna v10.0.0 : JavaScript 모노레포 도구, 릴리스 공지
SolidStart v2.0.0 : SolidJS 앱용 자바스크립트 프레임워크, 릴리스 공지
astro v7.2.0 : JavaScript 웹 프레임워크, 릴리스 공지
Node.js v26.7.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.19.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Playwright v1.62 : Chromium, Firefox, WebKit 브라우저 자동화 Node.js 라이브러리, 릴리스 공지
Argo CD v3.5.0 : Kubernetes 배포 도구, 릴리스 공지
Hono v4.13 : 엣지용 웹 프레임워크, 릴리스 공지
Next.js v16.3 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지
ClickHouse v26.7 : 컬럼형 데이터베이스, 릴리스 공지
FFmpeg v8.1 : 오디도/비디오 변환 프레임워크, 릴리스 공지
Flutter v3.47 : iOS, Android 네이티브 앱을 만드는 프레임워크, 릴리스 공지
Angular v22.1.0 : JavaScript 프레임워크, 릴리스 공지
Solid.js v2.0.0 RC : JavScript UI 라이브러리, 릴리스 공지
React Native v0.87.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
Packer v1.16.0 : 머신 이미지 생성 도구, 릴리스 공지
GitButler v0.22.0 : Git 클라이언트, 릴리스 공지

[Side Project] 코딩 세션을 모아 보는 Agentic Engineering History

2026-08-15T19:18:00+09:00

최근 LLM 사용 패턴을 파악해 보려고 LLM Usage Tracker를 만들고 나서, 블로그 글을 쓰려다 보니 기록을 보기 어렵다는 생각이 들었다. 아무래도 만드는 중에는 그 과정에 집중하다가, 어느 정도 완료되면(아직 마음의 결정을 하지 못해서 오픈소스로 공개하진 않지만...) 정리해서 개발 과정을 블로그에 남기고 싶다. 그런데 이때 예전 기록을 찾기가 어렵다는 걸 깨달았다.

로컬에 jsonl 파일로 세션 기록이 남아 있기는 하다. 조사해 보니 Claude Code는 30일 동안 보관하고(설정 가능함) Codex는 따로 정리하지 않아서 계속 쌓인다. 그래서 여길 보면 내용을 알 수 있고, 채팅으로 찾아 달라고 요청하면 잘 찾아주기도 한다. 하지만 커밋하진 않았어도 HTML이나 마크다운으로 정리한 내용, 검토했던 디자인 시안 등 개발 중간 과정을 보면서 글을 쓰고 싶었다. 그런데 없어진 기록이나 파일도 있어서 이런 작업 과정을 어딘가에 저장해 놓고 살펴보고 싶었다.

그래서 Agentic Engineering History를 만들기 시작했다. 사실 사용성이나 활용도 면에서 많이 부족하다고 느껴서 앞으로의 방향성을 고민하고 있는 프로젝트다. 그럼에도 글을 쓰는 건 1차 목표가 끝나서 기록도 남기고 회고하려는 뜻에서다. 또 글을 써야 이 프로젝트를 실제로 써 보면서 사용성을 다시 고민할 수 있다.

Agentic Engineering History 개발

Agentic Engineering History는 Claude Code나 Codex 같은 코딩 에이전트의 세션 기록을 모아 두는 서비스다. 내가 LLM한테 뭔가 요청하고 대화하면서 LLM이 작업한 내용을 다 남겨 두고, 나중에 필요할 때 찾아보려고 만들었다.

초기에 이 프로젝트로 하고 싶은 목표를 정하고 기본 골격을 잡기 시작했다. 프로젝트도 만들지만 테스트 목적도 있어서 처음 제안한 스택 위에서 내 취향에 대한 의견을 주면서 맞춰 가는 편이다. 결국 TypeScript에 oxlint, oxfmt, vitest를 쓰고, CSR을 선호하는 편은 아니라서 htmx를 써서 하이퍼미디어 방식의 SSR로 구현하도록 스택을 정했다. 한번 써 보고 싶어서 htmx를 선택했지만, 간단한 서비스이기도 하고 기술적 문제를 같이 고민한 것도 아니라 이걸 써 봤다고 할 수 있나 하는 생각이 들었다.

이 프로젝트를 하던 때는 한창 Loop Engineering이 유행하던 시기였다. 나는 주로 계속 검토하고 피드백하면서 작업하는 편이라 장기간 작업을 시키는 게 익숙지 않았다. 그래서 시험도 해 볼 겸 그때까지 잡은 방향성을 기준으로 Loop Engineering 자료를 주고 시도해 봤다.

Claude Code에서 Opus 4.8을 주로 사용했는데, 어느 정도는 장기간 작업이 돌아갔지만 기대만큼 오래 실행되지는 않고 자주 멈췄다. 다른 프로젝트지만 비슷한 시기에 Codex에서도 /goal로 시도했는데, 오히려 이쪽은 초기 목표를 너무 크게 줘서 그런지 거의 한 달 내내 돌아가서 느낌이 또 달랐다. 똑같은 방식으로 한 건 아니었지만, 이 차이는 모델보다는 내가 아직 하네스와 계획, 목표 설정에 능숙하지 않아서 생긴 것으로 느껴졌다.

Loop Engineering을 내가 잘 못해서 그런지(더 연습하긴 해야 하는데...) 결과는 적당히 만족스러운 수준이라, 그 이후에는 기존처럼 대화하면서 작업했다. 종종 생각하는데, 나는 구체적으로 어떻게 할지 명확히 정해 놓고 하기보다 머릿속의 막연한 생각을 얘기하고 설명하는 쪽이다. 그렇게 만들어진 결과를 보면서 결정하는 편이라 이 방식이 더 맘에 든다.

그동안 안 써 보던 다른 서비스도 써 보자는 생각에 이번에는 Cloudflare를 쓰기로 했다. Cloudflare Workers와 Cloudflare D1에 배포하도록 작업했고, 클라우드에 배포하므로 인증은 Cloudflare Access로 연결했다. 이후에 써 보니 어차피 작업해 두면 크게 신경 쓸 건 없었다. 다만 Google 로그인은 늘 구글에 로그인되어 있어서 쓰기 편한 데 비해, Cloudflare는 로그인해 둘 일이 많지 않다 보니 오히려 그 부분이 불편했다.

얼마 전에 만든 LLM Usage Tracker와 데이터를 로컬에서 수집해 원격에서 모아 보여주는 방식이 사실상 똑같아서, 기존과 유사한 구조를 사용했다. 로컬에 Claude Code와 Codex의 세션을 분석하고 수집해서 업로드하는 collector를 만들고, API 키로 원격 서버에 데이터를 계속 보내도록 했다.

UI

어느 정도 기능이 만들어지자 이제 UI를 본격적으로 만들기 시작했다. 혼자 사용하는 서비스라서 디자인을 디테일하게 챙기진 않는다. 요즘은 대충 말해도 디자인을 잘 뽑아내다 보니 시안의 초기 느낌만으로 고르고 이후에 개선해 나간다.

시안 A: 미니멀

시안 B: 에디토리얼

시안 C: 터미널

다 비슷한 느낌이지만(시안을 더 다양하게 받는 방법도 고민해 봐야겠다.) A 미니멀 버전을 선택하고 UI를 사용하면서 불편하다고 생각하는 부분을 계속 개선했다.

세션 목록은 마지막 대화 시간을 기준으로 보이게 했다. 그리고 로컬에서는 정액 요금제를 쓰고 있어서, collector가 세션을 업로드할 때 로컬에서 LLM을 사용해 내용 파악이 쉬운 제목을 붙이도록 했다. 서버에서 하면 더 잘하겠지만 그러면 비싼 API를 써야 해서 어쩔 수 없는 선택이다.

세션의 분량을 파악하기 쉽게 내가 얘기한 채팅과 LLM이 대답한 채팅, 서브에이전트의 채팅을 구분해서 보여준다. 사용한 모델도 쉽게 알아볼 수 있게 했다. Claude Code와 Codex도 계속 기능이 추가되어서 발견할 때마다 반영하고 있다. 다만 프로젝트라는 개념이 엄격하진 않아서 작업 폴더를 기준으로 프로젝트를 인식하도록 했는데, 잘못 판단하는 경우가 꽤 있어서 개선이 필요하다.

세션 상세는 채팅과 작업 내용을 쉽게 파악하는 게 목적인데, 양이 워낙 많아서 아직 어렵다. 불필요한 부분은 최대한 접게 했지만 여전히 많아서, 내용을 쉽게 파악하고 필요하면 더 자세히 볼 수 있는 방법을 고민 중이다.

세션 기록과 함께 중간에 생성한 에셋도 관리하는 게 목적이어서, 스샷을 찍거나 나한테 보여준 에셋 파일도 다 남기고 쉽게 볼 수 있게 구성했다. 그럼에도 아직 파악이 어려워서(사실 누락이 있을 수도 있고) 더 나은 방법을 고민 중이다.

세션의 구성을 쉽게 파악하고 탐색할 수 있도록 화면 우측에 레일 형식의 네비게이션을 구성했다. UI에서 이런 레일 형식의 네비게이션은 개인적으로 좋아하는 편이지만 사실 잘 써 본 적은 없어서 이번에도 시도해 보게 되었다. 한눈에 내가 얼마나 대화했고 그에 따라 코딩 에이전트가 얼마나 대답했는지 파악할 수 있게 했다. 최근엔 코딩 에이전트가 서브에이전트를 많이 사용해서 이 부분을 별도로 분리하고 서브에이전트의 작업도 표시하게 했더니, 저렇게 사람 이름처럼 이름이 붙어서 표시되었다.

내가 말한 부분으로 빠르게 이동하려고 네비게이션 기능도 넣었다. 다만 긴 세션 내용을 한 번에 로딩하지 않고 무한 스크롤로 채워지도록 구성해서, 특정 위치로 한 번에 움직이는 동작이 아직 어색해 고쳐야 한다.

에필로그

글 앞에서 말한 대로 이 프로젝트의 방향성은 아직 고민 중이다. 통계용 서비스라는 게 꼭 매일 봐야 의미가 있는 건 아니다. 그래도 현재 버전을 만족스럽게 개선하지 못하고 있어서 뭔가 부족하다는 생각이 든다.

일단 써 봐야 더 개선할 수 있으니, 그사이에 만든 사이드 프로젝트도 하나씩 정리해서 올려 보면서 고민할 생각이다. 이 프로젝트를 거의 만들었을 때쯤 다른 사람한테 AgentsView를 소개받았다. 훨씬 잘 만든 건 두말할 필요도 없고, LLM Usage Tracker와 별도로 만들 게 아니라 합쳤어야 했나 하는 생각도 하고 있다.

Istio External Authorization의 로컬리티 로드 밸런싱 확인하기

2026-08-05T00:22:09+09:00

수많은 마이크로서비스가 있을 때 일부 서비스에 공통 인증이 필요한 상황을 가정해 보자. 비교적 간단한 JWT 토큰을 검증하는 정도라면 Istio의 RequestAuthentication을 사용할 수 있겠지만 더 복잡한 인증 로직이 있다면 이를 사용할 수 없다.

내부에 인증 서버가 이미 구축돼 있다고 할 때, 인증이 필요한 서비스는 인증 서버를 거치도록 해야 한다. 각 서비스에서 인증 서버로 리다이렉트하거나, 요청을 처리하기 전에 인증 서버에서 인증 여부를 확인하도록 구현할 수도 있다. 하지만 모든 서비스가 이를 구현하면 작업 비용이 많이 들고 구현 수준도 달라져 좋지 않다. 그런 면에서 가능하다면 인프라 차원에서 처리하는 것이 훨씬 좋다.

Istio는 이러한 경우에 External Authorization과 Authorization Policy를 이용해 인증을 위임할 수 있도록 지원한다. 이때 설정에는 <service-name>.<namespace>.svc.cluster.local 형식의 클러스터 도메인을 지정한다. 이 설정에도 Istio의 Locality 로드 밸런싱이 적용되는지 궁금해 찾아보았다.

External Authorization

먼저 External Authorization이 무엇인지 살펴보자.

 1apiVersion: install.istio.io/v1alpha1
 2kind: IstioOperator
 3metadata:
 4  name: istio-lab
 5  namespace: istio-system
 6spec:
 7  meshConfig:
 8    extensionProviders:
 9      - name: extauth
10        envoyExtAuthzGrpc:
11          service: extauth-server.extauth.svc.cluster.local
12          port: "8085"
13          statusOnError: "500"

Istio의 전역 설정인 meshConfig에서 extensionProviders에 envoyExtAuthzGrpc나 envoyExtAuthzHttp를 지정하면 클러스터에서 외부 인증을 사용할 수 있다. 위 예시는 envoyExtAuthzGrpc를 사용한다.

여기서 gRPC와 HTTP는 Envoy가 인증을 위임할 때 사용하는 프로토콜이므로, 실제 서비스 트래픽이 HTTP인지 gRPC인지는 상관없다. 두 구현체는 동작이 다르다. 일반적으로 인증 서버는 gRPC로 더 많이 구현하는 것으로 보인다. 대표적인 차이점은 envoyExtAuthzGrpc가 기본적으로 모든 헤더와 호출한 서비스 정보를 전달한다는 점이다. 반면 envoyExtAuthzHttp는 헤더를 설정에 명시해야 전달하며 호출한 서비스 정보는 전달하지 않는다.

이렇게 설정한 envoyExtAuthzGrpc나 envoyExtAuthzHttp는 Authorization Policy를 이용해서 인증을 위임할 수 있다.

 1apiVersion: security.istio.io/v1
 2kind: AuthorizationPolicy
 3metadata:
 4  name: demo-app
 5  namespace: demo
 6spec:
 7  selector:
 8    matchLabels:
 9      app: demo-app
10  action: CUSTOM
11  provider:
12    name: extauth
13  rules:
14    - to:
15        - operation:
16            methods:
17              - GET
18            paths:
19              - /api/*

이렇게 구성하면 demo-app으로 들어오는 요청 중 /api/로 시작하는 GET 요청은 아래 그림처럼 extauth 서버로 전달된다.

demo-app.example.com/api로 GET 요청이 들어온다.
istio-proxy가 받아서 AuthorizationPolicy를 확인하고 demo-app으로 요청을 보내기 전에 extauth-server.extauth.svc.cluster.local로 extauth-server로 보낸다.
extauth-server는 auth-backend에 요청을 보내 인증을 확인한다. (사실 이 과정은 필요 없고 일반적인 서버 간 호출일 뿐이지만 인증 로직의 복잡성을 표현하려고 추가했다.)
인증에 성공하면 demo-app의 istio-proxy가 응답을 받고 demo-app으로 요청을 전달한다. 실패하면 요청을 즉시 거절한다. (demo-app에는 트래픽이 전혀 들어가지 않는다.)

인증이 필요한 곳에 AuthorizationPolicy를 설정하면 쉽게 인증을 연동할 수 있고 서비스마다 구현 수준이 다른 문제도 쉽게 피할 수 있다.

Locality Load Balancing

로컬리티 로드 밸런싱은 워크로드의 지리적 위치를 고려해 같은 지역으로 트래픽을 먼저 보내는 설정이다. 다음 세 레이블을 이용한다.

리전: topology.kubernetes.io/region
존: topology.kubernetes.io/zone
서브존: topology.istio.io/subzone

같은 지역에 있으면 지리적으로 가까워 응답 속도가 빨라질 가능성이 크다. 존이나 리전이 다르면 트래픽 비용이 발생할 수 있어 비용을 줄이는 효과도 있다.

1meshConfig:
2  extensionProviders:
3    - name: extauth
4      envoyExtAuthzGrpc:
5        service: extauth-server.extauth.svc.cluster.local
6        port: "8085"
7        statusOnError: "500"
8  localityLbSetting:
9    enabled: True

meshConfig에서 localityLbSetting.enabled를 True로 설정하면 전역에서 로컬리티가 활성화된다. 다만 이 설정만으로 로컬리티 로드 밸런싱이 동작하지는 않는다.

로컬리티는 다음과 같은 조건을 계산하면서 적용된다.

녹색 박스로 표시된 조건에 도달해야 실제로 로컬리티 로드밸런싱이 적용된다고 보면 된다.

distribute

조건 중 첫 번째에 해당하는 distribute는 DestinationRule에서 설정할 수 있다. 아래와 같이 레이블별로 가중치를 지정하면 그 가중치에 따라 로컬리티 로드 밸런싱이 동작한다.

 1apiVersion: networking.istio.io/v1
 2kind: DestinationRule
 3metadata:
 4  name: demo-app
 5spec:
 6  host: demo-app.example.com
 7  trafficPolicy:
 8    loadBalancer:
 9      localityLbSetting:
10        enabled: true
11        distribute:
12        - from: region1/zone1/*
13          to:
14            "region1/zone1/*": 70
15            "region1/zone2/*": 20
16            "region3/zone4/*": 10

outlierDetection

두 번째 조건인 outlierDetection도 DestinationRule에서 설정한다. outlierDetection은 업스트림 서비스 상태에 따라 서킷 브레이커를 구현하는 방식이며, 같은 지역에 문제가 생겼을 때 페일오버를 위해 필요하다.

 1apiVersion: networking.istio.io/v1
 2kind: DestinationRule
 3metadata:
 4  name: demo-app
 5spec:
 6  host: demo-app.example.com
 7  trafficPolicy:
 8    connectionPool:
 9      tcp:
10        maxConnections: 100
11      http:
12        http2MaxRequests: 1000
13        maxRequestsPerConnection: 10
14    outlierDetection:
15      consecutive5xxErrors: 7
16      interval: 5m
17      baseEjectionTime: 15m

로컬리티 데모

동작을 자세히 이해하려고 데모 앱을 구성했다. 이제는 AI로 이런 데모 앱을 쉽게 만들 수 있으니 참 신기한 세상이다.

데모는 kind를 사용했다. 로컬에서 Kubernetes를 테스트할 때 가장 편하다고 생각한다.

Kind 클러스터 설정

 1# kind-config.yaml
 2kind: Cluster
 3apiVersion: kind.x-k8s.io/v1alpha4
 4name: istio-lab
 5networking:
 6  ipFamily: ipv4
 7nodes:
 8  - role: control-plane
 9    image: kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5
10    extraPortMappings:
11      - containerPort: 30080
12        hostPort: 8080
13        listenAddress: "127.0.0.1"
14        protocol: TCP
15      - containerPort: 30443
16        hostPort: 8443
17        listenAddress: "127.0.0.1"
18        protocol: TCP
19  - role: worker
20    image: kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5
21    kubeadmConfigPatches:
22      - |
23        kind: JoinConfiguration
24        nodeRegistration:
25          kubeletExtraArgs:
26            node-labels: "topology.kubernetes.io/zone=zone-a"
27  - role: worker
28    image: kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5
29    kubeadmConfigPatches:
30      - |
31        kind: JoinConfiguration
32        nodeRegistration:
33          kubeletExtraArgs:
34            node-labels: "topology.kubernetes.io/zone=zone-a"
35  - role: worker
36    image: kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5
37    kubeadmConfigPatches:
38      - |
39        kind: JoinConfiguration
40        nodeRegistration:
41          kubeletExtraArgs:
42            node-labels: "topology.kubernetes.io/zone=zone-c"
43  - role: worker
44    image: kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5
45    kubeadmConfigPatches:
46      - |
47        kind: JoinConfiguration
48        nodeRegistration:
49          kubeletExtraArgs:
50            node-labels: "topology.kubernetes.io/zone=zone-c"

이 kind-config.yaml를 사용해서 Kubernetes 클러스터를 생성한다.

 1$ kind create cluster --config kind-config.yaml --wait 5m
 2Creating cluster "istio-lab" ...
 3 ✓ Ensuring node image (kindest/node:v1.36.1) 🖼
 4 ✓ Preparing nodes 📦 📦 📦 📦 📦
 5 ✓ Writing configuration 📜
 6 ✓ Starting control-plane 🕹️
 7 ✓ Installing CNI 🔌
 8 ✓ Installing StorageClass 💾
 9 ✓ Joining worker nodes 🚜
10 ✓ Waiting ≤ 5m0s for control-plane = Ready ⏳
11 • Ready after 9s 💚
12Set kubectl context to "kind-istio-lab"
13You can now use your cluster with:
14
15kubectl cluster-info --context kind-istio-lab
16
17Thanks for using kind! 😊

클러스터 설정에서 보듯이 컨트롤 플레인 1대와 워커 노드 4대가 있는데 2대는 a존에 2대는 c존에 배치된 것처럼 topology.kubernetes.io/zone 레이블을 설정했다.

1$ kubectl get nodes -L topology.kubernetes.io/zone
2NAME                      STATUS   ROLES           AGE   VERSION   ZONE
3istio-lab-control-plane   Ready    control-plane   24m   v1.36.1
4istio-lab-worker          Ready    <none>          23m   v1.36.1   zone-a
5istio-lab-worker2         Ready    <none>          23m   v1.36.1   zone-a
6istio-lab-worker3         Ready    <none>          23m   v1.36.1   zone-c
7istio-lab-worker4         Ready    <none>          23m   v1.36.1   zone-c

Istio 설치

클러스터에 Istio를 설치한다.(실제 설정은 데모앱을 구현하기 위해 좀더 설정이 있지만 여기서는 예제와 관련된 주요 설정만 넣었다.)

 1# istio-operator.yaml
 2apiVersion: install.istio.io/v1alpha1
 3kind: IstioOperator
 4metadata:
 5  name: istio-lab
 6  namespace: istio-system
 7spec:
 8  profile: demo
 9  meshConfig:
10    localityLbSetting:
11      enabled: false
12    extensionProviders:
13      - name: extauth
14        envoyExtAuthzGrpc:
15          service: extauth-server.extauth.svc.cluster.local
16          port: "8085"
17          statusOnError: "500"
18  components:
19    ingressGateways:
20      - name: istio-ingressgateway
21        enabled: true
22        k8s:
23          overlays:
24            - kind: Service
25              name: istio-ingressgateway
26              patches:
27                - path: spec.ports.[name:http2].nodePort
28                  value: 30080
29                - path: spec.ports.[name:https].nodePort
30                  value: 30443
31  values:
32    gateways:
33      istio-ingressgateway:
34        type: NodePort
35

데모 앱

상황을 재현하는 데모 앱은 app-a, app-b, extauth로 구성했다. 모두 replica를 2개로 설정하고 topologySpreadConstraints를 사용해 a 존과 c 존에 하나씩 배치했다. (아래에는 시각화 등을 위한 추가 설정을 제외하고, 데모 시나리오와 관련된 주요 설정만 간추렸다.)

  1# app-a.yaml
  2apiVersion: apps/v1
  3kind: Deployment
  4metadata:
  5  name: app-a
  6  namespace: app-a
  7  labels:
  8    app: app-a
  9spec:
 10  replicas: 2
 11  strategy:
 12    type: RollingUpdate
 13    rollingUpdate:
 14      maxSurge: 0
 15      maxUnavailable: 1
 16  selector:
 17    matchLabels:
 18      app: app-a
 19  template:
 20    metadata:
 21      labels:
 22        app: app-a
 23    spec:
 24      serviceAccountName: app-a
 25      topologySpreadConstraints:
 26        - maxSkew: 1
 27          minDomains: 2
 28          topologyKey: topology.kubernetes.io/zone
 29          whenUnsatisfiable: DoNotSchedule
 30          nodeTaintsPolicy: Honor
 31          labelSelector:
 32            matchLabels:
 33              app: app-a
 34        - maxSkew: 1
 35          topologyKey: kubernetes.io/hostname
 36          whenUnsatisfiable: DoNotSchedule
 37          nodeTaintsPolicy: Honor
 38          labelSelector:
 39            matchLabels:
 40              app: app-a
 41      containers:
 42        - name: app-a
 43          image: python:3.13-alpine
 44          imagePullPolicy: IfNotPresent
 45          command:
 46            - python
 47            - /app/server.py
 48          ports:
 49            - name: http
 50              containerPort: 8080
 51---
 52apiVersion: v1
 53kind: Service
 54metadata:
 55  name: app-a
 56  namespace: app-a
 57spec:
 58  selector:
 59    app: app-a
 60  ports:
 61    - name: http
 62      port: 8080
 63      targetPort: http
 64---
 65apiVersion: security.istio.io/v1
 66kind: AuthorizationPolicy
 67metadata:
 68  name: app-a-extauth
 69  namespace: app-a
 70spec:
 71  selector:
 72    matchLabels:
 73      app: app-a
 74  action: CUSTOM
 75  provider:
 76    name: extauth
 77  rules:
 78    - to:
 79        - operation:
 80            methods:
 81              - GET
 82            paths:
 83              - /auth
 84---
 85apiVersion: networking.istio.io/v1
 86kind: Gateway
 87metadata:
 88  name: app-a-gateway
 89  namespace: app-a
 90spec:
 91  selector:
 92    istio: ingressgateway
 93  servers:
 94    - port:
 95        number: 80
 96        name: http
 97        protocol: HTTP
 98      hosts:
 99        - app-a.example.test
100---
101apiVersion: networking.istio.io/v1
102kind: VirtualService
103metadata:
104  name: app-a
105  namespace: app-a
106spec:
107  hosts:
108    - app-a.example.test
109  gateways:
110    - app-a-gateway
111  http:
112    - corsPolicy:
113        allowOrigins:
114          - exact: http://visualize.example.test:8080
115        allowMethods:
116          - GET
117          - OPTIONS
118        allowHeaders:
119          - x-request-id
120          - x-ext-authz
121      route:
122        - destination:
123            host: app-a
124            port:
125              number: 8080

  1# app-b.yaml
  2apiVersion: apps/v1
  3kind: Deployment
  4metadata:
  5  name: app-b
  6  namespace: app-b
  7  labels:
  8    app: app-b
  9    app.kubernetes.io/name: app-b
 10    app.kubernetes.io/version: v1
 11spec:
 12  replicas: 2
 13  strategy:
 14    type: RollingUpdate
 15    rollingUpdate:
 16      maxSurge: 0
 17      maxUnavailable: 1
 18  selector:
 19    matchLabels:
 20      app: app-b
 21  template:
 22    metadata:
 23      labels:
 24        app: app-b
 25        app.kubernetes.io/name: app-b
 26        app.kubernetes.io/version: v1
 27    spec:
 28      serviceAccountName: app-b
 29      securityContext:
 30        runAsNonRoot: true
 31        runAsUser: 10001
 32        runAsGroup: 10001
 33      topologySpreadConstraints:
 34        - maxSkew: 1
 35          minDomains: 2
 36          topologyKey: topology.kubernetes.io/zone
 37          whenUnsatisfiable: DoNotSchedule
 38          nodeTaintsPolicy: Honor
 39          labelSelector:
 40            matchLabels:
 41              app: app-b
 42        - maxSkew: 1
 43          topologyKey: kubernetes.io/hostname
 44          whenUnsatisfiable: DoNotSchedule
 45          nodeTaintsPolicy: Honor
 46          labelSelector:
 47            matchLabels:
 48              app: app-b
 49      containers:
 50        - name: app-b
 51          image: python:3.13-alpine
 52          imagePullPolicy: IfNotPresent
 53          command:
 54            - python
 55            - /app/server.py
 56          env:
 57            - name: APP_NAME
 58              value: app-b
 59            - name: PORT
 60              value: "8080"
 61            - name: PYTHONDONTWRITEBYTECODE
 62              value: "1"
 63            - name: POD_NAME
 64              valueFrom:
 65                fieldRef:
 66                  fieldPath: metadata.name
 67            - name: POD_IP
 68              valueFrom:
 69                fieldRef:
 70                  fieldPath: status.podIP
 71            - name: NODE_NAME
 72              valueFrom:
 73                fieldRef:
 74                  fieldPath: spec.nodeName
 75            - name: POD_NAMESPACE
 76              valueFrom:
 77                fieldRef:
 78                  fieldPath: metadata.namespace
 79          ports:
 80            - name: http
 81              containerPort: 8080
 82          readinessProbe:
 83            httpGet:
 84              path: /healthz
 85              port: http
 86            initialDelaySeconds: 1
 87            periodSeconds: 3
 88          livenessProbe:
 89            httpGet:
 90              path: /healthz
 91              port: http
 92            initialDelaySeconds: 3
 93            periodSeconds: 10
 94          resources:
 95            requests:
 96              cpu: 25m
 97              memory: 32Mi
 98            limits:
 99              cpu: 250m
100              memory: 128Mi
101          securityContext:
102            allowPrivilegeEscalation: false
103            readOnlyRootFilesystem: true
104            capabilities:
105              drop:
106                - ALL
107          volumeMounts:
108            - name: app-code
109              mountPath: /app
110              readOnly: true
111      volumes:
112        - name: app-code
113          configMap:
114            name: app-b-code
115---
116apiVersion: v1
117kind: Service
118metadata:
119  name: app-b
120  namespace: app-b
121spec:
122  selector:
123    app: app-b
124  ports:
125    - name: http
126      port: 8080
127      targetPort: http
128---
129apiVersion: networking.istio.io/v1
130kind: Gateway
131metadata:
132  name: app-b-gateway
133  namespace: app-b
134spec:
135  selector:
136    istio: ingressgateway
137  servers:
138    - port:
139        number: 80
140        name: http
141        protocol: HTTP
142      hosts:
143        - app-b.example.test
144---
145apiVersion: networking.istio.io/v1
146kind: VirtualService
147metadata:
148  name: app-b
149  namespace: app-b
150spec:
151  hosts:
152    - app-b.example.test
153  gateways:
154    - app-b-gateway
155  http:
156    - route:
157        - destination:
158            host: app-b
159            port:
160              number: 8080

이 두 앱은 app-a가 app-b를 호출하는 관계다.

테스트를 위해 /etc/hosts에 아래 도메인을 등록했다.

1127.0.0.1 app-a.example.test
2127.0.0.1 app-b.example.test
3127.0.0.1 extauth.example.test
4127.0.0.1 visualize.example.test

이렇게 설정하고 나면 app-a.example.test:8080/hello로 GET 요청을 보내면 app-a를 거쳐서 app-b까지 호출한 뒤에 응답을 돌려준다.

아래는 app-a에서 인증을 위임할 extauth에 대한 구성이다.

  1# extauth.yaml
  2apiVersion: apps/v1
  3kind: Deployment
  4metadata:
  5  name: extauth-server
  6  namespace: extauth
  7  labels:
  8    app: extauth-server
  9spec:
 10  replicas: 2
 11  strategy:
 12    type: RollingUpdate
 13    rollingUpdate:
 14      maxSurge: 0
 15      maxUnavailable: 1
 16  selector:
 17    matchLabels:
 18      app: extauth-server
 19  template:
 20    metadata:
 21      labels:
 22        app: extauth-server
 23    spec:
 24      serviceAccountName: extauth-server
 25      securityContext:
 26        runAsNonRoot: true
 27        runAsUser: 10001
 28        runAsGroup: 10001
 29      topologySpreadConstraints:
 30        - maxSkew: 1
 31          minDomains: 2
 32          topologyKey: topology.kubernetes.io/zone
 33          whenUnsatisfiable: DoNotSchedule
 34          nodeTaintsPolicy: Honor
 35          labelSelector:
 36            matchLabels:
 37              app: extauth-server
 38        - maxSkew: 1
 39          topologyKey: kubernetes.io/hostname
 40          whenUnsatisfiable: DoNotSchedule
 41          nodeTaintsPolicy: Honor
 42          labelSelector:
 43            matchLabels:
 44              app: extauth-server
 45      containers:
 46        - name: extauth-server
 47          image: gcr.io/istio-testing/ext-authz@sha256:20ed075acb84d9a3ffaa2ded4d7945cb49bed5fbb14a3d6fc6e09ff85848942a
 48          imagePullPolicy: IfNotPresent
 49          ports:
 50            - name: http
 51              containerPort: 8000
 52            - name: grpc
 53              containerPort: 9000
 54          readinessProbe:
 55            tcpSocket:
 56              port: grpc
 57            initialDelaySeconds: 1
 58            periodSeconds: 3
 59          livenessProbe:
 60            tcpSocket:
 61              port: grpc
 62            initialDelaySeconds: 3
 63            periodSeconds: 10
 64          resources:
 65            requests:
 66              cpu: 25m
 67              memory: 32Mi
 68            limits:
 69              cpu: 250m
 70              memory: 128Mi
 71          securityContext:
 72            allowPrivilegeEscalation: false
 73            readOnlyRootFilesystem: true
 74            capabilities:
 75              drop:
 76                - ALL
 77---
 78apiVersion: v1
 79kind: Service
 80metadata:
 81  name: extauth-server
 82  namespace: extauth
 83spec:
 84  selector:
 85    app: extauth-server
 86  ports:
 87    - name: grpc
 88      appProtocol: grpc
 89      port: 8085
 90      targetPort: grpc
 91    - name: http
 92      appProtocol: http
 93      port: 8080
 94      targetPort: http
 95---
 96apiVersion: networking.istio.io/v1
 97kind: Gateway
 98metadata:
 99  name: extauth-gateway
100  namespace: extauth
101spec:
102  selector:
103    istio: ingressgateway
104  servers:
105    - port:
106        number: 80
107        name: http
108        protocol: HTTP
109      hosts:
110        - extauth.example.test
111---
112apiVersion: networking.istio.io/v1
113kind: VirtualService
114metadata:
115  name: extauth
116  namespace: extauth
117spec:
118  hosts:
119    - extauth.example.test
120  gateways:
121    - extauth-gateway
122  http:
123    - route:
124        - destination:
125            host: extauth-server
126            port:
127              number: 8080

인증 서버를 배포하면 app-a의 /auth 경로로 들어오는 GET 요청은 AuthorizationPolicy 설정에 따라 extauth로 인증을 위임한다.

이제 이러한 동작을 시각화하는 앱을 적용해보자.

  1# visualize.yaml
  2apiVersion: apps/v1
  3kind: Deployment
  4metadata:
  5  name: traffic-viewer
  6  namespace: visualize
  7  labels:
  8    app: traffic-viewer
  9    app.kubernetes.io/name: traffic-viewer
 10    app.kubernetes.io/version: v1
 11spec:
 12  replicas: 1
 13  selector:
 14    matchLabels:
 15      app: traffic-viewer
 16  template:
 17    metadata:
 18      labels:
 19        app: traffic-viewer
 20        app.kubernetes.io/name: traffic-viewer
 21        app.kubernetes.io/version: v1
 22    spec:
 23      serviceAccountName: traffic-viewer
 24      securityContext:
 25        runAsNonRoot: true
 26        runAsUser: 10001
 27        runAsGroup: 10001
 28      containers:
 29        - name: traffic-viewer
 30          image: python:3.13-alpine
 31          imagePullPolicy: IfNotPresent
 32          command:
 33            - python
 34            - /viewer/server.py
 35          env:
 36            - name: PORT
 37              value: "8080"
 38          ports:
 39            - name: http
 40              containerPort: 8080
 41          readinessProbe:
 42            httpGet:
 43              path: /
 44              port: http
 45            initialDelaySeconds: 1
 46            periodSeconds: 3
 47          livenessProbe:
 48            httpGet:
 49              path: /
 50              port: http
 51            initialDelaySeconds: 3
 52            periodSeconds: 10
 53          resources:
 54            requests:
 55              cpu: 10m
 56              memory: 16Mi
 57            limits:
 58              cpu: 100m
 59              memory: 64Mi
 60          securityContext:
 61            allowPrivilegeEscalation: false
 62            readOnlyRootFilesystem: true
 63            capabilities:
 64              drop:
 65                - ALL
 66          volumeMounts:
 67            - name: viewer
 68              mountPath: /viewer
 69              readOnly: true
 70      volumes:
 71        - name: viewer
 72          configMap:
 73            name: traffic-viewer
 74---
 75apiVersion: v1
 76kind: Service
 77metadata:
 78  name: traffic-viewer
 79  namespace: visualize
 80spec:
 81  selector:
 82    app: traffic-viewer
 83  ports:
 84    - name: http
 85      port: 8080
 86      targetPort: http
 87---
 88apiVersion: networking.istio.io/v1
 89kind: Gateway
 90metadata:
 91  name: visualize-gateway
 92  namespace: visualize
 93spec:
 94  selector:
 95    istio: ingressgateway
 96  servers:
 97    - port:
 98        number: 80
 99        name: http
100        protocol: HTTP
101      hosts:
102        - visualize.example.test
103---
104apiVersion: networking.istio.io/v1
105kind: VirtualService
106metadata:
107  name: visualize
108  namespace: visualize
109spec:
110  hosts:
111    - visualize.example.test
112  gateways:
113    - visualize-gateway
114  http:
115    - route:
116        - destination:
117            host: traffic-viewer
118            port:
119              number: 8080

이렇게 배포한 뒤에 http://visualize.example.test:8080/에 접속하면 다음과 같은 화면을 볼 수 있다.

배포된 서비스의 상태를 시각화했다. 앞에서 말한 대로 app-a와 app-b, extauth가 있고, 모두 replica 2로 topologySpreadConstraints를 사용해 a존과 c존에 하나씩 배치했다.

/hello 버튼을 누르면 10개의 요청을 보내고 메트릭을 수집한다. 요청이 같은 존으로 갔는지, 다른 존(a존 -> c존 또는 c존 -> a존)으로 갔는지는 비율로 쉽게 확인할 수 있다. /hello 요청은 app-a를 거쳐 app-b까지 호출한 뒤 응답을 돌려준다. 아직 로컬리티를 활성화하지 않았으므로 크로스 존 트래픽이 발생한다.

이번에는 extauth로 인증을 위임하는 /auth 경로로 똑같이 테스트를 했다. 앞에서도 설명했듯이 /auth 요청은 app-a의 istio-proxy에서 extauth로 요청을 보냈다가 app-a가 app-b를 호출한 뒤에 응답을 돌려주게 된다. 이 경우에도 로컬리티가 활성화되어 있지 않으니 양쪽 존 모두로 트래픽이 가게 된다.

이제 Mesh에 로컬리티를 활성화했다. 화면에도 표시했지만 로컬리티를 활성화하면 아래와 같은 설정이 동적으로 적용된다.

 1# istio-system/istio ConfigMap · data.mesh
 2localityLbSetting:
 3  enabled: true
 4---
 5apiVersion: networking.istio.io/v1
 6kind: DestinationRule
 7metadata:
 8  name: outlier-detection
 9  namespace: istio-system
10  labels:
11    app.kubernetes.io/managed-by: traffic-viewer
12spec:
13  host: "*.cluster.local"
14  trafficPolicy:
15    connectionPool:
16      http:
17        http1MaxPendingRequests: 2000
18        http2MaxRequests: 2000
19        maxRetries: 200
20    outlierDetection:
21      consecutive5xxErrors: 200000
22      interval: 10s
23      baseEjectionTime: 30s
24      maxEjectionPercent: 20

로컬리티를 켜고 다시 테스트해보자.

/hello로 요청을 보내면 아까와 다르게 트래픽이 같은 존으로만 100% 가고 크로스 존 트래픽은 전혀 발생하지 않는다. C존에서만 트래픽이 발생하는 이유는 Istio Ingress Gateway가 C존에 1대만 떠 있기 때문이다.

마찬가지로 /auth 요청에 대한 테스트를 하면 똑같이 로컬리티가 잘 적용되는걸 볼 수 있다.

로컬리티는 당연히 잘 동작하겠지만 envoyExtAuthzGrpc를 써서 Authorization Policy로 위임한 경우에도 로컬리티가 잘 동작함을 확인할 수 있다. 전체 예제 코드는 GitHub에 올려두었다.

왜 `EnvoyExternalAuthorizationGrpcProvider`에서도 로컬리티가 잘 적용되는가?

envoyExtAuthzGrpc를 사용해 설정한 것은 EnvoyExternalAuthorizationGrpcProvider이다. 결과를 보면 간단하지만 처음에는 여기서 동작하지 않을 거라고 생각했다. 메시에 설정된 도메인을 쓰지 못하고 <service-name>.<namespace>.svc.cluster.local 같은 클러스터 도메인으로 설정해야 하고, Istio Sidecar에서 설정할 때도 이 클러스터 도메인을 써야 하기 때문이다. 그래서 Mesh를 안 탄다고 막연히 생각했다.

EnvoyExternalAuthorizationGrpcProvider 문서를 보면 다음과 같이 설명하고 있다.

Envoy ext_authz gRPC 권한 부여 서비스를 구현하는 서비스를 지정합니다. 형식은 [<Namespace>/]<Hostname>입니다. 서비스 레지스트리에서 서비스를 명확하게 식별할 수 없는 경우에만 <Namespace>를 지정해야 합니다. <Hostname>은 Kubernetes Service 또는 ServiceEntry로 정의된 서비스의 정규화된 호스트 이름(FQDN)입니다.

예: my-ext-authz.foo.svc.cluster.local 또는 bar/my-ext-authz.example.com

이 문서에 따르면 Kubernetes Service나 ServiceEntry에 정의된 FQDN이어야 한다. 여기서는 ServiceEntry를 따로 정의하지 않았으니 서비스 FQDN인 클러스터 도메인을 사용한 것이다. 따로 테스트해보진 않았지만 ServiceEntry로 등록하면 원하는 도메인을 사용할 수 있을 거라고 생각한다.

extauth의 EndpointSlice를 보면 각 Pod에 Zone 정보가 들어가 있는 걸 확인할 수 있다.

 1$ kubectl describe endpointslice -n extauth -l kubernetes.io/service-name=extauth-server
 2Name:         extauth-server-n7m8r
 3Namespace:    extauth
 4Labels:       endpointslice.kubernetes.io/managed-by=endpointslice-controller.k8s.io
 5              kubernetes.io/service-name=extauth-server
 6Annotations:  endpoints.kubernetes.io/last-change-trigger-time: 2026-08-02T17:59:09Z
 7AddressType:  IPv4
 8Ports:
 9  Name  Port  Protocol
10  ----  ----  --------
11  http  8000  TCP
12  grpc  9000  TCP
13Endpoints:
14  - Addresses:  10.244.2.6
15    Conditions:
16      Ready:    true
17    Hostname:   <unset>
18    TargetRef:  Pod/extauth-server-6bbc7f7478-2swnp
19    NodeName:   istio-lab-worker4
20    Zone:       zone-c
21  - Addresses:  10.244.5.4
22    Conditions:
23      Ready:    true
24    Hostname:   <unset>
25    TargetRef:  Pod/extauth-server-6bbc7f7478-tbxhq
26    NodeName:   istio-lab-worker2
27    Zone:       zone-a
28Events:         <none>

app-a Pod은 다음과 같이 존별로 하나씩 떠 있다.

1$ kubectl -n app-a get pod -o wide --no-headers | awk 'NR==FNR{zone[$1]=$2; next}{print $1"\t"$7"\t"zone[$7]}' <(kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.metadata.labels.topology\.kubernetes\.io/zone}{"\n"}{end}') -
2app-a-6cd67bdcd7-dkwjf  istio-lab-worker2       zone-a
3app-a-6cd67bdcd7-s95hf  istio-lab-worker3       zone-c

zone-a에 떠있는 app-a-6cd67bdcd7-dkwjf Pod에서는 10.244.5.4에 떠있는 extauth 클러스터의 priority가 0이고 다른 Pod은 1로 되어 있는걸 볼 수 있다.

1$ kubectl exec -n app-a app-a-6cd67bdcd7-dkwjf -c istio-proxy -- pilot-agent request GET clusters | grep -E '8085\|\|extauth-server.*::(zone|priority)::'
22026/08/03 15:22:19 INFO GOMEMLIMIT is already set, skipping package=github.com/KimMachineGun/automemlimit/memlimit GOMEMLIMIT=1073741824
3outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.5.4:9000::zone::zone-a
4outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.5.4:9000::priority::0
5outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.2.6:9000::zone::zone-c
6outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.2.6:9000::priority::1

반대로 zone-c에 떠있는 app-a-6cd67bdcd7-s95hf Pod에서는 10.244.2.6에 떠있는 extauth 클러스터의 priority가 0이고 다른 Pod은 1로 되어 있는걸 볼 수 있다.

1kubectl exec -n app-a app-a-6cd67bdcd7-s95hf -c istio-proxy -- pilot-agent request GET clusters | grep -E '8085\|\|extauth-server.*::(zone|priority)::'
22026/08/03 15:22:44 INFO GOMEMLIMIT is already set, skipping package=github.com/KimMachineGun/automemlimit/memlimit GOMEMLIMIT=1073741824
3outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.2.6:9000::zone::zone-c
4outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.2.6:9000::priority::0
5outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.5.4:9000::zone::zone-a
6outbound|8085||extauth-server.extauth.svc.cluster.local::10.244.5.4:9000::priority::1

priority는 Envoy 문서에 따르면 0이 가장 우선순위가 높고 Istio 로컬리티의 페일오버 문서를 보면 다음과 같이 priority를 사용한다.

0 : region, zone, subzone이 모두 일치
1 : region, zone 일치
2 : region만 일치
3 : 로컬리티 불일치
4 : 페일오버 정책에 정의되지 않은 리전

이 기준에 따르면 0이 나오면 안 되지만, 설정 후 빈칸이 없게 압축하기 때문에 제일 높은 우선순위가 0으로 올라온 것이다.

추가 자료: PreferSameZone

Kubernetes에는 최근에 spec.trafficDistribution 필드를 통해 트래픽 분산 제어 기능을 추가했다. 이 기능은 1.33에서 알파로 들어오고 1.34에서 베타가 되고 1.35에서 GA가 되었다. 그리고 초기에는 PreferClose라는 이름으로 도입되었지만 1.34부터 PreferSameZone으로 이름이 바뀌었다.

KEP-2433에서 시작된 이 Topology Aware Routing 기능은 KEP-4444에서 EndpointSlices의 TopologyAwareHints를 사용해서 kube-proxy 등이 같은 존의 엔드포인트로 트래픽을 보낼 수 있게 하는 기능이다.

 1apiVersion: discovery.k8s.io/v1
 2kind: EndpointSlice
 3metadata:
 4  name: envoyauth-server-5fsst
 5  namespace: envoyauth
 6spec: {}
 7addressType: IPv4
 8endpoints:
 9  - addresses:
10      - 10.210.72.183
11    nodeName: ip-10-210-74-151.ap-northeast-2.compute.internal
12    zone: ap-northeast-2a
13    hints:
14      forZones:
15        - name: ap-northeast-2a
16  - addresses:
17      - 10.210.109.43
18    nodeName: ip-10-210-109-35.ap-northeast-2.compute.internal
19    zone: ap-northeast-2c
20    hints:
21      forZones:
22        - name: ap-northeast-2c

trafficDistribution을 지정하면 위처럼 hints.forZones 같은 힌트가 기록된다. 그러면 kube-proxy가 자신의 노드 zone 레이블과 forZones를 비교해서 모든 엔드포인트에 힌트가 있고 그중 자신의 zone과 일치하는 게 하나 이상 있으면 그 엔드포인트만 라우팅 대상으로 남긴다. 참고로 Istio가 이 힌트를 보진 않는다.

PreferSameZone 구성을 따로 테스트해보진 않았지만, 최신 Kubernetes를 사용한다면 Istio가 없더라도 Zone Aware Routing을 적용하는 데 이 기능을 검토해볼 수 있다.

Istio ServiceEntry로 외부 서비스 등록하기

2026-08-02T17:46:08+09:00

Istio ServiceEntry는 문서에서 다음과 같이 설명한다.

ServiceEntry를 사용하면 Istio 내부 서비스 레지스트리에 항목을 추가해 메시 내에서 자동으로 발견된 서비스가 수동으로 지정한 서비스에 접근하거나 라우팅할 수 있다. ServiceEntry는 서비스의 속성(DNS 이름, VIP, 포트, 프로토콜, 엔드포인트)를 설정한다. 이러한 서비스는 메시 외부에 있을 수도 있고 메시 내부 서비스일 수도 있다.

outboundTrafficPolicy

이 글은 Istio의 Sidecar 모드를 전제로 설명한다.

이전 Sidecar 글에서 봤듯이, Istio 서비스 메시를 사용하면 Pod의 요청은 함께 구성된 istio-proxy를 통해 나간다. 메시 내 서비스는 자동으로 등록되지만, 외부 서비스로 요청을 보내면 메시가 목적지를 알지 못한다.

이런 경우 외부 API를 Istio 내부 서비스 레지스트리에 수동으로 등록해 메시 서비스처럼 관리하려면 ServiceEntry를 사용한다.

ServiceEntry가 없으면 전역 설정인 meshConfig의 outboundTrafficPolicy를 따르게 된다.

1meshConfig:
2  outboundTrafficPolicy:
3    mode: REGISTRY_ONLY

outboundTrafficPolicy는 애플리케이션이 알 수 없는 아웃바운드 트래픽을 어떻게 다룰지 정하는 설정이다. 모드는 다음 세 가지 중 하나를 선택할 수 있다.

REGISTRY_ONLY : 알지 못하는 아웃바운드 트래픽을 드랍한다. 트래픽의 목적지는 명시적으로 ServiceEntry를 통해 서비스 레지스트리에 선언해야 한다.
ALLOW_ANY : 알지 못하는 목적지로의 트래픽을 허용한다. PassthroughCluster를 통해 원래 목적지 IP로 전달한다.
ALLOW_ANY_DYNAMIC_DNS : 알 수 없는 목적지로의 트래픽을 동적 DNS 해결로 허용한다.

이 outboundTrafficPolicy는 Sidecar에서 설정할 수 있다.

ServiceEntry

알 수 없는 목적지는 ServiceEntry로 허용 여부만 선택할 수도 있다. 하지만 Istio가 이를 인식하면 타임아웃, 재시도 규칙, 서킷 브레이커 같은 트래픽 정책을 적용할 수 있다. 또한 실제 서비스 이름으로 식별하므로 로그와 메트릭의 관측성도 높아진다.

다음은 간단한 ServiceEntry 예시이다.

 1apiVersion: networking.istio.io/v1
 2kind: ServiceEntry
 3metadata:
 4  name: external-svc-https
 5spec:
 6  hosts:
 7  - api.dropboxapi.com
 8  - www.googleapis.com
 9  - api.facebook.com
10  ports:
11  - number: 443
12    name: https
13    protocol: TLS
14  location: MESH_EXTERNAL
15  resolution: DNS

주요 필드를 살펴보자.

hosts : Istio에 등록할 호스트명이다.
- 와일드카드 접두사를 쓴 DNS 이름도 가능하다.
- VirtualService와 DestinationRule에서 일치하는 호스트를 찾을 때 사용한다.
- HTTP에서는 Host/Authority 헤더와 매칭한다.
- HTTPS/TLS에서는 SNI 값과 매칭한다.
ports : 서비스가 제공하는 포트와 프로토콜이다.
- name : (필수) 포트에 할당된 레이블
- number : (필수) 정수 형식의 포트 번호
- protocol : HTTP|HTTPS|HTTP2|GRPC|MONGO|TCP|TLS 중 하나의 값이다.
- targetPort : 트래픽을 수신할 포트 번호
location : 서비스가 메시 외부(MESH_EXTERNAL)인지 메시 내부(MESH_INTERNAL)인지를 정한다.
resolution : istio-proxy가 최종 엔드포인트 주소를 결정하는 방법을 지정하며, 아래 값 중 하나를 사용한다.
- DNS : Envoy가 DNS를 조회해 엔드포인트를 결정하며, 외부 API에는 보통 가장 안전한 선택이다.
- DNS_ROUND_ROBIN : DNS 결과 중 첫 주소를 사용한다.
  - 이름을 보면 여러 주소를 돌려서 사용할 것 같지만, 실제로는 새 연결이 계속 첫 주소를 사용하는 방식이다. DNS 변경이 잦아 기존 엔드포인트를 제거하고 커넥션 풀을 드레인한 뒤 새로 연결해야 할 때, 커넥션 풀이 너무 자주 생성되는 문제를 막기 위해 사용한다.
- STATIC : endpoints 필드에 선언한 정적 IP 주소를 사용한다.
- NONE : 들어오는 요청이 이미 IP로 해석되었다고 가정하고 아무것도 하지 않는다.
endpoints : 서비스에 연결된 IP 주소
workloadSelector : MESH_INTERNAL에서만 사용할 수 있으며, endpoints와 둘 중 하나만 사용할 수 있다.
addresses : 서비스에 연결된 가상 IP 주소
exportTo : 해당 ServiceEntry를 어느 네임스페이스에 노출할지를 정한다. 생략하면 모든 네임스페이스에 노출한다.
- "." : ServiceEntry가 생성된 네임스페이스에만 노출
- "*" : 모든 네임스페이스에 노출

구성이 간단하므로 몇 가지 예시를 보면 어떤 상황에 쓰는지 이해할 수 있다.

추가 예시

다음은 MongoDB를 ServiceEntry에 등록한 예시이다.

 1apiVersion: networking.istio.io/v1
 2kind: ServiceEntry
 3metadata:
 4  name: external-svc-mongocluster
 5spec:
 6  hosts:
 7  - mymongodb.somedomain # not used
 8  addresses:
 9  - 192.192.192.192/24 # VIPs
10  ports:
11  - number: 27018
12    name: mongodb
13    protocol: MONGO
14  location: MESH_INTERNAL
15  resolution: STATIC
16  endpoints:
17  - address: 2.2.2.2
18  - address: 3.3.3.3
19  
20----------
21  
22apiVersion: networking.istio.io/v1
23kind: DestinationRule
24metadata:
25  name: mtls-mongocluster
26spec:
27  host: mymongodb.somedomain
28  trafficPolicy:
29    tls:
30      mode: MUTUAL
31      clientCertificate: /etc/certs/myclientcert.pem
32      privateKey: /etc/certs/client_private_key.pem
33      caCertificates: /etc/certs/rootcacerts.pem

다음은 ServiceEntry와 VirtualService의 TLS 라우팅을 이용해서 SNI 값으로 방화벽에 연결하는 예시다.

 1apiVersion: networking.istio.io/v1
 2kind: ServiceEntry
 3metadata:
 4  name: external-svc-redirect
 5spec:
 6  hosts:
 7  - wikipedia.org
 8  - "*.wikipedia.org"
 9  location: MESH_EXTERNAL
10  ports:
11  - number: 443
12    name: https
13    protocol: TLS
14  resolution: NONE
15
16-------
17
18apiVersion: networking.istio.io/v1
19kind: VirtualService
20metadata:
21  name: tls-routing
22spec:
23  hosts:
24  - wikipedia.org
25  - "*.wikipedia.org"
26  tls:
27  - match:
28    - sniHosts:
29      - wikipedia.org
30      - "*.wikipedia.org"
31    route:
32    - destination:
33        host: internal-egress-firewall.ns1.svc.cluster.local

기술 뉴스 #299 : 2026-08-01

2026-08-01T20:45:17+09:00

웹개발 관련

CodeMirror 분석: 상태(State) 편 : 웹 코드 에디터 라이브러리인 CodeMirror의 코드 구조를 분석한 글이다. CodeMirror는 상태를 관리하는 state, DOM 표현을 관리하는 view, 키 입력을 담당하는 commands가 핵심 기둥이다. CodeMirror가 어떤 방법으로 대용량 텍스트를 다룰 수 있고 정확한 한 글자를 계산하고 트랜잭션을 통해서 상태를 어떻게 관리하는지를 설명한다.(한국어)

그 밖의 개발 관련

Own the Outer Loop : Addy Osmani가 AI Engineer World’s Fair 2026의 클로징 키노트에서 발표한 내용을 정리한 글이다. AI 에이전트 시대에 엔지니어는 코드 작성이 아니라 최종 책임자가 되어야 한다고 이야기 한다. AI는 Inner Loop를 수행하고, 사람은 책임(Outer Loop)을 맡는다. 사람은 어떤 문제를 풀지, 결과를 신뢰할지, 문제가 생겼을 때 누가 책임질지 정해야 한다. 여기서 핵심은 결과를 검증하는 품질(Quality), 그 결과를 바탕으로 결정하는 판결(Verdict), 이유를 설명할 수 있는 답변 가능성(Answerability)이다. AI로 인해 생성은 싸졌지만 검증이 비싸졌고 AI에서의 숨음 비용으로는 AI가 맞다고 믿어버리는 인지 항복(Cognitive Surrender), 이해도가 떨어지는 인지 부채(Cognitive Dept), AI를 많이 돌리면서 인간의 일이 많아지는 오케스트레이션 세금(Orchestration Tax)가 있다. 결국 모두가 개발자이지만 모두가 엔지니어는 아니라고 얘기한다.(영어)
The new rules of context engineering for Claude 5 generation models : Anthropic은 Claude 5 패밀리에서 시스템 프롬프트의 80%를 제거해도 성능 저하가 나타나지 않는다는 점을 발견하고, 컨텍스트 엔지니어링을 개선하는 방법을 설명한다. 이전에는 최악의 시나리오를 방지하기 위해 Claude.md나 스킬에서 많은 제약조건을 주었지만 모델의 판단이 더 좋아짐에 따라 그럴 필요가 없어졌다. Claude.md 파일을 간결하게 유지하고 제약을 너무 주지 말라고 안내한다. claude doctor와 /doctor 명령어에는 이 모범 사례가 추가되었다.(영어)
Everyone Should Know SIMD : Mitchell Hashimoto가 SIMD(Single instruction, multiple data)를 사람들이 어려워하지만 사실 이해하기 쉽고 개발자라면 어느정도 SIMD를 알아야 한다며 기본적인 SIMD의 활용 예시를 설명한다.(영어)
Go 1.27 interactive tour : 곧 나올 Go 1.27의 새로운 기능을 직접 실행해보면서 이해하기 쉽게 설명한다.(영어)
1Password for Claude: Give Claude access without giving up your credentials : AI 자동화에서 어려운 부분 중 하나는 인증 정보나 시크릿 정보를 다루는 일인데, 1Password에서 1Password for Claude를 출시했다. 1Password for Claude는 제로 노출 아키텍처를 기반으로 동작한다. Claude가 로그인을 시도하면 1Password는 요청된 인증 정보를 알려준다. 사용자가 생체 인증에 동의하면 1Password가 인증 정보를 페이지에 입력하며, Claude는 비밀 정보를 볼 수 없다.(영어)
Bringing MCP 2026-07-28 to Claude : MCP의 다섯 번째 사양 릴리스인 MCP 2026-07-28이 공개되었다. Stateless로 서버리스나 엣지 인프라에 배포할 수 있게 되었고 확장 기능이 표준화되고 OAuth 2.0과 OIDC에 맞는 인증 기능이 강화되었다.(영어)
Grok Build is Now Open Source : SpaceXAI가 코딩 에이전트인 Grok Build를 오픈소스로 공개했다.(영어)
Stacked pull requests are now in public preview : 큰 변경 사항을 작은 Pull Request로 나누고, 다음 Pull Request가 이전 Pull Request의 브랜치 위에 쌓이는 형태를 Stacked Pull Request라고 한다. GitHub가 Stacked PR 지원을 공개 프리뷰로 제공하기 시작했다.(영어)
ACP v2 is available in Draft : 에디터와 코딩 에이전트간의 통신을 위해 Zed에서 만든 ACP의 v2가 드래프트로 공개되었다. 발전된 에이전트에 맞게 에이전트 동작 중에도 이벤트를 업데이트하고 입력을 받을수 있게 개선되었고 메시지와 도구 호출이 개선되었다.(영어)
Cursor Router를 소개합니다 : Cursor에서 요청을 가장 적합한 모델로 라우팅해주는 Cursor Router를 출시했다. Cursor 측에 따르면 온라인 테스트에서 Cursor Router는 프런티어급 품질을 유지하면서 비용을 60% 절감한 것으로 나타났다. 현재 팀, 엔터프라이즈 요금제에서만 사용할 수 있다.(영어)

AI 관련

Introducing Claude Opus 5 : Anthropic이 Opus 5를 출시했다. Opus 5는 사이버 보안 점수는 Mythos보다 낮지만 코딩 및 지식 업무 평가에서 최고의 점수를 기록했고 Opus 4.8과 같은 비용에서 성능이 크게 향상되었다.(영어)
Kimi K3: Open Frontier Intelligence : Moonshot에서 새로운 오픈 프론티어 모델인 Kimi K3를 발표했다. Kimi K3는 2.8T 파라미터 모델로 1M 토큰 규모의 컨텍스트 윈도우를 지원해서 장기적인 코딩, 추론 등 최첨단 지능 분야를 위해 설계된 최초의 오픈소스 3T급 모델이다. 벤치마크에 따르면 Claude Fable 5와 GPT-5.6 Sol에는 못 미치지만 다른 모델들 보다는 훨씬 우수한 점수를 보여주었다.(영어)
How GPT‑5.6 fuses frontier intelligence with frontier efficiency : OpenAI가 GPT-5.6 Sol을 활용해 추론 영역과 에이전트 기반 하네스를 최적화한 과정을 설명한다. 부하 분산을 위해 프로덕션 트래픽의 불균형을 파악해 개선하고, 모델의 포워드 패스 연산을 최적화해 서비스 비용을 20% 줄였다. Sol로 추측적 디코딩의 대규모 실험을 진행하면서 개선해서 토큰 생성 효율이 15% 개선하고 추론 최적화를 지속적인 피드백 루프로 만들었다. 사용자가 에이전트를 사용할 때 작업을 진행하면서 컨텍스트가 너무 커지지 않게 조절하고 프롬프트 캐싱 적중률을 높여서 모델과 사용자 환경을 연결하는 에이전틱 하네스 계층을 개선했다.(영어)
Advancing the price-performance frontier with GPT‑5.6 : OpenAI가 GPT-5.6의 성능 개선을 통해 GPT-5.6 Luna는 80%, GPT-5.6 Terra는 20% 요금을 낮췄다.(영어)
Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber : Google에서 Gemini Flash 시리즈의 새로운 모델을 추가했다. 주력 모델로서 3.5 Flash보다 토큰 사용량이 17% 줄고 출력 토큰당 비용이 낮아진 3.6 Flash, 3.5 Flash 계열에서 가장 빠르고 비용 효율이 뛰어난 3.5 Flash-Lite, 그리고 CodeMender 코드 보안 에이전트를 결합한 사이버 보안 특화 모델 3.5 Flash Cyber를 출시했다.(영어)
Qwen-Image-3.0: Rich Content, Authentic Details, Deep Knowledge : Alibaba에서 이미지 생성 모델인 Qwen-Image-3.0을 출시했다.(영어)
FLUX 3: Multimodal Video, Image & Audio : Black Forest Labs에서 새로운 모델 FLUX 3를 얼리 엑세스로 발표했다. FLUX 3는 이미지, 동영상, 오디오를 함께 학습한 멀티모달 파운데이션 모델로, 비디오와 이미지를 생성할 수 있다.(영어)
Introducing Grok 4.5 : SpaceXAI에서 최신 모델인 Grok 4.5를 출시했다. 역대 가장 강력한 성능을 보여주며 CUrsor과 함께 훈련했다.(영어)

인프라 관련

Introducing Precursor: detecting agentic behavior with continuous client-side signals : Cloudflare가 봇 탐지에서 가시성 격차를 해소하기 위해 애플리케이션에 동적으로 삽입한 JavaScript로 사용자의 행동을 수집하는 클라이언트 측 세션 검증 시스템 Precursor를 공개했다. CAPTCHA없이 방문자를 검증하는 Turnstile을 보완하는 선택적 기능이다. Bot이 자동 검증을 뚫을 수 있는 방법이 더욱 고도화됨에 따라 Precursor가 추가 신호를 더 많이 제공하고 이를 통해 실제 사용자를 더 쉽게 구분할 수 있다.(영어)
Announcing v1 of OpenTelemetry Go Compile-Time Instrumentation : Java, Python, Node.js, .Net은 코드 수정없이도 OpenTelemetry를 추가할 수 있었지만 정적 바이너리로 컴파일되는 Go는 수동으로 계측하거나 외부 eBPF 에이전트를 사용해야만 했다. 이 문제를 해결하기 위한 OpenTelemetry Go 컴파일타임 계측의 첫 안정 버전인 v1이 나왔다. otelc는 Go 툴체인을 감싸며, otelc로 빌드하면 소스 코드 수정 없이 계측할 수 있다.(영어)
Reference same-repository actions with self-repository syntax : GitHub Actions에서 같은 레포지토리내의 액션이나 워크플로우를 사용하는 경우 uses:에서 ./ 대신 $/로 시작하는 문법을 추가해서 별도의 체크아웃을 하지 않고도 현재 실행중인 커밋의 레포지토리를 참조할 수 있게 되었다.(영어)

보안 및 장애

OpenAI와 Hugging Face, 모델 평가 중 발생한 보안 사고에 공동 대응 : Hugging Face에서 OpenAI 모델을 테스트하던 도중 보안 사고가 발생했다. 해당 모델은 출시되지 않은 모델로, 사이버 역량을 평가하기 위해 고도화된 악용을 수행하도록 시험했다. 최대 수준의 역량을 확인하기 위한 평가였기에 고위험 사이버 관련 요청을 거부하는 지침은 적용하지 않았다. 모델은 OpenAI의 연구 환경과 Hugging Face의 운영 인프라의 취약점을 연계해 Hugging Face의 테스트 정답을 직접 확보했다. 해당 환경은 인터넷이 안되는 환경이었지만 모델이 제로데이 취약점을 악용해서 권한 상승과 측면 이동을 통해 인터넷에 접근할 수 있는 노드에 도달해서 보안 사고가 발생했다.(영어)
OpenAI Agent Used Exposed Credentials Across Four Services During Hugging Face Breach : OpenAI가 Hugging Face에서 사이버 보안 역량 테스트 도중 발생한 보안 사고를 더 자세히 분석한 글이다. 분석 결과 해당 모델은 벤치마킹 프레임워크인 ExploitGym을 속이기 위해 이틀 반동안 활동했고 과제를 스스로 해결하는 대신 시스템에 침입해서 테스트 정답을 훔치려고 한 것이라고 밝혔다. 해당 모델은 JFrog가 관리하는 패키지 레지스트리인 Artifactory에서 익명 엑세스 기능을 이용한 제로데이 취약점으로 샌드박스를 탈출한 뒤 인터넷 접속이 허용된 네트워크 출구를 통해 공개 평가용 외부 샌드박스를 악용해서 루트권한으로 명령을 실행하여 Kubernetes의 관리자 권한을 획득하여 노드 사칭, CSI 토큰 탈취, 위조된 신원 토큰의 조합으로 C2 채널을 구축한 후 GitHub에 쓰기 권한을 획득했다.(영어)

볼만한 링크

Being Linux Torvalds : Linus Torvalds가 Linux를 처음 만든 것은 대단한 일이지만, 이를 할 수 있었던 다른 사람도 꽤 있었다. 그러나 지금의 Linus Torvalds는 단 한 명뿐이다. Linus Torvals는 유명한 오픈소스 프로젝트의 유지보수자 중 코드 작성을 거의 중단한 극소수 중 한명인데 아이다어와 방향성을 주도하고 프로젝트를 이끌었는데 이부분이 Linus Torvals의 천쟁성이다. 이제 AI와 함께 프로그래밍할 때 우리고 Linus Torvals와 같은 입장이 되었고 그런 역할을 해야 한다.(영어)
The State of AI Impact in Engineering: Q2 2026 : DX에서 조사한 엔지니어링에서 AI의 영향도를 조사한 보고서다. 2분기에는 AI로 생성된 코드가 52%로 1분기 34%보다 증가했지만 PR이 커지고 검토가 어려워져서 품질이 저하되고 있을수 있으며 리뷰나 매포 등 새로운 마찰이 생기면서 개발자 경험도 저하되고 있다. 코드는 더 이해하기 쉬워졌지만 신뢰도는 떨어지고 있고 AI로 절약된 시간이 혁신으로 이어지지는 않고 있으며 AI 비용의 증가속도가 성과 창출 속도를 앞지르고 있는 걸로 나타났다.(영어)
Open-weight AI is having its Kubernetes moment. Let's not ruin it. : 2013년 Apache Mesos를 기반으로 Mesosphere를 공동 창업하고 DC/OS를 만들었던 Tobi Knaup이 당시 Kubernetes가 등장하면서 대부분의 엔지니어가 Kubernetes에 참여하면서 혁신의 중심이 Kubernetes로 옮겨갔다. 이렇게 Kubernetes가 성공한 이유는 고객의 요구에 맞춰 확장할 수 있는 중립적인 기반이 되었기 때문인데 이를 통해 개방형 플랫폼이 업계의 중심이 되면 단일 공급업체는 이 혁심을 따라 잡을수 없다는 걸 깨달았다고 한다. 오픈웨이트 모델을 중심으로 생태계가 만들어지고 있고 Kubernetes에서 벌어졌던 비슷한 일이 일어날 수 있으면 미국이 중국산 모델에 대한 규제조치는 오히려 미국을 고립시키는 결과가 될 것이라고 얘기한다.(영어)
The Kimi K3 Moment : 평소 코딩하면서 Claude와 Kimi K3를 같이 사용해 왔는데 둘을 구분할수 없을 정도이고 가격은 Kimi가 훨씬 싸다고 칭친한다. 미국의 AI 규제 정책이 얼마나 실패인지를 보여준다고 얘기한다.(영어)
Our position on open-weights models : 중국산 모델을 중심으로 한 오픈 웨이트 모델에 대해 Anthropic이 입장을 밝혔다. 한번도 금지 조치를 지지한 적이 없고 오픈 웨이트 모델는 공공재와 다름 없으며 이러한 강력한 AI 모델을 사용해서 정부가 자국민을 탄압하는 용도로 사용하거나 사이버 공격이나 생물학적 공격에 악용하는 것을 우려한다. 그래서 Anthropic은 중국에 고성능 칩이나 칩 제조 장비를 판매하지 말고 산업 규모의 증류 작업은 단속해야 하고 개방형이든 폐쇄형이든 강력한 모델은 안정성 테스트를 의무적으로 거쳐야 한다.(영어)
개발 자동화에서 조직 AX까지 : Purple IO의 AX 여정을 정리한 글이다. AI로 어디까지 가능한지 궁금해서 이슈를 기반으로 개발 자동화를 테스트하고 손 못대던 레거시 시스템을 AI로 다시 구현하고 신규 서비스도 요구사항을 잘 정리하면 된다는 것을 깨닫고 AX를 더 본격적으로 하기로 한다. 사내 AI 챌린지를 진행하고 회사의 문서를 옵시디언 기반으로 변경해서 전사 직원들이 AI를 적극적으로 사용하게 했다. 여전히 배포는 어려웠기에 사내 AI 플랫폼과 연동해서 Kubernetes 환경에 배포하게 하면서 보안 검사를 강제하고 접근 제어를 위해 Cloudflare Access를 사용해서 내부 직원만 쉽게 접근하는 서비스를 배포할 수 있게 만들었다.(한국어)
I Regret Migrating to Codeberg : GitHub이 마이크로소프트의 소유 하에 엉망이 되어가는 걸 보면서 비영리 협회가 운영하는 Codeberg로 코드 저장소를 옮겼다. 하지만 최근 Codeberg가 이용 약관을 업데이트하면서 LLM으로 생성한 프로젝트를 금지하면서 커뮤니티를 강조하는데 이러한 Codeberg의 조치가 자유 소프트웨어로 구축된 플랫폼이 좋은 소프트웨어가 뭔지를 지시하는 검열에 가깝다고 아쉬움을 얘기한다.(영어)
Codeberg Divides : 유럽의 코드 호스팅 서비스인 Codeberg가 최근 생성형 AI로 대부분 작성된 프로젝트는 금지하면서 Armin Ronacher가 의견을 남겼다. Codeberg는 회원들고 구성된 협회에서 민주적으로 의사결정을 하지만 플랫폼에서 민주주의가 중요하진 않고 대부분 AI로 만들어졌다는 표현도 모호하기 때문에 원한다면 차라리 엄격한 규칙을 만들었어야 한다.(영어)
The Java Story | The Official Documentary : Sun Microsystems에서 코드네임 Oak로 시작된 Java의 공식 다큐멘터리가 나왔다.(영어)

IT 업계 뉴스

Superlogical : HashiCorp의 창업자이자 Ghostty 터미널을 만든 Mitchell Hashimoto가 새로운 회사 Superlogical을 시작했다. Superlogical은 AI 시대에 작업을 둘러싼 지속 가능한 세션이 누락된 계층이라는 생각하에 터미널 멀티플렉서를 구축하는 것이 목표이다.(영어)
Introducing Buzz: where humans and agents work together : Twitter와 Square의 창업자인 Jack Dorsey의 회사 Block에서 오픈소스 팀 채팅 앱인 Buzz를 출시했다. Buzz는 사람과 AI 에이전트가 같은 워크스페이스에서 작업할 수 있는 협업 플랫폼으로 탈중앙화 통신 개방형 프로토콜인 Nostr을 사용해서 사람과 에이전트의 신원을 확인하고 Claude Code, Codex나 다른 LLM을 이용해서 에이전트를 배포할 수 있다.(영어)

프로젝트

openai/codex-security : OpenAI에서 코드에서 보안 취약점을 찾아서 고칠 수 있는 CLI와 TypeScript SDK를 공개했다.
transcribe.cpp : ggml 런타임 기반 STT 라이브러리
98.css : Windows 98같은 UI를 만드는 CSS 라이브러리

버전 업데이트

Nuxt v4.5.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
Zed v1.13.1 : 코드 에디터, 릴리스 공지
astro v7.1 : JavaScript 웹 프레임워크, 릴리스 공지
Vite v8.2.0 : 프론트엔드 빌드 도구, 릴리스 공지
TinyBase v9.3.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
FastAPI v0.141 : Python 웹 프레임워크, 릴리스 공지
Visual Studio Code v1.131.0 : 에디터, 릴리스 공지
Blender v5.2.0 LTS : 2D/3D 컨텐츠 제작 도구, 릴리스 공지
Lima v2.2.0 : Linux 가상 머신, 릴리스 공지

Istio Sidecar로 서비스 구성 범위 좁히기

2026-07-31T02:53:19+09:00

최근 Istio 스터디를 팀 동료들과 하고 있다. 업무에서 Istio를 어느 정도 알고는 있지만, 깊이 있는 내용은 알지 못한다. 업무 이해도를 높이려고 스터디를 하는데, 정해진 책의 진도를 나가는 방식이 아닌 자유 주제라 매번 주제를 정하기 어렵다. 그래서 최근에 이해도가 부족하다고 생각한 주제를 공부했다.

Istio Sidecar

Istio에는 Sidecar라는 리소스가 존재한다. 개인적으로 이 이름은 잘못 지은 용어라고 생각하고 있다. Kubernetes 환경에서 Sidecar라는 용어를 쓰면

Kubernetes에서 Pod에 앱 컨테이너 외에 추가 운영 기능을 위해 컨테이너를 추가하는 방법을 Sidecar 패턴이라고 부른다.
위 패턴에 따라 Sidecar 패턴을 따르는 방식을 Istio에서는 Sidecar 모드라고 부르고 Sidecar가 없는 새로운 접근 방식을 Ambient Mode라고 부른다.
Sidecar 모드에서 Envoy proxy를 포함하고 있는 istio-proxy를 주입하는 걸 당연히 istio에서도 Sidecar Injection이라고 부른다. 그래서 의미상 istio-proxy를 Sidecar Proxy라고도 부를 수 있다.

여기서 얘기할 Sidecar는 Istio의 CRD인 Sidecar를 의미한다. 물론 이 Sidecar 리소스는 위에서 말한 istio-proxy와 관련 있어 이름이 틀린 것은 아니다. 다만 Sidecar의 의미가 너무 광범위해 실제로는 매우 헷갈리는 이름이라고 생각한다.

이 글에서는 이후 Sidecar는 Istio의 CRD를 의미하고, Sidecar Proxy는 istio-proxy로 지칭한다.

공식 문서는 다음과 같이 정의한다.

Sidecar는 연결된 워크로드 인스턴스의 인바운드 및 아웃바운드 통신을 중개하는 Sidecar Proxy의 구성을 설정한다. 기본적으로 Istio는 메쉬 내의 모든 Sidecar Proxy에, 메쉬 내의 모든 워크로드 인스턴스에 연결하는 데 필요한 구성과 워크로드와 관련된 모든 포트에서 트래픽을 수락하도록 설정합니다. Sidecar 구성을 사용하면 프록시가 워크로드로 향하거나 워크로드에서 오는 트래픽을 전달할 때 허용할 포트 및 프로토콜 집합을 세부적으로 조정할 수 있습니다.

xDS

Istio Sidecar 모드는 Envoy proxy를 기반으로 한다. Envoy proxy는 동적 구성 관리를 위한 API를 제공하며, 이러한 디스커버리 서비스 API를 xDS라고 부른다. xDS는 그 자체만으로 주제를 따로 잡아도 긴 글이 나올 정도로 큰 주제이므로 여기서는 간단히만 살펴본다.

Istiod가 이러한 정보를 수집해서 xDS로 각 istio-proxy에 전파한다. 그리고 Envoy는 Listener -> Route -> Cluster -> Endpoint 순으로 요청을 처리한다.

LDS - Listener Discovery Service

Envoy가 어떤 IP와 포트에서 트래픽을 받을지, 어떤 필터 체인을 적용할지 정의하며 다음과 같은 정보가 포함된다.

10.0.0.0:15001 virtualOutbound
20.0.0.0:15006 virtualInbound
310.96.20.30:8080 특정 서비스용 outbound listener

RDS - Route Discovery Service

HTTP Host, path, Header 등의 정보에 따라 어떤 클러스터로 보낼지를 정의한다.

1Host: catalog.catalog.svc.cluster.local
2Path: /v1/items 
3    -> outbound|8080|v1|catalog.catalog.svc.cluster.local

CDS - Cluster Discovery Service

Envoy에서 클러스터는 요청이 도달하는 업스트림 목적지를 정의한다.

1outbound|8080||catalog.catalog.svc.cluster.local outbound|8080|v1|catalog.catalog.svc.cluster.local
2PassthroughCluster
3BlackHoleCluster

EDS - Endpoint Discovery Service

각 클러스터의 실제 목적지 IP와 포트를 정의한다.

110.244.2.17:8080
210.244.3.21:8080

Configuration Scoping

Istio는 서비스 메시이므로 많게는 수백~수천 개의 마이크로서비스가 서로 통신한다. Istiod는 서비스 연결 방식과 적용 정책을 각 istio-proxy에 전파하고, 구성이 바뀌면 계속 업데이트한다.

Kubernetes에서 Istio를 사용하면 기본적으로 모든 네임스페이스의 정보를 모든 네임스페이스에 전달한다. 하지만 마이크로서비스 환경에서는 모든 서비스와 통신하는 서비스가 거의 없고, 대부분은 정해진 소수의 서비스와만 통신한다. 따라서 모든 구성을 알 필요 없이 실제로 통신할 네임스페이스 정보만 있으면 충분하다. 모든 정보를 전파하면 트래픽도 만만치 않고 시간이 오래 걸린다. 이 정보를 모두 유지하는 데도 비용이 든다.

그래서 원하는 구성만 선택해서 정보를 받아오는 것을 Configuration Scoping이라고 한다.

Istio에서 Configuration Scoping을 하는 방법은 세 가지가 있다.

Sidecar 리소스를 사용해서 특정 워크로드가 Configuration 집합을 가져오도록 설정할 수 있다. 이는 워크로드 쪽에서 설정해서 자신이 받아올 Configuration을 설정하는 방법이다.
exportTo 설정을 통해서 특정 워크로드로 Configuration을 내보내도록 설정할 수 있다. 이는 워크로드를 소유한 입장에서 자신의 Configuration을 어디로 보낼지 설정하는 방법으로 VirtualService, DestinationRule, ServiceEntry에서 exportTo를 사용할 수 있고 Service에서는 networking.istio.io/exportTo 어노테이션으로 설정할 수 있다.
Istio의 전역 설정인 meshConfig에서 discoverySelectors를 사용하면 원하는 네임스페이스에만 Configuration이 자동으로 전파되도록 할 수 있다. discoverySelectors가 없으면 모든 네임스페이스에 전파한다. 다음은 discoverySelectors의 예시다.

1meshConfig: 
2  discoverySelectors: 
3    - matchLabels: 
4        # Allow any namespaces with `istio-discovery=enabled` 
5        istio-discovery: enabled
6    - matchLabels: 
7        # Allow "kube-system"; Kubernetes automatically adds this label to each namespace
8        kubernetes.io/metadata.name: kube-system

이 세 가지는 discoverySelectors -> exportTo -> Sidecar 순으로 적용되며, 모두 AND 조건으로 적용된다.

예시

다음과 같이 4개의 네임스페이스에 각각 서비스가 있는 상황을 생각해 보자.

 1frontend namespace 
 2    frontend service 
 3
 4catalog namespace 
 5    catalog service 
 6
 7payments namespace
 8    payments service 
 9
10observability namespace
11    tracing service

이때 frontend 서비스에는 다음과 같은 클러스터가 4개 생성된다.

1outbound|8080||frontend.frontend.svc.cluster.local
2outbound|8080||catalog.catalog.svc.cluster.local
3outbound|8080||payments.payments.svc.cluster.local
4outbound|4317||tracing.observability.svc.cluster.local

이때 frontend 네임스페이스의 frontend 서비스가 http://catalog.catalog.svc.cluster.local:8080/items 로 요청을 보낸다면 다음과 같이 처리된다.

애플리케이션이 catalog.catalog.svc.cluster.local의 DNS를 조회하고 Kubernetes의 ClusterIP인 10.96.20.30를 받는다.
애플리케이션이 10.96.20.30:8080으로 연결을 시도한다.
Pod의 iptables 규칙이 outbound TCP 연결을 가로채서 Envoy virtualOutbound 15001 포트로 리다이렉션한다.
Envoy virtualOutbound listener가 원래 목적지 주소를 확인한다.
HTTP protocol임을 확인하고 RDS의 virtual host와 route를 조회한다.
route가 outbound|8080||catalog.catalog.svc.cluster.local 클러스터를 선택한다.
EDS에서 실제 catalog Pod의 endpoint인 10.244.2.17:8080를 선택한다.
DestinationRule의 로드밸런싱, TLS, retry 관련 설정 적용한다.
catalog Pod에 연결된다.

여기서 핵심은 DNS가 서비스 IP를 알려 주지만, Envoy는 Istiod에서 받은 listener, route, cluster, endpoint 구성으로 통신한다는 점이다.

그러면 frontend 네임스페이스에 Sidecar를 설정해 보자.

 1apiVersion: networking.istio.io/v1
 2kind: Sidecar 
 3metadata: 
 4  name: default
 5  namespace: frontend
 6spec: 
 7  egress: 
 8    - hosts: 
 9      - "./*"
10      - "catalog/*"

이렇게 구성하면 아까와 달리 아래 2개의 클러스터만 설정된다.

1outbound|8080||frontend.frontend.svc.cluster.local
2outbound|8080||catalog.catalog.svc.cluster.local

Sidecar는 꼭 1개만 있는 것은 아니므로 다음과 같은 순서로 적용된다.

같은 namespace에서 workloadSelector가 일치하는 Sidecar
같은 namespace에서 selector가 없는 기본 Sidecar
root namespace에서 selector가 없는 기본 Sidecar
아무것도 없다면 mesh의 기본값

앞에서 설정한 spec.egress.hosts는 <configuration-namespace>/<service-host> 형식으로 정의한다. 다음 예시는 다음과 같다.

./*: 현재 namespace의 모든 서비스와 관련 구성
catalog/* : catalog namespace의 모든 서비스 및 관련 구성
external-services/api.vendor.example : external-service namespace의 api.vendor.example 호스트의 서비스 및 관련 구성
*/*: 현재 워크로드에서 볼 수 있도록 export된 전체 mesh 구성
~/* : outbound 서비스 구성을 모두 제거

Sidecar의 핵심 필드

필드	역할	일반적인 사용 목적
`workloadSelector`	같은 namespace의 Pod/VM을 label로 선택	특정 애플리케이션만 별도 구성
`ingress`	Envoy의 inbound listener 정의	포트 변경, UDS 전달, 명시적 TLS 종료
`egress`	Outbound listener와 import할 서비스 구성 정의	proxy configuration 축소
`inboundConnectionPool`	서버 측 inbound connection pool 기본값	서버 과부하와 동시성 제어
`outboundTrafficPolicy`	알려지지 않은 outbound 목적지 처리	`ALLOW_ANY` 또는 `REGISTRY_ONLY`

참고로 egress에 설정하지 않았다고 바로 패킷을 차단하는 것은 아니고 outboundTrafficPolicy의 설정을 따르게 된다. 기본값인 ALLOW_ANY는 알려지지 않은(구성에 없어서 모르는) 목적지에 대한 요청도 그냥 통과시키고 REGISTRY_ONLY로 설정하면 알지 못하는 목적지에 대한 요청은 드랍한다.

주의할 점은 이 REGISTRY_ONLY를 보안 정책이나 아웃바운드 방화벽으로 사용하면 안된다. 이는 ServiceEntry 구성을 감지할 수 있는 방법을 제공하기 위해 오류를 발생시키도록 한 것이고 istio-proxy를 거치는 트래픽만 관여하기 때문에 istio-proxy를 거치지 않게 설정된 트래픽에는 전혀 적용되지 않는다.

ingress를 생략하는 경우 istiod가 워크로드와 Kubernetes Service의 정보를 보고 inbound listener를 자동으로 생성하므로 특별한 의도가 없다면 굳이 건드리지 않아도 된다.

아래는 앞에서 설명을 위해서 간단히만 다뤘기에 좀더 다양한 설정을 볼 수 있는 예시를 추가했다. 아래와 같이 연결에 대한 추가 설정을 할 수 있다.

 1apiVersion: networking.istio.io/v1 
 2kind: Sidecar 
 3metadata: 
 4  name: connection-pool-settings 
 5  namespace: prod-us1
 6spec: 
 7  workloadSelector: 
 8    labels: 
 9      app: productpage 
10  inboundConnectionPool: 
11    http: 
12      http1MaxPendingRequests: 1024
13      http2MaxRequests: 1024
14      maxRequestsPerConnection: 1024
15      maxRetries: 100
16  ingress: 
17    - port: 
18        number: 80 
19        protocol: HTTP 
20        name: somename 
21      connectionPool: 
22        http:
23          http1MaxPendingRequests: 1024 
24          http2MaxRequests: 1024 
25          maxRequestsPerConnection: 1024 
26          maxRetries: 100 
27        tcp: 
28          maxConnections: 100

보통은 연결에 대한 커넥션풀이나 재시도 설정을 DestinationRule에서만 다루어봤어서 Sidecar에 있는 설정과는 뭐가 다른지를 찾아봤다.

구분	`DestinationRule.connectionPool`	`Sidecar.inboundConnectionPool`
주 적용 위치	호출자 측 Envoy의 outbound cluster	서버 측 Envoy의 inbound cluster
upstream 대상	원격 destination service	같은 Pod의 애플리케이션
선택 기준	`DestinationRule.spec.host`	`Sidecar.workloadSelector`
주 목적	특정 호출자가 destination을 과도하게 호출하지 못하게 제한	서버 Pod 한 개가 전체 호출자로부터 받는 부하 제한
제한 단위	각 client Envoy의 outbound cluster별	각 server Envoy의 inbound port/cluster별
초과 시점	서버에 요청을 보내기 전 client Envoy에서	서버 Envoy까지 도착했지만 application으로 전달하기 전

LLM Usage Tracker: Claude Code와 Codex 사용량 기록하기

2026-07-18T15:37:17+09:00

최근 블로그를 개편하고 글 작성 도구도 만들면서 코딩 에이전트에 익숙해져가고 있다. 코딩 에이전트에 익숙해져 가면서 사람들이 이야기하던 것을 나도 몸으로 체감하고 있다.

시작은 블로그 개편이었지만 뭔가 만들기 시작하니까 추가적으로 만들고 싶은 아이디어가 생기고 있고 오랜만에 다시 사이드 프로젝트를 하는 느낌이 꽤 좋다.(몸이 힘들 뿐...)

다른 사람들이 토큰을 어느 정도 사용했다고 올리는 글을 보면서, 문득 “나는 토큰을 얼마나 사용하지?”라는 생각이 들었다. ccusage나 CodexBar로 어느 정도 통계를 볼 수 있고 공식 도구에서도 확인할 수 있지만, 도구마다 차이가 있어 일관된 방법으로 보고 싶었다. 작업하면서 현재 리밋이 얼마나 남았는지 보거나 오늘 얼마나 사용했는지 확인하는 데는 기존 도구로도 문제가 없다. 하지만 막상 기록하고 싶다고 생각하니, 더 오랜 기간 기록해 6개월 뒤에는 지금과 비교해 토큰 사용량이나 패턴이 얼마나 달라졌을지 궁금했다. (사용 여부와 상관없이 나는 기록에 집착하는 편이다.)

LLM Usage Tracker

이 프로젝트는 Codex GPT-5.5로 주로 만들었다.

claude, codex, gemini의 토큰 사용량을 한곳에서 추적할 수 있는 서비스를 만들고 싶습니다. 개인 사용 목적입니다.

claude, codex, gemini의 API로 토큰을 얼마나 사용하고 있는지 어디까지 조회할 수 있는지 조사해 주세요.

일별, 시간별 usage. 이게 있으면 주간 월간 통계도 쉽게 낼수 있습니다. 토큰을 어디서 사용했는지, 예를 들면 어떤 맥북인지, 어떤 프로젝트인지, 어떤 프로그램인지,

Codex, Claude Code, Antigravity 같은 코딩 에이전트인지, 다른 프로그램으로 사용한 것인지도 식별할 수 있는지? 사용 모델 종류, 토큰 usage가 모델별로 볼 수 있으면 더 좋습니다.

cladue와 codex는 fast모드라는 속도가 더 빠른 모드를 사용할 수 있습니다. 이걸 사용했을 때의 기준 등

ccusage 토큰을 달러로 환산할 수 있는지와 그 기준이 무엇인지?

회사 업무에서는 좀 더 상세한 내용을 적거나 계획을 함께 잡으며 진행하는 편이지만, 이건 사이드 프로젝트라 대충 요구사항을 던졌다. 적당히 대화를 주고받으며, 이미 사용 중인 ccusage와 CodexBar가 오픈소스라 두 프로젝트를 참고해 설계를 잡아 갔다.

데이터는 모두 로컬에 있고, 이를 중앙에 모으는 것이 목표였다. 그래서 로컬에서는 가벼운 collector를 실행해 서버로 데이터를 전송하고 SQLite에 저장하도록 Node.js로 만들었다.

데이터를 수집하고 필터링할 수 있는 기본적인 기능이 만들어졌다. 무엇을 만들지 머릿속에 모두 정해 둔 상태에서 만드는 것보다, 디자인을 적용해 사용해 보며 기능을 추가하는 편이 나을 것 같아 디자인 시안을 만들게 했다. (따로 디자인 도구를 연결하지는 않았다.)

(Codex) 시안은 이렇게 나눴습니다.

A. Operations Console: 매일 보는 기본 운영 화면. 필터, 컬렉터 상태, KPI, usage row가 균형 있게 보입니다. B. Provider Analysis: provider/model 비교 중심. “어디서 많이 썼는가”를 보기 좋습니다. C. Dense Ledger: 테이블 중심의 고밀도 화면. 실제 사용량 추적 도구로 오래 쓸 때 가장 실용적인 방향입니다.

적당한 시안이 나왔지만 딱히 맘에 들지는 않았다. 디자인은 원래도 어려웠는데 AI에서도 나는 아직 어렵다. (디자인쪽 잘하는 것도 연습해야 되는데...)

그래서 v0로 갔다. Vercel을 좋아하면서도 v0는 Vercel 느낌이 강하다고 느낀다. 그래도 한 번 써 보고 싶어서 현재 개발 중인 디자인 없는 사이트의 스크린샷을 주고 디자인해 달라고 했다.

역시 Vercel 느낌으로 나왔는데 아무래도 제품쪽으로 많이 깎은 서비스라서 Codex가 만들어준 시안보다는 훨씬 맘에 들었다. 그래서 이 시안을 던지고 디자인을 적용해 달라고 했다.

토큰 사용에는 입력·출력·캐시 토큰이 있어 계산이 복잡하다. 다른 오픈소스를 참고해 로직을 파악했고, 정액제를 사용 중이지만 대부분의 프로그램이 비용을 계산해 보여주므로 나도 비용을 볼 수 있게 만들었다. 사실 조금만 써도 정액제 요금보다 큰 비용으로 계산되지만, 정액제 비용도 적지 않으므로 낸 만큼 잘 쓰고 있는지 파악하려면 비용 추적도 필요했다.

어느정도 작업이 된 후에는 실제 데이터를 누적으로 쌓을 필요가 있어서 Railway에 배포했다. 평소 써보고 싶긴 했지만 사용할 일이 없었다가 이번 기회에 한번 사용해 보게 되었다. free trial이 끝나고 난 뒤에는 결국 $5 플랜을 결제했다. 혼자 쓰는 용도지만 결국 어딘가에는 배포해야 하니 배포 플랫폼 구독도 늘어난다. 지금은 다양한 서비스를 구경하고 경험하는 재미가 있지만, 결국에는 홈 서버를 구축해 운영하게 되지 않을까 생각했다.

서버에 배포하면 누구나 접속할 수 있으므로 Google 로그인을 연결했다. 서버 자체는 퍼블릭이지만 특정 이메일로만 로그인되도록 해서 Google로 로그인 하도록 구성했다. 이런 구성도 어떤게 더 편하고 유용할지 다양하게 테스트해볼 예정이다.

사용해보면서 데이터가 이상하거나 불편한 것들을 하나씩 수정하면서 개선했는데 데이터 누적을 위해서 원격 서버를 구성했지만 한편으로는 개발이 불편한 부분도 생기기 시작했다. 개발은 로컬에서 하다 보니, 실제 데이터를 덤프 떠서 테스트할 수 있도록 스냅샷 다운로드 기능을 만들었다. 또 에이전트가 배포된 서비스를 직접 확인하고 수정할 수 있도록 로그인을 우회하는 디버깅용 액세스를 임시로 여는 기능도 만들었다. 지금은 좀 최적화했지만 내 생각보다 데이터가 너무 많이 쌓여서 볼륨을 사용하는 디비 용량을 추적하는 사이트를 만들고 혹시 데이터가 잘못되는 경우를 대비해서 S3에 백업하는 기능도 만들었다.

보고 싶은 데이터가 무엇인지 생각하다가, 예전 Google Analytics에서 유용하게 사용했던 요일별, 시간대별 시각화를 적용해 내가 어느 시간에 토큰을 많이 사용하는지 볼 수 있게 했다. 데이터가 더 많이 쌓이면 패턴도 뚜렸해질 것이라고 생각하는데 이 시각화는 계속 고민하고 있다.

추가로 상세 차트를 몇 개 더 만들었다. 제공자별 토큰이나 비용 차트는 종종 보지만, 그 외 차트는 유용성이 높지 않아 고민 중이다. 이런 차트를 만들 때는 딱 3개나 6개로 맞추고 싶지만 아이디어가 부족하다.

LLM 사용이 늘어나고 사용량을 추적하다 보니 가장 궁금해진 것은 Limit이었다. 매 시간마다 어느정도 리밋이 남고 주간 리밋은 얼마나 남았는지 알게 되곤 하지만 이부분은 시간이 지나면 기억할 수 없으므로 이를 기록하고 싶었다. 마침 리밋도 추적할 수 있다고 해서 데이터로 남기니까 세션별, 주간 리밋을 볼 수 있었고 언제 리셋되는지 파악할 수 있어서 맘에 들었다.

리밋은 플랜에 따라 달라지고, 시간이 지나면 플랜도 계속 바뀔 거라 플랜별로 다르게 표시하고 싶었다. 하지만 이는 추적이 불가능하다고 해서 해당 기간의 플랜이 데이터로 남도록 만들었다. Kakao에서 ChatGPT 프로 플랜을 싸게 팔아서 사용하던게 끝나서 무료로 지낸 며칠까지 잘 기록되었다.

이 구조는 로컬에 Collector를 설치해 두고, 여기서 Claude Code나 Codex가 남기는 세션 데이터를 수집해 원격 서버로 전송하는 방식이다. 그래서 대시보드에서 Collector의 연결여부를 추적할 수 있게 했다.

Usage Detail에는 raw 데이터를 볼 수 있게 했다. 지금은 추적하지 않지만 나중에는 추적해서 봐야할 수도 있고 디버깅 목적으로도 필요해서 raw 데이터도 일단 쌓아두고 있다. 처음에는 데이터 증가폭이 너무 컸지만 어느정도 최적화를 한 뒤에는 적당한 선에서 유지되고 있다.

데이터를 쉽게 볼 수 있어 좋기는 한데, Claude Code와 Codex도 계속 기능을 추가하고 데이터 형식도 변경하기 때문에 지속적인 업데이트가 필요하다는 걸 알게 되었다. 최근 Fable 5와 GPT-5.6이 출시되면서 모델과 비용 추적이 제대로 되지 않아서 수정을 했다. 앞으로도 이런 일은 반복되겠지만 LLM이 원인을 잘 찾아주고 마이그레이션도 잘 해주므로 혼자서 사용하는 목적에는 크게 부담없이 사용하고 있다.

기술 뉴스 #298 : 2026-07-16

2026-07-16T04:21:32+09:00

웹개발 관련

Getting Started with Anchor Positioning : 툴팁을 화면 안에서 띄우려면 처리가 꽤 복잡한데, Anchor Positioning API로 이를 쉽게 처리할 수 있다. 대상 요소에 CSS로 anchor-name으로 고유한 이름을 지정하고 position-anchor로 앵커에 연결할 수 있다. position-area로 원하는 위치를 조정하고 세부사항을 지정하면 자연스러운 툴팁을 쉽게 구현할 수 있다.(영어)
Wordgard Release 0.1 : 웹용 코드 에디터 CodeMirror를 만든 Marijn Haverbeke가 텍스트 에디터 ProseMirror와 CodeMirror 6 재설계에서 얻은 경험을 바탕으로, ProseMirror의 새로운 버전인 리치 텍스트 에디터 Wordgard 프로젝트를 공개했다. ProseMirror도 계속 유지보수할 것이지만, 아쉬운 결정이 있어서 완전히 새로 만들게 되었다. Wordgard는 델타 형식에서 파생된 CodeMirror의 변경 사항 표현 방식을 바탕으로 한 시스템을 사용한다.(영어)
오리진 트라이얼로 이메일 확인 프로토콜 테스트 | Blog | Chrome for Developers : 입력받은 이메일 주소로 메일을 보내서 소유자를 인증하는 이메일 확인을 자동화할 수 있는 프로토콜을 크롬이 제안하고 오리진 트라이얼로 피드백을 받고 있다. 사용자가 브라우저에서 이메일 제공 업체에 로그인한 상태에서 이메일 확인을 하려는 사이트가 이메일 제공 업체에 등록된 상태이면 사이트에서 이메일을 선택하면 이메일 인증 토큰(EVT)를 발급하고 해당 사이트가 이를 통해 소유주임을 자동으로 확인할 수 있다.(영어)
How Astryx works : Meta에서 AI와 연동되면서 의존성 없이 사용자가 정의할 수 있는 디자인 시스템 Astryx를 오픈소스로 공개했다. Astryx는 사전 컴파일된 CSS와 함께 제공되는 React 컴포넌트 라이브러리로 React와 StyleX 기반으로 구축되었다.(영어)

그 밖의 개발 관련

Getting started with loops : Claude Code에서 중지 조건이 충족될 때까지 작업을 반복하는 에이전트인 루프를 사용하는 방법을 설명한다. 턴제 루프는 사용자 입력에 따라 실행되고 /goal은 목표 기반 루프에 /loop와 /schedule은 시간 기반 루프에 사용할 수 있다. 선제적 루프는 사람의 개입 없이 이벤트나 일정에 따라 트리거되어 작업을 진행한다.(영어)
Rewriting Bun in Rust : 2021년 esbuild의 트랜스파일러를 Go에서 Zig로 바꾸면서 시작된 Bun은 Zig 덕에 완성될 수 있었다. 하지만 Bun의 버그 수정 목록은 너무 많았고 Zig는 메모리를 자동으로 관리해 주지 않아서 정리 코드를 잘 사용하기 위해 엄격한 스타일 가이드를 도입하는 것이 현실적인 선택이었다. 버그의 상당수는 오류 경로에서 해제를 잊은 경우였는데, Rust는 이를 컴파일러 오류로 처리해 더 효과적인 피드백 루프를 준다. 그래서 Bun의 53만 라인에 이르는 Zig 코드를 Claude Fable 5를 이용해 11일 동안 새로 작성하기 시작했다. 작업은 한꺼번에 처리하기로 하고 동적 워크플로우를 사용했으며 구현자 외에 에이전트 2개로 검토하게 했다.(영어)
The git history command deserves more attention : Git 2.54, 2.55에서 실험적으로 도입된 git history 명령어에는 기존 커밋을 수정하고 모든 브랜치를 이에 맞춰 자동으로 리베이스하는 fixup, 커밋 메시지를 업데이트하고 그 위의 모든 내용을 자동으로 리베이스하는 reword, 하나의 커밋을 두 개로 분할하는 split 서브 커맨드를 제공한다.(영어)
Claude Desktop on Linux (beta) : Claude Code 데스크톱 앱이 Linux 버전도 베타로 출시되었다.(영어)
Open source license compliance is in public preview : 저장소에 의존성을 추가하거나 수정할 때 라이센스를 검사해서 프로젝트의 라이센스와 맞는지를 확인해주는 라이센스 컴플라이언스 기능이 공개 프리뷰로 열렸다. 저장소의 ruleset에서 "Require license compliance check results before merging"를 활성화해서 사용할 수 있다.(영어)
Announcing Box3D : Box2D에서 게임을 위한 오픈소스 3D 물리 엔진 Box3D를 공개했다.(영어)

AI 관련

GPT‑5.6: Frontier intelligence that scales with your ambition : OpenAI가 GPT-5.6 모델 제품군을 정식 출시했다. 여기에는 플래그십 모델인 Sol, 일상 업무에 적합한 Terra, 비용 효율적인 모델인 Luna가 포함되어 있다.(영어)
Introducing Claude Sonnet 5 : Anthropic에서 Opus 4.8에 근접하면서 가격이 저렴한 최신 모델 Sonnet 5를 출시했다. Sonnet 4.6에 비해 잘못된 행동을 할 확률이 낮고 더 안전한 것으로 평가되었다.(영어)
Introducing Grok 4.5 : SpaceXAI가 최신 모델인 Grok 4.5를 출시했다. Cursor와 함께 훈련했고 공학 과제에서 뛰어난 성능을 보여준다.(영어)
GPT‑Live 소개 : OpenAI에서 AI와 실제 사람처럼 대화할 수 있는 음성 모델 GPT-Live를 출시했다. 초기 계단식 음성 대화는 음성을 텍스트로 변환하고 응답을 생성하고 이를 다시 음성으로 만드는 3가지 모델을 이용했지만 턴 기반 음성 모델에서는 하나의 모델안에서 음성을 처리하고 생성해서 자연스럽게 만들었지만 사용자의 말이 끝나고 처리해야 하므로 어색함이 존재했다. GPT-Live는 응답을 생성하는 동시에 사용자 입력을 처리할 수 있어 자연스럽게 대화하고, 복잡한 작업은 다른 모델에 맡겨 추론하도록 했다.(한국어)
GPT-5.6 기반 ChatGPT Work : OpenAI가 GPT-5.6 기반으로 팀에서 사용하는 도구의 맥락을 연결해 결과물을 만들 수 있는 ChatGPT Work를 출시했다.(한국어)
Moving to the new ChatGPT desktop app : OpenAI가 ChatGPT와 Codex로 분리되어 있던 데스크톱 앱을 통합하고 하나의 앱에서 Chat, ChatGPT Work, Codex를 모두 제공하는 방식으로 바꾸었다. 기존 ChatGPT 앱은 ChatGPT Classic으로 이름이 바뀌었다.(영어)
Claude Science, an AI workbench for scientists : Anthropic이 과학자들을 위한 AI 워크벤치인 Claude Science를 출시했다. Claude Science는 연구 수행을 돕고 결과물을 생성하면서 반복적으로 개선하도록 도와준다.(영어)
Start building with Nano Banana 2 Lite and Gemini Omni Flash : Nano Banana에서 가장 빠르고 비용 효율적인 이미지 모델인 Nano Banana 2 Lite와 비용 효율적으로 고품질 동영상을 생성하고 편집할 수 있는 Gemini Omni Flash를 출시했다.(영어)
GeneBench-Pro 소개 : OpenAI에서 계산생물학 연구에 필요한 높은 수준의 판단과 분석을 모델이 제대로 수행하는지 평가하는 벤치마크인 GeneBench-Pro를 출시했다.(한국어)
Redeploying Claude Fable 5 : 지난 6월 12일 미국 정부의 수출 통제 조치로 차단되었던 Claude Fable 5와 Claude Mythos 5가 지난 6월 30일 해제되어서 7월 1일부터 다시 Fable 5를 사용할 수 있게 되었다. 7일까지 유료 플랜에서 제공되다가 12일까지로 연장되었다.(영어)
Leanstral 1.5: Proof Abundance for All : Mistral에서 코드의 정확성을 증명하는데 초점을 맞춘 모델인 Leanstral 1.5를 공개했다. Leanstral 1.5는 전체 매개변수가 119B지만 활성 매개변수는 6B여서, 성능을 높이면서도 사용하기 쉬워졌다.(영어)
Introducing Muse Spark 1.1 : Meta에서 에이전트 기반 작업을 위해 구축된 다중 추론 모델 Muse Spark 1.1을 발표했다.(영어)

인프라 관련

Kubernetes 버전 롤백을 사용하여 Amazon EKS 클러스터를 자신 있게 업그레이드하세요! : AWS EKS가 버전 업그레이드를 더 적극적으로 할 수 있도록 버전 롤백 기능을 도입해서 7일 이내에 이전에 운영하던 버전으로 롤백할 수 있게 되었다.(한국어)
Announcing vmestimator: Real-time Cardinality Estimations for VictoriaMetrics and Prometheus : VictoriaMetrics에서 시계열 데이터에서 카디널리티 추세를 실시간으로 모니터링하고 알림을 보낼 수 있는 vmestimator를 오픈소스로 공개했다.(영어)

보안 및 장애

GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos : GitHub에서 새로 출시한 Agentic Workflows를 이용해서 이슈를 만들어서 워크플로우를 실행하게 해서 접근할 수 없는 비공개 저장소의 데이터를 공개 저장소에 올리게 하는 공격에 성공하고 이를 GitLost라고 명명했다.(영어)
GPT‑Red: Unlocking Self-Improvement for Robustness : OpenAI에서 자동화된 내부 전용 레드팀 모델을 훈련시킨 GPT-Red를 공개했다.(영어)

볼만한 링크

My Thoughts on the Bun Rust Rewrite : Zig를 만든 Andrew Kelley가 Bun이 Rust로 재작성된 것에 대한 생각을 밝혔다. Bun을 만든 Jarred Summer가 Zig 커뮤니티에 합류해서 빠르게 배우면서 커뮤니티에 긍정적인 영향을 끼치면서 Zig 커뮤니티에 감사함을 많이 표현했다. 하지만 Bun이 관심을 모으고 Oven이 본격적인 사업을 운영하면서 양상은 달라졌고 다른 사람들에게도 자신과 같은 삶을 요구하면서 형편없는 관리자로 평가받기 시작했고 Zig 커뮤니티 사람들도 Oven에서 일하는 것은 기피하기 시작했다. 이때부터 Zig와 Jarred의 갈등도 깊어지기 시작했고 LLM을 사용한 Bun의 코드 품질은 매우 나빠졌고 GitHub 봇인 Robobun이 Zig를 어떻게 작성하면 안되는지를 보여주면서 Zig 커뮤니티는 부담을 느끼기 시작했다. Oven이 Anthropic에 인수되고 미팅에도 나타나지 않았을때 관계가 끝났음을 알고 있었고 Rust로 재작성한다고 발표했을 때 너무 기쁠 정도였다. 핵심은 Zig와 Rust의 언어적 특징과는 상관없이 두 프로젝트 간의 가치관 차이로 발생한 것이다.(영어)
Zuckerberg 'Admits' Meta's Layoffs Were Ineffective : Meta의 CEO인 Mark Zuckerberg가 타운홀 미팅에서 구조조정 이후 지난 4개월 동안의 에이전트 개발 속도가 예상만큼 좋지 못했고, 당시 Claude Code 같은 도구에 너무 낙관적이었다고 밝혔다. Meta는 분위기에 의존해서 의사결정을 하는 경향이 있는데 메타버스가 실패였다는 걸 너무 늦게 깨달아 AI에서도 뒤처지게 되었고, 수천 명의 직원을 해고하고 AI 엔지니어에게 투자하는 결정을 했지만 이 역시 분위기를 따른 의사결정이었다고 말한다.(영어)
Interview With Mitchell Hashimoto : HashiCorp의 창업자이면서 Ghostty 터미널을 만들고 있는 Mitchell Hashimoto의 인터뷰다. 어떤 의도로 Ghostty를 만들고 있고 오픈소스와 프로그래밍 언어 생태계에 대해 어떤 생각을 가지고 있는지 알 수 있다.(영어)

IT 업계 뉴스

Better Auth is joining Vercel : 인증 프레임워크를 만드는 Better Auth가 Vercel에 인수되었다. 3년 전 인증 기능이 필요해서 NextAuth를 주로 사용했지만 더 많은 요구사항을 충족하지 못했고 다른 사람도 인증 시스템에 시간을 많이 쓰고 있다는 걸 깨닫고 better-auth를 만들게 되었고, 사람들에게 피드백을 받으면서 1.0을 릴리스했다. Better Auth가 인기를 끌면서 YC에 지원해서 합격하게 되어 회사를 설립하고 Auth.js와 NextAuth.js를 인수하게 되었다. 다음 작업으로 호스팅을 준비하다가 AI로 인해 달라지는 환경에 맞게 Agent Auth를 출시했고 이 시도를 이어가기에 Vercel이 적합하다고 판단하게 되었다.(영어)
Chat Control 1.0 passed the European Parliament — through the back door : EU가 암호화된 메시지와 사진 등 사적인 디지털 통신 내용을 사전 심의 없이 스캔할 수 있는 법안인 Chat Control 1.0이 유럽 의회를 통과해서 2028년 4월 3일까지 유효하게 되었다. Chat Control 1.0은 지난 4월 이미 만료되었으나 2.0이 아직 합의되지 않았고 지난 3월 Chat Control 1.0의 연장안이 의회에서 부결되었지만 6월말 의장이 재검토 후 유럽 이사회로 회부했고 이를 의회로 다시 돌려보냈으나 거부 동의안이 절대 다수에 미치지 못하면서 통과되었다.(영어)
The 'Father of the Internet' is finally retiring : TCP/IP를 개발해서 인터넷의 아버지라고 불리는 Vinton Cerf가 구글에서 부사장 겸 Chief Internet Evangelist로 2005년부터 근무했지만 이 직책에서 물러나 은퇴하게 되었다.(영어)

프로젝트

MemNixFS : Linux 메모리 덤프를 파일 시스템으로 마운트해서 기존 도구로 조사할 수 있게 하는 프로젝트.
Agentic Inbox : Cloudflare의 인프라를 이용해서 웹 인터페이스를 통해 이메일을 보내고 받고 관리할 수 있다.
Maestro : 모바일 UI 테스트 도구
Cloudflare Drop : 폴더나 Zip 파일을 드래그앤 드롭해서 올리면 Cloudflare에 바로 배포해준다.
nose : 중복 코드를 찾아주는 CLI
Orca : 에이전트에 최적화된 IDE
Capsomnia : 캡스락을 키면 맥북을 켜진채로 유지하게 하는 앱

버전 업데이트

TypeScript v7.0 : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
- Go로 포팅해서 10배 빨라진 새 버전
podman v6.0.0 : 컨테이너 엔진, 릴리스 공지
npm v12.0.0 : Node.js 패키지 매니저, 릴리스 공지
sbt v2.0 : Scala 빌드 도구, 릴리스 공지
TinyBase v9.0 : 로컬 우선 앱을 위한 리액티브 데이터 스토어, 릴리스 공지
Zed v1.10 : 코드 에디터, 릴리스 공지
Antigravity CLI v1.1.0 : 코딩 에이전트, 릴리스 공지
Upyo v0.5.0 : Node.js, Deno, Bun용 이메일 라이브러리, 릴리스 공지
GraalVM v25.1 : 통합 가상 머신, 릴리스 공지
Node.js v26.5.0 : 자바스크립트 런타임, 릴리스 공지
Expo SDK v57.0.0 : React로 네이티브 앱을 만드는 플랫폼 SDK, 릴리스 공지
Ant Design v6.5.0 : React 디자인 컴포넌트, 릴리스 공지
etcd v3.7.0 : 분산 키-밸류 스토어, 릴리스 공지
Electron v43.0.0 : 크로스 플랫폼 데스크톱 애플리케이션 플랫폼, 릴리스 공지
ESLint v10.7.0 : JavaScript 코드 분석 도구, 릴리스 공지
Rust v1.97.0 : 프로그래밍 언어, 릴리스 공지
Module Federation v2.8.0 : 자바스크립트 애플리케이션의 아키텍처 패턴, 릴리스 공지
Vue Router v5.2.0 : Vue.js의 라우팅 라이브러리, 릴리스 공지
Rolldown v1.2.0 : JavaScript/TypeScript 번들러, 릴리스 공지

기술 뉴스 #297 : 2026-07-01

2026-07-01T01:45:17+09:00

웹개발 관련

Moving Linear from styled‑components to StyleX : 이슈 관리 서비스인 Linear의 React 애플리케이션을 런타임 CSS-in-JS의 성능 문제 때문에 StyleX로 마이그레이션했다. 그동안 styled-components를 잘 사용해 왔지만 자유도가 높아서 일관된 스타일을 유지하려면 신경 쓸 일이 많았고 styled-components가 유지보수 모드가 되면서 바꾸기로 결정했다. 다음 도구는 최소한의 런타임을 가지고 강한 캡슐화를 지원하면서 예측 가능성이 높아야 한다는 기준으로 검토한 결과 StyleX를 선택하고 점진적인 마이그레이션을 진행해서 현재는 58%를 전환한 상태이다.(영어)
The HTTP QUERY Method : GET처럼 멱등적인 요청이지만 URL 파라미터로 넣기에는 데이터가 많은 경우를 위해 POST처럼 쿼리를 바디에 넣을 수 있는 QUERY 메서드를 추가하는 표준이 제안되었다.(영어)
런타임 통계 잠금 해제: 에이전트용 Chrome DevTools의 서드 파티 개발자 도구 소개 : Google이 Chrome DevTools의 서드 파티 개발자 도구를 공개했다. 이 도구를 사용하면 단순히 최종 DOM을 보는 것을 넘어 프레임워크의 내부 상태까지 AI 에이전트가 살펴보면서 디버깅할 수 있게 된다.(한국어)
PACT: Anonymous Credentials for the Web : 사용자는 프라이버시를 보호하려고 하고 서비스는 봇을 차단하려는 양쪽의 목적이 있어서 브라우저의 프라이버시 보호 기능을 사용하면 서비스를 제대로 이용하기가 어려워진다. 결국 서비스는 봇의 속도를 제한하려고 하는데, 이를 위해서는 프라이버시를 침해할 수밖에 없게 된다. 이 둘을 다 해결하기 위해 W3C 워크숍에서 PACT(Private Access COntrol Tokens) 설계 초안을 그리기 시작했다. PACT는 사용자가 누구인지 식별하지 않은 채 속도 제한에 걸리지 않았다는 것을 익명으로 증명하는 것이 목표이다.(영어)

그 밖의 개발 관련

Iterating faster with TypeScript 7 : 초기 개발부터 TypeScript를 선택하고 함께 성장해왔던 VS Code가 TypeScript 7 도입도 적극적으로 협업했다. TypeScript 7 초기부터 빠르게 테스트를 진행했고 7 버전과의 브리지 역할을 하는 6이 나왔을 때 빠르게 채택했다. TS 6, 7을 모두 CI에 설정해서 둘 다 동작하게 하면서 TS 팀에 피드백을 주었다. 2026년에 들어서면서는 TS 7을 기본값으로 돌리기 시작했고 타입 검사가 36초에서 5초로 줄어들었으며 다른 컴파일이나 watch도 훨씬 빨라졌다.(영어)
DuckDB Internals: Why is DuckDB Fast? : 최근 많이 사용되고 있는 DuckDB가 왜 빠른지를 설명한다. DuckDB를 빠르게 하는 설계가 있는데 DuckDB가 클라이언트와 같은 프로세스에서 동작해서 대역폭과 오버헤드로 인한 병목문제를 피했고 SQL문을 파싱, 바인딩, 플랜, 최적화 단계를 거쳐서 빠르게 만든다. 스토리지는 존맵이 적용된 컬럼형 스토리지를 사용해서 빠르게 필요한 데이터를 조회할 수 있다.(영어)
The New SDLC With Vibe Coding : Google에서 AI 코딩 도구로 인해서 소프트웨어 개발 생명주기(SDLC)가 어떻게 바뀌었는지에 대한 백서를 공개했다. 이전엔 문법을 직접 다루었지만 이제는 의도를 설명하는 방식으로 바뀌었고, 개발 속도가 빨라지면서 명세의 품질, 설계 판단, 검증 역량이 더 중요해졌다. 이제 개발자의 산출물은 코드가 아니라 코드를 생산하는 시스템으로 바뀌었다. 이 백서 작성에 참여한 Addy Osmani가 백서의 내용을 정리한 The New Software Lifecycle도 작성했다.(영어)
Introducing eve : Vercel에서 오픈소스 에이전트 프레임워크인 eve를 발표했다. eve는 Vercel 내부에서 사용하는 프레임워크로 내구성 있는 실행, 샌드박스화된 컴퓨팅, 휴먼 인 더 루프 승인, 서브에이전트를 지원한다.(영어)
Cursor for iOS로 어디서나 개발하세요 : Cursor가 클라우드에서 실행되는 에이전트를 휴대폰에서 사용할 수 있도록 iOS 앱을 출시했다.(한국어)

AI 관련

Previewing GPT‑5.6 Sol: a next-generation model : OpenAI가 차세대 모델인 GPT-5.6 시리즈를 제한된 프리뷰로 공개했다. 5.6에서는 Sol이 플래그십 모델이고 GPT-5.5와 비슷한 성능을 보여주면서 2배 저렴한 Terra와 최저 비용으로 강력한 성능을 제공하는 Luna가 포함되어 있다. GPT‑5.6 Sol은 지금까지 공개한 모델 중 가장 강력한 모델로 코딩, 생물학, 사이버보안에서 강력한 성능을 보여주고, 더 깊게 추론할 수 있도록 max 추론 노력을 도입했다. 서브에이전트까지 활용할 수 있는 ultra 모드도 도입한다.(영어)
Introducing Mistral OCR 4 : 170개 언어를 지원하는 Mistral OCR 4가 나왔다. 이전 버전이 페이지에서 깨끗한 텍스트와 표를 추출하는 데 중점을 두었다면 OCR 4는 문서의 구조화된 표현을 반환한다. 각 블록은 경계 상자로 위치를 지정하고 유형별로 분류해서 신뢰도 점수를 생성한다.(영어)
Sakana Fugu: One Model to Command Them All : Sakana AI에서 자율 오케스트레이션으로 프론티어 성능에 맞춘 Fugu Ultra를 출시했다. Sakana Fugu는 단일 파운데이션 모델로 멀티에이전트 오케스트레이션 시스템을 단일 API로 지원하며, 낮은 지연 시간으로 일상 작업에 적합한 Fugu와 복잡한 작업을 할 수 있는 Fugu Ultra 두 가지 모델로 제공된다. Sakana AI에 따르면 Fugu Ultra는 가장 엄격한 엔지니어링, 과학, 추론 벤치마크에서 Fable 5와 Mythos Preview와 비슷한 수준의 성능을 보여준다.(영어)
Interactions API: our primary interface for Gemini models and agents : Google Gemini 모델과 에이전트와 상호작용하는 주요 API인 Interactions API가 작년 12월 공개 베타 이후 정식으로 출시되어 Gemini를 사용하는 표준 방식이 되었다.(영어)
Claude Code now supports artifacts : Claude Code가 세션 전체 컨텍스트를 기반으로 실시간 상호작용이 가능한 웹페이지를 만들어 다른 사람과 공유할 수 있는 artifacts 기능을 지원한다.(영어)
Grok Imagine Video 1.5 : Grok에서 비디오 생성 모델 Imagine Video 1.5를 출시했다. 이전 모델에 비해 오디오와 음성이 더 명확하고 움직임도 자연스럽게 표현되면서 생성속도는 2배로 빨라졌다.(영어)
Introducing Claude Tag : Anthropic이 Claude를 팀 구성원으로 참여시킬 수 있는 Claude Tag 기능을 출시했다. Claude Tag는 Slack부터 지원을 시작하고 채널에 Claude를 추가해서 @Claude를 멘션해서 작업을 시킬 수 있다.(영어)
GLM-5.2 - How to Run Locally : Z.ai의 최근 모델인 GLM-5.2를 Unsloth Studio, llama.cpp로 로컬에서 실행하는 방법을 설명한다.(영어)

인프라 관련

Google hits 50% IPv6 : Google 데이터 기준으로 IPv6가 처음으로 50%에 도달했다. APNIC 기준으로는 42%로 나타나는데 이는 측정 방법이 Google의 광고를 이용한 방식이라서 국가의 경제수준에 따라 샘플수가 다를 수 있어서 발생하는 차이이다.(영어)

보안 및 장애

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온 : AI 시대의 인증 과제를 해결한 ID-JAG를 직접 실습할 수 있는 ID-JAG The Hard Way 핸즈온을 만들고 AI 에이전트를 IdP와 Authenz로 인증/인가하는 흐름을 설명한다.(영어)
- Daybreak: Tools for securing every organization in the world : OpenAI의 사이버 보안 AI인 Daybreak를 확장해서 취약점을 발견하고 패치하는 Codex Security 플러그인과 GPT‑5.5‑Cyber를 공개했다.(영어)
Read-only Actions cache for untrusted triggers : GitHub Actions가 캐시 포이즈닝을 막기 위해서 쓰기 권한 없이 실행되는 워크플로우에서는 읽기 전용 캐시 토큰을 발급해서 캐시를 조작할 수 없도록 변경했다.(영어)

볼만한 링크

AI시대 나의 전문성을 재설계하는 법 : 믿고 보는 하용호님의 발표자료이다. AX를 하면서 겪게되는 시련들과 요즘 부각되는 기술부채, 인지부채, 의도부채를 설명하고 지금 AI 환경이 어떻게 달라지고 우리는 어떤 역할을 해야하는지 설명하는 자료다.(한국어)

IT 업계 뉴스

SpaceX is officially buying Cursor for $60 billion : SpaceX가 상장 후 코딩 에이전트를 만드는 Cursor를 600억 달러(약 92조원)에 인수한다고 밝혔다. SpaceX는 지난 4월 Cursor와 합의하고 600억 달러에 인수하거나 100억 달러의 해지 수수료를 지급하기로 발표한 뒤 이뤄진 인수다.(영어)
John Jumper: After nearly 9 years, I have decided to leave Google DeepMind and join Anthropic : 단백질 구조 예측을 하는 AlphaFold를 만들고 노벨 화학상을 수상한 Google DeepMind의 John Jumper가 Anthropic에 합류했다.(영어)
Dan Abramov: I have joined the nextjs team at vercel : React의 유명한 개발자 Dan Abramov가 Meta를 퇴사한 이후 독립 개발자로 일하다가 Vercel의 Next.js 팀에 합류한다고 밝혔다.(영어)
Justin Poehnelt: Two months ago I was fired by Google for creating the Google Workspace CLI : 몇달 전 Google Workspace CLI를 만들어서 공개했던 Google 엔지니어 Justin Poehnelt가 해당 CLI를 만들었다는 이유로 해고 당했다고 공개했다.(영어)
The U.S. government will decide who gets to use the latest American AI technology : 미국 행정부가 OpenAI와 Anthropic의 최신 AI 기술에 대한 접근을 심사하는 정책을 확대하고 있다. 지난 번에 Fable 5와 Mythos의 미국인외 접근을 차단하도록 한 조치에 이어 OpenAI의 최신 모델에 대한 접근을 미국 정부가 결정하기로 했다고 밝혔다.(영어)

프로젝트

로어: 차세대 오픈소스 버전 관리 시스템 : Epic Games에서 버전 컨트롤 시스템을 오픈소스로 공개했다.
Origin: A git forge for the agentic era : Cursor에서 AI 시대에 맞는 git 플랫폼을 공개했고 현재는 대기 신청을 받고 있다.

버전 업데이트

Android 17 : 모바일 운영체제, 릴리스 공지
astro v7.0 : JavaScript 웹 프레임워크, 릴리스 공지
- Vite 7 사용
- .astro 컴포넌트 형식을 위한 새로운 Rust 컴파일러 적용
- Rust 기반의 마크다운과 MDX 지원
TypeScript v7.0 RC : Microsoft가 만든 JavaScript transpiler, 릴리스 공지
- TypeScript에서 Go로 전환해서 6.0보다 10배 빨라진 7.0의 Release Candidate
React Router v8.0 : React의 라우팅 라이브러리, 릴리스 공지
Vite v8.1 : 프론트엔드 빌드 도구, 릴리스 공지
- 실험적 번들형 개발 모드로 10,000개의 React 컴포넌트 앱에서 비번들형에 비해서 15배 빠른 시작 속도와 10배 빠른 새로고침 속도를 보여주었다.
- 실험적인 청크 import map 기능으로 캐시 효율성을 개선
- Wasm ESM 통합 지원
Git v2.55.0 : 분산 형상관리 도구, 변경사항
LogTape v2.2.0 : JavaScript 로깅 라이브러리, 릴리스 공지
pnpm v11.9.0 : Node.js 패키지 매니저, 릴리스 공지
Base UI v1.6.0 : UI 컴포넌트 라이브러리, 릴리스 공지
Rsbuild v2.1 : Rspack 기반의 빌드 도구, 릴리스 공지
Node.js v26.4.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v22.23.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.18.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
Boundary v1.0 : 인프라 접근 관리, 릴리스 공지
Deno v2.9.0 : TypeScript 런타임, 릴리스 공지
Prettier v3.9 : 코드 포매터, 릴리스 공지
Dragonfly v2.5.0 : P2P 기반 파일 배포 및 이미지 가속 시스템, 릴리스 공지

기술 뉴스 #296 : 2026-06-16

2026-06-16T03:03:20+09:00

웹개발 관련

JavaScript Temporal API: Fixing Everything That Was Wrong With Date : JavaScript의 Date 객체의 현대적 대안인 Temporal API의 기본적인 사용법과 타임존 사용, 날짜 계산, 포매팅 등의 사용법을 설명한다.(영어)
원활한 PWA 출처 이전: 사용자를 잃지 않고 도메인 변경 : Chrome 150부터 프로그레시브 웹 앱(PWA)의 출처 이전을 지원해서 이제 도메인을 바꾸는 경우에도 기존에 설치된 PWA를 이동시킬 수 있게 되었다. 새 앱에 migrate_from을 추가하고, 이전 출처의 .well-known에 마이그레이션을 지정한 뒤 강제로 바꾸게 할지 제안만 할지 선택할 수 있다.(한국어)
Upcoming breaking changes for npm v12 : npm이 7월에 출시될 다음 메이저 버전 v12에서 의존성 설치와 관련된 변경 사항을 예고했다. allowScripts가 기본으로 꺼져서 의존성의 스크립트를 자동으로 실행하지 않고, --allow-git과 --allow-remote도 none이 되어 Git 의존성이나 원격 URL 의존성을 처리하지 않는다.(영어)
Introducing the MDN MCP server : MDN의 문서를 AI가 활용할 수 있도록 MDN에서 MCP 서버를 공개했다.(영어)

그 밖의 개발 관련

A new era for software testing : Redis를 만든 antirez가 AI를 활용한 소프트웨어 개발에서 품질과 시간 사이에 트레이드오프가 있지만, QA와 테스트 분야에서는 품질을 타협하지 않고 프로세스를 자동화하고 있다고 얘기한다. LLM에 테스트 외의 QA를 지시해서 소프트웨어 품질을 높일 수 있다.(영어)
Grit: rewriting Git in Rust with agents : Scott Chacon이 실험적인 목적으로 LLM을 사용해서 Git을 Rust로 재작성한 Grit을 작성했다. Git의 테스트를 이용했고 대부분의 테스트는 통과했지만, 복잡한 push, fetch 기능은 다른 도구에 통합하기 좋게 개선하고 WASM 빌드가 가능해지면서 Edge Function 같은 곳에서 Git 명령어를 모두 사용할 수도 있을 것으로 예상한다. Grit을 만들면서 에이전트가 편법으로 테스트를 통과시키는 걸 막느라 고생했고, 에이전트가 스스로 뭘 망가뜨리는지 알지 못해 중간에 테스트가 크게 깨지기도 했다. 병렬로 오래 돌리는 작업을 하면서 작업 목록 관리가 쉽지 않았고 여러 곳에서 병렬로 실행하는데 자원을 많이 사용해서 고생했다. 이 작업을 하면서 처음에는 OpenClaw에 Claude Code를 연결해서 사용했지만 비용도 비용이고 문제가 계속 발생해서 Cursor 클라우드 에이전트를 사용했는데 꽤 만족했다고 한다.(영어)
Loop Engineering : 루프 엔지니어링은 프롬프트를 직접 입력하는 대신 프롬프트를 입력하는 시스템을 설계하는 방식이다. 루프에는 자동화, 워크트리, 스킬, 플러그인/커넥터, 서브에이전트 다섯 가지 요소와 정보를 기억할 수 있는 메모리가 필요하다. 루프 엔지니어링이 미래라고 생각하지만 여전히 검증은 사람이 해야 한다. 루프를 구축하되 엔지니어로 남으려는 사람처럼 구축해야 한다.(영어)
Agentic Code Review : 코드 작성 비용은 줄어들었지만 코드를 리뷰하는 비용은 그대로인 상황이다. Faros AI에 따르면 AI로 인한 결함과 리뷰 시간이 증가했고, 리뷰 없이 머지된 PR도 증가한 것으로 나타났다. CodeRabbit도 AI가 작성한 코드에서 문제가 많이 발생한다고 얘기하고, GitClear는 10%의 생산성 향상을 위해 4배의 코드를 더 생산한다고 밝혔다. AI 코드 리뷰 도구들은 서로 같은 라인에 리뷰를 남기지 않으므로 최고의 도구 하나를 선택하기보다는 두 가지 도구를 함께 실행하는 것이 더 좋다. 사람이 모든 줄을 읽는 시대는 끝났고, 한 단계 위로 이동해서 모델이 책임지지 못하는 영역을 책임져야 한다고 주장한다.(영어)
I Built an Agentic Harness From Scratch. That Taught Me What Agents Actually Are : Python으로 만든 코딩 에이전트 하네스인 AgentForge를 만들면서 깨달은 점을 정리한 글이다. 파이썬 코드를 예시로 보여주면서 에이전트를 함수처럼 취급하지 않고, 제어 시스템을 구축해 도구를 제공하고 승인하는 방식을 설명한다.(영어)
Porting our Django backend to Rust improved the infra usage by 90% : Wasmer에서 패키지 정보를 제공하기 위해 운영한 Django 백엔드가 Python 개발자도 부족하고 부하가 너무 커져서 3개월간 1명이 AI를 이용해서 Rust로 전환했다. 전환 후 CPU는 220개에서 24개로, 평균 CPU 사용률은 80%에서 30%로, RAM은 800GB에서 64GB로 줄었고 성능도 훨씬 좋아졌다. Rust도 기존 저장소를 같이 사용하고 데이터베이스 모델과 로직을 같이 사용하며 검증기를 별도로 구축했으며 새로운 기능도 양쪽 모두에 같이 구축하면서 마이그레이션했다.(영어)
OpenAI Codex Sites : Codex에서 OpenAI가 호스팅하는 서버에 배포할 수 있는 Sites 플러그인을 미리보기로 출시했다.(영어)
Claude Client SDK CLI : Anthropic이 Claude의 모든 API를 CLI로 직접 사용할 수 있는 ant CLI를 출시했다.(영어)
Windsurf is now Devin Desktop : 작년 7월 Cognition이 Windsurf를 인수하고 이 Windsurf를 Devin Desktop으로 새로 런칭했다. Devin Desktop은 ACP(Agent Client Protocol)을 지원해서 다른 호환 에이전트와 같이 사용할 수 있다.(영어)
Introducing Vercel Drop : Vercel에서 Git이나 CLI를 사용하지 않고 그냥 파일이나 폴더를 브라우저에서 드래그 앤 드롭하면 배포할 수 있는 Vercel Drop을 공개했다.(영어)
MiMo Code: Scaling Coding Agents to Long-Horizon Tasks : Xiaomi의 MiMo 팀이 OpenCode를 기반으로 터미널 기반 코딩 에이전트를 오픈소스로 공개했다.(영어)

AI 관련

Claude Fable 5 and Claude Mythos 5 : Anthropic의 차세대 모델로 알려진 Mythos 계열의 모델인 Claude Fable 5가 출시되었다. 지금까지 공개된 모델보다 성능이 뛰어나고 사이버 보안 등에 끼칠 안전장치로 특정 주제에 대해서는 Claude Fable 5이 직접 대답하지 않고 Opus 4.8이 응답하도록 구성되어 있다. 그리고 보안업계를 위해 안정장치가 제거된 Claude Mythos 5로 Project Glasswing을 통해 배포했다. 공개한지 3일만에 미국 정부의 수출 통제 지침에 따라 모든 외국인의 Fable 5와 Mythos 5 접근이 전면 중단되었다.(영어)
MiniMax M3: Frontier Coding, 1M Context, Native Multimodality — All in One Model : MiniMax의 새 오픈 웨이트 모델 M3가 나왔다. 새로운 어텐션 아키텍처인 MSA(MiniMax Sparse Attention)를 적용해서 1M 컨텍스트를 지원하고 이미지와 동영상을 같이 사용할 수 있는 네티이브 멀티모달을 지원하고 코딩 능력 벤치마크에서도 GPT-5.5와 Gemini 3.1 Pro보다 좋게 나오고 Opus 4.7과 비슷하게 나왔다. M3가 나오면서 MiniMax Code도 공개했다.(영어)
Introducing Gemma 4 12B: a unified, encoder-free multimodal model : Google이 오픈 웨이트 모델인 Gemma 4 12B를 추가로 공개했다. Gemma 4 12B는 처음으로 오디오 입력을 지원하고 새로운 통합 아키텍처를 사용해서 다중 모달 인코더가 없으면 260억 파라미터 모델에 근접한 벤치마크를 보여주면서도 16GB의 VRAM으로 로컬에서도 실행할 수 있다.(영어)
Kimi-K2.7-Code : Moonshot AI에서 Kimi K2.6 기반으로 코딩에 특화된 에이전틱 모델 Kimi-K2.7-Code를 공개했다.(영어)
GLM-5.2 : Z.ai에서 새로운 플래그십 모델 GLM-5.2을 발표했다.(영어)
Fluid, natural voice translation with Gemini 3.5 Live Translate : Google이 실시간 음성 번역용 오디오 모델인 Gemini 3.5 Live Translate를 출시했다. 이 모델은 70개 이상의 언어를 자동으로 감지해서 화자의 억양, 속도, 음높이를 유지하면서 번역 음성을 생성할 수 있다.(영어)

인프라 관련

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify : Spotify는 에이전트가 등장하기 이전부터 개발자들이 의존성 관리나 마이그레이션, 취약점 패치 등 운영 작업에 많은 시간을 쓰는걸 알게되고 Fleetshift라는 시스템으로 유지 보수 작업을 자동화했다. 하지만 이는 단순한 작업만 자동화할 수 있었는데 LLM이 성숙해 지면서 백그라운드 코딩 에이전트인 Honk를 만들어서 Claude로 실행하도록 했고 Fleetshift와 함게 동작하면서 코드를 수정한다. 이를 통해 Claude가 참고할 코드가 많고 일관성이 있을 때 더 뛰어난 성능을 발휘한다는 것을 깨달았다.(영어)
The war on vibe coding – What belongs in the enterprise toolkit? : 바이브 토딩이 가벼운 데모나 실험에서는 훌륭하게 동작하고 작은 스타트업이라면 괜찮지만 규제를 받는 기존 기업에서는 AI 모델 자체보다 수많은 접근 제어, 승인 절차, 데이터 이력 관리 등 거버넌스와 운영사으이 제약을 뛰어넘는게 더 어려운 일이다. AI 네이티브 엔지니어링에서도 핵심은 속도가 아니라 반복 가능하고 통제된 배포에 있다. 그에 맞게 워크플로우를 재설계하여 초기부터 컴플라이언스와 보안을 참여시키고 시스템을 자동화해서 감독하에 AI의 성과를 낼 수 있게 되었다.(영어)
Your AI bill is out of control. Cloudflare can fix it now. : 회사에서 AI를 사용하면서 공용키를 많이 사용하기 때문에 전체 금액만 알수 있을 뿐 그 이상의 정보는 알기가 어려웠다. Cloudflare AI Gateway를 사용하면 게이트웨이를 통해서 AI를 사용하게 할 수 있는데 여기에 모델이나 프로바이더, 사용자나 팀 별 속성으로 지출 한도를 지정할 수 있고 사용자별로 사용량도 파악할 수 있게 되었다.(영어)
Building ClickCannon - a tool for benchmarking ClickHouse : ClickHouse에서 옵저버빌리티 워크로드의 벤치마크 도구인 ClickCannon을 오픈소스로 공개했다. ClickCannon을 이용해서 처리량을 제어하고 실제 사용자나 쿼리 패턴을 시뮬레이션해서 벤치마크 결과를 분석/비교할 수 있다.(영어)

보안 및 장애

Meta AI chatbot enabled hackers to access others' Instagram accounts : Meta가 지난 3월 AI 지원 챗봇을 통해 Facebook과 Instagram의 계정 관리를 지원하게 된 이후 해커들이 이용해서 특정 계정의 이메일 주소를 변경해 달라고 속여서 유명 Instagram 계정을 탈취했다. 현재 이 문제는 해결된 것으로 알려졌다.(영어)

볼만한 링크

The Intent Debt : Margaret-Anne Storey의 삼중 부채 모델에 따르면 기술적 부채, 인지적 부채, 의도 부채가 있다. 기술적 부채는 코드에 존재하고 인지적 부채는 사람안에 존재하고 의도 부채는 산출물에 존재한다. 의도 부채는 이 산출물이 왜 이런 모습이 되었는지에 대한 근거 등이 소실된 상태를 얘기한다. 이 세가지 부채중 의도 부채는 에이전트가 해결해 줄수 없는 영역이고 그동안은 사람의 머릿속에 의도가 있었기에 어느정도 의도 부채를 버틸수 있었는데 에이전트는 속도가 빠르고 의도가 없기 때문에 의도 부채는 더 빠르게 커지게 된다. 이를 해결하기 위해 의도에 대한 명세를 작성하고 결정할 때마다 그 내용을 기록해서 의도를 기록해야 한다.(영어)
Show Your Work : 과거 소프트웨어는 바이너리로 배포되었고 그 내용을 볼수 없었지만 오픈소스는 소스 코드를 공개해서 투명성을 제공했다. AI의 오픈 웨이트 모델은 바이너리로 제공하는 것과 똑같아서 그 안을 볼수 없다. 그래서 AI 모델이 데이터 출처부터 추적할 수 있게 공개하고 학습에 동의할 수 있는 프레임워크를 구축해서 편향이 생기지 않도록 삼사를 할 수 있어야 한다. 이러한 윤리를 지키려고 하는 회사는 그렇지 않은 회사보다 느리고 비용이 클것이므로 규제를 통해서 이를 따르도록 해야한다고 얘기한다.(영어)

IT 업계 뉴스

Anthropic confidentially submits draft S-1 to the SEC : Anthropic이 미국 증권거래위원회(SEC)에 기업 공개(IPO)를 위한 S-1 양식의 초안을 비공개로 제출했다.(영어)
SpaceX IPO : SpaceX가 기업 공개(IPO)를 위해 사이트를 열었다. 투자 설명서 IPO 관련 정보를 볼 수 있다.(영어)
VoidZero is Joining Cloudflare : Vue.js를 만든 Evan You가 Vite를 만들고 나서 자바스크립트 생태계의 통합 툴체인을 구축하기 위해 설립한 VoidZero가 Cloudflare에 인수되었다. VoidZero는 Vite, Vitest, Rolldown, Oxc를 만들었지만 오픈소스를 통한 수익화는 쉽지 않았고 Cloudflare를 통한 Vite 배포 플랫폼을 만들 던 중 인수되었다.(영어)
NVIDIA and Microsoft Reinvent Windows PCs for the Age of Personal AI : NVIDIA에서 개인용 에이전트 전용으로 설계된 RTX Spark 칩을 발표했고 Windows PC에 탑재될 예정이다.(영어)

프로젝트

Odysseus : 직접 운영할 수 있는 AI 워크스페이스로 채팅과 에이전트 등 다양한 작업을 한 곳에서 할 수 있다.
Velopack : 크로스 플랫폼 데스크톱 어플리케이션의 설치 및 자동 업데이트 프레임워크.
Magenta RealTime 2 : 로컬 라이브 뮤직 모델을 사용해서 악기를 연주할 수 있는 앱으로 Google이 공개했다.
kage : 헤드리스 Chrome으로 페이지에서 자바스크립트를 제거하고 똑같은 사이트를 만들어서 오프라인에서 실행할 수 있게 만들어준다.

버전 업데이트

Angular v22.0.0 : JavaScript 프레임워크, 릴리스 공지
Homebrew v6.0.0 : OS X 패키지 매니저, 릴리스 공지
Elixir v1.20.0 : 프로그래밍 언어, 릴리스 공지
Lynx v3.8 : 웹 기술로 Android, iOS, 웹 어플리케이션을 만들 수 있는 기술, 릴리스 공지
Grafana Tempo v3.0.0 : 분산 트레이싱 백엔드, 릴리스 공지
- 오브젝트 스토리지 비용을 절감할 수 있는 새로운 아키텍처 도입
- TraceQL 메트릭 정식 출시
Node.js v26.3.0 : 자바스크립트 런타임, 릴리스 공지
ClickHouse v26.5 : 컬럼형 데이터베이스, 릴리스 공지
Spring Vault v4.1 : 스프링 시크릿 관리, 릴리스 공지
Spring Modulith v2.1 : 모듈화된 스프링 부트 애플리케이션을 만들어주는 도구, 릴리스 공지
Spring HATEOAS v3.1 : Spring에서 HATEOAS를 따르는 REST API를 만들 수 있는 라이브러리, 릴리스 공지
Spring AI v2.0.0 : AI 엔지니어링을 위한 Spring의 어플리케이션 프레임워크, 릴리스 공지
Phoenix LiveView v1.2.0 : Phoenix 서버의 서버렌더링으로 웹 페이지를 만드는 기능, 릴리스 공지
Spring Tools v5.2.0 : Spring 코딩 환경을 위한 도구, 릴리스 공지
React Native v0.86.0 : React를 이용한 모바일 앱 개발 프레임워크, 릴리스 공지
FastAPI v0.137.0 : Python 웹 프레임워크, 릴리스 공지
Gukhanmun v0.2.0 : 국한문혼용체를 한국전용으로 바꿔주는 Rust/JavaScript 라이브러리, 릴리스 공지
Biome v2.5.0 : 프론트엔드 툴체인, 릴리스 공지

1Password SSH 에이전트로 로컬 SSH 키 안전하게 관리하기

2026-06-12T20:29:42+09:00

최근 몇 년 사이 보안에 관심이 많아졌다. 완벽한 보안이란 없지만, 여러 환경 중 의외로 보안이 취약한 곳은 로컬 환경이다. 아무래도 개인 장비라 외부 접근이 기본적으로 차단되는 데다가 자주 사용해서 편의성도 중요하다 보니 로컬에는 많은 시크릿이 평문으로 저장되어 있다.

로컬에서 관리되는 시크릿은 다양하지만, 그중 정말 중요하면서도 평문으로 관리되는 것 중 하나가 SSH 키다. 비밀키는 보안의 핵심이지만 현실에서는 평문으로 관리되고 있어서 개인 장비를 분실하거나 해킹당하면 쉽게 유출될 수 있다.

1Password SSH 에이전트 설정

1Password는 비밀번호를 관리해 주는 게 핵심 기능이지만 몇 년 전부터 개발자를 위한 기능을 강화하고 있다. SSH 에이전트 기능은 나온 지 수년이 되었지만 생각만 하다가 이제야 제대로 설정했다.

1Password의 개발자 메뉴에 들어가면 SSH 에이전트라는 메뉴가 보인다.

혹시 개발자 메뉴가 안 보인다면 설정에서 개발자 기능을 켜야 한다.

SSH 에이전트 설정을 누르면 다음과 같은 안내가 나온다.

설명을 완전히 이해는 못했지만 키 지문으로는 키를 구분하기 어려우므로 키 이름을 사용하기로 했다.

이는 ~/.ssh/config 설정인데, 해본 사람은 알겠지만 모든 SSH 호스트에 1Password SSH 에이전트를 사용하도록 하는 설정이다. 그래서 다른 호스트에서는 기존의 키 파일을 써야 한다면 호스트를 지정한 설정을 추가하면 된다.

SSH config에 설정을 넣으면 에이전트가 실행 중으로 바뀐다.

SSH 접속에 1Password SSH 에이전트 사용하기

먼저 SSH에 사용할 키를 등록해야 한다.

인식할 수 있는 이름을 주고 기존의 키를 드래그하면 된다.

1Password에서 바로 키를 생성할 수도 있는데 Ed25519와 RSA로 만들 수 있다. 특별한 이유가 없다면 지금은 Ed25519로 만들면 된다. 키 크기도 훨씬 작고 검증 속도도 훨씬 빠르다. 나 같은 경우는 기본으로 쓰던 키가 너무 오래되어서 그런지 지원하지 않는 형식이라고 나와서 이 기회에 새로 키를 생성했다.

생성된 키의 공개키와 지문도 바로 볼 수 있다. GitHub를 사용하는 경우 GitHub 계정의 SSH and GPG keys 설정에서 공개 키를 SSH Authentication Key로 등록하면 된다. 1Password에서 Git 커밋 서명에도 사용하라고 안내하는데, 나 같은 경우는 GPG로 서명하고 있어서 따로 설정하진 않았다. 간단히 설명하면 Authentication Key는 git clone이나 git pull 등 Git 저장소를 SSH로 접속할 때 쓰는 키이고 Signing Key는 커밋할 때 서명을 추가해서 해당 커밋을 본인이 했음을 증명할 때 사용하는 키다.

이제 터미널에서 Git 저장소에 접근하면 1Password 화면이 나오고, 여기서 인증하면 정상적으로 클론할 수 있다. 이렇게 구성하면 로컬에 비밀키를 평문으로 보관하지 않고서 안전하게 비밀키를 사용할 수 있다.

1Password 설정에서 키 승인에 대한 유효기간을 얼마나 유지할지 등을 설정할 수 있다.

북마크 관리

Git이 아니어도 서버 접속에 사용하는 SSH 키는 당연히 1Password에서 사용할 수 있다.

스크린샷에서는 해당 서버에 접속하는 화면을 보여줬지만, 앞서 ~/.ssh/config의 설정을 기억한다면 호스트를 *로만 설정했고 호스트별로 키를 식별하는 설정은 없었다는 것을 알 것이다. 실제로 어떤 기준인지는 모르지만 1Password에 등록한 SSH 키가 순서대로 하나씩 뜬다. 그래서 이름을 보고 해당 키가 아니면 거부하고, 사용할 키가 나오면 승인하면 된다. SSH의 구조 때문인지 키를 골라서 선택하는 게 아니라 이렇게만 동작한다. 이로 인해서 일반적으로 SSH 서버가 인증 시도를 6회로 제한하기 때문에 SSH 에이전트도 SSH 키가 6개 초과로 있으면 제대로 사용할 수 없는 문제가 생긴다.

그래서 한번 승인해서 사용하고 나면 아래처럼 활동 탭에서 그 기록을 볼 수 있다.

여기서 우측에 북마크 버튼이 있는데, 이걸 누르면 북마크로 저장된다.

이 북마크 저장해 두면 해당 호스트를 사용할 때는 1Password가 알아서 해당 키를 띄워주므로 자주 사용하는 키는 북마크로 등록해놔야 편하게 쓸 수 있다.

GitHub 멀티 계정을 사용하는 경우

앞에서 활동 탭을 보면 SSH 접속은 북마크 버튼이 있는데 Git 명령어에서는 북마크 버튼이 없는걸 볼 수 있다.

나는 업무용 GitHub과 개인용 GitHub을 따로 운영하고 있는데 경험상 이런 사람이 많지는 않지만 회사 사정 등 여러 이유로 내부 Git 저장소를 쓰는 등 여러 Git 호스팅 서비스에 인증을 해야 하는 경우가 있다. 여러 Git 호스팅을 쓰는 경우 ~/.gitconfig와 ~/.ssh/config 설정이 둘다 필요한데 여기서는 사실상 ~/.ssh/config만 관련있다.

 1# ~/.ssh/config
 2
 3# work account
 4Host company.github.com
 5  HostName github.com
 6  User git
 7  IdentityFile ~/.ssh/work-private-key
 8
 9# personal account
10Host github.com
11  HostName github.com
12  User git
13  IdentityFile ~/.ssh/personal-github-key

위 설정은 두 개의 키를 각 호스트에 쓰는 가장 일반적인 경우의 설정이다. 취향에 따라 약간씩 다를 수 있지만 기본 구조는 똑같다. SSH가 호스트만으로 구분할 수 있기 때문에 호스트를 이용해서 다른 키를 사용하게 하는데 호스트가 아예 다르면 오히려 편하지만 여기서는 둘다 GitHub인 예시이므로 company.github.com이라는건 임의로 만들어 낸 주소다. 그래서 둘 다 GitHub이지만 회사 저장소를 사용할 때는 git remote add에서 github.com 대신 company.github.com으로 등록하면 실제로는 github.com으로 연결되면서 다른 키를 사용하게 된다.

1Password도 이 방식을 이용해서 멀티 계정을 사용하는 방법을 안내하고 있다.

사용하는 키의 공개 키를 다운로드해서 ~/.ssh/ 아래에 저장한다.

 1# ~/.ssh/config
 2
 3Host *
 4  IdentityAgent "~/Library/Group Containers/2AAA333A2C.com.1password/t/agent.sock"
 5
 6# work account
 7Host company.github.com
 8  HostName github.com
 9  User git
10  IdentityFile ~/.ssh/company-github.pub
11  IdentitiesOnly yes
12
13# personal account
14Host github.com
15  HostName github.com
16  User git
17  IdentityFile ~/.ssh/personal-github.pub
18  IdentitiesOnly yes

그리고 위처럼 설정하면 공개키를 인식하고 해당키로 사용할 비밀키를 식별해서 정확히 원하는 키만 인증으로 뜨게 된다.

 1$ git clone git@github.com:outsideris/project.git
 2Cloning into 'project'...
 3remote: Enumerating objects: 199, done.
 4remote: Counting objects: 100% (199/199), done.
 5remote: Compressing objects: 100% (120/120), done.
 6remote: Total 199 (delta 87), reused 162 (delta 57), pack-reused 0 (from 0)
 7Receiving objects: 100% (199/199), 60.76 KiB | 467.00 KiB/s, done.
 8Resolving deltas: 100% (87/87), done.
 9
10$  git clone git@company.github.com:outsider-biz/test.git
11Cloning into 'test'...
12remote: Enumerating objects: 13, done.
13remote: Counting objects: 100% (13/13), done.
14remote: Compressing objects: 100% (6/6), done.
15remote: Total 13 (delta 1), reused 10 (delta 1), pack-reused 0 (from 0)
16Receiving objects: 100% (13/13), done.
17Resolving deltas: 100% (1/1), done.

호스트만 제대로 지정해주면 동시에 사용하는데 문제가 없다. 그리고 이는 1Password SSH 에이전트의 문제는 아니고 원래 SSH 키로만 사용할 때도 똑같다.

이로써 키가 유출될 걱정은 덜었고 새로운 장비를 사거나 할때도 키를 복사하는 과정이 필요했는데 이제는 1Password만 설치하면 바로 사용할 수 있게 되었다.

Claude Code로 만든 글 작성 도구

2026-06-06T18:47:28+09:00

오랫동안 사용하던 Textcube를 떠나 정적 사이트 기반 블로그로 마이그레이션하고 나서 글 마지막에 쓴 것처럼 글 작성 도구를 만들었다. 해당 글에서는 CMS라고 쓰긴 했지만 CMS까진 아닌 것 같아서 글 작성 도구라고 얘기하겠다.

AI를 사용한 글 작성 도구라고 하면 요즘 분위기에서는 AI가 글을 써준다고 생각할 수 있지만 이 블로그는 사람이 글을 쓴다. 내가 글을 써서 조회수를 늘리고 돈을 번다면 빠르게 자극적인(?) 글을 많이 쓰는 게 중요하겠지만 나한테 블로그는 내가 학습하는 과정이자, 생각을 정리하는 과정이기 때문에 항상 글은 직접 작성하려고 한다.

하지만 글을 작성하는 데 번거로운 반복 작업이 있어서 편하게 글을 쓸 수 있는 도구를 만들고 싶었다. 오랫동안 글을 많이 작성했기 때문에 내가 글을 작성하는 방식은 어느 정도 고착화된 편이다. 나는 글 쓰는 게 직업은 아니므로 블로그를 운영한 초기부터 어느 정도의 기준은 정한 편이다. 글을 읽기 좋게 쓰려고 노력하지만 퇴고에 너무 많은 힘을 들이진 않는다. 보통 Sublime Text를 사용해서 Markdown으로 글을 작성하고, 적당히 퇴고한 후 발행하는 편이다.

글 작성 도구

블로그도 이제는 정적 사이트라서 서버가 없다. 어차피 글은 나 혼자 쓰고 로컬 외의 환경에서 작성할 일도 없기 때문에 서버를 사용하되 로컬에서만 쓰는 목적으로 만들었다. 이렇게 하면 보안 등을 걱정할 필요도 없다.

간단히 정리하면 정적 사이트 기반 블로그는 글마다 Markdown 파일이 있고, 이를 빌드해서 HTML로 만든다. 글 작성 도구에서 글을 발행했을 때 Markdown 파일을 만들어 주면 배포 빌드와 자연스럽게 이어진다.

11. 새글 작성이 위주이지만 기존 글도 편집할 수 있어야 합니다.
22. 시작은 플레인 마크다운으로 시작하겠지만 곧 이어서 기능을 추가하면서 WYSIWYG-ish하게 바꿀 것입니다.
33. 글을 쓸때 주기적으로 자동 저장을 파일에 해야 합니다. 미리보기로 라이브로 갱신되어야 하는데 cmd/build는 15초나 걸려서 너무 오래 걸립니다. build는 모든 글에 대해서 하는 것이므로 이거 위에 글 작성도구에서는 새로 작성중인 글만 거의 실시간에 가깝게(레이턴시 수초 이내) 갱신되도록 되어야 합니다.
44. 파일 업로드도 필요한데 이는 일단 글쓰기 먼저 만들고 단계적으로 추가하겠습니다.

글 작성 도구이지만 종종 기존 글도 수정해야 하므로, 기존 글도 관리하면서 글 작성에 집중할 수 있는 도구를 만들려고 했다. 나는 Markdown으로 글을 작성하는 게 익숙해서 WYSIWYG 에디터는 오히려 거추장스럽고, 요즘 많은 글쓰기 도구가 그러듯이 마크다운을 쉽게 작성할 수 있게 해주는 정도만 원했다. 그리고 Sublime Text에서도 그랬듯이 텍스트 에디터에서 Markdown을 작성할 때 제일 불편한 건 이미지 업로드라서 이걸 해결하고 싶었다.

대충 요청했더니 대충 만들어줬는데 적당히 마음에 들었다.(물론 저 프롬프트 한 번에 이걸 만들어준 건 아니고 대충 과정을 설명하는 거다.) Markdown-ish하게 만들어달라고 했더니 에디터에서 가장 유명한 CodeMirror로 구현해줬는데 만족스럽게 꽤 잘 다뤄주었다. 기본 형태는 커서가 있는 문단만 Markdown으로 보여주고, 다른 부분은 렌더링해서 보여주는 방식이다.

어느 정도 기본적인 레이아웃이 잡히자 디자인을 잡고 싶었다. 디자인이 붙어야 또 감이 잘 오는 부분이 있고 구체화를 하기 좋을 것 같았다.

Claude Design을 설치하고 시안을 요청했더니 4가지를 만들어주었다.

나중에 이런저런 개선을 하다 보니 또 고민되긴 했지만, 시안에서는 네 번째인 Mono가 마음에 들어서 이를 그대로 사용했다. 시안을 보여주려고 바로 웹페이지를 만들어 쉽게 비교까지 할 수 있게 하는 건 정말 잘한다.

왼쪽은 글을 작성하는 에디터이지만 오른쪽에는 렌더링된 프리뷰를 볼 수 있게 구성했다. Markdown이 충분히 직관적이라 보통 프리뷰를 띄워두고 글을 쓰진 않는다. 하지만 렌더링 특성 때문에 화면이 깨지거나 실수로 마크다운 문법을 깨뜨리는 경우도 있어서, 도구를 만드는 김에 우측에서 바로 렌더링된 결과를 프리뷰로 볼 수 있게 구성했다. 물론 에디터 자체도 Markdown-ish하므로 렌더링된 스타일에 최대한 가깝게 만들었다.

대부분의 Markdown 에디터처럼 코드 블록을 위한 ``` 를 입력하면 코드 블록이 생기도록 만들었다. 제품으로 나온 서비스에 비하면 처리가 좀 투박하지만 적당히 내가 쓰기에 불편하지 않은 정도로 구현했다. 글은 드래프트 상태로 여러 글을 작성할 수 있고 발행을 누르면 해당 위치로 폴더와 에셋을 옮기고 글번호가 최신+1로 할당되도록 만들었다. 기본적으로 파일 시스템에 데이터를 모두 쓰기 때문에 별도 DB는 필요 없고, 작성한 글이 없어지지 않게 자동 저장되도록 만들었다.

파일 업로드

앞에서도 말했듯이 텍스트 에디터로 Markdown을 작성하는 건 아무런 불편함이 없지만 파일 업로드는 항상 수동으로 해야 했다.

보통은 글을 쓰면서 이미지가 들어갈 위치에 파일명을 표시해두었다가 Textcube에 글을 올리면서 파일첨부로 해당 부분을 일일이 교체했다. 그리고 블로그에 적절한 사이즈와 이미지 최적화를 위해 그래픽 에디터로 일일이 수정해줘야 했다.

도구를 만드는 김에 이러한 과정을 모두 개선하고 싶었다. 그래서 에디터에 이미지 파일만 드래그 앤드 드롭하면 바로 마크다운 문법으로 삽입해주고, 빌드할 때 사용할 수 있도록 파일 복사도 바로 해줄 수 있게 만들었다. 예전에는 그래픽 에디터로 크롭도 하고 수정도 하고 그랬지만 요즘은 스크린샷 도구들이 좋아서 간편하게 이미지를 만들 수 있으므로 드래그앤드롭으로 충분했다.

이제 모니터가 너무 좋아져서 device pixel ratio(DPR)이 맞지 않으면 이미지가 너무 뿌옇게 보이기 때문에 언젠가부터는 3x 이미지로 이미지를 첨부하고 있다. HTML에는 srcset을 지원하지만 Textcube에는 이런 기능이 없었기 때문에 그냥 3x 이미지로 합의봤지만 모바일 등 화면이 작은 곳에서는 네트워크가 낭비되긴 한다.

파일 업로드를 구현하는 김에 srcset도 지원하고 싶었고, 이미지만 던지면 본문의 width에 맞게 계산해서 1x, 2x, 3x 이미지를 만들고 srcset으로 빌드되도록 만들었다. 이것만으로도 너무 편하게 느껴졌다. 그래도 이미지 계산이 하드코딩된 값이 아니라 현재 디자인의 본문 width를 따르도록 지시했다. 나중에는 AI가 더 좋아질 테니 굳이 안 그래도 될 것 같지만, 그래도 신경 쓰여서 그렇게 만들게 했다.

Assist 사이드바

도구를 만들기 시작했으니 반복 작업은 최대한 자동화하고 싶었다. 당시에는 한달에 두번씩 올리는 뉴스레터를 작성하고 있었기에 Textcube에도 있던 템플릿 기능에서 아이디어를 가져와서 글의 패턴이 있는 글을 관리하도록 만들었다.

뉴스레터를 선택하는 경우 마지막 뉴스레터를 참고해서 번호를 올려주고 내가 뉴스레터를 올리는 날짜는 정해져있으므로 그 날짜에 맞춰서 제목도 자동으로 만들어주도록 구성했다.

뉴스레터를 AI로 자동화하기 좋을 거라는 얘기도 많이 들었지만, 뉴스레터도 발행이 목적이라기보다 내가 글을 읽는 게 목적이라서 뉴스레터 자체는 직접 작성하고 반복 작업을 하나씩 구현했다.

버전 업데이트 찾기

뉴스레터에는 내가 관심가지는 프로젝트의 최신 릴리즈를 올리는 부분이 있는데 별거 아닌 작업이지만 해당 라인의 형식이나 기존 설명을 찾아오는 과정이 번거로운 과정이었다. 예를 들어 Angular의 새버전이 나오면 이전 뉴스레터들을 검색해서 Angular 릴리스 글을 찾아서 이를 가져다가 붙여놓고 버전만 링크만 올려서 작성하곤 했다.

이 부분을 간편하게 처리하려고 프로젝트 이름이나 새로운 릴리스 링크를 올리고, 팝업 메뉴로 버전 업데이트를 선택할 수 있게 했다. 대부분은 기존에 올린 프로젝트를 다시 올리는 경우다. 글 쓰는 중에 키보드에서 손을 떼고 싶지 않아서 단축키도 구현했다.

이전 뉴스레터를 뒤져서 같은 프로젝트라고 판단한 버전 업데이트의 목록을 가져오게 했다. 여러개 가져오게 한 것은 프로젝트 이름이나 링크 등으로 완벽하게 찾아내지 못하기 때문에 내가 선택하게 했다. 원하는 것을 선택하면 이를 가져와서 분석한다.

그동안 운영해 보니 링크가 제대로 연결되지 않거나 공식 프로젝트 링크가 바뀌는 경우가 있었는데, 이 부분도 일일이 체크하기 귀찮아서 자동으로 처리하게 했다.

LLM 사용하기

아까 어시스트 사이드바 상단에서도 나왔지만 AI 모델을 선택할 수 있게 구성했다. 꼭 이렇게 할 필요까지는 없지만 처음 만들어 보면서 어떤 모델이 더 잘 해주는지 비교하고 싶었기 때문에 내가 구독 플랜을 가지고 있는 Gemini, Claude, Codex를 선택하고 모델이나 Effort를 선택할 수 있게 했다. 이후 글을 쓰면서 어떤 모델이 적당한지를 비교해보고자 했고 디버깅 목적으로 대화모드도 추가하고 걸린 시간이나 비용도 보이게 했다. 이게 서비스 목적이 아니라 내 로컬에서만 사용하는거라서 로컬에 CLI가 다 설치되어 있다는 전제하에 로컬 CLI를 사용하게 했는데 잘 동작해서 만족하고 있다.

링크 자동으로 걸기

Assist 사이드바에는 여러 가지 기능을 넣었는데, 웹의 핵심 중 하나는 링크라고 생각해서 가능한 한 링크를 많이 거는 편이다. 하지만 글을 쓰다 보면 특정 회사나 기술 등을 언급할 때가 많은데, 이를 일일이 검색하고 링크를 찾아 거는 건 번거로워서 잘 안 하게 됐다.

그래서 단어를 적고 링크 연결하기 메뉴만 누르면 자동으로 이전 글에서 해당 링크를 찾거나 공식 링크를 찾도록 만들었다. 완전 자동화하기 보다는 내가 한번 확인하고 삽입하도록 만들었고 아까 말한대로 링크는 바뀌는 경우도 많으므로 리다이렉트도 확인하도록 했다. 이전 글에 있는 링크는 잘 찾지만 그렇지 않으면 공식 링크를 잘 못찾는 경우도 많아서 개선은 필요하지만 시간이 지나면서 링크를 더 많이 쌓아가면 쉽게 해결될 문제라고 생각한다. 링크를 확인하고 싶을때도 있어서 macOS의 터미널처럼 에디터에서도 cmd + 클릭으로 링크를 열 수 있게 했다.

같은 글에서는 같은 기술이나 회사 등을 언급할 확률이 높기 때문에 한 번 링크를 걸면 이후에 같은 단어를 작성할 때 자동으로 링크가 걸리도록 했다. 평소에는 귀찮아서 첫 단어에만 한번만 골곤 했는데 쉽게 처리할 수 있게 되었다.

이미지 대체 텍스트 생성

추가로 Assist 사이드바를 만든 김에 파일 업로드를 하면 자동으로 이미지를 분석해서 대체 텍스트도 넣어주도록 만들었다. 이미지의 대체 텍스트도 중요하게 생각하므로 예전에는 최대한 이미지 첨부할 때마다 대체 텍스트를 작성했지만 생각보다 잘 작성하기 어렵기도 하고 귀찮아서 언젠가부터는 잘 작성하지 않았기 때문에 이미지만 올리면 자동으로 분석해서 넣어주도록 만들었다. 이런건 정말 AI의 큰 혜택인거 같다.

메타데이터 관리

블로그 글에는 카테고리, 발행 시간, 태그 등 메타데이터 관리가 필요하기 때문에 이러한 데이터가 저장되는 Frontmatter를 관리할 수 있도록 상단에 구성했다.

많은 글쓰기 도구에서 내가 글에 대한 통계 정보를 넣었다. 엄청 유용하진 않아도 내가 이런 기능을 좋아한다. 글자 수, 단어 수, 문장 수 등을 넣었다. 대부분의 글쓰기 도구가 영어권 도구라 통계가 한국어에서는 어색한 경우가 많은데, 이것도 Claude와 대화하면서 한국어에 적절한 값을 논의했다. 이 글이 어느 정도 분량이고 읽는 데 얼마나 걸리는지, 읽는 난이도는 어떤지 등을 통계로 정리해서 보여주도록 했다. 이게 엄청난 도움까지는 아니어도 공간도 남고 글을 쓰면서 어느정도 분량의 글을 쓰고 있는지 파악하는 용도로 사용한다.

또한, 에디터는 Markdown-ish하게 만들었지만 가끔은 Raw 마크다운이 필요하기 때문에 Raw로 볼 수 있는 기능도 만들어 두었다.

Code 블록 사용 가이드

코드 블록에는 언어를 지정하는 기능과 시작 줄 번호를 지정하는 기능이 있다. 자주 안쓰는 언어나 줄번호 기능은 가끔 사용하려고 할때 헷갈리는 경우가 있어서 코드블록에서 메뉴를 누르면 바로 사용방법을 볼 수 있게 만들었다. 첨엔 리스트만 보여달라고 했는데 알아서 검색도 되게 만들어주어서 좋았다.

Revise 사이드바

보통 글을 다 쓰고 나면 퇴고를 세밀하게 하진 않고 적당히 검토한 후에 한국어 맞춤법 검사기를 돌리는 편이다. 내 글이 좀 장황한 경향도 있고 문장도 깔끔하진 않지만 퇴고에 너무 많은 시간을 쓰고 싶진 않았다. 맞춤법 검사기도 오타 등은 수정하기 위해 하고 있지만 Markdown으로 글을 쓰다 보니 맞춤법 검사 돌릴때도 마크다운 문법도 같이 들어가서 귀찮기도 했다.

Revise 사이드바는 퇴고 과정으로 AI로 자동화하기 위해 만들었다.

LLM을 이용해서 맞춤법 검사를 해주도록 했고 가이드라인 파일은 Markdown으로 따로 만들어서 이후 필요한 규칙은 추가할 생각이다. 꽤 잘 잡아주긴 하는데 다 잡아주는건 아니라서 당분간은 맞춤법 검사와 같이 비교해 볼 생각이다.

검사할 때는 Markdown 문법을 무시하도록 했고, 어디를 고치는지 바로 파악할 수 있게 했다. 맞춤법뿐 아니라 표현도 더 간결하고 깔끔하게 교정하도록 했다.

교정된 내용을 적용할 때 앞뒤의 맥락을 같이 봐야하는 경우가 있어서 해당 영역을 선택하면 에디터에서 해당 위치로 바로 가게 만들어서 쉽게 교정 사항을 적용할 수 있게 했다.

맞춤법이나 표현을 문장단위로 개선한거 외에도 글에 대한 평가도 하도록 했다. 그동안은 시간 관계상 포기했던 부분이지만 AI의 도움을 받아서 계속 피드백 받으면서 개선하다보면 글을 더 잘 쓸 수 있는데 도움이 될것으로 기대하고 총평도 계속 개선할 수 있도록 가이드 파일을 별도로 분리했다.

OpenGraph 사이드바

블로그를 정적 사이트로 바꾸면서 기존에 방치했던 OpenGraph 이미지를 개선했다. 이미 배경화면서 제목과 글의 도입부로 이전보다는 훨씬 나아졌지만 글 작성 도구가 생긴만큼 더 개선할 수 있겠다는 생각이 들었다. 최근 글을 발행했을 때 오픈 그래프 카드가 맘에 들지 않은 경우가 생겨서 프리뷰 역할도 할 겸 사이드바를 만들었다.

오픈그래프에 글의 도입부가 나오는 건 큰 의미는 없는거 같아서 OpenGraph 사이드바에서 LLM으로 글을 요약해서 정리해서 카드 영역에 맞게 추가하도록 했다. 여기도 가이드 파일을 분리해두었지만 요약이 맘에 들지 않을수도 있어서 수동으로 수정해서 적용할 수 있는 기능도 만들었다.

여기서 생성한 OpenGraph의 본문은 Frontmatter에 추가해 두어서 나중에 정적 사이트 빌드시에 이 내용으로 OpenGraph 이미지를 생성할 수 있도록 만들었다.

Electron 앱

블로그를 새로 만들면서 Golang으로 만들었고 프로덕션용 빌드를 하지 않아도 개발에 사용하도록 개발 서버를 만들어서 사용하고 있었다. 안그러면 기능 추가할때마다 빌드해야 한다. 그래서 이 서버에 특정 경로로 접속하면 글 작성 도구가 뜨도록 만들고 있었고 어디에 배포할 게 아니라 로컬에서만 사용하니까 문제도 없었다.

기능을 구현하다보니 서버로 띄워서 웹브라우저에서 사용하는게 아니라 별도의 앱으로 있으면 좋겠다는 생각이 들었다. 만드는 중에는 큰 상관없었지만 글 작성 관점으로 보면 글쓰려고 서버를 띄우고 접속하는게 번거롭게 느껴졌고 글 쓰면서 웹 브라우저에서 검색하는 경우가 많다보니 작성도구도 브라우저에 있는게 좀 불편했다. 모니터에서 옆에 브라우저 열어두고 글 쓰기 도구를 따로 열어두는게 글쓰기가 훨씬 편했다.

어차피 웹으로 만든거라서 Electron으로 패키징하면 어렵지 않겠다고 생각했는데 Claude는 이미 Golang을 쓰고 있으니 훨씬 가벼운 webview_go를 사용하면 Go 바이너리 하나로 가볍게 만들수 있다고 추천했다.

처음 봤지만 추천대로 일단 webview_go로 만들었다. 그냥 패키징하는것이니 앱은 금방 나오긴 했는데 이게 Chrome에서 개발하다가 웹뷰가 되어서 그런지 세부 기능이 동작 하지 않는게 계속 발견됐다. 하나씩 수정을 요청하다가 이미 다 구현하고 고쳤던 기능을 다시 수정하는걸 반복하다 보니 짜증이나서 Electron을 재 검토하게 했다.

 1핵심을 정확히 짚으셨습니다. 솔직하게 답하면 — 네, Electron(또는 Chrome)으로 가면 이 부류의 문제가 사라집니다. 그리고 처음에 제가 webview_go 를 추천한 판단을 정정해야겠습니다.
 2
 3근본 원인은 "엔진 차이"입니다
 4지금 겪는 문제(한글 IME popup 단축키, keydown/beforeinput/composition 순서)는 전부 WKWebView = WebKit(Safari 엔진) 이 개발용 Chrome = Blink(Chromium 엔진) 와 다르게 동작하기 때문입니다. 그래서:
 5- 브라우저에서 이미 해결한 게 WebKit 에서 재발하고,
 6- 앞으로 기능 바꿀 때마다 Blink + WebKit 둘 다 맞춰야 합니다.
 7
 8이 프로젝트는 CodeMirror + 한글 IME + 정교한 키 이벤트 로직이 많아서, 엔진 차이가 계속 물립니다. 제가 "가벼움 + 프레임워크 무의존"을 우선해 webview_go 를 추천했는데, 실측해 보니 이 코드베이스에선 엔진 일치가 그 이점보다 훨씬 중요했습니다. 사용자 판단이 맞습니다.
 9
10Electron / Chrome 으로 가면
11둘 다 Chromium 엔진이라 — 개발 Chrome 에서 되면 앱에서도 똑같이 됩니다. e2e(Playwright Chromium)도 앱 동작과 일치합니다. "이미 해결한 문제 재발" + "이중 유지보수" 가 동시에 해소됩니다. 메뉴·클립보드·IME 같은 데스크톱 통합도 이미 성숙하게 처리됩니다.
12
13> 한 가지 정정: Electron 은 시스템 Chrome 을 쓰는 게 아니라 자체 Chromium 을 번들(~150MB)합니다. "내 PC 에 크롬이 있어서" 를 그대로 살리는 건 Chrome --app 런처 방식입니다 — 둘 다 Chromium 엔진이라 엔진 차이 문제는 똑같이 없습니다.
14
15전환 비용은 작습니다 (핵심 자산 재사용)
16지금까지 만든 것 중 버리는 건 webview 껍데기(cmd/app 의 webview/메뉴/재실행)뿐입니다:

설계 문서에 의존성 최소화하고 가볍게 만들겠다고 해서 그런지 이번에는 chrome --app으로 실행하는 방식을 추천했다. 이 방법도 직접 해본적은 없지만 Chrome과는 별도로 실행되기 원했기 때문에 그냥 Electron으로 만들도록 시켰다.

서버로 실행할 때는 워킹 디렉토리가 정해지지만 앱으로 띄우는 경우에는 컨텐츠가 있는 프로젝트 폴더를 지정해야만 사용할 수 있으므로 설정 기능을 넣어서 워킹 디렉토리를 지정할 수 있게 했다.

앱으로 설치하고 글을 쓰고 싶을 때 앱만 실행하면 서버도 자동으로 실행되니까 글쓰기가 훨씬 좋아졌다. 기존 브라우저에서 접속하는 방식도 기능 개발을 할때는 편하므로 그대로 남겨두었다.

블로그의 메인 배경 이미지를 이용해서 앱 아이콘을 만들었다. 아이콘은 처음에는 너무 맘대로 그려버려서 이미지 존중하라고 했더니만 적당한 시안 중에서 골랐다. 앱 이름은 따로 알려주지 않았는데도 적당히 잘 지어주어서 그대로 사용했다.

에필로그

개인적으로 사이드 프로젝트를 안한지가 꽤 오래되었는데 퇴근하고 와서 뭔가 계속 만드니까 기분이 꽤 괜찮다. 블로그도 오랜만에 손대는 거라 할게 많지만 또 뭔가 계속 만들기 시작하니까 다른 아이디어도 조금씩 다시 생겨나고 있다. 은근히 AI로 사이드 프로젝트하는거에 재미를 붙여하고 있는 느낌이라 좋다.

코딩 에이전트로 개발하면서 내 성향을 더 깨닫게 됐는데, 코딩 에이전트가 혼자서 진도를 나가기보다는 세부 사항을 내가 다 제어하기를 더 선호한다는 것을 느꼈다. 글 작성 도구에서는 내 원하는 요구사항이 꽤 명확해서 그럴수도 있지만 조금씩 진도를 나가면서 LLM과 의논도 하고 LLM 준내용 확인하고 찾아도 보면서 계속 발전시켜나가는 게 훨씬 더 좋았다.(자리에 없을 때 일 시키는건 더 연구해 봐야겠다.)

그러다 보니 속도가 빠르진 않아서 5월 중순부터 작업을 시작해서 3주 정도 걸려서 사용할 수 있을 정도로 만들었다. 실제로 써봐야 알게 되는 게 있어서 최근 2개의 글을 작성 도구로 글을 써보면서 느껴지는 불편함을 개선했다.

Models	Input	Output	Cache Create	Cache Read	Total Tokens	Cost (USD)
opus-4-7 opus-4-8	626,115	5,542,264	27,030,261	2,624,332,639	2,657,531,279	$1,724.16

저번보다는 많이 사용했다. 지금 Claude Max 5x 요금제를 사용하고 있는데 토큰을 다 쓰기가 쉽지 않아서 진짜 많이 사용하는 사람은 어떻게 사용하는지 궁금해졌다. 토큰이 남아서 사실 맘놓고 쓰고 있는 상황이다.

블로그도 정적 사이트로 바꾸고 글 작성 도구까지 만들고 나니 아주 만족스럽다.

GitHub은 금을 캐는 대신 청바지를 팔아야 한다

2026-06-01T00:51:30+09:00

그동안 내 블로그를 본 사람은 알 수도 있겠지만 나는 GitHub을 좋아한다. 내 커리어 내내 GitHub은 내 로망과도 같았고, GitHub의 제품 역량이 놀라워서 그 어떤 빅테크보다도 GitHub에서 일하는 순간을 꿈꿨다. GitHub 직원만 만나도 반가웠다. 우리 집에는 GitHub SWAG만 모아 놓은 공간이 있을 정도이고, 딱히 하는 건 없지만 GitHub Stars가 되었을 때는 너무 기뻤다.

2018년 GitHub이 Microsoft에 인수되었을 때 수많은 사람이 GitHub의 미래를 걱정했고, 나도 마찬가지로 걱정하며 GitHub이 상장해서 자립하지 않은 게 아쉬웠다.

2021년 GitHub이 Copilot을 처음 출시했을 때 너무 충격이었다. 탭만 누르면 코드가 자동으로 완성되는 게 내가 뭘 하려고 하는지 누군가 보는 것 같았고, 너무 신기했다. 이 Copilot은 GPT-3 시절 자연어를 코드로 만들어 주던 Codex 모델에 기반을 두고 있었다. 이때 Codex는 모델 이름이었고, 지금은 코딩 에이전트의 브랜드명이 되었다. Microsoft와 OpenAI의 파트너십이 강력했기 때문에 가능한 일이라고 생각해서, 한때는 GitHub이 인수된 게 아쉬웠지만 결과적으로는 좋은 결과로 이어졌다고 생각했다. 당시에는 그만큼 GitHub Copilot이 압도적이었고, AI를 잘 모르던 나로서는 GitHub이 인수되지 않았다면 Codex 같은 모델을 만들지 못했을 거라고 생각했다.

그러고 몇 년이 흐르면서 AI가 크게 발전하고 코딩의 양상도 달라졌다. 모두가 알다시피 Vibe Coding이라는 용어가 등장하고 그 이후 1년 만에 엄청나게 발전하면서, 자연어만으로 웬만한 프로그램을 만들 수 있는 시대가 되었다. 그리고 그 선두에는 Anthropic의 Claude Code와 OpenAI의 Codex, Google의 Gemini와 Antigravity가 있다.(그동안 Google은 Gemini를 밀었지만 최근에는 코딩 에이전트 쪽은 Antigravity로 통합하는 분위기이다.) 셋 중에는 Google이 밀리는 느낌이 강하긴 하지만 이 삼파전이 진행되고 있고 좀 다른 시장으로 Cursor와 opencode, pi같은 코딩 에이전트들이 있다. 이런 코딩 에이전트들의 미래를 작년 여름만 해도 나는 어둡게 보았지만, 각자 매력을 강화하면서 아직까지 자기 위치를 잘 지키고 있다.

GitHub의 금광 캐기

GitHub Copilot이 등장했던 시기에는 역시 GitHub이라는 느낌을 주며 압도적이었지만 몇 년 만에 시장은 달라졌다. 냉정히 말하면 GitHub Copilot은 1티어에서 2티어로 내려와 자체 모델이 없는 Cursor, opencode, pi와 경쟁하는 제품이 되었다.

모두가 주변을 통해 세상을 볼 수밖에 없어서 시장 점유율은 정확히 알기 어렵지만, 내 주위에 GitHub Copilot을 쓰는 사람은 그리 많지 않다. 아무래도 주류는 모델을 가진 Claude Code, Codex, Antigravity가 차지하는 분위기다. 물론 Microsoft와 OpenAI의 파트너십이 몇 년 전처럼 강력하지 않은 이유도 있을 거라고 생각한다.

내 주위에선 별로 사용하지 않는다고 얘기했지만, 아직 GitHub의 위치가 있기 때문에 GitHub Copilot도 전체로 보면 어느 정도 사용되고 있다고 생각한다. 다른 2티어 코딩 에이전트들이 자신만의 자리를 찾아가듯 GitHub Copilot도 그럴 수 있다고 생각한다. 코딩 에이전트는 어쨌든 지금 코딩 분야에서 가장 치열하게 경쟁하는 곳이고 앞으로 어떻게 달라질지 예측하기 어려울 정도로 빠르게 변화하고 있기 때문에 이 분야를 그냥 표기하기는 힘들고 또 누가 가장 앞서 나갈지도 쉽게 알 수 없는 상황이라고 생각한다. 시장을 예전처럼 주도하지 못하는 건 아쉽지만 계속 도전할 필요는 있는 시장이라고 본다.

하지만 청바지를 파는 일에 충실했으면 좋겠다

회사의 미래를 위해 도전하는 것은 당연히 해야 할 일이지만, GitHub에는 소셜 코딩 혹은 코드 호스팅으로 십수 년간 굳건히 다져 온 위치가 있다.

지금은 그렇지 않지만, GitHub은 소셜 코딩을 표방하면서 지금의 위치까지 올라왔다. 2024년 GitHub Universe 키노트에서 10억 명의 개발자를 목표로 한다고 얘기했을 때, 당시 GitHub의 사용자는 1억 명 정도였기 때문에 "10억이면 거의 모든 사람이 개발자여야 하는 거 아냐?" 같은 생각에 뜬구름 잡는 얘기처럼 들렸다. 하지만 2년도 채 지나지 않은 지금은 그게 현실이 되었다.

GitHub이 이 미래를 얼마나 예측했는지 모르겠지만 그들이 얘기했던 전 인류가 개발자가 되는 세상이 열리기 시작했다. 진짜 직군 상관없이 모두가 코딩하는 시대가 열리기 시작했고 자연히 그 코드를 호스팅할 곳으로 1번은 GitHub일 수밖에 없다.

요즘 뉴스에서 Claude에 보안 기능이 추가되면 보안 회사들 주가가 떨어지고 Claude에 디자인 기능이 추가되면 Figma 같은 디자인 관련 회사의 주가가 떨어진다는 뉴스가 쏟아진다. 그럼에도 GitHub은 주식회사가 아니라 주가는 없긴 하지만, GitHub이 더 이상 필요 없다거나 AI가 GitHub을 대체한다거나 하는 분위기는 전혀 없다. 오히려 GitHub의 위치는 더욱 굳건해질 수 밖에 없는 분위기로 가고 있다.

하지만 분위기와 상관없이 GitHub이 그 위치를 잃어가고 있다. HashiCorp의 공동 창업자인 Mitchell Hashimoto가 장애가 너무 많아서 GitHub을 떠나겠다고 공식적으로 말했고, 장애가 너무 나니까 GitHub이 장애 없이 며칠 지났는지 기록하는 서비스도 생겼다. 작년 GitHub의 보고서인 Octoverse 2025를 봐도 작년에만 3,600만 명이 가입해서 GitHub 역사상 가장 빠른 성장률을 보이면서 1억 8천만 명이 GitHub을 이용하고 있다고 나오는데 올해는 아마 더 빠른 성장률을 보이지 않을까 싶다.

빠르게 성장하는 서비스는 장애는 피할 수 없긴 하지만 안타깝게도 실제로 장애가 많이 발생하긴 하고 있다. Microsoft는 GitHub을 인수하고 공동 창업자들 대신 CEO로 세웠던 Nat Friedman까지는 기존 GitHub의 분위기를 유지했고, 개인적으로는 Thomas Dohmake가 CEO가 되는 시점부터 GitHub이 Microsoft의 분위기가 조금씩 나기 시작했고 작년 8월 Thomas Dohmke가 창업하러 퇴사한 이후 GitHub은 CEO 자리가 공백 상태에 있다. 그 영향인지 뭐 때문인지 모르지만, 그냥 외부에서 보기에는 GitHub이 지금 GitHub Copilot의 초기 위치를 놓친 뒤에 방향을 제대로 잡지 못하고 있는 게 아닌가 걱정된다.

예전에 주변 사람들이랑 스타트업에서 보통 말하는 피봇(Pivot)을 얘기하면서 피봇은 중심 발이 단단하게 유지되어야 의미 있다는 얘기를 한 적이 있다.

코딩 에이전트라는 새로운 변화에 대해 확장하려고 해도 피봇처럼 중심축이 더 중요한데 GitHub에게 그 중심축은 코드 호스팅을 하고 개발자들이 협업할 수 있는 공간이라는 생각이 든다. 이 중심축이 흔들린다면 피봇도 의미 없어질 수 있다.

앞에서 말한 대로 코딩 에이전트에 도전하는 것도 중요하지만, GitHub이 지금까지 잘해 온 부분도 여전히 중요하기 때문에 이 부분을 코딩 에이전트 시대에 맞게 개선하는 일을 소홀히 하지 않았으면 좋겠다. 서비스를 안정화하고 코딩 에이전트가 접근하기 쉽게 개선하고 코드 diff도 보기 쉽게 만들고 코드 리뷰도 AI의 도움을 받아서 더 잘할 수 있도록 개선하는 등 여전히 할 수 있는 부분이 너무 많다고 생각한다. 제대로 써본 적은 없지만 GitHub의 대안으로 언급되는 서비스는 아직 완성도 면에서 GitHub을 따라잡기는 많이 부족하게 느껴지지만 또 빨라진 변화를 생각하면 주도권을 놓치는 건 한순간일지도 모른다는 생각한다.

워낙 좋아하던 서비스이기에 GitHub이 코드 협업 서비스로의 위치를 잘 지키고 앞으로도 잘했으면 좋겠다.

기술 뉴스 #295 : 2026-06-01

2026-06-01T00:51:30+09:00

웹개발 관련

CSS vs. JavaScript : 애니메이션을 CSS와 JavaScript로 구현했을 때의 차이점을 데모로 보여준다. 공이 움직이는 간단한 애니메이션은 실제 성능 차이가 거의 없다. 다만 자바스크립트는 메인 스레드에서 실행되므로, 메인 스레드가 바쁘면 자바스크립트 애니메이션 동작이 멈춘다. Motion이나 GSAP 같은 라이브러리와 비교하면, Motion은 Web Animations API를 사용하므로 메인 스레드의 영향을 받지 않지만 GSAP는 영향받는다.(영어)
Announcing lynx-ui : ByteDance가 웹 기반 기술로 모바일 앱도 만들 수 있는 Lynx 기반 ReactLynx의 UI 라이브러리 lynx-ui를 공개했다.(영어)
ECMAScript Explicit Resource Management - Stage 4 : 파일이나 디비 연결처럼 명시적으로 닫아야 하는 리소스를 안전하게 정리할 수 있도록 using 키워드를 도입하는 제안이 ECMAScript Stage 4에 도달했다.(영어)
HTML-in-Canvas API 오리진 트라이얼 소개 : HTML-in-Canvas API가 Chrome 148~150에서 실험적으로 사용할 수 있다. HTML-in-Canvas API는 2D·3D 그래픽을 처리하는 Canvas 안에 웹의 기본 요소인 DOM을 배치하는 브리지다. 덕분에 Canvas 내에서도 HTML의 장점을 그대로 이용할 수 있다.(한국어)
에이전트 1.0용 Chrome DevTools로 AI 코딩 워크플로 간소화 : Chrome DevTools를 에이전트가 접근할 수 있도록 하는 Chrome DevTools for agents의 1.0 안정 버전이 출시되었고 MCP, CLI, 에이전트 스킬을 제공해서 코딩에이전트에서 쉽게 자동화할 수 있다.(영어)
Lighthouse 에이전트형 브라우징 점수 : Lighthouse에 사이트가 에이전트와 상호작용을 하기에 얼마나 잘 구성되어 있는지 평가하는 점수가 추가되었다.(한국어)
Announcing Web Serial Support in Firefox : Firefox 151에서 마이크로 컨트롤러, 개발보드, 3D 프린터 등 Serial로 연결된 하드웨어와 통신할 수 있는 Web Serial API를 지원한다.(영어)

그 밖의 개발 관련

Modern Java at Stripe: Language upgrades as a service : Stripe에서 JDK 버전을 업그레이드할 때마다 따르는 번거로운 수동 작업을 개선하기 위해 AutoJDK를 만들었다. AutoJDK를 실행하면 빌드 그래프를 분석해 업그레이드 가능 여부를 판단하고, 범위가 명확해 검토하기 쉬운 Pull Request를 생성하며, 해결해야 할 남은 문제를 파악해 알려준다. 도입 후 이른 시간 안에 JDK 17 도입률이 93%가 넘어 가장 보편적인 버전이 되었고 Java 8을 완전히 제거하고 대부분의 Java 11을 제거할 수 있게 되었다.(영어)
Introducing dynamic workflows : Claude Code에 단일 세션 내에서 수십, 수백 개의 서브 에이전트를 병렬로 실행하는 오케스트레이션을 통해 복잡한 작업을 수행할 수 있는 다이나믹 워크플로우가 추가되었다.(영어)
An important update: Transitioning Gemini CLI to Antigravity CLI : Google이 그동안 Gemini의 터미널용 코딩 에이전트로 Gemini CLI를 제공하고 있었지만 이제 요구사항이 달라져서 다수의 에이전트가 필요하기에 터미널 도구를 워크플로우의 다른 부분과 통합해서 사용해야 하게 되었다. 이를 단일 플랫폼으로 제공하기 위해 Antigravity로 통합하고 Antigravity CLI로 대체할 것이므로 Gemini CLI와 Gemini Code Assist IDE 확장은 6월 18일부터 무료 요청이 중단된다.(영어)
Composer 2.5 소개 : Cursor에서 자체 코딩 모델인 Composer 2.5를 출시했다. Composer 2.5는 2보다 지능과 동작이 크게 향상되어 장기간 작업을 꾸준히 실행할 수 있게 되었고 2.5도 2와 똑같이 Moonshot의 Kimi K2.5를 기반으로 한다.(한국어)
Codex 모바일 : ChatGPT 모바일 앱에 데스크탑에서 실행되는 Codex와 연결해서 모바일에서도 원격 작업을 할 수 있도록 Codex 기능이 프리뷰로 추가되었다.(한국어)
Introducing Workshop: launch sandboxed development environments on Ubuntu with a single command : Canonical에서 workshop launch dev 같은 명령어로 바로 개발 환경을 실행할 수 있는 워크숍 기능을 출시했다. 이 환경은 권한 없는 시스템 컨테이너에서 실행되어 격리된 환경을 제공하고, 한번 구성하면 똑같은 환경을 바로 띄울 수 있다.(영어)

AI 관련

Introducing Claude Opus 4.8 : Anthropic이 새로운 모델 Opus 4.8을 공개했다. Opus 4.8은 벤치마크 전반적으로 성능이 좋아졌고, 속도가 2.5배 빠른 Fast 모드의 비용도 1/3로 낮아졌다. 특히 정직성이 개선되어 근거 없는 주장을 하는 비율이 적어졌다.(영어)
Gemini 3.5: frontier intelligence with action : Google I/O에서 최신 모델인 Gemini 3.5를 공개하고 3.5 Flash를 출시했다. 3.5 Flash는 코딩과 에이전트 벤치마크에서 Gemini 3.1 Pro도 높게 나오며 출력 토큰 처리 속도도 다른 최첨단 모델보다 4배 빨라졌다.(영어)
Qwen3.7: The Agent Frontier : Alibaba가 최신 모델인 Qwen3.7-Max를 공개했다. Qwen3.7-Max는 코드 작성 및 디버깅, 워크플로우 자동화, 자율 실행을 지속하는 등 다방면에서 활용할 수 있는 범용 에이전트로 만들어져서 에이전트 기능의 폭과 깊이에서 뛰어난 성능을 보여준다.(영어)
DeepSeek-V4-Pro 75% Off - Now Permanent! : DeepSeek-V4-Pro가 가격을 4월에 할인 정책을 적용하다가 이 할인 가격을 계속 유지하기로 했다. 캐시된 입력 토큰은 $0.0145 -> $0.003625, 캐시 안 된 입력 토큰은 $1.74 -> $0.435, 출력 토큰은 $3.48 ->$ 0.87로 가격이 낮아졌다.(영어)
Gemini Spark - Your 24/7 personal AI agent : Google I/O에서 사용자의 지시를 하루 종일 처리할 수 있는 개인 AI 에이전트인 Gemini Spark를 발표했고 아직 출시되진 않았다.(영어)
‘제미나이 옴니(Gemini Omni)’를 소개합니다 : Google I/O에서 이미지, 오디오, 영상, 텍스트를 같이 입력해서 고품질 영상을 만들 수 있는 Gemini Omni를 발표하고 첫 번째 모델로 Gemini Omni Flash를 출시했다.(한국어)
Daily Brief - Your personalized overview of today’s priorities : Gemini가 받은 편지함, 일정, 할 일을 살펴보고 하루의 우선순위 등을 요약해 주는 Daily Brief 기능을 공개했다.(영어)
A new era for AI Search : Google 검색의 AI Mode가 1년 만에 월간 사용자 10억 명을 돌파하면서 기본 모델을 Gemini 3.5 Flash를 도입하고 검색 엔진과 AI를 결합하는 방향으로 나아가기로 했다. 이제 검색 에이전트의 시대로 진입하면서 원하는 정보를 지속적으로 검색해서 알려줄 수 있는데 이번 여름에 유료 구독자에게 먼저 제공될 예정이다.(영어)

인프라 관련

From Silos to Service Topology: Why Netflix Built a Real-Time Service Map : Netflix가 수많은 분산 서비스에서 문제를 빨리 파악할 수 있도록 실시간 서비스 맵을 구축한 과정이다. 마이크로 서비스 아키텍처로 유연성과 혁신을 얻었지만, 의존성 파악 문제는 계속 남아 있었다. 그동안의 경험을 통해, 1초 내로 응답하는 빠른 실시간 쿼리로 애플리케이션 계층과 네트워크 계층을 한꺼번에 살펴볼 수 있는 UI와 API가 필요하다고 결론지었다. 그래서 eBPF Flow log, IPC 메트릭, Trace 세 가지 데이터를 수집·처리한 뒤 그래프 스토리지에 저장했다. 그 결과 의존성을 쉽게 파악하고 문제 있는 곳을 바로 찾아내고 영향 범위도 쉽게 파악할 수 있게 되었다.
Introducing Nova, our internal platform for coding agents : Dropbox에서 클라우드 환경에서 코딩 에이전트를 실행할 수 있는 Nova 플랫폼을 구축했다. 코딩 에이전트가 점점 중요해지지만, 개발 워크플로우가 Dropbox 내부의 인프라와 검증 경로에 의존하기 때문에 별도의 AI 전용 워크플로우 대신 코딩 에이전트가 시스템 내에서 동작하길 원했기에 CI가 실패했을 때 에이전트가 결과를 확인하고 대응하도록 하는 문제부터 시작해서 Nova를 구축했다. 이후 동일한 인터페이스로 여러 코딩 에이전트를 지원하도록 확장하게 되었다. Dropbox 내에서 개발자가 웹 UI에서 코딩 에이전트로 개발하다가, Flaky test가 생기면 성공·실패 예시를 찾아 수정하게 하는 것이 가장 성공적으로 활용되는 사례다. 이를 통해 코딩 에이전트의 가치가 코드 생성뿐 아니라 주변 플랫폼에서 나오고 상황에 따라서는 주변 워크플로우가 에이전트를 불러 수정하게 하는 것이 더 효과적이라는 것을 깨달았다.(영어)
Beyond code generation: rethinking engineering productivity in the age of AI agents : 위의 글에서 얘기한 Dropbox의 Nova 플랫폼을 만든 이유와 그 효과를 설명한 글이다. AI가 코드 생산성을 높였지만 그 영향으로 코드 리뷰, CI, 검증 워크플로우, 릴리스, 운영에 가해지는 부담이 더 커지면서 이 부분을 조정해야 한다는 판단하에 Nova를 만들었다. 현재 회사 내 풀 리퀘스트의 1/12을 차지하고 있고 배포 직전 사람이 최종 판단하는 거 외에는 자동으로 모든 과정을 진행할 수 있다는 점이 가장 큰 변화이다. 또한 AI로 인해서 풀 리퀘스트 처리량만으로는 생산성 지표로 충분하지 않다고 판단하고 더 포괄적인 측정 모델을 만들었다. AI 도구를 활용하는지에 대한 Fuel 단계, 팀 전반적인 워크플로우의 변화를 추적하는 Adoption 단계, AI가 실제 업무에 기여하는지를 측정하는 Output 단계, 제품 개발 속도를 높이고 고객 가치 창출까지 걸리는 시간을 추적하는 Impact 단계 4가지 측정 모델을 만들었다.(영어)
Toto 2.0: Time series forecasting enters the scaling era : Datadog에서 옵저버빌리티 메트릭에 최적화된 시계열 예측 파운데이션 모델인 Toto 2.0을 오픈소스 라이센스로 공개하고 Hugging Face에 2m, 22m, 313m, 1B, 2.5B의 다섯 가지 가중치로 올렸다. 이전 버전보다 파라미터 효율성이 7배 좋아지고 추론 속도도 빨라졌으며, 벤치마크에서도 우수한 성능을 보였다. 또한 메트릭 패턴을 예측하는 데에서도 시계열에서도 모델 크기가 커질수록 성능이 좋아지는 것을 확인했다.(영어)
Benchmarking Kubernetes Log Collectors: vlagent, Vector, Fluent Bit, OpenTelemetry Collector, and more : VictoriaMetrics에서 VictoriaLogs를 위한 로그 수집 도구인 vlagent를 개발하고 다른 8개의 로그 수집 도구와 비교 테스트를 진행했다. 비교한 도구들은 VictoriaLogs Agent, Vector, Promtail, Grafana Alloy, Grafana Agent, Fluent Bit, OpenTelemetry Collector, Filebeat, Fluentd이다. 벤치마크에 따르면 로그 처리량에서 다른 도구들은 4만 미만에서 한계에 도달함에 비해 vlagent는 14만까지 선형적으로 증가하면서도 CPU와 메모리도 가장 적게 사용했다.(영어)
OpenTelemetry is a CNCF Graduated Project : OpenTelemetry가 CNCF의 졸업 프로젝트가 되었다.(영어)
OpenAI: Secure MCP Tunnel : OpenAI에서 회사 내부의 MCP 서버를 외부에 노출하지 않고 MCP 터널을 통해서 아웃바운드 요청만으로 OpenAI와 연결할 수 있는 Secure MCP Tunnel를 공개했다.(영어)

보안 및 장애

Compromised coding tool helped hackers breach thousands of GitHub repositories : 해커들이 수천 개의 GitHub 저장소 데이터를 탈취했다고 밝히고 다음 날 GitHub도 직원이 사용한 Visual Studio Code 확장의 악성 버전을 통해 침해가 발생했으며 3,800개의 저장소가 유출되었다고 확인했다. 추가 조사 결과 5월 18일에 공개된 Nx Console의 확장 프로그램에 악성 코드가 포함된 것이 밝혀졌다.(영어)
Incident Report: May 19, 2026- GCP Account Suspension : Google Cloud가 올인원 클라우드 플랫폼인 Railway의 프로덕션 계정을 정지하면서 UTC 기준 5월 19일 22:20부터 5월 20일 6:14까지 약 8시간 동안 플랫폼 전체가 중단되었다. Railway는 자체 메탈 워크로드와 AWS 워크로드가 있었지만, 컨트롤 플레인이 Google Cloud에 있었기 때문에 모든 Railway 워크로드를 이용할 수 없게 되었다. 이는 Google Cloud의 자동화가 Railway 계정을 잘못 정지 상태로 전환하면서 발생했다.(영어)
Project Glasswing: An initial update : Anthropic의 차세대 모델인 Mythos가 보안 취약점에 악용되는 걸 막기 위해 시작된 Project Glasswing의 현황이다. 50여 개의 파트너와 협업한 결과 1만 건이 넘는 취약점을 발견했고 몇몇 파트너는 취약점 발견 속도가 빨라졌다고 얘기한다. 1,000개 이상의 오픈소스 프로젝트를 스캔한 결과 6천여 건의 고위험·치명적 취약점을 발견했다. 이 중 1,700여 건을 보안 업체와 평가한 결과 90%가 양성으로 판명되었고, 62%가 고위험·치명적 심각도의 취약점으로 확인되었다.(영어)

볼만한 링크

I think Anthropic and OpenAI have found product-market fit : Simon Willison이 그동안 Anthropic과 Claude의 정액제 요금제를 쓰고 있어서 몰랐는데 최근 두 회사 모두 엔터프라이즈 요금제에서 라이센스 요금에 API 사용량 과금을 추가한 것을 확인했다. 이렇게 가격 정책을 바꾼 이유는 두 회사가 엔터프라이즈 시장에서 PMF를 찾은 것으로 보인다고 설명한다.(영어)

IT 업계 뉴스

Stainless is joining Anthropic : 2022년에 설립된 API 플랫폼을 만드는 회사인 Stainless를 Anthropic이 인수했다. Stainless는 Anthropic의 파트너로 그동안 Claude API 출시를 함께하고 있다가 이번에 인수되게 되었고, Stainless의 제품은 단계적으로 종료될 예정이다.(영어)
Andrej Karpathy: I've joined Anthropic : OpenAI의 창립 멤버이자 Tesla에서 AI를 총괄했던 Andrej Karpathy가 Anthropic에 합류했다.(영어)
Dropbox CEO Drew Houston to step down after 19 years at helm of cloud storage pioneer : 24세에 Dropbox를 창업한 Drew Houston(43세)이 제품 총괄인 Ashraf Alkarmi와 공동 CEO로 운영한 뒤 이사회 회장으로 물러날 예정이다.(영어)
Cerebras pops 68% in Nasdaq debut, pushing the AI chipmaker's market cap to $95 billion : AI 칩 제조사인 Cerebras Systems가 지난 14일 나스닥에 상장했다. 공모가 185달러로 시작해 68% 오른 311.07달러에 장을 마감하면서 기업가치가 약 950억 달러(약 131조 원)가 되었다.(영어)
OpenRouter Raises $113M Series B : 여러 LLM을 라우팅해 주는 OpenRouter가 1억 1,300만 달러 규모의 시리즈 B 투자 유치했다.(영어)
Pi 오픈소스 프로젝트 인수 : Armin Ronacher와 Colin Daymond Hanna가 설립한 회사인 Earendil Inc.가 오픈소스 코딩 에이전트인 Pi를 인수했다.(영어)

프로젝트

Agent Executor (AX) : 분산형 에이전트 런타임으로 Google 만들고 있고 개발 초기 상태이다.
K8S Cleaner : Kubernetes 클러스터에서 오래되거나 고아 상태인 리소스를 식별해서 제거하거나 업데이트할 수 있는 컨트롤러로 Slack, Discord 등 다양한 곳으로 알림을 보낼 수 있다.
MniSim : iOS, Android 에뮬레이터.
AI-DLC (AI-Driven Development Life Cycle) : AI-Driven Development Life Cycle은 AI의 실수를 줄이기 위해 표준 품질을 유지하고 프로세스 제어권을 유지하도록 돕는 지능형 소프트웨어 개발 워크플로우다.
herdr : 터미널용 에이전트 런타임
Claude Code Security Reviewer : Claude로 보안 취약점을 찾아주는 GitHub Actions
Antigravity CLI : Google의 코딩 에이전트인 Antigravity의 CLI
Hyperagent : Airtable 팀이 만든 클라우드 에이전트 시스템.
Webwright : LLM이 브라우저를 실행해서 페이지를 분석하고 웹 작업을 할 수 있게하는 웹 에이전트로 Microsoft에서 만들었다.
Koog : JetBrains에서 만든 AI 에이전트를 만드는 JVM 네이티브 프레임워크.
SkillSpector : AI 에이전트 스킬의 취약점을 분석해 주는 보안 스캐너로 Nvidia에서 만들었다.
CostBench : 데이터 웨어하우스의 비용 대비 성능을 보여주는 벤치마크 도구.

버전 업데이트

TypeORM v1.0 : TypeScript/JavaScript ORM, 릴리스 공지
ember v7.0 : JavaScript 프레임워크, 릴리스 공지
Consul v2.0.0 : 서비스 디스커버리/설정 도구, 릴리스 공지
Expo SDK 56 : React로 네이티브 앱을 만드는 플랫폼 SDK, 릴리스 공지
Deno v2.8 : TypeScript 런타임, 릴리스 공지
Proxmox v9.2 : 리눅스 기반 하이퍼바이저, 릴리스 공지
Storybook v10.4.0 : React, Vue3, Angular UI 컴포넌트 개발 도구, 릴리스 공지
Node.js v26.2.0 (Current) : 자바스크립트 런타임, 릴리스 공지
Node.js v24.16.0 (LTS) : 자바스크립트 런타임, 릴리스 공지
LogTape v2.1.0 : JavaScript 로깅 라이브러리, 릴리스 공지
Rstest v0.10 : Rspack 기반 테스팅 프레임워크, 릴리스 공지
Oxlint v1.66.0 : JavaScript/TypeScript Linter, 릴리스 공지
Oxfmt v0.51.0 : JavaScript/TypeScript 포매터, 릴리스 공지
Istio v1.30.0 : 서비스 매쉬, 릴리스 공지
Valkey v9.1.0 : 키/밸류 스토어, 릴리스 공지
pnpm v11.3.0 : Node.js 패키지 매니저, 릴리스 공지
vLLM v0.22.0 : LLM 서빙, 릴리스 공지
Visual Studio Code 1.122 : 에디터, 릴리스 공지
typeagent 0.5.0 : Guido van Rossum이 만든 Structured RAG의 Python 버전, 변경사항
Antigravity 2.0 : Google의 코딩 에이전트, 릴리스 공지
astro 6.4 : JavaScript 웹 프레임워크, 릴리스 공지
Falco v0.44.0 : 클라우드 네이티브 런타임 보안, 릴리스 공지
VictoriaMetrics v1.144.0 : 시계열 데이터베이스, 릴리스 공지

Textcube를 떠나며...

2026-05-18T00:47:16+09:00

이 블로그를 2007년부터 시작했으니 어느새 20년에 가까워졌다. 그동안 Textcube로 운영해 왔는데 이번에 블로그를 Textcube에서 정적 사이트로 마이그레이션했다.

처음에는 테터툴즈로 설치만 했다가 이후에 텍스트큐브로 바꿨던 걸로 기억한다. 언제 바꾸었는지까진 기억나지 않지만 내 개발 커리어에서 가장 잘한 결정은 개발 블로그를 시작한 것이다. Textcube와 거의 20년 가까이 지내다 보니 정이 많이 든 프로젝트가 되었다. 그래서 막상 떠나고 나니 아쉬움이 많이 남아서 추억을 남겨놓을 겸 Textcube의 히스토리를 정리해 본다. RetroTech 팟캐스트을 운영하면서 생긴 습관 같은데 언젠가 RetroTech에서도 이런 국내 프로젝트들도 다뤄보고 싶다.

Tattertools와 Textcube

2004년 3월 1일에 정재훈 님이 3달 동안 PHP로 만든 설치형 블로그 "테터툴즈"를 공개한다. 당시 버전은 0.9 버전이었다.

태터 툴즈는 '뜨개질을 하는 사람의 도구'란 뜻입니다. 글이라는 실과 키워드라는 바늘로 옷을 짜듯이 지식을 담는 스크립트를 만들고자 그렇게 이름을 짓게 되었습니다.

나는 그 흐름의 한복판에 있진 않았지만, 당시 블로그 도구들이 별로였는지 정재훈 님의 다음 글을 보면 배포 후 24시간 만에 큰 호응을 얻은 듯하다. 게시판 시대의 한국 웹에 제로보드가 있었다면 블로그 시대에는 테터툴즈가 있었다. 큰 맥락은 알고 있었지만, 세부 내용은 이번에 자료를 찾으며 알게 됐다.

테터툴즈는 엄청난 인기로 사용자층이 생기고 관련 글들을 찾아보면 사용자들이 자발적으로 테터툴즈를 홍보하고, 팁을 공유하고, 사이트를 만들며 커뮤니티를 키워가던 자유스러운 분위기였던 듯하다. 그런 분위기에서 1.0을 준비하던 2005년 테터툴즈의 개발과 배포를 지원하고 수익을 내기 위해 정재훈 님과 합의로 노정석 님이 TNC(Tatter and Company)를 설립한다. 개인이 가지고 있는 블로그를 연결해 주는 블로고스피어나 메타블로그가 인기 있었는데 테터툴즈 사용자를 연결해 주는 이올린도 TNC가 운영했다.

그리고 2006년 1.0이 GPL 라이선스를 선택하고 이후 개발이 부진해지자, 이에 항의하면서 커뮤니티 서버 권한을 받아 2006년 4월부터 포럼 형태로 테터툴즈 사용자들이 모이면서 TNF(Tatter and Friends)가 만들어지게 된다. 이후 똑같은 약자를 사용하는 Tatter Network Foundation에 대해 논의하면서 재단이 TNF의 공식 명칭이 된다.

2006년 TNC는 Daum과 협업해서 Tattertools를 서비스형으로 만들어서 Tistory를 공개하면서 직접 설치하기 어려운 사람들도 블로그를 운영할 수 있게 됐다. 처음에는 TNC와 Daum이 공동 운영을 했지만 이후 지분을 모두 넘기고 Daum이 Tistory를 전적으로 운영하게 된다.

오픈소스화된 테터툴즈는 2007년에는 inureyes님을 중심으로 TNF의 구체적인 실행 조직으로 Needleworks가 만들어져서 공식적으로 활동하기 시작했다. 이후 Tattertools는 Textcube로 이름을 바꾸었고, Needleworks와 TNF가 개발을 이어받고 Textcube 1.5가 정식으로 발표된다. 이후 마케팅을 주력으로 한 테터앤미디어(TNM)도 등장한다. 자세한 히스토리는 니들웍스 홈페이지에서 볼 수 있다.

이렇게 2000년대 중반부터 2010년대까지 국내의 웹서비스를 관통하는 중심에 테터툴즈가 있었다고 해도 과언은 아니라고 생각한다. 당시 나에게는 TNF, Niddleworks, TNC, TNM이 모두 로망 중 하나인 조직이었고(또 하나의 조직은 오픈마루 스튜디오였다.) 지금 돌아보면 더 대단하게 느껴지는 국내 오픈소스의 성공 사례다.(너무 조용히 일상처럼 지나가지 않았나 싶을 정도로...)

2008년에는 Blogger라는 플랫폼을 가지고 있던 Google이 TNC를 인수한다. 나의 로망과도 같은 생태계였기에 나도 이 당시에 TNC 인수에 대한 글도 썼다.

Textcube로 운영한 19년

Textcube는 나에게 블로그란 세상을 알려준 도구였다. 개발을 배우고 웹을 깊게 알게 되면서 블로그를 점점 더 좋아하게 되었고, 당시에 블로그를 중심으로 설계된 많은 기술은 여전히 좋은 접근 방법이라고 생각하는 편이다.

소셜 네트워크가 인기를 얻으면서 블로그의 인기가 줄어들었지만, 문서가 웹의 근본이라고 생각하는 나는 여전히 블로그가 좋다. 왜 인기 없는지 모를 정도의 RSS이지만 지금까지도 나는 RSS 리더로 수많은 글을 읽고 있으며 다시 RSS의 시대가 와야 한다고 생각하는 편이다. 소셜 네트워크의 소모적인 논쟁보다는 블로그에 글을 적어서 트랙백으로 서로의 글을 연결하는 방식은 훨씬 생산적인 방식이었다고 생각한다.(물론 시간이 지나면서 내 트랙백도 스팸으로 가득 차긴 했다. ㅠ)

그 시절 웹은 인터넷을 통해서 서로 연결하고 쉽게 찾을 수 있는 포맷을 많이 시도했는데 시맨틱웹을 포함해서 Microformats이나 Movable Type, XFN(XHTML Friends Network), OpenID같은 것도 Textcube의 개발자들이 워낙 뛰어나서 여기서 배운 것들이다.(여기서도 마찬가지로 오픈마루 스튜디오에도 이러한 신기술들을 자주 보여줬다.)

기본적으로 만족스러운 블로그 플랫폼이지만 2011년 이후 릴리스가 한참 없었고 소프트웨어도 시간이 지나면 녹슬기 마련이고, 내 요구사항도 달라지고 있었다. 나도 웹 개발을 하고 있었기 때문에 직접 고쳐서 쓰기 시작했다.

Textcube는 원래 WYSIWYG 에디터를 지원했는데 내가 Markdown에 익숙해지면서 WYSIWYG을 제거하고 다른 마크다운 플러그인을 나한테 맞게 수정해서 사용하기 시작하고 스킨을 작성하고 몇 가지 버그를 수정하면서 사용하게 됐다.

그러다가 마지막 릴리스 후 3년 만인 2014년에 1.9버전이 릴리스되고 곧이어 1.10.0까지 나와서 Textcube를 사용하는 나로서는 너무 반가웠다.

개발자분들이 돌아오셨을 때 PHP를 할 줄 몰라서 내가 해결하지 못하는 버그나 RSS 피드의 max 제한 문제 등은 이슈를 올리면 메인테이너분들이 정말 잘 대응해 주셨다. 물론 이때는 온라인으로만 뵈는 분들이었지만 지금은 종종 인사드릴 수 있는 사이가 되었다.

당시 2.0이 준비 중이었기 때문에 기대했지만 메인테이너분들이 바빠지신 관계로 2.0은 아직도 나오지 않았다.

그 상태로 스킨을 조금씩 수정하고 하면서 지금까지 사용하고 있다. 물론 지금까지 큰 문제 없이 운영하고 있다는 면에서도 잘 만들어진 프로젝트라고 할 수 있지만 완전 괜찮은 것도 아니었다.

가장 큰 건 아무래도 웹 기술이 발전하고 있다는 것이다. 이유는 모르지만 댓글 시스템은 멈춰버렸고 방문자 통계도 신뢰하기 어려워졌다. 또한 당시에는 멀티 파일 업로드를 Flash에 의존하고 있었지만, Flash는 이제 웹에서 사라진 기술이 되었고, Flash가 완전히 사라질 때 "이젠 파일 업로드 어떻게 하지?"하면서 고민했지만, 웹 표준 기술로 fallback이 잘 구성되어 있었다. 그래서 멀티 파일 업로드는 안 되지만 하나씩 여러 번 올리면 되기 때문에 괜찮았다. 귀찮다면 귀찮지만 난 그래도 이런 fallback까지 구성한 개발자들에게 감사함을 느꼈다.

이유는 모르겠지만 어드민 사이트도 로그인은 되지만 로그인 유지가 안 되어 수 분 내에 풀리기 시작했고, 글을 어드민에서 직접 작성하지 않고 Sublime Text에서 작성하고 복사만 해서 발행하기 때문에 이마저도 크게 문제는 안 되었다. 열심히 보면 해결할 수도 있지만 그냥 조금씩 고장 나는 상태에서 계속 버티면서 20년 가까이 쓰게 됐다.

이제는 도커라이즈도 하고 MySQL 백업 스크립트도 잘 작성해 두고 ansible 세팅도 해놔서 필요하면 로컬에서 테스트용 블로그를 띄워서 테스트도 할 수 있고 배포 인프라도 필요할 때 이사 가면서 운영할 수 있게 되었다. 여전히 요구사항은 많이 있지만 익숙해진 채로 계속 사용 중이었다.

남들이 보기에는 Textcube가 뭐야? 하면서 낡은 플랫폼이라고 생각할 수 있었지만, 나에겐 너무 소중한 플랫폼이었다.

내 Textcube의 기록

내 개발 커리어 전체를 함께한 막상 떠나려니 아쉬움이 더 이상 볼 수 없을 거 같아 스크린샷을 남겨둔다.

이번 글을 쓰면서 Tattertools 자료를 조사하면서 가끔 트위터에서도 인사도 드리던 Lunamoth님이 블로그에 2000년대 초반부터 세세한 기록을 많이 남겨두셔서 큰 도움을 받았다.

Outsider's Dev Story

기술 뉴스 #304 : 2026-10-16

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

기술 뉴스 #303 : 2026-10-01

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

기술 뉴스 #302 : 2026-09-16

개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

기술 뉴스 #301 : 2026-09-01

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

IT 업계 뉴스

프로젝트

버전 업데이트

Istio의 재시도 정책과 관련 메트릭 살펴보기

Istio의 defaultHttpRetryPolicy

Retry 데모

Kubernetes 클러스터 생성

Istio 설치

Retry 동작 확인

기술 뉴스 #300 : 2026-08-16

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

IT 업계 뉴스

프로젝트

버전 업데이트

[Side Project] 코딩 세션을 모아 보는 Agentic Engineering History

Agentic Engineering History 개발

UI

에필로그

Istio External Authorization의 로컬리티 로드 밸런싱 확인하기

External Authorization

Locality Load Balancing

distribute

outlierDetection

로컬리티 데모

Kind 클러스터 설정

Istio 설치

데모 앱

왜 EnvoyExternalAuthorizationGrpcProvider에서도 로컬리티가 잘 적용되는가?

추가 자료: PreferSameZone

Istio ServiceEntry로 외부 서비스 등록하기

outboundTrafficPolicy

ServiceEntry

추가 예시

기술 뉴스 #299 : 2026-08-01

웹개발 관련

그 밖의 개발 관련

AI 관련

인프라 관련

보안 및 장애

볼만한 링크

왜 `EnvoyExternalAuthorizationGrpcProvider`에서도 로컬리티가 잘 적용되는가?