코딩 테스트 준비, 막막하게 느껴지신 적 있으신가요? 🤔 저도 처음엔 리트코드 문제를 무작정 풀고, 정답을 외우는 식으로 비효율적인 준비를 했던 경험이 있습니다. 문제를 아무리 많이 풀어도 새로운 문제가 나오면 막막해지고, 면접에서 "왜 이렇게 풀었나요?"라는 질문에 제대로 대답하지 못했던 적도 있었죠. 심지어 분명히 풀어본 문제인데도 시간이 지나면 어떻게 풀었는지 기억이 안 나는 경우도 많았습니다. 18년 넘게 개발자로 일하면서 한국 대기업에서 아마존, 그리고 실리콘밸리 스타트업까지 이직할 때마다 수많은 코딩 테스트를 직접 겪어
좋아 보이는 에이전트 스킬을 동료 깃허브 저장소에서 발견해서 따라 써보고 싶은데, 막상 적용하려고 하면 막막할 때가 있죠. SKILL.md 파일을 다운로드해서 어디다 저장할지 검색하고, 의존하는 스크립트까지 같이 챙겨오고, 며칠 뒤에 원본이 업데이트되면 또 수동으로 덮어쓰고... 😅 게다가 직접 만든 스킬을 동료에게 공유할 때도 비슷한 문제가 생깁니다. 스펙에 맞게 잘 작성했는지 확인하기도 쉽지 않고, 검색이 잘 되도록 메타데이터를 챙기는 일도 신경 쓸 게 한두 가지가 아니거든요. GitHub이 이 문제를 해결하려고 GitHub
소스 코드 저장소에 API 키나 토큰이 실수로 들어간 적, 한 번쯤 있으시죠? 당장 git rm으로 지우고 강제 푸시를 해도 깃 히스토리에는 흔적이 남고, 공개 저장소라면 봇이 몇 분 안에 그 키를 긁어가 버립니다. 악의적인 사용자가 발견하기 전에 깃허브가 먼저 찾아서 알려주면 좋겠다는 생각이 절로 들죠. 이번 글에서는 깃허브가 무료로 제공하는 Secret Scanning 기능이 어떻게 동작하고, 푸시 시점부터 사후 알림까지 어떤 방어선을 쌓아주는지 정리해 보겠습니다. Secret Scanning이 푸는 문제 비밀 정보가 저장소로
HTTPS를 처음 켜본 사람이라면 한 번쯤 같은 장면을 거칩니다. 인증서를 사려고 검색하다 보니 1년에 몇 만 원짜리부터 수십만 원짜리까지 등급이 나뉘어 있고, 어떤 걸 골라야 할지부터 막막한데요. 사이드 프로젝트 하나 띄워보자고 비싼 인증서를 사기는 부담스럽지만, HTTP로 두자니 브라우저가 "안전하지 않음"이라고 경고를 띄웁니다. 이 진입 장벽을 거의 무너뜨린 것이 Let's Encrypt입니다. ISRG(Internet Security Research Group)라는 비영리 단체가 운영하는 무료 인증 기관인데, 발급 절차를 자
자바스크립트로 무언가를 만들다 보면 의외로 자주 마주치는 순간이 있습니다. 세션 토큰을 만들거나, 비밀번호를 해시하거나, 파일 무결성을 검증하거나, 쿠키에 서명을 넣어야 할 때인데요. 예전 같으면 별도의 라이브러리를 깔아야 했지만, 요즘은 브라우저와 서버 런타임 모두 이런 일을 표준 API로 해낼 수 있습니다. 바로 Web Crypto API입니다. 이 글에서 Web Crypto API의 사용법을 먼저 다루지만, 그 뒤에 깔린 대칭키와 비대칭키 암호화의 원리가 궁금하다면 별도 글에서 따로 풀어 두었습니다. 이름만 들으면 브라우저 전
소프트웨어 문서를 읽다 보면 "upstream 서버에 장애가 났다", "downstream consumer가 영향을 받는다" 같은 표현이 수시로 튀어나오는데요. 그때마다 "그래서 어느 쪽이 어느 쪽이지?" 하며 잠깐 멈칫한 경험, 저만 있는 건 아닐 거예요. nginx 설정의 upstream 블록, dbt의 downstream 모델, Debian/Ubuntu의 계보처럼 결이 완전히 다른 자리에서 같은 단어가 쏟아지니 한 번에 감을 잡기가 쉽지 않습니다. 이 글은 그 혼란의 뿌리를 짚어보고, 실무에서 두 용어가 쓰이는 대표 쓰임새를
블로그나 커머스 사이트를 운영해 보신 분이라면 이미지 때문에 골머리를 앓아본 경험이 한 번쯤 있으실 텐데요. 원본은 4000픽셀짜리인데 썸네일은 300픽셀이면 충분하고, 어떤 브라우저는 AVIF를 좋아하는데 어떤 브라우저는 WebP만 받아먹고, 심지어 같은 이미지를 카드용과 히어로용으로 다르게 잘라야 하는 경우도 있죠. 😅 예전에는 이런 작업을 하려면 Sharp 같은 라이브러리로 직접 변환 파이프라인을 짜거나, imgix 같은 별도의 이미지 CDN을 붙이는 게 일반적이었는데요. Cloudflare는 조금 다른 접근을 제안합니다.
MCP 서버를 직접 만들어 보신 적 있으신가요? 처음에는 로컬에서 STDIO로 붙여서 쓰다가, 원격으로 배포하려는 순간 고민이 시작되는데요. "아무나 내 MCP 서버를 호출하면 안 되는데, 누가 접근할 수 있는지 어떻게 가리지?"라는 질문이 떠오르거든요 🤔 이 질문에 대한 공식 답변이 바로 MCP 스펙의 Authorization 섹션입니다. 2025년 11월 25일 개정판에서는 OAuth 2.1을 기반으로 여러 RFC를 조합한 인증 방식을 정리했는데요. 얼핏 보면 OAuth 2.1, RFC 7591, RFC 8414, RFC 87
"내일 임원 보고 자료 좀 만들어 오세요." 퇴근 직전에 이런 말을 들어보신 적 있으신가요? 파워포인트를 열어 빈 슬라이드를 바라보는데 어디서부터 손을 대야 할지 막막하고, 그렇다고 디자인ㅌ`팀에 부탁하자니 일정이 빠듯하고요 😅 2026년 4월 17일 Anthropic이 공개한 Claude Design이 바로 이런 상황을 위한 도구입니다. 대화 한두 줄이면 브랜드에 어울리는 슬라이드나 프로토타입이 뚝딱 나오고, 마음에 드는 대로 슬라이더를 움직여 여백과 색을 다듬을 수 있어요. 이 글에서는 Claude Design이 무엇이고 어떤
회사 내부용 대시보드나 관리자 페이지를 외부에 공개해야 할 때 어떻게 하시나요? 사내 VPN으로 감싸자니 외부 협업자에게 계정을 만들어 줘야 하고, IP 화이트리스트로 막자니 재택근무 환경에서 자꾸 IP가 바뀌어 곤란하죠. 그렇다고 아예 공개 URL로 두고 로그인 화면을 직접 구현하자니 인증 로직을 매번 새로 붙여야 하니 배보다 배꼽이 더 큽니다 😅 Cloudflare Access는 이런 고민을 엣지에서 해결해 주는 ZTNA(Zero Trust Network Access) 서비스입니다. 원본 애플리케이션에 손대지 않고도 요청이 C
터미널에서 살다시피 하는 개발자라면 한 번쯤 생각해봤을 거예요. "Obsidian 볼트를 커맨드라인에서 다룰 수 없을까?" 노트를 쓰려면 매번 Obsidian 앱으로 전환해야 하고, 자동화하고 싶어도 마땅한 방법이 없었으니까요. 커뮤니티 도구가 이 빈자리를 채워왔지만 2026년 2월 Obsidian 1.12 버전에서 공식 CLI가 등장했습니다. "Obsidian에서 할 수 있는 건 뭐든 커맨드라인으로도 할 수 있다"는 기치를 내세우며요. 이 글에서는 Obsidian CLI의 설치부터 자주 쓰는 명령어와 셸 스크립트 자동화, AI 에
AI 기능을 웹 앱에 붙이는 일이 요즘 정말 흔해졌습니다. 채팅 인터페이스를 만들거나, LLM에게 도구를 쥐여주거나, 스트리밍 응답을 화면에 뿌리거나. 그런데 막상 시작하면 고민이 생깁니다. OpenAI를 쓸지 Anthropic을 쓸지, React인지 Vue인지, Next.js인지 다른 프레임워크인지에 따라 코드가 전부 달라지거든요. TanStack Query와 TanStack Router로 유명한 TanStack 생태계에서 이 문제를 해결하려고 나온 게 바로 TanStack AI입니다. 스스로를 "AI 도구의 스위스"라고 소개할
MCP 서버를 만들어 보신 적 있으신가요? 도구(tool)를 정의하고 JSON-RPC 메시지를 주고받는 코드를 작성하고 나면... 이게 제대로 동작하는지 어떻게 확인하셨나요? 🤔 Claude나 ChatGPT에 직접 연결해서 테스트하다 보면 문제가 생겼을 때 원인 파악이 어렵습니다. LLM이 도구를 엉뚱하게 호출한 건지, 서버가 잘못된 응답을 보낸 건지, 전송 계층 문제인지 구분이 안 되거든요. Postman으로 REST API를 테스트하듯 MCP 서버도 전용 도구로 검증할 수 있으면 좋겠다는 생각이 드실 겁니다. 바로 그 역할을
PR 하나에 파일 30개가 바뀌고 코드가 2,000줄 넘게 추가된 걸 리뷰해달라고 받아본 적 있으신가요? 😅 리뷰어 입장에서는 어디서부터 봐야 할지 막막하고, 작성자 입장에서는 피드백을 기다리는 시간이 길어지죠. "PR은 작게 만들어라"라는 원칙은 누구나 알고 있지만 실제로 지키기가 쉽지 않습니다. 큰 기능을 구현하다 보면 인증 레이어, API 엔드포인트, 프론트엔드 화면이 서로 물려 있어서 하나만 떼어내기 어렵거든요. 억지로 쪼개봤자 의존하는 브랜치끼리 rebase를 수동으로 맞추느라 시간을 허비하게 됩니다. 이 문제를 해결하기
이전 글에서 grep의 기본기를 살펴봤는데요. grep이 50년 넘게 살아남은 검증된 도구인 건 맞지만, 요즘 코드베이스를 다루다 보면 살짝 아쉬운 부분이 있습니다. node_modules를 빼먹으면 결과가 쏟아지고, .gitignore에 있는 파일까지 뒤지고, 바이너리 파일도 가리지 않죠 😅 ripgrep(rg)은 이런 불편함을 해결하기 위해 만들어진 검색 도구입니다. fd의 핵심 라이브러리를 만든 Andrew Gallant(BurntSushi)가 Rust로 개발했고, grep보다 훨씬 빠르면서도 개발자에게 친화적인 기본값을 가
오픈소스 프로젝트를 운영하다 보면 서버비, 도메인 비용, 컨퍼런스 참가비 같은 현실적인 지출이 생기기 마련입니다. GitHub Sponsors처럼 개인 개발자에게 후원하는 방법도 있지만, 프로젝트 자체의 재정을 관리하려면 조금 다른 접근이 필요하죠. 후원금이 얼마나 들어왔고 어디에 썼는지를 투명하게 공개할 수 있다면 후원자도 안심하고 기여할 수 있을 텐데요. Open Collective가 바로 이 문제를 해결하기 위해 만들어진 플랫폼이에요. 이번 글에서는 Open Collective가 어떤 플랫폼인지, 어떻게 활용할 수 있는지 하나
AI 에이전트 하나만으로 모든 일을 처리할 수 있다면 좋겠지만, 현실은 그리 단순하지 않습니다. 기업 환경에서는 채용 담당 에이전트, 일정 관리 에이전트, 데이터 분석 에이전트처럼 각자 전문 분야가 다른 에이전트들이 따로 돌아가고 있는 경우가 많거든요. 문제는 이 에이전트들이 서로 다른 프레임워크로 만들어져서 직접 대화할 방법이 없다는 겁니다. 바로 이 문제를 해결하기 위해 Google이 내놓은 것이 A2A(Agent-to-Agent) 프로토콜입니다. 이름 그대로 AI 에이전트 간의 통신을 표준화하는 오픈 프로토콜인데요. 이 글에서
Vite+가 로컬 개발 도구를 하나로 통합했다면, 이번에는 배포까지 먹으러 왔습니다. VoidZero가 내놓은 Void는 Vite 앱에 플러그인 하나를 추가하고 void deploy 한 방이면 데이터베이스, 인증, KV 스토리지, 큐까지 갖춘 풀스택 애플리케이션이 Cloudflare Workers 위에 올라가는 배포 플랫폼입니다. "자바스크립트에 드디어 Rails 순간이 온 건가, 아니면 그냥 Cloudflare 종속에 리본을 달아놓은 건가?" 궁금해서 Void가 뭘 하는 건지 직접 파헤쳐봤습니다. Vite+와 Void의 관계 먼저
Cloudflare Workers를 써보신 분이라면 한 번쯤 이런 생각을 해보셨을 겁니다. "Workers는 정말 편한데, 내가 쓰는 Python 라이브러리나 FFmpeg 같은 도구는 못 쓰잖아…" 🤔 Workers는 V8 엔진 위에서 돌아가기 때문에 JavaScript와 WebAssembly만 실행할 수 있습니다. Go로 만든 CLI 도구를 돌리거나 Python 머신러닝 모델을 서빙하거나 영상 트랜스코딩을 하려면 결국 별도의 서버나 컨테이너 서비스가 필요했어요. Cloudflare Containers는 바로 이 틈을 메워줍니다.
AI 코딩 에이전트에게 UI를 만들어달라고 하면 종종 난감한 결과물이 나옵니다. 프로젝트에 이미 잘 만들어둔 Button, Card, Modal 같은 컴포넌트가 있는데 에이전트는 그 존재를 모르니까 비슷한 걸 또 만들어버리는 거죠. 디자인 시스템을 열심히 구축해놨는데 AI가 인라인 스타일로 대충 때운 컴포넌트를 내놓으면 정말 답답합니다 😅 이 문제의 원인은 간단합니다. AI 에이전트에게 우리 프로젝트의 UI 컴포넌트에 대한 맥락이 없기 때문인데요. Storybook이 MCP(Model Context Protocol)를 통해 이 문