개요 프론트엔드 개발자라면 누구나 한 번쯤 이런 순간이 온다. 디자인 시스템이 없어서 매번 버튼 스타일을 복사-붙여넣기 하는 게 답답하거나, 레거시 코드가 섞인 컴포넌트 파일이 500줄을 넘어가는 걸 볼 때 참을 수 없는 충동을 느낀다. "이거 내가 싹 정리해서 공통 컴포넌트로 만들면 대박이겠는데?""지금 쓰고 있는 라이브러리 너무 구려. 요즘 뜨는 걸로 바꾸면 개발 속도 빨라질 텐데." 시작은 언제나 순수한 열정이다. 불편함을 해소하고, 코드를 우아하게 만들고 싶다는 선의다. 하지만 잠시 키보드에서 손을 떼고 냉정하게 생각해 보자. 그거, 정말 지금 우리 팀에 필요한 거 맞나? 혹시 나만의 기술적 만족감을 채우기 위한 욕심은 아닐까? 오늘은 현직 개발자들과의 대화 도중 나온 주제를 바탕으로, 주니..

개요 대한민국 남자 개발자라면 누구나 한 번쯤 마주하는 거대한 벽이 있다. 바로 군대다. 많은 이들이 경력을 끊지 않으면서 국방의 의무를 해결할 수 있는 산업기능요원(병역특례)에 눈을 돌린다. 하지만 요즘은 TO가 줄고 채용 트렌드가 급변하면서 전략 없이 덤볐다간 시간만 날리기 십상이다. 필자 역시 이 과정이 순탄치 않았다. 주변에 마땅히 정보를 얻을 만한 사람이 없었기 때문이다. 병특에 해당됐던 지인들은 개발자 붐이 일던 코로나 시기에 이미 좋은 곳에서 해결해버렸고, 그마저도 나와는 개발 스택이 달라 실질적인 도움을 받기 어려웠다. 결국 맨땅에 헤딩하듯 혼자 정보를 찾고, 개발 스택까지 바꿔가며 일반 회사를 다녔다. 그렇게 퇴근 후 사이드 프로젝트까지 병행하며 꼬박 2년이 걸려서야 겨우 병특을 시작할..

개요 출퇴근길, 습관처럼 인스타그램을 켠다. 지인들의 소소한 일상보다는 릴스를 시청하며 시간을 보낸다. 30분이라는 시간 제한을 둔 채, 주로 유머나 개그 콘텐츠를 소비하다 보면 알고리즘은 비슷한 영상을 끊임없이 추천해 준다. 개중에는 가끔 정치적, 사회적 이슈를 다룬 릴스가 섞여 있기도 하다. 보통 그런 영상의 댓글창은 전쟁터를 방불케 하기에 굳이 열어보지 않으려 한다. 하지만 호기심을 이기지 못하고 댓글창을 열었다가 후회하는 일이 종종 있다. 원본 영상의 일부만 잘라낸 릴스를 보다 보면, 같은 내용임에도 댓글 반응이 천차만별인 경우를 목격하게 된다. 첫 댓글의 논조에 따라 전체 여론이 형성되는 현상, 즉 '누가 먼저 어떤 평가를 내렸느냐'가 집단의 반응을 결정짓는 미묘한 광경을 마주하게 되는 것이다..

개요 회사와 사이드 프로젝트에서 디자인 시스템을 구축하게 됐다. React 기반에 Radix UI를 사용하고, Tailwind CSS로 스타일링하고, Storybook으로 문서화하는 전형적인 구성이었다. 하지만 여기서 한 가지 독특한 시도를 했다. 컴포넌트의 스크린샷을 자동으로 캡처해서 JSDoc에 주입하는 파이프라인을 만든 것이다. ▼ 'Storybook이 있는데 도대체 왜?' 라는 의문이 들 수 있을 것이다. 지금부터 왜 이런 걸 만들었고, 어떻게 구현했고, 실제로 얼마나 유용한지 정리해보려 한다. 문제 상황: 컴포넌트를 확인하려면 어디로 가야 하나?일반적인 디자인 시스템 사용 경험디자인 시스템을 만들어 본 사람이라면 알겠지만, 컴포넌트를 쓸 때 항상 이런 과정을 거친다. ▼"이 버튼 컴포넌트 어떻..

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

핵심만 원한다면 "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란 두 방식의 차이는 단순히 중괄호 `{}`를 쓰냐 마냐의 문제..