코딩 테스트 준비, 막막하게 느껴지신 적 있으신가요? 🤔 저도 처음엔 리트코드 문제를 무작정 풀고, 정답을 외우는 식으로 비효율적인 준비를 했던 경험이 있습니다. 문제를 아무리 많이 풀어도 새로운 문제가 나오면 막막해지고, 면접에서 "왜 이렇게 풀었나요?"라는 질문에 제대로 대답하지 못했던 적도 있었죠. 심지어 분명히 풀어본 문제인데도 시간이 지나면 어떻게 풀었는지 기억이 안 나는 경우도 많았습니다. 18년 넘게 개발자로 일하면서 한국 대기업에서 아마존, 그리고 실리콘밸리 스타트업까지 이직할 때마다 수많은 코딩 테스트를 직접 겪어
맥으로 개발을 하다 보면 디스크가 슬금슬금 차오릅니다. 저장 공간 경고가 뜰 때쯤 확인해보면 대개 이런 상태예요. 460GB짜리 디스크에서 남은 공간이 24GB 남짓입니다. 문제는 무엇을 지워야 할지 모르겠다는 거죠. 사진이나 영상을 지우자니 아깝고, ~/Library 안쪽은 열어봐도 알 수 없는 이름의 폴더뿐입니다. 😅 맥 청소 앱은 예전부터 많았습니다. 그런데 이 바닥은 유독 미심쩍은 광고와 연 3만~5만 원짜리 구독으로 얼룩져 있어서 선뜻 손이 가지 않죠. "잡동사니 12GB를 발견했습니다" 같은 문구는 봤어도, 정확히 무슨
AI 코딩 에이전트 하나를 터미널에서 돌릴 때는 별문제가 없습니다. 그런데 버그 수정은 Codex에 맡기고, 테스트 실패 원인 조사는 Claude Code에 시키고, 옆에서는 개발 서버까지 띄우기 시작하면 상황이 달라져요. 터미널 탭을 돌아다니며 누가 작업 중인지, 누가 권한 승인을 기다리는지 계속 확인해야 합니다. 일은 에이전트들이 하는데 정작 사람은 터미널을 순찰하느라 바쁜 셈이죠. 🤔 Herdr는 이 문제를 풀기 위해 만든 터미널 멀티플렉서(terminal multiplexer)입니다. 화면을 나누고 세션을 유지하는 데서 그
요즘 이런 말을 자주 듣습니다. 이제 개발자는 코드를 직접 짜기보다 코딩 에이전트를 지휘하고 감독해야 한다고요. 저도 개발자의 역할이 바뀌고 있다는 큰 흐름에는 동의합니다. 다만 여기에는 조심해야 할 역설이 있습니다. 과연 직접 구현을 할 수 없는 개발자가 에이전트를 감독할 수 있을까요? 문법을 빠르게 떠올리고 코드를 입력하는 속도는 조금 느려져도 괜찮습니다. 하지만 요구 사항을 파악하고, 코드의 동작을 예측하고, 실패 원인을 추적하는 능력까지 잃는다면 이야기가 달라집니다. 에이전트가 만든 결과물을 판단할 기반도 함께 사라지기 때문
회원 가입 API를 만들다 보면 데이터베이스의 비밀번호 열을 어떻게 채워야 할지 고민하게 됩니다. 평문(plaintext)을 그대로 넣으면 안 된다는 사실은 알겠는데, AES로 암호화해야 할까요? 아니면 SHA-256으로 해시하면 충분할까요? 둘 다 안전한 답은 아닙니다. 비밀번호 저장은 일반 데이터 암호화나 파일 무결성 검사와 다른 위협을 상대하기 때문인데요. 공격자가 데이터베이스를 통째로 가져간 뒤에도 사용자의 원래 비밀번호를 알아내기 어렵게 만들어야 합니다. 이번 글에서는 비밀번호를 저장하고 검증하는 기본 흐름부터 범용 해시가
AI 채팅을 하나 만들었다고 해볼까요? 사용자가 목표를 알려주고 대화를 나누는 동안에는 제법 그럴듯하게 동작합니다. 그런데 브라우저를 닫았다가 다시 열면 이전 목표를 잊습니다. "30분 뒤에 다시 알려줘"라고 해도 그때까지 프로세스를 붙잡아 둘 방법이 마땅치 않고요. 여러 기기에서 같은 대화에 접속하면 상태가 서로 어긋나기도 합니다. 🤔 대형 언어 모델(large language model, 이하 LLM)을 호출하는 것만으로는 이런 문제를 해결할 수 없습니다. 모델 밖에서 사용자별 상태를 저장하고, 실시간 연결을 관리하고, 정해진
관리자 화면에 버튼 하나를 추가하려는데 디자인부터 다시 잡아야 했던 적이 있나요? 버튼만 끝나면 다행이지만 입력창, 대화 상자, 탭, 드롭다운까지 필요해지면 이야기가 달라집니다. 직접 만들자니 접근성과 키보드 조작이 걱정되고, 익숙한 UI 프레임워크를 쓰자니 특정 JavaScript 프레임워크에 프로젝트 전체가 묶일 수 있죠. Web Awesome은 이 사이를 파고드는 UI 컴포넌트 라이브러리입니다. React나 Vue 전용 컴포넌트 대신 브라우저 표준인 웹 컴포넌트(Web Components)로 만들어졌는데요. 일반 HTML 페이
이직을 하고 Kotlin과 Rust라는 저에게 생소한 언어 두 개를 동시에 써야하는 기회가 생겼습니다. 마침 코딩 에이전트가 막 부상하던 시기였는데요. 공부를 하는 방법에도 변화를 주면 어떨까 싶었습니다. 그래서 두 프로그래밍 언어를 완전히 다른 방식으로 공부하는 실험을 시작했습니다. Kotlin 학습은 철저하게 AI 주도로 하기로 결심했습니다. 무조건 AI가 코드를 작성하게 하고, 코드를 이해할 때도 AI의 도움을 받았습니다. 모르는 문법이 나오면 바로 질문해서 답변을 얻고, 새로운 라이브러리를 만나면 핵심 용례만 빠르게 파악했습
클로드 코드를 쓰다 보면 어느 순간 이런 작업을 만나게 됩니다. "저장소 전체의 라우트 핸들러를 훑어서 인증 누락을 찾아줘", "컴포넌트 500개를 새 스타일 시스템으로 옮겨줘", "문서와 이슈를 여러 방향에서 조사한 뒤 서로 검증해서 보고서를 만들어줘" 같은 요청 말이죠. 이런 작업은 한 대화 안에서 차근차근 진행할 수도 있습니다. 하지만 파일이 많아지고 검증 단계가 늘어나면 컨텍스트가 금방 지저분해지고, Claude가 어느 파일을 봤는지, 어떤 결과를 검증했는지 사람이 계속 추적해야 합니다. 서브 에이전트를 여러 번 호출하는 방
Rust로 크레이트를 가져다 쓰다 보면 Cargo.toml에서 이런 줄을 한 번쯤 보셨을 거예요. 여기서 features는 대체 뭘까요? 왜 어떤 크레이트는 그냥 추가하면 되는데, 어떤 크레이트는 ["derive"]나 ["full"] 같은 걸 콕 집어줘야 제대로 동작할까요? 🤔 Cargo features는 크레이트의 기능을 조건부로 켜고 끄는 스위치입니다. 크레이트를 만드는 쪽에서는 "이 기능은 옵션이야"라고 미리 나눠두고, 쓰는 쪽에서는 필요한 것만 골라서 켤 수 있죠. 덕분에 안 쓰는 기능까지 컴파일하느라 빌드가 느려지거나 바
원격 MCP 서버에 OAuth를 붙일 때 의외로 까다로운 부분은 로그인 화면이 아닙니다. 처음 만난 MCP 클라이언트를 인가 서버(Authorization Server)에 어떻게 등록할지가 더 큰 문제인데요. 데스크톱 앱, 코드 편집기, 에이전트 플랫폼을 인가 서버에 일일이 미리 등록할 수는 없기 때문입니다. 2025년 11월 25일 MCP 스펙은 이 문제를 풀기 위해 클라이언트 ID 메타데이터 문서(Client ID Metadata Documents, CIMD)를 권장 등록 방식으로 추가했습니다. 이전 스펙에서 사용하던 동적 클라
집에서 와이파이에 연결된 기기를 한번 세어 볼까요? 노트북, 스마트폰, 태블릿, TV, 어쩌면 로봇청소기까지 십수 대는 우습게 넘어갑니다. 그런데 통신사가 우리 집에 내준 공인 IP 주소는 보통 딱 하나뿐인데요. 어떻게 그 많은 기기가 주소 하나로 동시에 인터넷을 쓰는 걸까요? 🤔 비밀은 집 공유기 안에서 조용히 돌아가는 NAT(Network Address Translation)에 있습니다. 우리말로 옮기면 "네트워크 주소 변환"인데, 이름 그대로 오가는 패킷의 주소를 바꿔치기하는 기술이에요. 이 글에서는 NAT가 무엇을 바꾸는지
요즘 웹 서비스에는 서버가 사용자 대신 외부 URL로 요청을 보내는 기능이 흔합니다. 링크를 붙여넣으면 미리보기 카드를 만들어 주고, 이미지 주소를 넣으면 썸네일을 대신 받아오고, 웹훅 주소를 등록해 두면 이벤트가 생길 때마다 서버가 그 주소로 알림을 쏴 줍니다. 편리하죠. 그런데 "사용자가 건넨 주소로 서버가 대신 요청을 보낸다"는 이 평범한 동작이, 잘못 다루면 서버를 통째로 공격자의 손발로 내주는 통로가 됩니다. 이번 글에서 다룰 SSRF(Server-Side Request Forgery) 이야기입니다. 이름부터 CSRF와 헷
매일 새벽에 낡은 데이터를 지우거나, 30분마다 외부 API에서 시세를 긁어오거나, 아침마다 요약 리포트를 보내는 일. 이런 정기 작업은 흔하지만, 이거 하나 돌리자고 서버나 VM을 24시간 켜두는 건 아깝죠. crontab을 걸어둘 상시 머신이 필요하고, 그 머신은 대부분의 시간을 놀면서 요금만 축내니까요. Cloudflare Workers의 Cron Triggers는 이 문제를 관리형으로 풉니다. 정해진 시각이 되면 Cloudflare가 알아서 우리 코드를 깨워주고, 실행이 끝나면 다시 잠들어요. 상시 켜둘 서버도 cron 데몬
게이트웨이로 봇을 띄우면 한 가지 숙명이 따라옵니다. 봇 프로세스가 24시간 살아 있어야 한다는 거예요. 노트북을 끄면 봇도 오프라인이 되니, 늘 켜져 있는 서버나 컨테이너에 올려둬야 하죠. "간단한 슬래시 커맨드 하나 만들려는 건데 서버까지 빌려야 하나?" 싶은 순간이 옵니다. 그런데 슬래시 커맨드나 버튼에만 반응하는 봇이라면, 굳이 항상 켜둘 필요가 없습니다. 요청이 올 때만 깨어나는 서버리스로 만들 수 있거든요. 이번 글에서는 Cloudflare Workers에 슬래시 커맨드에 응답하는 봇을 올려서, 호스팅 걱정 없이 배포하는
OAuth로 로그인을 붙일 때, 클라이언트 등록은 보통 이렇게 시작합니다. 인가 서버 콘솔에 앱을 미리 등록하고 client_id를 발급받아 코드에 박아 두는 거죠. 클라이언트와 서버가 서로를 아는 고정된 관계라 이 방식으로 충분했습니다. 그런데 이 전제가 통하지 않는 세계가 있습니다. 클라이언트와 서버가 처음 만나는 게 일상인 개방형 생태계예요. "Bluesky로 로그인"하는 서드파티 앱이 사용자마다 다른 서버에 붙고, AI 에이전트가 그날 처음 발견한 도구 서버에 연결하는 식이죠. 미리 등록할 시간도, 모두를 아우르는 중앙 등록
LLM 호출 한 줄을 코드에 붙이는 건 쉽습니다. 그런데 제공사가 둘, 셋으로 늘어나는 순간 이야기가 달라지죠. OpenAI SDK 깔고, Anthropic SDK 또 깔고, 키를 각각 발급받아 환경변수로 빼고, 비용은 대시보드 세 군데를 들여다봐야 하고요. 게다가 새 모델이 나올 때마다 "이거 한번 써볼까?" 하면 또 가입하고 결제 정보를 등록하는 일이 반복됩니다. 정작 하고 싶은 건 "프롬프트 보내고 답 받기" 한 줄인데 말이죠. 🤔 OpenRouter는 이 번거로움을 키 하나로 정리합니다. OpenAI, Anthropic,
봇 개발을 하다 보면 결국 마주치는 통로가 **게이트웨이(Gateway)**입니다. 슬래시 커맨드를 만들 때 client.login() 한 줄로 봇을 온라인으로 띄웠는데, 그 순간 봇은 바로 이 게이트웨이로 디스코드와 연결을 맺은 거였어요. 이번 글에서는 그 통로의 안쪽을 들여다보며, 봇이 어떻게 서버의 모든 일을 실시간으로 지켜보는지, 그리고 그렇게 만든 봇을 어떻게 24시간 운영하는지까지 살펴봅니다. 게이트웨이는 항상 열려 있는 WebSocket REST API가 "내가 물어보면 답해주는" 요청-응답 방식이었다면, 게이트웨이는
자동화를 만들다 보면 GitHub에 인증할 일이 계속 생깁니다. CI에서 릴리스 커밋을 올리고, 봇이 이슈에 댓글을 달고, 외부 서비스가 PR을 검사하는 식이죠. 가장 먼저 손이 가는 건 개인 액세스 토큰(Personal Access Token, 이하 PAT)인데요. 잘 돌아가다가도 꼭 한 번씩 벽에 부딪힙니다. "이 봇이 왜 내 계정으로 커밋하지?", "내가 퇴사하면 이 자동화도 멈추나?", "왜 이 토큰에 우리 조직 전체 권한이 다 붙어 있지?" 같은 의문이죠. 🤔 이 문제들의 답이 바로 GitHub App입니다. 이름만 보면
앱에 AI 기능을 하나 붙이려고 마음먹으면, 정작 모델을 부르는 코드보다 그 주변을 차리는 일이 더 번거롭습니다. 어느 제공사를 쓸지 정하고, SDK를 설치하고, API 키를 환경변수로 빼고, 스트리밍 응답을 직접 파싱하고, 사용량이 얼마나 나왔는지 따로 추적하고… 정작 "프롬프트를 보내고 답을 받는" 본질은 한 줄인데 말이죠. Void는 이 주변 작업을 void/ai라는 클라이언트로 미리 차려둡니다. Cloudflare의 AI 게이트웨이 위에서 동작하는 타입 안전한 클라이언트인데, Void 라우팅에서 본 라우트 핸들러 안에서 모델