빌드 도구를 바꾸면 개발 속도가 빨라질 것이라는 이야기는 매력적입니다. 하지만 이미 사용자가 있는 앱에서는 첫 화면이 뜨는 것만으로 전환을 결정하기 어렵습니다. 로그인한 사람의 화면, 저장 직후 목록, 오래 열어 둔 탭에서도 기존 동작이 유지되어야 합니다.Cloudflare는 2026년 9월 28일 Vinext 1.0을 발표했습니다. Next.js 애플리케이션을 Vite 기반으로 실행하고 배포 환경의 선택지를 넓히려는 프로젝트입니다. 웹 개발을 오래 해 온 제게 흥미로운 지점은 새 도구 자체보다, 익숙한 API의 행동을 다른 기반에서 어디까지 유지하느냐입니다.이 글은 운영 서비스를 Vinext로 이전한 후기가 아닙니다. 10월 11일 확인한 공식 발표에서 현재 범위를 짚고, 실제 앱의 전환 검토에 사용할..

OpenTelemetry를 처음 붙일 때 애플리케이션에서 로그·메트릭·트레이스를 원하는 백엔드로 바로 보내면 간단해 보입니다. 하지만 백엔드를 바꾸거나 샘플링·필터링을 조정할 때 애플리케이션을 다시 배포해야 합니다.혼자 운영하는 서비스에서도 Collector를 둘 가치가 있는지 판단하기 위해서는 멋진 다이어그램보다 데이터가 어디에서 사라질 수 있는지를 먼저 봐야 합니다. 이번 글에서는 최소 구성의 책임 경계를 정리합니다.세 신호는 서로 다른 질문에 답합니다트레이스는 한 요청이 어디를 지나갔는지 알려 주고, 메트릭은 시스템이 얼마나 바쁜지 보여 주며, 로그는 특정 사건의 맥락을 설명합니다. 셋을 모두 수집한다고 자동으로 장애 원인을 찾을 수 있는 것은 아닙니다.저는 알림에는 메트릭을, 원인 추적에는 트레이..

React의 새 기능을 보면 기존 컴포넌트를 모두 바꾸고 싶어집니다. 그러나 화면이 빨라질지, 효과의 생명주기가 더 이해하기 쉬워질지는 코드의 사용 맥락에 따라 다릅니다.React 19.2에서 소개된 Activity와 useEffectEvent는 숨겨진 화면과 효과 이벤트를 다루는 선택지를 넓혀 줍니다. 이 글은 API 사용법을 나열하기보다 어떤 화면에 적용하고 어떤 화면에는 적용하지 않을지에 초점을 둡니다.Activity는 숨겨진 화면의 생명주기를 명시합니다조건부 렌더링은 보이지 않는 화면을 언마운트하는 단순한 방법입니다. Activity의 hidden 모드는 화면을 유지하면서 효과를 중단하고 업데이트를 늦출 수 있어, 다시 돌아올 가능성이 높은 화면의 상태를 보존하는 데 유용할 수 있습니다.하지만 모..

ORM의 새 기능은 샘플 코드에서는 쉽게 동작하지만, 실제 서비스에서는 모델·데이터베이스·마이그레이션·쿼리 번역이 함께 움직여야 합니다. 특히 EF Core 11처럼 개발 중인 버전은 기능 목록보다 호환성 확인이 먼저입니다.이번 글에서는 Complex Types와 FullJoin 같은 기능을 바로 채택하자는 이야기가 아니라, 적용 여부를 판단하기 위해 어떤 실험을 해야 하는지 정리합니다. 테스트 환경과 버전은 글을 읽는 시점에 다시 확인해야 합니다.기능 이름보다 지원 범위를 고정합니다새 기능을 읽을 때는 무엇이 가능한지보다 어떤 데이터베이스와 런타임에서 가능한지 먼저 기록합니다. EF Core 11은 .NET 11 SDK와 런타임을 요구하는 개발 중 버전이므로, 기존 서비스가 사용하는 타깃 프레임워크와 ..

API에 제한을 붙일 때 가장 먼저 떠오르는 문장은 ‘분당 몇 번 허용할까’입니다. 하지만 같은 분당 열 번이라도 읽기 요청과 파일 변환 요청의 비용은 다릅니다. 제한값 하나를 정하기 전에 정책의 목적을 분리해야 합니다.이번 글에서는 ASP.NET Core의 Rate Limiting 미들웨어를 특정 값의 정답이 아니라 정책 선택 도구로 읽어 보겠습니다. 실제 값은 부하 테스트와 사용자 행동을 보고 조정해야 합니다.제한의 목적을 네 가지로 나눕니다Rate Limiting은 악성 요청만 막는 기능이 아닙니다. 공정 사용량을 보장하고, 백엔드 자원을 보호하고, 외부 비용을 통제하고, 동시 작업 수를 제한하는 데 사용할 수 있습니다. 목적이 다르면 관찰할 지표와 실패 응답도 달라집니다.저는 엔드포인트마다 ‘무엇..

새 런타임 기능을 보면 곧바로 기존 프로젝트에 적용해 보고 싶어집니다. 하지만 운영 서비스에서는 기능이 빠르다는 기대보다 빌드·디버깅·라이브러리 호환성·롤백이 먼저입니다..NET 11의 Runtime Async는 이 글을 쓰는 시점에 프리뷰 문서에서 확인되는 기능입니다. 정식 출시 전까지 사양이 바뀔 수 있으므로, 아래 내용은 도입 권고가 아니라 실험 범위를 정하는 체크리스트로 읽어 주시기 바랍니다.프리뷰 기능은 서비스와 격리해 확인합니다첫 실험은 운영 코드의 브랜치가 아니라 작은 샘플 프로젝트에서 시작합니다. 동일한 SDK와 런타임을 사용하고, 기존 async/await 코드와 새 방식의 호출 경로를 나란히 둡니다. 결과가 다르면 어느 계층에서 달라졌는지 추적할 수 있어야 합니다.실험 환경에는 프로젝트..

느리다는 문의를 받고 로그를 열었는데 아무것도 못 찾은 적이 있습니다. 로그에는 요청이 들어왔다는 줄과 응답을 보냈다는 줄이 있었고, 그사이에 무슨 일이 있었는지는 비어 있었습니다. 데이터베이스가 느렸는지, 외부 API가 늦게 답했는지, 제 코드가 오래 걸렸는지 구분할 방법이 없었습니다.로그 도구를 바꾼다고 해결되는 문제가 아니었습니다. 필요한 것은 하나의 요청이 어디를 거쳐 얼마나 걸렸는지 이어 보는 방법이었고, 그게 분산 추적입니다. .NET 11에서는 ASP.NET Core가 OpenTelemetry 태그를 네이티브로 방출하는 방향으로 가고 있어서, 이 부분을 다시 정리해볼 만한 시점이 됐습니다. 아래 .NET 11 관련 내용은 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다.세 축은 각자 답하는 ..

엔드포인트 목록을 열어놓고 하나씩 세어본 적이 있습니다. 화면 하나를 만들려고 라우트 파일을 만들고, 요청 타입을 정의하고, 클라이언트에서 부를 함수를 또 만들고, 응답 타입을 다시 선언하는 일이 반복되고 있었습니다. 실제 로직은 열 줄인데 그걸 감싸는 껍데기가 세 배쯤 됐습니다.Server Actions로 몇 개를 옮겨보기 시작한 건 그 목록을 본 다음이었습니다. 결론부터 말하면 절반쯤 옮겼고 나머지는 그대로 두었습니다. 이 글은 무엇을 옮겼고 무엇을 왜 남겼는지에 대한 기록입니다.옮기면서 실제로 줄어든 것가장 크게 체감한 것은 같은 타입을 두 번 쓰지 않아도 된다는 점이었습니다. 서버 함수를 직접 호출하는 형태가 되니 인자와 반환 타입이 그대로 이어집니다. 필드 이름을 바꿨을 때 컴파일 단계에서 잡히..

프로젝트에서 useMemo와 useCallback이 몇 개나 쓰이고 있는지 세어본 적이 있습니다. 생각보다 많았고, 더 문제는 그중 상당수가 왜 붙였는지 기억나지 않는 것이었습니다. 언젠가 성능이 걱정돼서 붙였고, 그 뒤로 아무도 건드리지 않은 코드였습니다.React Compiler가 자리를 잡으면서 이 코드들을 어떻게 할지 결정해야 하는 시점이 왔습니다. 컴파일러가 알아서 메모이제이션을 해준다면 손으로 붙인 것들은 중복입니다. 다만 전부 지우면 되는 것도 아닙니다. 여전히 손으로 남겨야 하는 자리가 있고, 그 구분을 모르고 일괄 삭제하면 조용히 느려지거나 이상하게 동작합니다.컴파일러가 해주는 일과 해주지 않는 일React Compiler는 컴포넌트와 훅을 분석해서 렌더 사이에 재사용할 수 있는 값을 자..

서버 지표를 보다가 이상한 장면을 만난 적이 있습니다. 트래픽은 그대로인데 CPU 사용률만 눈에 띄게 올라가 있었습니다. 원인을 좁혀보니 압축 설정을 바꾼 배포가 그 시점에 있었습니다. 응답 크기를 줄이려고 켠 옵션이 CPU를 대신 먹고 있었던 겁니다.응답 압축은 켜기만 하면 이득처럼 보이지만 실제로는 거래입니다. 네트워크로 나가는 바이트를 줄이는 대신 프로세서 시간을 씁니다. 이 거래가 이득인지 손해인지는 서비스마다, 심지어 엔드포인트마다 다릅니다..NET 11에서는 Zstandard 압축이 들어옵니다. Brotli에 준하는 압축률을 더 낮은 CPU 비용으로 얻는다는 성격의 알고리즘입니다. 이 글에서는 압축의 기본 거래 구조를 먼저 짚고, Zstandard가 1인 서비스에서 어떤 상황에 실익이 되는지,..