깨진 유리창의 법칙(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.sh/b
테스트를 작성하다 보면 여러 테스트에 걸쳐서 반복되는 로직이 생기기 마련인데요. 이러한 공통 로직을 모든 테스트마다 중복해서 작성하면 개발 생산성이 떨이지고 유지보수가 힘들어집니다. 이번 포스팅에서는 Vitest를 이용해서 테스트 전이나 후에 항상 실행되야 하는 로직을 효과적으로 실행하는 방법에 대해서 알아보겠습니다. 테스트 대상 코드 데이터베이스에 접근하는 애플리케이션에 대한 테스트를 작성한다는 가정 하에 예제 코드를 작성해보겠습니다. 최대한 간단한 예제를 위해서 자바스크립트 배열로 데이터베이스를 대신하도록 할께요. 사용자 데이터
길고 복잡한 코드에 대한 테스트를 작성하다보면 테스트 코드의 양도 비례해서 늘어나게 되기 마련지요? 하나의 파일 안에 테스트 코드가 많아지면 도대체 어느 테스트가 어떤 기능을 위한 것인지 빠르게 파악하기가 어려워집니다. 게다가 디버깅을 하다보면 특정 테스트만 실행하거나 특정 테스트만 제외하고 테스트를 해야하는 경우도 생기죠. 이번 포스팅에서는 이러한 상황을 효과적으로 대처하기 위해서 Vitest로 어떻게 테스트를 깔끔하게 묶어서 관리하고 테스트 별로 실행 제어를 할 수 있는지 알아보려고 합니다. 테스트 케이스와 스위트 테스트를 그룹
블로그를 운영하다 보면 독자와 소통하고 싶다는 생각이 들 때가 있습니다. 글에 대한 피드백을 받기도 하고 궁금한 점을 질문으로 남겨주시는 분도 계시죠. 때로는 본문보다 댓글에서 더 좋은 방법을 알게 되기도 하고요. 문제는 정적 블로그에 댓글 기능을 붙이려면 별도 서버나 데이터베이스가 필요하다는 겁니다. Disqus 같은 서비스를 쓸 수도 있지만 광고가 붙고 사용자 추적도 신경 쓰이고요. 이럴 때 쓸 만한 도구가 Giscus입니다. GitHub Discussions를 댓글 저장소로 쓰는 오픈소스 프로젝트인데요, 별도 서버 없이 댓글
Slack에서 코드 리뷰 요청하는 알림을 확인하고 PR을 열어보았습니다. 제법 많은 양의 코드가 추가되었는데 테스트 코드가 전혀 없더군요. 그래서 저는 PR을 승인하지 않고, 추가한 코드에 대한 테스트 코드를 작성해 달라는 짧은 코멘트를 남겼습니다. 다음 날, 코드 리뷰를 요청했던 개발자가 속한 팀의 stand-up 미팅에 참석했습니다. 그런데 그 친구가 PM(Project Manager)에게 약간 원망조로 얘기를 하더군요. 어제 자기는 빨리 코딩을 하고 팀원들에게 리뷰를 요청했지만, 아무도 승인해주지 않아서 배포를 할 수가 없었다
Astro로 사이트를 만들다 보면 .astro 파일을 수도 없이 만들게 됩니다. 처음에는 HTML이랑 비슷하니까 감으로 쓰다가, 어느 순간 "이 컴포넌트에 props를 어떻게 넘기지?", "슬롯이 여러 개 필요한데?", "스타일이 자식 컴포넌트까지 먹히질 않네?" 같은 질문이 하나둘 쌓이기 시작하죠. 사실 Astro 컴포넌트는 겉보기엔 단순하지만 파고 들어가면 꽤 많은 게 숨어 있습니다. TypeScript 기반의 Props 타입 시스템, 이름 있는 슬롯과 폴백 콘텐츠, CSS 스코핑과 전역 스타일 제어, 동적 태그까지. 이 글에서
Node.js로 웹 서버를 만들 때 오랫동안 Express가 사실상 표준이었는데요. 그런데 최근 몇 년 사이에 Cloudflare Workers, Deno, Bun 같은 새로운 런타임들이 등장하면서 상황이 달라지고 있습니다. Express는 Node.js에 특화되어 있어서 다른 런타임에서 그대로 쓸 수 없거든요. 이런 흐름 속에서 Hono가 주목받고 있습니다. Hono는 웹 표준(Web Standards) API 위에 만들어진 경량 웹 프레임워크로, 같은 코드가 Bun이든 Deno든 Cloudflare Workers든 어디서나 돌아
테스트를 작성하시다보면 어떤 함수나 호출한 후 예상 결과가 실제과 동일한지 검증하는 작업을 많이 하는데요. Vitest는 테스트를 작성할 때 효과적인 결과값 매칭이 가능하도록 Jest의 API와 호환되는 다양한 매처 함수를 제공하고 있습니다. 이번 포스팅는 실전 테스팅에서 많이 사용되는 Vitest의 매처 함수를 하나씩 살펴보면서 언제 어떻게 활용하는지 알아보겠습니다. 차세대 테스팅 프레임워크로 각광받고 있는 Vitest에서 생소하시다면 먼저 소개 포스팅을 읽어 보시고 돌아오시기를 추천드립니다. 검증 (Assertion) 테스트라는
영상 편집이라고 하면 보통 프리미어 프로나 파이널 컷 같은 전문 편집 도구를 떠올리게 되는데요. 만약 React 컴포넌트를 작성하듯이 코드로 영상을 만들 수 있다면 어떨까요? Remotion은 바로 그런 발상에서 출발한 프레임워크입니다. React와 TypeScript로 영상의 모든 요소를 코드로 제어하고 최종적으로 MP4 파일로 렌더링할 수 있게 해주죠. GitHub 스타 38,000개에 월간 설치 수 90만 건을 넘길 정도로 개발자들 사이에서 관심을 많이 받고 있습니다. 이번 포스팅에서는 Remotion의 핵심 개념부터 실전 활
개발자 채용을 위한 면접을 하다보면 본인이 합류하게 될 회사나 팀이 어떤 기술을 사용하는지에 대해 신경을 쓰는 지원자들이 정말 많은데요. 어떤 프로그래밍 언어로 개발을 하는지부터, 어떤 프레임워크와 라이브러리를 사용하는지, 어떤 데이터베이스와 클라우드 컴퓨팅을 쓰는지 등등... 이렇게 꼬리에 꼬리를 잊는 질문이 이어지죠. 제 답변을 들은 후 실망하는 표정을 감추지 못하는 지원자도 보았습니다 😞 그러나 정작 본인이 지원한 회사가 어떤 사업을 하는지에 대한 관심을 갖고 좋은 질문을 하는 개발자들은 상대적으로 드문 것 같아요. 혹시 기
데이터베이스 인덱스는 어떻게 조회를 빠르게 만들까?에서 인덱스가 빠른 이유를, 복합 인덱스는 왜 컬럼 순서가 중요할까?에서 컬럼 순서 규칙을 확인했는데요. 그런데 실무에서 더 자주 마주치는 건 이런 상황입니다. 인덱스를 분명히 걸었고 컬럼 순서도 맞췄는데 쿼리가 여전히 느린 경우요. 인덱스는 만들어 두는 것만으로 일하지 않습니다. 쿼리를 어떻게 쓰느냐에 따라 멀쩡한 인덱스가 통째로 무시되기도 하거든요. 이번 글에서는 인덱스가 있는데도 안 타는 경우를 하나씩 재현해 보겠습니다. 실험 준비 실습 데이터는 지난 글에서 쓰던 50만 명짜리
Lighthouse로 사이트 성능을 측정해 보면 이미지 때문에 점수가 깎이는 경우가 정말 많은데요. HTTP Archive에 따르면 평균 웹 페이지에서 이미지가 전체 바이트의 절반 가까이를 차지한다고 합니다. 포맷 변환, 리사이징, lazy loading, 반응형 srcset까지 직접 챙기려면 꽤 번거롭죠. Astro는 이런 작업을 프레임워크 차원에서 해결해 줍니다. 별도의 플러그인 없이 <Image />와 <Picture /> 컴포넌트만 쓰면 빌드 시 알아서 처리하거든요. 사실 이 블로그도 Astro로 만들었는데, 이미지 최적화
블로그를 운영하다 보면 마크다운 파일이 수십, 수백 개로 늘어나는 건 시간문제입니다. 처음에는 프런트매터에 title이나 date를 성실히 적다가도, 어느 순간 date 포맷을 잘못 쓴다든지, tags를 빠뜨린다든지 하는 실수가 슬슬 나타나기 시작하죠. 문제는 이런 실수가 조용히 사이트에 반영되어 깨진 페이지나 누락된 정보로 이어진다는 겁니다. 😅 Astro의 Content Collections는 바로 이 문제를 해결해 줍니다. 마크다운 파일의 프런트매터를 Zod 스키마로 정의해두면 빌드할 때 잘못된 데이터를 즉시 잡아내고 편집기
데이터베이스 인덱스는 어떻게 조회를 빠르게 만들까?에서 이메일 하나로 회원을 찾을 때 22ms가 0.002ms로 줄어드는 걸 확인했는데요. 그런데 실무에서 만나는 쿼리는 조건이 하나뿐인 경우가 오히려 드뭅니다. "서울에 사는 30세 회원", "결제 완료된 이번 달 주문"처럼 조건 두세 개가 AND로 엮이는 게 보통이죠. 조건이 여러 개면 인덱스도 여러 개 걸면 될 것 같은데, 실제로는 컬럼을 하나로 묶은 복합 인덱스(composite index)를 만듭니다. 그리고 이때 컬럼을 어떤 순서로 묶느냐에 따라 결과가 크게 달라집니다. 같
많은 양의 데이터를 다루는 서비스에서 검색 기능은 필수적이죠? 이번 포스팅에서는 아래와 같은 웹에서 흔히 볼 수 있는 검색 UI를 React로 함께 구현해보겠습니다. 검색창 컴포넌트 구현 검색창(SearchBox) 컴포넌트에는 사용자가 검색어를 입력하므로 기본적으로 HTML의 <input> 요소를 사용합니다. 이때, 접근성을 위해 type 속성을 search로 설정해 주세요. 스크린 리더 사용자에게는 매우 중요한 정보이기 때문입니다. 부모 요소에서 상태 관리를 하기 위해서 <SearchBox /> 컴포넌트는 prop으로 value와
조회가 느리다고 하면 일단 인덱스부터 걸어보게 되는데요. 그런데 막상 "인덱스를 걸면 왜 빨라지나요?"라는 질문을 받으면 말문이 막힙니다. "음... 책 뒤에 있는 색인 같은 거라서요?" 비유는 맞습니다. 다만 비유에서 멈추면 인덱스를 걸었는데도 안 빨라지는 상황을 만났을 때 손을 쓸 수가 없어요. 왜 빨라지는지를 알아야 왜 안 빨라지는지도 알 수 있으니까요. 이번 글에서는 50만 행짜리 데이터베이스를 직접 만들어놓고, 인덱스를 걸기 전과 후에 그 안에서 실제로 무슨 일이 벌어지는지 눈으로 확인해 보겠습니다. 실습은 SQLite로
코드로 인프라를 구성하는 Infrastructure as code의 장점이 많이 알려지면서 AWS CDK(Cloud Development Kit)를 도입하는 회사들이 늘어나고 있습니다. 이번 포스팅에서는 타입스크립트(TypeScript)로 클라우드 인프라를 정의하고 배포할 수 있게 해주는 도구인 AWS CDK에 대해서 알아보겠습니다. AWS CDK의 등장 배경 AWS와 같은 클라우드 서비스가 처음에 등장했을 때 많은 사람들은 AWS Management Console과 같은 웹 기반 UI에서 일일이 서버 자원을 프로비전(provisi
한빛미디어에서 고맙게도 책을 보내주셔서 우아한 타입스크립트 with 리액트을 읽어 보았습니다. 타입스크립트(TypeScript)와 리액트(React)는 각자가 상당히 넓고 깊은 주제인데, 한 권의 책에 이 둘을 모두 다루었다니 책을 읽기 전부터 제목이 흥미로웠습니다. 책의 전반부에는 주로 타입스크립트에서 대해서 다루고 있으며, 후반부에는 타입스크립트와 리액트를 함께 사용하는 방법이 다루어지고 있습니다. 타입스크립트와 리액트의 비중은 약 7:3 정도 되는 것 같네요. 이 책의 가장 좋았던 점은 우아한형제들에서 타입스크립트와 리액트를