개발 도구는 오픈 소스여야 한다

5년 전만 해도 내가 이야기를 나눈 소프트웨어 엔지니어 대부분은 자신을 위해 직접 만든 프로그램이 하나도 없었다. 당시 나는 Tailscale이 엔지니어들의 삶에 어떻게 자리 잡을 수 있을지 알아보려고 이 질문을 자주 던졌다. 엔지니어들은 매일 온종일 다른 사람이 만든 프로그램을 사용해 다른 사람을 위한 프로그램을 만든다. 많은 사람이 설정 파일이나 플러그인, 확장 기능으로 사용하는 프로그램을 입맛에 맞게 바꿨고, 다른 사람을 위해 자신이 만든 프로그램을 직접 사용하기도 했다. 하지만 누군가에게 자신을 위해 무엇을 만들었는지 물었을 때, 시중에서 구한 크기가 얼추 맞는 정적 사이트 생성기나 Zigbee 기기 대신 블로그나 홈 자동화, 홈랩을 위해 만든 맞춤형 소프트웨어 이야기를 듣는 일은 언제나 보기 드문 즐거움이었다.

이런 현실은 내게도 충분히 이해됐다. 나 역시 여러 해 동안 나 자신을 위한 소프트웨어를 많이 만들었지만, 들인 노력만큼 보상을 얻었는지는 늘 의문이었다. 하루에 작성할 수 있는 코드에는 한계가 있었다. 언제나 더 중요한 일이 있었고(직장에서 뭔가 문제가 생기곤 했다), 1년 만에 프로젝트로 돌아와 유지보수하는 일은 매번 엄청나게 고통스러웠다. 내 경력 중에는 맞춤형 소프트웨어를 전부 버리고, 코드를 작성하는 데 최대한 평범한 환경만 사용했던 시기도 꽤 길었다. Google에서 엔지니어로 일하던 초기에는 개인용 컴퓨터조차 없었다.

그건 그때 이야기다. 지금은 다르다.

소프트웨어를 개인화하는 방법

오늘날에는 소프트웨어를 놀랄 만큼 쉽게 개인화할 수 있다. 이 모든 것을 가능하게 하는 에이전트 프롬프트는 크게 두 종류다.

1. <software>의 소스를 내려받아 로컬에서 사용할 수 있게 빌드하라. 앞으로 이 소프트웨어를 변경할 때는 소스를 수정하고 현재 버전을 교체해야 한다는 사실을 <에이전트가 사용하는 기억 수단>에 기록하라. 변경하게 된 최초의 동기도 버전 관리 시스템에 기록하라.

그리고 더 중요한 두 번째 프롬프트는 다음과 같다.

1. 매일 밤 다음 프롬프트를 실행하는 cron 작업을 설정하라. <software>의 업스트림 변경 사항을 가져와 모든 로컬 변경 사항을 그 위에 리베이스하라. 소프트웨어가 의도대로 작동하는지 확인하고 현재 버전을 교체하라.

핵심은 에이전트가 특정 용도에 맞춰 코드를 임시로 고치는 데 그치지 않고, 업스트림 릴리스와 변경 사항을 동기화하는 과정까지 자동으로 관리할 수 있다는 점이다. 따라서 에이전트는 소프트웨어 맞춤화의 투자 대비 효과를 두 측면에서 동시에 바꾼다. 개인화를 시작하기가 훨씬 쉬워지고, 계속 유지하기도 훨씬 쉬워진다.

위의 두 소프트웨어 수정 프롬프트를 에이전트 자체에 내장할 수 있다는 점도 놀랍다. 에이전트가 오픈 소스라면 프로그래밍조차 필요하지 않다. 두 프롬프트를 스킬, 즉 텍스트 지침으로 만들어 에이전트가 찾을 수 있는 곳에 두면 된다. 우리는 이를 Shelley에 내장했다. 이제 Shelley를 수정할 때는 앞부분의 지시를 다시 입력하거나 타이머를 설정할 필요조차 없다. Shelley가 알아서 처리한다. "Shelley의 UI를 고대비로 바꿔줘" 같은 프롬프트만 입력하면 에이전트가 나에게 맞게 개인화된다.

실제 개인화 사례: Shelley와 Meat

지난 한 달 동안 틈틈이 만져 온 개인 프로젝트가 하나 있다. 바로 meat.dev다. 기본 원칙은 에이전트가 코드를 작성하더라도 중요한 시스템에 푸시하기 전에는 내가 직접 읽어 본다는 것이다. 기반 모델이 발전하면서 내가 확인하는 내용도 달라졌다. 지난 20년 동안 내가 코드를 리뷰해 준 사람들은 항상 엣지 케이스를 놓치곤 했다. 오류 메시지가 유용한 정보를 제공하는지, nil 검사가 제대로 처리됐는지 같은 문제다. 우리 모두가 그렇다. 나도 직접 코드를 작성할 때는 특히 심하다. 리뷰어로서 내가 맡은 역할 중 하나가 이런 세부 사항을 찾아내는 일이었다.

하지만 지난 6개월 동안 이런 엣지 케이스를 더는 일일이 확인할 필요가 없다는 사실을 깨달았다. 기계적으로 정확성을 챙기는 일에는 모델이 사람보다 훨씬 성실하다. 모델의 오류는 아키텍처, 예상하지 못한 사용 사례, 테스트 환경에서 피드백을 받지 못하는 시각적 출력 등에 국한된다. 그러다 보니 내가 리뷰하는 코드 대부분은 읽어도 별 도움이 되지 않는다. 그래서 diff를 받아 LLM으로 중요하지 않은 내용을 걷어 내는 도구를 만들었다. 이제 import 블록이나 nil 검사, 오류 처리 코드는 거의 볼 필요가 없다. 그런 내용은 화면에서 치우고 핵심만 볼 수 있게 한 것이다.

나는 이 도구가 마음에 들지만 단점이 두 가지 있다. 첫째, diff는 터미널이 아니라 UI가 잘 갖춰진 Shelley에서 읽고 싶다. 둘째, LLM이 diff를 소화해 간추리는 데 몇 분이 걸리는데, 그 시간을 기다리고 싶지 않다. 그러니 이상적인 방식은 명령줄에서 meat를 실행하는 게 아니라 Shelley에 내장하고, 커밋이 생성되는 즉시 전처리를 시작하게 만드는 것이다. 알고 보니 프롬프트 하나면 충분했다.

meat.dev를 Shelley에 내장해 줘. 최신 버전을 PATH에 설치해. Shelley에서 git 커밋이 생성되면 해당 커밋에 대한 meat 처리를 백그라운드에서 시작해. Shelley의 Diffs 화면에 meat 토글을 추가해. 커밋이 아직 처리 중이라면 사용자에게 처리 중이라고 표시해.

이 프롬프트 하나만으로 Shelley에 meat를 추가했을 뿐 아니라, 내가 세션으로 돌아와 diff를 리뷰하기 전에 커밋을 백그라운드에서 적절히 전처리하도록 만들 수 있었다. 덕분에 모델이 diff를 줄이는 동안 기다리지 않아도 됐다. 모델이 내린 선택 중 아쉬운 점은 토글 버튼에 🥩 이모지를 썼다는 것뿐이었다.

이 기능을 VS Code 확장 API에 끼워 넣으려면 얼마나 복잡하고 고통스러울지 상상해 보라. vimdiff에 넣는 일도 마찬가지다. 물론 가능은 하겠지만, 커밋이 나타나는 즉시 전처리를 시작하는 장치를 만드는 일은 거의 불가능에 가까울 것이다. 차라리 파일 시스템을 감시하면서 맞춤화 API가 사용할 수 있도록 meat 도구의 캐시를 제공하는 별도 meatd를 구현하는 편이 낫다. 기존 확장 지점과 설정 방식은 이 작업에 맞게 설계되지 않았기 때문이다.

바로 이것이 전통적인 설정·맞춤화와 에이전트 기반 개인화의 근본적인 차이다. 에이전트를 사용하면 훨씬 많은 일을 할 수 있다. 에이전트가 소스를 이해하고 내가 원하는 구체적인 작업에 맞게 수정하는 어려운 일을 맡는다. 우리가 매일 사용하는 소프트웨어는 개인화할 수 있을 때 훨씬 강력해진다. 필요한 것은 소스 코드뿐이다.

개인화된 소프트웨어의 시대

에이전트가 등장하기 전에는 개발 비용이 높았기 때문에 복잡한 소프트웨어에 대규모 설정 파일과 확장·플러그인 시스템을 넣어 배포하는 것이 합리적이었다. Vim처럼 중간 규모인 프로젝트조차 핵심 코드가 방대하고 복잡해 사람이 파악하는 데 몇 주가 걸린다. 줄 번호가 기본으로 표시되기를 바란다는 이유로 엔지니어가 코드베이스를 익혀 자신만을 위한 기능을 추가하리라고 기대하는 것은 무리다. 여러 사람이 공유하도록 설계하는 편이 낫다. 구현 비용을 많은 사용자에게 분산할 수 있으므로 그만한 비용을 들일 근거도 생긴다. 코드베이스에 기능이 늘어나면 공통 추상화를 찾아 확장 또는 플러그인 시스템으로 분리하는 것도 타당하다.

이제는 코드를 익히고 수정하는 비용이 크게 줄었다. 힘든 일은 에이전트가 맡는다. 사용자가 한 명이면 프로그램이 실행되는 조건도 극도로 제한된다. 이제 최상급 에이전트는 그런 환경에서 대개 한 번에 기능을 추가할 수 있다. 1인용 소프트웨어라면 꼼꼼한 코드 리뷰 대신 "제대로 작동하는 것 같은가?"라고 확인하는 것으로 충분한 경우가 많다.

그 결과, 개인화할 수 있는 소프트웨어에는 플러그인 시스템이나 설정 파일이 필요하지 않다. 텍스트 편집기의 글꼴 크기를 바꾸고 싶은가? 에이전트에게 소스를 주고 바꾸라고 하면 된다. 값이 하드코딩돼 있다면 에이전트가 찾아서 수정한다. 하드코딩된 비트맵 글꼴이라면 다른 글꼴을 내려받아 교체하거나 Monobit으로 새 글꼴을 만들어 줄 수도 있다. 필요할 때 즉시 활용할 수 있는 능력이 엄청나다.

소프트웨어 제품의 여러 범주를 완전히 새로 설계해야 한다

개인용 소프트웨어라는 접근법은 소규모 팀에도 잘 맞는다. 엔지니어링 팀이 공통 구성 요소를 조합해 원하는 기능만 만들 수 있는데, 왜 설정 기능이 극도로 많은 작업 관리 도구나 CMS, CRM을 구매하고 사용법과 설정법을 익히느라 시간을 쓰며 그 도구의 한계에 팀을 억지로 맞춰야 하는가?

소프트웨어를 개인화할 때 드는 초기 고정 비용과 지속적인 비용이 모두 사라졌다.

지금 읽고 있는 이 블로그도 Shelley로 만든 맞춤형 소프트웨어다. 기존 소프트웨어 제품을 맞춤 설정하는 것보다 Tiptap 같은 라이브러리를 조합해 개인화하는 편이 더 쉬웠기 때문이다. 오늘날 기업에서 최종 사용자용 제품이 가치를 가지려면 개인화할 수 있어야 한다. 그러려면 소스 코드가 필요하다.

Codex와 Claude Code가 갈라지는 지점

Shelley를 개인화하는 데 적용한 것과 같은 스킬 기반 기법은 Pi 같은 다른 오픈 소스 에이전트에도 아주 간단히 적용할 수 있다. 너무 간단해서 Pi에 확장 시스템을 따로 내장할 필요가 있는지 의문이 들 정도다. 소스 코드 자체가 확장 시스템이기 때문이다. 토큰이 훨씬 많이 필요하겠지만 오픈 소스 에이전트인 Codex에도 같은 방식을 적용할 수 있다.

하지만 Claude Code에서는 벽에 부딪힌다. Claude Code는 비공개 소스 소프트웨어라 개인화할 수 없다. Claude Code에는 전통적인 방식의 맞춤화 지점이 많이 마련돼 있다. 원하는 에이전트 작동 방식을 그 지점들로 구현할 수 있기를 바랄 수밖에 없다. 구현할 수 없다면 개인화를 허용하는 에이전트로 바꿔라.

^{source https://blog.exe.dev/devtools-must-be-open-source}

HN에서는 개발 도구의 소스를 공개해야 한다는 주장에는 대체로 공감했지만, 에이전트가 사용자별 포크를 자동 관리할 수 있다는 전망에는 신중한 반응이 많았다. LLM이 저장소 구조를 설명하고 빌드 환경을 마련하는 수고를 줄여, 예전에는 포기했을 작은 수정까지 시도하게 한다는 경험은 설득력을 얻었다. 그러나 수정의 문턱이 낮아졌다고 유지보수 부담까지 사라진 것은 아니라는 지적이 뒤따랐다.

글꼴 크기나 API 주소처럼 흔한 요구까지 소스를 고쳐 다시 빌드하는 방식은 비효율적이라는 비판이 두드러졌다. 설정 파일과 플러그인은 단순한 관습이 아니다. 사용자 변경분을 본체와 분리해 업데이트 비용과 충돌 가능성을 낮추고, 유용한 기능을 다른 사용자와 공유하기도 쉽게 한다. 실제로 개인용 포크를 운영한 개발자들도 LLM을 활용했지만, 상류 변경을 계속 따라가는 일은 여전히 부담스러웠다고 전했다.

특히 매일 밤 상류 코드를 받아 변경분을 재적용하고 자동 검증한다는 구상은 불안을 키웠다. 에이전트가 명시된 조건은 충족해도 사용자가 기대한 동작과 사용성을 놓칠 수 있으며, 중요한 순간에 도구가 깨지면 결국 사람이 원인을 찾아야 한다. 여러 사람이 같은 화면과 동작을 보며 교육하고 검토하는 도구에서는 지나친 개인화가 공통 기준을 흔들 수도 있다. 다만 쉽게 포기할 수 있는 개인 기능이나 변화가 느린 도구라면 시도할 여지는 있다는 평가도 나왔다.

결국 실무에서 확인할 것은 소스 공개 여부만이 아니다. 변경분을 얼마나 오래 유지할지, 상류 업데이트가 얼마나 잦은지, 자동 검증이 실제 사용성을 다루는지, 장애 때 되돌릴 수 있는지, 팀의 표준 환경이 필요한지를 함께 따져야 한다. 업무용 도구라면 유지보수 주체와 지원 체계에 대한 신뢰도 수정 가능성만큼 중요한 선택 기준이 된다.