State of HTML 2025 : HTML 생태계의 상황을 3천여 명에게 설문 조사해서 정리한 결과이다. From, 그래픽, 콘텐츠, 상호작용, 성능, 웹 컴포넌트, 접근성 등 각 기능의 사용 여부와 알려진 정도를 살펴볼 수 있다.(영어)
JavaScript Frameworks - Heading into 2026 : 2023년부터 자바스크립트 프레임워크의 동향을 연속해서 작성하는 글이다. AI의 발전으로 인해 AI가 중심이 되었고, AI의 경우 가장 큰 학습 세트가 있는 React가 마지막 프레임워크라는 주장이 있지만 모든 것은 변해가고 있어서 다른 프레임워크로도 AI는 잘 작성하며 Remix 3는 AI로 작성된 최초의 프레임워크가 될 것이라고 얘기한다. Islands, React Server Components, Tanstack Start, SvelteKit, SolidStart에서 동형 우선 아키텍처가 발전하고 있으면 비동기 우선 프레임워크도 발전할 것으로 보고 있다.(영어)
Introducing the <geolocation> HTML element : 위치 흐름은 그동안은 Geolocation API에 의존했는데 권한 문제로 사용자 경험을 해치는 문제가 있었는데 Chrome 144부터는 <geolocation>를 지원해서 사용자로부터 트리거 되어 사용자 경험이 훨씬 좋아졌고 구현도 쉬워졌다.(영어)
그 밖의 개발 관련
Claude Code On-The-Go : Vultr VM에 Tailscale을 연결하고 스마트폰에서 Termius와 Mosh로 접속해서 Claude Code 에이전트 6개를 동시에 돌리는 방법을 설명한다.(영어)
Lots of people have asked how I use Claude Code, so I wanted to show off my setup a bit. : Claude Code를 만드는 Boris Cherny가 트위터에서 자신이 사용하는 설정을 설명했다. 터미널 탭에 번호를 붙여서 5개를 동시에 실행하며 웹에서도 5~10개의 Claude를 운영하고 있다. Opus 4.5만 사용하고 팀에서는 단일 저장소에 CLAUDE.md를 공유하고 코드 리뷰 시 @claude를 태그해서 CLAUDE.md에 내용을 추가하고 대부분은 Plan 모드를 사용한다. 하루에 여러 번 하는 워크플로우는 슬래시 명령어를 사용하며 몇 개의 서브 에이전트를 사용하고 코드 포매팅은 PostToolUse 훅을 사용한다. 안전한 명령어만 등록해서 사용하면 모든 도구를 Claude Code가 직접 사용하도록 한다.(영어)
My LLM coding workflow going into 2026 : Google Cloud AI의 Addy Osmani가 자신이 사용하는 에이전틱 코딩 방식을 설명한 글이다. LLM으로 코딩할 때는 AI와 함께 상세한 스펙을 만들고 계획을 세운 뒤에 실제 코드를 작성하는 것이며 이 결정 사항을 spec.md로 정의한다. 그리고 AI가 다룰 수 있는 단위로 작업을 나누어서 작업을 시키고 AI가 알아야 할 모든 것을 정리해서 광범위하게 알려줘야 하는데 gitingest나 repo2txt를 활용할 수 있다. Claude Skills는 더 유용한 작업을 시킬 수 있으며 모델마다 고유한 개성이 있으므로 모델 바꾸는 것을 두려워하지 말고 가능하다면 최신 프로 모델을 사용하는 것이 좋다. 그리고 AI가 작성한 코드는 직접 검토하고 테스트하면서 품질에 대한 책임을 져야 하고 자주 커밋해서 버전 관리를 안전망으로 활용하라고 하고 있다.(영어)
Gemini CLI Tips and Tricks : Gemini 2.5, 3.0으로 에이전틱 코딩을 하는 팁 30가지를 정리한 글로 Gemini를 사용해 볼 생각이면 참고해 볼만하다.(영어)
인프라 관련
Your AI SRE needs better observability, not bigger models. : ClickHouse를 홍보하는 글이지만 AI SRE가 잘 동작하려면 무엇이 필요한지를 정리한 글이다. 기존 AI SRE 도구들은 기존 옵저버빌리티 플랫폼 위에 얇게 씌운 레이어에 불과하므로 데이터가 오래 보관되어 있지 않고 커디널리티 문제로 이벤트 간 연결할 수 있는 필드가 별로 없으며 쿼리 속도도 높지 않으며 너무 많은 쿼리를 하면 비용도 크게 나오게 된다. ClickHouse는 이 스토리지 비용, 높은 카디널리티 성능, 쿼리 지연 문제를 해결해서 AI SRE가 엔지니어를 도와주는 역할을 잘할 수 있게 구성할 수 있다고 설명한다.(영어)
IPv6 just turned 30 and still hasn’t taken over the world, but don't call it a failure : IP 주소 부족 문제를 해결하기 위해 1995년 IPv4의 첫 RFC가 나와서 IP 주소를 32비트에서 128비트로 전환할 수 있게 했지만, 현재 절반도 IPv6를 사용하고 있지 않다. IPv6는 IPv4와 호환되지 않으며 새로운 기능을 추가하지 않았기 때문에 채택이 많이 되지 않았고, NAT로 수천대의 장치가 하나의 IPv4 주소를 공유하면서 IP 주소 문제도 큰 문제가 되지 않았다. 반면 IPv6 쪽에서는 미래를 위한 준비이고 IPv6가 일부 성장 압력을 해소했기 때문에 IPv4가 생존할 수 있던 것이므로 실패라고 보기는 어렵다고 얘기한다.(영어)
2025년은 추론과 RLVR(Reinforcement Learning with Verifiable Rewards), GRPO의 해였는데 DeepSeek R1이 여러 면에서 큰 관심을 모았고 이 논문에서 GRPO를 활용해서 RLVR이 LLM 개선에 사용될 수 있다는 점이 관심을 모았고 RLVR은 내년에도 많은 관심을 끌 것으로 보인다.
LLM 아키텍처에도 많은 시도들이 있지만 몇 년 동안은 트랜스포머 아키텍처를 계속 사용할 것이고 효율성과 엔지니어링 개선이 더 많이 이루어질 것이다.
스케일링만으로는 효과가 많이 안 나타나기 시작했고 학습 파이프라인과 추론 확장에서 더 많은 발전이 있었고 도구 사용을 염두에 두고 LLM을 훈련하면서 큰 개선이 이루어졌다.
또 하나의 트렌드는 benchmaxxing인데 벤치마크 성능 자체를 목표로 해서 높은 점수를 받았음에도 실제에서는 성능이 나오지 않게 되는 현상을 말한다. 이는 LLM은 벤치마크에서 좋은 점수를 필수로 받아야 하지만 좋은 점수를 받았다고 좋은 LLM은 아니라는 의미가 된다.
코딩에 LLM을 사용하는 경우가 많아졌지만 언제 LLM을 쓰고 언제 안 쓸지 인지하는 게 중요하며 여전히 전문가가 만든 코드를 대체하진 못하고, 이는 기술 문서에서도 마찬가지다. AI를 잘 사용해서 학습을 가속화하고 한 사람이 감당할 수 있는 범위를 확장할 수 있으므로 이를 대체물이 아니라 파트너로 생각해야 한다.
독점적인 데이터를 팔지 않는 분위기가 많아지고 있고 시간이 가면서 사내 LLM을 더 많이 만들게 될 것이다.
Opus 4.5 is going to change everything : Claude Opus 4.5를 사용해 보고 나서 AI 코딩 에이전트가 개발자를 대체할 수 있다고 생각이 바뀌었다며 자신의 경험을 정리한 글이다. Opus 4.5로 이미지 파일을 빠르게 변환할 수 있는 Windows 유틸리티, GIF 녹화 유틸리티를 만들고 아내의 사업을 돕는 앱을 어떻게 만들었는지를 설명한다.(영어)
AI 에이전트를 위한 평가(evals) 쉽게 이해하기 : Anthropic의 Demystifying evals for AI agents의 번역 글이다. AI 에이전트의 평가는 필수적인데 단일 턴 평가를 주로 사용했지만, AI 역량이 높아지면서 멀티 턴 평가가 보편적으로 되고 있다. AI 에이전트를 출시하고 사용자로부터 성능이 안 좋아졌다는 피드백이 왔을 때 이를 검증하기 위해 평가를 사용하고 코드 기반, 모델 기반, 사람의 3가지 채점기를 결합해서 사용하는 데 여러 에이전트의 타입과 문제 상황에 따라 어떻게 평가하는 게 좋은지 그동안의 고민 방법이 정리되어 있다.(영어)
ChatGPT Health를 소개합니다 : OpenAI에서 개인의 건강 상태를 이해하고 관리할 수 있게 돕는 ChatGPT Health를 공개했다. 이미 ChatGPT에서 건강에 관한 질문을 많이 하는데 ChatGPT Health는 개인정보 보호와 보안을 강력하게 적용해서 자신의 건강 정보를 바탕으로 대화를 진행할 수 있다. 현재는 클로즈 베타이지만 곧 모든 사용자가 사용할 수 있게 될 예정이며 전자 의료 기록, Apple Health, Function, MyFitnessPal 같은 앱과 연동해서 사용할 수 있다.(한국어)
볼만한 링크
Don't fall into the anti-AI hype : Redis를 만든 antirez가 코딩을 워낙 좋아했고, AI의 성공을 바라지도 않았지만 실제로 해보니 AI가 프로그래밍을 영원히 바꿀 것이라고 얘기한다. 그동안 AI로 많은 작업을 했고, 본인의 의견에 상관없이 프로그래밍은 이미 바뀌었고 그동안 시간이 없어서 못 했던 오픈소스를 너무 하고 싶고 작성한 코드가 LLM에 흡수된 것이 오히려 기쁘다고 얘기한다.(영어)
AI가 초급 업무를 대체하며 주니어를 채용이 붕괴할 수 있다. 이에 따라 시니어로 성장하는 경로가 흔들리고 있고 이러한 추세는 가속화되고 있지만 반대 시나리오에서는 AI로 막대한 개발자 수요가 열리고 미국 노동 통계국도 34년까지 일자리가 15% 증가할 것으로 보고 있는데 주니어가 성장하지 못하면 수년 내에 리더십 공백이 생길 것이다.
AI로 프로그래밍 역량이 퇴화할 수도 있고 인간이 감독에 집중하면서 더 중요해질 수도 있다. 개발자의 84%가 AI를 사용하면서 프로그래밍 역량 저하를 우려하기도 하지만 일상의 80%는 AI가 하고 인간은 어려운 20%에 집중하면서 인간의 전문성이 더 중요하게될 수 있다.
개발자의 역할이 AI 생성 코드 감소로 축소될 수도 있고 AI 기반 시스템을 설계하고 관리하는 핵심 조정자로 확장될 수도 있다. 비관적 시나리오에서는 개발자의 창의적인 책임이 축소되고 AI 산출물을 감시하는 역할이 될 수 있다고 걱정하지만, 반대 시나리오에서는 AI가 기계적인 작업을 처리하고 개발자는 더 가치 있는 활동으로 이동해서 일자리가 더 흥미로워질 수 있다.
좁은 전문 분야는 해당 분야가 자동화되거나 구식이 될 위험이 있고 AI가 빠르게 변화하는 환경에서는 T자형 엔지니어가 기회를 얻을 수 있다.
컴퓨터과학 학위가 여전히 필요할까 아니면 부트캠프나 교육 플랫폼이 더 효과적으로 될 것인가? 기존에는 컴퓨터과학 학위가 주요 입구였지만 AI로 인해 더 빨라진 변화로 인해 직장에서 필요한 기술을 대학에서 충분히 배우지 못하고 있고 부트캠프나 고용주 주도 교육 등이 개선되고 성장하고 있으며 비용도 훨씬 싸다.
A website to destroy all websites. : 인터넷에서 생산적인 시간을 보내기보다는 낭비하는 시간이 많아진 상황을 비판하면서 사회 비평가 Ivan Illich의 의견을 소개하면서 기술이나 도구가 처음엔 사회를 위해 만들어지지만 산업화되고 나면 도구의 요구사항에 맞추기 위해 사회가 움직이게 되고 그렇지 않으면 사회에서 배제되는 느낌을 주는 문제를 지적하고 이게 웹에서도 일어나고 있다고 얘기한다. 이를 해소하기 위해 개인 웹사이트를 만들어서 운영하라고 얘기한다.(영어)
Comments