핵심만 원한다면 "JSDoc: 단순한 주석이 아니라 IDE와의 대화"로 이동해주세요.개요개발의 패러다임이 바뀌고 있다 개발의 패러다임이 바뀌었다. 불과 몇 년 전만 해도 개발자가 한 줄 한 줄 직접 코드를 작성해야 했지만, 이제는 AI가 개발의 대부분을 수행해준다. 전체적인 아키텍처 설계 면에서는 아직 인간의 통찰력이 필요하지만, 단순 기능 구현을 지시하면 AI는 불과 몇 초 만에 결과물을 내놓는다. 물론 AI에게 모든 것을 맹목적으로 맡기면 심각한 기술 부채로 이어진다. 하지만 인간이 뼈대를 세우고, AI가 살을 붙이면 이야기가 달라진다. '초안 구현'은 AI에게 맡기고, 인간은 그 결과물을 검수하고 리팩토링하는 워크플로우를 구축했을 때 생산성은 폭발적으로 증대된다. 이제 개발의 대세는 AI에게 대부..

개요 개발을 하다 보면 무의식적으로 `` 태그를 남발하게 되는 경우가 많다. 당장 스타일링하기 편하고, 별다른 고민 없이 레이아웃을 잡을 수 있기 때문이다. 하지만 ``로 점철된 코드는 Div Soup(div만 가득한 죽)이라고 불리며, 검색 엔진(SEO)과 스크린 리더(접근성)에게는 최악의 구조다. 이와 관련한 글을 이전 포스트로 작성했었다. 이번에 서비스의 SEO 최적화와 웹 접근성 향상을 목표로, 기존의 ``로 떡칠된... 코드를 시맨틱 태그로 대대적으로 리팩토링 했다. (사실 div 태그 제거 작업은 할당된 업무에 없었는데 어차피 해야하는 작업이라 같이 해결했다.) 결과적으로 Lighthouse 점수가 유의미하게 상승했는데, 그 과정과 기준을 정리해본다. 시맨틱 태그 적용과 기준`` vs ``..

개요 Sentry에서 INP(Interaction to Next Paint) 지연 경고가 간헐적으로 발생하고 있다. 로그를 분석해 보니 특정 페이지(eventDetail)에서 사용자의 클릭 반응 속도가 눈에 띄게 느려지는 현상이 포착되었다. 범인을 추적해 보니 피크(Peak)가 튀는 순간은 MUI(Material UI) 컴포넌트가 렌더링 될 때였다. Deep Dive : 왜 MUI v5가 범인인가? 최적화를 시작하기 전에, 도대체 왜 MUI v5가 느린지 근본적인 원인을 파악해 보자. 범인은 바로 편리함의 상징인 sx 문법이다. v5의 sx가 문제라는 것이지 지금 버전의 sx도 문제라고 오해하지 않는 것이 좋다. 런타임 오버헤드 (Runtime Overhead) 우선 sx로 작성된 스타일이 실제 DOM..

개요 프로젝트를 세팅하거나 새로운 컴포넌트를 만들 때마다 아주 사소하지만, 매번 마주치는 갈림길이 있다. "이거 export default로 내보낼까? 아니면 그냥 export로 내보낼까?" 사실 둘 중 뭘 써도 기능상으로는 전혀 문제가 없다. 어차피 import 해서 쓰면 그만이니까. 하지만 프로젝트 규모가 커지고, 팀원들이 늘어나고, 성능 최적화(Tree Shaking)를 고민하기 시작하면 이 사소한 차이가 생각보다 큰 영향력을 불러온다. 결론부터 말하자면 나는 Named Export를 강력하게 선호한다. 그 이유를 이야기하기 전에, 우선 두 방식이 본질적으로 어떻게 다른지부터 깊게 파보자. Named와 Default export란 두 방식의 차이는 단순히 중괄호 `{}`를 쓰냐 마냐의 문제..

개요 컴포넌트를 만들다 보면 필연적으로 간격을 어디에 줄 것인가에 대한 고민에 빠지게 된다. 예를 들어, 리스트에 들어갈 `UserCard`라는 컴포넌트를 만든다고 가정해보자. 리스트 아이템 사이에는 20px의 간격이 필요하다. 이때 가장 쉬운 방법은 `UserCard` 자체에 `margin-bottom: 20px`을 주는 것이다. "어차피 이 카드는 리스트에서만 쓰니까, 알아서 간격을 가지고 있으면 편하잖아?" 하지만 프로젝트가 커지고 `UserCard`를 다른 곳(가로 스크롤 뷰, 모달 내부, 그리드 레이아웃 등등)에서 재사용하려고 할 때, 내부에 심어둔 이 margin은 굉장히 거슬리는 무언가가 돼버린다. ▼ 나는 "자식 컴포넌트는 패딩이나 마진 같은 외부 간격에 대해 전혀 몰라야 한다"는 ..

개요 기획서나 디자인 시안을 보다 보면 정말 흔하게 등장하는 UI가 있다. 바로 긴 텍스트 줄이기다. 보통은 3줄 정도 보여주고, 넘치면 말줄임표(...) 처리를 한다. 여기까지는 CSS의 -webkit-line-clamp 속성만 쓰면 3초 만에 해결된다. 하지만 요구사항이 아래와 같다면 이야기가 달라진다. "3줄 넘어가면 말줄임표 하고, 그 '바로 옆'에 더보기 텍스트 버튼을 넣어주세요. 버튼 누르면 펼쳐지고요." 단순히 ...으로 끝나는 게 아니라, 인터랙션이 가능한 버튼이 텍스트 흐름에 자연스럽게 붙어야 한다. '그냥 position: absolute로 띄우면 되는 거 아닌가?' 싶지만, 막상 해보면 생각보다 까다로운 문제들이 발생한다. 오늘은 이 '더보기' 버튼을 자연스럽게 넣기 위해 삽질했던..

개요 유지보수를 하면서 이전에 작성된 코드를 보는데 `{...props}` 문법이 정말 많이 보였다. 리액트의 문법들에 대해 다 알지 못했기에 무슨 이런 해괴한 문법이 있나... 하면서 찾아보니 꽤나 유용한 문법이었다. 처음 봤을 때는 솔직히 조금 불편했다. 명시적으로 어떤게 있는 지 모르니 말이다... 그러면서 이건 아무래도 안티 패턴인거 같다는 생각이 들었고, 커뮤니티랑 글들을 찾아보니 내 생각이 맞았다. 얼핏 보면 코드도 간결하고, 고수처럼 코딩하는 것 처럼 보인다.// 이렇게 간단하게 props를 넘길 수 있다니!function ParentComponent() { const userProps = { name: '노근', age: 25, job: 'Developer' }; return ;} ..

개요 React로 폼을 개발하다가 꽤나 당황스러운 버그가 나타났다. 새로고침(F5)을 누르면 분명 State는 초기화되는데, Input에는 이전에 입력했던 값이 그대로 남아있는 것이다. 더 황당한 건 입력 값은 보이는데 Preview 영역에는 아무것도 표시되지 않는다는 점이었다. 처음에는 '내가 State 관리를 잘못한 건가?' 싶어서 코드를 여러 번 확인했다. 하지만 크롬에서는 문제없이 잘 작동했다. 문제는 Firefox와 Firefox 기반 브라우저(Floorp, Librewolf 등)에서만 발생했다. 문제 상황구체적인 상황은 이랬다. ▼사용자가 폼에 데이터를 입력입력한 데이터가 Preview 영역에 실시간으로 표시됨새로고침(F5) 실행React State는 정상적으로 초기화됨그런데 Input/Te..

개요 React 개발을 시작한 지 얼마 안 됐을 때, 나의 컴포넌트는 대충 이런 모습이었다. ▼ ... 솔직하게 말하면 지금도 종종 저러고 있는거 같다. 끝없이 중첩된 `div`들... 당시에는 어떤 문제가 생기는지도 모르고 굉장히 편리하네라고 생각했지만, 몇 개월 후 그 코드를 다시 열어봤을 때 이게 뭐하는 `div`였더라?라는 질문만 남았다. 여러 프로젝트를 경험하며 왜 모든 걸 `div`로 해결하면 안 되는가?라는 질문에 대한 답을 찾아가게 되었다. 그래서 이번 글에서는 단순히 시맨틱 HTML을 써라는 교과서적인 이야기가 아니라, 실제로 `div`를 남발했을 때 어떤 고통이 기다리고 있는지를 내 경험과 함께 풀어보려고 한다. 그전에... 왜 div만 쓰게 될까?솔직..

개요 국제화(i18n)를 구현하다 보면 번역 파일을 어떻게 관리할 것인가?라는 질문을 마주하게 된다. 처음에는 하나의 거대한 JSON 파일에 모든 번역을 때려넣으면 될 것 같지만, 프로젝트가 조금만 커져도 수천 개의 키가 뒤엉키게 된다. 그래서 이번 글에서는 국제화 파일을 페이지별로 분할해서 관리하되, 빌드 시점에 자동으로 병합하는 방식을 소개하려고 한다. 단순히 이렇게 하면 된다고 결론부터 내리기보다, 왜 이런 접근이 필요했는지, 그리고 실제로 어떻게 구현했는지의 흐름을 따라가보자. 문제파일 분할의 필요성국제화 파일을 단일 파일로 관리하면 처음에는 간단해 보인다. en.json 하나, ko.json 하나, 끝. 더 필요하면 es.json 혹은 ja.json 정도. 하지만 프로젝트가 커지면서 문제가 ..