프론트엔드7분
iOS 사파리 탭이 반복해서 죽을 때: 폰 시스템 로그로 WebContent 메모리 읽기
아이폰에서 랜딩 페이지 하나를 가로로 눕혀 스크롤하면 탭이 죽었습니다. 사파리는 「문제가 반복적으로 발생했습니다」를 띄웠고, 크롬은 빈 화면을 남겼습니다. 세로로는 멀쩡했고, 가로에서도 가끔 죽었으며, 크게 확대하면 더 잘 죽었습니다. 서버는 200을 돌려주고 있었습니다.
전체 카테고리
프론트엔드 34개 글
사용자가 직접 만나는 화면을 구현하는 방법을 다룹니다. 레이아웃과 상호작용, 접근성과 성능을 함께 살펴봅니다.
먼저 읽어볼 글
이 순서로 살펴보세요
우리 서비스에 적용할 계획이 있으신가요?
홈페이지·웹서비스 개발 살펴보기 →전체 글
- 프론트엔드9분
GA4 client_storage: 'none'은 정말 쿠키를 막을까?
두 달 전 이 블로그에 「GA4 쿠키 없이 쓰기」라는 글을 썼습니다. clientstorage: 'none' 으로 쿠키 저장을 끄고, 자체 분석이 쓰던 익명 ID 를 clientid 로 넘기면 쿠키 0개로 GA4 를 쓸 수 있다는 내용이었습니다. 어제 운영 사이트의 쿠키 목록을 열어 보니 ga 가 있었습니다.
- 프론트엔드14분
GA4 Measurement Protocol: gtag.js 없이 서버에서 이벤트 보내기
랜딩 페이지의 전송량을 파일 단위로 쪼개 보다가, 가장 큰 파일이 우리 코드가 아니라는 것을 알았습니다. Google Analytics 의 gtag.js 였고, 방문 한 번에 176KB 를 받고 있었습니다. 페이지 전체가 1,094KB 였으니 16% 가
- 프론트엔드8분
가상 스크롤로 장부 화면 만들기: 느린 원인은 Intl.DateTimeFormat
제조 공장 한 곳의 생산 관리 앱을 만들고 있습니다. 그 안에 수주대장이라는 화면이 있는데, 공장이 쓰던 생산 엑셀을 칸 순서까지 그대로 옮긴 표입니다. 1년치만 봐도 4천 줄이 넘습니다. 처음에는 100줄씩 쪽으로 나눠 두었습니다. 직접 써 보다가 이 부분은 확실히 엑셀보다 불편하다는 생각이 들었습니다. 엑셀은 수천 …
- 프론트엔드10분
코드 분할과 지연 로딩: 기능을 지우지 않고 첫 화면을 가볍게 하는 법
「체스, 지뢰찾기, 스티커 메모를 빼면 앱이 가벼워지고 빨라질까?」 웹 데스크톱에 메모 앱을 하나 더 붙인 뒤 이 질문이 나왔습니다. 기능이 늘수록 첫 화면이 무거워지는 건 당연해 보였고, 가장 쉬운 답은 덜 쓰는 앱을 지우는 것이었습니다.
- 프론트엔드4분
iframe 안의 CTA 버튼: 창 안에서는 문의 링크를 숨기는 규칙
듀오랩스의 데모 앱들은 두 곳에서 창으로 열립니다. 하나는 홈페이지의 데모 모달이고, 다른 하나는 브라우저 안에서 도는 웹 데스크톱(os.duolabs.co.kr)의 창입니다. 둘 다 iframe입니다.
- 프론트엔드9분
웹 워커를 언제 꺼내는가: 지뢰찾기와 체스의 차이
브라우저 안에서 도는 데스크톱을 만들고 있습니다. 창과 Dock과 터미널은 있는데 그 위에 올릴 앱이 없어서, 유틸리티 칸에 지뢰찾기를 하나 넣었습니다. 잘 돌길래 다음으로 체스를 만들기 시작했는데, 규칙을 다 짜고 엔진을 붙이려는 자리에서 한 번 멈춰야 했습니다. 지뢰찾기에는 없던 문제가 있었기 때문입니다.
- 프론트엔드10분
React error 300: 조건부 return 뒤의 훅과 가끔 나는 오류
관리자 화면에 들어갈 때마다 오류 카드가 한 번씩 떴습니다. 「문제가 발생했습니다. 잠시 후 다시 시도해 주세요.」 다시 시도를 누르면 그냥 들어가집니다. 그래서 한동안 넘겼습니다.
- 프론트엔드5분
iframe 안의 분석 스크립트: 자사 사이트를 창으로 띄웠을 때 생기는 일
저희 홈페이지를 저희가 만든 브라우저 안 데스크톱(os.duolabs.co.kr)에 창 하나로 띄웠습니다. 데모를 한 번 열어 본 사람이 방문 기록에는 두 번 찍혔습니다. 처음에는 창을 두 개 여니까 그렇겠거니 했는데, 세어 보니 문제는 개수가 아니라 그 숫자가 우리 통계 전부를 통과하고 있다는 쪽이었습니다.
- 프론트엔드9분
WebP가 JPEG보다 커질 때: 사진 종류별 WebP·AVIF 실측
인쇄기 롤러 견적 사이트를 만들면서 화면에 나가는 사진을 전부 WebP로 정했습니다. 제품 사진 네 장으로 재 보고 내린 결론이었습니다. 그 뒤에 설계도 사진 세 장이 들어왔고, 같은 스크립트에 그대로 태웠습니다. 이 글을 쓰려고 다시 재 보니 그중 두 장은 WebP가 JPEG보다 컸습니다.
- 프론트엔드8분
웹 퍼블리셔와 프론트엔드 개발자 차이: 산출물이 갈리는 지점
견적서에 이런 두 줄이 나란히 놓이는 경우가 있습니다.
- 프론트엔드10분
GA4 쿠키 없이 쓰기: client_id를 직접 넘기는 구성
방문 분석은 하고 싶은데 쿠키 동의 팝업은 만들기 싫었습니다. 배너를 하나 붙이면 화면에 층이 하나 더 생기고, 동의 상태를 저장하고 갱신하고 철회까지 받는 코드가 따라옵니다. 방문자가 하루 수십 명인 회사 사이트에 그만한 장치를 두는 것은 과합니다.
- 프론트엔드16분
Electron 배포 가이드: Windows 설치부터 macOS 공증까지
Electron 앱은 개발 환경에서 실행하는 것과 사용자에게 전달하는 과정이 꽤 다릅니다. 개발 중에는 명령 하나로 앱을 열 수 있지만, 실제 배포에서는 운영체제별 패키징과 설치 파일, 코드 서명, macOS 공증, 자동 업데이트까지 연결해야 합니다.
- 프론트엔드12분
Next.js와 Electron 비교: 같은 React, 다른 실행 구조
Next.js와 Electron은 둘 다 JavaScript와 TypeScript, React 생태계를 활용합니다. 화면만 만들 때는 꽤 비슷해 보입니다. 컴포넌트를 나누고 상태를 관리하며, npm 패키지를 설치하고 개발자 도구로 화면을 확인하는 흐름도 익숙합니다.
- 프론트엔드7분
Next.js 웹앱을 Electron 데스크톱 앱으로 만들기 전에 따져볼 것
사내 웹 도구를 쓰다 보면 어느 순간 "이거 그냥 데스크톱 앱으로 만들면 안 되나"라는 말이 나옵니다.
- 프론트엔드10분
Leaflet 지도가 느려지는 3가지 원인: React key, SVG 렌더러, 가드 위치
지도 위에 H3 육각 격자를 얹은 화면을 만들었습니다. 셀을 누르면 인접한 여섯 셀이 함께 칠해지는, 영업 구역을 나눠 보는 화면입니다.
- 프론트엔드8분
데스크톱 AI 화면을 모바일에서 과감히 제거한 이유
데스크톱에서 잘 작동하는 AI 인터페이스를 모바일 화면에 그대로 줄이면 기능은 남지만 경험은 쉽게 무너집니다. 사이드바, 대화, 참고 문헌을 동시에 보여주는 3단 구조는 넓은 화면에서는 강력하지만 작은 화면에서는 탐색과 스크롤이 서로 경쟁합니다.
- 프론트엔드13분
iOS Safari 모바일 버그 3종 해결기: 헤더 잘림 · 흰 화면 · 가로 넘침
같은 날 확인된 세 증상은 원인이 서로 달랐으며, 모두 해당 테스트 환경에서 데스크톱 Chrome과 다르게 나타난 WebKit 관련 동작이었습니다.
- 프론트엔드9분
디자인 시스템을 씌우기 전에 레이아웃 틀부터 맞춰야 하는 이유
같은 디자인 시스템을 사용하는데도 어떤 화면은 정돈되어 보이고, 어떤 화면은 미묘하게 어긋나 보일 때가 있습니다. 색상과 버튼 모양이 같아도 페이지 폭, 여백, 제목 위치, 입력 필드의 구성이 제각각이면 전체 인상은 쉽게 흐트러집니다.
- 프론트엔드10분
디자인 시스템을 복제하지 않는 방법: Polaris 구조와 CSS 테마로 다시 설계한 DEUX
디자인 시스템이 두세 개로 늘어나면 가장 먼저 보이는 차이는 색상과 모서리입니다. 그래서 새로운 시스템을 만들 때 기존 버튼과 카드의 색만 바꾸는 일로 시작하기 쉽습니다. 하지만 시간이 지나면 각 시스템 폴더에 Button, Input, Dialog, Chart 구현이 하나씩 생깁니다. 처음에는 독립성이 높아 보이지만,…