요즘 챗봇이나 검색 기능을 만들다 보면 "의미 기반 검색"이 거의 필수가 됐어요. 사용자가 "환불 받고 싶어요"라고 입력해도 "결제 취소 절차"가 적힌 문서를 찾아줘야 하잖아요. BM25 같은 키워드 검색은 단어가 정확히 일치해야 하기 때문에 이런 경우에 약한데, 그 빈틈을 메우는 게 바로 의미 기반 검색입니다. 이런 의미 기반 검색을 구현하려면 텍스트를 벡터로 바꿔 저장하고 비슷한 벡터를 빠르게 찾아주는 벡터 데이터베이스가 필요합니다. Pinecone, Weaviate, Qdrant 같은 전문 서비스도 좋지만 Cloudflare
AWS 콘솔에 들어가서 메뉴를 뒤져가며 EC2 인스턴스를 띄우거나 S3 버킷 정책을 만져본 경험이 있으실 텐데요. CLI에 익숙하더라도 200개가 넘는 서비스의 API를 다 외울 수는 없어서 결국 문서를 뒤지면서 작업하게 되죠. 이런 작업을 AI에게 자연어로 시킬 수 있다면 어떨까요? AWS가 2026년 5월 6일 AWS MCP 서버를 정식 출시하면서 그게 가능해졌습니다. "us-west-2 리전에 t3.micro 인스턴스 하나 띄워줘" 같은 요청을 클로드 코드나 Cursor에서 그대로 처리할 수 있어요. 이번 글에서는 AWS MC
요즘 LLM을 활용한 서비스가 늘면서 "벡터 데이터베이스"라는 말을 자주 듣게 됩니다. 의미 검색이나 RAG를 구현하려면 임베딩 벡터를 저장하고 빠르게 찾아줄 곳이 필요하기 때문인데요. Pinecone, Weaviate, Qdrant처럼 벡터 검색에 특화된 제품도 있고요. 그런데 기존에 PostgreSQL을 쓰고 있는 팀이라면 굳이 새로운 데이터베이스를 하나 더 운영하는 건 부담스러울 수 있죠. 이때 좋은 선택지가 pgvector입니다. PostgreSQL 확장(extension) 형태로 동작하기 때문에 별도 서버를 띄울 필요 없이
개발자 모임이나 사내 세미나에서 발표 자료를 만들 때 늘 똑같은 고민이 들곤 합니다. Keynote나 파워포인트로 만들자니 코드 블록 하나 넣자고 폰트와 들여쓰기를 만지작거리는 게 영 번거롭고, 그렇다고 Google Slides는 코드 신택스 하이라이팅이 부실하죠. 마크다운으로 그냥 글 쓰듯 쓰면 안 될까 싶었던 적이 한두 번이 아닙니다. presenterm은 딱 그 가려운 곳을 긁어주는 도구입니다. 마크다운 파일 하나로 슬라이드를 만들고 터미널에서 바로 띄울 수 있어요. 코드 블록은 bat 기반의 신택스 하이라이팅이 자동으로 들어
CLI 도구를 쓰다 보면 인증 토큰을 어디에 둘지가 늘 고민입니다. GitHub CLI는 GH_TOKEN, Cloudflare Wrangler는 CLOUDFLARE_API_TOKEN 같은 환경 변수를 지원하는데요. 편하다고 셸 설정 파일이나 .env 파일에 토큰을 넣어두면 어느 순간 평문 시크릿이 로컬 디스크 여기저기에 흩어집니다. 1Password에는 이런 문제를 줄여주는 Shell Plugins 기능이 있습니다. CLI가 인증 정보를 필요로 할 때 1Password가 토큰을 꺼내 환경 변수로 주입하고, 사용자는 지문이나 Appl
클로드 코드로 큰 작업을 시키다 보면 매 턴 마지막에 "다음 단계 진행해줘"나 "계속"이라고 답하는 자기 자신을 발견하게 됩니다. 테스트가 다 통과할 때까지, 마이그레이션이 끝날 때까지, 인수 조건이 모두 충족될 때까지 분명한 종착점은 있는데 그 사이를 사람이 일일이 클릭으로 끌고 가야 하죠. 🤔 이런 패턴을 한 줄로 해결해주는 명령어가 클로드 코드의 /goal입니다. 종료 조건을 걸어두면 매 턴이 끝날 때마다 별도 모델이 "조건이 만족됐나?"를 판단하고, 아니면 Claude가 알아서 다음 턴을 시작합니다. 이번 글에서는 /goa
클로드 코드로 일하다 보면 동시에 굴리고 싶은 작업이 점점 늘어납니다. 버그 하나는 조사를 시키고, 다른 한쪽에서는 PR 리뷰를 받고, 또 다른 세션에서는 깜박이는 테스트(flaky test)를 추적하고 싶죠. 그런데 터미널 탭을 세 개 열어두면 각각이 뭘 하고 있는지 일일이 들여다봐야 하고, 답해야 하는 세션이 어느 탭인지 찾는 데도 시간을 씁니다. 🤔 이럴 때 쓰라고 만든 게 바로 agent view입니다. claude agents 한 줄로 열리는 한 화면이고, 백그라운드에서 돌고 있는 모든 세션이 한눈에 들어옵니다. 누가 일
웹 API를 호출하는 코드를 작성하다 보면 항상 마주치는 고민이 있는데요. "이 코드는 어떻게 테스트하지?" 하는 문제입니다. 실제 API를 호출하는 테스트는 네트워크 상태에 따라 결과가 달라지고, 외부 서비스의 응답을 마음대로 흉내내기도 어렵죠. 이럴 때 유용한 것이 바로 HTTP 모킹 라이브러리인데요. Rust 생태계에서는 mockito 크레이트가 가장 널리 사용되고 있습니다. 이 글에서는 mockito를 사용해서 HTTP 요청을 보내는 코드를 어떻게 테스트하는지 단계별로 살펴보겠습니다. mockito란? mockito는 Rus
AI 코딩 에이전트에게 브라우저를 맡기는 흐름이 더 빨라지고 있습니다. 이전에 Playwright MCP로 AI 에이전트가 MCP 서버를 통해 브라우저를 다루는 방법을 살펴봤고, Vercel Labs의 agent-browser 같은 CLI 기반 접근도 소개했었는데요. 이번에는 Playwright를 만든 Microsoft가 직접 내놓은 새 도구를 들고 왔습니다. Playwright CLI는 그 이름 그대로 Playwright의 핵심 기능을 명령줄 인터페이스로 노출한 도구입니다. 흥미로운 점은 이게 단순한 playwright 패키지의
AI 덕분에 올라간 개발 생산성만큼, 우리의 실력도 함께 오르고 있을까요? AI가 업무 효율을 높인다는 건 이미 여러 연구를 통해서 밝혀졌습니다. 일부 작업은 AI를 활용하면 최대 80%까지 시간을 단축할 수 있다고 하죠. 하지만 생산성을 대가로 잃는 것은 없는지 생각해보셨나요? 특히 소프트웨어 개발처럼 지속적인 학습이 중요한 영역에서는 이 질문이 더 날카롭게 다가옵니다. AI가 점점 더 많은 코드를 작성하더라도, 그 코드가 올바른지 검증하고, 문제가 생겼을 때 디버깅하고, 시스템 전체를 이해하는 능력은 여전히 개발자의 몫이기 때문
Void: Vite 네이티브 배포 플랫폼에서 데이터베이스를 소개할 때 "로컬에서는 SQLite, 프로덕션에서는 Cloudflare D1로 매핑된다"는 한 줄로 짚고 넘어갔는데요. 이번엔 그 데이터베이스 레이어를 제대로 들여다볼게요. 스키마는 어떻게 정의하고, 마이그레이션은 어떻게 굴리고, 쿼리는 어떻게 날리는지까지 차근차근 살펴보겠습니다. Void 라우팅에서 API 핸들러에 insertUserSchema로 입력을 검증하는 예제를 봤는데, 그 검증기가 어디서 오는지도 이 글에서 채워집니다. 로컬은 SQLite, 프로덕션은 D1 Voi
Rust로 어느 정도 규모가 있는 코드를 짜다 보면 한 번쯤 부딪히는 문제가 있는데요. 바로 외부 의존성을 단위 테스트에서 어떻게 분리할 것인가 하는 문제입니다. 데이터베이스에 붙는 함수나 결제 게이트웨이를 호출하는 로직을, 매번 실제 서비스를 띄워놓고 검증할 수는 없잖아요. 자바에서는 Mockito, 파이썬에서는 unittest.mock이 이런 역할을 해주는데요. Rust 진영에서 이에 해당하는 라이브러리가 바로 mockall입니다. mockito가 HTTP 요청을 가로채는 도구라면, mockall은 트레이트의 구현체를 통째로 흉
GitHub Actions로 배포나 테스트를 자동화하다 보면 API 키, 데이터베이스 비밀번호, 배포 토큰 같은 시크릿을 다루게 됩니다. 처음에는 GitHub Secrets에 하나씩 넣어두면 충분해 보이는데요. 프로젝트가 늘어나고, 시크릿을 여러 저장소에서 공유하고, 키를 주기적으로 교체해야 하는 순간부터 관리가 조금씩 복잡해집니다. 이럴 때 1Password를 시크릿의 원천 저장소로 두고, GitHub Actions에서는 실행 시점에 필요한 값만 읽어오게 만들 수 있습니다. GitHub에는 1Password에 접근하기 위한 서비스
새로운 시스템 프로그래밍 언어 소식이 또 하나 들려왔는데요. 이름은 Rue, 만든 사람은 The Rust Programming Language 책의 공동 저자로 잘 알려진 Steve Klabnik입니다. 흥미로운 점은 Klabnik이 혼자 만든 게 아니라 Claude와 짝을 지어 짧은 기간에 컴파일러 뼈대를 세웠다는 사실이죠. 이번 글에서는 Rue가 어떤 자리에 서고 싶어 하는지, 그리고 Rust 소유권을 어떤 식으로 다시 풀어낸 건지 살펴봅니다. 아직 초기 단계의 실험이지만, 시스템 언어가 어떤 방향으로 더 갈 수 있을지 엿볼 만
요즘 Model Context Protocol이나 A2A 프로토콜 관련 글을 보다 보면 "JSON-RPC 2.0 위에서 동작한다"는 표현을 자주 마주치게 되는데요. 이름만 들으면 거창해 보이지만 막상 스펙을 펼쳐보면 한 페이지로도 충분히 설명되는 작고 단순한 프로토콜입니다. 😅 JSON으로 메서드 이름과 인자를 보내고 결과를 JSON으로 받는다는, 정말 그게 전부거든요. 이번 포스팅에서는 JSON-RPC 2.0이 어떤 구조로 메시지를 주고받는지, REST와는 무엇이 다른지, 그리고 왜 최근 AI 도구 생태계가 다시 이 오래된 프로
코딩 에이전트와 함께 React 코드를 짜다 보면 묘한 위화감이 들 때가 있습니다. 코드는 분명히 동작하고 타입도 맞는데, useEffect 안에서 상태를 폭포처럼 줄줄이 갱신하거나 dangerouslySetInnerHTML을 별 고민 없이 넣어두는 식이죠. 에이전트 입장에서는 "요구사항을 만족시키는 코드"를 짠 것이지만, 우리 입장에서는 "리뷰 코멘트가 쏟아질 코드"입니다. 이 간극을 메우는 도구가 Million.co에서 만든 React Doctor입니다. 한 줄짜리 명령으로 React 프로젝트를 진단해서 0~100 사이의 건강
Rust로 함수를 하나 만들면, 그 함수가 여러 입력에서 제대로 동작하는지 확인하고 싶어집니다. 점수를 학점으로 바꾸는 함수라면 95점은 A, 85점은 B, 40점은 F가 나오는지 일일이 따져봐야 하죠. 그런데 이걸 #[test] 함수로 하나하나 적다 보면 거의 똑같은 코드가 입력값만 바뀐 채 우수수 늘어납니다. 이럴 때 손이 가는 도구가 rstest입니다. 입력과 기대값만 나열해 두면 테스트 함수를 입력 개수만큼 자동으로 찍어내 주거든요. assert 매크로로 값을 검증하는 기본기 위에, "같은 검증을 여러 입력으로 반복"하는 부
회사 위키나 개인 노트를 Notion으로 관리하고 있으면 매일 비슷한 동선을 반복하게 되는데요. 새 프로젝트가 시작되면 PRD 템플릿을 복제해서 채워 넣고, 미팅 노트를 정리해서 관련 페이지에 링크를 걸고, 작업 상태를 데이터베이스에서 일일이 업데이트합니다. 정작 글을 쓰는 시간보다 페이지를 찾고 형식을 맞추는 시간이 더 길게 느껴질 때도 있죠. 😅 만약 코딩 중인 AI 도구에 "어제 미팅 노트를 보고 결정 사항만 추려서 새 PRD로 만들어줘"라고 말하면 그대로 처리해주고, "지난 분기 회고 페이지에서 반복적으로 나온 이슈를 찾아
Neovim에서 코딩을 하다가 Claude한테 물어보고 싶은 게 생기면 보통 어떻게 하시나요? 대부분은 별도 터미널을 띄워두고 거기에 claude 명령을 입력해서 대화하시죠. 그런데 작업 중인 코드 일부를 통째로 보내고 싶거나, Claude가 제안한 변경 사항을 그대로 파일에 반영하고 싶을 때는 복사 붙여넣기를 반복하느라 흐름이 자꾸 끊깁니다. 😅 claudecode.nvim은 이 끊김을 없애주는 Neovim 플러그인입니다. 에디터 안에서 바로 Claude Code 터미널을 띄우고, 시각 모드로 선택한 코드를 한 번에 전송하고,
GitHub Actions는 무료로 시작할 수 있고 워크플로우 한두 줄이면 배포까지 굴러가니 정말 편하죠. 그런데 편한 만큼 위험도 가까이에 있는데요. 워크플로우 한 줄을 잘못 쓰면 저장소의 모든 비밀이 외부로 흘러나가거나, 누군가의 PR 제목이 곧바로 러너에서 셸 명령으로 실행되는 일도 일어납니다. 실제로 PR 제목에 백틱과 셸 명령을 끼워 넣어 러너의 환경 변수와 토큰을 탈취한 사례가 종종 보고되고 있고, 인기 액션의 메인 브랜치가 손상되어 수많은 저장소에서 비밀이 유출되는 사고도 잊을 만하면 한 번씩 터집니다. 다행히 깃허브가