들어가기 앞서... 세상 모든 일이 그렇듯, 무조건 옳거나 그른 것은 없다. 굳이 꼽자면 물리 법칙 정도일까? 하지만 그마저도 언제든 새로운 발견으로 뒤집힐 수 있다. 회고를 시작하며 뜬금없이 이런 이야기를 꺼내는 이유는, 이 글이 나만의 주관적인 경험과 생각일 뿐 절대적인 진리가 아니기 때문이다. 내가 겪은 상황과 감정이 지금은 맞아 보일지 몰라도, 다른 관점에서는 틀릴 수도, 혹은 애초에 잘못된 전제일 수도 있다. 지난해 작성했던 포트폴리오 글이 감사하게도 많은 관심을 받았다. 깃허브 레퍼런스로 활용되기도 하고, 취업 준비를 하던 지인들에게 도움이 되었다는 연락도 받았다. 뿌듯함과 동시에 '혹시 내 글이 누군가에게 잘못된 가이드를 주진 않았을까?' 하는 책임감도 무겁게 느꼈다. 정보를 공유하는 사..

핵심만 원한다면 "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..

개요 열심히 기능 개발하고, 버그 잡고, 배포도 했는데 막상 글로 적으려니 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로 띄우면 되는 거 아닌가?' 싶지만, 막상 해보면 생각보다 까다로운 문제들이 발생한다. 오늘은 이 '더보기' 버튼을 자연스럽게 넣기 위해 삽질했던..