실제 커머스 프론트엔드의 성능 개선을 바탕으로 썼다. 조직과 저장소를 식별할 수 있는 정보는 걷어내고 요청 흐름과 판단만 남겼다.
[Read More]
content-visibility: auto를 적용했더니 position: fixed가 고정되지 않았다
실제 커머스 프론트엔드의 성능 실험을 바탕으로 썼다. 조직과 저장소를 식별할 수 있는 정보는 걷어내고 재현 가능한 구조만 남겼다.
[Read More]
동시에 처리한다는 것: AI 에이전트와 작업 규칙으로 병렬 개발하기
실제 업무에서 겪은 흐름을 바탕으로 썼다. 조직, 저장소, 티켓, 사람을 식별할 수 있는 정보는 걷어내고 구조와 판단만 남겼다.
[Read More]
얇은 훅은 혼자 오지 않는다: 훅이 쌓이고 엮일 때
지난 글에서 제값을 하지 못하는 얇은 커스텀 훅은 만들지 말자고 했다.
그런데 레거시 코드를 한참 돌아다녀 보니 얇은 훅은 혼자 오지 않았다. 쌓이고, 엮이고, 서로를 감쌌다. 이번에는 그렇게 마주친 유형을 사례로 정리한다. 코드는 모두 익명화하고 구조만 남겼다.
[Read More]
레거시를 다음으로 옮기는 전환용 피처 플래그, 지우기 쉽게 설계하기
커머스 프론트엔드에서 목록 항목에 붙는 조건부 표시(배지)의 데이터 소스를 바꾸는, 작아 보이는 작업이었다. 그런데 그 과정에서 피처 플래그를 어떻게 설계해야 나중에 아프지 않은지, 그리고 레거시 구조가 어떻게 작은 변경을 긴 작업으로 만드는지를 다시 배웠다. 기능 자체는 익명화하고 구조와 판단만 남긴다.
[Read More]
침묵은 중립적인 기록이 아니었다
내부 서비스의 장애 대응 경험을 바탕으로 썼다.
조직과 개인을 특정할 수 있는 이름, 링크, 번호와 수치는 제거했다.
[Read More]
TypeScript 7 도입 전에 팀이 확인할 것들
TypeScript 7이 정식 출시됐다. 가장 눈에 띄는 변화는 새로운 타입 문법이 아니다. TypeScript로 작성했던 컴파일러와 언어 서비스를 Go 기반 네이티브 구현으로 옮겼고, 공식 사례에서는 전체 빌드가 대체로 8~12배 빨라졌다.
[Read More]
AI 도구를 바꾸는 비용을 낮추는 법 (2) — Cursor에서 Claude로, 구체 사례
지난 글에서는 “규칙만 분리해 두면 도구가 바뀌어도 다시 만들 것은 많지 않다”는 원칙을 정리했다.
이번 글은 그 원칙을 Cursor → Claude Code로 실제 옮기며 부딪힌 구체 사례들이다.
사내 티켓·도메인·패키지·민감 정보는 빼고, 구조와 판단 기준만 남긴다.
[Read More]
AI 도구를 바꾸는 비용을 낮추는 법
내부 개인 설정 전환 작업을 바탕으로 썼다.
사내 티켓·도메인·민감 정보는 빼고, 구조와 판단 기준만 정리한다.
[Read More]
이상한 얇은 훅 만들지 말고, 그냥 useEffect 쓰자
웹뷰 ↔ iframe postMessage 브릿지 코드를 읽다 든 생각.
코드는 익명화했고, 실제 서비스/도메인/기능명은 전부 일반화했다.
[Read More]
앱 WebView에서 장바구니가 많을 때 — 로그가 없으면 FE가 보는 것
커머스 앱 WebView에서 장바구니 개수가 많을 때만 화면이 멈춘다는 VOC가 들어왔다. Sentry·Firebase에는 아무것도 없었다.
이 글은 그때 팀 채널에서 정리했던 증상·가설·시도를 회사 식별 없이 다른 팀도 쓸 수 있는 체크리스트로 옮긴 것이다.
선행: WebView와 UA · HTML-in-Canvas·capability
[Read More]
긴급 문구 수정과 QA가 겹친 날 — 조사는 Cursor, 구현은 손으로
같은 오전, 슬랙 스레드가 두 개 붙었다.
하나는 QA 확인 요청, 하나는 “오늘 안에 텍스트만 고쳐 주세요” 긴급 건.
예전 같았으면 조사부터 막혔을 텐데, 이번엔 역할만 나눠도 금방 끝났다.
[Read More]