소프트웨어를 릴리스할 때 "이 커밋이 v1.0.0이다"라고 표시해두면 나중에 특정 버전의 코드를 찾기가 훨씬 수월해지는데요. git tag는 바로 이런 용도로 특정 커밋에 이름표를 붙이는 명령어입니다. 커밋 해시를 외울 필요 없이 v1.0.0, v2.1.3 같은 의미 있는 이름으로 중요한 시점을 기록할 수 있죠. 이때 버전 번호를 매기는 규칙은 유의적 버전(SemVer)을 따르는 것이 일반적입니다. 태그 종류 Git 태그에는 두 가지 종류가 있습니다. Lightweight 태그는 단순히 특정 커밋을 가리키는 포인터입니다. 이름만 붙
Git으로 작업을 하다 보면 현재 브랜치에서 뭔가를 한창 수정하고 있는데 급하게 다른 브랜치로 전환해야 하는 상황이 생기곤 합니다. 아직 완성되지 않은 코드를 커밋하자니 찜찜하고 그렇다고 변경사항을 날리기엔 아까운데요. 바로 이럴 때 git stash가 유용합니다. git stash는 현재 작업 중인 변경사항을 임시로 저장해두고 나중에 다시 꺼내 쓸 수 있게 해주는 명령어인데요. 이번 글에서는 기본 사용법부터 실전에서 유용한 고급 활용법까지 함께 알아보겠습니다. 기본 사용법 git stash의 가장 기본적인 사용법은 간단합니다. 이
주변에 보면 경력과 무방하게 오픈 소스 기여에 관심이 있는 개발자 분들이 참 많은 것 같아요. 오픈 소스에 기여한 이력은 인터넷에 공개되어 있기 때문에 개인의 인지도를 높이는 데 도움이 되고, 오픈 소스 경험이 있는 개발자를 우대하거나 적극적으로 채용하는 기업들도 있으니까요. 뿐만 아니라, 오픈 소스 커뮤니티에서 활동하고 있는 전 세계의 개발자들과 협업하면서 글로벌 네트워크를 넓힐 수 있다는 점도 큰 매력인 것 같습니다. 무엇보다 자신이 작성한 코드가 무료로 많은 사람들에게 해택을 준다는 것은 개발자로서 정말로 보람된 경험이죠. 그
쉘을 처음 쓰시다 보면 누군가의 블로그나 README에서 이런 명령어를 자주 보게 됩니다. 가운데 들어 있는 | 기호가 도대체 무슨 역할을 하는지 처음에는 감이 잘 잡히지 않으실 텐데요. 이 기호를 파이프(pipe) 또는 파이프라인(pipeline)이라고 부릅니다. 이름 그대로 한 명령어의 출력을 다음 명령어의 입력으로 흘려보내는 관이라고 생각하시면 됩니다. 이번 포스팅에서는 리눅스 파이프의 기본 개념부터 실제로 자주 쓰는 조합 패턴까지 차근차근 살펴보겠습니다. 앞으로 파이프가 들어간 명령어를 보실 때 마음이 한결 편해지실 거예요.
자바스크립트의 배열은 forEach(), filter(),map(), reduce, every(), some() 등과 같이 콜백 함수를 인자로 받아 배열에 저장되어 있는 모든 원소로 상대로 호출해주는 함수들을 제공합니다. 이 함수들을 잘 활용하면 소위 함수형 프로그래밍(Functional Programming) 스타일로 코딩을 할 수 있게 되죠. 그런데 혹시 이러한 자바스크립트의 배열에 제공하는 함수에 비동기 함수를 인자로 넘기면 낭패를 볼 수 있다는 것을 아시나요? 이번 포스팅에서는 자바스크립트 배열 함수를 통해서 비동기 함수를
웹사이트를 만들다 보면 한 번쯤 이런 고민을 하게 되는데요. /about이라고 쓸까, /about/이라고 쓸까? 끝에 슬래시 하나 붙는 게 뭐 그리 대수일까 싶지만, 막상 운영해 보면 이 작은 문자가 검색 순위, 깨진 이미지, 끝나지 않는 리디렉션(redirect) 같은 문제로 돌아오곤 합니다. 😅 URL 끝에 붙는 이 슬래시를 트레일링 슬래시(trailing slash)라고 부릅니다. 결론부터 말씀드리면 이렇게 하면 됩니다. 빌드 결과물 모양에 맞춰 한쪽을 고릅니다. about/index.html처럼 페이지마다 디렉터리를 만든다
타입스크립트 프로젝트에서 @types/로 시작하는 수많은 패키지가 개발 의존성으로 설치되어 있는 것을 보신 적이 있으신가요? 아직 타입 선언이 낯설다면 TypeScript 입문 글에서 타입이 개발 단계에 어떤 역할을 하는지 먼저 살펴보셔도 좋습니다. 이번 포스팅에서는 이러한 패키지들이 도대체 왜 필요하며 어디서 오는 것인지에 대해서 간단히 알아보려고 합니다. Definitely Typed란? 자바스크립트는 생겨난지 30년이 다 되가는 프로그래밍 언어이지만 타입스크립트는 이제 겨우 탄생한지 10년이 조금 넘었습니다. 최근에 만들어진
React로 앱을 만들다 보면 서버에서 데이터를 가져오는 코드를 정말 자주 작성하게 됩니다. useEffect() 안에서 fetch()를 호출하고 useState()로 로딩 상태와 에러 상태를 관리하고 데이터가 오면 상태를 업데이트하고... 이 패턴을 몇 번이고 반복하다 보면 문득 이런 생각이 들지 않나요? "매번 같은 코드를 쓰고 있는데, 이걸 더 잘 처리하는 방법은 없을까?" 🤔 여기에 캐싱, 재시도, 백그라운드 갱신, 낙관적 업데이트까지 고려하면 상황은 더 복잡해집니다. 이런 문제를 정면으로 해결하기 위해 만들어진 라이브러리
요즘 어떤 프로그래밍 언어로 개발을 하든 코드 편집기로 VSCode를 참 많이 사용하는 것 같아요. 그런데 VSCode에서 마치 커서를 여러 곳에 둔 것처럼 동시에 편집할 수 있다는 것을 알고 계시나요? 잘 활용하면 여러분의 개발 생산성을 폭발시킬 수 있는 치트키와 같은 기능이죠! 이번 포스팅에서는 제가 VSCode에서 다중 편집을 위해서 즐겨 사용하는 멀티 커서 기능에 대해서 알려드리겠습니다. 멀티 커서 하나씩 추가하기 우선 멀터 커서를 사용하는 가장 기초적인 방법부터 알려드릴게요. VSCode에서 아무 파일이나 하나 여시고 맥(
지금까지 만든 구조에는 선이 하나뿐이었습니다. 애플리케이션이 백엔드로 직접 보내는 선이요. 서비스가 둘일 때는 아무 문제가 없죠. 그런데 스무 개가 되면 어떨까요? 백엔드 주소를 바꾸려면 스무 곳을 고쳐 배포해야 합니다. 어떤 속성을 모든 서비스에 붙이기로 했다면 역시 스무 곳이고요. 백엔드가 잠깐 죽으면 스무 개의 애플리케이션이 각자 재시도하다 메모리에 데이터를 쌓습니다. 😰 관측을 위해 넣은 코드가 서비스를 위협하는 셈이죠. 이 글에서는 그 사이에 두는 수집기(Collector)를 다루겠습니다. 파이프라인 세 조각 수집기는 텔
실시간 양방향 통신을 위해서 웹소켓(WebSocket)이 표준이 된지가 꽤 되었고, 현재 대부분의 모던 브라우저에서 웹소켓 API를 지원하고 있습니다. 하지만 여전히 우리는 모든 사용자가 최신 브라우저를 사용한다고 단정할 수 없으며, 웹소켓이 지원되지는 않는 환경에서는 어쩔 수 없이 대안 기술을 사용해야 하죠. Socket.IO는 이런 호환성 부분에 대해서 개발자가 크게 걱정할 필요없이 실시간 양방향 통신을 하는 웹 애플리케이션을 작성할 수 있도록 도와주는 라이브러리입니다. 이번 포스팅에서는 간단한 실습을 통해서 Socket.IO를
요즘 웹을 보면 예전에는 상상하지도 못했던 방식으로 여러 사용자와 실시간으로 양방향 상호작용을 하는 애플리케이션을 볼 수 있습니다. 대표적인 예로 다수의 참여자가 동시에 메시지를 주고 받는 채팅이나 실시간으로 게이머 간의 동기화해야 하는 온라인 게임을 들 수 있는데요. 게다가 최근에는 ChatGPT가 등장하면서 AI 기반 채팅 기능을 제공하는 웹사이트들이 점점 늘고 있는 것 같습니다. 이 블로그 글에서는 웹에서 이렇게 실시간 양방향 통신을 필요로 하는 애플리케이션을 구현하는데 필수적인 기술인 웹소켓(WebSocket)에 대해서 살펴
Git은 정말 강력한 도구이지만 명령어가 너무 많고 옵션도 복잡해서 막상 터미널에서 쓰려면 머리가 아플 때가 있습니다. git log --oneline --graph --all을 외우고 있는 사람이 몇이나 될까요? 😅 그렇다고 GUI 클라이언트를 쓰자니 무겁고, 터미널 작업 흐름이 끊기는 게 싫은 분들도 계실 겁니다. 이런 고민을 단번에 해결해주는 도구가 바로 Lazygit인데요. 터미널 안에서 동작하는 Git TUI(Text User Interface)로, 키보드 몇 번이면 스테이징부터 커밋, 브랜치 관리, 인터랙티브 리베이스까
올인원(All-in-one) 테스팅 프레임워크 Vitest를 사용하면 다른 라이브러리 설치 없이 바로 mocking과 spying 기능을 쓸 수 있는데요. 그런데 여기서 mocking과 spying을 한국어로 뭐라고 번역해야 모르겠네요. 😅 주변에서 보면 "모킹"과 "스파잉"으로 그냥 영어를 차용해서 쓰고 있는 것 같습니다. Mocking 이란? 먼저 mocking이 생소하신 분들을 위해서 mocking 대한 기본 개념부터 잡고 들어가는 게 좋을 것 같습니다. mocking은 단위 테스트를 작성할 때, 해당 코드가 의존하는 부분을
깨진 유리창의 법칙(Broken Windows Theory)을 들어보셨나요? 깨진 유리창을 방치하면 그 지점을 중심으로 범죄가 확산된다는 사회학 이론인데요. 이미 낙서가 되어 있는 화장실 벽에는 왠지 낙서를 더 해도 괜찮을 것 같은 느낌이 들거나, 누군가가 무심코 버린 작은 쓰레기 주변에 금세 쓰레기 더미가 쌓이는 모습은 깨진 유리창의 법칙의 대표적인 예입니다. 최근 많이 들리는 미국 캘리포니아 주에서 경범죄에 대한 처벌을 약화시킨 결과, 유명 브랜드들이 사업을 철수할 정도로 치안이 매우 좋지 않아졌다는 뉴스도 깨진 유리창의 이론의
React로 관리자 페이지나 대시보드를 만들다 보면 테이블 UI는 거의 빠지지 않고 등장합니다. 데이터를 표로 보여주는 것까진 괜찮은데, 정렬이나 필터링, 페이지네이션까지 붙이려면 코드가 금세 복잡해지죠 😅 예전에는 이런 걸 React Table이라는 라이브러리로 해결했는데요. 이 라이브러리가 v8에서 완전히 새로 설계되면서 이름도 TanStack Table로 바뀌었습니다. TanStack Query나 TanStack Start로 유명한 TanStack 생태계의 일원인데, "headless UI"라는 재밌는 접근 방식을 쓰고 있습
차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌 자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂 📝 블로그: https://bun.com/
테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다. 이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다. 테스트 대상 코드 데이터베이스에 접근하는 애플리케이션에 대한 테스트를 작성한다는 가정 하에 예제 코드를 작성해보겠습니다. 최대한 간단한 예제를 위해서 자바스크립트 배열로 데이터베이스를 대신하도록 할께요. 사용자 데이터
길고 복잡한 코드에 대한 테스트를 작성하다보면 테스트 코드의 양도 비례해서 늘어나게 되기 마련지요? 하나의 파일 안에 테스트 코드가 많아지면 도대체 어느 테스트가 어떤 기능을 위한 것인지 빠르게 파악하기가 어려워집니다. 게다가 디버깅을 하다보면 특정 테스트만 실행하거나 특정 테스트만 제외하고 테스트를 해야하는 경우도 생기죠. 이번 포스팅에서는 이러한 상황을 효과적으로 대처하기 위해서 Vitest로 어떻게 테스트를 깔끔하게 묶어서 관리하고 테스트 별로 실행 제어를 할 수 있는지 알아보려고 합니다. 테스트 케이스와 스위트 테스트를 그룹
블로그를 운영하다 보면 독자와 소통하고 싶다는 생각이 들 때가 있습니다. 글에 대한 피드백을 받기도 하고 궁금한 점을 질문으로 남겨주시는 분도 계시죠. 때로는 본문보다 댓글에서 더 좋은 방법을 알게 되기도 하고요. 문제는 정적 블로그에 댓글 기능을 붙이려면 별도 서버나 데이터베이스가 필요하다는 겁니다. Disqus 같은 서비스를 쓸 수도 있지만 광고가 붙고 사용자 추적도 신경 쓰이고요. 이럴 때 쓸 만한 도구가 Giscus입니다. GitHub Discussions를 댓글 저장소로 쓰는 오픈소스 프로젝트인데요, 별도 서버 없이 댓글