코딩 테스트 준비, 막막하게 느껴지신 적 있으신가요? 🤔 저도 처음엔 리트코드 문제를 무작정 풀고, 정답을 외우는 식으로 비효율적인 준비를 했던 경험이 있습니다. 문제를 아무리 많이 풀어도 새로운 문제가 나오면 막막해지고, 면접에서 "왜 이렇게 풀었나요?"라는 질문에 제대로 대답하지 못했던 적도 있었죠. 심지어 분명히 풀어본 문제인데도 시간이 지나면 어떻게 풀었는지 기억이 안 나는 경우도 많았습니다. 18년 넘게 개발자로 일하면서 한국 대기업에서 아마존, 그리고 실리콘밸리 스타트업까지 이직할 때마다 수많은 코딩 테스트를 직접 겪어
시스템 설계를 다루는 글을 읽다 보면 컨트롤 플레인(control plane)과 데이터 플레인(data plane)이라는 말이 늘 짝을 지어 나옵니다. 시스템을 둘로 나눈다는 이야기인 건 알겠는데, 정확히 무엇을 기준으로 나누는 건지 물으면 선뜻 답하기 어렵죠. 특히 웹 서비스를 만들며 시스템을 프론트엔드와 백엔드로만 나눠 보던 분이라면 더 낯설게 느껴질 겁니다. 그런데 이 구분은 그 익숙한 나누기와 전혀 다른 방향으로 시스템을 자르는 칼이에요. 한 번 익혀 두면 매일 만지는 백엔드 코드도 다르게 보이기 시작합니다. 이번 글에서는
ripgrep과 fd를 쓰기 시작하면 grep이나 find로는 돌아가기 어려운데요. 그래도 검색 범위를 홈 디렉터리 전체로 넓히면 이 둘도 몇 초씩 걸립니다. 매번 디스크를 처음부터 다시 훑기 때문이죠. 사람이야 1초쯤 기다려도 되지만, 코딩 에이전트는 작업 하나에 검색을 수십 번 돌리니 이 시간이 그대로 쌓입니다 😅 FSearch는 이 문제를 "미리 색인해 두기"로 풉니다. 상주하는 데몬(daemon)이 디스크 전체의 파일 이름과 텍스트 파일 내용을 색인해 두고, 파일이 바뀌면 그 부분만 바로 갱신합니다. 그래서 수백만 개 파일
파이썬으로 만든 CLI 도구에서 --version만 찍어 봐도 묘하게 굼뜬 느낌을 받은 적 없으신가요? 🤔 버전 문자열 하나 출력하는 데 쓰지도 않을 asyncio나 urllib.request 같은 모듈까지 전부 불러오고 있기 때문인데요. 파이썬의 import 문은 실행되는 순간 모듈을 찾아서 끝까지 실행하기 때문에, 파일 맨 위에 적어 둔 모듈은 쓰든 안 쓰든 시작할 때 모두 비용을 치릅니다. 그래서 지금까지는 무거운 모듈을 함수 안에서 import하는 꼼수를 많이 써 왔습니다. 실제로 파이썬 표준 라이브러리에서도 테스트를 뺀
블로그 글의 주소를 바꾸거나 문서 사이트의 폴더 구조를 정리하고 나면 꼭 이런 일이 생기는데요. 예전에 SNS나 다른 블로그에 공유된 옛 주소로 들어온 사람들이 모두 404 페이지를 보게 됩니다. 😅 게다가 검색 엔진이 옛 주소에 쌓아 둔 신호도 새 주소로 넘어가지 못합니다. 이럴 때 필요한 게 리디렉션(redirect) 규칙입니다. 서버를 직접 운영한다면 서버 코드에서 처리하면 되지만, 정적 사이트는 이야기가 다른데요. 이 글에서는 정적 사이트에서 리디렉션 규칙을 어디에 어떻게 적는지, 호스팅 플랫폼별 문법과 흔히 빠지는 함정을
어제 OpenAI에서 이메일 한 통이 날아왔습니다. GPT-4o, GPT-4o mini, GPT-4.1, GPT-4.1 mini 등 GPT-4 계열 모델들이 2027년 1월부로 서비스를 종료한다는 소식이었는데요. 이제 3개월밖에 남지 않았으니, 아직 해당 모델을 사용하고 있다면 다른 모델로 교체해야 합니다. 그래서 여러 프로젝트에서 사용하던 GPT-4 계열 모델들을 최신 모델로 교체하기 시작했습니다. 신모델들은 성능이 뛰어나고 가격까지 싸져서 굳이 예전 모델을 고집할 이유가 없기도 하죠. 그런데 막상 모델을 교체하려니 조금 섭섭한
회사에서 Rust로 만든 오픈소스 애플리케이션을 하나 관리하고 있는데요. 라이브러리가 아니라 실행 파일이라서 그동안 바이너리와 Docker 이미지로만 배포해 왔어요. 그런데 어느 날 이런 이슈가 올라왔습니다. 많은 회사가 규정상 crates.io 미러에 있는 패키지만 받아서 소스로 빌드해야 합니다. git 소스로만 공개된 패키지는 아예 쓸 수가 없어요. 생각해 보니 맞는 말이었습니다. 보안 규정이 엄격한 조직일수록 외부 바이너리를 그대로 들이지 않고 사내 레지스트리(registry)에 미러링한 크레이트(crate)만 빌드에 쓰게 하
동료가 올린 풀 리퀘스트(pull request, 이하 PR)를 꼼꼼히 리뷰하고 싶어도 하루에 몇 개씩 쌓이면 대충 훑고 승인하게 되는데요. 그러다 놓친 실수가 배포 후에 터지면 "그때 좀 더 볼걸" 하는 후회가 남습니다. 😅 OpenAI의 Codex에는 GitHub PR을 대신 리뷰해 주는 기능이 있습니다. PR에 @codex review라고 댓글을 달면 Codex가 변경 사항을 읽고 일반 GitHub 리뷰처럼 줄 단위로 의견을 남겨 주죠. 저도 이번에 운영하는 오픈소스 저장소 몇 곳에 이 기능을 연결했는데요. 이 글에서는 실제
NeoVim을 제대로 써 보겠다고 마음먹은 날을 떠올려 보면, 코드를 짠 시간보다 init.lua를 고친 시간이 더 길었던 것 같은데요. 플러그인 매니저를 고르고, 언어 서버(language server)를 붙이고, 구문 강조(syntax highlighting) 플러그인을 설치하다 보면 하루가 금방 갑니다. 그래서 LazyVim 같은 배포판이 인기를 끌기도 했고요. 그런데 처음부터 그 모든 걸 품고 나오는 에디터가 있다면 어떨까요? 오늘 소개할 Helix가 바로 그런 에디터입니다. 설치하고 파일을 열면 구문 강조, 자동 완성, 정
State of JS가 자바스크립트 개발자들의 연례 행사라면, 언어와 분야를 가리지 않고 전 세계 개발자들이 함께 챙겨보는 설문이 있는데요. 바로 Stack Overflow 개발자 설문(Developer Survey)입니다. 올해로 16번째인 이번 설문은 2026년 6월 23일부터 8월 5일까지 진행됐고, 169개 나라에서 30,903명의 응답을 모았습니다. Stack Overflow는 올해 설문을 한 문장으로 요약했는데요. "How are you doing?", 우리말로 하면 "요즘 어떻게 지내세요?"입니다. 기술 순위표만 나열하
클로드 코드를 오래 쓰다 보면 화면에 뭔가 하나 더 있었으면 좋겠다는 생각이 들 때가 있습니다. 지금 브랜치에 바뀐 파일이 몇 개인지 프롬프트 바로 위에서 보고 싶고, Claude가 고치고 있는 README를 옆에 띄워 놓고 싶고, .env 파일만큼은 절대 건드리지 못하게 막고 싶죠. 지금까지는 상태줄에 셸 스크립트를 걸거나 Hooks로 도구 호출을 막는 정도가 전부였습니다. 둘 다 클로드 코드 바깥에서 스크립트를 돌리는 방식이라, 화면에 버튼이나 패널(pane)을 그리는 건 불가능했어요. 클로드 코드 v2.1.287부터 기본으로
얼마 전 1Password 서비스 계정 글을 손보다가 1Password 설정 화면에서 낯선 체크박스를 하나 발견했습니다. Settings > Developer에 Integrate with MCP clients라는 항목이 생겨 있더라고요. 1Password가 직접 MCP 서버를 내놓은 건데요. 비밀번호 관리자가 AI 에이전트에게 문을 열어 준다니, 반갑기보다 먼저 걱정이 앞섰습니다. 🤔 에이전트가 내 API 키를 마음대로 꺼내 가면 어떡하죠? 직접 켜 보니 생각과는 다른 물건이었습니다. 이 서버는 시크릿 값을 에이전트에게 돌려주지
워크플로우를 처음 만들 때는 API 키 하나쯤 YAML 파일에 그냥 적어 두고 싶은 유혹이 생기는데요. 저장소가 공개되어 있다면 그 순간 키는 전 세계에 공개된 셈이죠. 😅 그렇다고 모든 설정값을 꽁꽁 숨기자니, 앱 이름이나 로그 레벨처럼 굳이 감출 필요가 없는 값까지 로그에서 ***로 보여서 디버깅이 괴로워집니다. GitHub Actions는 그래서 설정값을 두 종류로 나눠 보관합니다. 민감한 값을 담는 시크릿(secret)과, 감출 필요는 없지만 코드 밖으로 빼고 싶은 값을 담는 변수(variable)예요. 이번 글에서는 둘의
에이전트 워크플로를 만들다 보면 중간중간 작은 판단이 필요한 순간이 계속 나옵니다. "이 문의는 긴급한가?", "어느 팀으로 보내야 하지?", "이 도메인은 피싱 사이트일까?" 같은 질문이요. 보통은 이런 판단도 대규모 언어 모델(Large Language Model, 이하 LLM)에게 맡기는데요. 프롬프트에 "JSON으로만 답해"라고 신신당부해도 가끔 형식이 어긋나고, 같은 입력에 매번 다른 답이 나오고, 무엇보다 한 번 물어볼 때마다 몇 초씩 기다려야 합니다 😅 예/아니요 하나 정하자고 수천 개의 토큰을 생성하는 건 아무래도
Svelte 5 글에서 룬으로 컴포넌트를 만들어 봤는데요. 컴포넌트만으로는 웹 앱이 완성되지 않습니다. 주소마다 다른 페이지를 보여 줘야 하고, 서버에서 데이터를 가져와야 하고, 폼을 처리하고, 어딘가에 배포도 해야 하죠. 🤔 이런 일을 모두 맡아 주는 것이 Svelte 팀이 직접 만드는 SvelteKit입니다. 마침 2026년 10월 1일에 SvelteKit 3가 정식으로 출시됐는데요. 설정 파일이 바뀌고 $lib 별칭이 #lib로 바뀌는 등 프로젝트 구조부터 달라졌습니다. 이번 글에서는 SvelteKit 3로 작은 블로그 앱을
Cloudflare Workers로 만든 서비스가 하나둘 늘어나면 wrangler deploy를 직접 치는 게 슬슬 부담스러워지는데요. 누가 언제 어떤 커밋을 배포했는지 기록도 남지 않고, 테스트를 깜빡하고 배포하는 날도 생깁니다. 😅 결국 GitHub에 푸시하면 알아서 배포되는 흐름이 필요해집니다. Workers를 GitHub와 연결하는 방법은 크게 두 가지입니다. 하나는 Cloudflare가 직접 빌드와 배포를 맡는 Workers Builds이고, 다른 하나는 GitHub Actions 워크플로우에서 Wrangler를 실행하는
요즘 goose의 모델 제공자(provider) 설정 화면을 열면 낯선 항목이 하나 보이는데요. "Claude Code ACP"를 골라 보면 "ACP adapter not found"라는 경고와 함께 @agentclientprotocol/claude-agent-acp를 설치하라는 안내가 뜹니다. Zed의 AI 기능을 쓰다 보면 에이전트 패널에서 클로드 코드를 띄울 때도 같은 이름을 만나게 되고요. ACP는 이렇게 에디터나 앱이 외부 코딩 에이전트(coding agent)를 불러다 쓸 때 오가는 대화를 표준으로 정해 둔 프로토콜입니다
LLM을 코드 안의 if 문처럼 써보신 적 있나요? 고객 문의를 담당 부서로 나누는 것처럼 답이 몇 가지로 정해진 판단을 맡기는 일인데요. 프롬프트에 "반드시 JSON으로만 답해"라고 적고 돌아온 문자열을 Zod로 검증하다가 스키마가 어긋나면 다시 요청하는 코드를 한 번쯤 짜보셨을 겁니다. 그렇게 해도 판단 하나에 몇 초씩 걸리고, 가끔은 목록에 없는 부서 이름을 지어내기도 하죠. 😅 9월 15일 TypeSafe AI가 이 문제를 정면으로 겨눈 모델 Jev를 공개했습니다. ChatGPT의 바탕이 된 인간 피드백 강화학습(Reinf
클로드 코드로 일하다 보면 세션 하나로는 부족한 순간이 옵니다. 서비스 다섯 개에 같은 린트 설정을 적용해야 한다거나, 스펙 문서 하나를 놓고 며칠짜리 빌드를 굴려야 한다거나, 버그 리포트가 들어오는 족족 누군가 조사를 시작해줬으면 하는 상황이요. agent view나 git worktree로 세션을 여러 개 띄울 수는 있는데요. 문제는 그 세션을 지휘하는 사람이 여전히 나라는 겁니다. 어떤 세션에 뭘 시킬지 정하고, 세션마다 똑같은 배경 설명을 반복하고, 어느 게 끝났고 어느 게 내 대답을 기다리는지 탭을 돌아다니며 확인해야 하죠
tmux나 Zellij를 쓰다 보면 한 번쯤 아쉬운 순간이 옵니다. 노트북을 덮고 나왔는데 서버에서 돌려둔 작업이 어떻게 됐는지 폰으로 슬쩍 보고 싶을 때가 있죠. 동료에게 지금 내 터미널 화면을 그대로 보여주고 싶을 때도 있고요. 요즘 부쩍 늘어난 상황도 하나 있는데, 코딩 에이전트가 세션을 열 개씩 열어놓고 돌아가는 걸 지켜봐야 할 때입니다. 어느 쪽이든 결국 SSH로 다시 붙거나 화면을 캡처해서 보내는 우회로를 타게 됩니다. Superlogical은 이 지점을 정면으로 겨냥한 회사입니다. GPU 가속 터미널 Ghostty를 만