mirabo01 님의 블로그

요즘 개발자들 사이에서 Cursor 2.0 이야기가 많이 들리더군요. 예전 버전에서도 꽤 괜찮다는 평가가 있었는데, 이번 업데이트는 확실히 ‘다른 단계’에 올라섰다는 느낌입니다.저도 관련 소식을 찾아보다가, “이건 그냥 코드 자동 완성이 아니라, 진짜로 개발 과정을 함께하는 도구”라는 생각이 들었어요. 이번 글에서는 Cursor 2.0이 어떤 방향으로 바뀌었는지, 그리고 실제로 우리가 느낄 수 있는 변화가 무엇인지 차분히 정리해봤습니다.완전히 새로워진 에이전트 중심 구조 이번 Cursor 2.0의 핵심은 ‘에이전트 중심(Agent-first)’ 구조입니다. 이전에는 AI가 입력한 코드 맥락 안에서 추천을 주거나 리팩토링을 도와주는 정도였다면, 이제는 여러 AI 에이전트가 실제로 협업하면서 코드를 만들어가..

비동기 요청을 처리하다 보면 이런 순간이 자주 있습니다.좋아요 버튼을 눌렀는데, 반응이 1~2초 늦게 오는 경우요.사실 요청이 성공했는지 실패했는지는 중요하지 않습니다.사용자는 그저 ‘눌렀을 때 바로 반응이 오는가’를 체감할 뿐입니다.이걸 해결하는 핵심 개념이 바로 **옵티미스틱 업데이트(Optimistic Update)**입니다.React Query를 쓰면 이걸 정말 간단하게 구현할 수 있습니다.서버의 응답을 기다리지 않고,UI가 “먼저 결과를 보여주는” 구조입니다.예전엔 이렇게만 생각했습니다초반엔 단순히 버튼을 누르면 로딩 스피너를 띄우고,응답이 오면 상태를 바꾸는 식으로만 코드를 짰습니다.const handleLike = async () => { setIsLoading(true); await a..

React Query를 쓰다 보면 정말 자주 부딪히는 문제가 있습니다.“상세 페이지에서 데이터를 수정했는데, 목록 페이지는 그대로다.”처음엔 단순히 새로고침으로 해결했지만,프로젝트 규모가 커질수록 이런 불일치가 UX를 크게 해칩니다.특히 관리자 페이지나 대시보드처럼데이터가 여러 컴포넌트에 동시에 뿌려지는 구조에서는이 문제를 제대로 잡지 않으면 서비스 전체가 불안정해집니다.이번 글에서는 React Query로한 곳에서 데이터가 바뀌면 모든 관련 화면이 즉시 반영되는 구조를어떻게 구현했는지 정리해보려 합니다.페이지마다 상태가 따로 놀던 시절React Query를 도입하기 전에는데이터를 컴포넌트별로 useEffect와 useState로 관리했습니다.useEffect(() => { axios.get('/api..

리액트 프로젝트를 하다 보면,“리스트에서 상세 페이지로 넘어갈 때 로딩이 살짝 걸리는” 그 순간이 늘 아쉽습니다.데이터가 많지 않아도, 네트워크 요청이 새로 일어나니까사용자는 매번 짧은 ‘멈춤’을 경험하게 됩니다.저는 이 문제를 해결하기 위해 여러 가지 방법을 써봤는데,그중 가장 확실하게 체감된 게 바로 React Query의 prefetch 기능이었습니다.말 그대로 “사용자가 클릭하기 전에 데이터를 미리 가져오는” 기법이죠.처음엔 단순히 캐시가 오래 남는 줄 알았다React Query의 캐시를 익히면서 “데이터가 남아 있으니 괜찮겠지”라고 생각했습니다.하지만 캐싱은 ‘한 번이라도 가져온 적이 있는’ 데이터에만 적용됩니다.즉, 아직 들어가보지 않은 페이지의 데이터는 여전히 로딩이 필요합니다.그걸 해결해주..

React Query를 써본 사람이라면 한 번쯤 이런 경험이 있을 겁니다.목록 페이지에서 디테일 페이지로 갔다가 뒤로 돌아오면,목록이 다시 로딩되면서 화면이 살짝 깜빡이는 현상.성능 문제는 아닌데, 이 작은 깜빡임이 서비스 완성도를 확 떨어뜨립니다.저도 초반엔 단순히 “UX가 살짝 어색하네” 정도로 넘겼는데,결국 이걸 해결하려면 React Query의 캐싱 동작을 이해하는 게 핵심이었습니다.왜 깜빡이는 걸까React Query는 기본적으로 데이터를 캐싱합니다.그런데 캐시라고 해서 무조건 영구 저장되는 게 아닙니다.데이터는 staleTime과 cacheTime에 따라 언제든지 만료될 수 있습니다.staleTime: 데이터가 ‘신선한(fresh)’ 상태로 유지되는 시간cacheTime: 데이터가 ‘비활성화된..

React Query를 프로젝트에 도입한 이후,가장 체감이 컸던 부분은 비동기 요청의 상태를 눈으로 바로 확인할 수 있게 된 것이었습니다.하지만 그 상태가 화면에만 머물면,정작 사용자는 아무런 피드백을 받지 못합니다.버튼을 눌렀는데 아무 일도 안 일어나는 듯한 상황,“잘 눌린 건가?” 싶은 그 2~3초의 공백이 UX를 망칩니다.그래서 이번에는 React Query와 Toast 알림 시스템을 연결해사용자에게 명확한 피드백을 주는 방법을 정리해봤습니다.단순한 기능이지만 체감은 확실하다처음 React Query를 썼을 땐, 로딩 스피너 하나면 충분하다고 생각했습니다.그런데 사용자가 서버 응답을 기다리는 동안무언가 ‘눈에 띄는 반응’이 없으면“버그인가?” “멈췄나?” 같은 불안감을 느끼는 걸 자주 봤습니다.실무..

React Hook Form을 쓰다 보면 결국 마주치게 되는 단계가 있습니다.“이제 폼 데이터를 서버에 보내야 하는데, 어디서 API 요청을 처리하지?”이 지점에서 React Query를 함께 사용하면 폼과 서버 간의 흐름이 놀랄 만큼 깔끔해집니다.이 강의에서는 React Hook Form의 handleSubmit과 React Query의 useMutation을 결합해,폼 제출 시 비동기 요청을 어떻게 구조적으로 다룰 수 있는지 정리해보겠습니다.예전엔 이렇게 했다가 코드가 엉망이 됐다처음에는 React Hook Form만 쓰고, fetch나 axios로 직접 요청을 보냈습니다.const onSubmit = async (data) => { try { const res = await axios.pos..

React Hook Form을 쓰다 보면 금세 이런 고민이 생깁니다."검증 로직이 자꾸 길어지네?", “백엔드에서 유효성 검증도 하는데, 클라이언트는 또 따로 써야 하나?”저도 예전엔 minLength, pattern 같은 옵션으로만 검증을 처리했는데,폼이 복잡해질수록 코드가 점점 흩어지고 관리가 어려워졌습니다.그때 알게 된 게 zod였습니다.React Hook Form과 찰떡궁합으로 쓰이는 스키마 검증 라이브러리죠.처음엔 조금 생소했지만, 지금은 거의 모든 폼에 붙여서 씁니다.예전엔 이런 식으로 썼다처음에는 React Hook Form의 기본 옵션만으로 폼을 검증했습니다.이 방식이 나쁜 건 아닙니다.단순한 폼에서는 딱 이 정도만으로 충분하죠.하지만 회원가입, 결제, 설정 관리처럼 폼 필드가 열 개 이상..

React로 폼을 만들다 보면 “입력값이 제대로 들어갔는지”, “에러 메시지를 언제 보여줄지”, “제출할 때 상태가 맞는지” 등생각보다 챙겨야 할 게 정말 많습니다.저도 초창기에는 useState로 모든 input 값을 관리했는데,폼이 조금만 커져도 코드가 금세 복잡해지더군요.그런데 React Hook Form을 쓰고 나서부터는 폼 관리가 한결 편해졌습니다.특히 입력값 검증, 초기값 세팅, 제출 이벤트를 일관된 방식으로 다룰 수 있어서실무에서 가장 자주 쓰는 훅 중 하나가 됐습니다.예전엔 useState만으로 버텼던 시절처음엔 단순히 이렇게 코드를 짰습니다.const [email, setEmail] = useState('');const [password, setPassword] = useState('')..

React로 개발을 하다 보면 ‘로딩’과 ‘에러’는 정말 피할 수 없는 친구들입니다.처음엔 단순히 isLoading이나 isError 같은 조건문으로 해결하려고 하지만,프로젝트가 커질수록 코드가 꼬이고 화면이 깜빡이는 현상도 생기죠.저도 예전에 대시보드 페이지를 만들 때,데이터가 많아지니까 로딩 상태 처리만으로도 코드가 한참 복잡해졌던 기억이 있습니다.그때 처음 알게 된 개념이 바로 Suspense와 Error Boundary였습니다.이걸 몰라서 한참 헤맸던 시절React에서 데이터를 불러올 때 대부분 이렇게 시작합니다.const { data, isLoading, isError } = useQuery(['user'], fetchUser);이런 구조는 직관적이지만,페이지 곳곳에서 로딩 상태를 처리해야 하다..