본문 바로가기

분류 전체보기

 (79)
Next.js App Router .env 완전 정복: NEXT_PUBLIC, 로드 순서, 빌드·런타임 구분 가이드 왜 .env가 먼저 정리돼야 할까요 Next.js App Router에서 .env 설정이 흔들리면 클라이언트에 노출되면 안 되는 값이 공개되거나, 환경값이 빌드 시점에 고정되어 배포 후 수정이 먹지 않는 문제가 생깁니다. 특히 NEXT_PUBLIC 접두사, 로드 순서, 빌드·런타임 구분을 놓치면 디버깅이 길어집니다. 초기 설정 단계에서 “어떤 값이 브라우저에 노출되는가”와 “언제 읽혀서 캐싱되는가”만 명확히 잡아두면 대부분의 실수를 예방할 수 있습니다. 이 글은 그 두 가지를 짧은 규칙과 예시로 정리해 바로 적용할 수 있게 돕습니다. 실무에서는 API 엔드포인트, 공개 키, 비밀 키처럼 성격이 다른 값이 섞여 있습니다. 공개 가능 값은 브라우저로 보내고, 비밀 값은 서버 전용으로 남기는 선을 먼저 긋는 ..
Playwright + browser-use로 웹 태스크 LLM 자동화: 셀프힐링 로케이터와 검증 루프 패턴 시작 가이드 왜 이 조합이 필요한가 웹 업무를 LLM으로 자동화하면 가장 먼저 부딪히는 문제가 잦은 UI 변경과 예외 상황입니다. 버튼 텍스트나 DOM 구조가 조금만 바뀌어도 스크립트가 멈추는 일이 반복됩니다. Playwright는 안정적인 브라우저 제어와 테스트 친화적 로케이터를 제공합니다. 여기에 browser-use 같은 LLM 에이전트를 얹으면 “사람처럼” 탐색하고 선택지를 판단하는 흐름을 만들 수 있습니다. 이 글은 두 도구로 초보자도 적용하기 쉬운 최소 패턴을 제안합니다. 셀프힐링 로케이터로 선택 실패를 줄이고, 짧은 검증 루프로 결과를 즉시 확인해 실패를 빠르게 되돌리는 방식을 다룹니다. > 안티패턴: 처음부터 모든 과정을 LLM에게 완전 위임하면 디버깅이 어려워집니다. 기본 경로는 Playwright로..
CSS Anchor Positioning + Popover로 셀렉트·드롭다운·툴팁 무자바스크립트 구현 가이드 JS 없이도 동작하는 인터랙션이 왜 필요할까 현업 화면에서 셀렉트, 드롭다운, 툴팁은 작지만 자주 쓰는 요소입니다. 이 작은 요소를 위해 번들 크기와 이벤트 핸들러를 늘리는 일은 유지보수 부담으로 돌아옵니다. CSS Anchor Positioning과 Popover는 클릭/포커스 같은 상호작용과 위치 배치를 CSS만으로 처리하도록 돕습니다. 자바스크립트를 줄이면 초기 로드가 가벼워지고 접근성 속성 관리도 단순해집니다. Why now 관점에서, 최신 브라우저들이 두 기능을 빠르게 채택해 폴리필 의존도가 줄었습니다. 실무에서는 “간단한 열림/닫힘 + 기준 요소에 맞춘 위치” 요구가 대부분이어서 이 조합이 비용 대비 효율적입니다. > 주의: 팀이 IE11 같은 구형 브라우저를 반드시 지원한다면 대체 전략을 준..
OffscreenCanvas + Web Workers + WebAssembly SIMD로 고FPS 차트·시뮬레이션 렌더링 시작하기 왜 프런트에서 프레임이 끊길까 대시보드 차트가 많아지거나 입자 시뮬레이션처럼 계산량이 커지면 메인 스레드가 막혀 스크롤과 줌이 함께 느려집니다. 사용자 입장에서는 60FPS가 20~30FPS로 떨어지는 순간 체감 품질이 급격히 나빠집니다. 이 글은 브라우저에서 고FPS를 유지하기 위한 첫걸음을 제공합니다. OffscreenCanvas로 렌더링을 메인 UI와 분리하고, Web Workers로 계산을 백그라운드로 보내며, WebAssembly SIMD로 수치 연산을 빠르게 처리하는 접근을 다룹니다. 목표는 어려운 최적화 이론이 아니라, “왜 필요한지 → 어디에 쓰는지 → 시작 방법”을 순서대로 이해하는 것입니다. 실무 입문자도 바로 적용할 수 있는 최소 설정과 예시 흐름을 제시합니다. > 트레이드오프: 렌더..
Speculation Rules API 실전 가이드: prerender/prefetch 전략과 안전 가드 정리 느려진 첫 클릭, Speculation Rules로 줄일 수 있을까요? 사용자는 링크를 누르는 순간 바로 다음 화면이 뜨길 기대합니다. 하지만 라우팅, 데이터 패칭, JS 번들 로드가 겹치면 첫 클릭 체감이 무겁습니다. Speculation Rules API는 미리 불러오거나 미리 렌더링해 체감 속도를 앞당기는 브라우저 표준입니다. 이 글은 prerender와 prefetch를 언제, 어디에, 어떤 기준으로 적용할지 실무 관점에서 정리합니다. “무조건 다 미리 로드”가 아니라, 전환 가능성이 높은 링크만 선별하는 안전 가드까지 다룹니다. 왜 지금일까요? 크롬 등 주요 브라우저가 해당 API를 지원하면서, 기존 링크 프리패치 스크립트보다 설정이 단순해졌습니다. 반면 잘못 쓰면 불필요한 트래픽과 로그인 상태..
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 변화 -> 의존성 추적 -> 컴파일러 수준의 스킵 결정으로 이어집니다. 수동 메모와 컴파일러의 판단이 충돌하면 불필요한 캐시 유지, 구독 누수, 의존성 불일치 같은 비용이 생깁니다. 도입 판단을 미루면 코드베이스는 더 많은 수동 메모 레이어를 쌓게 되고, 나중에 걷어낼 때 회귀 테스트 범위가 기하급수적으로 ..

티스토리툴바