본문 바로가기

분류 전체보기

 (82)
bfcache 최적화 체크리스트: unload 제거, pagehide/pageshow 전환, DevTools 검사 방법 뒤로 가기 속도가 느린 이유, bfcache가 막혀서입니다 사용자가 브라우저 ‘뒤로 가기’를 눌렀을 때 화면이 즉시 뜨지 않고 다시 로딩된다면, bfcache(뒤로/앞으로 캐시)가 비활성화되었을 가능성이 큽니다. 이 순간 이탈률이 높아지고 세션당 페이지뷰가 줄어들 수 있습니다. bfcache는 이전 페이지의 상태를 통째로 보관해 즉시 복원합니다. 리스트 → 상세 → 뒤로 가기 같은 흐름에서 체감 속도를 크게 올려줍니다. 문제는 오래된 습관대로 unload 이벤트를 쓰거나, 상태 정리를 잘못하면 브라우저가 bfcache를 아예 끊어버린다는 점입니다. 이 글은 unload를 지우고 pagehide/pageshow로 전환하며, DevTools로 원인을 정확히 검사하는 체크리스트를 제공합니다. > 안티패턴: 분..
Tauri 2 자동 업데이트 채널 설계: 서명·릴리스 파이프라인·롤백 전략 가이드 왜 지금 업데이트 채널 설계가 필요한가 Tauri 2로 배포를 시작하면 업데이트가 코드 배포가 아니라 운영 행위가 됩니다. 자동 업데이트 채널을 설계하지 않으면 보안 서명, 배포 타이밍, 롤백이 얽혀 장애 전파 속도가 패치 속도를 앞지릅니다. 데스크톱 앱은 한번 설치되면 장기간 실행되고, 네트워크가 단절되거나 백그라운드 권한이 제한된 환경도 흔합니다. 안정·베타·캔리 같은 채널을 분리하고 서명·메타데이터·배포 파이프라인을 맞춰두면, crash 증가나 인증서 교체 같은 이벤트에 대응 범위를 좁힐 수 있습니다. 실무에서 부딪히는 비용은 명확합니다. 업데이트 서버 부하, 서명 키 보호, 이전 버전 호환성 유지가 새로 생기는 운영 비용입니다. 대신 채널·릴리스 규칙을 선제 설계하면 전체 사용자에게 일괄 배포하는..
React Compiler 도입 체크리스트: memo/useMemo 제거 기준과 회귀 테스트 전략 왜 지금 React Compiler를 도입 논의해야 하나 최근 React Compiler가 컴파일 단계에서 re-render 최소화를 자동으로 시도하면서, 수동으로 둘러친 memo/useMemo 최적화가 중복 투자일 수 있다는 문제가 떠올랐습니다. 잘못 남긴 메모 최적화는 유지보수 비용과 버그 회귀 리스크를 동시에 키웁니다. Under the Hood 관점에서 보면 데이터 흐름은 props/state 변화 -> 의존성 추적 -> 컴파일러 수준의 스킵 결정으로 이어집니다. 수동 메모와 컴파일러의 판단이 충돌하면 불필요한 캐시 유지, 구독 누수, 의존성 불일치 같은 비용이 생깁니다. 도입 판단을 미루면 코드베이스는 더 많은 수동 메모 레이어를 쌓게 되고, 나중에 걷어낼 때 회귀 테스트 범위가 기하급수적으로 ..
OpenAI Realtime API(WebRTC)로 브라우저 음성 챗봇 구축: 에페메럴 키와 Agents SDK 실전 가이드 브라우저에서 바로 말 걸 수 있는 챗봇이 왜 지금 중요한가웹에서 음성 챗봇을 구현하려면 STT/TTs, 스트리밍, 상태 동기화, 보안을 각각 붙여야 해 비용이 커집니다. OpenAI Realtime API(WebRTC)는 음성·텍스트·오디오를 한 세션으로 묶어 네트워크 왕복과 붙잡음(latency)을 줄이고, 에페메럴 키로 브라우저 보안 위험을 낮출 수 있습니다.Why now 관점에서, WebRTC는 브라우저 네이티브 오디오 경로와 P2P 전송으로 지연을 줄여 실시간 대화를 가능하게 합니다. 여기에 Agents SDK를 결합하면 프롬프트·도구 호출·메모리 같은 에이전트 상태를 서버에서 관리해 클라이언트 코드를 단순화할 수 있습니다.다만 트레이드오프가 분명합니다. WebRTC 연결 수립(ICE/DTLS)과..
ESLint v9 Flat Config 마이그레이션 가이드: typescript-eslint 연동 단계별 설명 왜 지금 Flat Config로 옮겨야 할까기존 .eslintrc 계열은 플러그인 해석 순서와 상속 체인이 복잡해 프로젝트마다 규칙 충돌이 잦았습니다. ESLint v9의 Flat Config는 단일 배열 기반 합성으로 규칙 적용 과정을 명시화해, 설정 비용은 늘지만 예측 가능성과 성능(캐싱·해석 비용 감소)을 제공합니다.타입스크립트를 쓰는 팀은 typescript-eslint의 파서·플러그인 조합과 타입 정보(프로젝트 참조) 전달이 핵심 과제입니다. Flat Config 전환 시 “파일 매칭 -> 파서/플러그인 바인딩 -> 타입 체크 규칙 분리” 흐름을 코드로 구조화해, tsconfig 경로·모노레포 워크스페이스 같은 엣지 케이스를 줄일 수 있습니다.다만 전환에는 리스크가 있습니다. 규칙 이름 변경, ..
React 19 Actions와 useOptimistic으로 폼 제출·낙관적 UI 마이그레이션 체크리스트 왜 지금 React 19 Actions/useOptimistic인가서버 액션과 낙관적 UI는 폼 제출 시 “요청 대기 → 리렌더 → 상태 동기화”로 생기는 지연과 깜빡임을 줄입니다. 기존 onSubmit + useState + 로더 패턴은 네트워크 왕복과 전역 상태 갱신이 겹치면 스피너 남용, 중복 전송, 충돌 해결 비용이 커집니다.React 19의 Actions와 useOptimistic은 요청 전 가상 상태를 먼저 반영하고, 응답이 오면 확정 상태로 스왑합니다. 흐름은 입력 → optimistic 적용 → 서버 액션 호출 → 성공/실패 반영으로 단순화되며, 렌더 비용과 대기 체감 시간을 동시에 낮출 수 있습니다.다만 낙관적 갱신은 실패 시 롤백, 중복 제출 방지, 비동기 레이스 처리 같은 운영 리스크..
NextAuth.js v5(App Router)로 구글·카카오 OAuth 소셜 로그인 구현 가이드 왜 NextAuth.js v5와 App Router 조합이 필요한가소셜 로그인을 붙이려면 보안, 리다이렉트, 토큰 갱신 같은 세부가 한꺼번에 얽힙니다. NextAuth.js v5(App Router)를 사용하면 구글·카카오 OAuth 흐름을 서버 액션과 라우트 핸들러로 일관되게 관리할 수 있습니다. Next 13+ 환경에서는 pages 라우팅과 설정 방식이 달라 혼선이 생기기 쉽습니다. 이 글은 v5 기준으로 폴더 구조, 환경변수, 콜백 처리까지 처음 적용하는 분도 실무에서 막히지 않도록 필요한 부분만 순서대로 다룹니다. 구글과 카카오는 승인 URL, 스코프, 프로필 매핑 규칙이 달라 같은 코드로 처리하면 오류를 만납니다. 각 프로바이더 차이를 최소한의 설정으로 맞추는 방법과, 팀 협업에서 재사용 가능한..
Wijmo FlexGrid ODataCollectionView로 서버사이드 필터·정렬·페이징 구현 가이드 클라이언트 처리의 한계와 OData 서버사이드의 필요성대용량 데이터를 FlexGrid에 바인딩하면 브라우저에서 필터·정렬·페이징 성능이 급격히 떨어집니다. 특히 수만 건 이상에서는 스크롤 지연과 메모리 부담이 눈에 띄게 커집니다. 이때 서버가 정렬·필터·페이징을 수행하고 클라이언트는 필요한 페이지만 받아오는 구조가 현실적인 해법입니다. 네트워크 트래픽과 렌더링 비용을 동시에 줄일 수 있습니다. ODataCollectionView는 OData 표준 쿼리(예: $filter, $orderby, $top, $skip)를 자동으로 구성해 서버 요청을 만들어 줍니다. 별도의 커스텀 API 없이도 FlexGrid와 자연스럽게 연동됩니다. 이 글은 처음 적용하는 분도 따라 할 수 있도록, ODataCollection..

티스토리툴바