컴퓨터과학·2026년 2월 4일
Full-Text Search: DB만으로 검색 기능 구현하기
검색 기능이 필요할 때마다 Elasticsearch를 써야 하나 고민했는데, PostgreSQL의 Full-Text Search만으로도 충분한 경우가 많았다.
#Full-Text Search#PostgreSQL#Database#Search
개발과 기술에 대한 이야기를 기록합니다.
검색 기능이 필요할 때마다 Elasticsearch를 써야 하나 고민했는데, PostgreSQL의 Full-Text Search만으로도 충분한 경우가 많았다.
단순 SELECT만 쓰다가 JSONB, CTE, Window Function을 알게 되니 SQL 한 줄로 해결되는 것들이 급격히 늘었다.
Redis를 단순 캐시로만 쓰고 있었는데, 세션 관리, 실시간 랭킹, Pub/Sub, Rate Limiting까지 가능한 만능 도구였다.
매번 수동으로 빌드하고 배포하다가 실수로 버그를 프로덕션에 올렸다. GitHub Actions로 자동화한 후 그런 실수가 사라졌다.
이미지와 정적 파일을 서버에서 직접 서빙하면 트래픽이 몰릴 때 서버가 위험해진다. S3 + CloudFront 조합으로 정적 파일 서빙을 분리하는 방법을 정리했다.
세 플랫폼 다 써봤는데, 가격, 속도, 기능 각각 장단점이 확실했다. 프로젝트 상황별로 어디를 써야 하는지 정리했다.
서버가 미국에 있어서 한국 사용자 응답이 느렸는데, Cloudflare Workers로 전 세계 엣지에서 코드를 실행하니 응답 시간이 극적으로 줄었다.
처음엔 다 비슷해 보였는데, 실제로 써보니 각각 강점이 완전히 달랐다. 스타트업 관점에서 클라우드 선택 기준을 정리했다.
isLoading, isError, data를 따로 관리하다가 불가능한 상태 조합이 생겼다. Discriminated Union으로 상태를 완벽하게 표현한 이야기.
CSS 클래스명을 string으로 받다가 오타 버그가 계속 났는데, Template Literal Types로 문자열 패턴 자체를 타입으로 만들 수 있었다.
함수의 반환 타입이 입력에 따라 달라져야 했는데, 조건부 타입을 알기 전까지는 any로 때우고 있었다.
API 응답이 성공일 수도, 에러일 수도 있는 유니언 타입을 다룰 때, 타입 가드를 알기 전과 후가 완전히 달랐다.
매번 비슷한 타입을 새로 만들고 있었는데, 유틸리티 타입을 알고 나니 기존 타입을 재활용하는 방법이 보였다.
새 팀원이 올 때마다 '로컬 세팅 문서' 보내주는 게 지쳤다. docker compose up 하나로 DB, Redis, 앱 서버를 한 번에 띄우는 방법.
ESLint와 Prettier 설정 충돌로 삽질한 경험, 누구나 있을 것이다. Biome는 이 둘을 하나로 합치고 속도까지 잡았다.
node_modules가 1GB를 넘어가고 npm install이 5분 걸리던 프로젝트가, pnpm으로 바꾸니 용량도 속도도 절반이 됐다.
프론트엔드, 백엔드, 공통 라이브러리를 각각 다른 레포에서 관리하다가 동기화 지옥을 겪었다. Turborepo로 모노레포를 구성한 이야기.
npm install이 3분 걸리던 프로젝트가 bun install로 10초. 빠르다는 건 알겠는데, 실제로 프로덕션에 쓸 수 있을까?
혼자 개발하면 코드 리뷰를 받을 수 없다고 생각했는데, AI 코드 리뷰 도구가 그 역할을 해줬다. PR마다 자동으로 리뷰받는 세팅을 정리했다.
LLM API를 처음 연동했을 때 토큰 비용 폭탄, 응답 지연, 할루시네이션에 당황했다. 실제로 배운 LLM API 활용법을 정리했다.
