개요 개발을 하다 보면 무의식적으로 `` 태그를 남발하게 되는 경우가 많다. 당장 스타일링하기 편하고, 별다른 고민 없이 레이아웃을 잡을 수 있기 때문이다. 하지만 ``로 점철된 코드는 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..

개요 열심히 기능 개발하고, 버그 잡고, 배포도 했는데 막상 글로 적으려니 XX 기능 개발, YY 페이지 구현 같은 밋밋한 문장밖에 떠오르지 않았다. 솔직히 그런 것들은 기본적으로 해야하는 것들이다. 정말 특수한 기능, 알고리즘이 들어간다거나 혹은 완전히 새로운 로직이 들어가는 기능이 아니고서 구현이나 개발 이라는 것을 쓰는건 작성하는 사람이나 읽는 사람이나 모두 시간낭비가 될거라고 생각했다. 일단 기억나는 대로 적어서 주변의 현업 개발자 지인들에게 피드백을 요청했다. 돌아온 답변은 이랬다. "너무 겸손하게 작성하면 안돼.""이건 자랑인 거랑 자랑 아닌 게 섞여 있어서 평균이 깎여 보여.""자기소개에 대한 증거가 없어. 임팩트를 끼쳤다는 증거가 될 만한 내용이 하나도 없잖아." 이력서는 겸손을 떠..

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

개요 최근 이직 준비를 하면서 이력서를 다시 작성하게 되었다. 그런데 막상 키보드에 손을 올리니 내 경력을 어떻게 포장할지보다 더 원초적인 고민이 앞섰다. "도대체 무슨 툴로 써야 하지?". 주변 개발자 지인들과 선배들에게 조언을 구해봤지만, 돌아오는 대답은 정말 천차만별이었다. "요즘 스타트업은 무조건 노션(Notion)이지.""무슨 소리야, 근본은 워드(Word)지. 인사팀은 보수적이라니까?""요즘은 피그마(Figma)로 깔끔하게 디자인해서 PDF로 주는 게 트렌드야." 각각의 주장이 너무나 타당해서 마음이 이랬다 저랬다 갈대마냥 흔들렸다. 하지만 동시에 반대 의견도 만만치 않았다. "노션은 너무 가벼워 보인다", "워드는 촌스럽다", "피그마는 배보다 배꼽이 더 크다" 등등. 그래서 이번 기회..

문제N×M크기의 배열로 표현되는 미로가 있다.101111101010101011111011 미로에서 1은 이동할 수 있는 칸을 나타내고, 0은 이동할 수 없는 칸을 나타낸다. 이러한 미로가 주어졌을 때, (1, 1)에서 출발하여 (N, M)의 위치로 이동할 때 지나야 하는 최소의 칸 수를 구하는 프로그램을 작성하시오. 한 칸에서 다른 칸으로 이동할 때, 서로 인접한 칸으로만 이동할 수 있다.위의 예에서는 15칸을 지나야 (N, M)의 위치로 이동할 수 있다. 칸을 셀 때에는 시작 위치와 도착 위치도 포함한다. 입력첫째 줄에 두 정수 N, M(2 ≤ N, M ≤ 100)이 주어진다. 다음 N개의 줄에는 M개의 정수로 미로가 주어진다. 각각의 수들은 붙어서 입력으로 주어진다. 출력첫째 줄에 지나야 하는 최소의..

개요 컴포넌트를 만들다 보면 필연적으로 간격을 어디에 줄 것인가에 대한 고민에 빠지게 된다. 예를 들어, 리스트에 들어갈 `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..