우테코를 진행하며, 벌써 1000일을 맞이했다 ! 💍

🎯 이번주 Action Plan 회고하기

• 세라처럼 미션과 관련된 주제에 대해 깊이 있게 고민해보고, 그 과정을 정리한 글을 최소 1편 작성하기

이번주는 나만의 컴포넌트 구현하는 기준은? 이라는 글을 작성했다.

무작정 컴포넌트를 만드는 대신에 어떤 사고를 가지고 만들 수 있는 지에 대해 작성했다. 확실히 글로 정리하니, 아직 추상적인 개념이 아직 있다는 게 느껴졌고, 다음에는 디자인 패턴을 적용해서 컴포넌트를 만들고 싶다는 생각을 했다.

위로받은 날

1. 통제할 수 있는 영역과 아닌 영역을 명확히 해라

회고를 공유하는 게 두려웠는데, 지금은 그냥 하고 있다. 제이슨이 해준 말 덕분이다. "통제할 수 있는 영역과 없는 영역을 명확히 해라. 그리고 통제할 수 없다면 신경 쓰지 마라." 뭔가 당연한 말인데도 이상하게 크게 와닿았고, 고민이 생길 때마다 이 말을 떠올리게 된다. 제이슨은 엄청 추운 날에도 날씨는 통제할 수 없는 영역이라 스트레스를 받지 않는다고 한다.

내 회고를 보고 누가 어떤 생각을 할지에 대한 걱정도 내가 통제할 수 없는 부분이라는 걸 받아들이고 나니, 마음이 훨씬 편해졌다. 이제는 그냥, 담담하게 공유하려고 노력한다.

2. 누군가 나의 신상을 물어본다면, 솔직히 말해서, 꼭 대답하지 않아도 돼. "왜요?" 라고 되물어도 좋아.

운동을 하러 가면, 꽤 많은 사람들이 나의 나이, 학벌, 부모님에 대해 궁금해한다. 처음에는 진짜 궁금해서 물어보는 줄 알았는데, 그걸 이용하는 사람들이 있다는 걸 알게 됐다. "그 나이까지 뭐해? 이제 취업해야지" 라든가, 점점 더 깊게 파고드는 말들이다.

어른이 물어보면 대답을 피하기 어려워서 그냥 말했는데, 이제는 정말 그 의도를 잘 모르겠다.

GPT랑 얘기하다가 얻은 해결책은 무작정 대답하지 않고 "왜요?"라고 되묻는 것. 그 한마디로 상대의 의도를 자연스럽게 드러나게 하고, 잠깐의 쉼을 가진 다음에 내가 판단해서 대답할지 말지를 정하는 거다. 그리고 꼭 대답할 필요는 없다는 것도 알게 됐다.

3. 나는 나대로 충분히 괜찮고, 저 크루도 나처럼 애쓰고 있을 뿐이야.

남도 나처럼 애쓰고 있다. 그 애쓰는 마음을 인정해줘야 한다. 우리는 애쓰는 마음, 노력하는 마음, 무엇 하나 쉽게 얻은 건 없다는 마음을 가지고 있다. 그 마음을 먼저 지켜줘야겠다는 생각이 들었다.

시지프와 대화에서 얻은 포인트

1️⃣ catch에 걸리는 이유는 하나여야 한다

여러 에러를 한 try-catch로 묶는 건 책임을 모호하게 만든다. catch는 "지금 무엇 때문에 실패했는지" 단번에 알 수 있어야 한다. 이유가 두세 개 섞여 있으면, 디버깅도 어렵고 책임도 흐려진다.
try-catch를 여러 개의 쓰더라도 catch에 걸리는 이유가 하나가 되도록 만들자.

2️⃣ isFetching과 isLoading을 구분하자

단순히 데이터를 다시 불러온다고 해서 항상 isLoading이어야 하는 건 아니다. 최초 요청(loading)과 이후 갱신 요청(fetching)은 사용자 경험이 다르다.

API 응답 상태를 다루고 refetch 로직이 들어가는 상황이라면, 최초 적재 시의 isLoading과, 갱신 시마다의 isFetching 상태를 분리하는 건 필수적이었다.

처음엔 isFetching 없이 isLoading만 사용했었다. 그래서 데이터를 처음 가져올 때든, 다시 가져올 때든항상 스피너 화면이 떴고, 단순히 '담기/빼기' 버튼만 누를 때도 전체 화면이 로딩되면서 스피너가 떠서 사용자 경험이 별로였다.

그래서 이런 식으로 개선했다.

• productList, cartItems 등 최초 호출에서만 isLoading을 사용해 로딩 UI를 노출
• 이후의 재요청(예: 버튼 클릭 시 refetch)에는 isFetching만 사용해 화면 깜빡임 제거

이렇게 나누고 나니 사용자 경험이 훨씬 부드러워졌다.

3️⃣ 인증된 사용자 데이터와 공개 데이터를 분리하자.

이번 미션에서 상품 목록을 가져오는 API를 이용할 때, 이런 궁금증이 들었다.
"상품 목록 가져오는 API에 IsCart 라는 필드가 있으면 굳이 장바구니 목록을 가져올 필요 없을텐데"

하지만 깨달았다. 예를 들어 isCart처럼 사용자별 상태 정보가 공용 API 응답에 섞이면, API가 점점 무거워지고, 공용 데이터의 역할도 흐려진다.

모든 사용자에게 보여줄 수 있는 공개 데이터와 인증된 사용자에게만 필요한 개인화된 데이터는
명확하게 분리된 인터페이스로 제공해야 한다.

이렇게 하면 API의 책임이 명확해지고, 인증 여부에 따른 처리 로직도 깔끔하게 나뉘는 것 같다.

🍵 마무리

1. 바다를 보면서 공부를 하고 싶어서, 방학 때 제주도를 가게 됐다.
   벌써 기대가 되고 빨리 떠나고 싶다 🍊 요즘 한강 작가님의 '작별하지 않는다'라는 책을 읽고 있는데, 제주 4·3 사건에 관련된 책이다. 몰입해서 읽은 만큼 제주에 가서 역사 현장도 살펴보고 싶다.

2. 메타가 나에게 칭찬을 많이 해준다. '멋진 사람'이라고도 해주고, '되고 싶은 사람'이라고도 해준다. 나도 타인의 장점을 찾아서 칭찬을 해주는 메타가 멋있고 감사하게 느껴진다. 좋은 영향을 주고 받을 수 있는 사람들이 우테코에 많아서 다행이다.

3. 시지프 강의에서 Provider 추상화를 하는 방법에 대해 배웠다. 여러 개의 Provider의 공통 로직을 빼기 위해서 인터페이스를 설계하고 분리하는 작업이다. 근데 나는 Provider가 하나라 이게 필요하지 않아서 그런지, 이해가 잘 안돼서 적용하기 힘들었다.

4. 최근에 제이슨과 황준일님이 공통적으로 해주신 말이 있다. "문제를 꼭 코드로만 해결해야 하는 건 아니다."는 말이다. 예를 들어, 새로운 기술을 도입하고 싶을 때, 그 기술이 팀원들에게 낯설지 않게 스며들 수 있도록 도우려면 어떻게 해야 할지, 또 회의 시간을 줄여서 사람들의 시간을 어떻게 아껴줄 수 있을지 같은 고민들이 있다. 개발자라고 해서 모든 걸 코드로만 바라볼 필요는 없다는 걸 조금 느끼게 됐다. 오히려 이런 게 AI가 하기 힘든 영역이라는 생각도.

🎯 다음주 Action Plan

쉬어갑니다 🙇‍♀️