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

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

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

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

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