최근 번아웃으로 일 자체에 대한 흥미가 떨어지고 몸이 아파오기 시작하면서팀원들에게 양해를 구하고 시간차를 사용해 이틀 정도를 쉬게 되었다. 요양 중 우연히 '그레이 존'과 관련된 내용을 접하게 되었고 마인드맵으로 생각을 확장해 봤을 때직장에 소속되어 일하는 모든 사람들에게 각자의 그레이 존이 존재하겠다는 생각이 들었고개발자인 나의 관점에서 가장 먼저 떠오른 그레이 존은 '왜 나만 문서화를 해서 팀에 공유해야 하지?','왜 동료의 PR에 대한 리뷰를 최선을 다해 작성하려고 하지?' 같은 의문이었다. 아직 명확한 답을 찾지는 못했지만, 새롭게 떠오른 질문이 있었다.'이게 과연 나만 경험하고 고민하는 이야기일까?'여기까지 생각이 다다르자 사내에서 일회성 모임을 통해 허심탄회하게각자의 그레이 존에 대해 말하고 ..

24년부터 들어오던 useFunnel이라는 라이브러리를 서비스 MVP의마지막 기능인 회원가입 퍼널을 구현할 때 적용을 해보고 싶었습니다.약 2년 전, 신입 개발자로 일할 당시엔 라이브러리를 사용하지 않고 퍼널을 구현해 낸 경험이 있는데요.당시 개발하며 불편했던 마음을 갖고 useFunnel을 사용해 본 경험을 포스팅했습니다. 1️⃣ Funnel이 무엇인지부터 알고가봅시다마케팅적 관점사용자가 웹사이트를 방문하여 구매까지 가는 과정을 단계별로 나눈 차트. 프론트엔드적 관점도메인 별 유저가 경험할 stage를 여러 단계로 분리, 각 단계에 필요한 정보만 수집하는 UI 패턴을 의미합니다.일반적으로 회원가입을 위해선 여러 단계의 폼 작성이 필요한 설문 조사 패턴으로 구성되어 있고해당 패턴을 ‘퍼널’이라고 부른다는..

1️⃣ 문제 발생RSC인 컴포넌트에서 next/headers의 cookies를 import 하여 사용했더니 에러가 발생했습니다.Error: × You're importing a component that needs next/headers. That only works in a Server Component but one of its parents is marked with "use client", so it's a Client Component. │ Learn more: https://nextjs.org/docs/getting-started/react-essentials │ │ ╭─[/Users/jiwooning/Desktop/.../src/app/.../components/list-ba..

내가 담당한 도메인이 아닌데도 나는 무엇을 위해 공통 모듈을 만들고특정 라이브러리를 도입해 DX를 개선하고자 하는걸까.개인 관점과 집단 관점을 기준으로 살펴보자. 개인담당한 도메인에서 유독 중복되는 기능이나 UI 요소가 있다.매번 코딩하기 귀찮으니 공통 모듈을 생성해 재활용성을 높이고 꿀을 빨자. 집단알고보니 프로젝트 전체적으로 중복되는 기능이었네?내가 가장 먼저 중복 이슈를 파악했고, DX 향상을 위해공통 모듈을 만들어 팀에 기여하면 다들 좋아할거야.  기여의 범위를 잘 파악하는 것이 첫째, 자신에게 기여하는 것이 둘째처음엔 나의 개발 편의성을 향상시키고자 하는 목표로 공통 모듈을 만들자.나에 대한 기여를 하자는 것이다. 다소 이기적일 수 있다고 생각한다.누군간 팀에 기여가 우선시 되어야 하는 게 아닌..

해당 포스팅은 Next.js 기반의 프로젝트에서 마크다운 콘텐츠 렌더링을 위한 라이브러리를react-markdown에서 next-mdx-remote/rsc로 마이그레이션 한 과정과 그 결과를 공유한 내용입니다. 길고 복잡한 마크다운 콘텐츠 처리를 클라이언트 대신 서버에서 수행함으로써클라이언트 번들 크기를 줄이고, RSC의 이점을 활용하여 초기 로딩 성능과전반적인 UX를 개선한 과정을 설명하고자 합니다. 1️⃣ 마이그레이션을 결심한 이유React Server Components(RSC)와 tanstack-query의 조합으로 서버 컴포넌트를 사용하기 전,클라이언트 컴포넌트에서 마크다운 콘텐츠가 포함된 페이지를 구성해보고 있었습니다. 당시 서버로부터 문자열(string) 형태로 전달받은 markdown 데이..

1️⃣ openapi generator를 사용하려는 이유서버 측에서 소통 없이 API 수정을 진행하면 프론트엔드에서는 문제 발생 이전까진 변경점을 파악할 수 없다는 점과프론트엔드 팀에서 협업하며 서버 response에 대한 각각의 type 설정으로 인한 사이드 이펙트가 존재했습니다. 프론트엔드에서 각자 타입을 설정해 사용하던 것을 서버 response의 타입이라고 착각해 벌어진 상황도 벌어졌는데요.이와 비슷한 상황이 꽤나 잦았기에 대책을 찾던 중, openapi generator를 알게 되었습니다. 작업 당시 대부분 참고했던 자료가 openapi-generator-cli였기에저 또한 openapi-generator-cli를 기반으로 진행하게 되었습니다.openapi-generator-cli ➡️ open..

tanstack query의 PrefetchBoundary를 프로젝트에 적용하며 prefetch의 동작 원리가 궁금해져소심하게나마 다이브 해봤습니다. 프로젝트 구성 환경Next.js 14(app router), React 18, TypeScript, Tanstack-Query 5, mantine.css, module.css클라이언트에서의 네트워크 요청은 TTFB 개선이 어려웠다.클라이언트 컴포넌트에서만 query fetch해도 되잖아?라고 물을 수도 있겠지만클라이언트에서의 네트워크 요청에 따른 페이지 로드 시간 감소를 이번 프로젝트의 팀 목표로 설정했거든요.목표를 충족시키기 위해선 prefetch로 진행하는 방법이 필요했습니다.기본 fetch 대신 TanStack Query를 활용한 prefetch를 사..

본 글에 앞서, 해당 포스팅은 개인의 유령의존성 경험을 토대로 yarn classic에서pnpm을 사용하게 된 계기를 설명합니다. 패키지 매니저에 대한 딥다이브가 아닙니다.1️⃣ yarn classic이 쏘아올린 작은(사실 겁나 큰) 공, 유령의존성저는 이전 회사도, 현재 회사도 yarn classic으로 프로젝트를운영하고 있었고, 다른 패키지 매니저 경험은 없었습니다. 현실에 안주해 있는 동안 yarn berry, pnpm이라는 새로운 패키지 매니저들이 등장했지만좋다는 말만 듣고 프로젝트에 적용은 하지 않고 있었는데요. 어느 날, 프로젝트를 진행하며제가 설치하지 않은 의존성이 어디선가 추가되어 하나둘씩 발생하기 시작한 문제로 인해 반강제로패키지 매니저에 대한 관심을 가지게 되었습니다.react-slic..