실제 업무에서 겪은 협업을 바탕으로 썼다. 조직, 저장소, 티켓, 사람을 식별할 수 있는 정보는 걷어내고 구조와 판단만 남겼다.
[Read More]
평균이 빨라져도 성능 개선이 아닐 수 있다: 캐시와 이봉 분포 읽기
실제 성능 실험에서 마주친 측정값을 범위만 남겨 익명화했다. 특정 서비스의 성능 결과가 아니라, 결과를 해석하는 과정에 대한 글이다.
[Read More]
같은 정책, 다른 API: 화면마다 답이 달라지는 데이터 일관성 문제
실제 QA에서 발견한 정책 불일치 사례를 바탕으로 썼다. 서비스와 도메인은 일반화하고, 여러 API가 같은 사용자 정책을 표현할 때의 문제만 남겼다.
[Read More]
Feature Flag 장애가 흰 화면을 만들 때: return null 대신 실패 정책 설계하기
실제 QA 과정에서 만난 흰 화면 사례를 바탕으로 썼다. 특정 조직과 서비스, 내부 주소는 제거하고 재사용할 수 있는 구조만 남겼다.
[Read More]
장애 기록은 저장으로 끝나지 않는다: 검색되고 전파되고 대응을 시작해야 한다
실제 장애 기록 자동화와 외부 개발 플랫폼 장애를 함께 겪으며 든 질문을 정리했다. 특정 조직, 채널, 사람, 내부 시스템을 식별할 수 있는 정보는 걷어내고 기록 시스템의 완료 조건만 남겼다.
[Read More]
GitHub Actions가 멈췄다: 모든 자동화 대신 중요한 배포만 이중화하기
실제 GitHub Actions 장애를 겪으며 든 질문을 정리했다. 특정 조직, 저장소, 인프라를 식별할 수 있는 정보는 걷어내고 자동화의 성질과 운영 원칙만 남겼다.
[Read More]
AI와 Google Sheets로 필요한 앱 만들기: 아이 투약 기록 도구 공개
이 글에서 공개하는 도구는 보호자가 이미 의료진에게 안내받은 투약 계획을 기록하기 위한 개인용 보조 도구다.
약의 종류, 용량, 투약 간격, 휴약 여부를 판단하지 않으며 처방전과 의료진·약사의 안내를 대신하지 않는다.
[Read More]
API를 당장 바꿀 수 없다면 호출 시점을 당겨본다: prefetch라는 합법적 꼼수
실제 커머스 프론트엔드의 성능 개선을 바탕으로 썼다. 조직과 저장소를 식별할 수 있는 정보는 걷어내고 요청 흐름과 판단만 남겼다.
[Read More]
content-visibility: auto를 적용했더니 position: fixed가 고정되지 않았다
실제 커머스 프론트엔드의 성능 실험을 바탕으로 썼다. 조직과 저장소를 식별할 수 있는 정보는 걷어내고 재현 가능한 구조만 남겼다.
[Read More]
동시에 처리한다는 것: AI 에이전트와 작업 규칙으로 병렬 개발하기
실제 업무에서 겪은 흐름을 바탕으로 썼다. 조직, 저장소, 티켓, 사람을 식별할 수 있는 정보는 걷어내고 구조와 판단만 남겼다.
[Read More]
얇은 훅은 혼자 오지 않는다: 훅이 쌓이고 엮일 때
지난 글에서 제값을 하지 못하는 얇은 커스텀 훅은 만들지 말자고 했다.
그런데 레거시 코드를 한참 돌아다녀 보니 얇은 훅은 혼자 오지 않았다. 쌓이고, 엮이고, 서로를 감쌌다. 이번에는 그렇게 마주친 유형을 사례로 정리한다. 코드는 모두 익명화하고 구조만 남겼다.
[Read More]
레거시를 다음으로 옮기는 전환용 피처 플래그, 지우기 쉽게 설계하기
커머스 프론트엔드에서 목록 항목에 붙는 조건부 표시(배지)의 데이터 소스를 바꾸는, 작아 보이는 작업이었다. 그런데 그 과정에서 피처 플래그를 어떻게 설계해야 나중에 아프지 않은지, 그리고 레거시 구조가 어떻게 작은 변경을 긴 작업으로 만드는지를 다시 배웠다. 기능 자체는 익명화하고 구조와 판단만 남긴다.
[Read More]