David Crawshaw는 프롬프트 한 줄로 개인 diff 정리 도구 meat.dev를 에이전트 Shelley에 통합한 사례를 들어, 이런 개인화가 가능한 이유는 Shelley가 오픈소스이기 때문이라고 썼다.
블로그 글 하나가 프롬프트 한 줄을 예로 든다. "meat.dev를 Shelley에 넣어줘. PATH에 최신 버전을 설치하고, Shelley가 커밋을 만들 때마다 백그라운드에서 meat 처리를 시작하고, Diffs 화면에 토글을 추가해줘." 이 한 줄로 개인용 diff 정리 도구가 에이전트 안에 통합됐고, 리뷰하러 돌아왔을 때는 이미 처리가 끝나 있었다.
exe.dev 블로그에 이 사례를 올린 David Crawshaw는 이걸 두고 devtools가 오픈소스여야 하는 이유를 설명한다.
두 개의 프롬프트
Crawshaw는 소프트웨어 개인화를 가능하게 하는 프롬프트를 두 가지로 정리한다. 하나는 소스를 내려받아 로컬에서 빌드하고, 이후 변경은 소스 코드를 고쳐 반영하며 그 동기를 버전 관리에 기록하라는 것. 다른 하나는 매일 밤 크론으로 업스트림 변경을 받아 로컬 변경을 리베이스하고, 동작을 확인한 뒤 기존 버전을 교체하라는 것이다. 에이전트가 오픈소스라면 이 두 프롬프트는 스킬(텍스트 지침)로 만들어 에이전트 자체에 내장할 수 있다고 그는 썼다. 그러면 시작할 때마다 프롬프트를 반복하거나 타이머를 따로 설정할 필요가 없어진다. Crawshaw는 이를 자신이 쓰는 에이전트 Shelley에 넣어, "Shelley UI를 고대비로 바꿔줘" 같은 한 줄로 에이전트 자체를 개인화할 수 있게 했다고 설명한다.
meat.dev로 본 실제 사례
Crawshaw가 만든 meat.dev는 diff에서 중요하지 않은 부분을 LLM으로 걸러내는 개인 도구다. 지난 6개월 동안 모델이 nil 체크나 에러 처리 같은 기계적인 정확성에서 사람보다 꼼꼼해지면서, 그런 줄을 리뷰에서 눈여겨볼 필요가 줄었다고 그는 썼다. 남은 리뷰 대상은 아키텍처나 예상 밖의 사용 사례, 테스트 환경이 잡아내지 못하는 화면 출력 같은 것들이다. 문제는 meat.dev를 터미널이 아니라 Shelley의 UI로 보고 싶었고, LLM이 diff를 압축하는 데 몇 분이 걸려 기다리기 싫었다는 점이었다. 앞서 나온 프롬프트 한 줄이 이 두 가지를 한 번에 해결했다 — 커밋이 생성되자마자 백그라운드에서 처리가 시작돼, 리뷰하러 돌아올 때는 이미 정리된 diff가 기다리고 있었다.
같은 통합을 VS Code 확장 API나 vimdiff 같은 닫힌 도구에서 시도했다면 이야기가 달라진다고 Crawshaw는 썼다. 커밋이 생성되는 시점에 맞춰 백그라운드 처리를 붙이는 일이 거의 불가능했을 것이고, 파일 시스템을 감시하며 캐시를 제공하는 별도의 meatd 데몬을 out-of-band로 만들어야 했을 거라는 설명이다.
References