Ayden's Journal

에이든 피자는 처음부터 복잡한 시스템을 만들 생각이 없었다. 처음에는 메뉴 몇 개만 만들면 됐다. 그런데 손님은 커스텀 주문을 넣기 시작했고, 주방은 상태를 나눠야 했고, 결제와 배달앱과 알림이 하나씩 붙었다. 코드도 가게를 닮는다. 장사가 잘될수록 이상하게 더 쉽게 망가진다. 디자인…

에이전트를 많이 만든다고 작업이 자동으로 잘 굴러가지는 않는다. 오히려 역할이 겹치고, 권한이 과하게 열리고, 어느 순간부터는 사람이 에이전트들을 관리하느라 더 바빠지는 일이 생긴다. OpenCode와 OMO(Oh My OpenAgent)를 함께 쓸 때 필요한 것은 더 많은 프롬프트가…

DI 컨테이너는 겉으로 보면 꽤 조용한 도구다. 클래스를 하나 달라고 하면 인스턴스가 나오고, 모듈을 부트스트랩하면 provider들이 알아서 이어진다. 문제는 “알아서”라는 단어가 커질수록 코드가 점점 마법처럼 보인다는 데 있다. 마법은 데모에서는 멋지지만, 장애가 나면 갑자기 로그를…

이 포스트는 Aurora Scharff가 자신의 블로그에 올린 Component Architecture for React Server Components 게시글을 번역한 것이다. 번역하는 과정에서 다소 의역이 있을 수 있으며, 일부 번역에는 사견이 포함되어있기도 하다. React의 역사…

상황 어느날 서비스를 살펴보시던 팀장님께서 이런 말씀을 slack에 남기셨다. 진호님, 예측 차트에서 zoom을 계속하면 어느 순간 라인 차트가 아니라 단일 스캐터 차트처럼 보이는 데, 이거 수정하면 좋을 거 같아요. 어느정도 zoom을 하면 그 이후로는 zoom이 안 되도록 할 수 없…

상태 관리 코어를 작게 유지하려고 하면 곧바로 한 가지 질문을 만나게 된다. 상태를 읽고, 바꾸고, 구독하게 해주는 것만으로 충분한가. 처음에는 충분해 보인다. 하지만 실제 애플리케이션으로 들어가면 업데이트를 기록하고 싶고, 잘못된 값은 막고 싶고, 들어온 값을 정규화하고 싶고, 상태가…

외부 상태는 프레임워크 내부에서 만들어진 상태가 아니다. React의 useState, Vue의 ref, Svelte의 $state, Solid의 createSignal처럼 프레임워크가 직접 소유하고 추적하는 값이 아니라, 프레임워크 바깥에서 먼저 존재하고 바깥에서 변하는 값이다. We…

상태 관리 라이브러리를 볼 때 먼저 눈에 들어오는 것은 보통 기능 목록이다. selector가 있는지, devtools와 연결되는지, persistence를 지원하는지, React 훅이 준비되어 있는지 같은 것들 말이다. 그런데 @ilokesto/store의 Store 클래스를 보면 질…

React 앱의 라우팅은 처음에는 별일 아닌 것처럼 보인다. /about으로 가면 About 화면을 보여주고, /posts/1로 가면 1번 글을 보여주면 된다. 문제는 앱이 조금만 커져도 URL이 더 이상 주소표시줄의 문자열로만 남아 있지 않다는 데 있다. URL은 권한의 경계가 되고,…