async function*를 처음 봤을 때 *가 함수 포인터처럼 보였고, 호출해도 본문이 실행되지 않았다. 동작을 외우기 전에 물었다. 스트림을 읽는 코드를 왜 제너레이터로 쓰나. 기능별로 나눠 쓰는 쪽은 반복자로만 받는 구조, 지역 변수가 되는 상태, 소비 속도가 스트림까지 전달되는 당김, 그리고 끝까지 따라오는 정리를 직접 돌려 보며 정리한다.
[Read More]
마이크로태스크는 왜 렌더링을 양보하지 않는가 — 브라우저에서는 화면이, 서버에서는 모든 요청이 멈춘다
Promise와 async/await는 비동기 코드를 동기처럼 읽히게 만들었지만, 마이크로태스크 큐가 빌 때까지 멈추지 않는다는 규칙 때문에 성능의 새 함정이 되기도 한다. 브라우저에서는 화면이, Node.js 서버에서는 모든 사용자의 요청이 같은 방식으로 멈춘다. 언제 막히는지, 어떻게 양보하고 옮기고 재는지를 문서로 확인하며 정리한다.
[Read More]
while(true)는 돌고 있지 않았다 — 호출 스택, 힙, 태스크 큐, 마이크로태스크 큐, 그리고 누가 await를 깨우는가
스트림을 읽는 while(true) 루프가 왜 UI를 막지 않는지 따라가다, await에서 멈춘 함수가 어디로 가는지, 기다리는 Promise는 큐에 있는지, 그 함수를 누가 깨우는지까지 왔다. 호출 스택, 힙, 태스크 큐, 마이크로태스크 큐가 각자 무엇을 맡는지 문서로 확인하며 정리한다.
[Read More]
releaseLock 한 줄을 cancel로 바꿨더니 409가 사라졌다 — fetch의 body는 처음부터 스트림이었다
스트리밍 응답을 읽다 그만둘 때 releaseLock()을 cancel()로 바꾼 한 줄의 이유를 따라가다 보니, await fetch가 언제 풀리는지, response.body가 무엇인지, 예전 XMLHttpRequest의 progress와 버퍼는 무엇이 달랐는지까지 왔다. fetch를 조사하고, XHR과 쓰기와 보안을 비교하고, 지금 Next.js 서버와 브라우저에서 fetch 스트림을 쓸 때 볼 것을 정리한다.
[Read More]
자동화는 '당신 일'이라 했고, 옆 팀은 '전달받은 게 없다'고 했다 — 302 하나가 내 일이 되기까지
요청 봇이 팀 일정에 없던 302 리다이렉트 하나를 내 일로 넘겼고, 같은 일의 티켓은 이미 옆 팀에 있었고, 옆 팀 코드라 넘겼더니 전달받은 게 없다는 답이 돌아왔다. 결국 에이전트로 끝까지 처리했지만 사람도 자동화도 이 일의 흐름은 다 읽지 못했고, 다음엔 '당신 일'을 받은 뒤 무엇부터 물을지 남긴다.
[Read More]
2주면 지울 플래그를 91일 만에 지웠다 — 하는 김에 가져간 일, 바뀐 사람, 그리고 다시 나
전환이 끝나면 2주에서 한 달 안에 지우려던 피처 플래그가 91일 동안 남았다. 첫 제거는 QA 에서 막혔고, 다른 작업을 하는 김에 지워 주겠다던 일은 그 작업이 바뀌고 담당자가 옮기고 퇴사하는 사이 멈췄다. 그동안 다들 숫자가 빨갛게 뜨는 장바구니 CLS 를 봤다. 날짜순으로 사실만 적고, 숫자가 없는 일을 어떻게 챙겨야 하는지 남겼다.
[Read More]
테스트가 실패했다고, 버그를 잡은 것은 아니다
테스트가 추가된 main과 구현을 바꾼 브랜치를 합치자, 배포 준비 과정의 CI가 실패했다. 모킹과 기대값을 고친 과정을 따라가며, 결함을 막는 테스트와 변경 비용을 늘리는 테스트를 어떻게 구분할지 정리했다.
[Read More]
승인은 빨라졌는데, 팀의 급한 일은 그대로였다
AI로 테스트와 리뷰를 빠르게 만들어도 팀의 급한 일이 줄지 않을 수 있다. 작업의 필요성, 동료의 검토와 유지보수에 드는 시간, 완료까지의 책임을 따지지 않고 산출물만 기여로 인정할 때 생기는 문제를 돌아본다.
[Read More]
다익스트라는 손으로 썼다 — 만드는 비용이 0이 된 날, 걸러내는 쪽이 일이 된다
하루 사이에 테스트 PR 열한 건, 자동 리뷰 예순세 건, 내 PR 에 지적 열아홉 건이 쏟아졌다. PR 도 테스트도 리뷰도 리뷰 답글도 만드는 비용은 0에 가까워졌는데, 읽고 가려내는 비용은 그대로 사람에게 남았다. 워드프로세서를 쓰지 않았다는 다익스트라 이야기에서 시작해, 한 사람이 6주 동안 올린 테스트 PR 쉰네 건과 지적 여덟 건을 한 시간 안에 가려낸 과정, 리뷰 밖에서 사람이 찾은 진짜 결함, 그리고 걸러내는 자리마다 붙여야 할 절차를 적었다.
[Read More]
리뷰가 열 개 달렸는데, 방향을 바꾼 건 측정 한 번이었다 — AI 리뷰를 고치고 있는 이야기
한 PR 에 리뷰가 열 건 넘게 붙고 승인이 여섯 번 찍혔지만, 설계를 바꾼 건 서버를 직접 찔러 본 측정 한 번이었다. 그걸 발견하고 내 리뷰 에이전트를 어떻게 고치고 있는지, 그리고 AI 리뷰가 지금 가진 네 가지 문제를 적었다.
[Read More]
AI 가 리뷰하고, 나는 AI 로 승인했다 — 목적 없는 테스트가 지키지 못하는 것
테스트 PR 에 '회귀 방지 가치가 있다'는 승인 답글을 AI 로 달고 나서, 그 테스트들이 결정적인 에러를 알려 준 적이 있었는지 한 달 반 치 기록을 재 봤다. AI 활용이 목적 없는 테스트와 리뷰로 이어질 때 무엇이 남는지, 그리고 나는 무엇을 묻지 않았는지 적었다.
[Read More]
팝업 하나를 피처 플래그로 깔끔하게 막았다. 그런데, 싸늘하다 — 하지 말아야 할 구현이 제품 코드에 쌓이는 방식
결제완료 팝업을 기간 지정 피처 플래그로 막는 작업을 AI 와 함께 검증하며 PR 을 연 지 세 시간 남짓 만에 운영까지 냈는데, 돌아보니 하지 말아야 할 구현이었다. 주인 없는 팝업, 거절할 수 없는 요구, 끝나지 않는 실험을 따라가며 그런 구현이 제품을 어떻게 짓누르는지와 요청을 받을 때 먼저 던질 질문을 적었다.
[Read More]