어느덧 올해 3번째 회고글!
집중요정과 함께 3월 패턴 분석 - 75.4시간
여전히 저녁과 주말에 집중 시간이 가장 길게 나타나는 것은 같다
지난달과 달라진 점은 저번 달은 오전 집중 시간이 0%였는데, 이번달은 1%로 늘어났다는 것이다
오전에 집중이 가능한 경우는 주말에 일찍 일어나서 오전에 공부를 시작하는 것인데 30분뿐인 걸 보니 늦잠 잔 티가 난다...
(하지만 오늘 어쩌다 오전 6시에 일어나서 이 글을 쓰기 시작했기 때문에 4월 회고 땐 오전 비율이 1%보단 높을 듯)
그리고 저번달엔 수요일 집중 시간이 13%였는데, 이번달엔 1%로 완전히 줄었다
대신 저번달 일요일 집중 시간이 18%였던 것에 비해 이번 달은 33%로 늘어났다
저번달이 65.1시간 이었던 것에 비해 이번 달은 10시간 늘어난 75.4시간이라 비율을 비교하는 게 큰 의미가 있을지는 모르겠다.
3월 1주차(3/1~3/8) - 8.4시간 집중
3월의 시작이 일요일에 걸쳐있어서 이렇게 잡았다
1. 커피챗
2월 회고에도 적은 내용이지만, 3월 1일에 2년 전 네이버 인턴 때 같은 부서에서 친하게 지냈던 동료분을 만났다.
다른 회사의 AI 활용 현황을 자세히 알 수 있어서 좋았다.
외부에서 자료로 접하는 것보다 실제로 재직자와 이야기를 할 때 훨씬 더 피부로 와닿는 것 같다.
2. 운동
사실 이번 달부터 매일 운동 루틴이 깨지기 시작했다.
그와 비례해 공부 시간이 압도적으로 늘어나긴 했지만...
운동은 그래도 시간 내서 하자고 다짐했던 게 무너진 것 같아 아쉬웠다.
심리적 시간 분배가 쉽지 않은 것 같다.
그래도, 짐박스 연속 nn주 운동을 깨기 싫어서 1주일에 1번씩은 꼭 운동을 했다.
1주차에는 일요일(3/8)에 가서 스텝밀 123층 30분과 걷기 1.2km를 했다.
3. 프론트엔드 공부
AI 드리븐 개발을 하며 내가 놓쳤던 지식들을 공부해서 채우는 시간을 가졌다.
1) Context, Provider로 관리하는 전역 상태
실무에서 zustand 같은 상태 관리 라이브러리를 쓸 땐 신경쓰지 않았던 부분들을 알게 되었다.
Context-Provider는 컴포넌트 트리에 데이터를 주입하는 역할로, props drilling 없이 하위 컴포넌트들이 필요한 데이터에 접근할 수 있다. Context 내의 set함수를 써서 어떤 값을 변경했다고 가정하면 그 Context를 제공하는 Provider는 리렌더링 된다. 리렌더링되며 매번 새로운 객체가 생겨나고, React는 이전 value와 새 value를 Object.is(이전 객체, 새 객체)로 비교한다. 두 객체는 참조가 다르기 때문에 비교문은 항상 false이고 결국 모든 consumer가 리렌더링된다. 결국 하나의 Context 안에 들어있는 변수들은 하나만 바뀌어도 나머지 변수를 쓰는 부분까지 전부 리렌더링 된다.
반년 전에 실무에서 딱 한 번 Context를 쓴 적이 있는데, 사실 그때 개념을 정확히 이해하진 못한 것 같다. 이번에 공부하면서 종근님께서 그때 Context는 값 변경 시 전부 리렌더링 되니까 쪼개서 설계하는 게 중요하다고 하셨던 말씀을 피부로 이해했다.
그리고, 역설적으로 이때 zustand를 왜 쓰는지 좀 체감했다. context는 value가 바뀌면 모든 소비자가 리렌더링되는데, zustand는 (state)=>state.특정value로 구독하면 이 값이 바뀔 때만 리렌더된다. 한 store에 여러 값이 있어도 selector로 필요한 값만 뽑아서 구독하면 리렌더링 지옥에서 벗어날 수 있는 것이다. 이래서 라이브러리 쓰는구만
2) Automatic Batching
이벤트 핸들러 안에 여러 setState를 호출할 때 React가 하나의 렌더링 사이클로 합쳐주는 것이다. 핸들러 끝에서 큐에 쌓인 업데이트를 한 번에 처리한다. 새로 알게된 사실은 React17까지는 이벤트 내부 핸들러 batching은 지원했지만, setTimeout이나 Promise 내부에서는 Automatic Batching을 지원하지 않았던 것이다. React 18부터 지원한다.
3) invalidate queries와 reset queries
invalidate queries는 캐시를 stale로 마킹하고 refetch를 트리거한다. 해당 캐시를 오래됨으로 표시하고, 그 쿼리를 쓰는 컴포넌트가 있으면 즉시 refetch하는데, refetch 동안 '기존 캐시 데이터'를 보여주다가 새 응답이 오면 교체한다. 이를 stale-while-revalidate라고 한다. 하지만, 중요한 점은 '에러가 캐시에 저장된 경우'에는 invalidate queries를 해도 refetch 전까지 캐시에 에러가 남는다. useSuspenseQuery가 이 캐시를 읽으면 다시 에러를 throw하고, Error Boundary가 이 에러를 잡아서 에러 폴백을 표시한다. 에러 폴백이 표시되는 순간 그 안에 있던 쿼리 컴포넌트가 언마운트되고, 백그라운드의 refetch 응답을 받을 컴포넌트 자체가 사라져서 의도한 동작이 발생하지 않는다.
그래서 이때는 reset queries를 써야하는 것이다. 캐시를 아예 초기 상태로 되돌려서 기존 데이터 뿐 아니라 에러도 다 날린다. 쿼리가 아예 처음 마운트 됐을 때의 상태를 만드는 것인데 useSuspenseQuery가 실행되면 캐시에 아무것도 없으니 Promise를 throw한다. Suspense가 Promise를 잡아서 로딩 폴백을 표시하고, 새로운 fetch를 시작한다.
tanstack query를 아직도 제대로 알지 못하는 것 같아서 이때 좀 절망했다. 이제라도 알아서 다행인건가...
4) QueryClient 설정
QueryClient에는 defaultOptions를 설정할 수 있는데, retry 횟수는 직관적으로 알 수 있듯 기본적으로 쿼리 fetch가 실패했을 때 몇 번 더 시도할 것인지를 설정하는 것이다. 기본값은 3회인데, 개발자 탭에서 특정 url request를 block했을 때 3번의 시도를 기다리느라 꽤 오래(2초 정도?) 로딩 폴백을 볼 수 있다. 하지만 이를 1회로 변경하면 실패 즉시->에러 폴백을 볼 수 있다. 서비스의 특성에 따라 ux를 고려해 선택하면 될 것 같다.
그리고 throwOnError라는 속성도 있는데, 기본적으로 suspens query는 error를 던져서 이게 왜 필요한가 싶었다. 그런데, useQuery를 쓰면서도 에러 처리를 Error Boundary에 위임하고 싶을 때 쓰는 속성이었다.
docs 읽으면 돌아서면 까먹지만 실제로 코드 짜면서 '엇쒸...'하고 느낀 경험은 오래간다...
엇..쒸...!!
3월 2주차(3/9~3/15) - 14.6시간
1. AI 시대에서 살아남기 - 인간의 컨텍스트 스위칭 설계
2월의 세 번째 커피챗에서 얻은 인사이트에서 바로 영감을 얻어 컨텍스트 스위칭에 대한 글을 써봤다. 툴은 정말 빠른 속도로 진화하지만 인간의 두뇌 리소스는 그렇게 빠른 시간에 진화하지 못한다. (당연함 진화는 원래 한 세대에서 발생하는 게 아님) 있는 두뇌를 잘 쓰려면 어떻게 해야할까...고민하다가 내가 평소 실무에서 병렬 작업을 어떻게 진행하는지 정리해봤다. 결국 업무의 맺고 끊음을 어떻게 설계하느냐 인데, 작업 단위/티켓 단위로 스위칭해서 내 두뇌가 '이 작업은 이 단계까지 마무리됐고 다음 작업으로 넘어감'을 자연스럽게 인식하게 하는 게 중요하다. 이 작업하다가 '아 맞다 저거 해야하는데' 저 작업 허둥지둥 넘어가고 이러면 모든 작업을 하다 만 상태로 넘기는 것 같다.
2. 클린 코드 - 15/16장
3월을 기점으로 흐지부지된 슬픈 클린코드 스터디... 15장은 테스트 코드에도 클린 코드 룰을 적용하라는 이야기였다. 하나의 테스트가 너무 많은 기능을 점검하도록 하지 않고, 프로덕션 코드에 너무 의존하지 않도록 '독립적'으로 짜는 것이 중요하다. 16장은 개발자가 비즈니스와 협업하는 이야기가 처음으로 나왔다. 클린코드니 뭐니 해도 결국 프로덕션에 나가는 건 비즈니스 조직의 승인이 있을 때이다. BA와 QA가 '읽을 수 있는 수준'의 테스트 코드를 작성하고, 인수 테스트가 실패했을 때 즉시 고쳐서 '실패를 노이즈로 느껴 그냥 넘기는' 일이 없도록 하라고 했다.
이 다음은 17장인데, 아직 읽다가 말았지만 AI 시대의 개발에 대한 이야기였다.
3. 집중요정 디벨롭 - 외부 워크스페이스 설치 지원
종근님께서 다른 워크스페이스에도 집중요정을 설치해보고 싶은데 install link 형태로 배포해줄 수 있냐고 물어보셨다. 그냥 스터디 내에서 쓰는 기능으로 만들었던 슬랙봇이 외부로 진출하다니!! 더할 나위 없이 좋은 기회였다. 제안을 받은 날 퇴근하고 바로 작업했다.
슬랙봇을 public하게 배포하지 않아도 private install 링크를 만들 수 있는 걸 처음 알게 됐다. 그리고, 집중요정 특성상 커스텀 이모지가 필요한데, 이걸 어떻게 자연스럽게 설치하도록 유도할지 고민이 많았다. 설치하지 않으면 이모지가 :fairy-wand: 이렇게 문자열로 보일거라 못생겨지는데... 이걸 또 커스텀 이모지를 설치하지 않은 경우에는 기본 이모지를 보여주도록 감지하는 것도 어려워서 고민이 됐다. 그래서 install 페이지에서 유저가 커스텀 이모지 등록 여부를 선택할 수 있게 하면서도, 등록을 결정했을 때 flow를 최대한 자연스럽게 하려고 고민을 많이 했다. 슬랙 이모지를 bulk로 등록할 수 있는 비공식 extension이 있는데, 이걸 설치하도록 유도하고 zip으로 커스텀 이모지를 내려받아 폴더 째로 등록할 수 있게 만들었다. UX 고민을 많이 했는데 종근님께서 이 부분을 칭찬해주셔서 기뻤다!
도입 예정인 워크스페이스의 인원 수가 적어서 여전히 cloudflare 무료 kv로 감당 가능했는데, 서버비 0원을 언제 어디까지 유지할 수 있을지 고민이 많다. 최근 DAU 10만까지 맥미니 로컬 홈서버로 견뎠다는 이야기를 어디선가 주워들은 뒤로 본가에서 놀고있는 맥미니를 들고올까 싶었다.
4. 운동
3월 3주차(3/16~3/22) - 26.5시간
1. 집중요정 디벨롭
1) 월별 조회
2월 집중요정 회고 글을 쓰다가 /pattern 키워드가 조회 시점으로부터 한 달만 가능한 게 불편해서 월별 조회 기능을 만들었다. 이번 글에서 서두에 쓰인 패턴 분석 결과도 /pattern 26-03으로 조회한 결과이다.
2) HeyTaco처럼 /cheer 커맨드
점점 팀원들의 집중요정 사용 빈도가 낮아지는 것 같아 슬픈 마음에... 어떻게 하면 활성화시킬까 하다가, 대학 시절 자치회 개발부서였던 인포팀에서 HeyTaco를 열심히 썼던 기억이 났다. HeyTaco 봇은 설치하면 별도의 커맨드 없이 [@팀원이름 🌮🌮🌮] 이런식으로 이름 멘션+타코 이모지 조합을 쓸 수 있었다.
그런데, 이 기능은 커맨드 감지가 아니라 모든 메시지를 읽으며 대기하고 있다가 타코 이모지가 나오면 타코 지급 로직이 실행되는 방식이라 cloudflare workers 사용량이 크게 증가하는 방식이었다. 또, 추가 슬랙 봇에 추가 권한(message)도 줘야 하는데, 봇의 권한을 늘리면 이 봇을 사용하는 모든 워크스페이스에 해당 권한을 포함해 재설치를 해야하는 문제도 있었다. 종근님의 워크 스페이스에서도 이 봇을 쓰게 된 이상 추가 권한을 늘리는 작업은 신중하게 할 필요가 있었다.
그래서, 단순히 커맨드를 추가해 [/cheer @팀원이름 응원메시지] 형태로 바꿨다. 커맨드 추가는 다른 워크스페이스에서도 재설치 없이 바로 적용된다는 점이 좋았다. 팀원들의 집중요정 사용 빈도를 아주 크게 늘리지는 못했지만, 그래도 종종 서로 감사와 응원을 주고받는 소소한 도구 정도로 자리잡은 것 같다.
3) 한 눈에 할 일이 보이는 기능
종근님께서 제안 주신 바를 바탕으로 이런 저런 고민을 했다.
커맨드를 입력하면 할 일 입력 팝업이 바로 뜨게 할지, 아니면 버튼을 눌러서 뜨게 할지... 아니면 /start add 커맨드를 입력해야만 버튼이 뜨게 할지... 세 가지 안을 만들어서 여러 번 써보면서 테스트를 하다가 '/start 커맨드 입력 시 '계획 추가' 버튼이 시작 쓰레드에 노출되고, 이 버튼을 누르면 할 일 입력 팝업이 뜨게 한다'라는 결론을 내렸다. 사실 종근님께 세 가지 안을 동시에 드리면서 제일 좋은 안을 골라보시라고 하려고 했던 게 의도인데, 내가 직접 쓰다 보니 한 가지의 결론으로 귀결되었던 것 같다.
계획 추가 시 카테고리를 함께 정할 수 있게 했는데, 이건 내가 예전부터 생각해오던 '집중 결과 그래프에 카테고리별 색상 다양화'를 구현하기 위해서였다. 3주차부터 그래프 색상이 알록달록 해진 것도 그 이유이다.
회사 워크스페이스에서는 항상 할 일을 입력해야 하니까 유효한 기능일 것 같은데, 스터디 팀원들은 그냥 집중요정을 타이머 정도로 쓰고, 할 일을 잘 공유하지 않는다. 아마 본인의 일과를 공유하는 게 부담스러워서일까? 팀원들이 계획 기능을 잘 안쓰다 보니, 제작자인 나도 뭔가 심리적 허들이 생겨서 공유를 잘 안하게 됐던 것 같다. 이렇게 되니, 항상 노출되는 계획 버튼이 오히려 노이즈인 것 같기도 했다.
할 일을 거리낌없이 공유하는 문화를 만들어서 이 기능을 더 쓰게 만들거나, 아니면 계획 추가 버튼을 디폴트로 노출하지 않도록 수정할 수도 있다. 이 부분은 여전히 고민 중인 포인트이다.
계획을 추가하면 이렇게 목록과 완료 버튼이 생기고, 완료 처리를 누르면 취소선이 그어진다. 취소 버튼을 눌러 완료 처리를 되돌리거나 계획 수정 버튼으로 수정할 수도 있다. 다만, 계획을 수정하면 이전에 완료 처리했던 계획들이 다시 미완료로 돌아오는 점, 그리고 이 버튼들이 나에게만 노출되는 것이 아니라 다른 팀원에게도 보인다는 점이 아쉽다. user id 방어 처리를 해서 다른 팀원이 내 버튼을 눌러도 '나의 세션만 수정할 수 있다'라는 ephemeral 메시지가 뜨긴 하지만, 슬랙 메시지 구조 상으로 버튼을 특정 유저에게만 보이게 하는 건 불가능하다고 한다. 다른 개선 방안이 있을지 여전히 고민 중...
4) pause, resume
이번 이슈도 종근님이 제보해주신 아이디어에서 출발했다!
난 사실 하루에 여러 세션이 기록되더라도 /start /end를 여러 번 하는 걸 생각했는데, 스터디의 사용과 회사에서의 사용 양상이 조금 다른 것 같았다. 종근님은 회사에서 /end 없이 /start로 한 세션을 /pause /resume하면서 출근 퇴근을 관리하고 계신 것 같았다.
5) 워크 스페이스별 개별 설정
회사에서는 일별 근무 시간이 최소 8시간이니까 스터디의 최대 세션으로 정해놓은 6시간이 짧았다. 이걸 어떻게 커스텀할지 고민하다가 그냥 설정 기능을 만들기로 했다.
왜냐면... 타임존 대응도 필요했기 때문이다. 워크스페이스 단 두 곳 도입인데 타임존 대응 케이스까지 경험해볼 수 있다니 오히려 좋다고 생각했다!
키워드로 설정을 입력하는 것보다 /settings 커맨드를 입력하면 설정 모달이 뜨도록 하는 게 나을 것 같았다. 설정할 항목이 꽤 많아져서 매번 커맨드를 추가하는 것도 ux적으로 좋지 않다고 생각했기 때문이다.
KV values에 워크스페이스 ID를 key값으로 해서 설정 값을 저장하도록 했다.
타임존 대응이 고민이었다. 그런데, 문득 대학교 개발 동아리에서 동아리 선배가 일본에 여행을 갔을 때 슬랙 프로필 타임존에 자동으로 '이 유저가 일본에 있다'라는 문구가 뜨는 게 기억났다. 그럼 유저 타임존을 자동으로 감지하면 되겠다.
슬랙에서 임의로 내 타임존을 PT(미국 서부/멕시코 북서부)로 바꾼 후 테스트해봤다. KST로는 오후 12시 46분이지만, 종료 메시지에는 오후 8시 46분으로 나오는 것을 볼 수 있었다. 이렇게 각 유저의 메시지는 각 유저 프로필의 타임존 메시지를 따르도록 했고, 워크스페이스 기준 타임존도 따로 설정할 수 있게 했다. 매주 /report 명령어로 팀원들의 집중 시간을 출력해보는 등, 조회 기준점이 필요한 기능들을 위함이다.
최대 세션 길이는 단순 number라 설정 값에 값을 하나 끼워넣는 것으로 마무리했다. 내 개인 테스트 워크스페이스에서 임의로 최대 세션 길이를 2시간으로 정한 후, 테스트했다. Ephemeral 메시지에도 버튼을 삽입할 수 있어서, 버튼을 누르면 최대 세션을 초과했더라도 기록된 시간이 그대로 입력되도록 구현했다.
2. AI 활용기 - Conctor+Cursor
클리커 기작을 만들면서 UI 구현이 figma와 완전히 일치해 디자인 QA가 거의 3건 이하로 나왔었다.
디자이너님이 매우 만족해하시면서 두고두고 칭찬하심.
이때 보자마자->무작정 구현이 아니라, 상태머신 설계에 거의 이틀을 투자했다.
그동안 시간에 쫓겨서 UI 보자마자 -> 그래픽 구현으로 이어졌던 걸 생각하면 매우 큰 시도였다고 볼 수 있다.
Conductor에서 Claude code를 사용해 상태 머신을 설계하고, 스캐폴딩 UI까지만 작업했다.
그리고 같은 워크트리를 Cursor IDE로 열어서 Cursor chat에서 각 페이지의 UI를 디벨롭했다.
그동안 UI를 구현하면서 제일 힘들었던 건,
자꾸 변하는 기획 때문에 비즈니스 로직을 뜯어고치다가 UI까지 뻑나는데 AI로 짠 코드라 어디 손을 대면 다 터지는 것이었다.
기획이 어느정도 확정될 때까지 구현을 시작하지 않고, (어차피 확정된 기획 위에서 0to1으로 짜는 게 더 빠름)
이를 xState 라이브러리를 도입해서 아예 각잡고 '변화에 열린' 상태 머신을 설계하면서 기획 변경에 대응한다.
디자인은 노드 단위로 뜯어서 figma mcp로 분석해서 코드화 할 부분과 svg로 export할 부분을 나눴다.
(복잡한 배경 패턴은 svg로 뽑고, 광택이나 그림자는 다중 div 레이어로 코드 구현함)
그간의 여러 시행착오 끝에 나름의 노하우를 얻은 듯... 비즈니스 성과도 좋게 나왔다.
아래의 글을 쓰며 그 flow를 정리했는데,
글로 정리하고 나니까 동료들이 어떻게 figma와 똑같은 화면을 구현해내냐고 물었을 때 바로 내 AI 사용 구조를 설명할 수 있어서 좋았다.
3. 독서 - '요즘 당근 AI 개발'
토요일에 오랜만에 서울대 도서관에 갔다...
이용료를 냈으면 좀 더 자주 가야할텐데 말이야...
지인분께서 당근 내부 세미나에 초대해주셔서 정말정말 신나있는 상태였다.
당근의 AI 활용에 대해 좀 알고 가면 도움이 될까 싶어서 당근에서 출판한 책을 빌리러 갔다.
생각보다 비개발자 글의 비율이 높아서 놀랐다. 전 직군이 AI 드리븐임을 어필하고 싶었던 것 같음.
위 글 본문에 더 자세하게 썼지만, 개발자 없이 PM이 mvp를 만들고 테스트하는 과정들이 인상 깊었던 것 같다.
4. 클리커 기작 개발 - GPUWatch 수치 측정과 Touch API 사용
클리커 개발 기간에 해보고 싶은 걸 다 해봤는데(아무도 안시켰음), GPUWatch로 성능 측정 찍먹을 해봤다.
뭔가 좀 진짜 개발자된 것 같고? 좀 멋져보이고? 그랬다.
그리고 실제로 연산 최적화할 때마다 그래프 수치가 내려가는 게 체감이 되는 것도 신기했다. (당연한거긴 하지만)
Touch API라는 걸 아시나요? 저도 이번에 알았음.
멀티 터치 구현은 의외로 추가 패키지 설치 없이 브라우저 기본 API로 구현할 수 있었다.
브라우저에 뭔 click synthesis가 있다는 것도 알게됐고, 클리커 구현하다 신기한 거 딥다이브 해서 좋았다.
멋쟁이 개발자가 된 것만 같아~~
5. 운동
화(3/17)에 스텝밀 121층을 올랐다....
3월 4주차(3/23~3/29) - 20.1시간
뭐지 화,수에 기절했나?
1. FigLog 개발기
어쩌다보니 입사 초에 프로덕트에 로깅된 300개의 로깅 정합성을 확인하는 작업을 자발적으로 맡았었는데, 그 뒤로 어째선가 로깅 마스터라는 칭호를 얻고 스쿼드마다 로깅 도입이 필요할 때 자문(?)을 해주는 역할을 했다. 그러다보니 로깅에 대한 애정이 생겨서 로깅을 좀 더 쉽게할 수 있는 방법을 고민하다가 vite-plugin과 figma plugin을 만들었다.
3주차 일요일 늦은 밤에 갑자기 불이 붙어서 4시간 만에 만들었는데, 다 만들고 나니까 오전 3시였던 것 같음. 그리고 월요일에 퇴근하자마자 블로그를 거의 오전 2시까지 쭉 쓰고... 뭔가 불이 붙었을 때 바로 만들고-배포하는 경험이 좋다. 이것 역시 AI 덕분이겠지.
vite-plugin npm 배포 경험과 figma plugin 배포 경험은 별도의 글로 분리했다. 나중에 내가 다시 메뉴얼 삼아 읽고 싶어서.... 그리고 피그마는 아직도 내 플러그인 승인을 안해줌. 평균 영업일 10일 안에는 처리해준다매!!!!!!
2. 당근 내부 세미나 - PEConf
정말네트워킹은좋아최고야
강연도 정말 재밌었고, 이때 알게 된 AI 하네스는 지금 실무에 적용해서 레슨을 쌓아보고 있다. 그리고 데이터를 보는 프론트엔드 개발자의 강연도 인상깊었고... 데이터를 보면서 유저 행동에 더 다가가는 게 재밌는 것 같다.
네트워킹 시간에는 이런 저런 이야기를 하다가 AI 활용기를 공유했는데, 뭔가 말을 많이 하고 나니까 속이 뻥 뚫린 기분이었다. 정말정말 행복했다. 약간 뭔가 개발자 정체성과 자아 고민 때문에 힘들던 참이었는데, 정말 구원의 손길... 세미나에 초대해주셔서 참말로 감사합니다...참말로... 이 날을 기점으로 좀 정체성을 잡았던 것 같다.
3. 운동
일(3/29)에 1.2km 걷기를 했는데 진짜 그냥 1주일에 한 번 헬스장 가는 데 의의둔 수준의 운동인 듯... 좀 더 열심히 하렴...
3월 5주차(3/30~3/31) - 5.8시간
그래프를 어떻게 뽑을지 고민하다가 그냥 딱 3/31까지만 뽑았다.
1. 프론트엔드 공부
1주차 쯤에 공부하던 searchParam을 좀 더 딥다이브를 했다.
1) useSearchParams: react-router-dom 출신. 지금 URL에 뭐가 있는지?
현재 URL에 무엇이 있는지 읽을 때 사용한다. React 훅이라서 URL이 바뀌면 자동으로 컴포넌트가 새 값을 받아 리렌더링한다.
useSearchParam은 내부적으로 react-router의 location context를 구독한다. setSearchParams를 호출하면 URL이 변경되고, location context가 변경되면서 해당 context를 구독하는 모든 컴포넌트가 리렌더링된다. 특정 param만 구독하는 건 불가능하고, data만 읽는 컴포넌트도 리렌더링된다.
그리고, useSearchParams()가 반환하는 첫 번째 값은 사실 URLSearchParams 인스턴스라서, searchParams.get('key') 같은 Web API 메서드를 그대로 쓸 수 있다. react-router가 내부적으로 Web API를 감싼 것이다.
setSearchParams({ newParam: 'value'})를 호출하면 기존 파라미터가 날아가서, 개별 파라미터만 업데이트하고 싶을 땐 함수형 업데이트를 써야 한다.
2) new URLSearchParams: WEB API 출신. 새 URL을 조립하자
- 이동할 URL을 만들 때 사용한다. 일반 JS 유틸리티. React 리렌더링과 무관하다. 만들기만하고, 실제 이동은 navigate가 담당한다.
단편적으로 searchParam이 바뀌면 리렌더링 된다는 건 경험적으로 알고 있었지만, 그게 location context를 구독하고 있어서인 건 딥다이브 하면서 알았다. location context가 어떻게 생겼는지 까보면서 오...신기하네...라는 생각을 했다.
결론
3월을 그냥 지나고 벌써 4월 중순이 됐는데 이제야 3월 회고를 했다.
지난 2월 회고 결론도 3월 중순 쯤 썼었는데,
'3월에는 좀 더 내 부족한 부분을 채우는 기간이 되기를 바란다'고 썼었다.
회고를 하기 전까지는 또 내가 나아지지 못한 상태로 시간이 흐르는 건지 두려웠는데,
막상 회고를 해보니 내가 3월에 정말 많은 것들을 배우고 나아간 것을 알 수 있었다.
3월엔 사이드 프로젝트도 많이 디벨롭하고, AI를 어떻게 하면 잘 쓸지 고민도 많이 하면서 성장했다.
조금 용기를 얻어서 남은 4월도 더 성장하는 시간을 보내기로 다짐했다.
작성: 2026.04.14. 22:33
'개발자 강화 > AI 활용' 카테고리의 다른 글
| 26년 4월 - 회고 with 집중요정 [79.6시간] (0) | 2026.05.02 |
|---|---|
| 로깅, 엑셀 시트 말고 Figma에서 하면 안 되나? - FigLog 개발기 (0) | 2026.03.24 |
| Figma Plugin 배포부터 npm publish까지 - FigLog 배포기 (0) | 2026.03.24 |
| '요즘 당근 AI 개발'을 읽고 - 개발/비개발 직군의 AI 활용 (0) | 2026.03.21 |
| AI에게 뼈대를, 사람이 디테일을: Conductor + Cursor 워크플로우 (1) | 2026.03.18 |
