useRef는 언제 사용하나요?DOM 조작 및 접근: 특정 DOM 요소에 접근하거나 조작할 때 사용값의 변경 추적: 값이 변경되더라도 리렌더링되지 않는다는 특징을 활용, 값이 유지할 때 사용const ref = React.useRef(null);{children}; useRef를 통해 렌더링 이후 해당 DOM 노드를 참조하고, 컴포넌트가 언마운트될 때 다시 null로 설정됩니다.렌더링 이후 특정 DOM 요소에 접근하기: useEffect와 callback refuseEffect를 사용한 경우useEffect를 통해 렌더링 이후 특정 DOM 요소에 접근할 수 있습니다.const ref = React.useRef(null);React.useEffect(() => { if (ref.current) { ..

우리는 모두가 설계자이자 이해당사자입니다. 업무와 일상에서 끊임없이 문제를 해결하고 결정을 내리는 과정 속에서 우리는 설계자의 역할을 맡기도 하고, 때로는 다른 사람의 결정에 영향을 받는 이해당사자가 되기도 합니다. 설계자는 복잡한 문제를 풀어내며 더 나은 솔루션을 찾기 위해 노력하고, 이해당사자는 그 솔루션이 자신의 상황에 어떻게 영향을 미칠지 고민합니다. 하지만 이 둘의 경계는 생각보다 명확하지 않습니다. 설계자의 결정은 이해당사자에게 직간접적으로 영향을 미치고, 이해당사자의 피드백은 설계자의 다음 결정을 좌우합니다. 결국, 설계자와 이해당사자는 서로의 역할을 넘나들며 상호작용하고, 이러한 과정 속에서 갈등과 협력, 그리고 새로운 기회를 만들어 갑니다. 따라서 설계자와 이해당사자가 서로의 입장에서 공..

TypeScript의 꽃🌷이라 할 수 있는 타입추론(Type Inference)과 Generic Type의 부분 타입추론 문제에 대해 알아봅니다. 이 주제에 대해 관심이 생긴다면 꼭 끝까지 파헤쳐 개념을 이해하시길 바랍니다. 이 글은 타입스크립트를 활용해 보았으며, Generic Type에 대한 기본적인 이해가 있음을 바탕으로 합니다. TL;DR TypeScript Generic은 완벽하지 않습니다. 조금 더 자세히 말해보자면 Generic의 부분적인 추론은 완벽하지 않습니다. TypeScript는 모든 Generic에 대해서 추론해 낼 수 있지만, 부분적인 추론에 대해서는 지원하지 않습니다. (적어도 현재까지는) 부분 추론 타입이 제한되는 상황에서 Generic Function에 대해 정상적인 추론을 ..

개발과 비개발의 충돌: 논리와 현실의 간극우리가 해결해야 할 문제는 종종 논리적 가능성과 현실적 가능성의 중간지대에 놓여 있습니다. 특히 개발직군과 비개발직군 사이에서 더 극명하게 드러나곤 합니다. 개발직군은 제품의 안정성과 신뢰성을 유지하기 위해 엣지 케이스까지 고려하며 논리적 결함을 허용하지 않으려는 경향이 있습니다. 모든 가능한 상황을 예측하고 대비해야 한다는 압박 속에서, 개발자들은 논리적 완결성에 집중합니다. 반면, 비개발 직군은 현실적인 가능성, 즉 시장의 요구와 고객의 실제 사용 패턴과 상황에 더 큰 무게를 둡니다. 그들에게는 제품이 사용될 현실적인 환경과 고객의 경험이 더 중요한 요소로 작용합니다. 이런 관점 차이로 종종 개발직군이 중요시하는 논리적 접근을 비개발직군에게는 지나치게 복잡하거..

기존 코드가 복잡하고 이해하기 어려울수록(코드를 만드는 데 더 많은 투자가 이루어질수록) 코드를 유지해야 하는 압박감을 더 많이 느낀다. 여기서 매몰비용의 오류가 발생한다. 매몰비용의 오류? 미래에 발생할 한계 편익과 한계 비용을 비교하여 의사결정을 해야 함에도 불구하고 사람들이 과거에 지출된 매몰 비용을 고려함으로써 비합리적으로 선택하는 현상 성급한 추상화를 피하라 공유하는 코드를 통해 매개변수를 전달하고 조건부 경로를 추가하고 있다면 이미 추상화가 잘못된 것이다. 추상화가 잘못된 것으로 판단된다면 가장 좋은 전략은 다시 중복코드를 생산해 무엇이 옳은지 보는 것. 즉, 잘못된 추상화에 대처할 때 가장 빠른 방법은 되돌아가는 것이다. 이것은 후퇴가 아니라 더 나은 방향으로 나아가는 길이다. 중복된 부분을..

shadcn이 얼마전 vercel팀에 Design Engineer로 합류했다는 소식이 들려왔습니다. 앞으로도 오픈 소스 커뮤니티를 위한 커스터마이징 가능한 UI 컴포넌트를 계속 만들어낼 것이라고 하며, 근시일 내 놀라운 무언가를 출시할 것만 같습니다. 현재 회사에서 활용중인 antd의 커스터마이징 어려움을 느낀 직후 이 프로젝트를 보고(당시 이 프로젝트는 완전 초기) Design System을 구축하는데 있어서 괜찮은 선택이지 않을까 생각했었는데, 발전되는 모습을 지켜보고 있자니 그때보다는 조금 더 기울어진 것 같습니다. 역사와 함께 알아보는 흐름 shadcn/ui는 눈에 띄지 않는 이름에도 지난 몇 달 동안 인기를 끌었습니다. 주요 이유로는 스스로를 라이브러리라고 부르기를 거부하기 때문인데요, 모든 C..

interface를 써야한다. type을 써도 괜찮다. 이에 관한 의견 차이가 약간 있었고, 이에 타입 선언 규칙을 정리했다. 그래서 무엇을 쓰는게 좋은건가? 나는 사실 Declaration Merging이 필요한 경우를 제외하곤 Type alias만을 사용하는 쪽이긴 한데 깊게 들어가서 차이를 비교해보니, interface를 적절히 사용함으로써 개념적인 정리와 이해에 대한 장점이 있었고 (프로젝트마다 다르겠지만)성능적인 이점도 있는 것을 알게 되었다. 결론은.. "객체" 에 대해서 interface를 선호하고, Inheritance 관련한 부분 이외엔 type을 사용하는 쪽으로 정리했다. 😄 이 글은 그 정리에 대한 결과이다. Primitive types 💡 Primitive types을 사용할 때 t..

올해 서른, 내년도 서른이겠지만 지금까지의 신년 계획은 실패로 끝날게 뻔할 금연뿐이었지만 올해의 시작은 새로운 다짐과 마음가짐으로 시작하고 싶었다. 하지만 많은 시간을 고민해보아도 미래의 모습이 잘 상상이 되지 않았고, 그렇게 제대로 그려지지 않은 미래에 대한 실현 의지도 생기지 생기지 않을 것 같았고, 한편으로는 나이를 들어감에 어떤 책임감과 압박감에 염려가 되기도 했다. "풀을 베는 사람은 들판의 끝을 보지 않는다" 프랑스 속담에 있는 말으로, 농부가 풀을 벨 때 들판의 끝을 보면 '이 넓은 들의 풀을 언제 다 베지?'라는 푸념과 함께 의욕을 잃는다는 것이다. 이번 계획을 통해 의욕을 잃지 않고 즐거운 마음으로 풀을 베는데 집중하며, 앞으로 다가올 낯선 시간을 보다 현명하게 이용할 수 있는 밑바탕이 ..

올해 6월 중순 새로이 시작한 사이드 프로젝트 팀원들과 서비스 오픈을 앞두고 1박 2일간의 나들이를 다녀왔다. (처음 계획을 전달받았을 때 서비스 오픈을 앞두고 1박 2일간의 해커톤인 줄 알고 굉장한 기대를 했다...) 결론부터 말하자면 오랜만에 MT와 같은 느낌으로 바람도 쐬고, 맛있는것도 먹으며, 좋은 시간을 보내며 리프레시할 수 있었다. 그리고 같은 프론트엔드 개발자 분과의 대화를 통해 다시 무언가를 깨닫게 된 의미 있는 시간이었다. 팀원분은 나와 마찬가지로 디자이너에서 전직한 1년차 프론트엔드 개발자이며, 현시점에서 각 분야의 일한 기간이 나와는 정확히 반대인 케이스다. 지난밤, 프로젝트 진행 간 어려운 부분이 있으시다며 다음날 카페에서 라이브 코딩으로 알려주실 수 있는지 물어보셨다. 거절할 이유..

Next.js의 개발 서버는 기본적으로 3000 포트에서 실행되도록 설정되어 있습니다. 개발 환경에 따라 다른 포트에서 개발 서버를 실행해야 경우가 종종 생기는데 이를 변경할 수 있는 방법을 알아봅시다. 1. 직접 변경하기 // package.json { ... "scripts": { "dev": "next dev -p 3005", "build": "next build", "start": "next start" } ... } -p 옵션을 통해 뒤에 입력된 포트로 개발 서버가 실행됩니다. 2. 환경변수 사용하기 // package.json { ... "scripts": { "dev": "next dev -p ${PORT-3000}", "build": "next build", "start": "next st..

개발자로서 Git은 매우 중요한 부분입니다. Git과 상호작용 하지 않고 하루를 보낼 수는 없습니다. 일반적으로 터미널에서 Git을 실행하거나 Sourcetree와 같은 GUI도구를 사용합니다. 우리는 Git의 명령어를 기억하고, 작성하는 것이 어렵고 소모적인 것을 알고 있습니다. GUI툴을 사용한다면 Git 명령어를 외울 필요가 없어 정말 쉽게 사용할 수 있습니다. 직관적으로 보이고 또 강력한 부가기능들도 포함되어 있습니다. 하지만 터미널에서만 Git을 실행하는 것을 좋아하는 fan이 분명 존재합니다. 터미널 fan을 위한 효율적인 어떤 방법이 없을까요? 우리는 Git Alias를 설정해 Git 명령어를 별칭으로 저장해 Git을 좀 더 쉽고 빠르게 사용할 수 있습니다. 그럼 Git Alias는 어떻게 ..

개발자로서 업무를 진행하다 보면 자연스럽게 markdown을 접하고 사용하게 됩니다. 마크다운은 텍스트 기반의 경량 마크업 언어로 쉽고 간단하게 서식이 있는 문서들을 작성하는데 용이합니다. README.md는 물론 issue template, pull request template를 만들어 사용하기도 하고 어떤 분들은 TIL과 스터디 자료를 정리해 개인 리포지토리에 저장하기도 합니다. 저 또한 마찬가지로 클린코드 스터디를 진행하며 md파일로 정리했던 섹션이 있었습니다. 저는 마크다운으로 작성하며 내용이 많아지니 미리 보기에 대한 니즈가 있었습니다. VS Code 내에서 관련 Extension이 있는지 찾아보고 사용해보니 그 외의 기능들도 경험이 좋아 추천하고자 글을 작성합니다. Markdown All i..

github의 pull request는 draft 상태로 올릴 수 있는 기능이 존재합니다. * private 리포지토리는 유료 플랜이 필요 Draft 상태의 PR은 작업중인 상태로 Merge를 막을 수 있습니다. 언제, 어떻게 사용할 수 있을까요? 현재 회사에서는 Draft PR을 다음과 같은 규칙을 만들어 활용하고 있습니다. 1. topic으로 다른 개발자와의 의견 조율 및 소통이 필요할 때 2. 변경사항이 많아 리뷰가 힘들어짐을 방지하기 위해 PR을 나누어 올릴 때 순차적으로 Merge하기 위해 즉, PR을 올리는 행위는 테스크가 완료되어 코드리뷰를 하고 Merge하기 위한 것으로 정리할 수 있었기에 git-action은 그 시점에서 필요한 것이고, Draft PR에서도 git-action이 동작하는..

프로젝트 진행 간 아래와 같은 문제가 발생한 경험이 있나요? 1. 같은 커밋에 위치했는데 A 개발자는 프로그램이 문제없이 동작하고, B 개발자는 프로그램이 에러가 발생한다. 2. 변경사항을 pull 받고 install 했더니 코드의 변경사항은 없는데 package-lock.json파일의 변경사항이 있다. 너무나 익숙하지만 어떤일을 하는 녀석인지 대부분 모르고 지나가는 package-lock.json에 대해서 내용을 정리해 글을 작성합니다. package.json 그리고 package-lock.json 기본적으로 package.json은 npm에 패키지를 배포하기 위해 반드시 필요한 "문서"입니다. 또한 프로젝트의 의존성 관리를 위한 명세라 할 수 있습니다. npm 버전 5 이상에서 npm install을..

여느날처럼 프로젝트를 둘러보며 둘러보며 코드를 구석구석 청소하고 있었다. 그러던 중 약 10개월 전 작성 된 코드중 정상적으로 동작하지 않는 코드를 발견했다. 해당 코드의 commit history가 남아있어 PR을 살피며 이부분은 명백히 프로그램이 개발자의 의도에 따라 동작하지 않는 버그로 판단을 내릴 수 있었다. 나는 당연하게도 본래 의도한 대로 동작할 수 있도록 코드를 정리하며 해당 버그를 수정했다. 오랜시간 보고되지 않고 숨어있던 버그를 해결한 것에 안도감과 뿌듯한 마음이 들었다. 그런데 버그를 수정한지 며칠 후 해당 부분이 제대로 동작하지 않는다는 리포트가 들어왔다. 여지껏 그렇게 동작하던 것이 프로그램의 버그였고 지금에서야 정상적으로 동작하는것이 맞다. 하지만 사용자 입장에서는 그간 사용해왔던..

개발직군에 대한 관심도가 날이 갈수록 증가하며 사내에서도 다른 분야의 직원들이 생기기 시작했다. 누군가는 취미로, 만들고 싶은 아이템을 실현하기 위한 도구로 또는 커리어의 전환을 위해 각자의 목적을 가지고 있었다. 개발팀 내에서는 이들을 위해 사내 개발 스터디 그룹을 만들고 지원하고자 하는 계획을 세웠다. 그 첫걸음으로, 회의를 통해 '개발자가 되고싶은 히치하이커를 위한 안내서'라는 큰 주제 아래에서 각자 준비해 발표하도록 했다. 나는 디자이너에서 전환한 비전공자 출신 프론트엔드 개발자다. 그 과정에서 힘든점도 있었고 누구보다 그 상황을 이해할 수 있을 거라 생각했다. 그렇기에 나와 같은 상황의 동료를 이끌어 줄 수도 있다는 생각에 기대와 설렘이 있었고 한편으로는 걱정이 되기도 했다. 발표를 준비하며 출..

진행 중인 프로젝트 내 비슷한 로직을 처리하는 Modal UI가 10개가량 존재하는 것을 발견했다. 자연스럽게 컴포넌트로 추출되었을 법 한데 무엇 때문인지 각각 존재하고 있었다. // 초기 컴포넌트의 형태 type Payload = { foo: string; bar: string; baz: string; }; type WithRequestComponentProps = {}; const WithRequestComponent = ({}: WithRequestComponentProps) => { const { register, handleSubmit } = useForm(); const onSubmit: SubmitHandler = (payload) => { // 서버로의 요청 }; return ( ); };..

이직 후 새로운 회사에서는 이전까지 프로젝트 일정을 핑계 삼아 제대로 하지 못한 Pull Request(PR)와 코드 리뷰 문화에 익숙해지기 시작할 때쯤 느꼈던 불편한 부분들과 이를 어떻게 개선하고자 하였는지에 대해 경험을 공유합니다. 어떤 문제가 발생했나? 제목에만 의존적인 PR 거의 대부분이 제목에만 의존적인 PR로 제목과 함께 변경된 코드들로만 내용을 Reviewer가 추측하고 있었고, 간혹 리뷰를 직접 말로 주고받고 하다보니 중복되는 Comment가 발생하기도 했다. 개발자는 코드로 말한다지만... 코드가 자신을 설명할 수 있다면 정말 좋겠지만, 문제영역과 깊숙하게 연관되어 있는 내용에 대해서는 코드만으로 설명이 어려울 때가 많았다. 오랜 기간 진행되어온 프로젝트로 각자 담당하고 있는 파트가 존재..

최근 가벼운 Next.js를 활용 한 프로젝트를 진행하며 사용자 인증 관리를 NextAuth.js를 통해 구현해보았다. Next.js 프로젝트에서 간편하게 인증관리를 할 방법이 없을까 고민을 하고 있던 차 NextAuth.js를 알게 되었고, 가벼운 프로젝트기에 부담 없이 적용해보았다. NextAuth에서 제공하는 많은 Provider 중에 Credentials를 이용하여 사용자 인증을 구현, 관리하도록 세팅했다. 실 적용하는데에는 크게 문제가 없었고, 배포 이후 클라이언트 측의 IE 환경에서의 문제가 발견되었다. 로그인 진행이 안 되어 관리자 페이지는 확인 못 하였으나... (생략) Problem 1. NextAuth는 수시로 /api/auth/session을 요청하며 수시로 로그인 상태인지를 확인하도..