아프니까 개발자다 아프니까 개발자다

집에 로컬 AI 서버를 두고 여러 작업을 에이전트에게 맡기다 보면, 어느 순간 스킬(skill)이 수십 개로 불어난다. 여기서 스킬이란 에이전트가 특정 작업을 할 때 따라 읽는 절차 묶음이다 — "이런 요청이 오면 이런 순서로 처리하라"를 적어 둔 설명서에 가깝다. 각 스킬에는 "언제 나를 불러야 하는지"를 적은 한 단락짜리 설명(description)이 붙는다. 에이전트는 사용자 요청이 들어오면 이 설명들을 보고 어떤 스킬을 쓸지 고른다.문제는 스킬이 10개를 넘고 30개를 넘어 50개에 가까워지면 시작된다. 어느 날 "캘린더 정리해줘"라고 했는데 엉뚱하게 일기 추출 스킬이 불렸다. 두 스킬의 설명을 나란히 펴 보니 둘 다 "Google Calendar에서 이벤트를 가져와…"로 시작하고 있었다. 설명이..

로컬 AI 서버를 한 달쯤 굴리다 보니, 에이전트에게 시킬 만한 반복 작업이 수십 개로 늘었다. 사진 정리, 캘린더 동기화, 블로그 초안 작성, 문서 분석… 이런 작업 절차를 하나씩 묶어 둔 것을 스킬(skill)이라 부른다. 스킬은 "이 작업은 이런 순서로, 이런 도구를 써서 처리하라"는 절차서다. 사람이 매번 같은 설명을 반복하지 않도록, 한 번 정리해 두고 에이전트가 알아서 꺼내 쓰게 만든 것이다.그런데 스킬을 여러 개 만들고 나서 한 가지가 궁금해졌다. 나는 어떤 스킬도 이름으로 부른 적이 없는데, 어떻게 매번 맞는 스킬이 불려 올까? "지난주 사진 좀 정리해줘"라고만 했는데 사진 정리 스킬이 정확히 깨어났다. 명령어를 외운 적도, 스킬 이름을 댄 적도 없는데 말이다. 이 글은 그 동작의 원리와,..

집에 둔 로컬 AI 서버에서 코딩 에이전트를 한 번에 세 개 띄워 일을 나눠 줬다. 하나는 테스트를 맡기고, 하나는 리팩터링을 하고, 하나는 문서를 손보게 했다. 셋이 동시에 달리니 체감 속도는 분명히 빨랐다. 그런데 작업이 끝나고 나서 결과를 합쳐 보니, 한 에이전트가 방금 고친 파일이 다른 에이전트의 옛 버전으로 덮여 있었다. 빨라진 줄 알았는데 사실은 서로의 일을 지우고 있었던 것이다.이 글은 그 "서로 덮어쓰는" 문제가 왜 생기는지, 그리고 git worktree(하나의 git 저장소에서 여러 개의 독립된 작업 디렉토리를 만드는 git 기본 기능)로 어떻게 깔끔하게 풀었는지를 정리한 기록이다. 에이전트를 병렬로 굴리는 사람이라면 한 번은 만나는 함정이라 공유해 둔다.배경 — 왜 에이전트를 병렬로 ..

집에 AI 개발용 서버 한 대를 두고 쓰고 있다. 이 서버 위에서는 자동화 에이전트(사람이 시키지 않아도 코드를 읽고 고치고 커밋하는 LLM 기반 프로그램)가 돌고, 동시에 챗봇 API, 문서 브라우저, 사진 분석 배치 같은 서비스가 여러 개 떠 있다. 프로젝트로 치면 열 개가 넘는다.이렇게 한 대에 여러 작업을 몰아넣으면 곧바로 부딪히는 문제가 있다. 작업끼리 서로 간섭한다. 한 작업이 다른 작업이 쓰던 파일을 덮어쓰고, 한 서비스가 실수로 외부에 포트를 열어 두고, 한 배치가 메모리를 다 먹어 시스템 전체가 멈춘다. 그리고 무엇보다 — 에이전트가 잘못된 경로에 rm을 날리면 그 피해가 어디까지 번질지 알 수 없다.이 글은 그 상황에서 Docker나 Kubernetes 같은 컨테이너 오케스트레이션을 도..

AI 코딩 에이전트에게 셸을 열어 주는 순간, 우리는 묘한 거래를 한다. 에이전트가 npm install도 돌리고 grep으로 코드도 뒤지고 테스트도 실행하길 바라지만, 그 똑같은 셸로 rm -rf를 부르거나 curl로 내 파일을 외부에 던지는 것은 원치 않는다. 명령을 실행하는 능력 자체에는 "좋은 명령"과 "나쁜 명령"이 새겨져 있지 않다. 같은 bash 한 줄이 빌드도 되고 사고도 된다.이 글은 그 거래를 설계로 푸는 방법 — 샌드박스 모드(sandbox mode), 즉 명령의 실행 권한과는 별개로 명령이 미칠 수 있는 영향의 범위를 따로 제한하는 장치 — 에 대한 정리다. 개인용 로컬 AI 서버에서 에이전트를 굴리며 직접 부딪힌 경계 설계의 트레이드오프를 옮겼다.배경 — 셸은 너무 강력해서 위험하..

집에 작은 AI 서버를 한 대 두고 코딩 에이전트(스스로 파일을 읽고 명령을 실행하는 LLM 기반 도구)를 종일 돌리다 보면, 가장 먼저 부딪히는 질문은 성능도 비용도 아니다. "이 녀석을 어떻게 믿고 키보드를 맡기지?"다.에이전트는 똑똑하지만 변덕스럽다. 같은 상황에서 어제는 멀쩡히 테스트를 돌리고, 오늘은 rm -rf 한 줄을 천연덕스럽게 실행하려 든다. 그래서 우리는 가드레일(guardrail, 에이전트가 넘으면 안 되는 선을 강제하는 안전장치)을 친다. 그런데 가드레일을 설계하다 보면 더 근본적인 갈림길이 나온다.바로 "이 규칙을 결정론적 코드로 막을 것인가, 아니면 LLM의 판단에 맡길 것인가"다. 이 글은 그 분담선을 어디에 긋는지에 대한 이야기다.왜 한쪽만으로는 안 되는가먼저 직관에 반하는 ..